Azure OpenAI オプトアウト申請は必要？

Azure OpenAIのオプトアウトとは、モデルの学習を止める手続きではなく、不正使用監視のための保存と人によるレビューを変えてもらう申請になります。申請をしなくても、入力したプロンプトや返ってきた応答がモデルの学習に使われることはありません。ただ、フラグが付いた入力や出力はレビューの対象になることがあるため、機密性の高い使い方をする会社は、申請の対象条件を確かめたうえで決めましょう。Azure OpenAIそのものの基本は親記事のAzure OpenAIとはにまとめていますので、こちらでは不正使用監視の話だけに絞って読んでみてください。

Azure OpenAIのオプトアウトは何を変える申請か

Azure OpenAIのオプトアウトは、学習への利用を止める申請ではなく、不正使用監視の扱いを変えてもらう申請になります。Microsoftの今の公式ページでは、対象がAzure OpenAIだけではなく、「Azureで販売されるFoundry Models」という呼び方で説明されています。

不正使用監視の中身は、コンテンツの分類、不正なパターンの検出、レビューと決定、通知と対応の4つに分かれます。このうち分類のモデルは、利用者のプロンプトやモデルの応答の中から、有害な文章や画像を見つけ出す役目となります。

ここで混乱しやすいのが、オプトアウトという言葉です。ChatGPTの学習オプトアウトと同じものだと思って読むと、Azure OpenAIでも入力を学習に使わせないための手続きに見えてしまいます。実際には、Azure OpenAIでは最初からプロンプトや応答を学習に使わない扱いになっています。

申請で変わるのは、主に不正使用監視のための保存と、人によるレビューの2つです。社内で説明するときは、学習の話と監視の話を分けて伝えてみてください。この2つを分けるだけで、稟議を読む方にぐっと伝わりやすくなります。

※Microsoft公式のabuse monitoring・data privacy・limited accessの各ページ（英語版）を2026年10月3日に確認した内容です。保存日数など、現行の公式ページに書かれていない数字は本文に載せていません。

申請しない場合の保存範囲｜現行公式に日数の記載はない

申請をしない場合は、フラグが付いた入力や出力が、不正使用監視のレビュー対象になることがある、と考えておけば充分です。すべてのプロンプトを人が読むわけではなく、分類や不審なパターンの検出に引っかかったものが中心となります。

既定では、フラグが付いたプロンプトや応答は、AIモデルなどによる自動のレビューに回されることがあります。Microsoftの説明では、この自動レビューを受けたプロンプトや応答は不正使用監視の仕組みに保存されず、AIモデルやほかの仕組みの学習にも使われないことになっています。

一方で、自動レビューの確信度が基準に届かない込み入ったケースや、自動レビューが使えない場合には、人によるレビューが入ることがあります。レビューを担当するのは承認を受けたMicrosoftの従業員で、Secure Access Workstationsと呼ばれる端末から、チームマネージャーのJust-In-Time承認を得てアクセスする仕組みと説明されています。

欧州経済領域にデプロイした場合は、その地域にいる従業員がレビューを担当します。確認した公式ページには、OpenAIが人のレビューをするという記載はありません。社内で「誰が見られるのか」と聞かれたら、OpenAIではなく、承認されたMicrosoftの従業員とお答えするのが安全でしょう。

30日保持という日数は、2026年10月3日に確認した現行のMicrosoft公式ページには見当たりません。保存期間を社内資料に書く場合も、確かめられない数字は置かないようにしたいところです。社内資料には30日と言い切らず、現行の公式には保持日数の記載がないと書きましょう。

人によるレビューに回る分は、不正使用監視用のデータストアに保存されます。保存される場所も押さえておくと、説明がずっと楽になります。不正使用監視のデータストアを含め、保存されるデータは顧客が指定したgeography（地域）に置かれ、顧客のリソースごとに論理的に分けて管理されます。GlobalやDataZoneのデプロイを使う場合でも、不正使用監視用のデータは顧客が指定したgeographyに保存されるという説明になっています。

プロンプトや応答は学習に使われず、OpenAIにも渡らない

Azure OpenAIでまず押さえておきたい前提は、プロンプト、出力、埋め込み、学習データが、OpenAIやほかのプロバイダーからは使えない扱いになっていることです。Microsoftのdata privacyページでも、これらがプロバイダーのモデルやサービスの改善に使われることはなく、許可や指示がない限り基盤モデルの学習にも使われないと説明されています。

モデルは「ステートレス」という扱いになります。ステートレスとは、モデル自体が会話の中身を覚えて、次のお客様に使い回すような仕組みではない、という意味で読んでおけば充分でしょう。ただし、使っている機能の側で保存される履歴は別にありますので、この点は後ろの節で分けて見ていきます。

この前提があるため、「学習を止めるためにオプトアウトを申請する」という言い方は少しずれてしまいます。学習への利用が心配な方ほど、申請フォームの話に進む前に、最初から守られていることと、不正使用監視として残ることを分けて整理してみてください。

稟議では、学習に使われないことと、人のレビューが入りうることを、別の行に分けて書くと伝わりやすくなります。この2つが混ざってしまうと、申請すれば学習への利用が止まる、という誤解が残ったままとなってしまいます。

申請先と対象条件、審査期間の見方

申請先は、Microsoft Customer Voice上にある「Modified abuse monitoring」の登録フォームになります。MicrosoftのLimited Accessのページ、abuse monitoringのページ、data privacyのページのいずれからも、同じフォームへ案内されています。

申請できる相手は、原文に沿って言うと、Microsoftのアカウントチームが担当している顧客やパートナー、または対象となるプログラムの利用者に限られます。Microsoftのアカウントチームが付いていない会社は、規模にかかわらず対象から外れることがあります。条件に当てはまる場合でも、追加の要件があると書かれている点は覚えておきたいところです。

Limited Accessのページでは、Limited Access Serviceに指定されたモデルを使う場合と、Guardrailsやabuse monitoringの変更を申し込む場合に、登録フォームが必要になると説明されています。Guardrailsは、以前content filtersと呼ばれていたものと同じものになります。

審査にかかる日数は、現行の公式ページには書かれていません。社内資料にも「公式に記載なし」とだけ書いておきましょう。承認を待つ期限を決めるときは、プロジェクトの予定にゆとりを持たせておくと安心です。

申請の前に、Code of Conduct（行動規範）に沿った使い方を社内でどう守るのかを用意しておくと、社内への説明にもそのまま使えます。利用規約、社内ルール、ログの確認、教育、違反があったときの連絡先を並べ、実際に回せるものだけを書くようにしてください。

一部の高度なモデルでは、不正使用監視をオフにするための基準がより厳しくなる場合があります。ただ、どのモデルが当てはまるかの一覧は確認した公式ページに出ていませんので、モデル名を推測で並べず、使う予定のリソースとモデルを申請のときに確かめてみてください。

稟議前に決める｜申請する会社と申請しない会社

申請するかどうかは、Azure OpenAIに入れる情報の種類と、Microsoftの担当者がレビューする可能性を会社として受け入れられるかどうかで決めることになります。対象条件に入るかどうかだけでなく、承認されたあとの運用まで含めて考えてみましょう。

個人情報、取引先の未公開の情報、社内の開発情報、法務や人事の相談文などをAzure OpenAIに入れる予定がある会社は、申請する意味が大きくなります。特に、入力前に伏せ字にするだけでは仕事が回らない場合は、不正使用監視の変更を申請してみるのがよいでしょう。

反対に、公開されている情報の要約や、ふつうの文章の下書き、社外秘を含まない社内FAQの草案などが中心であれば、申請しないという選び方もあります。その場合でも、入力してよい情報と入れてはいけない情報、フラグの通知が来たときの担当者は決めておくと安心です。

承認されなかったときの代わりの手まで決めてから申請すると、稟議が止まりにくくなります。代わりの手といっても、難しく考えなくて構いません。個人情報は入れない、固有名詞は伏せる、添付する前に該当する箇所を削る、人のレビューがありうる前提で使う範囲を絞る、といった現実的なところで決めておけば充分でしょう。

• 申請する寄り機密性の高い情報を扱っていて、対象条件にも入りそうで、人によるレビューを避ける理由を説明しなければならない場合になります。
• 申請しない寄り公開情報やリスクの低い文章が中心で、入力のルールと伏せ字で運用できる場合です。
• 保留する寄り使うモデルや機能がまだ決まっておらず、プレビュー機能や高度なモデルの扱いも確かめていない場合となります。
• 先に整えるもの利用規約、社内ガイドライン、ログを確認する担当者、Microsoftからの通知を受ける窓口です。

中小規模の会社では、申請書を書く手間や承認を待つ時間も、会社にとっては出費になります。担当の方が調査から稟議、設定の確認、社内への説明まで抱えることになれば、その間に手が回らなくなる仕事も出てきてしまいます。月額の費用だけでなく、誰の何時間を使うのかまで書き出してみてください。

承認後はContentLoggingで確認する

承認されたあとは、Azure portalかAzure CLIで、ContentLoggingの表示を確かめます。申請を出して終わりにせず、設定の値まで見届けたところで、ひと区切りと考えるのがよいでしょう。

ポータルで見る場合は、FoundryリソースのOverviewを開いて、JSON viewへ進みます。Capabilitiesの中に、nameがContentLogging、valueがfalseという項目があれば、不正使用監視のためのデータ保存がオフになっていると確かめることが出来ます。

ここでよくある失敗が、ContentLoggingという項目が見つからないのを「承認済み」と受け取ってしまうことです。Microsoftの説明では、ContentLoggingのfalseは、不正使用監視のデータ保存がオフのときにだけ表示されます。オフになっていなければ、その項目そのものが出てきません。

ContentLoggingが見当たらない状態は、falseとはまったく別のものになります。画面のスクリーンショットを稟議に添付するなら、falseが表示された画面を残すと決めておきましょう。

CLIで確かめる場合は、az cognitiveservices account showにリソース名とリソースグループ名を付けて実行します。出力されたCapabilitiesに、ContentLoggingのfalseがあるかどうかを見てください。エンジニアではない方が確かめるのであれば、ポータルのJSON viewを手順書にしておくほうが迷いにくいでしょう。

az cognitiveservices account show -n resource_name -g resource_group

確認の結果は、申請日、承認の連絡を受けた日、見たリソース名、ContentLoggingの表示、確認した担当者の名前を記録しておくと、あとから説明がしやすくなります。リソースを複数持っている会社は、リソースごとに見てみてください。

承認後も自動のAIレビューと通知対応は残る

承認されると、不正使用監視のところで説明したデータの保存と人によるレビューは行われなくなります。ただし、自動のAIレビューまでなくなるわけではありません。

Microsoftのdata privacyページでは、承認されたあとも、プロンプトや応答が送られた時点や生成された時点で、AIモデルを含むアルゴリズムによる自動レビューが行われる場合があると説明されています。ここを見落としてしまうと、申請が通れば監視がすべてなくなる、という社内説明になってしまいます。

重大な不正や、繰り返しの不正が見つかった場合には、アクセスを制限されることがあります。人のレビューを有効にするよう求められることもある、と考えておいてください。承認後の運用で大切なのは、通知を放っておかない窓口を決めておくことです。

変更したあとは人のレビューがない分、不正を見つける精度が下がるおそれがある、という注意書きも出ています。サービスが止まるのを避けるためにも、Microsoftからの連絡を誰が受け取り、何営業日以内に返すのかを決めておきましょう。

社内ルールには、禁止する使い方も書き入れてください。マルウェアづくり、攻撃手順の生成、なりすまし、権利の侵害につながる依頼など、Code of Conductに反する使い方はしない、という前提をはっきり書いておきます。承認は何でも自由に使ってよいという許可ではなく、利用を管理する責任は引き続き会社の側に残ることになります。

Responses APIなどの保存データは別枠で考える

不正使用監視の変更は、Azure OpenAIで保存されるデータをすべて消す話ではありません。Responses APIなど、機能として保存されるデータは別の枠で確かめる必要があります。

Microsoftのdata privacyページでは、顧客のFoundryリソースの中に保存されるデータとして、ファインチューニング（追加学習）のデータとモデル、Batch、Responses APIのメッセージ履歴、Assistants APIのThreads、Stored completionsが挙げられています。このうちAssistants APIとStored completionsは、プレビューの扱いとなります。

これらのデータは同じgeographyに保存され、既定でAES-256という方式で暗号化されていて、顧客が管理する鍵を使うことも出来ます。顧客がいつでも削除できるデータとしても示されています。ただ、不正使用監視の変更がこれらの保存データにまで及ぶとは、確認した公式ページには書かれていません。

オプトアウトが承認されたあとも、使う機能ごとの保存データは別に洗い出しておきましょう。会話履歴を残す作りにしているのか、Batchを使うのか、ファインチューニングを使うのかによって、確かめる場所が変わってきます。

プレビューの機能は、条件を満たさない場合があるという注意も付いています。新しい機能を使うときほど、申請で認められた範囲とデータ保存の説明を分けて読むようにしてください。承認のメールだけを根拠にして、Responses APIなどの保存データまで消えると説明するのは避けたいところです。

社内説明文とよくある質問

社内向けには、長い公式の説明をそのまま貼るより、学習、保存、人のレビュー、自動レビュー、機能ごとの保存データの5つに分けて話すほうが通りやすくなります。次の文章を下書きにして、自社の使い方に合わせて直してみてください。

Azure OpenAIでは、プロンプトや応答は既定でモデルの学習に使われず、OpenAIやほかのプロバイダーからも利用できない扱いになっています。一方で、不正使用監視のため、フラグが付いた入力や出力は自動レビューの対象になり、人によるレビューが入る場合もあります。Microsoftのアカウントチームが担当する顧客・パートナー、または対象プログラムの利用者であれば、Modified abuse monitoringの申請によって、不正使用監視のデータ保存と人によるレビューの変更を求めることが出来ます。承認後も自動レビューは残るため、通知の窓口と利用ルールを社内で決めておきます。

この説明文は、稟議書の冒頭にもそのまま使うことが出来ます。そのあとに、扱う情報、申請するリソース、承認後のContentLoggingの確認、通知の窓口、禁止する使い方の例を並べると、読む方も判断しやすくなります。

まとめ

Azure OpenAIのオプトアウトは、学習への利用を止める手続きではなく、不正使用監視のための保存と人のレビューを変えてもらう申請になります。申請しなくても、プロンプトや応答がOpenAIやほかのプロバイダーのモデル改善に使われることはありません。

申請しない場合は、フラグが付いた入力や出力がレビューの対象になりうる、という点を押さえておきましょう。現行の公式ページには、保存日数も審査にかかる日数も書かれていません。社内資料でも、確かめられない日数は言い切らずに、公式に記載がないと書いておくのが安心です。

申請できるのは、Microsoftのアカウントチームが担当する顧客やパートナー、または対象プログラムの利用者に限られます。承認されたら、ContentLoggingがfalseと表示されるかどうかを、リソースごとに確かめてみてください。

承認されても、自動のAIレビューや、重大な不正があったときのアクセス制限、通知への対応は残ります。Responses APIなど、機能として保存されるデータも別の枠になります。Azure OpenAIを安心して使うためには、申請そのものよりも、入力のルール、保存データの洗い出し、通知の窓口を会社の運用にきちんと落とし込んでいくことが大切です。