Microsoft 365 Business Basic で Power Apps を「テスト環境」「本番環境」に分けようとしたら、環境作成で「DB 容量 1GB が必要」と止まることがあります。これは SharePoint の容量ではなく、Power Platform 側の Dataverse 容量が原因です。仕組みと、現実的な解決策を整理します。
結論：このエラーは「Dataverse のデータベース容量」が足りないサイン
環境作成時に表示される下記エラーは、端的に言えば「新しい環境を作るための Dataverse データベース容量が、テナントに 1GB 以上“空いていない（または付与されていない）”」という状態を示しています。
This environment can't be created because your org (tenant) needs at least 1 GB of database capacity.
重要なのは、環境の作成が“データベース容量（Dataverse Database Capacity）”を基準に判定される点です。最近の仕様では、Dataverse を使う／使わないに関わらず、環境をプロビジョニングするには 1GB の利用可能容量が必要で、作成される環境は少なくとも 1GB を消費します。
さらに厄介なのは、「既定（デフォルト）環境には容量が含まれているのに、新規環境は作れない」パターンがあることです。既定環境には Dataverse 容量が含まれますが、新しい環境を作成する前の容量チェックでは、既定環境に含まれる容量は計算から除外されるため、テナントとして追加環境を作るには“別枠の容量”が必要になります。
「DB 容量 1GB」は SharePoint の容量ではない
「SharePoint リストしか使わないのに、なぜ DB？」と混乱しやすいのですが、ここで言う DB は SharePoint ではありません。Power Platform（Dataverse）側の容量です。混同しやすい容量を整理すると、次のとおりです。
| 容量の種類 | どこに効く？ | 主な用途 | 今回のエラーと関係 |
|---|---|---|---|
| SharePoint ストレージ | Microsoft 365（SharePoint/OneDrive） | サイト、ドキュメント、リストの添付など | 基本的に無関係 |
| Dataverse Database Capacity | Power Platform（Dataverse） | Dataverse のテーブル（レコード）やソリューションのメタデータ | 直撃 |
| Dataverse File Capacity | Power Platform（Dataverse） | ファイル列/画像列、添付、Web リソースなど | 基本は無関係（DB が足りないと解決しない） |
| Dataverse Log Capacity | Power Platform（Dataverse） | 監査ログなど | 基本は無関係 |
実際、「容量を買ったのに解決しない」相談で多いのが、File Capacity を買ってしまっているケースです。環境作成エラーが求めているのは “Database” であり、File を増やしても作成できないことがあります。
なぜ Microsoft 365 Business Basic で起きやすいのか
Business Basic の利用者が Power Apps を触れるのは、主に Microsoft 365 に含まれる「Power Apps for Microsoft 365」の範囲です。この範囲では、Microsoft 365 データ（SharePoint など）や標準コネクタを使ってアプリを作成・共有・実行できます。
一方で、テスト／本番で環境を分離して ALM（Application Lifecycle Management）を回そうとすると、「ソリューション」「環境変数」「接続参照」など、Power Platform の“環境”を前提にした機能を使うことになります。ソリューションは、アプリやフローなどの部品を環境間で運ぶための仕組みで、Power Platform で ALM を実装する中核です。
ここでポイントになるのが、Microsoft 365 ライセンスに“Dataverse”という表示が出る場合があっても、それは「Microsoft 365 アプリが内部的に Dataverse を使うための限定機能」であり、Power Apps で自由に Dataverse を使ってカスタムアプリを作れる権利とは別だという点です。
その結果、Business Basic だけのテナントでは、追加環境を作るために必要な Dataverse のデータベース容量が“実質 0”扱いになり、環境作成のタイミングで「1GB 必要」と止まることが起きます（既定環境の含有容量はチェック対象外）。
「環境を分けたい」だけで要件が変わる理由
SharePoint リストだけで完結するキャンバスアプリでも、運用を“個人の作業”から“組織のアプリ運用”に寄せると、環境分離が欲しくなります。よくある目的は次のとおりです。
- テストで壊しても本番に影響しないようにしたい
- 接続先（SharePoint サイト／リスト）を環境ごとに切り替えたい
- 更新を「管理されたソリューション」で安全に配布したい
- 権限（Maker/管理者/利用者）や DLP を環境ごとに分離したい
これらを “作法どおり” にやろうとすると、だいたいソリューション運用になります。ソリューションのインポートでは、接続参照（connection references）や環境変数（environment variables）が含まれる場合、インポート時に設定を求められるのが一般的です。
まず確認：自分のテナントは「容量ゼロ」なのか「容量不足（超過）」なのか
対処を最短にするために、まず Power Platform 管理センターで状況を可視化します。見るべきは「Dataverse Database（データベース）容量」です。
- Power Platform 管理センターで「Licensing（ライセンス）」→「Dataverse」→「Manage capacity（容量の管理）」へ
- Database / File / Log の「Entitled（権利）」「Used（使用）」「Available（空き）」を確認
容量レポートでは、「Org（テナント既定）」「User licenses（ユーザーライセンス由来）」「Additional storage（追加購入）」のように“どこから容量が来ているか”も分かります。
もしテナントが容量超過状態（entitlement を usage が上回る）だと、管理操作が制限され、環境作成・コピー・復元などがブロックされます。環境作成が止まるのが「容量ゼロ」なのか「超過」なのかで、打ち手が変わります。
なぜ「既定環境があるのに作れない」のか
Power Platform には “既定（デフォルト）環境” が必ず存在します。既定環境はテナントごとに自動作成され、すべてのユーザーが共有します。また、既定環境には Dataverse 容量が含まれます。
ただし、既定環境はバックアップ保証がなく、本番ワークロードに使うべきではないという位置づけであり、さらに新規環境作成の容量チェックでは、既定環境の含有容量が除外されるという仕様が明記されています。つまり「既定環境に 3GB あるから 1GB 余ってるはず」という考え方は通用しません。
解決策：何を購入すれば「1GB」を満たせるのか
ここからが本題です。購入の方向性は大きく分けて 4 つあります。ポイントは「容量を得る」だけなのか、「利用者のライセンスも同時に整理したい」のかです。
| 選択肢 | 向いているケース | 環境作成（容量） | 利用者の権利 | 注意点 |
|---|---|---|---|---|
| Power Apps Premium（ユーザー単位） | 今後 Dataverse や Premium コネクタも視野に入る／まずは簡単に前進したい | テナントに容量が付与されやすい | Premium アプリの利用権も付く | Premium 機能を使うなら利用者にもライセンスが必要 |
| Power Apps per app（アプリ単位） | Premium が必要なアプリは少数／利用者を限定できる | 環境に割り当てて使う運用 | 「特定アプリ」に対して付与 | 管理センターで環境へ割当が必要 |
| Dataverse Database capacity add-on（容量アドオン） | とにかく環境作成の 1GB を満たしたい／容量だけ増やしたい | 1GB 単位で追加購入できる | 容量は増えるが“利用権”は別問題 | 契約形態によって購入や割当の流れが変わることがある |
| Pay-as-you-go（従量課金） | 利用人数や利用頻度が読めない／まずは小さく始めたい | Azure サブスクリプションで従量 | 月間の利用者数に応じて課金（個別ライセンス無しの選択肢） | 請求・ガバナンスを Azure 側で管理する必要がある |
per app プランは「特定の環境で、特定の業務シナリオ向けに 1 アプリ（または 1 ポータル）を実行する」用途に向けた説明があり、環境に割り当てて運用します。
また、従量課金（Pay-as-you-go）は、Azure サブスクリプションを使い「月にそのアプリを使ったユニークユーザー数」に応じて後払いで運用できる、という FAQ 記載があります。
容量アドオンについては、Dataverse の Database/File/Log を1GB 単位で追加購入できることが、ライセンスガイドで案内されています。
「標準コネクタ＋SharePoint だけ」なのに Premium が必要に見える理由
ここが一番誤解されやすいポイントです。整理すると、論点は 2 つあります。
- アプリが Premium かどうか（＝利用者に Premium ライセンスが必要か）
- 環境を作れるだけの Dataverse 容量がテナントにあるか
環境を分ける ALM では Dataverse（＝データベースを持つ環境）が関わるため「Premium 必須」と見えがちです。しかし、環境変数のドキュメントでは、ALM は Dataverse を要するが、Premium コネクタの使用は必須ではない（ただし Dataverse コネクタで環境変数テーブルを直接触る場合は例外）と整理されています。
つまり、環境を分けてソリューションで配布する＝ただちに利用者全員が Premium になるとは限りません。アプリが SharePoint など標準コネクタのみで完結しているなら、利用者側は Microsoft 365 の範囲で足りる可能性があります（ただし、組織の契約やアプリ構成により判断が揺れるため、最終的には Microsoft のライセンス文書／販売店の見解で確認するのが安全です）。
一方で、環境作成には最低 1GB の利用可能な Dataverse データベース容量が必要で、環境の数だけ下限容量が積み上がるので、Business Basic のままだとそこで詰まります。
10ユーザー利用のライセンス設計：現実的な考え方
「開発者だけ 1 本買えばいいのか？ 10人全員必要か？」は、アプリが Premium かどうかで分かれます。ここでは、SharePoint リストをデータソースにした“標準コネクタのみ”という前提から、現実的な分岐を作ります。
| 運用パターン | 利用者（10人） | 開発／管理 | 環境分離（テスト／本番） | コメント |
|---|---|---|---|---|
| 標準コネクタのみ・既定環境で運用 | M365 の範囲で足りることが多い | M365 の範囲で作成・共有 | 分離しない | 最安だが、ガバナンス／変更管理は工夫が必要 |
| 標準コネクタのみ・テスト／本番で環境分離 | M365 の範囲で足りる可能性あり | 環境作成のための容量（or プラン）を用意 | 分離する | 「容量」だけがボトルネックになりやすい |
| Dataverse をデータソースに使う／Premium コネクタを使う | 原則、利用者ごとに Premium 相当の権利が必要 | Premium 前提 | 分離するのが基本 | この場合は「開発者だけ」では満たしにくい |
| 利用頻度が読めない・短期案件 | Pay-as-you-go で月単位最適化 | Azure 請求で管理 | 分離は構成次第 | 費用配分とガバナンスを設計できる組織向き |
大事なのは、環境分離は「運用・統制の要件」であり、Premium ライセンスは「Premium 機能の利用権」だという切り分けです。環境分離のためにまず必要になるのは、環境作成に必要な容量（最低 1GB×環境数）です。
Power Apps Developer Plan は使える？使えない？
Power Apps Developer Plan は、開発・検証のための無料プランとして非常に便利です。Dataverse を含む開発環境が提供され、ソリューションのエクスポートもできます。
ただし、Developer Plan はあくまで開発・テスト目的で、容量にも上限があります（例：データベースサイズ 2GB、フロー実行回数など）。また、非アクティブが続くと環境が無効化される旨も明記されています。
| 項目 | Developer Plan | 本番（Production / Sandbox） |
|---|---|---|
| 目的 | 開発・検証 | 運用（本番／テスト） |
| Dataverse | 利用可能 | 構成次第（ALM をするなら基本的に有り） |
| 容量 | 上限あり（拡張不可） | ライセンス／アドオンで拡張 |
| 用途の相性 | ソリューション作成・試験に最適 | 管理されたソリューションの配布・運用に最適 |
現実的には、開発は Developer Plan、テスト／本番は有償環境という役割分担が、コストと統制のバランスが良いことが多いです。
SharePoint リスト運用で「テスト／本番」を分けるときの実務ポイント
今回の前提である「SharePoint リストをデータソースにする標準コネクタのみ」の場合、環境分離のボトルネックは “容量” になりがちですが、実務ではもう 1 つ落とし穴があります。SharePoint のサイト／リストは、同名で作り直しても内部 ID が一致しないことです。
環境変数のドキュメントでは、SharePoint の場合はサイトとリストに対して環境変数が必要で、さらに「同じ名前・列で作っても内部識別子が一致しないため、ターゲット環境で動かないことがある」点に触れています。確実にメタデータを一致させる方法として、SharePoint サイトを複製（コピー）して使うことが挙げられています。
テスト／本番分離を成功させるには、Power Apps 側より先に、SharePoint 側の「データの分け方」を決めるのが近道です。
- テスト用サイトと本番用サイトを分ける（URL も別）
- リストは“作り直し”よりも、サイト複製＋必要に応じてサンプルデータで揃える
- ソリューションには、接続参照（SharePoint 接続）と環境変数（サイト／リスト）を入れて、インポート時に差し替える
ソリューションのインポートでは、接続参照があれば接続の選択を促され、環境変数があれば値の入力を促されます。ここを「手順化」しておくと、テスト→本番の移行がかなり安定します。
最短で解決するためのチェックリスト
- 環境をいくつ作りたいかを先に決める（テスト＋本番なら最低 2）
- Power Platform 管理センターで Dataverse Database の Available を確認
- Available が不足なら、容量が付与される購入（Premium／per app／容量アドオン／従量）のどれで進めるか決める
- 環境作成後、ソリューションで配布するなら接続参照と環境変数を前提に組む
- SharePoint を分けるなら、サイト複製（内部 ID の整合）を意識する
よくある落とし穴（特に Business Basic で多い）
- 既定環境に容量があるのに環境が作れない：既定環境の含有容量は新規環境作成チェックで除外されます。
- File Capacity を買ってしまった：環境作成で必要なのは Database 側のことが多いです。
- 容量超過で管理操作が止まっている：超過状態だと環境作成などがブロックされます。
- 「ソリューション＝Premium 必須」と決めつけて過剰見積もり：ALM は Dataverse を要しますが、Premium コネクタ利用が必須とは限りません（例外あり）。
- SharePoint を同名で作り直して動かない：内部識別子の不一致が原因になり得ます。
まとめ：Business Basic で詰まったら「容量」と「利用権」を切り分けて考える
この「DB 容量 1GB が必要」エラーは、アプリの作り方が悪いというより、環境分離をするための Dataverse 容量（テナント側の権利）が足りていないことが原因です。しかも最近は、環境作成自体が 1GB 以上の利用可能容量を前提に判定されるため、Business Basic 単体のテナントでは躓きやすくなっています。
解決の近道は、まず「テスト／本番で何環境必要か」を確定し、その数×1GB を最低ラインとして、Premium／per app／容量アドオン／従量のどれで容量を確保するかを決めることです。利用者 10 人のライセンスは、アプリが Premium（Dataverse をデータソースにする、Premium コネクタを使う等）かどうかで最終判断します。
コメント