2026年6月3日に公開または更新された公式情報では、Azure AI Search が Microsoft Foundry リソースに対して行う課金関連の呼び出しで、マネージド ID 認証を利用できるようになりました。要点は、従来のキー ベースの流れを、Microsoft Entra ID によるマネージド ID と Azure RBAC に置き換えられることです。Azure AI Search で AI エンリッチメントや Foundry Tools を使っている環境では、キーの保管・ローテーション・漏えい対策を見直す良いタイミングです。公式の Azure Updates では、この機能は「Launched」「Generally Available」として掲載されており、本番利用可能な状態として扱われます。(Microsoft Azure)
Microsoft EntraのAI/Copilot更新で何が変わるのか
今回の更新は、Azure AI Search の検索機能そのものを大きく変えるものではありません。変更の中心は、Azure AI Search が Microsoft Foundry リソースを課金対象として関連付けるときの認証方式です。
これまでは、Foundry リソースのキーを skillset に設定し、Azure AI Search 側からそのキーを使って課金用の関連付けを行う構成が一般的でした。今回の一般提供により、Azure AI Search サービスにシステム割り当て、またはユーザー割り当てのマネージド ID を付与し、その ID に Foundry リソース側で必要なロールを割り当てる構成を選べるようになります。
実務上の意味は明確です。キーをアプリケーション設定や skillset 定義に持たせる運用から、Microsoft Entra ID と RBAC で認可する運用へ寄せられるということです。
Azure AI Search の AI エンリッチメントでは、Built-in skills が Azure Vision、Azure Language、Azure Translator などの Foundry Tools に基づく API を呼び出す場合があり、その課金を Foundry リソースに集約できます。Microsoft Learn では、Foundry リソースは主に課金目的で skillset に関連付けられ、キー方式またはキーなし方式を利用できると説明されています。(Microsoft Learn)
今回の変更点を一言で整理
今回の「Managed identity for Foundry billing calls from Azure AI Search」は、次のように理解すると分かりやすいです。
| 項目 | これまでの代表的な構成 | 今回の更新後に選べる構成 |
|---|---|---|
| 認証方式 | Foundry リソースのキーを skillset に設定 | Azure AI Search のマネージド ID を使用 |
| 権限管理 | キーを知っているかどうかに依存しやすい | Microsoft Entra ID と Azure RBAC で管理 |
| キー管理 | 保管、秘匿、ローテーションが必要 | 課金連携部分ではキーを持たせない構成が可能 |
| ID の種類 | なし | システム割り当て ID、ユーザー割り当て ID |
| 主な設定場所 | skillset の cognitiveServices セクション | Search サービスの Identity、Foundry リソースの Access control、skillset |
| 運用上の利点 | 既存構成との互換性が高い | 最小権限、監査、IaC 管理に寄せやすい |
重要なのは、課金方式そのものが無料になるわけではない点です。変わるのは、Foundry リソースを課金先として関連付けるときの認証方法です。AI エンリッチメントの課金対象スキルを使えば、従来どおり利用量に応じた課金確認が必要です。
なぜMicrosoft Entraが関係するのか
マネージド ID は、Azure リソースに紐づく Microsoft Entra ID のセキュリティ プリンシパルです。Azure AI Search サービスでシステム割り当てマネージド ID を有効にすると、その Search サービス専用の ID が Microsoft Entra ID 上に作成され、他の Azure リソースへの認証に使われます。(Microsoft Learn)
つまり今回の更新は、Azure AI Search と Microsoft Foundry の課金連携を、単なる「キーの受け渡し」ではなく、Entra ID ベースのアクセス制御に寄せる変更です。
管理者にとっては、次のような運用改善につながります。
- Foundry リソースのキーを skillset 定義や構成ファイルに含めずに済む
- RBAC で「どの Azure AI Search サービスが Foundry リソースを使えるか」を管理できる
- システム割り当て ID とユーザー割り当て ID を、環境や運用ポリシーに応じて選べる
- IaC や CI/CD で ID とロール割り当てを管理しやすくなる
特に本番環境では、キーのコピー、退職者が残した設定、古い Key Vault シークレット、検証環境からの流用などが事故につながりやすいポイントです。今回の更新は、こうした「キーが残り続けるリスク」を減らす方向の改善といえます。
影響を受ける環境、受けにくい環境
すべての Azure AI Search 利用者がすぐに設定変更を求められるわけではありません。影響を受けやすいのは、Azure AI Search の skillset と Microsoft Foundry リソースを組み合わせている環境です。
| 環境 | 影響度 | 確認すべきこと |
|---|---|---|
| Azure AI Search で AI エンリッチメントを使っている | 高 | skillset の cognitiveServices 設定、Foundry リソースの関連付け方式 |
| OCR、画像分析、言語検出、翻訳などの Built-in skills を使っている | 高 | Foundry Tools への課金がどのリソースに紐づいているか |
| Foundry リソースのキーを skillset に設定している | 高 | マネージド ID 方式へ移行できるか |
| Azure AI Search をキーワード検索やベクトル検索だけで使っている | 低〜中 | Foundry 課金連携を使っていなければ直接影響は限定的 |
| Azure AI Search の管理キーやクエリキーだけを使っている | 低 | 今回の対象は主に Foundry 課金呼び出しであり、検索 API 全体の認証変更ではない |
| Custom Web API skill だけを使っている | 構成次第 | Foundry Tools の課金連携を使っているか確認 |
Microsoft Learn では、Foundry リソースを skillset に関連付けることで、Azure Vision、Azure Language、Azure Translator などの Foundry Tools 利用分を Foundry リソース側で課金できると説明されています。小規模な無料枠を超える処理では、課金対象リソースの関連付けが重要になります。(Microsoft Learn)
管理者がまず確認すべき設定
最初に見るべき場所は、Azure AI Search の skillset 定義です。既存環境で Foundry リソースのキーを使っている場合、cognitiveServices セクションにキー方式の設定が含まれている可能性があります。
確認ポイント
| 確認項目 | 見る場所 | 判断基準 |
|---|---|---|
| マネージド ID が有効か | Azure AI Search > Settings > Identity | System assigned が On、または User assigned が追加済みか |
| Foundry リソースにロールがあるか | Foundry リソース > Access control | Search サービスの ID に Cognitive Services User が付与されているか |
| skillset がキー方式か | Azure AI Search > Skillsets、または REST API | AIServicesByKey やキー値を使っていないか |
| Foundry リソースの endpoint | Foundry リソース > Keys and Endpoint | https://<resource-name>.services.ai.azure.com などの URL を使えるか |
| API / SDK の対応 | REST API、SDK、IaC | skillset 更新に対応したバージョンか |
| ネットワーク制御 | Private endpoint、Shared private link、NSP | 課金呼び出しが遮断されないか |
キーなし接続では、Azure AI Search サービスにマネージド ID を構成し、Foundry リソース上でその ID に Cognitive Services User ロールを割り当て、skillset 側でマネージド ID を使うよう設定します。Microsoft Learn では、システム割り当て ID とユーザー割り当て ID の両方がサポートされると説明されています。(Microsoft Learn)
システム割り当てIDとユーザー割り当てIDの選び方
マネージド ID には、システム割り当てとユーザー割り当てがあります。どちらも使えますが、運用上の性質が異なります。
| 種類 | 向いているケース | 注意点 |
|---|---|---|
| システム割り当てマネージド ID | Search サービス単位でシンプルに管理したい。本番・検証でリソースが明確に分かれている | Search サービスのライフサイクルに紐づくため、リソース再作成時はロール割り当ての再確認が必要 |
| ユーザー割り当てマネージド ID | 複数環境で ID を明示的に管理したい。IaC で ID を先に作り、ロール割り当てを安定させたい | ID リソース自体の作成・命名・権限管理が必要 |
迷った場合は、単一の Search サービスに閉じた構成ならシステム割り当て ID が簡単です。複数環境や大規模運用では、ユーザー割り当て ID のほうが、権限の棚卸しや IaC 管理に向いています。
ただし、ユーザー割り当て ID は「共有すれば便利」ですが、共有しすぎると権限境界が曖昧になります。たとえば、開発環境と本番環境で同じ ID を使うと、本来分けるべきアクセス権が混ざる可能性があります。基本は、環境単位、アプリケーション単位、または責任分界単位で分ける設計が安全です。
移行手順の実務例
既存のキー方式からマネージド ID 方式へ移行する場合は、いきなり本番 skillset を書き換えないことが重要です。インデクサーの実行に失敗すると、検索インデックスの更新が止まる可能性があります。
| 手順 | 作業内容 | 失敗しやすいポイント |
| -: | ———————————————- | ——————————— |
| 1 | 既存 skillset の JSON をバックアップする | 後から元に戻せない状態で直接編集してしまう |
| 2 | Azure AI Search にマネージド ID を有効化する | ID 作成直後は反映に数分かかる場合がある |
| 3 | Foundry リソースに Cognitive Services User を割り当てる | Search サービスではなく別の ID に付与してしまう |
| 4 | 検証環境の skillset を AIServicesByIdentity に変更する | subdomainUrl や identity の指定ミス |
| 5 | インデクサーを手動実行して履歴を確認する | 認可エラーとネットワークエラーを混同する |
| 6 | 本番へ段階展開する | 全 skillset を一括変更して障害範囲が広がる |
| 7 | 不要になったキー参照を削除し、必要に応じてキーをローテーションする | 古いキーが構成ファイルや CI/CD 変数に残る |
システム割り当て ID の skillset 例は、概念的には次のような形です。
{
"name": "my-skillset",
"skills": [
{
"...": "skills definition"
}
],
"cognitiveServices": {
"@odata.type": "#Microsoft.Azure.Search.AIServicesByIdentity",
"description": "Billing through system-assigned managed identity.",
"subdomainUrl": "https://<resource-name>.services.ai.azure.com",
"identity": null
}
}ユーザー割り当て ID を使う場合は、identity にユーザー割り当てマネージド ID のリソース ID を指定します。
{
"name": "my-skillset",
"skills": [
{
"...": "skills definition"
}
],
"cognitiveServices": {
"@odata.type": "#Microsoft.Azure.Search.AIServicesByIdentity",
"description": "Billing through user-assigned managed identity.",
"subdomainUrl": "https://<resource-name>.services.ai.azure.com",
"identity": {
"@odata.type": "#Microsoft.Azure.Search.DataUserAssignedIdentity",
"userAssignedIdentity": "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity-name>"
}
}
}Microsoft Learn の例でも、システム割り当て ID では identity を null にし、ユーザー割り当て ID では #Microsoft.Azure.Search.DataUserAssignedIdentity と userAssignedIdentity を指定する形が示されています。(Microsoft Learn)
キー方式はすぐ廃止されるのか
今回の更新だけを根拠に、既存のキー方式がただちに使えなくなると判断するのは早計です。Microsoft Learn では、キー方式による課金リソースの関連付けも説明されており、Azure portal、REST API、SDK を使ってキーを skillset に追加できるとされています。(Microsoft Learn)
ただし、新規構築やセキュリティ基準の見直しでは、マネージド ID 方式を優先して検討する価値があります。理由は、キーを持たない構成にすることで、シークレット管理の負担を減らせるためです。
判断基準は次のとおりです。
| 状況 | 推奨判断 |
|---|---|
| 新規に Azure AI Search と Foundry を構成する | まずマネージド ID 方式を検討 |
| 既存のキー方式で安定稼働している | すぐ一括変更せず、検証環境から段階移行 |
| キーの棚卸しやローテーションが負担になっている | 移行優先度を上げる |
| ネットワーク制御が厳しい | Shared private link、Private endpoint、Network Security Perimeter の要件を先に確認 |
| SDK や IaC が古い | skillset 更新に対応した API バージョンを確認してから移行 |
ネットワーク設定で注意すべきこと
マネージド ID 化しても、ネットワーク制御の確認は不要になりません。認証とネットワーク到達性は別の問題です。
特に、Foundry リソースの public network access を無効にしている場合や、Private endpoint を使っている場合は注意が必要です。Microsoft Learn では、Search サービスの作成時期、価格レベル、リージョンによって、Built-in skills の課金に public connection が必要になる場合があると説明されています。また、要件を満たす場合は shared private link や network security perimeter により、Foundry リソースへの通信をプライベート チャネルに保つ選択肢も示されています。(Microsoft Learn)
移行時にありがちな失敗は、先にキーを外し、同時に public access も閉じてしまうことです。認証エラーなのか、ネットワーク到達性の問題なのか切り分けにくくなります。変更は次の順序で分けるのが安全です。
- まず認証方式だけをマネージド ID に変更する
- インデクサーの実行履歴で成功を確認する
- その後、必要に応じてネットワーク制御を強化する
- 最後にキー参照や古いシークレットを削除する
開発者が確認すべき実装・CI/CD上のポイント
開発者や DevOps 担当者は、ポータル上の設定だけでなく、リポジトリやデプロイ パイプラインも確認してください。
特に見るべきなのは、次のような場所です。
- skillset 定義 JSON
- Bicep、ARM テンプレート、Terraform などの IaC
- GitHub Actions、Azure DevOps Pipelines の変数
- Key Vault に保存された Foundry リソース キー
- アプリケーション設定や
appsettings.json - 検証用スクリプトやサンプルコード
キー方式からマネージド ID 方式へ変更しても、古いキーが CI/CD 変数や Key Vault に残っていれば、棚卸し上のリスクは残ります。移行完了後は、使っていないキー参照を削除し、必要に応じて Foundry リソースのキーをローテーションしてください。
また、CI/CD でロール割り当てまで自動化する場合、デプロイを実行するサービス プリンシパルにはロール割り当てを作成する権限が必要です。Microsoft Learn では、マネージド ID 作成には Owner または User Access Administrator、ロール割り当てには Owner、User Access Administrator、Role-based Access Control Administrator、または必要な権限を持つカスタム ロールが必要とされています。(Microsoft Learn)
課金とコスト管理で誤解しやすい点
マネージド ID は、セキュリティと運用性を改善するための認証方式です。コストを直接下げる機能ではありません。
Azure AI Search の AI エンリッチメントでは、無料で試せる小規模な枠がありますが、一定量を超えると Foundry Tools の利用が課金対象になります。Microsoft Learn では、無料エンリッチメントは 1 indexer あたり 1 日 20 ドキュメントまでと説明されています。また、cognitiveServices を指定しない場合、無料枠を使い切ると実行履歴に “Time Out” が表示される場合があります。(Microsoft Learn)
コスト面で確認すべきことは、次の3つです。
| 確認項目 | 理由 |
|---|---|
| どの skillset が課金対象スキルを使っているか | OCR、画像分析、翻訳などは利用量が増えると費用に直結する |
| どの Foundry リソースに課金が集約されるか | 部門別、環境別の費用配賦に影響する |
| インクリメンタル エンリッチメントを使えるか | 再処理を減らし、不要なエンリッチメント実行を抑えられる可能性がある |
Microsoft Learn では、skillset 処理のコストを下げる方法として、変更のないエンリッチメント結果をキャッシュして再利用する incremental enrichment の利用が案内されています。(Microsoft Learn)
例外的にキー確認が残るケース
すべてをマネージド ID に寄せれば、キーに関する確認が完全になくなるわけではありません。
注意したいのが、Custom Entity Lookup です。Microsoft Learn では、Custom Entity Lookup は Azure AI Search 側でメーターされる一方、1日20トランザクションを超える処理を解放するために Foundry リソース キーが必要であり、このスキルについてはキーが課金そのものではなくトランザクション数の解放に関係すると説明されています。(Microsoft Learn)
そのため、移行時は「キーが残っているから移行漏れ」と単純に判断せず、どのスキルが何のためにキーを使っているのかを確認してください。
よくある質問
Azure AI Searchの検索APIキーも不要になりますか
今回の対象は、Azure AI Search が Microsoft Foundry リソースに対して行う課金関連の呼び出しです。Azure AI Search の管理キー、クエリキー、アプリケーションから検索インデックスへアクセスする認証方式を一括で置き換える更新ではありません。
検索アプリケーション側の認証を見直したい場合は、Azure AI Search の RBAC やアプリケーション認証の設計を別途確認する必要があります。
既存のskillsetは自動でマネージドID方式になりますか
既存の skillset 定義が自動的に書き換わると考えないほうが安全です。既存環境では、cognitiveServices セクションを確認し、キー方式の設定が残っているかを棚卸ししてください。
システム割り当てIDとユーザー割り当てIDはどちらが安全ですか
どちらが絶対に安全というより、運用に合っているかが重要です。小規模で Search サービスごとに権限を閉じたいなら、システム割り当て ID が分かりやすいです。複数のデプロイや IaC 管理を重視するなら、ユーザー割り当て ID が扱いやすい場合があります。
ただし、ユーザー割り当て ID を複数環境で安易に共有すると、権限が広がりすぎるリスクがあります。
Foundryリソースは不要になりますか
不要にはなりません。今回の更新は、Foundry リソースを課金先として関連付ける認証方式の改善です。課金対象の AI エンリッチメントを使う場合、Foundry リソースの関連付けやコスト管理は引き続き必要です。
移行後にまず見るべきログはどこですか
まずは Azure AI Search の indexer execution history を確認します。認証失敗、権限不足、ネットワーク到達性の問題、無料枠超過による停止などを切り分けます。あわせて、Azure Cost Management で Foundry リソース側に想定どおり課金が集約されているかを確認してください。
管理者・開発者向けチェックリスト
最後に、今回の更新を受けて実施すべき作業を整理します。
| 優先度 | チェック項目 | 対象者 |
|---|---|---|
| 高 | Azure AI Search の skillset にキー方式の cognitiveServices 設定があるか確認する | 管理者、開発者 |
| 高 | Search サービスでマネージド ID を有効化できるか確認する | 管理者 |
| 高 | Foundry リソースに Cognitive Services User ロールを割り当てる設計にする | 管理者 |
| 高 | 検証環境で AIServicesByIdentity に変更して indexer を実行する | 開発者 |
| 中 | CI/CD、IaC、Key Vault に古いキー参照が残っていないか確認する | DevOps |
| 中 | Private endpoint や public network access の制御を移行後に確認する | 管理者 |
| 中 | Foundry リソース単位でコスト配賦を確認する | 管理者、FinOps |
| 低 | 新規環境の標準テンプレートをマネージド ID 前提に更新する | 開発者、アーキテクト |
今回の一般提供は、Azure AI Search と Microsoft Foundry を組み合わせる環境で、キー管理から Entra ID ベースの権限管理へ移行するための実用的な更新です。まずは既存 skillset の棚卸しを行い、Foundry リソースのキーを使っている箇所を特定してください。そのうえで、検証環境からマネージド ID 方式へ切り替え、インデクサーの実行履歴、RBAC、ネットワーク、コストを順番に確認するのが安全な進め方です。
コメント