For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
メインナビゲーション

ミスアラインメントの監視

停止された会話とプロジェクトの安全性アラートへの対応。

ミスアラインメントの監視では、機密データの転送や機密データへのアクセス、破壊的な変更など、重大な影響を伴う場面で、エージェントがユーザーの指示を適切に解釈しているかを確認します。モデルの推論とアクションを非同期でレビューし、潜在的な問題を検出した場合は会話を停止できます。

フラグは、エージェントのアクションにレビューが必要であることを示します。ユーザーがポリシーに違反したことや、エージェントが指示に反して行動したことを確定するものではありません。監視では問題を見逃したり、正当な活動にフラグを付けたりする可能性があるため、重大な影響を伴うアクションに対する人間の承認など、アプリケーションの安全対策を引き続き使用してください。

詳しい背景については、ヘルプセンターにあるミスアラインメントの監視の概要をご覧ください。

対象となるリクエスト

このシステムの対象モデルでは、監視と自動停止の動作は、リクエストで使用する API と会話のコンテキストを保持する仕組みによって次のように異なります。

リクエスト動作
永続化された推論、WebSockets、または OpenAI のコンパクションを使用する Responses API リクエスト監視対象です。システムは会話の継続を識別し、それ以降の実行をブロックできます。
これらの仕組みをいずれも使用しない Responses API リクエスト監視対象です。設定済みの Webhook でアラートを受信できますが、システムによる会話の自動停止は行われません。
Chat Completions API リクエストこの監視システムの対象外です。他の安全性チェックは引き続き適用されます。

会話のコンテキストに関するガイダンスは、呼び出し間での推論の保持WebSocket モードコンパクションをご覧ください。アラート用の Webhook を設定しても、自動停止は有効になりません。

停止されたリクエストへの対応

ストリーミングの開始前にミスアラインメントの監視がリクエストをブロックした場合、API は HTTP 403 を返し、エラータイプは invalid_request_error、コードは misalignment_policy_violation となります。メッセージのテキストではなく、エラーコードで判定してください。ストリーミングを利用する実装では、出力を受信した後も含め、ストリームの読み取り中に発生するエラーにも対応する必要があります。

アプリケーションがこのエラーを受信した場合は、次のように対応してください。

  1. 対象の会話について、それ以上のアクションの実行指示を停止してください。ブロックされたワークフローを自動で再試行しないでください。
  2. データの取り扱いポリシーに従って、関連するリクエスト ID とレスポンス ID、ツール呼び出し、アプリケーションの記録を保存してください。
  3. タスクを担当するユーザーまたはオペレーターに、取得できたエラー情報を表示してください。エージェントのアクションを意図した作業と照合し、すでに行われた変更をレビューしてもらってください。

ミスアラインメントの監視によって停止された会話を再開するための汎用的な方法は、API では提供されていません。

監視は非同期で行われるため、懸念事項が検出される前にアクションがすでに完了している場合があります。リクエストが停止されても、それ以前のアクションは取り消されません。

プロジェクトの安全性アラートの受信

safety.alert.created をサブスクライブすると、API プロジェクトの監視アラートをチームが運用するシステムに送信できます。アラートを受信する場合も、API リクエストのエラー処理は必要です。

アラートを受信したいプロジェクトごとに、Webhook エンドポイントの作成に従ってください。署名の検証や、受信確認、再試行、重複配信については、Webhook ガイドをご覧ください。

Webhook には、次のようにアラートの詳細ではなくアラート ID が含まれます。

{
  "object": "event",
  "id": "evt_123",
  "type": "safety.alert.created",
  "created_at": 1787659200,
  "data": {
    "id": "alert_0123456789abcdef0123456789abcdef"
  }
}

Webhook を検証して受信確認を返した後、バックグラウンド処理でアラートを取得します。例として示した salert_123 の値を、Webhook の data.id に置き換えてください。イベントの id は、アラートではなく Webhook イベントを識別するものです。同じプロジェクトでの使用が許可され、api.safety.alerts.read 権限を持つ API キーを使用してください。

curl "https://api.openai.com/v1/safety/alerts/salert_123" \
  -H "Authorization: Bearer ${OPENAI_API_KEY}"
プロジェクトの安全性アラートの取得
# Replace the illustrative IDs and URLs below with your own resource values.

from openai import OpenAI

client = OpenAI()
alert = client.safety.alerts.retrieve("salert_123")
print(alert.error_type, alert.reason)

返された request_idresponse_id を使用して、アプリケーションの記録から対象の作業を見つけてください。アラートのカテゴリは、調査すべき懸念事項として扱ってください。request_pausedtrue の場合、安全性に基づくブロックの登録は成功しています。ただし、実行が停止したことや、それ以前のアクションが取り消されたことを確認するものではありません。アプリケーションのタスクの状態とツールの記録を確認してください。

ゼロデータ保持(ZDR)のリクエストを含め、アラートの reasonnull になる場合があります。null 以外の reason はカテゴリの説明であり、会話の全文や完全な調査報告ではありません。組織のデータポリシーに従って、必要な記録を保存してください。API のデータ管理については、お客様のデータをご覧ください。

取得時に 404 とコード safety_alert_not_found が返された場合は、アラート ID とプロジェクトの認証情報を確認してください。記録が存在しない場合、アクセスできない場合、不完全な場合に、このエラーが返されることがあります。アラートの配信と取得では、完全な監査履歴は提供されません。