人間がコードを1行も書かずに、AIエージェントだけでプロダクトを作る。少し前まで極端に聞こえたこの前提を、OpenAIは実際の開発事例として公開しました。同社は空のGitリポジトリから開発を始め、初期の構成、CI設定、AGENTS.md、アプリケーション実装までをエージェント主導で積み上げ、人間は主にプロンプト、環境設計、レビュー方針の設計に回ったと説明しています。※1

ただし、ここで重要なのは「人間がコードを書かなくなること」自体ではありません。問題は、コード生成の速度が上がるほど、人間のレビューとQAがボトルネックになりやすいことです。OpenAIは、コードスループットが上がるにつれて固定制約が human QA capacity に移ったと述べています。DORAも、AI導入の成否はツール単体ではなく、内部データ、ワークフロー、評価の仕組みといった組織能力に左右されると整理しています。※1※2 

その設計思想を捉える言葉として、2025年後半からAIエージェント文脈で「harness」という表現が増え、2026年2月にOpenAIが「Harness engineering」を冠した記事を公開しました。この記事では、「Harness engineering」の概念を整理し、何を整えればAI活用が加速し、どこを放置すると混乱が増えるのかを解説します。※1 ※3

＼ 図解でわかる ／

資料ダウンロード

ハーネスエンジニアリングの概念と実践を、図解付きでさらに詳しくまとめた資料を公開しています。

資料をダウンロードする

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

ハーネスエンジニアリングとは、AIエージェントが継続的に正しい仕事を進められるように、環境・文脈・評価・フィードバックループを人間が設計する手法です。OpenAIは、エージェント主導の開発では人間の主な仕事が「コードを書くこと」から「環境を設計し、意図を指定し、信頼できるフィードバックループを作ること」へ移ると説明しています。※1

ここでいう「ハーネス」は、モデル単体ではなく、入力、ツール呼び出し、状態管理、評価、記録を束ねてエージェントとして機能させる土台を指します。Anthropicはこれを「agent harness（or scaffold）」と説明しており、モデル単体ではなく、ハーネスとモデルを合わせて初めてエージェントとして評価すべきだと述べています。※4

なぜ今ハーネスエンジニアリングが必要なのか

AI導入が進み、個人の作業速度は上がっても、組織の制御系がそのままなら不安定性も増えることがわかってきたため、ハーネスエンジニアリングの必要性が増してきました。DORAは、AIの効果をツール単体の問題ではなく、内部データやドキュメントの品質、チームのワークフロー、評価の仕組みといった組織能力の問題として捉えています。「AIは増幅器である」とも言及し、整った組織では強みを伸ばし、弱い組織では弱点を速く拡大することを強調しています。※2 ※5

特に重要なのは、人間がレビューし続ける前提ではスケールしないという点です。OpenAIは、エージェント主導開発でコードスループットが上がるにつれて、ボトルネックが human QA capacity に移ったと述べています。Anthropicも、generator-evaluator ループはソフトウェア開発におけるコードレビューとQAに対応する構造だと説明しています。つまり、AIが生成を高速化しても、検証が人間に依存したままの目と時間に張り付いたままでは、全体最適になりません。※1 ※7

これは、単なる「レビューが大変」という話ではありません。AIが1日に生成する差分量が増えるほど、確認待ち、差し戻し、手戻り、仕様の見落としが累積しやすくなります。人間がすべてを最終判定する運用は、初期実験では回っても、運用規模が上がるほど詰まります。だから必要なのは、AIを止めることではなく、どこまでを機械的に落とし、どこだけを人間が見ればよいかを先に決めることです。ハーネスエンジニアリングは、そのための設計です。※1 ※4 ※7

また、社内の情報基盤が弱いままAIを入れても、生成量だけ増えてレビューと検証が詰まる可能性が高いという問題もあります。DORAは、内部データやドキュメントをAIが利用可能な状態にすることが、AI adoption の主要な推進要因だと明記しています。情報が弱ければ入力がぶれ、入力がぶれればレビュー負荷が増えます。レビューを減らしたいなら、まずレビュー前の段階でぶれない設計が必要です。※5

コンテキストエンジニアリングとの違い

混同しやすい概念として、コンテキストエンジニアリングがあります。Anthropicはこれを、LLMが推論するときに使う情報を適切に集め、絞り込み、維持するための設計だと説明しています。DORAも、最新のAPIドキュメント、社内ポリシー、準拠コードなどの関連情報を自動で集め、AIのワークフローに渡す仕組みとして説明しています。要するに、コンテキストエンジニアリングは「AIに何を見せるか」を設計する考え方です。※9 ※10

一方でハーネスエンジニアリングは、それより一段広い概念です。何を見せるかに加えて、どの順番で動かすか、途中結果をどう評価するか、失敗時にどうやり直すか、次のセッションへ何を引き継ぐかまで含めて設計します。つまり、コンテキストエンジニアリングが「入力情報の設計」なら、ハーネスエンジニアリングは「作業全体の運転設計」です。コンテキストはハーネスの重要部品ですが、ハーネスそのものではありません。※1 ※7 ※9 ※10

3つの概念はどういうレイヤー関係で捉えるべきか

ここは用語の違いとして横並びで比較するより、包摂関係のあるレイヤーとして捉えたほうが実務では分かりやすいです。この記事では、次のような整理を採用します。

• プロンプトエンジニアリング：1回の推論で、どう指示を書くか
• コンテキストエンジニアリング：その推論に、何の情報を入れるか
• ハーネスエンジニアリング：複数回の推論とツール利用を含む作業全体を、どう運転するか

この整理で見ると、プロンプトエンジニアリングはコンテキストエンジニアリングの一部であり、コンテキストエンジニアリングはハーネスエンジニアリングの重要な一部です。Anthropicは、コンテキストエンジニアリングを prompt engineering の natural progression と説明しています。OpenAIは、ハーネス設計の中核論点の1つとして context management を挙げています。※1 ※9

このレイヤーで見ると、議論の混線が減ります。たとえば「プロンプトを工夫しているのに成果が安定しない」という状況では、問題は書き方ではなく、渡している情報か、評価ループか、引き継ぎ設計かもしれません。逆に、ハーネス設計の話をしているのに、指示文の巧拙だけで解決しようとすると、打ち手が小さすぎます。自分たちが今、どのレイヤーについて議論を行う必要があるのかを考えてみるのも有効な手かもしれません。※1 ※5 ※9

プロンプトエンジニアリングとの違い

最も内側のレイヤーにあるのが、プロンプトエンジニアリングです。ハーネスエンジニアリングはその延長線上にはありますが、同じものではありません。プロンプトエンジニアリングは、一回の指示でより良い出力を引き出す設計です。一方でハーネスエンジニアリングは、どの情報を見せるか、どの順番で動かすか、途中成果をどう検証するか、失敗時にどう戻すかまで含めて設計します。対象が「1回の応答」ではなく「継続する作業系」だという違いがあります。※1 ※4

OpenAIの事例はこの違いを分かりやすく示しています。同社は、AGENTS.md を巨大な手引き書にするのではなく、短い目次として保ち、詳細な知識は docs/ ディレクトリ側を正本として扱う方法を紹介しています。Anthropicも、長時間タスクで性能を伸ばした要因として、タスク分解、構造化された引き継ぎアーティファクト、planner・generator・evaluator の役割分担を挙げています。ここでいう3エージェント構成は、planner が作業計画を分解し、generator が実際の変更や生成を行い、evaluator が要件・テスト・品質基準に照らしてチェックする役割分担です。人間で言えば「段取りする人」「手を動かす人」「検品する人」を分けるイメージです。良い指示文を書くことより、良い作業系を作ることのほうが効くということです。※1 ※6 ※7

ハーネスエンジニアリングを構成する4つの要素

この章では、構成要素をOpenAIの「Harness engineering: leveraging Codex in an agent-first world」から整理します。現場向けに言い換えると、OpenAIが実際に整備していたのは「正しい情報にたどり着けること」「アプリやコードの状態をエージェント自身が読めること」「生成後に自走で検証と修正を回せること」「崩れたコードベースを継続的に掃除できること」の4点です。※1 ※6

1. リポジトリ知識を正本にする

OpenAIが最初に強調しているのは、知識の置き方です。同社は巨大な AGENTS.md 1枚にすべてを書き込む方法は失敗すると述べ、短い AGENTS.md を目次として使い、構造化された docs/ ディレクトリを system of record として扱っています。重要なのは、AIに大量の規則を丸呑みさせることではなく、「何が正本で、どこを見に行けばよいか」を迷わせないことです。※1 ※6

長すぎる指示書はコンテキストを圧迫し、何が重要か分からなくなり、しかもすぐ陳腐化します。逆に、短い入口から深い文書群へ案内する構造にすれば、エージェントは必要な情報だけを段階的に参照できます。ハーネスの第一要素は、指示の量ではなく、知識の配置設計です。※1 ※6

2. アプリケーションとリポジトリをエージェントにとって読める状態にする

次の要素は legibility、つまり「エージェントが自分で読める状態」を増やすことです。OpenAIは、コードスループットが上がるにつれてボトルネックが human QA capacity に移ったため、UI、ログ、メトリクスをCodexが直接読めるようにしたと説明しています。Chrome DevTools Protocol を接続し、スクリーンショットやDOMスナップショットを扱えるようにし、さらにログ・メトリクス・トレースもローカルの観測基盤経由で参照可能にしました。※1

OpenAIの記事は、エージェントから見えていないものは存在しないのと同じであると述べられています。Google Docs、チャット、口頭で済まされる会話に閉じたままの情報は、エージェントにとって不可視です。そのため、設計判断やプロダクト知識、運用ルールを、リポジトリ内で発見可能かつ、バージョン管理された形に押し戻していく必要があります。ハーネスの第二要素は、AIに賢くなってもらうことではなく、必要情報を見える場所に移すことです。※1

3. フィードバックループを実装し、生成から修正までを自走させる

OpenAIの記事では、人間の役割は「コードを書くこと」から「環境を設計し、意図を指定し、信頼できるフィードバックループを作ること」へ移ると説明されています。実際の運用でも、エンジニアはタスクを渡して終わりではなく、Codexに自己レビュー、追加レビュー、フィードバック反映、再実行をループさせ、Pull Request を完成に近づけています。※1

記事後半では、ハーネスに開発ループを埋め込んだ結果として、1つのプロンプトから現状確認、不具合再現、失敗動画の記録、修正、修正後の再検証、PR作成、レビュー応答、ビルド失敗の修復、必要時のみ人間へのエスカレーション、マージまで進められるようになったと書かれています。つまり、ハーネスの第三要素は「出力をもらう仕組み」ではなく、「検証とやり直しまで含めて作業を閉じる仕組み」です。※1

4. アーキテクチャ原則を機械的に強制し、継続的に掃除する

最後の要素は、放置するとエージェント生成コードが崩れていく前提に立つことです。OpenAIは、完全自律に近づくほど、Codexは既存リポジトリ内の不均一なパターンや最適でない実装も増幅すると書いています。実際、当初は人間が毎週「AI slop（その場では動くが、徐々に荒れていくコードベース）」の掃除に時間を使っていたものの、それではスケールしなかったため、golden principles（機械的に判定できる明確なルール）をリポジトリに埋め込み、定期的なクリーンアップタスクを回す方式に切り替えています。※1

ここで重要なのは、原則を文章で掲げるだけではなく、機械的に守らせている点です。記事では、共有ユーティリティへの集約や、推測でデータ形状を扱わず境界で検証することなどを例に挙げ、バックグラウンドのCodexタスクが逸脱を検出して品質評価を更新し、リファクタ用のPRを自動で開くと述べています。ハーネスの第四要素は、生成時の制御だけではなく、生成後に蓄積するエントロピーを減らす運用まで含めて設計することです。※1

ハーネスエンジニアリングの進め方

次に、入口となる短いガイドを作ります。ここでのガイドは、AIにすべてを教える長文マニュアルではありません。何を見に行くべきか、どの順で確認すべきか、完了条件は何かを示す地図です。

（※OpenAIの事例を参考にした例）

# AGENTS.md

## このファイルの役割
このファイルは、詳細仕様をすべて書く場所ではなく、参照先と作業ルールを示す入口です。

## このリポジトリで最初に確認するもの
- `ARCHITECTURE.md`
- `docs/product-specs/index.md`
- 必要に応じて `docs/FRONTEND.md`、`docs/SECURITY.md`、`docs/RELIABILITY.md`

## 作業ルール
- 振る舞いを推測で決めず、必ず対応する仕様書を確認する
- 変更した挙動に関わるドキュメントは更新する
- 実装後は build / test / lint を実行する
- より深いディレクトリに `AGENTS.md` がある場合は、その指示を優先する

## 完了条件
- 変更内容が仕様と矛盾していない
- 必要なテストと検証が終わっている
- ドキュメント更新が必要なら反映済み

# AGENTS.md

## このファイルの役割
このファイルは、詳細仕様をすべて書く場所ではなく、参照先と作業ルールを示す入口です。

## このリポジトリで最初に確認するもの
- `ARCHITECTURE.md`
- `docs/product-specs/index.md`
- 必要に応じて `docs/FRONTEND.md`、`docs/SECURITY.md`、`docs/RELIABILITY.md`

## 作業ルール
- 振る舞いを推測で決めず、必ず対応する仕様書を確認する
- 変更した挙動に関わるドキュメントは更新する
- 実装後は build / test / lint を実行する
- より深いディレクトリに `AGENTS.md` がある場合は、その指示を優先する

## 完了条件
- 変更内容が仕様と矛盾していない
- 必要なテストと検証が終わっている
- ドキュメント更新が必要なら反映済み

OpenAIの記事では、AGENTS.md を詳細ルールの置き場ではなく入口の地図として扱い、構造化された docs/ ディレクトリを正本として運用しています。この役割分担は、AIが参照すべき情報を整理する設計の参考になります。 ※6

（※OpenAIの事例を参考にした例）

repo/

├── 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

repo/

├── 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

よくある失敗

もっとも多い失敗は、AIの賢さを過大評価し、組織の未整備を過小評価することです。ドキュメントが曖昧、レビュー基準が人依存、変更サイズが大きい、責任境界が曖昧なままAIを入れると、生成量だけ増えて下流が詰まります。これはAIの精度問題ではなく、構造の問題です。「ツールを変えれば解決する」というのは誤解で、実際に変えるべきなのは開発プロセスや仕組みなどの構造です。※2 ※5

まとめ

ハーネスエンジニアリングは、AIにうまく指示する技術ではありません。AIが継続的に成果を出せるように、開発組織そのものを再設計する技術です。OpenAI、Anthropic、DORAの示唆を合わせて見ると、AIを活用するうえで本当に重要なのは、モデルの性能そのものより、AIが迷わず進めて、途中でミスを検知でき、ミスを修正できる仕事の仕組みを作ることです。※1 ※5 ※7

• ハーネスエンジニアリングは、AIエージェントが安定して働ける環境・文脈・評価系を設計する実務です。※1 ※4
• 「harness」は、モデル単体ではなく、ツール・状態管理・評価を含むエージェントの足場を指します。※4
• AIは組織の強みを伸ばす一方、弱いワークフローや曖昧な運用も増幅します。※2 ※5
• 生成速度だけを上げても、人間のレビューとQAがボトルネックのままではスケールしません。※1 ※7
• プロンプト、コンテキスト、ハーネスは横並びではなく、prompt ⊂ context ⊂ harness と捉えると打ち手を整理しやすくなります。※1 ※9
• 内部ドキュメントの品質、small batches、評価ループ、利用ルールの整備が中核になります。※5 ※8

＼ 図解でわかる ／

資料ダウンロード

ハーネスエンジニアリングの概念と実践を、図解付きでさらに詳しくまとめた資料を公開しています。

資料をダウンロードする

ハーネスエンジニアリングに関心のある方にオススメの記事はこちら

プロンプトエンジニアリングとは？主要手法・実例・チーム導入まで徹底解説【2026年最新版】

プロンプトエンジニアリングは、LLMへの入力テキストを体系的に設計・最適化することで、期待する出力の品質を高める実践的手法です。Zero-shot・Few-shot・CoT・Role Prompting・深津式といった主要手法の使い分けから、プロンプトをコードと同様に管理するチーム導入の進め方まで解説します。

コンテキストエンジニアリングとは？プロンプトエンジニアリングとの違いから実践方法まで徹底解説

コンテキストエンジニアリングとは、LLMのコンテキストウィンドウに何を・どの順番で・どれだけ渡すかを設計・最適化するエンジニアリング手法です。CLAUDE.mdやMCPを使った実践的なコンテキスト設計から、AIコーディングエージェントが陥りやすいコンテキストの腐敗（Context Rot）の対策まで解説します。

仕様駆動開発（SDD）とは？TDD・ウォーターフォール開発との差分からSpec Kit・Kiroを使った実践まで解説

仕様駆動開発（SDD）は、コードを書く前に仕様を明文化し、その仕様を基準に設計・実装・検証を進めるアプローチです。AIコーディングエージェントが普及した今、仕様の曖昧さによる手戻りを構造的に減らす手法として注目されており、GitHub Spec KitやKiroを使った実践方法まで解説します。

FAQ

ハーネスエンジニアリングとは何ですか？

AIエージェントが継続的に正しい仕事を進められるように、環境・文脈・評価・フィードバックループを人間が設計する手法です。ここでいう「ハーネス」は、モデル単体ではなく、入力・ツール呼び出し・状態管理・評価・記録を束ねてエージェントとして機能させる土台を指します。AIにうまく指示する技術ではなく、AIが継続的に成果を出せるように開発組織そのものを再設計する技術です。

なぜ今ハーネスエンジニアリングが必要なのですか？

AIで生成が高速化すると、人間のレビューやQAがボトルネックになりやすいためです。そのため、どこまでを機械的に処理し、どこだけを人間が見ればよいかを先に決めることが必要であり、ハーネスエンジニアリングはそのための設計です。

コンテキストエンジニアリングとの違いは何ですか？

コンテキストエンジニアリングとの違いは扱う設計の対象範囲にあります。プロンプトエンジニアリングは「1回の推論でどう指示を書くか」、コンテキストエンジニアリングは「その推論に何の情報を入れるか」、ハーネスエンジニアリングは「複数回の推論とツール利用を含む作業全体をどう運転するか」を扱います。

ハーネスエンジニアリングを構成する要素は何ですか？

4つの要素で構成されます。1つ目は、リポジトリ知識を正本（正式な参照元）にすること。2つ目はアプリケーションとリポジトリをエージェントが読める状態にすること。3つ目はフィードバックループを実装して生成から修正まで自走させること。4つ目はアーキテクチャ原則を機械的に強制し継続的に掃除することです。

参考・出典

※1 OpenAI「Harness engineering: leveraging Codex in an agent-first world」, 2026
https://openai.com/index/harness-engineering/
※2 DORA「Balancing AI tensions: Moving from AI adoption to effective SDLC use」, 2026
https://dora.dev/insights/balancing-ai-tensions/
※3 Anthropic「Effective harnesses for long-running agents」, 2025
https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
※4 Anthropic「Demystifying evals for AI agents」, 2026
https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
※5 DORA「Capabilities: AI-accessible internal data」, 2026
https://dora.dev/capabilities/ai-accessible-internal-data/
※6 OpenAI「Harness engineering: leveraging Codex in an agent-first world」内 AGENTS.md / docs/ の記述, 2026
https://openai.com/index/harness-engineering/
※7 Anthropic「Harness design for long-running application development」, 2026
https://www.anthropic.com/engineering/harness-design-long-running-apps
※ 8DORA「Helping developers adopt generative AI: Four practical strategies for organizations」, 2025
https://dora.dev/insights/adopt-gen-ai/
※9 Anthropic「Effective context engineering for AI agents」, 2025
https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
※10 DORA「Capabilities: AI-accessible internal data」内 Context engineering の説明, 2026
https://dora.dev/capabilities/ai-accessible-internal-data/