Azure OpenAIのオプトアウト申請：不正使用監視のログ保持を止める条件と手順

「Azure OpenAIはオプトアウトしないと入力が学習に使われる」という説明を社内で見かけたら、まず出典の版を確認してください。2026年8月16日時点のMicrosoft Learnでは、プロンプト・補完・埋め込み・トレーニングデータが基盤モデルの学習に使われないことは既定の扱いとして明記されており、申請の有無とは無関係です。

オプトアウト申請、正式名称でいう「変更された不正使用の監視」が止めるのは別のものです。不正使用の検出でMicrosoft側にプロンプトと補完が保存され、承認された従業員が人手で確認する経路のほうを止めます。本記事では、申請で何が止まり何が止まらないのか、誰が申請できるのか、承認されたことをどこで確かめるのかを一次情報から整理し、社内審査に出す根拠の書き方まで扱います。

まとめ：申請の可否を分けるのはアカウント区分と用途の説明

先に結論を置きます。以降の章は、この六点の根拠と手順です。

• 学習に使われないことと、保存されないことは別の話である。前者は既定、後者だけが申請の対象になります。
• 申請で止まるのは、人手レビューのための保存と、その人手レビュー自体である。AIモデルによる自動レビューは承認後も走ります。
• 申請できるのは、Microsoftアカウントチームまたは対象プログラムの下で管理されている顧客とパートナーに限られる。従量課金で契約しただけの状態では入口に立てません。
• 承認の確認はContentLoggingがfalseで表示されるかどうかで行う。承認前はプロパティ自体が出ないため、「無い＝オフ」と読み違えないよう注意します。
• 承認後は検知精度が下がる代わりに、通知への対応義務が実務的に重くなる。返答できない体制のまま申請すると、サービス中断のリスクを自分で上げることになります。
• 「保存は最大30日」という記述は、2026年8月16日時点の一次情報では確認できない。審査資料に日数を書くなら、参照した版と日付を併記する運用へ切り替えます。

オプトアウトの対象範囲：学習停止ではなく人手レビュー用の保存停止

用語の指す先を最初に固定します。ここを曖昧にしたまま申請の可否を論じると、社内の議論が「学習に使われるか」の水掛け論に戻ってしまいます。

既定で止まっている範囲と、申請で初めて止まる範囲の切り分け基準

Microsoft Learnのデータ・プライバシーのページ（ms.date 2026-05-18）は、プロンプト（入力）、補完（出力）、埋め込み、トレーニングデータについて、他の顧客に提供されないこと、OpenAIをはじめとするモデル提供元に渡らないこと、モデルやサービスの改善に使われないこと、許可や指示なしに生成AI基盤モデルの学習に使われないことを明記しています。同ページには「モデルはステートレスであり、プロンプトや補完はモデルに格納されない」との記述もあります。

つまり学習利用の停止は、申請で獲得する権利ではなく契約時点の既定です。申請で動かせるのは、不正使用の検出という別目的でのデータ保存と人手による閲覧だけになります。この二つを混同した資料が社内に出回っている場合、先に用語を分離しておくと審査が短くなります。Azure OpenAI Serviceの全体像とできることを押さえたうえで、データの扱いだけを切り出して議論する形が扱いやすい進め方です。

不正使用監視の四工程と、保存が発生する地点を正確に特定する方法

不正使用の監視は四つの部品で構成されます。コンテンツ分類、不正使用パターンのキャプチャ、レビューと決定、通知とアクションの順です。分類モデルが入力と出力の有害なテキストや画像を検出し、その信号がパターン検出に流れ、頻度・重大度・意図性からスコアが付きます。繰り返しの脱獄試行のような反復行為は高スコアになりやすいと明記されています。

保存が起きるのは三番目のレビュー工程、しかも人手レビューに回った分だけです。既定でも一次審査はLLMを含むAIモデルによる自動レビューで、この自動レビューを受けたプロンプトと補完は不正使用監視システムに保存されず、AIモデルなどの学習にも使われません。自動レビューが信頼度のしきい値を満たさない複雑な文脈や、自動レビューを使えない場合にだけ、人の目による判断が入ります。

保存先の論理分離とアクセス制御について公式資料で確認できる内容

人手レビュー用の保存先は不正使用監視データストアと呼ばれ、顧客リソース単位で論理分離されます。各リクエストに顧客のFoundryリソースのリソースIDが含まれるためです。データストアは地理的単位ごとに別々に置かれ、顧客のプロンプトと生成物は、そのFoundryリソースが展開されているAzureの地理的範囲の内側に保存されます。

閲覧できるのは、不正使用監視システムが既にフラグを立てたデータか、不正な使用パターンの一部と判定されたデータに限られます。アクセス経路も限定されており、承認されたMicrosoft従業員がリクエストIDによるポイントワイズクエリで、Secure Access Workstations（SAW）とチームマネージャーによるJust-In-Time承認を経て到達する形です。欧州経済領域に展開されたモデルでは、レビュー担当者も同領域内に配置されます。

「最大30日」という保存期間の記述が現行版で確認できない点の検証

日本語の解説記事の多くは「最大30日間保存される」と書いています。ところが2026年8月16日時点で日英両版のデータ・プライバシーのページと不正使用の監視のページを照合したところ、日数を伴う保存期間の記述は見つかりませんでした。英語版のms.dateは2026-05-18、変更ログの最終エントリは2025年10月3日で、そこには「Azureが販売するモデルへの拡張」「ガードレールと不正使用監視のセクション分離」が記録されています。

ここから導ける実務上の扱いは一つです。保存期間を社内資料に数字で書くなら、参照した文書名・版・確認日を必ず併記してください。過去版の数値を出典なしで転記した資料は、監査や顧客説明の場で最初に崩れます。

申請の資格条件：管理された顧客であることが前提になる仕組みと判断基準

申請フォームは公開されていますが、送れば通るものではありません。前提条件のほうが実質的な関門です。

制限付きアクセスの資格基準とアカウントチーム管理下という条件

制限付きアクセスのページ（ms.date 2023-11-03 / updated_at 2026-08-09）は、変更されたガードレール（旧コンテンツフィルター）と変更された不正使用の監視について、「現時点では、Microsoftアカウントチームまたは対象となるプログラムの下で管理されている顧客とパートナーのみが利用でき、追加の要件が適用される」と記述しています。裏を返せば、クレジットカードで従量課金を始めただけのサブスクリプションは、この入口の外側にあります。

申請を検討する段階で最初に確認すべきは、自社にMicrosoftのアカウント担当が付いているか、パートナー経由の管理下にあるかです。ここが無いなら、フォームの記入内容を練る前に、営業窓口またはパートナーとの契約形態の話から始めることになります。

フォームで説明を求められる用途・データ機微性・低減策の三点を整理する

不正使用の監視のページは、申請の背景として「機微性の高いデータや極秘データの処理を伴うユースケース」と、「Microsoftがプロンプトや補完を保存し人手によるレビューを実施することを許可したくない、またはその許可を与える権利がないと判断する場合」を挙げています。この二つが、そのまま説明すべき論点になります。

• どの業務で何のデータを入力するのか。診療情報、与信情報、契約書面のように、第三者提供の可否が契約や法令で縛られている種別を具体名で示します。
• なぜ保存の許可を与えられないのか。自社の意向ではなく、顧客との秘密保持契約や委託契約で再委託先への開示が制限されている、といった根拠の形にします。
• 有害な出力のリスクをどう抑えるのか。ガードレールの設定、入力側のフィルタ、社内利用に限定した公開範囲など、監視が薄くなる分を補う手当てを並べます。

三点目を書き落とした申請は通りにくくなります。Microsoft側から見れば、監視を弱める判断は自社のリスクを引き受ける行為だからです。なお、Azureが販売する一部の高度なモデルには、不正使用の監視をオフにするためのより厳しい基準が設定される場合があると明記されています。

ガードレール変更との混同を避けるための申請フォームの使い分け方

制限付きアクセスのページには申請フォームが二つ並んでいます。ひとつは変更されたガードレール（旧コンテンツフィルター）、もうひとつが変更された不正使用の監視です。前者は有害コンテンツのフィルターを部分的または完全に切るための申請で、本記事が扱うログ保持とは目的が異なります。

重大度のしきい値の設定だけなら、どの顧客でも申請なしで構成可能です。フィルターを丸ごと切る話と、保存を止める話を一つの稟議にまとめると、審査側は最も強い変更に合わせて判断します。そのため、分けて出すほうが通ります。

申請から反映確認までの手順：フォーム送信とContentLoggingの読み方

ここからは実装者が手を動かす部分です。承認の反映はリソースのプロパティに現れます。

申請前に固めるサブスクリプションIDとリソースの適用範囲を確定する

申請は、対象のAzureサブスクリプションを特定したうえで出します。設定の反映も承認されたサブスクリプション単位で確認する形になるため、事前に棚卸ししておく対象は次の順です。

1. 対象業務が動くサブスクリプションIDと、その課金・契約形態を確認する
2. そのサブスクリプション配下のFoundryリソース（Azure OpenAIリソース）と地理的範囲を一覧化する
3. 検証環境と本番環境を同一申請に含めるか、本番のみに絞るかを決める
4. 申請対象外のリソースで機微データを扱っていないか、入力経路を洗い出す

四番目を飛ばした結果、承認された本番リソースの隣で、検証用リソースに実データが流れ続けていた、という取りこぼしが起こります。申請の単位と実際のデータ経路が一致しているかを、承認前に突き合わせてください。

Azureポータルのビューでプロパティの有無から状態を読む手順

承認後の確認方法は二通り用意されています。ポータル側の手順は、対象のFoundryリソースの概要ページを開き、右上のJSONビューのリンクを選び、機能の一覧にContentLoggingの項目があるかを見る流れです。

読み方には癖があります。この属性は不正使用の監視のためのデータ保存がオフになっている場合にだけfalseという値で現れ、それ以外の状態ではプロパティ自体がポータルにもCLIの出力にも表示されません。つまり「見当たらない」は「オフになっている」ではなく、「まだオフになっていない」を意味します。承認メールを受け取った直後にここを確認する運用にしておくと、反映漏れをその場で捕まえられます。

Azure CLIで同じ状態を取得するコマンドと確認のタイミング

同じJSONはコマンドラインからも取得できます。リソース名とリソースグループを指定してaz cognitiveservices account showを実行すると、ポータルのJSONビューと同じ内容が返ります。複数リソースを抱えている環境では、こちらを回して一括で状態を集めるほうが確実です。

確認のタイミングは三つ設けます。承認通知の直後、対象リソースを新規作成した直後、そして定期棚卸しのときです。二番目を入れておく理由は、承認がサブスクリプション単位でも、その後に増えたリソースの状態を人手の記憶で管理すると必ずずれるからです。

承認後に残るもの：自動レビューと通知対応という運用コストの把握

申請を「守りを固める作業」とだけ捉えると、承認後に増える仕事を見落とします。

人手レビューが止まっても自動レビューは継続するという実像を理解する

データ・プライバシーのページは、変更された不正使用の監視が承認された顧客について、データストレージと人手レビューのプロセスが実行されないと明記する一方で、「必要に応じて、提供または生成された時点でプロンプトと補完をレビューするAIモデルを含むアルゴリズムを利用して、自動レビューを実行することもできる」と続けています。承認は監視の全面停止ではありません。

さらに、その自動レビューが重大または繰り返しの不正使用を示す内容を検出した場合、顧客はアクセスの制限を受ける可能性があり、将来の制限リスクを下げるために人手レビュー込みの監視を有効化することへの同意を求められる場合があると書かれています。承認は取り消しうる状態だという前提で運用設計してください。

検知精度の低下と通知への未対応が招くサービス中断を防ぐ体制設計

不正使用の監視のページには、監視が変更され人手レビューが実行されない場合、潜在的な不正使用の検出精度が下がる可能性があるという注記が付いています。そのうえで、顧客は通知に対応できるよう準備しておくべきだと明記されています。

通知はメールで届きます。重大または繰り返しの不正使用を除けば、通常は説明や是正の機会が与えられ、対処できない場合や重大・反復のケースではアクセスの中断や終了に至る、という段取りです。窓口を共有メールボックスに寄せ、一次受けと技術判断の担当を決め、想定される問い合わせに何日で返すかまで先に決めておく。ここまでが申請とセットの作業です。

申請を通すべき場面と、入力側の設計で回避すべき場面の線引き基準

条件を付けて言い切ります。申請に進むべきなのは、入力から機微情報を外せない業務、たとえば診療録や与信審査の記録そのものを推論に渡す構成で、かつ再委託先への開示が契約で禁じられている場合です。この条件では設計の工夫に逃げ道がなく、申請以外に解がありません。

逆に、申請を見送るべき場面もはっきりしています。第一に、入力を匿名化・仮名化しても業務が成立するケース。マスキング処理を前段に挟むほうが、承認待ちの期間も承認後の通知対応も発生せず、費用対効果で上回ります。第二に、社内の問い合わせ対応や議事録要約のように、そもそも高い機微性を持たないデータしか流れないケース。ここで申請を出しても、審査で示すべき機微性の根拠が書けません。第三に、通知に応答する体制を用意できない少人数の運用。検知精度が下がった状態で連絡に気づかない構成は、監視を残したときより不利になります。

社内審査で示す根拠：所在地・分離・アクセス制御の三点で申請資料を組む

情報システム部門や監査部門に出す資料は、申請の可否より前に必要になります。一次情報のどの記述を引くかを決めておくと作業が速くなります。

保存先の地理的範囲と論理分離を審査資料に落とし込む具体的な書き方

審査で必ず問われるのは、データがどこに置かれ、誰が見られるのかです。前述の記述をそのまま使えます。保存先は顧客のFoundryリソースが展開されている地理的範囲の内側であること、データストアは顧客リソース単位で論理分離されること、閲覧はフラグ付きデータに限られSAWとJIT承認を経ること。この三点を並べれば、申請前の状態でも説明が成立します。

暗号化についても記述があります。ステートフル機能などで保存されるデータは、既定でAES-256により保存時に暗号化され、カスタマーマネージドキーを使う選択肢もあると明記されています（一部のプレビュー機能は非対応）。プレビュー段階のモデルや機能は条件をすべて満たさない場合があるという注記も、資料の但し書きとして引いておくと後の説明が楽になります。

グローバルとデータゾーンで処理場所と保存場所が分かれる点の説明

審査で誤解が起きやすいのがデプロイの種類の扱いです。グローバル展開ではAzureが販売する当該モデルが展開されている任意の地理的範囲で処理が行われ、データゾーン展開では指定されたデータゾーン内で処理されます。ただし保存については、アップロードデータも、グローバルとデータゾーン向けに作られた不正使用監視データストアも、顧客が指定した地理的範囲に格納されると明記されています。

影響を受けるのは処理の場所だけで、Azureのデータ処理とコンプライアンスに関する約束は引き続き適用される、という構造です。国内保存を条件にしている社内規程なら、この区別を書き分けないと不要な差し戻しが起きます。展開の種類ごとの提供差は東日本リージョンで使えるモデルをデプロイの種類別に確認する記事で整理しています。

オプトアウト前提の構成を外部委託するときの分担と受け入れ条件

申請の実務は、契約形態の確認、用途とリスク低減策の文書化、承認後の状態確認と証跡化、通知対応の体制づくりに分かれます。このうち社内に残すべきなのは、契約形態の確認と通知の一次受けです。どちらも自社の窓口と権限がなければ動かせません。

外部に渡しやすいのは、リスク低減策の設計と実装、状態確認の自動化、審査資料のたたき台づくりです。委託先を選ぶ際は、成果物の受け入れ条件に「参照した一次情報の文書名・版・確認日が資料に記載されていること」を入れてください。制度と挙動が版ごとに動く領域で、出典の版が書かれていない資料は再検証できません。進め方の全体像はAzure OpenAI Service導入支援の五工程と外部委託の判断基準にまとめています。機微データを扱う構成の設計から社内審査の資料づくりまでを含めて相談したい場合は、生成AI導入支援で個別の要件に合わせて対応しています。

Azure OpenAIのオプトアウトに関するよくある質問と実務回答

申請の検討時に社内から出やすい質問を、一次情報の記述に沿って整理しました。いずれも2026年8月16日時点の内容です。

オプトアウトを申請すれば、入力データが学習に使われなくなりますか？

学習利用の停止は申請とは無関係で、既定の扱いです。Microsoft Learnのデータ・プライバシーのページは、プロンプト、補完、埋め込み、トレーニングデータが他の顧客に提供されず、モデル提供元にも渡らず、許可や指示なしに生成AI基盤モデルの学習に使われないと明記しています。申請で止まるのは、不正使用の検出を目的とした保存と人手レビューのほうです。用語が混ざったまま稟議に出すと、承認しても期待した効果が得られなかったという評価につながります。

オプトアウト申請は誰でも出せますか？

フォーム自体は公開されていますが、資格条件が設けられています。制限付きアクセスのページによると、変更された不正使用の監視は現時点でMicrosoftアカウントチームまたは対象プログラムの下で管理されている顧客とパートナーのみが利用でき、追加の要件も適用対象です。従量課金で契約しただけの状態では、まず担当窓口の有無から確認することになります。加えて、Azureが販売する一部の高度なモデルには、より厳しい基準が設定される場合があるとの明記もあります。

承認されたかどうかはどこで確認できますか？

対象のFoundryリソースのプロパティで確認します。Azureポータルの概要ページからJSONビューを開き、機能一覧にContentLoggingがfalseで表示されていれば、不正使用の監視のためのデータ保存がオフになっている状態です。Azure CLIのaz cognitiveservices account showでも同じJSONを取得できます。この属性はオフのときだけ現れ、それ以外では表示されないため、「項目が見つからない」ときは未反映と判断してください。

オプトアウトすると不正使用の監視は完全になくなりますか？

なくなりません。承認された顧客ではデータストレージと人手レビューのプロセスが実行されない一方、提供または生成された時点でプロンプトと補完を確認するAIモデルを含む自動レビューは実行されうると明記されています。この自動レビューが重大または繰り返しの不正使用を示す内容を検出した場合、アクセスの制限を受ける可能性があり、人手レビュー込みの監視を有効にすることへの同意を求められる場合もあります。承認は恒久的な免除ではないという理解で運用してください。

保存期間は最大30日と説明されることがありますが、現在も同じですか？

2026年8月16日時点で日英両版の一次情報を照合した限り、日数を伴う保存期間の記述は確認できませんでした。日本語の解説記事に見られる「最大30日」は、過去版の記述に由来する可能性があります。社内資料や顧客説明に日数を書く場合は、参照した文書名と版、確認日を併記する形に切り替えてください。数値そのものより、出典の版を追える状態にしておくほうが、後の監査や再確認で効いてきます。

関連記事

• Azure OpenAI Serviceとは？できること・料金・導入事例まで実務目線で解説：本記事の前提となるサービス全体像と、できることの範囲を確認できます。
• Azure OpenAIのリージョン選定：東日本で使えるモデルをデプロイの種類別に確認する：データ所在地の判断とセットで検討する、モデルと展開の種類の提供差を扱っています。
• Azure OpenAI Service導入支援の進め方｜五工程と外部委託の判断基準：社内審査を含む導入の全体工程と、内製と委託の分担を整理しています。
• オプトアウトとは何か？定義と基本的な概念を解説：マーケティング文脈を含む一般的な語義を確認したいときの参照先です。