Dataverse capacity-based storage は、Power Platform 管理センターで Dataverse の容量を「データベース」「ファイル」「ログ」に分けて確認・管理するための仕組みです。2026年6月2日時点で押さえるべきポイントは、Azure Storage アカウントそのものの仕様変更ではなく、Dataverse 容量の見え方、超過時の通知・制限、Dataverse Search と生成 AI/Copilot 体験への影響を管理者が正しく判断することです。
特に注意したいのは、容量が不足すると新しい環境の作成、環境のコピー、復元、試用環境から有料環境への変換、Dataverse データベースの追加などの管理操作に影響が出る点です。さらに、Dataverse Search のインデックスは検索や生成 AI 体験に関係するため、容量削減だけを目的に安易にオフにすると、Copilot 関連機能や検索機能が制限される可能性があります。
本記事では、Microsoft Learn の「Dataverse capacity-based storage details」をもとに、2026年6月更新で確認すべき変更点、影響範囲、管理者・開発者が取るべき実務対応を整理します。なお、公式ページ上の最終更新日は 2026-06-01 と表示されています。本稿では日本語圏の運用で確認される 2026年6月2日時点の情報として扱います。(Microsoft Learn)
Azure Storageの更新ではなく、Dataverse容量管理の更新として読むべき
まず整理しておきたいのは、この公式情報の中心は Azure Storage のストレージアカウント機能ではなく、Power Platform / Dataverse の容量ベースストレージ管理 だという点です。
記事内では、容量超過時の対応として「環境を従量課金プランにリンクし、超過分を関連する Azure サブスクリプションに課金する」選択肢が説明されています。つまり Azure との接点はありますが、Azure Portal で Blob Storage や Files を直接設定する話ではありません。(Microsoft Learn)
混同しやすいポイントを整理すると、次のようになります。
| 項目 | 誤解しやすい理解 | 正しい見方 |
|---|---|---|
| 対象 | Azure Storage アカウントの容量管理 | Dataverse の容量権利と使用量の管理 |
| 管理画面 | Azure Portal | Power Platform 管理センター |
| 容量区分 | Blob、File、Queue、Table など | Database、File、Log |
| Azureとの関係 | Azure Storageを直接増減する | 従量課金プランを Azure サブスクリプションに紐づける場合がある |
| Copilot/AIとの関係 | Azure StorageのAI機能更新 | Dataverse Search のインデックスが検索・生成AI体験に影響 |
Power Platform 管理者が見るべき場所は、Azure Portal のストレージアカウントではなく、Power Platform 管理センターの「ライセンス」「容量アドオン」「Dataverse」 です。Dataverse 容量は、テナント全体、環境単位、テーブル単位で確認できます。(Microsoft Learn)
2026年6月更新で押さえるべき主な変更点
2026年6月の更新は、既存の容量モデルを根本から変えるというより、容量通知・バナー表示・インデックス容量の説明をより明確にした更新 と見るのが実務上は自然です。
GitHub 上の更新履歴では、2026年6月1日のコミットとして「Dataverse capacity banner notification」が確認できます。差分では、バナー通知の見出しが「Dataverse capacity banner notifications」に整理され、Dataverse の合計容量が残り 15% 未満、または割り当て容量を超過した場合のバナー表示について説明が更新されています。(GitHub)
実務で重要な変更点は、次の3つです。
| 確認ポイント | 内容 | 実務上の影響 |
|---|---|---|
| 容量バナー通知の明確化 | Dataverse の合計容量が 15% 未満、または割り当て容量を超えると、Power Platform 管理センターや Power Apps などにバナーが表示される | 管理者だけでなく、システム管理者にも容量問題が見えやすくなる |
| バナー再表示の挙動 | Power Platform 製品では閉じても7日後に再表示され、モデル駆動型アプリでは画面更新時に再表示される | 一時的に閉じても問題は解決しない。根本対応が必要 |
| インデックス容量の説明整理 | Dataverse のデータベース容量には、行データだけでなく検索性能向上のためのインデックスも含まれる | データ件数が増えていなくても、検索設定や利用パターンで容量が変動する |
ここで重要なのは、通知が増えたこと自体ではありません。容量不足が、環境作成や復元などの運用作業を止めるリスクとして扱われている ことです。
Dataverse capacity-based storageの基本：Database・File・Logの違い
Dataverse capacity-based storage では、容量が大きく3種類に分けて表示されます。
| 容量タイプ | 主な対象 | 増えやすいケース |
|---|---|---|
| Database | Dataverse のテーブル行、メタデータ、リレーショナルデータ、インデックスなど | テーブル行の増加、検索インデックスの増加、複雑なデータ構造 |
| File | 添付ファイル、ファイル列、画像列、Annotation、Attachment など | PDF・画像・Officeファイルの添付、ファイル列の多用 |
| Log | AuditBase、PlugInTraceLogBase、Elastic tables など | 監査ログの有効化、プラグイントレースの増加、ログ保持期間の長期化 |
Microsoft Learn では、PDF などの添付ファイルはファイルストレージに保存される一方で、ファイルへアクセスするために必要な一部属性はデータベースに保存されると説明されています。また、AnnotationBase、Attachment、ファイル・画像型列を持つテーブルなどは、ファイルとデータベースの両方に関係します。(Microsoft Learn)
この仕組みを理解していないと、次のような判断ミスが起きます。
たとえば、営業活動の証跡として PDF 見積書を案件レコードに大量添付している場合、管理者は「案件テーブルの行数は大きく増えていないのに容量が増えている」と感じるかもしれません。しかし実際には、添付ファイルが File 容量を押し上げ、関連する属性やインデックスが Database 容量にも影響している可能性があります。
また、Microsoft は Dataverse の最適化の一環として、Annotation や Attachment などのファイル型データをデータベースからファイルストレージへ移動する場合があると説明しています。そのため、ある時点で Database 使用量が減り、File 使用量が増える動きがあっても、必ずしもデータ削除や障害を意味するわけではありません。(Microsoft Learn)
容量レポートで最初に見るべき場所
管理者が最初に確認すべきなのは、Power Platform 管理センターの容量レポートです。容量アドオンの概要ページを見るには、テナント管理者、Power Platform 管理者、Dynamics 365 管理者のいずれかのロールが必要です。(Microsoft Learn)
確認の流れは次のとおりです。
| 手順 | 操作 | 確認すること |
|---|---|---|
| 1 | Power Platform 管理センターにサインイン | 対象テナントが正しいか |
| 2 | サイドメニューで「ライセンス」を開く | 容量・製品別の管理画面に入る |
| 3 | 「容量アドオン」または「Dataverse」を選択 | テナント全体の容量と使用量を見る |
| 4 | Database / File / Log を切り替える | どの容量タイプが逼迫しているかを見る |
| 5 | 上位の環境を確認 | 容量を消費している環境を特定する |
| 6 | 環境を選択してテーブル別消費量を見る | 増加原因のテーブル・ファイル・ログを特定する |
Dataverse ページでは、テナント全体だけでなく、環境ごとの容量消費、従量課金プランのリンク状態、利用可能なテナントプールから容量を引き出せるかどうかなども確認できます。環境単位では、Database、File、Log の使用量に加え、テーブルごとの消費量や過去3か月までの日次傾向も確認できます。(Microsoft Learn)
容量不足の原因調査では、いきなりデータ削除に進むのではなく、次の順番で確認すると失敗しにくくなります。
- 逼迫しているのが Database、File、Log のどれかを確認する
- 上位消費環境を特定する
- 環境内で容量を使っているテーブルを確認する
- 最近のソリューション展開、監査設定、ファイル添付増加、Dataverse Search 設定変更を照合する
- 削除・アーカイブ・追加購入・従量課金化のどれで対応するか決める
容量不足時に起きること：15%、5%、超過の3段階で考える
容量管理で最も重要なのは、しきい値ごとに何が起きるかを把握することです。
Microsoft Learn では、Database、File、Log のいずれかの空き容量が 15% 未満になると容量制限接近の通知が発生し、5% 未満になると管理操作に影響する可能性がある警告が送られると説明されています。さらに、容量使用量が権利を超える「超過」状態になると、問題が解消されるまで一部の管理操作が利用できなくなります。(Microsoft Learn)
| 状態 | 目安 | 起きること | 管理者の対応 |
|---|---|---|---|
| 注意 | 残り15%未満 | 容量接近の通知、バナー表示 | 上位環境と容量タイプを確認する |
| 警戒 | 残り5%未満 | 管理操作への影響が警告される | 削減・追加購入・従量課金の判断を急ぐ |
| 超過 | 権利を超える | 一部の環境操作が使えなくなる | すぐに容量不足を解消する |
超過時に利用できなくなる操作として、公式情報では次の操作が挙げられています。
- 新しい環境の作成
- 環境のコピー
- 環境の復元
- 試用環境から有料環境への変換
- 環境の回復
- 環境への Dataverse データベース追加
これらは、開発・検証・障害復旧に直結する操作です。特に本番リリース前にサンドボックス環境をコピーする運用や、障害時にバックアップから復元する運用をしている組織では、容量不足がそのまま展開遅延や復旧遅延につながります。
超過分はどの容量で相殺できるのか
Dataverse の容量超過では、Database、File、Log の余りが常に自由に相殺されるわけではありません。
公式ドキュメントでは、追加のデータベース容量を使ってログやファイルの超過をカバーできる場合、追加のログ容量を使ってファイルの超過をカバーできる場合がある一方で、ファイルストレージの余りはログやデータベースの不足を補えないと説明されています。(Microsoft Learn)
実務では、次のように考えると判断しやすくなります。
| 不足している容量 | まず見るべき原因 | 対応の方向性 |
|---|---|---|
| Database | テーブル行、メタデータ、検索インデックス、Quick Find設定 | 不要データ削除、検索対象列の見直し、追加容量 |
| File | 添付ファイル、ファイル列、画像列 | ファイル保存方針の見直し、古い添付の退避、追加容量 |
| Log | 監査ログ、プラグイントレース、Elastic tables | ログ保持・トレース設定の確認、不要ログ削除、追加容量 |
たとえば File 容量に大きな余りがあっても、Database の不足を必ず救えるわけではありません。逆に、Database 側に余裕があれば Log や File の超過をカバーできるケースがあります。容量を購入する前に、どのタイプが不足しているかを必ず分けて確認してください。
管理者が確認すべき設定と運用ポイント
容量割り当ては「全環境に一律」ではなく、重要環境を優先する
Dataverse では、管理者が特定の環境に Database、File、Log の容量を割り当てられます。容量を割り当てた後は、その環境が容量内か、超過状態かを確認できます。容量の割り当て値は正の整数で、利用可能容量を超えないように指定する必要があります。(Microsoft Learn)
すべての環境に細かく割り当てる必要はありません。重要なのは、次のような環境を優先して監視・割り当てすることです。
- 本番環境
- リリース前検証に使うサンドボックス環境
- Dynamics 365 と連携している業務影響の大きい環境
- Copilot や生成 AI 機能の検証・本番利用がある環境
- ファイル添付や監査ログが多い環境
容量を事前に割り当てると、テナントレベルで他の環境が使える容量は減ります。そのため、「余っているから多めに確保する」よりも、「本番・検証・開発の用途別に必要量を決め、定期的に見直す」運用が現実的です。
通知を受け取る管理者ロールを確認する
容量通知は、テナント管理者、Power Platform 管理者、Dynamics 365 管理者に送られます。公式情報では、これらの通知を顧客がオプトアウトしたり、別のユーザーに委任したりするオプションは現時点でないと説明されています。(Microsoft Learn)
そのため、通知が届かない場合は、まず次を確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| 管理者ロール | 対象者がテナント管理者、Power Platform 管理者、Dynamics 365 管理者のいずれかか |
| メール運用 | 通知メールが個人だけに届き、運用チームで共有されていない状態になっていないか |
| しきい値超過状態 | すでに複数のしきい値を超えており、期待した通知パターンと異なっていないか |
| 退職・異動 | 管理者ロールが古い担当者に残っていないか |
運用上は、個人の受信箱に依存せず、容量レポートを定期点検項目に入れることが重要です。
従量課金プランをAzureサブスクリプションに紐づける前に確認する
容量超過への対応として、環境を従量課金プランにリンクし、超過分を Azure サブスクリプションへ課金する選択肢があります。(Microsoft Learn)
ただし、これは「とりあえずオンにすれば安心」という設定ではありません。Azure 側の課金責任者、Power Platform 管理者、業務部門の間で、次の点を確認してから進めるべきです。
| 確認項目 | 理由 |
|---|---|
| どのAzureサブスクリプションに紐づけるか | 部門別費用配賦や予算管理に影響する |
| 上限・アラート運用 | 想定外の容量増加に気づけるようにする |
| 一時対応か恒久対応か | 短期のリリース対応なのか、継続利用なのかで判断が変わる |
| 追加容量購入との比較 | 長期利用ならアドオン購入の方が管理しやすい場合がある |
| 削減施策との併用 | 不要ログや添付ファイルを放置したまま課金だけ増やさない |
特にファイル添付やログが急増している場合、従量課金化だけで根本原因を放置すると、後からコスト説明が難しくなります。
開発者・メーカーが注意すべき設計ポイント
Dataverse の容量問題は、管理者だけの問題ではありません。Power Apps、Power Automate、Dynamics 365、モデル駆動型アプリを作る開発者やメーカーの設計でも、容量の増え方は大きく変わります。
ファイル列・画像列・添付ファイルを安易に増やさない
ファイル列や画像列は便利ですが、業務設計なしに使うと File 容量が急増します。
たとえば、現場報告アプリで写真を1レコードに複数枚添付する場合、1日あたりの件数が少ない検証段階では問題が見えません。しかし、全拠点で本番展開すると、数か月で File 容量が急増することがあります。
設計時には、次を決めておきましょう。
- 本当に Dataverse にファイルを保存する必要があるか
- SharePoint や別の文書管理基盤で管理すべきファイルではないか
- 画像サイズや添付数に業務ルールを設けるか
- 古いファイルをアーカイブする運用があるか
- 削除・保持の責任者が決まっているか
監査ログとプラグイントレースは「必要な粒度」で使う
Log 容量は、監査ログや PlugInTraceLogBase などの影響を受けます。トラブルシューティングのために詳細ログを有効にすることはありますが、調査後も高いログレベルを放置すると、Log 容量を圧迫します。
開発・保守では、次の運用が有効です。
| シーン | 推奨対応 |
|---|---|
| 障害調査中 | 必要な範囲で詳細ログを有効化する |
| 調査完了後 | ログレベルを通常運用に戻す |
| 本番リリース後 | 一定期間だけ重点監視し、その後ログ量を見直す |
| 監査要件がある業務 | 法務・内部統制要件に合わせて保持方針を決める |
「容量が足りないからログを消す」ではなく、「業務上必要な証跡を残しつつ、不要なログを増やさない」設計が必要です。
Quick Findや検索対象列を増やしすぎない
Dataverse のデータベース容量には、検索性能を支えるインデックスも含まれます。Quick Find で多くの列を検索対象にすると、列数、データ型、行数、データ構造の複雑さに応じてインデックスサイズが増える可能性があります。(Microsoft Learn)
特に注意したいのは、複数行テキスト列を安易に検索対象へ入れるケースです。コメント、説明文、問い合わせ本文のような長いテキストを多くのテーブルで検索対象にすると、使い勝手は上がる一方で、インデックス容量や検索性能への影響が大きくなる可能性があります。
検索設計では、次の基準で見直してください。
- 業務ユーザーが本当に検索する列か
- 部分一致で探す必要があるか
- 複数行テキスト列を検索対象にする必要があるか
- 古いテーブルや使われていない列が検索対象に残っていないか
- Copilot や生成 AI 体験で必要なデータ範囲か
Dataverse SearchとCopilot/生成AIへの影響
今回の公式情報で特に重要なのが、Dataverse Search と生成 AI 体験の関係です。
Dataverse Search には、構造化データ、表形式データ、Dataverse に保存されたファイルなどを検索・生成 AI 体験で活用するためのインデックスが含まれます。この消費量は、環境レベルで DataverseSearch というテーブルとして報告され、以前は RelevanceSearch と呼ばれていました。(Microsoft Learn)
また、DataverseSearch テーブルには、グローバル検索と生成 AI 体験のためのインデックスデータが保存され、Copilot セマンティックインデックスも含まれると説明されています。(Microsoft Learn)
ここで避けるべき失敗は、容量削減だけを目的に Dataverse Search をオフにすることです。公式情報では、Dataverse Search をオフにすると、検索や生成 AI 会話機能など依存するすべての体験が制限または利用できなくなると説明されています。さらに、12時間を過ぎるとインデックス付き Dataverse データが完全に削除され、再度オンにした場合はフル同期が必要になります。(Microsoft Learn)
Dataverse Searchをオフにする前の判断基準
| 判断項目 | 確認内容 |
|---|---|
| Copilot利用有無 | Copilot Studio、モデル駆動型アプリ、生成AI機能で Dataverse データを参照していないか |
| 業務検索の重要度 | グローバル検索が日常業務に使われていないか |
| 再インデックス時間 | 大規模環境で再同期に時間がかかる前提を持っているか |
| 代替策 | 検索対象列の削減、不要テーブルの見直しで対応できないか |
| 影響周知 | オフにする場合、利用者・運用担当へ事前周知しているか |
Dataverse Search は、単なる検索機能ではなく、Copilot や生成 AI 体験の土台になることがあります。容量削減策としては最後の手段に近い扱いにし、まずは検索対象列や不要なテーブル、ファイル運用、ログ運用を見直すべきです。
移行・展開時に失敗しやすいポイント
Dataverse capacity-based storage の影響は、日常運用だけでなく、移行や展開でも表面化します。
新環境作成前に容量チェックを済ませる
容量超過時には、新しい環境の作成や環境コピー、復元が制限される可能性があります。開発プロジェクトでは、リリース直前にサンドボックスをコピーして最終検証するケースが多いため、容量不足が直前に発覚するとスケジュールに影響します。(Microsoft Learn)
リリース前チェックには、次の項目を入れてください。
| タイミング | チェック項目 |
|---|---|
| 要件定義 | ファイル添付、監査ログ、検索対象、Copilot利用有無 |
| 設計 | Database / File / Log の増加要因 |
| 移行リハーサル前 | テナント全体の残容量、上位消費環境 |
| 本番移行前 | 新環境作成・コピー・復元に必要な空き容量 |
| 本番移行後 | 日次トレンド、テーブル別容量、通知発生有無 |
旧モデルと新モデルの混在を確認する
2019年4月以降にストレージを購入した場合、またはそれ以前と以後の購入が混在している場合、Power Platform 管理センターでは Database、File、Log ごとの容量権利と使用量が表示されます。新しい容量モデル用のライセンスがある場合、新モデルのレポートが表示されます。(Microsoft Learn)
既存テナントでは、過去の契約、Dynamics 365 の購入経路、パートナー経由の契約が混在していることがあります。Microsoft パートナーを通じて Dynamics 365 サブスクリプションを購入している場合は、ストレージ容量管理についてパートナーへ確認する必要があります。(Microsoft Learn)
移行・更新時には、管理センターの数値だけでなく、契約・ライセンス担当者にも確認しておくと安全です。
「0GB表示」をそのまま信じない
容量レポートでは、Microsoft Teams、Trial、Preview、Support、Developer 環境は容量に対してカウントされず、0GB として表示されることがあります。また、既定環境には 3GB の Dataverse データベース容量、3GB の Dataverse ファイル容量、1GB の Dataverse ログ容量が含まれます。(Microsoft Learn)
0GB と表示されていても、実際の消費量を見たい場合は、その環境の容量分析ページで確認できます。開発者向け環境や試用環境で大量データを扱っている場合、本番移行後に容量影響が変わる可能性があるため、検証環境の数値だけで本番容量を見積もらないようにしましょう。
容量不足が見つかったときの対応手順
容量不足が見つかった場合は、慌てて追加購入する前に、原因と緊急度を切り分けます。
| 優先度 | 対応 | 判断基準 |
|---|---|---|
| 高 | 業務停止リスクの確認 | 環境作成、復元、コピーが必要な予定が近い |
| 高 | 上位消費環境の特定 | 特定環境だけが急増している |
| 中 | テーブル別消費量の確認 | Database / File / Log のどれが原因か分からない |
| 中 | 不要データ・ログの削除 | 業務上不要な添付、古いログ、不要環境がある |
| 中 | 検索設定の見直し | Quick Find、Dataverse Search、Copilot利用範囲が広すぎる |
| 低〜高 | 容量アドオン購入 | 継続的に必要な容量が明確 |
| 低〜高 | Azure従量課金プラン | 一時的または変動的な超過に対応したい |
公式情報では、容量不足に対して、ストレージの解放、不要な環境の削除、追加容量の購入が選択肢として挙げられています。(Microsoft Learn)
現場では、「削除できるデータがあるのか」「追加購入が必要なのか」「一時的なリリース対応なのか」を分けて考えることが大切です。ファイル添付やログが増え続ける設計のまま追加購入だけを続けると、同じ問題が繰り返されます。
管理者と開発者のための確認チェックリスト
最後に、Dataverse capacity-based storage の更新を受けて、すぐ確認すべき項目を整理します。
| 対象者 | 確認すること |
|---|---|
| テナント管理者 | 容量通知を受け取る管理者ロールが正しいか |
| Power Platform管理者 | Database / File / Log の残容量と上位消費環境 |
| Dynamics 365管理者 | 業務アプリの添付ファイル、監査ログ、検索利用状況 |
| 開発者 | ファイル列、画像列、Quick Find、プラグイントレースの設計 |
| Copilot担当者 | Dataverse Search をオフにした場合の生成AI体験への影響 |
| Azure管理者 | 従量課金プランを紐づける Azure サブスクリプションと予算管理 |
| 運用責任者 | 環境作成・コピー・復元が容量不足で止まらないか |
Dataverse capacity-based storage は、単に「容量が足りるか」を見るだけの機能ではありません。Power Platform の環境展開、Dynamics 365 の運用、Copilot/生成 AI 体験、Azure サブスクリプション課金まで関係する管理ポイントです。
まずは Power Platform 管理センターで、テナント全体の Database、File、Log の使用量を確認してください。次に、上位消費環境とテーブル別消費量を見て、添付ファイル、ログ、検索インデックス、Dataverse Search のどれが容量を押し上げているかを切り分けます。
容量が逼迫している場合は、不要データの削除、環境整理、検索設定の見直し、追加容量購入、Azure 従量課金プランのいずれで対応するかを判断します。特に Dataverse Search は Copilot や生成 AI 体験に影響するため、容量削減だけを理由にオフにせず、影響範囲を確認したうえで慎重に扱いましょう。
コメント