生成AIでマーケティングデータ分析はどこまでできるのか

B社のマーケティング部門では、Adobe Marketo Engageで獲得・育成したリード情報をGoogle BigQueryに集約し、Looker Studioでダッシュボード化していました。
データ基盤と可視化環境はすでに整っており、定型的な指標はいつでも確認できる状態でした。しかし、実際の業務では、ダッシュボードだけでは解決できない課題が残っていました。

1. ダッシュボードにない切り口の分析に時間がかかる

Looker Studioでは、あらかじめ設計された指標やレポートは確認できていました。

一方で、現場で新たな問いが生まれたときには、すぐに分析できる状態ではありませんでした。たとえば、「このスコア帯のリードは本当に申し込みにつながっているのか？」「お客様の立場ごとにコンバージョン行動は違うのか？」といった問いを立てると、手作業でSQLを書くか、分析担当者に依頼する必要がありました。

その結果、分析担当者は毎回の集計作業から抜け出せず、現場側にも分析結果を待つ時間が発生していました。

2. データ項目の意味が属人化していた

リード情報のテーブルには150を超える項目があり、製品ごとの関心度、接触回数、お客様の立場などを表す社内独自の略号が多数使われていました。それぞれの項目が何を意味するのかを正確に理解しているのは、設計に関わった一部の担当者に限られていました。

新しく入った担当者や他部署のメンバーがデータを活用しようとしても、まず「この項目は何を表しているのか」を確認する必要があり、そこで分析が止まってしまうことがありました。

3. 命名規則のばらつきにより、正しい集計が難しかった

フォーム名や項目名の付け方は、時期や製品によって統一されていませんでした。

たとえば、名前には「問い合わせ」を意味する略号が含まれているものの、実際には申し込みフォームのデータも存在していました。また、配信停止などの運用フォームの混入、仮申し込みと本申し込みの二重カウント、旧名称と新名称の併存といった問題もありました。

人間でも確認が必要なデータを、AIがそのまま正しく解釈できるのか。ここが今回の大きな検証ポイントでした。

4. AI活用を本格導入する前に、自社データで使えるかを見極めたかった

B社が知りたかったのは、単に「AIは便利か」ではありませんでした。自社の実データには、独自の命名規則、属人化した項目定義、過去から積み上がったデータのばらつきがあります。その状態で、自然言語によるデータ分析が本当に実務で使えるのか、本格導入の前に、実データで検証する必要がありました。

パワー・インタラクティブは、B社に対してPower ROI-AI naviのお試し導入を支援しました。

今回の検証では、新しいデータ基盤を作り直すのではなく、既存のBigQuery上にあるMarketoデータにAIを接続し、自然言語での分析がどこまで実務に使えるかを確認しました。

構成は次の通りです。
・BigQueryに格納されたAdobe Marketo Engageのリード情報・行動ログを利用
・CData Connect AIを介して、AIがBigQuery上のデータに接続
・Claudeに対して日本語で質問し、必要な集計・分析を実行
・MCPを通じて、AIにデータの場所や使い方、項目の意味を伝える
・Looker Studio上の正値と比較し、AIの集計結果の妥当性を検証

検証では、以下の2つのゴールを設定しました。

ゴール1：AIが出す数字は正しいのか

資料ダウンロード、問い合わせ、申し込みの件数について、AIが出す集計結果が、正値として扱っているLooker Studioの数字と一致するかを確認しました。

ゴール2：AIはダッシュボードにない示唆を出せるのか

既存のダッシュボードにはない切り口で分析し、次に取るべき打ち手まで提示できるかを検証しました。

1. 定義をそろえたデータを使えば、AIの集計は正値と一致した

まず確認したのは、AIが出す数字の精度です。

結果として、あらかじめ定義を整えたBigQueryのViewを経由させた場合、AIが出した資料ダウンロード、問い合わせ、申し込みの件数は、Looker Studioの数字と一致しました。

つまり、AIに正しい集計の土台を渡せば、日本語で質問するだけでも、手作業で作成していたレポートと同じ数字を返せることが確認できました。

一方で、生データをAIに直接集計させると、数字にずれが発生しました。問い合わせ件数が正値より大きくなったり、申し込み件数が小さくなったりするケースがありました。

原因を確認すると、AIの性能不足ではなく、データ側の命名規則や定義のばらつきが主な要因でした。名前には問い合わせを意味する略号が入っているものの実際には申し込みフォームであるデータ、配信停止などの運用フォームの混入、仮申し込みと本申し込みの二重カウント、旧名称と新名称の併存などが見つかりました。

この検証から、AIによる自然言語分析で正しい数字を出すには、AIを導入する前に「問い合わせとは何か」「申し込みとは何か」といった定義を整えることが重要であるとわかりました。

2. 項目の意味をAIに渡すことで、新しい分析軸が開いた

次に確認したのは、ダッシュボードにない切り口で分析できるかどうかです。

B社のデータには、製品ごとの関心度、お客様の立場、個人・法人の区分など、分析に使える項目が多数ありました。しかし、項目名が社内独自の略号で管理されていたため、AIは最初、それらの意味を正しく理解できませんでした。

そこで、各項目が何を表しているのかを一覧化し、AIに渡しました。たとえば、ある項目は特定製品への関心度を表すスコア、別の項目はお客様の立場を表す区分、さらに別の項目は個人・法人の違いを表す、といった定義です。

その結果、これまで一部の担当者の頭の中にあった知識が、AIによる分析軸として活用できるようになりました。

新たに見えた切り口には、次のようなものがあります。
・お客様の立場別のコンバージョン傾向
・個人・法人の区分別のエンゲージメント差
・製品カテゴリ別の関心度
・複数製品カテゴリへの関心を持つ有望見込み客の抽出
・スコア帯と実際の申し込み行動の関係

特に注目されたのは、スコアが低い層が、実は申し込みを多く行っていたという発見です。一般的にはスコアが高いほど購買行動に近いと考えがちですが、実データでは逆転現象が起きていました。

背景として、保守・更新契約に関するルーティンの申し込みが多く含まれている可能性が見えてきました。この発見により、「マーケティングが商談化を狙って追いかけるべき層」と「カスタマーサクセス側で自動化・効率化すべき層」を分けて考える判断材料が得られました。

3. AIが具体的な打ち手まで提示できることを確認できた

AIは、単に集計結果を返すだけではなく、そこから次に取るべき施策の候補も提示しました。

たとえば、以下のような打ち手です。
・資料をダウンロードしたが問い合わせに至っていない有望見込み客への商談誘導メール
・特定製品への関心度が高いリードを営業へ自動で振り分ける設定
・複数の製品カテゴリに関心を持つリードへのクロスセル提案
・立場別に訴求内容を変えたナーチャリング施策
・保守・更新系の申し込みをカスタマーサクセス側で自動化する運用設計

これらは、既存のダッシュボードを眺めているだけでは見つけにくかった切り口です。

B社にとっての大きな収穫は、レポート作成時間の短縮だけではありませんでした。これまで気づいていなかった顧客行動の違いや、打てていなかった施策候補を発見できたことが、今回の検証の大きな価値でした。

本事例の成功要因は、AIをいきなり万能な分析担当者として扱わなかったことにあります。

AIにすべてを任せるのではなく、まず正しい数字を出すための定義を確認し、次にデータ項目の意味をAIに渡し、そのうえで自然言語分析の有効性を検証しました。

特に重要だったのは、次の3点です。

1. 正値と比較しながら検証したこと

Looker Studio上で正値として扱っている数字とAIの出力を比較したことで、どこまでAIに任せられるか、どこでずれが生じるかを具体的に確認できました。

2. 生データではなく、定義を整えたViewを活用したこと

AIに生データをそのまま読ませるのではなく、定義を整えたViewを通すことで、数字の一致を確認できました。これにより、自然言語分析を実務で使うには、分析用の土台づくりが重要であることが明確になりました。

3. 属人化していた項目定義を言語化したこと

一部の担当者しか知らなかった項目の意味を一覧化し、AIに渡したことで、新しい分析軸が開きました。これは、AI活用のためだけでなく、組織としてデータ活用を進めるうえでも重要な取り組みでした。

今回の検証により、B社ではAIを活用した自然言語分析の可能性を確認できました。一方で、今後さらに活用範囲を広げるための課題も明確になりました。

たとえば、従業員数や業種といった企業属性が十分に入力されていないため、企業規模別・業種別の分析は限定的でした。また、フォーム名や項目名の命名規則にもばらつきが残っており、今後は標準化が必要です。

つまり、今回の検証は「AIで分析できるか」を確認するだけでなく、「AIを活用できるデータ状態にするために、何を整えるべきか」を明らかにする機会にもなりました。

MarketoやBigQuery、Looker Studioなどを導入していても、現場が本当にデータを活用できているとは限りません。

定型的なダッシュボードはあっても、追加の問いを立てた瞬間にSQLや分析担当者への依頼が必要になる。データ項目の意味が一部の担当者にしかわからない。フォーム名や項目名の命名規則が統一されていない。こうした状態では、生成AIを導入しても、すぐに正しい分析ができるとは限りません。

一方で、すべてのデータ基盤を作り直さなくても、まずは既存データにAIを接続し、実データで小さく検証することは可能です。

自然言語でのデータ分析を実務に取り入れるには、まず次の点を確認することが有効です。
・正値として扱う指標が明確になっているか
・「問い合わせ」「申し込み」「資料ダウンロード」などの定義がそろっているか
・フォーム名や項目名の命名規則にばらつきがないか
・データ項目の意味を説明できる一覧があるか
・AIに任せたい分析範囲と、人が判断すべき範囲を切り分けられているか

AI活用の第一歩は、いきなり大きな仕組みを導入することではありません。まずは、自社のデータがAIで分析できる状態にあるかを確認することです。

定義をそろえれば、AIの集計は実務で使える

「問い合わせ」「申し込み」などの定義が整っていれば、AIの集計結果は既存レポートの数字と一致しました。ずれの原因はAIではなく、命名規則やデータ定義のばらつきにありました。

データ項目の意味を渡すと、ダッシュボードにない切り口が見える

属人化していた項目定義をAIに渡すことで、お客様の立場別、個人・法人別、製品カテゴリ別といった新しい分析軸が生まれました。

AIは作業時間の短縮だけでなく、打ち手の発見にもつながる

スコアが低い層の申し込みが多いという逆転現象や、立場ごとの関心度の違いなど、人が同じダッシュボードを見続けるだけでは気づきにくい示唆が得られました。

大がかりなデータ基盤再構築の前に、小さく検証できる

既存のBigQueryデータにAIを接続することで、本格導入前に「自社のデータで自然言語分析が使えるか」を実データで確認できました。