Harness エンジニアリング十二条：Google 主席エンジニアの一年間の実践を、そのまま使えるプロセスとテンプレートに凝縮
- Ryan Lopopolo 氏は現在 Google Cloud の主席エンジニアで、以前は OpenAI に在籍していました。彼はこの一年の仕事を十二条にまとめ、公開リポジトリにしました。自分のエージェントに参考資料としてそのまま読み込ませることができます。十二条の実証の多くは OpenAI 時代の経験に基づいています。
- 核となる操作は直感に反します。選んだモデルとコーディングエージェントは変更不可のブラックボックスとして固定し、一切パラメータを調整せず、周囲の「コンテキスト」と「ツール」の2つだけを変えます。
- 十二条は三層に分かれます。上位3条は境界を定め（ワーカー固定、社内プロセスデータの投入、実測結果での評価）、中位6条はテコ（仕事を一人のエージェントに委ねる、コンテキストのジャストインタイム・ルーティング、能力を使いこなす、リポジトリに教えさせる、権限を明確化する、実環境で証明する）、下位3条は複利をもたらします（フィードバックのインフラ化、長期的な一貫性の維持、確定済みタスクの常駐ループ化）。
- この手法を支える実証：ある社内プロダクトが5ヶ月で空のリポジトリから約100万行のコードに成長し、約1500件のマージ済みPRはすべて Codex が作成。人間は1行も書いていません。
- そのまま持ち帰れるもの：6ステップの改善プロセス、3つの穴埋めテンプレート、「何を主張するならどこで証拠を取るか」がわかる11行の対照表、「どのような場合に比較実験が無効になるか」の9項目チェックリストです。
十二条と、誤訳されがちな言葉
まず言葉を正しましょう。ここでの harness は馬具という意味です。鞍、手綱、蹄鉄、引き具などの一式で、リポジトリの冒頭には馬の絵文字が付いています。「束縛」と読まれがちですが、方向性はまったく逆です。
馬はすでに十分に走れます。不足しているのは鞍、手綱、そして走路であり、それによって馬力が実際に地面に伝わり、目指す方向へ進めます。harness エンジニアリングとは、まさにこの一式を整えることです。
これを書いたのは Ryan Lopopolo 氏です。彼は現在 Google Cloud の主席エンジニアで、agentic GCP を担当しています。それ以前は OpenAI に在籍し、シアトルオフィスと企業向け OpenAI Frontier の構築に参加。仕事内容はまさに、エージェントへのコンテキスト、ツール、権限、評価、可観測性、オーケストレーション、フィードバックループの提供でした。十二条の実証の多くはこの経験に由来します。さらに以前は Snowflake でデータマーケットプレイスのテックリード、Brex では40人チームを率いて350人のエンジニア組織を支え、Stripe ではインフラと決済のテックリードとして会社が600人から6000人に成長する過程を経験しました。余暇には Rust で Ruby の実装「Artichoke」を開発しています。
彼はこの十二条を公開した際、これはこの一年の仕事を表すものであり、実践であり、技術でもあると述べています。
彼は自身の実践を十二条にまとめ、証拠、事例、実行可能なプロセスとともに公開リポジトリに入れました。リポジトリの自作コンテンツは CC BY 4.0 でライセンスされています。使い方は2通りです。人間が直接読むか、改善したいシステムと一緒にコーディングエージェントへ渡し、エージェントに内部の分岐インデックスを参照させて、参照すべき条項を自分で調べさせるかです。
読む価値がある理由：十二条のそれぞれに検証可能な実証が付いています。ある社内プロダクトは5ヶ月で空のリポジトリから約100万行、約1500件のマージ済みPRに成長し、コードはすべて Codex が作成、人間は1行も書いていません。また、60時間・3億超トークンを使った大規模リファクタリングは、初期プロンプトと2回の追加質問だけでした。lint（コーディング規約違反を自動検出するツール）を有効にしたところ、約600件の違反が同じPR内で修正され、テストも追加されました。
以下が十二条の全体像です。三層に分けたのは、その関係を理解しやすくするためです。一番上が境界を定め、真ん中の6つが実際のテコ、そして一番下の3つが、この仕組みが時間とともに価値を積み上げられるかを左右します。では、一つずつ見ていきましょう。
第一条：働く「人」を固定する
1回の評価・デプロイサイクルにおいて、モデル、コーディングエージェントのランタイム、ネイティブツールインターフェースの3つを固定します。この3つのうちどれか1つでも変わったら、たとえ世代が1つ進んだだけでも、環境全体を再検証する必要があります。
ブラックボックスを固定する利点は、失敗の原因を特定しやすくなることです。明らかに有能なエージェントがタスクを達成できない場合、その原因は通常5つの場所にあります。関連する組織コンテキストの欠如、実際に使える能力の欠如、有用なフィードバックループの欠如、権限の欠如、そして出口での証拠の欠如です。これら5つはすべてデプロイ環境の属性であり、調査可能で、変更可能です。ブラックボックスを固定しなければ、「モデルが悪いのか、それとも自分の設定が悪いのか」という堂々巡りから永遠に抜け出せません。
あなた自身が培った経験則も、再検証の対象です。旧モデルで学んだ習慣、つまりタスクの適切な分割サイズ、必要なオーケストレーション量、内部ループの待機時間、人間の監視が必要な箇所などを、そのまま新世代に持ち込むと、新モデルの追加能力が台無しになります。逆に、すべてのマイナーバージョンがあらゆる側面で向上していると仮定するのも、もう一つの誤りです。
彼自身が記録した観察結果：GPT-5.3 は GPT-5.2 よりも困難なタスクに取り組むのを嫌がりました。これは単独の使用観察であり、傾向を示すものではありません。
世代交代がどれほどの差をもたらすか、2つの数字があります。GPT-5.2 がリリースされたとき、彼は休暇中でした。戻ってみると、チームは追加の環境投資なしで、エンジニア1人あたり毎日1〜2件多くのPRを生み出していました。その後、別の Symphony 環境改修では、エンジニア1人あたりの週間PR数が10倍になったと報告されています。前者はモデル世代交代によるもの、後者は環境改修によるものです。この2つは分けて考える必要があり、それこそがブラックボックスを固定する意味です。
GPT-5.2 リリース中、環境は1行も変更されていません。
1人あたり毎日1〜2件のPR増加。
Symphony での介入時、ワーカーは変更なし。
報告では1人あたり週間PR数が10倍に。
内部ループのレイテンシも検証範囲です。エージェントがどこまで推論できるかは、1回の実行（トラジェクトリ：エージェントがタスクを開始から完了まで処理する全過程）が脱線するまでに得られるフィードバックの量に依存します。GPT-5.2 時代の Codex 環境にはバックグラウンドシェルがなく、エージェントはブロックするビルドスクリプトが完了するまで素直に待っていました。GPT-5.3 でバックグラウンドシェルが追加されると、エージェントは待たなくなりました。チームは1週間かけて、リポジトリのビルドを独自スクリプトから専門のビルドツール（Bazel、Turbo、Nx を順に試行）へと置き換え、全量ビルドが1分以内になる地点で停止しました。この1分がハードリミットと定められ、超えそうになると、手元の作業を止めてビルドグラフの分割に取り掛かります。
検証には引き算も含まれます。エージェントにUIを見せるため、チームはかつて仮想ディスプレイと画面録画の仕組みを自作していました。モデルが自ら画面を見てクリックできる機能（computer use）が登場すると、この仕組みはすべて削除されましたが、エンドツーエンドの検証は失われませんでした。
第二条：社内プロセスデータの水面下を実装する
汎用モデルの重みに含まれているのは、組織ナレッジのほんの一角にすぎません。水面下こそが、実際の作業に必要なものであり、それらは社内固有で、変化し続けています。
この条項は、2つのものを明確にすることを求めます。1つは「データ本体」です。どのようなエンティティ、指標、識別子があり、それらの関係はどうなっているのか。もう1つは「作業本体」です。どのような成果物、ワークフロー、役割、ツール、例外、証拠、承認関係があるのか。
良い例があります。社内データエージェントにデータウェアハウスへの権限を与えるだけでは不十分で、「売上」と「アクティブユーザー」という言葉が社内で衝突する定義を解決できません。エージェントは、会社にどのような製品ラインがあるか、顧客がどのようにセグメント化されているか、どのようなチームがあるか、どの顧客がパイロット中か、現在の計画は何か、共有の指標定義がどのように書かれているかを知る必要があります。これらの関係があって初めて、その会社に固有の答えを出せるのです。
現在の記録は、データウェアハウス、チケットシステム、ドキュメントシステム、ログ、コードベース、顧客システムに残し、検索とコネクタで承認済みのスライスを取得します。期限切れになる可能性のあるコピーを別途作成しないでください。
組織形態として、そのまま真似できる方法があります。Basis 社には2つのリポジトリがあります。Arnold は本番用のモノレポ、Atlas は2つ目のリポジトリで、会社のコンテキスト専用であり、本番コードツリーの外にあります。Codex は個人メモ、会社の運営ナレッジ、本番コードを組み合わせて使用できますが、これら2つの情報はそれぞれ独立した更新パスを保持します。実装形態は非常に簡素で、彼の言葉を借りれば「Codex と Markdown で満たされた Git リポジトリ」です。
この層にはもう1つ重要なことがあります。安定した決定は、それを管轄できる層に引き上げるべきです。あるチームがセキュリティ部門と共に、承認済みの暗号化実装を選択しましたが、この決定は Slack に残ったままでした。その後、新しいエンジニアが Codex を使って作業したところ、Codex は別の npm 暗号化パッケージをインストールしました。チームはこの決定を回収し、リポジトリにガードルールとして書き加え、その変更を再実行しました。
第三条：仕事は1つのエージェントに丸ごと任せる
委任するのは結果です。1つのメイントラジェクトリに、分解、実行、統合、証拠提示、安全な完了までを一任し、手順はエージェント自身に決めさせます。人間が介入するのは、方向性、判断、そして結果を伴う承認の3箇所だけです。
彼はしばしば、ほぼ制約のないプロンプトを与えます。このようなプロンプトを彼は「怠惰なプロンプト」と呼びます。方法を空欄にし、どう進めるかをエージェント自身に決めさせるからです。この疎な委任は、同時にテスト手段でもあります。環境が、本当の要求をエージェント自身が見つけ出せるようにできているかを試すのです。エージェントが誤解した場合、露呈するのは環境のどの部分が未整備かということです。これに付随するループは「提案、観察、改善、再実行」です。トラジェクトリを確認し、環境を改善し、今回の結果を破棄して、再実行します。