広告運用のAI自動化は
「取り消せる仕組み」から作る

広告運用のAI自動化で先に作るのは「取り消せる仕組み」

AIエージェントに広告APIを触らせると、入札、予算、配信停止といった変更を人の手より速く、大量に実行できます。

その一方で、誤った変更も同じ速さで積み上がります。

私たちが運用している広告操作ツールは、食品を扱うECの広告アカウントで使っているものです。Amazon広告用とYahoo!検索広告用の2本があり、どちらもAIエージェントから呼び出すMCPサーバーとして作っています。

設計の前提は次の3つです。

• 書き込みの既定は「試し実行（dry-run）」にする
• 全ての書き込みを台帳に残す
• 承認が要る変更と要らない変更を、人の判断ではなくシステムで分ける

AIの判断精度を上げる話は、この記事では扱いません。判断が外れたときに被害を小さく止め、元に戻せるようにする側の話です。

2段の鍵と絶対上限

書き込み操作は、実行までに2段の鍵を通します。

• 1段目は confirm。試し実行のまま終わらせず、実行する意思を明示します
• 2段目は approve。変更幅が大きい場合だけ、人の承認を求めます

さらに、絶対上限（キャップ）を設定ファイルに持たせています。上限を超える変更は、承認があっても拒否します。承認とは別に、誰が押しても越えられない線を1本持っておく形です。

変更台帳：AIの変更を1件1行で残す

変更履歴の土台は、全ての書き込みを1件1行で残すJSONL形式の台帳です。

各行には次の項目を持たせています。

• 操作ID
• 日時
• 使った操作名
• 対象の種類とID
• 変更前の値
• 変更後の値
• APIが成功したかどうか
• 状態
• 承認の有無
• 呼び出し元（テスト実行かどうかのフラグを含む）
• 取り消し済みかどうか

Yahoo!検索広告側には、さらに変更額、変更率、承認が必要だったか、誰が決めたか（自動か承認か）を記録しています。

変更前の値を必ず残す理由

台帳で最も重要なのは「変更前の値」です。元に戻すときの戻し先は、この値そのものだからです。

変更後の値だけを残していると、戻すたびに人が過去の画面や記憶を探すことになります。AIが1日に多数の変更をした場合、この作業は現実的ではありません。

台帳の読み方を2種類に分ける

台帳の読み方は、用途で2つに分けています。

• 画面表示用は、壊れた行があっても読める分だけ返します。ただしエラーは必ず出します
• 1日の累計変更のガードのような安全判定は、壊れた行が1行でもあれば止まる厳格な読み方を使います

表示は多少欠けても業務が進みます。しかし安全判定が壊れた台帳を黙って読み飛ばすと、実際より少ない累計を前提に変更を許してしまいます。読み方を分けているのはそのためです。

ロールバック：戻せる操作と戻せない操作を分ける

元に戻す機能は、全ての操作に付けられるわけではありません。先に、戻せる操作と戻せない操作を分類しておきます。

戻せる操作は、変更前の値で戻せます。

• 入札の変更
• 予算の変更
• 配信状態の変更
• 掲載枠の調整率
• キーワードの追加

戻せない操作は、自動では戻しません。

• キーワードの削除（アーカイブは終端状態のため）
• 除外キーワードの追加
• 除外商品ターゲットの追加

戻せない操作は台帳にどう出るか

Amazon広告側の直近60件（2026-09-14〜09-28）を確認すると、60件すべてがAPI成功で、取り消しは0件でした。

承認の内訳は次のとおりです。

• 承認つき：50件
• 承認不要帯で自動実行：6件
• 承認欄が空：4件

承認欄が空の4件は、すべて除外キーワードの追加でした。承認の判定対象になっておらず、かつ自動では取り消せない操作です。

この4件から分かるのは、戻せない操作ほど、承認の設計を別に考える必要があるということです。台帳を集計しない限り、承認欄が空の操作が存在することにも気づけません。

戻し先が数値とは限らない

変更前が「未設定（上位の既定値を引き継ぐ）」だった記録もあります。この場合、戻し先は数値ではありません。

戻す処理は「未設定に戻す」を扱えなければなりません。0や空文字に置き換えてしまうと、元の状態とは別の状態になります。

承認のしきい値：取り消し操作も同じ関門を通す

承認のしきい値は、変更の大きさと向きで決めます。ここで最も見落としやすいのが、取り消し操作の扱いです。

取り消しが抜け道になる例

ロールバックだけを「元に戻すだけだから安全」と扱うと、次の2手で承認と上限チェックを迂回できます。

• 配信を停止する。その後、取り消しで再開する
• 掲載枠の上乗せを0%にする。その後、取り消しで大きな値に戻す

1手目は支出を減らす向きなので、承認なしで通る設定もあり得ます。2手目が取り消しであれば関門を通らず、結果として承認も上限チェックもなしに支出を増やせてしまいます。

そこで、ロールバックも通常の変更と同じ関門を通します。

• 支出を再開・増加させる向きの取り消しは、承認が必要
• 上限を超える取り消しは、承認があっても拒否

「停止へ戻す向き」も承認必須にした経緯

2026-08-04に、もう1つ規則を足しました。停止へ戻す向きの取り消しは、影響規模にかかわらず常に承認必須とする、という規則です。

理由は次の抜け道です。「配信開始（承認つき）を実行し、取り消す」を繰り返せば、一括停止の承認を経由せずに、何本でも配信を止められてしまいます。

この抜け道は、想定で書いただけではありません。検証役のAIに実際に試させたところ、5件連続で通りました。修正後は、承認なしで実行された件数が0であることをテストで確認しています。

微調整帯の操作と、共有する枠

予算には、微調整帯専用の操作も用意しています。承認不要帯の日常チューニング用です。

• 承認帯や遮断帯にかかる変更は、この操作では実行しません
• 大きい変更は、承認つきの通常操作で行います
• 1日の累計変更枠、絶対上限、下限は、通常操作と微調整操作で共有します

枠を共有するのは、小刻みな変更を重ねて上限をすり抜けることを防ぐためです。

Yahoo!検索広告側の実例

Yahoo!検索広告側の記録には、次の実例があります。

• キャンペーンの日予算を600円から1,000円に変更（+400円、+66.7%）。承認が必要と判定され、承認を経て実行
• キャンペーンの配信停止。承認なしの自動判定で通った記録がある
• 停止中の広告の再開。承認を経ていた

少なくともこの記録では、支出を戻す向きの操作に承認がかかっています。

台帳を読んで分かったこと

台帳は、あとから事故を調べるためだけのものではありません。APIの成功応答を鵜呑みにしないための材料にもなります。

成功と記録されたのに、実際は外れていなかった変更

Amazon広告側の2026-09-21の記録に、次の並びがありました。

• 掲載枠の上乗せ率を50%から0%にする変更を「空の指定」で送信。API成功で記録
• 16分後、同じ変更を明示的な0%で送信。このときの「変更前の値」は、まだ50%

記録上は、1回目は成功扱いでも、実際には設定が外れていなかったと読めます。

この記録から言えるのは、APIの成功応答だけで完了と判断せず、変更前の値を毎回読み直して残す意味があるということです。変更前の値を毎回記録していたので、後から台帳を読むだけでこの食い違いが見えました。

何もしなかった操作も1行として残る

変更前と変更後が同じ値（1,500から1,500）の書き込みも、1行として台帳に残っています。

件数だけで作業量を判断すると、実質的な変更のない操作まで数えてしまいます。台帳を集計するときは、変更前後の値が違う行がどれだけあるかを見ます。

どこまでAIに任せ、どこから人が判断するか

ここまでの内容を、任せる範囲の線引きとしてまとめます。

AIに任せてよい範囲

• 試し実行（dry-run）による変更案の作成と確認
• 承認不要帯の日常的な微調整（入札・予算の小さな変更）
• 支出を減らす向きの変更のうち、承認不要帯に収まるもの
• 台帳への記録と、変更前の値の読み直し

人が判断する範囲

• 変更幅が大きい入札・予算の変更
• 停止中の広告の再開など、支出を増やす向きの変更
• 支出を再開・増加させる向きの取り消し
• 停止へ戻す向きの取り消し（影響規模にかかわらず常に）
• 除外キーワードの追加やキーワードの削除など、自動で戻せない操作の扱いの見直し

導入の順番

AIに広告運用を任せるときの順番は、次のとおりです。

• 書き込みの既定を試し実行にする
• 変更前の値を含む台帳を作る
• 戻せる操作と戻せない操作を分類する
• 取り消しも通常の変更と同じ関門に通す
• 絶対上限を設定ファイルに持つ
• 承認なしで実行された件数を、テストで確認する

承認や上限のルールは、AIの善意や人の注意力に頼らず、ツール側で強制します。取り消し操作はその抜け道になりやすいため、最初から関門の内側に置いておくのが安全です。

なお、ここで紹介した数値は、食品を扱うECの広告アカウントでの直近60件などの限られた記録です。運用規模や広告の構成が違えば、承認帯の設定値も変わります。自社の変更履歴を集計し、どの操作が承認の対象外になっているかを確認するところから始めてください。