プロダクトヒストリーカンファレンス2026 登壇レポート
ソフトウェアの開発ライフサイクル全般にAIを組み込み、AIの支援や自律的な処理を前提に開発を進める「AI駆動開発」が注目を集めています。
しかし、いざフロントエンド開発に導入してみると、「デザインが再現されない」「既存のコード規約を無視される」「不具合の目視確認に時間がかかる」といった壁に直面している開発者やマネージャーも多いのではないでしょうか。
本記事では、2026年6月26日～27日にかけて開催され、SHIFTがダイアモンドスポンサーを務めた「プロダクトヒストリーカンファレンス2026」をレポート。
イベント当日はAIモダナイゼーション技術企画部 DevOpsエンジニア 馬塚が登壇し、フロントエンド開発を「イチゲキ」で行う取り組みを通じて得られた知見を紹介しました。
AIが迷わず高品質なコードを書くために必要な環境を整える「下ごしらえ」の重要性と、人間の目視をゼロにする「自動検証ループ」を紹介します。
-
AIモダナイゼーション技術企画部 DevOpsエンジニア 馬塚
独立系ソフトウェアベンダーにてWebアプリ開発等に従事した後、2020年にSHIFT入社。SHIFTではスクラム開発チーム向けにExtreme Programmingの各種プラクティスのコーチングや技術支援を実施。現在はSHIFT 開発標準（DQS）のボイラープレートの作成とAI開発プロセスの策定をメインで行っている。
目次
「フロントエンドをイチゲキで実装したいよね」からはじまった挑戦
システム開発において、不具合が多く発生しがちなのがフロントエンドです。ユーザーの目に直接触れる部分であるため、ここに不具合があるとシステム全体の品質が低いとみなされてしまいます。
「AIを使って、フロントエンドの開発を高品質かつ高速に、イチゲキで完了させられないか」——。
そんな想いから生まれたのが「イチゲキ実装」という取り組みです。
昨今のAIツールは進化しており、プロンプトを投げるとコードを吐き出してくれるツールも登場しています。
しかし、受託開発を行うSHIFTがもっとも重視しているのは「お客様との合意形成」です。
「これからどんな画面ができるのか」を事前に示し、お客様とイメージをすりあわせるためにはデザインデータが必要です。
そこで、私たちはFigmaで作成したデザインを、信頼できる唯一の情報源（SSOT：Single Source of Truth）としました。
ぶつかった3つの壁と、3度の失敗の歴史
プロジェクト開始後、いざFigmaのデータをAIに渡してイチゲキで実装させようとしましたが、大きく3つの壁に直面しました。
1.曖昧な設計書：自由な仕様書をAIに読ませると、足りない情報をAIが勝手に推測してしまい、出力が毎回ばらついた。
2.車輪の再発明：予め作成済みのボイラープレートコードを無視し、AIが独自の部品をつくり出してしまった。
3.目視の限界：AIが生成したアプリの画面と元のFigmaを、人間が目視で確認する方法は見落としの温床になる。
これらの壁を越えるために重ねた、3つの失敗をご紹介します。
失敗①：DevinにFigma MCPをそのまま渡した
最初に、私たちはDevinにFigmaのデザインURLをそのまま渡して「MCPを使って、この通りに実装して」と指示しました。
結果は、ステッパーや入力フォームの見た目が崩れ、実行するたびに出力が変わる不安定な状態でした。
実は当時Devin上で動いていたFigma MCPは公式製ではなくサードパーティ製だったという落とし穴もありましたが、根本的な原因は、Figmaがもつ膨大な情報量をAIが処理しきれず、情報の読み飛ばしが発生。デザインの再現性は低く、出力も不安定でした。
失敗②：JSONファイルによる中間データの抽出
次に、必要な情報だけを抽出したJSONファイルをAIに読み込ませました。出力のブレは減りましたが、Figmaのレイヤー構造や命名規則に強く依存しており、見た目の再現性は不十分でした。
失敗③：Figma Makeの導入
Figma公式の「Figma Make」を試したところ、UIの再現性は劇的に向上しました。
しかし、生成されたコードと私たちが予め用意していたボイラープレートの規約の違いから、その後のロジック追加作業が困難になるという新たな問題が発生しました。
また、当時はFigma MakeにGitリポジトリを直接渡せなかったため、「Figma Makeでコード生成 → Devinでボイラープレートを適用」という二段階の手順が必要となり、「これではイチゲキといえない」という課題が残りました。
（※なお、発表直後の2026年7月頃にFigma Makeへローカルコード連携機能のベータ版が追加されたとのことです）。
これらの失敗から得た教訓は、「ただツールを使うだけではなく、AIが迷わず高品質なコードを出力できる環境（下ごしらえ）を人間側が整えることこそが本質である」というものでした。
AIのポテンシャルを最大化する、5つの「下ごしらえ」
失敗を踏まえて、私たちは見た目（UI）の実装精度を高める3つの下ごしらえと、機能（ロジック）やテストに効く2つの下ごしらえを考案しました。
【下ごしらえ①】Figma Code ConnectでデザインとReactコードを宣言的に紐付ける
Figma Code ConnectはFigma上のデザイン要素と、あらかじめ用意したReactコンポーネントを明示的に紐付ける仕組みです。
AIは通常、Figma上のボタンが既存コードのどれに当たるかを知らないため、似たコードを探すか、見つけられずに勝手につくってしまいます。
Code Connectを用いることで、Figma MCP経由で「このデザインコンポーネントはこのコードを使う」「Figmaのバリアント（disabledなど）はReactのこのpropsに対応する」という情報がLLMに正確に渡るようになります。
SHIFTでは、標準で用意されている70〜80個のコンポーネントすべてに対して定義ファイルを作成しました。
膨大な作業に見えますが、「最初の1個をテンプレートとして人間がつくり、残りの定義ファイルはすべてAIに自動生成させる」ことで効率的にすべての定義ファイルを作成しました。
【下ごしらえ②】デザイントークンとコードを繋ぐ「デザインシステムルールファイル」の構築
デザイン上の色や文字サイズ（デザイントークン）を、実際のコード（Tailwind CSSのクラス）にどう変換するかをAIに教える仕組みです。
ここではFigma MCPの標準ツールである「create_design_system_rules」を実行。このツールはFigmaデザインを見るのではなく、既存のコードベースを解析してマッピングルールを自動生成します。
このルールファイルをAIに読み込ませることで、例えば「STD-16N」といった抽象的なデザイントークンから、迷わず正確なTailwindクラスを出力できるようになりました。
【下ごしらえ③】AIが読み取れる階層構造や命名規則を定めた「デザインガイドライン」の徹底
どれだけツールを連携させても、元のFigmaデザインが整理されていなければ意味がありません。
そこで、デザイナーとエンジニアが協働するためのデザインガイドラインを策定しました。
・レイヤー名の統一：Figma上のレイヤー名をReactコンポーネント名と揃え、AIの誤認を防ぐ。
・階層構造の最適化：デザイナー向けの深いグループ階層をあえて整理し、AIが読み飛ばさないように階層を浅く保つ。
・アクセシビリティ情報の“仕込み”： Figmaのメモ（アノテーション）機能にalt属性やaria-labelを記載。実装時、Figma MCPがその情報を自動取得し、AIがReactコードへ反映する。
【下ごしらえ④】備考欄を廃止し、AIの推測を排除する「構造化テンプレート」
曖昧な指示を排除するため、設計書の備考欄を廃止しました。代わりに、ボタンの活性化条件や強制的に初期化する項目など、書くべき内容を専用のカラムに細かく分割した“構造化テンプレート”を用意。
また、全角変換など100%結果が決まっている単純な処理は共通部品に仕込んでおき、AIには「設計書に指定があればプロパティをONにするだけ」と指示しました。
設計書の構造化により、セクションごとにサブエージェントを立ち上げて並列実装させることも可能になり、開発スピードが飛躍的に高まりました。
【下ごしらえ⑤】SHIFTのノウハウを凝縮した「テスト設計ガイドライン」
SHIFTが長年培ってきた、900項目にも及ぶ“標準テスト観点”をガイドライン化しました。最大の特徴は、「機能コードを実装させる前に、テストコードを先に書かせる（テストファースト）」点です。
構造化された設計書とテストガイドラインをAIに渡すことで、自動テスト仕様書と手動テスト仕様書を振り分けて生成させ、そこから自動テストコードを出力させます。
更地に家を建てる前に強固な測定器を置いておくように、AI自身にクリアすべき合格ライン（テスト）を先にセットさせ、そのテストをパスするコードを書かせることで、ロジックの不具合を抑え込んでいます。
目視チェックの極小化を目指す。自動検証ループの飽くなき探求
5つの下ごしらえによってAIのコード生成精度は劇的に向上しましたが、最後に検証（レビュー）の壁が立ちはだかります。
数百画面に及ぶ開発では、人間の目視による確認はどうしても見落としが発生します。
目視チェックをなくすために考案したのが、ビジュアルギャップ検証です。一般的な画像同士のピクセル比較では、1ピクセルずれただけで全てエラーとなり実用的ではありません。
そこでSHIFTでは、「Figmaデザインから変換したHTMLのDOM構造」と「Playwrightでアプリ画面を表示して抽出したDOM構造」を直接比較する構造比較を採用しました。
これにより「このボタン要素が欠落している」「テキストが違う」といった具体的な差異を検出できるようになりました。
さらに、検出したギャップレポートをAI自身に読み込ませ、自動修正させるループを構築しました。
「自分で間違いを見つけ、自分で直す」というサイクルを、デザインと実装の差異が解消されるまでまわしつづけるのです。
人間の目視チェックをゼロにするためのSHIFTの執念が、この自動検証ループに込められています。
手作業12時間が4時間に。一度つくった下ごしらえは組織の共通資産になる
これら5つの下ごしらえとビジュアルギャップ検証による“自動検証ループ”により、イチゲキ実装は現場に大きな変化をもたらしました。
入力フォームを例にとると、これまで人が手作業で行い10〜12時間かかっていた実装作業が、4時間程度まで短縮されました。
また、明確なルールとガイドラインを設けたことで属人化が排除され、安定した品質の確保につながりました。
AIとの対話回数が減ることで、コストも削減されるという副次的な効果も生まれています。
これらの下ごしらえは、一度構築すればほかのプロジェクトでも活用できる “組織的な標準化”の結晶です。
AIは単にプロンプトを投げるだけで完璧な結果を返してくれる魔法の杖ではありません。
質とスピードを両立させるための鍵は、人間がコードベースとプロセスを整え、標準化を推進する“下ごしらえ”にほかならないのです。
下ごしらえを制する者がAI駆動開発を制す。
SHIFTが失敗の歴史を糧につかみ取ったこの教訓は、AI駆動開発時代を生きる開発チームにとって、広く役立つものだと確信しています。
（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）
