Harness Engineering — なぜ AI が間違えたときシステムを問うべきか

直感に反する結論

LangChain がある実験を行った。モデルを固定したまま、まわりのインフラだけを変えたところ、Terminal Bench 2.0 のスコアが 52.8 から 66.5 に跳ね上がった。モデルもプロンプト技術も few-shot も変えていない。

この数字が指し示すのは直感に反する結論だ：AI コーディングエージェントの品質ボトルネックは往々にしてモデルそのものではなく、モデルを取り巻く周辺システムにある。

2026年2月、OpenAI が Harness Engineering という記事を発表した。あるチームが Codex で100万行を書き、人間が一行も書かなかった実験を描いている。同年4月、Martin Fowler が体系的な分析を書いた。Anthropic は長時間稼働エージェントのエンジニアリングレポートを三本連発した。CMU と Amazon のサーベイ論文は170以上のオープンソースプロジェクトを整理した。新しい用語が三ヶ月の間に散発的な議論から工学分野に結晶した。

Harness、本来の意味は馬具だ。手綱、鞍、銜（はみ）、力はあるが方向感覚の弱い馬を正しい方向に導く。AI は馬で、Harness がそのために構築する制御システム全体だ。

三層の進化

Harness Engineering は突然出現したわけではない。AI 工程方法論の三段階進化の最新層だ。

第一段階は Prompt Engineering で、制御対象は指示の言葉遣いだ。失敗モードは指示の不明瞭さで、時間境界は単一の会話ターン。第二段階は Context Engineering で、Andrej Karpathy が2025年末に理論化した。制御対象はトークンの選択、並べ替え、圧縮だ。失敗モードはコンテキスト内の情報の誤りや欠落で、適用範囲は一つのコンテキストウィンドウだ。第三段階は Harness Engineering で、制御対象はツールオーケストレーション、状態永続化、検証ループ、エラーリカバリだ。失敗モードは無限ループ、複数セッション間での一貫性喪失、安全でない操作で、適用範囲はタスクライフサイクル全体だ。

三層は入れ子関係だ。Phil Schmid の比喩が最も直接的だ：モデルは CPU で、Harness は OS だ。CPU がどれだけ優秀でも OS がダメなら意味がない。mtrajan の区別はさらに明確だ：Context Engineering は「エージェントに何を見せるか」を管理し、Harness Engineering は「システムがどう崩壊を防ぎ、どう定量化し、どう修復するか」を管理する。

フィードフォワードとフィードバック

Martin Fowler のフレームワークは現時点で最も明確な分析ツールだ。彼は Harness を二層に分ける：Guides と Sensors。

Guides はフィードフォワード制御で、エージェントが行動する前に導く。AGENTS.md、Skills、設計ドキュメント、LSP、codemod が含まれる。目標は最初の試行で正しくできる確率を高めることだ。Sensors はフィードバック制御で、エージェントが行動した後に観察し修正する。テスト、構造チェック、カスタム linter、レビューエージェントが含まれる。目標はエージェントに自己修正させることだ。

両方が揃って完全な Harness になる。フィードバックだけだと、エージェントは同じミスを繰り返す。行動前に予防するメカニズムがないからだ。フィードフォワードだけだと、エージェントはルールが有効だったかどうかを知らない。行動後に検証するメカニズムがないからだ。

この二つの次元に実行タイプを重ねると四象限が形成される。Computational guides は確定的ツールで、LSP や codemod が該当する。Inferential guides は推論を要するコンテンツで、AGENTS.md や設計ドキュメントが該当する。Computational sensors は確定的チェックで、テストと静的解析が該当する。Inferential sensors は判断を要する検証で、レビューエージェントや AI ジャッジが該当する。

Fowler はさらに三つの調節次元を提示する。Maintainability harness はコードスタイルと複雑さの制限に関心を持ち、最も実現しやすく、業界には成熟したツールが大量にある。Architecture fitness harness はモジュール境界と依存方向が正しいことを保証する。Behaviour harness は機能動作が期待通りかを検証する。これが現在最も難しく、まだ完全には解決されていない領域だ。

彼の核心的な洞察は：良い Harness は人間の介入を排除するのではなく、人間の注意力を最も重要な場所に導くことだ。

なぜ Harness の設計品質にこれほど差があるのか

最近ある視点が提唱された：research と engineering は二つのスキルではなく、同じ能力の二つの表現だ。フロンティア AI ラボの文脈では、この能力は不確実な環境で有用な抽象を構築する力だ。

教育体系は既に答えがある環境で働く人を訓練する。教科書は答えを知り、教授は答えを知り、面接官は通常答えを知っている。フロンティアラボの作業環境はまったく異なる。どのアーキテクチャ判断が五年後に当然と思われるか、どのボトルネックが根本的か、どの能力が欠けているかを知る者はいない。

Research のアウトプットは論文ではなく、「確実性が欠如している状況でも前進できる」能力だ。Engineering の核心も同様にコーディング速度ではなく、複雑なシステムの中で圧縮モデルを構築する能力だ。現代の AI インフラは機械というより都市に似ている。新しい区画が不断に建設され、古い道路は依存関係のために残され、異なる人が異なる街区を理解している。完全な地図を持つ者はいない。理解は分散しており、課題はもはや各詳細を学ぶことではなく、有用な抽象を構築することだ。

これが、同じように harness を構築するのに、ある人は linter ルールを数条加えるだけでエージェントを安定稼働させられるのに、ある人は大量のチェックを書いても効果が薄い理由を説明する。前者は不完全な情報の中で影響力の大きいポイントを素早く見つける人で、後者はすべての可能性の前で止まれなくなる人だ。 Herbert Simon の bounded rationality が正確に述べている：専門家の能力はすべての可能性を考慮することではなく、大部分の可能性を捨てながら重要なものを残すことだ。

Harness そのものが一種の抽象だ。「エージェントが犯しうるすべてのミス」を「いくつかの不変量とチェックルール」に圧縮し、有限の制約で無限の失敗モードをカバーする。良い harness 設計者は本質的に研究者がやっていることをしている：不確実性の中で投資に値する方向を特定し、最小の構造で最大のリスクを縛り上げる。

OpenAI の実践

OpenAI の100万行実験は最も具体的な一次証拠を提供する。Ryan Lopopolo は記事でこう書いている：エンジニアの仕事はコードを書くことから、環境を設計し、意図を指定し、フィードバックループを構築することに変わった。

彼らはいくつかの重要な設計判断を行った。

第一に、実装を微管理するのではなく不変量を強制する。各ビジネスドメインは固定レイヤーに分けられ、依存方向が厳密に検証される。コードはレイヤー内で「前方」にのみ依存し、ドメイン間は単一インターフェースで接続する。この制約はカスタム linter と構造テストで機械的に執行される。

第二に、linter のエラーメッセージをエージェントへの修復指示として直接注入する。これは「ポジティブプロンプトインジェクション」と呼ばれ、確定的チェックの出力を LLM フレンドリーにする。

第三に、リポジトリ知識がシステムの真実源だ。実行計画、技術負債、品質スコアはすべてリポジトリの一等市民だ。Slack の議論で合意されたアーキテクチャがリポジトリに書き込まれなければ、エージェントにとっては三ヶ月後に入社した新入社員と同じように見えない。

第四に、「退屈な」技術を選ぶ。 composability が良く、API が安定し、学習データセットのカバレッジが高い技術は、エージェントがモデリングしやすい。彼らは map-with-concurrency ツールを自ら実装した。汎用的な p-limit スタイルのパッケージが OpenTelemetry インフラと深く統合できなかったからだ。

第五に、定期的ガベージコレクション。コーディングの「黄金原則」をリポジトリにコード化し、定期的なクリーンアッププロセスを確立する。エージェントにドリフトをスキャンさせ修復を提案させる。

これらの制約は制限ではなく、速度の前提だ。Fowler の言葉通り：「実装を微管理するのではなく不変量を強制することで、基盤を壊さずにエージェントに素早く納品させる。」

Anthropic の長時間稼働方案

Anthropic が取り組む問題は異なる。エージェントに複数のコンテキストウィンドウにわたって数日間連続稼働させる必要がある。

彼らは二つの重要な失敗モードを発見した。第一は context anxiety だ：モデルがコンテキストウィンドウの残り少なさを感知すると、能動的に早めにまとめようとし、不完全な出力をサイレントに返す。エラーシグナルを生成しないため、発見が極めて難しい。第二は一度にやりすぎだ：エージェントはプロジェクト全体を one-shot しようとする傾向があり、コンテキストが枯渇したときに機能が半端になり、次のセッションは前のエージェントが何をやったかを推測するところから始まる必要がある。

解決策は三エージェントアーキテクチャだ。Planner がプロダクト仕様を機能リストに分解する。Generator が毎回一つの機能だけを担当し、スプリントモードで推進する。Evaluator が Playwright で実際にアプリケーションを操作して動作を検証する。

Generator と Evaluator は各スプリント前に「完了契約」を交渉し、具体的な実装詳細とテスト可能な動作を定義する。ファイル通信で、一つが書き、もう一つが読み、共有コンテキストを使わない。これによりマルチエージェント協調におけるコンテキスト汚染の問題を回避する。

Context reset は compaction よりも効果的だ。コンテキストウィンドウを完全にクリアして新しいエージェントを起動し、構造化された引継ぎファイルと組み合わせる。Anthropic は Sonnet 4.5 の context anxiety が compaction では対処できないほど強く、context reset が必須であることを発見した。後に Opus 4.5 がこの問題を大幅に緩和し、reset を取り消すことができた。

中国語コミュニティの導入

中国語コミュニティの議論は工学的な導入に集中している。

テンセントクラウド開発者コミュニティの万字長文は Harness を九つのコンポーネントに分解した：設計仕様ドキュメント、Rule、Skill、Sub Agent、Workflow、Scripts、dev-map、タスク看板、MCP。核心的な視点は、Harness Engineering は AI をより賢くするのではなく、AI をその場の思いつきで動くモデルから、制約可能、協調可能、検証可能な実行システムに変えることだ。

複数の独立した情報源の交差比較から、六つのコンセンサスと三つの空白エリアを整理した。コンセンサスにはインフラがボトルネック、ドキュメントは生きているべき、思考と実行の分離、コンテキストは多ければ多いほど良いわけではない、制約は自動化必須、エンジニアの役割が変化している、が含まれる。空白エリアはブラウンフィールドプロジェクトの改造、機能検証体系、AI コードの長期保守性だ。

iDao の実践記事が最も直接的で、五段階の増分構築パスを示している：AGENTS.md → docs/ → Linter+CI → Verify Loop → GC。その中で三層検証メカニズムは記録に値する：verify.py が lint + type + arch + tests を実行し、失敗後最大三回修復し、三回失敗したら人間にエスカレーションする。この「三回ルール」は実際の教訓から来ており、あるエージェントが同じテストを47回連続でリトライしたことがある。

SegmentFault の中国語サーベイは用語の進化の完全なタイムラインを提供し、Karpathy の Context Engineering から Hashimoto が Harness Engineering の用語を提唱し、Fowler の体系的分析に至るまでを網羅している。

日本語コミュニティの独自視点

日本語コミュニティは英語コミュニティであまり議論されない二つの角度を提供した。

Zenn の記事『ハーネスエンジニアリングでハーネスをつける対象は、AI？ いいえ、あなたです。』は Harness の対象を AI から人間に拡張した。核心的な論点は：AI に整備した Harness は同時に人間のオンボーディングコストも下げるということだ。ドキュメントに「SQL インジェクション対策は必須」と書いてあれば、AI は忘れないし、新しく入ったエンジニアも一読で理解できる。Harness は AI にだけつけるのではなく、まだ十分に強くないエンジニアにもつけるのだ。

Wantedly エンジニアリングブログの実践記事は LLM 自身を guardrail として使う設計を紹介している。Self-consistency（複数回サンプリングして一致結果を採用）で LLM の確率的揺らぎを吸収し、Exponential backoff + Full Jitter で API 通信の安定性を保証する。人間がエッジケースを審査した後、具体的な例を few-shot としてプロンプトに加え、判定精度を持続的に向上させる。

Qiita の実践ガイドは Harness Engineering を十の要点に精錬し、プロジェクトルールファイルの設計からコードベースの設計まで、各要点に具体的な実装方法を添えている。中でもルールファイルに関するアドバイスが最も実用的だ：各行について「この行を削除したらエージェントはミスするか？」を問い、しなければ削除する。重要なルールは IMPORTANT または YOU MUST を使って強調すると、エージェントの遵守率が明らかに向上する。

交差検証

検索結果の間には大量の交差検証が存在する。

LangChain の実験データはほぼすべての記事に引用されており、52.8 → 66.5 という数字は Harness Engineering の論証力において最も強力な単一証拠となっている。OpenAI の100万行実験も同様に広く引用されているが、異なるソースで強調する細部が異なる：OpenAI の原文はアーキテクチャ制約と不変量を強調し、転載記事は「人間が一行もコードを書かなかった」のドラマティックさをより強調する。

Anthropic の context anxiety の発見は複数のソースで独立検証されている。iDao の記事がエージェントの47回連続リトライに言及しており、Anthropic の記述する「一度にやりすぎ」モードと一致する。Wantedly の Self-consistency 方案は、LLM の確率的揺らぎが Harness が処理すべき核心問題であることを別方向から検証している。

Fowler の Guides + Sensors フレームワークはすべての英語・中国語分析記事で基礎分析ツールとして引用されている。しかし中国語コミュニティはこれにさらに多くのコンポーネント分類を追加しており、テンセントクラウド記事の九コンポーネントモデルは Fowler の四象限より細粒度で、実際の工学的導入により適している。

注目に値するのは、日本語コミュニティの「Harness は人間にもつける」という視点が英語・中国語コミュニティではほとんど議論されていないことだ。これは日本のソフトウェアエンジニアリング文化における「できる人材」育成への持続的な不安を反映しているかもしれない。

操作可能な結論

Harness Engineering の核心的な論点は一文に圧縮できる：モデルがミスを犯したとき、まずそのミスを犯すことをシステムがなぜ許したのかを問う。

この問いの優先度はモデルの交換、プロンプトの調整、few-shot の追加よりも高い。理由はシンプルだ。モデルは確率システムで、ミスは必然だ。Harness の価値はミスが人間に到達する前に捕捉・修正させることにある。

Mitchell Hashimoto の言葉が最も正確だ：「エージェントがミスを犯したとき、次回はうまくやるだろうと願うだけではだめだ。同じミスを二度と繰り返さない仕組みを設計する時間を投資すべきだ。」

AI コーディングエージェントを構築・使用しているなら、Fowler のフレームワークは良い出発点だ。Guides が完全か、Sensors が揃っているか、両方がクローズドループを形成しているかを確認しよう。エージェントが同じミスを繰り返すなら、最初の一度はモデルの問題、二度目はシステムの問題だ。

Research は不確実性を圧縮し、Engineering は複雑さを圧縮する。フロンティア AI ラボでは両者に向かう能力は同じだ：不完全な地図上で正しい方向を見つける力。知識そのものがますます安くなり、コード生成がますます安くなる中で、唯一希少なのは注意力を向けるに値するものを判断する力だ。harness engineering がこの時期に顕学となったのは、まさにこの判断力を再利用可能で検証可能なシステム構造にコード化するからだ。

One More Thing

今回の調査で見つけた核心文献のインデックスを整理した。今後の参照に役立ててほしい。

OpenAI: Harness engineering: leveraging Codex in an agent-first world Martin Fowler: Harness engineering for coding agent users Anthropic: Effective harnesses for long-running agents Anthropic: Harness design for long-running application development LangChain: Improving Deep Agents with harness engineering CMU/Amazon: Agent Harness Engineering: A Survey Mitchell Hashimoto 原始定義: Lysander の整理