Dynamics 365はアップデートのたびに揺れる—CRM・FO・BC保守対応の現実と、それでもシステム保守がプロジェクトより難しい理由 ♠ DX 365 Life

こんばんは。あっ、おはようございますが正解かな。
室長こと、吉島良平（Microsoft MVP for Business Applications｜Microsoft Regional Director）です。

引き続き、フィリピンのマニラBGCから書いています。深夜4時。頭がさえまくる時間帯になりました。
先日書いた「Dynamics 365のRelease Waveが終わる」という記事が、予想以上の反響をいただきました。
「Waveがなくなるとはどういうことか」「今後のアップデート対応はどう変わるのか」というお問い合わせを多数いただき、この記事を書くきっかけになりました。

今日は、そのご質問に正面から答えていきます。

※本記事は、Dynamics 365のオンラインサービス（CRM・FO・BC Online）を前提に説明しています。On-Premises型では、更新の適用主体、タイミング、手順が異なります。

「AIがあるから、システム構築は楽になった」は本当か

最近、こんな言葉をよく聞きます。

「AIがあるから、コードも書けるし、設定も調べられる。システム構築は昔より楽になった。」

半分は正しいです。でも半分は、大事なことを見落としています。

AIが助けてくれるのは「新しく作る」フェーズです。
問題は「作ったものを、Microsoftが変えてもずっと動かし続ける」フェーズにあります。
そこにAIは、まだ十分に介在できていません。

5月のDirections Asia 2026で、私は「Beyond Buildable AI Agents」というセッションを担当し、AI時代のパートナー価値について話しました。そのなかで伝えたかったことの一つが、「メカニックからの脱却」です。
AIが最も置き換えやすいのは、手順が決まっていて、文脈を必要とせず、判断が少ない仕事—いわゆる「メカニック」的な作業です。
保守・サポートは、一見そう見えるかもしれません。「アップデートのたびに同じ確認をする」「チェックリストをこなす」—確かにそういう面もある。

アーキタイプ	保守現場での具体的な場面	AIに置き換えられるリスク
🔧 メカニック	リリースノートの確認、定型チェックリストの消化、ログの目視確認	高い（AIがカバーしつつある）
🏗️ アーキテクト	アップデートの影響範囲の設計、カスタマイズの整合性判断、テスト設計	中程度
🧭 ガイド	顧客への影響説明、対応優先順位の合意形成、リリースタイミングの判断	低い
🤝 テラピスト	担当者変更後の関係構築、不満を持つ顧客との信頼回復、長期的な関係維持	低い

保守の仕事は、メカニック的な作業を入口にしながら、アーキテクト・ガイド・テラピストの能力を同時に要求します。
メカニックからの脱却が問われているのは、保守の現場も、そのひとつだと私は思っています。

そして、Dynamics 365のアップデートは止まっていません。
Waveという名前がなくなっても、Finance & Operationsは年4回、Business Centralは毎月、CRMは大型リリースが年2回、それに加えてAI機能が毎月のように追加されています。
むしろ「AI at Work」時代に入り、変更の頻度は上がっています。

保守は、プロジェクトより難しい

私がこの仕事に長く携わってきて、一貫して感じてきたことがあります。

室長の経験から—保守がプロジェクトより難しい理由

① 優秀な人材はプロジェクトに集まる
導入プロジェクトはやりがいがあり、評価もされやすい。一方、保守・サポートは地味に見られ、人材が枯渇しやすい。実際には、保守の方が製品・カスタマイズ・お客様の業務の三つを深く理解していないとできない、難易度の高い仕事です。

② 引継ぎが不十分なまま保守に入る
導入プロジェクトで作られたドキュメントは、多くの場合、プロジェクト完了時点で止まっています。その後の設定変更・カスタマイズの追加がドキュメントに反映されないまま、保守担当者は「動いているが、なぜそうなっているかわからない」状態で作業しています。

③ お客様の担当者が替わる
プロジェクトを経験した社内キーマンが異動・退職し、背景を知らない担当者から問い合わせが来る。「なぜこの設定になっているのか」「この動きに意図はあるのか」—プロジェクトの文脈を引き継げていないまま、問い合わせだけが積み上がっていきます。

④ 時間・優先順位・割り込みとの闘い
保守担当者は複数のお客様・複数のシステムを並行して担当します。アップデート対応中に別案件の緊急障害が入る。ドキュメントを書こうとすると問い合わせが来る。計画通りに進まないのが保守の日常です。

⑤ 予算が削られる
「システムは動いているから」という理由で保守費用が削減対象になりやすい。しかしアップデートが来るたびに、その削られた予算で対応しなければならない。これが積み重なると、いつかどこかで破綻します。

この記事では、この現実を踏まえた上で、Microsoftのプラットフォームアップデートがあったとき、ベンダー側に具体的にどんな作業が発生するかを整理します。
技術者には「自分たちがやっていること」の整理として。顧客には「なぜ保守が大切なのか」の説明として。両方に使っていただければと思います。

なぜ、保守が大切なのか

「システムは導入して終わり」—そう思っているお客様は、まだ多い。
しかし、Dynamics 365はクラウドSaaSです。Microsoftは毎月・毎四半期・毎年、プラットフォームを更新し続けます。
保守とは、その変化に追随し続ける作業です。止めた瞬間から、リスクが積み上がり始めます。

保守が大切な3つの理由

① 投資回収はGo-Liveの後に始まる
Dynamics 365とPower Platformのライセンスは、毎月課金され続けます。CopilotもPower AutomateもPower BIも、プラットフォームが最新であることを前提に動きます。保守が追いつかなければ、払い続けているライセンス費用の恩恵を受けられないまま、競合との差が開いていきます。「使い続けること」が、投資回収の条件です。

② AI・API・帳票—プラットフォームに依存する機能は広い
影響を受けるのはAI機能だけではありません。外部システムとの連携に利用するAPIについて、互換性のない変更や廃止が行われた場合、連携が失敗する可能性があります。帳票（ERコンフィグ・SSRS・Word Template）はデータモデルの変更に直接影響を受けます（帳票設計とアップデートの関係はこちら）。Power Platformのコネクター仕様、認証方式、アクション・トリガーに互換性のない変更があれば、Power Automateのフローがエラーになる可能性があります。「動いていたもの」が、アップデートを境に動かなくなる。

③ じわじわ蓄積して、ある日突然来る
アップデートを素通りさせ続けると、非推奨機能への未対応やカスタマイズの未検証が積み上がります。それぞれの更新では何とか動いていても、後続の更新で問題が一気に顕在化することがあります。そのとき対応に要するコストと時間は、定期的に保守していた場合の比ではありません。保守とは「何もなくて当たり前」の状態を維持し続ける、目に見えない価値です。

「追加される機能」だけでなく「なくなる機能」を追う

アップデート対応で見落とされがちなのが、Deprecated Features（廃止予定機能）です。
Microsoftは新機能を追加するとき、古い機能・API・設定方法を段階的に廃止します。廃止のスケジュールは事前に公開されますが、追いかけていないと気づかないまま本番環境で使い続け、ある時点で突然動かなくなります。

⚠️ Deprecated Featuresの確認は保守の必須タスク

廃止対象になりやすいのは：APIエンドポイント・帳票レイアウトが依存するデータ構造・Power Platformコネクターの旧バージョン・FOのX++クラス・BCのALオブジェクト—など、カスタマイズが深く依存している領域です。

Deprecations情報は、弊社ブログでもウォッチしています：Dynamics 365 2026 Wave 1 Deprecations まとめ

CRM（Customer Engagement apps）のアップデート対応

Dynamics 365のCustomer Engagementアプリケーション（Sales、Customer Service、Field Serviceなど。本記事では便宜上「CRM」と表記）は、Dataverseを基盤とするクラウドサービスです。
Microsoftは年2回（4月・10月）の主要リリースイベントを提供しています。また、環境のリリースチャネルの設定によって月次で新機能や品質修正が提供される場合があります。そのため、実際のアップデート対応は利用しているアプリケーションとリリースチャネルによって頻度が異なります。

AppSourceソリューションを使っている場合

業種特化型（バーティカル）・汎用型（ホリゾンタル）のソリューションをAppSourceから導入している場合、そのISVがリリースに対応したバージョンを出すまで待つ必要があります。ベンダー側は以下を確認します。

📋 AppSource製品：リリース対応タスク

□ISVベンダーからの互換性確認情報・リリースノートの確認

□AppSourceで新バージョンが提供されているかの確認・適用

□新バージョン適用後の動作確認（特にカスタマイズとの干渉チェック）

□ISVが対応版を出していない場合の一時的な回避策の検討

プロジェクト独自カスタマイズがある場合

⚙️ 独自カスタマイズ：リリース対応タスク

□Pluginコードの互換性確認

SDK更新・非推奨APIの置き換え

□PCFコントロール確認

Power Platform更新後も正常動作するか

□Power Automate フロー確認

コネクター仕様変更による既存フローへの影響

□Dataverseスキーマ変更の影響確認

標準エンティティへのフィールド追加・変更

□リグレッションテスト

独自業務フロー全体の動作確認

□ソリューションバージョン更新・再デプロイ

変更があればパッケージ再ビルドと適用

帳票（Word Template / カスタムレポート）がある場合

🖨️ CRM帳票：リリース対応タスク

□Word Templateの動作確認

テンプレートが参照するエンティティフィールドがDataverse更新後も存在するか・型が変わっていないか

□カスタムレポート（FetchXML）の確認

FetchXMLクエリが参照するエンティティ・属性の変更影響確認

□Power BI埋め込みレポートの確認

Dataverseコネクター経由のPower BIレポートがリリース後も正常にデータを取得できるか

外部APIや連携エンドポイントがある場合

🔌 CRM API：リリース対応タスク

□Dataverse Web API バージョン確認

利用しているAPIバージョンが廃止・変更されていないか

□カスタムAPI・Webhookの動作確認

独自に作成したDataverse Custom APIやWebhookの挙動がリリース後も意図通りか

□外部システムとの接続確認

Power Automateコネクター経由・直接API呼び出しどちらの場合も、外部システムへのデータ送受信が正常か

Finance & Operations のアップデート対応

Finance & Operationsは、年4回（2月・4月・7月・10月）のサービスアップデートが提供されます。顧客は年間最低2回の更新を受ける必要があり、連続して1回の更新を一時停止することができます。
また、品質修正を含むProactive Quality Update（PQU）がより短い周期で提供されるため、保守では主要なサービスアップデートだけでなく、その間に提供される品質更新も監視・検証対象となります。
10.0.49のように、2026年9月にセルフアップデート向けの一般提供が開始され、2026年10月から自動更新が予定されているというスケジュールで、まとまった変更が提供されます。
X++という専用言語で書かれたカスタマイズは、プラットフォーム変更の影響を直接受けます。

AppSource ISVソリューションがある場合

📋 ISVソリューション：リリース対応タスク

□ISVからの互換性情報・リリース対応版の確認

□LCSから対象のサンドボックス環境へ新しいサービスアップデートまたはISVパッケージを適用

□ISVソリューションと独自カスタマイズの干渉チェック

□ISV対応版が出ていない場合のリスク評価と顧客への報告

プロジェクト独自カスタマイズ（X++）がある場合

⚙️ X++カスタマイズ：リリース対応タスク

□コンパイル確認

新バージョンでX++コードがエラーなくビルドできるか

□Obsolete／Deprecated API対応

非推奨指定（Deprecated）されたクラス・メソッドと、すでに削除（Removed）されたAPIを区別して洗い出し、必要に応じて代替実装へ移行（MicrosoftはRemoved FeatureとDeprecated Featureを区分して公開）

□データモデル変更の影響確認

MicrosoftがテーブルやEntityを変更した場合の対応

□ERコンフィグ互換性確認

Electronic Reporting設定が新バージョンで動くか（Deprecations参照）

□UATサンドボックス環境での検証

LCSから更新済みのサンドボックス環境で、重要業務プロセスとカスタマイズを対象としたリスクベースのリグレッションテスト

□アップグレードスクリプト

データモデル変更が伴う場合のマイグレーション対応

帳票（SSRS / Electronic Reporting / BDM）がある場合

🖨️ FO帳票：リリース対応タスク

□SSRSカスタムレポートのコンパイル確認

X++のデータプロバイダークラスが新バージョンでエラーなくビルドできるか

□ERコンフィグのバージョン互換確認

Electronic Reportingのコンフィグレーションが新プラットフォームバージョンに対応しているか。GS1バーコード・計算式・マッピングの挙動変化がないか（帳票シリーズ参照）

□BDM（Business Document Management）テンプレート確認

Wordテンプレートが参照するERデータモデルの変更影響確認

外部APIや連携エンドポイントがある場合

🔌 FO API：リリース対応タスク

□ODataエンティティの変更確認

外部システムが利用しているODataエンドポイント（エンティティ名・フィールド名・型）がリリースで変更されていないか

□カスタムサービスとサービス操作の互換確認

X++で実装したカスタムサービス、サービスグループ、カスタムエンドポイントへの呼び出しがプラットフォーム更新後も正常に機能するか（認証方式・Microsoft Entraアプリ登録・証明書有効期限も含めて確認）

□Data Management Framework（DMF）エンティティの確認

データインポート・エクスポートに使用しているDMFエンティティの仕様変更がないか

Business Central のアップデート対応

Business Central Onlineは、年2回（4月・10月）のメジャーアップデートと、それ以外の月に提供されるマイナーアップデートという更新サイクルを持ちます。
今年9月のBC 28.5はマイナーアップデートに該当し、品質修正・規制対応・改善が含まれます。メジャーアップデートでは新機能やプラットフォーム改善が加わります。

AppSource AL拡張機能がある場合

📋 AppSource AL拡張：リリース対応タスク

□Business Central Admin CenterのManage Appsで、導入済みMarketplaceアプリの現在のBCバージョンへの対応状況と利用可能な更新を確認

□Per-Tenant Extension（PTE）について、次期BCバージョンに対する自動検証結果と互換性通知を確認（非互換が検出された場合はALコードを修正し再配備）

□ISVが未対応の場合の代替手段検討・顧客への報告

Per-Tenant Extension（独自AL開発）がある場合

⚙️ Per-Tenant Extension：リリース対応タスク

□ALコードのコンパイル確認

新BCバージョンでビルドエラーが出ないか

□Deprecated オブジェクト対応

非推奨となったTable・Page・Codeunitの置き換え

□Microsoft標準機能の変更影響確認

カスタマイズが依存している標準ロジックが変わっていないか

□リグレッションテスト

独自業務フロー・帳票レイアウトの動作確認

□サンドボックス環境での事前検証

本番適用前に新バージョンで動作確認

帳票（RDLCレポート / Wordレイアウト）がある場合

🖨️ BC帳票：リリース対応タスク

□カスタムRDLCレポートの確認

独自に作成したレポートオブジェクトが新BCバージョンでコンパイルできるか。参照しているALテーブル・フィールドの変更影響確認

□Wordレイアウトの動作確認

カスタムWordレイアウトが参照するデータセットの構造変更影響確認

□標準帳票への変更確認

Microsoftが標準帳票レイアウトを更新した場合、カスタマイズとの干渉がないか

外部APIや連携エンドポイントがある場合

🔌 BC API：リリース対応タスク

□Business Central API（標準）のバージョン確認

外部システムが利用しているBusiness Central APIのバージョン（v2.0等）が廃止・変更されていないか

□カスタムAPIページの互換確認

Per-Tenant ExtensionとしてALで作成したカスタムAPIページが新BCバージョンでも正しく動作するか

□Power Automateコネクターの動作確認

Business Centralコネクター経由のフローがリリース後も正常に動作するか（コネクター自体のバージョンアップも確認）

CRM⇔ERP連携がある場合

CRMとERPを両方使っていて、連携がある構成は、最もアップデート対応が複雑になります。
連携パターンによって、リスクの性質が異なります（設計パターンの整理はこちら）。

Virtual Table経由の連携

DataverseからFOのエンティティをリアルタイムで参照するパターンです（DataverseとVirtual Tableの使い分け）。
Virtual TableはデータをDataverseへ複製しないため、データの重複保持は抑えられます。ただし、実行時にはFOのエンティティ定義・ビジネスロジック・認証・権限・パフォーマンスに直接依存するため、「アップデートの影響が少ない」統合方式とは必ずしも言えません。

🔗 Virtual Table連携：リリース対応タスク

□FOエンティティ構造変更の確認

参照しているFOエンティティのフィールド追加・削除・型変更がないか

□OData仕様変更の確認

FOプラットフォーム更新でODataエンドポイントの挙動が変わっていないか

□Virtual Tableメタデータの更新確認

FOエンティティのメタデータが変更された場合、対象Virtual TableのメタデータをRefresh（更新）が必要

□パフォーマンス影響の確認

FOのクエリ最適化変更がVirtual Table経由のCRM画面レスポンスに影響していないか

□エンドツーエンドテスト

DataverseまたはCRMアプリからVirtual Table経由でFOデータを参照・登録・更新するシナリオ全体の動作確認

Dataverseへのデータ同期（Dual-write）

Dual-writeは、FOとDataverseを密結合し、標準およびカスタムのテーブルマップを通じて双方向にデータを同期する仕組みです。どちらか一方のテーブル構造、必須項目、検証ロジック、セキュリティ、ソリューションバージョンが変わると、同期全体へ影響する可能性があります。

🔗 Dual-write：リリース対応タスク

□Dual-writeソリューションとマップのバージョン確認

FO・CRM（Dataverse）どちらかのエンティティが変わればマップの更新が必要

□テーブル依存関係と起動順序の確認

マップ間の依存関係を把握し、正しい順序で同期が実行されるか確認

□同期エラー・アラートの確認・解消

リリース直後に同期エラーや停止状態が発生していないかを監視

□カスタムフィールドのマッピング維持確認

標準テーブル変更でカスタムフィールドのマッピングが外れていないか

連携アーキテクチャの設計原則については、CRM/ERP/AI時代のデータ設計原則もご参照ください。

データ移行プロジェクトへの影響

進行中のデータ移行プロジェクトがある場合、Microsoftのリリースはプロジェクトに直接影響することがあります（データ移行とAI時代の考え方）。

📦 データ移行プロジェクト：リリース影響タスク

□移行対象エンティティへの変更確認

移行設計時のスキーマと新バージョンのスキーマが一致しているか

□移行ツール・スクリプトの再検証

Data Management Framework（DMF）やAPIの仕様変更による移行スクリプトへの影響確認

□移行タイミングの見直し

大型リリースと移行本番日が重なっていないかのスケジュール調整

Copilot機能への影響

Copilot機能はDynamics 365の標準プラットフォームの上に乗っています。カスタマイズがあると、Copilotが期待通りに動かないケースが生まれます（Copilot 3層フレームワーク）。

🤖 Copilot機能：リリース影響タスク

□AI活用データの構造維持確認

Copilotや分析ツールが参照するデータ構造がリリースで変わっていないか

□新Copilot機能の動作確認

リリースで追加されたCopilot機能がカスタマイズ環境で正常に動くか

□Copilotが参照するフィールドの設定確認

独自追加フィールドをCopilotに参照させる場合、Copilot StudioやCopilot設定で明示的な設定が必要

□Copilot Studioカスタマイズの互換性確認

独自に構築したCopilotエージェントがプラットフォーム更新後も動作するか

□AI at Work Roadmapの新機能確認

アップデートで追加されたCopilot関連機能のデフォルト設定や挙動が、既存のワークフローに影響していないか確認

セキュリティ—アップデートに伴う確認と対応

Microsoftのプラットフォームアップデートには、サービスの安全性を高めるためのセキュリティパッチが含まれます。
一方、更新後に顧客固有のカスタマイズ・権限設計・外部連携との組み合わせによって、アクセス挙動が変わる可能性があります。パッチ自体が問題を生むのではなく、更新との組み合わせを確認することが重要です。

🔒 セキュリティ：リリース対応タスク

□セキュリティパッチの内容確認

リリースノートのSecurity Advisoryセクションを確認し、自社環境への影響を評価

□セキュリティロール変更の影響確認（CRM）

Dataverseのセキュリティロール定義がリリースで変更されていないか。カスタマイズが意図しないデータアクセスを引き起こしていないか

□Virtual Table・API アクセス権限の確認

Virtual TableやカスタムAPIのアクセス制御設定がリリース後も意図通りか

□サービスアカウント・接続文字列の確認

連携システムが使用するサービスアカウントの権限・証明書有効期限を定期確認

□カスタムコードの脆弱性確認

プラットフォーム更新で新たな脆弱性パターンが定義された場合の既存カスタマイズの見直し

□AppSource製品のセキュリティアップデート確認

導入済みISVソリューションのセキュリティ対応バージョンが提供されているかの確認

まとめ—ベンダーは、リリースのたびにこれをやっている

ここまで読んでいただければ、伝わったと思います。

Waveという名前はなくなりました。でもMicrosoftのリリースは止まっていない。
CRMは年2回の主要リリースに加えて月次更新が重なり、FOは年4回のサービスアップデートにPQUが加わり、BCは年2回のメジャーリリースに毎月のマイナーアップデートが続く。
それぞれに対して、AppSourceソリューション・独自カスタマイズ・連携層・データ移行・Copilot・セキュリティの各層を確認し、テストし、場合によっては修正します。

「AIがあるから楽になった」という言葉が広がっています。
確かに、ベンダーもAIを使って保守の効率化に取り組んでいます。
リリースノートの要約、廃止API（Deprecated API）の静的検出、エラーログの分析、テストケースの生成支援—こうした領域では、AIが確実に作業を助けてくれるようになりました。

ただし、まだAIがカバーできていない、あるいは難しい領域があります。

AIが助けてくれる領域 / まだ難しい領域

✓ AIが助けてくれる
リリースノート・Deprecations情報の要約と翻訳 / コード内の廃止APIの静的検出 / エラーログの原因候補の提示 / テストケースの生成支援

✗ まだ難しい・カバーできていない
「なぜこのカスタマイズをこう作ったか」の背景理解（ドキュメントがなければAIにも分からない） / 本番環境での実際のリグレッションテスト実行と合否判断 / ISVの対応版リリース待ちのスケジュール調整 / 「このエラーは許容範囲か、ブロッカーか」の業務文脈に基づく判断 / セキュリティロール設定が業務フローに与える影響の文脈理解

ベンダーはAIを活用しながら、保守の質と効率を高めようと日々努力しています。
しかし「作ったものを、Microsoftのリリースを超えて動かし続ける」判断の核心部分は、業務の文脈を理解した人間が担う必要があります。
むしろMicrosoftがAI機能を積極的に追加するほど、その変化に追従する保守作業の範囲は広がっていきます。

そしてもう一つ。
保守は、プロジェクトより難しい仕事です。
優秀な人がプロジェクトに集まり、保守は人が枯渇する。ドキュメントは更新されない。担当者が替わる。予算は削られる。
この現状を変えていきたいと、私はずっと思っています。

いいシステムを作るよりも、いいシステムを動かし続けることの方が、実は難しくて、価値があることを伝え続けていきたいと思います。

最後に、一言だけ。
保守・サポートの現場で日々向き合っているすべての方へ—私は皆さんを心からリスペクトしています。
誰にも見えないところで、誰も気づかない問題を潰し続けている。その仕事が、システムを、ビジネスを、お客様を支えています。
これからも、こっそりと応援しています。

Let’s Enjoy our DX365LIFE!