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 schedule | 10.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 East | Station 3 | 比較的早い段階で更新されるグループ |
| Japan West | Station 4 | Japan Eastより後の週に更新されることがあるグループ |
この違いは、単に表の分類上の違いではありません。たとえば、同じ10.0.47 Release-2でも、Station 3とStation 4ではSandboxとProductionの適用予定が異なります。
| 対象PQU | Station 3 | Station 4 |
|---|---|---|
| 10.0.47 Release-2 Sandbox | 2026年4月27日〜4月30日 | 2026年5月4日〜5月7日 |
| 10.0.47 Release-2 Production | 2026年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として掲載されています。
| Station | Sandbox予定 | Production予定 |
|---|---|---|
| Station 1 | 2026年4月27日〜4月30日 | N/A |
| Station 2 | 2026年5月4日〜5月7日 | 2026年5月16日〜5月17日 |
| Station 3 | 2026年5月5日〜5月8日 | 2026年5月16日〜5月17日 |
| Station 4 | 2026年5月11日〜5月14日 | 2026年5月23日〜5月24日 |
| Station 5 | 2026年5月18日〜5月21日 | 2026年5月30日〜5月31日 |
| Station 6 | 2026年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として掲載されています。
| Station | Sandbox予定 | Production予定 |
|---|---|---|
| Station 1 | 2026年4月6日〜4月9日 | N/A |
| Station 2 | 2026年4月13日〜4月16日 | 2026年4月25日〜4月26日 |
| Station 3 | 2026年4月14日〜4月17日 | 2026年4月25日〜4月26日 |
| Station 4 | 2026年4月20日〜4月23日 | 2026年5月2日〜5月3日 |
| Station 5 | 2026年4月27日〜4月30日 | 2026年5月9日〜5月10日 |
| Station 6 | 2026年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として掲載されています。
| Station | Sandbox予定 | Production予定 |
|---|---|---|
| Station 1 | 2026年4月22日〜4月25日 | N/A |
| Station 2 | 2026年4月27日〜4月30日 | 2026年5月2日〜5月3日 |
| Station 3 | 2026年4月27日〜4月30日 | 2026年5月2日〜5月3日 |
| Station 4 | 2026年5月4日〜5月7日 | 2026年5月9日〜5月10日 |
| Station 5 | 2026年5月11日〜5月14日 | 2026年5月16日〜5月17日 |
| Station 6 | 2026年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 center | PQU通知の確認 |
| 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確認担当 |
|---|---|---|---|---|
| UAT | Japan East | Station 3 | 業務検証 | 情シス／業務部門 |
| Production | Japan East | Station 3 | 本番 | IT運用責任者 |
| Regression test | Japan West | Station 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運用では重要になります。
コメント