# Harness Engineering AI エージェント（特に [[Codex]] のようなコーディングエージェント）を囲む**足場・制約・フィードバックループの完全な環境**を設計・維持する工学的規律。[[OpenAI]] が 2026 年 2 月に提唱した概念で、エージェントが安定した長時間の自律実行を行えるようにする。 ## 定義 > The name they gave to that environment — and to the emerging discipline of building it — is a harness. プロンプトエンジニアリング・コンテキストエンジニアリングとは異なる第三の設計層: | 概念 | 中心課題 | スコープ | |------|--------|--------| | プロンプトエンジニアリング | メッセージの表現・構造 | 単一ターン | | コンテキストエンジニアリング | 情報の可視性管理 | コンテキストウィンドウ | | **ハーネスエンジニアリング** | 運用環境全体の設計 | 数時間に及ぶ自律実行 | ## 主要要素 ### 1. コンテキストファイル（AGENTS.md / CLAUDE.md） エージェントへの共有理解を提供する機械可読ドキュメント。肥大化を防ぎ、構造化されたドキュメントへのインデックスとして機能させる。OpenAI 事例では 100 行のインデックス + `/docs/` ディレクトリに縮小。 ### 2. 機械的強制（Mechanical Enforcement） カスタムリンターと CI による依存関係の強制。OpenAI 事例での依存フロー: ``` Types → Config → Repo → Service → Runtime → UI ``` 違反時に自動修正指示をエージェントのコンテキストに注入する「一方向依存関係バリデーション」。 ### 3. フィードバックループ エージェントが自身の出力を検証するための観測環境: - Chrome DevTools Protocol（スクリーンショット） - LogQL（ログクエリ） - PromQL（メトリクス監視） ### 4. ガベージコレクション バックグラウンドエージェントによる技術負債の継続スキャンと自動リファクタリング PR 提出。 ### 5. エージェント間レビュー（Agent-to-Agent Review） レビューを人間からエージェントに委譲し、人間は高水準の設計判断に集中。 ## エンジニアの役割変化 ハーネスエンジニアリングにより、エンジニアの仕事は以下に移行する: - **環境を設計する**（Design the environment） - **意図を仕様化する**（Specify intent） - **フィードバックループを構築する**（Build feedback loops） ## OpenAI 実験の成果 [[OpenAI-Harness-Engineering]] によると、3 名のエンジニアが 5 ヶ月で以下を達成: - 100 万行の本番コード生成 - 1,500 本超の PR マージ - 平均 3.5 PR/エンジニア/日 - 手書きコード: **0 行** ## 実装事例・成果データ | 事例 | 変化 | 成果 | |------|------|------| | [[OpenAI]] Codex プロジェクト | ハーネス全体設計 | 100 万行・1,500 PR・手書き 0 行 | | [[Symphony]] 採用チーム | オーケストレーション層追加 | PR マージ 500% 増 | | Hashline | 編集フォーマット変更のみ | Grok Code Fast: 6.7% → 68.3% | | LangChain | ハーネス改善 | ベンチマーク: 52.8% → 66.5%、順位: 30 位台 → 5 位 | ## 設計哲学 > 「最良のハーネスコンポーネントは削除されるよう設計されている」 モデルが向上するにつれて、かつて必要だった制約は不要になる。ハーネスはモデルの現在の限界を補う一時的な足場であり、常に削減可能な余地を意識して設計する。 ## エージェント自己評価問題への対処 ### コンテキスト不安（Context Anxiety） エージェントがコンテキスト上限を感知して早期終了する問題。対策: 大きなコンテキスト枠を公開しつつ実使用を制限。 ### 自己評価バイアス エージェントが自身の出力を過大評価する問題。GAN から借用した生成器・評価器分離パターンで対処。 ## 関連概念・エンティティ - [[Codex]] — ハーネスエンジニアリングの主要対象エージェント - [[Symphony]] — ハーネスエンジニアリング原則のオープンソース実装 - [[OpenAI]] — 概念の提唱組織 - [[agentic SRE]] — SRE 文脈でのエージェント自律実行（関連領域） ## Anthropic のハーネス設計知見 [[OpenAI]] が概念を提唱した同時期に、[[Anthropic]] 側も独立して類似の知見を蓄積した。 ### Initializer + Coding エージェント（Justin Young, 2025-11-26） [[Justin Young]] による [[@2025__Anthropic Engineering Blog__Effective Harnesses for Long-Running Agents]] は、**マルチコンテキストウィンドウ**問題——各セッション終了時にエージェントがメモリを失う問題——に特化したハーネス設計を報告する。 - **Initializer エージェント**（初回）：`init.sh`・進捗ファイル・JSON フィーチャーリスト・初期 git コミットを作成 - **Coding エージェント**（後続）：固定シーケンス（git ログ確認 → 1 機能選択 → サーバー起動 → E2E テスト → 実装）で再現性を確保 - JSON フィーチャーリスト：モデルが Markdown より誤修正しにくいため JSON を使用 - Puppeteer MCP によるブラウザ E2E テストが品質向上に寄与 ### Planner + Generator + Evaluator（Prithvi Rajasekaran, 2026-03-24） [[Prithvi Rajasekaran]] による [[@2026__Anthropic Engineering Blog__Harness Design for Long-Running Application Development]] は、**自己評価バイアス**と**コンテキスト不安**に対応する 3 エージェント構成を提示する。 - **コンテキストリセット**：圧縮ではなく白紙再開でコヒーレンス保持 - GAN 着想の**ジェネレータ・エバリュエータ**分離で自己評価バイアスを構造的に解消 - Playwright MCP で実際のブラウザ操作を伴う評価（スクリーンショット・DOM 検査） - Solo vs フルハーネス比較：20 分/$9（動作不可）vs 6 時間/$200（高品質） - Opus 4.6 でスプリント分解を削除——**荷重仮定の再評価**の好例 > 「ハーネスの各コンポーネントは、モデルが単独ではできないことに関する仮定をエンコードしている。それらの仮定はストレステストする価値がある。」—— [[Prithvi Rajasekaran]] ## 学術的体系化: RSI 文脈でのハーネス設計パターン(Weng, 2026) [[Lilian Weng]] は [[@2026__Lil'Log__Harness Engineering for Self-Improvement]] で、[[OpenAI]]・[[Anthropic]] の実務ブログが個別に報告してきたハーネス設計知見を、[[Recursive Self-Improvement]](RSI)という統一的な研究文脈のもとで学術的に体系化した。 ### 3つの設計パターン 1. **Workflow Automation** — plan → execute → observe/test → improve の目標指向ループ。[[Andrej Karpathy]] の autoresearch リポジトリが典型例。 2. **File System as Persistent Memory** — ハーネスはワークフロー全体をコンテキストに保持せず、恒久的な状態はファイルに保持する。`bash` 経由のファイル読み書き編集能力が基礎技能となる。 3. **Sub-agent and Backend Jobs** — 並列サブエージェントとバックエンドジョブの監視。並列性を明示的・検査可能にすることが要点(出力がチャットコンテキストのみに存在すると陳腐化・不可視化する)。 ### ハーネス最適化の進行段階 `instruction prompts → structured context → workflow → harness code → optimizer code` の順に最適化対象が進行し、モデルが強く賢くなるほどより複雑で汎用的な対象へ移行する。この進行は、本ページ「設計哲学」節の「最良のハーネスコンポーネントは削除されるよう設計されている」という OpenAI の知見と同型の洞察であり、ハーネスコード自体・さらにはハーネスを最適化するコード(optimizer code)へと対象が深まっていく方向性を示す。 Weng はこの先の研究動向を [[コンテキストエンジニアリング]](ACE・MCE)、[[ハーネス自己進化]](Meta-Harness・Self-Harness・AHE)、[[進化的探索によるエージェント設計]](ADAS・AFlow・AlphaEvolve 系)の3系統に整理しており、それぞれ独立した concept ページで詳細を扱う。(Source: [[@2026__Lil'Log__Harness Engineering for Self-Improvement]]) ## デザイン史の類比からの独立到達: Mitchell Hashimoto の実践(広木大地, 2026-03-24) [[Mitchell Hashimoto]]([[HashiCorp]] 共同創業者、Vagrant/Terraform の開発者)は、OpenAI・Anthropic の実務ブログ群とは独立に、同じ「ハーネス」という語で類似の実践を行っている。[[@2026__NewsPicks__ソフトウェアの工業化とアーツ&クラフツ運動]]([[広木大地]])が報告する彼のアプローチは「エージェントがミスするたびに、同じミスが二度と起きないよう CLAUDE.md への制約追記・テスト追加・リンタールール追加でハーネスを構築する」というもので、OpenAI 版と同様に「エージェントの出力品質を、エージェント自身の賢さではなく周囲の環境設計によって制御する」という核心思想を共有する。 広木はこの実践を、[[William Morris]] のアーツ&クラフツ運動から [[Walter Gropius]] のバウハウスに至る150年のデザイン史の弁証法(正→反→合)における「合(統合)」の2026年版として位置づけ、特にバウハウス予備課程(Vorkurs)——学生が素材に手で触れその抵抗や性質を身体で学ぶ教育——と構造的に対応させた。「エージェントという素材の失敗モードを観察し、その知見をハーネスに変換する」という営みは、素材を知り尽くして初めて設計ができるという Vorkurs の思想と同型だと論じる。(Source: [[@2026__NewsPicks__ソフトウェアの工業化とアーツ&クラフツ運動]]) ## 横断的知見 - **実務ブログ(OpenAI・Anthropic)と学術サーベイ(Weng)の関係**: [[OpenAI-Harness-Engineering]] と Anthropic の2記事([[@2025__Anthropic Engineering Blog__Effective Harnesses for Long-Running Agents]]・[[@2026__Anthropic Engineering Blog__Harness Design for Long-Running Application Development]])はいずれも実務者の一次報告(具体的な数値成果・実装詳細)である一方、[[@2026__Lil'Log__Harness Engineering for Self-Improvement]] はこれらを RSI という理論的文脈に位置づけ、Meta-Harness・Self-Harness 等のより新しい学術研究との橋渡しを行う。3つの実務パターン(Initializer+Coding、Planner+Generator+Evaluator、GC タスク)は、Weng の「ハーネス最適化の進行段階」でいえば "workflow" 〜 "harness code" の中間に位置する具体例と読める。(Source: [[OpenAI-Harness-Engineering]], [[@2025__Anthropic Engineering Blog__Effective Harnesses for Long-Running Agents]], [[@2026__Anthropic Engineering Blog__Harness Design for Long-Running Application Development]], [[@2026__Lil'Log__Harness Engineering for Self-Improvement]]) - **実務者3系統(OpenAI・Anthropic・Hashimoto/広木)の定義の力点差**: OpenAI 版は「足場・制約・フィードバックループの完全な環境」という工学的・システム設計的定義を中心に置く一方、[[Mitchell Hashimoto]] の実践を紹介する[[@2026__NewsPicks__ソフトウェアの工業化とアーツ&クラフツ運動]]はデザイン史(アーツ&クラフツ→バウハウス)の類比を通じて「エージェントという素材の性質を手で知り尽くした上での制約設計」という職人的認識論を強調する。同じ「ハーネス」という語・同じ核心思想(環境設計による品質制御)に、異なる知的系譜から独立に到達している点が横断的に見える。(Source: [[OpenAI-Harness-Engineering]], [[@2026__NewsPicks__ソフトウェアの工業化とアーツ&クラフツ運動]]) - **「ハーネス」という語は、コーディングエージェントの実行環境設計だけでなく、AI 機能を組み込んだアプリケーション全体を取り囲む決定論的コード層にも独立に用いられる**: OpenAI・Anthropic・Hashimoto の実務知見(本ページ主要部)はいずれもコーディングエージェント([[Codex]] 等)を長時間自律実行させる環境設計を対象とするのに対し、`Observability Engineering` 第21章([[Phillip Carter]] 寄稿)は LLM 搭載アプリケーション(Honeycomb の Query Assistant・Canvas)において、AI にツールを提供する・入出力の誤りを補正する・AI とエンドユーザーの通信を仲介する、という「配管」の役割を担うコードを同じく「harness」と呼ぶ。適用対象(エージェントの実行環境 対 アプリケーションの実行時補正)は異なるが、「モデルの現在の限界を、周囲の決定論的コードで構造的に補う」という核心思想は共通しており、Query Assistant の`COUNT`演算子JSON補正(エラー率25%→14%)は、本ページ「設計哲学」節が述べる「モデルが向上するにつれて不要になる一時的な足場」の具体例として読める。(Source: [[OpenAI-Harness-Engineering]], [[@2026__OReilly__Observability Engineering 2E - Chapter 21 Observability for Large Language Models]]) → [[LLMアプリケーション信頼性]] - **「本番でのテスト」の必然性は、コーディングエージェント文脈とLLMアプリケーション文脈の双方で独立に到達される**: Anthropic の Planner+Generator+Evaluator(本ページ既述)がコンテキスト不安・自己評価バイアスへの対処として本番相当の評価環境(Playwright MCP でのブラウザ操作)を重視するのと同様に、`Observability Engineering` 第21章は「LLM アプリケーションは環境・ユーザーをまたいで同じ挙動をしないため、伝統的な網羅的テストケースでは不十分であり test in prod が必須」と述べる。ハーネスは静的なテスト環境ではなく、本番テレメトリと評価を結ぶ学習ループの一部として設計される点が両文脈に共通する。(Source: [[@2026__Anthropic Engineering Blog__Harness Design for Long-Running Application Development]], [[@2026__OReilly__Observability Engineering 2E - Chapter 21 Observability for Large Language Models]]) → [[GenAI オブザーバビリティ]] ## 未解決の問い - OpenAI 版の「足場・制約・フィードバックループ」という工学的定義と、広木大地が紹介する Mitchell Hashimoto の「素材の性質を手で知り尽くした上での制約設計」という職人的認識論は、同一実践の異なる説明語彙か、それとも実装上異なるアプローチに帰結するか。 - コーディングエージェントの実行環境としての「ハーネス」(本ページ主要部)と、LLM 搭載アプリケーションの実行時補正層としての「ハーネス」(`Observability Engineering` 第21章)は、将来的に1つの統一概念として体系化されるべきか、それとも適用対象の違い(開発時 対 実行時、エージェント 対 アプリケーション)ゆえに別概念として維持すべきか。 - Weng の3パターン(Workflow Automation / File System as Persistent Memory / Sub-agent and Backend Jobs)と、Anthropic の Planner+Generator+Evaluator・OpenAI の GC タスクは、どこまで同一の設計原則の異なる呼称か、どこから実装上の差異が本質的に異なるか。 - この概念をどのソース群で継続的に検証するか。 ## 出典 - [[OpenAI-Harness-Engineering]] (2026-02-11, OpenAI) - [[@2025__Anthropic Engineering Blog__Effective Harnesses for Long-Running Agents]] (2025-11-26, [[Justin Young]], Anthropic) - [[@2026__Anthropic Engineering Blog__Harness Design for Long-Running Application Development]] (2026-03-24, [[Prithvi Rajasekaran]], Anthropic) - [[@2026__Lil'Log__Harness Engineering for Self-Improvement]] (2026-07-04, [[Lilian Weng]]) - [[@2026__NewsPicks__ソフトウェアの工業化とアーツ&クラフツ運動]] (2026-03-24, [[広木大地]]、[[Mitchell Hashimoto]] の実践紹介) - [[@2026__OReilly__Observability Engineering 2E - Chapter 21 Observability for Large Language Models]] ([[Phillip Carter]]、Honeycomb Query Assistant/CanvasにおけるLLMアプリケーション実行時補正としての「harness」)