広告運用の工程をAIで束ねたAdvolve｜公表値と前提の読み方

広告運用の自動化は、工程ごとに見ればもう珍しくありません。入札は配信プラットフォーム側の自動入札に、クリエイティブの組み合わせは配信時の最適化に、数字の集計はダッシュボードに寄っています。それでも、工程と工程のあいだは人が運んでいます。素材を作る人、設定を入れる人、予算を動かす人、結果を見る人が別にいて、受け渡しのたびに確認が入ります。日々の運用で時間を食うのは、個々の作業よりもこの受け渡しのほうです。

AnthropicがClaudeの導入事例として公開しているAdvolveのページは、その受け渡しごと機械の側へ寄せた構成を公表したものとして読めます。同社のプラットフォームではClaudeが「中央のオーケストレーター」として置かれ、素材の生成から配信の設定、予算の配分までを束ねていると説明されています。この記事では、その配置が何を指しているのかを公表されている範囲で整理し、あわせて公表値の読み方を押さえます。使う一次情報は、Anthropicの導入事例ページ、Anthropic公式のエージェント設計の解説、Google広告の公式ヘルプの3つで、確認日は2026年11月13日です。

先に断っておきます。導入事例ページを出しているのは、道具を提供している側です。ここから読み取れるのは、ある事業者がこの構成で運用していると公表している事実までで、同じ数値が別の会社で再現するとは書かれていません。こちらも書きません。

どんな会社が、何を作ったのか

導入事例ページに付いている区分は、業種がProfessional services、規模がSmall、地域がNorth America、使っている製品がClaude Platformです。本文では、デジタルでの顧客獲得（digital customer acquisition）の工程を自動化するB2Bの事業者として紹介されています。共同創業者のJoão Sobreira氏の発言として、自社はAIネイティブであり、思いついた機能のすべてを任せられる信頼できるAIを前提にシステム全体を組んだ、という説明が載っています。

顧客として名前が挙がっているのは、ブラジルの大手であるiFoodとCognaです。地域の区分と、引用されている顧客の所在が一致しないため、どこを拠点にしているのかはこのページだけでは確定できません。確認できるのは、ブラジルの大企業を顧客に持つ小規模な事業者という範囲までです。規模の区分がSmallであることは、この事例を読むうえで効いてきます。数百万件の広告を同時に扱うという話を、少人数の体制で成り立たせている前提になるからです。

プラットフォームが受け持っている処理として、ページには次が並んでいます。素材の生成と評価（背景、アート、フォント、コピー）、複数の広告プラットフォームにまたがるキャンペーンの設定と配信、リアルタイムの予算配分と最適化、そして数百万件の広告の同時運用です。加えて、リアルタイムのデータ検証と、工程の整合性のチェックが機能として挙げられています。

この並びで目を引くのは最後の1つです。生成・設定・配分という手を動かす工程と、検証という手を止める工程が、同じ場所に並んでいます。自動化を作業の置き換えとして考えると、前者だけが列挙されます。後者が同じ重さで入っているかどうかは、設計の性格を見分ける手がかりになります。

「オーケストレーター」はどういう配置なのか

Anthropicは公式のエンジニアリング解説で、この領域の言葉を2つに分けています。workflowsは「LLMとツールが、あらかじめ決められたコードの経路を通って組み立てられる仕組み」。agentsは「LLMが自分の進め方と道具の使い方を動的に決め、どう達成するかの制御を持ち続ける仕組み」です。Advolveのページが使っている「中央のオーケストレーター」という言い方は、同じ解説にあるorchestrator-workersという型に重なります。こちらは「中央のLLMがタスクを動的に分解し、workerのLLMへ委譲し、その結果を統合する」ものとして定義されています。

もう1つ、evaluator-optimizerという型も定義されています。「一方のLLMの呼び出しが応答を生成し、もう一方が評価とフィードバックをループで返す」構成です。Advolveの素材の「生成と評価」という書き方は、この形に照らすと読みやすくなります。ただし、事例ページに型の名前は書かれていません。同社がこの型を名指しで採用したという記載はないので、ここでは型に照らして読む、という扱いにとどめます。

Sobreira氏の発言には、選定の経緯も残っています。自社のLLMの評価テストで、Claudeが一貫して他の選択肢を上回ったという内容です。注目したいのは順位ではありません。評価の仕組みを自分たちで持っていたという点です。生成物の出来を機械で比べられる状態になっていなければ、どのモデルが自社の作業に向いているかは決められません。モデルを選ぶ話より先に、評価を作る話が来ています。

同じ解説は、注意も書いています。1つ目は、エージェント的な仕組みはしばしば遅延と費用を性能と引き換えにすること。2つ目は、サンドボックス環境での広範なテストと、適切なガードレールが要ること。3つ目は、単純なプロンプトから始め、単純な方法で足りないときにだけ複雑さを足すという原則です。公表された成果の側だけを読むと、この3つは視界から消えます。工程を束ねた構成は、速くなる代わりに遅く高くなる部分を抱えているという前提で見るほうが安全です。

公表されている数値と、公表されていない前提

事例ページに出ている数値は5つです。換算せず、原文の表記のまま並べます。

公表されている内容	原文の表記
運用作業の時間の削減	90% reduction in operational work time
顧客の広告費用対効果の向上	15% increase in customer return on ad spend
2025年の売上の見込み	Projected 10x revenue for 2025
扱う広告予算の規模	managing ad budgets exceeding $100M by year-end 2025
到達までの期間	human-level ROAS when managing multi-million dollar budgets in under 30 days

読み方の注意が2つあります。1つは、10倍は見込みであって実績ではないことです。もう1つは、$100Mという広告予算の規模が、同社の売上ではなく預かって運用する側の金額だということです。扱う予算の大きさと、成果の大きさは別の指標です。

そして、この5つを自社に当てはめるために必要な前提は、ほとんど公表されていません。

確かめたかった項目	公表の状況	どう扱うか
90%は何と比べた削減か	記載がありません	自社の工数見積もりに転用しない
対象の広告プラットフォーム	記載がありません	特定の媒体で成立する話として読まない
15%を測った期間と対象	記載がありません	月あたりの改善幅に割り戻さない
料金と導入にかかる費用	記載がありません	費用対効果は自社の見積もりで確かめる
人が介在している工程	記載がありません	全自動と読み替えない
検証に落ちた処理の割合	記載がありません	誤りの起きにくさを推し量らない

書かれていない項目が多いのは、この種のページでは普通です。問題になるのは、空いた欄を自分の期待で埋めてしまうときです。とくに90%という削減幅は、何の作業をどの期間と比べたのかが分からないかぎり、自社の工数見積もりには使えません。社内へ共有するときは、公表されている内容と自分たちの推測を、行を分けて書いてください。

ROASの改善幅は、計測の前提とセットでしか読めない

15%というROASの向上を読むには、ROASがどう決まるのかを押さえておく必要があります。Google広告の公式ヘルプは、目標ROASを、検索ごとに見込まれるコンバージョンの価値を予測し、目標に等しい平均の広告費用対効果を保ちながらコンバージョンの価値を最大化しようとする入札戦略として説明しています。予測の材料になるのは、広告主が設定したコンバージョンの価値です。ヘルプは、使い始める前に追跡しているコンバージョンに価値を設定することを求めています。

件数の条件も書かれています。検索とショッピングは過去30日で15件以上のコンバージョン、ディスプレイは有効な価値を持つコンバージョンが同じく15件以上、アプリのキャンペーンは毎日10件、または30日で300件です。さらに、目標を高くしすぎると広告が得られるトラフィックの量が制限される可能性があること、目標に入札の上限を設けるのは推奨されないこと、目標を変えたら1〜2回のコンバージョンサイクルを見ることが書かれています。

ここから分かるのは、ROASは計測の設計で動く指標だということです。コンバージョンの価値の定義を変えれば、同じ配信でも数値は変わります。だから「ROASが15%上がった」という公表値は、前後で価値の定義と計測が同じだった場合にだけ、比較として成立します。自社で検証するときも同じです。自動化の導入と計測の見直しを同じ月に行うと、どちらが効いたのか分からなくなります。

日本の実務者が参考にできる3点

第一に、自動化の設計を「工程の置き換え」ではなく「検証をどこに置くか」から考えることです。Advolveのページで、生成や配信と同じ列にデータ検証と整合性のチェックが並んでいるのは、束ねた工程が止まる場所を内側に持っているという意味に読めます。人が1件ずつ確認していた工程を機械へ渡すと、確認そのものが消えます。消えた確認をどこに作り直すのかを、渡す前に決めてください。

第二に、評価を先に作る順序です。同社はLLMの評価テストを持っていたからモデルを選べました。自社で同じことをするなら、良い広告文や良い画像の合否を人がどう判断しているのかを、まず言葉にする作業から始まります。これは道具を入れる前にできる仕事です。公表値と確かめられる範囲を切り分ける考え方は、マーケ運用の行列をAIが処理｜Gradialの公表値3社分を読むでも同じ形で出てきます。

第三に、公表値は基準とセットで扱うことです。配信プラットフォームの側でも自動化の度合いを選べるようになり、どこを機械に任せるかは設定の問題になりつつあります（TikTokのSmart+が手動運用と1本化。自動化の度合いを選ぶ形へ）。任せられる幅が広がるほど、どこまでを機械がやったのかを記録していないと、効果の原因を後から切り分けられません。なお、ここに挙げた3点はいずれも効果を約束するものではありません。効き方は、扱う商材、予算の規模、計測の作り、体制によって変わります。

まとめ

Advolveは、デジタルでの顧客獲得の工程を自動化するB2Bの事業者として、Claudeを中央のオーケストレーターに置いた構成を公表しています。素材の生成と評価、複数のプラットフォームにまたがるキャンペーンの設定と配信、リアルタイムの予算配分、数百万件の広告の同時運用、そしてリアルタイムのデータ検証が、同じ列に並んでいます。顧客にはブラジルのiFoodとCognaが挙がっています。

公表されている数値は、運用作業の時間が90%減ったこと、顧客のROASが15%上がったこと、2025年の売上を10倍と見込んでいること、年末までに$100Mを超える広告予算を扱う見込みであること、そして数百万ドル規模の予算で30日未満にhuman-levelのROASへ達したことです。比較の基準、対象のプラットフォーム、測った期間、費用はいずれも公表されていません。

参考にできるのは数値ではなく、配置のほうです。工程を束ねるなら、同時に検証を内側へ入れる。モデルを選ぶ前に評価を作る。そして公表値は、計測の前提とセットでなければ比べられない。この3つは、扱う広告予算の大小に関係なく当てはまります。