内容が変われば承認を無効にする「実行指紋」

AIエージェントが作ったメールや更新内容を人が承認した後、送信直前に宛先や本文が変わったら、その承認は使えるでしょうか。開発責任者向けに、承認を実行内容へ固定する「実行指紋」と、変更時に必ず差し戻す手順を作ります。

承認は「操作名」ではなく「今回の内容」に付ける

「メール送信を承認」のようにツール名だけへ許可を付けると、別の宛先や添付にも再利用されかねません。承認対象は、誰が、どの実行で、どのツールを、どの引数と成果物で、いつまで使えるかの組み合わせです。

OpenAI Agents SDKでは、承認待ちのツール呼び出しにエージェント名、ツール名、引数などが含まれ、個別の判断は特定のcall IDに紐付きます。[1] この考え方を業務実装へ広げ、表示した内容と実行する内容が同一かを指紋で照合します。

コピーして使える承認受領票

実行指紋は、承認画面に表示した値を正規化し、同じ順序で連結してハッシュ化します。秘密情報そのものは表示・保存せず、秘密の参照IDと版だけを対象に含めます。

approval_receipt:
  approval_id: apr-2026-1016-0042
  run_id: billing-followup-42
  tool: send_email
  actor: finance-agent
  target:
    to: [customer@example.jp]
    cc: []
  payload:
    subject: 請求内容のご確認
    body_artifact: artifact://mail-body-v3
    attachment_ids: [invoice-2026-09-v2]
  constraints:
    max_recipients: 1
    execute_before: 2026-10-16T17:00:00+09:00
    single_use: true
  fingerprint: sha256:...
  reviewer:
    user_id: reviewer-017
    decided_at: 2026-10-16T15:12:00+09:00
    decision: approved

ハッシュの入力にはrun_id、tool、actor、target、payload、constraintsを含めます。JSONならキー順を固定し、空文字、未指定、空配列を区別します。添付はファイル名ではなく、変更時に版が変わる不変IDまたは内容ハッシュで参照します。

承認から実行までを5段階に分ける

1. 候補操作を凍結する

エージェントが送信や更新を提案した時点で、引数と成果物を読み取り専用の候補として保存します。承認画面はこの保存物から描画し、モデルが生成を続けている途中の値を直接表示しません。

2. 人が影響を確認する

レビュアーにはツール名だけでなく、対象、変更前後、添付、期限、取り消し可能性を見せます。サーバー側で本人認証と権限確認を行い、クライアントから送られたユーザーIDを信用しません。OpenAIの実装ガイドも、承認状態をサーバー管理し、レビュアーの認証・認可、保留中の要求との照合、再送防止を求めています。[1]

3. 受領票を一度だけ発行する

承認された候補から実行指紋を計算し、期限とsingle_useを付けます。承認ボタンの二重送信に備え、approval_idの状態をpendingからapprovedへ原子的に更新します。

4. 実行直前に再計算する

実行ワーカーは、現在の引数と成果物から指紋を再計算します。不一致、期限切れ、使用済み、レビュアー権限失効のいずれかなら実行せず、新しい承認要求を作ります。「軽微な修正だから」と本文差分を無視しません。

5. 使用済みにして結果を結ぶ

外部操作を始める直前に受領票をconsumingへ遷移させ、成功後は外部システムの受領IDとともにconsumedへ変えます。AWS Step Functionsのコールバック方式も、ワークフローを一時停止し、対応するタスクトークンが成功または失敗の応答とともに返るまで進めない仕組みです。[2] 同様に、承認待ちと実行済みを別状態で管理します。

仮想例：請求確認メールの宛先が変わった

たとえば、経理担当者が顧客Aへの確認メールを15時12分に承認した場面です。承認後、エージェントがCRMを再読し、宛先を担当者個人から共有窓口へ変更しました。実行直前の指紋は受領票と一致しないため、送信は停止します。

新しい承認画面では、宛先差分だけでなく本文、添付、期限を再表示します。担当者が再承認した後、新しいapproval_idで一度だけ送信します。完了条件は、送信時の指紋と承認時の指紋が一致し、受領票がconsumed、メール側のメッセージIDが保存されていることです。

参照専用で、結果が外部状態を変更しないという場合には向きません。毎回の凍結と照合が負担になるためです。送信、公開、削除、支払い、権限変更など、後戻りの費用が大きい操作から適用します。

明日から使える実装チェックリスト

[ ] 承認候補を読み取り専用で保存する
[ ] 対象、引数、成果物、期限を承認画面へ出す
[ ] JSONの正規化規則を一つに固定する
[ ] 添付と成果物を版または内容ハッシュで参照する
[ ] 承認者をサーバー側で認証・認可する
[ ] 承認受領票に期限と一回限りの状態を持たせる
[ ] 実行直前に指紋を再計算する
[ ] 不一致時は自動修正せず再承認へ戻す
[ ] 外部受領IDを使用済み受領票へ結び付ける

最初のテストでは、承認後に宛先、本文、添付、期限を一つずつ変更します。四つすべてで操作が停止し、元の承認を再利用できなければ、承認は表示内容へ正しく結び付いています。

参考資料

本記事はAIを活用して作成し、公開前に自動レビューを実施しています。情報の確認日：2026-10-16。