Codexのハーネス設計とは｜エージェントが働く環境の作り方

ハーネスとは何か — harness engineering とプロンプトエンジニアリングの違い

ハーネス（harness）は元来、馬具や安全帯を指す言葉だ。装着する相手の行動を止めるための道具ではなく、力を目的の方向へ伝え、逸脱や落下を防ぎながら目的地へ導くための補助具である。エージェント文脈での「ハーネス」もこの比喩の延長にあり、エージェントを取り巻く環境一式——正しい情報へたどり着ける経路、アプリやコードの状態を読み取れる観測手段、生成した結果を自分で検証・修正できる仕組み——を指す（出典: https://openai.com/index/harness-engineering/ ）。

プロンプトエンジニアリングとの違いはここにある。プロンプトエンジニアリングが「1 回の指示文をどう書くか」という入力の工夫だとすれば、ハーネスエンジニアリングは「何度も繰り返し働くエージェントのために、恒常的な環境をどう設計するか」という基盤の工夫だ。指示文は使い捨てだが、ハーネスは資産として積み上がり、以後のすべてのタスクの成功率を底上げする。

公式ブログの根底にあるのは「人間は舵取りし、エージェントが実行する（Humans steer. Agents execute.）」という原則だ。象徴的なのは、エージェントがタスクに失敗したときの向き合い方である。手を出してコードを書き直すのではなく、その失敗を「環境に何かが欠けているシグナル」として扱い、環境側を直す。ボトルネックはモデルの能力ではなく、エージェントにとって環境がどれだけ読み解きやすいかにある、という見立てだ（出典: https://openai.com/index/harness-engineering/ ）。

OpenAI は Codex で何を実践したか

公式ブログによれば、OpenAI のチームは約 5 ヶ月間で約 100 万行のコードベースを持つ製品ベータを構築し、その全行を Codex エージェントが生成した。人の手で書かれた行はないという。当初 3 人（のちに 7 人へ拡大）のエンジニアが Codex の舵取り役に徹し、期間中に約 1,500 件のプルリクエストを作成・マージした。チームは、人手で書いた場合に比べて約 10 分の 1 の時間で構築できたと見積もっている（出典: https://openai.com/index/harness-engineering/ ）。

実践の中身で目を引くのは、リポジトリの知識をエージェント向けに設計し直した点だ。AGENTS.md は約 100 行に抑えて「目次」として機能させ、詳細は構造化された docs/ ディレクトリに版管理して置く。巨大な指示ファイルをひとつ渡すのではなく、小さな入口から必要な場所へたどれる「地図」を渡す——コンテキストは希少資源であり、1,000 ページのマニュアルはタスクそのものを押し出してしまう、という整理だ（出典: https://openai.com/index/harness-engineering/ ）。

もうひとつの柱が、アーキテクチャの機械的な強制と継続的な手入れである。依存の方向などコードベースの不変条件はカスタムリンターで検証し、「境界は厳格に、内部は自由に」を機械が守らせる。溜まった逸脱の整理は人間の週末作業ではなく、エージェントが担う定期的な整理タスクへ移した。レビューで人間が付けた指摘は文書やルールへ昇格させ、次からはエージェント自身が守れるようにする。人間の仕事が「コードを書くこと」から「環境の設計・意図の明確化・フィードバックループの構築」へ移る、という主張がここに凝縮されている（出典: https://openai.com/index/harness-engineering/ ）。

Codex ユーザーが今日からできるハーネス設計の第一歩

100 万行の実例をそのまま真似る必要はない。ハーネスの構成要素は Codex の既存機能に分解でき、どれも今日から整えられる。

最初の一歩は AGENTS.md だ。リポジトリの前提・規約・やってはいけないことを教える場所であり、OpenAI の実践が示すとおり「短い目次」として書くのがコツになる。何もかも詰め込むのではなく、エージェントが次にどこを見ればよいかを示す。書き方の詳細はAGENTS.md の書き方の記事にまとめている。

次に、サンドボックスと承認ポリシーで「任せる範囲」を自分で決める。Codex は設定ファイル config.toml の sandbox_mode（read-only / workspace-write / danger-full-access）でファイルへの書き込み範囲を、approval_policy（untrusted / on-request / never）で確認を求めるタイミングを制御でき、ネットワークアクセスは既定で制限される（出典: https://developers.openai.com/codex/config-reference / https://developers.openai.com/codex/concepts/sandboxing ）。安全帯の長さを決めるのは自分だ、という点がまさにハーネスの発想であり、動作の詳細はサンドボックスモードの記事で解説している。

三つ目が、自己検証の足場だ。テスト・リンター・型検査・ログといった「結果を自分で確かめる手段」が整っているほど、エージェントは生成→検証→修正のループを自力で回せる。人間がレビューで拾っていた指摘をテストやリンタールールに昇格させていけば、フィードバックループは回すたびに強くなる。エージェントとしての使い方全般——タスクの渡し方やコスト管理——はCodex をエージェントとして使う方法の記事を参照してほしい。

業界全体の潮流 — エージェントに目と手を与える動き

ハーネスを拡張する流れは OpenAI に限らない。2026 年 7 月 1 日には GitHub Copilot で、画像や PDF をチャットに添付して内容を推論させられる Copilot Vision が全プラン対象で一般提供（GA）となり（出典: https://github.blog/changelog/2026-07-01-copilot-vision-is-generally-available/ ）、同日に VS Code の Browser tools も GA となって、エージェントが実ブラウザを操作しページ内容の読み取りやスクリーンショット取得まで行えるようになった（出典: https://github.blog/changelog/2026-07-01-browser-tools-for-github-copilot-in-vs-code-are-generally-available/ ）。エージェントに与える「目」と「手」、すなわち入力と道具を拡張する動きは業界全体で進んでおり、ハーネス設計という視点はツールを問わず効いてくる。

まとめ — 環境を設計する側に回る

ハーネス設計とは、エージェントが確実に働けるように環境を整えることだ。Codex なら AGENTS.md・サンドボックスと承認ポリシー・自己検証の足場という公式機能の組み合わせで今日から始められる。OpenAI 自身が約 5 ヶ月・約 100 万行の開発でこの考え方を実証し、その方法を公開している（出典: https://openai.com/index/harness-engineering/ ）。モデルの進化を待つのではなく、環境を設計する側に回ること——それがエージェント時代の成果の差になる。