Harness Engineering モデルを待つのではなく、環境を設計する — AI行動制御の理念と実践
ハーネスとは、AIエージェントを取り巻く足場（Scaffolding）・制約（Constraints）・フィードバックループの総体。 Vexはこの規律を行政書類審査ドメインで実践し、高精度・高速・コスト最適化を安定的に同時達成した。
Harness Engineering とは
モデル自体を改善するのではなく、モデルの周囲の環境を設計することでAIエージェントの信頼性・再現性・品質を確保するエンジニアリング領域。リポジトリ構造、CI設定、ツール統合、権限制御、検証ループ — モデルの外側にあって挙動を安定させるインフラすべてがハーネスである。
◎3層構造 — 各層をタップ／ホバーOVERVIEW
プロンプト工学はコンテキスト工学に、コンテキスト工学はハーネス工学に包含される。 左の図の各層にカーソルを合わせると、その層が扱う対象と役割が表示されます。
🏗環境が能力を決める
エージェントの初期生産性が低い原因の多くは「モデルが無能」ではなく「環境が未整備（underspecified）」であること。
🔧失敗の修正はハーネス側
失敗時の対処は「try harder」ではなく、「どの能力が欠けているか、それをエージェントに可読・強制可能にするには何が要るか」を問う。
🧪仮定のストレステスト
ハーネスの各コンポーネントは「モデルにはこれができない」という仮定をエンコードする。仮定はモデル改善で陳腐化するため、定期的に検証・簡素化する。
🛡境界は中央で、自律は局所で
入出力の形・権限・資源上限は中央で強制し、その内側の解き方はエージェントに委ねる。
用語の系譜 — Test Harness から Harness Engineering へ
Test Harness（テストハーネス）
自動テストを実行するための環境・フレームワーク。ハーネス＝「対象を安定して動かすための装具」という語源。
Evaluation Harness（評価ハーネス）
EleutherAI の LM Evaluation Harness に代表される、LLMを統一的・再現可能に評価するフレームワーク。OpenAI Evals も同系譜。評価系ハーネスの前史。
Agent Harness（エージェントハーネス）
Claude Code、Codex CLI 等の「エージェントループ＋ツール実行＋状態管理」を提供するランタイムをharnessと呼ぶ用法が定着。Anthropicは2025年11月にengineering blogで長時間稼働エージェント向けハーネス設計を公開。
Harness Engineering として業界用語に
OpenAIがブログ「Harness engineering: leveraging Codex in an agent-first world」（2026-02-11公開）でこの領域を命名し、業界用語として定着した。
提唱元と大手企業の実運用事例
出典未確認の伝聞事例は排除し、OpenAI・Anthropic の一次資料（2026年7月時点でWeb検証済み）のみを掲載する。各カードのリンクから原典へ直接アクセスできる。
3名（後に7名）のエンジニアチームが、社内プロダクトを手動記述コード0行で構築・出荷。アプリケーションロジック・テスト・CI・ドキュメント・ツーリングを含むコードをCodexエージェントが生成した。
課題: エージェントは離散的なセッションで動作し、新しいセッションは直前の記憶を持たない。解決: 初回に環境・機能リスト・進捗管理を整備する initializer エージェントと、毎セッション漸進的に進捗し次セッションへ明確な成果物を残す coding エージェントの2段構成。構造化された引き継ぎ（feature list・gitコミット・テストゲート）をセッション間の状態として利用する。
環境・機能リスト整備（初回） → Coding Agent
毎セッション漸進＋成果物残置 → 構造化引き継ぎ
feature list / git / テストゲート
続報では planner / generator / evaluator の3エージェント構成により、複数時間の自律コーディングでフルスタックアプリを構築した。
Claude Agent SDK / Codex SDK / OpenAI Agents SDK など、「LLM API（補完を返す）」から「ハーネスAPI（ループ・ツール・コンテキスト管理・フック・サンドボックスを備えたランタイムを返す）」への移行が業界全体で進行している。一次資料・ツール・評価基盤はコミュニティのキュレーションリストに集約されつつある。
Harness Engineering の実装パターン
Vexが採用した5つの基本パターン。いずれもモデル非依存の設計層に実装され、モデル更新後もそのまま資産として継承される。
境界の中央強制（Guardrails）
ツール権限・資源上限・入出力スキーマを中央で強制し、境界内の自律性は保つ。コスト暴走・無限ループ・権限逸脱をアーキテクチャレベルで不可能にする。
ツール呼出制限（Tool Call Limitation）
呼出回数上限・タイムアウト・フォールバックにより、コスト予測可能性と安定動作を保証する。
2段階パイプライン（＋早期終了）
軽量な事前判定（Stage 1）で確定できるものは確定させ、詳細検証（Stage 2）は必要な場合のみ実行。処理時間とトークンの最適配分を実現する。
根拠提示（Citation & Evidence）
AI判定に引用元テキスト・ページ番号を必ず添付させ、ハルシネーションの検出コストを下げる。人間レビューの効率化と監査証跡を両立する。
構造化引き継ぎ・監査（Structured Handoff & Audit）
セッション/実行をまたぐ状態は構造化された成果物（DB・ログ・サマリ）として永続化し、事後調査と継続的改善を可能にする。
Vex ＝ ハーネスの上のハーネス
Vex自体が「Bedrock AgentCore Runtime + Strands SDK」というエージェントハーネスの上に、行政書類審査固有のハーネスコンポーネントを積み上げた構成である。
Vexにおける実践 — 実インシデントと対策
PoC期間中に実際に発生した暴走インシデントと、ハーネスによる構造的な封じ込め。各Issueへのリンクから一次記録を参照できる。
⚠ 問題 — 回数暴走
- AIが審査中に同じ調査を12回以上繰り返す暴走が発生
- 本来軽い処理のはずが、調査のたびに情報が蓄積し処理量が2.6倍（コストも2.6倍）に膨張
- 高性能モデルは1回で判定完了するが、軽量モデルは迷って暴走 — AIの性格差がコスト差に直結
✔ ハーネス対策 — ToolCallLimiter
- 回数リミッター: 各調査手段は1審査につき最大1回まで（自動制御）
- 上限に達したら調査を打ち切り、それまでの情報だけで結論を出す
- 暴走が起きたら自動で記録され、後から確認・分析可能
⚠ 問題 — 単発体積暴走（#90とは別機序）
- AIがファイル検索時にサーバ内の全ファイル（14,301件）を一度に読み込んでしまった
- 1項目の審査だけで約$7.5のコスト暴走 — 回数制限では防げない別タイプの問題
- 審査と無関係なシステムファイルまで読み込まれ、AIの誤判定も誘発
- 根本原因は5つの設定不備が重なったこと: 不要ツールの混入、検索範囲の制限なし、読取量の上限なし、制御対象からの漏れ、ファイル名の不一致
✔ ハーネス対策 — 三層防御
- 第1層（根本修正）: 不要なツールがAIに渡らないよう設定を修正
- 第2層（範囲制限）: 一度に読める量と検索できる範囲に上限を設定
- 第3層（許可リスト）: 審査対象の文書だけアクセス可能にし、それ以外は自動ブロック
- 補強: サーバ環境から不要ファイルを事前に除去
⚠ 問題 — 消える監査証跡
- 審査記録を削除すると、異常コストの原因調査が不可能に
- 参照元データが審査記録と一緒に消えてしまう設計
- 過去に発生した異常高額処理が「記録削除済みで確認不能」に
✔ ハーネス対策 — [ToolAudit] 構造化ログ
- AIの全操作を独立した監査ログに自動記録（審査ID・使用モデル・処理量・操作内容）
- ログは審査記録とは別に保存されるため、記録削除後も調査可能
- ログ1件あたりのコストは極めて小さく（1円未満）、常時記録しても負担にならない
🔁反復検証による精度確認（Evaluation）
3施設 × 3回実行 ＝ 9回の検証で再現性を測定。Opus 4.6: 97.4%／Sonnet 4.6: 94.3%（人手再検証）、ルールベースは3回とも完全一致（100%）。
⚡2段階審査パイプライン（早期終了）
Stage 1（Document Review）でpass判定なら Stage 2（RAG・Web検索によるツール検証）をスキップ。pass項目のツール実行ゼロによりトークン削減・処理時間短縮（詳細はChapter 5）。
📎Citation & Evidence（根拠提示）
参照元テキスト・ページ番号・参照ドキュメントリンクをAI判定に自動付与し、UI上でハイライト。目視での最終確認を効率化し、監査証跡化する（ハルシネーション対策として貴省報告済み）。
🔄コスト完全可視化 ＋ フィードバック閉ループ
全LLM呼出（リトライ含む）のトークン捕捉によりコスト管理誤差3.8%。人手override → 日次集計 → feedback_summary → 次回審査プロンプトへ注入する継続的改善基盤（Chapter 4.7）。
Vexでの実証成果 — Harness適用の効果
性能（速さ・安さ）だけでなく、安定性・監査性・再現性を同時に達成したことがハーネス適用の核心的成果である。
高精度 × 高速 × コスト最適化を「安定的に」同時達成
| 観点 | 成果 | 出典 |
|---|---|---|
| 精度 | Opus 4.6: 97.4% ／ Sonnet 4.6: 94.3%（人手再検証） | PoC精度検証（3施設×3回） |
| 再現性 | ルールベース: 3回とも一致率 100% | PoC精度検証 |
| 処理時間 | 平均約11分/ジョブ、モデル切替で平均 ▼72.0% | PoC性能測定 |
| トークン | 同一モデル・同一ジョブ前後比較で ▼75.7%（コスト ▼75.4%） | Chapter 5 |
| コスト管理 | 可視化誤差率 3.8% | 拡張機能実装報告書 |
| 暴走防止 | 回数暴走（2.6倍膨張）・体積暴走（2.4Mトークン/項目）を構造的に遮断 | Issue #90 / #124 / #126 |
| 監査性 | 削除済ジョブ含む全ツール呼出の永続証跡 | Issue #113 |
まとめ ＆ 参考文献・リンク
参考文献はすべて2026年7月時点でWeb検証済み。カードをクリックすると原典が新しいタブで開きます。
「モデルを待つ」のではなく「環境を設計する」
OpenAI・Anthropicの実運用が示す通り、エージェントの生産性と信頼性はハーネスの完成度で決まる。
行政書類審査ドメインでの実践
ツール呼出制限・三層防御・監査ログ・2段階パイプライン・根拠提示・フィードバック閉ループにより、高精度（97.4%）・高速（約11分）・コスト最適化（▼75%）を安定的に同時達成した。
ハーネスはモデル非依存の資産
各コンポーネントは「モデルができないこと」の仮定であり、モデル更新時には仮定を再検証して簡素化できる。削減ノウハウと安全機構は次のモデルにもそのまま継承される。