AI エージェントがコードを書く時代が本格化しています。しかし、エージェントにプロンプトを投げるだけでは、プロダクション品質のソフトウェアは生まれません。エージェントが安定して成果を出し続けるためには、制約・ツール・ドキュメント・フィードバックループからなる「環境」の設計が不可欠です。
この環境設計を体系化した概念が Harness Engineering です。
Harness Engineering とは
Harness Engineering は、AI コーディングエージェントが信頼性の高い仕事をするための 制約・ツール・ドキュメント・フィードバックループ を体系的に整備するエンジニアリング規律です。
この用語を広めたのは HashiCorp 創業者の Mitchell Hashimoto です。彼は AI 導入の 6 段階を提唱し、その第 5 段階を「Engineer the Harness」と名付けました。
エージェントがミスをするたびに、そのミスが二度と起きないよう仕組みを整えること。それが Harness Engineering だ。
“It is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.”
— Mitchell Hashimoto
その後、OpenAI が 2026 年 2 月に公開した記事で、Codex エージェントを使って 100 万行のコードを手書きゼロで 構築した事例が紹介され、Harness Engineering は業界全体の注目を集めました。Martin Fowler は Birgitta Böckeler の分析記事を「AI 支援開発の重要な部分を捉えた貴重なフレーミング」として紹介しています。
Prompt → Context → Harness：3 層の関係
Harness Engineering を理解するには、関連する概念との位置関係を整理すると分かりやすくなります。
| レイヤー | 焦点 | 問い |
|---|---|---|
| Prompt Engineering | LLM への指示テキストの最適化 | 「何を伝えるか？」 |
| Context Engineering | LLM が受け取るすべてのトークン（ツール、RAG、スキーマ、メモリ） | 「何を見せるか？」 |
| Harness Engineering | システム全体の制約・フィードバック・改善サイクル | 「何を防ぎ、何を測り、何を制御するか？」 |
Prompt Engineering と Context Engineering が「1 回の推論の質」を高めるのに対し、Harness Engineering は システム全体の継続的な品質 を担保します。
OpenAI の実験：100 万行を手書きゼロで
OpenAI の Ryan Lopopolo は、Harness Engineering の記事で、5 ヶ月間の実験について詳細に報告しています。
数字で見る成果
- コード量：約 100 万行（アプリケーションロジック、インフラ、ツール、ドキュメント）
- 手書きコード：0 行
- チーム規模：当初 3 名 → 7 名に拡大
- スループット：エンジニア 1 人あたり平均 3.5 PR/日
- PR 総数：約 1,500 件（5 ヶ月間）
- 開発速度：手書きの場合の推定 1/10 の期間
哲学：Humans steer. Agents execute.
OpenAI チームが掲げた哲学は明確です。人間が舵を取り、エージェントが実行する。エンジニアの仕事は、コードを書くことから「環境・意図・フィードバックループを設計すること」へと変わりました。
初期の進捗が遅かったのは、Codex の能力不足ではなく 環境の仕様不足 が原因でした。エージェントにはツール・抽象化・内部構造が足りなかったのです。何かが失敗したとき、答えは「もっと頑張れ」ではなく「何の能力が欠けていて、どうすればエージェントにとって読み取れ、実行可能にできるか？」でした。
Harness の 4 つの柱
OpenAI・Mitchell Hashimoto・Birgitta Böckeler の知見を総合すると、Harness は以下の 4 つの柱で構成されます。
1. アーキテクチャ制約（Architecture as Guardrails）
エージェントは自由度が高すぎると迷走します。逆説的ですが、制約が厳しいほどエージェントの信頼性は上がります。
OpenAI は厳格なレイヤードアーキテクチャを採用しました。
Types → Config → Repo → Service → Runtime → UI
各ビジネスドメインはこの固定レイヤー順にのみ依存でき、横断的関心事（認証・テレメトリ・フィーチャーフラグ）は単一の Providers インタフェースを経由します。これらの制約は カスタム linter と構造テスト で機械的に強制されます。
通常、数百人のエンジニアがいる組織でしか導入しないようなアーキテクチャだ。コーディングエージェントを使う場合、これは初期の前提条件になる。制約こそが、劣化やアーキテクチャのドリフトなしにスピードを出すための鍵だ。
“This is the kind of architecture you usually postpone until you have hundreds of engineers. With coding agents, it’s an early prerequisite: the constraints are what allows speed without decay or architectural drift.”
— Ryan Lopopolo, OpenAI
2. リポジトリ知識の体系化（Documentation as System of Record）
OpenAI チームが学んだ最も重要な教訓の一つは、「AGENTS.md は百科事典ではなく目次として扱え」 ということです。
巨大な AGENTS.md ファイルに全情報を詰め込むアプローチは、予想通り失敗しました。
- コンテキストは希少資源：巨大な指示ファイルはタスクやコードを圧迫し、エージェントが重要な制約を見落とす
- すべてが「重要」なら何も重要でない：エージェントがローカルなパターンマッチに頼るようになる
- モノリシックなドキュメントは陳腐化する：何が最新か判別できなくなり、メンテナンスされなくなる
代わりに、AGENTS.md は約 100 行の「地図」として、構造化された docs/ ディレクトリへのポインタを提供する設計にしました。
| ファイル / ディレクトリ | 役割 |
|---|---|
AGENTS.md | 目次（約 100 行）。各ドキュメントへのポインタ |
ARCHITECTURE.md | ドメインとパッケージレイヤリングのトップレベルマップ |
docs/design-docs/ | 設計ドキュメント・コアビリーフ |
docs/exec-plans/active/ | 進行中の実行計画 |
docs/exec-plans/completed/ | 完了した実行計画 |
docs/product-specs/ | プロダクト仕様 |
docs/references/ | LLM 向けリファレンス資料 |
設計ドキュメント、実行計画、技術的負債のトラッカーがすべてバージョン管理され、エージェントが外部コンテキストなしで自律的に動けるようになっています。
Mitchell Hashimoto も同様のアプローチを推奨しています。エージェントがミスをするたびに AGENTS.md を更新し、暗黙のプロンプティング改善を蓄積していく。ドキュメントは静的な成果物ではなく、生きたフィードバックループ になります。
3. Observability とフィードバックループ（Application Legibility）
エージェントがコードを「見る」だけでなく、アプリケーションの「動作」を理解できるようにすることが重要です。
OpenAI は以下を実現しました。
- Chrome DevTools Protocol をエージェントランタイムに接続し、DOM スナップショット・スクリーンショット・ナビゲーションでバグの再現と修正検証を可能にした
- ローカル Observability スタック（Victoria Logs / Victoria Metrics / Victoria Traces）を各 git worktree に用意し、LogQL や PromQL でログとメトリクスをクエリ可能にした
- アプリを git worktree 単位でブート可能 にし、Codex が変更ごとに 1 インスタンスを起動・検証できるようにした
これにより、「サービス起動が 800ms 以内であることを確認」「このユーザージャーニーのスパンが 2 秒を超えないこと」といったプロンプトが実行可能になりました。単一の Codex ランが 6 時間以上（人間が寝ている間に）タスクを処理し続けることも珍しくないそうです。
4. エントロピー管理とガベージコレクション
エージェントの完全自律はエントロピーを生みます。Codex はリポジトリに既存のパターンを、たとえそれが最適でないものであっても複製します。時間とともに、これがドリフトにつながります。
OpenAI チームは当初、毎週金曜日の 20% を「AI slop」の掃除に充てていましたが、スケールしませんでした。
代わりに、golden principles をリポジトリに直接エンコードし、定期的なクリーンアッププロセスを構築しました。
- バックグラウンドの Codex タスクが逸脱をスキャンし、品質グレードを更新し、リファクタリング PR を自動で開く
- ほとんどの PR は 1 分以内にレビューされ、自動マージされる
- 技術的負債は高金利ローンのようなもので、小さな増分で日々返済するほうが、何日も放置するより遥かに効率的
Mitchell Hashimoto の 6 段階フレームワーク
Mitchell Hashimoto の AI 導入 6 段階は、個人の実践者にとって実用的なロードマップです。
| 段階 | アクション | 説明 |
|---|---|---|
| 1 | チャットボットを捨てる | 単純なチャット UI から、ファイル読み書き・プログラム実行・HTTP リクエストができるエージェントへ移行 |
| 2 | 自分の作業を再現する | タスクを手動で行った後、エージェントで再現。得意分野と限界を把握する |
| 3 | 終業時エージェント | 1 日の最後の 30 分にエージェントを起動し、リサーチや探索的作業を委任 |
| 4 | 確実なタスクを委任する | 高確度のタスクをエージェントに任せ、自分はディープワークに集中。通知はオフに |
| 5 | Harness を構築する | ミスが起きるたびに、二度と起きない仕組みを整える（AGENTS.md・スクリプト・検証システム） |
| 6 | 常にエージェントを動かす | バックグラウンドで継続的にエージェントを稼働。1 日の 10-20% から開始 |
ポイントは、段階 5 の Harness Engineering が 複利的に効く ことです。1 つの改善が、将来のすべてのエージェント実行に適用されます。
実践のための具体的なステップ
Harness Engineering を自分のプロジェクトに導入するために、まず何から始めるべきでしょうか。
今日からできること
- AGENTS.md（または CLAUDE.md）を作成する：プロジェクトの規約・禁止事項・テスト方法を記述する。エージェントがミスをしたら即座に追記する
- pre-commit hook を見直す：linter・formatter・型チェックが CI だけでなくローカルでも走るようにする。エージェントにとってこれは即座のフィードバックになる
- テストカバレッジを意識する：エージェントが「正しく動いた」と判断するための基盤になる。テストがなければエージェントは検証できない
中期的な投資
- アーキテクチャ制約を機械的に強制する：依存関係の方向、ファイルサイズ制限、命名規約をカスタム linter やスクリプトで検証する
- ドキュメントを構造化する：巨大な 1 ファイルではなく、目的別に分割し相互参照できる構造にする
- エージェントにアプリの動作を可視化する：テスト結果だけでなく、ログやメトリクスにアクセスできるようにする
チームでの導入
- エージェントのミスを「インシデント」として扱う：ミスが起きたらポストモーテムを行い、Harness を改善する
- 定期的なガベージコレクション：エージェント生成コードの品質チェックを定期的に実施し、パターンの逸脱を検出する
コードレビューの再定義：仕様駆動の品質保証へ
Harness Engineering がエージェントの「実行環境」を整備する規律だとすれば、その影響が最も顕著に表れるのが コードレビュー のプロセスです。Aviator CEO の Ankit Jain は How to Kill the Code Review で、AI エージェント時代のレビューの変容について鋭い問題提起をしています。
従来のコードレビューはボトルネックになる
AI エージェントの高い生産性は、レビュープロセスに深刻なボトルネックを生みます。高度な AI 採用チームでは PR マージ数が 98% 増加する一方、PR 確認時間が 91% 増加する という報告があります。エージェントがコードを量産する時代に、人間がすべての diff を行単位で読むモデルは持続しません。
この問題は OpenAI の Harness Engineering 実践でも表面化していました。1,500 件の PR を 5 ヶ月で処理し、「ほとんどの PR は 1 分以内にレビューされ、自動マージされる」というプロセスは、従来のコードレビューとは根本的に異なるものです。
「コードは正しいか？」から「仕様は正しいか？」へ
Ankit Jain が投げかける問いは本質的です。AI がコードを生成し、AI がレビューするなら、人間がレビュー UI で diff を眺める意味は何か？
答えは、人間の関心を 上流 にシフトすることです。
| 従来のレビュー | AI エージェント時代のレビュー |
|---|---|
| コードの行を読んで正しさを確認 | 仕様・制約が正しく定義されているか確認 |
| 実装の詳細に注目 | 意図と受け入れ基準に注目 |
| レビュー後にマージ | 決定論的検証を通過したら自動マージ |
| 人間がゲートキーパー | 仕組みがゲートキーパー、人間はアーキテクト |
これは Harness Engineering の「Humans steer. Agents execute.」という哲学と完全に一致します。仕様が真実の源泉になり、コードは仕様の成果物 となるのです。
多層防御：レビューを仕組みに置き換える
Ankit Jain は、人間のコードレビューに代わる 5 層の検証モデル を提案しています。これは Harness Engineering の 4 つの柱と補完関係にあります。
- 複数案の比較：複数のエージェントに異なるアプローチで実装させ、最も検証を通過した案を選択する。単一の解法に賭けるのではなく、競争させる
- 決定論的ガードレール：テスト、型チェック、契約検証など、意見を含まないファクトベースの検証。Harness Engineering のアーキテクチャ制約やカスタム linter がここに該当する
- 人間による受け入れ基準の定義：行動駆動開発（BDD）フレームワークを活用し、仕様から検証基準を事前に定義する。検証基準は実装後に発明するものではない
- 権限システムの構造化：エージェントのアクセス範囲を最小化し、特定パターン（セキュリティ関連、データベースマイグレーション等）では人間レビューを自動トリガーする
- 敵対的検証：実装エージェントとレビューエージェントの責任を分離し、相互監視体制を構築する
これらの層が正しく機能していれば、人間がコードの行を読む必要性は大幅に減ります。人間の仕事は「コードを読むこと」ではなく、この多層防御そのものを設計・改善すること ——つまり Harness Engineering——になるのです。
Ship Fast, Observe, Roll Back
従来の「レビューしてからマージ」モデルに代わり、「高速にリリースし、すべてを観測し、問題があれば即座にロールバック」 する運用モデルへの移行も提案されています。
これは OpenAI が Codex で実践した Observability スタック（Victoria Logs / Metrics / Traces）や、エントロピー管理のためのバックグラウンドスキャンと自動リファクタリング PR と同じ思想です。品質の担保ポイントが「マージ前のゲート」から「継続的な観測とフィードバック」へ移行しているのです。
Harness Engineering の先にあるもの
OpenAI は記事の結論で、まだ学んでいる途中だと率直に述べています。
ソフトウェアを作るには依然として規律が必要だ。ただし、その規律はコードよりもスキャフォールディングに現れるようになった。コードベースの一貫性を保つツール・抽象化・フィードバックループが、ますます重要になっている。
“Building software still demands discipline, but the discipline shows up more in the scaffolding rather than the code. The tooling, abstractions, and feedback loops that keep the codebase coherent are increasingly important.”
— Ryan Lopopolo, OpenAI
エンジニアの価値は「コードを書く速度」から「エージェントが正しく動く環境を設計する能力」へと移行しつつあります。コードレビューの変容が示すように、人間の介入ポイントは実装の詳細から上流の仕様・制約・検証設計へと移動しています。この変化は、単なるツールの進化ではなく、ソフトウェアエンジニアリングという職業そのものの再定義 です。
Harness Engineering は、その再定義の中核にある概念です。
以上、AI エージェント時代の新しいエンジニアリング規律 Harness Engineering を整理した、現場からお送りしました。