Office 365でデータベースを作る方法 Access・Lists・Dataverseの違いと選び方

顧客名簿や案件管理をExcelで回してきたものの、「同時に開けない」「誰がいつ更新したか分からない」「ファイルが何世代にも分かれている」といった問題が出てきた。そろそろデータベースにしたいが、Office 365のどれを使えばいいのか分からない。こうした相談は非常に多く寄せられます。

Office 365（現在のMicrosoft 365）には、「データベース」という名前の単体製品は存在しません。代わりに、用途と規模に応じて使い分ける選択肢が複数用意されています。ここを知らずにExcelのまま粘るか、いきなり本格的な基盤を選んでしまうかで、その後の手間が大きく変わります。

本記事では、Microsoft 365でデータベースとして使える選択肢の全体像から、それぞれの得意分野と制限、選び方の判断基準、そして運用で押さえておくべき権限や個人情報の扱いまでを順番に整理します。自社の要件に合う候補を絞り込める状態を目指します。

確認したいポイント	結論	詳細
Office 365にデータベース機能はある？	複数の選択肢から選ぶ形	単体製品はなく、Microsoft Lists、Access、Dataverse、外部DB連携から用途に応じて選びます。
まず試すならどれ？	Microsoft Listsが第一候補	追加費用なしで使え、列の型指定、権限管理、通知、Power Appsとの連携まで標準で備わっています。
件数の上限はある？	1リスト3,000万件まで	上限は十分ですが、1つのビューが扱えるのは5,000項目までで、このしきい値は変更できません。
Excelで代用してもいい？	共有と同時更新に弱い	排他制御、権限、更新履歴の面で限界があり、複数人で貯め続けるデータはリスト系が安全です。

この記事でわかること

• Microsoft 365でデータベースとして使える4つの選択肢とその違い
• Microsoft Lists（SharePointリスト）でできることと件数の上限
• AccessとDataverseがそれぞれ今も選ばれる場面
• 件数・構造・費用・体制の4軸で候補を絞り込む判断基準
• 権限設計や個人情報の扱いなど、運用開始前に決めておくべきこと

▼ 社内のデータ管理をどう整理すべきか迷っている方へ Microsoft 365や生成AIを使った業務効率化の進め方、支援内容、導入までの流れをまとめた資料をご用意しています。検討の初期段階でも構いませんので、まずは全体像の把握にご活用ください。 ＞ 資料請求はこちら

Office 365にデータベース機能はあるのか

最初に全体像を押さえます。Microsoft 365でデータベースを作るとき、選択肢は大きく4つあり、それぞれ想定している規模と使い方が異なります。ここを踏まえずに個別の使い方を調べ始めると、途中で方針転換することになります。

単体の「データベース製品」は存在しない

Microsoft 365のアプリ一覧を見ても、データベースという名前のアプリは出てきません。データを蓄積して共有するという目的に対して、複数のサービスが役割を分担している構成になっているためです。

そのため、「Office 365でデータベースを作る」という表現は、実際には「どのサービスをデータの入れ物として使うか」を選ぶことを意味します。まずはこの前提を共有しておくと、社内での議論がかみ合いやすくなります。

なお「Office 365」という名称は現在Microsoft 365に統合されています。社内で古い呼び方が残っていることも多いため、本記事でも両方の呼称に触れていますが、指しているものは同じです。

データベースとして使える4つの選択肢

実務で候補になるのは次の4つです。Microsoft Lists（SharePointリスト）、Access、Dataverse、そしてSQL Serverなどの外部データベース。上から順に手軽で、下にいくほど本格的になります。

Microsoft Listsは追加費用なしで使え、クラウド上で複数人が同時に扱えます。Accessは古くからあるデスクトップ向けのデータベースで、複雑な帳票や集計に強みがあります。

DataverseはPower Platformの基盤となるデータ保管先で、リレーションや権限の作り込みが本格的にできます。外部データベースは、既存の基幹システムとつなぐ場合や、件数が非常に多い場合の選択肢です。

どれか1つに統一しなければならないわけでもありません。日々の入力はLists、分析はExcelへ書き出して行う、といった組み合わせは実務でよく使われます。データの正本をどこに置くかだけ決めておけば、使い分けは自由です。

Excelをデータベース代わりにする限界

多くの現場では、まずExcelで管理を始めます。手軽さは大きな利点ですが、共有して複数人で更新する段階になると、排他制御、権限、更新履歴の3点で限界が出ます。

同じファイルを別々の人が開いて別々に保存した結果、内容が食い違う。誰がいつどの行を変えたのか追えない。特定の列だけ見せたいのに、ファイル単位でしか権限を分けられない。いずれもExcelが表計算ソフトである以上、避けにくい制約です。

ただし、Excelをやめるべきという話ではありません。1人で使う集計や一時的な分析はExcelのほうが速い場面も多くあります。共有して継続的に貯めるデータをどこへ置くか、という問題として切り分けてください。

選ぶ前に確認しておく3つの問い

候補を比べる前に、自社の要件を言葉にしておくと判断が速くなります。1つ目は扱う件数と同時に使う人数、2つ目はデータ同士の関係の複雑さ、3つ目は誰が作り、誰が直し続けるのかです。

数百件を数人で扱うのか、数十万件を全社で扱うのか。単純な一覧で済むのか、顧客と案件と対応履歴が絡み合うのか。情報システム部門が面倒を見るのか、現場の担当者が自分で直すのか。この3つが決まれば、候補はかなり絞れます。

Microsoft Listsで作る

最初に検討したいのがMicrosoft Listsです。Microsoft 365に含まれており、追加のライセンスなしで今日から始められます。ここでは実体、できること、制限、作成手順の順に見ていきます。

Microsoft ListsとSharePointリストの関係

Microsoft Listsは、SharePointのリスト機能を単体アプリとして使いやすくしたものです。裏側のデータはSharePointに保存されるため、どちらの画面から開いても同じデータを見ていることになります。

見た目は行と列の表なのでExcelと似ていますが、性格は異なります。Excelが計算のためのソフトであるのに対し、Listsはデータを貯めて共有することを目的に設計されています。位置づけとしてはAccessに近いと考えると分かりやすいでしょう。

TeamsのタブとしてもWebブラウザからもスマートフォンアプリからも開けるため、現場からの入力にも向いています。

Listsでできること

列には1行テキスト、複数行テキスト、数値、日付、選択肢、ユーザー、添付ファイル、他リストの参照といった型を指定できます。型を決めておくことで、入力の揺れを防げる点がExcelとの大きな違いです。

ビューの機能も強力です。同じデータに対して、担当者別、ステータス別、今週分だけといった見せ方を複数用意でき、各自が自分用のビューを作ることもできます。グループ化や条件による書式設定も画面から設定できます。

加えて、Power Automateと組み合わせれば、アイテムが追加されたときに承認を回す、期限が近づいたら通知する、といった処理も組めます。Power Appsで入力画面を作り込むことも可能で、そのまま業務アプリの土台になる点が実務上の強みです。

件数の上限と5,000件のしきい値

よく誤解されるのが件数の上限です。Microsoftの公式情報によれば、1つのリストには最大3,000万アイテムを格納できます。5,000件までしか入らないというのは誤りです（出典：Microsoft Learn「SharePoint の制限」）。

ただし、1つのビューが一度に扱える件数には5,000項目というしきい値が設定されています。これを超えるビューを開こうとするとエラーになり、SharePoint Onlineではこのしきい値自体を変更できません。

回避策としては、絞り込みに使う列にインデックスを設定し、ビューのフィルターで5,000件以内に収まるようにします。日付や担当者で区切ったビューをあらかじめ用意しておけば、件数が増えても運用に支障は出ません。

権限まわりにも制限があります。1つのリスト内で個別に権限を設定できるアイテム数はサポート上限が50,000で、推奨は5,000です。アイテムごとに細かく権限を分ける設計は、早い段階で行き詰まると考えておいてください。

作成の手順

作成自体は数分で終わります。Microsoft Listsを開いて新規作成を選び、空白のリストかテンプレートかを選ぶだけです。Excelファイルから取り込んで、列の型を指定しながら作る方法も用意されています。

作成後は、必要な列を追加し、型と必須設定を決めていきます。ここで手を抜かず、選択肢型にできるものは選択肢にしておくと、後の集計が安定します。自由入力の列が多いほど、表記ゆれで苦しむことになります。

保存先のサイトは、個人ではなくチームのSharePointサイトを選びます。作成者個人に紐づく場所に作ると、異動や退職の際に引き継ぎで困ることになります。

▼ 自社に合うデータ管理の形を一緒に整理しませんか どの選択肢が適しているかは、件数、体制、既存システムとの関係によって変わります。現状をうかがったうえで、無理のない進め方をご提案します。 ＞ 相談予約はこちら

Accessを使う場合

昔から社内で使われてきたAccessも、依然として選択肢です。得意分野がはっきりしている一方で、クラウド前提の環境では制約も出てきます。現在の位置づけを整理しておきます。

Accessという選択肢を検討する前提として、社内にすでに稼働中のファイルがあるかどうかを確認しておいてください。ゼロから新規に作る場合と、既存資産を活かす場合とでは、判断がまったく変わります。

Accessが得意なこと

Accessは、テーブル、クエリ、フォーム、レポートが1つのファイルにまとまった本格的なデータベースソフトです。複数テーブルを関連づけた設計ができ、複雑な条件の抽出や、印刷を前提とした帳票の作り込みに強みがあります。

テンプレートから始められるほか、既存データの取り込み機能も充実しています。数万件規模のデータを1台のPCで扱い、決まった形式の帳票を出力するといった用途では、いまも十分に実用的です。

クラウド環境での制約

一方で、制約も明確です。AccessはWindows向けのデスクトップアプリで、Macでは利用できません。ファイルを共有フォルダに置いて複数人で使う運用は可能ですが、同時利用者が増えると動作が不安定になりやすい構造です。

かつて提供されていたWebアプリとして公開する仕組みはすでに提供が終了しており、ブラウザから使う用途には向きません。スマートフォンからの入力も想定されていません。

また、Accessが含まれるのは一部のMicrosoft 365プランに限られます。全社で使えるかどうかは、自社の契約プランを確認しておく必要があります。

今もAccessが選ばれる場面

現実的にAccessが適するのは、特定部署の数名が、決まったPC上で、複雑な帳票を扱うケースです。すでにAccessで作られた資産があり、動いているのであれば、無理に移行する必要はありません。

ただし、新規に作るなら慎重に検討してください。作成者しか中身が分からないAccessファイルが放置され、退職後に誰も触れなくなるという事態は、多くの企業で起きています。

Dataverseを使う場合

より本格的な基盤が必要なら、Dataverseが候補になります。Power Appsで業務アプリを本格的に作る場合の標準的な保存先であり、Listsでは足りない要件を満たせます。

Listsとの違い

最も大きな違いは、データ同士の関係を本格的に定義できる点です。顧客と案件、案件と対応履歴といった関連を明確に設定でき、片方を削除したときの挙動まで制御できます。

データ型も豊富で、入力値の検証やビジネスルールをデータ側に持たせられます。アプリごとにチェック処理を書くのではなく、データ層で一元的に担保できるため、アプリが増えても品質が保たれます。

セキュリティの粒度も違います。ロールベースで、テーブル単位、レコード単位、項目単位の権限を設計できるため、部署ごとに見える範囲を厳密に分ける要件にも対応できます。

Power Platformの他のサービスとも標準で連携するため、アプリ、自動化、分析をまたいで同じデータを扱えます。複数の業務アプリを継続的に作っていく想定があるなら、共通の土台として選ぶ価値があります。

ライセンスと費用の前提

注意すべきはライセンスです。Dataverseの利用には、Power AppsやPower Automateの有償ライセンスが必要になります。Microsoft 365に含まれる範囲では使えないため、利用人数分の費用を見込む必要があります。

検証目的であれば開発者向けの環境を使う方法もありますが、本番運用には適しません。試作の段階で費用感を確認し、稟議の見通しを立ててから作り込むことをおすすめします。

Dataverseを選ぶ判断基準

判断の目安は、テーブルが5つ以上に分かれ、相互に関連し、部署ごとに見える範囲を分ける必要があるかどうかです。ここまで来ると、Listsでの作り込みは無理が出てきます。

逆に、単一の一覧を全社で共有するだけならListsで十分です。将来の拡張を見込んで最初からDataverseを選ぶ判断もありますが、費用と学習コストが先に発生する点は理解しておいてください。

▼ どこまで作り込むべきかの判断からご相談いただけます 「Listsで足りるのか、Dataverseが必要か」といった設計段階の判断も含めて、実務目線でご相談を承っています。 ＞ 相談予約はこちら

外部データベースと連携する

既存の基幹システムにデータがある場合や、件数が非常に多い場合は、Microsoft 365の中で完結させず、外部のデータベースと組み合わせる構成が現実的です。

SQL ServerやAzure SQLを使う

数十万件を超えるデータや、秒単位の応答が求められる処理では、本格的なデータベースが必要になります。Azure SQL Databaseのようなクラウド型を使えば、サーバーの管理負担を抑えつつ性能を確保できます。

この場合、データの置き場所は外部、画面はPower Appsという分担になります。既存システムのデータをそのまま参照できるため、二重管理を避けられる点も利点です。

一方で、運用と保守の負担は自社側に発生します。性能の監視、バックアップ、パッチ適用といった作業を誰が担うのかを、導入前に決めておく必要があります。

Power Appsから接続する

Power Appsには多数のコネクタが用意されており、SQL Serverをはじめとする外部データベースにも接続できます。ただし、これらの多くはプレミアムコネクタに分類され、利用には有償ライセンスが必要です。

社内のサーバーにあるデータベースへつなぐ場合は、オンプレミスデータゲートウェイという中継の仕組みを別途構築します。ネットワークやセキュリティの調整が必要になるため、情報システム部門との連携が前提になります。

段階的に移行するという考え方

いきなり大掛かりな構成を目指す必要はありません。まずListsで小さく始め、件数や要件が増えた時点で移行するという進め方は十分に現実的です。

その際に効いてくるのが、最初の設計です。列名を分かりやすくする、1つの列に複数の意味を持たせない、キーになる項目を決めておく。この3点を守っておけば、後の移行がはるかに楽になります。

選び方の判断基準

候補が出そろったところで、絞り込みの基準を整理します。件数、構造、費用、体制の4軸で見ていくと、自社に合うものが自然に浮かび上がります。

件数と同時利用者数で見る

数千件までで、同時に使うのが十数人程度ならListsで問題ありません。数万件を超え、全社規模で使うならDataverse、数十万件以上ならSQL系というのが大まかな目安です。

件数は現在値ではなく、3年後の想定で考えてください。日次で数十件ずつ増えるデータは、数年で数万件に達します。増え方の見込みを最初に計算しておくと、選択を誤りません。

また、1件あたりの列数や添付ファイルの量も効いてきます。列が数十に及ぶ、1件ごとに複数のファイルを添付する、といった使い方では、件数が少なくても動作が重くなることがあります。

データ構造の複雑さで見る

1つの表で完結するならLists、複数の表が関連し合うならDataverseや外部データベースという分け方が基本です。Listsでも他リストの参照はできますが、関連が増えるほど管理が難しくなります。

判断に迷ったら、扱いたいデータを紙に書き出して線でつないでみてください。線が3本以上引かれるようなら、本格的な基盤を検討する段階に来ています。

ライセンスと費用で見る

費用は選択を左右する現実的な要素です。Listsは追加費用なし、Dataverseや外部データベース接続は有償ライセンスが必要という違いは、利用人数が多いほど大きく響きます。

費用対効果を見積もるときは、削減できる作業時間と比べます。月に何時間の手作業がなくなるのかを金額に換算し、ライセンス費用と並べて示せば、稟議での説明もしやすくなります。

作る人・直し続ける人で見る

見落とされがちですが、最も重要かもしれない軸です。現場の担当者が自分で列を追加したり画面を直したりできるのはLists、設計の知識が求められるのがDataverseや外部データベースです。

高機能な基盤を選んでも、触れる人が社内に1人もいなければ、変更のたびに外部へ依頼することになります。今いる人材で回せる範囲から始め、必要に応じて広げるほうが定着します。

▼ 選定と設計を伴走します 要件の整理からツール選定、作成、社内定着までを見据えてご提案します。何から手をつけるべきか整理したい段階でも構いません。 ＞ 相談予約はこちら

運用開始前に決めておくこと

どの選択肢を選ぶにせよ、作る前に決めておかないと後から直しにくい項目があります。権限、個人情報、バックアップ、体制の4つです。

権限設計を先に決める

誰が見られて、誰が編集できて、誰が削除できるのか。運用を始めてから権限を分けようとすると、既存データへの適用で手間がかかります。最初に決めておくのが鉄則です。

Listsの場合、アイテムごとに細かく権限を分ける設計は推奨されません。見せる範囲を分けたいなら、リスト自体を分ける、あるいは見せたい範囲だけを別のリストに同期する構成を検討してください。

個人情報を扱う場合の確認事項

顧客名簿や従業員情報を扱うなら、個人情報保護法上の義務が発生します。個人データの漏えいや滅失を防ぐため、必要かつ適切な安全管理措置を講じることが事業者に求められます（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」）。

ガイドラインでは、組織的、人的、物理的、技術的の各面で講じるべき措置の内容が示されています。クラウドに置けば自動的に満たされるわけではなく、アクセス権限の管理や取扱ルールの整備は自社の責任範囲です。

利用目的の特定、保管期間、退職者のアカウント処理まで含めて、運用ルールを文書にしておいてください。判断に迷う場合は、法務部門や専門家に確認することをおすすめします。

外部への共有リンクを許可するかどうかも、最初に方針を決めておきたい項目です。既定の設定のまま運用を始めると、意図しない範囲まで閲覧できる状態になっていることがあります。

バックアップと復旧の手段を確認する

クラウドだから安心、とは限りません。誤って大量のデータを削除した場合に、どこまで戻せるのかを事前に確認しておく必要があります。ごみ箱からの復元には保持期間があります。

重要なデータについては、定期的に別の場所へ書き出しておく仕組みを用意しておくと安心です。Power Automateで月次にエクスポートする程度でも、いざというときの選択肢が増えます。

触れる人を1人に限定しない

内製したデータベースで最も多い失敗は、作成者の異動とともに誰も触れなくなることです。部署内に最低2人は構造を理解している人を置き、設計の意図をメモとして残しておくことが確実な対策になります。

列の意味、選択肢の定義、他のリストとの関係。この3点を1枚にまとめておくだけで、引き継ぎの負担は大きく下がります。業務全体の整理の仕方は業務効率化アイデア55選の記事でもまとめています。

あわせて、社内で扱える人を増やす取り組みも並行して進めてください。ツールを導入するだけでは、使いこなせる状態にはなりません。育て方の考え方はAI研修の目的と選び方をまとめた記事も参考になります。

まとめ

Microsoft 365には「データベース」という単体製品はなく、Microsoft Lists、Access、Dataverse、外部データベースの4つから用途に応じて選ぶ形になります。まず検討すべきは、追加費用なしで使えるMicrosoft Listsです。

Listsは1つのリストに最大3,000万アイテムを格納でき、件数の上限が問題になることはほとんどありません。ただし1つのビューが扱えるのは5,000項目までというしきい値があるため、インデックスとフィルターでビューを分ける設計が前提になります。

複数のテーブルが関連し、部署ごとに権限を細かく分ける必要が出てきたらDataverse、件数が数十万件を超えるなら外部データベースへ。判断は、件数、構造、費用、そして社内で触れる人がいるかの4軸で行います。

そして、作る前に権限設計と個人情報の扱い、バックアップの手段を決めておくこと。触れる人を複数置くこと。この準備があれば、小さく始めて必要に応じて広げていく進め方が安全に取れます。

▼ 社内のデータ基盤づくりを、定着する形で進めませんか 株式会社ネクストスケールでは、業務の棚卸しからツール選定、アプリ構築、社内への定着支援までを一貫してご支援しています。何から手をつけるべきか整理したい段階でも構いません。まずはお気軽にご相談ください。 ＞ 相談予約はこちら