AI活用の話は、たいてい「どのモデルを使うか」から始まります。ところが、数百の代理店を抱えるWPPの取り組みをGoogle Cloudが公開した記事では、モデルの選定はほとんど主題になっていません。中心にあるのは、散らばっていたマーケティングデータをどうそろえたかという工程です。
記事は2026年8月11日付で、Google Cloudの公式ブログに掲載されています。そこに書かれている出発点が、この事例でいちばん参考になる部分です。モデルへのアクセスは「方程式の一部でしかなかった」と明記され、本当の壁は、モデルを作っていたマーケティングデータが数百のグローバル代理店に分散していたことだとされています。その状態では、AIツールを効率的かつ安全に展開することがほぼ不可能だった、という書き方です。
先に結論を書きます。WPPがやったのは、データをそろえる層と、それを動かし続ける層の二層の土台を作ることでした。そのうえで公表されている値が、戦略とクリエイティブに要した時間の4週間から3時間への短縮、制作効率の70%向上、コンテンツ量の33倍、キャンペーンROIの2.8倍です。金額や件数といった絶対値は公表されていません。この記事では、公表された範囲だけを扱い、確認できなかった項目は確認できなかったものとして残します。
モデルが使えることは、もう差にならない
WPP Openは、同社のエージェント型マーケティングシステムと説明されています。市場の変化に対してAIによる視点を与え、ブランドが確信を持って投資し、市場の速度で動けるようにする、という位置づけです。推測を予測に置き換える、という表現が使われています。
ここで注目したいのは、その手前に置かれた課題の書き方です。データが数百の代理店に散っていたため、AIツールの展開が効率と安全の両面で成り立たなかった、とされています。モデルが使えることは前提であって、それだけでは何も動かないという整理です。
日本の組織に引き写すと、担当部署ごとに媒体別のレポートがあり、同じ「顧客層」という言葉が部署ごとに違う定義で使われている状態に近いでしょう。この状態でモデルを入れると、出てくるのはそろっていない前提のうえでの答えになります。精度を疑う前に、入力がそろっているかを疑う順番になるわけです。
作ったのは二層の土台
土台の一層目はデータの置き場です。Cloud StorageとBigQueryを置く共有のデータプロジェクトを中央に作り、計算と処理の負荷は別のプロジェクトへ分けています。権限は、Cloud Storageのバケット単位とBigQueryのデータセット単位でIAMを当てる形です。置き場所と処理を分け、権限は細かい単位で当てるという、派手さのない設計です。
二層目は、その上でアプリケーションを動かし続けるための基盤です。Cloud RunとCloud Run Functions、Google Cloud Artifact Registry、Identity-Aware Proxy、そしてGitLabのCI/CDが並びます。記事ではこの2つをあわせて「dual foundation」と呼び、公表された成果はこの二層を作ったことによるものだと説明されています。
データを5つのキーでそろえる
一層目の中身が、この事例のいちばん具体的な部分です。パートナーから届いた生データは専用のCloud Storageバケットに入り、Managed Service for Apache Sparkのジョブが洗浄・正規化・正準化を行います。そのうえで、SCD（Standardized Cohort Definitions、標準化されたコホート定義）という形式へ変換されます。
SCDは、フレームワーク全体で参照の鍵として使われる中核の概念だと説明されています。鍵は5つで、age（年齢）、gender（性別）、geo（地域）、product（商品）、interest（関心）です。代理店ごとに違っていた持ち方を、この5つに寄せたという理解になります。
処理の中核は、型安全なScalaで独自に組まれています。目的は、可視性とコンプライアンスを担保することと説明されており、データの変換の仕方を厳しく制御したうえで、整備済みデータセットに入っているすべてのデータ点を出どころまで遡れる形を保証するとされています。AIの出力について社内で説明を求められたとき、元のデータまで戻れるかどうかは、この設計で決まります。
動かし続ける側に、同じだけ手が入っている
二層目については、運用の作り方が具体的に書かれています。プラットフォームエンジニアリングのチームが、再利用できる中央管理のGitLab CI/CDテンプレート群を用意しました。Cloud Run上のフルスタックなWebアプリケーション用、バッチ処理と定期実行のパイプライン用、多段の工程で使うデプロイ専用、そしてイベント駆動のマイクロサービス向けのCloud Run Functions用です。
デプロイの方針として挙げられているのが「build once, deploy many」です。本番環境でコンテナイメージを作り直すと、不要なリスクと構成のずれを招くとされ、開発側で作って試したイメージをそのまま本番へ上げる形にしています。クロスプロジェクトのIAMの扱いとArtifact Registryの設定を、その流れに合わせて当てています。
安全側では、Wizのセキュリティスキャンをコードがマージされる前の段階、つまりCI/CDのpre-pushの位置に組み込み、Identity-Aware Proxyで社内アプリケーションにゼロトラストのアクセス制御をかけています。監視では、リクエストの遅延をp50・p95・p99で追い、4xxと5xxのエラー率、コールドスタートを抑えるためのコンテナ起動時間、CPUとメモリの使用率を見ているとされています。
AI活用の記事に出てきにくい領域ですが、ここが止まれば前段の成果はそのまま止まります。公表資料がこの部分に分量を割いていること自体が、この事例の性格を示しています。
公表されている結果
数値は4つです。二層の土台を作ったことで、クリエイティブと戦略に要していた時間が4週間から3時間になり、制作効率が70%向上し、コンテンツ量が33倍になり、キャンペーンのROIが2.8倍になったと書かれています。
出どころの異なる値が混ざらないよう、どの数値がどの文書に載っているかを分けておきます。
| 公表されている内容 | 載っている文書 | 確認日 |
|---|---|---|
| 4週間から3時間への短縮／制作効率70%向上／コンテンツ量33倍／キャンペーンROI 2.8倍 | Google Cloud 公式ブログ（2026年8月11日） | 2026-10-22 |
| $400 million の支出コミットメント／今年の£300 million のAI投資 | WPP 公式ニュース（2025年10月14日） | 2026-10-22 |
| 最大70%の効率向上と2.5xのアセット活用の加速／ターゲティング精度98%／運用効率80%向上 | WPP 公式ニュース（2025年10月14日） | 2026-10-22 |
| 単一の仮説から数百から数千のクリエイティブ派生を数時間で作る | Google Cloud「101 real-world generative AI use cases」 | 2026-10-22 |
Google Cloudが公開している生成AIの活用事例集では、WPPは別の文脈で登場します。Veo 3とImagen 4のようなモデルによって、メディア制作が手作業から計算の工程へ移りつつあるという説明のなかで、WPPとAuthentic Brands Groupが、単一の仮説を数百から数千のパーソナライズされた映像的なクリエイティブの派生へ、数時間で変えている例として挙げられています。
規模として公表されているもの
土台の話とは別に、WPP側の発表にも数値があります。2025年10月14日付の公式ニュースで、Googleとの提携を5年規模で拡張すると公表されており、WPPからGoogleの技術に対する$400 million の支出コミットメントが含まれるとされています。これはWPPのAI投資の一部で、その投資には今年の£300 million が含まれると書かれています。人材面では、2030年までに1,000人を超える若手のクリエイティブテクノロジストを育てるとされています。
同じ発表には、クライアント側の結果として、最大70%の効率向上と2.5xのアセット活用の加速、AIエージェントによるオーディエンスのターゲティング精度98%と運用効率の80%向上、21体の仮想ペルソナのエージェントを使い10,000回を超えるシミュレーションでクリエイティブの検証を行った例が挙がっています。
これらはGoogle Cloudのブログの4つの値とは別の文書の数値です。同じ70%という数字が両方に出てきますが、前者は制作効率の向上、後者はクライアントの事例における効率向上として書かれています。並べて足したり、同じ指標として扱ったりはできません。
公表されていないこと
確認できなかった項目を、埋めずに残します。
33倍や2.8倍といった倍率について、母数となる案件数、対象の期間、対象のクライアントは示されていません。金額としての効果も公表されていません。4週間から3時間への短縮が、どの種類の案件で測られたものかも記載がありません。
SCDについては5つのキーが示されていますが、キーごとの値の持ち方やスキーマの詳細は公開されていません。体制についても、プラットフォームエンジニアリングのチームが用意したという記述までで、人数や期間は分かりませんでした。日本法人や日本市場での適用については、今回確認した3つの文書のいずれにも記載がありませんでした。
日本の実務者が参考にできる点
移植しやすいのは、順序のほうです。
第一に、モデルを選ぶ前に鍵を決めることです。WPPは5つのキーで全社のデータを寄せました。自社であれば、媒体別のレポートと顧客データベースと問い合わせ履歴を、どの単位で突き合わせるのかにあたります。この単位が決まっていない状態でAIを入れても、出てくる答えの前提がそろいません。
第二に、出どころまで遡れる形にすることです。WPPは整備済みデータのすべてのデータ点を元まで追えるようにしています。AIの出力に対して社内や取引先から根拠を問われる場面を考えると、遡れない設計は後から直しにくい部分です。
第三に、本番で作り直さないことです。build once, deploy manyは、検証した状態と公開した状態を同じに保つための方針です。マーケティングの現場でも、検証環境で確認した配信設定やテンプレートを本番で手作業で組み直すと、同じずれが起きます。
第四に、何を監視するかを先に決めることです。WPPは遅延、エラー率、コンテナの起動時間、計算資源の使用率を見ています。仕組みが止まったときに気づける指標を持たないまま運用に乗せると、止まっていることに気づく手段が利用者からの連絡だけになります。
現場の側が自分でAIを作る形に振った事例としてはGE Appliancesが現場に配ったエージェントが、クリエイティブの評価をデータに寄せた例としてはKrogerとVidmobの配信前の採点が参考になります。ほかの事例は海外AI活用事例にまとめています。
なお、同じ構成を作れば同じ値が出ると書かれているわけではありません。公表されているのはWPPの環境で得られた結果であり、効果は扱うデータと運用によって変わります。
出典と注記
この記事は、Google Cloud 公式ブログ「How WPP operationalizes platform and data engineering for AI marketing」（2026年8月11日付）、WPP 公式ニュース「WPP and Google forge groundbreaking partnership to redefine marketing with AI」（2025年10月14日付）、Google Cloud「101 real-world generative AI use cases from industry leaders」を出典としています。確認日は2026年10月22日です。
原文の数値は表記のまま扱い、通貨や単位の換算はしていません。製品名と技術用語は原文の表記を優先し、必要な箇所で日本語の説明を添えています。提携と基盤の整備は進行中の取り組みであり、公表内容は今後更新される可能性があります。
この分野の実務を相談したい方へ
記事で扱っている内容は、当社が実務として支援している領域です。 自社で進めるか外部に任せるかの判断からご相談いただけます。
あわせて読みたい
現場が自分でAIを作る。GE Appliancesが800超のエージェントを配った設計 米GE AppliancesはGemini Enterpriseで800を超えるAIエージェントを製造・物流・調達に展開したと公表しました。誰が作り、何に使い、どこまでが公表された結果なのかを公式発表の範囲で整理します。
配信前にクリエイティブを採点する。KrogerとVidmobの検証 米KrogerはVidmob、MMA Globalと共同で、広告クリエイティブの採点が配信前にeコマースの獲得を予測できるかを検証しました。1,934点を使った手順と、公表された数値の範囲を整理します。
AIが6,000行書き、人が選ぶ｜PODSの走る看板の分担 米PODSと広告会社Tombrasは、走行するコンテナの看板にGeminiで作った文面を出し分けました。12日間で通した工程と、出典ごとに違う公表値を一次情報の範囲で整理します。