# 承認フロー非同期設計——コールバックトークンとエスカレーション > AIエージェントの承認フローは実行をブロックせず、コールバックトークンで一時停止しタイムアウトで自動エスカレーションする非同期設計が本番運用の基本です。 - Canonical: https://kuucorp.com/blog/agent-approval-workflow-async-callback-design/ - Date: 2026-08-15 - Last modified: 2026-08-15 - Publisher: Kuu株式会社 (https://kuucorp.com) --- 発注確定や顧客への一括送信をエージェントに任せると、必ず「誰かの承認を挟みたい」という要件にぶつかる。だがAPI呼び出しをブロックして承認を待つ同期実装は、エンタープライズ規模では数分でタイムアウトし、承認者不在の夜間に処理全体が止まる。[エージェントガバナンス](/glossary/agent-governance/)の観点でも、承認フローはポリシーではなくアーキテクチャの問題だ。本稿ではコールバックトークンによる非同期化、タイムアウト・エスカレーション設計、そして承認疲れを防ぐ運用設計までを実装レベルで整理する。 ## 承認フローをリクエスト-レスポンスで実装するとなぜ壊れるのか > 同期的な承認待ちはAPIゲートウェイのタイムアウト・トークン失効・承認者不在で必ず破綻する設計だ。 エージェントの実行ループの途中で「承認APIを呼んでレスポンスを待つ」実装は直感的だが、本番では成立しない。承認は人間が対応するため数分〜数時間かかるが、APIゲートウェイのタイムアウトは大半が30〜60秒で切れる。長時間コネクションを維持すればワーカースレッドを占有し続け、同時実行数がボトルネックになる。加えて承認待ちの間にセッショントークンが失効すれば、承認後の再開処理自体が失敗する。 正しい設計は「エージェントは承認待ちのアクションを永続ストアに退避し、他のタスクの処理を続ける」非同期モデルだ。承認は独立したプロセスとして扱い、エージェントの実行ループとは疎結合にする。 ## コールバックトークンで承認を非同期化するにはどう設計するか > 承認対象アクションは「提案」として永続化し、トークンが返ってから初めて「実行」に昇格させる設計にする。 非同期承認の骨格は**提案（propose）と実行（commit）の分離**だ。エージェントは実行したいツール呼び出しをそのまま実行せず、構造化されたアクションのペイロードとして永続ストアに保存し、一意のトークンを発行してSlackやメール、承認UIに提示する。人間の判断結果がトークンとともに返ってきた時点で初めて実際のツール呼び出し（commit）を行う。 このパターンはAWS Step Functionsの`.waitForTaskToken`統合が標準実装として示している。ワークフローはSQSやSNS経由でタスクトークンを外部システムに送り、`SendTaskSuccess`または`SendTaskFailure`が呼ばれるまで実行を一時停止する。エージェント基盤に置き換えると、ツール呼び出し1件をタスクトークン付きでキューに送り、承認UIからのコールバックで再開する構造になる。実行（commit）側にはべき等キーと事前条件の再検証を必ず挟む。トークン発行から承認まで数時間空くこともあり、その間に対象データが変化している可能性があるためだ。[エージェントの冪等性設計](/blog/agent-idempotency-at-least-once-design/)で扱うat-least-once実行の考え方はこの再開処理にそのまま適用できる。 ## タイムアウトとエスカレーションはどう設計すべきか > 承認待ちには必ずハートビートタイムアウトを設定し、無応答時は次の承認者へ自動エスカレーションする。 トークンが永久に返ってこないケース——承認者の休暇、通知の見落とし——に備え、タイムアウトを必須の設計要素にする。Step Functionsの`HeartbeatSeconds`はこの典型で、指定秒数以内にトークンが返らなければ`States.Timeout`エラーでタスクを失敗させる。エージェント側の実装でも同様に、承認リクエストごとに有効期限を持たせ、期限切れは自動失敗として扱う。 単純な失敗ではなく、エスカレーションチェーンを組むとより実務に合う。一次承認者が一定時間内に応答しなければ、次の承認者（上長、または別チームの当番）に自動転送し、それも無応答なら安全側のデフォルト（自動却下、または人間へのブロッキングアラート）に倒す。承認対象のリスクによって初期タイムアウトとエスカレーション段数を変える設計も有効だ。読み取り専用・可逆・外部影響あり・不可逆の4段階でアクションを分類し、不可逆アクションほどタイムアウトを短く、エスカレーション段数を多くする。 ## 承認疲れ（アプルーバル・ファティーグ）はどう防ぐか > 1件ずつの承認を義務化すると人間は次第に注意を払わなくなるため、監視と介入を軸にした設計が有効だ。 承認フローを設計するときに見落とされがちなのが、人間側の注意力の劣化だ。Anthropicがエージェントの自律性を計測した調査では、利用経験が浅いユーザーはセッションの約20%でフル自動承認モードを使う一方、750セッション以上の経験者では40%超に増える。興味深いのは、自動承認が増えても介入（Claudeへの割り込み）の頻度はむしろ増加している点で、経験者の割り込み率は約5%から約9%に上昇する。これはユーザーが「1件ずつ承認する」から「エージェントの挙動を監視し、必要なときに介入する」戦略へ移行していることを示している。 同調査は、あらゆるアクションに人間の承認を義務付けるような画一的な監督要件は、安全性の向上を伴わずに摩擦だけを生むと明言している。設計上の含意は明確だ。承認ゲートは不可逆・高リスクなアクションに絞り込み、可逆・低リスクなアクションは自動承認かログのみの通知に倒す。可視性の高い実行トレースと簡単な介入手段（一時停止・差し戻しボタン）を用意するほうが、承認プロンプトの数を増やすより実効性のあるガバナンスになる。 ## エンタープライズ実装で見落としやすいポイントは何か > 承認イベントは監査ログと同じ改ざん防止基盤に記録し、複数承認者間の定足数ロジックも設計に含める。 承認・却下・タイムアウト・エスカレーションの全イベントは、[監査ログのスキーマ設計](/blog/audit-log-tamper-proof-schema-design/)で扱うような改ざん防止基盤に記録する。誰が・いつ・どの根拠で承認したかは、事後のインシデント調査や規制対応で必ず必要になる。複数承認者が必要な高リスクアクションでは、単純な「誰か1人が承認すればOK」ではなく、定足数（quorum）ロジック——例えば2名中1名の承認では不十分で、指定ロール2名の承認が必要——を状態機械に組み込む。承認フローの状態遷移自体は[エージェントハーネスの状態管理](/blog/agent-harness-state-management-retry-design/)と同じチェックポイント設計の延長線上にあり、プロセス再起動時に承認待ち状態を失わない永続化が前提になる。エンタープライズ規模の承認フロー・監査基盤の設計支援は[Kuu株式会社のRDEサービス](/services/rde/)で提供している。 ## 参考 - [Building Effective AI Agents — Anthropic](https://www.anthropic.com/engineering/building-effective-agents) - [Measuring AI agent autonomy in practice — Anthropic](https://www.anthropic.com/news/measuring-agent-autonomy) - [Discover service integration patterns in Step Functions — AWS](https://docs.aws.amazon.com/step-functions/latest/dg/connect-to-resource.html) ## まとめ 承認フローを同期APIで実装すると、タイムアウトと承認者不在で必ず破綻する。コールバックトークンで「提案」と「実行」を分離し、ハートビートタイムアウトとエスカレーションチェーンで無応答に備える非同期設計が本番運用の基本形だ。加えてAnthropicの計測が示すように、1件ずつの承認義務化はかえって人間の注意力を削ぐ。不可逆・高リスクなアクションに承認ゲートを絞り込み、可視性の高い監視と介入手段を組み合わせる設計が、承認疲れを避けながらガバナンスを実効あるものにする。 大規模なエージェント基盤で承認フロー・監査基盤の実装を検討している場合は、[Kuu株式会社のRDEサービス](/services/rde/)にご相談ください。