Azure AI Foundryで社内文書や製品マニュアルを使ったAIエージェントを作るなら、今回確認すべきポイントは明確です。Foundry agentsにAzure AI Searchインデックスを接続することで、エージェントの回答を自社データに基づかせ、引用付きで返せるようになります。 一方で、プライベートネットワーク、認証方式、インデックス設計、接続IDの扱いを誤ると、401/403エラーや「インデックスが見つからない」といったトラブルにつながります。
Microsoft Learnの該当ドキュメントでは、Azure AI Searchツールがインデックス済みドキュメントを取得し、Foundryモデルがインライン引用付きの回答を生成できることが説明されています。日本語ページでは2026年6月3日が最終更新日として表示されているため、2026年5月29日前後の更新情報として追っていた管理者・開発者も、最新表示を確認したうえで設定を見直すのが安全です。(Microsoft Learn)
Azure AI FoundryとAzure AI Search連携で何が変わるのか
今回のポイントは、Azure AI FoundryのFoundry agentsが、Azure AI Searchインデックスを外部知識ソースとして直接利用しやすくなっている点です。
これまでRAG構成を作る場合、検索処理、プロンプトへのコンテキスト挿入、引用情報の整形などをアプリケーション側で実装するケースが多くありました。今回の公式手順では、Foundry agentにAzure AI Searchツールを設定し、インデックス名や接続ID、検索方式を指定することで、エージェントが検索インデックスを参照して回答できます。
特に重要なのは、単に「検索できる」ことではありません。回答に引用を含める前提で構成できるため、社内FAQ、規程、製品仕様、サポート文書、ナレッジベースなどを使う業務AIで、根拠を確認しながら回答を利用できるようになります。
ただし、完全に自動で高精度な社内AIが完成するわけではありません。インデックスに必要なフィールドがない、URLやタイトルが取得不可になっている、エージェントの指示で引用を求めていない、といった状態では、期待した引用付き回答にならない可能性があります。
影響を受ける利用者・管理者・開発者
今回のAzure AI Foundry更新で特に確認すべき対象は、次のようなチームです。
| 対象 | 確認すべきこと |
|---|---|
| Azure管理者 | Foundryプロジェクト、Azure AI Search、マネージドID、RBAC、ネットワーク設定 |
| AIアプリ開発者 | SDK、REST API、接続ID、query_type、ストリーミング時の引用取得 |
| 情報システム部門 | 社内文書の公開範囲、APIキー管理、Key Vault利用、監査要件 |
| セキュリティ担当 | プライベートエンドポイント、パブリックネットワーク無効化、キーレス認証 |
| 業務部門のAI推進担当 | どの文書を検索対象にするか、回答の根拠をどう検証するか |
PoCでは「とりあえずAPIキーで接続する」構成でも動作確認できる場合があります。しかし、本番環境や閉域ネットワークで利用する場合は、最初からMicrosoft Entra IDとマネージドIDを前提に設計したほうが安全です。
まず理解すべき構成：Foundry agentが検索インデックスを参照する
Azure AI FoundryでAzure AI SearchインデックスをFoundry agentsに接続する構成は、大きく次の流れで考えると分かりやすくなります。
- Azure AI Searchに社内文書やナレッジを取り込む
- ベクトル検索に対応したインデックスを作成する
- FoundryプロジェクトからAzure AI Searchサービスへの接続を作成する
- Foundry agentにAzure AI Searchツールを追加する
- エージェントの回答に引用が出るか検証する
公式ドキュメントでは、既存の検索インデックスがある場合の想定セットアップ時間は15〜30分とされています。ただし、これはインデックスや権限が整っている場合の目安です。実務では、文書の整形、チャンク分割、URLフィールドの設計、アクセス権限の確認に時間がかかることが多いため、PoCでも半日から数日程度の検証時間を見込むと現実的です。(Microsoft Learn)
インデックス設計で確認すべきポイント
Azure AI Searchインデックスは、単に文書を入れておけばよいわけではありません。Foundry agentに接続する場合は、検索と引用に必要なフィールドを意識して設計する必要があります。
公式ドキュメントでは、ベクトル検索用に構成されたAzure AI Searchインデックスとして、検索可能かつ取得可能な文字列フィールド、検索可能なベクトルフィールド、引用対象となる本文フィールド、引用リンクに使えるソースURLフィールドなどが前提条件として示されています。(Microsoft Learn)
実務で確認すべき項目は次のとおりです。
| 確認項目 | 見落とすと起きる問題 | 実務上の判断基準 |
|---|---|---|
| 本文フィールドが取得可能か | 回答の根拠として使えない | チャンク本文はretrievableにする |
| URLフィールドがあるか | 引用リンクを表示できない | 元文書URL、SharePoint URL、Blob URLなどを保持する |
| タイトルフィールドがあるか | 引用が分かりにくい | 文書名、章タイトル、ページ名を持たせる |
| ベクトルフィールドがあるか | ベクトル検索が使えない | Collection(Edm.Single)のベクトルフィールドを確認する |
| フィルター用フィールドがあるか | 部署別・製品別の出し分けが難しい | category、department、product、permissionなどを設計する |
特に重要なのは、検索精度より先に引用の確認性を設計することです。回答が正しそうに見えても、引用URLが不明、タイトルが空、古い文書を参照している状態では、業務利用時の信頼性が下がります。
ツールパラメーターの見方
Foundry agentにAzure AI Searchツールを設定する際は、主に次のパラメーターを確認します。
| パラメーター | 必須 | 役割 |
| ———————– | -: | —————————————- |
| project_connection_id | 必須 | FoundryプロジェクトからAzure AI Searchへの接続リソースID |
| index_name | 必須 | 利用するAzure AI Searchインデックス名 |
| top_k | 任意 | 検索結果として取得する件数。既定値は5 |
| query_type | 任意 | 検索方式。既定値はvector_semantic_hybrid |
| filter | 任意 | エージェントがインデックスに投げる全クエリに適用する条件 |
公式ドキュメントでは、query_typeのサポート値として、simple、vector、semantic、vector_simple_hybrid、vector_semantic_hybridが示されています。既定値はvector_semantic_hybridです。(Microsoft Learn)
実務では、最初から既定値だけで進めるのではなく、次のように使い分けると検証しやすくなります。
| 利用シーン | 検討しやすい検索方式 |
|---|---|
| キーワード一致をまず確認したい | simple |
| 意味的に近い文書を拾いたい | vector |
| セマンティックランキングを使いたい | semantic |
| キーワードとベクトルを組み合わせたい | vector_simple_hybrid |
| 精度重視でハイブリッド検索を試したい | vector_semantic_hybrid |
PoCでは、まずsimpleやsemanticで「正しい文書に当たるか」を確認し、その後にハイブリッド検索へ広げると、問題の切り分けがしやすくなります。
認証方式の注意点：本番ではキーレス認証を優先する
Azure AI Searchとの接続では、キー認証とキーレス認証のどちらを使うかが重要です。
公式ドキュメントでは、プライベート仮想ネットワークでAzure AI Searchツールを使う場合、Microsoft EntraプロジェクトマネージドIDによる認証が必要であり、キーベース認証はサポートされないとされています。(Microsoft Learn)
これは本番設計で大きな影響があります。たとえば、Azure AI Searchのパブリックネットワークアクセスを無効化し、プライベートエンドポイント経由で使う構成では、APIキーを設定しても接続できません。FoundryプロジェクトのマネージドIDに適切なRBACロールを付与し、Azure AI Search接続をキーレス認証で構成する必要があります。
キーレス認証では、公式ドキュメント上で次のRBACロールが案内されています。
| 割り当て先 | 必要なロール |
|---|---|
| FoundryプロジェクトのマネージドID | 検索インデックス データ共同作成者 |
| FoundryプロジェクトのマネージドID | Search Service 共同作成者 |
401/403エラーが出る場合は、コードを疑う前に、まずマネージドIDとRBACの割り当てを確認してください。特に、Azure AI Searchリソース側ではなく、別のリソースグループや別テナントにロールを付けてしまうミスが起きやすいです。
ネットワーク構成で注意すべき制限
今回の公式情報で、管理者が最も注意すべきなのはネットワーク関連の制限です。
公式ドキュメントでは、基本的なエージェントデプロイを使用するFoundryリソースでは、プライベートAzure AI Searchリソースや、パブリックネットワークアクセスを無効化してプライベートエンドポイントを持つAzure AI Searchはサポートされないと説明されています。プライベートAzure AI Searchツールをエージェントで使うには、仮想ネットワークインジェクションを使った標準エージェントのデプロイが必要です。(Microsoft Learn)
つまり、次のような判断が必要です。
| 構成 | 推奨判断 |
|---|---|
| PoCで公開ネットワーク許可の検索サービスを使う | まず動作確認は可能。ただし本番移行時の再設計を前提にする |
| 本番で閉域構成にしたい | 標準エージェントと仮想ネットワークインジェクションを検討する |
| パブリックネットワークアクセスを無効にする | APIキーではなくマネージドID認証に切り替える |
| 別テナントのAzure AI Searchを使いたい | 同一テナント制約に注意し、構成を見直す |
ネットワーク制限は、開発後半で発覚すると手戻りが大きくなります。PoC開始時点で「本番では閉域化するのか」「検索サービスはどのテナントに置くのか」「FoundryプロジェクトはBasicかStandardか」を決めておくべきです。
接続作成時の実務ポイント
Azure AI FoundryプロジェクトとAzure AI Searchサービスの接続は、Foundryポータル、Azure CLI、Python SDK、REST API、Bicepなどで作成できます。ポータルでの作成が最も手軽ですが、複数環境へ展開する場合はCLI、Bicep、REST APIを使った再現性のある構成が向いています。(Microsoft Learn)
ポータルで確認する場合の流れは、次のように整理できます。
| 手順 | 確認内容 |
|---|---|
| Foundryポータルを開く | 対象のプロジェクトを間違えていないか |
| Operate > Adminへ進む | 管理対象のプロジェクトを確認 |
| Add connectionを選ぶ | 接続先としてAzure AI Searchを選択 |
| Searchサービスを選択 | インデックスが存在するサービスか確認 |
| Authenticationを選択 | キー認証かキーレス認証かを決める |
| 接続を追加 | 接続名と接続IDを控える |
開発者が特に注意したいのは、RESTやTypeScriptサンプルではproject_connection_idが必要になる点です。Python、C#、TypeScriptの一部サンプルでは接続名からSDKで接続IDを取得できますが、環境変数やIaCで展開する場合は、接続IDをどこで解決するかを決めておく必要があります。
移行時の注意点：az mlではなくaz cognitiveservicesを使う
既存のAzure Machine Learning系ワークスペースや古いサンプルに慣れているチームは、接続作成時のコマンドに注意が必要です。
公式ドキュメントのトラブルシューティングでは、接続作成時に「Workspace not found」が出る原因として、az ml CLIやazure-ai-ml Python SDKが新しいFoundryプロジェクトのMicrosoft.CognitiveServicesリソースプロバイダーをサポートしないことが示されています。解決策として、az cognitiveservices account project connection createまたはazure-mgmt-cognitiveservices Python SDKを使うことが案内されています。(Microsoft Learn)
移行作業では、次の観点で棚卸ししてください。
| 確認対象 | 見直す内容 |
|---|---|
| 既存のデプロイスクリプト | az mlに依存していないか |
| Python管理スクリプト | azure-ai-ml前提の接続作成になっていないか |
| IaCテンプレート | Foundryプロジェクトのリソースプロバイダーに合っているか |
| CI/CD | APIキーを直接リポジトリや変数に置いていないか |
| 環境分離 | dev、stg、prodで接続先Searchサービスが混ざっていないか |
「ローカルでは動いたがCI/CDで失敗する」場合、認証方式、接続ID、リソースプロバイダーの不一致を優先的に確認すると解決が早くなります。
開発者が確認すべき実装上のポイント
Azure AI SearchをFoundry agentsに接続しただけでは、業務で使える回答品質にはなりません。開発者は、少なくとも次の3点を確認する必要があります。
エージェントの指示で引用を明示する
公式サンプルでは、エージェントのinstructionsに「回答では必ず引用を提供する」趣旨の指示が含まれています。引用が出ない場合、検索ツールの問題ではなく、エージェント指示が不足していることがあります。
業務向けには、たとえば次のような指示を入れると運用しやすくなります。
回答は必ず検索インデックス内の情報に基づいてください。
根拠が見つからない場合は推測せず、「該当する根拠が見つかりません」と回答してください。
回答には可能な限り引用を含めてください。ポイントは、「分からない場合の挙動」まで指定することです。これを入れないと、検索結果が不十分なときにモデルが一般知識で補ってしまう可能性があります。
ストリーミング時は引用アノテーションを取得する
ストリーミング応答を使う場合、本文の差分だけを表示していると、引用情報を取りこぼすことがあります。公式ドキュメントでも、ストリーミング時にurl_citationアノテーションが表示されることを確認するよう案内されています。(Microsoft Learn)
チャットUIを作る場合は、本文表示と引用表示を別々に設計してください。ユーザーが回答を読んだ後、すぐに根拠文書を開ける導線が必要です。
filterで検索範囲を制御する
filterは、エージェントがインデックスに対して行うすべてのクエリに適用されます。部署、製品、文書種別、公開範囲などで検索対象を絞る場合に有効です。
ただし、filterを固定しすぎると、本来参照すべき文書が検索対象から外れる可能性があります。たとえば、製品Aの問い合わせでも、共通規約や全社FAQに回答があるケースがあります。業務設計では、フィルターを「権限制御」と「精度向上」のどちらに使うのかを分けて考えるべきです。
管理者向けチェックリスト
本番展開前に、管理者は次の項目を確認してください。
| 項目 | 確認内容 |
|---|---|
| テナント | Azure AI SearchとFoundry Agentが同じテナントにあるか |
| ネットワーク | Basic/Standard、VNet、プライベートエンドポイントの要件が合っているか |
| 認証 | 本番でAPIキーに依存していないか |
| RBAC | FoundryプロジェクトのマネージドIDに必要ロールを付与しているか |
| シークレット管理 | APIキーを使う場合でもソース管理に含めていないか |
| 接続先 | dev/stg/prodで誤ったSearchサービスを参照していないか |
| インデックス | 本文、URL、タイトル、ベクトル、フィルター用フィールドが揃っているか |
| 監査 | 回答ログ、引用URL、参照文書の確認方法を決めているか |
特にAPIキーを使う場合、公式ドキュメントでも実キーをソース管理に置かず、Azure Key Vaultなどの安全なストアに格納し、デプロイ時に注入することが推奨されています。(Microsoft Learn)
よくある失敗と対処法
Azure AI FoundryとAzure AI Searchの連携では、エラーの原因がコード、権限、ネットワーク、インデックス設計のどこにあるか分かりにくいことがあります。代表的な失敗パターンを先に把握しておくと、切り分けが速くなります。
| 症状 | よくある原因 | 対処 |
|---|---|---|
| 401/403が出る | マネージドIDにRBACロールがない | Search Index Data Contributor、Search Service Contributorを確認 |
| 引用が出ない | エージェント指示で引用を求めていない | instructionsに引用必須の指示を追加 |
| ストリーミングで引用が出ない | url_citationを処理していない | ストリーム処理ロジックを見直す |
| index not found | インデックス名の大小文字や接続先が違う | index_nameとSearchサービスを確認 |
| 検索結果が空 | インデックスに対象文書がない、検索方式が合わない | Azure AI Search側でテストクエリを実行 |
| プライベート接続で失敗 | APIキー認証を使っている | マネージドIDによるキーレス認証に変更 |
| Workspace not found | az ml系コマンドを使っている | az cognitiveservices系に変更 |
公式ドキュメントでも、401/403、インデックス名不一致、接続エンドポイント誤り、検索結果なし、パフォーマンス低下、プライベートネットワークでのキー認証利用などがトラブルシューティング項目として整理されています。(Microsoft Learn)
Foundry IQとの使い分け
ドキュメント冒頭では、マネージドなナレッジベース体験としてFoundry IQも案内されています。(Microsoft Learn)
単純に「社内文書をアップロードして、エージェントに根拠付きで回答させたい」という目的であれば、Foundry IQのほうが運用負荷を下げられる可能性があります。一方で、既にAzure AI Searchインデックスを持っている、独自のインデックス設計やフィルター制御をしたい、既存の検索基盤を活かしたい場合は、Azure AI Searchツールを直接接続する構成が向いています。
| 選択肢 | 向いているケース |
|---|---|
| Azure AI Searchインデックス接続 | 既存のSearch基盤を活用したい、スキーマや検索方式を細かく制御したい |
| Foundry IQ | マネージドなナレッジベース体験を優先したい、運用負荷を抑えたい |
どちらを選ぶかは、「誰がインデックスを管理するのか」「文書更新をどの頻度で行うのか」「検索精度をどこまで制御したいのか」で判断するとよいでしょう。
本番展開前に行うべき検証
最後に、実際にFoundry agentへAzure AI Searchインデックスを接続した後は、次の観点で検証してください。
1つ目は、答えが分かっている質問でテストすることです。特定の文書に明確な答えがある質問を用意し、エージェントが正しい文書を参照するか確認します。
2つ目は、引用が本文と一致しているか確認することです。引用URLが表示されていても、回答内容と引用元の該当箇所がずれていれば、業務利用では危険です。
3つ目は、検索できない質問での挙動を確認することです。インデックスに存在しない情報を聞いたとき、エージェントが推測で答えず、根拠が見つからないと返せるかを確認します。
4つ目は、権限別の検索範囲を確認することです。部署別、顧客別、機密区分別の文書がある場合、ユーザーに見せてはいけない文書が引用されないかを必ずテストしてください。
Azure AI FoundryでAzure AI SearchインデックスをFoundry agentsに接続する構成は、社内ナレッジ活用やRAG型AIアプリの実装を進めるうえで有力な選択肢です。ただし、成功の鍵は接続手順そのものではなく、インデックス設計、認証、ネットワーク、引用検証を最初から運用前提で整えることにあります。まずはPoC環境で小さなインデックスを接続し、引用付き回答、RBAC、プライベートネットワーク要件、CI/CDでの接続作成まで確認してから、本番展開へ進めるのが安全です。
コメント