ミスアライメント監視は、機密データの転送や機密データへのアクセス、破壊的な変更など、影響の大きい操作を行う際に、エージェントがユーザーの指示を適切に解釈しているかを確認する仕組みです。モデルの推論と操作を非同期で確認し、問題の可能性を検出すると会話を停止することがあります。
フラグが付いた場合は、エージェントの操作を確認する必要があります。フラグだけでは、ユーザーがポリシーに違反したとも、エージェントが指示に反する操作を行ったとも断定できません。監視では問題を見逃したり、正当な操作にフラグを付けたりすることがあるため、影響の大きい操作に人による承認を求めるなど、引き続きアプリケーションの安全対策を講じてください。
詳しくは、ヘルプセンターのミスアライメント監視の概要をご覧ください。
監視対象のリクエスト
このシステムの対象モデルでは、リクエストに使用する API と会話のコンテキストを保持する方法によって、監視と自動停止の適用範囲が異なります。
| リクエスト | 動作 |
|---|---|
| 永続化された推論、WebSocket、OpenAI のコンパクションのいずれかを使用する Responses API リクエスト | 監視対象です。システムは、同じ会話の続きであることを識別し、それ以降の実行をブロックできます。 |
| 上記の仕組みをいずれも使用しない Responses API リクエスト | 監視対象です。設定済みの Webhook でアラートを受信できますが、システムが会話を自動停止することはありません。 |
| Chat Completions API リクエスト | このシステムの監視対象外です。他の安全性チェックは引き続き適用されます。 |
会話のコンテキストを保持する方法については、呼び出し間での推論の保持、WebSocket モード、コンパクションを参照してください。アラート用の Webhook を設定しても、自動停止は有効になりません。
停止されたリクエストへの対応
ストリーミング開始前にミスアライメント監視がリクエストをブロックした場合、API は HTTP 403 を返します。エラータイプは invalid_request_error、エラーコードは misalignment_policy_violation です。エラーの判定には、メッセージ本文ではなくエラーコードを使用してください。ストリーミングを利用するアプリケーションでは、出力の受信が始まった後も、ストリームの読み取り中に発生するエラーを処理する必要があります。
アプリケーションがこのエラーを受け取った場合は、次の手順に従ってください。
- 該当する会話では、それ以降の操作の実行指示を停止してください。ブロックされたワークフローを自動で再試行しないでください。
- データの取り扱いポリシーに従って、関連するリクエスト ID とレスポンス ID、ツール呼び出し、アプリケーションの記録を保存してください。
- タスクを担当するユーザーまたはオペレーターに、取得できたエラー情報を提示してください。エージェントの操作を意図した作業内容と照合し、すでに行われた変更を確認するよう依頼してください。
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 の署名を検証して受信確認を返した後、バックグラウンド処理でアラートを取得してください。以下の例の alert_0123456789abcdef0123456789abcdef は、Webhook で受け取った data.id に置き換えてください。イベントの id が識別するのは、アラートではなく Webhook イベントです。同じプロジェクトでの使用が認められ、api.safety.alerts.read 権限を持つ API キーを使用してください。
curl "https://api.openai.com/v1/safety/alerts/alert_0123456789abcdef0123456789abcdef" \
-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("alert_0123456789abcdef0123456789abcdef")
print(alert.error_type, alert.reason)返された request_id と response_id を使って、アプリケーションの記録から該当する作業を特定してください。アラートのカテゴリは、どのような懸念を調査すべきかを示します。request_paused が true の場合、安全上の理由によるブロックの登録には成功しています。ただし、実行が停止したことや、それまでの操作が取り消されたことを確認できたわけではありません。アプリケーションでタスクの状態とツールの実行記録を確認してください。
アラートの reason は、ゼロデータ保持(ZDR)が適用されるリクエストなどで null になることがあります。値がある場合、reason に含まれるのはカテゴリの説明であり、会話の逐語記録や調査報告の全文ではありません。組織のデータポリシーに従って、必要な記録を保存してください。API のデータ管理については、データの取り扱いを参照してください。
アラートの取得時に 404 が返され、エラーコードが safety_alert_not_found の場合は、アラート ID とプロジェクトの認証情報を確認してください。記録が存在しない場合、アクセスできない場合、または記録が不完全な場合に、このエラーが返されることがあります。アラートの配信と取得だけでは、完全な監査履歴は得られません。