Mock駆動開発のススメ──AIに実装させる前に、Mockで「正解」を固定する
AIエージェントに実装を任せられるようになって、開発のボトルネックが移動しました。書く速度ではなく、「できあがったものが正しいかを判定する速度」がスループットを決めるようになったのです。
エージェントは1時間で数十ファイルを変更します。人間が1つずつ目視で確認していれば、レビュー待ちの行列がすぐ伸びます。しかも指摘のほとんどは「思っていたものと違う」という種類のもので、これは実装の質ではなく受け入れ基準が曖昧だったという問題です。
Mock駆動開発は、この順序を入れ替えます。実装を依頼する前に、Mockで「完成の姿」を確定させ、それを判定基準として使う。本記事では、その考え方と既存プロダクトへの入れ方を整理します。
Mock駆動開発とは何か
一文で言うと、こうです。
実装より先にMockを確定させ、Mockを受け入れ基準（審判）として使う開発の進め方。
ポイントは、Mockの位置づけが変わることです。
| 従来のモック | Mock駆動開発のMock | |
|---|---|---|
| 目的 | 完成イメージの共有・社内合意 | 判定基準（何をもって完成とするか） |
| 作るタイミング | 要件定義の途中、参考資料として | 実装着手の前提条件として、先に確定 |
| 実装との関係 | 実装が始まると参照されなくなる | 実装の入力であり、受け入れ判定の対象 |
| 更新 | 実装とズレたまま放置 | ズレを残さない（原則は実装を直す。Mock側の誤りを再合意したときだけMockを更新） |
「デザインを先に作る」という話ではありません。判定できない基準でAIに実装させないという規律の話です。
「使いやすい一覧画面を作って」が破綻する理由
この指示をAIに出すと、それらしい画面が出てきます。ここで問題になるのは出力の質ではなく、受け入れられるかどうかを機械が判定できないことです。判定が人間の目にしか宿っていないので、次の3つが起きます。
- レビューが人間の目の数で頭打ちになる（並列化しても人間が詰まる）
- 指摘が「好み」に見えて、エージェントに同じ間違いを繰り返させる
- 直しても、次の画面で同じ議論が再発する
Mockが先に在れば、判定はこう降りてきます。
- レイアウト構造 → Mockと同じ構造か
- 色・余白・タイポグラフィ → デザイントークンに準拠しているか
- 表示項目 → Mockに存在する項目と一致するか
- 画面遷移 → ユーザーフローと一致するか
いずれも人間の主観を通さずに確認できる形になります。ここが「絵」と「審判」の違いです。
全体の流れ
Mock駆動開発では、Mockが起点になって下流が決まります。
Mock 確定
├──→ 画面一覧 / ユースケース / ユーザーフロー
├──→ デザイントークン（色・余白・タイポ）
│
└──→ シーケンス図（必要なAPIの洗い出し）
│
▼
既存API定義と突合
├─ 在る → 既存APIを結線（変更しない）
└─ 不足 → まず既存の組合せで賄えないか再検討
（それでも不足なら別フェーズ扱い。後述）
│
▼
実装
│
▼
受け入れ判定 ＝ Mockとの一致
順番に意味があります。
1. Mockから画面一覧・ユースケース・ユーザーフローを起こす
逆ではありません。ユースケースを先に文章で書き切ってからMockを作ると、たいてい書き漏れが出ます。Mockを見ながら「この画面はどの業務のどの手順か」を割り当てていくと、抜けが目に見えます。
2. デザイントークンを確定させる
色・余白・タイポグラフィを値として固定します。トークンは機械判定できる基準なので、ここを決めておくと「なんとなく違う」という指摘が消えます。
3. 必要なAPIを洗い出し、既存API定義と突合する
これが地味ですが効きます。ユースケースとシーケンス図から必要なAPIを列挙し、既存のAPI定義書と突き合わせて、不足が確定した分だけを拡張APIとして定義する。この突合表（画面↔APIマッピング表）を作らずに実装へ入ると、AIは「存在しないAPI」を前提にした実装を平気で出してきます。
4. 実装し、Mockとの一致で判定する
実装フェーズの指示は「使いやすい画面を作って」ではなく、「このMockの構造と、このトークンと、この画面↔APIマッピングに従って実装して」になります。
既存プロダクトでこそ効く
Mock駆動開発は新規開発の話に聞こえますが、実は既存プロダクトの改修で最も効きます。 理由は、既存プロダクトには「変えなくていいもの」が大量にあるからです。
数年動いている業務システムには、次のものが揃っています。
- 実運用に耐えているデータモデル
- 業務要件や制度を反映したビジネスロジック
- それを外に出すAPI
これらは古い資産ではなく、検証済みの仕様そのものです。だからこう決められます。
原則、バックエンド（データモデル・ビジネスロジック・既存APIの挙動）は変えない。変えるのはフロントだけ。
ここで「必要なAPIが不足していた」場合の扱いを、先に決めておきます。新規エンドポイントの追加は、追加であってもバックエンド変更です。 データ取得や認可の実装が伴うため、下に挙げる「切り分けがフロントに閉じる」という効果は、その機能については崩れます。
だから優先順位はこうなります。
- 既存APIの組み合わせで賄えないかを先に検討する（実際、多くはこれで足ります）
- どうしても不足するなら、その機能だけを別フェーズ＝バックエンド変更として切り出す
- 切り出さずに進めるなら、既存エンドポイントには一切手を入れず新規追加に限定し、その機能は例外扱いであることをチームで共有する
避けたいのは、「不足APIがあったから」を入口に、なし崩しで既存エンドポイントの改修まで広がることです。
Mockを先に確定させると、この決定を工程として強制できます。フロントの完成形が固まっているので、データモデルを触る動機が発生しないのです。
得られるものは5つあります。
| 決めたこと | 効果 |
|---|---|
| マイグレーションが発生しない | 最も後戻りが困難な作業が消える |
| ビジネスロジックを再実装しない | 最も事故が起きやすい領域をAIに触らせない |
| 既存APIが「動く仕様書」になる | OpenAPI等の形で機械可読に抽出できる |
| 不具合の切り分けがフロントに閉じる | 原因候補が1層に限定される（拡張APIを足した機能は除く） |
| 禁止領域が明確になる | 「DB・認可・課金には触らせない」をルールとして書ける |
特に2番目が重要です。制度計算や判定ロジックの誤りは、間違っていても動いてしまうため、テストが無い状態では発見されません。ここをAIに書き直させないだけで、リスクの大半が消えます。
Mock駆動開発が向く場面・向かない場面
| 向く | 向かない |
|---|---|
| 既存バックエンドを使い回すフロント刷新 | Mockを作れないほど要件が流動的な探索フェーズ |
| 画面単位に分割できる機能追加 | バッチ処理・データパイプラインなど画面を持たない領域 |
| 複数人・複数エージェントで並行して進めたい | 数行の軽微な修正（固定費のほうが高い） |
| レビューが詰まっている | 1人で全部見られる規模 |
画面を持たない領域では、Mockの代わりに**入出力の実例（ゴールデンデータ）**が同じ役割を果たします。「正解を先に固定してから実装させる」という構造は同じです。
何から始めるか
- Mockを1画面ぶんだけ確定させる。 全画面を揃える必要はありません
- その画面のデザイントークンを値として書き出す
- その画面が必要とするAPIを列挙し、既存API定義と突合する
- 受け入れ基準を「Mockとの一致」として明文化する
- AIに実装させ、判定してみる。 判定が主観に落ちた項目があれば、それが基準の穴です
1画面ぶんで型ができたら、以降は同じ手順を横に展開するだけになります。
シリーズ記事
この記事はシリーズのハブです。各論はこちらをご覧ください。
- Mockを「審判」にする──テスト資産がない既存プロダクトでAI駆動開発を回す方法 テストが無いプロダクトで、何を終了条件にするか。審判の作り方を「正解の出所」で場合分けします
- 既存リポジトリでAI駆動開発を始める順序──まず変数を減らす 同時に変えるものを減らす／分離する。着手順序の話です
- AIに読ませるドキュメント体系──L0〜L6と正本ルール AIの出力を安定させるコンテキストの整備順です
- チケットからマージまで──AI駆動開発の日常ループと多層ゲート 型ができた後、毎日どう回すか。品質ゲートとブランチ運用です
エージェントの並列実行そのものについては「Dynamic Workflows 徹底解説」も参考になります。
よくある質問
Q. Mockはどのツールで作るべきですか？ A. ツールは問いません。Figmaのようなデザインツール、HTMLの静的モック、生成AIによるUIプロトタイプのいずれでも成立します。条件は「構造と値が読み取れる状態で固定されていること」だけです。判定に使うので、更新履歴が追えるところに置いてください。
Q. Mockを作る時間がありません。実装しながら決めるのでは駄目ですか？ A. 実装しながら決めると、判定基準が実装の後追いになります。結果として「できたものを見て良し悪しを決める」ことになり、AIの生成量が増えるほどレビューが破綻します。1画面ぶんのMockに数時間かけるほうが、その後の手戻りより安いという判断です。
Q. デザイナーがいない場合はどうしますか？ A. デザイントークン（色・余白・タイポグラフィの値）と、既存画面の構造を流用するだけでも判定基準として機能します。目的は美しさではなく、判定可能性です。
Q. バックエンドも変えたい場合はどうしますか？ A. 同時に変えないことをおすすめします。フロントを先に置き換え、型ができてから、データモデル変更を別フェーズとして切り出してください。理由は「既存リポジトリでAI駆動開発を始める順序」で詳しく説明しています。
Q. Mockと実装がズレたときはどちらを直しますか？ A. 原則としてMockを正本とし、実装を直します。ただしMock側が業務上成立しないことが判明した場合は、Mockを直してから実装をやり直します。ズレたまま進めないことがルールで、どちらを直すかは状況判断です。
関連サービス
最終確認日: 2026-07-26