Azure AIの公式ドキュメント更新「publish a365 docs without toc」でまず確認すべき結論は、Agent 365関連ドキュメントの導線変更だけでなく、FoundryリソースのAgent 365データ収集設定を見直す必要があるという点です。
特に、Azure CLI、PowerShell、REST API、Bicep、Terraform、Azure PolicyでAgent 365データ収集を制御しているチームは、旧来のenabled / disabledやagent365Config.loggingEnabledを前提にしたスクリプトが残っていないか確認してください。公開中のMicrosoft Learnでは、Agent 365データ収集の制御プロパティとしてa365LoggingEnabledを使い、値はtrue / falseで扱う形に整理されています。(Microsoft Learn)
何が変わったか：TOC導線とAgent 365データ収集設定の整理
2026年4月29日のMicrosoftDocs/azure-ai-docsコミット「publish a365 docs without toc」は、Azure AI関連の公式ドキュメントリポジトリにおけるAgent 365関連ページの更新です。コミット差分では、configure-agent-365-data-collection.mdと、Foundry関連のTOCファイル2つを含む計3ファイルが変更されています。(GitHub)
今回の更新は、単なる表記修正ではありません。実務上は次の3点を確認する必要があります。
| 確認項目 | 変更の意味 | 実務での対応 |
|---|---|---|
| TOCからの導線変更 | Agent 365関連ページがナビゲーションに表示されにくくなる可能性がある | 左メニューだけで探さず、公式ページのURLや関連リンクを管理する |
| 設定値のBoolean化 | enabled / disabledではなくtrue / falseで扱う方向に整理 | CLI、PowerShell、REST、Bicep、Terraform、Azure Policyの値を棚卸しする |
| データ収集条件の明確化 | trueにするだけではデータ収集は始まらず、Agent 365ライセンスとテナント同意も必要 | 技術設定、ライセンス、管理者同意をセットで確認する |
コミット差分では、Agent 365データ収集の無効化例がloggingEnabled=disabledからloggingEnabled=falseへ、有効化例がloggingEnabled=enabledからloggingEnabled=trueへ変更されています。また、ポリシーのallowedValuesも文字列の"enabled" / "disabled"からBooleanのtrue / falseへ変わっています。(GitHub)
ただし、実装時にそのまま参照すべきなのは、コミット時点の差分だけではなく公開中のMicrosoft Learn最新版です。2026年5月1日更新のMicrosoft Learnでは、FoundryリソースのAgent 365データ収集はa365LoggingEnabledというBooleanプロパティで説明されています。(Microsoft Learn)
「without toc」は機能削除ではなく、ドキュメント導線の変更として読む
コミット名にある「without toc」は、直訳すると「TOCなしで公開」です。ここでいうTOCは、Microsoft Learnなどの左側ナビゲーションやドキュメント階層に相当する目次構造を指すと考えるのが自然です。
実際の差分では、次のTOC項目がコメントアウトされています。
| TOCファイル | コメントアウトされた項目 |
|---|---|
agent-service/toc.yml | Microsoft Agent 365 integration |
security-governance/toc.yml | Configure Agent 365 data collection |
差分上はTOC項目がコメントアウトされているだけで、本文ファイルそのものを削除しているわけではありません。そのため、「TOCから外れた＝機能が廃止された」と判断するのは早計です。(GitHub)
運用チームが注意すべきなのは、機能の有無よりも「社内手順書やナレッジが、Microsoft Learnの左ナビを前提にしていないか」です。たとえば、オンボーディング資料に「Azure AI FoundryのSecurity governance配下からAgent 365 data collectionを開く」と書いている場合、今後その導線で見つからない可能性があります。
社内ドキュメントでは、次のように書き換えると混乱を防げます。
| 旧い書き方 | 改善例 |
|---|---|
| 左メニューからAgent 365 integrationを開く | Microsoft Learnの「Microsoft Agent 365 integration with Foundry」ページを直接参照する |
| Security governance配下のConfigure Agent 365 data collectionを確認する | Microsoft Learnの「Configure Agent 365 data collection for Microsoft Foundry」ページを直接参照する |
| 目次上の場所を手順として記載する | ページ名、確認日、主要プロパティ名を記載する |
実装で最も注意すべき点はa365LoggingEnabledとBoolean値
今回の更新で、エンジニアが最も間違えやすいのは設定値です。
現在のMicrosoft Learnでは、Agent 365データ収集を制御する主なプロパティは次の2つとして説明されています。(Microsoft Learn)
| プロパティ | 型 | 役割 |
|---|---|---|
a365LoggingEnabled | Boolean | FoundryリソースからAgent 365へエージェント活動データを送信するかを制御する |
a365Status | String | ライセンスと同意の確認後の有効化状態を示す読み取り専用プロパティ |
a365LoggingEnabledは、trueまたはfalseで設定します。"enabled"や"disabled"のような文字列ではありません。
無効化の例
Microsoft Learnの例では、FoundryリソースでAgent 365データ収集を止める場合、次のようにa365LoggingEnabled=falseを設定します。(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を設定します。(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=trueここで重要なのは、trueに設定しても、それだけで必ずデータ収集が始まるわけではないという点です。公式ドキュメントでは、データ収集には有効なAgent 365ライセンス、テナントレベルのA365同意、そしてa365LoggingEnabled=trueが必要とされています。(Microsoft Learn)
旧スクリプト・IaCで確認すべき検索キーワード
既存環境を運用している場合は、まずリポジトリや社内手順書を横断検索してください。特に次のキーワードが残っている場合は、最新版の公式ドキュメントに合わせた見直しが必要です。
| 検索キーワード | 見つかった場合に確認すること |
|---|---|
agent365Config | 現行のa365LoggingEnabled前提に移行すべき箇所がないか |
loggingEnabled | 旧プロパティを使っていないか |
"enabled" | Booleanではなく文字列で設定していないか |
"disabled" | Booleanではなく文字列で設定していないか |
ingestionEndpoint | 現在の構成例で不要になっている箇所を引きずっていないか |
a365LoggingEnabled | 値がtrue / falseとして扱われているか |
2026-03-15-preview | APIバージョンを明示しているか |
特にBicep、ARMテンプレート、Terraform AzAPIでは、falseと"false"の違いに注意してください。前者はBoolean、後者は文字列です。型が違うと、デプロイ時にエラーになる、または意図したプロパティ更新にならない可能性があります。
Cloud Adminが確認すべき運用影響
Cloud Adminが見るべきポイントは、設定変更の可否だけではありません。Agent 365データ収集は、リソース単位、テナント単位、ライセンス、同意、データ所在が絡みます。
既定で有効になる可能性を把握する
公式ドキュメントでは、EntraテナントでAgent 365が有効になっている場合、同じAzureテナント内のFoundryリソースではa365LoggingEnabledが既定でtrueになると説明されています。組織がデータ収集を止めたい場合は、各リソースで明示的にオプトアウトする必要があります。(Microsoft Learn)
つまり、管理者が取るべき行動は「有効化したいリソースだけを設定する」ではなく、有効になってよいリソースと、オプトアウトすべきリソースを先に分類することです。
設定範囲はFoundryリソース単位
a365LoggingEnabledはFoundryリソースレベルで適用されます。公式ドキュメントでは、同じFoundryリソース内のプロジェクトやプロンプトエージェントは同じデータ収集設定を継承し、プロジェクト単位またはエージェント単位のオーバーライドはないとされています。(Microsoft Learn)
そのため、1つのFoundryリソース内に「Agent 365へ連携してよいエージェント」と「連携してはいけないエージェント」が混在している場合は、設定値だけでは整理できません。リソース分割を含めて設計を見直す必要があります。
| 状況 | 推奨される考え方 |
|---|---|
| すべてのエージェントをAgent 365に連携してよい | 既定設定を確認し、監査ログと運用手順を整備する |
| 一部のエージェントだけ連携したい | Foundryリソースを分ける設計を検討する |
| 規制対象データを扱うエージェントがある | 該当リソースをa365LoggingEnabled=falseにするか、別テナント・別リソースで管理する |
| Hosted Agentを使っている | Agent 365 SDKの明示設定がリソース設定を上書きしないか確認する |
Hosted AgentではSDK設定の上書きに注意
見落としやすいのがHosted Agentです。公式ドキュメントでは、Hosted AgentはAgent 365 SDKをエージェントコードと一緒に構成する必要があり、Hosted Agent側の明示的なAgent 365 SDK構成はFoundryリソースレベルのログ無効化設定をオーバーライドすると説明されています。(Microsoft Learn)
これは、運用上かなり重要です。
たとえば、Cloud AdminがFoundryリソースでa365LoggingEnabled=falseを設定していても、Hosted Agent側のSDK構成によってデータが流れる可能性を確認しなければなりません。開発チームと管理チームが別々に設定を管理している組織では、ここが事故になりやすいポイントです。
Hosted Agentを使っている場合は、次の3点を確認してください。
| 確認項目 | 確認内容 |
|---|---|
| SDK構成 | Agent 365 SDKを明示的に組み込んでいるか |
| リソース設定 | 対象Foundryリソースのa365LoggingEnabledがどうなっているか |
| 実際のデータフロー | Agent 365側に活動データが登録・分析されていないか |
Solution Architectが確認すべきデータ所在とガバナンス
Agent 365連携は、単に「ログを送る・送らない」の話ではありません。データ所在とガバナンスの観点で設計判断が必要です。
公式の統合ドキュメントでは、Microsoft Foundryは作成時に選択したAzureリージョンに基づくデータ所在モデルを持ち、Microsoft Agent 365はMicrosoft Entraテナントのストレージ場所に基づくデータ所在モデルを持つと説明されています。FoundryからAgent 365へエージェント活動データが流れる場合、データはAzureリージョンベースのモデルからEntraテナントベースのモデルへ移動します。(Microsoft Learn)
このため、グローバル企業や規制産業では、次のような判断が必要になります。
| 判断ポイント | 確認すること |
|---|---|
| データ所在 | FoundryリソースのAzureリージョンとEntraテナントの保存地域が一致するか |
| 規制要件 | エージェント活動データが国外・域外に移動しても問題ないか |
| オプトアウト範囲 | リソース単位でa365LoggingEnabled=falseにすべき対象があるか |
| 監査証跡 | 誰が、いつ、どのリソースのデータ収集を有効化・無効化したか記録できるか |
| 管理責任 | Azure管理者、Microsoft 365管理者、セキュリティ部門の責任分界を明確にしているか |
技術的に設定できることと、組織として設定してよいことは別です。特に、エージェントが顧客情報、社内文書、業務プロセス情報にアクセスする場合は、アーキテクチャレビューの段階でAgent 365へのデータ流通を確認してください。
Agent 365連携の対象エージェント種別も確認する
Agent 365連携は、すべてのFoundryエージェントで同じように使えるわけではありません。公式ドキュメントでは、Prompt agent、Hosted agent、Workflow agentで、レジストリ同期、デジタルワーカー公開、活動データ収集の対応状況が異なると説明されています。(Microsoft Learn)
| エージェント種別 | 確認すべきポイント |
|---|---|
| Prompt agent | レジストリ同期、デジタルワーカー公開、活動データ収集の対象になり得る |
| Hosted agent | 活動データ収集はA365 SDK利用が前提になる |
| Workflow agent | Agent 365連携機能の対象範囲が限定される |
この違いを知らずにa365LoggingEnabledだけを見ていると、「設定は有効なのに期待したデータが見えない」「無効にしたはずなのにHosted Agent側のSDK設定が効いている」といったトラブルにつながります。
移行準備でやるべきチェックリスト
今回のAzure AI公式ドキュメント更新を受けて、実務では次の順番で確認すると効率的です。
| 順番 | 作業 | 担当の目安 |
|---|---|---|
| 1 | Microsoft Learn最新版の該当ページを確認する | 開発者、Cloud Admin |
| 2 | IaC、CLI、PowerShell、REST、Azure Policyの旧表記を検索する | 開発者、SRE |
| 3 | enabled / disabledをBooleanのtrue / falseへ見直す | 開発者 |
| 4 | agent365Config.loggingEnabledなど旧プロパティ前提のコードを確認する | 開発者、Cloud Admin |
| 5 | Foundryリソースごとのa365LoggingEnabled状態を棚卸しする | Cloud Admin |
| 6 | Agent 365ライセンスとテナント同意の有無を確認する | Microsoft 365管理者 |
| 7 | データ所在と規制要件をレビューする | Solution Architect、セキュリティ部門 |
| 8 | 社内手順書のTOC依存リンクを直接URL・ページ名ベースに更新する | 技術広報、運用チーム |
現在の設定を確認するコマンド例
実環境では、対象リソースのプロパティを確認してから変更してください。たとえば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}" \
-o json確認結果でa365LoggingEnabledがtrueの場合でも、Agent 365側にデータが流れるにはライセンスとテナント同意が必要です。逆に、Hosted AgentでSDKを明示構成している場合は、リソースレベルの設定だけで判断しないようにしてください。(Microsoft Learn)
よくある失敗と回避策
falseを文字列で書いてしまう
IaCでは、falseと"false"は別物です。Booleanプロパティに文字列を渡すと、デプロイエラーや意図しない挙動の原因になります。
悪い例です。
{
"properties": {
"a365LoggingEnabled": "false"
}
}正しい例です。
{
"properties": {
"a365LoggingEnabled": false
}
}enabled / disabledをそのまま使い続ける
コミット差分では、enabled / disabledからtrue / falseへの変更が複数箇所で行われています。古いサンプルをコピーした社内テンプレートが残っている場合は、必ず見直してください。(GitHub)
a365LoggingEnabled=trueだけでデータ収集が始まると思い込む
公式ドキュメントでは、データ収集にはAgent 365ライセンス、テナントレベルのA365同意、a365LoggingEnabled=trueの3つが必要です。技術設定だけを変更しても、ライセンスや同意が未完了ならデータは取り込まれません。(Microsoft Learn)
リソース単位の設定をプロジェクト単位の設定と誤解する
a365LoggingEnabledはFoundryリソース単位で適用されます。プロジェクトやエージェントごとに細かく切り替えられる前提で設計すると、後からリソース分割が必要になることがあります。(Microsoft Learn)
TOCから見つからないため廃止と判断する
今回の「without toc」は、差分上はTOC項目のコメントアウトを含む更新です。左ナビに表示されない、または場所が変わることはあり得ますが、それだけで機能廃止と判断しないでください。公式ページ本文、関連リンク、GitHub差分をあわせて確認するのが安全です。(GitHub)
役割別に見るべきポイント
| 役割 | すぐ確認すべきこと |
|---|---|
| Developers | CLI、PowerShell、REST、Bicep、Terraformの旧プロパティ・旧値を修正する |
| Cloud Admins | Foundryリソースごとのa365LoggingEnabled状態とAzure Policyの適用方針を確認する |
| Solution Architects | Agent 365へのデータ流通、データ所在、リソース分割方針をレビューする |
| Technical Decision Makers | Agent 365利用時のライセンス、同意、ガバナンス、監査責任を整理する |
今回の更新は、表面上はドキュメント更新に見えます。しかし、Agent 365連携を使う組織では、実装、運用、ガバナンスに影響します。特にグローバル環境では、データ所在と管理責任の整理が欠かせません。
まとめ：まず旧表記の棚卸しから始める
Azure AIの公式ドキュメント更新「publish a365 docs without toc」で確認すべき最重要ポイントは、次の3つです。
1つ目は、TOCからAgent 365関連ページへの導線が変わる可能性があることです。社内手順書がMicrosoft Learnの左ナビ依存になっている場合は、ページ名と直接URLを基準に更新してください。
2つ目は、Agent 365データ収集の設定がBoolean値で扱われることです。公開中のMicrosoft Learnでは、a365LoggingEnabled=trueまたはfalseでFoundryリソース単位のデータ収集を制御します。
3つ目は、trueにしてもライセンスとテナント同意がなければデータ収集は始まらないことです。一方で、Hosted AgentではSDK側の設定が関係するため、リソース設定だけで判断しないようにしましょう。
次に取るべき行動はシンプルです。リポジトリ、IaC、運用手順書を横断検索し、agent365Config、loggingEnabled、enabled、disabled、ingestionEndpointが残っていないか確認してください。そのうえで、Microsoft Learn最新版に合わせてa365LoggingEnabled、a365Status、true / falseを前提にした運用へ更新するのが安全です。
コメント