OCI Generative AI の Guardrails を整理してみた

Posted at 2026-04-19

はじめに

OCI Generative AI で Guardrails が使えるようになって、
「危険な入力や出力をどう制御するか」を、モデル任せではなくアプリやプラットフォーム側で明示的に設計できるようになりました。

2026 年 2 月には、まず On-Demand 向け Guardrails が追加され、その後 Dedicated AI Cluster endpoint 向け Guardrails も利用できるようになっています。

ただ、実際に調べ始めると、ここが結構ややこしいです。

On-Demand と Dedicated Endpoint は何が違うのか
Block と Inform はどう使い分けるのか
どこまでがモデル自身の安全機能で、どこからが Guardrails なのか
PII は何語まで見られるのか

今回の記事では、Oracle の公式ドキュメントと手元の資料をベースに、
Guardrails for OCI Generative AI を実務目線で整理します。

先に結論

結論から言うと、OCI Generative AI の Guardrails は次のように理解するとかなり分かりやすいです。

On-Demand は「アプリ層主導」
- ApplyGuardrails を明示的に呼び出し、結果を見て 自分で ブロック・許可・マスクを決める方式です。
Dedicated Endpoint + Block は「プラットフォーム主導の強制ゲート」
- 違反を検知すると、エンドポイント側で即座に拒否します。
Dedicated Endpoint + Inform は「記録中心の監査モード」
- 推論は通しつつ、Guardrails の結果をメタデータとして返します。

個人的には、Guardrails を「安全機能」だけで見るより、
誰が最後に判断するのか で整理すると一気に理解しやすくなりました。

アプリが決めるなら On-Demand
OCI に強制的に止めてほしいなら Block
まず観測・監査したいなら Inform

Guardrails とは何か

Guardrails は、モデルが受け付ける入力と、モデルが生成する出力を管理するための安全・コンプライアンス制御です。
OCI Generative AI では、主に次の 3 つを扱います。

Content Moderation (CM)
Prompt Injection (PI)
Personally Identifiable Information (PII)

ここで大事なのは、
「事前学習済みモデルに Guardrails が最初から自動適用されるわけではない」 という点です。

OCI のすぐに使える事前学習済みモデルには基本的な出力フィルタリングがありますが、
今回の Guardrails レイヤーは別物です。
明示的に使う必要があります。

つまり、

On-Demand なら ApplyGuardrails を呼ぶ
Dedicated Endpoint なら endpoint 作成/更新時に設定する

という理解で OK です。

3 つの Guardrails は何を見ているのか

1. Content Moderation (CM)

Content Moderation は、入力と出力の両方に対して、
有害・不適切・ポリシー違反になりうる内容を検知するための仕組みです。

たとえば、次のような内容が対象になります。

ヘイトやハラスメント
性的コンテンツ
暴力
自傷行為
その他ポリシー上問題となる表現

OCI の Guardrails では、CM の結果として主に次の 2 つを返します。

OVERALL: 全体として危険/不適切か
BLOCKLIST: 事前定義された禁止語に一致したか

ここは「単なる NG ワード判定」だけではなく、
内容全体を見て危険性を判定する層 と理解しておくとよいです。

2. Prompt Injection (PI)

Prompt Injection は、
「以前の指示を無視して」「システムプロンプトを出して」「秘密を返して」のような、
モデルの挙動を不正に誘導しようとする入力を検知するための仕組みです。

しかも直接的な攻撃だけでなく、
アップロード文書や取得コンテキストに埋め込まれた間接的な指示 も対象になります。

RAG やツール利用を組み合わせる構成では、
個人的にはこの PI がかなり重要だと思っています。

3. Personally Identifiable Information (PII)

PII は、個人を特定できる情報を検知するための仕組みです。

たとえば次のようなタイプが対象です。

PERSON
EMAIL
TELEPHONE_NUMBER
そのほかの定義済み PII タイプ

返却結果には、
検出された文字列そのもの / ラベル / 位置 / 長さ / 信頼度スコア が含まれます。

このため、単に「危険でした」で終わるのではなく、
どこをマスクするか までアプリ側で制御しやすいのがポイントです。

ただし注意点もあります。
PII 検知は現時点では英語のみ対応 です。
CM と PI は日本語を含む多言語対応ですが、PII はここがかなり違います。

OCI ではどう使うのか

OCI での使い方は、実質的に次の 2 パターンです。

1. On-Demand: `ApplyGuardrails` を API として使う

On-Demand では、ApplyGuardrails を明示的に呼び出して使います。
対象は、商用リージョンで利用できる On-Demand の chat / text embedding モデルです。

この方式の強みは、
判定後のアクションをアプリ側で自由に決められること です。

たとえば次のような制御ができます。

入力が危険なら モデルを呼ばずに終了 する
PII が見つかったら その部分だけマスク する
軽度の違反なら 警告だけ返して継続 する
監査用に ログだけ残す

つまり、On-Demand はかなり柔軟です。

資料のフローで表現するなら、

まず入力に対して Guardrails をかける
安全ならモデルを実行する
必要なら出力にももう一度 Guardrails をかける
最後の返し方をアプリで決める

という形になります。

この構成だと、入力段階で止められれば 無駄な Token 消費を防げる のも大きいです。

2. Dedicated AI Cluster Endpoint: endpoint に Guardrails を組み込む

Dedicated AI Cluster 側では、endpoint 作成または更新時に Guardrails を設定できます。
こちらも商用リージョンの chat / text embedding endpoint が対象で、Console / API / SDK / CLI から利用できます。

ここは資料では「Block モード」「Inform モード」と整理されていましたが、
実際の設定画面/ドキュメントでは CM / PI / PII をそれぞれ Off / Block / Inform で設定 できます。

この方式の特徴は、
Guardrails が endpoint 側の実行フローに統合される ことです。

アプリ側で毎回明示的に ApplyGuardrails を呼ぶ必要はなく、
エンドポイント推論の一部としてリアルタイムに適用されます。

ただし、ここにも重要な注意点があります。

現時点の公式ドキュメントでは、Dedicated Endpoint の Guardrails は「事前学習済みモデル」と「カスタムモデル」が対象で、imported model では使用できません。

DAC 上でいろいろなモデルをホストできるのと、
Guardrails がそのすべてで使えることは同義ではないので、ここは見落としやすいポイントです。

Block と Inform はどう違うのか

ここが一番気になるところだと思います。

ざっくり言うと、こうです。

Block

Block は、違反が検知された時点で 強制的に止める 方式です。

入力で違反したら、モデルを呼ばずに終了
出力で違反したら、結果を返さずに拒否
返ってくるのは基本的にエラーで、詳細な違反情報はあまり見えない

公開チャットボットや外部公開 API のように、
とにかく危険なものを返したくない 場面に向いています。

また、入力で止められるケースでは、
不要な推論を走らせないぶんコスト面でも有利です。

Inform

Inform は、違反を検知しても 止めずに結果を返す 方式です。

推論は実行する
Guardrails の結果を応答に含める
後段で監査・可視化・表示制御に使える

たとえば、

社内向け PoC
本番導入前の観測
どの程度リスクが検知されるかの実測
フロント側でぼかし表示や警告表示をしたいケース

にはかなり相性が良いです。

一方で、違反があっても モデル自体は常に呼ばれる ので、
コスト最適化だけを見るなら Block より不利です。

どちらを選ぶべきか

迷ったら、個人的にはこう考えると整理しやすいです。

まず止めたい → Block
まず見たい / 測りたい → Inform
止めるだけでなく、業務ルールに応じて細かく加工したい → On-Demand

サンプル結果を見ていて面白かった点

資料のサンプル比較を見ていて、実務的に大事だと思ったポイントが 3 つありました。

1. 安全な問い合わせは普通に通る

たとえば通常の製品質問では、
On-Demand 側の結果は OVERALL: 0.0、BLOCKLIST: 0.0、promptInjection: 0.0 のように返り、
Dedicated 側でも普通の LLM 応答になります。

つまり、Guardrails は「何でも過剰に止める層」ではなく、
危険なものを選んで検知する層 として使えます。

2. PII / PI / 有害表現は、見え方がかなり違う

たとえば電話番号を含む入力では、On-Demand の結果として
PERSON や TELEPHONE_NUMBER が構造化データで返るため、
「どこを隠すか」を後段で処理しやすいです。

一方、Dedicated の Block では、
基本的には HTTP 400 系の拒否 になり、詳細をそのまま返す運用には向きません。

つまり、

構造化された検知結果が欲しい → On-Demand
とにかく止めたい → Block

という差がかなりはっきりしています。

3. モデル自身の安全応答と、Guardrails は別レイヤ

これが個人的には一番大事だと思いました。

サンプルを見ると、Guardrails 無効でも、モデル自身の安全機能で危険な依頼を拒否するケースがあります。

ただし、それは Guardrails の代わりにはなりません。
なぜなら、実務で欲しいのは単なる「拒否文」ではなく、

どの種類のリスクだったのか
アプリ側でどう扱うのか
監査ログに何を残すのか
どの条件でブロック / 許可 / マスクするのか

を 一貫して制御できること だからです。

この意味で、
モデルの安全性 と Guardrails による運用制御 は分けて考えた方が分かりやすいです。

導入時に気をつけたいポイント

1. PII は英語のみ

日本語で PII を強く見たいユースケースでは、
ここは最初に確認しておいた方がいいです。

CM / PI は日本語対応ですが、PII は別です。
ここを同じ感覚で期待するとズレます。

2. imported model では Guardrails が使えない

DAC 上で imported model を使っている場合、
「専用 AI クラスタだから Guardrails も付けられるだろう」と思いやすいのですが、
現行ドキュメントではそうなっていません。

事前学習済みモデル / カスタムモデル / imported model は、
Guardrails 可否まで含めて区別して見る必要があります。

3. ベンチマーク性能と本番性能は同じではない

公式ドキュメントでも、CM と PI は多言語ベンチマークで評価されている一方、
実際の性能はドメインやデータ分布、言語、運用パターンで変わりうると明記されています。

なので、導入時は

自社データで検証する
誤検知 / 取りこぼしを見る
Block をいきなり本番全開にしない
最初は Inform で観測する

といった進め方がかなり現実的です。

実務でのおすすめの考え方

最後に、実務での使い分けをかなりラフにまとめるとこうです。

パターン 1: 外部公開チャットボット

パターン 2: 社内向けアシスタント + 監査重視

パターン 3: ルールが細かい業務アプリ

まとめ

OCI Generative AI の Guardrails は、単なる「危険コンテンツ拒否機能」ではなく、
生成 AI を実運用に乗せるための制御レイヤ として見ると本質が分かりやすいです。

整理すると、ポイントは次の通りです。

Guardrails は CM / PI / PII の 3 本柱
On-Demand は アプリ側が最終判断 する方式
Dedicated Endpoint は プラットフォーム側に組み込む 方式
Block は 強制停止、Inform は 観測・監査向き
PII は英語のみ
imported model では Guardrails は使えない
実導入では、まず Inform で観測してから絞り込む進め方が現実的

個人的には、Guardrails の価値は「危険な内容を止めること」そのものより、
安全性の判断をモデル任せにせず、運用ポリシーとして外出しできること にあると感じました。

生成 AI を本番で使うほど、
この「どこで、誰が、どう止めるのか」は重要になります。
OCI Generative AI の Guardrails は、そこをきちんと設計するための土台としてかなり使いやすいと思います。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up