Azure AI Search のインデクサーが、Blob Storage を「選択したネットワーク」にすると接続エラーになる――この現象は IP ホワイトリストの考え方がズレているのが原因です。マネージド ID とリソース インスタンスで安全に解決する手順を整理します。
発生しやすいシナリオ（現象の再現条件）
このトラブルは、次のような「ネットワーク制限をきちんと掛けている環境」ほど起きやすいです。
- Azure AI Search 側：ネットワーク アクセスを「選択したネットワーク」に制限（許可したネットワーク以外からのアクセスを遮断）
- Azure Blob Storage 側：ストレージ アカウントのネットワーク アクセスを「選択したネットワーク」に制限（ファイアウォール有効）
- 自分の PC から、Azure ポータル／REST API／SDK 等でインデクサーの実行を開始する
- インデクサー実行結果で「Blob Storage に接続できない」「403/Forbidden」「ネットワーク規則でブロック」等のエラーが出る
一方で、Blob Storage を一時的に「すべてのネットワークからのアクセスを許可」に戻すと成功する場合、資格情報（接続文字列・キー）が間違っているのではなく、ネットワーク制限が原因と切り分けできます。
最初に押さえるべきポイント：通信の主体は「あなたの PC」ではない
ここで多くの人がハマるのが、「PC からインデクサーを実行したのだから、Blob Storage 側には PC のグローバル IP を許可すべき」という思い込みです。
しかし実際の通信は、次の流れで発生します。
あなたの PC（実行ボタン／API 呼び出し） ↓ ※ここは「指示」 Azure AI Search（インデクサーが Azure 上で動作） ↓ ※ここが「実データ取得」 Azure Blob Storage（BLOB/コンテナ）
つまり、Blob Storage に対してデータを取りに行くのはローカル PC ではなく Azure AI Search サービスです。PC は“インデクサー開始の指示”を出しているだけで、Blob Storage へのデータ取得の通信経路に直接入りません。
| 観点 | 実際に通信する相手 | 許可すべき対象（考え方） |
|---|---|---|
| PC からインデクサーを開始できるか | PC → Azure AI Search | AI Search のネットワーク設定で、PC／社内ネットワーク／Private Endpoint 等を許可 |
| インデクサーが BLOB を読めるか | Azure AI Search → Blob Storage | Blob Storage 側で、AI Search サービスからのアクセスを許可（IP ではなくリソース単位が理想） |
症状で分かる切り分け（ネットワーク起因か、認証起因か）
「動くときは動く」系の問題は、手当たり次第の設定変更が増えがちです。まずは症状から原因を絞り込むと、最短で正しい対策に辿り着けます。
| 観測できる事象 | 示唆される原因 | 次に確認すべきポイント |
|---|---|---|
| Blob を「すべてのネットワーク許可」にすると成功する | ストレージのファイアウォールによるブロック | ストレージの「選択したネットワーク」でも AI Search から到達できる設計にする |
| ストレージを開放しても失敗する／401/403 が続く | 資格情報（キー／SAS／RBAC）が不足・誤り | データソースの認証方式、RBAC ロール付与、対象コンテナの指定を再確認 |
| ポータルからは動くが、API/CI からは開始できない | AI Search 自体へのアクセス制限 | Search サービスの「選択したネットワーク」設定、呼び出し元 IP、Private Endpoint を確認 |
質問①：Blob Storage のネットワーク設定で、どの IP アドレスを許可すればよい？
結論から言うと、「PC のグローバル IP」を許可しても根本解決になりません。許可すべきなのは、Blob Storage へアクセスしてくる主体であるAzure AI Search 側の送信元です。
IP ホワイトリストで対処するなら：許可すべきは Search の「アウトバウンド IP」
どうしても IP ベースで閉じたい場合は、一般に次の方針になります。
- Azure AI Search のアウトバウンド（送信）IP アドレスを確認し、ストレージのネットワーク許可リストに追加する
実務的には、Azure ポータルで Azure AI Search を開き、プロパティや概要情報の中にある「アウトバウンド IP アドレス」の一覧を参照し、ストレージ側の「IP ネットワーク規則」に登録します（表示される場合、複数の IP が並びます）。
ただし IP ベース運用には弱点があります。
- 許可すべき IP が複数になりやすい（構成やリージョンにより増減）
- サービス更新・スケール・再作成などで IP が変わる可能性があり、運用として追従が必要
- IP が増えるほど、ストレージの許可リストが肥大化し、管理コストと事故リスクが上がる
そのため IP ホワイトリストは「一時的な切り分け」や「短期の検証」には使えても、本番のベストプラクティスとしては採用しにくいのが実情です。
「信頼された Microsoft サービス」を許可する方法はどうか？
ストレージのネットワーク設定には、例外として「信頼された Microsoft サービスを許可する」趣旨のオプションが用意されていることがあります。これで通るケースもありますが、許可範囲が広くなりやすいため、セキュリティ要件が厳しい環境では「リソース インスタンスで特定リソースだけ許可」へ寄せた方が説明しやすいです。
対処法の選び方（結局どれが良い？を一枚で整理）
選択肢は複数あります。現場で迷ったときの判断材料として、代表的な対処法を比較しておきます。
| 方法 | セキュリティ | 運用負荷 | 向いているケース |
|---|---|---|---|
| IP ホワイトリスト（Search のアウトバウンド IP を許可） | 中（IP が増えるほど管理が難しい） | 高（IP 変更・追加に追従） | 短期検証、切り分け、やむを得ず IP ベースで閉じたい |
| 信頼された Microsoft サービスを許可 | 中〜低（許可範囲が広くなりがち） | 低 | 要件が緩めで、素早く通したい |
| マネージド ID ＋ リソース インスタンス許可 ＋ RBAC | 高（リソース単位＋最小権限） | 低（秘密情報なし・IP 追従なし） | 本番推奨。選択したネットワークを維持したい |
| Private Endpoint ＋ Shared Private Link | 最高（完全にプライベート経路化） | 中〜高（DNS/承認/設計が必要） | パブリック通信を排除したい、監査要件が厳しい |
推奨される解決策：マネージド ID と「リソース インスタンス」で閉じる
結論としては、個別 IP の登録ではなく、Azure の管理単位（リソース）でアクセスを許可する設計が推奨です。具体的には次の 3 点セットが軸になります。
- Azure AI Search でシステム割り当てマネージド IDを有効化
- Blob Storage のネットワーク設定でリソース インスタンス（Resource instances）として AI Search を許可
- ストレージの IAM（RBAC）で、マネージド ID にStorage Blob Data Reader等の最小権限ロールを付与
この構成に寄せると、ネットワーク制限と権限管理をどちらも「Azure の標準機能」で一貫して制御できるようになります。接続文字列やアカウントキーを扱わずに済む点も、運用の事故を減らします。
手順：システム割り当てマネージド ID でインデクサー接続を復旧する
以下は、質問文の「解消した構成」を、手順として再現できるように整理したものです。画面名はポータルの表記揺れがあり得るため、近い項目を辿ってください。
AI Search サービスでシステム割り当てマネージド ID を有効化
- Azure ポータルで対象の Azure AI Search を開く
- 設定メニューから 「ID（Identity / マネージド ID）」 を開く
- 「システム割り当て」 をオンにして保存する
この操作により、Azure AI Search リソースに「サービス固有の ID（サービス プリンシパル）」が割り当てられ、RBAC の付与先として選べるようになります。
Blob Storage のネットワークで「リソース インスタンス」を許可
- 対象ストレージ アカウントを開く
- 「ネットワーク」（または「Networking / ファイアウォールと仮想ネットワーク」）を開く
- 「パブリック ネットワーク アクセス」は「選択したネットワーク」のまま維持する
- 同画面の 「リソース インスタンス」 から、許可するリソースとして Azure AI Search サービスを追加する
ここが最大のポイントです。IP アドレスを許可するのではなく、「この検索サービス（リソース）から来る通信は許可する」という単位で閉じられます。ネットワークの閉域性を崩さずに済みます。
ストレージに RBAC（IAM）で必要なロールを付与
次に、「ネットワーク的に届く」だけでは足りないので、データにアクセスできる権限（認可）を付けます。
- ストレージ アカウントの 「アクセス制御 (IAM)」 を開く
- 「ロールの割り当て」を追加
- 割り当て先に、AI Search のシステム割り当てマネージド IDを選択
- ロールは基本的に 「Storage Blob Data Reader（ストレージ Blob データ閲覧者）」 を付与
| ロール名 | できること | 用途の目安 |
|---|---|---|
| Storage Blob Data Reader | Blob の読み取り（一覧・取得） | 取り込み（インデクシング）専用。最小権限で推奨されやすい |
| Storage Blob Data Contributor | 読み取り＋書き込み＋削除 | インデクサーが中間成果を保存する等、書き込みが必要な特殊ケース |
| Storage Blob Data Owner | データ操作＋ACL 管理 | 原則不要。本番では避けたい（権限が強い） |
多くのケースでは Reader で十分です。「とりあえず Owner」は権限過多になりやすいので、まず Reader で動かし、必要なときだけ段階的に上げるのが安全です。
AI Search のデータソースを「マネージド ID 認証」に変更
最後に、AI Search 側のデータソース設定を見直します。接続文字列（アカウントキー）で接続している場合は、マネージド ID を使った認証に切り替えます。
- Azure AI Search を開き、「インデクサー」→「データ ソース」を開く
- 対象のデータソースを編集（もしくは新規作成）
- 認証方式を 「マネージド ID（システム割り当て）」 に変更
- 対象のコンテナ、パス、インデクサー設定（変更検出など）を保存
| 認証方式 | 秘密情報の管理 | ネットワーク制限との相性 | コメント |
|---|---|---|---|
| 接続文字列（アカウントキー） | 必要（キー保管・漏えい対策・ローテーション） | 弱い（ネットワーク許可が IP 寄りになりがち） | 短期検証なら楽だが、本番運用では注意点が多い |
| SAS | 必要（期限管理・再発行） | 中 | 期限切れが事故原因になりやすい |
| マネージド ID（RBAC） | 不要 | 強い（リソース インスタンス等と組み合わせやすい） | 推奨。最小権限で設計しやすい |
この時点で、「ネットワークはリソース インスタンスで許可」「権限は RBAC」「秘密情報は保持しない」という形に揃います。
インデクサー実行と確認ポイント
インデクサーを実行したら、失敗時は「エラー詳細」を必ず確認します。特に次の 2 系統のメッセージは意味が異なります。
- ネットワーク遮断系：ストレージのネットワーク規則で拒否された、到達できない、など
- 権限不足系：RBAC が足りない、対象コンテナにアクセスできない、など
ネットワーク遮断系が出る場合は「リソース インスタンスの追加漏れ」や「別のストレージ アカウントを参照している」などが典型です。権限不足系なら、IAM のスコープ（ストレージ アカウント／コンテナ）やロール種別を見直します。
質問②：システム割り当てマネージド ID を使う構成は正しい／推奨？
はい。システム割り当てマネージド ID＋リソース インスタンス許可＋RBAC は、セキュリティと運用の両面で合理的です。質問文の「受け付けられた回答でも正しい／推奨される」とされるのは、まさにこの点にあります。
この構成が“推奨されやすい”理由
- 秘密情報を持たない：接続文字列やアカウントキーを配布・保管・ローテーションする必要がない
- ネットワーク制御と相性が良い：IP ではなく「リソース」を許可対象にでき、閉域を維持しやすい
- 最小権限（Least Privilege）：Reader など読み取り専用ロールに絞れる
- 変更に強い：スケールや環境追加で IP が増えても、設計の軸がブレにくい
システム割り当てとユーザー割り当て、どちらを選ぶべき？
マネージド ID には大きく 2 種類あります。どちらが正解というより、用途で使い分けます。
| 種類 | 特徴 | 向いているケース |
|---|---|---|
| システム割り当て | Search リソースと 1:1。削除すると ID も消える | まずはこれ。単一サービスの取り込み、検証〜本番まで素直に使える |
| ユーザー割り当て | ID を独立して管理でき、複数リソースで共有可能 | 複数の Search／Function／Data Factory などで同一 ID を共有したい、移行や入れ替えを頻繁に行う |
「今回のインデクサー接続問題を解消する」目的なら、システム割り当てで十分なことが多いです。運用ポリシー上、ID のライフサイクルを分離したい場合にユーザー割り当てを検討すると分かりやすいです。
推奨構成を採用したときのメリット（現場で効くポイント）
資格情報（接続文字列）を扱わないので、事故が減る
ストレージのアカウントキーは強力で、漏れると被害が大きくなりがちです。マネージド ID へ寄せると、「キーをどこに保存したか」「誰が知っているか」という管理問題から解放されます。
IP 変更に追従しない運用にできる
IP ホワイトリストは、NAT 変更・回線変更・サービス側の IP 変更などで「ある日突然止まる」リスクがあります。リソース インスタンス許可なら、許可の単位が Azure リソースなので変更に強い設計にできます。
監査・棚卸しがしやすい
IAM（RBAC）でロール割り当てが可視化されるため、「どの Search がどのストレージにアクセスできるか」を棚卸ししやすくなります。セキュリティ監査や引き継ぎ時に効いてきます。
よくある落とし穴（ハマりどころ）とチェックリスト
同じ構成にしても、細部の漏れで詰まることがあります。以下のチェック表を、作業後のセルフレビューに使ってください。
| チェック項目 | ありがちなミス | 対処の方向性 |
|---|---|---|
| ストレージのネットワーク | 「選択したネットワーク」にしたが、リソース インスタンスを追加していない | ストレージのネットワーク画面で、AI Search を Resource instances に追加 |
| RBAC ロール | ロールを付けたつもりが、付与先が「Search サービスの ID」ではなく別の ID だった | 割り当て先に「（Search 名）のシステム割り当てマネージド ID」を選ぶ |
| RBAC のスコープ | 別のストレージ／別のリソースグループに付与していた | スコープを「対象ストレージ アカウント（または対象コンテナ）」で付与し直す |
| データソースの認証方式 | データソースが接続文字列（キー）のまま | データソースを編集し、認証方式を「マネージド ID」に切り替える |
| 参照先のコンテナ | コンテナ名／パスの誤りで、存在しない場所を読みに行っている | ストレージ側で実体のパスを確認し、データソースの指定を合わせる |
より閉域に寄せたい場合：Private Endpoint と Shared Private Link の考え方
「パブリック ネットワークを一切通したくない」「社内基準で Storage は Private Endpoint 必須」という環境もあります。その場合は、今回の“リソース インスタンス許可”に加えて、次の設計も検討対象になります。
- ストレージ アカウントに Private Endpoint を作り、パブリック アクセスを無効化する
- Azure AI Search からデータソースへ到達させるために、Shared Private Link（検索サービスから参照先リソースへ張るプライベートリンク）を構成する
ただし Private Endpoint は DNS や承認フロー、運用ルールまで含めた設計が必要です。まずは本記事の構成（マネージド ID＋リソース インスタンス＋RBAC）で「閉じたまま動く」状態を作り、要件が厳しい場合に段階的に Private 化していくのが失敗しにくい進め方です。
まとめ：IP を追いかけるより、リソースと権限で堅牢にする
Azure AI Search のインデクサーが Blob Storage に接続できない問題は、単なる設定ミスというより、「誰が」「どこから」データを取りに行くのかの理解ズレから起きやすいトラブルです。
- Blob Storage 側で許可すべきは「あなたの PC」ではなく、Azure AI Search サービス
- IP ホワイトリスト運用は管理コストが高く、長期運用には不向きになりやすい
- マネージド ID＋リソース インスタンス許可＋RBACは、閉域性とセキュリティと運用性のバランスが良い
これから同様の構成を組む場合も、まずはこの 3 点セットを“基準の設計”として採用し、要件に応じて Private Endpoint などを追加していくと、無理なく安全な構成に到達できます。
コメント