技術概要：水力学におけるマルチエージェント自律推論への道

問題定義

単一エージェントシステム（SAS）は、大規模言語モデル（LLM）駆動の科学的ワークフローにおけるデフォルトのパラダイムとなっており、計画、推論、ツールの実行を単一のコンテキストウィンドウを通じて、単一のモデルに依存しています。しかし、科学的調査の複雑さが拡大するにつれ、SAS アーキテクチャは構造的および認知的な天井に直面しています。ツールのドキュメント、観測履歴、プロンプト指示の累積的な流入がモデルのコンテキスト制限を急速に飽和させ、注意の希薄化とパフォーマンスの低下を招きます。さらに、すべての論理を単一のノードにルーティングすることは運用上のボトルネックを生み出します。エージェントがサブタスクで失敗したり、競合する専門分野の統合に苦労したりした場合、分析パイプライン全体が停止してしまいます。

水力学という特定の領域では、これらの課題が、データの本質的な多ソース性によってさらに悪化しています。沿岸の洪水ハザードを特徴づけるには、形式、解像度、物理量が異なる、根本的に異なる由来（例えば、潮位計記録、水深測量、リモートセンシング、非構造化グリッドモデル出力）の観測データを調整する必要があります。運用上の水力学は、さらに大気強制力、海洋境界、河川流出を取り込み、単一のスキーマ下での統合的なクエリに抵抗する断片化されたデータ景観を形成します。

手法

著者らは、ハリケーンによる高潮の予測に特化した水力学における科学的ワークフローを自動化するために設計されたマルチエージェントシステム（MAS）のプロトタイプを提示します。このシステムは、モノリシックなアーキテクチャから、レイヤー実行グラフ（LEG） を用いたグラフ構造オーケストレーションへと移行します。

コアアーキテクチャ

MAS は、実行時に動的に選択されたエージェントが LEG として配置された構成です。システムは、エージェントの識別子、機能、およびツールの許可リストを定義するレジストリを利用します。エージェントは以下のように分類されます：

1. 専門エージェント：厳格なツールの許可リストの下で動作し、相互補完的なデータクラス役割を担います。これらには以下が含まれます：
   • NHC：熱帯低気圧のガイダンス、ベストトラック、およびアドバイザリを取得します。
   • NOAA CO-OPS：観測および予測された水位を提供します。
   • USGS：測量に基づく高水位マーカーおよびイベントデータを提供します。
   • FEMA：洪水保険率マップおよびデジタルハザードレイヤーにアクセスします。
   • STOFS：運用上の高潮予報の等高線プロットを生成します。
   • OSM：Open Street Map タイルをソースとして取得します。
2. 汎用エージェント：ワークフローと統合を管理します：
   • グラフアーキテクト：レジストリから導出された自然言語ルーティングヒューリスティックに基づいて LEG を構築します。単一パイプラインを使用するか、並列トラックを使用するかを決定します。
   • コンソリデーター：下流のエージェントのためのコンテキストを圧縮するために、レイヤーからの並列出力を簡潔な要約に融合させます。
   • クロストラックマージ：複数の並列トラックからの出力を統合します。
   • イメージエージェント：STOFS や OSM からのイメージなど、イメージを最先端の LLM イメージ理解機能を用いて分析します。
   • レポーター：マージされた素材と元のクエリに基づいて最終応答を統合します。

オーケストレーション戦略

グラフアーキテクトは、厳密な制御ロジックをハードコーディングすることなくドメイン知識を捉える自然言語ルーティングヒューリスティックを用いて、ユーザーのクエリを LEG にマッピングします。LEG は以下の 2 つのトポロジーをサポートします：

• 単一パイプライン：順序付けられたレイヤーのシーケンス。
• 並列トラック：独立したサブクエリが個別のパイプラインに割り当てられ、後にマージされます。

重要なのは、システムがコンテキスト圧縮戦略を採用している点です。レイヤー内で複数の専門エージェントが並列に動作する場合、その出力は生のまま次の段階に渡されません。代わりに、コンソリデーターエージェントがそれらを一貫性のある Markdown ブロックに融合させ、コンテキストウィンドウの飽和を防ぎます。実行時は、すべてのツール呼び出しに対して構造化された監査証跡を維持し、引数、タイミング、コンテンツハッシュ、URL を記録して、データの由来と監査可能性をサポートします。

このプロトタイプは、Python ベースのツール呼び出しおよびイメージ理解に依存し、Anthropic および OpenAI の API とインターフェースを接続します（評価におけるすべてのエージェントのバックボーンモデルとして、特に Claude Sonnet 4.6 を使用）。

主要な貢献

1. レイヤー実行グラフ（LEG）オーケストレーション：本論文は、作業を同期されたステージ（レイヤー）にグループ化し、バリアでマージされる前に並列実行するグラフベースの調整戦略を導入します。これは、グローバルなレイヤーバリアとステージごとの同期を強制することでコンテキスト管理を支援する点で、標準的な有向非巡回グラフ（DAG）とは異なります。
2. ドメイン固有のルーティングヒューリスティック：システムは、グラフアーキテクト内で自然言語ヒューリスティックを利用してルーティング決定（例えば、高潮データに先立ってベストトラックデータをソースとして取得する、または観測された専門家と仮定の専門家を分離する）を行い、厳格で事前に定義されたプログラム的ワークフローに依存するのではなく、意思決定を行います。
3. 統合によるコンテキスト圧縮：並列出力を融合する専用のコンソリデーターエージェントの導入は、単一エージェントシステムに固有の「コンテキスト飽和」ボトルネックに対処し、LLM のコンテキストウィンドウを圧倒することなく、複雑な多ソースクエリを処理することを可能にします。
4. 由来意識のある実行：システムは、共有されたトレース識別子で各ツール呼び出しをログ記録し、報告された記述や量の由来を精査するための台帳を作成します。

結果

プロトタイプは、単一専門家の検索から複雑なマルチトラック並列問い合わせまで、6 つの複雑さカテゴリにわたる37 のクエリで評価されました。すべての実験は Claude Sonnet 4.6 を使用しました。

• パフォーマンス：システムは、93.6% の事実精度を達成し、100% のパス率（ゼロの実行エラー）を記録しました。
• 複雑さ別精度：
  • 単一エージェントクエリ（例：NHC の嵐の分類）は 99.5% の精度を達成しました。
  • マルチエージェント線形パイプラインは 90.1〜95.0% の精度を達成しました。
  • 並列トラッククエリは 94.9〜95.9% の精度を達成しました。
  • 最も低い精度（82.2%）は「NHC→N+U」カテゴリで発生しました。ここでは、システムは異なる垂直基準を持つ独立した機器からの測量された高水位マーカーと、ゲージ観測を調整する必要がありました。
• 堅牢性：
  • ストレステスト：1 つから 5 つの独立したサブクエリにスケールアップしても、精度は 90% 以上を維持しました。
  • 敵対的堅牢性：システムは、不可能なシナリオ（存在しない嵐や内陸の場所など）に対してデータを幻覚させることはなく、5 つの有害な前提のうち 4 つを検出しました。
  • フォールトトレランス：シミュレートされた API 障害（NOAA CO-OPS、USGS、または FEMA）において、システムはクラッシュすることなく実質的な部分的回答を返すことで、優雅に劣化しました。
• アブレーション研究：
  • 適応型グラフアーキテクトを静的パイプラインに置き換えると、事実精度が 28.7 ポイント低下し、適応型計画が重要であることを確認しました。
  • コンソリデーターエージェントを削除すると、事実精度は 4.6 ポイント低下しましたが、生の技術トークンの存在によりソース帰属スコアが向上しました。これは、一貫性と生データ保持の間のトレードオフを浮き彫りにしました。
  • レポーターエージェントを削除すると、事実精度は 10.8 ポイント低下し、最終統合ステップの価値を実証しました。
• コスト：システムは、行われた作業に対して計算効率的です。専門エージェントはトークンの 92.2% を消費しましたが、オーケストレーションのオーバーヘッド（アーキテクト、コンソリデーター、レポーター）はわずか約 6% でした。

意義と主張

本論文は、プランナー主導のグラフ構造マルチエージェントオーケストレーションが、モノリシックな単一エージェントアーキテクチャを制約するコンテキスト飽和のボトルネックを有意に緩和できると主張しています。著者らは、マルチエージェントシステム（MAS）が通信や遅延に関する新たな複雑さを導入する一方で、専門的で協調的な推論の利益が調整オーバーヘッドを上回る地球科学モデリングのような高複雑度・多スケールの調査においては、実行可能な戦略であると論じています。

この研究は、状態とツールの実行を複数のコンテキストウィンドウに分散させることで、単一のエージェントが異種データに圧倒されるのを防ぐことを示唆しています。さらに、専門エージェントが検索を扱い、汎用エージェントが計画と統合を扱うという「関心の分離」は、複雑な科学的ワークフローにとって構造的に不可欠な分解を生み出します。

著者らは、プロトタイプの現状について控えめに述べており、それは「比較的軽量」であり、水力学モデル自体を実行するのではなく、API に大きく依存していると指摘しています。また、現在の由来ログ記録戦略は大規模なワークフローにとって最適ではない可能性があり、システムは現在、冗長性とエラー回復のための「監督者」エージェントを欠いていることを認めています。しかし、結果は、このアーキテクチャが正確で、回復力があり、地球科学の他のサブドメインへ拡張可能であることを示しています。