エージェントが継承したウェブ検索機能では不十分です

外部世界を必要とするエージェント

あるソフトウェア企業のエンジニアが、自社の市場概況を常に最新の状態に保つためのエージェントを構築しています。このエージェントは、数十万件の見込み客や顧客のアカウントを監視し、アプローチの好機を示すシグナル（新たな資金調達ラウンド、経営陣の交代、製品のリリース、予算の存在を示す採用の急増など）を検知します。

アカウントのレコードはすでにDatabricks内にあり、Unity Catalogによって管理されるDeltaテーブルに格納され、自社の利用状況データやパイプラインデータと結合されています。しかし、アカウントを動かすシグナルは社外のウェブ上に存在します。エージェントの役割は、これら2つの情報を継続的に統合し、すべてのアカウントの一貫した最新の全体像を作成することです。これにより、営業担当者に今週電話をかけるべき少数の候補を提示できます。

バージョン1.0：動くものの、混沌とした状態

最初のバージョンは、単一のシステムではありません。エンジニアが手にしたツールごとに、同じエンリッチメントロジックをゼロから3回別々に再構築したものです。最初の実装はClaude Codeで実行され、エージェント的な部分（どのアカウントを再確認すべきかの判断、検索の連鎖、サマリーの作成）が作業の大半を占めています。同僚から、Codexの方が特定のバッチスクリプトを高速に処理できると聞き、エンジニアは検証のためにエンリッチメントループを移植します。3つ目のコピーはハーネスを完全にスキップし、API経由でモデルを直接呼び出します。これは、ツールのオーケストレーションを必要とせず、単一のプロンプトとレスポンスだけで済む軽量な夜間ジョブ用です。同じジョブでありながら3つのビルドが存在し、それぞれがその瞬間に適したツールによって形成されています。

各ハーネスは独自のツールと独自のウェブ検索をバンドルし、それぞれ独自の方法で接続しているため、エンジニアは同じエンリッチメントロジックを各ハーネスの設定形式に合わせて3回構築することになります。これで1日が終わってしまいます。アカウントのエンリッチメント方法を改善する代わりに、エンジニアはClaude Codeがどのようにツールを宣言させたいのか、なぜ同じMCPサーバーがCodexでは異なる接続になるのか、そして他の2つが標準で備えていた機能が生のAPIパスで何が欠けているのかを学ぶことに時間を費やしています。

ツールが同等ではないため、結果も同等にはなりません。あるハーネスにバンドルされているウェブ検索は、別のハーネスとは異なるデータを返します。一方でアクセスできるソースが、他方では見落とされます。LLM用の組み込みウェブ検索ツールは、資金調達ラウンドや経営陣の交代といった大まかな情報は検索できますが、技術スタックの変更といった詳細な情報を見落とします。オンライン情報へのアクセスこそがこのエージェントの存在意義ですが、その品質は、ウェブ上の重要な詳細情報を確実に提示できないウェブ検索に依存してしまっています。

そして、これら3つを統括するものは何もありません。共通の計測メーターがないため、数十万件のアカウントにわたるサイクルのコストを把握することも、制限することもできません。共通のルールブックがないため、エージェントがどのソースを読み取ることができるか、また人間がいつ承認するかは、3通りの方法で設定されるか、あるいはまったく設定されません。共通の記録がないため、結果が間違っている場合に、エージェントが何を読み、何を費やし、何を決定したかを再構築する場所がありません。

結果を出せるという意味では、一応機能しています。そしてそれこそが、これが決して修正されない理由です。使い続けるには十分機能しますが、完全に信頼するには不十分です。

Omnigent：1つの定義、あらゆるハーネス

Omnigentは、この無秩序な広がりを抑制するレイヤーです。個々のハーネスの上位に位置するため、エンジニアはエージェント、実行するモデル、アクセスできるツール、動作するポリシーと制限を一度定義するだけで済みます。3つの再構築作業は1つの定義に集約され、エンジニアは再びアカウントのエンリッチメントに集中できるようになります。ツールは各ハーネスにバンドルされていたものではなく、エージェント上の宣言となり、一度設定すれば自由に交換できるようになります。Databricksでホストされたモデルで実行すると、モデルの呼び出しはFoundation Model APIsを経由してルーティングされ、すべての呼び出しが3つのランタイムに分散されることなく、コスト、監査、ガバナンスのために1箇所で記録されます。また、モデルや経済状況が変わった場合でも、エンジニアは1行変更するだけで、業務を中断することなく新しいモデルを選択したり、より安価なモデルに切り替えたりできます。

これにより無秩序な広がりの大部分は解消されますが、設計ではなくデフォルトによって決定される重要な要素が1つ残ります。ウェブ検索はすべてのハーネスがバンドルしているコア機能の1つですが、同じものをバンドルしているハーネスは2つとありません。同じクエリでも、Claude CodeとCodexでは異なる結果が返されます。Omnigentは、各タスクにわたって一貫した選択肢を定義する機能を提供しますが、決定を代行するわけではありません。パートナーの検索機能を割り当てる必要があります。Nimbleのようなパートナーを利用することで、タスクに適応する機能をスロットに配置し、その下にあるすべてのハーネスに同じ専門的な読み取り能力を提供できます。

Nimble：検索スロットを埋める

NimbleのSearch APIは、ライブ検索を通じて、最新のリアルタイムなウェブデータに回答をグラウンディング（根拠付け）できます。深いリサーチタスクでは、NimbleのWeb Search Agentsがウェブ検索と抽出のオーケストレーションを自動化してタスクを実行します。多くのソースを調査してクロスチェックし、各主張を裏付ける引用付きの回答を返します。これは、一般的な方法では決して生成できない監査証跡です。

一般的なウェブ検索ツールはすべてのユースケースを同様に扱いますが、Nimbleはエージェントの特定のユースケースに特化し、最適な取得方法を自己学習し、ウェブ検索とクローリングを適応させてドメインを深く掘り下げ、一般的な検索ツールが見落とすデータを取得します。通常のクローラーが諦めてしまうような、JavaScript、フィルター、ページネーションの背後にあるデータにもアクセスできます。また、関連データを取得するための最適な方法を記憶しているため、すべてをゼロから再発見するのではなく、データ取得パスを再利用してトークンコストを削減します。設定でプロバイダーとして指定するだけで、エージェントにより完全なウェブコンテキストを提供する近道となります。

Nimbleのテストでは、Nimbleのウェブ検索を追加することで、LLMベンチマークの精度が46%から71%に向上し、同時にウェブ検索コストが半分に削減されました（ClaudeとNimbleのウェブ検索コストの比較）。Web Search Agentsは特定のドメインに向けて固定できるため、どのソースとどの取得パスが適切なデータを生成したかを記憶し、次回もそれらを再利用します。ドメインでの稼働時間が長くなるほど精度が向上し、最も頻繁に実行されるアカウントにおいて、シグナルがどこにあるかを再発見するためのコストが低下します。

バージョン2.0：DatabricksとNimble上で一度だけ構築

エンジニアの話に戻ると、エージェントは一貫性があり、管理可能で、信頼できる全体像へと進化しつつあります。エージェントはOmnigentで一度定義され、Databricksでホストされたモデル上で、そのツール、ポリシー、制限が単一の仕様にまとめられます。3つの再構築作業は不要になりました。面倒な接続作業 of 負担も解消され、エンジニアは各ハーネスがどのようにツールを宣言させたいかではなく、再びエンリッチメントに集中できるようになりました。

ウェブ検索の決定は、3つではなく1つになりました。組み込みのweb_searchでNimbleを指定すると、その下にあるすべてのハーネスが同じNimble Search APIを指すようになり、高速で効率的なウェブ検索が可能になります：

生のウェブデータではなく、根拠のある回答を必要とするアカウントに対して、OmnigentはNimbleのWeb Search Agentsを利用できます。これにより、リサーチ、エンリッチメント、またはデータセット構築のためのウェブ検索と抽出が自動化されます。

キーはNimbleアカウントから取得できます。アカウントは無料で開始できます。

管理が1箇所に統合されました。モデルの呼び出しはガバナンス下でFoundation Model APIsを経由してルーティングされ、コストは1箇所で可視化および制限され、エージェントが何を読み、何を費やし、何を決定したかが単一のガバナンスサーフェス全体で一貫して記録されます。

そして、2つの側面がようやく1つにまとまりました。Databricks内の内部レコードとNimbleからの外部シグナルが1箇所に集約され、1つのエージェントによって管理および読み取られます。バージョン1.0は、3つのハーネスが存在し、全体を見渡す視点がありませんでした。これは、企業が把握している情報とウェブから得られる情報にグラウンディング（根拠付け）され、すでにデータが存在する場所で実行される単一のエージェントです。以前はブレが生じていた部分が一貫し、浅かった部分が深くなり、外部ウェブコンテキストの取得に対する完全なガバナンスが実現します。

今すぐお試しください

これを立ち上げるには、2つのステップが必要です。

OmnigentをDatabricksに接続する。DatabricksがOmnigentサーバーを代わりに実行します。ご自身のマシンにDatabricks統合機能付きのCLIをインストールし、そのマシンをホストとして登録します：

次に、ワークスペースのアイデンティティでサインインし、Databricksでホストされたモデル上で最初のエージェントを実行します。Omnigent on Databricksから始めてください。マネージドセットアップをエンドツーエンドでカバーし、CLIのステップへのリンクを提供しています。まず確認すべき2つの前提条件があります。ワークスペースでOmnigentベータ版が有効になっていること、およびワークスペースがUnity AI Gatewayをサポートするリージョンにあることです。その他のインストール方法や要件については、完全なインストールリファレンスをご参照ください。

エージェントはマネージドサーバー上で実行されるため、すべてのサーフェスで同じセッションが引き継がれます：

• インストールを実行したターミナル
• デスクトップアプリ（通知機能や、対応待ちのエージェントを示すドックバッジを備えたネイティブウィンドウ）
• モバイル（ワークスペースのURLを入力することで、ネイティブのiOS/Androidアプリ、またはスマートフォンのブラウザのWeb UIからアクセス可能）

検索先をNimbleに設定します。組み込みのweb_searchでNimbleを指定する（先ほどの1行の変更）だけで、Databricksでホストされているすべてのエージェントが、それを基に回答をグラウンディング（根拠付け）するようになります。根拠が明確で監査可能な作業を行うには、リサーチパスをご利用ください。Nimbleコネクタのドキュメントで両方について説明しています。Nimbleキーが必要になりますので、無料トライアルを開始して取得してください。

社内データはすでに手元にあります。これにより、同じプラットフォームで両方を管理しながら、エージェントがWeb上の他の情報に基づいて推論できるようになります。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事