Azure AIの公式ドキュメント更新「remove policy sample for now」は、Azure AIそのものの機能廃止ではなく、Microsoft FoundryとAgent 365のデータ収集設定に関するAzure Policyのサンプル手順が一時的に削除された更新として確認するのが適切です。特に、Azure Policyで a365LoggingEnabled を一括制御している、またはこれから実装しようとしていた開発者・クラウド管理者・アーキテクトは、既存ポリシーの根拠、権限、適用範囲、将来の移行余地を見直す必要があります。
2026年4月30日のGitHubコミットでは、articles/foundry/agents/how-to/configure-agent-365-data-collection.md から「Enforce data collection settings with Azure Policy」セクションが削除され、112行の削除が行われています。削除対象には、modify 効果を使ったカスタムポリシー定義、Azure CLI・Azure PowerShellによる割り当て例、既存リソースの修復に関する説明が含まれていました。(GitHub)
Azure AIの公式ドキュメント更新「remove policy sample for now」で何が変わったか
今回の更新で変わったのは、Azure AI関連ドキュメントに掲載されていたAzure Policyによる一括設定サンプルです。対象ファイルは、Microsoft FoundryのAgent 365データ収集設定に関する手順ページです。
現在のMicrosoft Learnページでは、FoundryリソースのAgent 365データ収集は a365LoggingEnabled と a365Status の2つのプロパティで扱われると説明されています。a365LoggingEnabled はユーザーが制御できる真偽値、a365Status はライセンスや同意確認後の状態を示す読み取り専用の文字列です。(Microsoft Learn)
一方、削除されたコミットでは、以前掲載されていたAzure Policyサンプルが丸ごと取り除かれています。変更内容を整理すると、次のようになります。
| 確認項目 | 変更前に掲載されていた内容 | 更新後に確認すべきこと |
|---|---|---|
| Azure Policyサンプル | modify 効果で a365LoggingEnabled を設定するカスタムポリシー例 | 公式サンプルをそのまま新規採用しない |
| 対象リソース | Microsoft.CognitiveServices/accounts | Foundryリソース単位で設定する前提は引き続き確認 |
| 適用範囲 | サブスクリプションまたは管理グループ単位の一括適用 | 本番適用前にスコープと除外条件を再設計 |
| デプロイ例 | Azure CLI、Azure PowerShell | 既存スクリプトが削除済みサンプル由来か棚卸し |
| 修復の説明 | 既存リソースの評価・修復、新規リソースへの設定適用 | Azure Policyの修復タスクやマネージドID権限を個別に検証 |
重要なのは、削除されたのはサンプルであり、a365LoggingEnabled という設定自体が消えたわけではないという点です。現行ドキュメントには、Azure CLI、Azure PowerShell、REST API、Bicep、Terraform AzAPIで a365LoggingEnabled を true または false に設定する例が残っています。(Microsoft Learn)
変更の背景をどう読むべきか
コミットメッセージは「remove policy sample for now」です。日本語にすると「今のところポリシーサンプルを削除する」という意味合いです。ここから読み取れるのは、恒久的な機能廃止というよりも、サンプル内容の正確性、実装タイミング、権限、API仕様、ガバナンス上の表現などを再確認するために、公式ドキュメントから一時的に取り下げられた可能性です。
ただし、Microsoftが削除理由を詳細に説明していない以上、「Azure Policyが使えなくなった」「Agent 365連携が廃止された」と断定するのは避けるべきです。実務では、次のように扱うと安全です。
| 判断してよいこと | 断定しない方がよいこと |
|---|---|
| 公式ドキュメントからAzure Policyサンプルが削除された | Azure Policyによる制御が全面的に非推奨になった |
| 削除前のサンプルを新規実装の根拠にするのは危険 | a365LoggingEnabled が廃止された |
| 既存のカスタムポリシーは再検証すべき | 既存環境が即座に壊れる |
| Microsoft Learnの記述とGitHub差分を併せて確認すべき | すべてのAgent 365データ収集が停止する |
特に注意したいのは、現行ページの本文にはAzure Policyへの言及が残っている一方で、具体的なポリシー定義サンプルは削除されている点です。記事執筆時点では、ドキュメントが移行途中または調整中の状態に見えるため、実装判断はGitHubの差分とMicrosoft Learnの最新ページを併せて確認する必要があります。(Microsoft Learn)
Azure AI運用でまず確認すべきポイント
今回の更新を見たら、最初に確認すべきなのは「自社環境で削除済みサンプルに依存していないか」です。Azure AI、Microsoft Foundry、Agent 365を使っている組織では、データ収集設定がセキュリティ、監査、データレジデンシー、社内規程に関係する可能性があります。
既存のAzure Policy定義を棚卸しする
クラウド管理者は、Azure Policy定義やイニシアティブの中に a365LoggingEnabled、Microsoft.CognitiveServices/accounts、Agent 365、Foundry関連のルールが含まれていないか確認します。
確認対象は、Azureポータル上のポリシー定義だけではありません。GitHub、Azure DevOps、Terraform、Bicep、社内テンプレート、手順書、運用Runbookも対象です。
例として、リポジトリ内では次のキーワードで検索します。
a365LoggingEnabled
a365Status
Microsoft.CognitiveServices/accounts
agent365
Agent 365
configure-agent365-foundry削除前のサンプルに近い定義が見つかった場合は、すぐに削除するのではなく、次の観点で評価します。
| 確認観点 | 見るべき内容 |
|---|---|
| 目的 | データ収集を有効化するためか、無効化するためか |
| スコープ | 管理グループ、サブスクリプション、リソースグループのどこに割り当てているか |
| 影響範囲 | すべてのFoundryリソースに適用されるか、一部だけか |
| 例外管理 | 検証環境、規制対象ワークロード、海外リージョンを除外しているか |
| 権限 | マネージドIDやロール割り当てが過剰でないか |
| 根拠 | 公式ドキュメントの削除前サンプルをそのまま使っていないか |
a365LoggingEnabled の現在値を確認する
Microsoft Learnでは、Foundryリソース単位で a365LoggingEnabled を設定すると説明されています。プロジェクト単位やエージェント単位ではなく、Foundryリソース内のプロジェクトとプロンプトエージェントに同じ設定が適用される点が重要です。(Microsoft Learn)
運用担当者は、まず対象リソースの現在値を確認します。Azure CLIを使う場合の例は次の通りです。
az resource show \
--resource-group <resource-group> \
--name <foundry-resource-name> \
--resource-type Microsoft.CognitiveServices/accounts \
--api-version 2026-03-15-preview \
--query "properties.{a365LoggingEnabled:a365LoggingEnabled,a365Status:a365Status}"ここで確認すべきなのは、単に true か false かではありません。a365Status、Agent 365ライセンス、テナントレベルの同意、対象リソースの用途を組み合わせて判断します。
Agent 365のライセンスと同意状態を確認する
a365LoggingEnabled を true にするだけでデータ収集が始まるわけではありません。公式ドキュメントでは、データ収集には有効なAgent 365ライセンス、テナントレベルのA365同意、そして a365LoggingEnabled=true が必要だと説明されています。(Microsoft Learn)
つまり、運用上は次の3点を分けて確認する必要があります。
| 確認項目 | 意味 | 見落とした場合のリスク |
|---|---|---|
| Agent 365ライセンス | データ収集や管理機能を利用できる前提 | 設定を有効にしても期待通りに動かない |
| テナントレベルの同意 | 組織としてAgent 365を有効化しているか | 管理者の合意なしに運用設計が進む |
a365LoggingEnabled | Foundryリソース単位の送信設定 | リソースごとのオプトアウト漏れが起きる |
特に、技術チームだけで判断すると「設定値はtrueだから有効」と誤解しやすい部分です。実際には、ライセンス・同意・リソース設定の3つがそろって初めて、データフローを評価できます。
役割別に見る影響範囲
今回の「remove policy sample for now」は、読む人の役割によって影響が異なります。開発者だけでなく、クラウド管理者、ソリューションアーキテクト、技術意思決定者がそれぞれ別の観点で確認すべき更新です。
| 役割 | 主な関心事 | 今すぐ確認すべきこと |
|---|---|---|
| developers | アプリやエージェントの挙動、SDK設定 | Hosted Agentsで明示的なAgent 365 SDK設定をしていないか |
| cloud admins | Azure Policy、RBAC、リソース設定 | 既存ポリシーが削除済みサンプル由来でないか |
| solution architects | ガバナンス設計、データフロー、リージョン設計 | FoundryとAgent 365間のデータ移動を設計書に反映しているか |
| technical decision makers | リスク、コンプライアンス、導入判断 | 公式サンプル削除を移行計画・監査資料に反映するか |
開発者にとって特に重要なのは、Hosted Agentsの扱いです。公式ドキュメントでは、Hosted AgentsはAgent 365 SDKの手動構成が必要であり、明示的なSDK構成がFoundryリソースレベルのログ無効化設定を上書きする可能性があると説明されています。(Microsoft Learn)
このため、「Azure Policyでリソース側を無効化したから、すべてのエージェント活動データが止まる」と単純に考えるのは危険です。Hosted Agentsを利用している場合は、アプリケーションコードやデプロイパッケージ側のAgent 365 SDK設定も確認してください。
削除済みサンプルを使っていた場合の対応方針
すでに削除前のAzure Policyサンプルを参考にしていた場合、対応は「即削除」ではなく「凍結・検証・再設計」の順で進めるのが現実的です。
新規展開は一度止める
まず、削除済みサンプルをそのまま使った新規展開は止めます。理由は、公式がサンプルを取り下げた以上、今後の修正、名称変更、推奨手順の変更が起きる可能性があるためです。
特に本番環境への管理グループ単位の割り当ては避けるべきです。管理グループ配下に多数のサブスクリプションがある場合、意図しないFoundryリソースまで一括変更される可能性があります。
既存ポリシーは検証環境で再評価する
既存のカスタムポリシーを利用している場合は、まず検証環境で次の項目を確認します。
| 検証項目 | 確認内容 |
|---|---|
| ポリシー条件 | Microsoft.CognitiveServices/accounts の全リソースに広く当たりすぎていないか |
| 変更対象フィールド | properties.a365LoggingEnabled が想定通り評価・変更されるか |
| 効果 | modify が期待通り動くか |
| 修復 | 既存リソースに修復タスクが必要か |
| 権限 | マネージドIDに過剰なロールを付与していないか |
| 監査ログ | 誰が、いつ、どのリソースの設定を変更したか追跡できるか |
Azure Policyの modify 効果は、作成・更新時にリソースやタグのプロパティを追加・更新・削除するために使われ、既存の非準拠リソースは修復タスクで修復できるとされています。また、modify を使うポリシー割り当てでは、修復のためにマネージドIDが必要です。(Microsoft Learn)
そのため、ポリシーの動作確認では「定義が作れるか」だけでなく、「修復が正しく動くか」「不要な権限を持っていないか」まで確認する必要があります。
社内ドキュメントの表現を修正する
技術文書、設計書、監査向け資料に「Microsoft公式サンプルに準拠」と書いている場合は、表現を見直します。公式サンプルが削除された後も同じ表現を残すと、レビュー時に根拠が弱くなります。
修正例は次の通りです。
| 修正前 | 修正後 |
|---|---|
| Microsoft公式サンプルに基づきAzure Policyで強制 | 2026年4月30日の公式ドキュメント更新によりサンプル削除を確認。現行の実装は社内検証済みカスタムポリシーとして管理 |
| Agent 365データ収集はAzure Policyで一括制御可能 | Foundryリソース単位の設定を基本とし、Azure Policy利用時は個別に検証する |
a365LoggingEnabled=true でデータ収集が有効 | ライセンス、テナント同意、リソース設定がそろった場合にデータ収集を評価する |
このように、公式ドキュメントの削除を反映しておくと、監査やセキュリティレビューで説明しやすくなります。
データ収集設定で失敗しやすいポイント
Agent 365とMicrosoft Foundryの連携は、単純なオン・オフ設定だけで判断するとミスが起きやすい領域です。特に次のポイントは、実務で混乱しやすいです。
プロジェクト単位で設定できると誤解する
a365LoggingEnabled はFoundryリソースレベルの設定です。公式ドキュメントでは、リソース内のFoundryプロジェクトとプロンプトエージェントは同じデータ収集設定を継承し、プロジェクト単位またはエージェント単位の上書きはないと説明されています。(Microsoft Learn)
複数の用途を1つのFoundryリソースにまとめている場合、あるプロジェクトだけデータ収集を止める、といった設計はできません。規制対象ワークロード、社外秘データを扱うエージェント、検証用エージェントを分けたい場合は、Foundryリソースの分割を検討します。
既定値を見落とす
公式ドキュメントでは、Agent 365がEntraテナントで有効になると、同じAzureテナント内のFoundryリソースは既定で a365LoggingEnabled=true になると説明されています。データ収集を止めたい場合は、各リソースで明示的にオプトアウトする必要があります。(Microsoft Learn)
この仕様を見落とすと、新規リソース作成時に期待と異なる状態になる可能性があります。特に、開発チームが自由にFoundryリソースを作成できる環境では、作成後の確認プロセスを用意しておくべきです。
Hosted AgentsのSDK設定を見落とす
Hosted Agentsでは、Agent 365 SDKを手動で構成する必要があります。さらに、Hosted Agents側の明示的なSDK構成が、Foundryリソースレベルのログ無効化設定を上書きする可能性がある点にも注意が必要です。(Microsoft Learn)
このため、クラウド管理者がAzure側の設定だけを見ていても、アプリケーション側で別の設定が入っていると想定とずれることがあります。開発チームとインフラチームで、SDK構成、環境変数、デプロイ手順を一緒に確認してください。
Azure Policyを使い続けるべきかの判断基準
公式サンプルが削除されたからといって、すべてのAzure Policy利用をやめる必要はありません。ただし、今後は「公式サンプルがあるから使う」ではなく、「自社の要件に合わせて検証済みのポリシーとして使う」という扱いに変えるべきです。
| 状況 | 推奨判断 |
|---|---|
| まだ実装していない | 公式サンプルの再掲載や更新を待ち、まずはリソース単位の設定で運用する |
| 検証環境でのみ利用中 | 継続検証は可。ただし本番展開前に公式ドキュメント差分を再確認する |
| 本番環境で利用中 | 直ちに棚卸しし、影響範囲・権限・監査ログを確認する |
| 管理グループ全体に適用中 | 除外条件、対象リソース、修復タスクの影響を優先的に確認する |
| コンプライアンス目的で必須 | Azure Policy以外の確認手段も用意し、二重チェック体制にする |
現実的には、データ収集を禁止したい組織ではAzure Policyのようなガバナンス機能が必要になる場面があります。ただし、削除済みサンプルをそのままコピーしたポリシーは、今後の仕様変更に追随できない可能性があります。
運用チーム向けの確認手順
Azure AIとMicrosoft Foundryを運用しているチームは、次の順序で確認すると効率的です。
| 手順 | 作業内容 | 完了基準 |
|---|---|---|
| 1 | Microsoft Learnの現行ページを確認 | a365LoggingEnabled と a365Status の説明を把握 |
| 2 | GitHubコミット差分を確認 | 削除されたAzure Policyサンプルの範囲を把握 |
| 3 | 社内IaCを検索 | 削除済みサンプル由来の定義を特定 |
| 4 | Foundryリソースを棚卸し | どのリソースがAgent 365対象か整理 |
| 5 | 設定値を取得 | a365LoggingEnabled と a365Status を確認 |
| 6 | Hosted Agentsを確認 | SDK側設定がリソース設定と矛盾しないか確認 |
| 7 | ポリシー運用を見直し | 継続、停止、再設計の方針を決める |
| 8 | 監査資料を更新 | 公式サンプル削除を反映した説明に修正 |
この手順で進めると、「ドキュメントが変わった」という情報を、実際の運用リスク確認に落とし込めます。
開発・検証環境での安全な確認例
新しい挙動を確認するときは、本番サブスクリプションではなく、検証用のFoundryリソースで実施します。特にAPIバージョンがプレビュー扱いの場合は、将来的な変更も想定しておく必要があります。
データ収集を無効化する例は、公式ドキュメントでは次のように示されています。(Microsoft Learn)
az resource update \
--resource-group <resource-group> \
--name <foundry-resource-name> \
--resource-type Microsoft.CognitiveServices/accounts \
--api-version 2026-03-15-preview \
--set properties.a365LoggingEnabled=false再度有効化する場合は、a365LoggingEnabled を true に設定します。
az resource update \
--resource-group <resource-group> \
--name <foundry-resource-name> \
--resource-type Microsoft.CognitiveServices/accounts \
--api-version 2026-03-15-preview \
--set properties.a365LoggingEnabled=trueここで大切なのは、コマンドを実行して終わりにしないことです。実行後は、次の観点で確認します。
| 確認項目 | 理由 |
|---|---|
a365LoggingEnabled の値 | 変更がリソースに反映されたか確認するため |
a365Status の値 | ライセンスや同意後の状態を確認するため |
| Agent 365側の表示 | 期待通りにレジストリや分析に反映されるか確認するため |
| 監査ログ | 誰が設定変更したか追跡できるようにするため |
| 既存エージェントの挙動 | データ収集停止・再開が想定通りか確認するため |
技術意思決定者が見るべきリスク
技術意思決定者にとって、今回の更新は単なるドキュメント差分ではありません。AIエージェントの活動データをどこまで収集し、どの統制基盤に送るかというガバナンス判断に関係します。
Agent 365は、Microsoft Foundryで作成されたエージェントを含むAIエージェントの観察、統制、セキュリティ管理を支援するコントロールプレーンとして説明されています。Microsoft Learnでは、FoundryとAgent 365の連携により、エージェントの登録、アクセス制御、可視化、セキュリティなどを扱うとされています。(Microsoft Learn)
また、FoundryとAgent 365ではデータレジデンシーの考え方が異なり、Foundryのデータは選択したAzureリージョンに従う一方、Agent 365側のデータはMicrosoft Entraテナントの保存場所に従うと説明されています。Agent activity dataがFoundryからAgent 365へ流れる場合、AzureリージョンベースのモデルからEntraテナントベースのモデルへ移る可能性があるため、規制要件があるワークロードでは個別にオプトアウトを検討すべきです。(Microsoft Learn)
つまり、意思決定者が確認すべきなのは次の3点です。
| 観点 | 確認すべき問い |
|---|---|
| ガバナンス | AIエージェントの活動データを組織として収集・可視化する方針は明確か |
| コンプライアンス | データレジデンシーや規制対象データの扱いに矛盾はないか |
| 実装責任 | Azure Policy、Foundry設定、SDK設定の責任分界点は決まっているか |
この整理がないままAzure Policyで一括設定すると、後から「誰がどの根拠でデータ収集を有効化したのか」を説明しづらくなります。
今後のドキュメント更新を追跡する方法
MicrosoftDocs系のリポジトリ更新は、サービスの正式な仕様変更そのものとは限りません。しかし、実務では公式ドキュメントのサンプルや手順を根拠に運用しているケースが多いため、変更差分の追跡は重要です。
おすすめの追跡方法は次の通りです。
| 方法 | 用途 |
|---|---|
| GitHubのコミット差分を確認 | 何が削除・追加されたかを正確に見る |
| Microsoft Learnの最終更新日を見る | 公開ドキュメントの反映状況を確認する |
| 社内IaCとの差分を取る | 公式から削除されたサンプルが残っていないか確認する |
| 変更管理チケットを作る | 設定変更の判断を記録する |
| 検証環境で再テストする | 仕様ではなく実際の挙動を確認する |
特に、Azure AIやMicrosoft Foundryのように更新が速い領域では、「一度作った手順を固定化する」のではなく、公式ドキュメントとリポジトリ差分を定期的に見直す運用が必要です。
よくある質問
今回の更新でAzure AIの機能が止まるのですか？
いいえ。今回確認されているのは、Azure AI関連ドキュメントからAzure Policyサンプルが削除されたという変更です。Microsoft Learnの現行ページには、Foundryリソースで a365LoggingEnabled を有効化・無効化する手順が残っています。(Microsoft Learn)
Azure Policyはもう使わない方がよいですか？
一概には言えません。ただし、削除された公式サンプルをそのまま新規採用するのは避けるべきです。既存のカスタムポリシーを使っている場合は、対象リソース、効果、修復、権限、監査ログを再確認したうえで継続可否を判断してください。
a365LoggingEnabled=false にすれば完全にデータ収集は止まりますか？
FoundryリソースからAgent 365へのエージェント活動データ送信を止める設定として、公式ドキュメントでは a365LoggingEnabled=false が説明されています。ただし、Hosted AgentsではSDK構成が関係するため、リソース設定だけで判断しない方が安全です。(Microsoft Learn)
まず何をすればよいですか？
最初に、社内のAzure Policy、IaC、Runbook、設計書から a365LoggingEnabled と Microsoft.CognitiveServices/accounts を検索してください。次に、対象Foundryリソースの現在値を確認し、削除済みサンプルを根拠にした設定がないかを棚卸しします。
まとめ：公式サンプル削除を「仕様変更の兆候」として扱い、運用を点検する
Azure AIの公式ドキュメント更新「remove policy sample for now」で確認すべき最重要ポイントは、Azure Policyサンプルが削除されたことと、Foundryリソース単位の a365LoggingEnabled 設定は引き続き現行ドキュメントに残っていることを分けて理解することです。
実務では、次の順で対応してください。
- GitHubコミットで削除された範囲を確認する
- Microsoft Learnの現行ページで残っている仕様を確認する
- 社内のAzure Policy、IaC、手順書を棚卸しする
- Foundryリソースごとの
a365LoggingEnabledとa365Statusを確認する - Hosted AgentsのSDK設定も含めてデータ収集経路を確認する
- 本番環境への一括適用は、検証と承認を経てから行う
今回の更新は、今すぐ大規模な移行を求めるものとは限りません。しかし、Azure AIとAgent 365の連携は、AIエージェントの可視化、セキュリティ、データガバナンスに直結します。削除済みの公式サンプルに依存していないかを確認し、必要に応じて社内ポリシーと運用手順を更新することが、次に取るべき具体的なアクションです。
コメント