AIが書いたコードをAIにテストさせる時代へ

AIを使って開発するとき、多くの人がまずやることは「もっといいプロンプトを書く」ことだ。しかし、Googleのエンジニアが公開した解説動画「The Agent Factory」が伝えるメッセージは、その優先順位を根本から問い直すものだった。

鍵になる概念が「ハーネス」だ。日本でいうところの「自動採点の仕組み」に近い。AIが出した結果が正解かどうかを、人間が毎回目で確認するのではなく、あらかじめ決めておいた基準で自動的に判定する構造のことを指す。

Googleのエンジニアは、このハーネスが整っていない状態でプロンプトを磨いても、生成結果が良くなったのか悪くなったのかを判断する基準がないため、実質的にただの「ガチャ回し」になると説明している。つまり、評価の仕組みが先、プロンプトの改良は後、というのがAIエージェント開発の基本順序だという主張だ。

先日のASADAHSIで触れたGoogleのエージェント専用インフラの話とも重なる動きで、Googleはエージェントの「出力を管理する層」に明確に力を入れ始めている。

バイブコーディングでLPやツールを作っている人には、特に刺さる話だと思う。

CursorやClaudeにコードを書かせてブラウザで動作確認、問題なさそうなら完成——このフローで作っている人は多い。しかし、これは「なんとなく動いた」を正解としている状態であり、生成されたコードが本当に意図通りかどうかを測る基準がない。

たとえばLPのCTAボタンが正しい位置にあるかどうかは目で確認できる。しかし、フォームのバリデーションが全パターンに対して機能しているか、外部APIとの連携が異常系でも正しく動くか、といったことは目視では拾いきれない。ハーネスの考え方は、こうした「見えないバグ」を自動で検出するための仕組みだ。

もう一段ブレイクダウンすると、「正解の定義を先に言語化する」という習慣そのものが価値を持つ。AIに「ボタンを左上に配置して」と指示するより、「ボタンはページ上部から20px以内に、かつ横幅の左30%に収まること」と定義できると、AIが出した結果の合否を機械的に判断できる。プロンプトの書き方より、判定基準の書き方を先に鍛える、という発想の転換だ。

実際の開発シーンでどういうことが起きるか、具体的に整理しておく。

まず、「プロンプトを変えたら改善した気がする」という感覚頼りの状態になりやすい。前の出力と今の出力を比較する基準がなければ、良くなったかどうかは印象でしかない。特にコードの品質やUIの正確さのように、主観が入り込みやすい領域では、この問題が顕著になる。

次に、AIが生成した複数の候補から「どれがベストか」を選ぶ判断も難しくなる。ハーネスがあれば、10個の候補を自動採点して上位だけ残す、という処理が自動化できる。なければ人間が10個を読み比べるしかない。これはスケールしない。

AIが本番DBを消した事例を扱った記事でも触れたとおり、AIの出力をそのまま信頼して本番に流す構造には根本的なリスクがある。承認フローを増やす前に、「何を検証すれば安全と言えるか」の定義を持つことが先決だ、というGoogleの主張とも一致する。

「ハーネス」と聞くとエンジニアリングの話に聞こえるが、コードを書かない人でも同じ発想を使える場面は多い。

たとえばAIに記事の要約を書かせるとき、「読んで問題なければOK」ではなく、「元記事の主張が3点含まれているか」「200字以内に収まっているか」「固有名詞の誤りがないか」という判定軸を先に決めておく。このリストがあれば、複数のAI生成案を並べて採点できる。

LP制作なら、「CTA文言にサービス名が含まれているか」「ファーストビューに価格が明示されているか」という項目を先に箇条書きにしておく。AIに何度か作らせて、このチェックリストに当てはめればいい。

どの仕事でも、「AIが出した結果の合否を判定するリストを先に書く」という習慣を取り入れるだけで、AI活用の精度は上がる。プロンプトを練り直すより先に、採点基準を書くことに時間を使う——これが今回のGoogleの解説が示す実用的な教訓だ。