ExcelからBIへの移管プロジェクトで、数値のズレが起こる13の理由と対応策

はじめに

Excelではデータの処理が大変になり、PowerBIやTableauなどのBIツールを導入した企業でよく起こるのが、「（既存の）エクセルとBIで出てくる数値が違う」という問題です。

「エクセルではこうだったのに」「BIの数値が間違っているのでは」といった指摘を受けることは、支援会社としても少なくありません。

しかし、多くのケースでは、数値のズレはツールの不具合ではなく、前提条件や集計ロジック、データ仕様の違いによって生じていることが多いです。

本記事では、エクセルとBIで数値が合わない理由について、業務的・技術的・システム的な観点から網羅的に整理し、原因の見極めと適切な対策をわかりやすく解説します。

業務的な要因

1. エクセルでの手作業による補正・加工

現場で使用されるエクセルファイルは、担当者の判断により以下のような加工が加えられていることがあります。

• 一部のデータ行や顧客を手動で除外

• 数値の丸めや調整

• 条件付きでの個別補正や非表示処理

こうした処理が明示されないままBIと比較されると、当然ながら数値に差が出ます。

担当者やこの作業に関連していた人がこの手作業を認識していない場合や明示されていない場合も存在し、その場合は解決をするのがさらに困難になるケースもあります。

2. 集計条件やフィルタの前提の違い

BIとエクセルで比較される際、以下のように対象条件が揃っていないことがあります。

• エクセルは直近3か月、BIは全期間

• エクセルは特定の部門のみ、BIは全社データ

• エクセルにはフィルタが適用されているがBIは全件表示

前提条件が異なれば、出てくる数値は異なって当然です。

3. KPIや用語定義の不統一

「売上」「契約数」「新規顧客」など、同じ名称の指標でも部門や担当者によって定義が異なる場合があります。

• 売上：税込／税抜、出荷ベース／入金ベースなど

• 新規顧客：初回受注／初回問合せ／初回ログインなど

定義が揃っていないと、BIでの数値が「違う」と見なされやすくなります。

4. 粒度の違い（明細とサマリ、日次と月次）

集計単位の違いもズレの原因になります。

• エクセルは月次のカテゴリ別集計

• BIは日次の個別商品別集計

粒度が異なると合算や平均などで差異が出るため、比較する際は単位を揃える必要があります。

5. エクセルは加工済み、BIは生データ

エクセルとBIツールの数値が合わない原因の一つに、扱っているデータの「状態の違い」があります。

具体的には、エクセルで使用されているデータは現場で事前に加工・整形・除外処理がされた“完成形”のデータであることが多いのに対し、BIではデータベースやシステムから直接取り込んだ“生データ（未加工データ）”をそのまま集計しているケースが大半です。

この違いが、「同じはずの集計」で結果が異なる原因となります。

こうした処理は、エクセル上では「慣習的に」「個人の判断で」行われていることが多く、加工のロジックや判断基準が明文化されていないこともしばしばあります。

一方、BIはそれらを自動で再現する設計がされていない限り、全件の生データをロジック通りに集計します。

結果として、“正確なはずのBI”の数値が、“人間が整えたエクセル”と合わないという現象が起こります。

つまり、同じ業務のはずでも、「どの状態のデータを基準にしているか」が違えば、数値が合わないのは当然とも言えます。

技術的な要因

6. 浮動小数点誤差（2進数の仕様）

コンピュータは数値を内部的に2進数で処理しています。しかし、人間が日常的に使う10進数の中には、2進数では正確に表現できない値があります。代表的な例が「0.1」や「0.2」といった小数です。

0.1という値は、2進数では「0.000110011001100110011…」と無限に続く小数になります。

コンピュータはこの無限小数をすべて保持することができないため、一定の桁数で切り捨て（または丸め）て近似的に保存します。この処理方法が「浮動小数点表現」であり、ほんのわずかな誤差が蓄積される仕組みになっています。

たとえば、以下のような計算を考えてみましょう。

実際には、コンピュータ内部では以下のように計算されている場合があります。

この誤差は小数点以下16桁目以降に現れるほど微細なものですが、BIツールやデータベースでは内部の正確な数値をそのまま表示する設計となっていることが多く、「エクセルと数値が微妙に違う」「合計値が合わない」と感じられる原因になります。

エクセルではこのような誤差が画面上で自動的に丸められたり、表示桁数が制限されたりしており、ユーザーが誤差に気づかないこともあります。しかしBIツールでは、たとえばグラフのツールチップやKPIカードの数値などに誤差を含んだ数値が表示されることもあるため、現場で「不一致」として問題視されるケースがあります。

この浮動小数点誤差は、金額計算や平均値・比率など小数点以下の精度が重要な業務領域において、特に注意が必要です。

誤差を完全に防ぐことはできませんが、以下のような対処で影響を抑えることが可能です。

• BIツール側でROUND関数やFORMAT関数を用いて表示を制御する

• 金額や比率の計算には表示桁数の明示的な設定を行う

• 必要に応じて**decimal型（固定小数点）**の使用を検討する（データベース側）

このような仕様による誤差は「バグ」ではなく、あくまでコンピュータの設計上避けられない仕様であることを理解し、設計段階から意識しておくことが大切です。

7. 丸め処理（四捨五入）のルールの違い

エクセルとBIツールでは、同じ小数点以下の桁数で丸め処理（四捨五入など）をしているように見えても、採用しているルールが異なることで、結果に差が出ることがあります。

エクセルでは一般的に「四捨五入（round half up）」が使われており、これは小数点以下の端数が「5」の場合に、常に切り上げるルールです。

たとえば：

これに対して、BIツール（あるいは一部のプログラミング言語やデータベース）では「銀行丸め（round half to even）」と呼ばれるルールが使われていることがあります。

銀行丸めは、小数点以下がちょうど「5」の場合に、その前の数字が偶数なら切り捨て、奇数なら切り上げるという方式です。

これは大量のデータを集計する際に、切り上げ・切り捨ての偏りをなくすための方法です。

具体例：

このルールの違いは、1件ずつの差は小さいものの、大量の取引データや売上明細を集計した場合に、最終的な合計値や平均値に影響を及ぼすことがあります。

さらに、BIツール側では明示的に丸め処理を設定しない限り、内部的には丸められていない状態で表示されることもあり、エクセルの“見た目の値”と一致しない原因になります。

この違いが生じやすい場面としては、以下のようなケースが挙げられます。

• 小数を扱う単価や金額の計算（例：税抜金額、割引後単価）

• 平均値の算出（例：顧客単価の平均）

• BI上でのKPI表示やダッシュボードの数値表示

丸めルールの違いによる不一致を防ぐためには、次のような対策が有効です。

• BI側で使用する丸め処理（ROUND、ROUNDUP、ROUNDDOWNなど）を業務で使われているルールと統一する

• 数値表示フォーマットをあらかじめ定義・設定しておく

• 丸め処理のタイミング（計算前／計算後）を関係者間で明確にする

• KPI定義書などで丸めルールも含めて記述する

このように、丸め処理は小さな違いのように見えても、実務では集計値の信頼性や、関係者間の認識統一に直結する重要な要素です。

見た目の数値だけで判断せず、その背後にある計算ロジックまで確認する姿勢が、精度の高いBI運用に不可欠です。

8. NULL値や空白セルの扱いの違い

エクセルでは空白セルを無視する関数が多く使用されますが、BIではNULL値として集計処理され、平均や件数に影響を及ぼすことがあります。

9. 数値型と文字列型の違い

データベースやBI上で「1000」のような値が、見た目は数値でも実際は文字列として扱われている場合があります。その結果、集計対象外となってしまうことがあります。

10. 表示フォーマットと内部値の差異

エクセルとBIで数値が合わない原因の一つに、「表示フォーマットと内部値の違い」があります。これは、表示されている見た目の数値と、コンピュータが保持している実際の数値が一致していないことによって生じます。

エクセルでは、セルの表示形式として「小数点以下第2位まで」「通貨形式」「桁区切りあり」などを設定することができます。これにより、画面上に表示される数値は丸められたり、桁が制限されたりして見やすく整えられています。

たとえば、内部的に「0.2958」という値が入力されていたとしても、セルの書式設定が「小数点第2位まで」になっていれば、表示上は「0.30」と見えることになります。

一方で、BIツールでは、表示フォーマットの指定が明示的に行われない限り、内部に保持されている実数値そのものがそのまま画面に表示されることがあります。つまり、エクセルで「0.30」と見えていたものが、BI上では「0.2958」と表示され、「数値が合っていない」と受け取られるケースが生じます。

このようなズレは、「浮動小数点誤差」と混同されがちですが、根本的には異なります。

浮動小数点誤差は計算精度に関するものであり、数値そのものに誤差が含まれている現象です。一方、「表示フォーマットと内部値の差異」は、数値は正しいにもかかわらず、“見せ方”が異なることによって違って見えるだけの問題です。

特に、以下のような場面でズレが顕在化しやすくなります。

• BI画面上でKPIや合計値を表示する際、桁数制限がされていない

• エクセルから数値をコピー＆ペーストしたが、見た目と内部値が異なっていた

• エクセル上で関数による丸め（ROUND関数など）が行われていなかった

こうしたケースでは、「数値が違う」と感じても、本質的には“計算ミス”でも“データ不備”でもなく、表示の整え方が違うだけということが多くあります。

このズレを防ぐためには、次のような対策が有効です。

• BIツール側で、小数点以下の表示桁数を業務ルールに沿って統一する

• 表示用と計算用の項目を分ける（例：KPIは四捨五入して表示、内部集計は精密値を使用）

• エクセルでもROUND関数を活用し、表示と内部値の乖離を減らす

• 比較の際は、「見た目の値」か「内部の実数値」かを明確に意識する

表示フォーマットと内部値の差異は、見た目の安心感と計算の正確性のバランスが問われる問題です。

業務上は「0.30」と見せることで十分な場面もあれば、正確な「0.2958」を活用すべき分析もあります。目的と用途に応じて、見た目の整形とデータ精度の両立を意識することが、BI活用の成熟度を高める一歩になります。

システム・運用面の要因

11. データソースや更新タイミングの差

エクセルは過去にダウンロードされたCSVやExcelファイルを元にしていることが多く、BIはリアルタイムまたは日次で更新されたデータを参照しています。

同じように見えても、元のデータが異なれば数値に差が出るのは当然です。

12. ログインユーザーごとのアクセス制御（RLS）

BIツールでは、ログインユーザーによって閲覧可能なデータ範囲を制限する「行レベルセキュリティ（Row Level Security）」が設定されている場合があります。

これにより、同じレポートでもユーザーごとに表示される数値が異なる可能性があります。

13. エクセルの定義・ロジックが明文化されていない

お客様側が提示するエクセルは、最終出力表のみで、その数値をどう導出したかのロジックや処理手順が共有されていないことがあります。

BIで同じ数値を出すためには、元データからどのような加工・計算がなされたのかを明らかにする必要があります。

ExcelからBIの移管に伴い、必然的に発生する作業

(1)業務プロセス自体の見直し

Excelで手作業でやっていた処理などを、BIに移行する際に、廃止したり、変更したり、自動化したりするケースが出てきます。

その場合、これまでやっていた作業を妥協するのか、改良するのか、それともそもそも無意味だから廃止するのか、という難しい意志決定が必要になります。

これは、一種のBPRであり、単なるツールを変更するだけの問題ではありません。大きな意志決定なので、それによって影響を受ける関係者を集めて、問題のすりあわせをしないといけません。当社のような支援会社がこのような部分を支援することもあります。

(2)暗黙的作業のドキュメント化と処理

「担当者が手作業で行っていた業務」や「野良マクロ/野良関数式でやっていた業務」をいったん、ドキュメント化します。その上で、それをBIツールにどう移行するのかを決定します。

ここでも、そのまま移行するのではなく、移行の際に仕様を妥協したり、仕様の一部を廃止したり、仕様を改良したり、別のやり方で同じ事をするようにしたり、ということを決め、落とし所のコンセンサスを取る必要があります。

(3)Excel外作業の洗い出し

「Excel → BI」の作業に影響する、Excel外のデータ処理などの業務を洗い出し、リスト化し、それも、仕様の妥協・廃止・変更・改良の方針を決め、落とし所のコンセンサスを作ります。

(4)BIでは対応できない処理の対応

諦めるのか、BIで対応できるような代替手段にするのか、それも決定する必要があります。

(5)Excel/手作業とBIの仕様の違いで、データの見え方に違いが出るケースの対応

違いが出たら、その違いを受け入れるのか、その違いが出ないように何かの工夫を作り込むのか、その方針を決めるフローを作っておく必要があります。

(6)上記には、大きな工数と決裁権が必要

それをどの部署の誰が負担し、誰が決裁するのかを、事前に決めておく必要があります。

(7)データの表示がExcelのときと違っていて困ったときのチェックリストとエスカレーションスキームを決定しておく

まずは、そのチェックリストに従って問題を切り分け、その問題が担当者で対応できないなら、それを順に上に上げていくフローを作って、現場の方々とそのフローのコンセンサスを作っておきます。

まとめ

上記は理由や解決策の一例です。

エクセルとBIツールで数値が一致しないという課題は、多くの企業で直面する問題ですが、その背景には単純な集計ミスやツールの不具合ではなく、「前提条件の違い」や「表示の仕様」、「データの粒度や型の違い」など、さまざまな業務的・技術的・システム的な要因が複雑に絡み合っています。

特に、エクセルでは人の判断や手作業が加わった加工済みの数値が基準となっている一方で、BIでは定義に基づいた生データの自動処理が行われており、その差が「ズレ」として現れることは少なくありません。

このような違いを理解しないまま、単に「数値が違う」と判断してしまうと、原因の特定や修正に多くの時間と労力を要するだけでなく、プロジェクトの信頼性にも影響を与えかねません。

重要なのは、数値を比較する際に、どの定義・条件・処理ステップで集計されたものかを丁寧に確認し、関係者間で共通認識を持つことです。支援会社とクライアントの双方が、立場を超えて「どの数値を業務上の正」とするのかを対話しながら決めていくことで、BI導入の価値を最大限に引き出すことができます。

ツールの正しさだけでなく、業務理解と協働があってこそ、データの可視化と意思決定の精度は高まります。数値の不一致はそのプロセスを見直すきっかけととらえ、より良い運用設計につなげていくことが大切です。