Mockを「審判」にする──テスト資産がない既存プロダクトでAI駆動開発を回す方法
AI駆動開発において審判（judge）とは、終了条件のことです。エージェントは「完成したかどうか」を自分で判断できないので、外側に判定装置が必要になります。これが無いと、ループは止まりません。正確には、止まる場所が「人間が目視で満足したとき」になり、そこがスループットの上限になります。
一方、既存プロダクトにテストが無いのは普通です。数年動いているシステムで、外部から叩ける形のテストが十分に揃っている例は少数派です。
本記事の主張はシンプルです。
「テストが無いから始められない」ではなく、審判を作る作業そのものを最初のスプリントにする。 AIに書かせる最初のコードは、プロダクトコードではなく審判です。
審判の作り方は「正解の出所」で決まる
ここを間違えると、作った審判が機能しません。最初に問うべきことは1つです。
その機能の「正解」を、いま何が決めているか？
答えは4通りあり、それぞれ審判の作り方が違います。
| 正解の出所 | 典型的な作業 | 審判 |
|---|---|---|
| 現行実装 | リファクタ、リポ統合、挙動据え置きのUI刷新 | 新旧の出力を diff する |
| 制度・業務ルール | 計算ロジック、判定ロジック | ルール文書から生成したテストケース |
| どこにも無い | 新規UI、新機能 | Mock |
| 人の主観 | 文言、レイアウトの妥当性 | LLMによる採点（ルーブリック） |
以下、順に見ていきます。
段1｜正解が現行実装にある場合 — 差分テスト
リファクタや、挙動を変えないUI刷新では、現行実装が完全な仕様書です。仕様書が古くても、動いているコードは嘘をつきません。
やることは差分テスト（characterization test）です。テストコードである必要すらありません。
- 代表シナリオを7〜10本選ぶ
- 新旧の両方に同じ入力を流し、出力を diff するスクリプトを書く
- 失敗した1本ごとに修正エージェントを当て、全部通るまでループ
- 通ったら、その diff スクリプトが以降の回帰テストになる
大規模なコード移行の事例でも、テストスイートが無かった側は「7つの実シナリオを新旧で diff する小さなスクリプト」から始めています。さらに一段進めるなら、AI自身にE2Eスイートを設計させ、夜間に自走させて壊れたものを直させる。数晩回すと、シナリオ表では予測できなかった細かい不具合が出てきます。
ここで大事なのは、元のコードベースが常に ground truth であるということです。仕様書が無くても、比較対象があれば審判は作れます。
段2｜正解が制度・業務ルールにある場合 — ルール文書からテストを起こす
規制産業の業務システムでは、正解がコードでも人の好みでもなく制度にあります。配置基準の判定、按分や端数処理、加算の可否といった領域です。
この場合の順序はこうなります。
- 業務ルールを正本ドキュメントとして書き切る（ルール集・計算ロジック仕様）
- 業務有識者のレビューを、コードではなくこのルール文書に対して行う
- ルール文書からテストケースを生成する（境界値・端数・例外を特に）
- そのテストケースを審判としてループを回す
これが「人間の時間を前倒しする」の実体です。有識者の時間は希少なので、生成された大量のコードに使うのではなく、その全部を規定するルール文書1枚に使います。
レビューの優先順位も機械的に決める
ドキュメントが数十本あると「どれから見るか」で揉めます。3軸のスコアで並べると議論が収束します。
| 軸 | 意味 |
|---|---|
| 参照頻度（正本性） | 他のドキュメントからどれだけ参照されるか |
| 業務・法令インパクト | 間違えたときの実害の大きさ |
| 実装との乖離リスク | 現行実装とズレている可能性 |
各1〜3点、合計9点満点。上から潰します。実務では用語集と「正本ルール」が最上位に来るのが典型で、これは基盤ドキュメントの誤りが下流全部に伝播するという当たり前の帰結です。
段3｜正解がどこにも無い場合 — Mockが審判になる
新規UIや新機能では、現行実装も制度も答えを持っていません。ここでMockが審判の役割を引き受けます。
Mockが審判として機能するのは、次の4点が機械的に確認できる形になるからです。
| 判定対象 | Mockから降りてくる基準 |
|---|---|
| レイアウト構造 | Mockと同じ構造・同じ階層か |
| 色・余白・タイポグラフィ | デザイントークンに準拠しているか |
| 表示項目 | Mockに存在する項目と一致するか（過不足なし） |
| 画面遷移・データ取得 | ユーザーフローと画面↔APIマッピングに一致するか |
「使いやすいか」は判定できませんが、「Mockと一致しているか」は判定できます。 そして使いやすさの議論は、Mockを作る段階（人間が合意する場面）に前倒しされています。これがMock駆動開発の眼目です。
考え方の詳細は「Mock駆動開発のススメ」をご覧ください。
段4｜機械が判定できない領域 — LLMをルーブリックで使う
文言の自然さ、エラーメッセージの適切さ、レイアウトの妥当性など、どうしても定量化できない領域は残ります。ここはLLMを審判として使う（LLM as a judge）方法があります。
条件が2つあります。
- ルーブリック（評価観点と点数基準）を明文化する。 「良いか」ではなく「この観点で何点か」を聞く
- judge自体の妥当性を人が抜き取り検証する。 判定が甘いjudgeは、品質低下を隠蔽します
judgeは万能ではなく、人間のレビュー物量を減らすための減衰装置として捉えるのが実務的です。
段5｜それでも残る部分 — 工程として回収する
最後は実ユーザーに見てもらうしかありません。ここで重要なのは、それを偶然に任せず工程として設計することです。
開発 → レビュー → 単体テスト → CI（統合・E2E・build）→ ★初期リリース
↓
FB① → 修正① → FB② → 修正② → 完成（全体公開）
↑
限定パイロット（検証環境 or 一部ユーザー）
ここでいう初期リリースは「全体公開」ではありません。 検証環境か、合意済みの一部ユーザーに限定して出すパイロットです。通常のリリースゲート（統合テスト・E2E・セキュリティ確認・CIの全テストとbuild）は省略しません。 これを飛ばすと、前章までに積み上げた多層ゲートを最後で無効化することになります。
省略するのは「全ユーザーに出す前の完成度の作り込み」であって、品質ゲートではない、という切り分けです。そのうえで実ユーザーのフィードバック→修正を2サイクル回してから全体公開とする。1機能＝このサイクルを単独で完結できる単位と定義しておくと、複数機能を並行で走らせられます。
全部に共通する規律：審判を壊して検証する
作った審判は必ず検証します。
- 正しいコードで通ることを確認する
- わざと壊したコードを流して、落ちることを確認する
2番目を飛ばす人が多いのですが、ここが本質です。落ちない審判は審判ではありません。 アサーションが緩いテスト、diff対象が浅いスクリプト、点数が甘いルーブリックは、「全部通った」という誤った安心を提供します。
大規模移行の事例でも、既存テストスイートが全通過した状態でマージした後に十数件の不具合が出ています。機械的な審判が提供するのは「安全」ではなく「安価な繰り返し」です。 その前提で使う限りは強力です。
まとめ
| 状況 | やること |
|---|---|
| テストが無い | 審判を作る作業を最初のスプリントにする |
| 現行実装がある | 新旧の出力 diff（7〜10シナリオから） |
| 制度が正解を決める | ルール文書 → テストケース生成。有識者レビューは文書へ |
| 新規UI | Mockを受け入れ基準として明文化 |
| 定量化できない | ルーブリック採点＋人による抜き取り検証 |
| 全部に共通 | 壊して落ちることを確認する |
審判が揃ったら、次はそれをAIが安定して参照できる状態にする作業です。「AIに読ませるドキュメント体系」に続きます。
よくある質問
Q. 既存コードにテストを後付けするのと、差分テストを作るのはどう違いますか？ A. 目的が違います。テストの後付けは資産としての品質保証を狙いますが、差分テストは「新旧が同じ挙動か」だけを判定します。後者のほうが圧倒的に速く作れて、リファクタや刷新の局面では十分に機能します。両方やる必要はなく、まず差分テストで着手障壁を下げるのが実務的です。
Q. 代表シナリオはどう選べばよいですか？ A. 利用頻度の高い操作から選びます。加えて、失敗したときの実害が大きい処理（金額計算、権限判定、外部連携）を必ず含めてください。網羅性は最初から狙わず、後からAIに追加設計させるほうが早いです。
Q. AIが作ったテストは信頼できますか？ A. そのままでは信頼できません。だから「壊して落ちるか」の検証をします。意図的にバグを入れたコードを流し、落ちなければテストが甘いということなので、その場で強化させてください。
Q. LLM as a judge の判定はぶれませんか？ A. ぶれます。だからルーブリックで観点と基準を固定し、重要な判定は複数回・複数の観点で走らせます。それでも人による抜き取り検証は必要です。judgeは人間のレビュー量を減らす装置であって、置き換えるものではありません。
Q. 審判づくりにどれくらい時間をかけるべきですか？ A. パイロット1機能ぶんで数日、という規模感です。ここをケチると、以降の全生成物が判定不能になるため、投資として最も効率が良い箇所です。
関連サービス
最終確認日: 2026-07-26