OpenAIは生成APIへインラインモデレーションを追加した。安全判定用の別APIを呼び出す構成だけでなく、生成リクエストの入力と出力について判定結果を同じレスポンスで受け取れる。実装を簡略化できる一方、判定結果が届く時点と、判定サービス自体が失敗した場合の扱いを曖昧にすると、危険な出力を一時表示したり、正常な生成を誤って破棄したりする。
何が変わったか
Responses APIとChat Completions APIにインラインのmoderation指定が追加され、入力・生成出力の安全判定を同じ応答へ含められるようになった
| 項目 | 内容 |
|---|---|
| 対象 | OpenAI API |
| API・機能 | Responses API,Chat Completions API |
| 変更種別 | セキュリティ |
| 重要度 | 高 |
| 対応期限 | 期限なし |
変更前後の差
従来は、入力をModerations APIへ送信してから生成し、生成結果を再度Moderations APIへ送る二段階構成が一般的だった。新方式では生成リクエストにmoderationを指定し、入力・出力の結果を同じレスポンスへ含められる。ただし判定スコアはポリシー判断材料であり、自動的にブロックする仕様ではない。
誰に影響するか
チャットUI、文章生成、検索要約、Agentの最終回答、ユーザー生成コンテンツの保存処理に影響する。ストリーミングでは出力スコアが完全な出力後に利用可能になるため、トークンを即時表示するUIは特に注意が必要である。ツール名やスキーマ自体は判定対象ではないため、ツール権限管理を代替する機能ではない。
期限
強制移行期限はない。既存のModerations APIは引き続き利用できるため、入力を生成前に遮断する必要がある経路や、複数モデルを共通ポリシーで評価する経路では併用できる。
必要な対応
入力の事前遮断、出力の公開前確認、監査用記録を分ける。インライン判定だけで安全制御が完結すると考えず、危険なツール実行、個人情報、業務固有禁止事項はアプリケーション側のガードレールで制御する。モデレーション失敗時はfail-openかfail-closedかを用途別に決める。
実装・移行手順
- 代表的な正常・境界・違反入力を評価セットへ登録する
- 非ストリーミング経路でinputとoutputの判定構造を保存する
- ストリーミング経路は一時バッファ表示と完了後公開を比較する
- モデレーションエラーを意図的に発生させ、縮退動作を確認する
- 既存Moderations APIとの重複呼び出しと費用・遅延を測定する
- 判定カテゴリ、スコア、最終処置、担当者判断を監査ログへ残す
失敗しやすい点
flaggedだけを見てカテゴリ別の業務ルールを無視する、ストリーミング中の部分出力をすでに安全とみなす、モデレーションエラーを正常判定として扱う、ツール定義まで検査されると誤解することが失敗につながる。
リスク
過剰遮断による業務停止、判定遅延によるUX悪化、危険出力の瞬間表示、監査ログへの機密入力保存が主なリスクである。判定スコアの閾値を一律にすると、用途ごとの許容範囲を反映できない。
評価方法
- カテゴリ別の再現率・適合率
- 危険出力が公開前に停止された割合
- 正常出力の誤遮断率
- P50・P95追加レイテンシー
- モデレーションエラー率
- 人手再確認へ送られた件数
ロールバック
生成リクエストのmoderation指定を無効化し、従来のModerations APIによる事前・事後判定へ戻す。切り替えはFeature Flagで行い、監査ログの形式は共通化して比較可能にする。
編集部分析
インライン化の価値はAPI呼び出し数の削減だけではない。生成と安全判定を同じリクエストIDへ結び付けられるため、追跡性が上がる。一方、表示前遮断が必要なシステムではストリーミング特性を理解しない導入が危険であり、速度より公開境界の設計が先である。
実務チェックリスト
- [ ] 入力と出力の両方を評価した
- [ ] ストリーミング時の公開境界を定義した
- [ ] 判定失敗時の動作を決めた
- [ ] 既存Moderations APIとの役割を整理した
- [ ] カテゴリ別の業務閾値を設定した
- [ ] ログへ機密情報を残しすぎない