Azure の「Secure AI – Guidance to set up your organization’s AI security process – Cloud Adoption Framework」は、新しい単体機能の追加というより、Azure 上の AI ワークロードを安全に運用するための実務ガイダンスです。結論から言うと、管理者が確認すべきポイントは「AI資産の棚卸し」「データ保護」「通信経路の保護」「脅威検知」「インシデント対応」の5つです。特に、Azure OpenAI Service、Azure AI Foundry、Azure Machine Learning、Copilot Studio、AIエージェント、RAG構成、モデルやデータセットを扱う環境では、PoC段階でもセキュリティプロセスを整備しておく必要があります。Microsoft Learn の該当ページでは、Secure AI を Cloud Adoption Framework における継続的な取り組みとして位置付け、AI Strategy、AI Plan、AI Ready と必要に応じて行き来しながら見直すものと説明しています。(Microsoft Learn)
Azure の新機能・変更点：「Secure AI – Guidance to set up your organization’s AI security process – Cloud Adoption Framework」で確認すべきポイント
今回の更新で押さえるべき点は、Azure の AI セキュリティを「導入後に個別対応するもの」ではなく、「導入前から継続的に回すプロセス」として整理していることです。
Microsoft Learn の Secure AI ガイダンスでは、AI セキュリティを大きく次の3領域に分けています。
| 領域 | 管理者が確認すべきこと | 実務での意味 |
|---|---|---|
| AI セキュリティリスクの発見 | AI特有の脅威、データリスク、モデル脆弱性を評価する | 従来の脅威モデリングだけでなく、プロンプトインジェクションやデータ漏えいも評価対象にする |
| AI リソースとデータの保護 | AI資産台帳、ID、ネットワーク、RBAC、DLPを整備する | 「誰が、どのデータを、どのAIから使えるか」を明確にする |
| AI セキュリティ脅威の検知 | Defender for Cloud、監視、インシデント対応を整える | AIワークロードの異常利用や設定不備を継続的に検知する |
従来のクラウドセキュリティでは、仮想マシン、ネットワーク、ID、ストレージの保護が中心でした。しかし AI ワークロードでは、モデル、プロンプト、学習データ、埋め込みデータ、RAG用インデックス、AIエージェント、MCPサーバーなども保護対象になります。Secure AI の更新は、この範囲拡大を前提にした運用設計を促す内容です。(Microsoft Learn)
今回の更新は「強制的な仕様変更」ではなく「運用基準の見直し」
まず誤解しやすい点として、Secure AI のガイダンス自体は、Azure ポータル上の特定設定を自動的に変更するものではありません。新しい必須スイッチが追加された、既存リソースが突然停止する、といった種類の更新ではなく、組織が AI セキュリティプロセスを整備するための設計指針です。
ただし、実務上の影響は小さくありません。これまで「AI は一部チームの実験環境」として扱っていた組織では、AI資産の所在、利用データ、外部公開エンドポイント、権限設計、DLP、監視体制を改めて確認する必要があります。
特に影響を受けやすいのは、次のような環境です。
| 影響を受ける環境 | 確認すべきポイント |
|---|---|
| Azure OpenAI Service を利用している環境 | モデルデプロイ、APIキー、Managed ID、ネットワーク公開範囲、コンテンツフィルター |
| Azure AI Foundry を利用している環境 | エージェント、プロジェクト、接続データ、評価、監視、ライセンス |
| Azure Machine Learning を利用している環境 | 学習データ、モデル成果物、エンドポイント、実験環境、RBAC |
| RAG構成を持つアプリ | Azure AI Search、Blob Storage、SharePoint、社内DBなどのデータ境界 |
| Copilot Studio やエージェントを使う環境 | エージェントの権限、DLPポリシー、監視、Agent 365関連の変更 |
| マルチクラウドのAI活用 | Azure、AWS、GCP上のAI資産を横断的に把握できているか |
Microsoft Defender for Cloud の AI security posture management は、Azure、AWS、GCP を含むエンタープライズ環境の生成AIアプリケーションやAIエージェントを対象に、AI BOM、推奨事項、攻撃パス分析、外部到達可能なAIエンドポイントの把握を支援します。(Microsoft Learn)
管理者が最初にやるべきことは AI 資産の棚卸し
Secure AI ガイダンスで最初に重視されているのは、AI資産の把握です。これは単なる一覧表作りではありません。組織内にある AI リソース、モデル、エージェント、データ接続、API、ストレージ、ネットワーク経路を把握し、セキュリティポリシーの対象にできる状態にすることです。
Azure 管理者は、まず Azure Resource Graph や Microsoft Defender for Cloud を使って、サブスクリプションをまたいだ AI 関連リソースを洗い出すのが現実的です。Microsoft Learn でも、Azure Resource Graph によるリソース検出と Defender for Cloud による生成AIワークロードの識別が推奨されています。(Microsoft Learn)
たたき台としては、次のような観点で棚卸しを始めます。
Resources
| where type in~ (
"microsoft.cognitiveservices/accounts",
"microsoft.machinelearningservices/workspaces",
"microsoft.search/searchservices",
"microsoft.apimanagement/service",
"microsoft.storage/storageaccounts",
"microsoft.containerregistry/registries",
"microsoft.containerservice/managedclusters"
)
| project name, type, resourceGroup, subscriptionId, location, tagsこのクエリは完全な検出ルールではありません。実際には、AIアプリが利用するKey Vault、App Service、Functions、Container Apps、AKS、Application Gateway、Log Analytics、Storage、DB、ネットワーク関連リソースも合わせて確認する必要があります。
失敗しやすいのは、「Azure OpenAI リソースだけ」を棚卸しして満足してしまうことです。RAG構成では、検索インデックスや元データのストレージ、ベクトル化処理、アプリケーション層、認証基盤まで含めて確認しないと、実際の漏えいリスクを見落とします。
AIリスク評価は STRIDE だけで終わらせない
Secure AI ガイダンスでは、既存の脅威モデリングを使いながらも、AI特有のリスクを明示的に検証することが求められています。例として STRIDE に加え、MITRE ATLAS や OWASP Generative AI Risk などのAI固有の知識ベースを参照することが示されています。(Microsoft Learn)
実務では、次のように既存のセキュリティレビューを拡張すると進めやすくなります。
| 従来の確認項目 | AIで追加すべき確認項目 |
|---|---|
| 認証・認可 | モデルやエージェントが代理実行できる操作範囲 |
| ネットワーク公開範囲 | AIエンドポイント、MCPサーバー、API Managementの公開状態 |
| データ分類 | プロンプト、応答、RAG参照データ、ログに含まれる機密情報 |
| 脆弱性診断 | プロンプトインジェクション、データ漏えい、モデル反転、過剰なツール実行 |
| ログ監視 | 異常なプロンプト、機密データの出力、エージェントの不審な操作 |
ポイントは、AIリスクを「アプリの脆弱性診断の一部」として軽く扱わないことです。AIは入力と出力が自然言語であり、外部データや社内データを横断して処理するため、従来のWebアプリとは異なる攻撃経路が生まれます。
設定変更で優先すべきポイント
Secure AI ガイダンスを実務に落とし込むなら、いきなり全設定を見直すのではなく、リスクの高い順に確認するのが効果的です。
| 優先度 | 確認項目 | 推奨アクション | 失敗しやすいポイント |
|---|---|---|---|
| 高 | AI資産台帳 | Azure Resource Graph と Defender for Cloud でAI関連リソースを一覧化する | 手作業のExcel管理だけで終わる |
| 高 | IDと権限 | APIキー依存を減らし、Managed ID と最小権限を基本にする | 検証時の高権限を本番に残す |
| 高 | ネットワーク | Private Link、VNet、API Managementで通信経路を制御する | AIエンドポイントやMCPサーバーを広く公開する |
| 高 | データ境界 | Microsoft Purview、RBAC、秘密度ラベル、DLPで利用可能データを制限する | RAGの参照データを全社向けに広げすぎる |
| 中 | コンテンツ保護 | コンテンツフィルターやカスタムフィルターで機密情報の出力を抑制する | 汎用フィルターだけで業務固有の機密語を見ない |
| 中 | 監視と検知 | Defender for Cloud の AI security posture management を確認する | 推奨事項を確認するだけで是正しない |
| 中 | インシデント対応 | AI固有のエスカレーション手順を用意する | 通常の障害対応フローに混ぜて初動が遅れる |
Microsoft Learn では、Managed ID、VNet、Azure API Management、Microsoft Purview、Azure RBAC、Azure Private Link、Purview DLP、コンテンツフィルターなどが、AIリソースとデータ保護の具体的な選択肢として挙げられています。(Microsoft Learn)
DLPは本番ブロックの前にシミュレーションで確認する
AIセキュリティで特に慎重に進めたいのが DLP です。AIチャット、RAG、Copilot、エージェントは、利用者から見ると便利な一方で、機密情報を意図せず入力・参照・出力するリスクがあります。
Microsoft Purview DLP は、Exchange、SharePoint、OneDrive、Teams、Officeアプリ、Windows、macOS、オンプレミス、Microsoft Fabric、Power BI、Microsoft 365 Copilot など、複数の場所を対象に機密情報の共有や持ち出しを制御できます。DLPポリシーでは、警告表示、ブロック、上書き許可、監査などの保護アクションを設定できます。(Microsoft Learn)
実務では、次の順番で進めると失敗しにくくなります。
| 手順 | やること | 判断基準 |
|---|---|---|
| 1 | 機密情報の種類を定義する | 個人情報、契約情報、財務情報、ソースコード、顧客データなどを分類する |
| 2 | 対象場所を決める | Microsoft 365、AIアプリ、エンドポイント、Webトラフィックを分けて考える |
| 3 | シミュレーションモードで影響を見る | 正常業務が止まらないか、誤検知が多すぎないかを確認する |
| 4 | 条件を調整する | 対象ユーザー、ラベル、例外、検出条件を絞り込む |
| 5 | 段階的にブロックへ移行する | 重要データから強制制御を適用する |
Microsoft Learn でも、DLPポリシーはシミュレーションモードで影響を評価し、業務への悪影響を避けながら調整してから有効化する流れが説明されています。(Microsoft Learn)
移行期限はあるのか
Secure AI ガイダンスそのものには、「この日までに設定変更しなければならない」という一律の移行期限は示されていません。したがって、Azure の全利用者が同じ期限で対応を迫られる変更ではありません。
ただし、関連する AI エージェントのセキュリティ機能には重要な期限があります。Microsoft Learn では、2026年7月1日以降、Microsoft Copilot Studio と Microsoft Foundry エージェントのAIエージェントセキュリティ機能に Microsoft Agent 365 ライセンスが必要になると説明されています。対象ライセンスがないテナントでは、該当機能へのアクセスを失う可能性があります。(Microsoft Learn)
特に確認すべき変更は次のとおりです。
| 対象 | 変更内容 | 管理者の確認事項 |
|---|---|---|
| Copilot Studio エージェント | 一部のエージェント検出、姿勢管理、脅威検知が Agent 365 側へ移行 | Agent 365 の対象ライセンス有無を確認する |
| Microsoft Foundry エージェント | エージェントレベルの検出、姿勢管理、脅威保護に Agent 365 が必要 | Foundryアカウント・プロジェクトとエージェントの見え方を確認する |
| Advanced Hunting | AIAgentsInfo から AgentsInfo への移行が案内されている | 保存済みクエリ、カスタム検知、ブックを見直す |
| リアルタイム保護 | 既存のブロックルールは2026年7月1日に停止する場合がある | 新しいポリシー画面でブロックルールを再定義する |
| サードパーティクラウドエージェント | Defender for Cloud コネクタ経由の検出から Agent 365 レジストリ同期へ移行 | レジストリ同期の構成を確認する |
2026年7月以降にこの記事を読んでいる場合は、すでに期限を過ぎています。エージェントを使っている組織は、まず Microsoft Defender ポータルで AI Agents inventory、Security for AI 設定、Advanced Hunting のクエリ、リアルタイム保護ルールを確認してください。
グローバル環境で注意すべき点
グローバル企業や複数リージョンで Azure を使っている場合、Secure AI の対応は本社だけで完結しません。リージョンごとのデータ保管要件、現地法人の利用AI、外部委託先の開発環境、各国の法規制、利用可能なAzure機能の差を考慮する必要があります。
特に注意したいのは、次の3点です。
データ境界を国・部門・用途ごとに分ける
AIアプリが参照するデータは、アプリ利用者の権限に合わせて制御する必要があります。例えば、日本法人の営業データをグローバル共通エージェントが参照できる設計にすると、意図しない情報共有が起きる可能性があります。
RAG構成では、検索インデックスに入れた時点でデータ境界が曖昧になりやすいため、元データ、インデックス、アプリ、利用者権限をセットで設計してください。
プレビュー機能やリージョン差を前提に設計する
AI関連サービスは更新が速く、機能の提供リージョンやプレビュー状態が変わることがあります。特定リージョンで使える機能を前提に、全社標準を決めてしまうと、別リージョンで同じ運用ができない場合があります。
グローバル標準を作る場合は、「必須統制」と「リージョンごとの代替策」を分けておくと運用しやすくなります。
セキュリティ運用チームとAI開発チームを分断しない
AI開発チームがモデルやプロンプトを管理し、セキュリティチームがクラウド設定だけを見る体制では、AI固有のリスクを見落とします。モデル、データ、アプリ、ID、ネットワーク、監視ログを横断して確認できる責任分界を作ることが重要です。
既存環境の確認チェックリスト
Azure 管理者は、次のチェックリストを使って現状を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| AI資産台帳はあるか | Azure OpenAI、AI Foundry、Azure ML、AI Search、Storage、API Management、MCPサーバーを含めて一覧化しているか |
| 所有者は明確か | 各AIリソースに業務責任者、技術責任者、セキュリティ責任者が設定されているか |
| 外部公開範囲は妥当か | AIエンドポイント、API、MCPサーバー、管理画面が不要に公開されていないか |
| 認証は強いか | APIキーの直書きや共有を避け、Managed IDや最小権限を使っているか |
| データ分類はできているか | Purview、秘密度ラベル、RBACでAIが参照できるデータを制御しているか |
| DLPは機能しているか | Copilot、AIアプリ、Teams、SharePoint、エンドポイントで機密情報の流出を検知・制御できるか |
| 監視はあるか | Defender for Cloud、Log Analytics、Microsoft Defender ポータルでAI関連のリスクを確認できるか |
| インシデント対応はあるか | プロンプト経由の漏えい、モデル悪用、エージェントの不審操作に対応する手順があるか |
| Agent 365 の影響を確認したか | Copilot Studio、Foundryエージェント、Advanced Hunting、リアルタイム保護ルールを見直したか |
このチェックリストで「未確認」が多い場合は、いきなり細かい設定変更に入るより、まず AI資産台帳を作ることを優先してください。台帳がない状態では、DLPや監視を設定しても対象漏れが起きやすくなります。
導入前・本番化前に決めるべき判断基準
Secure AI を実務に定着させるには、AI導入の承認基準を明文化することが重要です。特に、本番化前に次の条件を満たしているか確認してください。
| 判断基準 | 本番化してよい状態 |
|---|---|
| 利用目的 | 業務上の目的、利用者、期待効果が明確になっている |
| データ | 機密情報の分類、参照範囲、保存先、ログ出力範囲が確認済み |
| ID・権限 | 利用者、アプリ、エージェント、ワークロードIDに最小権限が適用されている |
| ネットワーク | 不要なパブリック公開がなく、必要に応じてPrivate LinkやVNetを使っている |
| DLP | シミュレーションまたは本番ポリシーで機密情報の流出を確認できる |
| 監視 | AIリソース、API、エージェント、データアクセスのログを追跡できる |
| 例外管理 | 一時的な高権限や公開設定に期限と承認者がある |
| インシデント対応 | 漏えい、誤回答、権限逸脱、不正利用の対応手順がある |
この基準を満たしていないAIアプリは、たとえ技術的に動作していても本番化を急がない方が安全です。AIは利用開始後にデータ接続やエージェント機能が追加されやすいため、初期設計が甘いと後から統制をかけるのが難しくなります。
まとめ：Secure AI 対応は「台帳化」から始める
Azure の Secure AI ガイダンス更新で最も重要なのは、AIセキュリティを単発の設定確認ではなく、継続的な運用プロセスとして扱うことです。
まず、Azure Resource Graph や Defender for Cloud を使って AI資産を棚卸ししてください。次に、Microsoft Purview、RBAC、Private Link、Managed ID、DLP、コンテンツフィルターを使い、データ境界と通信経路を明確にします。そのうえで、Defender for Cloud の AI security posture management や Microsoft Defender ポータルを使い、リスク検知とインシデント対応を整えます。
特に Copilot Studio や Microsoft Foundry のエージェント機能を使っている場合は、2026年7月1日以降の Agent 365 ライセンス要件、Advanced Hunting クエリ、リアルタイム保護ルールの移行状況を確認してください。Secure AI の対応は、最初から完璧に整えるよりも、まず「どこにAIがあり、何のデータに触れているか」を見える化することが出発点です。
コメント