MENU

Dynamics 365の2026年4月更新ポイント：Finance & OperationsのPQUスケジュールと管理者が取るべき対応

Microsoft

Dynamics 365 Finance & Operationsを運用しているIT管理者にとって、2026年4月21日に更新されたMicrosoft公式ドキュメント「Release schedule for proactive quality updates」は、単なるスケジュール表ではありません。今回確認すべきポイントは、PQU（Proactive Quality Update）の適用時期、リージョンごとのStation割り当て、10.0.47以降の隔週ペースへの移行、そして本番反映前の検証期間です。

特に日本リージョンでは、Japan EastはStation 3、Japan WestはStation 4に分類されます。つまり、同じDynamics 365 Finance & Operationsでも、環境をどのAzureリージョンに配置しているかで、SandboxとProductionの更新タイミングが変わります。この記事では、2026年4月更新の要点を、IT admins、product owners、Microsoftエコシステム関係者がすぐ運用に落とし込めるよう整理します。(Microsoft Learn)

目次

Dynamics 365 Finance & OperationsのPQUとは何か

PQUは、Dynamics 365 Finance & Operations向けにMicrosoftが提供する累積的な品質更新です。主な目的は、既知の不具合修正や重要な品質改善を、次回の大きなサービス更新まで待たずに届けることです。

Microsoftの説明では、PQUはMicrosoft Dynamics Lifecycle Services環境に対してバックグラウンドで適用され、リージョンごとの段階的な安全展開プロセスに従います。問題が検出された場合に影響範囲を広げにくくするため、最初は限定されたグループに展開し、その後、より広いStationへ進む仕組みです。(Microsoft Learn)

実務上は、PQUを「小さな修正だから軽視してよいもの」と見るべきではありません。業務アプリ、帳票、バッチ、外部連携、カスタム拡張に影響する可能性があるため、Sandboxでの確認、本番反映日の把握、関係者への事前共有が必要です。

2026年4月21日更新で見るべきポイント

今回のMicrosoft Learn更新で重要なのは、PQUの考え方が変わったというより、今後の更新予定を判断するための情報が具体化されたことです。公式ページでは、Station-to-region mapping、高レベルのPQU train schedule、各PQUのSandbox／Production適用予定が掲載されています。(Microsoft Learn)

管理者がまず確認すべき項目は、次の4つです。

確認項目見るべき内容実務上の意味
Station-to-region mapping自社環境のリージョンがどのStationかSandboxとProductionの適用週を判断できる
High-level PQU train schedule10.0.45、10.0.46、10.0.47以降のPQU予定年間の検証・リリース計画に反映できる
Upcoming train schedule直近のPQUごとの具体的な適用日影響確認、社内告知、凍結期間調整に使う
App／Platform version適用されるアプリ・プラットフォームのバージョンカスタム開発や検証観点の整理に使う

特に10.0.47以降では、PQUの運用が従来より短いサイクルで進みます。MicrosoftのFAQでは、10.0.47からPQUが従来の28日サイクルから隔週ペースへ移行し、修正や改善をより早く届ける方針が示されています。(Microsoft Learn)

日本リージョンのStation割り当て

Dynamics 365 Finance & OperationsのPQUスケジュールを読むときは、まず自社環境のリージョンを確認します。公式ページのStation-to-region mappingでは、日本リージョンは次のように分類されています。(Microsoft Learn)

リージョンStation読み方
Japan EastStation 3比較的早い段階で更新されるグループ
Japan WestStation 4Japan Eastより後の週に更新されることがあるグループ

この違いは、単に表の分類上の違いではありません。たとえば、同じ10.0.47 Release-2でも、Station 3とStation 4ではSandboxとProductionの適用予定が異なります。

対象PQUStation 3Station 4
10.0.47 Release-2 Sandbox2026年4月27日〜4月30日2026年5月4日〜5月7日
10.0.47 Release-2 Production2026年5月2日〜5月3日2026年5月9日〜5月10日

Japan EastとJapan Westの両方を利用している企業や、グローバル展開で複数リージョンに環境を持つ企業では、「Dynamics 365の更新日」ではなく「環境ごとの更新日」として管理する必要があります。

直近で確認したいPQUスケジュール

2026年4月21日時点の公式ページでは、直近のPQUとして複数のtrain scheduleが掲載されています。特に実務で注意したいのは、10.0.45 Release-8、10.0.46 Release-3、10.0.47 Release-2です。(Microsoft Learn)

10.0.45 Release-8

10.0.45 Release-8は、App version 10.0.2345.212、Platform version 7.0.7690.141として掲載されています。

StationSandbox予定Production予定
Station 12026年4月27日〜4月30日N/A
Station 22026年5月4日〜5月7日2026年5月16日〜5月17日
Station 32026年5月5日〜5月8日2026年5月16日〜5月17日
Station 42026年5月11日〜5月14日2026年5月23日〜5月24日
Station 52026年5月18日〜5月21日2026年5月30日〜5月31日
Station 62026年5月19日〜5月22日2026年5月30日〜5月31日

10.0.46 Release-3

10.0.46 Release-3は、App version 10.0.2428.139、Platform version 7.0.7778.76として掲載されています。

StationSandbox予定Production予定
Station 12026年4月6日〜4月9日N/A
Station 22026年4月13日〜4月16日2026年4月25日〜4月26日
Station 32026年4月14日〜4月17日2026年4月25日〜4月26日
Station 42026年4月20日〜4月23日2026年5月2日〜5月3日
Station 52026年4月27日〜4月30日2026年5月9日〜5月10日
Station 62026年4月28日〜5月1日2026年5月9日〜5月10日

10.0.47 Release-2

10.0.47 Release-2は、App version 10.0.2527.93、Platform version 7.0.7858.80として掲載されています。

StationSandbox予定Production予定
Station 12026年4月22日〜4月25日N/A
Station 22026年4月27日〜4月30日2026年5月2日〜5月3日
Station 32026年4月27日〜4月30日2026年5月2日〜5月3日
Station 42026年5月4日〜5月7日2026年5月9日〜5月10日
Station 52026年5月11日〜5月14日2026年5月16日〜5月17日
Station 62026年5月11日〜5月14日2026年5月16日〜5月17日

ここで注意したいのは、表の「4日間の範囲」が、更新処理そのものに4日かかるという意味ではない点です。Microsoftは、Station内の対象環境を順次処理するため、どの環境が範囲内のどの日に更新されるかを事前に固定できないと説明しています。更新は各リージョンのdark hours内に実行されます。(Microsoft Learn)

PQUの通知とスケジュール公開のタイミング

PQUの詳細スケジュールと対応するbuild app version numberは、各PQU train開始の5日前に公開されます。また、Microsoftは更新対象となる環境の顧客に対して、リリース前に通知を送るとされています。(Microsoft Learn)

IT管理者は、次の通知経路を定期的に確認しておくべきです。

確認先目的
Microsoft 365 admin centerのMessage centerPQU通知の確認
Lifecycle Services（LCS）対象環境、更新、利用可能なbuildの確認
Power Platform admin center（PPAC）Maintenance Settingsや本番環境の更新設定確認
社内変更管理ツール業務部門、開発チーム、運用チームへの共有

MicrosoftのFAQでは、PQU通知はMicrosoft 365 admin centerのMessage centerで確認できると説明されています。PQUの変更内容を確認する場合は、Lifecycle ServicesのEnvironment detailsからAvailable Updatesを開き、対象buildをCSVまたはExcelへエクスポートして差分を確認する流れが示されています。(Microsoft Learn)

IT管理者が取るべき実務対応

PQUは「Microsoftが自動で適用するから任せればよい」というものではありません。自動適用であるほど、社内側の準備が重要です。

自社環境のStationを確認する

最初に行うべきことは、各環境のリージョン確認です。Dynamics 365 Finance & Operationsでは、Sandbox、UAT、Productionが同じリージョンとは限りません。プロジェクト統合や移行の履歴がある場合、環境ごとに配置リージョンが異なることもあります。

確認後、次のように管理表へ落とし込みます。

環境リージョンStation用途PQU確認担当
UATJapan EastStation 3業務検証情シス／業務部門
ProductionJapan EastStation 3本番IT運用責任者
Regression testJapan WestStation 4自動テスト開発チーム

この表を作っておくと、公式スケジュールが更新されたときに「どの環境がいつ影響を受けるか」をすぐ判断できます。

Sandbox反映後に検証する業務を決める

PQUは品質更新ですが、業務影響がゼロとは限りません。検証対象は、広く浅くではなく、業務停止リスクが高い領域に絞るのが現実的です。

優先度が高い検証項目は次のとおりです。

優先度検証対象具体例
高日次・月次の基幹業務受注、出荷、請求、支払、在庫締め、会計転記
高バッチ処理MRP、請求生成、仕訳転記、データ連携バッチ
高外部連携EDI、Dataverse連携、API連携、倉庫システム連携
中カスタム拡張独自フォーム、拡張テーブル、X++カスタマイズ
中帳票請求書、発注書、税関連帳票、電子帳票
低画面表示のみの軽微な操作検索、一覧表示、参照系レポート

すべてを手作業で確認しようとすると、隔週サイクルでは運用が破綻します。重要業務はチェックリスト化し、可能な範囲でRegression Suite Automation Toolなどの自動テストや、社内のテストスクリプトに組み込むことが現実的です。

Production適用日の前に変更凍結を設定する

ProductionのPQU予定日前後には、別の大きな変更を重ねないことが基本です。特に避けたいのは、PQU、独自カスタムのリリース、外部連携の仕様変更、データ移行、本番PITRなどが同じ週に重なるケースです。

MicrosoftのFAQでは、PQUと事前に予定された操作が同じメンテナンスウィンドウで競合する場合、PQUが次の利用可能なメンテナンスウィンドウへ再スケジュールされる場合があると説明されています。(Microsoft Learn)

現場では、次のようなルールを決めておくと混乱を減らせます。

期間推奨ルール
Sandbox適用日〜2営業日後主要業務シナリオの確認期間にする
Production適用日の3営業日前影響の大きいカスタムリリースを避ける
Production適用当日バッチ監視と連携監視を強化する
Production適用後の翌営業日問い合わせ、性能、エラー、未処理バッチを確認する

隔週PQUで運用はどう変わるか

10.0.47以降の隔週PQUは、管理者にとってメリットと負荷の両方があります。メリットは、重要な修正をより早く受け取れることです。一方で、検証や社内調整を従来の月次感覚で進めていると、スケジュールに追いつけなくなります。

従来型の運用では起きやすい問題

隔週化で起きやすい失敗は、次の3つです。

失敗パターン原因対策
Sandbox検証が終わらない毎回フルテストを実施しようとする重要業務に絞ったスモークテストを作る
業務部門への連絡が遅れるPQUをITだけの作業と見なしている月次の運用会議でPQUカレンダーを共有する
本番後にバッチエラーへ気づく更新後監視の担当が決まっていない適用後チェックリストと担当者を固定する

隔週PQUへの対応では、完璧なテストよりも、毎回確実に回せる最小限の検証セットを持つことが重要です。

Weekday update scheduleをどう考えるか

MicrosoftのFAQでは、Production環境について、従来の週末メンテナンスだけでなく、平日の更新スケジュールを選択できる仕組みも説明されています。PPACのMaintenance Settingsで希望日を選び、Maintenance Cadenceを設定する流れです。なお、Production環境はSandbox適用から少なくとも5日後に更新対象となる点は維持されます。(Microsoft Learn)

平日更新を選ぶかどうかは、業種や運用体制によって判断が分かれます。

選択肢向いているケース注意点
週末更新平日は業務負荷が高く、休日に監視できる体制がある月曜朝に問題が見つかると初動が遅れることがある
平日更新IT・業務部門が即時確認できる体制がある更新時間帯とグローバル業務時間の重なりに注意
複数曜日を選択更新遅延のリスクを下げたい社内カレンダーと変更管理の整合が必要

グローバル企業では、日本時間だけでなく、欧州、米国、アジア拠点の業務時間も考慮する必要があります。ひとつのFinance & Operationsインスタンスを複数タイムゾーンで使っている場合、特定国の休日だけを基準にすると、別地域の重要業務と重なることがあります。

PQUで特に注意すべき運用ポイント

PQUはnear-zero downtimeを前提に設計されていますが、「完全に何も起きない」という意味ではありません。MicrosoftのメンテナンスFAQでは、更新中もシステム利用は継続できる一方、短時間の切断や一部サービスへの影響が発生する可能性が説明されています。(Microsoft Learn)

バッチ処理は事前に確認する

Finance & Operationsでは、バッチ処理が業務の裏側を支えています。PQUの影響を受けやすいのも、画面操作よりバッチや連携処理です。

特に次のバッチは、更新前後に確認しておきます。

バッチ種別確認ポイント
会計転記系未転記、重複転記、途中停止がないか
請求・支払系請求書生成、支払提案、承認フローが正常か
在庫・生産系MRP、在庫評価、倉庫連携が遅延していないか
外部連携系API、EDI、Dataverse、データエンティティ連携の失敗がないか
帳票出力系定時出力、電子帳票、PDF生成が継続できるか

MicrosoftのメンテナンスFAQでは、バッチサーバーが一定時間利用できない場合や、サービスが実行中のバッチジョブを終了し、自動再開する場合があると説明されています。自動再開してほしくないジョブについては、再試行設定を確認することが重要です。(Microsoft Learn)

PQU適用後のロールバックは前提にしない

PQU適用後に問題が起きた場合、「すぐ前の状態へ戻せる」と考えるのは危険です。MicrosoftのFAQでは、他のコード昇格と同様に、PQU適用後のロールバックはできないと説明されています。(Microsoft Learn)

そのため、管理者が準備すべきなのはロールバック手順ではなく、次の3点です。

準備内容
早期検知適用後すぐに確認する画面、バッチ、連携、ログを決める
切り分けPQU起因か、カスタム変更起因か、外部システム起因かを判断する材料を残す
エスカレーションMicrosoft Supportへ起票する条件、社内連絡先、業務回避策を決める

問題が複数顧客へ影響する重大なものであれば、Microsoftがロールアウトを停止する場合があります。一方、特定環境だけの問題では、サポートチケットを通じた切り分けが必要です。(Microsoft Learn)

Product ownerが見るべきポイント

Product ownerや業務責任者は、PQUを技術部門だけの話として扱うべきではありません。PQUは業務アプリの安定性や不具合修正に関係するため、業務部門側にもメリットがあります。

ただし、次の観点は必ず押さえておきたいところです。

観点Product ownerが判断すべきこと
業務影響更新週に重要な締め処理、棚卸、決算、出荷集中日がないか
受け入れ確認誰がSandboxで主要業務を確認するか
優先順位すべての機能ではなく、止まると困る業務を優先できているか
社内告知本番更新後に利用者へ何を伝えるか
問題発生時業務回避策、問い合わせ窓口、判断者が決まっているか

PQU対応の成熟度が高い組織ほど、IT部門だけでスケジュールを見ていません。業務部門と同じカレンダーにPQU予定を入れ、検証担当と確認期限を明確にしています。

グローバル環境での注意点

Dynamics 365 Finance & Operationsをグローバルで使っている企業では、Station-to-region mappingの確認がさらに重要です。たとえば、日本、欧州、米国、インド、オーストラリアの環境が混在している場合、PQU適用タイミングはリージョンごとに異なります。

グローバル運用では、次のような管理方法が有効です。

管理対象推奨方法
リージョン別スケジュールStation単位でPQUカレンダーを作成する
業務カレンダー各国の祝日、決算日、出荷ピークを重ねる
検証テンプレート各拠点で同じ観点のスモークテストを使う
障害連絡タイムゾーン別の一次対応者を決める
変更管理PQU、独自開発、外部連携変更を同じボードで管理する

特に「日本では問題がなかったが、欧州の本番更新後に別の処理で問題が出た」というケースを避けるには、国ごとの業務差分をテスト観点に含める必要があります。税、請求、支払、ローカライズ、帳票、銀行連携は地域差が出やすい領域です。

今回の更新を受けたチェックリスト

2026年4月更新を受けて、IT管理者がすぐ実施すべき作業をチェックリスト化すると次のようになります。

チェック作業内容
□自社のDynamics 365 Finance & Operations環境のリージョンを確認する
□Japan EastはStation 3、Japan WestはStation 4としてスケジュールを読み替える
□10.0.45、10.0.46、10.0.47のどのPQUが自社環境に関係するか確認する
□Sandbox適用予定日とProduction適用予定日を社内カレンダーへ登録する
□Microsoft 365 admin centerのMessage center通知を確認する
□LCSで対象buildと更新情報を確認する
□主要業務、バッチ、外部連携、帳票の検証担当を決める
□本番適用日前後のカスタムリリースやデータ移行を調整する
□Production適用後の監視項目と初動対応者を決める
□問題発生時のMicrosoft Support起票基準を明確にする

このチェックリストは、1回限りではなく、PQUのたびに使い回せる形で整備しておくと効果的です。隔週サイクルに対応するには、都度ゼロから確認する運用ではなく、標準化された確認フローが必要です。

Dynamics 365の2026年4月更新ポイントまとめ

2026年4月21日に更新された「Release schedule for proactive quality updates」は、Dynamics 365 Finance & OperationsのPQU運用を見直すきっかけになります。最大のポイントは、更新スケジュールの把握をMicrosoft任せにせず、自社のリージョン、Station、Sandbox検証、本番適用日、業務カレンダーを結び付けて管理することです。

日本環境では、Japan EastがStation 3、Japan WestがStation 4です。10.0.47以降は隔週PQUの流れも意識する必要があります。これまで月次の感覚で更新確認をしていた組織は、検証項目を絞り、通知確認と本番後監視を定型化しなければ追いつきません。

まずは、自社環境のStationを確認し、直近のPQU予定を社内カレンダーへ反映してください。そのうえで、Sandbox適用後に確認する業務シナリオを10〜20項目程度に絞り、毎回同じ品質で確認できる運用へ切り替えることが、2026年以降のDynamics 365運用では重要になります。

Microsoft
Dynamics 365 Microsoft Learn PQU Finance and Operations

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次