BIとAIの棲み分け設計：マーケ指標を統制する手順
「BI is dead」論を入口に、定型指標はBI・アドホックな探索はAIという棲み分けの決め方、問いの設計、根拠を検証する統制の手順を、BtoBマーケティング部長向けに整理します。
公開 2026年9月24日
結論：BIとAIは置き換えではなく役割分担
結論から述べます。AIが入ってもBIはなくならず、役割が分かれます。
判断の軸は単純です。定型・共通指標はBI、アドホックな探索はAI。この線引きを先に決めないと、同じ数字が会議ごとに変わります。
マーケティング部門でまず固めるべきは、MQL・SQL・CPL・CVRの定義と計算式です。定義が一本化されていない状態でAIに問いを投げても、答えの正しさを誰も判定できません。
本記事では、棲み分けの決め方、問いの設計、出力の検証手順、統制のチェックリストを扱います。
※本記事は2026年9月時点の情報をもとに作成しています。
「BI is dead」論とは
「BI is dead」論とは、自然言語で分析できるAIが普及すればダッシュボードは不要になる、という主張です。2026年9月にSalesforce Japan Blogが有識者の見解を紹介し、議論が可視化されました。同記事では、AIはBIを不要にせず役割を再定義するという見方で一致したと整理されています。
マーケティング文脈に置き換えると、論点は3つです。
- 共通基盤：全員が同じ指標・同じ定義を見る場所が要るか
- 探索：その場で立てた仮説を検証する手段は何か
- 説明可能性：出てきた数字の根拠をたどれるか
BIは1つ目を担います。AIは2つ目に向きます。3つ目は、どちらを使う場合も設計しないと成立しません。
つまり議論の実体は「BIの要否」ではなく「どの問いをどちらに渡すか」の設計です。
棲み分けの判断基準
棲み分けは、問いの性質で決めます。頻度・定義の固定度・意思決定の重さの3点で振り分けます。
| 判断軸 | BIに寄せる | AIに寄せる |
|---|---|---|
| 頻度 | 毎週・毎月繰り返す | 単発・その場限り |
| 指標定義 | 合意済みで固定 | 定義を試行錯誤中 |
| 参照者 | 経営・営業・マーケが共有 | 担当者個人の仮説検証 |
| 求める粒度 | 推移と差分 | 要因の分解・仮説列挙 |
| 誤りの影響 | 予算配分など重い | 次の調査対象を絞る程度 |
運用上のルールはこう置きます。
- 会議資料に載る数字はBIから取る
- AIの出力は、BIの数字で裏を取ってから共有する
- AIで繰り返し使えた問いは、BIの定型レポートに昇格させる
3番目が要です。アドホックな問いのうち、再現性があるものだけを定型化します。これをやらないとダッシュボードが増え続け、誰も見なくなります。
問いの設計と出力の検証手順
AI時代に効くのは実装力より「問いの設計」です。設計と検証を続けて手順に落とします。
1. 意思決定を先に書く
「何を決めるための数字か」を1行で書きます。決めることがない問いは、出力が出ても使われません。
2. 指標を式で書く
MQLは「どのスコア以上」「どの行動が起点」かまで書きます。CVRは分母を明示します。分母の定義違いが、部門間の数字のズレの大半を生みます。
3. 比較対象を決める
単独の数値は解釈できません。前月・前四半期・他チャネルのいずれと比べるかを先に決めます。
4. 反証条件を決める
「この数字がこうなら仮説は外れ」と先に宣言します。AIの出力は都合よく読めてしまうため、先に反証を置きます。
5. 粒度と期間を固定する
期間をずらせば傾向は変わります。集計期間・タイムゾーン・重複排除の扱いを固定します。
6. 出力を項目で検証する
検証は項目化しておくと属人化しません。
| 検証項目 | 確認すること | 不合格時の対応 |
|---|---|---|
| データソース | どのテーブル・期間を参照したか | 参照先を指定して再実行 |
| 指標定義 | 社内定義と式が一致するか | 定義を明示して再実行 |
| 欠損・重複 | 除外条件が明示されているか | 条件を固定して再集計 |
| 再現性 | 同じ問いで同じ結果か | 揺れる箇所を定型化 |
| 根拠提示 | 数字の出所をたどれるか | たどれない出力は共有しない |
原則は1つです。根拠をたどれない出力は、社外にも社内会議にも出さない。
生成物の根拠と参照範囲をどう管理するかは、AIの回答を統制する考え方も併せて整理してください。
マーケティング指標への適用
棲み分けは、日々のKPI運用に落とすと具体化します。
| 場面 | BIで見るもの | AIに聞くもの |
|---|---|---|
| 週次の進捗 | リード数・MQL数・CPLの推移 | 前週と差が出た要因の候補列挙 |
| チャネル評価 | チャネル別CPLとSQL到達 | 除外すべき外れ値の洗い出し |
| ナーチャリング | シナリオ別の反応推移 | 反応が鈍い層の共通点の仮説 |
| 営業連携 | MQLの引き渡し件数と滞留 | 滞留案件の記述内容の要約 |
注意点は、AIが出した「要因の候補」を結論として扱わないことです。候補はあくまで次に見る場所の指示です。
営業との数字のズレは、定義とSLAの問題であることが多いです。引き渡し基準の整え方はMQLの引き渡しとSLA設計で扱っています。
チャネル評価の前提を揃える観点は費用対効果の見方も参照できます。
よくある失敗のパターン
よくある失敗を、一般化して挙げます。
定義を決めずにAIを入れる
MQLの定義が部門ごとに違うまま自然言語分析を始めると、答えの正誤を誰も判定できません。直し方は、指標定義書を1枚にまとめ、式と分母を書くことです。
ダッシュボードが増え続ける
要望ごとにレポートを作り、使われない画面が残ります。直し方は、四半期ごとに閲覧のない定型レポートを棚卸しすることです。
AIの出力をそのまま会議資料にする
根拠が示されないまま数字が一人歩きします。直し方は、共有前にBIの数字で裏を取る運用を必須にすることです。
問いが「分析して」で終わる
意思決定が書かれていないため、出力が長くなるだけです。直し方は、問いのテンプレートに「何を決めるか」欄を置くことです。
人材育成を後回しにする
ツールだけ入れても、問いを立てられる人が増えません。直し方は、問いの設計と検証をレビュー対象に含めることです。
この進め方が向いていないケース
この棲み分け設計が適さない場合もあります。
データ基盤が未整備の場合は向きません。取得元が散在し、重複排除もできていない段階では、BIもAIも同じ誤りを再生産します。先に収集と名寄せを整えます。
指標の合意が取れていない組織も適しません。定義の議論を飛ばしてツール選定に進むと、運用開始後に数字の否認が起きます。
意思決定の頻度が低い事業では、定型レポートの整備が負荷に見合いません。都度集計で十分な場合があります。
規制やセキュリティ要件で外部処理が制限される領域では、AI側に渡せるデータ範囲が限られます。範囲の線引きを先に確認してください。
また、施策側の改善が先という場合もあります。着地ページの構造に課題があるときはLPのCVRが頭打ちになる要因の整理が先になります。
よくある質問
BIはもう不要になりますか。
不要にはなりません。組織全員が同じ指標を見る共通基盤としての役割が残り、AIが参照する信頼できるデータソースにもなります。
AIに任せる範囲はどう決めますか。
頻度・定義の固定度・誤りの影響の3点で判断します。単発で、定義が試行錯誤中で、誤っても次の調査対象を絞る程度の問いがAI向きです。
SQLやPythonを学ぶ必要はありますか。
実装力より、解くべき課題を定式化する力と、出力の妥当性を検証する批判的思考が重要という見方が示されています。
定型レポートはどう減らしますか。
閲覧実績で棚卸しします。一定期間参照されていない画面は統合するか廃止し、代わりに問いのテンプレートを整備します。
営業と数字が合いません。
多くは定義のズレです。分母・期間・重複排除の扱いを揃え、引き渡し基準を文書化してください。
まとめ
整理します。BIとAIは対立せず、問いの性質で分担します。
- 定型・共通指標はBI、アドホックな探索はAI
- 問いは「何を決めるか」から書く
- 出力は根拠をたどれるかで採否を決める
- 再現性のある問いだけを定型に昇格させる
この順序を守れば、ツールが増えても指標の一貫性は保てます。逆に定義の合意を飛ばすと、どのツールでも同じ混乱が起きます。
まずは指標定義書の1枚化から着手してください。関連する整理はナレッジ記事の一覧にまとめています。
なお、UniAgentは、Webサイト上で登録資料を根拠に説明とヒアリングを行い、その文脈を担当者へ引き継ぐAIです。