LLMエージェントを本番環境で運用し始めると、多くの開発者が共通の課題に直面します。温度パラメータ（temperature）を下げて同一の入力を与えた場合でも、実行ごとにツールの呼び出し順序や最終出力が微妙に変動してしまいます。また、タスクが長期化するにつれて、過去のやり取りが判断を阻害し、途中で同様の失敗を繰り返す現象も発生します。モデルをより高性能なものへ差し替えたとしても、こうした挙動のばらつきを完全に排除することは困難です。

これらの挙動の多くは、モデル単体ではなく、モデルを取り囲む「ハーネス（harness、エージェントの実行を制御する層）」の設計に起因しています。ハーネスは、モデルが各ステップで参照する情報、利用可能なツール、そしてタスクの継続や終了のタイミングを規定する役割を持ちます。すなわち、エージェントとは「モデル」と「ハーネス」の組み合わせとして捉えるべきであり、評価やチューニングを行う際にも両者を一体として扱う必要があります。

この記事では、ハーネス設計に関する実証的アプローチを取り上げ、同一の軸で横断的に比較します。具体的には、有限状態の実行フローに構造化プランニング（Structured Planning）を導入した際の再現性の変化、モデルの重みを固定したまま文脈管理方式を変更した際のコーディングベンチマーク解決率の推移、そして会話履歴の蓄積を明示的な実行状態へと置き換えた際の長時間タスクにおけるトークン消費量と精度の挙動を検証します。得られる効果だけでなく、レイテンシの増加やリソース消費の増大といったトレードオフ、ならびに各手法が有効に機能する適用条件についても整理して解説します。

1. エージェントの再現性という運用課題

再現性の重要性

実務運用において再現性が極めて重視される背景には、以下の業務がいずれも「同一の入力に対して同一の結果が得られること」を前提としている点があります。

• 監査対応: 処理プロセスの透明性と説明責任の担保
• 回帰テスト: システム改修時における動作の整合性確認
• インシデントの再現調査: 障害発生時の原因究明と対策検証

しかし、低温デコード（低 temperature 設定）を適用した場合であっても、エージェントの実行トレース（ツールの呼び出しシーケンス、引数、状態遷移、最終出力）は実行ごとに変動します。

決定性を測定する3つの評価指標

実行トレースのばらつきを定量的に把握するため、決定性の評価には主に以下の3つの指標が用いられます。

• Determinism Index（DI、決定性指数）:
  Plan Stability（計画の安定性）、Tool Path Consistency（ツールパスの一貫性）、State Transition Stability（状態遷移の安定性）、Output Consistency（出力の一貫性）の4つのサブスコアを等しい重みで合成した \([0, 1]\) の指標です。
• Reproducibility Rate（再現率）:
  「完全な実行トレースが、そのグループにおける最頻トレースと完全一致する実行の割合」として厳格に定義される指標です。
• Task Success Rate（TSR、タスク成功率）:
  決定論的な正解に対する出力の正しさを表す指標です。決定性とは独立した枠組みで測定されます。

再現性が高くても出力結果が誤っていれば実用上の意味をなさないため、決定性とタスク成功率は切り分けて評価する必要があります。

「モデル ＋ ハーネス」という視点

コーディングエージェントを「モデル ＋ ハーネス」の複合体として捉える視点では、ハーネスが以下の制御を一手に担います。

• モデルが各ステップで何を参照するか
• どのツールが利用可能か
• 作業をどのように継続・停止するか

これらの制御構造が変化すると、モデルの重みが同一であっても到達できる結果が大きく変化します。

長時間タスクにおける計算量と文脈汚染

タスクが長期化するにつれて、別の運用課題も顕在化します。

• 計算量の爆発: やり取りを逐次追記し続ける単純なランタイムでは、プロンプト長がステップ数 \(t\) に対して \(O(t)\) で伸長し、実行全体での累積トークン数は \(O(T^2)\) に達します（\(T\) は総ステップ数）。
• 文脈汚染（context poisoning）: 過去の不要な観測結果や役目を終えた推論メモが文脈内に残留し続けることで、実行ステップが伸びるほど判断ミスや失敗が累積します。

2. ハーネスを構成する制御要素

基本ハーネスの4つの主要コンポーネント

決定性制約に関する検証では、基本となるハーネスが以下の4つのコンポーネントで構成されます。

1. 有限状態実行（finite-state execution）:
   タスクを固定された名前付きの状態に分解し、状態間の遷移ルールをグラフ構造として事前に定義します。
2. ツール選択の強制（forced tool selection）:
   各状態において利用できるツールを認可された1つのみに束縛します。実装上は tool_choice="required" などを指定して制御します。
3. 出力検証（output validation）:
   ツールの出力をスキーマおよび型のバリデータで検証し、検証を通過した場合にのみ状態機械を次のステップへ遷移させます。
4. 上限付きリトライ（bounded retry with escalation）:
   出力検証に失敗した場合、事前に設定された規定回数を上限として再試行を行い、上限を超過した段階で処理を停止してエスカレーションを実行します。

比較検証における3つの条件

検証においては、制御制約を設けずにモデル本来の tool-calling 挙動に委ねるベースラインを設定し、以下の3条件を切り分けて比較を行う必要があります。

• Baseline: 制約を一切適用しない素のエージェント構成
• Harness: 有限状態実行から上限付きリトライまでの基本制約を適用した構成（後述の構造化プランニングは非搭載）
• Harness+SP: 基本制約に構造化プランニングまで統合したフル構成

3. 基本ハーネスの限界

基本ハーネス導入時の検証

基本ハーネスのみを適用した段階における検証では、明確に結果が分かれる形となります。

2つのタスク（12件の融資に対する期待信用損失の計算、および10条項の契約分類）と2つのモデル（Qwen-2.5-7B-Instruct および Gemma-3-27B-IT）を組み合わせた4つの条件（各 \(N=100\)）において Reproducibility Rate を測定した結果は以下の通りです。

タスク × モデル	Baseline	Harness	判定
finance_ecl × Qwen-2.5-7B	0.91	0.93	有意差なし
legal_clause × Qwen-2.5-7B	0.79	0.68	有意に悪化（\(p=0.038\)）
finance_ecl × Gemma-3-27B	0.42	0.55	有意に改善（\(p=0.006\)）
legal_clause × Gemma-3-27B	0.56	0.38	有意に悪化（\(p<0.001\)）

揺れの要因分析

検証した4つの組み合わせのうち、改善が見られたのは1件のみであり、2件は悪化、残り1件は有意差なしという結果になりました。

実行トレース単位で原因を分析すると、有限状態実行、ツール選択の強制、出力検証の導入によって各コンポーネントの動作はほぼ完全一致する水準（ceiling consistency）に達しています。しかし、唯一制約がかけられていなかった「自由記述のプラン文（plan-text）」の表現差が、測定された揺れの大部分を占めていることが判明しました。

コンテキスト窓の制約とハーネス効果の相関

ハーネスの限界は別の検証からも確認されています。

クローズドループ型のハーネスを用いた検証において、コンテキストウィンドウを 262,144 トークンまで拡張して実質的に文脈制約を解除したところ、ハーネス適用（処置あり）による優位性がほぼ消失しました。

• SWE-bench Verified: 処置ありと処置なしの平均 F2PF 差は −0.3 ポイント（95% 信頼区間 \([-4.5, +3.9]\)）、完全解決数も 102 件 対 101 件とほぼ同等でした。
• FeatureBench: 例外的に、広いコンテキスト窓であっても F2PF が 23.9% から 30.7% へ有意に改善しました（p=0.00022）。

この結果から、ハーネスによる制御が真価を発揮するのは、文脈や計算リソースに強い圧力がかかっている状況に限定されることが示唆されます。

4. ハーネス設計の3つの方向性

ハーネス設計における課題を解決するため、制御対象のレイヤーが異なる3つのアプローチが提案されています。

1. 構造化プランニング: プラン文を構造化して決定性を担保するアプローチ
2. クローズドループと半減期ビュー: モデルに提示する文脈を動的に制御するアプローチ
3. 明示的な実行状態への置き換え: 会話履歴そのものを状態オブジェクトへ移行するアプローチ

4.1 構造化プランニングによる決定性の担保

仕組みと実行フロー

構造化プランニング（Structured Planning）は、プラン文における自由記述という最後のばらつき要因を、検証可能なデータ構造に制約する仕組みです。

• 計画の JSON 出力: エージェントはいかなるツールを呼び出す前であっても、計画を {state, intended_tool} オブジェクトの JSON 配列として出力することが義務付けられます。
• 有限状態グラフによる検証: 出力された計画は有限状態グラフと照合・検証されます（validate_structured_plan）。
• 再プロンプトとエスカレーション: グラフに適合しない場合は規定で最大2回まで再プロンプトが実行され、それでも適合しない場合は処理を停止してエスカレーションします。
• ツール呼び出しの制限: 有効な計画が確定するまで、ツールの呼び出しは一切許可されません。

これにより、実行ログには検証済みのペアのみが記録されるため、自然言語による言い回しの違いに起因するばらつきが機械的に排除されます。

導入効果

同一の4条件（各 \(N=100\)）において Reproducibility Rate および TSR を測定した結果、大幅な改善が確認されました。

• Gemma-3-27B（両タスク）: Reproducibility Rate がそれぞれ 0.42 → 1.00、0.56 → 1.00 へと完全再現に達し、TSR も 1.00 を達成しました。
• legal_clause × Qwen-2.5-7B: Reproducibility Rate が 0.79 → 1.00 へ向上しました。
• finance_ecl × Qwen-2.5-7B: Reproducibility Rate が 0.91 → 0.98（TSR 0.98）へ向上しました。

結果として、4条件中3条件で完全再現を達成し、3条件で TSR 100% を記録しました。Stage 1 で生じていた結果のばらつきが解消され、自由記述のプラン文をスキーマに制約することの有効性が実証されました。

4.2 クローズドループと文脈の半減期ビュー

「Yuj」と呼ばれるハーネスアーキテクチャでは、3つの主要機構によって文脈管理をクローズドループ化しています。

構成する3つの主要機構

1. Working-View Rule（半減期ポリシー、Half-Life Policy）:
   • 完全な会話ログをメモリ上に保持しつつ、モデルへ提示する作業ビュー（working view）を完全に分離します。
   • 推定プロンプト長が設定コンテキスト窓の半分に到達した時点で発動します。
   • 直近4件のツール実行結果は全文を維持し、それ以前の古い結果は「ステップ経過が2倍になるごとに文字数上限が半分になる」底2の対数スケールに基づいて段階的に圧縮します。
   • 圧縮対象の古い結果は冒頭と末尾のみを残し、中間部分を省略マーカーへ置換します。
2. Detector（検出器）:
   • コマンドの連続失敗や、編集を伴わないファイル読み取りの繰り返しといった異常パターンを、実行記録内の確定事実のみから即座に検出します。
   • トランスクリプトの再読み込みや追加のモデル推論を一切行わないため、軽量に動作します。
3. Interventions（介入）:
   • 異常パターンを検出した際、ハーネス側から「同一の試行が同一のエラーを引き起こしているため、別のアプローチを選択せよ」といったプロンプトを差し込み、その後の挙動を再観察します。
   • これにより「観察 → 介入応答 → 再観察」の自律ループを形成します（対照群は時系列の会話をそのまま提示し、コンテキスト窓の上限で停止）。

評価指標「F2PF」

評価には F2PF（fail-to-pass fraction）が用いられます。

• 定義: \(\text{F2PF} = \frac{\text{pass に転換できた F2P テスト数}}{\text{全 F2P テスト数}}\)
• 特徴: F2P は「パッチ適用前に失敗し、パッチ適用後にパスすべきテスト」を指します。完全解決のみを評価するのではなく、部分的な修正成果も適切にスコアへ反映します。各タスクに対して 0〜1 のスコアが等しい重みで割り当てられます。

ベンチマーク結果とモデル移植性

文脈圧力が高い環境下において Qwen3.6 を評価したところ、3つのベンチマークすべてで F2PF が有意に向上しました（すべて p<0.0001）。

• SWE-bench Verified: 28% → 49%（完全解決数: 43件 → 72件）
• SWE-bench Pro: 15% → 33%（完全解決数: 31件 → 72件）
• FeatureBench: 11% → 20%（完全解決数: 2件 → 3件）

さらに、本手法をハイパーパラメータの再調整なしで他モデルへ適用した場合でも、同様に F2PF の改善が確認されました。

• Devstral: 17% → 37%（+20 ポイント）
• Nemotron: 12% → 18%（+6 ポイント）
• Qwen3.8: 20% → 35%（+15 ポイント）

この結果は、ハーネス側の設計が特定のモデルに依存せず、複数のモデルアーキテクチャに対して高い移植性を持つことを示しています。

4.3 会話履歴から明示的な実行状態への置き換え

「SKILL.state」のアーキテクチャ

「SKILL.state」は、逐次追加される会話履歴そのものを廃止し、明示的かつ直接更新可能な実行状態オブジェクトへと置き換える設計を採用しています。

• 入力構造: 各ステップでモデルに与えられる入力は、3つ組 \(A_t = (P, \Sigma_t, O_t)\) です。
  • \(P\): 不変の手続き仕様（プロシージャ）
  • \(\Sigma_t\): ステップ \(t\) における構造化された実行状態
  • \(O_t\): 最新の環境観測結果
• 出力構造: モデルは各ステップで \((R_t, \Delta\Sigma_t, a_t)\) を生成します。
  • \(R_t\): 多段の推論プロセス
  • \(\Delta\Sigma_t\): 状態更新用辞書
  • \(a_t\): 実行アクション
• 状態更新と推論の破棄: 推論 $R_t$ は検証後に永続的に破棄され、検証を通過した状態更新 \(\Delta\Sigma_t\) のみが保持されます。状態更新は以下の数式で定義されます。
  $$\Sigma_{t+1} = \Sigma_t \oplus \Delta\Sigma_t$$
  ここで \(\oplus\) は「値が null の場合に該当キーを削除する辞書マージ演算子」を表します。既存のキーを維持しつつ、指定されたキーの値を上書きし、null が指定されたキーを削除します。
• 計算量の削減: プロンプトサイズをステップ数から完全に分離し、\(O(|P| + |\Sigma| + |O|)\) の一定サイズに保ちます。これにより、従来の会話ランタイムで \(O(T^2)\) であった累積トークン計算量が \(O(T)\) にまで削減されます。

性能とノイズ耐性の検証

Gemini-3-Flash を用いた倉庫管理タスクにおいて顕著な効果が実証されています。

• ステップ数 T=100:
  • SKILL.state: 精度 0.94、平均 1,905 トークン、累積 65,408 トークン
  • 状態保持型（stateful）ベースライン: 精度 0.91、平均 31,354 トークン、累積 1,062,387 トークン（累積トークンで約16倍の差）
• ステップ数 T=200:
  • SKILL.state: 精度 0.94、累積 122,384 トークンを維持
  • メモリ型ベースライン: 精度 0.84、累積 6,175,509 トークンまで膨張
• 高ノイズ環境（1ターンあたり50件の無関係イベント、T=50）:
  • プロンプト型ベースライン: 精度が 0.53 まで低下
  • SKILL.state: 精度 0.98 を維持
• トークン予算固定比較（予算約 1,800 トークン、T=100）:
  • 単純な sliding window による切り詰め: 精度 0.18
  • LLMLingua による圧縮: 精度 0.22
  • SKILL.state: 精度 0.94 を達成
• 公開ベンチマークでの成果:
  • InterCode CTF: 解決率 41.8% → 54.2%（累積トークン 1.13M → 387k）
  • $\tau$-Bench（Retail）: 51.7% → 58.3%
  • $\tau$-Bench（Airline）: 28.1% → 32.4%

小型オープンウェイトモデルにおける課題と対策

一方で、小型のオープンウェイトモデルを適用した場合には課題も確認されています。

Gemma-4-31B（T=100）における評価では、SKILL.state の精度は 0.42 にとどまりました（Full ReAct の 0.21 は上回るものの実用上十分とは言えない水準です）。主な失敗原因の内訳は以下の通りです。

• 早すぎる状態の上書き・削除（68%）: 状態更新時に既存キーを意図せず欠落させてしまう事象
• スキーマ理解・型の取り違え（20%）: 期待されるネスト構造と実際の構造との不一致
• JSON 構文の乱れ（12%）: 区切り記号の誤りや末尾カンマの混入

これらの課題に対する有効な対策として、文法制約付きデコード（grammar-constrained decoding）を用いて出力形式を機械的に強制することが不可欠となります。

5. ベンチマークで見る効果と代償

3つのアプローチはいずれも再現率、F2PF、テスト通過率を向上させ、トークン消費量を抑制する方向で機能します。しかし、発生するトレードオフ（代償）はアプローチやモデルごとに異なります。

アプローチごとのコストとトレードオフ

• 構造化プランニング:
  • トークン消費: 全ての評価条件においてベースライン比 14.8〜16.7% の削減を一貫して達成します。
  • レイテンシ: モデル依存性が顕著です。Qwen ではベースライン比 −14.2〜−24.7% と高速化するのに対し、Gemma では +41.4〜+47.0% と大幅に遅延します。同一の手法であってもモデルによって明確な利点となるか重い代償となるかが分かれます。
• クローズドループ型（Yuj）:
  • リソース消費: 文脈圧力が高い SWE-bench Verified（20,480 トークン窓）において、対話ターン数が 3,280 から 6,517 へ、プロンプトトークンが 37.8M から 80.7M へ、実時間（wall time）が 1.3 時間から 4.6 時間へとおよそ3倍前後に増加します。F2PF や完全解決数の向上と引き換えに、計算資源と実行時間を追加で消費します。
• 明示的な実行状態（SKILL.state）:
  • トークン削減: トークン消費量が大幅に削減されます（倉庫管理タスクで約16倍削減、CTF で約3分の1に圧縮）。
  • 追加の実装コスト: 小型オープンウェイトモデルを採用する場合、文法制約付きデコードの実装と検証が必要となります。

評価における重要原則

実証検証から得られる共通の教訓として、ハーネスエンジニアリングの性能評価は全体平均などの集約値で行うべきではなく、モデルごとに個別に測定・報告すべきです。また、評価対象は常に「モデルとハーネスの組み合わせ」として固定して検証する必要があります。

6. 実務での使いどころと適用条件

ハーネス投資の費用対効果が高いシナリオ

ハーネスの設計・導入への投資効果が特に高くなるのは、以下の要件が存在するシナリオです。

• 文脈圧力が高い場面: コンテキストウィンドウが狭い、あるいはログの蓄積により急速に上限へ達する環境
• 長時間タスク: 多数のステップを要し、計算量や文脈汚染が問題となる環境
• 決定性・再現性の要求: 監査対応や回帰テストなど、同一トレースの再現が必須となる環境

適用が推奨されない、または効果が限定的なシナリオ

一方で、以下のような環境では導入効果が薄れる、あるいは逆効果となるリスクがあります。

• 実質無制限の文脈窓が存在する場合: クローズドループ型における優位性は、広大なコンテキスト窓を持つ SWE-bench Verified および Pro では消失しました。
• 自由記述のプラン文が残存している場合: 基本的なハーネス制約のみではプラン文の揺れを吸収できず、再現性が改善しない可能性があります。
• レイテンシ増加の影響が大きいモデルを用いる場合: Gemma のように構造化プランニングの導入でレイテンシが大幅に悪化するモデルでは、慎重な検討が必要です。

明示的な実行状態を採用する際の前提条件と制約

明示的な実行状態（SKILL.state）の採用は、「現在の実行状態が将来の意思決定を行うための十分統計量である」という前提に基づいています。この前提が成り立たない以下のようなケースでは適用が困難です。

• 実行中に動的に状態スキーマを探索・定義しなければならない場合
• 観測時点ではその情報の重要度が判別できない過去データが存在する場合
• 監査ログや来歴追跡のように、過去の履歴軌跡そのものがタスクの成果物となる場合
• 複数エージェントによる並行アクセス環境（現状は単一エージェントを想定しており、マルチエージェント拡張には並行書き込みセマンティクスの設計が必要）

天井効果の診断とリソース配分の最適化

評価指標においてスコアが 1.0 に達する「天井効果（ceiling effect）」は、単なる頭打ちではなく「その評価軸にはこれ以上の改善余白が存在しない」ことを示す重要なシグナルです。

実行トレース単位で「どのコンポーネントが挙動の揺れを引き起こしているか」を精緻に診断することで、単にハーネスの有効・無効を判断するだけでなく、各制約がどのリソース軸（レイテンシ、ターン数、実時間、トークン数、実装の複雑さ）とトレードオフの関係にあるかを正確に切り分けて設計判断を下すことが可能になります。

おわりに

3つの実証的な検証結果が共通して示しているのは、ハーネスはモデルから切り離して考えることのできない重要な制御層であり、同一のモデル重みであっても実行層の設計次第で達成可能な成功率・再現性・スケーラビリティの限界が大きく変化するという事実です。

ハーネス設計の効果を一律に優劣で語ることはできません。プラン文の構造化、文脈の半減期圧縮、実行状態の外部化といった各種の制約は、それぞれレイテンシ、対話ターン数、トークン消費量、実装コストとのトレードオフの上に成り立っています。そのため、どの制約がどのリソースを消費するのかを実測に基づいて分解・評価することが不可欠です。実務においては、高い決定性が要求されるタスク、長時間の実行を要するタスク、あるいは文脈圧力が高い環境ほど投資対効果が高くなります。その際、コスト評価はモデルごとに個別に行い、常に「モデルとハーネスのペア」を単位として評価・選定を進めることが推奨されます。

今後の展望としては、マルチエージェント環境における状態の並行書き込み制御、状態スキーマの動的探索・適応手法、ハーネス構成パラメータの自動最適化、そして監査ログのように履歴の全軌跡そのものが成果物となるタスクへの対応などが、主要な未解決課題として残されています。

More Information

• arXiv:2608.26197, Saransh Dhage, 「Harness Engineering for Predictable Agentic Systems: An Empirical Study of Deterministic Execution Constraints」, https://arxiv.org/abs/2608.26197
• arXiv:2608.26218, Sydney Lewis, 「Same Model, Different Harness: Different Coding-Agent Results」, https://arxiv.org/abs/2608.26218
• arXiv:2608.26263, Sanket Badhe, Priyanka Tiwari, Jonghyun Chung, 「SKILL.state: Scalable Long-Horizon Agent Skills」, https://arxiv.org/abs/2608.26263