OpenAIは、安全性運用を支援する二つの機能を追加した。Safety Usage Dashboardでは、safety_identifierに基づいてブロックされたResponses APIリクエストを確認できる。Inline Moderationでは、通常の生成リクエストに入力・出力のModerationを追加し、分類結果やスコアを取得できる。
これらは安全対策を自動完成させる機能ではない。誰を識別し、どの閾値で止め、モデルが生成した出力をいつ利用者へ見せるかを、サービス側が決める必要がある。
何が変わったか
従来は、生成前後にModeration APIを別途呼ぶ構成が一般的だった。Inline Moderationは、Responses APIまたはChat Completions APIの処理内で入力・出力の安全分類を取得できる。
公式資料では、Inline Moderationを有効にしてもモデル生成自体は行われる。アプリケーションは結果を確認し、出力を利用者へ表示する前に自社ポリシーで許可・遮断・レビューを判断する。
Safety Usage Dashboardは、safety_identifierを手掛かりに、どの識別子からの要求が安全システムでブロックされたかを運用者が把握するための画面である。
変更前後の差
| 項目 | 従来 | 新機能利用時 |
|---|---|---|
| Moderation呼出 | 別API・別ワークフロー | 生成リクエストへ統合可能 |
| 出力判定 | アプリが後段で別呼出 | 同じ処理でスコア取得 |
| ブロック可視化 | 独自ログ中心 | Safety Usage Dashboardを併用 |
| 利用者識別 | 任意実装 | safety_identifierを活用 |
| 最終判断 | 自社責任 | 引き続き自社責任 |
Inline Moderationのスコアは、法的判断やサービス規約の最終結論ではない。製品の対象年齢、地域、文脈、許容リスクへ合わせて解釈する。
誰に影響するか
- 一般利用者が自由入力できるサービス
- 生成結果を公開、共有、送信する機能
- 学校、未成年、医療、金融、採用など高リスク領域
- エージェントが外部Toolを実行するサービス
- 複数アカウントや匿名利用で濫用対策が必要
- Moderation APIの追加呼出レイテンシを減らしたい
- OpenAI側ブロックと自社ブロックを区別できていない
社内限定サービスでも、秘密情報、個人情報、ハラスメント、危険行為への対応は必要である。
必要な対応
safety_identifierを設計する
同一利用者または同一クライアントを安定して追跡でき、OpenAIへ直接の個人情報を送らない値を使う。メールアドレスや氏名をそのまま設定せず、サービス側の内部IDを秘密付きハッシュなどで変換する。
safety_identifier = HMAC-SHA256(service_secret, tenant_id + ":" + user_id)ローテーション、削除、アカウント統合時の扱いも決める。
判定表を作る
カテゴリーとスコアを、許可、警告付き許可、出力を伏せて再生成、人間レビュー、リクエスト拒否、アカウント制限、緊急エスカレーションへ変換する。単一の全カテゴリー共通閾値を使わない。
実装・移行手順
1. 現行フローを図示する
入力受付、生成、Tool実行、出力表示、ログ、通報、アカウント措置の順序を確認する。現在のModerationがどこで実行されるか特定する。
2. 入力と出力を分ける
入力が安全でも出力が安全とは限らない。入力・出力の両方を評価し、出力結果を確認するまでクライアントへストリーム表示しないモードを用意する。
3. ストリーミング方針を決める
リアルタイム表示では、最後にModeration結果が返る前に有害部分を見せる可能性がある。高リスク機能では、サーバー側でバッファし、判定後に公開する。
4. Tool実行を別制御する
会話内容のModerationだけで、購入、削除、送信、権限変更などのTool操作を許可しない。Tool引数、対象、権限、承認を独立して検査する。
5. Dashboardと自社ログを突合する
OpenAI側のブロック、自社Moderationの遮断、アプリの業務ルール拒否を別の理由コードで記録する。Dashboard上の増加とデプロイ、キャンペーン、攻撃イベントを相関する。
6. 異議申立てとレビューを用意する
誤検知で利用者を永久停止しない。レビュー可能な証跡を保持し、必要最小限の期間で削除する。
失敗しやすい点
- モデルが生成しないと誤解し、判定前に出力を表示する
- スコアを絶対値として扱い、自社データで校正しない
safety_identifierへメールや氏名を直接入れる- 全利用者で一つの識別子を共有する
- Tool出力や外部検索結果を検査対象から外す
モデルやカテゴリ更新でスコア分布が変わる可能性がある。自動措置は人間レビュー結果で継続校正する。
評価方法
- 入力・出力別の許可、拒否、レビュー率
- カテゴリー別スコア分布
- 人間レビューによる誤検知率・見逃し率
- Safety Usage Dashboardのブロック件数
safety_identifier未設定率- ブロック急増から検知までの時間
- 出力判定前に利用者へ表示された件数
- Tool実行前の独立承認率
- 異議申立ての覆り率
- 攻撃テストでの回避成功率
評価用データには、通常利用、曖昧表現、引用、教育目的、多言語、意図的な難読化を含める。
ロールバック
Inline Moderation導入でレイテンシや誤検知が問題になった場合、既存の独立Moderation APIフローへ戻せるFeature Flagを用意する。
- Inline判定による自動措置を停止する
- 既存の入力・出力Moderationを有効化する
- 高リスク機能は一時的に出力をバッファする
- 誤検知対象のアカウント措置をレビューする
- スコア分布と閾値を再校正する
- 限定トラフィックで再開する
安全機能を完全に外すことをロールバックにしてはいけない。
編集部分析
今回の機能は、安全性を「個別API呼出」から「生成ワークフローと運用画面」へ近づける。実装負荷と観測性は改善するが、最終判断の責任はサービス提供者に残る。
重要なのは、OpenAI側ブロックと自社ポリシー違反を混同しないことである。OpenAIの安全システムはプラットフォーム保護、自社Moderationは製品・顧客・法域の要件を満たすための統制であり、目的が異なる。
また、識別子単位の可視化は濫用対策に有効だが、識別子設計が粗いと「一人の問題を全利用者へ拡大する」危険がある。匿名性、追跡性、削除可能性のバランスを設計すべきである。
実務チェックリスト
- [ ]
safety_identifierを匿名化し安定生成している - [ ] 入力と出力を別々に判定している
- [ ] 判定前に高リスク出力を表示していない
- [ ] カテゴリー別の業務アクション表を作った
- [ ] 自動停止と人間レビューを分けた
- [ ] Tool実行をModerationとは別に認可している
- [ ] Dashboardと自社ログを理由コードで突合できる
- [ ] 多言語・引用・難読化を含む評価を行った
- [ ] 誤検知の異議申立てと復旧手順がある
- [ ] 独立Moderationフローへの切替手段がある