概要
https://qiita.com/haruty/items/1250324eba7861d8f186
詳細内容
## ギャルと学ぶContent filtering system #Azure
https://qiita.com/haruty/items/1250324eba7861d8f186
Azure OpenAIのContent Filterが「原宿」を住所情報として誤検知する実例に基づき、フィルタの内部構造とContent Safety Studioを用いた具体的なデバッグ手法を提示する。
**Content Type**: ⚙️ Tools
**Language**: ja
**Scores**: Signal:4/5 | Depth:3/5 | Unique:4/5 | Practical:5/5 | Anti-Hype:4/5
**Main Journal**: 81/100 | **Annex Potential**: 80/100 | **Overall**: 80/100
**Topics**: [[Azure OpenAI, Content Filter, 個人識別情報(PII), LLMセキュリティ, Content Safety Studio]]
Azure OpenAI Serviceを利用するエンジニアにとって、避けては通れない「Content filter（コンテンツフィルタ）」の挙動と対策を、実例ベースで解説した技術記事です。著者が開発した「原宿でAIとオケできるサービス」において、地名である「原宿」が住所情報（PII: 個人識別情報）として過敏に判定され、APIが400エラー（ResponsibleAIPolicyViolation）を返してAIがサビ前で無言になるという、具体的かつ切実なトラブル事例から始まります。
記事の核心は、Azure OpenAIのフィルタリングが単なるキーワードマッチングではなく、多層的なパイプラインで構成されている点にあります。入力フィルタと出力フィルタの2段階が存在し、ヘイト、性的表現、暴力、自傷行為といった基本カテゴリに加え、著作権保護（コード/テキスト）やPII、プロンプトインジェクション対策などが独立して機能しています。特に重要な指摘は、フィルタによってブロックされた際、APIはセキュリティ上の理由から「どの単語が原因か」を具体的に返さないという点です。これは攻撃者にフィルタの閾値を学習させないための意図的な設計ですが、開発者にとってはデバッグを「勘と経験」に頼らざるを得ない要因となっています。
この不透明な問題を解決する手段として、著者は「Content Safety Studio」の活用を詳説しています。このツールを用いることで、カテゴリごとの深刻度（Severity: Safe, Low, Medium, High）を可視化でき、なぜ自分のプロンプトやAIの応答が弾かれたのかを定量的に分析することが可能になります。
最終的な回避策として、(1)固有名詞をやわらかい表現に言い換えるプロンプトチューニング、(2)「これはフィクションである」といったガード文による文脈の補強、(3)リスクを承知の上で特定のフィルタ（PIIなど）をオフにする設定変更、の3点が提示されています。特にフィルタのオフについては、サービスの性質や代替のバリデーション実装、説明責任といった観点から慎重に判断すべき「最後の手段」であると強調されています。LLMを用いたプロダクト開発において、安全装置としてのフィルタをいかにUXを損なわずに制御するかという、極めて実践的な知見が詰まった内容です。