OpenAIのSafety IDは何を変える？利用者単位の遮断と通知を実装する

公開日2026.10.23

約9分で読めます

※本ページのリンクにはプロモーションが含まれています。

複数の匿名利用者IDのうち一件だけをAI APIから調査経路へ切り分けWebhookで運用担当へ通知する概念イラスト

複数の利用者が一つのAI機能を使うWebサービスでは、ある利用者の不正利用が組織全体のAPI利用へ影響する設計を避けたいところです。OpenAIは2026年10月21日、安全性に関する運用方針の更新とともに、APIリクエストを利用者単位で識別するSafety IDと、警告・無効化を受け取る仕組みを案内しました。

本稿は2026年10月23日に確認したOpenAIの公式発表とAPIドキュメントを基にした実装解説です。新しい脆弱性や攻撃事例を伝える記事ではありません。確認済みの製品仕様と、本サイトが提案するWebサービス向けの設計・導入手順を分けて説明します。

Safety IDで変わるのは安全対策の粒度

OpenAIは公式発表「Broad access through consistent standards」で、エンドユーザーを区別するSafety IDにより、疑わしい利用への対応を精密にし、正当な利用者への影響を減らす考えを示しました。漏えいしたAPIキー、侵害されたアカウント、利用者による不正利用が起きても、提供元へ氏名やメールアドレスを知らせずに利用者を区別するための識別子です。

OpenAI APIドキュメント「Safety identifiers」では、Safety IDの付与は推奨であり必須ではないと説明されています。ただし、サイバーセキュリティ向けの安全対策では、利用者ごとの識別子がない場合に組織全体のアクセスへ影響し得る一方、固有の識別子があれば審査後に特定の利用者へ制限を絞れる場合があるとされています。

ここで重要なのは、Safety IDが本人確認の証明ではないことです。ログイン、テナント分離、権限判定、ツール実行の承認、監査ログを置き換えるものではありません。アプリ側で把握している利用者を、APIリクエスト上で一貫して区別するための補助情報です。OpenAIが不正利用を検知したときの切り分けを細かくできますが、誰がどの権限で何をしたかを決める責任はアプリ側に残ります。

APIごとに渡し方が異なり自動では引き継がれない

対象	渡し方	実装時の注意
Responses API	`safety_identifier`	エンドユーザーが変わるたび、その利用者に対応する安定した値を送る
Chat Completions API	`safety_identifier`	別APIから値が自動継承されるとは考えない
Images API	`safety_identifier`	生成・編集リクエストごとに付与し、128文字以内にする
Realtime API	`OpenAI-Safety-Identifier`ヘッダー	セッション接続時にヘッダーとして渡す

公式ドキュメントは、APIやセッションをまたいで識別子が自動的に引き継がれないと説明しています。Responses APIへ値を付けても、画像生成やRealtime接続へ同じ利用者の情報が勝手に伝わるわけではありません。複数APIを使う製品は、リクエスト生成の共通層に処理を置き、各APIの形式へ確実に変換する必要があります。

逆に、端末や会話ごとに毎回新しい値を作ると、同じ利用者を継続して区別できません。セッションIDではなく、アプリ内の利用者に安定して対応する値を使います。未ログイン利用を許す場合は、匿名利用をどの単位で扱うかを別に決め、ログイン済み利用者と同じ強さで本人を識別できるように装わないことも大切です。

個人情報を送らずに安定した識別子を作る

OpenAIは、メールアドレスや内部IDをそのまま送らず、ハッシュ化した値などを使うよう案内しています。本サイトの提案としては、単純なメールアドレスのハッシュだけにせず、サーバー側の秘密鍵を使うHMACと、テナント・利用者ID・方式の版を組み合わせる設計が扱いやすいでしょう。これはOpenAIが特定のアルゴリズムを必須にしているという意味ではありません。

import { createHmac } from "node:crypto";

export function makeSafetyId(tenantId, userId) {
  const key = process.env.SAFETY_ID_KEY;
  if (!key) throw new Error("SAFETY_ID_KEY is required");

  return createHmac("sha256", key)
    .update(`v1:${tenantId}:${userId}`)
    .digest("base64url");
}

この例では、OpenAIへ送る値から元の利用者IDを直接読み取れません。アプリ側は「どの利用者からどのSafety IDが導かれるか」を再計算できるため、メールアドレスとの対応表を外部へ渡す必要もありません。ただし、秘密鍵を変更すると値が変わり、過去との連続性が切れます。鍵をローテーションする場合は版を管理し、サポート・調査期間と保存期間を決めてください。

テナントを識別子へ含めるのは、同じ数値の利用者IDが複数顧客で重複する構成を避けるためです。複数の自社製品が同じOpenAI組織を使うなら、製品名の名前空間も加えられます。一方、行動履歴を必要以上に結合できる万能IDにすると、内部プライバシーの範囲が広がります。安全対応に必要な範囲へ用途を限定し、アクセス権と保持期間を設定します。

警告をWebhookで受け取りSafety Caseを調べる

OpenAI APIドキュメント「Safety enforcement notifications」によると、組織のWebhookではsafety.warning_issuedとsafety.deactivation_issuedを購読できます。イベントに含まれるSafety Case IDを使い、GET /v1/safety/cases/{id}から識別子、通知種別、時刻、理由を取得します。取得にはapi.safety.read権限を持つ制限付きAPIキーを使えます。

Webhookの受信処理は、署名を検証してからキューへ入れ、イベントIDで重複排除します。ドキュメント上、WebhookイベントのIDとSafety Caseを示すdata.idは別物です。受信したイベントをそのまま画面に表示するのではなく、Case APIで内容を取得し、Safety IDを自社利用者へ照合して、調査チケット、利用制限、問い合わせ対応へつなげます。Caseを取得しても制限が自動解除・変更されるわけではありません。

Webhook署名と送信時刻を検証し、同じイベントの再送を安全に処理する
Safety Case取得用キーを通常の推論キーと分け、読み取り権限だけを与える
Safety IDから利用者を特定できる担当者を限定し、調査記録へ生の個人情報を複製しない
警告、利用停止、誤判定の申し立て、アカウント再作成を別の運用状態として扱う

ストリーミング中断と再試行の設計が必要

OpenAI APIドキュメント「Cybersecurity checks」では、新しい高いサイバー能力を持つモデルのAPI向け安全対策が説明されています。評価がストリーミング開始後まで続く場合があり、途中でcyber_policyエラーが返ることがあります。また、現在のSafety identifiers資料では、高い確度の違反により識別子が今後のGPT-5リクエストで遮断された場合、その識別子を個別に解除する機能は現時点で提供していないと説明されています。

この仕様を通常の通信失敗と同じ自動再試行へ流すと、同じ利用者から失敗リクエストを繰り返す恐れがあります。ポリシー関連のエラーはネットワーク障害やレート制限と分け、利用者には生成が完了しなかったことを明示し、運営側にはSafety IDとリクエスト追跡情報を残します。途中まで届いた出力を自動保存・公開するかも、製品の性質に合わせて決める必要があります。

モデル仲介サービスは11月20日の規約変更も確認

OpenAI Usage Policiesには、2026年11月20日から、モデルルーター、AIゲートウェイ、その他の仲介サービスとして第三者へモデルへの直接アクセスを提供する場合、事前の審査と承認が必要になると記載されています。一方、自社機能の一部としてモデルを組み込む通常のアプリは、それだけを理由にこの要件の対象にはならないと説明されています。

したがって、Safety IDを追加すれば仲介サービスの要件を満たす、と考えてはいけません。自社サービスが完成機能を提供するアプリなのか、利用者が基盤モデルへ直接アクセスする経路なのかを棚卸しし、後者なら施行前にOpenAIへ確認する必要があります。複数モデルを切り替えるゲートウェイでは、Safety IDが他社APIへ自動的に移植されるわけでもありません。提供元ごとの識別子・通知・異議申立て手順を分けて管理します。

段階導入では切り戻しより観測可能性を先に作る

まず、APIを利用する主体を「組織管理者」「ログイン済み利用者」「匿名利用者」「バックグラウンド処理」に分けます。次に、Safety IDの生成規則と保持期間を決め、Responses、画像、Realtimeなど利用中の全経路へ付与します。値を付けたリクエストの成功率とポリシーエラーを、個人情報を含めずに集計できる状態を作ります。

その後、WebhookとSafety Case APIを限定された担当チームへ接続し、警告を受けたときの確認順序を手順化します。Safety IDだけを根拠に自社アカウントを永久停止するのではなく、該当リクエスト、アカウント侵害、APIキー漏えい、アプリの入力制御を合わせて確認します。ツールを実行するAI機能では、権限確認、引数検証、実行範囲の制限、承認、監査ログを別に維持してください。

本サイトでは実際の組織WebhookやSafety Case APIを用いた導入試験は行っていません。導入時はテスト環境で、識別子がAPIごとに欠落しないこと、Webhookの重複・遅延・順序逆転を処理できること、ポリシーエラーを無限再試行しないこと、担当者以外が対応表を閲覧できないことを確認します。Safety IDの効果は「不正利用がなくなる」ことではなく、発生時の影響範囲と調査単位を細かくできることとして評価するのが適切です。