Azure OpenAIの警告で気づいた 「AIガードレール」の必要性と、軽量モデル「Jev」の可能性
この記事のポイント
「プラットフォーム側のFilter」では企業の説明責任を果たせない：Microsoftからの利用確認メールで気づいた、Content Filterとガードレールの本質的な違い。
モデル任せにできない「企業の安全基準」：未発表情報や自社独自の禁止トピックは汎用LLMには制御不能。AI Gateway＋Prompt判定層での共通化が不可欠。
軽量モデル「Jev」をPrompt判定層にする対策：生成AIにリクエストを渡す前に高速・低コストでリスク分類できるか？を検証
突然届いた、Microsoftからの「利用内容の説明要求」
Azure OpenAI（Azure AI Foundry）を使ってシステムを開発・検証していたときのことです。普通に業務利用しているつもりでしたが、入力内容や処理結果が何度か「Harmful Content」として検知されました。
しばらくすると、Microsoft側からメールで利用内容についての具体的な説明を求められました。
何のためにこのモデルを使っているのか？
なぜそのようなContentが発生したのか？
業務上必要な利用なのか？
今後どのように対策するのか？
もし十分な説明や改善ができず重大・継続的な問題と判断された場合、最悪のケースとしてサービス利用そのものが停止・終了されるリスクがあることを知りました（公式ドキュメントにも abuse monitoring によるアクセス停止措置について明記されています）。
このメールを受け取るまで、私は生成AIの安全対策をどこか「他人事」として捉えていました。
「クラウド側のContent Filterがあるから大丈夫」という大きな勘違い
当時の私の最大の誤解は、**「Microsoft側にContent Filterがあるから任せておけば安心」**と思い込んでいたことです。
たしかにFilterは機能しており、危険な入出力を止めてくれます。しかし、それは**「危険な事象がプラットフォーム側に記録された」**ことを意味します。
観点クラウド標準の Content Filter企業に必要な AI Guardrails役割プラットフォーム全体の利用規約・違反検知自社のセキュリティ基準・社内ルール適用防御対象一般的な有害コンテンツ（差別・暴力・自傷など）未発表の機密情報・自社独自の禁止トピック事故時の責任検知ログを記録し、ユーザーへ通知・監視「なぜ起きたか・どう防ぐか」を自社で説明
検知された結果として説明責任を求められるのは、プラットフォームではなく利用している企業側なのです。
ガードレールは結局、何をしている仕組みなのか？
ガードレールの仕組み自体は非常にシンプルです。生成AIへの入力（Prompt）や出力（Response）をチェックし、あらかじめ設定したルールに従って検知・Block・Mask・人間によるReviewなどにつなげる仕組みです。
モデル自体を賢くするのではなく、「ここから先には行かせない」という境界線をアプリ側に設けるアプローチと言えます。
主要クラウド3社のガードレール機能を比較すると、方向性が完全に一致していることが分かります。
クラウド提供元主な機能・サービス名特徴とカバー範囲MicrosoftFoundry Guardrails / Content Safety重大度（safe〜high）の判定、直接的/間接的なPrompt Shield（Jailbreak対策）AWSAmazon Bedrock GuardrailsDenied Topics（禁止トピック定義）、Sensitive Information Filters（PII・機密除去）GoogleGoogle Cloud Model Armor特定のLLMに依存しないREST API形式で、Prompt/Responseのリアルタイム検査
呼び方は異なっても、「有害コンテンツ」「攻撃的な入力」「機密情報」「アプリ固有の禁止トピック」を切り分けて制御するアプローチは共通しています。
ChatGPTに安全機能があるのに、なぜ外側で止める必要があるのか？
「ChatGPTやClaudeなどのモデル自体にも安全機能があるのに、なぜさらに外側（アプリ側）で止める必要があるのか？」
答えはシンプルで、「守りたいものが会社ごとに違うから」です。
例1：未発表の製品価格
「来期の製品Aの価格は12,800円に変更予定です」 という文章は、一般的なLLMにとっては何も危険ではありません。
しかし、発表前の情報であれば企業にとっては重大な機密漏洩です。
例2：投資アドバイスの制限
「A社とB社のどちらに投資すべき？」 という質問も、普通のAIサービスなら回答できます。
しかし、金融機関のアプリなら「個別の投資助言をさせない（Denied Topics）」という社内ルールが必要です。
つまり、モデルの安全基準と会社の安全基準はまったくの別物なのです。
入力側（Prompt）に潜む2大リスク
OWASP Top 10 for LLM Applications (2025) でも、上位2つが入力側のリスクで占められています。
順位リスク項目概要と企業への影響LLM01Prompt Injection意図的な悪意（Jailbreak）や、外部文書・RAG経由の間接的な攻撃（Indirect Prompt Injection）LLM02Sensitive Information DisclosurePII（個人情報）、資格情報（API KeyやPass）、未発表の企業機密の流出
特に恐ろしいのは間接的な攻撃（Indirect Prompt Injection）です。人間が一文字も入力していなくても、RAGやAgentが読み込んだ外部文書の中に潜む悪意ある命令によって、AIが誤作動してしまうリスクがあります。
有害コンテンツ制御の難しさ：「悪意がない業務利用」での検知
自分のケースで一番読み違えていたのは、「普通に業務をしているだけでも検知に引っかかる」という点でした。
医療、安全情報、事故報告、苦情対応、ニュース、法務文書などを扱う業務では、正当な文脈で過激な言葉や機密に近い表現が含まれることは日常茶飯事です。
厳しくしすぎる ➔ 正当な業務入力までBlockされ、社員が使えなくなる（False Positive）
緩くしすぎる ➔ 本当に危険な攻撃や機密漏洩を見過ごしてしまう（False Negative）
「単語が入っていたら一律Block」ではなく、文脈に応じた適切な「しきい値設計」を行うことが、ガードレール運用の一番の肝になります。
ガードレールの真価は「説明責任」と「ガバナンス」にある
万が一トラブルが起きたとき、「AIが勝手にやりました」では会社として社会的に通用しません。
上図のようにPrompt 判定層(INPUT GUARDRAIL)を置くアーキテクチャにしておくことで、以下のガバナンスが実現できます。
共通ルールの適用：裏側のモデルをAzure OpenAIから別のLLMへ変更しても、会社共通の安全基準を維持できる。
適切な振り分け：入力内容をチェックし、ALLOW（通過）/ REVIEW（人間確認）/ BLOCK（遮断）に振分ける。
説明責任の担保：「何を許可し、何をBlockしたか」のログを保持し、監査やプラットフォームへの説明に提示できる。
NISTの「Generative AI Profile」でも、AIリスクをGovern / Map / Measure / Manageというライフサイクル全体のガバナンスとして管理する重要性が示されています。
Prompt判定層を追加する対策：軽量モデル「Jev」の可能性
ここで最近発表したばかりの、TypeSafe AIの分類特化型軽量モデル「Jev」が使えるではないかと可能性を感じました。
Jevは長文を生成する汎用LLMではなく、あらかじめ定義されたカテゴリやルールに対して高速・低コストで判定（Score / Category）を返すモデルです。
重い生成AI（Azure OpenAIなど）にリクエストを送信する前に、JevをLLM Modelsへ送信する前に「判定層（Guardrail Filter）」として配置したらどうなるでしょうか？
[ User / Application ]
↓
[ AI Gateway ]
↓
[ Jev (高速リスク判定層) ] ──→ (ALLOW / REVIEW / BLOCK)
↓ (安全と判定されたリクエストのみ)
[ LLM (Azure OpenAI etc.) ]
もしJevによって以下のリスクを事前フィルタリングできれば、大きなメリットが生まれます。
判定カテゴリチェック内容Jevを前段に置くメリット攻撃入力検知Prompt Injection / Jailbreak汎用LLMに到達する前にミリ秒単位で遮断可能機密・PIIフィルタ住所・氏名・API Key・社内未発表情報外部LLMへの意図しない情報送信を前段で防止自社独自ルールアプリ固有の禁止トピック（Denied Topics）会社独自のプロンプトポリシーを高速・安価に一律適用
もし精度・レイテンシ・コストが実用レベルであれば、「重いLLMに頼らない、高速かつ柔軟なAIガードレール」という新しい選択肢になります。
レイテンシ・コストは現時点では軽くテストしたところ問題なさそうですが、ポイントはやはり精度ですね。適切なデータセットを作成してシルバウィークで検証して見ます。
ぜひ次回の検証編も楽しみにしていてください！
