AIエージェントの承認ログには何を残すべき？後から説明できる記録設計

AIエージェントに Human-in-the-loop を入れると、危険な操作の前に人間が承認できます。
ただし、承認ボタンを押せるだけでは不十分です。

あとで問題が起きたときに、

• 誰が承認したのか
• 何を承認したのか
• AIは何を根拠に提案したのか
• 承認後に実際に何が起きたのか

を説明できなければ、承認フローは形だけになります。

この記事では、2026年4月21日時点の OpenAI Agents SDK と NIST AI RMF の公開情報を確認しながら、AIエージェントの承認ログに何を残すべきかを実務目線で整理します。

承認ログは監査ログの一部

AIエージェントの承認ログは、広い意味では 監査ログ の一部です。
つまり、作業者を責めるための記録ではなく、問題が起きたときに事実を追い、説明し、改善するための記録です。

OpenAI Agents SDK の Human-in-the-loop では、approval が必要な tool 呼び出しで run が中断され、承認または拒否後に再開する流れが説明されています。
このとき、ただ 承認済み とだけ残すのではなく、承認対象と判断材料をセットで残す必要があります。

NIST AI RMF でも、AIリスク管理では human oversight のプロセスを定義・評価・文書化する考え方が示されています。
承認ログは、この文書化と説明責任を支える材料になります。

最低限残したい項目

まず、AIエージェントの承認ログで最低限残したいのは次の項目です。

このくらい残っていれば、少なくとも 何が起きたか を追いやすくなります。

1. 承認対象の操作

最初に必要なのは、何を承認したのかです。

たとえば、

• メール送信
• Slack投稿
• チケット起票
• DB更新
• ユーザー削除
• 権限変更
• 本番デプロイ
• クラウドリソース作成

のように、操作の種類を明確に残します。

ここが曖昧だと、あとで 何に対して承認したのか が分からなくなります。
特にAIエージェントでは、内部的に複数の tool call が連続することがあるため、承認対象の粒度をそろえることが大切です。

2. 入力パラメータ

承認ログには、実行予定だった入力パラメータも残します。

たとえばメール送信なら、

• 宛先
• 件名
• 本文の要約
• 添付ファイルの有無

DB更新なら、

• 対象テーブル
• 対象レコード条件
• 更新内容
• 件数見込み

のような情報です。

ただし、本文や個人情報をそのまま残すとログ自体がリスクになります。
全文保存が必要な場合でも、閲覧権限、保存期間、マスキングを決めておきます。

3. AIの提案理由

AIがなぜその操作を提案したのかも残した方がよいです。

たとえば、

• エラー解消のためにこの設定変更が必要
• 顧客への回答期限が近いのでメール送信が必要
• テストに失敗したため再実行が必要
• 権限不足を解消するためロール変更が必要

のような理由です。

ここを残しておくと、承認者が何を見て判断したのかを後から追いやすくなります。
逆に、理由が空欄のまま承認だけ残っていると、実質的には「ボタンを押した記録」にしかなりません。

4. 承認者と承認権限

承認者のユーザーID、所属、ロール、承認権限も重要です。

誰が承認したか だけではなく、その人が承認してよい操作だったか も追えるようにします。
たとえば、本番デプロイの承認者と、顧客メール送信の承認者は違うかもしれません。

権限設計と承認ログをつなげておくと、あとから 権限外の人が承認していないか を確認しやすくなります。

5. 承認結果と拒否理由

承認ログには、承認だけでなく拒否も残します。

拒否理由が残っていると、AIエージェントの改善に使えます。

• 宛先が違う
• 本文に機密情報が含まれる
• 本番反映の時間帯が不適切
• 変更範囲が広すぎる
• 人間レビューが不足している

のような拒否理由は、次回の guardrail や prompt、tool設計の改善材料になります。

6. 実行結果

承認したあとに、本当に実行されたのか。
実行は成功したのか、失敗したのか。
失敗したならロールバックしたのか。

ここまで残さないと、承認と実行がつながりません。

OpenAI Agents SDK の Human-in-the-loop は、承認後に run を再開する形です。
そのため、承認イベントと、その後の tool 実行結果を trace ID や run ID でつなげる設計が重要です。

7. guardrailや検証結果

承認前に ガードレール や検証を通したなら、その結果も残します。

たとえば、

• DLPチェック結果
• スキーマ検証結果
• 禁止語検出
• 宛先ドメイン確認
• 本番環境フラグ
• 影響件数の見積もり

などです。

承認者が見た検証結果を残しておくと、後から なぜ承認できると判断したのか を説明しやすくなります。

残しすぎると危険な情報

承認ログは大事ですが、何でも残せばよいわけではありません。

特に注意したいのは次の情報です。

• 個人情報
• 認証情報
• APIキー
• 顧客の機密情報
• 契約書全文
• 脆弱性情報
• 本番ログの詳細
• プロンプト全文

これらを無制限に保存すると、ログが第二の情報漏えい経路になります。
必要な場合でも、マスキング、暗号化、アクセス制御、保存期間、削除手順を決めます。

承認画面とログの内容は一致させる

実務で見落としやすいのが、承認者が見た情報とログに残る情報のズレです。

承認者が見ていない情報をあとからログに足しても、それを見て承認した とは言えません。
逆に、承認画面には出ていたのにログへ残っていないと、後から判断材料を確認できません。

承認画面に出す主要項目と、承認ログに残す主要項目はそろえる方が安全です。

実務でのログ例

実装上は JSON のような構造化ログにしておくと扱いやすいです。

{
  "approval_id": "appr_20260421_001",
  "run_id": "run_abc123",
  "agent": "deployment-agent",
  "tool": "deploy_production",
  "action": "production_deploy",
  "target": {
    "service": "billing-api",
    "environment": "production"
  },
  "risk_level": "high",
  "reason": "Fix payment callback error confirmed in staging",
  "proposed_by": "ai-agent",
  "approved_by": "user_42",
  "decision": "approved",
  "decided_at": "2026-04-21T04:38:00Z",
  "execution_status": "succeeded"
}

実際には、ここに変更前後、影響範囲、検証結果、拒否理由、ロールバック結果などを足します。

最低限の設計チェックリスト

AIエージェントの承認ログを設計するときは、次を確認すると抜け漏れを減らせます。

• 承認対象の操作が明確か
• 承認者と権限が残るか
• 入力パラメータが残るか
• AIの提案理由が残るか
• 承認画面に表示した内容とログが対応しているか
• 拒否理由も残るか
• 承認後の実行結果まで追えるか
• run ID / trace ID で前後の処理とつながるか
• 機密情報を残しすぎていないか
• 保存期間と閲覧権限が決まっているか

このあたりがそろっていれば、承認ログはかなり実務で使える状態になります。

まとめ

AIエージェントの承認ログには、承認者、対象操作、入力パラメータ、AIの提案理由、承認または拒否の結果、実行結果、時刻、run ID / trace ID を残すのが基本です。
ただし、プロンプト全文や機密情報を無制限に残すと、ログ自体がリスクになります。

大事なのは、

• 承認者が何を見て判断したか
• 承認後に何が実行されたか
• 問題が起きたときに説明できるか

を後から追えることです。
承認をどこに置くかは、人間承認をどこで入れるべき？AIエージェントの承認設計を整理 もあわせて読むとつながりやすいです。

参考リンク

• OpenAI Agents SDK: Human-in-the-loop
• OpenAI Agents SDK: Handoffs
• OpenAI Agents SDK JS: Guardrails
• NIST: AI RMF Core