WPP が Google Cloud で実現した「壊れない AI マーケティング基盤」

データとプラットフォームエンジニアリングで、広告運用の常識を変えた舞台裏 ―

世界中に数百のエージェンシーを抱える広告大手 WPP は、人間の勘や経験だけに頼る従来のマーケティング手法を根本から見直し、AI を中核に据えたエージェンティック・マーケティング・システム「WPP Open」を構築しました。しかし、AI に賢い判断をさせるには、まずデータの断片化という巨大な壁を壊さなければなりませんでした。本記事では、WPP が Google Cloud と共に築いた統一データ基盤と、標準化されたプラットフォームエンジニアリングの全貌を解説します。

データのサイロ化が AI 活用の足かせに

WPP の最大の課題は、マーケティングデータがグループ内の無数のエージェンシーやパートナー企業に散らばり、統一された形で AI モデルに渡せないことでした。データの所在や形式がバラバラでは、強力な生成 AI も宝の持ち腐れ。しかも、セキュリティやガバナンスを保ったままデータを集約し、加工し、AI へ供給するパイプラインを整えるには、単なるツール導入以上の「基盤作り」が求められました。

WPP はこの問題を解決するために、Google Cloud とのパートナーシップのもと、「一元化されたデータの背骨」 と 「標準化されたプラットフォーム開発手法」 を同時に確立。その結果、ターゲット広告キャンペーンを数か月から数日で展開できるスピードを手に入れました。

1. サービスベースのプロジェクト構造でデータを集約

WPP が最初に取り組んだのは、データ基盤そのもののアーキテクチャ整理です。彼らが採用したのは、「データプロジェクト」と「処理プロジェクト」の分離。Google Cloud Storage（GCS）バケットと BigQuery を専用の共有データプロジェクトに集約し、計算や処理ワークロードは別の処理プロジェクトで実行するサービスベースの設計にしました。

• 単一の信頼できる情報源：すべてのデータ利用者が同じ GCS / BigQuery を参照し、重複や不整合を排除。

• きめ細かなアクセス制御：GCS バケットや BigQuery データセットのレベルで IAM を直接適用し、各チームは自分たちに権限のあるデータだけを見られる。

生データはパートナーごとに専用の GCS バケットへ着地し、その後 Apache Spark のマネージドサービス（サーバーレス Spark）と Kubeflow で統率されたパイプラインが起動。Scala で書かれたジョブがデータをクレンジング・正規化し、Standardized Cohort Definitions（SCDs） と呼ばれる標準化されたコホートデータへ変換します。インフラ管理の手間がないサーバーレス構成のため、WPP のデータエンジニアはクラスタ運用ではなく、データ変換ロジックそのものに集中できました。

2. データを「SCD」で標準化し、トレーサビリティを確保

WPP の処理ゾーンに入った生データは、5 つのキー（年齢・性別・地域・プロダクト・興味関心） に基づく SCD に変換されます。これらのキーは固定的ではなく、マーケティング上の概念の進化に合わせて継続的に正規化される“流動的な定義”です。この統一構造のおかげで、共通の識別子を使わずにグローバル規模でデータを結合・集計でき、機密性の高い個人情報が露出するリスクもありません。

もう一つの大きな特徴は、フルトレーサビリティ（完全な来歴追跡） です。データ変換の中核エンジンは型安全な Scala で構築されており、加工後のすべてのデータポイントが元のソースまで遡れる仕組みになっています。これはエンタープライズ AI アプリケーションにとって極めて重要な要件であり、データサイエンティストや監査担当者がモデルへの入力情報を正確に把握できることを意味します。将来的には Google Cloud の Data Catalog を活用した全社的なデータガバナンスへの移行も視野に入っています。

3. CI/CD テンプレートで開発からデプロイまでを標準化

データを処理するパイプラインが整っても、アプリケーションを安全かつ高速に提供できるプラットフォームがなければ意味がありません。WPP のプラットフォームエンジニアリングチームは、一元化された GitLab CI/CD テンプレート を開発し、すべての開発チームの負荷を軽減しながら企業セキュリティ基準を強制することに成功しました。

用意されたテンプレート群は以下の通りです。

• Cloud Run 用ユニバーサルテンプレート：フルスタック Web アプリやバッチ処理、スケジュールパイプラインに対応

• Deploy-only テンプレート：マルチステージワークフロー向け

• Cloud Run functions 用テンプレート：イベント駆動マイクロサービスを展開

「ビルド一度きり、デプロイ多数」のゼロリビルドプロモーション

本番環境でのコンテナイメージ再ビルドは、設定ドリフトや予期せぬ不具合の温床です。WPP は “build once, deploy many” の原則を徹底し、Artifact Registry で管理したイメージを開発環境でビルド・テストした後、まったく同じイメージを本番へ昇格させます。これにより、デプロイ段階間の完全な一致性が保証され、本番環境での想定外の挙動を排除。さらに、CI/CD テンプレートはプログレッシブなトラフィック移行をサポートしており、新リビジョンに少量のトラフィックを流してから全ロールアウトする安全なリリースが可能です。

4. セキュリティとネットワークもテンプレートで自動化

WPP のプラットフォームではセキュリティが基盤そのものを支える要素です。CI/CD パイプラインの プリプッシュフェーズに Wiz のセキュリティスキャンを統合 し、コードがマージされる前に脆弱性を検出。また、社内アプリケーションへのアクセスには Google Cloud の Identity-Aware Proxy（IAP）を用いてゼロトラストアクセスを徹底しています。

さらに、ネットワーク設定にも自動化の仕掛けが。VPC コネクタの競合を自動検出して解決するテンプレートを導入し、レガシーな VPC コネクタと新しい Direct VPC アクセスが衝突してデプロイが失敗する事態を防止。この自動ネットワーキングがリリースサイクルの高速化に貢献しています。

5. オペレーショナルな可観測性と圧倒的なビジネス成果

強靭なプラットフォームには深い可観測性が欠かせません。WPP のエンジニアリングチームはデプロイ頻度だけに頼らず、以下のような厳密な運用指標を監視しています。

• リクエストレイテンシ（p50, p95, p99）

• 4xx / 5xx エラーレート

• コンテナ起動時間（コールドスタートの緩和）

• CPU・メモリ使用率

こうしたきめ細かな監視により、データパイプラインもサーバーレスインフラも常に高い可用性を保てるようになりました。

そして、これらのデータ基盤とプラットフォームエンジニアリングの積み重ねが、目に見えるビジネスインパクトを生み出しています。

• クリエイティブと戦略策定にかかる時間：4 週間 → わずか 3 時間

• 生産効率：70% 向上

• コンテンツ制作量：33 倍に増加

• キャンペーン ROI：2.8 倍に向上

まとめ：AI マーケティングの成否は「基盤」で決まる

WPP の事例が示すのは、AI マーケティングで成果を出すには、派手なモデルやアルゴリズムだけでは不十分だということです。断片化したデータを安全に一つにまとめ、変換ロジックを標準化し、開発からデプロイまでのプロセスをテンプレート化し、不変のイメージで本番に昇格させる――こうした泥臭いプラットフォームエンジニアリングとデータエンジニアリングの積み重ねこそが、AI の真価を引き出します。

WPP と Google Cloud の協業は、テクノロジーの力で「人間の勘」から「データに基づく予測的確実性」へとマーケティングのゲームを変えた好例と言えるでしょう。

※本記事は Google Cloud 公式ブログ「How WPP operationalizes platform and data engineering for AI marketing」（2026年8月11日公開）を基に、日本語で解説したものです。