2026年6月上旬にPublic Previewとして告知された Agentic Retrieval Toolkit for Azure Cosmos DB は、Azure Cosmos DBを使って高度なRAGアプリを作るための新しいリファレンス実装です。結論から言うと、既存のAzure Cosmos DBアカウントが自動的に変更される更新ではありません。開発者が多段検索・追加質問・根拠付き回答生成を行うRAG構成を試しやすくなる一方で、管理者はプレビュー機能、ベクトル検索、全文検索、セマンティックリランカー、認証、RU消費、レイテンシを事前に確認する必要があります。公式情報ではPublic Previewとして案内されており、GraphRAGやマルチホップ推論の課題を意識した更新とされています。(マイクロソフトアジュール)
Azure Cosmos DBのAI/RAG更新で何が変わるのか
Agentic Retrieval Toolkit for Azure Cosmos DBのポイントは、従来の「1回検索して1回答を作る」RAGから、不足情報を見つけて追加検索するRAGへ進めることです。
公式ドキュメントでは、このツールキットを「Azure上でマルチステップRAGアプリケーションを構築するためのリファレンス実装」と説明しています。Azure Cosmos DB for NoSQLのベクトル検索、全文検索、Azure OpenAIの埋め込み、LLMによる推論を組み合わせ、より多様な根拠を取得して回答を生成します。(Microsoft Learn)
従来の単発RAGでは、最初の検索で関連文書を取り逃すと、そのまま不完全な回答になりがちです。Agentic Retrieval Toolkitでは、最初に検索した文書から仮回答を作り、不足している情報を分析し、追加のサブ質問を生成して再検索し、最終回答を合成します。(Microsoft Learn)
| 観点 | 従来の単発RAG | Agentic Retrieval Toolkit |
|---|---|---|
| 検索の流れ | 質問を1回検索し、取得結果から回答する | 初期検索、仮回答、不足分析、追加質問、再検索、最終合成を行う |
| 向いている質問 | FAQ、単純な文書検索、定型問い合わせ | 複数文書に根拠が分かれる質問、技術文書、調査系Q&A |
| 根拠の扱い | 最初に取れた文脈に依存しやすい | 多様な文脈を選択し、追加根拠で補強しやすい |
| コストと速度 | 比較的軽い | 複数回の検索とLLM呼び出しにより、レイテンシとトークン消費が増えやすい |
| 導入形態 | 既存の検索基盤に組み込みやすい | リファレンス実装を自社要件に合わせて調整する前提 |
この更新は「Azure Cosmos DBにAI検索機能が追加されたからすぐ本番移行すべき」という話ではありません。実務では、既存のRAGパイプラインと比較しながら、回答品質の改善がコストや遅延に見合うかを検証することが重要です。
対象サービスと影響範囲
公式ドキュメント上の適用対象は Azure Cosmos DB for NoSQL です。MongoDB API、Cassandra API、Gremlin APIなどで同じ前提で使えると決めつけず、対象APIと利用リージョン、関連プレビュー機能の有効化可否を個別に確認してください。(Microsoft Learn)
影響を受けるのは、主に次の担当者です。
| 担当者 | 確認すべきこと |
|---|---|
| アプリ開発者 | RAGの検索品質、回答生成ロジック、質問分解、評価データ、失敗時のフォールバック |
| Cosmos DB管理者 | ベクトル検索、全文検索、コンテナ設計、インデックス、RU消費、認証方式 |
| AI基盤担当者 | Azure OpenAIまたはMicrosoft Foundryモデル、埋め込みモデル、推論モデル、トークン消費 |
| セキュリティ担当者 | Microsoft Entra ID RBAC、キー認証の扱い、接続情報、ログに含まれる機密情報 |
| プロダクト責任者 | Public Previewの扱い、本番適用可否、回答品質の合格基準、運用時の責任分界点 |
既存のAzure Cosmos DBデータベースに対して自動的にエージェント検索が有効になるわけではありません。ツールキットを利用する場合は、リポジトリのコード、構成ファイル、Cosmos DBコンテナ、インデックス、モデル接続を明示的に準備する必要があります。公式リポジトリでも、Cosmos DBアカウント、データベースやコンテナ、Azure OpenAIまたは互換する埋め込みエンドポイントなどが前提条件として示されています。(AKA.ms)
Agentic Retrieval Toolkitの主な構成
Agentic Retrieval Toolkitは、単一の完成済みSaaS機能というより、RAG構成を学び、検証し、自社アプリに合わせて調整するためのコードベースです。Microsoftのブログでも、Public Previewのリファレンス実装であり、すぐにそのまま使えるターンキーのマネージドサービスではないと説明されています。(Microsoft for Developers)
主な処理は、取り込み段階と検索・回答段階に分かれます。
| 構成要素 | 役割 |
|---|---|
| ドキュメント取り込み | JSON、JSONL、フォルダー、カスタムパーサーから文書を読み込む |
| 埋め込み生成 | Azure OpenAIまたは互換エンドポイントでベクトルを生成する |
| Cosmos DB保存 | 文書と埋め込みをAzure Cosmos DBコンテナに保存する |
| ベクトル検索・全文検索 | 意味検索とキーワード検索を組み合わせて候補文書を取得する |
| 多様性選択 | 類似しすぎたチャンクを減らし、根拠の幅を広げる |
| セマンティックリランカー | 任意で検索結果を意味的な関連度に基づき並べ替える |
| 質問分解 | LLMが不足情報を判断し、追加のサブ質問を作る |
| 評価ワークフロー | 事前に用意した質問ファイルで回答品質や処理時間を確認する |
公式ドキュメントでは、文書取り込み、Cosmos DBコンテナ設定、埋め込み生成、検索、回答生成、タイミング分析、サンプル評価ワークフローが含まれると説明されています。(Microsoft Learn)
管理者が確認すべき設定と注意点
Public Previewの扱いを本番基準で確認する
この機能はPublic Previewです。Azureのプレビュー機能は一般提供前の段階であり、公式ドキュメントでもプレビュー機能はSLAなしで提供され、本番ワークロードには推奨されないと説明されています。(Microsoft Learn)
そのため、まずは開発環境または検証環境で試すのが安全です。顧客向けの本番検索、法務・医療・金融などの高リスク回答、社内の重要意思決定に直接使う場合は、回答根拠の表示、人手確認、既存検索へのフォールバックを用意してください。
ベクトル検索の有効化とコンテナ設計
Azure Cosmos DB for NoSQLでベクトル検索を使うには、アカウント側でVector Search for NoSQL APIを有効化し、コンテナにベクトルポリシーを定義します。公式ドキュメントでは、Azure portalのFeaturesから有効化する方法と、Azure CLIで EnableNoSQLVectorSearch を指定する方法が示されています。(Microsoft Learn)
特に注意したいのは、ベクトルのパス、データ型、次元数、距離関数です。埋め込みモデルを変更すると次元数が変わることがあるため、後から簡単に差し替えられる前提で設計しない方が安全です。Azure Cosmos DBのベクトルポリシーでは、ベクトルのパス、float32 や float16 などのデータ型、次元数、cosine などの距離関数を定義します。(Microsoft Learn)
また、ベクトルインデックスには flat、quantizedFlat、diskANN などの種類があります。quantizedFlat と diskANN は最大4,096次元に対応しますが、少なくとも1,000ベクトルが必要で、少ない場合はフルスキャンになる可能性があります。Shared Throughputアカウントではベクトルインデックス検索がサポートされない点も見落としやすいポイントです。(Microsoft Learn)
全文検索は日本語データで特に検証が必要
Agentic Retrieval Toolkitは、ベクトル検索だけでなく全文検索も組み合わせます。Azure Cosmos DB for NoSQLの全文検索では、全文ポリシーと全文インデックスを設定することで、BM25に基づくスコアリングや全文検索関数を使えます。全文ポリシーやインデックスを定義しない場合、検索は動作してもインデックスを活用できず、RU消費や実行時間が増える可能性があります。(Microsoft Learn)
日本語のナレッジベースを扱う場合は、ここが重要です。公式ドキュメントの多言語サポート一覧には、英語、ドイツ語、スペイン語、フランス語、イタリア語、ポルトガル語が示されていますが、日本語は含まれていません。日本語テキストでキーワード検索の品質を重視する場合は、チャンク分割、表記ゆれ、同義語、カタカナ語、固有名詞の検索精度を必ず検証してください。(Microsoft Learn)
実務では、次のような対策が考えられます。
| 課題 | 対策 |
|---|---|
| 日本語の単語境界が曖昧 | チャンクに見出し、カテゴリ、別名、英語名をメタデータとして持たせる |
| 型番や製品名が検索に出ない | ベクトル検索だけでなく、全文検索用フィールドに正式名称・略称を追加する |
| 表記ゆれが多い | 取り込み前に正規化辞書を適用する |
| キーワード検索の再現率が低い | Azure Cosmos DB単体に寄せすぎず、既存の検索基盤との比較を行う |
セマンティックリランカーは有効化より効果測定が先
Agentic Retrieval Toolkitでは、Azure Cosmos DBのSemantic Rerankerを任意で利用できます。Semantic Rerankerは、ベクトル検索、全文検索、ハイブリッド検索などの結果を、ユーザーの検索文脈に対する関連度で並べ替える機能です。(Microsoft Learn)
ただし、リランカーは検索品質を必ず改善する万能機能ではありません。公式ドキュメントでも、リランカーの呼び出しは追加のネットワーク呼び出しと推論時間を伴うため、適用前後で関連性を評価すべきだと説明されています。(Microsoft Learn)
管理者は、次の観点でON/OFFを比較してください。
| 評価項目 | 見るべき指標 |
|---|---|
| 回答品質 | 根拠文書が正しい順で上がるか |
| レイテンシ | 95パーセンタイルやタイムアウト率が許容範囲か |
| コスト | 追加推論による費用増が品質改善に見合うか |
| 運用 | プレビュー機能として有効化・無効化の手順を把握しているか |
| 権限 | 実行IDに必要なロールだけを付与しているか |
Semantic Rerankerはプレビュー機能であり、有効化前に Microsoft.InferenceService のプロバイダー登録が必要になる場合があります。Azure portalでCosmos DBリソースごとに有効化し、Microsoft Entraユーザー、サービスプリンシパル、マネージドIDなどへ必要なロールを割り当てる流れです。(Microsoft Learn)
開発者向けの検証手順
Agentic Retrieval Toolkitを試す場合、最初から本番データ全体を取り込むのではなく、小さな検証データで検索品質とコスト感をつかむのが現実的です。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 環境準備 | Python 3.10以上、Azure Cosmos DB、Azure OpenAIまたは互換エンドポイントを用意する | ローカル実行環境とAzure接続情報を分ける |
| 構成ファイル作成 | config.yaml.example をもとに config.yaml を作る | LLMエンドポイント、埋め込みモデル、Cosmos DB URI、DB名、ソース定義を確認 |
| コンテナ設計 | cosmos.sources にコンテナ名、パーティションキー、埋め込みフィールド、全文検索フィールドを定義する | 取り込み後に変えにくい設定を事前レビューする |
| 文書取り込み | cosmos_db_upload.py で文書と埋め込みをCosmos DBへ登録する | チャンク数、RU消費、失敗した文書を確認 |
| 質問ファイル準備 | question_id、question_text、期待回答を含むJSONを作る | 実際のユーザー質問に近い評価セットにする |
| 検索・回答実行 | dynamic_retriever.py で回答生成を実行する | 回答、根拠、処理時間、追加質問の妥当性を見る |
| 性能測定 | --timing や timing_summary.py を使う | どの処理が遅いか、リランカーや追加検索が効いているかを確認 |
公式リポジトリでは、config.yaml に llm.llm_endpoint、llm.embed_endpoint、llm.llm_model、llm.embed_model、cosmos.uri、cosmos.database_name、cosmos.sources などを設定する流れが示されています。Cosmos DB認証は既定でEntra ID RBACを使い、必要に応じてキー認証も設定できます。(AKA.ms)
最小構成の流れは次のようになります。
pip install -r requirements.txt
python cosmos_db_upload.py --config config.yaml
python dynamic_retriever.py --config config.yaml --questions-path data/questions-answers.json --max-questions 1--max-questions 1 を使えば、まず1問だけのスモークテストができます。処理時間を見たい場合は、--timing を付けて主要処理ごとの所要時間を出力できます。(AKA.ms)
移行時に失敗しやすいポイント
既存RAGをすぐ置き換えない
既にAzure AI Search、外部ベクトルDB、独自検索基盤を使っている場合、Agentic Retrieval Toolkitへの移行は「置き換え」ではなく「比較検証」から始めるべきです。
多段RAGは、複雑な質問には強みがあります。一方で、公式ブログでも、反復検索は複数回の検索パスとLLM呼び出しを行うため、単発RAGよりレイテンシとトークンコストが増えると説明されています。(Microsoft for Developers)
比較時は、少なくとも次の4パターンを見てください。
| 比較対象 | 確認したいこと |
|---|---|
| 既存RAG | 現在の回答品質、検索漏れ、運用コスト |
| ベクトル検索のみ | 意味的に近い文書を拾えるか |
| ハイブリッド検索 | 固有名詞、型番、専門用語に強いか |
| Agentic Retrieval | 複数文書をまたぐ質問で回答が改善するか |
単純なFAQや社内規程の1文検索であれば、Agentic Retrievalの複雑な流れは過剰かもしれません。逆に、障害調査、技術仕様比較、契約条件の横断確認、研究文献の要約など、根拠が複数文書に分かれる場面では効果を検証する価値があります。
ベクトルインデックスの後戻りを軽く見ない
ベクトル検索では、埋め込みモデル、次元数、距離関数、インデックス種別を先に決める必要があります。公式ドキュメントでは、ベクトルポリシーやベクトルインデックスの設定を直接変更できず、変更するには既存設定を削除して追加し直す必要があると説明されています。(Microsoft Learn)
失敗しやすい例は、PoCで使った埋め込みモデルのまま本番設計を進め、後から別モデルへ変更して次元数が合わなくなるケースです。検証段階から、使用予定モデルの次元数、ベクトル型、インデックス種別を本番候補に近づけておくと手戻りを減らせます。
TOP N を付けない検索は避ける
ベクトル検索では、必要以上に大量の候補を返すクエリがRUとレイテンシを押し上げます。公式ドキュメントでも、ベクトル検索クエリでは常に TOP N を使うことが重要とされています。指定しない場合、必要以上の結果を返そうとしてRU消費と遅延が増える可能性があります。(Microsoft Learn)
RAGでは「とりあえず多めに取る」設計にしがちですが、取得件数を増やすほどLLMに渡す文脈も増え、トークンコストも上がります。最初は top_k、追加質問数、ラウンド数を小さくし、評価結果を見ながら広げる方が安全です。
展開前の実務チェックリスト
本番展開を検討する前に、次の項目を確認してください。
| チェック項目 | 合格の目安 |
|---|---|
| Public Previewの扱い | 本番クリティカルな経路に直接組み込まず、検証・限定利用から始める |
| 対象API | Azure Cosmos DB for NoSQLで設計している |
| データ設計 | チャンク、メタデータ、文書ID、更新日、出典URLを保持している |
| 埋め込み設計 | モデル、次元数、距離関数、ベクトル型を決めている |
| 全文検索 | 日本語データで検索品質を実測している |
| リランカー | ON/OFFで品質、遅延、コストを比較している |
| 権限 | Entra ID RBACまたはキー認証の方針が決まっている |
| コスト | RU、LLMトークン、リランカー呼び出し、再検索回数を計測している |
| 品質評価 | 期待回答付きの質問セットで、根拠の正しさまで見ている |
| フォールバック | 失敗時に既存検索や簡易RAGへ戻せる |
特に重要なのは、回答文だけで良し悪しを判断しないことです。RAGでは、自然な文章で間違った回答を生成することがあります。検証では「回答が正しいか」だけでなく、「根拠文書が正しいか」「追加質問が妥当か」「不足情報を勝手に補っていないか」を見てください。
導入判断の目安
Agentic Retrieval Toolkit for Azure Cosmos DBは、すべての検索アプリに必要なものではありません。判断基準は、質問の複雑さと、回答品質の改善が追加コストに見合うかです。
| 導入を検討しやすいケース | 慎重にしたいケース |
|---|---|
| 複数文書を横断して答える必要がある | 単純なFAQ検索で十分 |
| 技術文書、研究資料、仕様書、議事録などを扱う | ミリ秒単位の低遅延が最優先 |
| 既存RAGで検索漏れが多い | 日本語全文検索の品質検証ができない |
| Cosmos DBに文書とベクトルを集約したい | 既に別検索基盤で十分な品質が出ている |
| 検証用の評価質問セットを用意できる | Public Previewを本番SLA前提で使いたい |
まず行うべきことは、既存の全データを移行することではありません。10〜30問程度の代表質問を用意し、既存RAG、ベクトル検索、ハイブリッド検索、Agentic Retrievalの結果を比較してください。そのうえで、改善が見られた質問タイプだけに限定して、段階的に組み込むのが現実的です。
まとめ：まず非本番環境で「多段検索が効く質問」を見極める
Agentic Retrieval Toolkit for Azure Cosmos DBは、Azure Cosmos DB for NoSQLをAIアプリケーションの検索・根拠取得基盤として活用しやすくするPublic Previewのリファレンス実装です。最大の変化は、単発検索ではなく、不足情報を検出して追加検索する多段RAGを組みやすくなる点にあります。
一方で、プレビュー機能であること、ターンキーのマネージドサービスではないこと、複数回の検索とLLM呼び出しでコストやレイテンシが増えること、日本語全文検索では個別検証が必要なことは見落とせません。
次に取るべき行動は、明確です。まず非本番環境で小さなコーパスを用意し、評価質問セットを作り、既存RAGとAgentic Retrievalを比較してください。回答品質、根拠の正しさ、RU、トークン、レイテンシを数字で見てから、限定的なユースケースに展開するのが安全な進め方です。
コメント