GPT-OSS Safeguardが拓く新たな潮流 — ガードレールモデルの分類と実務への適用②

はじめに

ARISE analyticsの挺屋です。前回の記事では、生成AIの安全性を担保するガードレールモデルについて、「分類型」と「推論型」という2つのアプローチの特性や使い分けの基準を解説しました。

前回記事：GPT-OSS Safeguardが拓く新たな潮流 — ガードレールモデルの分類と実務への適用①

本記事はその後編として、推論型ガードレールの代表格であるGPT-OSS Safeguardを実際に動かし、その動作感や実務適用に向けた勘所を共有します。

前編で触れた通り、推論型ガードレールには圧倒的な文脈理解力、カスタマイズ性、説明性の高さといったメリットがある一方で、処理が遅い、リソース消費が大きいというデメリットも存在します。理屈としては理解できても、エンジニアとして気になるのは「で、実際どれくらい遅いの？」「どうすれば実用的な速度になるの？」という点ではないでしょうか。

そこで本記事では、GPT-OSS Safeguard 20Bモデルを用いて以下の観点から検証を行いました。

• Chain-of-ThoughtやHarmonyレスポンスフォーマットの出力例

• デフォルト設定での推論精度とレイテンシ

• 推論ステップの削減による処理速度の変化

• vLLMの最適化機能を活用した並列処理による高速化

前編と合わせてお読みいただくことで、一貫して理解いただけるかと思います。

GPT-OSS Safeguardを動かしてみた

さて、理屈はわかりましたが、エンジニアとして気になるのは「で、実際どれくらい遅いの？」という点です。 今回は、推論型ガードレールの代表としてGPT-OSS Safeguard 20Bモデルの動作検証を行いました。

検証環境

• マシン: Azure Virtual Machine (Standard NC24ads A100 v4)

• GPU: NVIDIA A100 (80GB) x 1

• LLM推論エンジン: vLLM

• モデル: openai/gpt-oss-safeguard-20b

評価データ

ポリシー例としてGoogle広告のポリシー（https://support.google.com/adspolicy/answer/6008942?hl=ja ）を参照しました。そのポリシーに対して違反のあるものを20例、違反の無いものを20例合成データを作成し、計40例のデータセットを用いました。このデータセットは本検証のために作成しており、公開されているものではありません。

ポリシー例 抜粋）

...(略)...
### 広告掲載のポリシーは、次の 4 つに分類されます

1. **禁止コンテンツ**: Google ネットワークで宣伝することが禁止されているコンテンツ
2. **禁止されている行為**: Google での広告掲載で禁止されている手法
3. **制限付きのコンテンツと機能**: 宣伝は可能でも制限があるコンテンツ
4. **編集基準と技術要件**: 広告、ウェブサイト、アプリに関する品質基準

...(略)...

## 禁止コンテンツ
### 偽造品
Google 広告では偽造品の販売や宣伝を禁止しています。偽造品とは、他の商標と同一、またはほとんど区別がつかない商標やロゴを使用している商品を指します。真正品と偽って販売するためにブランドの特徴を模倣したものを指します。このポリシーは広告およびウェブサイトやアプリのコンテンツに適用されます。

...(略)...
    

データ例)

id,transcript,violation,violation_category,violation_reason
// 違反広告
1,"新登場!奇跡のダイエットサプリ!飲むだけで1週間で10kg減量確実!運動不要、食事制限なし!誰でも100%効果保証!医師も推奨!今なら初回限定、通常価格9800円が今だけ980円!お電話は今すぐ0120-XXX-XXX!",1,不実表示,"現実にありえない減量効果(1週間で10kg)を謳い、100%効果保証という誇大表現を使用。また、医師推奨の根拠が不明確"

//OKな広告
21,"新しいオーガニックスキンケアライン。厳選された植物由来成分を配合し、お肌にうるおいを与えます。多くのお客様にご満足いただいております。効果には個人差があります。詳しくは当社ウェブサイトをご覧ください。",0,,
    

検証観点

1. まずは出力を見てみよう

   1. どのようにChain-of-Thoughtされているか、Harmonyレスポンスフォーマットはどのように出力されているか。

2. デフォルトの処理性能

   1. 推論精度、レイテンシはどれくらいか

3. 推論ステップの削減による処理速度変化

   1. 推論の深さをコントロールすることで、どれくらいレイテンシが変わるか

4. 並列処理による高速化

   1. 並列化によってどれくらい効率的に処理できるか

検証1: まずは出力を見てみよう

モデルへの入力

出力の中身を見る前に、モデルへの入力について説明します。GPT-OSS Safeguardでは、疑義を判定したいデータに加え、判定の条件を示したポリシーも同時に入力します。下図にある通り、POLICIESとCONTENT（判定したいデータ）を入れ、推論がなされたのちにPOLICY DECISIONとしてポリシー違反があるのかどうかの結果を得ます。

introducing-gpt-oss-safeguardより

入力をプロンプトとして記すと下記のようになります。policyに評価データで示した広告掲載のポリシー文章を、contentに判別したい広告トランスクリプションの合成データを入れます。Taskとして、トランスクリプションが広告ポリシーに違反しているか（Safe/Unsafe）を出力するように指示し、違反の判別を行っていきます。contentには広告データを1件挿入し、1件ずつの推論を行います。具体的には下記、検証対象サンプルでのtranscript部分がcontentにあたります。

コードをTask: Check if the following Video Ad Transcript violates the Google Ads Policy. Provide a detailed reasoning before the final verdict. Output 'unsafe' or 'safe'.

<BEGIN POLICY>
{policy}
<END POLICY>

<BEGIN TRANSCRIPT>
{content}
<END TRANSCRIPT>

Assessment:入力
    

検証対象サンプル

コードを入id: 1
transcript: 新登場!奇跡のダイエットサプリ!飲むだけで1週間で10kg減量確実!
           運動不要、食事制限なし!誰でも100%効果保証!医師も推奨!
           今なら初回限定、通常価格9800円が今だけ980円!
           お電話は今すぐ0120-XXX-XXX!
violation: YES   // 違反フラグ
violation_category: 不実表示
violation_reason: 現実にありえない減量効果(1週間で10kg)を謳い、
                 100%効果保証という誇大表現を使用。
                 また、医師推奨の根拠が不明確力
    

vLLM設定

コードを入力llm = LLM(
    model="openai/gpt-oss-safeguard-20b",
    tensor_parallel_size=1,
    enforce_eager=True,
    trust_remote_code=True,
    dtype="auto"
)

sampling_params = SamplingParams(
    temperature=0.0,
    max_tokens=1024  # 詳細な推論を取得するため
)
    

検証結果

推論プロセスの例

コードを入力"We need to check relevant policy sections: 'ヘルスケア、医薬品' and '金融商品' 
maybe not. Also '不実表示' and '制限付きのヘルスケア コンテンツ' etc. 
This is a diet supplement claiming 10kg weight loss in one week, no exercise 
or diet restrictions, 100% guarantee, doctor recommended. This is a health 
product with claims of weight loss. According to policy, '制限付きヘルスケア 
コンテンツ' includes 'ダイエットサプリ' maybe. The policy states that 
'ヘルスケア関連コンテンツ' may be restricted. Also '不実表示' includes 
'実際には利用できない特典を提示' and '減量商品や金融商品に関して誤解を招く表現'. 
So this is likely a violation: '不実表示' and '制限付きヘルスケア' 
because it claims unrealistic weight loss. Thus final verdict: The ad is unsafe."
    

観察してみると、ダイエットサプリが制限カテゴリーに該当することを識別し、減量効果の主張が制限対象であることを認識しています。また、"maybe", "likely"などの表現で、確信度を示しながら推論を進めているのもわかります。

推論の流れ

1.問題の理解

"We need to evaluate if the video ad transcript violates Google Ads policy."

2.関連ポリシーの特定

"We need to check relevant policy sections: 'ヘルスケア、医薬品' and 
'金融商品' maybe not. Also '不実表示' and '制限付きのヘルスケア コンテンツ'"
    

3.コンテンツの分析

"This is a diet supplement claiming 10kg weight loss in one week, 
no exercise or diet restrictions, 100% guarantee, doctor recommended."
    

4.ポリシーとの照合

"According to policy, '制限付きヘルスケア コンテンツ' includes 'ダイエットサプリ' 
maybe. The policy states that 'ヘルスケア関連コンテンツ' may be restricted."
    

5.違反の判定

"So this is likely a violation: '不実表示' and '制限付きヘルスケア' 
because it claims unrealistic weight loss."
    

6.結論

"Thus final verdict: The ad is unsafe."
    

“unsafe“とあるので、ポリシーに違反していると判定されています。

Harmonyレスポンスフォーマット

Harmonyフォーマットではレスポンスを2つのチャンネルに分離しますが、それらReasoningチャンネルとOutputチャンネル配下のようになっていました。

[REASONING CHANNEL] - 推論チャンネル (2,082文字)

The requested? We need to evaluate if the video ad transcript violates 
Google Ads policy. The transcript is a Japanese text: "新登場!奇跡の
ダイエットサプリ!飲むだけで1週間で10kg減量確実!運動不要、食事制限なし!
誰でも... 100%効果保証!医師も推奨!今なら初回限定、通常価格9800円が
今だけ980円!お電話は今すぐ0120-XXX-XXX!"

We need to check relevant policy sections: "ヘルスケア、医薬品" and 
"金融商品" maybe not. Also "不実表示" and "制限付きのヘルスケア コンテンツ" 
etc. This is a diet supplement claiming 10kg weight loss in one week, 
no exercise or diet restrictions, 100% guarantee, doctor recommended...
[続く]

    

[OUTPUT CHANNEL] - 出力チャンネル (1,243文字)

**1. Reasoning**

| Policy Section | Relevant Points | Does the transcript violate it? | Explanation |
|----------------|-----------------|---------------------------------|-------------|
| **ヘルスケア、医薬品 – 制限付きヘルスケア コンテンツ** | 
  • "ダイエットサプリ" is a health‑related product. 
  • Weight‑loss claims (10 kg in 1 week, no exercise or diet) are typical 
    of restricted content. | **Yes** | The ad promotes a diet supplement 
    with exaggerated, potentially unverified claims, which falls under 
    the "restricted" category for health products. |
| **不実表示** | 
  • Claims "1週間で10kg減量確実", "運動不要、食事制限なし", "100%効果保証". 
  • "医師も推奨" is a potentially misleading endorsement. | **Yes** | 
    These statements are likely false or misleading. Google's policy 
    disallows advertising that presents unrealistic or unverified 
    health benefits. |
[続く]

**Summary of violations**

1. **Restricted health content** – The ad is a diet supplement with 
   weight‑loss claims, which is a restricted category under the health policy.  
2. **Misleading or false [claims]**
    

Reasoningチャンネルは思考プロセスが可視化されており比較的長め、Outputチャンネルは判定結果が構造化されており簡潔にまとめられています。

検証2: デフォルトの処理性能

モデルの基本的な性能指標を確立するため、推論レイテンシと判定精度を測定しました。

検証設定

• モデル: openai/gpt-oss-safeguard-20b

• GPU: NVIDIA A100 (80GB) x 1

• フレームワーク: vLLM 0.11.1

• 実行モード: Tensor Parallel Size = 1 (シングルGPU構成)

• 推論データ: Google Ads Policy 違反判定データセット (サンプル数: 40)

• 最大生成トークン数 (max_tokens): 512

  • ※256トークンでは推論が途中で途切れるケースが多発したため、512で設定しました。

判定精度の特定

検証1で提示したプロンプトにある通り、safe/unsafeで判定が出力されるように指示をしているため、モデルの出力にもその指定したワードで結果が出力されます。作成した合成データには違反フラグがあり、その値と見比べて各精度指標を算出します。

イメージ）{推論結果："The ad is unsafe.", 違反フラグ: 1} → 正解

また、safe/unsafe以外に表記ゆれで他のワードで違反の結果が出力されてしまうことも考慮して、念のため以下のワードが含まれているかどうかで違反の判別をしています。

安全：["safe", "no violation", "compliant", "does not violate"]

違反：["unsafe", "violates policy", "violation", "violate"]

検証結果

性能評価 (レイテンシ・スループット)

精度評価

判定結果（Safe/Unsafe）をパースできた26件（全体の65%）に対する評価。

• 判定可能 : 26件 (65.0%)

• 判定不能 : 14件 (35.0%)

  • 理由1: 推論が長く、512トークンでは結論まで到達しなかった。

  • 理由2: 推論中で "violation" と "no violation" の両方に言及しており、単純なルールベースでの判定が困難だった。

プロンプトの調整を全然行っていない中、ポリシーとデータを投げただけにしては良く判別できていそうと見受けられます。何も強い制限のプロンプトは書いていないがRecallが100%になっていることから、保守的な傾向が強く安全性に最適化されているように見られます。

検証1・2の結果を見て

検証1から、HarmonyフォーマットやChain-of-Thoughtにより多くの推論情報が得られますが、検証2の通り返答が遅いです。ガードレールモデル・コンテンツフィルタとして実際のシステムで利用したい場合、1件処理するのにこれほど多くの時間（12.74 秒/req）をかけられないことが往々にしてあります。そこで検証3,4ではもっと大量に・速く処理を行うことに主眼を置きます。

応答を早くするには以下のような工夫があると思いますが、「1.モデルの軽量化」はGPT-OSS Safeguard（および元モデルのGPT-OSS）は既に MXFP4（4-bit） 化されており、これ以上の劇的な軽量化は精度（特にReasoning能力）の崩壊を招くため、今回は実施しません。「2.リソースのスケールアウト」は単にハードウェアリソースを増やすだけなのでスコープ外としています。したがって、3,4について検証します。

1. モデルの軽量化（Quantization）

2. リソース（主にGPU）のスケールアウト

3. 推論ステップの削減

4. 並列処理による高速化

検証3: 推論ステップの削減による処理速度変化

推論ステップを削減し、スループットを向上させるためのアプローチを検証しました。具体的には、プロンプトによる推論指示 (Reasoning Effort) アプローチの比較検証を実施しました。

検証設定

GPT-OSS Safeguard（およびGPT-OSS）では、システムプロンプトに思考の深さを指示しておくと推論の深さを調整することができます。そこで3パターン（High, Medium, Low）でレイテンシを比較しました。

検証結果

プロンプトによる生成量制御（High/Medium/Low）の効果は、今回のデータ、パラメータ設定（Max Tokens=512）下ではMediumとLowの間で差が生じました。

• 検証2の結果の生成平均トークン数にある通り、今回のタスクに対しては生成量の指定無しには467tokenの生成がありました。

• そのようなデフォルトでMax Tokens=512近くの生成トークンがある中において、生成量がHighではや推論が長くなったものの途中で打ち切られ、MediumとHighはあまりレイテンシに差があまり生じていないと考えられます。

• 一方で、Lowにするとレイテンシ削減幅が大きくなり、Mediumに対して処理速度が向上していることがわかります。

検証4: 並列処理による高速化

これまでは1問ずつ実行する逐次処理での実行をしてきましたが、そのような逐次処理ではGPUリソースを持て余すことになり無駄が多くなります。そこで並列処理、およびリソース消費の最適化をすることが大切になります。推論エンジンとして、そのような並列処理やリソース消費の最適化が容易に行えるvLLMを利用しました。

vLLMによって、並列化と最適化機能である Prefix Caching と Continuous Batching を活用し、大規模バッチ処理におけるスループットとレイテンシの改善効果を定量的に評価しました。特に、全リクエストで共通する長文ポリシーテキスト（約7400トークン）の再利用によるKVキャッシュ効率化の効果を検証しています。

最適化機能

まずはvLLMの2つの重要な最適化機能について説明します。

• • Prefix Caching (https://docs.vllm.ai/en/stable/design/prefix_caching/ )

    • 複数のリクエスト間で共通するプロンプトの先頭部分のKVキャッシュを自動的に再利用する機能

    • 仕組み

      1. プロンプトをハッシュ化してキャッシュテーブルに保存

      2. 同じプレフィックスを持つ新規リクエストが来たら、キャッシュされたKVペアを再利用

      3. LRU（Least Recently Used）ポリシーでキャッシュを管理

    • 効果

      • TTFT（Time To First Token）を最大80%削減

      • メモリ効率が向上

  • Continuous Batching (https://voice.ai/hub/tts/vllm-continuous-batching/ )

    • リクエストの完了を待たずに、イテレーション単位で動的に新しいリクエストをバッチに追加する機能

      • 従来の静的バッチングの問題点として①最も遅いリクエストの完了を全体が待つ必要がある ②パディングトークンへの無駄な計算 ③バッチの組み立て中や完了待ちでGPUがアイドル状態になる点がありますが、それを解決する機能です。

      • 効果

        • スループットが最大24倍向上（HuggingFace Transformers比）

        • GPU利用率が大幅に改善

        • レイテンシが削減

検証設定

並列数を段階的に増やし、各設定でのスループットとレイテンシを測定をしました

• 並列数: 1, 2, 4, 8, 16, 32, 40

• 共通部分: 全40リクエストで同一のポリシーテキスト（約7400トークン）を使用（Prefix Cachingの適用）

vLLM設定

llm = LLM(
    model=MODEL_PATH, 
    tensor_parallel_size=1, 
    enforce_eager=True, 
    trust_remote_code=True,
    max_num_seqs=512,              # 最大並列シーケンス数
    enable_prefix_caching=True,     # Prefix Caching有効化（固定）
    dtype="auto"
)

sampling_params = SamplingParams(
    temperature=0.0,
    max_tokens=512                  # 詳細な推論結果を取得
)
    

検証結果

並列数とパフォーマンスの関係

レイテンシ、スループットで大きな効率化が見られています。

• 平均レイテンシの劇的な改善

  • 並列数1で15.05秒/sampleのところ、並列数40では0.36秒/sampleになり、約41倍の高速化を達成

• スループットの線形的な向上

  • 並列数1で0.07 req/sのところ、並列数40では2.75 req/sになり、約39倍のスループット向上

    • 単純な並列化だけでは、バッチ内のリクエスト完了時間のばらつきによってGPUリソースが部分的に遊休し、並列数×1の線形なスループット向上は実現できない場合があります。Continuous Batchingによって初めて、並列数に比例したスループット向上が達成できているということが見られます。

  • 並列数に対してほぼ線形に向上

Prefix Cachingに関してはログより共通トークン（ポリシー）をキャッシュとして参照できていることを確認しました。

INFO: GPU KV cache size: 1,176,976 tokens
    

まとめ

本記事では、前編で解説したガードレールモデルの分類を踏まえ、推論型の代表格であるGPT-OSS Safeguardの実践的な検証結果を共有しました。

Chain-of-Thoughtによる推論の可視化

GPT-OSS Safeguardは、ポリシーの特定から違反判定まで、人間が追跡可能な形で推論プロセスを出力します。Harmonyレスポンスフォーマットにより、詳細な思考過程と構造化された判定結果が分離されるため、監査性と説明責任の確保に有効です。

デフォルト設定での性能特性

1リクエストあたり約12〜13秒のレイテンシが発生し、そのままではリアルタイム処理には不向きです。一方で、Recallが100%となる保守的な判定傾向が見られ、OpenAIによるチューニング時点で安全性を重視した設計をしていることが確認できました。

レイテンシ削減のアプローチ

推論ステップ削減による処理速度改善の検証では、プロンプトによる推論深度の制御がレイテンシに影響を与えることが確認されました。特に、生成量をLow（簡潔な出力）に明示的に制限した場合、High（詳細な推論）と比較して6.6%のレイテンシ削減を達成し、処理速度の向上が実現できました。推論の深さを適切にコントロールすることで、アプリケーションの要件に応じたパフォーマンス最適化が可能であることが示唆されます。

並列処理による大幅な効率化

vLLMのPrefix CachingとContinuous Batchingを活用することで、シングル実行比で約40倍のスループット向上を確認しました。GPUリソースの規模次第ではありますが、検証においてレイテンシが約15秒/reqから約0.3秒/reqになったよう、適切な最適化により大量トラフィックを処理できる可能性が示されました。

前編で述べた通り、分類型と推論型のどちらが優れているかではなく、適材適所の使い分けが重要です。実運用においては、軽量な分類型で明らかな違反を高速にフィルタリングし、グレーゾーンの案件のみを推論型で詳細にチェックするハイブリッド構成が現実的な解となるでしょう。

本記事の検証結果が、皆様の生成AIプロダクトにおける安全なシステム設計の一助となれば幸いです。

参考

• https://openai.com/ja-JP/index/gpt-oss-safeguard-technical-report/

• https://www.ariseanalytics.com/tech-info/20250718

• https://huggingface.co/openai/gpt-oss-safeguard-20b
  

• https://huggingface.co/openai/gpt-oss-20b
  
  
• https://blog.vllm.ai/2025/09/05/anatomy-of-vllm.html
  
  
• https://docs.vllm.ai/en/stable/design/prefix_caching/