TL

Cloud Service

Azure AI Content Safety

テキストや画像の有害コンテンツを検知し、生成 AI の入出力を保護するモデレーション API。自前で分類器を持たずに安全フィルターを組み込める。AWS の Bedrock Guardrails に近い位置づけ。

中級セキュリティ運用上の優秀性
最終更新: 2026-06-28公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.テキストと画像の有害カテゴリ(憎悪・性的・暴力・自傷)を重大度付きで判定し、しきい値でブロックできる。
  • 2.プロンプトインジェクション検知や根拠性(グラウンデッドネス)チェックなど、生成 AI 向けの保護機能を備える。
  • 3.AWS の Bedrock Guardrails や Amazon Rekognition のモデレーションに近い、コンテンツモデレーションのマネージドサービスである。

Azure AI Content Safety は、テキストや画像に含まれる有害なコンテンツを検知し、アプリケーションや生成 AI の入出力をモデレーションするためのマネージドサービスです。学習済みの分類モデルが API として提供されるため、自前で有害表現の検出器を構築・運用することなく、安全フィルターを組み込めます。AWS では Amazon Bedrock Guardrails や Rekognition のコンテンツモデレーションが近い役割を担います。

解決する課題

ユーザー投稿や生成 AI の出力に有害な表現が含まれていないかをチェックする処理は、自前で機械学習モデルを構築・運用しようとすると、データ整備・多言語対応・継続的な精度改善といった大きな負担を伴います。Azure AI Content Safety は、有害カテゴリの検出を学習済みモデルの API として提供し、こうしたモデレーションをアプリへ手軽に組み込めるようにします。

  • ユーザー投稿やチャットの 有害テキスト・画像を自動で検知してブロックしたい
  • 生成 AI への **プロンプトインジェクションや脱獄(ジェイルブレイク)**の試みを検知したい
  • 大規模言語モデルの回答が **与えた資料に根拠を持つか(ハルシネーションでないか)**を確認したい
  • モデレーション基盤を 自前で抱え込まずにマネージドで運用したい
  • 業務固有のルールに合わせ、独自カテゴリやブロックリストで判定を補強したい

主要概念と用語

  • Analyze Text / Analyze Image: テキストまたは画像を解析し、有害カテゴリごとの重大度(severity)を返す中核 API
  • 有害カテゴリ(Harm categories): 憎悪(Hate)・性的(Sexual)・暴力(Violence)・自傷(Self-harm)の4つを基本とする分類軸
  • 重大度(Severity level): 各カテゴリの有害度を段階的なスコアで返す指標。アプリ側でしきい値を決めてブロック判定する
  • プロンプトシールド(Prompt Shields): ユーザー入力やドキュメントに含まれるプロンプトインジェクション・脱獄の試みを検知する機能
  • グラウンデッドネス検出(Groundedness detection): LLM の出力が与えたソース文書に根拠づけられているかを判定し、ハルシネーションを抑制する機能
  • 保護対象素材の検出(Protected material detection): 既知の著作物やコードと一致するテキストを検出する機能
  • ブロックリスト(Blocklist): 業務固有の禁止語句を登録し、カテゴリ判定に上乗せして検出するカスタム機能
  • カスタムカテゴリ(Custom categories): 利用者が用意した例から独自の有害カテゴリを学習させる機能
  • Content Safety Studio: ブラウザ上でしきい値の調整やテスト、ブロックリスト管理を行える GUI ツール

仕様・制限・クォータ

  • テキストと画像の両方を解析でき、いずれもカテゴリごとに重大度を返す。ブロックの可否はアプリ側でしきい値を決める
  • REST API と各言語の SDK から利用でき、Azure AI services の1リソースとして払い出す
  • 1リクエストあたりのテキスト長・画像サイズに上限があり、長文は分割やチャンク化が必要になる
  • 多言語に対応するが、言語ごとに精度や対応状況が異なるため、対象言語のサポート状況を事前に確認する
  • プロンプトシールドやグラウンデッドネスなどの保護機能は基本の有害カテゴリ検出とは別の API として提供される
  • 重大度の段階数やレート上限はリージョン・機能で異なり更新されるため、固定値を前提にせず最新の公式ドキュメントで確認する
しきい値は固定で埋め込まない

重大度の段階やブロック判定のしきい値は、サービス更新や運用方針で見直しが入ります。コードにマジックナンバーを直書きせず、設定として外出しし、レビューしながら調整できるようにしてください。

内部の仕組み

利用者はテキストや画像を HTTPS の REST API(または SDK)でサービスに送信し、Microsoft が学習・運用する 学習済みの分類モデルが推論した結果を、カテゴリと重大度の構造化データとして受け取ります。モデルの学習・スケーリング・更新はすべてマネージド側が担うため、利用者はモデルの中身を意識せずに済みます。

  • 有害カテゴリ検出は、入力を複数カテゴリの分類モデルに通し、各カテゴリの重大度を返す。アプリはこの値としきい値を突き合わせて許可・ブロックを決める
  • プロンプトシールドは、ユーザー入力やドキュメントに紛れ込んだ指示の上書き・脱獄パターンを検知する専用のモデルで処理される
  • グラウンデッドネス検出は、LLM の出力と与えたソース文書を突き合わせ、根拠のない主張を検出する
  • ブロックリストは、登録した語句をカテゴリ判定に上乗せして適用するため、汎用モデルでは拾えない業務固有の禁止語をカバーできる
  • カスタムカテゴリは、利用者の例示データから独自カテゴリを学習し、専用の判定として呼び出せる
入力と出力の両方をかける

生成 AI では、ユーザー入力(プロンプト)とモデル出力(応答)の両方をモデレーションするのが定石です。入力側でプロンプトシールド、出力側で有害カテゴリ検出とグラウンデッドネス検出をかけることで、攻撃と不適切応答の両面を抑えられます。

設計パターン / ベストプラクティス

  • 入力・出力の二段モデレーションを基本とし、プロンプト側と応答側で別々のチェックを通す
  • しきい値は設定として外出しし、誤検知(フォールスポジティブ)と見逃しのバランスを運用で調整する
  • ブロックリストで業務固有の禁止語を補い、汎用モデルだけでは拾えない語をカバーする
  • 長文はチャンク分割して上限内に収め、必要ならカテゴリごとに集約して最終判定する
  • ブロック時のユーザー体験を設計し、再入力の案内や人手レビューへのエスカレーション経路を用意する
  • Azure OpenAI のコンテンツフィルターと役割を整理し、外部入力やドメイン固有の禁止語は Content Safety で補強する

運用・監視

  • Azure Monitor のメトリクスで呼び出し回数・遅延・エラー率・スロットリングを監視する
  • 診断設定でログを Log Analytics へ送り、ブロック率やカテゴリ別の傾向を長期に分析する
  • しきい値とブロックリストの調整サイクルを運用に組み込み、誤検知・見逃しの報告を定期的に反映する
  • **スロットリング(レート上限)**に備え、リトライとバックオフをクライアント側で実装する
  • ブロックされた事例を 人手レビューへ回す経路を整え、判定品質の継続的な改善に使う

コスト

課金は基本的に 解析したリクエスト数(テキストレコードや画像の処理量)に対する従量制で、機能や層によって単価が異なります。無料枠が用意される機能もあり、検証段階ではコストを抑えやすい一方、プロンプトシールドやグラウンデッドネスなどの保護機能は基本のカテゴリ検出とは別に課金観点が分かれる点に注意します。

観点有害カテゴリ検出保護機能(シールド等)
課金の中心解析したテキスト量・画像数の従量機能ごとに別の従量課金
主な用途投稿・応答の有害判定プロンプト攻撃や根拠性の検査
コスト最適化必要な入力だけ解析し重複を避ける対象を生成 AI 経路に絞って適用
多重チェックの課金に注意

入力と出力の両方を複数機能でチェックすると、機能ごとに処理量が課金されます。すべての入力に全機能をかけるのではなく、リスクの高い経路に絞って適用し、前処理で重複や明らかに安全な入力を除外することで無駄を抑えられます。具体的な単価・無料枠は変動するため、最新の料金ページで確認してください。

セキュリティ

  • Microsoft Entra ID 認証 + RBAC を基本とし、キー認証への過度な依存を避ける
  • リソースのキーは Key Vault で管理し、コードへのハードコードを避ける
  • プライベートエンドポイント / 仮想ネットワークで通信を閉域化できる
  • 解析対象に含まれる 機微情報の取り扱い範囲を最小化し、保存・ログ出力する内容を絞る
  • 保存データはサービス側で暗号化され、要件に応じて カスタマーマネージドキーにも対応する
  • データレジデンシー(処理リージョン)の要件を満たすリージョンを選ぶ

関連サービス・比較

Azure AI Content Safety は外部入力や任意のアプリ向けのモデレーションに使えるスタンドアロンのサービスです。一方、Azure OpenAI には同種のコンテンツフィルターが組み込まれており、役割の境界を整理すると選び分けやすくなります。

観点Azure AI Content SafetyAzure OpenAI のフィルター
位置づけ独立したモデレーション APIOpenAI モデルに組み込み
対象任意のテキスト・画像OpenAI の入出力が中心
カスタム性ブロックリスト・カスタムカテゴリ標準カテゴリ中心
主な用途投稿審査や外部入力の保護OpenAI 利用時の標準防御
権限付与Entra ID + RBACEntra ID + RBAC
役割を重ねて使う

Azure OpenAI を使う場合でも、外部から来るユーザー投稿の審査や、業務固有のブロックリスト、グラウンデッドネス検査が必要なら Content Safety を併用します。OpenAI 内蔵フィルターを基本防御、Content Safety を補強・拡張、と役割を重ねるのが実用的です。

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# Content Safety リソースを作成
az cognitiveservices account create \
  --resource-group demo-rg \
  --name demo-contentsafety-0628 \
  --kind ContentSafety \
  --sku S0 \
  --location japaneast \
  --yes

# エンドポイントとキーを確認(アプリから呼び出す際に使う)
az cognitiveservices account show \
  --resource-group demo-rg \
  --name demo-contentsafety-0628 \
  --query "properties.endpoint" -o tsv

az cognitiveservices account keys list \
  --resource-group demo-rg \
  --name demo-contentsafety-0628 \
  --query "key1" -o tsv

# 取得したエンドポイントとキーで、REST API からテキストを解析する例
# (ENDPOINT と KEY は上のコマンドの出力に置き換える)
curl -X POST "https://<ENDPOINT>/contentsafety/text:analyze?api-version=2024-09-01" \
  -H "Ocp-Apim-Subscription-Key: <KEY>" \
  -H "Content-Type: application/json" \
  -d '{
        "text": "ここに判定したいテキストを入れる",
        "categories": ["Hate", "SelfHarm", "Sexual", "Violence"]
      }'

Azure Service

Azure AI Content Safetyを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

AI / 機械学習

比較で見る軸

クラウド: Azure / カテゴリ: AI / 機械学習 / 難易度: intermediate

導入後に効く点

プロンプトインジェクション検知や根拠性(グラウンデッドネス)チェックなど、生成 AI 向けの保護機能を備える。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Azure
カテゴリ
AI / 機械学習
難易度
intermediate
関連資格
設計柱
security / operational

判断チェックリスト

  • 自社の用途が「AI / 機械学習 / security」に近いか確認する。
  • 強みである「テキストと画像の有害カテゴリ(憎悪・性的・暴力・自傷)を重大度付きで判定し、しきい値でブロックできる。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

AI / 機械学習securityoperational