Dynamics 365 Finance and Operationsでデータベース容量、古いトランザクション、監査対応に悩んでいるなら、2026年4月更新のポイントは明確です。まず確認すべきは、Dataverse long-term retentionを使ったアーカイブ対象データではなく、Dataverse-managed data lakeへの同期問題、hotfix適用状況、最小ビルド要件、アーカイブジョブの実行可否です。
Microsoft Learnの「Archive data in Dynamics 365 finance and operations apps with Dataverse」は2026年4月23日に更新され、Finance and Operations appsの履歴データをDataverse long-term retentionへアーカイブする考え方に加え、2026年4月時点で運用担当者が注意すべき同期問題と修正方針が明記されました。特にdata engineers、DBAs、analytics leadersは、単に「古いデータを移す機能」と捉えず、ビルド確認、分析基盤への影響、容量レポート、履歴テーブルの扱いまで含めて判断する必要があります。(Microsoft Learn)
Dynamics 365の2026年4月更新で押さえるべき結論
今回の更新で最も重要なのは、Dynamics 365 Finance and Operations appsのデータアーカイブを本番運用する前に、環境が修正済みの状態かを確認する必要がある点です。
Microsoftは、一部のData Archiveシナリオで、Dynamics 365 finance and operations dataをDataverse-managed data lakeへ同期する際に、privateまたはinternalのフィールドがコピーされない同期問題を確認したと説明しています。対象フィールド自体はFinance and Operations側のテーブルに残っており、hotfixによって該当フィールドをpublic化し、不足分をDataverse-managed data lakeへコピーする方針が示されています。(Microsoft Learn)
実務上は、次の順番で確認するのが安全です。
| 確認項目 | 実務で見るポイント | 担当の目安 |
|---|---|---|
| hotfix適用状況 | 自社環境が修正対象ビルド以上か | DBA、F&O管理者 |
| アーカイブジョブ | 新規ジョブ作成が一時的に無効化されていないか | アプリ管理者 |
| 対象シナリオ | 自社が扱うデータ種別がサポート対象か | data engineer、業務部門 |
| 分析影響 | Fabric、Power BI、データレイク側で欠損やフィルター条件が変わらないか | analytics leader |
| 容量効果 | live table、history table、-Retainedテーブルを比較して削減効果を見る | DBA、FinOps担当 |
Dataverse long-term retentionによるアーカイブとは
Dynamics 365 Finance and Operations appsのデータアーカイブは、過去データを単純に削除する機能ではありません。Microsoftは、業務データのライフサイクルを「active data」「監査・法務・規制対応のために保持するhistorical/inactive data」「deleted data」の3段階で説明しています。アーカイブは、このうちhistorical/inactive dataを長期保持するための仕組みです。(Microsoft Learn)
Finance and Operations appsはactive data自体に上限を設けていないと説明されていますが、実際の運用では、大量の古い明細やトランザクションがライブテーブルに残り続けると、容量、照会性能、保守作業、分析クエリに影響します。そのため、監査上は残す必要があるが日常業務では頻繁に参照しないデータを、Dataverse long-term retentionへ移す判断が重要になります。(Microsoft Learn)
2026年4月更新ポイント：何が変わったか
GitHub上のMicrosoftDocs履歴を見ると、2026年4月には同じドキュメントに対して複数回の更新が行われています。更新内容は、同期問題の説明、hotfix、Proactive Quality Update、最小アプリケーションビルド、サポート対象データ種別の整理に集中しています。(GitHub)
| 更新ポイント | 内容 | 現場での判断 |
|---|---|---|
| 同期問題の明記 | Dataverse-managed data lake同期時にprivate/internalフィールドがコピーされないケースがある | アーカイブ済みデータを分析に使う前に、欠損の有無を確認する |
| hotfixと自動検出 | hotfix適用後、システムが更新を自動検出する | 手動適用するか、PQUを待つかをリリース計画に入れる |
| 2026年6月までのPQU | 環境バージョンに応じて、Proactive Quality Update経由で自動対応される可能性がある | 本番アーカイブ前にLCSや更新通知を確認する |
| 最小ビルド要件 | 10.0.45、10.0.46、10.0.47の最小アプリケーションビルドが提示された | 対象未満なら、本番実行を急がない |
| 新規アーカイブジョブの一時制御 | 修正支援のため、新規アーカイブジョブ作成が一時的に無効化される場合がある | 「機能が使えない」ではなく、修正プロセス中の制御として扱う |
特に注意したいのは、2026年4月23日の更新で、最小ビルド表からPlatform number列が削除され、アプリケーションビルドの要件が整理された点です。最新の公式ページでは、10.0.45は10.0.2345.220以上、10.0.46は10.0.2428.162以上、10.0.47は10.0.2527.94以上が最小アプリケーションビルドとして示されています。(Microsoft Learn)
対象データ種別：すべてのF&Oデータをアーカイブできるわけではない
Dataverse long-term retentionによるアーカイブは、Finance and Operations apps内のすべてのテーブルを自由に移動できる汎用削除ツールではありません。2026年4月時点の公式ページでは、サポート対象として次のデータ種別が示されています。(Microsoft Learn)
| サポート対象 | 実務での活用シーン |
|---|---|
| Dynamics 365 Finance General ledger | 長期監査、会計履歴、決算後データの保持 |
| Dynamics 365 Finance Tax transactions | 税務調査、法定保存、国・地域別の保持要件 |
| Dynamics 365 Supply Chain Management Inventory transactions | 大量明細によるライブテーブル肥大化対策 |
| Dynamics 365 Supply Chain Management Inventory journals | 棚卸、調整、入出庫履歴の長期保持 |
| Dynamics 365 Supply Chain Management Sales orders | 過去受注の参照、分析、監査対応 |
| Dynamics 365 Commerce transactions | 店舗・ECトランザクションの履歴管理 |
この一覧にないデータを、関連しているからという理由だけで自動的にアーカイブできると考えるのは危険です。Microsoftは、Inventory transaction tablesをアーカイブしてもsales tablesが自動的にアーカイブされるわけではない、という例を示しています。つまり、業務シナリオ単位で対象範囲を確認し、関連テーブルやカスタム拡張を別途評価する必要があります。(Microsoft Learn)
アーカイブ処理の流れを実務目線で理解する
アーカイブジョブは、Finance and operations archive workspaceから開始します。アプリケーション管理者は、サポート対象のfunctional scenarioに対して条件を指定し、該当データをDataverse long-term retentionへアーカイブします。(Microsoft Learn)
処理は大きく次の順番で進みます。
| ステップ | 処理内容 | 確認すべきこと |
|---|---|---|
| レプリケーション | live application tablesのデータをDataverse long-term retentionへ複製 | 対象テーブル、対象期間、想定件数 |
| アーカイブ準備マーク | 条件に一致するレコードをready for archivingとしてマーク | 条件設定ミスがないか |
| retained状態への変更 | Dataverse long-term retention側でアーカイブ済みとして扱う | 分析側でactive/inactiveの扱いを確認 |
| 照合 | ready for archivingにしたレコードがDataverse側に存在するか確認 | 欠損、同期遅延、対象外フィールド |
| 履歴テーブル移動 | live tableからhistory tableへ移し、live tableから削除 | 業務照会ページで必要な履歴が見えるか |
ここで誤解しやすいのは、Dataverse long-term retentionへ移したデータをそのままライブテーブルへ戻す機能ではない点です。公式ページでは、history tableからlive tableへ復元できる一方で、Dataverse long-term retention内のアーカイブデータをlive application tableへ直接戻すことはできないと説明されています。(Microsoft Learn)
data engineersが見るべきポイント
data engineersにとって重要なのは、アーカイブ後のデータがどこで、どの状態として見えるかです。Microsoftの別ページでは、Fabricを使ってlive dataとarchived dataを表示でき、Dataverse-managed data lake上ではmserp_プレフィックスのDataverseテーブルを利用し、msft_datastate列でactiveとinactiveを判別できると説明されています。(Microsoft Learn)
たとえば、分析用SQLやPower BIモデルで「現在有効な受注明細のみ」を見ている場合、アーカイブ後はmsft_datastate=0またはNULLを明示する必要が出る可能性があります。一方、監査レポートや長期傾向分析では、msft_datastate=1のarchived dataを含める設計が必要です。アーカイブはDBAだけの作業ではなく、データモデル、ETL、セマンティックモデル、KPI定義にも影響します。
DBAsが見るべきポイント
DBAsは、アーカイブを「容量削減策」として期待しがちですが、効果測定には注意が必要です。Microsoftは、Finance and Operations appsからDataverse long-term retentionへ移動したデータは平均して50%少ないdatabase capacityを消費すると説明しています。ただし、削減率はテーブルのデータ内容によって上下し、数百GB規模のデータで効果が見えやすいとされています。(Microsoft Learn)
また、history tableを残すかどうかで容量効果は大きく変わります。Finance and Operations apps内のhistory tableは、インデックスのない場合にlive tableより平均30%以上少ない容量を消費すると説明されていますが、in-app accessが不要ならhistory tableからの削除を検討することで最大限の容量削減につながります。ただし、公式ページ内には完全削除機能の提供タイミングに関する記述もあるため、本番計画では現在の環境で利用可能な機能状態を必ず確認してください。(Microsoft Learn)
容量確認では、Power Platform admin centerのレポートが重要です。Dataverse側ではアーカイブ済みのFinance and Operationsテーブルが<tablename>-Retainedのように表示され、Finance and Operations側ではlive tableとhistory tableの容量を確認できます。-Retainedテーブルが画面に見えない場合は、Excelへダウンロードして確認する方法も示されています。(Microsoft Learn)
analytics leadersが見るべきポイント
analytics leadersにとっての論点は、アーカイブによって「データが消えた」と誤認されないようにすることです。業務ユーザーは、画面やレポートで過去データが見えなくなると、障害やデータ欠損と受け止めることがあります。実際には、live table、history table、Dataverse long-term retention、Dataverse-managed data lakeのどこに存在するかが変わっているだけの場合があります。
そのため、アーカイブ前に次の3つを決めておくべきです。
| 決めること | 具体例 |
|---|---|
| 業務レポートの対象 | 日次売上はactiveのみ、監査レポートはarchivedも含める |
| データ状態の定義 | msft_datastate=0を現行、msft_datastate=1を長期保持として扱う |
| 問い合わせ窓口 | 「過去データが見えない」問い合わせをDBA、業務管理者、分析チームのどこで受けるか |
グローバル展開している企業では、国・地域ごとの税務・監査要件、リージョンごとの更新スケジュール、FabricやPower BIの利用権限も絡みます。PQUはリージョンやstationに応じて段階的に展開され、Microsoftは更新対象環境へ事前通知を行うと説明しています。(Microsoft Learn)
導入前チェックリスト
本番環境でアーカイブを始める前に、次のチェックを行ってください。
| フェーズ | チェック内容 | 失敗しやすいポイント |
|---|---|---|
| 環境確認 | 10.0.45、10.0.46、10.0.47の最小ビルド要件を満たすか | 古いビルドで本番ジョブを計画してしまう |
| 対象選定 | General ledger、Tax、Inventory、Sales orders、Commerceなど対象シナリオに含まれるか | 関連テーブルも自動対象だと誤解する |
| カスタマイズ確認 | custom fields、custom tablesをジョブ開始前に設定済みか | 後から追加した拡張項目が期待通りに含まれない |
| 分析確認 | Fabric、Power BI、ETLでactive/inactiveをどう扱うか | アーカイブ後にKPIが突然変わる |
| 容量測定 | live、history、-Retainedを比較できるか | 1つのレポートだけで削減効果を判断する |
| 復元方針 | history tableからlive tableへ戻す条件を決めているか | Dataverse long-term retentionから直接戻せると誤解する |
| 権限確認 | Microsoft Entra IDに基づくDataverse securityを確認する | アーカイブ後の閲覧権限を見落とす |
| 暗号化確認 | BYOK利用環境で長期保持データの暗号化方針を確認する | Microsoft-managed keyとcustomer-managed keyの扱いを確認しない |
Microsoftは、長期保持されたデータはread-onlyであること、Finance and Operations attachmentsは現在サポートされていないこと、Dataverse long-term retentionを伴うアーカイブ処理は複数段階でバックグラウンド実行され、最大14日かかる可能性があることも示しています。これらは本番スケジュール、監査対応、ユーザー説明に直結します。(Microsoft Learn)
よくある誤解と対策
アーカイブすればすぐ容量が減ると思っている
容量レポートへの反映には時間差があります。Microsoftは、history tableの容量削減が反映されるまで自動チューニングに最大7日、-RetainedテーブルのDataverse database capacity反映に最大1日かかる可能性があると説明しています。ジョブ直後に効果が見えなくても、失敗と判断する前に反映タイミングを確認してください。(Microsoft Learn)
アーカイブを削除やバックアップの代わりに使う
アーカイブは、不要データを消すための単純な削除機能ではありません。監査・法務・規制対応のために履歴データを安全に長期保持し、必要に応じて限定的に参照するための仕組みです。Dataverse long-term retentionでは、保持データはread-onlyであり、既存の削除運用やバックアップ設計とは目的が異なります。(Microsoft Learn)
カスタムテーブルも自動的に含まれると思っている
アーカイブフレームワークは、サポート対象のfunctional scenario内でcustom fieldsやcustom tablesを扱えますが、ジョブ開始前に設定しておく必要があります。また、functional scenario外の関連テーブルは、関連があっても自動的にはアーカイブされません。カスタム拡張が多い環境では、業務部門、開発チーム、DBAで対象範囲を明文化することが重要です。(Microsoft Learn)
新規アーカイブジョブが作れないことを障害と判断する
2026年4月更新では、同期問題の修正を支援するために、新規アーカイブジョブの作成が一時的に無効化される場合があると説明されています。一方で、進行中のスケジュール済みジョブは完了を許可し、同期問題が解決した後にアーカイブジョブを再有効化する方針です。ジョブ作成不可の状態を見たら、まず公式情報、環境バージョン、Microsoft Supportへの問い合わせ要否を確認してください。(Microsoft Learn)
本番導入のおすすめ手順
まず、Power Platform admin centerとFinance and Operations storage capacity reportで、容量を大きく消費しているテーブルを洗い出します。MicrosoftのFinance and Operations storage capacity reportでは、環境単位およびテーブル単位でストレージ消費を確認でき、CSVエクスポートや時系列トレンドの確認も可能です。(Microsoft Learn)
次に、対象データが公式にサポートされるシナリオに含まれるかを確認します。対象外データを無理にアーカイブ計画へ含めると、後で関連データの欠落、業務照会の不整合、分析モデルの混乱につながります。
その後、非本番環境で小さな期間・少ないデータ量からテストします。テストでは、ジョブ完了だけでなく、次の項目を確認してください。
| テスト観点 | 確認内容 |
|---|---|
| データ完全性 | 対象件数、主要フィールド、custom fieldsに欠損がないか |
| 業務画面 | history table経由で必要な照会ができるか |
| 分析 | Fabric、Power BI、ETLでactive/inactiveを正しく扱えるか |
| 容量 | live、history、-Retainedの容量変化を比較できるか |
| 権限 | アーカイブ後の閲覧者が適切に制御されているか |
| 運用 | 最大14日かかる可能性を前提に監視・連絡体制を作れるか |
最後に、本番導入では「いつ、どのデータを、どの条件で、どのレポートに影響させるか」を変更管理に載せます。特に四半期決算、棚卸、税務申告、監査対応の直前に初回アーカイブを実行するのは避けた方が安全です。
まとめ：2026年4月更新後にまずやるべきこと
Dynamics 365 Finance and Operations appsのDataverse long-term retentionアーカイブは、古いデータを整理しながら監査・法務・規制対応のために長期保持する有効な選択肢です。ただし、2026年4月更新では、Dataverse-managed data lakeへの同期問題、hotfix、最小ビルド、新規アーカイブジョブの一時制御が重要な確認ポイントになりました。
まずは自社環境のアプリケーションビルドを確認し、公式ページに示された最小ビルド以上かを見てください。そのうえで、サポート対象データ、custom fields、分析基盤、容量レポート、history tableの扱いを整理し、非本番環境で検証してから本番へ進めるのが現実的です。
読者が次に取るべき行動は、シンプルです。Power Platform admin centerで容量上位テーブルを確認し、F&O環境のビルドを照合し、対象シナリオごとに「残すデータ」「アーカイブするデータ」「分析で参照するデータ」を分けてください。これを行うことで、Dynamics 365のデータアーカイブを、単なる容量対策ではなく、グローバル環境でも通用するデータライフサイクル管理へ発展させられます。
コメント