OpenAIのSafety Usage Dashboard、AIのブロック履歴をユーザー単位の運用画面にした
OpenAI DevelopersのAPI changelogは、2026年6月23日にSafety Usage Dashboardを公開したと示しました。ダッシュボードは、Responses APIでブロックされたリクエストを、リクエスト時に送るsafety_identifierの値にもとづいて表示します。派手な新モデルではありませんが、AI安全性を「その場で拒否する機能」から、利用者単位で傾向を追い、運用側が対処する画面へ移す更新です。
拒否されたリクエストが、運用者の画面に残る
changelogの更新点は短いものです。Safety Usage DashboardはOpenAI API Platform上の画面で、Responses APIのブロックされたリクエストをsafety_identifierにもとづいて表示します。つまり、アプリが同じ利用者を識別できる値をリクエストに渡しておけば、ブロックがどこで起きたかを後から追いやすくなります。
これは、先日のmoderation scoresとは別の方向の安全機能です。moderation scoresは生成リクエストの入力と出力に安全判定を同梱する部品でした。Safety Usage Dashboardは、その後の運用面です。あるユーザー、セッション、組織内の利用単位でブロックが増えているのか、どのプロダクト面で止まっているのかを見つける入口になります。
ユーザー体験としても意味があります。AIが突然「答えられない」と返すだけでは、利用者にも運用者にも原因が残りません。ダッシュボードがあれば、プロンプトの導線が悪いのか、特定ユーザーの使い方が危険なのか、年齢や権限の設計が足りないのかを、後から見直せます。
safety_identifierは、個人情報ではなく安定した鍵として使う
OpenAIのSafety best practicesは、各エンドユーザーを一意に示す文字列としてsafety_identifierを送ることを勧めています。ただし、メールアドレスやユーザー名をそのまま送るのではなく、ハッシュ化して個人を直接識別できる情報を避けるよう説明しています。ログインしていないプレビュー利用では、セッションIDを使う選択肢も示されています。
この設計は、AIアプリの安全性とプライバシーの折り合いを示しています。運用者は「同じ人の行動か」を追いたい。一方で、AI基盤側へ不要な個人情報を渡したくない。safety_identifierは、その中間にある安定した鍵です。
API referenceでも、chat completionsのbody parameterとしてsafety_identifierが説明されています。これは利用規約違反の可能性をOpenAIが検出しやすくするための安定した識別子で、最大64文字の文字列として扱うよう案内されています。Realtime APIではOpenAI-Safety-Identifier headerを使い、セッションごとに同じ安定した値を渡す必要があります。
安全性はモデルの中だけでなく、プロダクト運用の設計になる
Interface Wire的に見ると、今回の更新は「安全なモデルかどうか」だけの話ではありません。生成AIの安全性が、ユーザーID、セッション、ログ、管理画面、サポート対応まで含めたプロダクト運用の設計へ広がっていることを示しています。
たとえば教育、社内ナレッジ、カスタマーサポート、クリエイティブツールでは、ブロック回数が多い利用者をただ止めればよいとは限りません。画面上の説明を直す、入力フォームを分ける、権限を調整する、年齢や利用目的に応じて導線を変える、といった改善が必要になります。
Safety Usage Dashboardは、その判断材料をAPIの外側へ出す小さな管理面です。ブロックはユーザーに見える瞬間で終わらず、運用者が後から読める状態になる。AIプロダクトの安全性は、モデルの出力を止めるだけでなく、止まった事実をどう記録し、誰が見て、どの画面を直すかという設計に移っています。
Safety Usage Dashboardは、OpenAIの大きな発表群に比べると地味です。それでも、AIアプリを実運用する側には効く更新です。ブロックされたResponses APIリクエストをsafety_identifier単位で見られるなら、安全性は一回ごとの拒否ではなく、利用者、セッション、プロダクト面ごとの改善サイクルになります。生成AIの安全UIは、ユーザーに何を見せないかだけでなく、運用者が何を見て直すかまで含む段階に入っています。