AI駆動開発 2026年10月24日

「プロンプトを書いて祈る」をやめる日――Googleのハーネスエンジニアが語るAI駆動開発の本質

「プロンプトを書いて祈る」という状態の正体

Googleのライアン・ロポポロ氏は、2025年5月以降、コードエディタを一度も開いていない。

これは比喩ではない。個々のコード行を書かず、レビューもしない。自然言語を使って作業を進め、プルリクエストやドキュメント、スプレッドシートといった最終的な成果物が組織の基準を満たしているかどうかを判断する。Google Cloudに移籍してからも、その姿勢を変えていないという。

この人物が「エージェントハーネス」という用語を生み出した張本人だ。Googleが2026年9月25日に公開した解説動画「The Agent Factory」のなかで、ロポポロ氏はこう言い切っている。

「ハーネスエンジニアリングを怠ると、私が『プロンプトを書いて祈る』と呼ぶ状態に陥る」

この一言が、記事全体のコアだ。「プロンプトを書いて祈る」——聞けば笑えるが、実態は笑えない。多くの開発チームがCursorやClaude Codeを導入し、良さそうなプロンプトを試行錯誤している。うまくいったら「勝った」、うまくいかなければ「書き直す」。このループを個人が抜け出せても、チーム全体に適用できる改善策にはならない。ロポポロ氏が問題にしているのは、まさにその再現性のなさだ。

エージェントハーネスとは何か、3分で整理する

定義はシンプルだ。AIエージェント = LLM（大規模言語モデル）+ エージェントハーネス。ハーネスとは、モデル本体を除いた「周囲にあるすべて」を指す。

具体例で理解するのが早い。「空はなぜ青いのか」という質問にはLLM単体でも答えられる。だが「今日はレインコートを着るべきか」には、リアルタイムの気象データがなければ答えられない。ハーネスは質問の意図を読み取り、気象APIに問い合わせ、結果をコンテキストとしてプロンプトに組み込んでモデルに渡す。根拠のある回答を生成させる仕組みが、ハーネスの役割だ。

Google Antigravityを例にとると、「Gemini 3.8 Flash」がLLMで、「Google Antigravity」がハーネスにあたる。モデルが何かではなく、モデルを取り巻く環境が何かを問う発想の転換が、ここにある。

Googleのビリー・ジェイコブソン氏（シニアデベロッパーアドボケイト）は、ハーネスを設計するうえでの判断軸を3つに整理している。

ループ：エージェントに何回反復させ、どの条件で終了させるか
ツール：どのツールを使わせ、いつ、どのように呼び出させるか
メモリ：会話や作業のメモリがどれだけ重要で、いつ取り出したり圧縮したりするか

この3軸は、プロンプトの中身より先に設計すべき問いだ。実演では3種類のハーネスが紹介された。反復不要なタスク向けの「線形エージェントハーネス」、バグ修正などで検証済みの解決策に至るまで繰り返す「クローズドループ型ハーネス」（最大5回の反復制限あり）、そしてGoogleのAgent Development Kitをベースにした「安全対策付きハーネス」だ。最後のものは、ファイルの再帰的削除やデータベースの削除、許可されていないgit pushをフック段階でブロックする仕組みを備えている。

シフトレフトという考え方が示すもの

ロポポロ氏が強調するのは「シフトレフト」という概念だ。

介入を開発ライフサイクルのより早い段階、より低コストで対応を自動化できる段階に移していく。具体的には、プロンプトの調整 → リポジトリのドキュメント → リンター → テスト → さらに上流の評価、という順序で「基準を環境そのものに組み込む」。

「次のターンでモデルが正しく推測することを期待するのではなく、基準を環境に埋め込む」——この発想が面白い。リンターやテスト、「AGENTS.md」ファイルが、何を「良し」とするかを示す永続的な記憶になり、それを強制する役割も担う。エージェントが軌道を外れそうになったとき、手取り足取り指示しなくても済む環境を先に作る、という考え方だ。

ハーネスに先行投資しておけば、エンジニアは長いプロンプトを書かずに済む。リポジトリに構造化されたドキュメントや明確なインタフェース、見つけやすいツールがそろっていれば、モデルはハーネスを使って関連するコンテキストを自ら取得し、大規模なコードベースでも人の監督なしに複雑なタスクを実行できる——ロポポロ氏はそう述べている。

ここからは見方だが――この話が示す開発現場の地殻変動

「プロンプトエンジニアリング」「コンテキストエンジニアリング」「ハーネスエンジニアリング」という流れは、AI活用の成熟段階として読める。

プロンプトエンジニアリングは「何を書くか」の最適化、コンテキストエンジニアリングは「何を渡すか」の設計、ハーネスエンジニアリングは「モデルが動く環境そのものを整備する」だ。前の2つは優れた個人が存在する場所でしか機能しない。ハーネスエンジニアリングは、仕組みとして機能するから複利で効く。

興味深いのは、ロポポロ氏が「独自のハーネスを過度に作り込むと、フロンティアモデルが進化したときに技術的負債になり得る」と指摘している点だ。これは逆説的だが、まったく正しい。カスタムハーネスをゴリゴリ作ると、特定のモデルの癖に合わせた固定的な設計になる。半年後に新しいモデルが出たとき、そのハーネスごと捨てることになる。

ロポポロ氏が勧めるのは、標準的なハーネスが既に備えるプリミティブ（ファイルの読み込み、grepによる検索、コマンドの実行）を活用しながら、ツールとコンテキストの品質向上に集中することだ。「新しいモデルを自由に採用でき、陳腐化しない部分に投資の効果を積み上げ続けられる」という表現がクリアで、判断軸として使いやすい。

もうひとつ、スミタ・コラン氏（シニアデベロッパーリレーションズエンジニア）の発言も拾っておきたい。「コーディングエージェントに必ずしも重い推論モデルは必要なく、高い性能はモデル・ハーネス・ナレッジという3つのレイヤーのバランスから生まれる」という整理は、「とにかく高性能なモデルに切り替えれば解決する」という反射的な発想への牽制になっている。Google Skillsという、Google Cloudをはじめとする100以上の分野別パッケージを収録したエージェントスキルのリポジトリを「ナレッジレイヤー」として提示しているのは、特定のハーネスに依存せずに「正確なコンテキストを注入する」ための設計だ。

RPGのキャラクターに能力値を足すように、チームの各専門家の知識を環境に組み込めば、エージェントは依頼に応じて必要なスキルを選べるようになる——というロポポロ氏の比喩は、わかりやすいだけでなく、実装イメージを持ちやすい表現だった。

実務的な示唆と今後の論点

この記事を読んで、自分のチームに引きつけて考えるべき問いがいくつか浮かぶ。

「ツールを入れた」で止まっていないか

CursorやClaude Codeを導入し、生産性が上がった実感はある。だが、それは「個人レベルの改善」で止まっていないか。エージェントが失敗したとき、プロンプトを調整して再試行するだけなら、それはチームに適用できる改善策ではない。ハーネスエンジニアリングが問うているのは、「再現可能な仕組みとして整備されているか」という点だ。

暗黙知の明文化が強制される

AGENTS.mdにルールを書き、リポジトリにドキュメントを整備し、リンターにコーディング規約を落とし込む——これは、エージェントのためにやることだが、副産物として「組織の暗黙知が明文化される」という効果を持つ。ドキュメント文化のない組織には重い要件だが、逆に言えば、ハーネスエンジニアリングへの取り組みが組織の知識資産化を強制的に促すことになる。

半年前に失敗したタスクを再評価する視点

ロポポロ氏はこう述べている。「AIモデルの能力を過去の経験で決めつけず、できることを継続的に見直すべきだ。半年前に失敗した作業も、現在のモデルならこなせる可能性がある」——これは地味だが重要な指摘だ。「うちではエージェントにこのタスクは任せられない」という判断を、1年前の経験に基づいて維持しているチームは多い。モデルは半年で別物になる。評価も更新し続けなければ、機会損失だけが積み上がっていく。

今後の論点として気になるのは、「エージェントの作業範囲をどう絞るか」という問題だ。ロポポロ氏はまず範囲を絞り、人が確認しやすい変更範囲の小さいプルリクエストを作らせ、それを繰り返して「長期間安定して進められる」と分かれば、コードベース全体のプログラミング言語移行のような大きな仕事まで任せられるようになる、という段階論を示している。この「どこまで任せるか」の判断軸を、チームとして持てているかどうかが、次に差がつくポイントになる気がしている。