新しいBIを作ったのに、これまでのスプレッドシートやSalesforceのレポートと数字が合わない。
私の経験上、このような既存レポートと新しいBIの数字が合わないときは、どこで差が生まれたかを探すことが大切です。つい数字を合わせたくなりますが、まずは「なぜそうなったのか」を確かめましょう。
本記事では、このようなケースで困っている方のためにデータの流れと調査手順を示します。また、実際に遭遇した2つの例も紹介します。
構築担当者は調べ方を、業務部門の担当者は入力や数え方を確認する観点を持ち帰れます。
BIの数字は、入力からDWH・BIまで複数の工程を通っている
まず、BIに表示される数字がどのような工程を通っているのかについて、簡単に解説します。数字が合わない原因を探る上で、「どのような工程を通るのか」が分かっていることは重要です。
営業活動やWeb上の行動（図解内01）は、まずSFA（営業活動を管理するシステム）やCRM（顧客情報を管理するシステム）、計測ツールに記録されます（02）。その記録が連携処理でDWH（データウェアハウス）に取り込まれます（03）。
DWHとは、各システムのデータを1か所に集め、集計しやすい形に加工しておく場所です。DWHでは、顧客の表と案件の表を共通のIDでつなぐ「結合」や、部署・顧客区分を付ける分類などの加工を行い（04）、その結果がBIの画面に表示されます（05）。表示された数字は、会議や施策の判断に使われます（06）。
BIの画面だけでは、数字が合わない場所は分からない
BIに見えるのは、一連の処理を通った後の結果です。
元のシステムに記録がない場合と、DWHで対象から外れた場合では、同じ件数差でも確認先が変わります。
そのため、調査するときは対象の指標について、どのシステムから、どの処理を経てBIへ届くかを書き出します。
業務部門も「BIだけを直せばよい」と決めず、入力方法や何を数えるかというルールを確認する必要があります。
BIの数字が合わない工程は、3つの手順で上流から探す
それでは、具体的に既存レポートと新しいBIで数字が合わないときの比較方法を解説します。
既存レポートと新しいBIの数字を比べるときは、次の3つの手順で進めましょう。合計だけを見ても原因を絞れないことに注意してください。
- 比較条件をそろえる
- 工程ごとの件数を比べる
- 対象のレコード（1件ごとのデータ）を追う
以下、各手順を順番に解説します。
手順1：期間・更新時点・集計単位・フィルターを既存レポートとそろえる
まず「同じ数字」を比べているかを確かめます。
同じ「今月の受注件数」でも、受注日で数えるのか登録日で数えるのかによって対象は変わります。
以下の項目を既存レポートと新しいBIでそれぞれ書き出しましょう。
- 対象期間
- データの最終更新時刻
- 集計単位（日次か月次か）
- BIの画面で指定したフィルター
- データを取り出すSQL（データベースへの命令文）に書いた条件
条件をそろえられない場合でも、その違いを残したまま「BI側の不具合」と判断しないことが大切です。
比較の基準日と条件を記録しておけば、後で同じ結果を再現できます。全体の合計に差があれば、日付や部署、状態ごとに分け、差が出る範囲も絞りましょう。
手順2：元システムからBIまで、工程ごとの件数を突合する
次に、対象件数を比べます。金額の合計も、必要に応じて比べましょう。
以下の順番で比較します。
- 元システム
- 連携後のデータ（DWHに取り込んだ直後のデータ）
- DWHでの加工後
- BI表示
件数を順に比べていくと、どこかで件数が減ったり増えたりする工程が見つかります。その工程によって、疑うところは次のように変わります。
- 元システムにはあるのに、連携後のデータにない：データを取り込むときの条件や、取り込んだ時刻
- 連携後にはあるのに、DWHでの加工後にない：表をつなぐ結合や、対象を絞り込む除外の条件
- DWHでの加工後とBIの表示だけが違う：BIの画面で設定した集計の条件
件数が変わった工程では、差分に入ったレコードを見て、その処理が意図したもの（重複の除外など）かを確かめます。既存レポート側に手作業がある場合は、それも比較対象に入れます。
連携後やDWHでの加工後の件数を自分で出せない場合は、連携やDWHを構築した会社、連携ツールのベンダーに依頼します。
そのときは「この指標について、元システム・連携後・加工後・BI表示の件数を、同じ時点で出してください」と、比べたい時点と工程を指定すると話が早く進みます。
手順3：両方に入る1件・片方だけの1件・空欄の1件を最後まで追う
集計結果から原因を推測したら、明細で確かめます。
既存レポートと新しいBIで同じ期間の明細をIDで突き合わせてください。両方に入るレコード、片方だけのレコード、判定に使う項目が空欄のレコードが分かるようにしましょう。
同じIDを元システムからBIまで追い、各工程で対象に入ったか、どの条件で外れたかを書き出します。集計単位が変わる場合は、集計前の明細まで戻ってください。
そうすることで、どの工程のどの条件で対象から外れたかが分かります。
私が関わった案件では、Salesforceの既存レポートに含まれるレコードが、BigQuery（Googleのデータウェアハウス）で集計する新しいBIには含まれませんでした。対象から外れた明細を見ると、判定に使う項目が空欄でした。そこで、既存レポートと新しいBIのそれぞれで、「〇〇ではない」という否定の条件が空欄のレコードをどう扱っているかを確認しました。
その結果、原因候補が空欄の扱いと分かったのです（仕組みは「DWHの加工で合わない」で説明します）。判明後も、SQLを既存レポートに合わせて直すだけでは終えませんでした。この件では、空欄を除外するBigQuery側の数え方が妥当と判断し、データ定義を修正しました。ただし、別のケースでは既存レポート側の数え方を採用したこともあります。
数字が合わない原因は、工程ごとに確認する場所が違う
差が生まれた工程が見えたら、調べる場所を絞りましょう。
先ほどの図を再掲して説明します。
図の工程に沿って、合わない場所を次の5つに分け、それぞれで最初に確認したい原因を挙げます。
- 入力・計測で合わない
- データ連携で合わない
- DWHの加工で合わない（結合とNULLの扱い）
- BIの集計で合わない
- 業務上の数え方で合わない（KPIの定義）
これらについて、直すかどうかは、原因と期待する数え方を確かめてから決めます。
入力・計測で合わない
入力・計測で合わない場合は、元システムの明細に対象の記録があるか、集計に使う項目が空欄でないかを見るのが先です。過去に記録されなかった行動は、設定を直しても自動では戻りません。
SFAやCRMへの未入力、重複登録、分類の違いがあれば、連携前から対象が合いません。Webの行動なら、計測設定や計測開始日を確認します。
データ連携で合わない
元システムにあるレコードがDWHにないときは、取得対象のテーブル・項目・期間、最後に正常終了した時刻、処理した件数を確認します。既存レポートは昨日まで、新しいBIは一昨日までという更新時点の差なら、同じ時刻にそろえて比べ直します。
取り込みの失敗や再実行漏れ、期間途中の連携仕様の変更も確認します。元システムとDWHの件数は、同じ時点で比べます。
実行の履歴や処理件数は、連携ツールの管理画面で確認できます。自社で見られない場合は、連携を構築した会社やツールのベンダーに、対象期間の実行履歴と処理件数を出してもらいます。
DWHの加工で合わない（結合とNULLの扱い）
DWHの加工で合わない場合は、加工前後の件数と合計を見て、結合できなかったレコードや条件から外れたレコードを確認します。
結合先が複数あってレコードが増える、結合できずに対象から外れる、WHERE条件やマスタ変換（コードを部署名などに置き換える処理）で対象外になる、といった差があります。日付・タイムゾーンや重複削除の扱いも既存レポートと比べます。
値が入っている行だけでなく、空欄の行も追います。というのも、BigQueryでは、NULL（値が入っていない状態）を「=」「!=」などの比較演算子で比べると、結果は真（TRUE）でも偽（FALSE）でもなくNULLになるからです。
SQLで行を絞り込むWHERE句は、判定がTRUEの行だけを残します。そのため「区分が『除外』ではない」という条件だけでは、区分が空欄の行は残らないのです。
| 区分の値 | 既存のSalesforceレポート（当時） | 新しいBIのBigQuery側（条件例） |
|---|---|---|
| 除外 | 入らない（判定はFALSE） | 入らない（判定はFALSE） |
| 対象 | 入る（判定はTRUE） | 入る（判定はTRUE） |
| NULL | 入る（判定はTRUE） | 入らない（判定はNULL） |
※上表は、前章の手順3で紹介した、私が関わった案件を例にしたものです。BigQuery側は「区分が『除外』ではない」という条件の例で、当時のSQLそのものではありません。
加工のSQLを自社で書いていない場合は、DWHを構築した会社に、加工前後の件数と、対象から外れたレコードのIDを出してもらうよう依頼します。
BIの集計で合わない
DWH上の集計とBI表示が異なるなら、画面上の期間、フィルター、計算フィールド（BIの画面上で作った計算式の項目）、表示単位を同じ条件にそろえます。日次と月次、明細の件数と重複を除いた顧客数は、別の数字です。
小数の丸め方も確認します。ダッシュボードの初期設定と、閲覧者やページごとに変更された条件は分けて見ます。
業務上の数え方で合わない（KPIの定義）
業務上の数え方で合わない場合は、既存のスプレッドシートに手作業や例外がないかを作成者に聞き、含める対象・除外する対象・計上日・担当部署を書き出します。その例外が今も必要で、共通のルールとして説明できるかも確かめます。
何を売上や獲得として数えるかは、特定の工程だけでなく、入力から表示までの全てに関わります。受注日と入金日、顧客区分、部署への計上先、コンバージョンの対象が違えば、同じ指標名でも数字は変わります。
BIと既存レポートのどちらが正しいかは、原因を見て決める
数字が違うだけでは、既存レポートと新しいBIのどちらが間違っているかは決められません。差の理由を確認した後で、期待する定義と実際の処理を比べます。
原因が分かったあとの対応は、実装の修正、差を説明した上での定義の採用、業務ルールの見直しに分かれます。
実装が期待と違うなら、BIを直す
実装を直すのは、以下の4つのケースです。
- 期待する定義が決まっているのに取得が漏れた
- 二重に取得・集計した
- 結合や除外条件を誤った
- 意図しないフィルターが入った
このとき、取得対象や更新条件、結合・除外条件、BIの集計式や初期フィルターを確認します。
連携が失敗した場合に備え、通知と再実行の方法も決めます。計測設定を変えるときは、いつから正しく記録できるようになったかを残し、修正後は元と同じ比較条件で数字を確かめます。
連携やDWH、BIを社外の会社に構築してもらった場合は、差が出たIDと比較条件を添えて、その会社に修正を依頼します。
どちらも仕様どおりなら、目的に合う定義を採用して差を残す
空欄の扱い、更新時刻、丸め方などが違っても、どちらも仕様どおりという場合があります。この場合は、既存レポートの数字に似せるためだけに処理を増やす必要はありません。
構築担当は現行の集計条件を業務部門に示し、その数字を何の判断に使うかを確認します。差が出たレコードを例に、数えるべき対象の漏れや、対象外の混入がないかを一緒に確かめます。その上で、採用する定義を合意します。
空欄のレコードを含めるかも、業務部門と合意して決めます。比較に使うデータの更新時点をそろえ、表示単位や更新時刻を画面上に明記します。期間途中で仕様が変わったなら変更日を残し、前後で比較条件を分けます。
過去に存在しない記録は完全には戻せないため、補完できるかどうかと、その期間の扱いも決めます。採用した定義、なお残る差、確認日を記録し、社内で説明できるようにします。
既存レポートの例外が多すぎるなら、業務ルールを見直す
既存レポートの例外をBIへ一つずつ移すと、見た目の数字は近づいても、後から同じ結果を再現するための条件が増え続けます。必要な例外なら条件と管理方法を明文化します。一方、今の業務で必要性を説明できない例外は、移植を前提にせず、業務部門とルール自体を見直します。
私が関わった別の案件では、顧客や案件の獲得数をどの部署へ計上するかについて、既存のスプレッドシートに例外処理が多くありました。新しいBIでその処理を再現し続けても、既存レポートとの完全な一致は難しい状態でした。
そこで、BI側に条件を足す前に、実際の案件を通常の計上ルールに当てはめ、例外として扱う必要があるかを業務部門に繰り返し確認しました。その結果、例外処理を業務ルールからなくす提案が採用され、例外はすべて廃止されました。
このとき優先したのは、過去のスプレッドシートと同じ数字を作ることより、今後も説明できる計上ルールにすることです。技術担当だけで計上先を決めたのではなく、業務部門の判断として数え方を変えました。数字が合わない原因を調べることが、既存のルールを見直すきっかけになった例です。
よくある質問
新しいBIと既存レポートの数字が合わないときに、よくいただく質問をまとめました。どちらの数字に合わせるか、例外をどこまで移すかなど、調査の途中で迷いやすい点を取り上げています。
BIと既存レポートの数字は完全に一致させる必要がありますか
必ずしも必要ではありません。どの判断に使う指標か、差の理由を説明できるか、残る差が判断を変える大きさかで決めます。
ただし、数字が近づいたところで調査を終えるのは避けましょう。理由が分からない差を残すと、次の集計でも同じ調査をやり直すことになります。比較条件、原因、採用した定義、残る差と確認日を、データ定義書（指標ごとに、対象・除外条件・計上日を書いておく資料）に記録しておきます。
どのシステムを正しい数字の基準にすべきですか
システム名だけでは決められません。数字を使う目的、入力を管理する人、更新時刻、同じ条件で再現できるかを確かめ、業務部門と基準を決めます。
新しいBIだけを疑うと、既存レポートに残る手作業や過去の条件を見落とします。元システム、既存レポート、新しいBIの条件を並べ、どちらにどの処理があるかを確かめてから決めましょう。
既存レポートの例外処理は新しいBIでどこまで再現すべきですか
すべてを再現する必要はありません。例外をすべて移すと集計ロジックが複雑になり、変更のたびに数字が合わなくなります。
条件を増やす前に、その例外が今も必要かを業務部門に確かめます。何を成果として数えるかは、その数字で判断する業務部門と合意して決めます。データ基盤担当者が示すのは、差が生じた工程と実装上の制約です。必要な例外は条件を明文化し、不要なら新しいBIへ移しません。
SalesforceのレポートとBigQueryで数字が合わないのはなぜですか
原因は、指標やレポートの作り方によって変わります。この記事の事例のように「〜を含まない」などの除外条件がある場合は、空欄のレコードが両方でどう扱われるかを入念に確認します。そのほか、対象オブジェクトと関連レコードの関係、結合・集計条件、更新時点も見比べ、必要に応じてIDで突き合わせます。
数字が初めて変わる工程を見つければ、原因を特定できる
BIの数字が合わない原因は、入力・連携・DWHの加工・BIの集計・業務上の数え方のどこかにあります。数字が初めて変わる工程を上流から探すと、特定できます。
比較条件をそろえ、数字が変わった工程で対象になった明細を調べましょう。原因が分かったら、BIを直すか、差を説明して残すか、業務ルールを見直すかを決めます。
まずは指標を一つ選び、記録が発生してからBIに表示されるまでの流れを書き出してみてください。
目指すのは既存レポートとの一致だけではありません。なぜ数字が違うのかを社内で説明でき、同じ定義で繰り返し集計できることです。
新しいBIと既存レポートの数字の照合は、月曜日のトラで対応できます
元システム、データ連携、DWHのSQL、BIの設定、業務上の数え方を横断すると、どこから確認すべきか迷うことがあります。月曜日のトラでは、既存レポートと新しいBIの条件を並べ、数字が変わる工程を調べるところから承っています。原因が分かった後の定義の整理や、社内への説明についてもご相談いただけます。
マーケティングデータ基盤構築のご紹介
月曜日のトラでは、指標の定義、データの連携と加工の設計、データ基盤やBIの構築、既存レポートとの照合、運用の引き継ぎまで支援しています。移行の途中で数字が合わなくなった段階からでもご相談いただけます。
関連セミナーアーカイブのご案内
この記事と近いテーマのセミナーを、アーカイブでご覧いただけます。
AI活用を見据えたデータ基盤の現状チェック
（2026年5月21日開催アーカイブ視聴可）
部署やツールごとに分かれたデータを、共通の指標定義でそろえるためのデータ基盤の考え方と、まずどこから整備を始めるかを解説しています。この記事を書いた大竹も登壇しています。
成果が伝わるデータ可視化とLookerStudio
（2026年3月26日開催アーカイブ視聴可）
Looker Studioを使って、成果が伝わるレポートの設計と、継続して共有できる報告の仕組みの作り方を解説しています。新しいBIの数字を上司や経営層に説明するときの参考になります。
※ セミナーアーカイブ視聴にはお申し込みが必要です。メールアドレスをご登録いただくと、動画のURLをお送りします。
関連コラムのご案内
データ基盤をこれから作る段階で、何から手を付けるかを決めたい場合は、次のコラムもあわせてご覧ください。スプレッドシートで続けられる条件と、データ基盤が必要になるタイミングを解説しています。
メールマガジンで最新情報をどうぞ
月に2回、メールマガジンを配信しています。各メンバーによるコラムや書籍紹介、近日開催のセミナー情報、アーカイブ配信のご案内をしております。
お昼休み11:30頃に配信。さっと読めるお手軽メールマガジンです。ご興味がありましたらこちらからご登録下さい。
参考サイト一覧
