Azure AI Foundry（現行ドキュメントでは Microsoft Foundry と表記される場合があります）のデータ、プライバシー、セキュリティで最初に押さえるべき結論は、プロンプト、応答、埋め込み、学習データが、他の顧客やOpenAIなどのモデル提供元に渡されるわけではなく、明示的な許可なしに基盤モデルの学習にも使われないという点です。一方で、Responses API、Assistants API、Stored completions、Batch、fine-tuning、Global／DataZoneデプロイなどを使う場合は、データの保存有無、処理場所、監視、削除運用を個別に確認する必要があります。(Microsoft Learn)
本記事では、Azure AI Foundryの「Data, privacy, and security for Foundry Models sold by Azure in Microsoft Foundry」の公式情報をもとに、管理者・開発者が確認すべき変更点、影響範囲、設定、移行・展開時の注意点を実務目線で整理します。
Azure AI Foundryのセキュリティ更新で押さえるべき要点
今回のポイントは、単なる「データは安全です」という説明ではありません。管理者が見るべき観点は、どのデータが処理されるのか、どの機能で保存されるのか、どの地域で処理されるのか、監視データをどう確認するのかです。
Microsoftの公式ドキュメントでは、Foundry Models sold by Azureを「FoundryでAzureによって販売されるモデル」と位置づけており、Azure OpenAIモデルもこの範囲に含まれます。FoundryはAzureサービスであり、これらのモデルはMicrosoftのAzure環境でホストされ、OpenAIのChatGPTやOpenAI APIなど、モデル提供元が運用する外部サービスとは直接やり取りしないと説明されています。(Microsoft Learn)
特に重要なのは、以下の5点です。
| 確認項目 | 実務上の意味 |
|---|---|
| プロンプト・応答の扱い | 他顧客、OpenAI、他のモデル提供元には利用できない |
| 学習利用 | 明示的な許可や指示なしに基盤モデルの学習へ使われない |
| 保存されるデータ | Responses API、Assistants API、Stored completions、Files API、vector storeなどは保存設計が必要 |
| 処理場所 | Standard、Global、DataZone、Batchなどのデプロイ種類で変わる |
| 監視 | abuse monitoring、Guardrails、ContentLoggingの確認が必要 |
変更点として見るべきポイント
「Azure AI Foundry」から「Microsoft Foundry」表記への移行を前提に読む
Azure AI Foundry関連のドキュメントは、現行ではMicrosoft Foundryという名称で整理される場面が増えています。Microsoftの移行ドキュメントでは、Azure AI Studio／Azure AI FoundryからMicrosoft Foundryへ名称が進化している一方、Azureリソース種別は引き続きMicrosoft.CognitiveServices/accountsであると説明されています。(Microsoft Learn)
そのため、管理者は「名称が変わっただけ」と軽く扱わず、以下を確認してください。
| 旧来の見方 | 現行ドキュメントでの見方 | 確認すべきこと |
|---|---|---|
| Azure AI Foundry | Microsoft Foundry | ポータル、SDK、RBAC名の表記差異 |
| Azure OpenAI中心 | Models sold by Azureを含むFoundry Models | 対象モデルの範囲 |
| Assistants API中心 | Responses API／Foundry Agent Serviceへの移行 | 会話履歴や状態保存の扱い |
| 月次APIバージョン指定 | v1 stable routes | SDK・エンドポイント変更 |
名称変更は見た目の問題だけではありません。RBACロール名、API、ポータル構成、エンドポイント、Agent関連の設計に影響します。既存の社内手順書やIaCテンプレートに「Azure AI User」「Azure AI Project Manager」など旧名称が残っている場合は、現行のFoundryロール名と照合しておくとトラブルを減らせます。Foundry RBACロールは改名されているものの、ロールIDと主要権限は変わらないと説明されています。(Microsoft Learn)
Azure OpenAIだけでなく「Models sold by Azure」全体を対象にする
公式ドキュメントは、Azure OpenAI単体のデータ保護説明ではなく、Foundry Models sold by Azure全体を対象にしています。ここにはAzure OpenAIモデルが含まれますが、管理上は「Azureが販売するFoundryモデル」として、モデルの種類やデプロイ方式ごとにデータ処理を確認する必要があります。(GitHub)
実務では、モデルカタログで選んだモデルが次のどちらに該当するかを最初に確認してください。
| モデルの種類 | 主な確認ポイント |
|---|---|
| Models sold by Azure | MicrosoftのAzure環境でホストされ、Azureのデータ処理・コンプライアンス前提で確認する |
| パートナー／コミュニティ提供モデル | 提供元の条件、サポート、データ処理条件を別途確認する |
「Foundryで使っているからすべて同じデータ条件」と考えるのは危険です。モデル提供形態が違うと、適用される条件や確認すべきドキュメントが変わります。
どのデータが処理・保存されるのか
Azure AI Foundryで管理者が特に注意すべきデータは、プロンプトと応答だけではありません。公式ドキュメントでは、プロンプトと生成コンテンツ、アップロードデータ、状態を持つエンティティのデータ、プロンプトに付加される拡張データ、fine-tuning用の学習・検証データが処理対象として整理されています。(GitHub)
保存されないものと保存されるものを分けて考える
通常の推論では、モデル自体はステートレスであり、プロンプトや応答はモデル内に保存されず、基盤モデルの学習・再学習・改善にも使われないと説明されています。(GitHub)
ただし、次の機能を使う場合は、サービス側にデータが保存される可能性があります。
| 機能 | 保存される可能性があるデータ | 管理者の確認ポイント |
|---|---|---|
| Files API／vector store | アップロードファイル、検索用データ | 保存場所、削除手順、アクセス権 |
| Responses API | メッセージ履歴や関連コンテンツ | 会話履歴の保持要件 |
| Assistants API | Threadsなどのメッセージ履歴 | 既存実装の移行計画 |
| Stored completions | 入出力ペア | 本番データを評価・fine-tuningに使う可否 |
| Batch | アップロードしたバッチ処理データ | Global処理の影響 |
| fine-tuning | 学習・検証データ、fine-tuned model | 削除、暗号化、利用者範囲 |
保存データは、原則として顧客のAzureテナント内にあるFoundryリソースに、同じAzure geography内で保存され、保存時はMicrosoft管理のAES-256暗号化が既定で適用されます。顧客管理キーを使える場合もありますが、プレビュー機能ではすべての条件を満たさない可能性がある点に注意が必要です。(GitHub)
Global／DataZone／Standardデプロイで変わる処理場所
セキュリティレビューで見落としやすいのが、保存場所と処理場所は同じとは限らないという点です。
公式ドキュメントでは、通常のデプロイではプロンプトと応答が顧客指定のgeography内で処理されますが、GlobalまたはDataZoneデプロイを使う場合は処理場所の考え方が変わると説明されています。Globalでは該当モデルがデプロイされている任意のgeographyで処理される可能性があり、DataZoneでは指定されたデータゾーン内で処理されます。一方、保存データは顧客指定のgeographyに保存されるとされています。(Microsoft Learn)
デプロイ種類ごとの確認観点は次のとおりです。
| デプロイ種類 | 処理場所の考え方 | 向いているケース | 注意点 |
|---|---|---|---|
| Standard／Regional | 単一リージョン中心 | データ所在地を厳密に管理したい | モデル可用性やスループットに制限が出る場合がある |
| Global Standard | 任意のAzureリージョンで処理され得る | 高いクォータ、広いモデル可用性を重視 | データ所在地要件が厳しい業務には不向き |
| DataZone Standard | USまたはEUなど指定ゾーン内 | データゾーン単位の要件がある | 「特定リージョン固定」ではない |
| Global Batch | 大量非同期処理 | コスト重視の大規模処理 | リアルタイム用途ではない |
| DataZone Batch | データゾーン内の大量非同期処理 | EU／USゾーン内でのバッチ処理 | 保存場所と処理場所の説明を監査資料に残す |
Deployment typesの公式ドキュメントでも、デプロイ種類はデータ処理場所、支払い方法、パフォーマンス特性に影響すると説明されています。Globalは任意のAzureリージョン、DataZoneはMicrosoftが指定するUSまたはEUのデータゾーン、Standard／Regionalはデプロイリージョンで処理される整理です。(Microsoft Learn)
管理者は、モデル選定時に「高性能だからGlobal」「安いからBatch」と決めるのではなく、次の順で判断すると安全です。
- 規制・契約上、処理場所をどこまで限定する必要があるか
- リアルタイム応答が必要か、24時間程度の非同期処理でよいか
- スループットやレイテンシのばらつきを許容できるか
- Azure Policyで禁止すべきデプロイ種類があるか
- 監査資料に保存場所と処理場所を分けて説明できるか
なお、デプロイ種類を組織標準として制御したい場合は、Azure Policyで特定のFoundryデプロイ種類を制限する考え方も公式ドキュメントで示されています。(Microsoft Learn)
abuse monitoringとGuardrailsで確認すべきこと
Azure AI Foundryでは、不正利用や有害コンテンツ生成を抑止するために、abuse monitoringとGuardrailsが関係します。ここは「ログを取るか取らないか」だけでなく、コンプライアンス、インシデント対応、サービス継続性に関わるため、管理者が必ず確認すべき領域です。
abuse monitoringは、利用規約やCode of Conductに違反する可能性のある反復的なコンテンツや行動パターンを検出・緩和する仕組みです。公式ドキュメントでは、分類、パターン検出、レビュー、通知・対応の流れが説明されています。(Microsoft Learn)
一方、Guardrailsはプロンプト処理と同期的に動作し、有害コンテンツの検出・抑止に使われます。公式説明では、Guardrailsの分類モデルにプロンプトや生成コンテンツは保存されず、明示的な許可なしに基盤モデルの学習にも使われないとされています。(GitHub)
Modified abuse monitoringを使う場合の確認方法
高度に機密性の高いデータを扱う顧客は、条件を満たす場合にmodified abuse monitoringを申請できます。承認されると、人間によるレビューのためのデータ保存・レビューが行われない一方、オンラインでの自動レビューは引き続き行われる可能性があります。(Microsoft Learn)
承認後、abuse monitoring向けのデータ保存がオフになっているか確認するには、Azure portalのJSONビューまたはAzure CLIを使います。公式ドキュメントでは、ContentLoggingがfalseとして表示されるのは、abuse monitoringのデータ保存がオフになっている場合のみと説明されています。(GitHub)
az cognitiveservices account show -n <resource-name> -g <resource-group>確認すべき値は次の形式です。
{
"name": "ContentLogging",
"value": "false"
}注意点は、ContentLoggingが表示されないことを「オフ」と解釈しないことです。公式ドキュメントでは、falseの値はデータ保存がオフの場合にのみ表示されるとされています。監査証跡として残すなら、CLI出力、対象サブスクリプション、Foundryリソース名、確認日、承認状況をセットで記録しておくとよいでしょう。
管理者が確認すべき設定チェックリスト
Azure AI Foundryのデータ保護を実務で確認する場合は、次の順で棚卸ししてください。
| チェック項目 | 確認方法 | 見落としやすいポイント |
|---|---|---|
| 対象モデル | モデルカタログ、デプロイ情報 | Azure販売モデルか、パートナー／コミュニティモデルか |
| デプロイ種類 | Models + endpoints、IaC、Azure CLI | Global／DataZone／Batchの処理場所 |
| 保存データ | Files API、vector store、Responses、Stored completions | 会話履歴や入出力ペアの保持 |
| 暗号化 | リソース設定、CMK対応状況 | プレビュー機能がCMK非対応の場合 |
| abuse monitoring | JSONビュー、CLI | ContentLogging=falseの有無 |
| Guardrails | コンテンツフィルター設定 | デフォルト設定のまま本番要件を満たすとは限らない |
| RBAC | Azure RBAC、Foundryロール | Owner／Contributorだけではデータプレーン操作できない場合 |
| 削除運用 | API、ポータル、運用手順 | アップロードファイルや状態保持データの消し忘れ |
| 移行対象 | Assistants API、SDK、エンドポイント | Responses API移行時の保存データ設計 |
特にRBACは、AzureのOwnerやContributorを付けているだけでは十分でない場合があります。Hosted agent関連の公式ドキュメントでは、Foundryの権限はARMのコントロールプレーンとFoundryのデータプレーンに分かれており、エージェント作成や操作にはFoundry User、Foundry Project Manager、Foundry Ownerなどのデータプレーン権限が必要と説明されています。(Microsoft Learn)
開発者が見直すべき実装ポイント
Responses APIやStored completionsでは「状態保存」を前提に設計する
開発者が最も注意すべき点は、APIの種類によってデータの保持設計が変わることです。Responses APIはマルチターン会話やワークフローに必要なメッセージ履歴などを保存します。Assistants APIのThreadsやStored completionsも、メッセージ履歴や入出力ペアを扱います。(GitHub)
実装時は、次のような設計を最初に決めてください。
- 会話履歴を保存する必要があるか
- 保存する場合、個人情報や機密情報を含めてよいか
- 削除APIや保持期間の運用を誰が管理するか
- 評価やfine-tuningに本番入出力を使う場合、社内承認が必要か
- ログ、アプリDB、Foundry側の保存データを二重管理していないか
「アプリ側DBには保存していないから大丈夫」と考えるのは危険です。Foundryの機能側で状態を保持している場合、アプリDBとは別に削除・棚卸しの対象になります。
on your data構成ではデータソース側の権限も確認する
Azure OpenAIの「on your data」では、指定したデータソースから関連データを取得し、プロンプトを拡張して回答を生成します。公式ドキュメントでは、Azure OpenAIが重複したデータストアを作成するのではなく、指定したデータソースと場所にデータが残ると説明されています。(Microsoft Learn)
つまり、Foundry側だけでなく、Azure AI Search、Storage、データベース、Key Vaultなど、接続先リソースのRBACやネットワーク制御も同時に確認する必要があります。検索インデックスに不要な個人情報が入っていれば、モデル側の設定が適切でも、回答生成時に意図せず参照される可能性があります。
移行・展開時に失敗しやすいポイント
Assistants APIからResponses APIへの移行で履歴管理を見落とす
Microsoftの移行ドキュメントでは、Assistants APIは2026年8月26日にsunset予定とされ、一般提供されているMicrosoft Foundry Agents serviceへの移行が案内されています。また、移行計画ではResponses APIへの更新、対応リージョンの確認、新ポータルでの検証が挙げられています。(Microsoft Learn)
ここで失敗しやすいのは、API呼び出しの書き換えだけで移行を完了したつもりになることです。Threads、Messages、Runsから、Conversations、Items、Responsesへ概念が変わるため、会話履歴、ツール呼び出し、監査ログ、削除処理の設計も見直してください。
SDKとポータル体験の不一致に注意する
公式移行ドキュメントでは、azure-ai-inferenceパッケージの廃止予定や、openaiパッケージ、azure-ai-projects 2.xへの移行が示されています。さらに、2.x SDKサンプルを1.xの環境で使う、またはその逆を行うとエラーの原因になると注意されています。(Microsoft Learn)
開発チームでは、次の項目をリリース前にそろえてください。
| 項目 | 確認内容 |
|---|---|
| ポータル | Foundry classicか、現行Foundryか |
| SDK | azure-ai-projectsのメジャーバージョン |
| OpenAIクライアント | AzureOpenAI()依存を残すか、標準OpenAI()へ寄せるか |
| エンドポイント | account-levelかproject endpointか |
| 認証 | APIキーかMicrosoft Entra IDか |
| リージョン | Responses APIやAgent Serviceが利用可能か |
プレビュー機能を本番前提で使わない
公式ドキュメントでは、プレビュー中のモデルや機能は、abuse monitoringを含むプライバシー慣行が異なる可能性があり、Azure Previewの追加条件が適用される場合があるとされています。また、プレビュー機能では顧客管理キーなど、すべての保存条件をサポートしない可能性にも触れられています。(GitHub)
本番環境でプレビュー機能を使う場合は、少なくとも次の条件を満たしてから展開してください。
| 判断基準 | 展開前に確認すること |
|---|---|
| データ分類 | 個人情報、機密情報、契約上の制約があるデータを扱うか |
| 保存条件 | 暗号化、CMK、削除、保存場所の要件を満たすか |
| 監視条件 | abuse monitoringやGuardrailsの扱いを説明できるか |
| サポート | 障害時に代替手段があるか |
| 監査 | 公式ドキュメント、設定値、承認記録を残せるか |
実務でのおすすめ対応手順
Azure AI Foundryのセキュリティ確認は、以下の順で進めると効率的です。
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 1 | 利用中のFoundryリソース、プロジェクト、モデル、デプロイ種類を一覧化 | 利用棚卸し表 |
| 2 | 各モデルがModels sold by Azureか確認 | モデル分類表 |
| 3 | Standard／Global／DataZone／Batchの利用有無を確認 | データ処理場所の整理 |
| 4 | Files API、vector store、Responses、Stored completions、fine-tuningの利用有無を確認 | 保存データ一覧 |
| 5 | RBACをコントロールプレーン／データプレーンで分けて確認 | 権限レビュー表 |
| 6 | Guardrailsとabuse monitoringの設定を確認 | セキュリティ設定記録 |
| 7 | ContentLogging=falseの有無を確認 | 監査証跡 |
| 8 | Assistants API、旧SDK、旧ポータル手順の残存を確認 | 移行計画 |
| 9 | 削除・保持・監査ログの運用ルールを定義 | 運用手順書 |
| 10 | 本番前にテスト環境でデータフローを再確認 | 展開判定記録 |
最初にやるべきことは、設定画面を眺めることではなく、どの機能がデータを保存し、どのデプロイ種類がどこで処理するかを一覧化することです。これがないと、セキュリティレビューも移行計画も場当たり的になります。
まとめ：Azure AI Foundryでは「保存・処理・監視」を分けて確認する
Azure AI FoundryのData, privacy, and securityに関する公式情報で最も重要なのは、プロンプトや応答が無断で基盤モデルの学習に使われないという安心材料だけではありません。実務では、機能ごとの保存有無、Global／DataZone／Standardデプロイによる処理場所、abuse monitoringとGuardrails、RBAC、SDK・API移行をまとめて確認する必要があります。
管理者はまず、利用中のモデル、デプロイ種類、保存機能、RBAC、監視設定を棚卸ししてください。開発者は、Responses APIやStored completionsのような状態保持機能を使う場合、会話履歴や入出力データの削除・保持・監査設計まで含めて実装を見直すべきです。
次に取るべき行動は、現在のFoundry環境で「どのデータが、どこに保存され、どこで処理され、誰がアクセスできるのか」を1枚の表にまとめることです。そのうえで、GlobalやDataZoneの利用可否、modified abuse monitoringの承認状況、Assistants APIや旧SDKの移行計画を順に確認すると、セキュリティ更新への対応を現場で進めやすくなります。
コメント