Harness_Engineering

PoCの壁を突破する「知能の設計図」 ハーネスエンジニアリング 原理原則 2026年最新論文と実証データに基づく、 AIエージェントの本番稼働に向けた体系的アプローチ。 うさうさ研修工房

優秀なモデルを採用したのに、 なぜPoCでつまずくのか？ 観測される事象 ・「タスクを完遂できない」 ・「途中でループに陥る」 ・「文脈を忘れる」 エンジニアの誤解 ・「プロンプトの工夫が足りない」 ・「もっとパラメータ数の多い、賢い モデルに変えなければ…」 真のボトルネック：問題は「脳（モデ ル）」の知能ではなく、それを動かす 「身体（実行基盤）」の設計にある。

パラダイムシフト：エージェントの形式的定義 Agent = φ (Base Model) ⊕ A (Harness / Scaffold) φ（推論器）：LLMなどの基盤モデル。 純粋な「思考」のエンジン。 A（足場・実行基盤）：モデルを“動くエージ ェント”にする周辺ソフト一式（制御プレーン）。 Anthropic社が「Scaffold（足場）」と呼ぶ領域。 性能を最終的に律速するのはモデル（φ）ではなく、ハーネス（A）である。

実証データ：ハーネスの変更のみで性能は「10倍」飛躍する データセット：SWE-bench（ソフトウェアエンジニアリングタスク） 68.3% PoC Target 6.7% 旧ハーネス 新ハーネス： Grok Code Fast 1 モデルは一切不変。編集ツール形式を 「str_replace」から「hashline」に変更 しただけで10倍の改善。（Boluk 2026） Additional Evidence • LangChain DeepAgents (TerminalBench): ハーネス変更のみで+26% (52.8% → 66.5%) • Meta-Harness (TerminalBench-2): ハーネスの自動最適化が手作業設計を上回る (76.4%)

ハーネスの6成分形式モデル：H = (E, T, C, S, L, V) S: 状態ストア (State) コア実行層 T: ツールレジストリ (Tools) E: 実行ループ (Execution) C: 文脈マネージャ (Context) V: 評価インタフェース (Evaluation) インフラ層 (Infrastructure) L: ライフサイクル・観測 (Lifecycle) 2026年のサーベイ(Meng et al.)に基づく形式化。介入も評価も、この6成分の単位で設計・整理する。

Core Execution：エージェントの「思考と行動」を制御する E（実行ループ - Execution) • 役割：観測 → 思考 → 行 動の反復サイクル。 • 設計要素：終了条件の定 義、エラーからの自律 的復旧（リカバリ）メカ ニズム。 T（ツールレジスト - Tools) • 役割：エージェントが外 部と介入するための「手 足」。 • 設計要素：型付きツール 群の管理、ルーティング、 厳格なスキーマ検証と監 視。 C（文脈マネージャ - Context) • 役割：コンテキストウィ ンドウ（短期記憶）の最適 化。 • 設計要素：窓に何を入れ るかの選別、情報の圧縮 (compaction)、効率的 な検索の仕組み。

Infrastructure：本番環境での「信頼性と再現性」を担保する S (状態ストア - State) • 役割：ターンやセッショ ンをまたぐ記憶の永続化。 • 設計要素：外部データベ ースとの連携、クラッ シュ時の確実な状態復 旧。 L (ライフサイクル - Lifecycle) • 役割：セキュリティと可 観測性 (Observability) の確保。 • 設計要素：認証、詳細な ロギング、ポリシーの強 制、計装 計装(instrumentation)。 V (評価インタフェース - Evaluation) • 役割：改善のためのフィ ードバックループ。 • 設計要素：行動軌跡（ト レース）の記録、中間状 態の抽出、客観的な成功 シグナルの定義。

トラブルシューティングの定石：5ステップ対応フロー 観測 (Observe)： トレース(L,V)を 用いてエー ジェントの行動 軌跡を完全に 可視化する。 切り分け (Isolate)： 問題がE/T/C/ S/L/Vのどの 成分に起因する かを特定する。 介入 (Intervene)： 該当する成分の コード・設定を 修正する。 評価 (Evaluate)： 評価ハーネス(V) で再計測し、回帰 (デグレード) がないか確認 する。 恒久化 (Permanence)： 個別の対応を システム規則や 新しいツールに 変換し、再発を システムレベル で防止する。

The Golden Rule of Intervention：介入の絶対的な優先順位 1. ハーネス (Harness) [最優先] 2. プロンプト (Prompt) [次点] 3. モデル (Model) [最終手段] E, T, C, S, L, Vの修正。 確実性が高く、コストが安い。 システムプロンプトの調整。 モデルの変更やファインチューニング。 コストが甚大で、改善効果が不確実。 「モデル変更は最後の手段。必ず安価で確実なハーネス側の修正から着手すること。」

アーキテクチャ比較マトリクス：目的に応じた6つの設計類型 Pattern Pros Cons Best For 最小/ネイティブSDK 軽量・高パフォーマンス 拡張性が低い 定型・短いタスク モジュラー 部品の再利用・分析が容易 設計と境界定義の手間 多様な環境・研究開発 長時間（複数窓） 記憶を越境し長尺タスク完遂 状態管理が複雑化 数時間〜数日の作業 マルチエージェント 親子委譲等で複雑さに対応 管理負担・結合コスト増 複雑さが読めないタスク 評価ハーネス 同条件での挙動採点・回帰検知 構築と維持のコスト 品質保証・継続運用 ランタイム適応 モデル不変で自動チューニング 探索コスト・過適合のリスク 本番環境の継続最適化

トレードオフ：ハーネス工学が効くレジームと落とし穴 Why it Works - 効く理由 ■ モデル非依存で改善が可能（LLMの差し 替えが不要）。 ■ 観測(L)と評価(V)により、再現性と説明性 が担保される。 ■ コーディング等の複雑タスクで大幅改善の 実例 (6.7% → 68.3%)。 Pitfalls - 注意点・落とし穴 ■ 複雑化のしすぎ：最初からマルチエージェント 等を組み、最小構成から始めない失敗。 ■ 標準からの逸脱：ハーネスとエージェントは 密結合。非標準化による劣化リスク。 ■ 評価の形骸化：観測・評価を後回しにすると 改善不能に。また、ベンチマーク通過が本番 採用と乖離するリスク。

中堅エンジニアへの5つの戦略的推奨 1. 観測と評価(L,V)を最優先で導入する なぜ：計装なしに改善も回帰検知も不可能。最初に軌跡と成功シグナルを確保する。 2. モデルの前に、まずハーネスを疑う なぜ：モデル不変で10倍改善する事実（安く確実なアプローチ）。 3. ネイティブSDK/標準に合わせる なぜ：密結合の恩恵を受け、不必要な劣化を防ぐ。 4. 文脈(C)を「有限資源」として厳密に設計する なぜ：詰め込みは劣化（Context Rot)を招く。選別・圧縮・検索を仕組み化する。 5. 失敗を「システム」として恒久化する なぜ：環境の未規定が失敗の主因。個別のエラーを規則や新ツールに変換し、再発を防止する。

ハーネスエンジニアリング習得へのロードマップ Step 1: 地図を持つ H=(E,T,C,S,L,V)のパラダイ ムをチームで共有する。 Step 3: 計装 (L/V) トレースと評価を組み込み、 軌跡と成功率を可視化する。 Step 5: 本番コードの読解 自社タスクにおいて、評価駆動の 改善サイクルを回し統計を学ぶ。 Step 2: 最小実装 ReActループを自前で書き、 ツールを1つだけ接続して動かす。 Step 4: 成分別の深掘り 文脈・記憶・ツー ル・安全を1つずつ 強化していく。 Step 6: 最適化の反復 自社タスクにおいて、評価駆動 の改善サイクルを回し続ける。

Summary：本番稼働への鍵は「身体」の設計にある ● 原理：Agent = φ ⊕ A。本番の信頼性は モデルではなくハーネスが律速する。 ● 構成と介入：6成分 H=(E,T,C,S,L,V) で事象を切り分け、「ハーネス優先」 で介入する。 ● 実践：最小構成から始め、観測(L) と評価(V)を基盤に、目的応じた アーキテクチャへと拡張する。 「面白きこともなき世を面白く」 最新論文(Meng et al. 2026 / SWE-bench 等)およびAnthropic公式技術録に基づく。うさうさ研修工房