Mozilla AIが問う：あなたのエージェントのためにWebを検索するのは誰か？
Mozilla AIは、モデルとは独立して検索サービスを選べるOtariによって、統合型のエージェント検索に異議を唱えている。あなたのエージェントのためにWebを検索するのは誰か？ 同社の10月19日の投稿は、この問いを具体化した。AIモデルを選んだからといって、その検索クエリの送信先まで決まるとは限らない。
Otariは、タスクを完了するためにツールを使うソフトウェアであるエージェントと、モデルプロバイダーの間に位置する。Mozilla AIによれば、この位置により、対応するクライアントインターフェースを維持しながら検索先を切り替えられる。この提案が扱うのは、どのモデルが回答を書くかではなく、情報検索を誰が管理するかという問題だ。
競合するアプローチは明快である。モデルサービスに付属する検索を受け入れるか、検索を独立した依存関係として管理するかだ。Claude Codeは、組み込み検索がAnthropicのバックエンドを使うため、有用な参照例となる。Otariは、検索ルーティングを独立した判断にすることで、その構成に異議を唱える。ただし、その判断を行う側には追加の責任も生じる。
あなたのエージェントのためにWebを検索するのは誰か？ Otariが選択を明示する
Mozilla AIはエージェント検索の分析で、Otariが運用する検索、顧客自身の検索アカウント、セルフホストのエンドポイントという3つの選択肢を示している。同社は、顧客が自らの認証情報を用いて接続できるサービスとして、Brave、Exa、Tavilyを挙げている。
Mozilla AIによれば、顧客は検索を処理するサービスを変更しつつ、Claude、GPT、Geminiを維持できる。検索認証情報はエージェントに届くのではなく、リクエストをルーティングする仲介役であるゲートウェイに保持される。同社はまた、モデル利用に関連付けられたワークスペース制御と検索記録についても説明している。
重要な変化は、チームがモデルとは別に選択できる依存関係として検索を扱う点にある。
アプリケーションが単一の回答ボックスを提示すると、この区別は見落とされやすい。ユーザーは質問し、待ち、引用を含む回答を受け取る。異なるサービスが実行していても、インターフェース上では検索と推論が一つの処理に見える場合がある。
これらの処理を分離すると、購入者によるシステム評価の方法も変わる。モデル評価は、モデルが指示に従い、効果的に推論できるかを問う。検索評価は、システムが適切な証拠を取得するか、クエリを許容できる形で扱うか、組織の運用要件を支えられるかを問う。
どちらの評価も、もう一方の代わりにはならない。推論が優れていても、証拠集合に入らなかった文書を取り戻すことはできない。検索が優れていても、根拠のない結論をすべて防げるわけではない。別々に扱うことで、チームはあらゆる問題をモデルのせいにせず、障害をより明確に調査できる。
Mozilla AIの投稿は、製品の方向性と文書化された機能に関する説明としても正確に読むべきだ。公開日だけでは、基盤となる各機能がいつ利用可能になったかは確定しない。また、この発表は、顧客がすでにより良い回答や低い運用コストを実現していることを示すものでもない。
したがって、当面のニュースは、エージェント検索が解決済みだという主張よりも限定的である。Mozilla AIは、検索サプライヤーを購買とアーキテクチャの議論における明示的な要素にしている。これにより、選択したモデルに付随する検索サービスをそのまま受け入れる以外の実践的な選択肢が生まれる。
すでに統合型検索に満足しているチームにとって、その代替案は運用負荷を正当化する必要がある。受け入れがたい検索構成に阻まれているチームにとっては、この依存関係を分離することがまったく別の問題に対応する。必要なのは、もう一つのモデルランキングではなく、評価できる選択肢だ。
クエリそのものも精査に値する
検索クエリは、要求される回答が公開情報に関するものであっても、外部への情報開示となる。
ソフトウェア障害を調査する仮想的なコーディングアシスタントを考えてみよう。有用な公開クエリには、エラーメッセージとライブラリのバージョンを記述できる。不必要に具体的なクエリには、内部サービス名、顧客識別子、未公開プロジェクト名まで含まれる可能性がある。
ここでの区別は、公開ドキュメントを読んで安全かどうかではなく、何が組織の外へ出るかに関するものだ。アシスタントには検索する正当な理由があっても、不適切なクエリを構成する可能性はある。検索サプライヤーの選択は受信者に対応し、クエリ構成の見直しは内容に対応する。
この分離は、エンジニアリングマネージャーやエンタープライズの購入担当者にとって重要だ。モデルを承認しても、それに接続されるツールについてのすべての問いに答えたことにはならない。追加される各サービスは、それぞれ独自の評価に値する運用上の関係を生む。特に、クエリが非公開の作業コンテキストから生じる場合はなおさらだ。
妥当な対応は、実際のタスクをたどることだ。どの情報がプロンプトに入ったのか。どのテキストが検索クエリになったのか。どのサービスがそれを受け取ったのか。どの結果が返り、そのうちどれが回答に影響したのか。
これらの問いにより、購買に関する議論はより具体的になる。同時に、主張がどこで止まるかも明らかになる。送信先を知ることで、ルーティングの可視性は得られる。しかし、それだけでは、すべてのクエリが必要だったこと、適切に表現されていたこと、許容可能な取り扱い条件の対象であったことは証明されない。
同じ考え方は顧客調査にも当てはまる。見込み顧客に関するブリーフィングを準備するアシスタントを想像してほしい。公開企業情報は調査プロセスに含めるべきだ。非公開の営業メモ、契約案の文言、内部評価については、外部クエリに現れる前に別途判断が必要になる。
これらは説明のためのシナリオであり、文書化されたOtari顧客導入事例ではない。その価値は、検索の選択が開発者の好みを超えて重要である理由を示すことにある。一見ありふれた検索でも、最終回答からは見えない境界を越える場合がある。
ナレッジワーカーには、公開情報の発見と自分自身の資料の検索を区別する必要もある。パーソナルナレッジベースは、新たな公開ソースを見つけることとは異なる情報ニーズに対応する。効果的なワークフローでは、どこを検索するかを選ぶ前に、そのタスクにどの種類の証拠が必要かを特定すべきだ。
プロダクトマネージャーであれば、最新の競合情報を求める前に社内調査を参照することを意味するかもしれない。エンジニアであれば、公開ドキュメントを調べる前に非公開の設計判断を確認することを意味するかもしれない。重要なのは、あらゆる不確実性をオープンWebへ送るのではなく、目的に沿った検索である。
これは、エージェント導入を承認する人々に負担をかける。彼らには、その限界を含め、情報の経路を説明できるだけの可視性が必要だ。検索先を公開する製品はその説明を支援できるが、どの情報をその経路に載せるかは組織が判断しなければならない。
あなたのエージェントのためにWebを検索するのは誰か？ 購入者にとって十分な回答には、運用者、関連する契約、送信される情報の範囲が含まれる。よく知られたモデル名を挙げるだけでは、回答のうち検索に関する部分が未完のままだ。
統合型検索は利便性をもたらし、分離型検索は説明責任を加える
統合型検索を支持する最も強い理由は利便性だ。開発者は、検索のすべての部分を組み立てることなく、サポート対象のツールインターフェースを得られる。組織は、自らの要件がプロバイダーのサービスと文書化された挙動に合致する場合、その構成を選ぶことができる。
AnthropicのWeb検索ツールは、統合型アプローチを示している。Claudeが検索するタイミングを判断し、サービスが検索を実行し、最終応答には引用が含まれる。そのドキュメントでは、ドメイン制御や異なるツールバージョンについても説明されている。
これらの機能が重要なのは、設定可能な検索が独立したゲートウェイだけのものではないためだ。顧客は、検索動作に対する制御と、検索サプライヤーに対する制御を区別すべきである。プロバイダーは、基盤サービスの運用責任を保持したまま、有用な制限を公開できる。
中心となる選択は、検索に関する判断と、それを維持するために必要な作業を誰が担うかである。
Otariの提案は、その責任を担いたいチームに訴求する。しかし、独立性には、統合型サービスが引き受けるか簡素化する責任が伴う。誰かが認証情報を管理し、サービスの挙動を評価し、障害を調査し、エージェントとその検索ツールの機能的な関係を維持しなければならない。
Ollamaも有用な比較対象となる。同社のホスト型Web検索のドキュメントでは、ollama.com/api/web_searchへの認証済みリクエストが指定されている。応答には、ページタイトル、アドレス、コンテンツの抜粋を含む結果が返される。
この例が示すのは限定的だが重要な点である。ローカルモデルを使っていても、そのWeb検索がローカルに留まるとは限らない。文書化された検索リクエストはホスト型サービスに到達する。顧客は、どこで処理が行われるかを評価する際、推論、検索、ページ取得を別々に検討する必要がある。
これは、ホスト型検索が本質的に不適切であるという証拠ではない。利用規約、挙動、信頼性が組織のニーズを満たすなら、ホスト型サービスは受け入れ可能な選択肢になり得る。問題となるのは、一つのアーキテクチャ上の選択が、他のすべてのコンポーネントを自動的に決定すると考えることだ。
同じ規律は回答品質にも当てはまる。検索サービスを変えると、モデルが利用できる証拠も変わる。モデルと検索を同時に変更する評価では、どの変更が結果を改善または悪化させたのかを容易に説明できない。
これらの変数を分離すれば、より有益な比較を支えられる。チームは検索を調べる際にモデルを一定に保ち、統合を調べる際には証拠を一定に保てる。このような評価には依然として慎重な設計が必要だが、アプリケーション全体を分割不能なブラックボックスとして扱うことを避けられる。
したがって、OtariのWeb検索評価は、そのチーム固有のタスクから始めるべきだ。公開ドキュメントの検索、最近の企業調査、専門的な技術情報の発見には、それぞれ異なる証拠が必要となり得る。ある検索サービスが最良だという普遍的な主張には、個々のワークロードを超える証拠が必要になる。
Mozilla AIの発表には、そのような勝者を示す独立した比較調査は含まれていない。より妥当な読み方は、顧客が依存関係を選択し、テストできるべきだということだ。これは、検索エンジンの実証済みランキングではなく、制御と評価を支持する議論である。
負担は両方のアプローチにかかる。統合型プロバイダーは、購入者が評価できるほど明確に検索構成を説明する必要がある。独立したインフラは、クライアント、モデル、ツールインターフェースが変わっても、追加の制御が使い続けられることを示す必要がある。
OtariのWeb検索はクライアントの期待を維持できるかに依存する
設定可能な検索サービスは、エージェントが正しく使えなければ役に立たない。アプリケーションが期待するのはリンクの一覧だけではない。認識可能なツール応答、エラー時の挙動、タスクを継続するために十分なソース情報に依存している。
Otariの検索インターセプトに関するドキュメントでは、インターセプトが有効な場合に、対応するプロバイダー名付き検索宣言を引き継ぐ仕組みが説明されている。インターセプトとは、本来であればプロバイダーのツールに送られるリクエストを処理することを意味する。このドキュメントでは、その挙動をプロバイダー固有のリクエストを転送する場合と区別している。
また、検索の無効化、結果の制限、対象ドメインの絞り込みを含むワークスペース制約についても説明している。ドキュメントでは、同梱のSearXNG設定は継続的な利用に対してレート制限があると警告している。この注意は、短いデモではなく本番運用の準備状況を評価する際に重要となる。
インターフェースを維持すれば統合作業は減るが、同一の動作が保証されるわけではない。
クライアントはレスポンスを受け入れても、得られる根拠が異なる場合がある。また、正常な検索結果を適切に扱える一方で、サービスが利用できない場合には不適切に反応することもある。したがって互換性は、通常時の動作だけでなく、それを妨げる事象も対象にする必要がある。
仮想的なコーディング作業を考えると、その違いは明確になる。アシスタントが移行ガイドを検索し、結果を読み、コード変更を提案する。有用な評価では、取得したガイドが該当するソフトウェアバージョンに一致し、提案された変更を裏付けているかを問う。
検索結果が何も返らない場合でも、同じ作業は理解可能であるべきだ。根拠が不足していることを明確に報告するエージェントは、回答を即興で作るエージェントとは異なる振る舞いをする。ゲートウェイのレスポンス形式は重要だが、クライアントが失敗をどう解釈するかも同様に重要である。
ここで、回答の流暢さだけに基づく比較は誤解を招く。洗練された説明は、弱い根拠を覆い隠しうる。限界を明示する、やや洗練度の低い回答のほうが、重要な技術的判断では役立つ場合がある。
Otariの検索設定では、名前付きの検索インスタンスとデフォルト選択が文書化されている。また、プロバイダー固有の設定と認証情報の要件についても説明している。これらの詳細は、検索の独立性がプロンプトで示す単なる選好ではなく、運用上の設定であることを示している。
プラットフォームチームにとって、設定には馴染み深い保守上の問いが伴う。誰がデフォルトを変更できるのか。変更は異なるワークスペースにどのように届くのか。リクエストが意図したサービスを使用したことを示す根拠は何か。こうした問いへの答えが、通常の組織活動の中で制御が維持されるかを決める。
設定が存在しても、有効なポリシーになるとは限らない。評価では、許容される例外も含め、実際のデプロイ設定で何が起きるかを確認する必要がある。そうしなければ、選択可能な検索のデモが、すべての本番リクエストに対する保証と誤認されるおそれがある。
この区別は、アプリケーションが外部情報に到達する複数の手段を持つ場合に特に重要になる。検索ツール、ページ取得ツール、ブラウザは、それぞれ異なる経路を表しうる。1つの経路を制御しても、すべてを制御していることにはならない。
この指摘はアーキテクチャ上の考慮事項であり、Otariに特定の迂回経路があるという結論ではない。購入者は、自身のクライアントと有効化したツールに合致するカバレッジの根拠を求めるべきだ。「すべてのエージェントトラフィック」のような広い表現には、検索のインターセプト成功よりも広範な検証が必要となる。
この仕組みが有望なのは、ルーティングの判断をモデルの判断の外に置くためだ。その実用的な価値は、周辺アプリケーションがその制御された経路を一貫して使うかに左右される。評価は、想定された経路が失敗する場面も含め、作業全体を追う必要がある。
セルフホスティングは依存関係をなくさずに責任を変える
検索仲介サービスを自ら運用しても、独立したウェブインデックスを運用することにはならない。
SearXNGのメタサーチ・アーキテクチャは、他の検索エンジンからの結果を集約する。これにより、セルフホスティングの意味は明確になる。組織は集約サービスを運用できる一方、結果については依然として上流の検索エンジンに依存する。
SearXNGを使用するOtariデプロイメントでは、この区別によってプライバシーに関する過大な主張を避けられる。運用者は自らのインスタンスを管理するが、そのインスタンスで設定された上流との関係も依然として重要である。完全な評価では、組織の最初のサーバーを越えてクエリを追跡する。
これは、より広範な主張を検証する有用な懐疑的テストである。セルフホスティングが完全な独立性として提示されるなら、メタサーチはその約束を複雑にする。定義されたコンポーネントに対する制御として提示されるなら、主張はより限定的になり、評価しやすくなる。
同じ規律はコスト比較にも適用すべきだ。同梱検索の料金をなくしても、検索取得を運用するための作業がなくなるわけではない。インフラ、保守、インシデント対応、スタッフの注意は、クエリ単位の請求に現れなくても、評価に含めるべきである。
ここから、セルフホスティングが常に安価だと断言する根拠はない。適切な比較は、ワークロード、サービス要件、組織の既存能力に依存する。すでに関連インフラを運用しているチームと、その専門知識を持たないチームでは、判断が異なる。
認証情報の制御にも正確な解釈が必要である。認証情報をエージェントから遠ざけることは、1つの露出経路を減らす。だが、その認証情報を保持するサービスは依然として機微なシステムであり、適切な管理とアクセス制御が必要になる。
検索記録は別のトレードオフを生む。エージェントがなぜその回答を出したのかを説明する助けになる一方で、機微なクエリテキストを保存する可能性もある。説明責任を求める組織は、誰がその記録を確認できるのか、またどの期間まで有用性があるのかを決めるべきだ。
したがって、可視性の向上はそれ自体がガバナンス上の課題を生む。詳細な記録が、あらゆる状況で自動的に優れているわけではない。目標は調査に十分な根拠を確保しつつ、その記録に含まれる情報に適した取り扱いルールを設けることだ。
ドメイン制限にも同様に限定された価値がある。対象となるソースの集合を制約することはできる。しかし、許可されたドメインのすべてのページが、特定の作業に対して正確、最新、あるいは適切であることを保証するものではない。
また、検索サプライヤーを選んだからといって、プロンプトインジェクション、すなわちアシスタントの行動を誘導するよう設計された悪意あるコンテンツが解決されるわけではない。取得したページは依然として外部入力である。エージェントは、それらをタスクに対する権限を持つ指示ではなく、評価すべき根拠として扱わなければならない。
こうした制約は、独立した検索を支持する論拠を無効にするものではない。その論拠が何を裏付けられるかを定義するものである。依存先を選ぶことは、組織が判断を行う場を与えるが、その判断が正しいことを保証するわけではない。
信頼できる成果は、識別可能な選択に対する説明責任の向上である。購入者は、なぜサービスが選ばれたのか、どの前提がそれを支えているのか、何が変更の契機となるのかを問える。選ばれた答えがマネージドプロバイダーであっても、これらの問いには価値がある。
Otariのウェブ検索デプロイメントは、こうした具体的な責任に照らして評価されるべきだ。発表だけでは、優れた検索取得、普遍的な互換性、または完全なプライバシー上の成果は証明されない。チームの実際の環境から得られる根拠が、それらの結論を支えなければならない。
互換性、比較根拠、プロバイダー開示を注視する
次の報道期間では、よりオープンなAIスタックに関する約束ではなく、観測可能な変化に注目すべきだ。2026年後半から2027年初頭にかけて重要な兆候は、独立した検索が運用しやすくなり、評価しやすくなるかどうかに関わる。
最も強い根拠は、失敗や変更を含む実際の作業中に、信頼できる制御が機能することを示す。
最初の兆候は、チームが実際に使用するクライアントとツールインターフェースに関する公開済みの互換性根拠である。有用なリリースでは、テスト済みの動作、対応バージョン、既知の制約が特定される。再現可能な例があれば、顧客が検索を変更しながらアプリケーションを維持できるという論拠が強まる。
逆に、クライアント固有の回避策が繰り返し必要になるなら、独立性に関する実用的な主張は弱まる。理論上は置き換え可能なサービスでも、置き換えるたびに大規模なアプリケーション修正が必要なら、提供できる自由は限定的だ。周辺ソフトウェアが進化しても、互換性は理解可能な状態で維持されなければならない。
2つ目の兆候は、統制されたワークロードによる比較評価である。モデルとタスクを一定に保ち、その上で検索取得の関連性、鮮度、応答時間、失敗、総運用負荷を検証する。結果では、同梱検索が依然として望ましいケースも含め、それぞれの構成がどこで機能するのかを示すべきだ。
説得力のある評価では、読者がその境界を理解できるだけの詳細が公開される。ドキュメント検索での結果を、あらゆる調査作業に関する主張へと拡張すべきではない。選択的な利点を示す根拠のほうが、説明のない全体的優位性の宣言よりも信頼できる。
3つ目の兆候は、同梱プロバイダーによる、より明確な開示または追加のサプライヤー選択肢である。より明示的なドキュメントがあれば、顧客は別の仲介サービスを導入せずに既存サービスを評価しやすくなる。プロバイダーが支援する選択肢は、顧客が主に独立性を求めているのか、それとも単に明確な制御を求めているのかを検証することにもなる。
この展開は、Otariの競争上の位置付けを変えつつ、Mozilla AIの根本的な主張を強化する。購入者が別の場所で選択を行ったとしても、検索はより可視化された購買判断になる。持続する論点は、誰がその判断を行い、説明できるのかという点である。
あなたのエージェントは誰がウェブ検索を行うのか。この問いへの答えは、こうした兆候が進展するにつれて、より具体的になるべきだ。モデル名から導かれた仮定に頼るのではなく、実際の情報経路と、その利用を裏付ける根拠を特定すべきである。
エージェントのワークフローを拡大する前に、プロンプトから最終回答まで代表的な作業を確認する。送信されるクエリ、その宛先、返されたソース、結論を裏付ける根拠を特定する。そのうえで、その構成が作業の機微性と目的に適合しているかを問う。同梱検索の文書化された動作がその要件を満たすなら、それを維持する。サプライヤー選択、運用上の制御、またはより明確な記録が具体的な要件に対応する場合は、別の検索サービスを評価する。プライベートな知識と公開調査を組み合わせる作業では、すべての検索を同じものとして扱うのではなく、その境界を明示的に検討する。有用な次の一歩は、チームが説明できる判断である。このエージェントはどの検索サービスを使うべきか。そして、その選択を正当化する根拠は何か。
