ハーネス・エンジニアリングとは

2026年2月、OpenAIのブログに「Harness engineering: leveraging Codex in an agent-first world」(https://openai.com/index/harness-engineering/)という記事が公開されました。3人のエンジニアがCodex（OpenAIのコーディングエージェント）を使い、5か月で約100万行のコードを出荷したという実験について紹介されています。興味深いのは、人間が手で書いたコードは一行もなかったという点です。

この記事で強調されているのは、AIの能力そのものではありません。AIに仕事を任せるために人間がどのような環境を整えたのか、という点です。

ここで使われているharness（ハーネス）は馬具を意味し、馬を制御して正しい方向に向かわせる仕組みのことです。AIに置き換えると、エージェントの行動を方向づける仕組みを設計することがハーネス・エンジニアリングだと言えます。

似た言葉を整理すると、プロンプトエンジニアリングは「個々のプロンプトをどう書くか」、コンテキストエンジニアリングは「エージェントに何を見せるか」に関するものです。ハーネス・エンジニアリングは、それらを含めてエージェントが動く環境全体を対象とする、より広い概念と言えそうです。

Humans steer. Agents execute. （人間が舵を取り、エージェントが実行する）

それでは具体的にどのような環境整備が行われたのか、記事の内容を踏まえて紹介します。

１.AGENTS.mdは100行以内に抑える

AIエージェントを導入すると、まず AGENTS.md（エージェントへの指示書）に必要な情報をすべて書き込みたくなります。元記事のチームも最初はそうしていましたが、このやり方はうまく機能しませんでした。指示書が膨らむほど、本当に必要なタスクに割けるリソースが減ってしまいます。

そこで AGENTS.md を約100行に抑え、百科事典ではなく目次として扱う方針に切り替えました。詳しい情報はリポジトリ内に構造化して配置しておきます。

AGENTS.md                        # エージェントへの指示書（目次）

ARCHITECTURE.md                  # アーキテクチャ全体図

docs/

├── design-docs/                 # 設計ドキュメント

│   ├── index.md

│   ├── core-beliefs.md

│   └── ...

├── exec-plans/                  # 実行計画

│   ├── active/

│   ├── completed/

│   └── tech-debt-tracker.md

├── generated/                   # 自動生成ドキュメント

│   └── db-schema.md

├── product-specs/               # プロダクト仕様

│   ├── index.md

│   ├── new-user-onboarding.md

│   └── ...

├── references/                  # 外部ライブラリ等の参照情報

│   ├── design-system-reference-llms.txt

│   ├── nixpacks-llms.txt

│   ├── uv-llms.txt

│   └── ...

├── DESIGN.md

├── FRONTEND.md

├── PLANS.md

├── PRODUCT_SENSE.md

├── QUALITY_SCORE.md

├── RELIABILITY.md

└── SECURITY.md

エージェントは目次から始めて、必要な時に必要な情報を段階的にたどっていきます。こうした手法は「段階的開示（progressive disclosure）」と呼ばれます。

ドキュメントの鮮度管理も仕組み化されています。古くなった記述を自動で検出し、修正する仕組みが動いているそうです。

２.コードの構造に制約を設ける

ドキュメントを整備しても、コードの構造に制約がなければエージェントは自由に書きすぎてしまい、コードベースはすぐに統一感を失います。

元記事のチームは、ビジネスドメインごとに固定のレイヤー構造を定義し、依存関係の方向を厳密に定めました。これらのルールは、自動チェックの仕組みで常に検証されます。

エージェントに書かせる場合、制約がなければコードベースがすぐに発散してしまいます。そのため、制約こそが開発速度の前提条件になるという考え方です。枠組みをしっかり整えれば、その中でエージェントに大きな裁量を委ねることができます。

３.コードベースを定期的にクリーニングする

エージェントはリポジトリ内の既存コードを学習します。その結果、良いパターンだけではなく、不適切なパターンも次第に増えていきます。当初は人手で整理していたそうですが、やはり長く続かなかったとのことです。

そこで、コーディング規約をリポジトリに定義し、違反箇所の検出と修正もエージェントに任せる仕組みを構築しました。「こうあるべき」という判断を一度ルールに落とし込めば、そのルールを全コードに対して継続的に適用できます。

４.情報をリポジトリに集約する

元記事に一貫しているのが「エージェント可読性（agent legibility)」という考え方です。Slackでの会話や個人の頭の中にある”暗黙知”は、リポジトリに書き込まない限り、エージェントからは見えません。「Slackで話したよね」は通じないのです。これは新しく入ったメンバーに対しても同じことが言えます。

エージェントがリポジトリだけを見てドメイン全体を把握できる状態を整えることが、ハーネス・エンジニアリングの土台になります。

まとめ

紹介した内容は、ドキュメントの構造化やアーキテクチャの明確化など、従来のソフトウェアエンジニアリングの定石に近いものばかりです。ただし、エージェントを相手にすると、整備されていない部分の影響が即座にコードベースへ波及します。そのため、個人の注意や努力に頼るのではなく、仕組みとして整備せざるを得ないというのが実態に近いのだと思います。

元記事は英語ですが読みやすい文章ですので、興味をお持ちの方はぜひご覧ください。

参考

「Harness engineering: leveraging Codex in an agent-first world | OpenAI」(https://openai.com/index/harness-engineering/)