こんにちは！食べログノートチームの荒川です。
弊社では現在Devin、Claude Code、CursorといったAIツールの活用により、エンジニアの開発作業は変化しています。しかし、単に「○○の画面を作って」というプロンプトだけで、思い通りのプロダクションレベルのコードを得るのは依然として困難です。
本記事では、昨年度私が担当した、食べログの店舗管理画面のSPページ刷新プロジェクトにおいて、これらのAIツールを活用してフロントエンドの実装とテストに取り組んだ際の成果と見えてきた課題を共有します。
新しい店舗管理画面SPページ
プロンプトから生成する画面の精度の課題
これまで、部分的にAIを使った開発は行なってきましたが、０からシステムを構築するのはこのプロジェクトが初めてでした。
まっさらなリポジトリに単に要件定義書のテキストをコンテキストとして読み込ませ、デザインの画像を元にReactコードを生成しようとすると、以下のようなギャップに直面しました。
- ビジネスロジックの反映漏れ:
テキストを読ませた上での指示だけでは、意図通りに入力チェックやクリック時の期待値が正確にコードに反映され辛い。 - デザインの再現性:
細かな余白やフォントサイズ、スタイルガイドラインが正確に反映されない。 - 構造の整理不足:
JSXが肥大化し、再利用性が低いコードが出力される。 - モジュール設計の不一致:
チームの規約、モジュールの設計方針に基づいたコンポーネント分割やディレクトリ構造にならない。
これらのギャップを埋めるために大量のプロンプトを手動で書くのは、かえって工数が増えてしまい、AI活用のメリットを相殺してしまいます。
ドキュメントをAIが参照するナレッジにする
そこで試みたのが、「要件のドキュメントをAIのナレッジベースとして接続する」というアプローチです。
当社では以前から要件定義などのドキュメントはConfluence、画面デザインはFigmaを利用しています。去年はタイミングよく Atlassian MCPとFigma MCP server がリリースされたので、これらを活用しました。人間が要件を要約して伝えるのではなく、AIが必要な時に必要なドキュメントを自ら読みに行く形を構築しています。
実現方法：開発からテストまでの具体的なステップ
実際の開発プロセスは、以下の取り組みを行いました。
1. 知識のインプット：Atlassian MCP Serverで業務知識を参照
まずは、業務の核心となるドメイン知識をAIに提供します。
Atlassian MCP Serverを利用し、Confluence上の要件定義書をAIが直接参照できるようにしました。
- 動的な参照:
プロジェクトの要件、周辺情報の参照するURLを指定し、漏れなく最新の仕様を元にコードを生成できる環境を整えました。 - 構造化:
主要な要件や、画面の仕様などは膨大なConfluenceページをそのまま読ませるのではなく、一度Markdown形式に構造化して同一リポジトリ内に管理し、AIが理解しやすい以下のようなナレッジを生成しました。
- 要件定義書
- Confluenceの記載からプロジェクトの概要、業務要件、非機能要件などをMarkdownに出力したもの
- 画面一覧
- 開発対象の画面と、URLの一覧
- 画面フロー
- 画面間の遷移を表したもの
- 画面設計
- ページ個別の仕様、機能の定義
2. UIコンポーネントの生成：Figma MCP serverでデザインをコード化
次に、デザインの見た目をコードに落とし込みます。
Figma MCP serverを使用し、Figmaのデザインデータを直接入力ソースとしてReactコンポーネントを生成します。今まではデザインを一度画像ファイルなどに落として入力していましたが、MCPを利用することで手間が減っただけに留まらず、より正確にデザインがStyleに反映できるようになりました。
また、本プロジェクトにはStyleのフレームワークにTailwind CSSを採用しています。ユーティリティクラスに基づいたコードは、スタイリングの自由度の高いフレームワークより再現性の高い出力が得られ易いと考えたためです。
3. モジュール設計の体系化：プロジェクト規約の共有
生成するたびにコードの品質にばらつきが出ないよう、設計思想やコーディング規約をAIのナレッジにします。
本プロジェクトでは Bulletproof React のアーキテクチャを採用しました。以前、食べログでは「Atomic Designから移行した話」を紹介しました。これに似ていて親しみ易かったことと、規約のドキュメントが整備されていて、AIのナレッジに使い易かったことなどが理由です。
4. テストの自動生成：ドキュメントからテストを作る
最後に、信頼性を担保するテストコード、およびテストケースを生成します。
これらのナレッジと実装コードから、Jest/React Testing Libraryの単体テストコードと、Gherkin記法の結合試験ケースをそれぞれ生成しました。
実装に基づいた単体テストケースの生成は再現性が高く、網羅率などの簡単な指示でほぼそのまま使えるものが生成できました。
これに対して、シナリオベースの結合テストは簡単にはいかず、ケースの粒度にばらつきがあったり、ケースの分類が整理されていないといった問題が出てきました。 これらの問題は以下のようなナレッジを用いて解決していきました。
# ケース抽出時の注意点 - Gherkin記法でテストケースを作成してください - 第一階層を画面名とし、画面ごとにケースをまとめてください - 第二階層を正常系、異常系でケースを分類してください # ケースの抽出には以下の観点を用いてください UI/UX - レイアウト崩れがないか（各種画面サイズ、動的コンテンツ） - 文字の見切れ、重なりがないか - 操作に対するフィードバック（ローディング等）が適切か - 画面遷移が仕様通りか ... 機能 入力: - 最小/最大文字数での入力 - 境界値（仕様の端となる値）での入力 - 不正な文字種（記号、絵文字など）での入力 - 必須項目が未入力の場合のエラー表示 データ表示: - 0件の場合の表示（空の状態） - 多数件の場合の表示（リストのスクロールなど） - API取得失敗時の表示（エラーメッセージ、リトライ処理） ...
ドキュメントという「正解」をAIが直接知っているため、実装との不整合を突くようなテストケースも効率的に作成できます。
考察：AIとの協業で得られた成果と新たな課題
実際にこの手法を試してみて、いくつかの明確なメリットと、乗り越えるべき課題が見えてきました。
得られたメリット
- プロンプトの簡略化:
「○○画面を作って」という抽象的な指示でも、FigmaやConfluenceの情報をMCP serverを通じて参照することで、コンテキストを含んだ精度の高い実装が返ってくるようになりました。 - 実装コストの削減:
手作業ではDOMやスタイルの構築に半日〜1日かかっていたものが、1〜2時間程度の手直しで済むようになりました。特にデザインからTailwindのコードへの変換は、ほぼ生成のみで完結します。 - 価値への集中: 定型的なコーディングやテストケース作成の工数が減った分、ビジネスロジックの作り込みや複雑なユーザー体験の設計といった、サービスの価値に直結する部分に時間を割けるようになりました。
見えてきた課題と対策
初期精度の向上（Few-shot）:
初期のコードベースがまっさらな状態では、AIの生成結果が期待通りの設計にならないこともありました。そこで、ベースとなる1機能分（データ取得から画面表示まで）は手作業で作り込み、それを手本としてAIに提示（Few-shotプロンプティング）することで、後続の画面の生成精度を飛躍的に向上させることができました。スタイルの重複問題:
AIがTailwindを生成すると、要素ごとにユーティリティスタイルが書かれてしまいました。また、重複しているスタイルが考慮されず、以下の例のような余分なコードが多く発生しました。
// 本来は親の要素で定義すれば良いが、テキスト本文の要素に同じStyleが出力されてしまう
// おそらくデザインの定義で個別にfontの指定がある為？
return (
<div>
<div>
<p className="font-['Hiragino_Kaku_Gothic_ProN:W6',_sans-serif] leading-[1.5] text-[#273c5c] text-[14px] font-bold">{title}</p>
</div>
<div>
<p className="font-['Hiragino_Kaku_Gothic_ProN:W6',_sans-serif] leading-[1.5] text-[#273c5c] text-[14px]">{content}</p>
</div>
</div>
)
また、部分的に同じ見た目の実装でもDOMがベタ書きされ、共通化が難しい場合があります。
今の時点ではこれらによるパフォーマンス・出力サイズへの顕著な影響は確認されていませんが、継続的な監視の仕組みは今後の課題として認識しています。 一方、コードの保守性については「DOM・Styleの作成・変更は生成を前提とした保守」という方針を取り、Linter・Formatter・ロジックのテストを厚くすることで定量的な品質担保としています。 人の手で実装の最適化を進めると、AIによる生成・改修の効率化メリットが損なわれるうえ、改修時にも人手対応が必要になるという懸念があるためです。
これらの課題に関しては、Figmaの Code Connectの導入や、AIによる生成の精度の向上・リファクタリングの方法などを検討し、取り組んでいきたいです。
結論：AIとの協業と、この手法が活きる条件
AIを活用した開発効率化は、単に便利なツールを使うだけでは達成できません。
今回の挑戦を通して感じたのは、「AIが参照することを前提としたドキュメント管理」 の重要性です。ドキュメントを構造化し、曖昧さを排除して管理することは、人間にとってもAIにとっても価値ある資産になります。
私の所属するチームでは現在、業務知識・仕様・テストを一つのgitリポジトリで管理し、AIのナレッジとして活用する取り組みを始めています。AIを単なる「コード生成機」としてではなく、ドキュメントを理解する「パートナー」として迎え入れることで、よりクリエイティブな開発に集中できる環境を作っていきたいと考えています。
採用リンク
