軍事戦略の意思決定ループでツール利用エージェントの「状態-行動競合」を分離する──OODA-Tool

複数のツールを何ターンにもわたって呼び出しながらタスクをこなすエージェントは、「次にどのツールを呼ぶか」を決めることに気を取られるあまり、それまでの対話で積み上げてきた情報を見失うことがある。arXivで2026年8月25日に公開された論文（arXiv:2608.24368、8月27日にv2へ改訂）は、この現象を軍事戦略の意思決定モデルを借りて構造化する手法を提案している。

論文PDF本文の1ページ目を確認すると、著者8名の所属は華中科技大学（Huazhong University of Science and Technology）・Knowin AI（深圳）・福建理工大学・江西理工大学・キング・アブドゥラー科学技術大学（サウジアラビア）・カリフォルニア大学マーセド校・アムステルダム大学の7機関にまたがっており、単一の大手研究機関ではなく、中国国内の複数大学と海外の大学・スタートアップが混成したチームによる研究だった。著者名はRongfeng Guo、Yinxuan Huang、Yusen Wu、Maoqing Zhong、Yunlu Chen、Meng Tang、Teng Long、Vincent Tao Huの8名で、責任著者（提出者）はRongfeng Guo氏。arXiv上の分類は、主分類がArtificial Intelligence（cs.AI）、副分類がSoftware Engineering（cs.SE）の2つで登録されている。投稿履歴を確認すると、v1は2026年8月25日10:27:25 UTC（781KB）、今回参照しているv2は2026年8月27日08:07:54 UTC（1,290KB）に提出されており、2日で改訂版が出たことになる。

• 直接的な関数呼び出しやReActスタイルのエージェントは、状態の追跡と行動の生成を同じ自己回帰的な軌跡の中で学習しているため、「次の呼び出しを出す圧力」が「それまでの対話で蓄積した情報」を上書き・無視してしまう「状態-行動競合（state-action competition）」が起きると指摘
• 対策として、BoydのOODAループ（Observe-Orient-Decide-Act）に着想を得た「OODA-Tool」を提案。状態の保持と行動の実現を明示的に分離した、コントローラーによって検証される中間状態を経由する構造を採る
• Qwen3の0.6B〜14Bまでのモデル群で評価し、複数ターン・複数ツール・情報が不完全な設定を横断して一貫した改善を確認。特に小規模モデルと、複数ターンにまたがる情報依存が強いタスクで改善幅が大きいと報告されている

「状態-行動競合」とは何か

論文のアブストラクトはこう説明している。

Direct function-calling and ReAct-style policies learn state tracking and action generation within the same autoregressive trajectory. This coupling creates state-action competition: the pressure to produce the next call can overwrite or ignore information accumulated earlier in the interaction.

（直接的な関数呼び出しやReActスタイルの方策は、状態の追跡と行動の生成を同じ自己回帰的軌跡の中で学習する。この結合が状態-行動競合を生む：次の呼び出しを出す圧力が、対話の初期に蓄積された情報を上書きまたは無視することがある）

つまり、通常のツール利用エージェントは「今どういう状況か」の把握と「次に何をするか」の決定を、区切りのない1つの生成プロセスの中で同時にやらされている。その結果、行動を出すことへのプレッシャーが状態把握の質を犠牲にしてしまう、という構造的な問題として整理されている。

OODAループを模した4段階構造

対策として提案されているOODA-Toolは、各判断を4つの明示的なステップに分けてルーティングする「型付きの閉ループ方策」だ。

• Observe（観察）：タスク状態を再構築する
• Orient（情勢判断）：実行が妥当かどうかを判定する
• Decide（意思決定）：実行可能な行動構造を形成する
• Act（行動）：外部への出力を実現する

論文は、対話履歴から行動を直接生成させるのではなく、「コントローラーによって検証される中間状態」を経由させることで、最終的な出力が現在のタスク状態に根ざした状態を保てるようにしている、と説明している。

評価環境と傾向

評価にはQwen3系のモデル（0.6Bから14Bまで）が使われ、複数ターン・複数ツール・情報が不完全な設定という3つの条件を横断してOODA-Toolを直接関数呼び出しおよびReAct方策と比較している。論文が挙げる傾向は次の2点だ。

• モデルサイズを問わずタスク成功率が一貫して改善するが、モデルサイズが小さいほど改善幅が大きい
• 行動が複数ターンにわたって蓄積された情報や過去のツール結果に強く依存するタスクほど、改善幅が大きい

これは、大規模モデルほど自前で状態を保持する能力が高く、構造化の恩恵が相対的に小さいことを示唆していると読める。制御変数を使ったバリアント比較・段階別のアブレーション・転移評価でも改善の頑健性が確認されたとされている。

評価に使われたベンチマーク「ToolDial」と、具体的な数値

論文本文を確認すると、主要な評価には「ToolDial」というベンチマークが使われていた。ToolDial自体は本論文とは別の既存研究（Shim・Seo・Lim・Jo、ICLR 2025）で、RapidAPI上のAPIをもとに構築された11,111件のマルチターン対話（1対話あたり平均8.95ターン）から成るデータセットだ。「Request」「Clarify」「Fail inform」など16種類のユーザー・システム行動を含み、情報が足りない場合にモデルがユーザーへ聞き返す・追加のAPIを探すといった、現実の対話に近い複雑さを再現するよう設計されている。OODA-Toolは、このToolDial上でQwen3系列（0.6B〜14B）をLoRA（rank 32、alpha 64、dropout 0.05）でファインチューニングし、直接関数呼び出し（Direct-LoRA）・ReAct方式（ReAct-LoRA）・既存手法のα-UMiなどと比較している。

論文のTable 1から、Task Success（タスク成功率、0〜100）の一部を抜粋すると次の通り。

さらに、論文はOODA-Toolの改善幅がタスクの種類によってどう変わるかも報告している（Table A2、1.7Bモデルでの改善幅、パーセンテージポイント）。

「長い対話履歴」「情報の欠落」「状態の変化」といった、過去の情報を正しく保持し続ける必要があるタスクでは改善幅が13〜16ポイントと大きい一方、単純に複数のツールを並列で呼ぶだけの「並列呼び出し」タスクでは改善幅が3.2ポイントにとどまる。論文は「並列呼び出しでの主なエラーは、呼び出しの展開とツール間の引数の紐付けに起因し、対話状態の再構築とは性質が異なる」と説明しており、OODA-Toolが効くのはあくまで「状態を保持し続ける必要があるタスク」であって、万能の改善策ではないことを論文自身が示している。

さらに、実行の根拠づけ（グラウンディング）に関するエラー率の比較（Table A3、500ターンのサンプル）では、「時期尚早な呼び出し（Premature Call）」がDirect-LoRAの9.0%からOODA-Tool（Specialized）で3.0%へ、「古い・根拠のない引数（Stale/Ungrounded Argument）」が7.6%から1.6%へ、それぞれ減少したと報告されている。

転移評価に使われたBFCLの現在地

論文が転移評価に使った3つのベンチマーク（FAIL-TaLMs・MTU-Bench・BFCL）のうち、BFCL（Berkeley Function Calling Leaderboard）については公式サイトを直接確認した。論文の参考文献リストによれば、論文が引用しているBFCLの原典はPatil, S. G.らによる"The Berkeley Function Calling Leaderboard (BFCL): From Tool Use to Agentic Evaluation of Large Language Models"（ICML 2025）。公式サイトを見ると、BFCLは2026年4月12日更新時点で「V4」まで版が進んでおり、V1で導入されたAST（抽象構文木）評価指標、V2のエンタープライズ・OSS関数追加、V3のマルチターン対話、V4の「holistic agentic evaluation（総合的なエージェント評価）」と、段階的に評価範囲を広げてきたベンチマークだと分かる。OODA-Tool論文が転移評価で使ったBFCLのバージョンが具体的にV何時点のものかは、論文本文の記載からは特定できなかった。

コードは公開されておらず、手元での再現検証もしていない

この記事は論文PDF本文（v2、20ページ）と、評価に使われたToolDialの原論文、BFCL公式サイトを情報源としている。ただし、論文本文を確認した範囲では、OODA-Toolの実装コードやコントローラーの具体的なソースコードを公開しているGitHubリポジトリ等へのリンクは見当たらなかった——コードが非公開なのか、単に本文に記載がないだけなのかは、この記事の範囲では判別できない。FAIL-TaLMs・MTU-Benchの2つの転移評価ベンチマークについては、論文中での言及を確認したのみで、それぞれの原論文までは遡っていない。自分の手元で、既存のツール利用エージェントにこの4段階構造（Observe-Orient-Decide-Act）を実装して再現する検証も行っていない。Table 1・Table A2・Table A3として紹介した数値はすべて論文が報告した値であり、独立した第三者による追試の結果ではない。

関連記事: AIエージェントとは / MCPとは / RAG（検索拡張生成）とは

感想・指摘はコメント欄へ。