第5章 広告運用を自動化する

広告運用は工程ごとのスキルに分けて回す

運用型広告とは、媒体の入札の仕組みに予算と配信先を預け、実績を見ながら調整を続ける広告のことです。検索広告、Facebook や Instagram のフィード広告、TikTok の動画広告、LINE のトーク一覧に出る広告。どれもここに入ります。この章では、その運用を API とエージェントで回す方法を扱います。クリエイティブ（画像・動画・文言）の作り方は第 4 章に譲り、ここで書くのは「作ったものを出し、測り、直す」側だけです。

工程は 7 つ。1 つのスキルに全部を書かない

与件把握、媒体選定、クリエイティブ準備、遷移先ページの準備、入稿と配信開始、運用チューニング、レポート。工程はこの 7 つです。これを 1 つのスキル（第 2 章）に書き切ろうとすると、手順書が長くなりすぎて実行者が読まなくなります。著者は工程ごとに担当スキルを分け、順番と受け渡しだけを管理する「オーケストレータ」のスキルを 1 つ置いています。

オーケストレータに持たせるものは 3 つに絞ります。どの順番でどのスキルを呼ぶか。各工程の出力（与件サマリー、媒体選定レポート、台本一式、遷移先の URL と計測設定、入稿完了状態、運用ログ、月次実績）を次の工程の入力として明示的に渡すこと。そして、どの工程を省略してよいか。新規案件はフル、既存案件への追加は検証設計だけ簡略化、稼働中の調整とレポートだけならクイック、の 3 段階です。ただし媒体選定と入稿前の環境チェックだけは、どの段階でも省きません。媒体を決め打ちした入稿と、環境チェック抜きの入稿。事故の定番はいつもこの 2 つです。

実働はサブエージェント（第 2 章）に切り出し、メインの会話に戻すのは成果物のファイルと要点だけ。リサーチも設計も、ツールの結果でコンテキストを大量に消費するからです。逆に、配信・停止・大幅な増額の判断はメインに残します。途中で落ちたら部分成果物を引き継ぎ、ゼロからはやり直しません。

例: 実績の取得を任せるサブエージェントの定義

切り出す単位の例として、実績の取得だけを担当するサブエージェントの定義を示します。Claude Code では、frontmatter（name・description・使えるツール・モデル）と本文を書いたファイル 1 本で定義します。ツール名は説明のための仮の名前です。実際には、つないだ MCP サーバーのツール名を書きます。

---
name: ad-results-fetcher
description: >-
  広告媒体の実績を、指定された媒体・広告アカウント・期間・階層で取得し、
  CSV と取得メモを保存して返す。集計・評価・レポートの文章は書かない。
  広告の作成・停止・予算変更はしない（頼まれても実行せず、親に返す）。
tools: list_ad_accounts, get_ad_insights, Read, Write
model: haiku
---
あなたは広告実績の取得だけを担当します。

## 受け取るもの
- 媒体名、広告アカウント ID（親が一覧から確定したもの）、期間、階層

## 手順
1. 広告アカウントの一覧を取得し、受け取った ID があることとアカウント名を確かめる
2. 実績を日次で取得する。結果が複数ページに分かれていれば最後のページまで取る
3. 取れなかった日・指標は 0 で埋めず空欄にし、メモに「未取得」と理由を書く

## 返すもの（これ以外は返さない）
- 保存した CSV のパス、行数、期間、アカウント名
- 単位のメモ（金額の単位、CTR の単位、成果として数えた行動）
- 未取得の項目と、取得できなかった理由

この定義を「取得だけ」に切ったのは、実績の取得がツールの結果でコンテキストを大量に消費する作業だからです。集計や評価まで持たせると、返ってくるのは表と文章になり、メインの会話はそれを抱えたまま続くことになります。そこで description で集計とレポートの文章を外し、返すものを保存先のパスと数行のメモに限りました。渡すツールは読み取りの 2 つとファイルの読み書きだけ。依頼文の書き方を誤っても、このサブエージェントには広告を止める手段がありません。「頼まれても実行せず、親に返す」の一文は、配信・停止・増額の判断をメインに残す分担を、サブエージェントの側からも守らせるためのものです。

手順 1 では一覧を取らせ、アカウント名まで確かめさせています。ID の誤りは権限不足と同じエラーになって区別できず、別のアカウントの数字が出ても、名前を見る以外に気づく手段が無いからです（原則 F）。手順 2 の「最後のページまで取る」は、一覧を 1 ページずつしか返さない媒体への備えで、1 ページ目だけで集計すると合計が欠けます（原則 C）。手順 3 で 0 埋めを禁じた理由は単純です。0 が入った瞬間に平均も前月比も崩れ、CV が 0 件の対象が「CPA 0 円」の優良な広告に見えてしまいます。返すものに単位のメモを入れたのは、CTR の単位が媒体で違い、次の工程が値の大小から単位を推測すると 100 倍ずれるためです（原則 D）。「成果として数えた行動」も添えさせます。成果の決まり方は媒体ごとに違い、書いていないと次の工程が別の定義の件数を 1 つの CPA に混ぜるからです。定型の作業なので、モデルは軽量なものにしています。媒体・アカウント・期間・階層は案件ごとに依頼文で渡し、単位と未取得の扱いはこの定義の側に固定しています。

例: 工程を渡す依頼文

サブエージェントは、メインの会話の内容を引き継ぎません。受け渡しはファイルと依頼文だけで行うので、依頼文には毎回同じ 4 つを書きます。使うスキルの名前、与件の要約の全文、前の工程の成果物の保存場所、出力先の保存場所です。

広告レポートのスキルを使って、次の作業をしてください。

与件: 温泉旅館（県内 1 館）。Meta 広告と Google 広告で宿泊予約を集めている。
成果として数えるのは予約完了。月の広告費は 30 万円。目標 CPA は 6,000 円。

前の工程の成果物（作業の前に必ず読んでください）:
- 媒体選定レポート: work/ryokan/media-selection.md
- 先月の実績の CSV: work/ryokan/results-2026-08.csv

出力: work/ryokan/report-2026-08.md に Markdown で保存してください。

返答は、保存したファイルのパスと要点 5 行以内だけにしてください。レポートの本文は返さないでください。
広告の停止や予算の変更はしないでください。必要だと考えたことは提案としてレポートに書いてください。

返答を「パスと要点 5 行」に限ったのには理由があります。レポートの全文がメインの会話に戻ると、以降のやり取りのたびにその分のコンテキストを消費し続けるからです。与件を要約ではなく全文で渡すのも同じ発想で、サブエージェントには与件を聞き返す相手がいません。

7 つの工程を順に渡すオーケストレータは、手順書にすると次の形です。description には依頼の言い方と、扱わない依頼の行き先を書きます（第 2 章）。載せたのは骨子だけなので、使うときは本文の規則を足してください。

---
name: ad-operations
description: >-
  広告運用の全工程を、工程ごとのスキルへ渡しながら回す。
  「広告を一気通貫で」「広告の PDCA を回したい」「媒体選定からレポートまで」で使う。
  ※工程 1 つだけならその工程のスキルを直接使う（このスキルは自分では作らない）。
---
# 広告運用の全工程

## 工程と渡す先
1. 与件把握（目標 CPA・月予算・CV の定義・禁止表現）——このスキル
2. 媒体選定 → 媒体選定のスキル（第 3 章）
3. クリエイティブ → コピー・バナー・動画のスキル（第 4 章）
4. 入稿・配信 → 媒体ごとの入稿のスキル（確認画面を通る）
5. 運用チューニング → 週次のチューニングのスキル
6. レポート → 広告レポートのスキル

## 守ること
- 工程を飛ばさない。与件が埋まらなければ、そこで止まって聞く
- 各工程の出力をファイルで渡す（会話の文脈では渡さない）
- 自分で広告を作らない・入稿しない

このオーケストレータは「振り分けるだけで、自分では作業しない」形にしました。7 工程を 1 つの手順書に書き切ると長くなりすぎて、実行者が読まなくなるからです。数値基準を持たせず担当スキルの正本を読ませるのも同じ考え方で、複製した瞬間に正本が 2 つになります（原則 A）。description の「工程 1 つだけならその工程のスキルを直接使う」は、レポートだけの依頼でこの手順書が立ち、与件把握から全工程が回り始めるのを防ぐ一文です。反対に「一気通貫で」「PDCA を回したい」を依頼の言い方に挙げておかないと、その依頼で工程 1 つの手順書が立ち、その工程だけで終わってしまいます。

「守ること」の先頭には「工程を飛ばさない。与件が埋まらなければ止まって聞く」を置きました。事故の定番である、媒体を決め打ちした入稿と環境チェック抜きの入稿は、どちらも工程を省いたときに起きます。与件（目標 CPA・月予算・CV の定義・禁止表現）を最初の工程にしたのは、ここが埋まらないまま進むと、後の工程が推測で埋めた値のまま確認画面に並ぶためです。「各工程の出力をファイルで渡す」の理由は、サブエージェントがメインの会話の内容を引き継がないこと。会話の文脈に頼ると、渡ったつもりの与件が届きません。「自分で広告を作らない・入稿しない」は、入稿を媒体ごとの手順書へ渡して確認画面を通すための一文です。配信・停止・大幅な増額の判断をメインに残す分担を、オーケストレータの側からも守っています。フルかクイックかの段階と与件の中身は依頼文で渡し、工程の順番と省かない工程はこの手順書に固定しています。

媒体は決め打ちしない

「うちは Instagram でしょう」「若い人向けだから TikTok」。こうした決め打ちは、たいてい実測とずれます。WHO（誰のどんな悩みか）、WHY（なぜ今まで使わなかったか、なぜ今伝えるのか）、WHAT（何を伝えるか）、HOW（どう伝えるか）を先に整理し、狙う相手が「どのくらい欲しがっている段階か」で候補を絞ります。

候補は 2〜4 個に絞り、同一クリエイティブ・同額・同期間で並べて比べます。条件を揃えないと、媒体の差なのか予算の差なのかが分からないままです。出稿前に撤退ライン（いくら使って成果が何件なければ止めるか）を数字で書いておきます。走り出してから「もう少し様子を見よう」を繰り返すと、判断はどんどん感情に寄っていきます。順番は「探している人」で勝ち方を見つけてから「まだ知らない人」へ。前者に効いた広告は後者にも効くことが多い一方、逆はほとんど成り立ちません。審査の厳しい商材では少額で別媒体の並行検証も続け、アカウント停止のリスクを分散します。

図を原寸で開く

図の元になった mermaid を見る

mermaid

flowchart TD
    A["与件把握<br>商材・成果の定義・予算・契約範囲"] --> B["媒体選定<br>WHO/WHY/WHAT/HOW と関心度層<br>候補 2〜4・検証設計・撤退ライン"]
    B --> C["クリエイティブ準備（第 4 章）<br>競合の当たり広告 → 台本 → 制作"]
    C --> D["遷移先ページ（第 4 章）<br>広告と同じ言葉・計測タグの検証"]
    B -.既存の素材・ページを使う.-> E
    D --> E["入稿・配信開始<br>停止状態で作成 → 確認 → 配信開始も別の確認"]
    E --> F["運用チューニング<br>学習期間・差し替え・予算配分・トリガー"]
    F --> G["レポート<br>指標計算・前月比・要因分析"]
    G -.勝ちパターンを次の企画へ.-> B

検索広告の見積もりはキーワードプランナーの実数で行う

検索広告（検索結果に出る広告）を候補に入れるかどうかは、キーワードごとの検索回数とクリック単価の見込みで決まります。この数字の一次情報は Google のキーワードプランナーです。Google Ads API からも同じ数字を取れます（GenerateKeywordIdeas と GenerateKeywordHistoricalMetrics）。とはいえ何でも取れるわけではなく、取れるものと取れないものははっきり分かれています。

読むときに気をつけたいことが 3 つあります。まず入札単価。マイクロ単位（100 万で通貨 1 単位）で返り、通貨は広告アカウントの設定に従うので、円に直すときに通貨を推測してはいけません。次に表記ゆれ。単数形と複数形などは Google 側で 1 行にまとめられることがあり、その行のボリュームは合計です。1 つのキーワードの数字として扱わないでください。最後に言語と地域。指定次第で数字は変わり、違う地域の数字もそれらしい値として返ってきます。どの地域・どの言語で取った数字かは、表に必ず書いておきます。

月の予算の見込みは「入札単価の下限〜上限 × 見込みのクリック数」で出します。見込みのクリック数は検索回数に想定のクリック率を掛けたもので、クリック率は仮の値です。仮に置いた値は、表の外に必ず書き出します。

駅前の美容室（〇〇駅から徒歩 3 分）の検索広告を検討しています。キーワードの検索回数とクリック単価を調べてください。

- 起点の語: 「〇〇駅 美容室」「〇〇駅 カット」「〇〇駅 縮毛矯正」「〇〇駅 ヘアカラー」。関連する語を 30 件まで広げてください。
- 地域は店舗のある市、言語は日本語で取ってください。表の上に、取得した地域と言語を書いてください。
- 表の列: キーワード、月間平均検索ボリューム、多い月と少ない月、広告の競合性、ページ上部の入札単価（下限〜上限、円）。
- 検索ボリュームが返らなかった語は 0 と書かず「データ無し」と書き、表の下にまとめてください。
- 競合性は SEO の難しさとして説明しないでください。
- 最後に、上位 10 語に月 5 万円を使った場合のクリック数の見込みを出してください。クリック率を仮に置く場合は、その値を書いてください。
- 広告の作成はしないでください。

列名を「広告の競合性」と指定し、SEO の説明を禁じたのは、競合指数の高い語を「上位表示が難しい語」と書いてくるレポートが実際に出やすいからです。広告枠の埋まり具合と検索順位の取りにくさは、まったく別の数字です。

依頼のたびにこの条件を書かずに済むように、キーワードの実数値を取る作業を手順書にしておきます。調べて表にするだけで、広告は作らない手順書です。

---
name: keyword-volume
description: >-
  キーワードの実検索ボリューム・クリック単価・広告の競合性を取る。
  「検索ボリュームを調べて」「CPC は」「入札単価の目安」で使う。
  **実数値の一次ソースはここだけ**。
  ※難易度の推定や記事形式の判定はキーワード調査のスキル、
  順位の実測は順位計測のスキル（第 6 章）。
---
# キーワードの実数値

## 手順
1. 地域と言語を指定する（既定のまま取らない）
2. ボリューム・単価のレンジ・競合性を 1 行 1 キーワードの表にする
3. 季節変動がある語は、月別の推移を一緒に出す
4. 見積もりに使うときは、単価のレンジの**上側**で計算する

## やらないこと
- ここの数字を順位の代わりに使わない
- 平均値を「毎月この件数検索される」と断定しない（幅のある推定値）

description の「実数値の一次ソースはここだけ」は、経路を 1 本に保つための一文です。検索回数と単価の一次情報はキーワードプランナーで、同じ数字を別の経路からも取ると、ずれたときにどちらが正しいか決められなくなります（原則 A）。難易度の推定と順位の実測は第 6 章のスキルへ送り、「やらないこと」の先頭にも「順位の代わりに使わない」を置きました。この API には検索順位も SEO の難易度も無いのに、競合指数の高い語を「上位表示が難しい語」と書くレポートが実際に出やすいからです。同じ取り違えを、依頼の段階と実行の段階の両方で断っています。

手順 1 では、地域と言語を「既定のまま取らない」と限定しています。指定次第で数字が変わり、違う地域の数字もそれらしい値として返ってくるからです。依頼文に地域を書き忘れた回でも、手順書にあればエージェントは指定してから取ります。手順 3 で季節変動のある語に月別の推移を添えさせるのは、宿泊や観光を年平均だけで判断すると繁忙期を見誤るため。見積もりはレンジの上側で計算させます。レンジは過去の入札額の 20〜80 パーセンタイルなので、安いほうで見込むと、預かった予算で買えるクリック数を多く見せてしまいます。「毎月この件数と断定しない」を入れたのは、返る値が 12 か月の平均で、表記ゆれをまとめた行では合計にもなるからです。起点の語・地域・予算の額は案件ごとに依頼文で渡し、単位と読み方の規則はこの手順書に固定しています。

初回の配信は手動の設定から始める

媒体の自動最適化は、その広告アカウントで過去に起きた成果のデータを使って配信先を選びます。新しいアカウントや新しい商材には、そのデータがありません。著者は、最初の配信を人が決めたターゲティングと入札で始め、目標に近い単価の成果がたまってから自動に切り替えています。初手の組み合わせは次のとおりです（著者の運用での目安）。

Meta の類似オーディエンスは、元になるオーディエンスが 100 人以上いれば作れます。元を 1 つに固定せず、「予約した人」と「繰り返し来店している顧客のリスト」のように別の元から作って比べます。Google ディスプレイの「最適化されたターゲティング」は既定で有効です。手動で検証している期間はオフにし、自動入札に移ってから戻します。

自動入札へ移るときは、次の順で進めます。

1. 手動の期間に、目標に近い単価の成果をためる。件数が足りなければ、予約フォームを開いたなどの中間の行動も成果として数える
2. 移行時の目標 CPA は、手動の期間の実績と同じか 2 割引きまでにする。下げすぎると配信が止まる
3. 移行後は日予算を上限に張り付かせない。予算の上限で配信が抑えられると、学習に使う成果が増えない。支出を抑えたいときは、予算ではなく目標 CPA で調整する
4. 目標 CPA の変更は直近 7 日の実績を見て、1 回 20% 以内にする。Google もディスプレイの自動入札について、目標を 20% ずつ上げ下げし、変更の間を 1 週間空けることを勧めている

競合の広告は 2 段階で調べる

公開の広告ライブラリの読み方（出稿額と再生数は無く、継続配信日数で判断する）は第 3 章で扱いました。動画を再生せずに一覧を広く見て（1 段目）、選んだ 2〜4 本だけを文字起こしや遷移先の確認まで深く見る（2 段目）調べ方は、第 8 章の「調べ方の設計: メタ情報を広く、本命だけ深く」で詳しく扱います。Meta と TikTok の広告ライブラリは利用規約でスクレイピングが禁じられているので、1 段目の一覧は人が検索して記録するか、広告データを MCP で提供する商用サービス（第 3 章）から取ります。広告運用の工程で決めておくのは、どこで止めるかと、結果をどの形で次の工程へ渡すかです。

台本を使う作業（第 4 章の台本づくり）に渡すなら、2 段目まで要ります。コピーの型や遷移先の傾向を知りたいだけなら、1 段目で十分です。全部の動画を文字起こししてみても、かけた時間と費用に見合うほど分かることは増えません。

遷移先の URL は、競合がどの順番で申し込みまで進ませているかを示します。ドメインとパスから次のように分類します。

1 段目の結果は、次の形でまとめさせます。

# 競合広告の一覧調査の返し方（例）
条件: {検索語: "〇〇温泉 旅館", 国: JP, 配信状態: 配信中, 取得日: 2026-09-20, 検索結果の総数: 184, 取得経路: 人が広告ライブラリで記録}
広告:
  - 広告主: 競合 A（ページ名）
    配信開始日: 2026-05-02
    継続配信日数: 141
    同じクリエイティブの件数: 6
    配信面: [Facebook, Instagram]
    形式: 動画
    本文の冒頭: "平日限定、露天風呂付き客室が…"
    CTA: 予約する
    遷移先の種類: 予約フォーム
    画像: shots/competitor-a-01.png   # URL は失効するのでファイルで持つ
傾向:
  長く配信されている広告の共通点: "…"
  遷移先の種類の内訳: {予約フォーム: 9, 記事型: 4, LINE: 3}
深く見る候補: [競合 A の 1 本目, 競合 C の 2 本目]
取れない項目: 出稿額・再生数・クリック数（広告ライブラリに無い）

「取れない項目」を毎回書かせるのは、次の工程で出稿額や再生数を推定して書き足させないためです。取得日と検索結果の総数を残しておくと、翌月に同じ条件で調べ直したときに差分を比べられます。

媒体とつなぐ：各社の公式 MCP を前提にする

4 媒体とも公式の MCP サーバーがある

MCP（第 2 章）は、AI エージェントが外部のサービスを操作するための共通の接続方式です。2026 年に入って、Meta・Google・LINEヤフー・TikTok の 4 社が、広告 API を MCP のツールとして呼べるサーバーを公式に公開しました。少し前までは媒体ごとに認証とリクエストを自前で実装するしかなかったのが、いまは公式の MCP サーバーをエージェントに登録するところから始められます。この章では、媒体とのつなぎ方は公式 MCP が第一候補、MCP でできない操作だけ API を直接呼ぶ、という前提で書きます。

参照専用の MCP と、書き込みもできる MCP がある

Google と LINEヤフーの公式 MCP は参照専用で、広告の作成・編集・停止はできないと両社の公式ドキュメントに明記されています。書き込みもできるのは Meta です。作成系のツールは停止状態で作り、配信の開始は別のツール（ads_activate_entity）に分かれています。媒体ごとの経路は、ここから次のように決まります。

• 実績と設定を読むのは、公式 MCP です。TikTok だけは、認証と書き込みの仕様を公式で確認できるまで API を直接呼びます。
• 書き込むのは、Meta なら公式 MCP のツールです。Google と LINEヤフーは、API を直接呼ぶ書き込み用のツールを自分で用意します。後の「入稿を自動化する」の節で扱う Google の注意点は、この書き込み用のツールの話です。
• 同じ媒体の実績を、MCP と API の 2 つの経路で読まないようにしてください。単位や期間の解釈がずれたとき、どちらの数字が正しいのかを判断できなくなります（原則 A）。書き込みに API を使う媒体でも、書き込みの前後の確認は MCP で読む、と役割を分けます。

階層はどの媒体も同じ形をしている

4 媒体とも、広告アカウント、キャンペーン（目的と予算）、広告セットまたは広告グループ（配信先と入札）、広告、クリエイティブの入れ子です。違うのは名前だけ。キャンペーンの 1 つ下を Meta は「広告セット」、他の 3 媒体は「広告グループ」と呼びます。画面に出す語はその媒体の管理画面と揃えます。利用者は管理画面で探すからです。例外は Google の P-MAX（全配信面に自動で出すキャンペーン種別）で、広告グループも広告も無く、アセットグループに素材を登録すると組み合わせは Google が決めます。公式 MCP のツールもこの階層に沿っていて、Meta なら ads_create_campaign、ads_create_ad_set、ads_create_ad の順に呼びます。

トークンは MCP の側が持つ。持ち方は媒体ごとに違う

公式 MCP を使うと、アクセストークンの取得と更新は MCP サーバーか MCP クライアント（Claude などの接続元）が行います。エージェントが受け取るのはツールの結果だけで、トークンそのものは受け取りません。原則 I（鍵を AI に渡さない）を、自前で作り込まずに満たせる。公式 MCP を前提にする一番の理由はここにあります。ただし、トークンをどこで持つかと、事前に何を用意するかは媒体ごとに違います。

Meta の MCP サーバーは、トークン無しで呼ぶと認可サーバーの場所を返します。MCP の標準の手順（RFC 9728 の保護リソースのメタデータから、RFC 8414 の認可サーバーのメタデータへ）で読み取れるので、認可とトークンの URL は決め打ちせず、この手順で取得してください。認可サーバーのメタデータはリフレッシュトークンでの更新に対応していると案内しています。実際に応答にリフレッシュトークンが含まれるかは応答を見て確かめ、含まれていれば更新のたびに保存し直します。Meta のアプリを持たずに、AI サービス側が用意した公式コネクターから使う方法もあります。一方、自社のサービスから多くの広告主をつなぐ場合は自社のアプリが要ります。著者が試した範囲では、MCP サーバーが案内する動的クライアント登録は一部の AI サービスのコールバック URL にしか開かれておらず、自社サービスの URL では登録できませんでした。以前のように Marketing API へ直接つなぐ場合は、無期限のシステムユーザートークンを取るために認可 URL の指定を揃える必要があり、指定が 1 つ欠けると約 60 日で切れるユーザートークンに切り替わっていました。エラーが出ないので、気づくのは 2 か月後に全案件が同時に認証エラーを返したときです。MCP の認可サーバーは標準の認可コードの手順で動くので、この指定は要りません。付与された権限は、要求した内容ではなく、実際に付与された内容を API で確かめて保存します（原則 B）。同意画面で利用者が権限の一部を外せるからです。

Google の MCP サーバーは自分で動かすので、Google Ads API の利用条件がそのまま効きます。利用者の同意（誰の広告アカウントを読むか）とは別に、「どのアプリが呼ぶか」を示す運営側の資格が要ります。長く開発者トークンがその役でしたが、執筆時点（2026 年 9 月）では廃止が案内され、アクセスレベル（Test・Explorer・Basic・Standard）は OAuth クライアントを発行した Google Cloud プロジェクトに紐づく形へ移っています。MCP サーバーの README は、開発者トークンを「任意だが推奨」と書いています。どちらの形でも設計は変わりません。運営側の資格は案件ごとに持たせず、MCP サーバーを動かす環境に 1 つだけ置きます。案件ごとに複製すると、資格を更新するたびに全件を書き換えることになります。見落としやすいのが、Google 広告の OAuth スコープは読み書きが 1 本で、読み取り専用のスコープが無いことです。MCP サーバーが参照専用なのはツールがそう作られているからで、サーバーが持つトークンは書き込みにも使えます。トークンの保管場所は、書き込みの鍵と同じ水準で守ってください。一方、顧客 ID（どの広告アカウントの数字を見るか）は鍵ではないので案件が持ちます。ここで管理者アカウント（MCC）を選ぶと、連携も疎通も通ったうえで実績だけが常に空になります。広告が入っているのは子アカウントのほうだからです。

LINEヤフーの MCP サーバーは、手元のマシンで起動し（Python の実行環境と pipx が要ります）、localhost の決まったポートで MCP クライアントからの接続を待ちます。初回はブラウザに認可画面が出て、ビジネス ID で許可します。サーバーの上でエージェントを動かす場合は、MCP サーバーも同じマシン（コンテナ）の中で起動する必要があります。レポートは CSV ファイルとして、起動時に指定したディレクトリに書き出されます。MCP クライアントがそのファイルを読めないと結果を受け取れないため、サンドボックスの中で動くクライアントやリモートのクライアントからは読めないことがある、と README が注意しています。レポートの作成は 60 秒で打ち切られ、一覧を返すツールは 1 回に 1 ページずつしか返しません。1 ページ目だけを見て合計を出さず、最後のページまで取ったかを確かめてから集計してください（原則 C）。

TikTok の公式ヘルプには、全ツール（約 400）を出す接続先と、主要な約 40 ツールに絞った接続先の 2 つが載っています。ただし執筆時点では、認可の手順と、作成したキャンペーンが停止状態になるかどうかを公開ドキュメントで確認できませんでした。TikTok の Marketing API は、キャンペーン作成時の既定が配信中です（次の節の表）。MCP 経由でも同じかどうかを確かめるまでは、書き込みのツールを使わない設定にしておいてください。

アプリ審査が本番運用の前提になる

他社の広告アカウントを扱うには、公式 MCP を使う場合も媒体側の審査や申請が要ります。実装が正しくても、審査前は「アプリに役割を付けたアカウント」しか連携できません。

Meta の公式ブログは、アプリレビューを任意としたうえで、代理店やパートナーとして他の事業者のデータを扱う場合は ads_mcp_management の Advanced Access をアプリレビューで申請するよう案内しています。Marketing API を直接呼ぶ経路には、以前から互いに独立した審査が 3 つあります。①ビジネス認証（事業者が実在すること）、②アクセス認証（他社のデータを扱う事業者であること）、③アプリレビュー（その権限を役割の無い相手にも要求してよいこと。Marketing API のアクセス階層の引き上げもここ）。③が通っただけではクライアントは繋げません。②が済むまで、役割の無いユーザーは同意画面まで進んでも権限が付かないからです。上位階層の条件には直近の API 呼び出し実績（執筆時点では 15 日間に 500 件以上、エラー率 15% 未満）が含まれるので、申請は連携を実装して動かしてからになります。よくある却下理由は「クライアントが自分でアクセスを付与する導線が無い」でした。この 3 つが MCP の経路でどう扱われるかは、執筆時点では公式に書かれていません。申請の前に最新の案内を確認してください。Google は MCP サーバーも Google Ads API を呼ぶので、API のアクセスレベルがそのまま効きます。テスト用のレベルでは本番アカウントを読めません。LINEヤフーは、広告 API の利用申し込み（執筆時点では 1 企業 1 アプリ）と、MCP 用 OAuth クライアントの発行の 2 つが要ります。書き込みに使う広告 API のアプリと MCP 用のクライアントは別々に管理することになります。TikTok は、API を直接呼ぶ場合、審査が通って初めて鍵（アプリ ID とシークレット）が発行されるので、それまで連携を始められません。

媒体をまたいだ落とし穴もあります。却下を通知してくれないポータルがあり、記録の上では「審査中」のまま 10 日間気づかなかったことが実際にありました。状態はメールを待たず、画面で確かめてください。却下の理由も、本題（権限・デモ動画）より周辺の項目であることのほうがむしろ多いくらいです。Web サイトの URL がログイン画面だった、アプリのアイコンがサイトと違う、といった具合です。

公式 MCP を使うときの共通の設計

• 使うツールを絞る。公式 MCP のツールは数が多く、Meta は 7 つの分類にわたり、TikTok は全ツール版で約 400 あります。使わないツールまで見せると、エージェントが似た名前のツールを取り違えやすくなり、ツールの説明文がコンテキストも消費します。Google の MCP サーバーは設定ファイルでツールごとに有効・無効を切り替えられます。リモートのサーバーでは、MCP クライアント側のパーミッション（第 2 章）で、使わないツールを「ブロック」（Claude Code では deny）にします。
• 書き込みのツールは、パーミッションで確認の対象にする（原則 H）。Meta の公式ドキュメントは、書き込みのツールは停止状態で作り、配信を始める前に AI クライアントが確認を出す、と書いています。Claude では、この確認はパーミッションの確認画面として出ます。ただし確認を出すかどうかはクライアント側の設定で決まり、利用者が「常に許可」を選ぶと出なくなり、サーバー側からはそれを確かめられません。作成・更新・配信開始・Instagram 投稿の広告化・オーディエンスの更新と削除のツールを、ツール名で ask（Claude Code の settings.json）か「承認が必要」（claude.ai のコネクタのツール権限）に入れてください。組織で使うなら、利用者が外せないように、claude.ai の組織のツール権限か Claude Code の managed settings（管理者が配布し、ほかの設定から上書きできない設定）で固定します。API を直接呼ぶために自分で作る書き込みのツールには、確認必須の印（anthropic/requiresUserInteraction。第 2 章）も付けます。Claude Code では、印の付いたツールは allow に書かれていても、呼び出すたびに確認画面が出ます。
• 「鍵がある」と「読める」を分ける（原則 B）。接続状態は、MCP サーバーのツール一覧（tools/list）と、アカウント一覧のツールを実際に呼んだ結果から作ります。トークンが保存されていても、権限が足りなければツールの呼び出しは失敗します。「鍵はあるのに認証エラー」が、一番原因を特定しにくい壊れ方です。
• 広告アカウントは一覧から選ばせる（原則 F）。Meta は ads_get_ad_accounts、Google は list_accessible_customers が、利用者が触れるアカウントの一覧を返します。act_ の付け忘れや桁の取り違えは権限不足と同じエラーになり、区別できません。一覧が取れないときだけ手入力にします。
• 連携後にアカウント名を必ず画面に出す。ブラウザが別のアカウントでログインしていると、同意も疎通も通ったうえで別の会社の数字が出ます。名前を確かめる以外に気づく手段がありません。
• 読み取りだけの案件は読み取りの権限だけで連携する。Meta なら ads_read だけを要求します。媒体の権限とパーミッションの 2 箇所で書き込みを止められます。
• 自分で動かす MCP サーバーはバージョンを固定する。Google と LINEヤフーのサーバーは GitHub で公開されていて、起動時にバージョンを指定できます。LINEヤフーは v0.0.1 から始まったばかりで、ツール名や返す形が変わる可能性があります。上げるときは変更履歴を読み、同じ期間の実績が同じ値で取れるかを確かめてから切り替えます。リモートのサーバーはこちらで固定できないので、使っているツールが一覧に残っているかを接続確認のたびに見ます。
• API を直接呼ぶ部分は、共用のアプリを 1 つにし、コールバック URL を固定の 1 本にする。保存先の案件は URL ではなく署名付きの state から取り出します。案件ごとに URL を発行すると登録数の上限に達し、動的な値を禁じる媒体では登録そのものができません。Meta の MCP を自社アプリで使う場合も、リダイレクト URL は同じ考え方で 1 本にします。アクセストークンを利用者に手で貼らせることもしません。誰がいつ発行したか追えず、失効しても「鍵あり」に見え続けます。

例: つないだ直後の接続確認を頼む

公式 MCP を登録したら、最初の依頼は読み取りだけの接続確認にします。次のように頼むと、この節の「鍵がある」と「読める」の区別と、一覧から選ばせる手順を 1 回で確かめられます。

Meta 広告と Google 広告の公式 MCP をつないだので、接続確認をしてください。

- 媒体ごとに、操作できる広告アカウントの一覧を取得し、アカウント名と ID を表にしてください。
- 温泉旅館の広告アカウントがどれかは私が選びます。候補を並べたところで止め、推測で 1 つに決めないでください。
- Google で管理者アカウント（MCC）しか出てこないときは、その下の子アカウントも一覧にしてください。
- 私が選んだアカウントについて、昨日 1 日分の消化額・表示回数・クリック数を取得してください。管理画面の数字と見比べるので、媒体が返した単位のまま出してください。
- 作成・変更・停止のツールは使わないでください。
- 失敗したら、エラーの本文と、足りないと考えられる権限や設定を書いてください。

期間を昨日 1 日分にしたのは、管理画面と照合しやすい小さな数字で、単位のずれをあぶり出すためです。金額が 100 倍や 100 万倍になっていれば、この時点で気づけます。アカウントを選ぶ操作を人に残したのは、候補が複数あるとエージェントが先頭のアカウントを選んでしまいがちだからです（原則 F）。

媒体で揃っていないものを 1 表にまとめる

同じ「広告 API」でも、単位・語彙・階層は媒体ごとに違います。著者が公式ドキュメントで確認できた範囲を 1 表にしました。執筆時点の内容なので、実装前に公式で再確認してください。表は各社の API の仕様です。公式 MCP のツールが API の値をそのまま返すとは限らないので、ツールの説明に単位が書かれていなければ、同じ期間の数字を管理画面でも確かめ、一致することを確認してから使ってください。

この表から、守るべきことが 2 つ見えてきます。

1 つ目。単位は値の大小から推測せず、取得経路ごとに確定させます（原則 D）。同じ ctr でも Meta は 1.8（= 1.8%）、Google は 0.018 で返ります。「値が 1 以下なら比率」のような推測分岐を書くと、実 CTR 0.8% が 80% になります。著者の環境では、2 つの取得経路が同じ名前の指標を違う単位で返し、どちらで取れたかによって 100 倍ずれていた時期がありました。経路を 1 本にし、変換を 1 箇所に固定したのはそのためです。TikTok の率は公式が「パーセンテージ」としか書かず、0〜1 か 0〜100 かを示す記述も例もありません。確定できない単位の値は要求せず、表示回数・クリック・消化額から出し直します（原則 G）。Google の CV 数は小数で返るので、整数に丸めると 2.5 件が 2 件になります。通貨も同じで、Meta のオフセット表に無い通貨は「たぶん 100」で割らず、予算を動かしません。

2 つ目。媒体差は 1 箇所に集約します。検証関数の中に「Google なら複製不可」「LINEヤフーなら広告グループ不可」と条件式を散らすと、媒体を足したときにどこを直せば揃うのかが分からなくなります。代わりに「その媒体で何ができるか」の能力表を 1 つ持ち、画面もサーバーもそこだけを読みます。

# 媒体ごとの能力表（概念例）。新しい媒体はここに 1 行足せば揃う
Meta:       {1 つ下の階層: 広告セット,   予算を置ける階層: [キャンペーン, 広告セット], できる操作: [停止, 予算, 配信, 複製], 配信中の語: ACTIVE,  中間CV: あり}
Google:     {1 つ下の階層: 広告グループ, 予算を置ける階層: [キャンペーン],             できる操作: [停止, 予算, 配信],       配信中の語: ENABLED, 中間CV: なし}
TikTok:     {1 つ下の階層: 広告グループ, 予算を置ける階層: [キャンペーン],             できる操作: [停止, 予算, 配信],       配信中の語: ENABLE,  中間CV: なし}
LINEヤフー: {1 つ下の階層: 対象外,       予算を置ける階層: [キャンペーン],             できる操作: [停止, 予算, 配信],       配信中の語: ACTIVE,  中間CV: なし}
# 「対象外」= その階層を操作する手段をこちらが持っていない（媒体に階層が無いという意味ではない）
# 画面は媒体名で分岐せず、サーバーがこの表から返す「できること」を描く

入稿を自動化する

この節の書き込みは、Meta では公式 MCP のツールで、Google と LINEヤフーでは API を直接呼ぶ自作のツールで行います。経路は違っても、設計の考え方は変わりません。

「作ってよい」と「出稿してよい」は別の確認

作成系のツールはすべて停止状態で作り、配信開始は別のツールにして、別々に確認画面を通します。パーミッションは MCP のツールを名前だけで判定するので、作成と配信開始が同じツールの引数の違いだと、別々に確認させることができません。1 回の確認でまとめてよいのは「作成」どうしだけ。TikTok だけは既定が配信中なので、ツール側で必ず停止を明示します。

一式を 1 回の呼び出しにまとめる

書き込みのツールは、呼ぶたびに確認画面が出ます（後述の「パーミッション」の節）。キャンペーン、広告セット、クリエイティブ、広告を個別に 4 回呼ぶと、確認画面が 4 回出ます。途中で断ると、広告の無いキャンペーンが広告アカウントに残ります。だから新規入稿は「一式」を 1 回の呼び出しにします。確認画面で全体を見て 1 回許可すれば、サーバーが順に作って ID を繋ぎます。必須項目が欠けた呼び出しでは、サーバーは何も作らずに不足の一覧を返します。ただし確認画面は呼び出しがサーバーに届く前に出るので、不足のある呼び出しも一度は確認画面に出ます。確認画面を出す前に不足を知りたいときは、何も変更しない検証用のツール（Google の API の validate_only のように、通るかどうかだけを返すもの）を先に呼びます。

呼び出しの前に部品を確定させます。順番は、素材（実写か生成物かの由来を必ず見る。実在しない料理で実店舗の広告を出さないため）、差出人のページ、広告の中身（広告文・遷移先 URL・配信地域・予算の置き場）。予算はキャンペーンか広告セットの一方だけに置きます。両方に付けると媒体が弾きます。最低予算は媒体のエラー本文にしか出ないので、預かった予算が届かなくても勝手に増額せず、根拠を示して確認を取ります。途中で落ちたら「どこまで作られたか」を結果に載せます。残ったまま作り直すと、同じキャンペーンが二重に並びます。同じ内容で呼び直すのは 1 回まで。2 回同じエラーなら、原因は内容ではなく環境（権限・設定）です。

例: 入稿の依頼文

新規入稿を頼むときは、確認画面に並ぶ値を依頼の段階で決めておきます。まず足りない例です。

美容室の広告を Meta で出しておいてください。予算は月 6 万円くらいで。

どの広告アカウントか、何を成果と数えるか、予算を日予算にしてどの階層に置くか、作成と配信開始を分けるか。この依頼には、どれも書かれていません。するとエージェントは、候補が 1 つならそのアカウントを使い、月 6 万円を日予算に割り戻し、「出しておいて」を配信開始まで含む指示と読むことがあります。配信開始のツールを確認の対象にしておけば、その確認画面で断ることで配信は止められます。厄介なのは作成の確認画面のほうで、依頼者が決めていない値がそこに並びます。そのまま許可すれば、決めていない値で広告ができあがってしまうので、依頼の段階で書いておく必要があります。

次は、必要な値をそろえた例です。

駅前の美容室の新規入稿をお願いします。Meta 広告で、キャンペーンから広告までを 1 回の呼び出しで一式作ってください。

- 広告アカウント: 接続確認で選んだ美容室のアカウント。他のアカウントには作らないでください。
- 目的: 予約ページへの誘導。成果として数えるのは予約完了です。
- 予算: 日予算 2,000 円を広告セット側に置いてください。キャンペーン側には置かないでください。
  最低額に届かないと言われたら増額せず、最低額とエラーの本文を見せて確認してください。
- 配信地域: 店舗から半径 3km。年齢は 20〜49 歳。
- 素材: 素材フォルダの店内とスタイリングの写真 3 枚。店舗で撮影した写真だけを使い、生成画像は使わないでください。
- 広告文: 用意したコピー案の A 案。遷移先は予約ページ。
- 状態: すべて停止状態（PAUSED）で作ってください。配信開始は、作成の結果を見てから別に依頼します。
- ツールを呼ぶ前に、必須項目がそろっているかと、成果を約束する表現が広告文に無いかを確認してください。
  そのうえで、確認画面に出る内容を、呼ぶ前に日本語の箇条書きで見せてください。
  確認画面で私が断ったら、別の方法で作らずに止まってください。

予算の置き場、停止状態、配信開始を別の依頼にすること。どれもこの章で説明した設計を、そのまま依頼文に書き起こしたものです。最低額に届かないときの扱いを書いておけば、エージェントが預かった予算を超えて増額するのを防げます。素材の由来を指定したのは、実在の店舗の広告に、店舗に存在しない内装やスタイルの画像が紛れ込まないようにするため。最後の行は、確認画面で断った操作をエージェントが別の方法で実行しようとするのを止めるためです（第 2 章）。

停止状態での作成と一式の呼び出しを、Meta 広告を操作する手順書にまとめたのが次の例です。目的や予算の設計判断は扱わず、実行だけを受け持つ手順書です。

---
name: meta-ads-api
description: >-
  Meta 広告（Facebook / Instagram）のキャンペーン・広告セット・広告・素材を
  取得・作成・更新し、実績を取る。
  「キャンペーンを作成して」「広告を停止して」「予算を変更して」「実績を取って」で使う。
  ※目的・予算・オーディエンスの設計判断は運用設計のスキル。このスキルは実行層。
---
# Meta 広告の操作

## 手順
1. 広告アカウントを一覧から選ぶ（ID を手入力させない）
2. 作成は**停止状態**で行う。配信開始は別のツールにして、別に確認画面を通す
3. 一式（キャンペーン・広告セット・素材・広告）を 1 回の呼び出しにまとめる
4. 実績の取得は確認不要。取れなければ「連携が未設定」と報告する

## 守ること
- フィールド名は公式リファレンスで確かめてから使う（推測で足さない）
- 金額の単位は通貨ごとに確定させる。表に無い通貨は予算の操作を止める
- 広告の配信状態と、取得の成否を同じ項目で返さない
- 確認画面で断られた操作は、別の方法で実行しない。断られたことを報告して止まる

この手順書は実行層に切り、設計判断は運用設計のスキルへ送っています。判断と実行が 1 つにまとまっていると、「数値が悪いので見直したい」という依頼で作成や更新のツールが呼ばれ、見直しの結論が出る前に設定が変わってしまいます。実行の規則は案件が変わっても同じなので、分けておけば書き換えずに使い回せます。

手順 1 で ID の手入力を禁じたのは、act_ の付け忘れや桁の取り違えが権限不足と同じエラーになり、区別できないからです（原則 F）。手順 2 では、停止状態の作成と配信開始を別のツール・別の確認に分けました。パーミッションはツールを名前だけで判定するので、引数の違いでは別々に確認させられません。こうしておけば、「出しておいて」を配信開始まで含む指示と読んだ回でも、配信開始の確認画面で止められます。手順 3 で一式を 1 回の呼び出しにまとめるのは、個別に 4 回呼ぶと確認画面が 4 回出て、途中で断ると広告の無いキャンペーンが残るためです。手順 4 で取得を確認不要にしたのは、確認画面を書き込みのときだけに絞るため。取れなければ「連携が未設定」と報告させ、鍵があることと読めることを分けて、0 で埋めた表を作らせないようにしています（原則 B・C）。

フィールド名は公式リファレンスで確かめさせます。推測で足した項目は、人が確認画面で許可したあとに媒体で弾かれ、許可した入稿が丸ごと落ちるからです（原則 G）。金額の単位を通貨ごとに確定させ、表に無い通貨で予算の操作を止めるのは、Meta の金額が通貨ごとのオフセットで返り、「たぶん 100」で割ると桁がずれるためです（原則 D）。「別の方法で実行しない」も外せません。確認画面で断られた操作の代わりを、エージェントが探すことがあるからです。依頼文の最後の行と同じことを手順書にも置き、書き忘れた回にも効くようにしています（第 2 章）。

失敗したら、誰が直せるかで返し方を分ける

入稿の失敗には、エージェントが直して呼び直せるものと、利用者か運営側にしか直せないものがあります。区別せずに呼び直すと、確認画面のたびに人の手を煩わせたうえで、同じエラーが返ってきます。Meta の API はエラーの応答に番号（error_subcode）を入れて返すので、番号ごとにどちらの扱いにするかを表にしておきます。

著者の環境では、ページの権限が足りないエラーは、管理画面で権限を付けたあとに連携し直すまで直りませんでした。権限は連携した時点のトークンに付くからです。止まるときの文面には「権限を付けたあと、連携をやり直してください」まで書きます。

連携そのものが無い案件でも、入稿の依頼を断って終わりにはしません。キャンペーンの構成、ターゲティング、クリエイティブの割り当てを、連携したらそのままツールの引数にできる形の入稿設計書にして渡し、連携の手順を添えます。

Google 広告で先に決めておくこと

• 検索キャンペーンの配信面は既定で閉じます。明示しないと検索パートナーとディスプレイにも出て、気づくのが請求書の時点になります。
• validate_only で Google 側に検算させます。何も変更せずに、通るかどうかだけが分かります。
• 部分成功を要求しません。一部だけ成功した状態が「成功」として返ると、どこまで出来たのかを人が調べて回ることになります。
• 削除は remove 操作で、状態の更新ではありません。Meta の削除は状態の更新です。API が用意した形が違うので、片方に寄せません。
• P-MAX のアセットグループは、必須の素材と一緒に 1 回の変更リクエストで作ります（Google の要求）。一時リソース ID（負の数）を種別をまたいで一意にし、参照される側を先に定義します。必須素材の本数と文字数は送る前に数えます。Google は 1 つ足りないだけでリクエスト全体を拒否し、「どれが足りないか」を返せるのは手前だけだからです。
• 文字数は全角を 2 と数えます。見出し 30 文字は日本語では 15 文字です。著者は手前の検算を半角で数えていて、人が内容を確かめて許可した入稿が、Google に送った時点で丸ごと落ちる失敗をしました。
• 作れる種類を絞ります。検索広告と P-MAX まで。動画・ディスプレイ・ショッピングはフィールド体系が別物で、公式で確認していない項目を足すことになります（原則 G）。TikTok も同じ理由で広告グループと広告は作らず、必要なら送信内容そのものを人が読む汎用の書き込みか、管理画面で作ってもらいます。

入稿の前に点検する

入稿が実行時にだけ失敗する原因は決まっています。支払い方法が未登録、ピクセル（成果を数える計測タグ）が未設置、Instagram アカウントが広告アカウントに未割り当て、差出人ページの広告権限が無い。どれも媒体の管理画面でしか直せません。だから連携直後に「いま、どこまで頼めるか」を一覧で出します。ここで肝心なのは、取れなかった項目を「未設定」と読まないこと。支払い方法のように、権限が無いと値そのものが返らない項目があります。分からないものは「不明」と返し、どこで確かめられるかを書きます。

同じ発想で、審査に落ちやすい表現（成果の確約、ビフォーアフター）は、書き込みのツールを呼ぶ前に指摘します。確認画面に出るのはツールの名前と引数だけで、警告の文を足すことはできないからです。「一式を 1 回の呼び出しにまとめる」で挙げた検証用のツールで広告文も点検し、エージェントはその結果を、呼ぶ前の返答で利用者に伝えます。判定は決定論で、同じ広告文なら同じ警告です（原則 Q）。ブロックはせず、「違反です」とも書きません。審査するのは媒体で、こちらは下書きを点検するだけだからです。配信中の広告セットには媒体の「学習期間」があり、その最中の重要な編集は学習をリセットします。予算を変えるツールを呼ぶ前の返答に「いま学習中か」と増額の幅を添えさせ、分からないときは何も書かせません。分からないことを危険と判定すると、何も壊れていない変更に警告が出続けて、誰も読まなくなります。

Meta で配信前に確かめる計測の設定

• ドメイン認証: 遷移先のドメインを所有していることの証明です。ビジネス設定で行います。
• ピクセル: 全ページに共通のベースコードと、成果の地点のイベント（予約完了など）が入っているか。コードが入っていることではなく、テストのイベントで実際に発火することを確かめます。
• コンバージョン API: 後の「計測を補う」の節で扱う、サーバー側からの送信です。ピクセルと同じイベント ID を使います。
• 最適化するイベント: 広告セットで何を最適化の対象にするか。成果が少ない案件では手前のイベントを選びます（次の「運用チューニング」の節）。

iOS 14 以降、ウェブのイベントは 8 件までに優先順位を付けて設定する手順が長く必要でした。2025 年に、この手動の設定は不要になったと案内されています。社内の手順書やスキルに「8 件の上限」の記述が残っていたら、そのまま使わず、公式の現行の案内で確かめてください。媒体の仕様を手順書に書くときは、確認した日付を添えておくと、見直す時期が分かります。

パーミッション：書き込みは 1 つ残らず人が確認する

外部に反映される書き込みのツールは、すべてパーミッション（第 2 章）で確認の対象にします。確認画面は、エージェントがツールを呼んだその場で、会話を操作している人に出ます。対象は作成、配信状態の変更、予算の変更、削除、素材のアップロード、汎用の書き込みです（原則 H）。つまずきやすいところを 5 つ挙げます。

1. 書き込みのツールは 1 つ残らず ask に入れます（claude.ai では「承認が必要」）。ツールを足したら ask にも足してください。忘れると、そのツールだけ確認なしで実行されます。auto モードでは、ask に無いツールを自動の判定が許可することもあります。書き込みのツールの一覧と、ask に書いたツールの一覧が一致しているかを、ツールを足すたびにテストで確かめます。
2. 「読むツールしか用意しない」だけでは守れません。Google と LINEヤフーの公式 MCP は参照専用ですが、Google の OAuth スコープは読み書き共通で、書き込み用に自分で用意した API のツールも同じ種類のトークンで動きます。Meta の公式 MCP は書き込みのツールを持っています。止められるのは、公式 MCP のツールと自作のツールをまとめて書いたパーミッションの設定だけです。
3. 確認画面で許可した呼び出しは、画面に表示された内容のまま 1 回だけ実行されます。確認画面で「今後は確認しない」を選ぶと allow のルールが保存されます。ask に書いたツールは ask が優先されるので確認は出続けますが、ask に書き忘れたツールでは以後確認が出なくなります。書き込みのツールでは選ばないでください。自分で作るツールには、確認必須の印（anthropic/requiresUserInteraction）を付けます。Claude Code では、印の付いたツールには「今後は確認しない」自体が表示されず、allow に書いても、確認を省くモードでも、呼び出すたびに確認画面が出ます（第 2 章）。
4. 確認画面に出るのは、ツールの名前と引数だけです。説明の文やプレビューを足すことはできません。名前だけで何の操作かが分かるようにし（作成と配信開始は別の名前のツールにする）、引数には広告アカウント名、金額と通貨を含めます。ID だけの引数では、人は何を許可するのか判断できません。サーバーの側では、アカウント名と ID が食い違っていないかを確かめます。また、誰がいつ何を許可したかは、ツールを提供する側には残りません。書き込みを実行したツールの側で、実行のたびに記録（誰の接続か・いつ・何を・結果）を残します。
5. 予算の単位が確定できない通貨では、予算を動かすルールの保存自体を止めます。

Claude Code の settings.json に書くと、次のようになります（概念例）。

{
  "permissions": {
    "allow": [
      "mcp__meta__ads_get_ad_accounts",
      "mcp__google_ads__search",
      "mcp__google_ads__list_accessible_customers",
      "mcp__ads_writer__validate_*"
    ],
    "ask": [
      "mcp__meta__ads_create_*",
      "mcp__meta__ads_activate_entity",
      "mcp__ads_writer__create_*",
      "mcp__ads_writer__activate_*",
      "mcp__ads_writer__update_status_*",
      "mcp__ads_writer__update_budget_*",
      "mcp__ads_writer__upload_*",
      "mcp__ads_writer__delete_*",
      "mcp__ads_writer__raw_write",
      "mcp__ads_writer__enable_trigger"
    ],
    "deny": ["mcp__tiktok__*"]
  }
}

meta google_ads tiktok は公式 MCP を、ads_writer は API を直接呼ぶために自分で作った MCP サーバーを登録したときに付けた名前で、どれも仮の名前です。ads_get_ad_accounts、ads_create_*（ads_create_campaign など）、ads_activate_entity は Meta の公式 MCP のツール名、search と list_accessible_customers は Google の公式 MCP のツール名で、ads_writer の下のツール名は概念例です（raw_write は任意の書き込みを送る汎用のツール、enable_trigger は後の節で扱うトリガーを有効にするツール）。Meta の公式 MCP の更新・Instagram 投稿の広告化・オーディエンスの更新と削除のツールも、ツールの一覧で名前を確かめて ask に足してください。

実績・一覧・キーワード候補の取得のような読み取りのツールは、allow に書いて確認なしにします。どこにも書かないツールの扱いはモードによって変わるので（第 2 章）、読み取りのツールも allow に書いておくと、確認画面が出るのは書き込みのときだけになります。TikTok の公式 MCP は、認証の手順と、作成したキャンペーンが停止状態になるかを公式で確かめるまで使わないので（「媒体とつなぐ」の節）、サーバーごと deny にしています。

図は横にスクロールできます。図を原寸で開く

図の元になった mermaid を見る

mermaid

flowchart LR
    S["エージェントが入稿一式のツールを呼ぶ"] --> G1{"確認①<br>作成（停止状態）"}
    G1 -->|許可| C["媒体に作成（ID を繋ぐ）"]
    G1 -->|断る（直し方を添える）| S
    C --> G2{"確認②<br>配信開始"}
    G2 -->|許可| D["配信中"]
    D --> I["実績を毎時取得<br>媒体ごとに別の数字"]
    I --> T{"トリガー判定<br>（決定論。エージェントを通らない）"}
    T -->|停止・減額・複製| A1["即時に実行 → 通知と発火履歴"]
    T -->|増額・配信開始| A2["確認③<br>トリガーを有効にする呼び出しを 1 回確認"]
    A2 -->|確認した範囲内で| D

実績を取る

実績は公式 MCP のレポート用のツール（Google なら GAQL を投げる search、LINEヤフーならレポート取得のツール）から階層別・日次の粒度で取り、集計はこちらで行います。気をつけるのは「定義」と「足し算」、この 2 つです。

成果（CV）の定義は媒体で決まり方が違います。Meta はレスポンスに並ぶアクション種別（購入、リード、フォーム送信など）のどれを成果と数えるかをこちらで選びます。選択肢は直近 90 日に実際に発生した種別だけ。使える種別はピクセルと計測の設定次第で変わるからです。中間コンバージョン（最終成果の手前の行動。フォームを開いた、電話番号をタップした）を決めておくと、成果が少ない案件でも判定できます。Google の CV 数は管理画面で「コンバージョン列に含める」としたアクションの合計で、定義の正本は Google 側にあります。TikTok と LINEヤフーも媒体側の設定に従い、中間コンバージョンはありません。定義を変えると過去の CPA（成果 1 件あたりの広告費）の見え方も変わります。同じ実績を別の分母で割り直すのだから当然です。

2 媒体を合算しません（原則 E）。消化額・表示回数・クリックは足せますが、成果の件数は数え方が違うので足せません。足した金額を足した件数で割った瞬間、その「1 件あたり」は意味の違う数字の平均でしかなくなります。通貨が違うときは消化額の合計も出さず、理由を書きます。投稿の再生数と広告の表示回数も別の数字です。

CTR は API の値をそのまま使わず、手元の分子分母から出し直します。単位が媒体で違ううえ、行の粒度によって媒体側の率の意味が変わるからです。

CV が 0 件のときの CPA は 0 ではなく「計算できない」です。0 にすると「CPA が目標を下回る = 優良」の判定に合致し、成果ゼロの広告が自動で複製・増額されます。同じ理由で、判定する最低消化額に届かない対象は判定しません。取れなかった数字は 0 で埋めず、「未取得」と対処法を返します（原則 C）。0 で埋めた瞬間、平均も前月比も全部崩れます。

def read_metric(row: dict, metric: str) -> float | None:
    """実績 1 行から指標を取り出す。取れないときは None。
    ここで 0 を返すと、CV が 0 件の対象が「CPA 0 円」として
    「下回る」側の条件に合致し、優良判定で増額が走る。"""
    value = row.get(metric)
    return None if value is None else float(value)

管理画面の CV は、ブラウザ側の計測制限のせいで実際の予約・来店より少なく出ます。差が大きい案件では実際の予約記録も並べ、EC で本命商材と他商品が混ざるときは本命と副次の成果を分けます。

例: 週次の実績レポートを頼む

実績の依頼は、短く書くほど前提をエージェントに補わせることになります。まずは足りない例から。

先週の広告の数字をまとめて、CPA も出してください。

この 1 行からは、たとえば次のようなことが起こりえます。2 媒体の成果の件数を足して、1 つの CPA が出る。Meta が返す複数のアクション種別のうち、どれを成果と数えるかをエージェントが選ぶ。「先週」が月曜始まりか日曜始まりかが依頼のたびに変わり、前週比が比べられない数字になる。厄介なことに、どれもエラーにはなりません。それらしい表ができあがってしまうので、定義は依頼の側で書いておくしかありません。

定義を書いた例です。

温泉旅館の広告について、先週（9 月 15 日〜21 日）の週次レポートを作ってください。

- 対象: Meta 広告と Google 広告。媒体ごとに別の表にし、成果の件数と CPA は合算しないでください。
  消化額の合計だけは出してかまいません。
- 成果の定義: Meta は計測設定で予約完了として送っているイベント、Google は「コンバージョン列に含める」に
  している予約完了のアクション。レポートの冒頭に、この定義を書いてください。
- 比較: 前週（9 月 8 日〜14 日）と比べてください。
- 計算: CTR と CPA は媒体が返す率を使わず、表示回数・クリック数・消化額・成果の件数から計算してください。
  成果が 0 件の CPA は「—」にしてください。
- 取れなかった数字は 0 で埋めず「未取得」と書き、理由を添えてください。
- 読み手は旅館の女将です。専門用語を使わずに「一言でいうと」の 3 行から始め、次にやることは 3 つまでにしてください。
- 広告の停止や予算の変更はしないでください。必要だと考えたことは提案として書いてください。

期間を日付で書き、成果の定義を媒体ごとに書き、合算してよいもの（消化額）と合算しないもの（件数と CPA）を分けました。この 3 点がそろえば、毎週同じ依頼をしたときに同じ数字が出ます。とはいえ毎週この文面を打つのは手間なので、この章の「レポート」の節の最後にある例のように、スキルとして保存します。

運用チューニング：配信を始めてから何を見て、何を動かすか

配信を始めた後の調整を自動にする前に、まず人が判断の順番を持っていなければなりません。この節ではその順番と、判断に使う基準の持ち方を書きます。自動にできる部分は、次の節のトリガーで扱います。

基準は「判断の構造」と「数値」に分けて持つ

運用の手引きや講座に出てくる数値（目標 CPA 1,000 円、日予算 5,000 円から始める、など）は、それが作られた業種と商材の実測です。メールアドレスを集めて講座を売る事業の CPA を、旅館の予約にそのまま当てることはできません。一方、「消化のペースと成果の付き方を見て入札を上げ下げする」「目標 CPA の何倍を使って成果が無ければ止める」といった判断の組み立ては、業種が変わっても使えます。著者はスキルの参照資料の先頭に出典の業種を書き、判断の構造と数値の表を分けて置いています。数値はクライアントごとに計算し直します。

撤退ラインを金額ではなく倍数で持つと、商材が変わっても同じ規則を使えます。「目標 CPA の約 2 倍を使って成果 0 件なら止める」は経験則で、著者はここを出発点に案件ごとに調整しています。

学習期間を壊さない

Meta の自動最適化には学習期間（情報収集期間）があります。Meta のヘルプは、最後の大きな編集から 1 週間でおよそ 50 件の最適化イベントが得られない見込みの広告セットを「情報収集が不十分」と表示すると説明しています。大きな編集には、広告セットの一時停止、最適化イベント・オーディエンス・クリエイティブの変更が含まれます。予算と入札戦略の変更も、変更の幅によっては含まれます。

この件数に届かないときに Meta が挙げる対処は、広告セットやキャンペーンをまとめる、予算を上げる、オーディエンスを広げる、入札や上限を上げる、より頻繁に起きるイベントを最適化の対象にする（購入からカートへの追加に移すなど）、の 5 つです。予約完了が週に数件しかない店舗型ビジネスでは、予約フォームを開いた、電話ボタンを押した、のような中間の行動を最適化の対象にし、広告セットを分けすぎないようにします。

Google の自動入札も、変更の直後はしばらく成績が揺れます。Google はディスプレイ キャンペーンの自動入札について、最初の 2 週間ほどの立ち上がりの後はほとんど手を加えなくてよく、調整するなら目標を 20% ずつ動かして変更の間を 1 週間空けるよう案内しています。

エージェントに運用を任せるなら、この規則は依頼や手順に必ず書いておきます。書かなければ、エージェントは毎日の数字の上下を見て毎日設定を変え、広告セットはいつまでも学習期間から出られません。

学習期間の規則を含めて、Meta 広告の設計と運用判断を手順書にした例です。実際の作成・更新・取得は、入稿の節で示した Meta 広告の操作の手順書が受け持ちます。

---
name: meta-ads-playbook
description: >-
  Meta 広告の設計と運用判断。環境チェック・目的と入札の選び方・オーディエンス設計・
  審査落ち対応・学習期間の扱いを扱う。
  「Facebook 広告を運用したい」「審査落ちした」「数値が悪いので見直したい」で使う。
  ※実際の作成・更新・取得は実行層のスキル。
---
# Meta 広告の運用設計

## 配信前に確かめる
- ビジネス設定とドメインの認証、計測タグの発火、CV の定義
- 目標 CPA と月予算、学習に要る件数が 1 週間で埋まるか

## 運用の規則
1. 学習期間中は触らない（何を触ると学習がやり直しになるかを先に書く）
2. 変えるのは 1 回に 1 箇所。予算の変更幅に上限を置く
3. 審査落ちは 1 回に 1 箇所ずつ直して切り分ける
4. 値を動かす判断は、消化のペースと成果の付き方の両方を見てから

## やらないこと
- CV が 0 件のときに CPA を 0 とみなさない（優良な広告に見える）
- 消化額が少ないうちに良し悪しを判定しない

この手順書が持つのは判断の構造だけで、目標 CPA や変更幅の数値は入れていません。手引きに載る数値はそれが作られた業種と商材の実測で、クライアントごとに計算し直すものだからです。数値は依頼文と案件の参照資料に残し、構造だけを手順書に置きます。実行層のスキルと分けているのは、「数値が悪いので見直したい」という依頼が、見直しの結論より先に設定の変更へ進まないようにするためです。

「配信前に確かめる」は、運用の規則より前に置きました。入稿が実行時にだけ失敗する原因は計測タグ・権限・ビジネス設定と決まっていて、どれも管理画面でしか直せません。環境チェック抜きの入稿は事故の定番です。「学習に要る件数が 1 週間で埋まるか」を確かめさせるのは、Meta が 1 週間におよそ 50 件の最適化イベントを求めるため。予約完了が週に数件の店舗では、中間の行動に切り替えないと学習期間から出られません。運用の規則の先頭には「学習期間中は触らない」を置き、何を触るとやり直しになるかを先に書かせています。書かなければ、エージェントは毎日の数字の上下を見て毎日設定を変え、広告セットはいつまでも学習期間から出られません。「1 回に 1 箇所」と変更幅の上限は、目標を下げすぎると配信が止まり、複数を同時に変えるとどれが効いたか分からなくなるためです。審査落ちを 1 箇所ずつにしているのも同じ理屈で、原因を特定しないまま申請を繰り返すと広告アカウントの制限につながります。「やらないこと」の 2 つにも理由があります。成果 0 件の CPA を 0 円にすると優良な広告に見えて増額が走り、消化額の少ないうちの判定は成果 1 件の揺れで反転します。

入札と予算は、消化のペースと成果の付き方で動かす

目標 CPA で入札しているときの調整は、2 つの観察の組み合わせで決まります。予算がどのくらいの速さで使われているか（消化のペース）と、成果がついているか、です。

消化のペースは「日予算 ÷ 24 × 経過時間」と実際の消化額を比べて判断します。ただし Meta では、1 日に日予算の最大 75% 増しを使う日があり、その代わり 1 週間（日曜〜土曜）の合計は日予算の 7 倍を超えないと説明されています。1 日の途中の消化額だけで「使いすぎ」と判定しないようにします。

もう 1 つ、見落としやすい点があります。媒体の自動入札が合わせにいくのは、管理画面に計上された成果の CPA です。実際の予約は入っているのに管理画面の成果が少ない案件で目標 CPA を下げると、配信が止まりやすくなります。管理画面と実際の予約数のずれは、入札を変える前に確かめます。

予算を大きく増やしたいときは、1 つのキャンペーンの予算を一度に上げる方法のほかに、同じ設定のキャンペーンを分けて並べる方法があります。分けると、1 つが審査で止まったときの影響が小さくなります。その代わり、管理の手間は増えます。

YouTube の動画広告は、課金の地点から設計する

YouTube の広告は、Google 広告の動画キャンペーンとして出します。スキップ可能なインストリーム広告を視聴単価（CPV）の入札で出す場合、課金されるのは、視聴者が 30 秒（動画が 30 秒より短ければ最後まで）見たときか、広告を操作したときの、どちらか早いほうです。最初の数秒でスキップした人には課金されません。そのため冒頭で「誰に向けた広告か」をはっきり言い、対象外の人にはスキップしてもらう構成にします（台本の作り方は第 4 章）。

動画キャンペーンの成果が悪いときは、クリエイティブを疑う前に、配信が YouTube の面ではなく動画パートナーのサイトやアプリに寄っていないかを、ネットワーク別の分割で確かめます。

課金の地点から構成を決める進め方を、YouTube 広告の運用の手順書にまとめました。

---
name: youtube-ads-playbook
description: >-
  YouTube 広告の設計と運用。課金の地点から逆算した構成、入札、日予算の上げ方、
  不承認への対応を扱う。
  「YouTube 広告を運用したい」「日予算を上げたい」「CPA が高い」で使う。
  ※媒体を決める前は媒体選定のスキル、レポートは広告レポートのスキル。
---
# YouTube 広告の運用

## 先に決める
- どの時点で課金される形式か（ここから動画の冒頭の作りが変わる）
- 計測の紐づけ（動画を見た後の行動をどこで数えるか）

## 運用の規則
1. 日予算は一度に大きく上げない（上げ幅と間隔を手順に書く）
2. 入札の変更とクリエイティブの差し替えを同じ週にやらない
3. 不承認は理由を控え、直した箇所を 1 つずつ記録する

## やらないこと
- 再生数を成果として報告しない（見るのは行動と CV）

「先に決める」の先頭は課金の地点です。スキップ可能なインストリーム広告なら、30 秒見るか操作するまで課金されず、最初の数秒でスキップした人には払いません。この形式では冒頭で「誰に向けた広告か」を言い切り、対象外の人にスキップしてもらう構成が正しく、形式が変われば冒頭の作りも変わります。ここが決まらないまま台本（第 4 章）へ進ませないための順番です。「再生数を成果として報告しない」も置きました。課金の地点と成果の地点は別で、見た回数を成果のように書くと、行動と CV が読めなくなるからです。

日予算の上げ幅と間隔は「手順に書く」としました。Google の自動入札は変更の直後にしばらく揺れ（「学習期間を壊さない」の小節）、目安が無いとエージェントは毎日の数字で毎日動かします。幅の数値は案件ごとに決めるので、骨子には入れていません。入札の変更とクリエイティブの差し替えを同じ週にやらない、不承認は 1 つずつ記録する。この 2 つは、複数を同時に変えるとどれが原因か分からないまま、次の広告に同じ表現を使うことになるからです（次の小節）。description では、媒体を決める前の依頼を媒体選定のスキルへ送っています。「動画広告を出したい」の一言で、YouTube に決め打ちした入稿が始まらないようにするためです。

審査で落ちたら、1 回に 1 箇所ずつ変えて切り分ける

広告が審査で落ちたときに、原因を特定しないまま申請を繰り返すと、広告アカウントの制限につながるおそれがあります。次の順で、1 回に 1 箇所ずつ変えて切り分けます（著者の運用での順番）。

1. 媒体の説明を読み、どのポリシーに当たったのかを確かめる。媒体の誤判定と考えられるなら、再審査を申し立てる
2. クリエイティブを 1 箇所変える（冒頭、テロップ、素材のどれか）
3. 遷移先のページの表現を変える（効果の断定、注記の不足）
4. 広告文の表現を弱める

複数の箇所を同時に変えると、どれが原因だったのか分からないまま、次の広告に同じ表現を使うことになります。成果の良い広告ほど表現が強く、審査で止まりやすい傾向があります。止まってから慌てないよう、表現を弱めた代わりの版を先に用意しておきます。

例: 週次の運用チューニングの SKILL.md

配信中の広告の実績を読んで、何をどう動かすかを提案するところまでを担う手順書です。変更は実行せず、入稿・変更のスキルへ渡します。骨子は次のとおりです。

---
name: weekly-ad-tuning
description: >-
  配信中の広告の直近の実績を読み、「触らない / 入札を変える / 予算を変える /
  クリエイティブを差し替える / 止める」のどれにするかを広告セットごとに提案する。
  「広告の調整案を出して」「CPA が上がったので見直して」「予算を増やしていいか見て」で使う。
  ※提案までを行い、変更の実行は入稿・変更のスキルへ渡す（確認画面を通る）。
  ※月次・週次の報告書の作成は広告レポートのスキルへ。
---
# 週次の運用チューニング

## 先に確かめること
- 案件の目標 CPA、撤退ラインの倍数、1 回に動かしてよい幅（既定は 20%）
- 各広告セットの最後の大きな編集の日付。7 日以内のものは判定せず「学習中」と書く

## 手順
1. 直近 7 日と、その前の 7 日の実績を広告セット・広告ごとに取得する（読み取りのみ）
2. 消化のペースを日予算と比べる。1 日単位ではなく 7 日の合計で見る
3. 次の順に判定し、最初に当てはまったものを採る
   - 最低消化額に届かない → 判定しない
   - 撤退ラインの額を使って成果 0 件 → 停止を提案
   - 消化が速く成果が少ない → 目標 CPA を下げる
   - 消化が遅く成果がついている → 目標 CPA を上げる
   - 目標どおり → 触らない
4. クリック率が 3 週続けて下がっている広告は、差し替えを提案する

## 守ること
- 1 回の提案で動かす幅は 20% まで。同じ広告セットを 1 週間に 2 回変えない
- 成果 0 件の CPA を 0 円として扱わない
- 管理画面の成果と実際の予約数がずれている案件は、その差を提案に書く

## 出力の型
| 広告セット | 判定 | 根拠の数字 | 提案 | 確認の要否 |
増額と配信開始は「確認が要る」、停止と減額は「即時に実行できる」と書き分ける

## データが取れないとき
- 取れた媒体だけで判定し、取れなかった媒体は「未取得」と理由を書く

この手順書は提案までに限り、変更の実行は入稿・変更のスキルへ渡します。配信・停止・大幅な増額の判断を人に残すためです。提案と実行が同じ手順書にあると、「見直して」という依頼で読み取りから書き込みまで一続きに進み、確認画面には提案の途中で決まった値が並びます。目標 CPA・撤退ラインの倍数・動かす幅は「先に確かめること」で受け取り、手順書の側には数値を入れていません。数値はクライアントごとに計算し直すものだからです。撤退ラインを金額ではなく倍数で受け取るのは、商材が変わっても同じ規則で判定できるためです。

判定の順番は固定し、「判定しない」条件を先頭に置きました。後ろに回すと、消化額の少ない広告セットで成果が 1 件増減しただけで、停止や増額が提案されます。最後の大きな編集から 7 日以内を「学習中」として外すのは、その最中の編集が学習をやり直しにするため。消化のペースは 7 日の合計で見ます。Meta は 1 日に日予算の最大 75% 増しを使う日があり、1 日単位では「使いすぎ」の誤判定が出るからです。「守ること」の 20% と週 2 回の上限は、目標を大きく動かすと配信が止まり、頻繁に触ると学習期間から出られないためです。成果 0 件の CPA を 0 円として扱わないのは、優良判定に合致して増額が提案されるからです。管理画面と実際の予約数のずれも提案に書かせます。自動入札が合わせにいくのは管理画面の成果の CPA で、ずれたまま目標を下げると配信が止まりやすくなります。「3 週」「20%」は例で、案件ごとに決めます。出力の型にある確認の要否の列は、次の節の「お金が動く向き」の線引きを、提案の段階から読み手に見せるためのものです。「データが取れないとき」に取れた媒体だけで判定させるのは、片方の媒体が読めない週に提案がゼロになるのを防ぐためです（原則 C）。

自動化ルールはトリガー（条件 + 実行）

1 時間ごとの巡回はエージェントを通らない

配信中の見張りは 1 時間ごとの巡回で行い、判定は決定論の関数に閉じます（原則 Q）。自動化でいちばん大事なのは、「なぜ止まったか」を後から再現できることだからです。巡回は実績を 1 回だけ引いて有効なトリガーを順に判定し、1 つの案件・1 つのトリガーの失敗で全体を止めません。時間の予算を超えたら、未処理の件数を必ず返します。件数を返さずに打ち切ると「全部見た」ように見えてしまいます。

トリガーは条件と実行の組です。条件は広告の実績（直近の CPA・CTR・消化額など）、広告の時間指定（曜日と時刻）、検索パフォーマンス（Search Console の直近の実績）の 3 種類。実行は、通知する、タスクを作る、停止する、日予算を増減する、複製する、配信を開始・停止する、の 6 つです。組める組み合わせは表 1 箇所で決めます。時間指定から通知やタスクは作れません。決まった時刻にひとりでに動くものの置き場は定期実行（原則 M）で、ここに時刻起点を足すと「止めたつもりのものが動いていないか」を 2 箇所で見比べることになります。検索の実績から広告も操作できません。どの広告を止めるかが決まらないからです。弾くときは「代わりに定期実行へ」と代替を書き添えます。

「お金が動く向き」で切る

1 時間ごとの巡回はサーバーが自分で動かし、エージェントを通りません。そのため、巡回の中で行う停止や増額には、パーミッションの確認画面は出ません。人が確認できるのは、エージェントがトリガーを有効にするツールを呼んだときだけです。そこで、実行する操作を「お金が動く向き」で分け、支出が増える向きの操作を含むトリガーは、有効にする呼び出しの確認画面で人が確かめます。

トリガーが増額・配信開始を含むかどうかを判定する関数は 1 つに集約し、含むトリガーは、確認の対象（ask）にした有効化のツールからしか有効にできない形にします。分岐が散ると、人が確認しないまま広告費が増える経路ができ、しかもどの分岐が抜けているのかはコードを読むまで分かりません。確認画面に出るのはツールの名前と引数だけなので、有効化のツールの引数にはトリガーの ID だけでなく上限・対象・時刻も含め、サーバーの側で保存済みのトリガーと食い違っていないかを確かめます。加えて、媒体へ書き込む側でも、増額と配信開始は「有効化の確認を経たトリガーからの実行」であることを呼び出し側が明示しないと受け付けない形にし、二重に通らないと実行されないようにします。新しい経路を足したときに、確認を経ずに配信が始まらないための、既定で通さない設計です。自動で実行した分は確認画面を通りません。発火の履歴と通知が唯一の手がかりなので、通知先が無いトリガーは有効にできない形にします（原則 N）。例外はタスクを作る実行だけで、作られたタスクがボードに残ります。見送った回も理由（最低消化額に届かない、クールダウン中）を残します。

{
  "name": "CPA が上がった広告セットを止める",
  "media": "Meta",
  "condition": {"kind": "広告の実績", "metric": "CPA", "comparison": "より大きい", "threshold": 4000},
  "window_days": 7, "min_spend": 10000,
  "target": {"level": "広告セット", "ids": []},
  "action": "停止する",
  "cooldown_minutes": 1440, "max_per_day": 3
}

暴走を防ぐ設定は 5 つ。判定する最低消化額（0 のままだと 1 件の成果の揺れだけで停止が走る）、集計期間、クールダウン、1 日の上限回数、予算の下限と上限（両方必須。片方だけだと反対向きの制限が無い）。変更後の額が現在と同じなら動かしません。上限に達したままの予算を毎時「上限に設定し直す」書き込みが走ると、発火履歴が埋まって本当の変化が見えなくなります。媒体でできることの差は登録時に止めます。実行時にだけ落ちると、「失敗しました」が毎時 Slack に流れ続けます。

例: トリガーの作成を頼む

上の JSON は、トリガー 1 つ分の保存形式です。マーケターがエージェントに作成を頼むときは、止める側と増やす側を分けて書きます。

駅前の美容室の Meta 広告に、次の 3 つのトリガーを作ってください。

1. 止める: 直近 7 日の CPA が 4,000 円を超えた広告セットを停止し、Slack の広告通知チャンネルに知らせる。
   7 日の消化額が 10,000 円に届かない広告セットは判定しない。
   成果が 0 件の広告セットは CPA を計算できないものとして扱い、この条件では判定しない。
2. 知らせる: 成果が 0 件のまま 7 日の消化額が 10,000 円を超えた広告セットがあれば、停止はせず Slack に知らせる。
3. 増やす: 直近 7 日の CPA が 2,500 円を下回り、成果が 5 件以上ある広告セットの日予算を 20% 増やす。
   日予算の上限は 5,000 円、下限は 1,000 円。1 日 1 回まで。次の判定まで 24 時間空ける。

作成したら、各トリガーの条件・対象・実行・上限を表にして見せてください。
有効にするツールを呼ぶと確認画面が出るので、私が表と見比べて許可します。
3 つ目は予算が増える向きなので、上限と対象を特に確かめます。断ったトリガーは、別の方法で有効にしないでください。

成果 0 件の扱いを書いているのは、書かないと CPA が 0 円として計算され、「2,500 円を下回る」に合致して増額が起きるからです。一方で、0 件の広告セットを判定から外すだけでは、成果の出ない広告セットが消化を続けても誰も気づきません。2 つ目で通知だけを入れているのはそのためです。逆に「CPA が高ければ止めて、低ければ増やして」とだけ頼めば、閾値も最低消化額も予算の上限も、すべてエージェント任せになります。

ルールを 1 つも書いていない案件でも見張るもの

広告アカウントの停止、審査で落ちた広告、配信中なのに 1 回も表示されていない広告、発火していないピクセル。誰かが設定するまで放置してよい異常ではないので、標準で毎時見張ります。何も外に反映せず、状態が変わったときだけ通知します。毎時同じ警告が飛ぶと、すぐ誰も読まなくなります。取得に失敗したチェックは判定せず理由だけを残し、公式で対応するフィールドを確認できていない媒体では、そのチェック自体を一覧に出しません（原則 G）。Meta の判定をそのまま当てると、どちらかが必ず嘘になります。

検索パフォーマンスを条件にするときは、取れなかった期間を 0 として扱いません。「クリック数が閾値を下回った」に必ず合致し、連携が切れた案件に毎時アラートが飛び続けます。サイトが複数ある案件で「1 件目」を自動で選ぶこともしません。別のサイトの数字で発火し、画面には正しいサイト名が出たままになるからです。

計測を補う：サーバー側から成果を返す

ブラウザに置いたピクセルは、トラッキング防止機能や広告ブロッカー、Cookie の制限で欠けます。欠けた成果は媒体の最適化にも実績にも載りません。これを補うのが、サーバー側から成果を送る API（Meta ではコンバージョン API）です。予約完了や購入をサーバーが知った時点で、媒体に直接送ります。

決まりごとは公式で確認できたものだけ実装します。イベント ID は必須で、ピクセル側と同じ値にします。違うと同じ成果が二重に数えられるので、こちらで採番せず呼び出し側に指定させます。発生時刻は 7 日以内。1 件でも古いとリクエスト全体がエラーになります。発生源が Web サイトなら発生ページの URL が必須です。メールアドレスや電話番号はハッシュ化して送りますが、ハッシュはサーバー側で行い、元の値は保存しません。電話番号は国番号込みで受け取り、こちらでは補いません。テスト用のイベントコードを付けずにテスト送信すると実績に計上され、取り消せません。

受信口の鍵はブラウザ側の JavaScript に書きません。ページのソースを見れば誰でも読め、任意の成果を送り込まれます。送信は LP のバックエンドやサーバーサイドのタグ管理、予約システムから行います。受信口は書き込み専用にし、読み取りの口を生やしません。鍵 1 つで他人の成果データが読めてしまうからです。存在しない案件も鍵の不一致も同じ「見つかりません」で返し、ID の存在を漏らしません。媒体の応答の構造を公式で確認できていないなら、キーを決め打ちで取り出さず応答を丸ごと保存し、成否は HTTP のステータスで判定します（原則 G）。計測 ID のダミー投入は禁止です。入っているように見えて何も送っていない状態は、未設置より発見が遅れます。LINE の友だち追加を広告の成果として返す設計は第 9 章で扱います。

レポート：読み手は数字が読めない人

直す順番はいつも同じです。まず押されるか（CTR）、次に申し込まれるか（CVR）、その結果として 1 件あたりいくらか（CPA）。CTR が低ければ見せ方を、CVR が低ければ広告ではなく遷移先を疑います。CTR だけを引き上げる誇大な表現は、申し込む気のない人のクリックに広告費を払うことになるので逆効果です。

コメントは 3 層で書きます。事実（何がどう変化したか）、解釈（媒体の傾向、クリエイティブの疲労、季節性、競合。「〜と考えられる」と仮説を明示）、次にやること（3 つまで、担当と期限つき）。悪化した指標を「悪化した」で終わらせません。

読み手は店舗のオーナーや広報担当です（原則 O）。「一言でいうと」から始め、専門用語を出さず、数字には意味の文を添えます。「CPA 3,200 円（前月比 +18%）」ではなく、「予約 1 件を取るのにかかった広告費は 3,200 円。先月は 2,700 円だったので 500 円ぶん悪化した」と書く。率は人数に言い換え（CVR 2.1% は「100 人のうち 2 人が申し込んだ」）、比べる相手を必ず置き、良し悪しはこちらが言い切ります。成果保証と読める表現は書きません。数字が合っていても、読めなければ届いていない。しかも数字は正しいので、提出後に誰も間違いだと言えません。

競合の広告クリエイティブを載せるときは、画像をファイルに落としてから貼ります。媒体のクリエイティブ URL は署名付きで短時間に失効し、本文に貼ると翌日には全部消えます。貼った画像は読むためのもので、自社の広告に使える素材ではありません。素材ライブラリにも出しません。公開の広告アーカイブから出稿額や再生数は取れないので、「継続配信〇日・同一クリエイティブ〇件」という観測事実で当たりを語り、「推定出稿額」には変換しません。

週に 1 度の「次の一手」もレポートの一種として、定期実行（原則 M）に載せます。判断できるほど数字がたまっていないときは「今週は触らずに待つのが正解です」と言い切ります。始めた翌日の数字で設定をいじると学習がやり直しになり、いつまでも安定しません。

遷移先の問題を、広告の数字から切り分ける

上で「CVR が低ければ遷移先を疑う」と書きました。原因が広告にあるのか遷移先にあるのかは、クリックから申し込みまでを段に分けると切り分けられます。

2 段目以降の問題は、既存ページの監査（第 4 章）に渡します。監査の点数は直す場所の候補を絞るためのもので、CVR が上がるかどうかは配信して測るまで分かりません。改善を実験として比べる方法は第 11 章で扱います。

客先に出すレポートの構成

社内で見る報告と、クライアントに提出する資料は分けて作ります。提出する資料は、次の 9 ページを基本にしています。

• 主役の数字は業態で変わります。予約・来店が成果の店舗集客型では、成果の件数と CPA が主役です。物販では売上と ROAS を加え、本命の商品と他の商品の購入が混ざるときは、本命と副次を別の行にします。
• 訴求の型別の集計は、媒体からは返りません。広告の名前に訴求の型を入れる命名規則（第 4 章）があれば、名前から機械的に分けられます。命名規則が無い案件ではこのページを作らず、「次月までに命名規則を決める」を宿題として書きます。
• 予算の再配分案を金額で書くには、実績ではなく、キャンペーンや広告セットの設定（現在の日予算）が要ります。実績とは別に取得します。取れなければ、再配分案は「増額・縮小・停止」の向きだけで書きます。
• 取れなかった数字は、提出前に管理画面の書き出しなどで埋めます。それでも埋まらない指標は、0 や空欄の行として残さず、表から外します。外した指標は、まとめのページに「来月から載せるために必要なデータ」として書きます。

7 ページと 8 ページは、次の形で組み立てさせます。

# 原因の仮説と次にやること（ページ 7・8 の例。駅前の美容室）
原因の仮説:
  - 内容: 7 月 20 日から、成果の多かった「髪質改善」の広告が審査で止まり、配信が他の広告に移った
    優先度: 最有力
    再現: できる（審査を通る表現に直して再開すれば戻る見込み）
    確かめること: 審査の状態、止まった日と CPA が上がり始めた日が一致するか
  - 内容: 夏休みで学生の予約が増えた
    優先度: 中
    再現: できない（季節の需要）
次にやること:
  - 何を: 「髪質改善」の広告の表現を弱めた版を申請する
    いつ: 即日
    見込む効果: CPA を 7 月前半の水準（約 3,200 円）に戻す
  - 何を: CPA が目標の 2 倍を超えている下位 2 本を停止する
    いつ: 翌日
    見込む効果: 月の消化のうち約 1.5 万円を上位の広告に回せる
予算の再配分:
  - 広告セット: 髪質改善_20-39歳
    現在の日予算: 1500
    提案: 2000
    理由: 目標 CPA の範囲で成果がつき、予算の上限で配信が抑えられている

次にやることに「見込む効果」を書かせると、翌月のレポートで、その打ち手が効いたかどうかを比べられます。見込む効果が書かれていない打ち手は、効いたかどうかを誰も確かめません。原因を再現できるものとできないものに分けておくと、季節の需要で伸びた月の数字を、来月の目標にしてしまうことも防げます。

例: 広告運用レポートの SKILL.md

「実績を取る」の節の例で示した週次の依頼を、毎週書かなくて済むようにスキルにまとめた例です。読んで書くだけで、広告には触らない手順書です。書式は第 2 章に合わせ、骨子だけを載せます。

---
name: ad-weekly-report
description: >-
  広告媒体の実績から週次・月次の広告レポートを作る。指標を計算し、前期間比・目標比の
  評価、原因の仮説、次にやることまで書く。「広告レポートを作って」「先週の広告の数字を
  まとめて」「CPA を出して」「なぜ予約が減ったか見て」で使う。
  ※広告の作成・停止・予算変更はしない（入稿のスキルへ）。SNS や検索流入まで含めた
  横断の定例まとめは、チャネル横断レポートのスキルへ。
---
# 広告運用レポート

## 手順
1. 対象を確定する: 媒体、広告アカウント名、期間、比較期間、成果として数える行動。
   決まっていないものがあれば、取得を始める前にまとめて 1 回で聞く
2. 実績を媒体ごと・日次で取得する。読み取りのツールだけを使う
3. 単位をそろえる: 金額は媒体の単位から円に直す。CTR・CPA などの率は媒体の値を使わず、
   表示回数・クリック数・消化額・成果の件数から計算する
4. 評価する: 媒体ごとに前期間比・目標比を出し、◎ ○ △ ✕ で判定する

## 守ること
- 媒体をまたいで成果の件数と CPA を足さない。消化額は同じ通貨のときだけ合計する
- 成果 0 件の CPA は「—」。取れなかった数字は 0 で埋めず「未取得」と理由を書く
- 原因は「〜と考えられる」と書き、事実と分ける

## 出力の型
1. 一言でいうと（3 行。専門用語を使わない）
2. いま何が起きているか（媒体ごとの表と判定）
3. なぜそうなったか（仮説）
4. 次にやること（3 つまで。担当と期限）
5. 詳しく見たい人へ（指標の明細、成果の定義、取得経路、データの限界）

## 取得できないとき
- 管理画面の CSV を 1 回の依頼で頼む（媒体、期間、日別・広告セット別、消化額・表示回数・クリック数・成果の列）
- CSV が届く前でも、取れた媒体の分で書き切り、欠けている媒体を冒頭に書く

この手順書は読み取りだけに限り、description で入稿を除外しています。「数字を見て止めておいて」のような依頼でこの手順書が選ばれると、レポートの途中で書き込みの判断が入るからです。横断のまとめを別の手順書へ送るのは、投稿の再生数と広告の表示回数が別の数字だからです。同じ表に並べば足されてしまいます。依頼の言い方には「先週の広告の数字をまとめて」をそのまま入れました。足りない依頼文の例のような短い依頼でも、この手順書が立ち、定義を確定する工程から始まるようにするためです。

手順 1 では対象を確定させ、取得の前にまとめて 1 回で聞かせます。短い依頼で起きる失敗（件数の合算、アクション種別の選択、「先週」の始まりのぶれ）は 3 つとも定義の欠落から来ていて、どれもエラーになりません。手順 3 で率を分子分母から出させるのは、CTR の単位が媒体で違い、行の粒度によって率の意味も変わるからです（原則 D）。合算を禁じた理由は、成果の数え方が媒体で違うこと。足した金額を足した件数で割った瞬間、意味の違う数字の平均になります。消化額を同じ通貨のときだけ合計するのも同じ理由です（原則 E）。成果 0 件の CPA は「—」、取れなかった数字は「未取得」にします。0 が入ると平均も前月比も崩れ、CPA 0 円が優良に見えるからです。

出力の型が「一言でいうと」から始まるのは、読み手が店舗のオーナーや広報担当だからです（原則 O）。数字が合っていても読めなければ届かず、数字は正しいので提出後に誰も間違いだと言えません。「詳しく見たい人へ」に成果の定義を置くのは、定義を変えると過去の CPA の見え方も変わるからです。「取得できないとき」を書いたのは、連携が切れた週にレポートがゼロになるのを防ぐためです（原則 C）。期間の日付・成果の定義・読み手は毎回変わるので依頼文に残し、単位・合算禁止・0 の扱い・構成はこの手順書に固定しています。

一次情報をどこで確かめるか（執筆時点）

仕様は変わります。実装前に必ず公式ドキュメントで最新を確認してください。

• Meta: ads MCP server の概要、ads MCP server の始め方、広告の作成と管理のツール、ads MCP server の公開と審査の案内（2026 年 7 月 16 日の開発者ブログ）、Marketing API、アクセス階層と審査、通貨のオフセット、コンバージョン API
• Google: Google Ads MCP server、google-ads-mcp（GitHub）、Google Ads API、アクセスレベル、開発者トークンの廃止、P-MAX のアセットグループ、一時リソース ID の規則
• TikTok: TikTok for Business MCP Server（ヘルプセンター）、Marketing API（TikTok API for Business）
• LINEヤフー: MCP サーバー提供開始のお知らせ、ly-ads-mcp-server（GitHub）、LINEヤフー広告 Developer Center、アプリケーションの登録

各媒体が利用者向けに公開しているヘルプセンターの記事も、指標の定義（何を成果と数えるか、率の分母は何か）を確かめる一次情報として併用してください。API リファレンスとヘルプの説明が食い違ったときは、API 側で確認できたものを実装の根拠にします。

章のまとめ

• 広告運用は 7 工程を順に渡す形。オーケストレータは順番と受け渡しだけを持ち、数値基準は担当スキルの正本を読ませる。媒体選定と入稿前の環境チェックは省略しない。
• 媒体とは公式 MCP でつなぎ、MCP でできない書き込み（Google・LINEヤフー）だけ API で補う。同じ媒体の実績を 2 つの経路で読まない。4 媒体の階層は同じ形で、トークンの持ち方と審査が違う。運営側の資格は案件に持たせず、顧客 ID は鍵ではない。「鍵がある」と「読める」を分け、アカウント名を画面に出し、ID は一覧から選ばせる。書き込みのツールはすべて ask に入れ、組織では外せない設定で固定する。
• 単位・語彙・階層の媒体差は 1 表に集約し、条件式として散らさない。単位は経路ごとに確定し、確定できない値は取らずに分子分母から出す。
• 作成は停止状態、配信開始は別の確認。一式を 1 回の呼び出しにし、必須項目と文字数（全角 2 カウント）は手前で数える。
• 確認画面で許可した呼び出しは、表示のまま 1 回だけ実行される。書き込みのツールと ask の一覧を揃え、確認を迂回する経路を作らない。確認画面にはツールの名前と引数しか出ないので、名前と引数を人が読める形にし、実行の記録はツールの側に残す。
• 成果の定義は媒体で違う。消化額は足せても CPA は足せない。CV が 0 件の CPA を 0 にしない。取れなかった数字は「未取得」。
• 1 時間ごとの巡回はエージェントを通らないので、確認画面は出ない。トリガーは「お金が動く向き」で切り、増える側は有効にする呼び出しを 1 回確認する。通知先が無ければ有効にできない。判定は決定論で、媒体差は登録時に止める。
• 計測はサーバー側から補い、イベント ID で重複を排除する。ダミーの計測 ID を入れない。レポートは「一言でいうと」から始め、数字に意味の文を添える。
• 運用チューニングの基準は「判断の構造」と「数値」に分けて持つ。目標 CPA と撤退ラインはクライアントの客単価と粗利から計算し直し、撤退ラインは目標 CPA の倍数で書く。
• 学習期間を壊さない。変更は 1 回 20% までにして間隔を空け、成果が少ない案件は中間の行動を最適化の対象にする。入札は消化のペースと成果の付き方の組み合わせで動かす。
• 審査落ちは 1 回 1 箇所ずつ変えて切り分け、入稿の失敗は「誰が直せるか」で返し方を分ける。検索広告の見積もりはキーワードプランナーの実数で行い、競合性を SEO の難しさとして読まない。

演習

1. 自分が扱う広告媒体について、「媒体で揃っていないもの」の表を自分の言葉で埋めてください。金額の単位、CTR の単位、配信中の語彙、作成時の既定状態、日予算の階層、複製 API の有無、成果の決まり方。埋められない項目は公式ドキュメントで確認し、確認できなかった項目は「取らない」と決めてください。
2. いま手元にある広告の操作（作成・配信開始・停止・増額・減額・複製・素材アップロード）を、「お金が増える向きか」「取り消せるか」の 2 軸で分類し、どれを確認の対象（ask）にし、どれを即時に自動化するかを表にしてください。
3. 先月の広告レポートを 1 つ選び、「一言でいうと」の 3 行を専門用語ゼロで書き直してください。CPA・CVR・ROAS を使わずに、数字に意味の文を添えて書けるかを確かめてください。
4. 自分の案件の 1 つについて、目標 CPA と撤退ラインを、客単価・粗利率・来店回数から計算し直してください。手元の手引きにある数値と比べ、その数値がどの業種の実測だったのかを書き添えてください。

次の章へ

広告は、クリックから成果までの距離が短い経路でした。次の第 6 章「SEO/LLMO を自動化する」では、どこから来たかがすぐには分からない流入を、Search Console と GA4 の連携、監査モジュール群、順位計測、AI 検索での言及計測まで含めて追いかけます。ここで確定させた「単位は経路ごとに」「取れなかった数字は未取得」の原則が、検索の数字でもそのまま効きます。