Excelからデータベースへ移行！一元管理とシステム化【低コスト連携DBも】
- 「Excelではなく、
長期的なデータ管理に適したデータベースに移行したい…」 - 「データベースを使いたいが、
費用や手間を抑えたい…」 - 「データベースの選択肢が多すぎて、
最適な移行先がわからない…」
Excel（エクセル）
本記事では、
ExcelとDBの全体像を把握したい方へ
移行を検討する前に、
目次
Excelによるデータ管理は、
- デメリット1. 大容量データを扱えない
- デメリット2. 共有・多人数での同時編集に制限がある
- デメリット3. データ整合性を強制しにくい
- デメリット4. セキュリティ・ガバナンスの統制が限定的
デメリット1. 大容量データを扱えない
Excelには最大約104万行・1.6万列という仕様上限があり、
仕様上限に達していなくても、
- 配列数式や揮発性関数（INDIRECT、
OFFSETなど） による複雑な計算式 - 過度な条件付き書式の設定
- 大量の数式参照
データ量の増大と計算負荷が重なるほど、
デメリット2. 共有・多人数での同時編集に制限がある
1つのExcelファイルを複数人で同時編集する場合、
OneDriveやSharePointを介したWeb版Excelでの共同編集機能は近年かなり安定してきています。
- フィルタや並び替えの共有状態
- 重いマクロ（VBA）
との併用 - 複雑なブック構造での同時アクセス
デメリット3. データ整合性を強制しにくい
Excelでは「データの入力規則」
そのため列内に異なるデータ型が混在したり、
デメリット4. セキュリティ・ガバナンスの統制が限定的
Excelは単一ファイルで管理されるため、
加えて、
小〜中規模であればExcelの適切な設計で改善・運用は可能ですが、
あわせて読みたい
ExcelをDB代わりとしたときの限界・デメリットの詳細は、
ExcelからDBへの移行は、
出発点（ステップ1）
- ステップ1：Excel 1ブック完結
すべてのデータ・計算・帳票が1つのブックに集約されており、
各ルート内の「ステップ」
-
ルートA：クラウド表計算ルート：
Excelの標準クラウド機能を活用した延命策。データ量の増大や運用の複雑化により限界を迎えた場合はルートB/Cへ再合流。 - ステップ2：1ブック同時編集
- ステップ3：外部セル参照（数式連携）
-
ルートB：内製化（DIY）
ルート：
自社の業務ロジックやExcelのインターフェースを維持したまま、段階的にリレーショナルDBへ移行する。 自由度が高く、 ステップ4程度までは非常に低コスト。 - ステップ2：Excel複数ブック分離
- ステップ3：Access/SQLite
- ステップ4：Dataverse（Teams環境）
- ステップ5：サーバー型DB
-
ルートC：既製パッケージルート：
自社でのプログラム開発を伴わず、外部ベンダーの完成済みシステム基盤を活用する。 業務フローの見直しが必要な場合もあるが、 属人化リスクを低く抑えられる。 - ステップ2-a：SaaS型業務システム
- ステップ2-b：SaaS型ノーコードWebDB
大人数での使用や継続的なデータ蓄積、
ルートAは、
- ステップ2：クラウドストレージでの1ブック同時編集
- ステップ3：クラウドストレージ上で複数ブック（外部数式連携）
Googleスプレッドシートに移行するのもこのルートAに含まれます。
ステップ2：クラウドストレージでの1ブック同時編集
単一のExcelブックをクラウドストレージ上に配置し、
- 構成・使用方法： 単一Excelブック（クラウドストレージ上）
→ Web版Excel/デスクトップアプリの共有機能を使用 - コスト：0円（OneDrive、
SharePoint、 Googleドライブの既存ライセンス範囲内） - 必要な技術スキル：初級（クラウドストレージへのファイル配置、
共有リンク発行、 アクセス権限付与の設定）
できるようになること：
- 共有・同時編集可能に：Webブラウザまたはデスクトップアプリを介して、
同一のExcelブックに対し、 複数人が同時にセルの値を閲覧・入力・更新できるようになる。
発生する運用上の制限・課題：
- 画面同期の競合：同一シート上で特定のユーザーが「オートフィルター」
の抽出条件変更や「並び替え」 を実行すると、 ビュー設定を個別化していない限り、 他の同時接続ユーザーの画面表示も強制的に同期される。 入力作業を阻害する場合がある（最新のExcelでは 「個人用ビュー」 機能で回避可能 だが、 ユーザー側の操作習熟が必要） - マクロ（VBA）
の制限：Web版Excelでは VBAコードの実行が不可能。 デスクトップアプリで開くユーザーとの間で動作不整合が発生しやすい
ステップ3：クラウドストレージ上で複数ブック（外部数式連携）
データが蓄積される「データ保管用ブック（マスターなど）
- 構成・使用方法： 複数のExcelブック（クラウドストレージ上）
→ 外部参照数式でブック間連携 - コスト：0円
- 必要な技術スキル：中級（ブック間を跨ぐ外部参照数式の構文理解、
パス指定方法、 XLOOKUPやINDEX＋MATCH関数のネスト利用）
できるようになること：
- データの一元管理・再利用：「データ保管用ブック」
と「集計・帳票出力用ブック」 を物理的に分離でき、 マスタなどのデータを1つのファイルとして切り出して管理可能になる。
発生する運用上の制限・課題：
- リンク切れ（#REF!エラー）
：クラウド上のデータ保管用ファイルの保存先フォルダ移動、 ファイル名変更、 または同期遅延により、 数式内の参照パスが不一致となり、 参照エラーが一斉に発生する - 外部参照の構文例（仕様）
：
=[データ保管用ブック.xlsx]Sheet1!$A$1 ='https://d.docs.live.net/ユーザーID/Documents/[データ保管用ブック.xlsx]Sheet1'!$A$1excel - 外部参照の構文例（仕様）
- ファイル同期と参照解決の遅延：参照元のデータ件数が増大するにつれ、
ファイルを開く際の同期処理および参照解決処理に要する時間が増大する。 動作の大幅な遅延やExcelの強制終了を引き起こす原因となる
ルートBは、
- 前提知識：ExcelとDBの連携方法
- ステップ2：複数Excelブックの連携（データ保管の分離）
- ステップ3：ファイル型DB（Access/SQLite）
によるデータ保管・一元管理 - ステップ4：Dataverse(Teams環境) によるクラウドDB化
- ステップ5：サーバー型DB構築による本格システム化
UIとしてExcelを使用する前提で話を進めますが、
前提知識：ExcelとDBの連携方法
ExcelとDBの連携は、
接続方法は主に2つあります。
- Power Query：ExcelからDB（または外部ファイル）
のデータを読み取れる。 ただし、 Excel単体で利用する場合、 DB内のデータへの直接書き込み・更新はできない - VBA（ADODB）
：ExcelからDBのデータの読み取り・書き込みの両方が可能
ADODBによる外部接続の例
ADODB（ActiveX Data Objects）
以下は、
Dim cn As Object
Set cn = CreateObject("ADODB.Connection")
' 1. Access（.accdb）への接続文字列およびプロバイダ仕様
' ※UNCパス（\\Server\Share\）を用いて共有ネットワーク上の保管庫を指定
cn.Open "Provider=Microsoft.ACE.OLEDB.16.0;Data Source=\\Server\Share\Database.accdb;"
' 2. データ挿入（INSERT文）のSQL構文定義
Dim sql As String
sql = "INSERT INTO T_営業管理 (ProductCode, Quantity) VALUES ('P001', 10);"
' 3. コマンドの実行（非同期処理を挟まない即時書き込み）
cn.Execute sql
' 4. コネクションの明示的クローズ（ファイルロックの即時解除）
cn.Close
Set cn = Nothing構文・処理のポイント：
- Provider指定（Microsoft.ACE.OLEDB.16.0）
：ACE OLEDBプロバイダを呼び出し、 Access 2007以降の標準フォーマット（.accdb） のDBエンジンを直接駆動させる仕様 - SQL文の実行（INSERT INTO）
：Excelシート上にデータを展開することなく、 指定したテーブル（T_営業管理） のフィールド（ProductCode, Quantity） に対して、 値を直接レコードとして追加する処理 - 明示的なクローズ（cn.Close）
：SQL実行後直ちに接続を閉じることで、 共有ファイルに対するロックを最小限のセッション時間（数秒未満） に留め、 複数人同時アクセス時のファイル競合リスクを抑制する手順
ファイル型DBのクラウドストレージ管理には要注意
ファイル型DB（Access/SQLite）
ステップ2およびステップ3のファイル型DBは、
ファイル破損のメカニズム
SQLiteやMicrosoft Accessなどのファイル型DB を、
クラウドストレージの同期アルゴリズム（差分同期を含む）
ステップ2：複数Excelブックの連携（データ保管の分離）
ユーザーが操作する「集計・帳票出力用Excel」
- 構成・使用方法： 複数のExcelブック（ローカル/共有フォルダ上）
→ Power Query/VBA（必要に応じてADODB） でブック間連携 - コスト：0円
- 必要な技術スキル：中級〜上級（Power Queryによる外部ファイル接続・データクレンジング設定、
VBAによる特定ブックへのデータ追記マクロ開発）
できるようになること：
- データの一元管理・再利用：「データ保管用ブック」
と「集計・帳票出力用ブック」 を物理的に分離でき、 複数のブックから参照するためのデータ（マスタなど） を1つのファイルとして切り出して管理可能になる。
発生する運用上の制限・課題：
- ファイルロック問題：バックエンドが通常のExcelブックであるため、
あるユーザーがVBA経由で書き込み処理を実行している間、 ファイルがOSによって排他ロック（書き込み禁止状態） となる。 他ユーザーからの同時書き込みVBA命令はエラー（実行時エラー '70': 書き込み権限がありません） となり、 処理が遮断される。
データ保管庫を分離する際のテーブル（マスタとトランザクション）
ステップ3：ファイル型DB（Access/SQLite）
データの保管庫をExcelから、
- 構成・使用方法： Excel + ファイル型DB（ローカル/共有フォルダ上）
→ Power Query/VBA（ADODB） でデータ連携 - コスト：0円（SQLite利用時）
。 Accessの場合はMicrosoft 365の特定プラン、 またはスタンドアロンライセンス代が必要 - 必要な技術スキル：（SQL構文（DDL/DML）
、 ADOによる接続管理、 RDB設計論）
できるようになること：
- 同時書き込み対応の向上：DBエンジンがページ/行単位の排他制御（ロック）
を行うため、 数人規模の同時書き込み時におけるロックエラーが解消される（SQLiteの場合はVBA側でリトライ制御の実装を推奨） 。 - データ整合性の強制：主キー（Primary Key）
による重複データの排除、 データ型（整数型、 日付型など） の厳格な定義、 外部キー制約（Foreign Key） によるリレーションシップ参照整合性の有効化により、 表記揺れや不正データの混入をDB層で遮断できる。 - 破損耐性の向上：ACID特性（トランザクション処理）
により、 書き込み処理中のPC強制終了やネットワーク切断時にも自動ロールバックが働き、 DB全体の構造崩壊を防止する。
発生する運用上の制限・課題：
- 同時接続数が10名を超える環境や、
頻繁にミリ秒単位の書き込みが発生する高負荷なトランザクション処理では、 書き込みキューの衝突（ロック競合） によりパフォーマンスが低下する場合がある。 規模に応じてサーバー型DBへの移行検討が必要
あわせて読みたい
AccessとSQLiteの機能や容量制限の違い、
ステップ4：DataverseによるクラウドDB化
Microsoftのローコードプラットフォーム（Power Platform）
-
構成・使用方法：
Excel (+ Power Apps) + Dataverse（Teams環境）
→ Power Query/ VBA（Dataverse Web API）でデータ連携
（＋Power Automateで自動化）- Dataverse Web API：HTTP通信を介してDataverseのデータを操作するための公式API
-
コスト：0円（Microsoft 365のTeams利用可能な既存ライセンスに含まれる）
-
必要な技術スキル： 上級（Power Appsによる入力UI開発、
Power Automateによるワークフロー構築、 Dataverse固有のリレーション・セキュリティ設定）
できるようになること：
- Web共有・クロスプラットフォーム対応：社内LAN/NASの制約から脱却し、
インターネット経由で拠点間共有が可能になる。 スマートフォンやタブレット端末の専用アプリ（Power Apps） からのリアルタイムデータ閲覧・更新にも対応 - 運用の自動化：データの追加・更新をトリガーに、
Power AutomateでTeams通知、 承認ワークフロー、 自動メール送信などをノンプログラミングで連動できる - クラウド管理の信頼性：クラウド基盤による自動バックアップ、
Microsoft Entra ID（旧Azure AD） と連動した柔軟なアクセス権限制御（ガバナンス） が適用される
発生する運用上の制限・課題：
- 容量の上限値（目安）
：Teams環境におけるDataverseの仕様上、 1つのチームあたり「2GB」 のストレージ上限が定義されている。 データ行数は最大100万行程度が目安（テーブル構造に依存） 。 これを超える場合は有償の上位版（Dataverse製品版） へのアップグレード（追加月額コスト） が必要
Dataverseは分類上サーバー型DBの一種ですが、
Dataverseへの接続は、
ステップ5：サーバー型DB構築による本格システム化
SQL Server（Azure SQL Database）
この段階で、
- 構成・使用方法： Excel + サーバー型DB → Power Query/VBA (ADODB)でDBに接続
- コスト：月額数千円〜（Azure SQL Database、
AWS RDSなどのクラウドDBインスタンス利用料、 ネットワークインフラ維持コスト、 外部委託時の保守管理費用） - 必要な技術スキル：プロレベル（DBMSのインデックス最適化、
ネットワークセキュリティ（ポート制御、 SSL/TLS暗号化） 、 IP制限、 接続認証基盤の設計・運用）
できるようになること：
- 高度なスケーラビリティ：容量および行数の制限が事実上撤廃される。
1,000万件を超えるビッグデータや長年の履歴データに対して、 インデックスチューニングによるミリ秒単位の応答速度で高速検索が可能。 - 外部連携の拡張：基幹システム（ERPや各種WebサービスのAPI：Application Programming Interface）
と直接データ連携し、 夜間バッチ等によるマスターデータの完全自動同期を実現できる。
発生する運用上の制限・課題：
- クラウド/マネージドDBの普及により、
ハードウェア保守などの運用負荷は大幅に低減されている。 ただし、 DBの初期設計、 脆弱性対策、 インデックスの最適化、 セキュリティ監視などを適切に行うには、 専門のインフラ知識・スキルを持つ担当者（または外部ベンダー） による継続的な管理体制が必要
ルートCは、
- ステップ2-a：SaaS型業務システムの導入
- ステップ2-b：SaaS型ノーコードWebDBの導入
ステップ2-a：SaaS型業務システムの導入
特定の業務領域（会計、
- 構成・使用方法：SaaS →（必要な場合のみ）
Excelアドイン/API連携/データのインポート・エクスポートなどでExcel併用（ツール仕様による） - コスト：初期導入費用 ＋ 月額ライセンス費用（利用ユーザーID数に応じたアカウント課金、
またはデータ量に応じた従量課金） - 必要な技術スキル：業務要件定義スキル（フィット＆ギャップ分析、
外部ベンダーとの仕様調整・ベンダーコントロール） 、 プログラミング開発スキルは不要
できるようになること
- 即時導入と法対応の自動化：自社でデータ構造の設計やプログラム開発を行わずに、
業界標準の業務プロセス（インボイス制度、 電子帳簿保存法などの最新税制・法改正） に準拠した完成済みのシステム基盤を即座に稼働できる - 運用の堅牢性：SaaSベンダー側がサーバーの可用性（SLA）
、 二重化、 セキュリティ監視、 自動アップデートを担保するため、 自社でのインフラ保守が不要
発生する運用上の制限・課題：
- 業務プロセスの見直し：パッケージの標準仕様を自社都合で柔軟に改修することは難しい。
自社固有の特殊な計算ロジックや変則的な商習慣が存在する場合、 大幅な業務フローの見直しが必要になることがある。 独自のカスタマイズ（アドオン開発） を行う場合は、 高額な追加費用が発生する
ステップ2-b：SaaS型ノーコードWebDBの導入
kintoneやAirtableなどのノーコードWebDBツールを活用し、
- 構成・使用方法：SaaS →（必要な場合のみ）
Excelアドイン/API連携/データのインポート・エクスポートなどでExcel併用（ツール仕様による） - コスト：初期導入費用 ＋ 月額アカウント料金（プランに基づく）
- 必要な技術スキル：Webブラウザ上でのドラッグ＆ドロップによるテーブル設計、
リレーション設定、 簡易な数式・プラグインの設定スキル
できるようになること
- 開発の自由度とスピード：プログラミング言語（コード）
を使用せず、 Excelの列概念に近い「フィールド」 を配置するだけで、 多人数同時編集・共有可能なリレーショナルDBを迅速に構築できる。 - 属人化リスクの解消：GUI（グラフィカルユーザーインターフェース）
で構造が可視化されているため、 複雑なVBAマクロのような「ブラックボックス問題」 が発生しにくい。 組織内でのメンテナンスの引き継ぎや仕様変更が容易になる
発生する運用上の制限・課題：
- 複雑なループ処理を伴う計算、
帳票ごとの細かな文字配置（セルの結合やミリ単位の印刷レイアウト制御） 、 大規模データ間を複雑に跨ぐトランザクション処理においては、 製品仕様上の制限により実装が不可能な場合がある。 有料プラグインによる拡張が必要になるケースもある
あわせて読みたい
国内の主要SaaS型WebDBサービスの機能・コストの比較は、
本記事では、
- ルートA（クラウド表計算）
：Web版Excel/スプレッドシートを使用した延命策。 コスト0円で始められるが、 データ量の増加に伴い限界がある - ルートB（Excel＋DB連携）
：ExcelにDBを連携し、 段階的に機能を拡張する。 自由度が高く、 小規模であれば低コストで運用可能 - ルートC（SaaS型システム/WebDB）
：SaaS型システムやWebDBを導入し、 開発なしで法改正対応・属人化解消を実現する
ルートの選び方は、
SaaS型のツール導入を検討する場合は、
「自社での保守を無くし、