OpenAI · February 2026 · Harness Engineering
SECTION 01 · DEFINITION
「ハーネス（harness）」は本来、馬を制御するための馬具のことです。強くて予測不能な馬を、人間が望む方向に安全に導くための手綱・鞍・留め具の総体。
OpenAIはこの言葉を、AIエージェントを制御するための技術的仕組みの総体に使いました。
ハーネスエンジニアリングとは、AIエージェントが安全かつ高品質に開発できる「環境・制約・フィードバックループ」を設計する仕事のことです。コードを書く人から、AIがコードを書くためのシステムを設計する人へ——役割の転換を意味します。
SECTION 02 · KEY FINDING
最初にこの実験を聞いたとき、多くの人はこう思うかもしれません。「性能の良いAIモデルさえあれば、あとは指示するだけでは？」
実際には違いました。
AIモデルの性能が低かったわけではありません。問題は「環境が不十分だった」ことでした。エージェントには、高レベルの目標に向かって前進するための「ツール」「抽象化」「内部構造」が欠けていました。
エンジニアチームの主な仕事は、「エージェントが有益な仕事をできるようにすること」に変わりました。Codexが「賢い」かどうかより、Codexが「動ける環境があるか」の方が重要だったのです。
エンジニアにとって最も難しかったのは、「コードを書かない」という制約を守ることだった。手を出したい衝動を抑え、その代わりに「なぜCodexがここで詰まったのか」を分析し、環境を修正することに集中した。
OpenAI, Harness Engineering, 2026SECTION 03 · CORE INSIGHT
ハーネスエンジニアリングを理解する上で最も重要な洞察が一つあります。
AIエージェントにとって、リポジトリの外に知識は存在しない。
Slackの会話、Google Docsの資料、人間の頭の中にある暗黙知は——Codexからは見えない。
この洞察が意味することは明確です。設計判断・アーキテクチャの経緯・運用ルール・技術的負債——重要なことは全て、バージョン管理されたファイルとしてリポジトリ内に書き残さなければならない。Slackで話し合っても、GoogleDocsに書いても、Codexには届きません。
SECTION 04 · ARCHITECTURE
OpenAIの実験で明らかになった、AIエージェントが自律的に開発を続けるために必要な4つの要素。どれか一つが欠けても、エージェントは止まる。
リポジトリの構造と「何がどこにあるか」を示す目次。巨大なマニュアルではなく、エージェントが作業に必要な知識へたどり着くための道案内として機能する。
設計判断・プロダクト原則・技術的経緯・運用ルールを構造化して保管する場所。人間にとっての「ドキュメント」ではなく、AIにとっての「長期記憶」として設計する。
依存方向・レイヤー構造・命名規則・ファイルサイズ・ログ形式などを、「お願い」ではなく自動チェックで強制する。これらのリンター自体もCodexが書く。
ログ・メトリクス・トレースをCodexが直接参照できる形式で整備。LogQLやPromQLで原因調査、Chrome DevToolsでUIのバグ再現まで自律的に行う。
SECTION 05 · DEEP DIVE
AGENTS.md の正しい使い方AGENTS.md は「エージェントへの指示書」として使われがちですが、OpenAIの実験で分かったのは、それを巨大なマニュアルにするのは逆効果だということです。
全ての指示・ルール・例外を1ファイルに詰め込む
問題: コンテキストを圧迫・古くなりやすい・判断精度が下がる
目次・地図として機能させ、詳細はdocs/に委ねる
効果: 必要な知識だけ参照・更新しやすい・判断精度が高い
重要な前提：最初のAGENTS.mdも、最初のCI設定も、最初のリポジトリ構造も、Codex自身が生成した。人間が手書きで用意したわけではありません。ハーネスを育てるのもAIの仕事です。
SECTION 06 · HOW IT WORKS
十分なハーネスが整ったとき、Codexは一つのプロンプトから以下の全工程を自律的に実行できるようになりました。人間の介入は「必要な場合のみ」です。
SECTION 07 · HUMAN ROLE
エンジニアは「コードを書く人」から、「AIがコードを書けるシステムを設計する人」になりました。これは仕事の減少ではなく、仕事の抽象度が上がったということです。
| 従来の開発（コードを書く） | エージェントファースト（環境を設計する） |
|---|---|
| コードを実装する | Codexに実装させ、結果をレビューする |
| 実装方針を細かく指示する | 境界条件・不変条件・品質基準を定義する |
| 手作業でコードレビューする | 自動レビュー＋機械チェックの仕組みを設計する |
| 補助的にドキュメントを書く | docs/をAIの「記憶システム」として設計・維持する |
| 技術的負債は後でまとめて直す | 定期的にAIに検出・修正させる仕組みを作る |
| テストが失敗したら原因調査する | AIが読めるログ・メトリクス環境を整備する |
| バグ再現を手で行う | ブラウザ操作・観測ツールをAIに接続する |
「コードを書かない」という制約が最も難しい習慣の変化だった。手を出したい衝動をおさえ、代わりに「なぜCodexはここで詰まったのか」を分析し、ハーネスを修正することに集中する——これが新しいエンジニアリングの形だ。
OpenAI内部チームのふり返りよりSECTION 08 · FLYWHEEL
チームが3人から7人に増えたにもかかわらず、1人あたりの生産性は落ちなかった。むしろ上がった。これは「複利効果」によるものです。
現在到達した閾値： Codexは現在、仕様書を受け取ってからマージまでを完全に自律的に実行できるようになっています。コードを書き、テストを実行し、レビューフィードバックに対応し、マージする——全工程をエージェントが担います。
SECTION 09 · CRITICAL VIEW
OpenAI自身も明言しています。「これは特定のリポジトリ構造・ツール・制約があって初めて成立するもので、準備なしに一般化できるものではない」と。
ハーネスを整えるにはCI・リンター・ドキュメント構造・観測インフラの設計が必要。この準備期間は生産性が下がる。
docs/をAIの記憶として使うということは、docs/が古くなれば「AIが間違った知識で動く」ことを意味する。メンテナンスコストが新たに発生する。
AIが生成したコードを別のAIがレビューし、さらに別のAIが修正する構造では、小さな誤りが指数的に拡大する可能性がある。人間の目が入る箇所を意図的に設計する必要がある。
高い安全要件・医療・金融・規制業界など、人間の判断が法的に求められる領域では、このアプローチをそのまま適用することはできない。
ハーネスエンジニアリングは、コードを書く技術とは異なるスキルを要求する。「AIが詰まる理由を見抜く」能力は、新しい専門性であり、まだノウハウが蓄積途中だ。
この実験は、OpenAI自身が作ったモデル（Codex/GPT-5）を使った、OpenAIの社内プロダクト開発。異なる組織・モデル・プロダクト領域での再現性は未検証だ。
SECTION 10 · IMPLICATIONS
OpenAIはブログの結びにこう書いています。
現在の最も難しい課題は、大規模で複雑かつ信頼性の高いソフトウェアをエージェントが構築・保守できる「環境・フィードバックループ・制御システム」を設計することだ。
OpenAI, Harness Engineering, February 2026どう実装するかを考え、自分で書く。個人の技術力が生産性に直結する。
AIが最高のパフォーマンスを発揮できる環境を設計する。制約・フィードバック・記憶システムの設計者になる。
これは「エンジニアが不要になる」という話ではありません。エンジニアが扱う問題の抽象度が上がったという話です。コードの1行1行ではなく、システム全体の設計・制約・信頼性を考えることがエンジニアの仕事になりつつあります。
プロンプトを1つ工夫するより、リポジトリ構造・ドキュメント・リンター・CI・観測環境を整える方が、AIを本当に使いこなす近道だということを、この実験は示しています。
SOURCES · 情報ソース