Safety Usage Dashboardにより、組織全体のブロックだけでなく、アプリケーションが送信した safety_identifier 単位で傾向を追跡できるようになった。識別子は安全対策に役立つが、ユーザーのメールアドレスや氏名をそのまま送ればプライバシー上の問題を増やす。ID設計とインシデント対応を一体で整える必要がある。
何が変わったか
OpenAI APIプラットフォームにSafety Usage Dashboardが追加され、safety_identifierに基づいてブロックされたResponsesリクエストを確認できるようになった
| 項目 | 内容 |
|---|---|
| 対象 | OpenAI API |
| API・機能 | Responses API,Chat Completions API,Realtime API |
| 変更種別 | セキュリティ |
| 重要度 | 高 |
| 対応期限 | 期限なし |
変更前後の差
従来も safety_identifier は送信できたが、ダッシュボードでブロック状況を利用者単位に確認する運用導線が弱かった。新しいダッシュボードはブロックされたResponsesリクエストを可視化する。識別子は最大64文字の安定した文字列とし、ユーザー名やメールはハッシュ化することが推奨される。
誰に影響するか
ログインユーザーを持つサービスだけでなく、匿名プレビューやRealtime音声にも影響する。匿名利用者にはセッションIDを使える。RealtimeではOpenAI-Safety-Identifierヘッダーをセッション作成・接続時に別途送る必要があり、他APIから自動継承されない。
期限
必須化の期限はなく、識別子送信は推奨事項である。ただし不正利用が一部ユーザーに集中するサービスでは、組織全体の停止リスクを下げるため早期導入の優先度が高い。
必要な対応
内部ユーザーIDから一方向ハッシュを生成し、環境をまたいで衝突せず、退会後の再利用も起きない規則を作る。ダッシュボードの確認担当、調査開始条件、ユーザー制限・解除、異議申立て、ログ保持期間を決める。
実装・移行手順
- 内部IDと環境識別子を組み合わせたハッシュ規則を定義する
- メールアドレスや氏名を直接送っていないことをコードレビューする
- ResponsesとChat Completionsへ同じ識別子を設定する
- Realtimeの一時キー作成・接続へ専用ヘッダーを追加する
- 匿名利用では短命セッションIDを利用する
- ダッシュボードのブロック件数と自社監査ログを突合する
失敗しやすい点
ランダムIDを毎回作って追跡不能にする、メールを平文送信する、開発と本番で同じ利用者が衝突する、Realtimeへ引き継がれると誤解する、ブロック件数だけで利用停止を自動決定することが失敗につながる。
リスク
識別子から個人を推測できる設計、誤検知による利用停止、複数端末・複数アカウントの誤統合、ダッシュボード閲覧権限の過剰付与がリスクである。
評価方法
- 識別子設定率
- 空・不正形式の識別子率
- ブロック利用者の再発率
- 組織全体のブロック率
- 調査開始から処置までの時間
- 誤停止・解除件数
ロールバック
送信をFeature Flagで停止し、既存の内部不正利用監視だけへ戻す。ハッシュ方式を変更する場合は旧新IDの変換表を作らず、移行日を境に別バージョンとして扱う。
編集部分析
この機能は安全性ダッシュボードであると同時に、IDガバナンス機能である。精度を上げるために個人情報を増やす必要はない。安定性、非可逆性、API間の一貫性を満たす最小識別子が最も運用しやすい。
実務チェックリスト
- [ ] 平文の個人情報を送っていない
- [ ] 64文字以内の安定IDを使用した
- [ ] 匿名セッションの規則がある
- [ ] Realtimeへ別途設定した
- [ ] 閲覧権限を最小化した
- [ ] 自動停止前に人手確認を入れた