Azure AI Foundry で GPT‑4o‑mini の「エージェント」を作ったものの、モデル デプロイと違ってエージェント画面に「コンテンツ フィルター（ガードレール）」の設定が見当たらず困ることがあります。本記事では“なぜ見えないのか”を整理しつつ、いま確実に安全対策を効かせる方法と、エージェント側でのガードレール運用（プレビュー）まで、実務目線でまとめます。
結論：まずは「モデル デプロイメント」にコンテンツ フィルターを付けるのが正攻法
Azure AI Foundry のエージェント設定画面に、モデル デプロイメントのような「コンテンツ フィルターを紐付ける」項目が見当たらないケースは珍しくありません。Microsoft Q&A でも、少なくとも 2025 年 9 月時点では「コンテンツ フィルターはエージェントに直接適用できず、デプロイメント（エンドポイント）に設定し、エージェントはそれを継承する」という回答が示されています。
また Azure AI Agent Service 側の説明としても、エージェントが利用するモデル デプロイメントに適用されたコンテンツ フィルタリングに従って出力がフィルタされる、という記載があります。つまり「エージェント経由でも prompt / completion の両方にフィルターを効かせたい」なら、まずモデル デプロイメント側の設定が現実解です。
なぜ「エージェントに直接」付けられないように見えるのか
Azure AI Foundry のエージェントは、単体で LLM 推論を行うのではなく、必ず何らかの モデル デプロイメント（例：gpt‑4o‑mini のデプロイ） を呼び出して動作します。エージェントは「指示（Instructions）」「ツール（検索、関数呼び出し等）」「会話履歴の管理」などをまとめてくれる“実行ランタイム”で、推論エンドポイントそのものではありません。
そのため、従来の Foundry（classic）で用意されているコンテンツ フィルター（Content filters）は基本的に「デプロイメントに紐付く」設計になっています。ドキュメントでも、コンテンツ フィルター構成はリソース側で作成し、1 つ以上のデプロイメントに関連付けられる、と説明されています。
用語をいったん整理（混乱ポイント）
| 要素 | 役割 | 設定が効く範囲 | 現場での扱い |
|---|---|---|---|
| モデル デプロイメント | gpt‑4o‑mini などの推論エンドポイント | 入力（prompt）/出力（completion）をフィルタ可能 | まずここで安全設定を固める |
| エージェント | Instructions + ツール + 会話管理で“業務化”する枠 | 内部でデプロイメントを呼ぶ（＝デプロイ設定の影響を受ける） | 指示の更新をチームで一元化しやすい |
| コンテンツ フィルター | 危険/不適切コンテンツの検知・ブロック/注釈 | 主にデプロイメント単位（classic） | モデル側に付けてエージェントにも効かせる |
| Guardrails（新） | リスク検知、介入点、アクションをまとめた枠 | モデルとエージェントに割り当て可能（エージェントはプレビュー） | 環境によっては“エージェント単位”運用が可能 |
コンテンツ フィルターは「入力と出力の両方」に作用する（やりたいことに合致）
Azure AI Foundry のコンテンツ フィルタリングは、ユーザーが投げたプロンプト（入力）と、モデルが返す生成文（出力）の両方を分類モデルで評価し、カテゴリと深刻度（Severity）に応じてブロックや注釈を行います。Foundry（classic）のドキュメントでも、暴力・ヘイト・性的・自傷の 4 カテゴリを複数の深刻度（safe/low/medium/high）で扱い、既定は「medium 以上をフィルタ」する構成になっていることが説明されています。
既定の挙動（まず押さえるべきポイント）
- 既定は、4 カテゴリ（暴力/ヘイト/性的/自傷）を medium 以上でブロック
- 入力（prompt）と出力（completion）それぞれに、しきい値を別々に持てる
- 完全な無効化（No filters / Annotate only など）は、承認が必要になる場合がある
設定方法（Foundry ポータル / classic）：デプロイメントにコンテンツ フィルターを関連付ける
手順A：コンテンツ フィルターを作成する（必要なら）
Foundry（classic）では、プロジェクトの左メニューから Guardrails + controls に入り、Content filters タブでフィルター構成を作成できます。入力フィルター（ユーザーの prompt）と出力フィルター（モデルの completion）をそれぞれ調整でき、Prompt Shield や保護された素材（protected material）などの項目も含めて設定します。
ポイントは「エージェントに付ける」のではなく、後述の通りこのフィルターを“デプロイメントに付ける”ところまでやり切ることです。
手順B：モデル デプロイメントにフィルターを適用する（ここが本丸）
作成した（または既存の）コンテンツ フィルターを、対象のデプロイメントに関連付けます。
- Foundry でプロジェクトを開く
- 左メニューの Models + endpoints を開く
- 対象のデプロイメント（例：gpt‑4o‑mini）を選び、Edit
- content filter を選択して保存
これで、そのデプロイメントを呼び出す経路（エージェント経由の会話も含む）に対して、同じフィルタリングが適用される設計になります。
「エージェント側の設定は変えなくていい」のか？
多くのケースでは不要です。エージェントは“どのモデル デプロイメントを使うか”を持っているので、デプロイメントにフィルターが付けば、その推論呼び出しに対してフィルターが走ります（＝入力/出力どちらも対象）。
エージェントごとにフィルターを変えたい場合の現実的な回避策
「エージェントAは厳しめ」「エージェントBは緩め」といった運用要件はよくあります。しかし Foundry（classic）の UI で “エージェントにコンテンツ フィルターを直接紐付ける” 形が見えない場合、最も堅い設計は 同じモデルでもデプロイメントを分ける ことです。
デプロイメント分割パターン（おすすめ）
| やり方 | メリット | デメリット | 向いているケース |
|---|---|---|---|
| デプロイメントを2つ作る（Strict / Standard） | エージェント単位で安全しきい値を変えられる | 運用対象（デプロイ）が増える | 部門別に安全基準が違う、外部公開と社内向けを分けたい |
| プロジェクト自体を分ける | 権限・ログ・接続先まで含めて分離できる | 環境が増える分、管理コストが上がる | 規制要件が異なる（社外/社内、子会社、国別など） |
| アプリ側で Azure AI Content Safety も併用 | ツール入出力や独自ルールまでカバーできる | 実装が必要（追加コスト） | エージェントが外部データ/外部APIを多用する |
チームが大きい場合は「エージェントの Instructions は一元化しつつ、安全設定はデプロイメントで管理」という分業がしやすく、実務的に事故りにくいです。
知っておきたい高度な話：リクエスト単位でポリシーを切り替える（x-policy-id）
Foundry（classic）のドキュメントには、デプロイメントに紐付けた設定とは別に、リクエスト ヘッダーで x-policy-id を指定して、その呼び出しだけ別のコンテンツ フィルター構成で上書きできる仕組みが説明されています。
ただしこの方法は、あなたのアプリが「モデル推論 API を直接叩く」場合に有効です。Foundry のエージェント（Agent Service）が内部でどのようにヘッダーを扱うかは構成によって異なり、少なくとも “ポータルで作ったエージェントの設定画面で x-policy-id を自由に差し込む” という用途には向きません。エージェントで確実に効かせるなら、基本は「デプロイメント側に適用」または次章の「Guardrails（新）」を検討するのが安全です。
【最新動向】Foundry（new）の Guardrails なら「エージェントに割り当て」が可能（ただしプレビュー）
2025 年後半の Microsoft Foundry（new）では、Guardrails（ガードレール） という枠組みで、モデルだけでなくエージェントにも安全・セキュリティ制御を適用できる流れが明確になっています。公式ドキュメントでは、エージェント向けの guardrails は preview と明記されています。
さらに、エージェントの場合は user input / output だけでなく、tool call（プレビュー） と tool response（プレビュー） といった介入点も扱える、という整理がされています。エージェントが外部ツールやデータソースを使うほど、この差は効いてきます。
重要：エージェントの Guardrail は「モデル側を上書き」する考え方
Guardrails の説明では、エージェントに割り当てた guardrail が、基盤モデル（デプロイメント）に割り当てられた guardrail を上書きする（override）という挙動が示されています。つまり将来的には「同じデプロイメントを使いながら、エージェントごとに基準を変える」といった運用もしやすくなります。
Foundry（new）での割り当て手順（UI）
Guardrails の作成と割り当ては、Foundry（new）の UI で以下の流れが案内されています。
- Build を開き、左メニューの Guardrails から Guardrail を作成
- リスク（例：Violence/Hate/Sexual/Self-harm など）、介入点、アクション（Annotate / Annotate and block など）を追加
- 作成手順の中で エージェントとモデルを選択して割り当て
また、既存のエージェントを開いて Guardrails セクションから “Manage” → “Assign a new guardrail” のように割り当てる導線も説明されています。ポータル上で「エージェント設定にコンテンツ フィルターが無い」と感じた場合でも、Foundry（new）側の UI では Guardrails という別メニューに集約されている可能性があります。
注意：適用対象の“エージェント種別”に制限がある
Guardrails の概要では、現時点でガードレールが適用できるのは「Foundry Agent Service で開発されたエージェント」であり、Foundry Control Plane に登録した別種のエージェントには適用されない、という注意書きがあります。画面や機能が見えないときは、ここが原因のこともあります。
「GA なの？リージョン限定？」に対する実務的な答え方
コンテンツ フィルター（デプロイメントに付けるやつ）は GA として使える範囲が広い
Foundry（classic）のドキュメントでは、コンテンツ フィルタリングの設定・適用手順が明確に案内されており、prompt/completion の両方をフィルタすること、既定値、調整方法が整理されています。加えて、フィルターの無効化には承認が必要、という形でガバナンスが前提になっています。
エージェントへの Guardrails 割り当ては preview（＝まずは検証前提）
一方、エージェントに対して“エージェント単位で”制御を当てる発想（Guardrails for agents）は preview と明記されています。運用で使うなら、(1) まずは非本番で十分に試験、(2) 期待する介入点（ツール入出力含む）が効くか確認、(3) 既存のデプロイメント側フィルターとの関係（上書き/継承）を理解、の順で進めるのが安全です。
リージョン差で「メニューが出ない」ことはあり得る
Microsoft Foundry は、機能のリージョン差があり得ることが公式に明記されています。特定の機能（Agents、Guardrails など）が表示されない場合は、「プロジェクトを作ったリージョン」「Foundry（classic/new）のどちらを使っているか」「テナントの機能解放状況」を疑うのが近道です。
また、Foundry Agent Service で利用できるモデルやツールにはリージョン差があり、gpt‑4o‑mini を含む対応状況がリージョン一覧で提示されています（例：japaneast など）。ツール（例：File Search）のようにリージョン限定の注意もあるため、運用前に “自分のリージョンで何が使えるか” を一度確認しておくと事故が減ります。
おすすめ運用：安全対策を「1枚の設定」に寄せず、多層で考える
コンテンツ フィルターは強力ですが、エージェントのリスクは「プロンプトと最終回答」だけではありません。例えば、外部ツールに送るクエリ、取得した文書に混入する間接プロンプト注入、PII の持ち出しなど、経路が増えます。
そこで実務では、次のように “守る層” を分けると設計が安定します。
- 最低限（必須）：モデル デプロイメントにコンテンツ フィルターを付ける（入力/出力）
- できれば：Foundry（new）の Guardrails でエージェント単位に要件を寄せる（プレビュー）
- 業務要件が強いなら：アプリ側でも検知（例：Azure AI Content Safety でツール入出力をチェック、独自ブロックリスト）
- 運用：ログ、評価（red teaming）、ポリシー変更の承認フローを整備
現場でよくあるハマりどころ（チェックリスト）
「エージェントでフィルターが効かない気がする」
- エージェントが参照している デプロイメント名 を再確認（別のデプロイを見ていた、が多い）
- デプロイメントの content filter が “選択済み” になっているか確認
- ストリーミング利用時の挙動や、出力が途中で切れるケースも想定してテスト
- Foundry（classic/new）を行き来して UI が違う状態になっていないか確認（New Foundry toggle）
「エージェント単位で変えたいのに UI が無い」
- Foundry（classic）前提なら、まずは デプロイメント分割 が最も確実
- Foundry（new）が使えるなら、Guardrails メニュー（プレビュー）を確認
- “Foundry Agent Service のエージェント” であること、権限、リージョン差を疑う
まとめ：いま確実にやるなら「デプロイ側」、将来見据えるなら「Guardrails」
エージェントにコンテンツ フィルター（ガードレール）を効かせたい場合、まず押さえるべきは「フィルターはモデル デプロイメントに紐付く」という前提です。Foundry（classic）ではその設計が色濃く、エージェント画面に“フィルターの UI”が無いのは仕様に沿った挙動です。
一方で Foundry（new）では、Guardrails としてエージェントにも割り当てられる方向に進んでおり、ただしエージェント向けは preview という位置付けです。現時点の最短距離は「デプロイメントにフィルターを適用して、エージェントはそれを使う」。そしてエージェント単位のきめ細かい制御が必要なら、(1) デプロイ分割、(2) Guardrails（プレビュー）の導入、(3) アプリ側の追加対策、の順で検討するのが失敗しにくいです。
コメント