広告・計測データの実行基盤
広告データを、
AIの実行基盤へ。
cotomuは、広告・計測アカウントをpromotion単位で整理し、CLI、MCP、REST APIから同じデータへ接続します。読む操作と変更する操作を分け、変更時はpreviewと担当者確認を組み込む運用を推奨します。
対応する媒体・操作・OAuth権限は契約と接続アカウントにより異なります。自律的な書き込みを無条件に約束するものではありません。
One source, three entries
同じpromotionを呼び出す
- CLI
- cotomu promotion list
- MCP tool
- list_promotions
- REST API
- GET /api/v1/promotions
返す対象
API keyまたはOAuth tokenに許可されたtenantとpromotionの範囲だけ。読み取りと書き込みのpermissionは分離されます。
実行入口
入口が違っても、scopeは一つ。
どの経路でも、tenantとpromotion、接続済みdata source accountを起点にします。AIの名前ではなく、誰がどの範囲へアクセスできるかを先に決めます。
- 01
promotion
- 02
data source account
- 03
query / change plan
- 04
response / audit
- CLI
- 自動化・script・CI
- OAuth login後、通常はOS keychainのtokenを使ってcommandを実行。keychainが使えない環境では権限を制限したconfig fileへ保存します。JSON出力、idempotency key、retryを扱えます。
- MCP
- 人がAI toolから対話的に利用
- HTTP MCP serverとしてtoolを公開。自然文からpromotionやqueryを選び、Public APIへ接続します。
- REST API
- 社内tool・独自workflow
- OpenAPIで定義したendpointへ直接接続。API keyはpermissionとpromotion whitelist、OAuthはroleとpromotion grantで範囲を決め、操作履歴を残します。
導入前の確認
最初に、接続先と権限を決める。
「AIをつなぐ」だけでは運用を始めません。対象、認証、変更権限を分けることが、最初の設計です。
- 01
対象promotion
どのブランド・案件・期間を扱うか。API keyやuserがアクセスできるpromotionを固定します。
- 02
接続アカウント
Google Ads、Meta、GA4など、必要なdata source accountとOAuth scopeを確認します。
- 03
読む / 変更する
API keyではREADONLY / READ_WRITEを選びます。OAuthはOwner / Manager / Staffのroleとpromotion grantで範囲を決め、Staffは現状readのみです。書き込みの停止点も先に決めます。
向かない運用
対象アカウントや変更責任者を決めず、AIへ無制限の書き込みを任せたい場合には向きません。媒体・操作ごとの提供状態は相談時に確認します。
対応範囲
読む、提案する、反映するを分ける。
「連携済み」を一括りにせず、data sourceごとに読み取りと書き込みの経路を示します。以下はPublic APIで確認できる代表範囲です。
| DATA SOURCE | READ | WRITE / BOUNDARY |
|---|---|---|
| Google Ads | GAQL query、検索語句、改善候補、simulation | Change Plan（preview → apply） |
| Meta Ads | Graph node + fields query | Change Plan（preview → apply） |
| GA4 | Admin API / Data API query | Change Plan（analytics.edit必須） |
| GTM | container / workspace / tag等のquery | Change Plan（操作別scope必須） |
| Search Console / YouTube / PageSpeed | 認可済みsite・channel配下のquery | 提供なし |
狭い画面では、表を選択して左右矢印キーまたは横スクロールで確認できます。
実際の提供可否はtenant、promotion、接続アカウント、OAuth scope、feature gateで決まります。表は成果や自動反映を保証するものではありません。
操作の単位
AIの会話を、
追える操作へ。
抽象的な「自動化」ではなく、対象の特定、query、変更案、監査という単位で扱います。
- 01
探す
promotionと接続先を特定
cotomu promotion accounts <PROMO_ID>tenant内で許可されたpromotionとdata source accountを確認し、別案件・別accountへの越境を防ぎます。
- 02
読む
媒体APIへscope付きquery
cotomu google-ads query <PROMO_ID> <DSA_ID> --gaql …Google Ads、GA4、GTM、Search Consoleなどを、接続済みaccountの範囲でqueryします。
- 03
組む
変更案をChange Planへ積む
cotomu change-plan add-op <PROMO_ID> <PLAN_ID> …対象resource、operation、理由をplanへまとめ、反映前にpreviewできる形へします。
- 04
追う
responseと自分の監査履歴を追う
cotomu audit list認証主体自身がどのpromotionへ何を実行したかを確認できます。mutating requestはidempotency keyで再送を扱います。
対応サービス
接続先を、名前で確認する。
ロゴを信頼の飾りにせず、何のデータを扱うかを識別するために使います。
広告媒体
広告データの収集・query・運用支援
Google Ads
Meta Ads
TikTok Ads
LINE Ads
Yahoo!広告
Amazon Ads
計測・分析
認可済みproperty・site・channelのquery
Google Analytics 4
Google Tag Manager
Search Console
蓄積・出力
要件に応じたdata warehouse・可視化先
BigQuery
Looker Studio
Google Sheets
各社のロゴは対応先を識別する目的で掲載しています。提携・推奨を示すものではありません。利用できる媒体、機能、更新頻度は契約・接続状態・API提供条件により異なります。
Change Plan
変更は、draftにまとめて確認する。
Google AdsやMeta Adsへの変更は、対象と理由をplanへまとめてpreviewできます。担当者確認は推奨運用としてapply前に組み込みます。
説明用デモ
無関係な検索語句を除外候補へ追加する場合
cotomu change-plan preview <PROMO_ID> <PLAN_ID>- 01
DRAFT
変更理由とoperationを記録
対象promotion、data source account、resource、変更内容をplanへ積みます。
- 02
PREVIEW
対応operationを事前確認
preview responseでoperationごとのvalidation結果を確認します。検証内容は媒体・operationにより異なり、未対応項目はskippedになります。
- 03
OPERATOR REVIEW*
担当者が対象と理由を読む
これは推奨する運用上の停止点です。現行APIが必須承認状態として強制するものではありません。
- 04
APPLY / AUDIT
明示操作で反映し、履歴を追う
apply後はresponseとaudit logで結果を確認します。mutating requestはidempotency keyを扱います。
* 担当者確認は、API key利用時に現行APIが強制する必須system statusではありません。raw mutate endpointへの直接実行はchange_plan_requiredで拒否されます。writeはChange Planへ積み、previewとapplyで実行し、外部承認手順と操作対象を要件に合わせて設計します。
FAQ
相談前に、
境界を確認する。
対応可否を広く約束せず、入口、権限、書き込み、保存先の前提を先に示します。
CLI・MCP・REST APIは何が違いますか？
同じcotomu Public APIへ接続します。CLIはscript・CI・自動化、MCPは人がAI toolから対話的に使う場面、REST APIは社内toolや独自workflowへの組み込みに向きます。提供commandとtoolには一部差があります。
AIが広告設定を自動で変更しますか？
無条件には変更しません。広告系のwriteはChange Planで対象と理由を記録し、previewと担当者確認を組み込む運用を推奨します。raw mutate endpointへの直接実行はchange_plan_requiredで拒否されます。担当者確認はAPI key利用時の必須system statusではないため、権限と外部承認手順を運用側で設計し、Change Planを明示的にapplyします。
読み取り専用で使えますか？
はい。API keyはREADONLYとREAD_WRITEを分けられます。分析専用agentにはREADONLYを使い、promotion whitelistと接続accountのscopeでアクセス範囲を限定できます。
どの広告・計測サービスに対応していますか？
Google Ads、Meta Ads、GA4、GTM、Search Console、YouTube Analytics、PageSpeedなどのPublic API経路があります。TikTok、LINE、Yahoo!、Amazonを含む媒体連携も扱いますが、利用できる機能は契約・接続状態・各APIの提供条件により異なります。
BigQueryやBIへ出力できますか？
BigQueryへの蓄積やLooker Studio、Google Sheetsなどへの出力構成を扱えます。保存先、更新頻度、項目定義、権限は要件によって変わるため、現在のdata flowを確認して設計します。
広告代理店と事業会社のどちらが対象ですか？
どちらも対象です。代理店ではclientごとのpromotionと権限分離、事業会社では社内toolやAI agentからの利用など、運用責任とaccount構成に合わせて設計します。
操作の安全性はどのように確認できますか？
promotion whitelist、READONLY / READ_WRITE、OAuth scope、Change Plan、preview、audit logを組み合わせます。cloud構成や契約上のdata handlingは一律に断定せず、相談時に利用条件と必要資料を確認します。
お問い合わせ
まずはお気軽にご相談ください
サービスに関するご質問・ご相談など、お気軽にお問い合わせください。