TinyFish、本番環境向けAIエージェントのためのアージェンティック検索アーキテクチャを解説

AI検索エージェントは、 AI検索エージェント がデモでは動作しても、検索が不完全なエビデンスを返したり、リトライが失敗したアクションを繰り返したり、実行が時間やコストの上限を超えたりすると、本番環境のワークロードでは失敗することがある。 TinyFishはAIエージェント向けのウェブインフラを提供する企業で、これらの課題に対応する2本の技術ガイドを公開した。1つ目は 本番環境向けのアージェンティック検索アーキテクチャを定義し、2つ目は ディープリサーチシステムの構築から得られた教訓を共有している。両者を合わせて、自律型検索エージェントがどのように検索を計画し、エビデンスを評価し、障害に対処し、モデルの推論と決定論的実行の境界を管理できるかを検証している。 

TL;DR

TinyFishはアージェンティック検索アーキテクチャと、ディープリサーチシステム構築から得られた主要なエンジニアリングの教訓を発表した。4つのウェブプリミティブ（TinySearch、TinyFetch、TinyBrowser、TinyAgent）の上に構築されたこのシステムは、ベースモデルを中心とした7フェーズの制御ループで動作する。OpenBenchmarksにおいて、 TinyFishはコーディングタスクで79.0%の完了率を達成 しつつ、最も低い中央値タスクコスト（$0.050）とトークンフットプリントを実現しており、独立したプランナーではなく厳格な制御ループ、障害固有のリトライ、統合された推論の重要性が際立っている。

アージェンティック検索アーキテクチャとは？

アージェンティック検索アーキテクチャ により、AIエージェントは検索を計画し、ソースにアクセスし、エビデンスを評価し、新しい情報が入手可能になった際にアプローチを適応させることができる。モデルは推論を担い、周囲のアプリケーションが状態管理、ツール実行、エビデンス処理、ランタイムポリシー、出力検証を管理する。これらのコンポーネントが連携することで、エージェントは不完全な結果、回復可能な障害、変化する情報要件に対応できる。

TinyFishのアーキテクチャは、 2026年2月のアーキテクチャプレプリントから基盤となる概念を取り入れており、これは型付きツールインターフェースを通じて推論を実行から分離している。この論文では、詳細なトレーシングに加え、トークン、実行時間、総コスト、ツール呼び出しに対する厳格な上限を含む、不可欠なシステムガードレールを確立している。

本番環境での検索実行はどのように機能するのか？

TinyFish は1回の実行を7つのフェーズに分割する:

1. タスクの定義: ゴールを「エビデンス契約」に変換する。必須フィールド、ソース、鮮度、完了ルールを定める。
2. 検索の計画: 依存しないニーズと依存するニーズを分離する。依存するクエリは、先の回答を待つ。
3. 最初のルートの選択: 証拠についてシステムが何を知っているかに基づいてツールを選択します。
4. 発見、選択、取得： ページのコンテンツが届くまで、検索結果は候補として扱います。
5. 評価： 証拠を十分、不完全、矛盾、アクセス不能、予算枯渇のいずれかとして分類します。
6. 復旧またはエスカレーション： クエリを修正し、再試行し、ソースを変更するか、アクセス方法を変更します。
7. 停止して検証： 完了、不完全、失敗、キャンセル、または人間によるレビューが必要、を返します。

Phase 2 は既知の失敗に対処します。 ChainRAG (ACL 2025) はこれを「lost-in-retrieval」問題と呼んでいます。これは、マルチホップの質問分解の過程で重要なエンティティが消えてしまう問題です。Phase 6 は Search-R1に基づいています。これは、初期の検索が不十分な場合に、モデルが推論中に追加の検索クエリを生成することを学習できる方法を実証したものです。7つのQAデータセットにおいて、その学習されたマルチターン検索は RAG ベースラインを 41%(Qwen2.5-7B)、20%(Qwen2.5-3B) 上回りました。

検索エージェントはどのようにツールをルーティングすべきでしょうか？

ルーティングは、固定された階層ではなく、情報のギャップに従うべきです。

エスカレーションが常に解決策とは限りません。弱い結果にはより良いクエリが必要です。矛盾する情報源にはより強力な証拠が必要です。より重いツールはどちらも解決しません。

リトライは障害の種類に基づいて行うべきであり、定義された上限内に留める必要があります。一時的なエラーであればリクエストの再試行が正当化される場合がありますが、不完全または矛盾する証拠の場合には異なるアプローチが必要です。ブラウザのリトライでは、意図しない結果（同じフォームを2回送信するなど）を避けるため、すでに完了したアクションも考慮しなければなりません。

TinyFishはディープリサーチの構築から何を学んだのか？

ディープ リサーチエージェントは検索を行い、 ウェブを閲覧し、出典付きの包括的なレポートを生成します。技術的な課題のほとんどは、コンテキスト管理、システムオーケストレーション、プロダクトデザインをめぐるものでした。

教訓 #1: 独立したプランナーの削除

初期の反復では、毎回新たに呼び出されるスタンドアロンのプランナーを使用していました。プランナーに渡されるのは構造化された状態のみでした。「東南アジアの価格リスクのみに焦点を当てて」といったフォローアップの質問に対し、エージェントは広範な市場調査へと話が逸れてしまうことがありました。TinyFishはその後、計画をオーケストレーター自身の統合された推論ループの中に移動させました。

教訓 #2: サブエージェントの削除：

TinyFishは 当初、検索クエリごとに個別のサブエージェントを割り当てており、これがコンテキスト切り替えのオーバーヘッド、レイテンシ、コストを増大させていました。チームは後により、検索結果のランキング、情報源の分類、証拠の抽出といった反復可能なタスクを、これらのサブエージェントをツール呼び出しに置き換えて処理するようにしました。これによりオーガストレーターに返される情報量が削減され、調査計画や次に何を調査すべきかの判断に集中できるようになりました。

教訓 #3- リサーチャーの適合：

TinyFishは 当初、情報源のカバー範囲を重視してリサーチシステムを最適化していましたが、ユーザーは裏付けとなる証拠の質と関連性をより重視していました。チームは調査目的を考慮するよう情報源のランキングを調整し、ドメインの優先、除外、制限を管理するコントロールを追加しました。また、LLMジャッジを使ってレポートの関連性、証拠の強さ、引用の信頼性、情報源の多様性を評価する内部評価ハーネスも開発しました。

コストとレイテンシはどのように積み上がるのか？

TinyFishは単一の呼び出しではなくタスク全体に対して予算を割り当てます：

• タスクのレイテンシ ＝ 計画 ＋ 検索 ＋ 取得 ＋ 評価 ＋ リトライ ＋ 対話ステップ ＋ キューイング。
• タスクのコスト ＝ トークン ＋ ツール呼び出し ＋ ページまたはブラウザの利用 ＋ リトライ ＋ インフラ。

SearchAgent-X （ICLR 2026）がその理由を示しています。完全一致検索はオーバーヘッドを生み、粗い検索は余分な推論を強いていました。その修正により、テストされたベースラインに対して最大3.4倍のスループットと5倍低いレイテンシを達成しました。

TinyFishは検索とフェッチの比較でどうなのか？

OpenBenchmarksはモデル（gpt-5.6-sol）、100タスクと予算を固定し、プロバイダーのみを変更します。スコアは3回の実行の平均値です。

出典: OpenBenchmarksボード、2026年9月26日更新。タスクはエンタープライズドキュメントのみを対象とする。

OpenBenchmarksは検索のみの結果も別途報告している。その構成では、TinyFishは59.3%のタスク完了率を達成したのに対し、Perplexityは77.3%、Firecrawlは70.3%、Exa Fastは66.3%だった。利用可能な検索機能が異なるため、これらの結果を検索・取得のスコアと直接比較すべきではない。

重要なポイント

• 検索1回ではなく、軌道全体を制御する。
• 情報格差によるルーティングを行い、アクセスが失敗した場合にのみエスカレーションしてください。
• 計画と実行を1つの推論ループの中に保ちます。
• 決定論的なステップはサブエージェントではなく、ツール呼び出しに移しましょう。
• 研究目的ごとに情報源をランク付けし、単一の品質スコアによらないようにしましょう。

以下をお読みください アーキテクチャガイド、その ディープリサーチから得られた教訓 そして TinyFish ドキュメント.

_{本記事の着想とリソースを提供してくれたTinyfishチームに感謝します。この記事はTinyFishの提供です。}

この記事 TinyFish、本番環境向けAIエージェントのためのエージェンティック検索アーキテクチャを解説 最初に掲載されたのは MarkTechPost.