Excel と Googleスプレッドシート と BigQuery｜「集計の置き場所」を比較で決める
目次 クリックで開く
ビジネスにおけるデータ活用が進む中で、誰もが直面するのが「どのツールでデータを管理・集計すべきか」という問題です。長年慣れ親しんだExcel、リアルタイム共有に優れたGoogleスプレッドシート、そして圧倒的な処理能力を持つGoogle CloudのBigQuery。これらは競合するツールではなく、本来はデータ量、更新頻度、利用目的に応じて使い分けるべき「層」の異なるソリューションです。
本記事では、IT実務者の視点から、これら3つのツールの性能限界を数値で示し、業務プロセスを停滞させないための最適なアーキテクチャを具体的に解説します。
Excel・スプレッドシート・BigQueryの根本的な役割と違い
まずは、それぞれのツールがどのような思想で設計されているかを理解しましょう。ここを誤ると、数万行のデータに対してExcelでVLOOKUPを連発してフリーズさせたり、逆に100行程度のリストをBigQueryで管理して運用を複雑にしたりといった「道具のミスマッチ」が起こります。
各ツールの得意領域と「限界値」の定義
- Excel: 「パーソナルな計算機・レポート作成」。ローカルPCのメモリをフル活用するため、複雑な計算や細かな書式設定が可能です。ただし、ファイル共有による「先祖返り」や、数万行を超えたあたりからの動作遅延が課題となります。
- Googleスプレッドシート: 「チームの共同作業台」。ブラウザ上で複数人が同時に書き込み、外部のSaaSとAPI連携することに長けています。しかし、スプレッドシートには「全シート合計で1,000万セル」という明確な上限が存在し、これを超えると動作が著しく不安定になります。
- BigQuery: 「データの中央倉庫（DWH）」。数億行、数テラバイトのデータであっても数秒で集計する怪物級の性能を持ちます。UIとしての柔軟性はありませんが、データの整合性を守り、高速に結果を返すことに特化しています。
比較表：機能・容量・コスト・スキルセット
実務で判断するための比較表を以下にまとめます。
| 比較項目 | Excel | Googleスプレッドシート | BigQuery |
|---|---|---|---|
| 最大容量（行数） | 1,048,576行 | 1,000万セル（全シート計） | 実質無制限（ペタバイト級可） |
| 計算速度 | PCスペックに依存（重いと停止） | ネットワークとGoogle側に依存 | 分散処理により極めて高速 |
| 共同編集 | △（SharePoint等が必要） | ◎（リアルタイムで快適） | ◎（権限管理されたSQL実行） | △（Power Queryによる接続） | ◎（GASやアドオンが豊富） | ◎（ETLツールやコネクタが充実） |
| コスト | ライセンス料（Microsoft 365） | 基本無料（Google Workspace） | 従量課金（ストレージ+クエリ） |
| 必要スキル | 関数、ピボットテーブル | 関数、GAS（JavaScript） | SQL、データパイプライン設計 |
Excelを選択すべきケース：個人完結の高度なシミュレーション
Excelが最も輝くのは、「非定型かつ複雑な計算を試行錯誤しながら行う」シーンです。例えば、新規事業の損益シミュレーションや、複雑な条件分岐が絡む原価計算などが該当します。
強力なオフライン計算能力とUIの柔軟性
Excelはローカルマシンのリソースを使用するため、ネットワークの遅延に左右されません。セルの色付け、罫線、条件付き書式などを駆使して「そのまま会議資料として使える」レベルまで作り込む自由度は、他の2ツールを圧倒しています。また、「Power Query」機能を活用することで、ローカルにある複数のCSVファイルを結合・整形する処理も、エンジニアの手を借りずに完結できます。
Excelで運用し続ける場合の「データ構造」の作法
Excelでの集計が破綻する原因の多くは、「入力、計算、出力」が1つのシートに混在していることです。これを防ぐには、以下の原則を徹底する必要があります。
- Rawデータシート: 関数や書式を一切入れない、純粋なデータのみを置く。
- Masterシート: VLOOKUP等で参照するマスタ情報を管理する。
- Reportシート: ピボットテーブルやグラフを用いて可視化する。
もし、このExcel運用が社内各所で乱立し、データの整合性が取れなくなっている場合は、次のステップであるスプレッドシートや、業務アプリ化を検討すべきタイミングです。特に現場のDX推進については、Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイドで詳しく解説しています。
Googleスプレッドシートを選択すべきケース：チーム共有とAPI連携のハブ
Googleスプレッドシートの真価は、クラウドネイティブであることによる「連携性」にあります。
同時編集と「Google Apps Script(GAS)」による拡張性
複数人がバラバラにExcelファイルを更新し、メールで送り合う不毛な作業は、スプレッドシートで解消されます。さらに、GAS（Google Apps Script）を用いることで、外部のWeb APIからデータを取得したり、特定の条件でSlackに通知を飛ばしたりといった自動化が容易です。
スプレッドシートが重くなる原因と回避策
多くの現場で「スプレッドシートが開かない、重い」という悲鳴が上がります。主な原因は以下の通りです。
- IMPORTRANGEの多用: 外部ファイルからデータを引っ張る関数が多すぎると、再計算ループに陥ります。
- 過度な条件付き書式: 全セルを常にスキャンするため、描画負荷が激増します。
- 1,000万セルの限界: データの蓄積がこの閾値に近づくと、関数一つ動かすのにも数秒待たされるようになります。
これらの事象が発生し始めたら、それは「スプレッドシートを集計用データベースとして使うのは限界である」という明確なサインです。
BigQueryを選択すべきケース：100万行を超えるデータの「中央集権化」
データ量が100万行を超えたり、複数のシステム（広告、CRM、会計）を横断して集計したりする必要がある場合、BigQueryが最強の選択肢となります。
サーバーレスDWHがもたらす圧倒的な集計速度
BigQueryはGoogleのインフラ上で動作する分散型データベースです。最大の特徴は、インフラの構築が不要（サーバーレス）であり、SQL（Structured Query Language）を投げるだけで、数億行のデータでも瞬時に処理できる点にあります。
10年分のログを数秒で検索するスケーラビリティ
例えば、過去10年分の広告クリックログや、全店舗の数年分の購買データを「昨日の売上と比較したい」といったオーダーに対し、スプレッドシートならフリーズしますが、BigQueryなら数秒で結果を返します。これにより、意思決定のスピードが飛躍的に向上します。
特に広告運用やCRMの文脈では、BigQueryにデータを集約することで、機械学習を用いた高度な最適化が可能になります。詳細は広告×AIの真価を引き出す。CAPIとBigQueryで構築する「自動最適化」データアーキテクチャをご参照ください。
実務での使い分け判断基準：5つのチェックリスト
どのツールを使うべきか迷った際は、以下の5項目をチェックしてください。
- 行数は100万行を超えるか？
→ YESならBigQuery一択。10万行〜100万行ならスプレッドシートは危険、Excelなら工夫が必要。 - 同時編集をするか？
→ YESならスプレッドシート。権限管理を厳密にするならBigQuery。 - 「誰が」そのデータをいじるか？
→ 非エンジニアが自由に関数を使いたいならスプレッドシート/Excel。エンジニアが品質を保証するならBigQuery。 - データソースは何か？
→ Webログ、SaaSのAPIなど自動連携が主ならBigQueryまたはスプレッドシート。手入力が主ならExcel。 - データの鮮度は？
→ リアルタイム性を求めるならスプレッドシート。日次・時間次のバッチ処理で良いならBigQuery。
理想的なアーキテクチャ：3つのツールを「組み合わせる」運用
実務においては「どれか一つ」に絞る必要はありません。むしろ、これらを組み合わせて「データの川」を作るのが最も賢明です。
スプレッドシートをBigQueryの「入力画面」にする
BigQueryは強力ですが、手入力には向きません。そこで、現場の人間が入力する「マスタ情報」や「予算値」はスプレッドシートで管理し、それをBigQueryから「外部テーブル」として直接参照する構成を取ります。これにより、エンジニアがデータを投入する手間が省けます。
BigQueryの結果をExcelで「清書」するコネクテッドシート活用
BigQueryで集計した数億行の結果（例えば月別のサマリ）を、Googleスプレッドシートの「コネクテッドシート」機能やExcelの「データ接続」機能で呼び出します。膨大な計算はBigQuery側で済ませ、人間が見る最後の数行だけをシートに表示させることで、動作の軽快さと見栄えを両立できます。
SaaSデータを自動集約するパイプラインの構築
例えば、freee会計の仕訳データやSalesforceの商談データをBigQueryに集約すれば、SaaSを跨いだ予実管理が自動化されます。こうしたモダンなデータ基盤については、高額なCDPは不要？BigQuery・dbt・リバースETLで構築する「モダンデータスタック」ツール選定と公式事例で具体的なツール選定に触れています。
移行手順：スプレッドシートからBigQueryへステップアップする
現在スプレッドシートで運用している集計をBigQueryへ移行する際の手順を解説します。
STEP 1：データの正規化とクリーニング
BigQueryはデータベースであるため、Excelのような「セルの結合」や「中見出し」を許容しません。
- 1行目は必ず「カラム名（英数字推奨）」にする。
- 1つの列には1つのデータ型（数値なら数値のみ）を入れる。
- 空行や合計行は削除する。
STEP 2：外部データソース機能による簡易連携
Google Cloudコンソールから以下の手順で連携します。
- BigQueryのデータセットを作成。
- 「テーブルを作成」を選択し、ソースに「ドライブ（Google Drive）」を選択。
- スプレッドシートのURLを貼り付け、ファイル形式を「Googleスプレッドシート」にする。
- 「スキーマを自動検出」にチェックを入れ作成。
これで、スプレッドシートを更新するたびにBigQuery側のデータも（クエリ実行時に）最新化されます。
STEP 3：定期実行クエリによる自動集計の設定
外部参照は便利ですが、データ量が増えるとクエリが遅くなります。最終的には、スプレッドシートからBigQueryのネイティブテーブルへ定期的にデータをコピーし、SQLで集計結果を作成する「定期実行クエリ（Scheduled Queries）」を設定します。
よくあるエラーと対処
- Error: Schema mismatch: スプレッドシート側で列を挿入したり、数値列に文字列を混ぜたりすると発生します。入力規制をかけてデータ整合性を守る必要があります。
- Error: Access Denied: BigQueryのサービスアカウントにスプレッドシートの閲覧権限がない場合に発生します。スプレッドシートの共有ボタンから、サービスアカウントのメールアドレスを追加してください。
まとめ：集計の置き場所が「事業の速度」を決める
Excel、Googleスプレッドシート、BigQueryはどれが優れているというわけではなく、「どのフェーズでどのツールを使うか」という設計思想の問題です。
- アイデアを形にし、高度なシミュレーションをするならExcel。
- チームで情報共有し、外部サービスと素早く繋ぐならスプレッドシート。
- 膨大なデータを安全・高速に、かつ構造的に蓄積するならBigQuery。
データが重くなり、誰かが「待ち時間」を強いられているなら、それは配置を変えるべき合図です。ツールの限界を正しく見極め、常に最適なパフォーマンスを発揮できる環境を構築しましょう。
参考リンク（公式サイト）:
組織導入を成功させる「データ統制とコスト」の補足知識
各ツールの機能差を理解した上で、実務上の最終的な判断基準となるのが「データの統制（ガバナンス）」と「目に見えない運用コスト」です。特に複数部署が関わるプロジェクトでは、単なる計算速度以上に、データの「正しさ」をどう担保するかが重要になります。
データ品質を支える「権限管理と変更履歴」の比較
Excelやスプレッドシートは、誰でも自由にセルを書き換えられる柔軟性がメリットですが、一方で「誰がいつ、どの計算式を書き換えたか」を追跡しきれず、数値の整合性が崩れるリスク（いわゆるデータの属人化）を抱えています。BigQueryを基盤に据えることで、これらの中央制御が可能になります。
| 統制項目 | Excel / スプレッドシート | BigQuery |
|---|---|---|
| 誤操作の防止 | 低い（行削除や計算式の誤上書きが容易） | 高い（権限分離により閲覧専用設定が可能） |
| 変更履歴の透明性 | 困難（版管理がファイル単位になりがち） | 容易（クエリログにより実行履歴が自動記録） |
| 列・行単位の制御 | △（シート保護機能はあるが限定的） | ◎（特定の列のみ閲覧不可にする等の設定可） |
BigQueryのコストに関する「よくある誤解」
「BigQueryはエンタープライズ向けで高価」というイメージがありますが、実際には小規模な分析であれば、スプレッドシートの有料アドオンを契約するよりも安価に収まるケースが多々あります。
- 無料枠（無料階層）の活用: Google Cloudは、毎月1TBまでのクエリ処理、および10GBまでのストレージを無料枠として提供しています（※2026年4月時点の仕様。詳細はBigQueryの料金（公式）を要確認）。
- ストレージ料金の自動最適化: 90日間更新がないテーブルは「長期保存」とみなされ、ストレージ料金が自動的に約半分に適用される仕組みがあります。
高額なツールを導入する前に、既存のGoogle環境を活かしてどこまで自動化できるかについては、【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』のセクションもあわせて確認しておくと、無駄な投資を抑えることができます。
移行・運用開始前のチェックリスト
スプレッドシートからBigQueryへ、あるいはExcelからクラウドへ「置き場所」を変える際は、以下の3点を確認してください。
- データのバックアップ: BigQueryの「タイムトラベル機能（過去7日間のデータ復元）」で十分か、あるいは長期のバックアップが必要か。
- SQL担当者の有無: 複雑な加工が必要な場合、基本的なSELECT文を記述できるメンバーがチームに1名は必要です。
- 元データの整合性: 参照元のスプレッドシートで「列名の変更」や「データ型の混在（数値列にテキストを入れる等）」が起きないルールがあるか。
もし、データの収集から活用までの全体最適化を目指すのであれば、モダンデータスタックのツール選定事例などを参考に、自社のフェーズに合った構成を検討してみてください。
ご相談・お問い合わせ
本記事の内容を自社の状況に当てはめたい場合や、導入・運用の設計を一緒に整理したい場合は、当社までお気軽にご相談ください。担当より折り返しご連絡いたします。