Azure AI Foundry（Azure OpenAI）にプロンプトや業務データを送ると、「そのデータは学習に使われないのか」「別テナントに混入して返ってこないのか」「個人情報（PII）を扱っても安全か」を確認したくなります。本記事では、公式に示されている前提を軸に、漏えいを起こさない実務設計（マスク・ログ・ネットワーク・運用）まで具体的に整理します。
まず結論：Azure AI Foundry（Azure OpenAI）の「データ取り扱い」はどう整理すべきか
監査・セキュリティレビューでまず押さえるべきポイントは、次の3つです。
- 学習利用（モデル改善）：Azure AI Foundry（Azure OpenAI）へ送ったプロンプト（入力）や生成結果（出力）は、原則として他社に提供されず、基盤モデルの学習にも使われない前提で説明されています。
- 他テナントへの混入（プロンプト分離）：設計上、顧客ごとのデータは論理分離され、リクエストは暗号化されて処理される前提です。別顧客が似た質問をしても、あなたの入力や出力が“再利用”されて返る、という想定ではありません。
- 実務上の盲点：本当に事故が起きやすいのはLLMサービスの外側（アプリのログ、RAGの検索インデックス、キャッシュ、スレッドIDの取り回し、権限設計）です。ここを潰せば、説明可能性と安全性が一気に上がります。
| 論点 | 基本の整理（前提） | 現場で注意すべきポイント |
|---|---|---|
| 送ったデータが公開される？ | 一般公開される前提ではない | 自社が作るログ・分析基盤に保存していないかを最優先で確認 |
| モデル学習に使われる？ | 基盤モデルの学習に使われない、という整理 | ファインチューニングや「保存系機能」を使うと「自テナント内に保存」は起きる（＝学習とは別の論点） |
| 他テナントに混入する？ | テナント間で論理分離される設計 | マルチテナントアプリの場合は「共有リソース＋実装ミス」で漏えいが起きる。サービス単体よりアプリ層が危険 |
| PII（個人情報）を送ってよい？ | 送信自体は可能だが、最小化が基本 | マスク／匿名化、権限、ログ、保持期間、閉域化をセットで設計 |
誤解が多いポイント：Azure OpenAIは「ステートレス」だが、例外として“保存される機能”がある
「Azure OpenAIはステートレス＝何も保存されない」と理解されがちですが、正確には次のように分けて考えるとスッキリします。
- 通常の推論（チャット/補完/画像/埋め込み）：モデル自体はステートレス（モデル内部にプロンプトや出力が保存される前提ではない）。
- 保存が発生する機能：会話履歴を扱う“状態あり”のAPI（例：Responses API、AssistantsのThreads、Stored completions、Files/Vector store、ファインチューニング用アップロードなど）は、機能要件としてデータストアを持ちます。
- 悪用監視（abuse monitoring）：乱用検知の仕組みとして、特定の条件下でプロンプト／生成結果が保存・レビュー対象になり得ます（後述）。
「保存＝学習」ではない
ここが重要です。保存されること（ログ/スレッド/ファイル）と、基盤モデルの学習に使われることは別の論点です。保存は、会話継続や運用・監査・乱用対策などの“サービス機能”として発生し得ます。一方で、基盤モデル学習に使うかどうかは別ポリシーです（後者は使われない前提の整理）。
学習利用・公開の心配：Azure AI Foundry（Azure OpenAI）に送ったデータはどう扱われる？
公式の説明の軸はシンプルで、監査資料にも落とし込みやすい形になっています。
- プロンプト（入力）、生成結果（出力）、埋め込み、学習データは他の顧客が利用できない。
- それらはOpenAI（提供事業者）など外部のモデル提供者に渡らない。
- それらは基盤モデルの学習や再学習、改善に使われない（ユーザーの指示や許可がある場合を除く）。
- Microsoft側の他製品・第三者製品の改善にも、明示的な許可なく使われない、という整理。
また、Azure AI Foundry（Azure OpenAI）はAzureサービスとして、モデルはMicrosoftのAzure環境でホストされ、ChatGPTやOpenAI APIなど“OpenAI社が運用するサービス”と直接連携して処理する構造ではない、という説明も明記されています。「OpenAI側に露出しないか？」という質問には、この点が一番効きます。
ファインチューニングは「自分のために作る」もの
ファインチューニングを行う場合、学習データのアップロードや生成されたカスタムモデルは“保存”されますが、その成果物（ファインチューニング済みモデル）は自分だけが使える、という整理です。また、アップロードした学習データが勝手に他の基盤モデル学習に転用されるものではない、と説明されています。
| 利用シナリオ | 基盤モデル学習への利用 | 保存（データが残る可能性） | 運用でやるべきこと |
|---|---|---|---|
| 通常のチャット/補完 | 使われない前提 | モデル内部に保存しない（ただし監視・運用の例外は後述） | アプリ側のログ/監視のPII混入を止める |
| Responses API / Assistants Threads | 使われない前提 | 会話履歴などが保存される（状態あり） | テナント単位でIDを分離、削除運用、最小保持 |
| Files / Vector store / Stored completions | 使われない前提 | アップロード/入出力ペアが保存される | 保管ポリシー・暗号鍵・アクセス権を設計 |
| ファインチューニング | 勝手に転用されない前提 | 学習データや成果物が保存される | データ分類、CMK、削除手順、誤投入防止 |
他テナントへの漏えい（プロンプト分離）問題をどう説明するか
「別顧客が似たプロンプトを投げたときに、自分の入力や生成結果が混ざって返るのでは？」という不安は、現場で非常に多いです。ここは“サービス側”と“アプリ側”を分けて説明すると納得度が上がります。
サービス側：顧客ごとの論理分離を前提に設計されている
公式の説明では、顧客のリクエストは暗号化され、顧客のやり取りは論理的に分離・保護される（TLS 1.2以上、計算領域のセキュリティ境界、トークン化、GPUメモリの排他利用など）という“技術的措置”が挙げられています。さらに、プロンプトや出力は他の顧客やモデル提供者（OpenAIなど）に提供されない、という前提も明記されています。
つまり、「他テナントがあなたの入出力を参照できる」「あなたの入出力が別テナントの回答として混入する」といった“横流し型の事故”を許容する設計ではない、という整理になります。
アプリ側：マルチテナント実装ミスが最大の漏えい原因
一方で、あなたがSaaSや社内共通基盤としてAzure OpenAIを“共有”している場合、漏えいリスクはゼロではありません。理由は単純で、「共有リソースを使う＝あなたのアプリがテナント分離を実装しないといけない」からです。
Microsoftのアーキテクチャガイドでも、共有Azure OpenAIは実装が簡単な一方でデータ分離が弱く、モデルデプロイ単位のセキュリティ分離が提供されないこと、細かなアクセス制御はアプリ側で担う必要があること、ファインチューニングを共有で扱うのは避けるべき、といった注意が書かれています。
| 漏えいが起きる場所 | 典型的な事故パターン | 実務対策（効く順） |
|---|---|---|
| アプリの会話状態管理 | 別テナントのスレッドID/レスポンスIDを誤参照して会話履歴が混ざる | テナントIDをキーにしてIDを保存・参照（スコープ強制）、ID推測耐性、権限チェック |
| RAG（検索） | 検索インデックスが共有で、フィルタ漏れにより他テナントの文書が混入 | テナントフィルタを必須化、インデックス分割、アクセス制御の二重化 |
| ログ/監視 | APMやアプリログにプロンプトが丸ごと記録され、閲覧権限が広すぎる | PII除去ログ、最小権限、保管期間短縮、暗号化、監査証跡 |
| キャッシュ/キュー | 共有キャッシュのキー設計が甘く、別テナントが取得 | キーにテナントID必須、暗号化、TTL短縮、分離ストア |
| 共有Azure OpenAIリソース | 同一リソース内の複数デプロイを、アプリが誤って他テナントに開放 | 原則は専用リソース/専用デプロイ、やむを得ず共有ならアプリで到達制御 |
特にResponses APIのような“状態ありAPI”は、会話履歴をIDでつないでいくため、IDの保管・参照をテナントスコープで強制しないと混線事故が起きます。アーキテクチャガイドでも、レスポンスIDをテナント単位のキーで保存する、といった対策が推奨されています。
ログ保持（データ保持）と「30日」の正しい捉え方
データ保持は、Azure AI Foundry（Azure OpenAI）を安全に使ううえで最も揉めやすい論点です。ここも「何が」「どこに」「誰が」「どれくらい」残るかで分解すると、説明しやすくなります。
保存される可能性があるデータの種類
| データの種類 | 保存の主な発生源 | 保存場所の考え方 | 削除・抑制の方向性 |
|---|---|---|---|
| 会話履歴（状態） | Responses API / Assistants Threads / Stored completions 等 | 顧客テナント内のFoundryリソースに保存される整理 | 不要なら使わない、使うなら削除API・保持期間・アクセス制御 |
| アップロードデータ | Files / Vector store / ファインチューニング | 顧客テナント内に保存、暗号化（CMKオプション） | データ分類、最小化、CMK、削除手順の標準化 |
| 悪用監視用データ | abuse monitoring（パターン検知・レビュー） | 顧客リソースIDで論理分離されたデータストアに格納され得る | 要件次第で「modified abuse monitoring」を申請、設定確認 |
| アプリ/基盤ログ | アプリのログ、APM、SIEM、チケット、監視通知 | 自社が設計した場所に残る（＝最も漏えいしやすい） | PIIマスク、保存禁止、ロール分離、保管期限、暗号化 |
状態あり機能の保存は「自テナント内＋暗号化＋削除可能」という整理
公式ドキュメントでは、Responses APIやAssistantsのThreads、Stored completionsなどの“状態あり”機能で保存されるデータは、顧客テナント内のFoundryリソースに保存され、既定の暗号化（AES-256）に加えてカスタマー管理キー（CMK）を使える場合がある、そして顧客が削除できると説明されています（プレビュー機能は例外あり）。
Responses APIは既定で保持が発生し得る
例えばResponses APIのドキュメントでは、レスポンスデータが既定で一定期間保持され、削除APIで削除できる旨が記載されています。マルチターン会話やワークフローのための仕様なので、「会話履歴を残したくない」要件の場合は、採用時点で設計判断が必要です。
悪用監視（abuse monitoring）は「自社の要件」で扱いを決める
悪用監視は、サービスの責任ある利用を担保するための仕組みです。ドキュメントでは、危険・乱用が疑われるパターンが検知された場合、プロンプトや生成結果がサンプルとして選ばれ、自動レビュー（AI）や必要に応じて人手レビューが行われる、と説明されています。自動レビューに使われるデータは保存されない一方、人手レビュー用のデータストアは顧客リソースIDで論理分離され、アクセスは厳格な手順（SAWやJIT承認など）に制限される、という整理です。
機微情報を扱うなどの理由で「保存・人手レビューを避けたい」場合は、要件を満たす顧客向けにmodified abuse monitoring（悪用監視の変更）を申請できる仕組みが案内されています。ただし、監視を弱めると検知精度が下がるため、利用者側の統制（自社のガードレール、監査、インシデント対応）がより重要になります。
「30日保持」は“どのデータか”を明確にして説明する
データ保持期間は、機能・契約・運用（監視やトラブルシュート）で変わり得ます。実務では、「悪用監視や運用目的で最大30日程度保持される」という説明が参照されることが多い一方、公式ドキュメントは保持の仕組みや検証方法（ContentLogging）を中心に記述しています。社内説明では「最大30日」という数字だけを独り歩きさせず、“何の保持か（監視ログか、状態あり履歴か、アプリログか）”を必ずセットで提示してください。
悪用監視のログ保存が無効化されているかを確認する方法
申請が通った（＝悪用監視の保存が無効化された）場合、AzureポータルやAzure CLIでContentLoggingの値を確認する手段が案内されています。
Azureポータルで確認する手順（概要）
- 対象のFoundryリソース（Azure OpenAI）を開く
- Overview（概要）からJSONビューを表示する
- CapabilitiesにContentLoggingが表示され、値がfalseになっているか確認する（表示されない場合は既定のまま、という整理）
Azure CLIで確認する例
az cognitiveservices account show -n <resource_name> -g <resource_group>重要なのは「falseが出るのは“無効化されている場合だけ”」という点です。監査対応では、スクリーンショット＋CLI出力（必要なら監査証跡）をセットにしておくと説明が通りやすくなります。
PII（個人情報）を扱う場合の実務対策：結局、どこまで守ればよい？
SSN、生年月日（DOB）、住所、社員番号などを扱うときは、次の考え方が“現場で強い”です。
基本方針は「最小化」＋「マスク」＋「権限」
- 最小化：LLMに渡す前に、「そのPIIは本当に必要か」を削る。多くの業務は氏名の代わりに顧客IDで成立します。
- マスク/匿名化：必要な場合でも、可逆/不可逆を使い分けて送る。
- 権限：復号（再埋め込み）できる人・システムを限定する。LLMに再識別の鍵を渡さない。
PIIマスクの現実的パターン（例）
例えば、ユーザーが入力する文章にPIIが混ざるケースは多いです。以下のように“置換トークン”に変換してからAzure OpenAIに渡すと、リスクと機能要件のバランスが取りやすくなります。
| 入力例（マスク前） | Azure OpenAIへ送る形（マスク後） | 備考 |
|---|---|---|
| 山田太郎（1985/01/23）のSSNは123-45-6789です | [PERSON_1]（[DOB_1]）のSSNは[SSN_1]です | 対応表は別ストア（Key Vault等）で厳格管理 |
| 連絡先は[email protected]、電話は090-xxxx-xxxx | 連絡先は[EMAIL_1]、電話は[PHONE_1] | 出力側も再マスク（漏れ戻り防止） |
| 住所：東京都◯◯区◯◯、顧客番号A-12345 | 住所：[ADDRESS_1]、顧客番号[CID_1] | 顧客番号はハッシュ化でもよい |
PII検出はAzure AI Language（PII検出）を“前段”に置くと実装しやすい
PIIをマスクするにはルールベースでもできますが、運用を回すなら、AzureのPII検出（PII detection）を前段に置いて、名前・電話番号・メール・ID類などを検出して置換する設計が現実的です。PII検出はテキストからPII/PHIを検出して赤塗り（redact）できる機能として案内されています。
ただし、マスクすると「検索・照合・並べ替え」などの要件に影響が出ます。要件がある場合は、置換トークン＋別途メタデータ（正規化済み属性）を持つ設計（例：DOBは年齢帯だけ渡す、住所は都道府県レベルに丸める）にすると、業務要件とセキュリティ要件の両立がしやすくなります。
マスクだけでは不十分：プロンプト/出力の“二次利用”を止める
PII事故は「LLMに送った」よりも、「LLMの入出力がログやチケットに貼られて拡散した」で起きがちです。次のような運用をセットにすると、監査で強い対策になります。
- アプリログにプロンプト本文を残さない（残すならマスク済みのみ）
- サポート問い合わせのテンプレに「プロンプト貼り付け禁止」「貼るならマスク済み」を明記
- 監視通知（Slack/Teams等）に入出力を流さない
- デバッグ時のみ短期間・限定ロールで閲覧可能にする
「外に出さない」を強める：ネットワーク分離（Private Link）とアクセス制御
“OpenAI側に露出しない”に加えて、「ネットワーク的にも外に出さない」を求める場合、閉域化は効きます。Azure OpenAIはPrivate Endpoint（Private Link）を使った構成が案内されています。
Private Linkでの基本方針
- Azure OpenAIリソースのネットワーク設定で、パブリックアクセスを無効化し、Private Endpoint経由のみ許可する
- DNS（Private DNS Zone）を含めて名前解決を設計する
- RAGで使うAzure AI SearchやStorageも同様に閉域化し、信頼されたサービス/マネージドIDで接続する
Private Linkは、VNetとサービス間の通信をMicrosoftバックボーン上に閉じる仕組みとして説明されています。社内ポリシーで「インターネットを経由しない」要件がある場合、この説明が通りやすいです。
認証は“APIキーよりEntra ID”が説明しやすい
運用面の事故（キーの漏えい、開発者端末への平文保存）を避けるため、可能ならMicrosoft Entra ID（マネージドID）ベースの認証に寄せると、最小権限・棚卸し・失効がやりやすくなります。特にSaaS/共通基盤では、誰がどの権限で呼んでいるかを監査で説明できることが重要です。
データレジデンシと「処理される場所」：Global / DataZone の注意点
「日本リージョンに置けば、処理もすべて日本か？」という質問もよくあります。公式ドキュメントでは、標準のデプロイでは顧客指定のジオグラフィ内で処理される一方で、GlobalやDataZoneのデプロイタイプでは“処理される場所”が広がり得ることが説明されています。また、Global/DataZoneでも、保存されるデータ（アップロードデータや監視用データストアなど）は顧客が指定したジオグラフィに保存されるという整理が示されています。
データレジデンシ要件が強い場合は、「どのデプロイタイプを選んでいるか」を設計書に明記し、標準デプロイを基本にするのが無難です。
ケース別：安全性が上がるおすすめ構成パターン
Azure AI Foundry（Azure OpenAI）を“安全に使う”には、要件（機微度・法規・監査）に応じて分離レベルを変えるのが合理的です。
| ケース | 推奨構成 | 理由 | 最低限の運用ルール |
|---|---|---|---|
| 社内PoC / 一般情報 | 共有リソース（標準） | スピード優先、分離要件が軽い | プロンプトをログに残さない、利用規程を明文化 |
| 業務データ（社外秘） | 環境別にリソース分離（dev/stg/prod）、RAGはテナントフィルタ徹底 | 誤投入/誤参照のリスクを下げる | PIIマスク、権限最小化、保持期間、監査ログ |
| 高機密/規制データ（PII/PHI等） | テナント別リソース、Private Link、必要ならmodified abuse monitoring申請 | 説明責任・分離・閉域化を最大化 | ゼロトラスト前提、復号権限の分離、データ分類の強制 |
特にマルチテナントSaaSでは、共有Azure OpenAIが「実装は簡単だが分離が弱い」こと、デプロイ単位のアクセス制御はアプリ側で担う必要があることが明記されています。テナント要件が強い顧客がいる場合は、最初から“テナント別”または“デプロイ別”を選ぶ方が、後から作り直すより安く済みます。
よくある質問：似たプロンプトで似た回答が出た。これって漏えい？
結論から言うと、「似た回答が出た」だけでは漏えいの証拠になりません。LLMは一般的な質問に対して似た文体・似た構造で答えやすい（テンプレ的に回答する）ためです。
本当に確認すべきは次の観点です。
- その回答に自社固有の情報（社内コード、固有名詞、非公開の数字、メール文面など）が含まれているか
- 含まれている場合、その情報がアプリのRAG（検索）で混入していないか（フィルタ漏れ）
- 会話履歴やレスポンスIDが誤参照されていないか（マルチテナント実装）
- ログやデータセット（Stored completions等）を別用途に流用していないか
最終チェックリスト：監査・社内審査で通すために揃えるもの
| チェック項目 | 確認ポイント | 成果物の例 |
|---|---|---|
| 学習利用の整理 | プロンプト/出力が基盤モデル学習に使われない説明 | 社内向けFAQ、設計書の前提章 |
| 分離モデル | テナント別/環境別/共有のどれか、理由 | アーキ図、データフロー図 |
| 保存される機能の棚卸し | Responses/Assistants/Files/Vector store/Stored completionsを使うか | 機能一覧、保持期間表、削除手順 |
| 悪用監視の扱い | 既定のままか、申請しているか、ContentLoggingで検証可能か | CLI出力、申請記録、運用手順 |
| PII対策 | 前段での検出・マスク、復号権限、出力側再マスク | マスク仕様、対応表の保管設計、テスト証跡 |
| ネットワーク | Private Link、パブリックアクセス無効化、DNS設計 | ネットワーク構成図、設定手順 |
| ログ設計 | プロンプトを保存しない/保存するならマスク、権限と期限 | ログ設計書、DLPルール、権限棚卸し |
まとめ：不安を「設計に落とす」と、Azure AI Foundry（Azure OpenAI）は説明しやすくなる
Azure AI Foundry（Azure OpenAI）にデータを送るときの不安は、「学習利用」「テナント分離」「保持（ログ）」が混ざっていることが原因で大きく見えがちです。公式の前提（他顧客やモデル提供者に渡らない、基盤モデル学習に使わない、状態あり機能は自テナントに保存、悪用監視は条件付きで保存・レビューがあり得る）を押さえたうえで、PIIの最小化・マスク、アプリのマルチテナント分離、ログ設計、Private Linkといった実務対策を積み上げれば、監査でも運用でも破綻しにくい構成になります。
コメント