ハーネスエンジニアリングとは｜AIエージェント時代に「環境・意図・フィードバック」を設計する開発手法

ハーネスエンジニアリング（harness engineering）は、OpenAI が 2026 年 2 月の公式記事 Harness engineering: leveraging Codex in an agent-first worldで表題に掲げ、Anthropic Engineering の Harness design for long-running application developmentや、Microsoft Foundry の公式表現 「multi-model and multi-harness by design」などの一次ソースで関連する harness 概念が広がっている開発手法です。中心命題は「Humans steer. Agents execute.（人間は舵を取り、エージェントが実行する）」── エンジニアの仕事は、コードを書くことから「環境を設計し、意図を明示し、フィードバックループを構築する」ことに変わる、というのが共通の見方です。

01.結論：Humans steer. Agents execute.

OpenAI の Ryan Lopopolo 氏が 2026 年 2 月に公開した記事の中心命題は短い 1 行に凝縮されています。原文を直接引きます。

OpenAI 自身は、Codex (GPT-5) を使った 3〜7 名の社内チームが 5 ヶ月で約 100 万行・1,500 PR の社内製品を 手書きコード 0 行 でリリースしたと報告しています（同記事）。これは harness engineering を極端まで突き詰めたときの実証実験で、書くべきものはエージェントが動く環境とその制約だ、というのが直接の主張です。この実証を支えた組織側の仕組み（DRI・少人数精鋭チーム）は 「なぜ OpenAI は開発が異常に速いのか」 で詳しく扱っています。

02.業界用語として確立した経緯（2025-2026）

「harness」という語は元々 EleutherAI lm-evaluation-harness（2021〜）のような evaluation framework で使われていましたが、2025〜2026 にかけて 本番エージェント運用 の文脈でも各社が独立に使い始め、業界共通の語彙へ広がりました。代表的な一次ソースを並べておきます。

AGENTS.md は OpenAI / Google（Jules）/ Cursor / Factory / Sourcegraph（Amp）が 共同で標準化したリポジトリ単位の agent 指示ファイル仕様で、現在は Linux Foundation 配下の Agentic AI Foundation（AAIF）がホストしています。さらに xAI は Grok Code Fast 1 の model card で「SWE-Bench-Verified 70.8% using xAI's own internal harness」と ベンチスコアが harness 込みでしか比較できない ことを公式表現に含めており、業界全体で harness を独立した工学領域として扱う流れになっています。

03.ハーネスエンジニアリングの 3 つの仕事

OpenAI の定義「design environments / specify intent / build feedback loops」を実装に落とすと、次の 3 つに分解できます。各仕事に対応する具体的な成果物がはっきりしているので、PR レビューや設計議論で「これはどの仕事の話？」を切り分けやすくなります。

環境を設計する：リポ構造・AGENTS.md・Sandbox

エージェントが参照できる「世界」を物理的に作る仕事です。OpenAI Lopopolo は「anything it can't access in-context while running effectively doesn't exist（実行中に context で参照できないものは、エージェントにとって存在しないのと同じ）」と書いており、リポジトリ構造そのものをエージェント可読性で最適化することを推奨しています。

• AGENTS.md / CLAUDE.md は map であって encyclopedia ではない：OpenAI は「give Codex a map, not a 1,000-page instruction manual（Codex には 1,000 ページの指示書ではなく、地図を渡せ）」と明言。100 行程度の AGENTS.md を目次にして、詳細は docs/ 配下を system of record として構造化（design-docs / exec-plans / product-specs / references）するパターンを推奨。
• Sandbox（壊しても良い実行環境）：Docker・Firecracker microVM・Modal・Daytona・E2B・Cloudflare Sandbox のいずれかで隔離。試行ごとにコンテナを使い捨てるのが基本で、AWS Bedrock AgentCore も Runtime コンポーネントで同じ抽象を提供。最初は Docker で十分。
• Observability の事前配線：本番では Langfuse / LangSmith / W&B Weave 等で trace を蓄積。OpenAI は Vector → Victoria Logs/Metrics/Traces を git worktree ごとに立てて LogQL/PromQL/TraceQL でエージェントから query できる構成を採用。

意図を明示する：custom lint で規約を機械強制

エージェントが「何が良いコードか」を判定できる形に落とす仕事です。system prompt や規約ドキュメントだけでは、エージェントの出力が回を重ねるごとに少しずつ規約から外れていく（OpenAI が言う architectural drift） ので、機械的に強制する仕掛けを並走させます。OpenAI Lopopolo の表現で「constraints are what allows speed without decay or architectural drift（制約こそが、品質劣化やアーキテクチャの drift なしに速度を出すことを可能にする）」。

• Architectural guardrails by custom lint：OpenAI は各 business domain を「Types → Config → Repo → Service → Runtime → UI」の固定レイヤに分割し、依存方向を custom linter と structural test で機械的に強制。一般化すれば「自社のアーキテクチャ規約を AST レベルで lint 化する」というパターン。
• Remediation hint をエラーメッセージに埋め込む：lint で弾くだけでなく、「次にどうすべきか」を出力に含めることで、エージェントの context にそのまま戻せる。Verify Loop の効率が劇的に上がる。
• Golden principles + 定期 refactor タスク：「共有ユーティリティを優先」「データを YOLO で probe しない」のような社内規範を encode し、定期的に Codex/Claude タスクが quality grade を更新して refactor PR を自動マージするパターンで「AI slop」を garbage collect する。

フィードバックループを構築する：test・lint・agent-to-agent

エージェントが「自分の出力が良いか悪いか」を機械的に知れるようにする仕事です。Anthropic Engineering「Harness design for long-running application development」が示すように、every component in a harness encodes an assumption about what the model can't do on its own（harness の全てのコンポーネントは、モデル単体ではできないことの前提を encode している）── つまり verify が無いと、エージェントは「出力が良いと自分で信じる」状態で止まります。

• テスト・lint・型を bash 経由で回せるようにする：エージェントが pytest / ruff / tsc / pyright を呼べる構成にしておけば、その終了コードが verify scorer になる。最も単純で再現性の高い feedback。
• agent-to-agent review（Ralph Wiggum Loop）：OpenAI Lopopolo は生成したエージェントが自分の PR を別の reviewer agent にレビューさせ、合格まで反復するパターンを公開。レビューもほぼ agent-to-agent。
• 本番 trace を eval dataset に戻す：observability で取った失敗 trace を毎週 eval に戻すと、harness は継続的に改善する閉ループになる（後述）。

04.ガードレール：scaffolding の保護層

ガードレールは自社アプリの周辺コードとして組む実装パターンで、Claude Agent SDK・OpenAI Agents SDK・LangGraph、あるいは Anthropic / OpenAI の API を直接叩く構成、いずれの場合も同じ 4 層を実装することになります。

05.CI と本番フィードバックループ

CI は「コードが壊れていないか」を測る既存パイプラインに、「エージェントが期待通り動くか」を測る eval ジョブを足す形で組みます。さらに本番運用の trace を eval dataset に戻すと、harness は継続的に改善する閉ループになります。

N 試行 matrix で確率分布を取る

LLM は temperature を 0 にしても完全に決定論ではなく、同じ入力で結果がぶれます。1 試行の合否ではなく、N 試行回して成功率 / pass@k / p95 を測るのが基本です。GitHub Actions であれば matrix strategy で並列化します。

name: agent-eval
on: [pull_request, workflow_dispatch]

jobs:
  eval:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        epoch: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]   # 10 試行を並列実行
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - name: Run agent eval
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          MAX_TOKENS_PER_TASK: 200000              # ② Cost ガードレール
          AGENT_MODEL: claude-haiku-4-5            # PR では小モデルで回す
        run: pnpm agent:eval
      - name: Upload trace
        uses: actions/upload-artifact@v4
        with:
          name: trace-${{ matrix.epoch }}
          path: logs/
  aggregate:
    needs: eval
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
      - run: pnpm agent:aggregate  # pass@10 / 成功率 / p95 を集計

PR では小モデル × 代表 10〜30 件 × 3〜5 試行で「明らかな回帰」を弾き、nightly では本番モデル × 全件 × 10 試行で「確率的な回帰」を検出。リリース前は拡張データセット × 全モデルでフル eval、週次では本番ログから抽出した実トラフィックを回す、と階層化します。

agent-to-agent review（Ralph Wiggum Loop）

OpenAI Lopopolo が「Ralph Wiggum Loop」と命名したパターンは、生成エージェントが書いた PR を、別の reviewer エージェント（複数・並列）にレビューさせ、合格まで反復する仕組みです。命名は『シンプソンズ』のキャラクター Ralph Wiggum から取られており、「単純なループだが、回し続けるとちゃんと結果が出る」というニュアンスが込められています。

OpenAI の運用実態は「レビューもほぼ agent-to-agent」で、人間レビューは 最後の merge gate にだけ残す。Lopopolo は社内 100 万行・1,500 PR を 3〜7 名のチームでリリースした文脈で、このパターンを 並列に複数 reviewer を回す 構成として公開しています。なぜ機能するかは 3 つの理由に分解できます。

• self-review より other-review の方が効きやすい：生成エージェントは自分の出力に bias がかかる（自己肯定の傾向）。別 context で起動した reviewer は「fresh eye」として欠陥を見つけやすい。
• 役割を分担すると指摘の質が上がる：security / style / performance / API 互換性 などの観点で reviewer を分け、それぞれに専門 system prompt を渡す。1 つの reviewer に全部やらせるより、観点ごとに分けた方が指摘漏れが減る。
• 合格基準が外在化される：reviewer の「合格 / 不合格 + 理由」を出力させると、それがそのまま test / lint の終了コードと同じ verify scorer として機能する。生成エージェントは reviewer のコメントを context に戻して fix する Verify Loop が回る。

実装の最小構成は次の 3 ステップです。自社アプリでも、Claude Agent SDK の subagent や OpenAI Agents SDK の handoff、あるいは LangGraph のサブグラフで組めます。

1. 生成エージェントの出力（diff / PR） を、N 個の reviewer エージェントに並列配信。各 reviewer は { verdict: "pass" | "fail", reasons: string[] } 形式で返す。
2. 全 reviewer が pass なら merge gate へ。1 つでも fail なら、その理由を生成エージェントの context に戻して再生成。これを最大 N 回ループ（無限ループ防止に上限）。
3. 上限に達しても合格しない、または reviewer 同士の見解が割れた場合は、人間にエスカレーション。これが Behavioral ガードレールの「人間承認」フックと接続する。

類似パターンとの位置付け：Anthropic の planner / generator / evaluator 三エージェント harness（5〜15 反復で「retro game maker」を $200 で生成）も同じ系列で、evaluator が Ralph Wiggum の reviewer 役。Cursor / Vercel の自動レビュー機能、GitHub Copilot Code Review も同じ思想の製品化。「生成と評価を別エージェントに分ける」 という原則が、agent-to-agent 全般の核です。

本番 trace を eval dataset に戻す

本番運用の trace は最良の eval データセットです。次の条件に該当する trace を毎週 eval dataset へ自動投入する scheduled job を組みます。

• ユーザーが「これは違う」とフィードバックした trace（UI フィードバックボタン経由）
• kill switch / 人間承認エスカレが発火した trace（harness 側から自動でタグ付け）
• 高コストになった trace（ループ上限・トークン上限に達したもの）
• 長時間化した trace（clock time の p95 を超えたもの）

Anthropic Engineering の Demystifying evals for AI agentsも同じパターンを推奨。リリース時は shadow（並走計測のみ） → canary（10%） → 全展開 の 3 段で出すのが安全です。

06.「太らせ派 vs 痩せ派」の哲学的対立

Harness の作り方には、2025-2026 にかけて 2 つの哲学が見えてきています。どちらが正解かは決着しておらず、組織サイズと用途で選びます。

補助的に Anthropic 自身が「every component in a harness encodes an assumption about what the model can't do on its own」と表現しており、「モデルが進化したら harness を剥がせ」というメッセージを残しています。モデルが強くなるほど harness は痩せる方向に動く、というのが両派の合意点です。

07.よくある批判と応答：「新しい名前を付けただけ」なのか

この章では、よくある批判①「構成要素は以前からある技術ではないか」と、よくある疑問②「人によって指す範囲が違うのではないか」を分けて扱います。前者は部品の新しさと運用の変化を、後者はエージェントを作る側と使う側の違いを切り分けると整理できます。

批判への応答：違いは自律的に完遂できるか

この批判は半分正しい、というのが本記事の立場です。構成要素が以前から使われてきた技術である点は、批判の通りです。 OpenAI の公式記事が述べるのも新技術の発明ではなく、「discipline shows up more in the scaffolding rather than the code」という規律の置き場所がコードからエージェントの実行構築へ移ったという変化です。

違いを生むのは、lint やテストが存在することではなく、エージェントがそれらを読み、合否を判断し、修正して次へ進めることです。そのためには、次の 3 つを一つの実行基盤として接続する必要があります。

1. 何が正解かを機械可読な形で与える（意図の明示と verify scorer）
2. 暴走と漏洩を止めるガードレールを渡す
3. 最後まで仕事を完遂できる Sandbox を渡す

Sandbox はエージェントを本番環境から隔離し、必要な権限だけを与える実行環境です。エージェントはその範囲で、人間が操作するときと同じように情報を読み、ツールを使い、結果を確かめ、失敗を修正できます。ハーネスエンジニアリングのポイントは、ガードレールで安全性を保ちながら、この自律性をどこまで高めて仕事の完遂につなげるかにあります。

この差は、名称だけの議論ではありません。一次情報では、読み手、工数の配分、実行環境、評価条件に次の変化が確認できます。

ハーネスエンジニアリングは、新技術の名称というより、エンジニアの規律と工数が、コードを書く作業から実行環境・意図・検証の設計へ移っている変化を表す言葉です。呼び名に抵抗がある場合も、名称を使わずに 環境・意図・フィードバックループの設計 だけを実務に取り入れられます。

弊社が描く次の段階：評価関数で品質を管理する

弊社がハーネスエンジニアリングの先にイメージしているのは、アルゴリズムで成果物をスコアリング（点数化）する評価関数（成果物の品質を合否や数値で判定する仕組み）を設け、エージェントの仕事の品質を継続的に管理する世界です。テスト、lint、eval、業務上の成果指標を判定材料に使い、基準に届かなければエージェント自身が修正と再評価を繰り返します。

ハーネスエンジニアリングは、この循環を支える実行環境、権限管理、観測、評価基盤を整える、エージェントのためのインフラづくりだと弊社は考えています。人間は評価基準の設計と例外時の判断を担い、すべての成果物を一件ずつ確認する運用から、評価の仕組みそのものを管理する運用へ比重を移していきます。

指す内容が人によって違うという疑問への応答

指す内容が人によって違うのは、エージェントを「作る側」と「使う側」で設計対象が異なるためです。エージェント本体の制御構造を組む話と、AGENTS.md や権限、CI を整えて既製エージェントを使う話を、次の 2 系統に分けると整理できます。

OpenAI の Lopopolo 氏の記事は Codex を使う側のユーザーハーネスが中心です。一方、 Anthropic の三エージェント構成は作る側のビルダーハーネスにあたります。 Böckeler 氏の論考も、対象を「使う側が組む外側のハーネス」に限定しています。議論では、どちらの系統を指しているかを先に確認すると混同を避けられます。

08.よくある質問（FAQ）

09.まとめ

ハーネスエンジニアリングは、OpenAI が 2026 年 2 月に公式記事で表題に掲げ、Anthropic / Microsoft / xAI / Block などの一次ソースでも関連する harness 概念が広がっている開発手法です。「エンジニアの仕事は、コードを書くことから『環境を設計し、意図を明示し、フィードバックループを構築する』ことに変わる」という考え方で、scaffolding ・ガードレール ・CI を組んでエージェントを支えます。OpenAI Lopopolo の「Humans steer. Agents execute.（人間は舵を取り、エージェントが実行する）」がスローガンで、「discipline shows up more in the scaffolding rather than the code（規律はコードよりも scaffolding にこそ現れる）」が骨子になっています。