💬 NLP

Table-as-Search: Formulate Long-Horizon Agentic Information Seeking as Table Completion

本論文は、長期的な情報探索をテーブル補完タスクとして再定式化することで、検索のコヒーレンスと状態追跡を維持し、多様な検索戦略を統一する構造化フレームワークであるTable-as-Search（TaS）を導入し、それによって堅牢性と効率性の両面において最先端のベースラインを大幅に上回る性能を実現する。

原著者： Tian Lan, Felix Henry, Bin Zhu, Qianghuai Jia, Junyang Ren, Qihang Pu, Haijun Li, Longyue Wang, Zhao Xu, Weihua Luo

公開日 2026-02-09

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Tian Lan, Felix Henry, Bin Zhu, Qianghuai Jia, Junyang Ren, Qihang Pu, Haijun Li, Longyue Wang, Zhao Xu, Weihua Luo

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

問題点：「情報の海で迷子になる」エージェント

あなたは、非常に賢いが少し忘れっぽいリサーチ助手（AIエージェント）を雇ったと想像してください。その助手に、インターネット上の特定の情報を探すよう依頼します。例えば、「北米にある、昨年売上が50%以上成長したペット用品店を30軒探し出し、それぞれの販売責任者の電話番号を調べてください」といった複雑な質問です。

現在のAIアシスタントは、これを頭の中で「長く連続した物語」として書き出そうとすることで解決しようとします。「まず店舗Aを探して、次に店舗Bを探して、それから成長率をチェックして……」と考えます。しかし、調査が深まるにつれ、この精神的な「物語」は膨大なものになります。やがate、アシスタントは圧倒されてしまいます。物語の冒頭を忘れてしまったり、すでに調べた店舗を把握できなくなったり、あるいは膨大なメモの量に混乱したりします。論文では、これを**「真ん中で迷子になる（lost in the middle）」**現象と呼んでいます。正しい店舗は見つけても、電話番号を書き留めるのを忘れてしまったり、メモリが混雑しすぎて事実を捏造（ハルシネーション）したりする可能性があるのです。

解決策：「Table-as-Search (TaS)」フレームワーク

著者らは、この作業を整理するための新しい方法を提案しています。それは、長い、まとまりのない物語を書く代わりに、リサーチ業務を**「表（スプレッドシート）を埋める作業」**へと変換することです。

次のように考えてみてください：

従来の方法： 巨大な倉庫の中を歩き回りながら、牛乳や卵を忘れないようにと、買い物リストを記憶し続けようとする状態。
新しい方法 (TaS)： クリップボードとグリッド（格子状の表）を持っています。製品を見つけるたびに、それを特定のボックスに書き込みます。もしボックスが空であれば、次に何を見つけるべきかが明確に分かります。

仕組み：3つの役割

このシステムは、デジタルスプレッドシートを囲んで協力し合う、AI「エージェント」のチームを使用しています。

プランナー（マネージャー）： このAIはユーザーの質問を確認し、スプレッドシートをセットアップします。必要な列（例：「店舗名」「成長率」「電話番号」）を決定します。そして、空のボックスを見て、「よし、これらの行を埋めるために30軒の店舗を見つける必要がある」と判断します。
サブエージェント（ワーカー）： これらは検索エンジンです。マネージャーは彼らを送り出し、候補を見つけさせます。
- 行の拡張 (Row Expansion)： まだテーブルに十分な数の店舗がない場合、ワーカーは新しい行として追加するための新しい店舗を探しに行きます。
- セルの入力 (Cell Population)： 店舗は見つかったものの「電話番号」のボックスが空である場合、ワーカーはその特定の情報を探すためにピンポイントで動きます。
外部データベース（ファイリングキャビネット）： AIの短期記憶（制限があります）の中にすべての検索結果を保持しようとする代わりに、スプレッドシートは外部データベースに存在します。AIは今必要な部分のテーブルだけを参照します。これにより、AIの「脳」は単なるデータの保存ではなく、思考のためにクリアな状態を保つことができます。

検証内容

論文では、この手法を3種類の困難な検索タスクでテストしました。

ディープ・サーチ (Deep Search)： 藁の中から一本の針を見つけるようなタスク（例：「これら5つの特定の条件に合致する唯一の歌手を見つけてください」）。
ワイド・サーチ (Wide Search)： 大量の針を見つけるようなタスク（例：「2005年から2015年までのすべての受賞者をリストアップしてください」）。
ディープ・ワイド・サーチ (DeepWide Search)： 最も困難なタスク。大量の針を見つけ、かつ、それぞれが厳格なルールを満たしていることを検証するタスク（例：「これら5つのルールを満たし、かつ電話番号も取得できる店舗を30軒見つけてください」）。

結果：なぜ優れているのか

論文では、TaSが現在の最先端の手法（多くの大手AI企業が使用している標準的な「ReAct」法など）よりも大幅に優れていると主張しています。

迷子にならない： テーブルが「何が完了し、何が不足しているか」を正確に追跡するため、非常に長い検索プロセスであっても、AIは計画を見失うことがありません。
効率的である： 競合よりも少ない検索試行回数で、より良い回答を見つけ出しました。力任せの探索（ブルートフォース）ではなく、精密に動作したのです。
小さな脳でも機能する： 驚くべきことに、この「テーブル」方式を用いた小さくて安価なAIモデルが、従来の「物語」方式を用いたはるかに大規模で高価なAIモデルに勝利しました。構造化によって、小さなモデルが本来の実力を超えた成果を出せたのです。
柔軟である： 「マネージャー」は「ワーカー」を入れ替えることができます。例えば、電話番号を見つけるための特化したツールがある場合、システム全体を壊すことなく、それを組み込むことができます。

要約

論文の主張は、AIエージェントが長く複雑なインターネット上のスカベンジャーハント（宝探し）を行う際、意識の流れのような、まとまりのない情報の連なりに頼るべきではないということです。代わりに、メモを整理するために構造化されたテーブルを使用すべきです。このシンプルな変更により、混乱を防ぎ、より正確な回答を見つけ、より少ない計算資源でより多くの成果を上げることが可能になります。

技術要約: Table-as-Search (TaS)

1. 問題定義

現在のエージェント型情報探索（InfoSeeking）システム、特に大規模言語モデル（LLM）に依存するシステムは、**長期的な探索（long-horizon exploration）**において重大な課題に直面しています。ReActのような従来のパラダイムは、検索状態（計画手順と膨大な検索結果）を単一の非構造化されたプレーンテキストのコンテキスト内で管理します。このアプローチは本質的に脆弱であり、複雑なタスクにおいて以下の問題を引き起こします：

「中間での消失（Lost in the Middle）」現象： インタラクションのホライゾンが拡大するにつれ、関連情報の密度が希薄化し、エージェントは計画手順や検索履歴を見失う原因となります。
状態の忠実度の喪失（State Fidelity Loss）： 数千の検索結果とそれに対応する計画ステップを単一のテキスト・トラジェトリで追跡することは、深刻なハルシネーション（幻覚）とエラーの伝播を招きます。
複雑なシナリオにおける非効率性： エージェントは、特に広範な集計と深い検証の両方を必要とするタスクにおいて、単一のフォワードパス内で情報抽出と状態追跡を同時に行うことに苦慮します。

本論文は、以下の3つの異なる情報探索パラダイムを同時に扱う際のギャップを特定しています：ディープ・サーチ（Deep Search）（精密なターゲット・フィルタリング）、ワイド・サーチ（Wide Search）（広範な情報の集約）、そして困難なディープワイド・サーチ（DeepWide Search）（広範な探索と深い検証の同時実行）です。

2. メソドロジー: Table-as-Search (TaS)

これらの限界に対処するため、著者らは情報探索を**テーブル補完（Table Completion）タスクとして再定式化する構造化計画フレームワークであるTable-as-Search (TaS)**を導入します。

コア・アーキテクチャ

構造化スキーマ： 自由形式のテキスト生成の代わりに、TaSはユーザーのクエリ $q$ を、キー候補を表す $K$ 、制約を表す $C$ 、および必要な情報を表す $I$ からなる構造化スキーマ $S = \langle K, C, I \rangle$ にマッピングします。
外部データベース： フレームワークは、外部データベース（例：MongoDB）内に構造化されたテーブルを維持します。行は候補エンティティを表し、列は属性または制約を表します。
- 埋められたセル（Filled Cells）： 検索履歴と結果を厳密に記録します。
- 空のセル（Empty Cells）： 明示的な保留中の検索計画として機能します。
オフローディング： 膨大な検索結果は外部データベースにオフロードされ、エージェントの限られたコンテキスト・ウィンドウを受動的な情報ストレージではなく、複雑な推論のために保持します。

マルチエージェント・オーケストレーション

TaSは、共有データベースを中心としたマルチエージェント・システムによって実装され、以下の3フェーズを実行します：

テーブルの初期化： 中央の**プランナー（Main-Agent）**がクエリを解析し、テーブル・スキーマを構築します。
動的なオーケストレーション： プランナーは反復的にアクションを選択します：
- 行の拡張（Row Expansion）： 候補が不十分な場合、プランナーは新しい候補を発見するための多様な検索戦略を策定します（サブエージェントが並列で広範な検索を実行）。
- セルの充填（Cell Population）： 候補は存在するが情報が不完全な場合、特定のセルを埋めるためにサブエージェントが並列に派遣されます（制約の検証または情報の収集）。
回答の合成： 飽和状態に達すると、プランナーはデータベースから構造化された証拠を抽出し、最終的な回答を合成します（例：ディープ・サーチのための制約の相互検証、またはワイド・サーチのためのSQLクエリの実行）。

統一された表現

TaSは、以下のための統一された表現を提供します：

ディープ・サーチ： すべての制約を満たす一意の候補行の特定（ $|C| > 0$ ）。
ワイド・サーチ： 最小限の制約の下で大量の候補に関する情報を収集（ $|I| > 0$ ）。
ディープワイド・サーチ： 厳格な制約下での候補発見の最大化と、それに続く高密度な情報収集（ $|C| > 0, |I| > 0$ ）。

3. 主な貢献

フレームワークの革新： 長期的な情報探索を構造化されたテーブル補完タスクとして再定式化し、ディープ、ワイド、およびディープワイドの検索パラダイムを統合する初のフレームワークであるTaSを提案しました。
状態管理： 「保留中のアクション（空のセル）」と「検証済みの履歴（埋められたセル）」を分離することで、検索状態を精密に管理するメカニズムを導入し、「中間での消失」問題を軽減しました。
ベンチマークの作成： 実世界のEコマース・ビジネス開発シナリオに基づいた、挑戦的なDeepWide Searchベンチマークをキュレートしました。これは、ハイブリッド検索タスクに対する高品質な公開評価の欠如に対処するものです。
モジュール設計： 特化したディープ・サーチ・エージェント（例：ファインチューニングされたモデル）がサブエージェントとして機能できる「プラグ・アンド・プレイ」型のアーキテクチャを示し、計画と実行をデカップリング（分離）しています。

4. 実験結果

3つのベンチマークカテゴリ（GAIA/BrowseComp-ZH（ディープ・サーチ）、WideSearch（ワイド・サーチ）、およびキュレートされたDeepWide Search）にわたって広範な実験が行われました。

性能の優位性： TaSは、3つの全パラダイムにおいて、最先端のベースライン（マルチエージェントReActやGemini DeepResearchなどの商用システムを含む）を大幅に上回りました。
- ディープ・サーチ： GAIAにおいて、コスト効率の高い Gemini-2.5-Flash を使用したTaSは、マルチエージェントReActのベースラインを +14.0% 上回り、構造化された状態管理によって小型モデルが大型モデルに匹敵できることを証明しました。
- ワイド・サーチ： Claude-Sonnet-4 (No-Think) を使用したTaSは、計算負荷の高い Claude-Sonnet-4 (Thinking) ベースラインと同等の成功率を達成しつつ、Max@4メトリクスにおいて大幅に上回りました（9.1% vs 6.5%）。
- ディープワイド・サーチ： TaSは、独自の Gemini DeepResearch システムを、Column-F1で +4.7%、Item-Precisionで +5.1% 上回りました。
効率性と堅牢性：
- 検索効率： TaSは、ベースラインと比較して同等またはより少ないツール使用量で高いパフォーマンスを達成しており、その利得がブルートフォース的な検索のスケーリングではなく、計画の質に由来することを証明しています。
- 堅牢性： タスクの複雑さ（難易度レベル）が増すにつれ、TaSとベースラインの性能差は広がります。TaSは、ベースラインが大幅な低下（>30%のドロップ）に見舞われる「Hard」ティアにおいても安定性を維持しています。
- テスト時スケーリング（Test-Time Scaling）： TaSは、非構造化ReActよりも、増加した推論計算量（スケーリング $N$ ）からより効果的に恩恵を受け、 $N$ が増加するにつれて性能差が拡大します。
アブレーション研究： **プランナー（Main-Agent）**が決定的なボトルネックであることが特定されました。プランナーをダウングレードすると大幅な性能低下を招く一方で、サブエージェントのダウングレードによる影響は限定的でした。これは、効果的な探索をオーケストレートする役割としてのプランナーの重要性を裏付けています。

5. 意義と主張

本論文は、TaSがエージェント型システムにおける、非構造化テキスト生成からデータ中心の構造化計画へのパラダイムシフトを象徴していると主張しています。

アーキテクチャの直交性： TaSは、コンテキスト管理（要約など）やモデル学習（RLなど）の最近の進歩に対して直交しています。テキストを圧縮するのではなく、構造化されたスキーマを課すことで状態のオフロードを実現しています。
スケーラビリティ： 本フレームワークは、効果的な長期情報探索が、基盤モデルの生の推論能力よりも、構造化された状態管理に依存していることを示しています。これにより、TaSアーキテクチャと組み合わせることで、コスト効率の高い小型モデルが複雑なタスクを実行できるようになります。
産業への適用可能性： 計画と実行を分離することで、TaSは高頻度の検索アクションに対して特化したコスト効率の高いモデルの統合を可能にし、Eコマース・ビジネス開発のような産業規模のアプリケーションにおける実行可能なソリューションとなります。

認められた限界事項：

非検索タスク： 構造化されたスキーマは、内部知識のみに依存するタスクや単純な指示遂行を行うタスクに対して硬直性を導入する可能性があり、非検索型のGAIAインスタンスにおいて性能の変動を招くことがあります。
プランナーへの依存： パフォーマンスは現在、中央のプランナーの推論能力によって制限されています。
評価のスケーラビリティ： DeepWideベンチマークは、タスクのオープンエンドな性質上、人間の検証に依存しており、クローズドドメインのベンチマークと比較して大規模な再現性に制限があります。