Azure AI Foundry の Agent（エージェント）を作ったのに、モデル デプロイでは見える「コンテンツ フィルター」がエージェント画面に見当たらず不安になることがあります。結論から言うと、エージェントの安全性は「ガードレール（RAIポリシー）/モデル デプロイ」側で統制する設計です。この記事では、設定場所の整理、複数ポリシーの使い分け、そしてプロンプト（Instructions）を大人数で安全に更新する運用までを具体的に解説します。
Agentにコンテンツ フィルターの設定欄がないのは「仕様」
Azure AI Foundry（Microsoft Foundry と表記されることもあります）のエージェントは、単体でモデルを持っているわけではなく、背後にあるモデル デプロイ（推論エンドポイント）を使って応答を生成します。Azure AI Agent Service のドキュメントでも、エージェントで処理される出力は「そのエージェントが利用するモデル デプロイに適用されたコンテンツ フィルター処理」に従ってフィルターされる、と説明されています。
Microsoft Q&A でも、エージェントの画面に個別のフィルター設定欄が見当たらない場合はデプロイ（エンドポイント）側に紐づけたコンテンツ フィルターが適用される、という整理が示されています。つまり、ポータルでエージェント作成画面にフィルター欄がないのは、誤動作ではなく設計思想に沿った挙動と考えてよいです。
| よくある混同 | 実態（どこで決まるか） | 結果として起きること |
|---|---|---|
| 「エージェントにフィルターを付ける」 | 基本はモデル デプロイ（またはガードレール）に紐づく | エージェント画面にフィルター設定欄がなくても不具合ではない |
| 「プロンプトを書けば安全になる」 | プロンプトは補助。強制力のある統制はガードレール/フィルター側 | 運用で変えたいのはプロンプト、変えたくないのは安全ポリシー…という分離が重要 |
| 「リージョン差は関係ない」 | Foundry は機能のリージョン展開が段階的 | 同じ手順でも、環境によってメニューや機能が見え方が違う場合がある |
Foundry (classic) と Foundry (new) で「見え方」が違う
「エージェントに設定欄がない」という悩みは、Foundry (classic) を使っていると起きやすいです。classic では、主にGuardrails + controls（コンテンツ フィルター）を作成→モデル デプロイに関連付けという流れで統制します。
一方で、Foundry (new) のドキュメントでは、ガードレール（Guardrails）を作成し、エージェントやモデルに割り当てる手順が整理されています。つまり「エージェントに直接フィルター設定を“編集する”」のではなく、用意したガードレールを“割り当てる”形で安全性を変える、という見せ方です。
どちらのUIでも押さえるべきポイントは同じで、安全性ポリシーはプロジェクト/リソース側で一元管理し、エージェントはそれを参照して動くという構造を理解すると迷いが減ります。
Azure AI Foundryのコンテンツ フィルタリング（ガードレール）の基礎
Foundry のコンテンツ フィルタリングは、入力（プロンプト）と出力（応答）を分類モデルで評価し、危険度（重大度）に応じてブロック/注釈付けする仕組みです。代表的なカテゴリは「暴力」「憎悪」「性的」「自傷」で、重大度は safe/low/medium/high の段階で扱われます。既定設定は、これら4カテゴリをmedium 以上でフィルターするバランス型が前提になっています。
また、攻撃的な入力（プロンプトインジェクション）を検出するPrompt Shieldsや、既存テキスト/公開コードと一致する出力の検出（Protected material）など、用途に応じた追加のコントロールもあります。Prompt Shields は、ユーザーの直接攻撃だけでなく、文書やメールなどの第三者コンテンツに紛れ込む間接攻撃も想定して設計されています。
言語面では、日本語を含む複数言語で学習・テストされている旨が明記されています（ただし、アプリ側での検証は必須です）。
注意点として、音声系モデル（例：Whisper）の入出力には、このコンテンツ フィルタリングが適用されないケースがあるため、対象モデル・API種別も含めて確認が必要です。
重大度しきい値（Low/Medium/High）の考え方
設定画面のスライダーは直感と逆に感じることがありますが、Microsoft Learn では「Low が最も厳密（low/medium/high をブロック）」という形で整理されています。運用チーム内で誤解が起きやすいので、ここは表にして共有するのがおすすめです。
| しきい値 | ブロック対象 | 向いている使い方 |
|---|---|---|
| Low | low / medium / high | 対外公開・未成年利用など、リスク許容度を最小化したい |
| Medium | medium / high | 一般的な業務利用（既定のバランス設定に寄せたい） |
| High | high のみ | 表現の自由度を高めたいが、明確な危険は抑止したい |
| No filters / Annotate only | 承認が必要 | 研究・評価など、注釈は欲しいがブロックは不要（ただし申請前提） |
安全性の制御をどう設計するか：多層ガードレール設計
「エージェント単位でフィルターを付けられない/付けづらい」状況でも、現場で事故を防ぐためには一発勝負の設定ではなく、役割を分けた多層構造（Defense in Depth）が効きます。コンテンツ フィルターは強力ですが、万能ではありません。ツール実行・データ参照・権限境界など、エージェント特有のリスクは別レイヤーで押さえるべきです。
| レイヤー | 目的 | 具体策（例） | 変更頻度の目安 |
|---|---|---|---|
| ガードレール/コンテンツ フィルター | 有害カテゴリ・攻撃入力の検知/ブロック | 重大度しきい値、Prompt Shields、ブロックリスト、PII/グラウンデッドネス等 | 低（安定運用） |
| モデル デプロイ | 統制の単位を固定し、影響範囲を明確化 | ポリシー別にデプロイを分ける、TPM制限で暴走を抑える | 低〜中 |
| AgentのInstructions | 役割・期待動作・ツール利用ルールの明文化 | 「何をしないか」を明確に、出力フォーマット、エスカレーション条件 | 中〜高（頻繁） |
| ツール/データ接続 | 誤実行・情報漏えいの防止 | 必要最小限のツールだけを付与、書き込み系は段階的に解禁 | 中 |
| アプリケーション層 | UI/業務ルールの最終防波堤 | 入力制限、監査ログ、レート制限、ヒューマンレビュー導線 | 中 |
Prompt Shieldsは「プロンプトインジェクション対策」として別枠で考える
LLMの運用では「禁止事項をプロンプトに書いたのに破られた」という相談が起きがちです。Prompt Shields は、ユーザーがシステム指示を無視させようとする直接攻撃や、文書中に混入する間接攻撃を検出することを目的とした仕組みとして整理されています。エージェントがファイル検索や外部ドキュメントを扱うほど、重要度が上がります。
実務で迷わない：コンテンツ フィルター/ガードレールの設定手順
Foundry (classic) の手順（コンテンツ フィルターを作成→デプロイに適用）
classic では、まずプロジェクトでコンテンツ フィルター（ガードレール）を作り、必要ならデプロイに紐づけます。概略は次の流れです。
- プロジェクトを開く → Guardrails + controls → Content filters → 「Create content filter」
- Input filters（ユーザープロンプト）と Output filters（モデル出力）で、重大度しきい値やオプションの検知を設定
- 作成時、または後から「Models + endpoints」でデプロイを編集し、作成したフィルターを関連付け
この方式だと、エージェントはそのデプロイを参照する限り、同じフィルターを継承します。エージェント側に設定欄がないのはこのためです。
Foundry (new) の手順（ガードレールを作成→エージェントへ割り当て）
new では「ガードレール」を作成して、エージェントやモデルに割り当てる流れが明確です。特に、エージェント側のPlayground画面に Guardrails セクションがあり、Manage から割り当て変更ができます。
- Build → Guardrails → Create Guardrail → コントロールを追加 → エージェント/モデルへ割り当て
- または Build → Agents → 対象エージェントを開く → Guardrails → Manage → Assign a new guardrail
割り当て変更は即時反映されると説明されています。チームで「安全性ポリシーを一括で入れ替える」運用が必要な場合、この流れの方が管理しやすいことがあります。
APIで“呼び出し単位”にガードレールを変える選択肢
アプリ側で Azure OpenAI の推論APIを直接叩く構成なら、リクエストヘッダーでガードレール（ポリシー）を指定して、デプロイ既定をその呼び出しだけ上書きする方法もあります（x-policy-id）。「同じデプロイを使いつつ、用途別にポリシーを切り替えたい」ケースで便利です。
ただし、画像入力（chat with images）ではリクエスト単位の指定ができない、といった制約もあるため、ユースケースに合わせて判断します。
「異なる安全ポリシー」を使い分けたい場合の設計パターン
組織でよくあるのは「本番は厳しめ、社内検証は緩め」「未成年向けは最大限厳しく、専門職向けは誤ブロックを減らしたい」などの要件です。エージェント単位で細かくポリシーを変えたい場合は、次のいずれかが現実的です。
| パターン | 向いている状況 | メリット | 注意点 |
|---|---|---|---|
| ポリシー別にデプロイを分ける | 確実に分離したい／監査で説明責任が重い | 影響範囲が明確。エージェントは参照先を変えるだけ | デプロイ数が増える（運用・コスト・クォータ管理が必要） |
| ガードレールをエージェントへ割り当て | Foundry (new) を使い、プロジェクト単位で一括運用したい | UIで切替しやすい。安全性の変更を中央で管理しやすい | テナント/環境によりUIや機能が段階展開の可能性 |
| 呼び出し単位でポリシー指定（x-policy-id） | アプリ側で複数用途が混在し、同一デプロイで切替したい | デプロイ増を抑えられる。APIで柔軟に切替可能 | 画像入力など一部シナリオで不可。実装側の責任が増える |
プロンプト（Instructions）を中央集約で更新するベストプラクティス
「プロンプトは頻繁に変えたいが、安全性ポリシーは安定運用したい」なら、プロンプト＝エージェント側、ガードレール＝デプロイ/ガードレール側という分離が効きます。Q&Aでも、エージェントはベースプロンプトを中央で管理・更新しやすい点がメリットとして言及されています。
更新方法は「手作業」と「自動化」を併用すると回る
| 方法 | 向いているチーム | 良い点 | 弱い点 |
|---|---|---|---|
| ポータルでInstructionsを編集 | 少人数／スピード重視 | 即時に反映でき、開発者に依頼しなくてよい | レビュー/差分/ロールバックが属人化しやすい |
| REST APIでエージェントを更新（Git運用） | 人数が多い／監査が必要 | PRレビュー→自動反映で統制が効く。履歴が残る | 初期のパイプライン整備が必要 |
| 環境（Dev/Stg/Prod）でエージェントを分ける | 本番品質が重要 | 安全に検証→段階リリースができる | エージェントやデプロイが増え、管理対象が増える |
API更新（Update Agent）で“中央集約”を仕組みにする
Foundry のREST APIには、既存エージェントの name/description/instructions を更新するためのエンドポイントが用意されています。Request Body に instructions を渡すことで、システム指示（ベースプロンプト）を差し替えられます。また、metadata として最大16個のキー/値を付与でき、キーは最大64文字、値は最大512文字といった制約が明記されています。
この metadata を活用し、たとえば「prompt_version」「git_commit」「approved_by」などを埋めると、ポータル編集よりもはるかに監査しやすくなります。プロンプトが“口頭の運用”から“変更管理された資産”に変わります。
Instructionsは強力だが「万能なガードレール」ではない
Foundry のベストプラクティス文書でも、instructions はモデルの振る舞いを助ける一方で、非決定的（nondeterministic）である点が明示されています。つまり、禁止事項を丁寧に書いても、確率的に逸脱が起こり得ます。安全性の“強制”はガードレール/フィルターで担保し、instructions は業務要件とツール運用の明文化に集中させるのが現実的です。
大人数で破綻しないInstructionsテンプレ（例）
更新頻度が高い環境ほど、書き方をテンプレ化すると品質が安定します。以下は「安全性ポリシーは外側で担保しつつ、エージェントの役割をブレさせない」ための骨格例です。
【役割】
- あなたは社内向けの業務アシスタント。目的は「業務手順の案内」と「社内ドキュメントの要約」。
【してよいこと】
* 依頼内容が業務範囲内なら、結論→根拠→手順の順で回答する。
* 参照した情報源（社内文書・検索結果）を区別して述べる。
【してはいけないこと】
* 個人情報や機密情報が含まれる可能性がある場合は、出力せず確認を促す。
* ツールで実行する前に、ユーザーに目的と影響を説明する。
【ツールの使い方】
* 検索系ツールは「必要なときだけ」。取得した情報は要点だけを引用し、過度に長文を貼らない。
* 書き込み系ツールは、必ずユーザーの明示承認を取ってから実行する。
【出力フォーマット】
* 可能なら箇条書きで。手順は短いステップに分解する。 ガバナンス設計：大人数運用で事故を防ぐコツ
「プロンプトだけ頻繁に更新したい」要求は正当ですが、権限と変更手順を決めずに人数だけ増やすと、内容が肥大化して破綻します。おすすめは、“編集できる人”と“承認して本番に反映できる人”を分けることです。
| 役割 | 主な権限 | 責任 | 実装のヒント |
|---|---|---|---|
| Prompt Editor | Dev/Stgエージェントのinstructions更新 | 内容の改善、業務要件の反映 | GitでPR運用すると衝突が減る |
| Prompt Approver | Prod反映（API実行/割り当て変更） | リスク評価、リリース判断 | metadataに承認者やチケット番号を残す |
| Safety Owner | ガードレール/フィルターの作成・変更 | 安全性ポリシーの定義と検証 | 変更頻度は最小化し、効果測定とセットで行う |
テストと評価を運用に組み込む
Microsoft Learn では、ガードレールの設定はレッドチームやストレステスト等で反復的に評価し、効果測定を繰り返すことが推奨されています。プロンプト更新が頻繁なほど、最低限の回帰テスト（禁止領域の質問、情報漏えいの誘導、ツール誤実行の誘導など）を自動化しておくと運用が安定します。
「一部リージョンだけ」と言われる理由：機能はリージョンで差が出る
Foundry は「すべての機能がすべてのリージョンで同時に提供されるとは限らない」ことが明記されており、機能のリージョン差は現実に起こります。最大の機能可用性を得るための推奨リージョン（例：East US 2 / Sweden Central など）にも触れられています。
また、Foundry Agent Service は「利用できるモデルやツールがリージョンで異なる」ことが表で示されており、たとえば特定リージョンでは file search ツールが利用できない、といった注意書きもあります。こうした差分が、現場で「このリージョンだと機能がない/見えない」という体験につながります。
結論として、コンテンツ フィルター（ガードレール）そのものの有無というよりも、Foundry/Agent Service/ツール群の提供状況がリージョンごとに揃っていないことが要因になりがちです。手順が見つからないときは、まず「自分のポータルが classic/new どちらか」「プロジェクト/リソース/デプロイがどのリージョンか」を確認すると切り分けが早くなります。
よくあるつまずきチェックリスト
- エージェントが参照しているデプロイが想定どおりか（同名デプロイの取り違えが多い）
- フィルター/ガードレールを「作っただけ」で、デプロイやエージェントに割り当てていない
- Output filter の設定で、ストリーミング時の挙動を期待しているのに、設定が追従していない
- 「Annotate only」など、ブロックではなく注釈モードになっている
- 画像入力シナリオで、呼び出し単位のポリシー指定が使えない制約に引っかかっている
- 音声系モデルなど、そもそもフィルタが適用されないAPI種別を使っている
まとめ
- エージェント出力は、モデル呼び出しに紐づいたガードレール（デプロイ既定、または割り当て/指定したポリシー）に従ってフィルターされる。
- Foundry (classic) では「フィルターを作ってデプロイに関連付け」が基本。Foundry (new) では「ガードレールを作ってエージェントへ割り当て」という見せ方がある。
- 安全性はガードレール/フィルターで一元管理し、プロンプト（Instructions）は業務要件とツール運用を中央集約で更新するのが現実的。
- ポリシーを複数使い分けるなら、デプロイ分割・ガードレール割り当て・呼び出し単位指定のいずれかで設計する。
- リージョン差は現実にあるため、機能が見えないときは classic/new とリージョンを切り分ける。
コメント