Access レポートを Looker Studio / Power BI に移行する方法：BI基盤への進化ステップ
目次 クリックで開く
本記事の親ピラー（包括ガイド）
本記事は Aurant Technologies の Access移行 親ピラーガイドを支えるクラスター記事です。
Access のレポート機能（印刷用の集計表・グラフ）は、業務帳票として長年使われてきたが、現代の経営層・現場が求める「インタラクティブな分析」「リアルタイム更新」「モバイル対応」には対応できない。Looker Studio・Power BI・Tableau などの BI ツールへの移行で、レポートを「分析できるダッシュボード」に進化させる。本稿は、Access レポートから BI ツールへの移行手順と設計判断を整理する。
1. Access レポートと BI ツールの本質的な違い
| 側面 | Access レポート | BI ツール |
|---|---|---|
| 主目的 | 印刷・PDF 出力 | 画面で対話的に分析 |
| 更新頻度 | レポート実行時に毎回再集計 | リアルタイム or バッチ更新 |
| フィルタ操作 | 事前にパラメータ設定 | 画面上で動的フィルタ |
| グラフ表示 | 静的 | ドリルダウン可能 |
| 共有方法 | PDF メール送信 | URL 共有・埋め込み |
| モバイル対応 | × | ○ 標準 |
| データソース | Access テーブル | 多種多様（SQL・CSV・API・SaaS） |
2. 主要 BI ツールの位置づけ
- Looker Studio（旧 Google Data Studio）：Google 提供の無料 BI。BigQuery・Google Analytics・Google Sheets との接続が強い。シンプルで導入が早い。Pro 版で組織管理機能追加。
- Power BI：Microsoft 提供。Microsoft 365 環境との統合が深い。Excel ライクな UI で業務担当者にも親和性が高い。Pro / Premium で複数ユーザ向け。
- Tableau：データ可視化の老舗。複雑な可視化・大規模データに強い。月額 ¥10,000〜/ユーザの上位ツール。
- Qlik Sense：連想エンジンで多次元分析に強い。中堅・大手企業向け。
- Looker（Google Cloud）：LookML による定義済みモデル。エンタープライズ大規模向け。月額数百万円。
3. Access レポートから BI ツールへの移行手順
- レポートの棚卸し：Access のすべてのレポートをリスト化。利用頻度・利用者・業務影響度を評価。
- レポートの分類：(a) 印刷用帳票（請求書・注文書 等）、(b) 経営ダッシュボード、(c) 業務運用レポート（在庫・売上 等）。
- 移行方針の決定：(a) 印刷用帳票は Power BI のページ分割レポート、または別ツール（請求書発行 SaaS）。(b) 経営ダッシュボードは BI ツール。(c) 業務運用レポートも BI ツール。
- データソースの整備：BI ツールが参照する DB（Azure SQL・BigQuery・Snowflake）を準備。Access のデータをここに移行 or 連携。
- BI ツールでのダッシュボード構築：Access のレポートを参考に、BI ツールでより使いやすい形に再設計。
- ユーザートレーニング：業務部門が自分でフィルタ・ドリルダウンを使えるように。
| Access レポートの構成要素 | Looker Studio での実装 | Power BI での実装 | 移行時の注意 |
|---|---|---|---|
| グループ化ヘッダー / フッター（集計フッタ） | テーブル / ピボットテーブルの「ディメンション」と「集計指標」。グループ小計は組み込みの合計行 | マトリックス ビジュアル＋小計 (Subtotal) オン、または DAX の SUMMARIZE | Access は印刷ページごとに小計が走るが、BI は集計済みデータを動的に再計算するため、元データ側を行明細粒度に揃える |
| サブレポート（親レポートに従属するレポート） | 同一ダッシュボード内の別チャート＋共有フィルタ、もしくは詳細表示用のページ遷移 | ドリルスルー ページ、または親ビジュアル選択で連動する明細マトリックス | サブレポートの「親レコードと連動」は BI 側ではキー結合で再現する。データモデルでリレーションを必ず定義 |
| パラメータクエリ（実行時にパラメータ入力） | レポート上のコントロール（日付範囲・プルダウン）＋データソースのパラメータ | スライサー、または「フィールド パラメータ」「クエリ パラメータ」 | Access のパラメータは SQL に埋め込まれるが、BI は閲覧者が画面で切り替える前提。既定値と権限による絞り込みを設計に追加 |
| パススルークエリ（外部 DB に SQL を直接発行） | BigQuery / Cloud SQL コネクタの「カスタムクエリ」 | DirectQuery モード、または Power Query の「ネイティブ SQL クエリ」 | 結果セットがそのまま画面更新ごとに走るため、SELECT 範囲とインデックスを見直す。重い集計は中間テーブル化 |
| 連結クエリ / UNION クエリ | データソース側のビュー、または「データの統合（ブレンド）」 | Power Query の「クエリの追加 (Append)」 | 列名・データ型の不一致は BI 側でエラーになる。事前に統一スキーマを決める |
| リンクテーブル / インポート テーブル | ライブ接続（コネクタ経由）／抽出は不可（都度クエリ） | DirectQuery（ライブ）／インポート モード（抽出キャッシュ）の二択 | リアルタイム性と性能はトレードオフ。閲覧頻度の高い経営ダッシュボードはインポート＋スケジュール更新が無難 |
| コントロールソース計算式（テキストボックスに =[売上]-[原価]） | 「計算フィールド」＋ CASE / IF / SUM 等 | DAX のメジャー（例: 粗利 = SUM(売上)-SUM(原価)） |
BI ではメジャーをデータモデルに一度定義すれば全ビジュアルで再利用できる。レポート毎に式を書かない |
| IIf(条件, 真, 偽) | CASE WHEN ～ THEN ～ ELSE ～ END | DAX の IF(条件, 真, 偽) または SWITCH |
ネストが深い IIf は SWITCH / SWITCH(TRUE()) に書き換えると保守性が上がる |
| DLookup(“列”,”テーブル”,”条件”) | データのブレンド（左外部結合）＋計算フィールド | DAX の LOOKUPVALUE または RELATED（リレーション経由） |
DLookup は行単位で走り低速。BI ではリレーションを張って RELATED に置き換えるのが原則 |
| Format(値, “yyyy/mm”)／Format(数, “#,##0”) | フィールド設定の「表示形式」、または FORMAT_DATE / FORMAT 関数 | 列・メジャーの「書式」プロパティ、または DAX の FORMAT |
Format で文字列化すると並び替え・集計が崩れる。表示書式はビジュアル側で指定し、値は数値・日付のまま保つ |
| Nz(値, 0)（Null を 0 に） | IFNULL / COALESCE | DAX の COALESCE または IF(ISBLANK(...), 0, ...) |
BI の空白は集計から自動除外されることが多いが、平均・割合では明示的な 0 補完が必要 |
| ページヘッダー / ページフッター（印刷前提） | レポート上部の固定テキスト・画像、ページ番号は廃止 | 「ページ分割レポート (Paginated Reports)」を使う場合のみページヘッダーあり。通常レポートは廃止 | 画面用ダッシュボードでは「ページ」概念が消える。請求書・帳票として PDF 出力が必須なものだけページ分割レポートで残す |
4. データソースのアーキテクチャ
Access レポートを BI ツールに移行する際、データソースの設計が中核。
- Access → 中間 DB → BI：Access データをまず Azure SQL や BigQuery に移し、BI ツールから参照。最も標準的な構成。
- Access の直接参照：BI ツールから ODBC 経由で Access ファイルを直接参照。性能が出ない・ファイル破損リスクがあるため非推奨。
- CSV エクスポートの定期取込：Access から日次 CSV エクスポートし、BI ツールがそれを参照。簡易的な構成。
- Power Query 経由：Power BI から Power Query で Access ファイルを参照、データ整形して BI 内で保持。中規模向け。
5. ダッシュボードを「見られ続ける」状態にするための設計
Access のレポートを BI ツールに移行するときに最も惜しいのは、技術的な置き換えだけで終わってしまい、誰も使わないダッシュボードができることです。BI に変えるタイミングは、設計を見直すよい機会でもあります。Access レポートはページごとに情報を整理する印刷物としての設計でしたが、BI ダッシュボードは1画面で完結することが前提になります。優先度の低い指標まで詰め込むと利用者の視線が分散し、結局見られないダッシュボードになりがちです。優先度の低い指標は別タブ・別ページに分離して、主要画面は経営判断や日次運用判断に直結する指標だけに絞ります。
数字を並べるだけのダッシュボードは「気づき」が生まれにくいため、異常値が一目で分かる色分けや、しきい値を超えたメトリックへの目印、推奨アクションの提示まで設計します。階層的なドリルダウン（全社サマリ → 部門別 → 個別案件）で、上位の異常を見つけたあと、その場で原因まで掘り下げられるとダッシュボードへの依存が深まります。さらに、定期会議のアジェンダに組み込まれることで利用が定着し、しきい値を超えたら Slack や Teams、メールに自動配信する仕組みを足すと、「ダッシュボードを見に行く」から「ダッシュボードから情報が来る」運用に変わります。Access の印刷レポートでは作れなかった運用形態で、移行の効果が最大化する領域です。
6. BI 移行で実際に時間がかかる場面
Access レポートから BI ツールへの移行プロジェクトは、ツール上でビジュアルを作るだけなら短期間で完了しますが、現場で本当に時間がかかるのは別の3つの工程です。最初に詰まりやすいのが、Access に散らばっているレポートの棚卸しと分類です。利用頻度・利用者・業務影響度を1本ずつ評価していくと、ほとんど見られていないレポートと、業務の中核に組み込まれているレポートが入り混じっていることに気付きます。ここを丁寧にやらずに「全部移行する」と決めてしまうと、後で不要なダッシュボードの保守が肥大化します。
次に時間がかかるのが、データバックエンド（Azure SQL・BigQuery・Snowflake・Cloud SQL 等）の構築と、Access からのデータ取込です。スキーマ整理、増分更新の設計、データ品質の検証、テストデータでの再現確認といった作業は、ツール側の華やかな部分とは別軸で粛々と進む工程です。Access の単一ファイルを単に置き換えるのではなく、業務全体で「データの正本」をどこに置くかを決める作業でもあります。
最後に意外と時間が必要なのが、本番展開とユーザートレーニング、運用ルールの整備です。経営層・現場の双方が、Access レポートで「与えられていた数字」から、BI ダッシュボードで「自分で掘る数字」に切り替わることに慣れるには、見る習慣・更新タイミングの合意・データ責任者の指定など、運用ルールを言語化する作業が必要になります。技術的な構築よりも、運用の合意形成のほうがプロジェクト後半の工数を消費します。逆にこの3つを甘く見積もらなければ、BI 移行は技術以上に投資対効果の見える施策になります。
Access移行の進め方に迷ったら ― 無料の「移行診断・セカンドオピニオン」
現行 Access の棚卸しから、kintone・Power Apps・Salesforce など移行先の選定、VBA資産の引き継ぎ、IT導入補助金の活用可否までを実装視点で無料診断します。すでにベンダーから提案を受けている場合のセカンドオピニオン（その見積り・移行方式が妥当か）にも対応します。診断のみのご利用も歓迎です。
関連ピラー
データ分析・予実可視化とダッシュボード構築のご相談
散在するデータの集約から、予実管理やKPIをひと目で追えるダッシュボードの構築までを支援します。何をどの指標で見える化すべきかという設計段階から、貴社の状況に合わせてご一緒します。
データ分析・BI
Looker Studio・Tableau・BigQueryを活用したBIダッシュボード構築から、データ基盤整備・KPI設計まで対応。経営判断をデータで支援します。