AIエージェントの承認フローは、承認者の名前より「どの版のどの操作を誰がいつまで許可したか」を一件ずつ固定すると決めやすくなります。たとえば予算C-017を10000円から12000円へ変える案は差分と戻す値を添えて承認し、台本v1の承認後に商品主張を変えたv2は古い承認を使わず確認し直します。
本記事の金額・期間・日時・担当の記号は、すべて編集部の設計例で使う仮の値です。実際の運用実績や動作試験の結果ではありません。以下では、承認票に入れる項目、差分による再確認、差し戻し、版ごとの受け渡しと実行結果の記録の順に整理します。
AIエージェントの承認フローとは何か
承認依頼とは、AIが出した作業案を人が可否判断できる単位にしたものです。承認証跡とは、いつ、誰が、どの条件で通したかを後から追える記録です。実行結果とは、承認後にシステムへ出した操作が成功したか、失敗したか、まだ分からないかを分けて残す結果です。
承認フローの範囲
AIエージェントの承認フローは、AIの案を見て人が可否を決める所、承認後にシステムが実行する所、実行後に結果を照合する所に分けます。広告運用自動化では、日々の取得や転記は戻しやすい一方で、予算変更や配信停止は費用と機会損失に直結するため、失敗した時に戻せるかどうかで扱いを分ける考え方が使えます。(SynClip 広告運用自動化の記事)
MCPのツール仕様(2025-11-25版)では、モデルが外部システムへアクセスする道具を呼び出せる一方で、信頼性と安全性のために人が否認できる状態や確認プロンプトを置くことが推奨されています。(MCP Tools仕様 2025-11-25版・公式)2026年10月12日に確認した内容で、これは法的義務としてではなく、AIが外部の操作へ進む前に人が見る位置を設計する参考として扱います。
承認票に入れる項目
次の表は、C-017の例を一件の承認票として埋めたものです。承認者は金額の増減だけを見るのではなく、何のために変えるのか、どの期間の根拠を見るのか、いつ取得した情報なのか、戻す時の値が何かを同じ票で確認します。期間・日時・担当の記号は説明用の仮の値で、実際のアカウントから取得した数字ではありません。
横にスクロールして比較できます
| 項目 | 見る内容 | C-017の例 | 欠けた時 |
|---|---|---|---|
| 対象 | 変更する広告単位 | キャンペーンC-017 | 別対象へ誤適用しやすい |
| 変更前 | 現在の値 | 一日予算10000円 | 差分が見えない |
| 変更後 | 承認する値 | 一日予算12000円 | 承認範囲が曖昧になる |
| 理由 | 変更の目的 | 追加検証のため | 金額だけで判断する |
| 根拠期間 | 判断に使う集計期間 | 10/5〜10/11の7日間(仮の値) | 期間違いを混ぜる |
| 取得時刻 | データを取った時刻 | 10/12 09:00に取得(仮の値) | 古い数値に気づけない |
| 戻す値 | 取り消す時の値 | 10000円 | 復帰手順が詰まる |
| 担当者 | 申請と確認の役割 | 申請担当A/確認責任者B(仮の記号) | 誰が見たか残らない |
| 有効期限 | 承認が使える期限 | 10/12 18:00まで(仮の値) | 古い承認で進む |
未取得の指標は、取得済みのゼロや悪化として扱わず、不明として残します。Google広告のレポートでは、クリック数、インプレッション数、費用などの統計データは通常1時間ごとに更新される一方で、一部の指標は1日に1回しか更新されないため、取得時刻を残さない承認票では判断時点の前提がずれます。(Google広告ヘルプ データの更新頻度・公式)
広告数値を見る時は、期間違いの数値を同じ根拠として扱いません。Google Ads APIのレポート資料では、成果データはキャンペーン全体から個別キーワードまでのリソースを対象に取得でき、属性、セグメント、指標を組み合わせて扱う考え方が示されています。(Google Ads APIレポート概要・公式)承認依頼では、どの期間と粒度の数値かを取得時刻と一緒に残すと、後から見た時に根拠がずれにくくなります。
承認票に戻す値を入れる理由は、承認を通すためだけではありません。誤った変更や期限切れの承認に気づいた時、元の値へ戻す判断を人が取りやすくするためです。返答がないことを承認と扱わず、確認責任者が期限内に通した記録を残す形にします。
承認と実行は別物
承認済みでも、システムへの実行要求が失敗することがあります。承認時刻、実行要求時刻、成功、失敗、結果不明を同じ言葉でまとめると、承認したのに反映されていない状態や、反映されたか分からない状態を見落とします。成功と呼べるのは、現在値と履歴で変更の反映を確認できた状態だけです。
AWSの冪等性に関する資料では、同じ依頼を再試行しても副作用を増やさない設計が、重複作成のような望ましくない結果を避けるために説明されています。(AWS Builders' Library 冪等APIと再試行・公式)一方、同社の再試行に関する資料は、副作用のある操作は冪等性がなければ再試行しても安全とは言えず、過剰な再試行は負荷も増やすと述べています。(AWS Builders' Library タイムアウトと再試行・公式)すべての操作で同じ保証があるとは扱わず、広告予算の承認フローでは、同じ依頼の重複実行を避ける考え方として使います。冪等性とは、同じ依頼を再送しても副作用が一度だけに収まる性質です。
タイムアウトなどで実行結果が分からない時は、未実行と決めつけて同じ操作をすぐ繰り返さず、現在値、変更履歴、依頼の識別情報を照合してから次の動きを決めます。C-017なら、承認票の変更後が12000円で、現在値も12000円なのか、まだ10000円なのか、別の値に変わっているのかを見ます。未反映だと確認できてから再実行へ進み、承認証跡と実行結果を分けておくと、通した判断と実際の状態を別々に確認できます。
実行結果を評価する確認資料 関連記事を読む
変更内容で承認範囲を分ける
変更内容で承認範囲を分ける時は、承認者の返答そのものよりも、どの値と条件が承認対象だったかを先に固定します。再確認条件とは、元の承認から外れた変更をもう一度人へ戻す条件です。

元の案と同じ範囲
承認後に変更後予算を15000円へ変えるなら、同じC-017でも承認された金額の範囲を超えるため、再確認に戻します。対象、変更前後の値、理由、根拠期間、戻す値がひとまとまりで承認されているので、どれか一つが変わった時も同じ扱いです。
横にスクロールして比較できます
| 変わった物 | 元の承認 | 次の動き | C-017の例 |
|---|---|---|---|
| 金額 | 変更後12000円 | 再確認する | 15000円は範囲外 |
| 対象 | C-017だけ | 別対象なら戻す | C-018は別承認 |
| 理由 | 追加検証のため | 理由を見直す | 恒常増額なら再確認 |
| 期限 | 期限内だけ | 切れたら戻す | 期限後は再確認 |
| 元データ | 取得時刻の値 | 更新後は見直す | 古い数値は使わない |
| 実行先 | 承認票の範囲 | 外部送信は戻す | 送信先追加は再確認 |
期限と元データの変化
有効期限とは、承認者がその条件で判断した扱いにできる期限です。期限を過ぎた依頼や、根拠にした元データが更新された依頼は、同じ文面に見えても判断時点が変わるため再確認条件に入れます。
取得時刻が古い時は、特定の待機時間を決め打ちせず、承認者が見た根拠と現在の根拠が同じかを確認します。C-017の変更で集計期間や取得時刻が変わった場合は、12000円という値が同じでも、承認時の判断材料が残っているかを見直します。
差し戻しの往復
差し戻しは、AIへ直す項目だけを返すのではなく、残す根拠と変えてはいけない条件を、再提出期限と一緒に返します。再提出時に差分を絞って見られるからです。
短い差し戻し文面は、主観語を避けて条件を並べます。たとえば「C-017の変更後予算を15000円ではなく12000円に戻してください。理由は追加検証のためのまま残し、根拠期間と取得時刻を更新した場合は再確認に戻し、有効期限内に再提出してください」と返すと、AIが直す値と承認者が再び見る条件が分かれます。
通知文の例は「C-017の一日予算を10000円から12000円へ変更。追加検証のため。根拠は10月5〜11日の7日間で10月12日09:00取得。10月12日18:00まで有効。戻す値は10000円」です。通知にはこの要約を出し、理由の詳細と集計内訳は承認票へのリンクで確認する設計にします。
小さい参照と大きい操作
承認の厚さは、全処理を人へ戻すかどうかではなく、損失の可能性と取り消しやすさで変えます。資料の参照、候補理由の整理、下書きの作成は、外部状態を変えにくいため軽い確認に寄せられます。一方で予算変更、支払い、外部送信は、費用や相手先への影響が残るため、承認者、上限、戻し方を分けて置く必要があります。
同じ考え方は他の業務連携にも使えます。編集部の架空の問い合わせ連携例では、初期範囲を返信案の作成までにとどめ、外部送信とCRMのステータス変更を含めない設計にしています。読むだけの処理と、外部へ影響を出す処理を同じ承認ボタンへ入れない方が扱いやすくなります。連携範囲の決め方はAIと既存システムの連携範囲の決め方で整理しています。

台本の版ごとに承認を分ける受け渡し例
予算と同じ考え方は、台本・素材・納品の受け渡しにも使えます。編集部の設計例では、商品P-01の台本v1を確認担当Cが承認したあとに、AIが商品の特長を述べる一文を差し替えたv2を出したとします。v1とv2は文面の大半が同じでも、商品主張が変わった時点で別の承認対象です。v1の承認IDをv2に付け替えて素材制作へ渡すことはせず、担当Cが変更箇所と根拠資料を見直してから、v2に新しい承認IDを発行します。
横にスクロールして比較できます
| 項目 | 台本v1 | 台本v2 | 納品送信 |
|---|---|---|---|
| 承認対象の版 | v1(承認ID AP-101) | v2(商品主張の一文を変更) | v2の承認IDに一致する納品データ |
| 許可する操作 | 素材制作への受け渡し | 再承認までは受け渡し不可 | 納品先への送信1回 |
| 確認担当 | 商品事実の確認担当C | 担当Cが変更箇所を再確認 | 納品担当D |
| 期限 | 10/14 17:00まで(仮の値) | 再承認時に新しく設定 | v2の承認期限内 |
| 実行結果 | 受け渡し済み | 再承認待ち | 結果不明のため照会中 |
表の承認ID・担当の記号・期限はすべて仮の値です。納品担当Dは、手元のデータの版と承認IDが表の行と一致する場合だけ送信します。
納品送信がタイムアウトして結果が分からない場合は、同じデータをすぐ再送しません。まず送信依頼ID(例 DL-v2-01)で納品先の受領状況と送信記録を照会します。受領済みなら成功として記録して再送しません。未受領と確認できた場合だけ同じ依頼IDを付けて再送し、照会できなければ結果不明のまま担当Dへ戻します。これは二重送信を避けるための設計例です。特定の仕組みで実装や権限制御を試験した結果ではないため、受け取り側が依頼IDで重複を判別できるかは導入先で確かめます。
自社の業務で版・許可操作・確認担当・期限・実行結果を書き出す時は、この記事の記入例と空欄版を使うから始められます。ZIP内の記入ガイド.mdは、版ごとの承認台帳を作るための補助教材です。AIに任せる範囲や対象外そのものを決める段階では、既存のAI開発の要件定義シートの「変更後再承認」欄を先に埋めて併用します。
導入先の仕組みで確かめること
導入する仕組みでは、承認した内容を後から変更できるか、変更すると再確認へ戻るか、実行結果を記録できるかを確かめます。製品名だけで判断せず、同じ依頼で金額変更、期限切れ、結果不明の各条件を試す受入項目として残すと比較できます。
広告運用全体での担当と承認の分け方 関連記事を読む
自社の業務で試す
AIの変更案を人が確認する流れはインパクトトライアル(最短1ヶ月のスピード検証)で検証する対象として相談できます。自社の業務資料や承認条件を使った試作を毎週更新し、合意した指標で変化を確かめます。



