中小企業のデータ分析基盤：BigQueryとLooker Studioで小さく始める

データ分析基盤は、見たいグラフやツールからではなく、何の判断に使う数字か、誰がどの頻度で確認するかを決めることから始めます。たとえば「月次の会議で顧客別の粗利を見て、値引きの方針を決める」のように、判断・利用者・指標・確認の頻度を一文で書けると、集めるデータと必要な更新の頻度を絞れます。

業務システム、会計ソフト、営業管理のSaaS、担当者の表計算などにデータが分かれ、月次の集計を手作業に頼っている場合は、最初の1テーマを選び、そのテーマで使う指標から整えます。売上・粗利、問い合わせから受注までの件数、採用や問い合わせ対応の状況などがよく選ばれるテーマです。指標の数や画面の枚数に決まった正解はなく、判断に必要な指標を、利用者と業務に合わせて絞ります。

「売上」「粗利」のような指標は、受注・請求・入金・会計上の計上のどれを基準にするか、税や取消をどう扱うかで値が変わります。定義は分析の担当者だけで決めず、その数字を使う業務の責任者と経理などの関係者が決めます。DX全体の目標と成果指標の決め方は、中小企業のためのDX推進ガイドで扱っています。

BigQueryはデータを蓄積・変換・集計する役割、Data Studio（旧Looker Studio。2026年4月に名称変更）はBIとして集計結果を可視化・共有する役割を担います。Data Studioは、GoogleのBIであるLooker Studioの名称が元に戻ったものです（Google Cloud：Data Studio の概要、確認日：2026年10月21日）。名前の似たLookerは別の製品です。この記事では以後、現在の名称またはBIと書きます。

最初からすべての段階をそろえる必要はありません。次の表は、構成を選ぶ条件の例です。

表は横にスクロールできます →

元データが少なく、表計算で足りている間は、無理に基盤を増やす必要はありません。複数の元データを同じ計算でまとめる、過去の状態を残して推移を見る、閲覧者ごとに見せる範囲を分ける、といった必要が出てきたら、BigQueryのような蓄積・加工の層を検討します。会社の規模に合わせて製品を段階的に替えるのではなく、更新の頻度、元データの数、運用の担当で選びます。

BigQueryの処理時間と費用は、データの量に加えて、読み込む列や行、結合や集約の書き方によっても変わります（BigQuery：クエリ処理の最適化）。性能は、対象のデータと実際の集計で確かめます。複雑な計算をグラフごとに分散させず、BigQuery側の集計用の表やビューにまとめると、同じ定義を複数の画面で使いやすくなります。Apps Scriptなどのスクリプトで取り込む場合も、割り当てや実行時間の上限を超えると処理が止まります（Apps Script：割り当てと制限、確認日：2026年10月21日）。連携ツールの比較と実行回数の見積もりは、Zapier/Makeによる業務自動化で扱っています。

ダッシュボードの数字が別の資料と合わないときは、同じ指標・対象期間・取得時点・集計条件で比べ、差を元の明細まで確認します。画面を再読み込みするだけで済ませたり、合計額が一致したことだけで正しいと判断したりせず、件数やキー、どの明細が含まれているかも確かめます。

次の表は、ずれの原因になりやすい確認軸と照合の方法です。担当は役割の例で、自社の体制に合わせて決めます。

表は横にスクロールできます →

表の確認軸には、製品の仕様が関わるものがあります。BigQueryの日時関数は、タイムゾーンを指定しない場合にUTCを使うため、日本時間の月の境界とずれることがあります（BigQuery：TIMESTAMP関数）。Data Studioのブレンドは結合の前に各表を集約するため、同じデータをSQLで結合した場合と行数が変わることがあります（Data Studio：ブレンドの仕組み）。また、Data Studioは結果を一時的に保存して表示し、データの鮮度の設定や、フィルタ・期間の変更、手動の更新で元データから取り直します。鮮度の設定は、閲覧者の認証情報なら閲覧者ごと、オーナーの認証情報なら閲覧者全員で共通です（Data Studio：データの鮮度、いずれも確認日：2026年10月21日）。

差が見つかったら、どの確認軸で、いくらの差が説明できたかを記録します。差の理由が分かるまでは、画面の数字を確定値として扱わない、注記を付けて参考値として使うなど、扱い方を決めておきます。

KPI定義票には、指標の目的、算式と除外、期間と日付、粒度とキー、取得時点と更新、承認と受入の条件を書きます。様式を用意したら、1つの指標を例に実際に埋めてみると、関係者の解釈の違いを見つけやすくなります。次は、説明のために作った仮定の記入例です。

指標は「月次請求額」とし、会計上の売上や入金額とは区別します。対象は2026年10月分の次の3件の取引だけで、金額は税抜の円、各取引の請求は1件ずつ、金額の重複はない前提です。

• 取引A：100,000円。受注9月30日、請求10月1日、取消なし
• 取引B：60,000円。受注10月2日、請求10月3日、取消なし
• 取引C：40,000円。受注10月3日、請求10月3日、10月4日に取消

表は横にスクロールできます →

この定義で元の明細を集計すると、対象は取引AとBの2件で、160,000円です。ところが、ダッシュボードには100,000円と表示されていました。照合の記録は次のとおりです。

表は横にスクロールできます →

この例で確かめられたのは、3件の取引について、日付の基準と除外の条件をそろえたことまでです。金額の一致は、ほかの期間のデータや会計処理が正しいことまでは示しません。未確認の事項と担当を残し、定義や集計の条件を変えたときは、定義票の版と変更の理由を記録します。

構築は、目的と定義を決め、小さな範囲で取り込み、同じ条件で照合してから、定例の利用へ進めます。取り込みや集計を自動化しても、定義・実装・接続・再実行の誤りはなくなりません。段階ごとに確認する内容を決めておきます。

1. 目的と判断者を決める
   何の判断に使う数字か、誰がどの頻度で見るかを決めます。
2. 定義票と元データ、利用の権限を確認する
   指標ごとに定義票を作り、元データの所在と管理者、分析に使ってよい範囲を確認します。
3. 小さな範囲で取り込み、履歴と重複の扱いを決める
   最初は必要な列と期間だけを取り込みます。同じデータを取り込み直したときに二重にならないか、元データの更新・削除をどう反映するか、過去の状態を残す必要があるか、元システムの列の変更にどう対応するかを決めます。
4. BIで画面を作り、条件をそろえる
   グラフごとの期間・フィルタ・集計方法を定義票に合わせます。画面には、データの対象時点と最終更新の時刻を表示します。
5. 明細・合計・閲覧結果で受け入れる
   元の明細と件数・金額を照合し、実際の閲覧者の立場で表示を確かめてから使い始めます。自動更新を設定したことと、正しい対象期間の数字が表示されることは、別に確かめます。
6. 定例で使い、更新の失敗と担当の交代に備える
   数字を使う会議などの場と、更新が失敗したときの連絡先、数字を参考値として扱う判断、再実行と再照合の手順を決めます。担当が替わっても運用できるよう、定義票と手順を残します。経営への月次報告に組み込む場合の報告項目は、外部IT責任者と90日ロードマップの月次IT報告の節で扱っています。

定義や計算方法を変えたときは、変更の理由、承認者、適用した日を記録し、過去の数字と比べるときに区別できるようにします。

レポートを共有する権限と、元データにアクセスする権限は、分けて管理します。Data Studioのデータソースでオーナーの認証情報を使う場合、閲覧者は元のデータセットへの権限を持っていなくても、レポートを通じてデータを見られます。閲覧者の認証情報を使う場合は、閲覧者ごとに元データへの権限が必要です（Data Studio：データの認証情報）。BigQueryに接続する場合も、認証方式によって、閲覧者にBigQueryの役割が必要かどうかが変わります（Data Studio：BigQueryへの接続、いずれも確認日：2026年10月21日）。

共有リンクの設定や組織単位での共有だけで、行ごとの表示の制限まで済むとは限りません。利用するプランとコネクタ、認証方式で何ができるかを確認し、実際の閲覧者の立場で表示を確かめてから公開します。

個人情報は、分析の目的に必要な最小限の項目だけを扱います。氏名を外して顧客IDに置き換えても、ほかのデータと照合すれば個人に結び付く場合があるため、IDへの置き換えやマスキングだけで漏えいのおそれがなくなるわけではありません。利用の目的、扱う項目、保存の期間と削除の方法、閲覧できる人を決めて記録します。

更新の失敗にも備えます。取り込みや更新が失敗したときに、最後に成功した時刻とデータの対象時点を確認できるようにし、連絡先、数字を使わないか参考値とするかの判断、再実行と再照合の手順を決めます。また、BigQueryのタイムトラベルで変更・削除前のデータを参照できるのは、設定された限られた期間だけです（BigQuery：タイムトラベルとフェイルセーフ、確認日：2026年10月21日）。月末時点の状態を残すなど、業務上の履歴が必要な場合は、別の表への保存やバックアップを設計します。

データ分析基盤の費用は、ツールの利用料、設計、データの収集・連携、保存、処理、BI、保守と失敗への対応に分けて確認します。BIを無料で使い始められても、基盤全体が無料になるとは限りません。Data StudioからBigQueryのデータを使う場合は、課金アカウントに関連づけたプロジェクトが必要で、クエリの処理や保存の費用が発生することがあります（Data Studio：BigQueryへの接続、確認日：2026年10月21日）。画面の表示や更新のたびに元データへ問い合わせると、通常のクエリ費用がかかります。

表は横にスクロールできます →

金額が分からない項目は0円とせず、確認できた小計と分けて記録します。BigQueryの処理の費用は、オンデマンド料金では処理したデータ量、容量ベースの料金では使用する処理容量によって変わります。

費用の上限は、仕組みごとに確認します。Cloud Billingで通知だけの予算を設定した場合、予算を超えても利用や請求は自動では止まりません（Cloud Billing：予算とアラート）。BigQueryのオンデマンド料金では、maximum bytes billed（課金される最大バイト数）を設定すると、見積もった処理量が上限を超えるクエリは、課金されずに失敗します。これは対象のクエリの処理量を制限するもので、保存やほかのサービスを含む全体の金額の上限ではありません。1日の処理量を制限するカスタム割り当ても、対象と、超えたときに止まる処理を確認します（BigQuery：費用の見積もりと制御、いずれも確認日：2026年10月21日）。対応するサービスでは支出の上限を設ける予算も設定できますが、上限に達すると対象のサービスが一時停止します。費用を抑えるために処理を止めると、ダッシュボードの更新も止まるため、そのときに数字をどう扱うかも決めておきます。

生成AIで社内の情報を使う場合も、数値の集計と文書の検索は分けて考えます。売上や請求額のような数値は、合意した定義・期間・権限に沿って集計し、その結果を照合する必要があります。社内規程やマニュアルを検索して回答するRAG（検索拡張生成）では、根拠となる文書とその版、検索の精度、回答の評価が中心になります。

そのため、データ分析基盤の構築やデータの全社統合を、すべてのRAGの前提条件にする必要はありません。文書の検索が目的なら、対象の文書と更新の担当を整えるところから始められます。反対に、BIの数字を整えただけで、AIが数値に関する質問に正しく答えられるとは限りません。AIに集計結果を扱わせる場合も、どの定義の数字を、どの権限で参照させるかを決め、回答を評価します。業務への組み込み方と評価の進め方は生成AIを業務へ組み込む方法、文書検索の精度の評価はRAGシステムの構築で扱っています。

導入や見直しを始める前に、分かる範囲で次の点を確認します。すべてに当てはまっても、数字の正確さや安全性が保証されるわけではありません。未確認の項目は、担当と次に確認する時期を決めて残します。

社内や外部に相談するときは、何の判断に使う数字か、どの数字と合わないか、元データと更新の担当について分かる範囲をまとめておくと、整理を進めやすくなります。資料がそろっていなくても、ご相談いただけます。パスワードや実際の顧客データを、相談フォームに書いていただく必要はありません。