Azure OpenAI は既定で、有害コンテンツを検知・ブロックする「コンテンツフィルター（近年は Guardrails と呼ばれることもあります）」が有効です。正当な業務用途でも誤検知で止まることがあり、「解除したい／ほぼオフにしたい」と感じる場面も少なくありません。ここでは、一般ユーザーが変更できる範囲と、完全制御に近づけるための申請先・手順を実務目線で整理します。
Azure OpenAI のコンテンツフィルター（Guardrails）とは
Azure OpenAI のコンテンツフィルターは、モデルへの入力（prompt）と、モデルからの出力（completion）の両方を分類モデルで判定し、一定のルールに当てはまる場合にブロックや注釈（アノテーション）を行う仕組みです。画像生成モデルを含むモデル群に対して動作し、音声モデル（例：Whisper）など一部は対象外とされています。
基本となる「有害カテゴリ」は、次の4カテゴリが中心です（いずれも safe / low / medium / high のように強度が段階化されています）。また、用途によっては prompt 攻撃（jailbreak）や PII（個人情報）、保護対象テキスト/コードなどの検出も関係します。
| カテゴリ（代表例） | 想定される判定対象 | 業務で誤検知しやすい例 |
|---|---|---|
| Hate / Fairness | 差別・攻撃的表現、特定属性への侮辱 | ヘイト表現を含む文書の監査、SNSモデレーション |
| Sexual | 性的表現、露骨な性行為、児童搾取など | 医療・保健の説明文、性教育資料の要約 |
| Violence | 暴力、武器、殺傷、テロ等 | セキュリティ事故報告（attack/kill/weapon などの語彙）、法務文書 |
| Self-Harm | 自傷、自殺、摂食障害など | メンタルヘルス相談の一次対応、相談記録の要約 |
| Prompt attacks（ユーザー/間接攻撃） | jailbreak など、モデルを規約外の動作へ誘導する入力 | RAGで取り込んだ文書に悪意ある指示が混入するケース |
| PII（個人情報） | 個人を特定し得る情報の検出・制限 | 問い合わせ対応の会話ログ、顧客名簿の取り扱い |
さらに、コンテンツフィルターとは別に、規約違反を示唆する利用を検知するための監視（abuse monitoring）も運用されています。フィルター調整だけでなく、用途・運用設計も含めて説明できることが申請の現実的なポイントになります。
結論：できること／できないこと（まずここを押さえる）
「解除したい」という相談で最初につまずきやすいのは、“自分で調整できる範囲”と“Microsoft 承認が必要な範囲”が明確に分かれている点です。
| やりたいこと | 一般の Azure OpenAI 利用者 | Microsoft 承認（Modified Content Filters/Guardrails） |
|---|---|---|
| カテゴリごとにブロック閾値（低/中/高）を調整したい | 可能（入力/出力別に設定） | もちろん可能 |
| “High のみブロック”など、より緩い設定に寄せたい | 可能（UI/ポリシーが許す範囲） | もちろん可能 |
| コンテンツフィルターを完全にオフ（No filters）にしたい | 不可 | 承認があれば可能 |
| ブロックせず注釈だけ返す（Annotate only）にしたい | 不可 | 承認があれば可能 |
つまり実務的には、次のどちらかのルートになります。
- ルートA（多くの人が現実的）：自分でできる範囲の調整（閾値の見直し、入力/出力の切り分け、運用での誤検知対策）
- ルートB（条件を満たす組織向け）：Microsoft の「Modified Content Filters / Modified Guardrails」承認を申請し、No filters / Annotate only などの強い制御を解放する
Low/Medium/High の意味を誤解しない（“低＝緩い” ではない）
現場で混乱しやすいのが、UIに出てくる「Low / Medium / High」です。これは多くの場合、“検知の厳しさ”というより「どの深刻度からブロックするか」を表します。つまり、Low までブロック＝最も厳しい、High のみブロック＝最も緩いという方向になります。
Microsoft Learn では、フィルター適用範囲が次のように整理されています（safe は注釈対象で、ブロックの対象ではなく、設定の対象にもならないと説明されています）。
| 設定（ブロック対象の深刻度） | 意味 | 一般ユーザーで選べるか |
|---|---|---|
| Low / Medium / High をブロック | 最も厳しい。低レベルでもブロックされる | 可能 |
| Medium / High をブロック | 標準に近い。low は許容し、medium 以上をブロック | 可能 |
| High のみブロック | 最も緩い。high のみブロックし、それ未満は許容 | 可能 |
| No filters | ブロックしない（承認が必要） | 不可（承認が必要） |
| Annotate only | ブロックせず注釈のみ返す（承認が必要） | 不可（承認が必要） |
「Low にすると緩くなるはず」と思って設定してしまうと、逆にブロックが増えてしまうことがあります。まずはこの方向性を揃えるだけで、トラブルシューティングがかなり楽になります。
自分でできる設定変更：Foundry ポータルでカスタムコンテンツフィルターを作る
コンテンツフィルターの設定は、Foundry ポータル上でリソース単位に作成し、デプロイメントに関連付ける形で運用します。入力（prompt）と出力（completion）で別々に強度を変えられるため、「ユーザー入力は厳しめ、出力は少し緩め」「入力は緩め（業務文書の取り込み用）、出力は厳しめ（生成物の外部公開対策）」のような設計も可能です。
Microsoft Learn に記載の、Foundry ポータル（classic）の代表的な手順は次の通りです。
| 手順 | 操作（Foundry ポータル） | 実務メモ |
|---|---|---|
| 入口 | Foundry portal に移動 | ポータルは新旧があり、ドキュメントが classic 前提のことがあります |
| 設定画面 | 左メニューで Guardrails & controls を選択 | 「コンテンツフィルター」が Guardrails 配下にまとまっています |
| 作成 | Content filters タブ → Create content filter | フィルターは“テンプレ”として作り、複数デプロイで使い回すのが運用しやすいです |
| 基本情報 | 名前を付ける | 「用途」「環境（prod/dev）」「緩和レベル」が分かる命名が便利です |
| 接続 | プロジェクトに紐づく Foundry Tools resource への Connection を選択 | 権限不足だと選べないことがあるので RBAC を確認 |
| 入力フィルター | Input filter を要件に合わせて設定 | モデルに届く前にブロックされるため、ログ取り・再試行設計が重要です |
| 出力フィルター | Output filter を要件に合わせて設定 | 生成後にブロックされるため、UI では“途中で途切れる”体験になりがちです |
| 関連付け | Connection 画面でモデルデプロイメントに関連付け | 関連付けは後から変更できる前提で、まずは検証環境で試すのが安全です |
ここまでが「一般ユーザーが自分でできる」範囲です。まずはHigh のみブロックなど最も緩い側へ寄せつつ、どのカテゴリで詰まっているかを可視化していくのが王道です。
“完全オフ”に近づけたいとき：Modified Content Filters（Modified Guardrails）の申請
コンテンツフィルターを部分的または完全にオフにしたい（No filters / Annotate only を使いたい）場合は、Microsoft の承認が必要です。Microsoft Learn では、承認された顧客のみがコンテンツフィルターをオフにできる旨と、申請フォーム（Limited Access Review: Modified Content Filters）が明記されています。
申請できるのはどんな組織か
大枠としては、「Microsoft のアカウントチームに管理されている顧客」または「対象プログラム下の顧客／パートナー」が中心です。加えて、Limited Access の仕組み自体が“managed customer”を前提にしていることも明記されています。
一方で、「自社が managed customer か分からない」ケースも多いと思います。この点について Microsoft Learn は、managed customer は Microsoft のアカウントチームと協業している顧客であり、登録フォームを提出すれば適格性を確認するとしつつ、managed customer になること自体のリクエストは受け付けられないとも説明しています。また、managed customer でない場合も同じフォームで申請でき、適格性プログラムの機会があれば連絡するとされています。
どこに申請するのか（フォーム）
申請先は、Microsoft が案内している Customer Voice のフォームです。
- Azure OpenAI Limited Access Review: Modified Content Filters（Modified Guardrails）申請フォーム
- Azure Government 向け：Request Modified Content Filtering
申請時は、個人メールではなく組織ドメインのメールアドレスを使うよう明記されています（個人メールは否認される）。
審査の流れ（期待値）
Limited Access の登録については、申請後にメールで審査結果の連絡があり、目安として5〜10営業日（長引く場合あり）と説明されています。Modified Content Filters も同じ枠組みの申請であるため、社内稟議やスケジュールにはこのリードタイムを織り込んでおくと安全です。
申請を“通す”ための実務チェックリスト（書類づくりのコツ）
フォームの設問は更新される可能性がありますが、審査で見られやすいのは「なぜ必要か」と「どう安全に運用するか」です。特に“完全オフ”は強い権限なので、目的の正当性とガバナンス（安全策）を具体的に書けるかが重要です。
| 観点 | 書くべきポイント | 具体例（例示） |
|---|---|---|
| 用途の正当性 | なぜフィルター緩和が必要か、誰が何のために使うか | 法務の訴訟資料要約、SOC のインシデント解析、医療相談の一次整理など |
| 取り扱うデータ | データ種別、機密度、保管・アクセス制御、ログの扱い | 社内限定の監査ログ、患者の匿名化済み記録、公開情報のみ等 |
| 出力の使われ方 | 生成結果が外部公開されるか、社内限定か | 社内ナレッジに限定、外部公開前に必ず人がレビュー等 |
| 安全策（技術） | 入力/出力の二段階チェック、UIでの警告、NG語のブロック | 外部公開する出力は別の安全チェックを必須化、PIIマスキング |
| 安全策（運用） | 利用者の権限、教育、監査、インシデント対応 | 利用者は部門限定、利用規約同意、監査ログ保持、定期レビュー |
| 最小権限 | “完全オフ”が本当に必要か、Annotate only で足りないか | まず Annotate only を希望（ブロックせず注釈で運用）など |
ポイントは、単に「邪魔だから外したい」ではなく、誤検知で困っている業務シナリオと、その業務を安全に回すための具体策をセットで提示することです。Microsoft 側も Code of Conduct を前提にしているため、社内のコンプライアンス体制や責任者の所在を明確にすると、レビューの会話が進みやすくなります。
一般利用者が「完全無効化」できないときの現実解（誤検知を減らす運用）
申請が通らない／そもそも対象外というケースでは、できる範囲で“業務に支障がないレベル”へ寄せる必要があります。ここでは「規約や安全の趣旨を守りながら、無駄なブロックを減らす」ための具体策を紹介します。
入力（prompt）と出力（completion）で強度を分ける
コンテンツフィルターは入力と出力で別設定にできます。たとえば、セキュリティ事故のレポート要約では、入力に「attack」「exploit」「kill」などの語彙が含まれやすく、入力側で止まると処理全体が失敗しがちです。以下のような設計にすると、現場の詰まりが減ります。
- 入力：必要最低限のブロック（業務文書を通すため、最も緩い側へ）
- 出力：外部公開しないなら緩めでもよいが、公開するなら中程度以上で守る
“用語”を業務向けに正規化してから投げる
回避目的の言い換えではなく、業務的に誤解のない言葉へ正規化する発想です。典型例は IT 用語の “kill” で、文脈によっては暴力カテゴリに寄りやすいことがあります。ログや手順書を機械的に処理する場合は、入力前に次のような置換を行うだけでも改善することがあります。
| 元の表現 | 正規化の例 | 狙い |
|---|---|---|
| kill process | terminate process / プロセスを終了 | IT 文脈へ寄せ、誤検知を減らす |
| attack | security incident / 不正アクセス | “暴力”ではなく“セキュリティ”の話と明確化 |
| weapon | tool / exploit tool / 攻撃ツール | 物理武器ではないことを示す |
重要なのは、危険な内容を生成させるための迂回ではなく、業務文脈を正確に伝えるための整形として運用することです。
ユーザー体験を設計して「止まったとき」に復帰できるようにする
フィルターが発火すると、入力側であれば HTTP 400 エラーになったり、出力側であれば finish_reason が content_filter になったりと、アプリ側で判定できます。止まること自体をゼロにするのが難しい場合は、止まったときにどう復帰させるかがプロダクト品質を左右します。
- 入力で止まったら：ユーザーに「どの種類の表現が問題か」を伝え、言い換えガイドを出す（ただし規約回避の誘導にならない範囲で）
- 出力で止まったら：部分出力や要約モードに切り替える、あるいは「安全な範囲で説明し直す」定型応答を用意する
- 監査・改善：どのカテゴリで止まったか、どの部門・画面で多いかをログで集計し、フィルター設定や前処理を調整する
実装面では、「コンテンツフィルターが動作しなかった」ケース（content_filter_results の error など）も想定し、例外処理とログを入れておくと原因究明が早くなります。
// 疑似コード：コンテンツフィルター検知の扱い
try {
res = call_model(prompt)
if (res.finish_reason == "content_filter") {
// 出力がフィルターで一部/全部ブロックされた
return safe_fallback_message()
}
return res.text
} catch (e) {
if (e.http_status == 400 && e.error_code contains "content_filter") {
// 入力がフィルターでブロックされた
return request_rephrase_message()
}
throw e
}よくある質問（現場で詰まりやすいポイント）
フィルターを「完全無効化」する設定が画面に出てきません
Microsoft Learn の説明では、No filters / Annotate only は承認された顧客のみが利用できる設定です。一般ユーザーの画面に出ないのは仕様です。
“マネージド顧客”かどうか分かりません
公式には、managed customer は Microsoft のアカウントチームと協業している顧客であり、フォーム提出後に適格性を確認するとされています。また、managed customer になるためのリクエストは受け付けられない一方、managed でない場合も申請自体はでき、適格性プログラムの機会があれば連絡するとされています。まずはフォーム申請と並行して、社内の購買ルート（EA/CSP など）や Microsoft 担当の有無を確認するのが現実的です。
コンテンツフィルターと abuse monitoring は同じですか？
別物です。コンテンツフィルターは入力/出力の内容をブロック・注釈する仕組みで、abuse monitoring は利用状況から規約違反の兆候を検知する運用です。いずれも「変更（modified）」には追加要件・申請が関わるため、社内の説明資料では分けて整理しておくと混乱が減ります。
まとめ：実務的な対応方針（最短ルート）
最後に、現場で迷わないための流れを整理します。
- まずは自社でできる範囲を最大限使う：入力/出力別・カテゴリ別に閾値を見直し、「High のみブロック」など緩い側へ寄せて誤検知を観察する
- 「No filters / Annotate only」が本当に必要かを切り分ける：止まる地点（入力か出力か）とカテゴリをログで特定し、正規化やUXで回避できないか検討する
- 必要なら申請に進む：Modified Content Filters（Modified Guardrails）申請フォームから、用途の正当性と安全策を具体的に記載して申請する（組織メールを使用）
- 承認後は運用を固める：No filters/Annotate only の影響範囲（デプロイ、ユーザー、公開有無）を限定し、監査ログとレビュー体制をセットで構築する
コメント