cotomu

AI × AD OPERATIONS

AIで広告運用を自動化する前に。権限設計と変更確認の実務

AIエージェントは、広告データを読み、変更案を作り、APIで反映できます。 それでも最初に決めるべきなのは、モデルの性能ではありません。 どのアカウントで、何を、誰の確認後に実行できるかです。

公開日 2026年7月30日読了目安 8分株式会社adding

自動化の成否は、実行範囲を説明できるかで決まる

AI広告運用の自動化は、読み取りと書き込みを分け、対象アカウントと変更手順を限定して始めます。 AIに渡す指示文より先に、権限と確認の境界を決めてください。

広告運用で起きる事故は、AIの回答が少しずれたときだけに発生するわけではありません。 別クライアントのアカウントを選ぶ、意図より広い期間へ変更をかける、確認前の案を本番へ反映する。 こうした問題は、接続先と操作権限が曖昧なまま自動化したときに起こります。

cotomuでは、業務やクライアントごとの単位をpromotionとして扱い、接続する広告アカウントを限定します。 API keyはREADONLYとREAD_WRITEを分離できます。 変更は理由と対象をChange Planへ記録し、previewで確認材料をそろえてからapplyします。

PERMISSION DESIGN

権限は4つの境界へ分ける

「AIに広告運用を任せる」という一文には、対象、権限、変更、確認という別々の判断が混ざっています。 一つずつ言葉にすると、どこから自動化できるかが見えます。

境界決めることcotomuで対応する要素
対象どのpromotion・広告アカウントへ接続するかpromotion whitelist / DataSourceAccount
権限読み取りだけか、変更も許可するかREADONLY / READ_WRITE
変更何を、なぜ変えるかChange Planのoperation / reason
確認apply前に誰が何を見るかpreview + 外部の承認手順

OAuthで接続する場合は、Owner / Manager / Staffのroleとpromotion grantも別に扱います。API keyのREADONLY / READ_WRITEと同じ概念ではありません。

READ FIRST

最初の実装は、読み取りと提案作成に絞る

自動化の初期段階では、AIにREADONLYのAPI keyを渡します。接続済みアカウントと配信状態を読み、変更案だけを作らせる構成です。 書き込み権限がないため、プロンプトや処理に不備があっても広告設定は変わりません。

接続先と配信状態を確認

READONLY
cotomu promotion accounts <PROMO_ID>

cotomu google-ads query <PROMO_ID> <DSA_ID> \
  --gaql "SELECT campaign.id, campaign.name,
  campaign.status FROM campaign"

ここで確認したいのは、AIの提案が当たるかだけではありません。 promotionとDataSourceAccountの対応が正しいか、停止中のcampaignを変更対象に含めていないか、担当者が同じデータを再確認できるか。 実行の土台を先に検証します。

CONTROLLED WRITE

書き込みは、変更案をplanとして切り離す

読み取りが安定したら、変更案を本番操作から切り離します。 cotomu Public APIの書き込みはChange Plan経由に統一されており、直接のraw mutateは拒否されます。planには変更理由とoperationを積み、preview後にapplyします。

変更を作成・確認・適用

CHANGE PLAN
cotomu change-plan create <PROMO_ID> \
  --title "除外KW追加" \
  --reason "無関係クエリ除外"

cotomu change-plan add-op <PROMO_ID> <PLAN_ID> \
  --op-type google_ads.keyword.create \
  --data-source-account-id <DSA_ID> \
  --payload '{"ad_group_id":"<AD_GROUP_ID>",
  "text":"無料","match_type":"EXACT","negative":true}'

cotomu change-plan preview <PROMO_ID> <PLAN_ID>
# 担当者が対象・理由・検証結果を確認
cotomu change-plan apply <PROMO_ID> <PLAN_ID>

previewは承認状態ではない

previewは、operationごとの検証結果や変更前の情報をそろえる工程です。 GA4やGTMなど、上流APIにvalidate相当機能がない操作はskippedと表示される場合があります。 また、担当者確認は現行APIが必須のsystem statusとして強制するものではありません。 apply前に誰が何を読むかは、チームの承認手順として設計します。

本番へつなぐ前に、4つの問いへ答える

01

アカウント境界

AIが触れてよいpromotionと広告アカウントを列挙します。「全社の広告」では広すぎます。クライアント別、ブランド別、環境別に対象を切り分けます。

02

操作境界

分析、提案、下書き、書き込みを分けます。READONLYのAIが提案を作り、READ_WRITEの経路だけが変更を実行する構成なら、役割を混同しにくくなります。

03

確認境界

予算、配信状態、キーワードなど、操作ごとに確認責任者を決めます。previewは確認材料です。人の承認そのものを代替する状態ではありません。

04

記録境界

変更理由、対象resource、実行結果、再試行に使うidempotency keyを追えるようにします。失敗時の連絡先と、戻す操作の作り方も先に決めます。

境界が決まらない操作は、自動化しない

誰が確認するか決まっていない予算変更、正否を機械判定できないクリエイティブ判断、緊急停止時の連絡経路がない操作は、書き込みへ進めません。 AIには分析と提案作成までを任せ、人が媒体管理画面で反映する方が適切です。

自動化率を上げること自体を目標にすると、この停止判断が遅れます。 先に決めるべき指標は、変更対象を説明できるか、確認者が同じ情報を再現できるか、失敗を検知できるかです。 三つがそろった操作から書き込みへ移します。

AI広告運用の権限設計でよくある質問

AIに広告アカウントの閲覧だけを許可できますか？

はい。cotomuのAPI keyはREADONLYとREAD_WRITEを分けられます。分析専用のAIエージェントにはREADONLYを使い、promotion whitelistと接続アカウントの範囲も限定します。

Change Planのpreviewを実行すれば、人の承認も完了しますか？

いいえ。previewは変更内容や対応operationの検証結果を確認する機能です。担当者確認は現行APIが強制するsystem statusではないため、apply前に誰が何を確認するかを外部の運用手順として定めます。

広告運用のすべてを最初から自動化するべきですか？

対象アカウント、許可する操作、確認責任者、失敗時の対応が決まっていない段階では、まず読み取りと提案作成に限定するのが現実的です。境界が固まった操作から、Change Planを経由して書き込みへ広げます。

NEXT STEP

自社の権限構成を、実際のアカウント単位で整理する

現在の広告媒体、運用担当、AIに任せたい作業を伺い、読み取りから始める範囲と、Change Planへ進める操作を整理します。相談時点でAPI仕様が固まっていなくても構いません。

自社の権限構成を相談する