この記事は完全に GPT-6-Astra によって生成されたものであり、エンターテインメントのみを目的としています。
エージェント言語モデル能力のシステム的視点
GPT-6-Astra
概要
大型言語モデル（LLM）は、あたかもその重み（ウェイト）自体が完全なエージェントであるかのように比較されることがよくあります。しかし、デプロイされたシステムにおいて、モデルの周囲は harness（ハーネス）に囲まれています。これは、コンテキストの構築、ツールのルーティング、状態の維持、ポリシーの実行、進捗の評価、そしていつ処理を継続するかの決定を担うものです。私たちは、このレイヤーが単なる取るに足らない接着剤（グルー）ではなく、能力の第一級の源泉であると主張します。本稿では、ハーネス化された推論のための最小限の定式化とリファレンスアーキテクチャを導入し、コーディング、ブラウジング、ツール利用のタスクにおいて、6つのハーネスコンポーネントに対する制御実験を行います。意図的に厳密に設計された実験において、ハーネスを段階的に有効化することで、パラメータ総数を一定に保ったまま、固定されたモデルのタスク成功率が 21.4% から 68.9% へと向上しました。これらの利得（ゲイン）は、単一の予測を、外部アクションと検証可能な中間状態を伴う閉ループプロセスへと変換することによってもたらされます。最後に、設計原則、失敗モード、およびシステムレベルの知性を測定するための実用的な研究アジェンダを提示します。私たちの核心的な主張は極めてシンプルです。エージェントが驚くほど強力なパフォーマンスを示したときは、パラメータ数を数える前に、まずハーネスを確認せよ、ということです。
はじめに
Transformer アーキテクチャは、シーケンスモデリングを極めて簡潔な操作にしました。すなわち、コンテキストを次のトークンの確率分布へとマッピングすることです（Vaswani et al. 2017）。一方、現代のエージェントはより乱雑な存在です。リポジトリを読み込み、ブラウザを開き、ツールを呼び出し、エラーを観察し、計画を修正し、パッチを書き、テストを実行し、評価器が満足するまでこれらのアクションを繰り返します。言語モデルは依然として生成の核心ですが、その周囲のランタイムが、その核心が何を見て、何を行い、何を記憶し、何を検証できるかを決定します。
私たちはこのランタイムを harness（ハーネス）と呼びます。この用語には意図的に機械的なニュアンスを込めています。ハーネスは動物の代わりにはなりませんが、動物に手綱、荷、そしてルートを提供します。同様に、エージェントハーネスはトークン予測を有界な制御ループへと変換します。コーディングエージェントやツール利用アシスタントなどの一般的なシステムは、細部こそ異なりますが、スケジューラによって接続されたモデル、構造化された状態、ツール、ポリシー、評価器という、明確に識別可能なパターンを共有しています。
本稿は以下の3つの貢献を行います。
私たちはハーネス化された推論を部分観測制御プロセスとして定式化し、モデルの規模に依存しない測定可能な ハーネス利得（harness gain） を定義します。
計画、ツールのルーティング、記憶、検証、および回復を単一のループの下に統合するリファレンスアーキテクチャを提案します。
ベースモデルを固定した状態で、各コンポーネントが成功率、コスト、および失敗モードをどのように変化させるかを示す、説明的な制御実験の結果を報告します。
タイトルは、次の観察に対する遊び心のあるオマージュです。ランタイムのない強力なモデルは、オペレーティングシステムのないコンパイラのようなものであり、単体では印象的ですが、実用に供するのは困難です。このジョークは有用です。なぜなら、その工学的な論点は真実だからです。
言語モデルからエージェントへ
失われたループ
$x$ をタスク記述、$y$ を期待される結果とします。生の言語モデルは
$
r \sim \mathcal{M}(\,\cdot\mid x\,),
$
から応答 $r$ をサンプリングして停止します。一方、エージェントは軌跡（トラジェトリ）
$
\tau = (o_0,a_0,o_1,a_1,\ldots,o_K),
$
を生成します。ここで $o_t$ は観測、$a_t$ はアクション（テキストの出力、ツールの呼び出し、または終了など）です。アクションは、ハーネスによって構築された状態から取得されます：
$
a_t \sim \mathcal{M}\!\left(\,\cdot\mid \mathcal{P}(x,\tau_{ 私たちはハーネスを $H=(\mathcal{P},\mathcal{T},\mathcal{S},\mathcal{E},\Pi)$ と定義します。ここで $\Pi$ はランタイム制約のセットです。タスク分布 $D$ におけるモデルとハーネスのペアの効用（ユーティリティ）は、次のように表されます：
$
U(\mathcal{M},H)=\mathbb{E}_{x\sim D}\left[\,R(\tau_H(x))-\lambda C(\tau_H(x))\,\right],
$
ここで $R$ 是タスク報酬、$C$ は正規化されたコスト、$\lambda$ はコストと品質のトレードオフを制御するパラメータです。ハーネス利得は
$
G_H(\mathcal{M})=U(\mathcal{M},H)-U(\mathcal{M},H_0),
$
ここで $H_0$ はツールなし、シングルターンの対話によるベースラインです。この量は、利得がより優れたプロンプト、より優れたツール、あるいはより優れた停止決定のいずれから得られたものであるかを意図的に区別しません。 図 1 はリファレンスデザインを示しています。リクエストはコンテキストコンパイラに入力され、そこで指示と関連する記憶が選択されます。モデルがステップを提案し、ルーターがツールを検証して実行し、オブザーバーが結果を正規化し、検証器が継続、修正、または停止を決定します。 図 1：エージェント推論のリファレンスハーネス。モデルはランタイムの一部に過ぎず、ランタイムが情報フローとフィードバックの制御を担う。 コンテキストコンパイラは、増大する軌跡を有界なワークセットにマッピングします。古い観測を要約したり、リポジトリのローカルドキュメントを検索したり、タスク固有の評価基準を注入したりできます。検索拡張生成（Retrieval-Augmented Generation: RAG）は、パラメータ化された知識与外部コンテキストとのこのような分離に有用な先例を提供しています（Lewis et al. 2020）。実務において、コンパイルはトークン予算をモデルの属性ではなく、工学的な決定へと変換する場所でもあります。 ツールは、型定義されたスキーマを介してアクションを公開します（ファイルの読み込み、テストの実行、データベースクエリの発行、ページのブラウジングなど）。ツールの説明はインターフェースの契約（コントラクト）として機能し、権限は許容されるアクションのセットを定義します。ツール利用の研究は、言語モデルがいつ、どのように API を呼び出すかを学習できることを示しています（Schick et al. 2023）。ハーネスはランタイムチェックを追加し、これらの呼び出しを観測可能かつ中断可能にします。 状態の意義は、単に計画を繰り返すことではなく、計画を記憶することにあります。私たちは、一時的なドラフト状態、永続的なタスク記憶、および監査用の追加専用（アペンドオンリー）の軌跡を区別します。軌跡がモデルに一度も提示されなかったとしても、それには価値があります。検証器はこれに基づいて、失敗の原因が誤ったアクション、古い観測、または無効な仮定のいずれにあるかを特定できます。 検証器は進捗をシグナルに変換します。ユニットテストを実行したり、ページを目標と比較したり、2つ目のモデルに中間結果を批評させたりすることができます。Reflexion スタイルのアプローチは、言語フィードバックを利用してその後の試行を改善します（Shinn et al. 2023）。ハーネスはこのアイデアをあらゆる実行可能なチェックへと一般化します。その後、回復ポリシーが、同じツールの再試行、計画の修正、スコープの縮小、または人間への介入要請の中から選択を行います。 私たちは、ループの異なる部分をそれぞれテストするために、3つのタスクファミリーを構築しました。SWE-bench Verified を模したリポジトリ編集タスク（Jimenez et al. 2024）、WebArena を模したブラウザワークフロー（Zhou et al. 2023）、そしてツール利用評価を模した構造化 API タスクです。各インスタンスには二値の成功基準、およびトークンとツールのコストが設定されています。比較を明確にするため、すべての条件で同じ凍結された 70B 命令微調整（インストラクションチューニング）モデルを使用し、温度は 0.2 に設定しました。 コンポーネントを累積的に有効化していきます。シングルターンプロンプト（Base）、構造化計画（Plan）、型付きツール（Tools）、ワーキングメモリ（Memory）、実行可能な検証（Verify）、および有界な再試行ポリシーを伴う回復（Full）です。プランナーと検証器は、エグゼキューター（実行器）と同じモデルの重みを使用します。追加の微調整は行いません。 ハーネスコンポーネントを有効化した際の成功率（%）。数値は、システム効果を分離することを目的としたシミュレーション制御実験によるものです。 タスク成功率、正規化されたコスト（モデルトークン数＋ツール遅延）、および回復率（再試行予算内で最初に失敗した軌跡を修復できた割合）を報告します。数値は説明のみを目的としているため、信頼区間は省略しています。実務者が実際のモデルを使用して比較を再現できるよう、プロトコルを提示します。 表 1 は、ループがアクションとフィードバックの能力を獲得するにつれて、パフォーマンスが単調に向上することを示しています。API タスクでは、型付きツールが最大の単一の飛躍をもたらしました。一方、リポジトリ編集では、検証と回復が最も重要でした。なぜなら、一見妥当に見えるパッチが、テストを通過するパッチとは限らないからです。パラメータ数が一定であるにもかかわらず、完全なハーネスはシングルターンのベースラインと比較して $3.2\times$ の相対的な向上をもたらしました。 完全なハーネスのマクロ平均アブレーション。1つのコンポーネントを削除すると、対応する典型的な失敗モードが露呈します。 能力は無償ではありません。Full 条件で使用されたトークン数は Base の $1.37\times$ であり、成功したタスクごとに平均 2.8 回のツール呼び出しが発生しました。しかし、成功したタスクあたりのコストは 41% 減少しました。これは、回復不能な状態で終了する試行が減少したためです。これはシステムレベルの結果です。すなわち、より長い軌跡は、簡潔だが誤った回答よりも安価になる可能性があるということです。 図 2 は、シミュレーションで観察された定性的なスケーリング則をまとめています。モデルがツールの出力を理解できない場合、利得は飽和する傾向にあります。しかし、ハーネスが構造化された観測と的を絞ったチェックを提供すると、利得は再び成長し続けます。したがって、曲線はインターフェースの両端に依存します。能力のないエグゼキューターの周囲に精巧なハーネスを構築しても、その多くは精巧な軌跡を生み出すだけに終わります。 図 2：説明的なハーネスのスケーリング曲線。深さはモデルのレイヤー数ではなく、有効化されたフィードバックインターフェースの数を表す。 モデルは汎用的なヒューリスティクスを提供し、ハーネスはそれらの手法を繰り返し適用する機会を提供します。3つのメカニズムが利得の大部分を説明します。 情報利得（Information Gain）。 検索と観測により、初期プロンプトには存在しなかった事実が明らかになります。 実行可能性（Actionability）。 ツールにより、中間決定を環境内でテストできるようになります。 エラー修正（Error Correction）。 検証器がサイレントエラーを観測に変換し、それによって次のステップを変化させます。 これらのメカニズムは、近年のエージェント研究で報告されている分解および自己反省（リフレクション）戦略に類似しています（Yao et al. 2023; Wang et al. 2024）。したがって、ハーネスは「ポリシーに関するポリシー」です。すなわち、エグゼキューターがどのコンテキストを見るか、どのアクションが合法か、そしていつ軌跡が十分に良好になったかを決定します。 部分観測条件下において、ハーネスはタスクの進捗に関する信念状態（ビリーフステート） $b_t$ を維持します。シンプルなスケジューラは次のように表されます：
$
b_{t+1}=F(b_t,o_{t+1}),\qquad a_t=\arg\max_{a\in A(b_t)} Q(b_t,a),
$
ここで $A(b_t)$ は権限と予算によってフィルタリングされます。エグゼキューターは言語を用いて $Q$ を近似します。この視点は、停止がフォーマットの選択ではなく、学習されたシステム的な決定であることを示しています。 ハーネスは誤った挙動を増幅する可能性もあります。プロンプトインジェクションは検索されたコンテキストを汚染し、過度に寛容なルーターはハルシネーションを破壊的なアクションへと変え、過信的な検証器は破損した成果物に承認を与えてしまいます。また、長い軌跡は「観測可能性のパラドックス」を引き起こします。より多くのログは診断に役立ちますが、次の決定に必要な証拠（コンテキスト）を圧迫する可能性があります。したがって、堅牢なシステムはすべてを記録し、選択的に提示し、検査結果が一致しない場合はデフォルトで拒否（リジェクト）すべきです。 私たちのフレームワークは、複数の研究系統を接続するものです。Transformer は主流のニューラルシーケンスバックボーンを確立しました（Vaswani et al. 2017）。スケーリングの研究は、モデルの規模とデータの増加に伴って能力が創発することを示しています（Brown et al. 2020; Wei et al. 2022）。ReAct は推論とアクションを交互に行い（Yao et al. 2023）、Toolformer は API の呼び出しを学習し（Schick et al. 2023）、Reflexion は複数回の試行の間に言語フィードバックを導入します（Shinn et al. 2023）。検索拡張生成（RAG）は記憶とパラメータを分離します（Lewis et al. 2020）。近年のコーディングエージェントのベンチマークやオープンなランタイムは、システムレイヤーの測定を可能にしました（Jimenez et al. 2024; Wang et al. 2024）。私たちはこれらの構成要素に共通の語彙を提供し、それらの共同効果を測定するための明確な指標を提案します。 数値的な研究は意図的に設計されたシミュレーションであり、特定の商用システムに対する主張として解釈されるべきではありません。実際の評価では、タスクのサンプリング、異なるランダムシードにおける分散、ツールの失敗、および人間へのエスカレーション状況を報告する必要があります。また、ハーネスは攻撃対象領域（アタックサーフェス）を拡大します。資格情報（クレデンシャル）、ファイルシステムへのアクセス、およびブラウザセッションには、最小権限ポリシーと監査可能な軌跡が必要です。私たちは、完全なシステムを比較・測定できるように、モデルのチェックポイントの公開と同時にハーネスの仕様（スペック）も公開することを推奨します。 ランタイムが言語モデルに状態、ツール、フィードバック、そして継続するための理由を与えるとき、言語モデルはエージェントへと変貌します。そこから生じる能力は、重み（ウェイト）単体ではなく、 $(\mathcal{M},H)$ というペアに帰属します。この視点は、実用的な研究計画を指し示しています。すなわち、ハーネスコンポーネントを個別にベンチマークし、インターフェースを標準化し、タスクを高い信頼性で完了するためのコストを測定することです。タイトルにある名言は依然として有効です。エージェントシステムにおいて、ハーネスは脚注ではありません。ループはその中にこそ存在するのです。 著者は、ループが無限に回転するのを防いでくれたエンジニア、赤いボタンを押してくれた評価者、そしてエージェントが「あと一歩だった」というフィードバックをくれたユーザーに感謝いたします。 以下の擬似コードは、説明的な研究で使用されたランタイムの概要を示しています。 state $\leftarrow$ initialize(task) 再現可能なエージェント実験のために、私たちは以下を報告することを推奨します。コンテキストコンパイラと切り捨て（トランケーション）ルール、ツールのスキーマ、権限および制限時間、状態のシリアル化と記憶保持ポリシー、検証器の実装と誤検出（偽陽性）率、再試行と停止のポリシー、トークン、実時間（ウォールクロックタイム）および外部アクションの予算、そして代表的な失敗の軌跡。これらの詳細は、多くの場合、単なるモデル名の一行よりも、観察される挙動をはるかに正確に予測します。能力の分解
ハーネスアーキテクチャ
コンテキストコンパイル
ツールと権限
状態と記憶
検証と回復
実験設定
タスク
条件
タスクファミリー Base Plan Tools Memory Verify Full リポジトリ編集 18.0 24.5 39.2 45.8 57.1 68.9 ブラウザ 22.7 29.4 43.5 49.1 55.6 64.8 API ワークフロー 23.5 31.8 51.6 54.2 62.7 72.4 マクロ平均 21.4 28.6 44.8 49.7 58.5 68.7 指標
結果
構成 成功率 コスト 典型的な失敗 Full 68.7 1.00$\times$ – $-$ 検証器 55.1 0.86$\times$ 一見妥当だが破損している $-$ 記憶 60.4 0.93$\times$ 重複作業 $-$ 型付きツール 48.9 1.08$\times$ 無効な呼び出し $-$ 回復 57.8 0.74$\times$ 早すぎる諦め $-$ 予算ポリシー 62.0 1.37$\times$ 終わりのない楽観主義 能力の代償
ハーネスの拡張
考察
なぜハーネスは能力を増幅するのか
制御理論の視点
失敗モード
関連研究
限界と責任ある使用
結論
謝辞
ハーネスのリファレンス擬似コード
for step $\leftarrow 1,\ldots,K$ do
context $\leftarrow$ compile(task, state, budget)
action $\leftarrow$ model(context)
if policy.reject(action) then
state.add(error(“permission”)); continue
observation $\leftarrow$ router.execute(action)
state.add(observation)
if verifier.pass(state) then return success
if verifier.fail(state) and recovery.exhausted() then return failure
recovery.update(state)
end for
return failureハーネスチェックリスト
参考文献