技術概要：SPIN – 産業タスクのための反復ナビゲーションによる構造的 LLM 計画

1. 問題定義

産業用大規模言語モデル（LLM）エージェントシステムは、計画と実行を分離することが多い。しかし、LLM プランナーは頻繁に構造的に無効なワークフロー（例：誤ったインデックス付け、無効な依存関係参照、存在しないエージェント名）や、不必要に長いワークフローを生成する。これらの問題により、ツール呼び出し、API 使用、実行時間におけるコストの増大と、実行の脆弱な失敗が生じる。

AssetOpsBench などの産業環境では、プランナーの出力が下流の実行モジュールに対する厳格なインターフェース契約として機能する。小さな構造的エラーはハードな失敗を引き起こし、根本原因がタスク推論にあるのか、それともインターフェースの脆弱性にあるのかを不明瞭にする。さらに、外部アクションがコストを支配する場合、部分的な進捗でユーザーの問い合わせに回答できるにもかかわらず、長く保守的なワークフローを最初から最後まで実行することは非効率的である。既存の研究は、推論や自己反省の改善に焦点を当てることが多く、プランナーと実行モジュールのインターフェースを暗黙のままとしており、ドメインに根ざしたベンチマークではフォーマットエラーが評価を支配する結果となっている。

2. 手法：SPIN

著者は、構造的妥当性を強制し、コストを考慮した実行制御を可能にする計画ラッパーであるSPIN（Structural LLM Planning via Iterative Navigation）を提案する。SPIN は 2 つの中核コンポーネントを通じて動作する。

A. 検証済み DAG 計画と修復

SPIN は、プランナーの出力を一般的なテキストではなく、実行可能な有向非巡回グラフ（DAG）インターフェースとして扱う。

• シリアライズ: 計画は、#TaskN、#AgentN、#DependencyN、#ExpectedOutputN の 4 つの整列したリストにシリアライズされる。
• 検証ループ: 検証器（_validate_plan_text）が以下の項目をチェックする。
  1. 4 つのリスト間の長さの一致。
  2. 1 から $N$ までの連続したインデックス。
  3. 有効な依存関係参照（直前のノードへのみ参照可能）。
  4. 許容されるエージェント名。
• 反復修復: 計画が無効な場合、検出されたエラーセットは修復プロンプトと共にプランナーにフィードバックされ、修正された DAG が生成される。このループは、有効な計画が生成されるか、再試行予算が尽きるまで継続する。

B. 早期停止を伴うプレフィックス評価

SPIN は、検証済みのワークフロー全体を実行するのではなく、シミュレーターとクリティックを用いて計画を段階的に評価する。

• プレフィックス反復: システムは、DAG の長さが増加するプレフィックス $p^{(k)} = \{n_1, \dots, n_k\}$ を評価する。
• シミュレーター（$S$）: 検索条件付きの「世界モデル」として機能する。ユーザーの問い合わせと現在のプレフィックスに基づき、実際の下流ツール呼び出しを実行することなく、実行状態の候補結果を予測する。AssetOpsBench では履歴軌跡データを、MCP Bench では内部知識を活用する。
• クリティック（$C$）: 現在のプレフィックスとシミュレートされた結果が、元の問い合わせに回答するのに十分かどうかを評価する。構造化された判断を返す。
  • status：ACCOMPLISHED、PARTIALLY_ACCOMPLISHED、または NOT_ACCOMPLISHED。
  • can_answer_now：十分性を示すブールフラグ。
  • rationale：短い説明。
• 停止ポリシー: can_answer_now が True かつ status が ACCOMPLISHED または PARTIALLY_ACCOMPLISHED になった時点で実行は停止する。この条件が満たされない場合、システムはデフォルトとして検証済みの計画全体を実行する。

3. 主な貢献

1. 契約ベースの計画ラッパー: 依存関係認識型 DAG 検証器とプレフィックス評価ループを組み合わせた手法。これにより、プランナーと実行モジュールの境界を明示的かつ機械が消費可能なものとする。
2. 実証的評価: 2 つの異なるベンチマークにおける評価。
   • AssetOpsBench: 外部ツール実行を伴う産業用アセット操作に焦点を当てたもの。
   • MCP Bench: 外部軌跡メモリなしでのマルチツール接地に焦点を当てたもの。
3. 失敗モード分析: SPIN の成果が、すべての種類の推論エラーを均等に修復するのではなく、実行行動（反復の削減、状態制御の改善）に集中していることを示す詳細な分析。

4. 実験結果

AssetOpsBench（261 シナリオ）

• 実行可能性: 検証と修復ループにより、複数のモデルで有効な計画を生成する成功率が 100% となり、ベースラインと比較して構造的エラー（リストの不一致、未知のエージェントなど）が大幅に減少した。
• 効率性: SPIN は実行されたタスクの総数を 1,061 から 623 に削減した。
  • ツール呼び出し: 1 回の実行あたり 11.81 から 6.82 に削減。
  • API 呼び出し: 1 回の実行あたり 34.05 から 19.97 に削減。
  • 実行時間: 198.44 秒から 143.53 秒に削減。
• 品質: 「達成（Accomplished）」率が 0.638 から 0.706 に向上し、「未達成（Not Accomplished）」率は減少した。
• コストのトレードオフ: 外部実行コストは低下したが、シミュレーターとクリティックのプロンプトによるオーバーヘッドにより、内部トークン使用量は増加した（送信トークンが約 111k から約 117k へ）。著者はこれを、高価な外部実行から内部検討への有利な転換と位置づけている。

MCP Bench（18 タスク）

• 汎化性: 検索データベースへのアクセスがない場合（LLM の内部知識のみに依存）でも、SPIN は GPT-OSS1 と Llama 4 Maverick の両方において、計画、接地、依存関係認識のスコアを向上させた。
• モデルのばらつき: Llama 4 Maverick において、SPIN は平均ラウンド数を 17.06 から 14.00 に、プロンプトトークンを大幅に削減した。GPT-OSS1 ではラウンド数は安定していたが、計画品質の指標は向上した。

除去実験と失敗分析

• コンポーネントの役割:
  • シミュレーター: 堅牢な中間状態推定に不可欠。これを除去すると、「ステップの反復」や「早期終了」の失敗パターンが再発した。
  • クリティック: 主に停止制御と実行長さの削減を担当。これを除去すると、より長く高価な実行となった。
• 失敗モード: SPIN は「ステップの反復」（約 35.8% から約 10.5% へ）と「終了条件の無知」を大幅に削減した。しかし、「明確化の要求失敗」や「検証」に関連する失敗は顕著に改善されなかった。これは、SPIN が不確実性に対する堅牢な安全策の追加ではなく、不要な継続の剪定に最適化されていることを示唆している。

5. 意義と主張

本論文は、産業用ツール利用エージェントシステムにおいて、構造的妥当性と実行コストは、生粋の推論長さよりも優先すべき第一級の関心事であると主張する。

• 最適化ターゲットの転換: 想像上の未来における検索品質に焦点を当てる先行研究（例：SPIRAL）とは異なり、SPIN は実際の下流実行ステップ、ツール呼び出し、API トラフィックの負担軽減に焦点を当てている。
• 実行可能インターフェース: 著者は、プランナーの出力を一般的な構造化テキストではなく、実行可能な DAG インターフェースとして扱うべきであると論じる。厳格な契約を強制し、早期停止を可能にすることで、SPIN はエージェントシステムをフォーマットエラーに対してより堅牢にし、コストの重い環境においてより効率的にする。
• 限定的な範囲: 著者は限界を認め、SPIN は不確実性下での明確化やフォールバック行動を自動的に改善しないことを指摘している。将来の研究では、明示的な明確化とフォールバックブランチを備えた条件付き計画へと SPIN を拡張すべきであると提案している。

要約すると、SPIN は、厳格な構造的検証とプレフィックスベースの実行制御を組み合わせることで、タスク達成率を維持または向上させながら、産業用 LLM エージェントの運用負担を大幅に削減できることを示している。