Dynamics 365やPower Platformの導入・運用を担当していると、「次の標準機能を待つか、今カスタマイズするか」という判断が必要になります。
この判断を支えてきた製品情報の確認方法が、いま変わろうとしています。
Microsoftは2026年8月25日、Dynamics 365、Power Platform、Dataverseのロードマップ情報を、9月から「AI at Work roadmap」に統合すると発表しました。年2回のRelease Wave単位の発表から、計画が固まり次第、継続的に情報を公開する方式への移行です。Microsoft公式発表
私がこの変更で重要だと考えるのは、情報の掲載先ではありません。製品情報を確認するタイミングと、プロジェクトとして意思決定するタイミングを、これまで以上に意識して分ける必要があるという点です。
1. 何が変わり、何が変わらないのか
まず、2026年9月25日時点で確認できる公式情報を整理します。
- 新しい機能計画は、9月からAI at Workロードマップで公開されます。
- 既存情報の移行対象は、Public PreviewまたはGAの日付が2026年6月1日以降の項目です。移行は9～11月に進む予定です。
- Release Plannerは、2026年11月15日までに移行を完了して終了する予定です。
- My Release Plansの個人用保存ビューは、終了後に引き継がれるわけではありません。
これは情報公開の変更であり、製品の開発・リリース・展開方法そのものを変更する発表ではありません。テナントに関係する通知は引き続きMessage Center、実装のための製品ドキュメントはMicrosoft Learnが担います。Microsoft公式発表・移行FAQ
Microsoft Learnの2026 release wave 1ページにも、9月以降は新たなRelease Plansを公開せず、既存の計画は履歴参照用として残す旨が掲載されています。なお、同ページの対象期間は2026年4～9月です。Power Platform 2026 release wave 1
つまり、「Release Waveの発表方式が変わる」ことと、「既存環境の更新がすべて別の方式になる」ことは同じではありません。移行途中のいまは、旧ページが残っていることだけを理由に、そこを今後の情報収集の中心にし続けないことが大切です。
2. 「提供予定」と「プロジェクトで採用可能」を分ける
ここからは、公式発表を踏まえたコンサルタントとしての提案です。Microsoftの必須手順ではありません。
ロードマップで注目する機能を見つけても、そのまま要件定義書の実装方針を「標準機能で対応」に変更するのは早計です。
少なくとも、次の三つを別々に確認するべきだと考えます。
- 製品側の状態：開発中か、プレビューか、正式提供か。
- 対象環境の条件：必要な地域・言語・ライセンス・管理設定などの条件を満たせるか。
- 業務としての受入可否：必要な操作、権限、例外処理、運用責任まで確認できたか。
これは、特定の新機能に必ず地域制限や追加ライセンスがあるという意味ではありません。採用判断の際に、機能ごとの条件を確認するための観点です。
リリース計画にも、提供時期や内容は変更される可能性があると明記されています。そのため、計画上の提供月を、顧客への利用開始の確約日として扱うべきではありません。リリース計画の注意事項
例えば、将来の標準機能で帳票作成の一部を置き換えられそうだとします。しかし、求める帳票形式、権限別の出力、例外時の処理まで満たせるかは、機能名からは判断できません。
この段階の要件評価は「標準対応確定」ではなく、「標準機能の採用候補・検証待ち」とするほうが、後の説明責任を果たしやすくなります。
3. 機能一覧ではなく「判断台帳」を作る
新しいロードマップへのリンクを共有するだけでは、担当者によって読み取り方が変わります。そこで提案したいのが、注目機能と業務要件をつなぐ小さな判断台帳です。
| 管理項目 | 残しておきたい内容 |
|---|---|
| 対象機能 | 機能ID、名称、公式URL |
| 確認時点 | 確認日、その時点の公開状態・提供予定 |
| 関連要件 | 要件ID、業務上の課題、期待する改善 |
| 未確認事項 | 利用条件、制約、既存設計との整合性 |
| 次の判断 | 調査継続、検証着手、採用、保留、不採用 |
| 責任と期限 | 確認担当者、決裁者、次回判定日、代替案 |
この台帳は、製品ロードマップの複製を目的としません。記録するのは「その情報を受けて、自分たちがどう判断したか」です。
特に残したいのは、判断時点の情報です。後から提供予定が変わっても、当時何を前提として見積もりや設計を行ったかが分かれば、変更の影響を説明できます。
また、採用しなかった理由も残します。「機能が足りなかった」のか、「今回の検証期間に間に合わなかった」のかで、次回の見直し方は変わるからです。
4. 情報確認は短く、採用判断は必要な人で行う
継続的に情報が出るからといって、すべての関係者が毎日ロードマップを読む必要はありません。
例えば、次のように活動を分けます。
- 週次の確認：担当者が対象製品の変化を確認し、関連要件のある項目だけ台帳に追加する。
- 月次の判断：コンサルタント、技術担当、業務責任者が、検証する価値と優先順位を決める。
- リリース前の再確認：採用を決めた機能について、条件や動作を確認し、未解決事項があれば方針を見直す。
この頻度はあくまで一例です。小規模な導入なら月次中心でもよいですし、変更の影響が大きい業務では、重要な通知を受けた時点で個別に判断する運用が必要でしょう。
重要なのは、確認する人と決める人を明確にすることです。情報収集をした担当者が、そのまま業務リスクまで引き受ける構造にしないほうがよいと考えます。
5. 新機能待ちには「判断期限」と「代替案」を置く
架空の例として、あるプロジェクトのUAT開始日が12月1日だとします。採用候補の機能は、ロードマップ上ではその前に提供される見込みです。
ここで「間に合いそうだから待つ」と決めると、利用条件の確認や結合テストの時間が不足する可能性があります。そこで、プロジェクト側で次のような判断条件を置きます。
- 10月末までに対象環境で検証を始められるか確認する。
- 権限、既存処理との連携、例外ケースを評価する。
- 条件を満たせない場合は、既存方式または合意済みの代替案でUATを進める。
- 新機能の採用は、次の改善リリースで再評価する。
これは実在する機能の提供予定ではなく、判断の組み立て方を示す例です。また、10月末という期限も、必要な検証期間に応じて変えるべきものです。
判断期限を決めておけば、標準機能を待つことも、いったん見送ることも、説明可能な選択になります。避けたいのは、期待だけを理由に代替案の準備まで止めてしまうことです。
6. 新機能の紹介から、採用判断の支援へ
ロードマップの確認で価値を出すには、「何が発表されたか」の一覧だけでは不十分です。
その機能がどの要件に関係し、どの前提が未確認で、いつまでに誰が判断するのか。ここまで整理して初めて、製品情報がプロジェクトの意思決定に使える材料になります。
最初から大きな管理プロセスを作る必要はありません。まずは、自分たちの案件に関係する機能を三つだけ選び、関連要件、未確認事項、次回判定日を記録する。それだけでも、情報共有と採用判断の違いが明確になるはずです。
新機能の情報は継続的に追いながら、採用の判断は業務上の根拠と検証結果で行う。 AI at Workロードマップへの移行を、単なるブックマークの変更ではなく、変更管理を見直す機会にしたいところです。
参考情報・確認日
本稿は2026年9月25日時点の公開情報に基づきます。11月の移行完了・終了日は発表された予定であり、完了済みとは扱っていません。個別のプレビュー機能を正式提供済みとする記述はありません。
- 発行：Microsoft Dynamics 365 Blog、Richard Riley
- 公開日：2026年8月25日（記事表示および日付入りの公式URLで確認）
- 参照内容：公開方式の変更、移行対象と日程、変更されない運用、保存ビューの扱い。
- 発行：Microsoft Learn
- 計画公開日：2026年3月18日（本文の公開マイルストーンで確認）
- ページ表示の最終更新日：2026年9月3日。本文に9月からの公開先変更の案内あり。
- 参照内容：新たなRelease Plansの公開終了、既存計画の履歴参照、計画の対象期間、提供内容・日程に関する注意事項。
両資料とも、送審日から遡る1年間（2025年9月25日～2026年9月25日）の公開資料です。検索取得日や著作権表記を公開日の根拠にはしていません。
コメント