Azure AI公式更新「Update using right api versions」確認ポイント|APIバージョンとAgent 365設定の変更

Azure AIの公式ドキュメント更新「Update using right api versions」は、単なる文言修正ではなく、Azure AI Foundry/Microsoft FoundryのAgent 365データ収集設定を扱う運用手順に影響する更新です。結論から言うと、既存のCLI、PowerShell、REST API、Bicep、Terraform、Azure Policyで Microsoft.CognitiveServices/accounts を操作している場合は、APIバージョンとプロパティ名を必ず確認してください。特に api-version=2024-10-01 や properties.agent365Config.loggingEnabled を使っている構成は、2026-03-15-preview と properties.a365LoggingEnabled への見直しが必要になる可能性があります。今回のコミットは2026年4月30日にMicrosoftDocsのAzure AI Docsリポジトリへ反映され、対象ファイルはAgent 365データ収集の構成ドキュメントです。(GitHub)

目次

Azure AIの公式ドキュメント更新「Update using right api versions」で何が変わったか

今回の更新で最も重要なのは、Agent 365データ収集を有効化・無効化する手順において、正しいAPIバージョンと正しいプロパティ名を使うよう修正された点です。Microsoft Learn上の該当ドキュメントでは、FoundryリソースがAgent 365の制御プレーンへエージェント活動データを送信できること、その設定を個別リソース単位で制御できることが説明されています。(Microsoft Learn)

今回の差分で見るべき変更点は、次の4つです。

確認項目変更前の例更新後の例実務上の影響
APIバージョン2024-10-012026-03-15-previewREST API、Bicep、Terraform、CLI、PowerShellの指定を確認する
データ収集設定プロパティagent365Config.loggingEnableda365LoggingEnabledネストされたプロパティではなく、リソースプロパティ直下のBooleanとして扱う
ステータス確認プロパティagent365Config.a365Statusa365Status監視や設定確認スクリプトの参照先を見直す
Azure PolicyのパラメーターloggingEnabled などa365LoggingEnabledポリシー定義・割り当てパラメーターの型と名称を修正する

特に注意したいのは、a365LoggingEnabled がBooleanである点です。以前の説明では文字列やネスト構造に見える記述が含まれていましたが、更新後の公式ドキュメントでは true または false を使うユーザー制御プロパティとして整理されています。(GitHub)

既存環境で最初に確認すべきポイント

まず確認すべきなのは、Azure AI Foundry関連の自動化コードやIaCテンプレートに、古いAPIバージョンや古いプロパティ名が残っていないかです。対象になりやすいのは、運用スクリプト、CI/CDパイプライン、Bicepテンプレート、TerraformのAzAPIリソース、Azure Policy定義です。

リポジトリ内では、次の文字列を検索すると影響範囲を洗い出しやすくなります。

api-version=2024-10-01
Microsoft.CognitiveServices/accounts@2024-10-01
agent365Config
loggingEnabled
agents365IngestionEndpoint

見つかった場合は、単純に文字列を置換するのではなく、APIバージョン、プロパティ階層、値の型をセットで確認してください。たとえば loggingEnabled を a365LoggingEnabled に変えるだけでは不十分です。agent365Config の入れ子構造を残したままにすると、更新後のドキュメントに沿った構成になりません。

CLI、PowerShell、REST APIでの確認ポイント

Azure CLIの更新例では、az resource update に --api-version 2026-03-15-preview を指定し、--set properties.a365LoggingEnabled=false または true を設定する形に変わっています。Microsoft Learnの現在の例でも、データ収集を無効化する場合は a365LoggingEnabled=false、再度有効化する場合は a365LoggingEnabled=true を指定しています。(Microsoft Learn)

設定状況を確認する場合は、次のような形で対象リソースのプロパティを確認できます。

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}" \
  -o json

更新作業では、いきなり本番サブスクリプションで変更するのではなく、開発環境または検証用リソースでレスポンスを確認してから進めるべきです。2026-03-15-preview は名前の通りpreview APIバージョンであるため、組織の変更管理ルールでpreview APIの利用可否を確認しておくと安全です。

BicepとTerraformで注意すべき点

Bicepでは、リソース宣言のAPIバージョンが Microsoft.CognitiveServices/accounts@2026-03-15-preview に変わり、properties 配下に a365LoggingEnabled を直接指定する形になっています。TerraformのAzAPI例でも、type が Microsoft.CognitiveServices/accounts@2026-03-15-preview へ変更され、body内のプロパティも a365LoggingEnabled に整理されています。(GitHub)

失敗しやすいのは、次のような中途半端な修正です。

よくあるミスなぜ問題になるか修正方針
APIバージョンだけを新しくする古い agent365Config 構造が残るプロパティ階層も a365LoggingEnabled に変更する
プロパティ名だけを変える古いAPIバージョンでは期待通り扱われない可能性があるAPIバージョンも公式例に合わせて確認する
true / false を文字列で渡すBooleanとして扱うべき値が文字列になる"true" ではなく true を使う
既存のPolicyだけ更新しない新規リソース作成時に古い設定が再適用されるAzure Policy定義と割り当ても同時に見直す

IaCでは、テンプレートの構文が通っても、実際のリソースプロバイダー側で期待通り反映されるとは限りません。変更後はデプロイ結果だけでなく、ARM上の実プロパティを取得して確認することが重要です。

Azure Policyを使っている組織はパラメーター型も見直す

Agent 365データ収集をサブスクリプション単位や管理グループ単位で統制している場合、Azure Policyの定義も確認対象です。今回のコミットでは、ポリシーの説明から「ingestion endpoint」を設定する記述が外れ、ログ設定を制御する a365LoggingEnabled に焦点が移っています。また、パラメーターも loggingEnabled ではなく a365LoggingEnabled、型もBooleanとして扱う形に修正されています。(GitHub)

たとえば、ポリシー割り当てでデータ収集を無効化する場合は、次のような考え方になります。

{
  "a365LoggingEnabled": {
    "value": false
  }
}

ここで重要なのは、Policyだけを更新しても、既存リソースへの反映には評価サイクルや修復タスクが関係する点です。公式ドキュメントの差分でも、ポリシー割り当て後に既存リソースが次回のコンプライアンス評価サイクルで評価・修復され、新規リソースには作成時に設定が適用される旨が説明されています。(GitHub)

データ収集の有効化条件を誤解しない

a365LoggingEnabled=true に設定しただけで、必ずAgent 365へデータが送信されるわけではありません。公式ドキュメントでは、データ収集には有効なAgent 365ライセンス、テナントレベルのA365同意、そして a365LoggingEnabled=true の3つが必要であり、設定値をtrueにするだけではデータ収集は開始されないと説明されています。(Microsoft Learn)

これは、セキュリティレビューや監査対応で重要です。設定値だけを見て「データ送信中」と判断するのではなく、a365Status などの状態確認、ライセンス、同意状況を合わせて確認する必要があります。

反対に、データ収集を止めたい場合は、対象のFoundryリソースで a365LoggingEnabled=false を設定します。Microsoft Learnでは、この設定を無効化すると、そのFoundryリソース内のすべてのプロジェクトとエージェントに反映され、以後そのリソースからAgent 365へエージェント活動データが送信されないと説明されています。(Microsoft Learn)

設定範囲はプロジェクト単位ではなくFoundryリソース単位

今回の更新で運用担当者が特に注意すべきなのは、a365LoggingEnabled のスコープです。この設定はFoundryリソース単位で適用され、同じリソース内のFoundryプロジェクトやプロンプトエージェントは同じデータ収集設定を継承します。プロジェクト単位、エージェント単位で個別に上書きする仕組みではありません。(Microsoft Learn)

そのため、1つのFoundryリソース内に本番用途、検証用途、機密度の異なるプロジェクトが混在している場合は、設定変更の影響範囲が広くなります。運用上は、データ収集ポリシーが異なるワークロードを同じFoundryリソースにまとめない設計も検討すべきです。

また、Hosted Agentsを使う場合は追加確認が必要です。公式ドキュメントでは、Hosted AgentsではAgent 365 SDKを手動構成する必要があり、明示的なSDK構成がFoundryリソースレベルのログ無効化設定を上書きする可能性があると説明されています。(Microsoft Learn)

役割別に見る今回の更新の影響

読者確認すべきこと具体的な行動
開発者SDK、REST API、CLIスクリプトのプロパティ名agent365Config 参照を検索し、a365LoggingEnabled に修正する
クラウド管理者サブスクリプション全体の設定統制Azure Policy定義、割り当て、修復タスクを見直す
ソリューションアーキテクトリソース分離とデータ収集方針プロジェクト単位で制御できない前提でFoundryリソース設計を見直す
技術意思決定者Agent 365利用時のガバナンスライセンス、同意、監査、データ収集ポリシーをセットで確認する

今回の更新は、機能追加というよりも「正しいAPIバージョンと正しいプロパティで運用するための修正」と捉えるのが実務的です。とはいえ、ドキュメントのサンプルをもとに自動化している組織では、既存のテンプレートやポリシーに直接影響する可能性があります。

移行準備の進め方

移行準備は、次の順番で進めると安全です。

手順作業内容確認ポイント
現状把握対象リソースと関連スクリプトを棚卸しするMicrosoft.CognitiveServices/accounts を操作している箇所を洗い出す
影響調査古いAPIバージョンと古いプロパティ名を検索する2024-10-01、agent365Config、loggingEnabled を確認する
検証修正検証環境でAPIバージョンとプロパティを更新するa365LoggingEnabled と a365Status の取得結果を確認する
Policy更新Azure Policy定義と割り当てを更新するBoolean型の a365LoggingEnabled を使う
本番反映変更管理に沿って段階的に展開する反映後にARM上の実プロパティを再取得する

本番環境では、単に「コマンドが成功したか」ではなく、「期待したプロパティが期待した値で保存されているか」まで確認してください。特にグローバル展開している組織では、複数リージョン、複数サブスクリプション、複数テナントで同じ結果になるとは限らないため、対象範囲を分けて検証するのが現実的です。

今回の更新で取るべき次のアクション

Azure AIの公式ドキュメント更新「Update using right api versions」を受けて、まずやるべきことは、既存の自動化コードとAzure Policyの検索です。2024-10-01、agent365Config、loggingEnabled が残っている場合は、2026-03-15-preview と a365LoggingEnabled を前提に修正案を作成してください。

次に、Agent 365のデータ収集方針を組織として確認します。a365LoggingEnabled=true はデータ収集の条件の一部であり、ライセンスやテナント同意も関係します。一方で、設定スコープはFoundryリソース単位のため、プロジェクトごとにデータ収集方針を変えたい場合は、リソース分離の設計から見直す必要があります。

今回の変更は小さな差分に見えますが、運用スクリプト、IaC、Azure Policy、監査観点では見落としやすい更新です。Azure AI FoundryやAgent 365を本番運用している場合は、公式ドキュメントのサンプルを最新化するだけでなく、自社環境の設定値、ポリシー、変更管理プロセスまで含めて確認しておきましょう。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次