会話で広告運用。SupermetricsがClaude連携で引いた承認の線

広告の運用を会話で進める、という話で最初に引っかかるのは、たいてい2つのうちどちらかです。出てきた数字が合っているのか。そして、合っていない数字のまま予算が動いてしまわないのか。

マーケティングデータ基盤のSupermetricsが公開した事例は、この2つに別々の手当てをしています。数字の精度は、AIに考えさせる前の段階、つまりデータを渡す側で詰める。事故の防止は、AIが出した案を実行する手前で止める。Anthropicが公開した同社の導入事例と、同社の公式製品ページに書かれている範囲を読むと、この分け方がはっきり出ています。

この記事では、同社が何を作り、どこに人の判断を残し、公表されている結果が何なのかを順に整理します。扱うのはその2つの一次情報に記載がある内容だけです。売上や契約数への影響は公表されていないため、本記事でも扱いません。

ダッシュボードが答えられない質問から始まっている

出発点は、ツールの不足ではなく、ダッシュボードという形式そのものの性質です。

同社の創業者で共同CEOのMikael Thunebergさんは、事例の中で「Dashboards are fixed: they answer the questions their designer anticipated, and nothing else」と述べています。ダッシュボードは固定されていて、設計者が想定した質問にだけ答える。想定の外側に出た瞬間、答えられるものが何もない、という指摘です。

これは運用の現場では見覚えのある状況です。レポートの枠は決まっていて、知りたいことがその枠の外にあるとき、作業は手でやり直すことになります。事例では、ノルウェーの代理店Layerが、5つのソースからデータを集めてクライアント向けのレポート1本を作るのに10時間の稼働を使っていたと紹介されています。

一方で、AIアシスタントに直接聞けばよい、とすぐに進めなかった理由も書かれています。クライアントへ出す数字が間違っていれば、相手の予算が無駄に動きます。代理店の仕事では、その危険があるかぎり採用できない、という整理です。精度の問題を先に片付けないと、会話の便利さは使えないものになります。

何を作ったのか。正規化したデータをMCPで渡す

同社が置いた手当ては、AIの側ではなくデータの側にあります。

公式製品ページによれば、Supermetrics MCPは、Google Ads、Meta、GA4をはじめとする各媒体の生きたデータへ、AIツールから直接アクセスできるようにするものです。接続と認証、データの整形を裏側で引き受けます。重要なのはその整形のほうで、導入事例は、数百のマーケティングソースから正規化されたデータを扱い、1つ1つの数値に出典と取得時刻が付いていると説明しています。

精度についての記述も、製品ページ側にあります。MCPが提示するのは成功した実際のAPI呼び出しから得られたデータだけで、値を推定したり作ったりはしない、という書き方です。認証はユーザー単位で、セッションごとに分離されるため、権限のあるアカウントとデータソースしか見えません。

Thunebergさんの表現では、こうなります。「Combine our understanding of marketing with our clean data, and Claude went from being a passable marketing intern to a full-blown marketing data assistant」。マーケティングの理解と整ったデータを組み合わせた結果、まあまあのインターンから、本格的なデータ担当へ変わった、という言い方です。

同社のMCPサーバーは主要なAIアシスタントへ展開されていますが、投資をいちばん厚くしたのはClaudeだと述べられています。理由として挙げられているのは「the experience matched how marketers work」、つまり体験がマーケターの働き方に合っていたこと。具体例としては、Claude Coworkが会話の中に図を直接表示するため、生の数字を読み解く手間が省けることが挙げられています。数字の羅列を受け取って自分でグラフにし直す工程が、会話の中で済むという話です。

読み取りで止めず、書き込みまで広げた

事例のもう半分は、データを見るだけで終わらせていない点です。

同社は、Google Ads、Meta、Microsoft Advertising、TikTok、LinkedIn、Snapchatに対して書き込みの操作を実装しています。会話の中でキャンペーンを作る、変更する、という操作がここに含まれます。読み取りと書き込みでは、間違ったときの結果がまったく違います。読み取りの誤りは誤解を生みますが、書き込みの誤りは配信と課金に直結します。

そこで置かれているのが、初めから組み込まれた安全側の既定です。事例に引かれている説明は「Campaigns get created in a paused state, not live, so nothing goes to market without a human actively choosing」。キャンペーンは一時停止の状態で作られ、公開状態では作られない。だから、人が能動的に選ばないかぎり市場には出ない、という線引きです。

さらに、承認の水準はアカウントごとに設定でき、提案された変更を関係者が見て判断するための専用画面が用意されているとされています。設計の考え方として、Thunebergさんは「The system should never take an action that could surprise the user」と述べています。利用者を驚かせるような動作をシステムが取ることはあってはならない、という言い方です。

ここで注目したいのは、安全側の仕組みが機能の追加ではなく既定値の置き方として実装されていることです。警告を出す、確認を求める、といった形ではなく、作られるものが最初から配信されない状態になっています。運用者が確認を飛ばしても、飛ばしただけでは何も起きません。会話を入口にするときの設計としては、この順番のほうが壊れにくいと言えます。

公表されている結果は3つ

数字として公表されているのは3つだけです。

1つ目は、Claude向けの連携を2月に公開して以降、アクティブユーザーが前月比で平均250%成長したこと。2つ目は、代理店Layerがクライアント向けのレポート作成を同じ連携へ通したところ、10時間かかっていたものが20分になったこと。3つ目は、その代理店が数週間かけて実データで検証した範囲で、ハルシネーションと誤ったデータが見つからなかったことです。

20分という数字には、読み方の鍵になる内訳が添えられています。そのうち17分は、仕上げたデータをクライアントのGoogle Sheetへ移す作業だというのです。つまり、集計そのものに使われている時間は数分で、残りは受け渡しの形式を整える手間ということになります。短縮されたのは分析ではなく、分析の前後にあった作業だと読むのが正確でしょう。

Layerの担当者であるMorten Klevenさんの言葉として引かれているのは「When using AI for client reporting, trust is everything. I have not found a single hallucination or incorrect data point」です。検証の件数や対象の範囲は公表されていないため、この0件がどれだけの量に対する結果なのかは分かりません。

社内で先に使ってから、顧客へ出している

もう1つ特徴的なのは、同社が自分たちの業務で先にClaudeを使っている点です。

CTOのDuleepa Wijayawardhanaさんの説明では、エンジニアリングは独自のモノリスを対象にClaudeを使っており、「a small change in one part might have unexpected effects elsewhere」という性質のコードベースで、想定外の依存関係を障害対応の最中に見つける用途が挙げられています。全社では、Coworkがレポートや調査、業務の流れに使われています。

使っている側	使っているもの	公表されている用途	公表されている結果
社内のエンジニアリング	Claude Code（既定のツール）	独自のモノリスの調査、障害対応中の依存関係の洗い出し	かなりの精度で使えるようになったという説明まで
社内の全部門	Cowork	レポート、調査、業務の流れ	記載がありません
顧客の代理店（Layer・25人規模）	Claude 向けの連携	クライアント向けレポート、キャンペーンの調整	10時間→20分、誤り0件
少人数・個人のマーケター	Claude 向けの連携	これまで手が届かなかったデータ担当の役割	記載がありません

表の各行は、上記の導入事例と公式製品ページの記載によります（確認日 2026-10-06）。公表されていない欄は、推測で埋めずに「記載がありません」と置いています。

この順番について、同じCTOの言葉が理由を説明しています。「If we’re asking marketers to trust AI with their decisions, we have to prove we trust it with ours first」。マーケターに判断を委ねてもらうなら、まず自分たちが自分の判断で委ねていることを示す必要がある、という筋立てです。社内利用を先に置く理由を、宣伝ではなく順序の問題として述べている点は、提供側の説明としては珍しい形です。社内の部門ごとに使い方を分ける話は、HubSpotが3つのチームで使い分けた事例のほうが細かいので、あわせて読むと比較しやすくなります。

日本の実務者が持ち帰れること

一般化できるのは、効果ではなく設計の順番です。次の3点になります。

1つ目は、AIに渡す前の整形で精度を作ることです。この事例で精度を支えているのは、モデルの選択ではなく、正規化と出典・時刻の付与、そして推定値を返さないという方針です。社内にデータがばらばらに置かれている状態で会話の入口だけを足しても、返ってくる答えの確かさは変わりません。手を付ける順番としては、つなぐ前に整えるほうが先になります。

2つ目は、書き込みの既定値を安全側に倒すことです。一時停止で作る、という形は、特別な技術ではありません。自社でAIから何かを操作させる仕組みを作るなら、作られたものが初期状態で動かないようにしておけるかどうかを、最初に確認する価値があります。確認画面を増やすより、既定値を変えるほうが確実です。

3つ目は、短縮された時間の内訳を見ることです。10時間が20分になった事例でも、残った20分のうち17分は転記でした。自社で同じ試算をするときは、どの工程が短くなったのかまで分けて見ないと、次に手を付ける場所を間違えます。縮んだのが分析なのか、受け渡しなのかで、次の改善は変わります。

そのまま持ち込めない部分もあります。この連携はSupermetricsが対応している媒体の範囲で動くもので、国内特有の媒体や、社内の独自システムに同じ形で当てはまるとは限りません。製品ページでは、MCPの利用はData APIを含むプランに含まれるとされているため、前提となる契約も確かめる必要があります。MCPを通じて広告プラットフォーム側が公式に接続口を出し始めている流れについては、Snapの広告向けMCPサーバーの記事でも扱っています。

なお、会話で運用できることが成果を保証するわけではありません。公表されている数値は、使った側と提供した側が示したものです。同じ仕組みを入れれば同じ結果になる、という読み方はできません。

公表されていないこと

確認できなかった項目を残しておきます。アクティブユーザーの実数は公表されておらず、250%という成長率の基準になる人数は分かりません。検証で誤りが0件だった範囲についても、対象の件数や期間の詳細は示されていません。

売上、契約数、解約率への影響は公表されていません。書き込み操作を実際にどれだけの顧客が使っているか、承認画面で却下された提案の比率も記載がありません。また、読み取りと書き込みで必要な承認を分けて設定できるかどうかは、公表された説明の範囲では判断できませんでした。

埋めずに残しているのは、この種の事例で推測を混ぜると、設計の参考という用途まで壊れるからです。全体を1行でまとめると、精度はデータを渡す前の整形で作り、事故は作られたものを止まった状態にしておくことで防ぐ、という2段構えの事例です。