ハーネスエンジニアリングとは何か——実務では何を置くのか¶
対象 / ポイント
対象: ハーネスエンジニアリングという言葉を見聞きしているが定義が曖昧に感じている開発者。「で、現場では結局何をすればいいのか」を知りたい読者。
ポイント:
- ハーネスは「AIレビューのこと」でも「lintのこと」でもない。AIを安定して働かせるために、制約・情報・検証・回復・レビューをどう組み合わせるかの設計
- 一次ソースに立ち返ると、LLMベースのレビュー層もサブエージェントもハーネスの構成要素として扱われている
- 層を積むほど再現性・制御性・検証性が上がる。自分の現場でどこまで積むかを判断するための整理を提供
ハーネスエンジニアリングが曖昧に見える理由¶
ここ数か月で「ハーネスエンジニアリング」という言葉が急速に広まった123。同時に、この語が指す範囲が人によってかなり違う。AGENTS.mdを書くことをハーネスと呼ぶ人もいれば、AIにAIをレビューさせることをハーネスと呼ぶ人もいるし、lint / test / contractの必須通過をハーネスと呼ぶ人もいる。
曖昧に見えるのは、どれも部分的には正しいが、指している層が違うからである。ハーネスは単一のツールや手法ではなく、複数の層からなる設計であり、どの層を指して語っているかが人によって異なる。本記事では、一次ソースに立ち返った上で各層を分解し、現場で何を置けばよいかまで落とす。
本サイトでも概要記事やレビューループ実装ガイドを公開してきたが、議論を重ねる中で整理を更新する必要が出てきた。本記事はその更新版にあたる。
ハーネスの中核定義——提唱者たちは何を言っているか¶
Mitchell Hashimotoのアプローチは「エージェントがミスをしたら、そのミスを二度と起こさないように仕組みで防ぐ」1。手段としてAGENTS.mdの更新（implicit prompting）と専用ツールの整備（programmed tools）の両方を挙げており、決定論的ツールに限定していない。
OpenAI Codexチームは、Codexに自己レビューと追加のagent reviewsをさせ、review・validation・feedback handling・recoveryをシステムに埋め込んでいると報告している2。さらに、custom linters、structural tests、taste invariantsを機械的に強制するアーキテクチャ制約を併用している。
Birgitta BöckelerはOpenAIのハーネス構成を分析し、「deterministic and LLM-based approaches」の混在を明示した3。同時に、機能や振る舞いのverificationが相対的に弱い点も指摘しており、検証層の重要性を裏付けている。
共通点はこうなる。ハーネスとは、モデルの外側にある、モデルを安定して有効に機能させるためのシステム設計すべてである。 リンターも、AGENTS.mdも、AIレビュー層も含まれる。LangChainの「Agent = Model + Harness」4という整理もこの方向と一致する。
先進事例はハーネスをどう広げているか¶
一次ソースが示す中核定義に加えて、先進事例がハーネスの実装をさらに広げている。
Anthropicの直近のエンジニアリングブログでは、planner・generator・evaluatorの3エージェント構成を「ハーネス設計」と呼んでいる5。evaluatorはLLMだが、事前定義した評価基準にハードしきい値を設定し、Playwright MCPで実アプリを操作して採点する。
注目すべきは、evaluatorの初期状態では「問題を見つけても自己判断で承認してしまう」傾向があり、チューニングで初めて安定した品質判定に到達したという報告である5。LLMレビュー層はハーネスの構成要素だが、検証の仕組みとの組み合わせで安定性が大きく変わることを示している。
HumanLayerはハーネスのレバーとして、system prompt、tools / MCPs、context、sub-agents、hooks、skillsの6つを挙げている6。サブエージェントは確率的なLLMだが、ハーネスの正当なレバーとして位置づけられている。
実務では何を置くのか——5つの層¶
一次ソースの議論を踏まえた上で、ここからはハーネスの構成要素を実務の観点で5層に分解する。
┌─────────────────────────────────────────────────────────────┐
│ ① 制約の層 │
│ │
│ 禁止事項、権限、触ってよいファイル/ディレクトリの範囲 │
│ ネットワーク制限、サンドボックス設定 │
│ → エージェントが「やってはいけないこと」を構造的に防ぐ │
├─────────────────────────────────────────────────────────────┤
│ ② 情報の層 │
│ │
│ AGENTS.md / CLAUDE.md、設計方針、ADR、命名規約 │
│ 参照すべき仕様、コーディングガイドライン │
│ → エージェントに「何をすべきか」を伝える │
├─────────────────────────────────────────────────────────────┤
│ ③ 検証の層 │
│ │
│ lint / typecheck / test / contract / policy check │
│ Playwright等による実行環境での動作確認 │
│ → 同じ入力なら毎回同じ判定が返る。再現可能な合否基準 │
├─────────────────────────────────────────────────────────────┤
│ ④ 回復の層 │
│ │
│ rollback、再試行、差分限定、失敗時の打ち切り │
│ ループ回数上限、人間へのエスカレーション │
│ → 失敗したときに安全に戻れる仕組み │
├─────────────────────────────────────────────────────────────┤
│ ⑤ レビューの層 │
│ │
│ 実行AIとは別のAIによるレビュー / 人間レビュー │
│ 重大度分類（P0/P1/P2）、トリアージ │
│ → 実行側のバイアスを排除し、見落としを補完する │
└─────────────────────────────────────────────────────────────┘
どの層もハーネスの構成要素になり得る。ただし、複数層が組み合わさるほど、より強いハーネスになる。
各層の役割と限界¶
① 制約の層。 read-onlyサンドボックス、ファイルの編集範囲制限、ネットワーク遮断など。エージェントが「やってはいけないこと」を構造的に不可能にする。最も強制力が高いが、「何をすべきか」は伝えられない。
② 情報の層。 AGENTS.md、設計方針、コーディングガイドライン。エージェントに文脈を与える。Hashimotoが推奨するように、エージェントがミスするたびに更新することで暗黙知が徐々にコード化される1。ただし「ほぼ毎回」従うが「例外なく毎回」ではない。
③ 検証の層。 lint、test、typecheck、contract。同じ入力に対して毎回同じ判定を返す。モデルを入れ替えても結果が変わらない。合否の再現性を提供する。Böckelerが「機能や振る舞いのverificationが弱い」と指摘した部分3は、この層の不足を示している。
④ 回復の層。 ループ回数の上限、失敗時のrollback、人間へのエスカレーション。エージェントが想定外の状態に陥ったときに安全に戻す仕組み。これがないと、振り子問題（A→B→Aの修正ループ）や無限ループが止められない。
⑤ レビューの層。 実行AIとは別のAI、または人間によるレビュー。実行側のバイアスを排除し、人間の目に届く前にフィルタを入れる。指摘の重大度分類（P0: correctness / security、P1: maintainability、P2: style）を入れると、レビューの確率的なブレを構造化できる。
ここで有効な診断基準がある。レビュー担当モデルを別のものに入れ替えたとき、最終合否がほぼ同じになるか。 yesに近いなら③検証の層が効いている。noなら、③④を積む余地がある。
5層の分解は障害分析にも使える。エージェント起因の問題が起きたとき、どの層が破れたのかを特定する診断フレームとして機能する。「情報は渡していたが検証がなかった」「検証はあったが回復がなかった」——破れた層を特定すれば、次に積むべきものが決まる。
現場別の構成例¶
各層の特性が見えたところで、現場の規模や制約に応じてどう組み合わせるかを整理する。
個人開発の最小構成——まず②＋④¶
AGENTS.mdにプロジェクトの方針と禁止パターンを書く（②情報）。エージェントがミスしたら都度追記する。ループを回すなら上限回数を決めておく（④回復）。
これだけでも、エージェントの出力品質は目に見えて変わる。コストはほぼゼロ。すでにCI/CDにlintやtestがあるなら③検証も自然に入る。
次の層を足すトリガー: エージェントの出力を複数人が触るようになったら、①制約と③検証を足してチーム構成に移行する。
チーム開発の標準構成——①②③④¶
サンドボックスで編集範囲を制限する（①制約）。AGENTS.mdにコーディング規約と禁止パターンを書き、チームで共有する（②情報）。lint / test / typecheckを必須通過にする（③検証）。ループ上限を設定し、超えたら人間に判断を委ねる（④回復）。
⑤レビューの層は、人間のレビュー負荷が課題になった段階で導入する。OpenAIのCodexチームは、agent-to-agent reviewをほぼ人間レビューの代わりに回していた2。ただし、custom lintersやstructural testsと併用しており、レビュー層単独ではなく③検証の層と組み合わせている。
次の層を足すトリガー: エージェントの出力が顧客やプロダクションに直接影響するなら、⑤レビューと④回復の自動化を足して本番構成に移行する。
本番変更を伴う強い構成——5層すべて¶
仕様・禁止事項・受け入れ条件が事前に外部化されている（②情報＋③検証）。エージェントの実行はサンドボックス内に限定（①制約）。lint / test / contractが合否判定の中心で、AIレビューは論点抽出に限定（⑤レビュー→③検証への接続）。基準を下回ったら自動ロールバックまたは人間承認（④回復）。記録・再現・監査が可能。
Anthropicの直近のハーネス設計5はこの構成に近い。evaluatorが事前定義した基準にハードしきい値を持ち、Playwright MCPで操作して検証し、基準を下回ればスプリント不合格になる。
本サイトのレビューループ実装ガイドで紹介したSKILL.md方式は、ループ上限やread-onlyサンドボックスといった①④の要素を持つが、③検証が品質判定の中心にはなっていない。「チーム開発の標準構成」と「本番変更の強い構成」の間に位置する。
ハーネスの強さを測る3つの観点¶
自分のハーネスがどのくらい強いかを判断するには、以下の3軸が使える。
再現性。 同じ入力に対して、近い結果が得られるか。③検証の層が厚いほど再現性は上がる。レビューモデルを入れ替えても合否が大きく変わらないなら、再現性が高い。
制御性。 止め方、制限、権限が明確か。①制約の層と④回復の層がこれを担う。「エージェントが暴走したときにどうやって止めるか」に答えられるかが基準になる。
検証性。 良し悪しをモデルの外で判定できるか。③検証の層がこれを担う。lint / test / contractが合否判定の中心にあるほど検証性が高い。
おわりに¶
ハーネスエンジニアリングは「AIレビューのこと」でも「lintのこと」でもない。AIを安定して働かせるために、制約・情報・検証・回復・レビューをどう組み合わせるかの設計である。
どの層から始めてもよい。ただし、層を積むほど再現性・制御性・検証性が上がる。自分の現場で何が足りていないかを5層に当てはめて考えてみると、次に何を整備すべきかが見えてくる。
関連記事
本記事はハーネスエンジニアリングの概念整理シリーズの一部です。
- ハーネスエンジニアリングとは何か——コンテキストエンジニアリングの「外側」を定義する——初回の概要記事
- Claude Code × Codex レビューループ実装ガイド——⑤レビューの層の実装パターン集
- 仕様は残すな、接続しろ——③検証の層へのverification接続
Mitchell Hashimoto, "My AI Adoption Journey," mitchellh.com, February 5, 2026. https://mitchellh.com/writing/my-ai-adoption-journey ↩↩↩
Ryan Lopopolo, "Harness engineering: leveraging Codex in an agent-first world," OpenAI, February 11, 2026. https://openai.com/index/harness-engineering/ ↩↩↩
Birgitta Böckeler, "Harness Engineering," martinfowler.com, February 17, 2026. https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html ↩↩↩
LangChain, "The Anatomy of an Agent Harness," March 2026. https://blog.langchain.com/the-anatomy-of-an-agent-harness/ ↩
Prithvi Rajasekaran, "Harness design for long-running application development," Anthropic Engineering, March 24, 2026. https://www.anthropic.com/engineering/harness-design-long-running-apps ↩↩↩
HumanLayer, "Skill Issue: Harness Engineering for Coding Agents," March 2026. https://www.humanlayer.dev/blog/skill-issue-harness-engineering-for-coding-agents ↩