「Excel に AI が入ったから、分析ツールは要らないのでは」。最近、そんな相談をよく受けます。表計算ソフトに組み込まれた AI は、自然な日本語で「地域別の売上を出して」と頼むだけで集計表やグラフを返してくれます。一方で、BI ツール（ビジネスインテリジェンスツール＝社内のデータを集めて集計・可視化する専用ソフト）やデータ処理基盤を使った受注開発の引き合いも、同じくらい増えています。
両者は「どちらが高性能か」で並べても結論が出ません。決め手になるのは、同じ問いに同じ答えが返るか（再現性）、そしてその数字を誰が責任を持って社外に出せるかです。この記事では、集計・グラフ・再現性の三つの軸で比較し、実装で詰まりやすい箇所と、受注開発に出すならどこから切り出すかを整理します。
二つの道具は「どこに処理を置くか」が違う
まず前提をそろえます。
表計算に組み込まれた AIは、Microsoft 365 の Copilot や Google スプレッドシートの AI 機能のように、シートの中身を読み取って数式を提案したり、集計表やグラフを生成したりするものです。処理の出発点は「いま開いているシート」であり、結果もシートの上に置かれます。
専用の分析ツールは、BI ツールや SQL（データベースに問い合わせるための言語）、あるいは Python などのスクリプトを使い、データベースや基幹システムから直接データを取り出して集計します。集計のルールは定義ファイルやクエリとして保存され、毎回同じ手順が走ります。
違いを一言でまとめると、前者は「人が都度お願いする」仕組み、後者は「あらかじめ定義したものが毎回走る」仕組みです。この差が、後述する再現性の差として現れます。
集計・グラフ・再現性で比べる
| 観点 | 表計算に組み込まれた AI | 専用の分析ツール |
|---|---|---|
| 集計の作りやすさ | 日本語で頼めば数式や集計表が出る。手元のデータならすぐ着手できる | データの取り込み設計が先に必要。初期の手間は大きい |
| 扱えるデータ量 | シートの行数上限や動作速度に制約。数十万行を超えると扱いづらい | データベース側で処理するため、量が増えても設計次第で耐えられる |
| グラフ | その場で作れる。見た目の調整は手作業になりがち | ダッシュボードとして固定でき、毎回同じ体裁で出る |
| 集計ルールの所在 | 会話の文面とシート上の数式。人が消せば消える | クエリや定義ファイル。変更履歴を残せる |
| 再現性 | 同じ依頼でも出力が揺れることがある | 定義を変えない限り同じ結果 |
| 更新の手間 | 毎月、人が同じ作業を繰り返す | スケジュール実行で自動更新できる |
| 向く用途 | その場限りの確認、仮説出し、少量データの加工 | 定例レポート、社外提出資料、複数部署での共有 |
この表を見て「分析ツールが優れている」と読むのは早計です。表計算 AI の強みは、準備ゼロで試せることにあります。「この数字、地域別に割ってみたらどうなるだろう」という思いつきを 1 分で確かめられる道具は、分析ツールにはない価値です。問題は、その場限りのはずの集計がいつの間にか定例業務になり、月次報告の根拠になってしまうことです。
再現性が崩れるのはどこか
再現性とは、同じデータに同じ問いを投げたら、いつ誰がやっても同じ答えが返ることです。業務システムとしては最低条件に近いのですが、表計算 AI では次の理由で崩れます。
- 出力の揺れ：大規模言語モデル（LLM＝大量の文章から学習して言葉を生成する AI）は、同じ指示でも毎回まったく同じ文言・同じ数式を返すとは限りません。「売上」を税抜で取るか税込で取るかといった解釈が、依頼の仕方で変わることがあります。
- 依頼文が残らない：どう頼んだかの履歴がシートに残らないため、半年後に「この数字はどう出したのか」を追えません。結果だけが残り、手順が消えます。
- 列の増減に弱い：元データに列が 1 本増えただけで、範囲指定が狂います。AI が生成した数式は、人が意図を理解していないぶん、壊れたことに気づきにくい。
- 担当者に依存する：依頼のうまい人とそうでない人で、出てくる表の精度が変わります。異動や退職でノウハウごと消えます。
この「動いたように見えて業務では崩れる」構造は、チャット画面で試した AI を本番に載せるときの失敗と同じ形をしています。詳しくはチャットで動いたAIが業務で崩れる理由でも整理しています。
どちらを選ぶかは「その数字の行き先」で決まる
判断軸はシンプルで、出した数字が誰の目に触れ、間違ったときに何が起きるかです。
表計算 AI で十分な場面
- 自分または同じチーム内だけで見る、検討途中の数字
- データ量が数千〜数万行程度で、手元のファイルで完結する
- 集計の切り口が毎回変わり、定型化できない
- 間違えても、気づいた時点で直せば実害がない
専用ツール・受注開発を検討する場面
- 取引先、金融機関、監査など社外に出る数字を含む
- 毎月・毎週、同じ形のレポートを繰り返し作っている
- 複数のシステム（販売管理、会計、勤怠など）をまたいで集計する必要がある
- 担当者が替わっても同じ数字が出ることを保証したい
- 個人情報や取引先情報を含み、誰がどのデータにアクセスできるかを制御したい
最後の項目は軽視されがちですが重要です。個人情報を含むデータを外部の AI サービスに渡す場合、個人情報保護法上の取り扱いや、委託先の管理をどう整理するかという論点が出ます。表計算 AI は使う側の判断で何でも貼り付けられてしまうため、ルールではなく仕組みで止める設計が要ります。この点はAIに渡せない入力を止める手順で扱っています。
実装で詰まりやすい四つの箇所
分析の仕組みを受注開発として作る場合、見積もり前に確認しておくと後戻りが減る箇所があります。
1. 用語の定義が社内で揃っていない
「売上」が受注ベースか出荷ベースか計上ベースか、「稼働率」の分母は何か。この合意がないまま作ると、完成後に「数字が違う」という指摘が出ます。実装よりも、定義を文書に落とす工程に時間がかかることが珍しくありません。
2. 元データが分析に耐えない
たとえば次のような場面です。取引先名が「株式会社○○」「（株）○○」「○○」と三通りで入力されており、そのまま集計すると三社に分かれてしまう。こうした名寄せや表記ゆれの処理は、AI に任せれば一発というものではなく、ルールを決めて例外を人が確認する工程が要ります。
3. 自然文での問い合わせを入れるかどうか
「先月の A 支店の粗利は」と日本語で尋ねると集計を返す、という機能は魅力的ですが、ここで出る数字も社外に出すなら検証が必要です。実務では、定型レポートは固定のクエリ、探索的な質問だけ自然文と役割を分け、自然文側の回答には「この数字は参考値」と明示する設計が現実的です。
4. 検証の方法を決めていない
AI が絡む集計機能は「なんとなく合っている気がする」で検収を迎えがちです。代表的な問いを数十件リストにし、人が手計算した正解と突き合わせる仕組みを作っておくと、モデルや設定を変えたときの影響をすぐ確認できます。考え方は評価データセットの作り方と運用にまとめています。
段階的に移すのが現実的
いきなり全社の分析基盤を作る必要はありません。多くの中小企業では、次の順で移していくのが無理のない進め方です。
- 棚卸し：いま表計算で作っている定例資料を一覧にし、作成頻度・所要時間・提出先を書き出す
- 仕分け：社外に出るもの、毎月作るもの、複数システムをまたぐものに印を付ける
- 固定化：印が付いたものだけ、集計ルールを文書にして自動化の対象にする
- 残す：その場限りの検討は表計算 AI のまま残す。全部を仕組みにしない
「全部を分析ツールに寄せる」も「全部を表計算 AI で済ませる」も、どちらも運用で苦しくなります。定型は固め、探索は自由にという切り分けを先に決めることが、結果的に開発費も保守費も抑えます。
まとめ
表計算に組み込まれた AI と専用の分析ツールは、競合する製品ではなく、役割の違う道具です。選ぶときに見るべきは機能の多さではなく、次の三点です。
- 集計：データ量と切り口の固定度。毎回同じ切り口なら定義として保存すべき
- グラフ：その場で見るのか、毎回同じ体裁で配るのか
- 再現性：半年後に「この数字はどう出したか」を説明できるか
社外に出る数字、繰り返し作る資料、複数システムをまたぐ集計。この三つに当てはまるものから順に仕組み側へ移し、それ以外は表計算 AI の手軽さを活かす。この線引きができていれば、どちらを選んでも大きく外しません。逆に、線引きのないまま「AI が付いたから大丈夫」と進めると、数字の根拠を誰も説明できない状態が静かに広がります。まずは手元の定例資料を一覧にするところから始めてみてください。