エージェントが途中で止まる、同じミスを繰り返す主因は、モデル不足よりハーネスの欠落です。ハーネスは、モデル以外のループ、ツール、検証、権限です。同じ重みでも、LangChain 公式 は Terminal Bench 2.0 を 52.8% から 66.5%（+13.7ポイント）まで動かしたと報告しています。自然言語のルールだけでは、確率的に破られます。
📑目次
テクノロジーの現場では、プロンプトを追加する前に、現在の実行基盤が何を許可し、何を検証しているかを書き出す方が早いでしょう。読後の一手はこれです。
- 直近の失敗を1件選ぶ
- Guide（作業前のルール）か Sensor（作業後の機械的チェック）のどちら不足かを判定する
- 1つ足す
指示とガードと検証の分け方は、エージェントLoopを安全に回すハーネス設計 と同じ層です。
ハーネスはモデル以外の実行基盤である
エージェントはモデル単体ではありません。モデルは推論を供給し、実リポジトリで仕事を終わらせるのは周辺ソフトウェアです。Agentic Dev は、ハーネスを次の要素と定義します。
- ループ
- ツール
- コンテキスト
- メモリ
- 回復
- ガードレール
信頼性の尺度とは、監督なしで正しい仕事を終えられるかどうかです。Claude CodeやCodex CLIは、そのハーネスの具体例です。
Copilot Studioのハーネスが決めること
Microsoft Learn の Copilot Studio では、ハーネスはビルダーが設計したエージェントとモデルの間のランタイムです。次を決めます。
- モデルをいつ呼ぶか
- どのコンポーネントを送るか
- 戻りをどう解釈するか
- どのツールを呼ぶか
GitHub Copilot、標準機能、Copilotチャットでは、スキル、メモリ、ファイル対応、回復、請求がそれぞれ異なります。チャットハーネスの公開先は内部チームです。同じ「エージェント」という言葉でも、許可範囲は製品ごとに大きく違います。
モデルを差し替える前に、今使っている実行基盤が何を許可し、何を検証しているかを書き出してください。書き出せない場合は、失敗の原因をモデルに帰さない方が安全です。選定会議でモデル名だけが議題になるなら、ハーネスの列が空だと言えます。
プロンプトとコンテキストの次に足す層
プロンプトは1ターンの指示、コンテキストは見える情報です。どちらもハーネスの内側にあります。劇場で言えば台詞と舞台装置であり、建物と防災設備がハーネスです。指示を磨いても、危険コマンドの遮断やテストの差し戻しがなければ、同じ失敗が繰り返されます。
入れ子の3層と常時ロード規約
HP Japan は、プロンプト、コンテキスト、ハーネスを対立ではなく入れ子として整理します。AGENTS.md や CLAUDE.md は常時ロードのプロジェクト規約です。
OpenAI は、次の運用を書いています。
- AGENTS.md を約100行の目次にする
- 本体知識は versioned な docs/ に置く
- 巨大マニュアルはすぐ腐る前提で短く保つ
Garry TanのCLAUDE.mdが約20,000行から約200行のポインタへ削られた例も、同じ方向性を示しています。
自然言語ルールは確率的に破られます。lint、テスト、rm -rf や DROP TABLE の遮断は、ハーネス層の機械的制御です。プロンプト追加より、常時ロードの短いポインタと機械的停止を先に足してください。
GuidesとSensorsで失敗を仕組みに変える
作業前のGuides（feedforward）と作業後のSensors（feedback）は、両方とも必要です。
- Guides だけだと結果を確認できません
- Sensors だけだと同じ間違いを繰り返します
computationalとinferentialを分ける
Birgitta Böckeler（Martin Fowler、2026年4月2日） は、制御を次の2種に分けます。
- computational: lint、型、テスト。ミリ秒〜秒、決定的
- inferential: LLMレビュー。高コスト、非決定的
誤診断、過剰実装、指示の取り違えは、センサーでは確実に捕まりません。仕様が無い正しさは人間確認です。
GIGAZINE（2026年8月28日） は、同じミスをその場のチャット修正で終わらせず、ハーネス自体を改善すると整理します。Addy Osmani / O’Reilly（2026年5月15日） は、実失敗だけを次へ落とすラチェットを推奨します。
- AGENTS.md の行
- precommit フック
推測ルールは足しません。良い AGENTS.md の各行は、特定の失敗に辿れる必要があります。
セッションをまたぐ長時間タスク
長時間タスクでは、セッションをまたぐ仕組みが要ります。Anthropic は、次の手順を置きます。
- initializer が
feature_list.json（passes:false）とinit.sh/claude-progress.txtを置く - 後続セッションは1機能ずつ進める
- 開始時にブラウザ E2E を走らせる
制約もあります。Puppeteer MCPはブラウザネイティブのalertを見られないため、その系統の失敗は残りやすいです。センサーが完了を証明できない領域は、完了扱いにしないでください。
テストをエージェント自身が書く場合、センサーが握り潰されるリスクは別問題です。実装と検証の分離は、AIコーディングエージェントのテスト改ざんを防ぐ記事 と重なります。繰り返した失敗を1件選び、Guide 不足か Sensor 不足かを判定して、1つだけ足してください。
同じモデルでもハーネスでスコアが動く
重みを変えずにハーネスだけを変えて順位が動いたという報告もあります。モデル待ちを第一手としない、という読みです。数字は条件付きです。自リポジトリの失敗ログに置き換えて読んでください。
公開数字は条件付きで読む
| 報告 | 固定したもの | 変えたもの | 数値 | 読み方の注意 |
|---|---|---|---|---|
| LangChain deepagents-cli | gpt-5.2-codex | プロンプト・ツール・middleware | Terminal Bench 2.0 52.8%→66.5%（+13.7pt）。Top30圏外→Top5 | 公式。89タスク。xhigh のみは 53.9%（タイムアウト）。Claude では同じ改善ループを回していない |
| HumanLayer / Osmani 引用 | Claude Opus 4.6 | ハーネス | Claude Code 約33位 → 別ハーネスで5位 | 二次引用。順位はリーダーボード時点に依存 |
| BSWEN（HP経由） | 同一モデル重み | scaffold | SWE-Bench Pro 38%→60%（22pt） | 公式論文ではなくブログ整理 |
出典（2026年9月時点）:
- LangChain（Improving Deep Agents with harness engineering）
- O’Reilly Radar（Agent Harness Engineering）
- HP Japan Tech&Device
LangChain公式が書いた手順
LangChain公式が書いた手順は簡潔です。
- トレースから失敗を集計する
- 完了前に検証を差し込む（PreCompletionChecklistMiddleware）
- 起動時に環境マップを注入する（LocalContextMiddleware）
- 同一ファイルへの編集回数で方針見直しを促す（LoopDetectionMiddleware）
よくある失敗は、解を書いたあと自分のコードを読み直し、テストなしで止まることです。直し方は次の通りです。
- 計画する
- テスト付きで作る
- タスク仕様と照合する
- 直す
xhigh だけを回すと 53.9% まで落ち、タイムアウトが理由です。high では 63.6% です。推論強度はハーネス変数です。
OpenAI社内実験は参考スケール
OpenAI の社内実験 は参考スケールです。手書き0行、約100万行、約1,500 PR、当初3名で 3.5 PR/人/日。金曜の20%をスロップ掃除に使っていた時期もあります。一般化は限定です。同じ投資なしに、同じ数字は出ません。
テクノロジー現場で最初に足す制御を決めるチェックリスト
全部を一度に作らないでください。観察した失敗に対して、機械的に止められるものから足します。差別化は、成熟ハーネスの上のパターン、スキル、レビュー、ゲート側です。合格基準の置き方は、社内AIエージェントのSkillsとEval設計 と接続します。
- 直近1ヶ月の失敗を10件書き出す（指示無視、目的喪失、同一エラー反復、完了嘘、危険コマンド）
- 各件を Guide不足 / Sensor不足 / 人間承認不足 に分類する
- Sensor 候補: テスト未通過なら完了禁止、lint 失敗でブロック、
rm -rfとDROP TABLEをハーネス層で拒否する - Guide 候補: AGENTS.md / CLAUDE.md を短いポインタ（目安100〜200行）に削り、詳細は docs/ へ移す
- 人間承認: 本番デプロイ、顧客メール、高額決済、共有ファイル削除の前に止める
- 長時間タスクなら feature list、progress ファイル、セッション開始時の E2E を足す
- 新しい失敗が出たらラチェットで1行追加する。実失敗が無いルールは足さない
Copilot Studioを使う場合の選択も、失敗の種類に合わせて行います。
- 多段階業務とファイル編集は GitHub Copilot ハーネス
- FAQ・定型は標準
- Microsoft 365 Chat 拡張はチャットハーネス
請求と公開範囲が変わります。来週レビューする項目は、「今月追加したSensorが実際に発火したか」です。発火ゼロなら、検知不足を疑ってください。テクノロジー運用の改善幅は、モデル世代ではなく、実際に発火したセンサー件数で測ってください。
よくある質問
Q1. プロンプトを長くすればハーネスは不要ですか？
不要ではありません。自然言語ルールは確率的に破られます。lint とテストが完了ゲートになります。
Q2. AGENTS.md に全部書けばよいですか？
いいえ。OpenAI は約100行の目次を推奨します。約20,000行まで膨らんだ例は、約200行のポインタへ削られました。
Q3. 公式の +13.7ポイントを、自チームの改善幅と思ってよいですか？
いいえ。Terminal Bench 2.0、gpt-5.2-codex、deepagents-cli の条件付きです。自リポジトリでは失敗分類から始めてください。
Q4. ユーザーが欲しい機能かどうかも、センサーで保証できますか？
できません。Böckeler は Behaviour を仕様＋テスト＋人手確認とし、意図の正しさはセンサー外と述べます。
Q5. 自前ハーネスをゼロから書くべきですか？
多くのチームは成熟ハーネスの採用が先です。Agentic Dev もその立場です。差別化はパターン、スキル、レビュー、ゲート側です。
Q6. Copilot Studio ならどれを選べばよいですか？
長時間の推論とファイル処理は GitHub Copilot、予測可能なルール会話は標準、社内 Microsoft 365 Chat 拡張はチャットです。請求が違います。
関連記事:
まとめ
ハーネスはモデル以外の実行基盤です。プロンプトとコンテキストの次に足す層です。Guides と Sensors を対で置き、実失敗だけをルールとフックに落とします。同じモデルでもベンチが動く公式数字はありますが、条件付きです。自チームは失敗10件の分類から始めてください。
次の一手は、繰り返している失敗1件を選び、Guide か Sensor を1つ追加し、来週そのセンサーが発火したかを見ることです。発火しなければ、ルール文ではなく検知を直してください。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す