なぜマーケROIは「誰も答えられない」状態になるのか — 測定設計の3層と運用ガイド

このホワイトペーパーで分かること

マーケROIが「誰も答えられない」状態に陥る構造的な原因
「リード数」「CPA」「ROAS」が経営判断に届かない理由
計測設計層・データ統合層・意思決定運用層の3層アーキテクチャ
中小企業がGA4・広告・HubSpot・スプレッドシートを段階的に統合する手順
3ヶ月で「経営と現場が同じROI指標を見る」状態に到達するMonth別ロードマップ
自社のROI測定成熟度を30分で棚卸しするセルフチェックの4軸

対象読者

中小企業のマーケティング責任者・CMO候補
マーケを管掌する事業責任者・取締役
施策が5〜8チャネルに増えたが、経営にROIを説明できなくなっている経営者
月次レポートの集計に3〜5日かかっており、運用が回らないと感じているマーケ担当
AIで生成した記事・広告クリエイティブが増えたが、効いている本数の判定基準が無い責任者

マーケROIが「誰も答えられない」状態に陥る3つの構造的原因
「リード数」「CPA」「ROAS」では経営判断に届かない理由
3層アーキテクチャの全体像：計測設計層 / データ統合層 / 意思決定運用層
計測設計層：KPIツリーとアトリビューションモデルをどう設計するか
データ統合層：GA4・広告・HubSpot・スプレッドシートをどう一本化するか
意思決定運用層：週次/月次の数字レビューを「会議」ではなく「運用」に変える
AIを組み込む優先順位：3ヶ月で効くのはこの3シナリオ
3ヶ月構築ロードマップ：Month 1〜3で揃うもの／揃わないもの
発注前の30分セルフチェック：自社のROI測定成熟度マップ

1. マーケROIが「誰も答えられない」状態に陥る3つの構造的原因

中小企業でマーケROIが「誰も答えられない」状態に陥る原因は、ツール選択の問題ではない。施策数の増加・チャネル分断・ROI定義の不在の3つが同時進行し、それを束ねる設計が後回しになったまま運用が膨らんだ結果である。

中小企業ではマーケが1〜3名の体制で、SEO・広告・コンテンツ・SNS・メール・ウェビナーといった5〜8チャネルを兼務している。1チャネルあたりのデータ深掘りが浅いまま、施策本数だけが増える。AIで記事や広告クリエイティブの生成本数が増えたここ1〜2年、この傾向は加速している。1名のマーケ責任者が10本の記事と5本の広告クリエイティブを並行運用する局面は、中小企業の現場で珍しくない。

第一の原因は施策数の増加そのものではなく、施策の増分に対する測定設計の増分が伴っていないことにある。新しいチャネルや施策を追加するたびに、計測タグ・パラメータ・KPIの再設計が必要だが、現場は実行に手一杯で測定設計に時間を割けない。結果、新施策は「とりあえずGA4のイベントは飛ばしている」状態で始まり、半年後に「効いたのか分からない」が積層する。

第二の原因はチャネル分断である。GA4、各広告管理画面、HubSpotなどのMA、スプレッドシート集計、Notion上の手作業レポートに、データが5〜7箇所に分散している。月次レポートの集計に3〜5日かかる中小企業は、この分散が原因である。集計が遅れると意思決定が遅れ、意思決定が遅れると施策の打ち直しも遅れる、という連鎖が起きる。

原因1：施策数の増加に測定設計が追いつかない

5〜8チャネル並行運用が当たり前になったが、新施策の追加時に計測タグ・パラメータ・KPIの再設計が後回しになる。半年後に「効いたのか分からない」が積層する。

原因2：チャネル分断（データが5〜7箇所に散る）

GA4・広告管理画面・HubSpot・スプレッドシート・Notionにデータが分散。月次集計に3〜5日かかり、意思決定が遅れる。

原因3：ROI定義の不在（経営と現場で見る数字が違う）

経営は受注額・LTVで判断したいが、現場はチャネル別CPA・ROASを報告する。両者の翻訳係数が定義されないまま会議だけが回る。

第三の原因はROI定義の不在である。経営は「受注額」「LTV」「事業利益」で判断したいが、現場は「リード数」「CPA」「ROAS」をチャネル別に報告する。両者の翻訳係数（マーケKPIが事業KPIにどう貢献しているかの定量関係）が定義されないまま、報告会だけが繰り返される。この翻訳の欠落こそが、「ROIが見えない」と「ROIが答えられない」の本質的な差を生む。

3つの原因はそれぞれ独立しているように見えるが、実際には連鎖している。施策数が増えるとチャネルが分断し、チャネルが分断するとROI定義が形骸化し、ROI定義が無いから施策の取捨選択ができず、結果として施策数がさらに膨らむ。この循環を断ち切るのは、特定のツール導入ではなく、計測設計・データ統合・意思決定運用の3層を順序立てて設計し直すことである。

2. 「リード数」「CPA」「ROAS」では経営判断に届かない理由

経営会議で「来月の広告費を増やすべきか減らすべきか」が決まらない原因の大半は、報告される指標がチャネル別効率指標（CPA・ROAS）どまりで、事業ROIに翻訳されていないことにある。CPA・ROASは現場運用の指標として正しいが、それ単独で経営判断はできない。

経営者が知りたいのは「マーケに投下した予算で、3ヶ月後の受注額が結局どれだけ積み上がったのか」である。これを答えるには、リードからの商談化率、商談からの受注率、平均受注額、受注後の継続率（LTV）を、チャネル別に紐付けて見る必要がある。CPAだけ報告されても、商談化率が他チャネルの半分なら、CPAが安いことは経営的にはむしろ悪材料になり得る。

— 現場が見る指標（チャネル別効率）

リード数 / インプレッション / CTR / CPA / ROAS / メール開封率 / 記事PV。施策の良し悪しを週次で改善するためには必要。ただしこの指標群だけでは「来月の広告費を増減すべきか」は答えられない。

— 経営が必要な指標（事業ROIに直結）

チャネル別の受注貢献額 / マーケ起点の商談化率・受注率 / 顧客獲得単価（CAC）/ ペイバック期間 / マーケ起点顧客のLTV。施策の取捨選択と投資配分を月次・四半期で意思決定するための指標。チャネル別効率指標とは別の軸で見る必要がある。

中小企業でこの2階層の指標が分離していない典型例は、月次レポートにチャネル別CPAとROASだけが並んでいるパターンである。経営者が「で、結局マーケ起点で受注はいくら入っているのか」と問うても、HubSpotのリード履歴とSFAの受注データが手動で突き合わされていないため、即答できない。集計に1〜2日かかる、または受注との紐付けが諦められて空白で運用される。これが「ROIが誰も答えられない」状態の現場での見え方である。

CPA・ROASを上げる施策と、事業ROIを上げる施策は、必ずしも一致しない。CPAが安い広告チャネルが、商談化率が低いセグメントばかりを連れてくることは多い。ホワイトペーパーDLのCPAが安く見えても、商談化率が2%しかなく、受注に至るのは50DLに1件、というケースは中小企業のマーケ現場で頻出する。チャネル別効率指標の最適化が、事業ROIの最適化を裏切る局面が存在する。

経営判断に届く指標を設計するときの起点は、事業KPI（年間受注額・四半期受注額・ARR）から逆算することである。逆算すると、マーケに必要な月次の新規商談数が決まり、商談化率から逆算して必要なリード数が決まり、リード数から逆算してチャネル別の獲得目標が決まる。この逆算の鎖が成立していて、かつチャネル別の実績データが受注まで紐付けられていれば、経営会議で「広告費を増やす根拠／減らす根拠」が定量で語れる。

3. 3層アーキテクチャの全体像：計測設計層 / データ統合層 / 意思決定運用層

マーケROI測定を中小企業で機能させるためには、計測設計層・データ統合層・意思決定運用層の3層を、責務の階層として明確に分離し設計する必要がある。3層のうちどれか1つでも欠けると、他の2層の投資が回収できない。

3層アーキテクチャは「何を測るか（計測設計層）」「どこに集めるか（データ統合層）」「誰がいつ判断するか（意思決定運用層）」の3問いに対応する。中小企業のマーケROI測定の議論はツール選択（HubSpotか、Marketoか、BigQueryか）に流れやすいが、ツールはこの3問いのうちの2問目を担う1要素に過ぎない。1問目と3問目が未設計のままツール導入を進めると、ダッシュボードは立ち上がるが運用に乗らない、という状態に着地する。

計測設計層：事業KPIから逆算したKPIツリーとアトリビューション

事業KPI（受注額・LTV）から逆算したマーケKPIツリーを設計し、各チャネルが事業ROIにどう貢献するかの翻訳係数（アトリビューションモデル）を定義する。責務は「何を測るか」を決めること。

データ統合層：分散データを1ダッシュボードに集約

GA4・広告管理画面・HubSpot・SFA・スプレッドシートを統合し、計測設計層で定義したKPIを1ダッシュボードで見られる状態にする。責務は「分散データを束ねる」こと。

意思決定運用層：週次/月次レビューを運用に組み込む

統合されたダッシュボードを使って、誰がいつ何を判断するかを運用に乗せる。週次（施策レビュー）・月次（投資配分判断）・四半期（戦略見直し）の3階層でリズムを作る。責務は「数字を判断と紐付ける」こと。

計測設計層が落ちていると、データ統合層と意思決定運用層が立ち上がっても「何を見ても意思決定に繋がらない」状態になる。事業KPIから逆算されたKPIツリーが無いまま、GA4の数値とHubSpotのリード数をBigQueryに集約しても、出てくるのは「数字の集合」であって「判断材料」ではない。

データ統合層が落ちていると、計測設計層で立派なKPIツリーを定義しても、実データで埋められない。経営会議で「マーケ起点の商談化率は今月何%か」と問われても、HubSpotとSFAを毎月手作業で突き合わせている限り即答できない。逆に統合層が整うと、計測設計層で定義した指標が常時更新されるダッシュボードに乗り、月次集計の3〜5日が30分に圧縮される。

意思決定運用層が落ちている状態は、最も見落とされやすい。ダッシュボードを立ち上げただけで、運用に乗らないままダッシュボードが「誰も見ない壁紙」になっているパターンである。週次レビューの参加者・アジェンダ・判断基準が定義されないと、整備したダッシュボードのROIは出ない。3層のうち最も投資額が小さいが、最後に効くのがこの層である。

3層を順序立てて設計し直すことで、AIによる自動化（タグ付与・要約・スコアリング・異常検知）を乗せる土台が一気に整う。AIは3層のいずれの層にも組み込めるが、土台が無いまま個別にAIを散りばめると、効果が分散して測定対象から外れる。AI組み込みの議論は3層が立ち上がった後に始めるのが現実的である。

4. 計測設計層：KPIツリーとアトリビューションモデルをどう設計するか

計測設計層の中核は、事業KPIを最上位に固定したKPIツリーと、チャネル接触の貢献度を配分するアトリビューションモデルの2点である。中小企業ではフルマルチタッチアトリビューションを組むのは過剰で、ファースト・ラスト・線形の3パターンを使い分けるのが現実的である。

KPIツリーは事業KPI（年間受注額・四半期ARR）を頂点に置き、そこから逆算する。例えば中堅規模の事業会社が今年マーケ起点で新規受注を一定額狙う場合、平均受注単価から必要受注数が決まり、受注率20%なら必要商談数、商談化率10%なら必要リード数、と逆算が降りる。これがツリーの幹である。

ツリーの枝は、必要リード数7,500件をチャネル別に配分する設計である。SEO起点・広告起点・ホワイトペーパーDL起点・ウェビナー起点・SNS起点・メールリスト起点、と6〜8チャネルに分けて月次目標を持つ。ここで重要なのは、各チャネルの目標は「リード数」ではなく「事業ROIへの寄与係数」で評価することである。リード数が同じ100件でも、商談化率が異なれば事業ROIへの寄与は2〜5倍違う。

アトリビューションモデルは、複数チャネルを経由したリードが受注に至った場合、どのチャネルにどれだけ貢献度を配分するかのルールである。中小企業のマーケ計測で過剰な精度を求めると運用が破綻するため、4象限で施策の位置付けを整理した上で、ファースト・ラスト・線形の3パターンに集約するのが実装可能な範囲である。

低高チャネル接触頻度

高低受注貢献度

低頻度・高貢献

年に数回しか接触しないが、接触すると高確率で商談化するチャネル。例：業界向け基調講演登壇・大手メディア取材・経営者向けクローズドウェビナー。ラストタッチアトリビューションでは過大評価される。線形配分で評価する。

高頻度・高貢献

日常的に接触し、かつ受注貢献も高い主力チャネル。例：自社SEO記事の指名キーワード経由流入・既存リードへのメールナーチャリング・ホワイトペーパーDL。投資配分の中核。ラスト/線形どちらでも評価が安定。

低頻度・低貢献

接触頻度も低く貢献も低い。多くは整理・撤退の候補。例：年1回のスポット展示会・効果検証なしのアドネットワーク広告。投資を引き上げて他象限に再配分する判断対象。

高頻度・低貢献

大量に接触しているが受注貢献が薄いチャネル。例：SNSの一般投稿・運用が形骸化した広告キャンペーン・配信目的化したメルマガ。最適化余地が大きい領域だが、AIで自動化したまま放置されやすい盲点でもある。

3パターンの使い分けは目的別になる。ファーストタッチは新規認知への投資判断（どのチャネルが初接触を作っているか）、ラストタッチは商談化直前のレバー特定（どのチャネルがクロージング時に効いているか）、線形配分は事業ROI全体の俯瞰（複数チャネル接触の貢献度を均等配分）に使う。1つのアトリビューションモデルに固執するのではなく、3パターンで多面的に見ることが、中小企業の実装範囲として現実的である。

AIによる発話・問い合わせ内容の自動タグ付けを計測設計層に組み込むと、ツリーの末端の解像度が上がる。受注に至った商談の議事録・問い合わせフォームの自由記述を、LLMで自動分類してKPIツリーに紐付けると、「どのテーマ・どの課題のリードが受注に近いか」がチャネル別だけでなく内容別にも見えるようになる。この一段深い計測が、AI前提時代のKPIツリー設計の現実的な肉付けである。

5. データ統合層：GA4・広告・HubSpot・スプレッドシートをどう一本化するか

データ統合層の設計で最初に決めるべきは、「全データを一気に集約する」のではなく「事業ROIに直結する3〜5指標を確実に1ダッシュボードで見る」を起点にすることである。中小企業の社内開発リソースで3ヶ月の構築期間を考えると、絞り込みこそが成否を分ける。

統合先の選択肢はBigQuery + Looker Studio、HubSpotのカスタムレポート、Looker Studioのみ（コネクタ直結）、Notion Database＋スクリプト連携、など複数ある。中小企業では、BigQuery + Looker Studioを中核に、計測タグはGA4で統一する構成が、3ヶ月で立ち上げる現実的な選択肢として頻出する。

統合の難所は技術ではなく、計測タグの命名規則・パラメータ設計・データ重複の判定ルールである。例えば1人のリードがウェビナー申込フォーム・ホワイトペーパーDL・問い合わせフォームの3つを別々の日に送信した場合、HubSpot側で同一Contactに統合される必要がある。メールアドレスを主キーにする運用は基本だが、フリーメール・社内共用メール・典型的なミススペルを吸収する正規化ルールを最初に定義していないと、ダッシュボード上で1人が3人にカウントされる。

指標を3〜5本に絞り込む

事業KPIに直結する指標だけを最初の統合対象にする。例：マーケ起点商談化率／チャネル別獲得CAC／月次マーケ起点受注額／パイプライン金額／LTV12ヶ月平均。それ以外の指標は段階拡張で後追いする。

計測タグとパラメータを再整備

GA4のイベント命名規則・UTMパラメータ規約・HubSpotのカスタムプロパティを統一する。命名規則の文書化が次工程の基盤になる。チームに新メンバーが入っても規則が継承される状態にする。

統合先を選定し初期接続

BigQuery + Looker Studio構成なら、GA4のBigQueryエクスポート設定・広告管理画面の各種コネクタ・HubSpot APIによる定期同期を順に繋ぐ。各データソースの更新頻度（日次・時間次）を明示する。

ダッシュボードを公開し定例で見る

3〜5指標のシンプルなダッシュボードを公開し、週次レビュー会のアジェンダに組み込む。誰が見ても同じ数字が出る状態を作ることが第一目的で、見栄えやインタラクティブ性は後追いで良い。

データ統合層の構築は、FULLFACTで言えば「データ基盤 / BI 構築」（B07・1〜2ヶ月）の範囲に相当する。納品物は計測タグ設計と実装、GA4 / GSC / 広告 / SFAの統合、BigQuery / Looker Studioダッシュボード、計測仕様書と運用マニュアルの4点である。1〜2ヶ月で立ち上げる範囲を「事業ROIに直結する3〜5指標を1ダッシュボードで見る」状態に絞り込むことで、3ヶ月のうちMonth 2〜3を統合層に充当できる。

段階拡張の設計も合わせて持っておく。Month 1〜3で立ち上がるのは中核の3〜5指標と1ダッシュボードで、ここから先のMonth 4〜6で「チャネル別マイクロセグメント分析」「ファネル詳細分析」「カスタマージャーニー横断分析」を段階的に追加する。最初から全部を組もうとすると、要件定義だけで2〜3ヶ月使ってしまい、現場の意思決定タイミングを逃す。最小構成で動かして、運用に乗せながら拡張するのが現実的な進め方である。

統合層が機能し始めると、月次レポートの集計時間が大きく減る。3〜5日かかっていた月次集計が、ダッシュボード公開後は30分〜1時間で1人が確認するだけになる、というのが中小企業のマーケ現場で起きる典型的な変化である。この時間圧縮は、現場が施策運用に戻れる時間を作り、結果として施策の質が上がる二次効果を生む。

6. 意思決定運用層：週次/月次の数字レビューを「会議」ではなく「運用」に変える

ダッシュボードが整っても、それを使った意思決定が運用に乗らなければROI測定は機能しない。意思決定運用層の設計の中核は、週次・月次・四半期の3階層でリズムを作り、各階層で「誰が何を見て何を決めるか」を明確にすることである。

数字レビューを「報告会」から「意思決定会」に変える鍵は、AIが事前にサマリと異常値の仮説を出し、人間は判断に集中する形に役割分担することである。マーケ責任者がスプレッドシートを開いて数字を集計し、コメントを書き、スライドにまとめる作業に週4〜6時間を消費している状態は、中小企業のマーケ現場でよく見る。この時間をAIが下書きする運用に移すと、人間の時間は「数字の読み」と「意思決定」に集中する。

週次レビューは施策レベルの改善判断、月次レビューは投資配分の見直し、四半期レビューは戦略の見直しに用途が分かれる。週次に経営者を巻き込むと意思決定の解像度が合わず、四半期だけだと施策の打ち直しが遅れる。3階層を分けることで、各階層に適したメンバーと意思決定スコープが定義できる。

— TIP

週次レビュー（30分・マーケ担当＋責任者）：先週の3〜5指標の変動／異常値の検知結果／施策別の進捗／次週のアクション3つ。アジェンダ固定。 月次レビュー（90分・マーケ責任者＋事業責任者）：月次の事業ROI／チャネル別寄与の変化／投資配分の見直し提案／来月の予算配分判断。AI下書きのサマリを起点に進める。 四半期レビュー（120分・経営層含む）：3ヶ月トレンド／戦略レベルの調整（チャネル増減・撤退）／半年先の見通し／予算再配分。

意思決定の質を上げるためには、レビュー前に「判断を要する論点」と「判断材料」をAIに整理させる運用が効く。例えば月次レビュー前日に、過去30日のダッシュボードデータをLLMに渡して「事業ROIに対する寄与が上位30%のチャネルの変化点を3つ」「下位30%のチャネルで撤退検討すべきものを1つ」「来月の予算配分の3パターン（積極・現状維持・縮小）」をドラフトさせる。マーケ責任者はこのドラフトに対して「自分の見立てとの差異」「現場の温度感の補正」を加えて、会議に持ち込む。会議は判断に集中できる。

運用に乗せるための鉄則は、レビューの形式・参加者・アジェンダ・所要時間を固定することである。「今月は事業責任者の都合で30分短縮」「次回はマーケ担当のみで」と例外運用を許すと、3ヶ月で形骸化する。年間カレンダーに固定の予定として組み込み、欠席者には議事録と判断結果を漏れなく送る運用が、半年スパンで定着するかどうかを決める。

意思決定運用層が立ち上がると、経営者が「マーケに月いくら投下しているのか、それで何が起きているのか」を即答できるようになる。この状態は、経営者が次の投資判断（人員追加・チャネル拡張・ツール導入）の意思決定をするときに、推測ではなく数字を起点にできる。3層アーキテクチャの最後の層が、経営判断の解像度を底上げするレバーになる理由はここにある。

7. AIを組み込む優先順位：3ヶ月で効くのはこの3シナリオ

マーケ計測にAIを組み込む適用領域を多数列挙すると焦点がボケる。3ヶ月で運用に乗りやすいのは、データの入口・数字の異常検知・アウトプット自動化の3シナリオに絞った形である。

3シナリオ

3ヶ月でマーケ計測の運用に乗るAI組み込み領域は、データの入口（タグ付与）／数字の異常検知（ダッシュボードの監視）／アウトプット自動化（月次レポート下書き）の3つに絞ると効く。

第一シナリオは、データの入口でのタグ付与である。問い合わせフォーム・ウェビナー申込フォーム・ホワイトペーパーDLフォームの自由記述項目を、LLMで自動分類してHubSpotのカスタムプロパティに書き戻す運用。例えば自由記述の「課題は何ですか」回答を「営業効率化」「データ統合」「マーケ計測」「採用」など事前定義したタグに自動分類する。手作業で分類すると週2〜3時間かかる処理が、運用設計後は実質ゼロ時間になる。3ヶ月の中ではMonth 1〜2で実装に着手しやすい領域である。

第二シナリオは、ダッシュボードでの異常値検知と仮説生成である。例えば「先週のCV率がチャネルAで前週比マイナス40%」のような変化を検知し、「広告クリエイティブ差し替えのタイミングと一致」「ランディングページのABテスト切り替えと一致」など複数の仮説を提示する運用。人間の見落としを防ぎ、レビュー会で「何が起きたか」の議論を「なぜ起きたか」「次どうするか」の議論に進める時間を作る。

第三シナリオは、月次レポートの自動ドラフト生成である。ダッシュボードデータをLLMに渡し、「事業ROIへの寄与トップ3チャネル」「変化点3つ」「来月の論点3つ」を含む下書きを生成する。マーケ責任者はこのドラフトを起点に、自分の見立てと現場の温度感を加える編集作業に集中する。月次レポート作成に半日〜1日かかっていた工数が、編集作業1〜2時間に圧縮される、というのが中小企業のマーケ現場で起きる典型的な変化である。

3シナリオの組み込み順は「データの入口（タグ付与）」「数字の異常検知」「アウトプット自動化」の順で進めると、3ヶ月で運用に乗る。データの入口でタグが整備されていないと、後段の異常検知も自動レポートも精度が出ない。最も地味だが、最初に投資すべきシナリオである。

3シナリオから外したものも明示しておく。AI広告クリエイティブの自動最適化・AIによるパーソナライズメール生成・LLMによる予測モデリングなどは、効果は出るが3ヶ月の構築期間を超える。3ヶ月で3層アーキテクチャと3シナリオを動かした後、Month 4以降の拡張範囲として扱うのが現実的である。最初から手を広げると、土台が無いまま個別AIが散らばり、効果が測れない状態に戻ってしまう。

8. 3ヶ月構築ロードマップ：Month 1〜3で揃うもの／揃わないもの

3ヶ月構築の標準型は、Month 1で計測設計と指標絞り込み、Month 2でデータ統合とダッシュボード、Month 3で意思決定運用とAI組み込みの順序で進める。3ヶ月で揃うのは「経営と現場が同じ3〜5指標を見ている状態」までで、フルアトリビューションや個別最適化はMonth 4以降の領域である。

Month 1

計測設計と指標絞り込み

事業KPIから逆算したKPIツリー設計／チャネル別寄与係数の定義／アトリビューションモデル3パターンの選択／計測タグ命名規則・UTMパラメータ規約の整備／指標を3〜5本に絞り込み。納品物は計測仕様書ドラフトと統合ダッシュボードの要件定義。

Month 2

データ統合とダッシュボード

GA4のBigQueryエクスポート設定／広告管理画面・HubSpot・SFAのコネクタ接続／データ重複・正規化ルールの実装／BigQuery + Looker Studioでの3〜5指標ダッシュボード公開。納品物は稼働ダッシュボードと運用マニュアル初版。

Month 3

意思決定運用とAI組み込み

週次・月次・四半期レビューの参加者とアジェンダ確定／AI下書き運用の仕組み化（タグ付与・異常検知・月次レポート）／3回分の週次レビューと1回の月次レビューを実走行／運用上の調整。納品物は運用SOPと最初の月次レポート。

Month 1は計測設計層の構築フェーズである。この月の最大の意思決定は「事業KPIをどこに固定するか」と「指標を3〜5本に絞り込むこと」の2点。マーケ責任者と事業責任者の合意形成が要るため、ヒアリングと議論の往復が中心になる。FULLFACTの「グロース戦略」（S03・1〜2ヶ月）の前半フェーズに相当する範囲で、現状診断とボトルネック特定、成長レバーと優先順位、投資配分とロードマップが主な納品物となる。

Month 2はデータ統合層の構築フェーズで、技術的な実装が中心となる。「データ基盤 / BI 構築」（B07・1〜2ヶ月）の範囲が直接対応する。計測タグ設計と実装、GA4 / GSC / 広告 / SFAの統合、BigQuery / Looker Studioダッシュボード、計測仕様書と運用マニュアルが納品物として揃う。この月にダッシュボードが稼働することで、Month 3の意思決定運用のリハーサルが可能になる。

Month 3は意思決定運用層の立ち上げとAI組み込みのフェーズである。週次レビューを3回・月次レビューを1回、実走行することが、運用が乗ったかどうかの判定基準になる。「マーケ基盤構築」（B03・3ヶ月）と組み合わせると、マーケ組織設計とKPIツリー、MA / CRM設計と初期構築、AIコンテンツ生成・スコアリング基盤、マーケSOPと運用マニュアルまでが3ヶ月で揃う統合構築のパスになる。

3ヶ月で揃わないものを先に明示しておくことは、社内合意形成上極めて重要である。フルマルチタッチアトリビューションの精緻化、チャネル別マイクロセグメント分析、AIによる予測モデリング、LTV予測モデルなどはMonth 4〜9の領域である。3ヶ月時点で測れるのは「経営と現場が同じ3〜5指標を見ている状態」までで、収益効果が立ち上がるのは仕組みが回り始めて4〜6ヶ月後である。経営者がこの時間軸を最初に合意できているかが、3ヶ月後の解散リスクを左右する。

Month 4以降は3層を厚くするフェーズになる。計測設計層でアトリビューションの精緻化、データ統合層でマイクロセグメント分析、意思決定運用層で四半期戦略レビューの定例化、を段階的に進める。最初の3ヶ月で立ち上げた最小構成を踏み台にすることで、Month 4以降の拡張は要件定義から運用まで1〜2ヶ月で1サイクル回せるようになる。

9. 発注前の30分セルフチェック：自社のROI測定成熟度マップ

外部パートナーに相談する前に、自社のROI測定成熟度を30分でセルフチェックしておくと、提案の解像度が変わる。4軸（経営が見ている指標／現場が見ている指標／データの分散先／意思決定で詰まる頻度）で棚卸しすると、自社の位置が3レベル（測定なし／チャネル別測定どまり／統合測定運用中）のどこにあるかが見える。

第一軸は「経営が見ている指標」である。経営会議で報告されるマーケ関連指標を箇条書きで書き出す。「リード数」「広告費」「メルマガ配信数」しか出てこなければ、事業ROIへの翻訳が無い状態である。「マーケ起点の四半期受注額」「マーケ起点商談化率」「顧客獲得単価（CAC）」が並んでいれば、事業ROI指標が設計されている状態である。

第二軸は「現場が見ている指標」である。マーケ担当が日常的に見る指標を書き出す。GA4・各広告管理画面・HubSpotの各画面で何を確認しているかをリストにする。チャネル別CPA・ROAS・CTRが並ぶのは一般的だが、それと第一軸（経営指標）が翻訳係数で繋がっているかどうかが要点になる。両軸の間に明示的な翻訳が無ければ、「ROI定義の不在」状態である。

第三軸は「データの分散先」である。マーケに関するデータがどこに格納されているかを列挙する。GA4・Google広告・Meta広告・HubSpot・Salesforce・スプレッドシート・Notion・各種MA、と数えていく。5つ以上に分散していて、かつ統合ダッシュボードが無ければ、データ統合層が未整備の状態である。

第四軸は「意思決定で詰まる頻度」である。経営会議や月次レビューで「数字が出ない」「集計に時間がかかる」「結局判断できない」が起きる頻度を、月次・四半期で書き出す。月1回以上詰まっている状態であれば、意思決定運用層が機能していない状態である。

— NOTE

30分セルフチェックの進め方：4軸それぞれを5分ずつ書き出し、最後に10分でレベル判定をする。 レベル1：測定なし（経営指標が「リード数」「広告費」のみ／現場指標が箇条書きで出てこない／データの分散先が5つ以上／意思決定の詰まりが月1回以上） レベル2：チャネル別測定どまり（経営指標と現場指標が分離／データ統合ダッシュボード無し／月次集計に3〜5日／意思決定が四半期に2〜3回詰まる） レベル3：統合測定運用中（経営指標と現場指標が翻訳係数で繋がる／統合ダッシュボードが稼働／月次集計が1時間以内／意思決定が数字起点で進む）レベル1〜2の自社は、3層アーキテクチャの順序立てた構築が次の打ち手になる。

セルフチェックの結果がレベル1だった場合の最初の打ち手は、計測設計層から手を付けることである。データ統合層やAI組み込みは後回しで、まずは「事業KPIから逆算したKPIツリーを描く」「指標を3〜5本に絞り込む」の2点に集中する。3層の順序を守ることが、最短で結果を出す経路である。

レベル2だった場合の打ち手は、データ統合層の構築である。計測設計層は一定整っているが、データが分散していて月次集計に時間がかかっている状態が典型である。BigQuery + Looker Studioへの統合と、3〜5指標のダッシュボード公開を2ヶ月で立ち上げると、Month 3には意思決定運用層に進める。

レベル3だった場合の打ち手は、Month 4以降の拡張領域である。フルアトリビューションの精緻化、AI予測モデリング、LTV予測モデルなど、3層の上に乗せる発展形を検討するフェーズに入る。FULLFACTでは「マーケ基盤構築」（B03・3ヶ月）の中で、MA / CRM連携とAIスコアリング基盤までの統合構築を進めるパスを取ることが多い。

外部パートナーに相談する際は、このセルフチェック結果（自社レベルと4軸の現状）を最初に共有する。提案側がどの層から、どの順序で、どの予算規模で着手すべきかを判断する材料が揃うと、初回提案の解像度が変わる。何も棚卸ししない状態で「マーケROIの測定を改善したい」とだけ伝えると、一般論の提案が返ってきて意思決定が進まない。

まとめ

マーケROIが「誰も答えられない」状態の根本原因は、施策数増加・チャネル分断・ROI定義不在の3つの連鎖。ツール選定では解決しない。
CPA・ROASは現場運用の指標として正しいが、事業ROIに翻訳されていなければ経営判断には届かない。事業KPIから逆算するKPIツリーが起点になる。
計測設計層・データ統合層・意思決定運用層の3層を順序立てて設計することが、3ヶ月で結果に届くための最短経路。AI組み込みは3層の土台が整った後に着手する。
AIで3ヶ月で運用に乗るのは「データの入口（タグ付与）」「数字の異常検知」「アウトプット自動化」の3シナリオに絞る。
発注前に30分の自社セルフチェック（4軸・3レベル）を実施すると、外部パートナーとの初回提案の解像度が変わる。

次のステップ

自社のROI測定設計を3ヶ月で再構築するなら、まずS03 グロース戦略（1〜2ヶ月）で現状診断とボトルネック特定、成長レバーと優先順位、投資配分とロードマップを設計します。データ統合層の実装はB07 データ基盤 / BI 構築（1〜2ヶ月）で計測タグ設計から統合ダッシュボード公開までを担当。マーケ組織設計とMA / CRM連携、AIスコアリング基盤まで含めた統合構築はB03 マーケ基盤構築（3ヶ月）が範囲です。「いきなり戦略・構築は重い」場合はB01 業務診断パッケージ（1ヶ月）から始め、マーケ業務の棚卸しとAI適用領域の優先度リストで自社の打ち手を見える化する入口設計をご利用いただけます。