AI検索エージェントは「デモでは完璧に動くのに、本番では壊れる」。検索が不完全な証拠しか返さない、失敗したアクションを延々とリトライする、実行時間とコストの上限を突破する——本番運用を妨げるこの3つの問題に対して、AIエージェント向けのWebインフラを提供するTinyFishが、本番向けのエージェント型検索アーキテクチャを体系化し、設計手法として公開しました。基盤モデルの周囲に7つのフェーズからなる制御ループを構築するこの設計は、OpenBenchmarksのコードエージェント向けWeb検索ベンチマークで完了率79.0%、タスクあたりの中央値コスト0.050ドルという結果を達成しています。
公開されたのは、「本番向けエージェント型検索アーキテクチャ」と「深層リサーチシステム構築の教訓」の2本の技術ガイドです。前者は、検索の計画立案、証拠の評価、失敗の処理、そしてモデルの推論と決定的な実行の境界管理という、自律型検索エージェントの設計全体を扱います。後者は、実際の深層リサーチシステムを開発する中で得た具体的な教訓を整理した内容です。
デモは成功するのに、なぜ本番で失敗するのか
デモ環境と本番環境の差は、環境の複雑さではなく「失敗の扱い方」にあります。デモでは検索結果が返ってくれば成功とみなされますが、本番では要求された証拠が揃っているか、競合する情報にどう対処するか、予算内で完了できるかまでが問われます。
TinyFishはこの問題を、個別のバグではなくシステム全体で解決すべき構造的問題として捉えます。モデルは推論に専念し、状態管理、ツール実行、証拠処理、実行時ポリシー、出力検証は周囲のアプリケーションが担当する。この役割分担が設計の核です。
エージェント型検索アーキテクチャとは何か
エージェント型検索アーキテクチャとは、AIエージェントが検索の計画立案、情報源へのアクセス、証拠の評価、次の行動の決定を自律的に繰り返しながら、新しい情報を得るたびにアプローチを適応させるシステム設計のことです。モデル単体の能力に頼るのではなく、推論と実行を分離して制御可能なシステムとして構築する点に特徴があります。
設計の基礎には、2026年2月に公開されたアーキテクチャに関するプレプリントがあります。この論文は、型付きツールインターフェースを通じて推論と実行を分離することを提唱し、詳細なトレーシングに加えて、トークン数、実行時間、総コスト、ツール呼び出し回数に対する厳格な上限設定を不可欠のガードレールとしています。
TinyFishは、TinySearch、TinyFetch、TinyBrowser、TinyAgentという4つのWebプリミティブを基盤に、この設計を具体化しています。どこまでをモデルに任せ、どこからをコードで制御するか。2本のガイドは、この境界線の引き方を示したものです。
7つのフェーズで構成される実行制御ループ
1回の検索実行は、7つのフェーズに分割されます。各フェーズが明確な役割を持ち、その結果が次の行動を決定します。
- タスク定義 — 目標を「証拠契約」に変換します。必要なフィールド、情報源、鮮度、完了条件を定義します。
- 検索計画 — 独立した要件と依存関係のある要件を分離し、依存クエリは先行する回答を待たせます。
- 最初のルート選択 — システムが持つ証拠に関する知識に基づいて、ツールを選択します。
- 発見・選択・取得 — ページのコンテンツが届くまでは、検索結果を「候補」として扱います。
- 評価 — 証拠を「十分」「不完全」「競合」「アクセス不能」「予算枯渇」のいずれかに分類します。
- 回復またはエスカレーション — クエリの修正、リトライ、情報源やアクセス手段の変更を行います。
- 停止と検証 — 「完了」「不完全」「失敗」「キャンセル」「要人的レビュー」のいずれかを返します。
フェーズ2とフェーズ6は、先行研究の知見を実装に落とし込んだ部分です。ACL 2025で発表されたChainRAGは、多段階の質問分解の過程で重要なエンティティが消える「lost-in-retrieval」問題を指摘しています。検索計画を独立要件と依存要件に分離するのは、この消失を防ぐためです。一方、フェーズ6の裏付けは、初期の検索が不十分な場合に推論中で追加クエリを生成するよう学習するSearch-R1です。7つのQAデータセットの評価では、学習型マルチターン検索がRAGベースラインをQwen2.5-7Bでは41%、Qwen2.5-3Bでは20%上回りました。
実行全体には、トークン数、実行時間、総コスト、ツール呼び出し回数の上限が設定されます。予算の限界に達した場合、エージェントはもっともらしい推測で埋めるのではなく、「部分的+要レビュー」として正直に停止します。これが、不完全な結果を人間のレビューにつなぐ最後の防衛線です。
ツール選択は「情報のギャップ」で決まる
ルーティングで重要なのは、固定の段階を順に昇ることではなく、情報のギャップに応じて適切なプリミティブを選ぶことです。TinyFishは初期状態に応じて4つのプリミティブを使い分けます。
| 初期状態 | 使用するプリミティブ | アプリ側が保持する責務 |
|---|---|---|
| 情報源の場所が不明 | TinySearch（Search） | クエリ計画、ソースポリシー、停止判断 |
| URLが既知で読み取り可能 | TinyFetch（Fetch） | 完全性チェック、主張の検証 |
| アプリがページ操作を制御 | TinyBrowser（Browser） | すべてのアクション、リトライ、チェックポイント |
| 複数ページにまたがる意思決定 | TinyAgent（Web Agent） | ビジネスルール、予算、検証 |
弱い結果にはより良いクエリが必要で、競合する情報源にはより強力な証拠が必要です。重いツールへのエスカレーションは、どちらの問題も解決しません。この原則は、漫然と「より高度なツール」へ切り替える設計への警告でもあります。
失敗の種類に応じたリトライの設計
リトライは「何が失敗したのか」に基づいて設計します。一時的なエラーであれば同じリクエストの再実行が正当化されますが、証拠の不完全性や情報源同士の競合は、別のアプローチが必要です。リトライの回数も、明確な上限を設定した上で運用します。
特に注意が必要なのは、ブラウザ操作を伴うリトライです。単純に同じ操作を再実行すると、フォームの二重送信のような意図しない副作用が発生します。すでに完了したアクションを考慮し、チェックポイントごとに状態を確認してから再開する設計が求められます。
深層リサーチシステムの進化が示した設計の教訓
「深層リサーチシステム構築の教訓」では、実際のシステムを3段階に進化させる中で得られた知見が紹介されています。この変遷は、エージェント設計における「推論と実行の境界」の探し方そのものです。
v1: プランナー方式は文脈を失う
初期アーキテクチャは、オーケストレーターがプランナーに指示し、新しいLLM呼び出しで計画を立てる方式でした。構造化された状態は渡りますが、「価格リスクにだけ焦点を当てて」といったフォローアップの文脈が反映されず、意図が徐々に逸れていく問題が発生しました。
v2: サブエージェント方式はレイテンシとコストが増大
次の段階では、クエリごとにサブエージェントを起動する方式を採用しました。しかしオーケストレーターが起動、待機、マージを繰り返すうちに、レイテンシとコストが増大。処理の分散と引き換えに、システム全体の効率が悪化しました。
v3: ツールコール方式で決定的な処理をコードに戻す
最終的に選ばれたのは、検索、フェッチ、ブラウズといった決定的なステップをツールコールとして実装し、オーケストレーターにはランク付けされた情報源と抽出済みの主張だけを渡す方式です。コンテキスト量、レイテンシ、コストがすべて削減され、文脈の維持というv1の課題も解消されました。
情報源の重み付けについても重要な示唆があります。同じ情報源でも、リサーチの目的が「製品の評判分析」ならソーシャル投稿の重みが高まり、「失業率の調査」なら政府報告書の重みが高まります。単一の品質スコアではなく、リサーチの目的に応じたランク付けが必要です。
制御ループがもたらす完了率とコストの両立
この設計の有効性は、数値にも現れています。OpenBenchmarksのコードエージェント向けWeb検索ベンチマーク（100タスク、gpt-5.6-sol、2026年9月26日時点）では、TinyFishは完了率79.0%を達成。タスクあたりの中央値コストは0.050ドルで、トークン使用量も比較対象の中で最小でした。高精度な結果を低コストで安定的に出すという、本番運用のニーズに直接応える結果です。
この結果を支えているのが、制御ループの剛性です。検索のたびに計画を練り直すのではなく、決められたフェーズに従って、評価、回復、停止を機械的に実行する。その徹底が、モデルの性能差だけに依存しない安定した運用を可能にしています。
本番適用の分かれ目はモデルではなく設計にある
TinyFishの2本のガイドが示したのは、モデルの推論能力を最大限に引き出すためのシステム設計の全体像です。推論と実行の分離、7フェーズの制御ループ、失敗の種類に応じたリトライ、情報ギャップに基づくルーティング、目的に応じた情報源の重み付け。どれも単独では新しいものではなく、本番運用に耐える構造として組み合わせた点に価値があります。
AIエージェントの競争軸は、モデルの性能差から、いかに制御し、検証し、コストを管理するかという「運用設計」に移りつつあります。TinyFishの設計手法は、その新たな競争軸におけるひとつの参照点になるでしょう。
