注
現在、この機能はパブリック プレビュー段階にあります。 このプレビュー版はサービス レベル アグリーメントなしで提供されています。運用環境のワークロードに使用することはお勧めできません。 特定の機能はサポート対象ではなく、機能が制限されることがあります。 詳細については、「 Microsoft Azure プレビューの追加使用条件」を参照してください。
エージェント取得とはどのようなものでしょうか。 Azure AI Search では、 エージェント検索 は、チャット内や Copilot アプリ内でユーザーまたはエージェントが提起する複雑な質問向けに設計された、新しいマルチクエリ パイプラインです。 これは、 取得拡張生成 (RAG) パターンとエージェント間ワークフローを対象としています。
実行内容は次のとおりです。
大規模な言語モデル (LLM) を使用して、複雑なクエリをより小さい、焦点を絞ったサブクエリに分割し、インデックス付きコンテンツのカバレッジを向上します。 サブクエリには、追加のコンテキストのチャット履歴を含めることができます。
サブクエリを並列で実行します。 各サブクエリは、最も関連性の高い一致を昇格させるためにセマンティックに再ランク付けされます。
最適な結果を、LLM が独自のコンテンツで回答を生成するために使用できる統一された応答に結合します。
応答はモジュール式ですが、クエリ プランとソース ドキュメントも含まれている方法で包括的です。 検索結果のみをグラウンド データとして使用するか、LLM を呼び出して回答を作成することができます。
このハイ パフォーマンス パイプラインは、チャット アプリケーションの高品質のグラウンド データ (または回答) を生成するのに役立ち、複雑な質問にすばやく答える機能を備えています。
エージェント検索は、2025-11-01-preview および機能を提供する Azure SDK プレビュー パッケージの新しい ナレッジ ベース オブジェクト を通じてプログラムによってサポートされます。 ナレッジ ベースの取得応答は、他のエージェントやチャット アプリによってダウンストリームで使用できるように設計されています。
エージェント検索を使用する理由
エージェント検索には 2 つのユース ケースがあります。 1 つ目は、Microsoft Foundry (新しい) ポータルでの Foundry IQ エクスペリエンスの基礎です。 Microsoft Foundry のエージェント ソリューションのナレッジ レイヤーを提供します。 2 つ目は、Azure AI Search API を使用して作成するカスタム エージェント ソリューションの基礎です。
エージェントとアプリに最も関連性の高いコンテンツを提供し、チャット コンテキストと独自のコンテンツを活用して、より困難な質問に答える場合は、エージェントの取得を使用する必要があります。
エージェント的な側面は、指定したサポートされている大規模言語モデル (LLM) によって実行されるクエリ計画処理の推論手順です。 LLM は、チャット スレッド全体を分析して、基になる情報のニーズを特定します。 LLM は、ユーザーの質問、チャット履歴、要求のパラメーターに基づいて、複合的な質問を、全体を包括する単一のクエリではなく焦点に合ったサブクエリに分割します。 サブクエリは、Azure AI Search のインデックス付きドキュメント (プレーンテキストとベクター) を対象とします。 このハイブリッドなアプローチにより、キーワードの一致とセマンティックな類似性の両方を一度に確認できるので、再現率が大幅に向上します。
取得コンポーネントは、サブクエリを同時に実行し、結果をマージし、セマンティックに結果をランク付けし、次の会話ターンの接地データ、ソース コンテンツを検査できるように参照データ、クエリ実行手順を示すアクティビティ プランを含む 3 部構成の応答を返す機能です。
クエリの拡張と並列実行、および取得応答は、生成 AI (RAG) アプリケーションに最適なエージェント検索の主要な機能です。
エージェント検索ではクエリ処理の待機時間が長くなりますが、次の機能を追加することでそれを構成します。
- 取得パイプラインへの入力としてチャット履歴を読み取ります。
- 複数の "asks" を含む複雑なクエリをコンポーネント 部分に分解します。 例: "ビーチの近くにあり、空港送迎付きで、ベジタリアンレストランの徒歩圏内にあるホテルを見つけてください。"
- シノニム マップ (省略可能) と LLM で生成された言い換えを使用して、元のクエリを複数のサブクエリに書き換えます。
- スペル ミスを修正します。
- すべてのサブクエリを同時に実行します。
- 統合された結果を 1 つの文字列として出力します。 または、ソリューションの応答の一部を抽出することもできます。 クエリの実行と参照データに関するメタデータが応答に含まれます。
エージェント取得では、サブクエリごとにクエリ処理パイプライン全体が複数回呼び出されますが、これは並列的に処理されるため、合理的なユーザー エクスペリエンスが必要とする効率性とパフォーマンスは維持されます。
注
クエリ計画に LLM を含めると、クエリ パイプラインに待機時間が追加されます。 gpt-4o-mini などのより高速なモデルを使用し、メッセージ スレッドを要約することで、効果を軽減できます。 LLM 処理を制限するプロパティを設定することで、待機時間とコストを最小限に抑えることができます。 テキスト検索とハイブリッド検索だけでなく、独自のクエリ計画ロジックについても、LLM 処理を完全に除外することもできます。
アーキテクチャとワークフロー
エージェント取得は、複雑なクエリをインテリジェントに分解するために LLM を使用する、会話型検索エクスペリエンスを対象にして設計されています。 システムは、複数の Azure サービスを連係させて、包括的な検索結果を提供します。
動作方法
エージェント検索プロセスは次のように機能します。
ワークフローの開始: アプリケーションは、クエリと会話履歴を提供する取得アクションを使用してナレッジ ベースを呼び出します。
クエリの計画: ナレッジ ベースは、クエリと会話の履歴を LLM に送信します。これはコンテキストを分析し、複雑な質問を焦点を絞ったサブクエリに分割します。 この手順は自動化されており、カスタマイズすることはできません。
クエリの実行: ナレッジ ベースは、サブクエリをナレッジ ソースに送信します。 すべてのサブクエリは同時に実行され、キーワード、ベクター、ハイブリッド検索を使用できます。 各サブクエリには、意味論的な再ランク付けが行われ、最も関連性の高い一致が検出されます。 引用のために参照元が抽出され保持されます。
結果の合成: システムは、結合されたコンテンツ、ソース参照、実行の詳細という 3 つの部分で、すべての結果を統合された応答に結合します。
検索インデックスは、クエリの実行と、クエリの実行中に発生する最適化を決定します。 具体的には、インデックスに検索可能なテキスト フィールドとベクター フィールドが含まれているのなら、ハイブリッド クエリが実行されます。 検索可能なフィールドがベクター フィールドのみの場合は、純粋ベクター検索のみが使用されます。 インデックスのセマンティックな構成に加えて、オプションのスコアリング プロファイル、同意語マップ、分析機能、正規化機能 (フィルターを追加する場合) のすべてが、クエリの実行中に使用されます。 セマンティック構成とスコアリング プロファイルに対しては、名前付きの既定値が必要です。
必須コンポーネント
| コンポーネント | サービス | Role |
|---|---|---|
| LLM | Azure OpenAI | 会話コンテキストからサブクエリを作成し、その後で典拠データを使用し応答を生成します |
| ナレッジ ベース | Azure AI 検索 | パイプラインを調整し、LLM に接続し、クエリ パラメーターを管理します |
| ナレッジ ソース | Azure AI 検索 | ナレッジ ベースの使用に関連するプロパティで検索インデックスをラップします |
| 検索インデックス | Azure AI 検索 | 検索可能なコンテンツ (テキストとベクター) を、セマンティック構成と共に格納します |
| セマンティック ランカー | Azure AI 検索 | 関連性について結果を再ランク付けする必須コンポーネント (L2 の再ランク付け) |
統合の要件
アプリケーションは、ナレッジ ベースを呼び出して応答を処理することで、パイプラインを駆動します。 パイプラインは、会話インターフェイスで応答を生成するために LLM に渡す典拠データを返します。 実装の詳細については、「 チュートリアル: エンドツーエンドのエージェント検索ソリューションを構築する」を参照してください。
注
クエリ計画では、gpt-4o、gpt-4.1、gpt-5 シリーズのモデルのみがサポートされています。 最終的な回答の生成には、任意のモデルを使用できます。
始め方
エージェント検索ソリューションを作成するには、Azure portal、最新のプレビュー REST API、または機能を提供するプレビュー Azure SDK パッケージを使用できます。
- クイック スタート: Azure portal でのエージェント検索
- クイック スタート: エージェント検索 (C#、Java、JavaScript、Python、TypeScript、REST)
可用性と料金
エージェント検索は、 選択したリージョンで使用できます。 ナレッジ ソースとナレッジ ベースには、価格レベルと取得の推論作業によって異なる 上限 もあります。
Premium 機能に依存しています。 検索サービスのセマンティック ランカーを無効にした場合、エージェント駆動の取得を実質的に無効にします。
| Plan | Description |
|---|---|
| Free | 無料レベルの検索サービスでは、月に5千万個のエージェント推論トークンを無料で使用できます。 上位レベルでは、無料プラン (既定) と Standard プランのどちらかを選択できます。 |
| Standard | 標準プランは、毎月の無料クォータが使用されると、従量課金制の価格になります。 無料クォータが使い切った後、100 万個のエージェント推論トークンが追加されるたびに追加料金が課金されます。 切り替えが発生しても通知されません。 通貨別の料金の詳細については、 Azure AI Search の価格に関するページを参照してください。 |
LLM ベースのクエリ計画と 応答合成 のトークンベースの課金 (省略可能) は、Azure OpenAI で従量課金制です。 これは、入力トークンと出力トークンの両方に基づくトークンです。 ナレッジ ベースに割り当てるモデルは、 トークンの使用に対して課金されるモデルです。 たとえば、gpt-4o を使用する場合、トークンの料金は gpt-4o の請求書に表示されます。
エージェント検索のトークン ベースの課金は、各サブクエリによって返されるトークンの数です。
| 特徴 | クラシックの単一クエリ パイプライン | エージェンティック検索のマルチクエリ パイプライン |
|---|---|---|
| 単位 | 通貨単位あたりのクエリ ベース (1,000 クエリ) | トークン ベース (通貨単位あたり 100 万トークン) |
| ユニットあたりのコスト | クエリあたりの均一コスト | トークンあたりの均一コスト |
| コスト見積もり | クエリ数の見積もり | トークン使用量の見積もり |
| Free レベル | 1,000 個の無料クエリ | 5,000 万個の無料トークン |
例: コストの見積もり
エージェント検索には、Azure OpenAI からの課金 (クエリ計画と、有効な場合は応答合成) と、エージェント検索による Azure AI Search からの課金という 2 つの課金モデルがあります。
この価格の例では、回答の合成は省略されていますが、見積もりプロセスを示すのに役立ちます。 お客様のコストはこれより低い可能性があります。 トランザクションの実際の価格については、 Azure OpenAI の価格に関するページを参照してください。
クエリ計画の推定請求コスト
Azure OpenAI でクエリ プランのコストを従量課金制として見積もるには、gpt-4o-mini を想定してみましょう。
- 100 万個の入力トークンに対して 15 セント。
- 100 万個の出力トークンに対して 60 セント。
- チャット会話の平均サイズに対して 2,000 個の入力トークン。
- 平均出力プランサイズは350トークンです。
クエリ実行の推定課金コスト
エージェント取得トークンの数を見積もるために、まず、インデックス内の平均ドキュメントがどのように表示されるかを理解します。 たとえば、次のように概算することができます。
- 10,000 個のチャンク。各チャンクは PDF の 1 ~ 2 段落です。
- チャンクあたり 500 トークン。
- 各サブクエリは、最大 50 チャンクを再ランク付けします。
- クエリ プランごとに平均で 3 つのサブクエリがあります。
実行価格の計算
プランごとに 3 つのサブクエリで 2,000 個のエージェント検索を行うとします。 これにより、合計約 6,000 個のクエリが得られます。
サブクエリごとに 50 個のチャンクを再ランク付けします。合計チャンク数は 300,000 個です。
平均チャンクは 500 トークンであるため、再ランク付けのトークンの合計は 1 億 5,000 万です。
トークンあたり 0.022 という架空の価格を考えると、$3.30 は米ドルでの再ランク付けの合計コストです。
クエリ プランのコストに進む: 2,000 個の入力トークンに 2,000 個のエージェント検索が乗算され、合計 60 セントの入力トークンが 400 万になります。
平均 350 トークンに基づいて出力コストを見積もります。 350 に 2,000 個のエージェント検索を乗算すると、合計 42 セントの合計で 700,000 個の出力トークンが取得されます。
すべてをまとめると、Azure AI Search でのエージェント検索に約 3.30 ドル、Azure OpenAI の入力トークンに 60 セント、Azure OpenAI の出力トークンに対して 42 セント、クエリ計画の合計で $1.02 が支払われます。 完全実行の合計コストは $4.32 です。
コストを管理するためのヒント
応答のアクティビティ ログを確認して、どのソースとパラメーターが使用されたクエリが発行されたかを確認します。 インデックスに対してこれらのクエリを再発行し、パブリック トークナイザーを使用してトークンを見積もり、API で報告された使用状況と比較することができます。 ただし、クエリまたは応答の正確な再構築は保証されません。 要因には、パブリック Web データや、ユーザー ID に基づくリモート SharePoint ナレッジ ソースなど、クエリの再現に影響を与える可能性があるナレッジ ソースの種類が含まれます。
ナレッジ ソース (インデックス) の数を減らす。コンテンツを統合すると、ファンアウトとトークンの量が減少する可能性があります。
クエリの計画とクエリの拡張 (反復検索) 中の LLM の使用を減らすための推論作業を減らします。
コンテンツを整理して、最も関連性の高い情報をより少ないソースとドキュメント (たとえば、キュレーションされた概要やテーブル) で見つけることができます。