こんばんは。皆さま、いかがお過ごしでしょうか？

“室長”こと、吉島良平（Microsoft MVP for Business Applications | Microsoft Regional Director）です。

今日は珍しく18時に仕事が終わったため、19時からこの文章を書き始めました。バンコクはとにかく暑く、日本との気温差に少し戸惑っています。体調管理には気をつけないといけませんね。

さて、ワールド・ベースボール・クラシック。日本代表、残念ながら負けてしまいました。日本を破ったベネズエラが、その後アメリカに勝って優勝したというニュースをYahoo!で見ました。勝負事は本当に時の運。勝つときもあれば、負けるときもあります。

ベネズエラ戦は日本で観戦し、そのまま成田空港へ向かったのですが、試合を見ながら前回のラグビーワールドカップのアルゼンチン戦を思い出しました。南米特有の情熱的な応援に、日本の投手陣が少し飲まれてしまったようにも感じます。とはいえ、ベネズエラの投手陣は本当に素晴らしかったですね。実力を認めざるを得ません。対アメリカ戦ということで、また別の意味で闘志が燃えたのかもしれません。

ベネズエラ代表の皆さん、優勝おめでとうございます。そして日本代表の皆さん、本当にお疲れさまでした。素晴らしい試合をありがとうございました。

……あ、そろそろNetflixを解約しないと（笑）

Dynamics 365 2026 wave 1リリース

さて、昨日2026年3月18日に、Dynamics 365 2026 wave1のリリースノートが公開されました！イエーイ！待ってました！

Power Platform、そして今回からは Role-Based Copilot offeringsについても同様にリリースノートが公開されました”(-“”-)”

マイクロソフトの製品開発チームの皆さま、おめでとうございます！

序章｜2026 wave 1が示した、もう一つのメッセージ

Microsoftは 2026 release wave 1の発表と同時に、Dynamics 365における Deprecations （将来的に廃止される機能）を公式に公開しました。Deprecationとは、「すぐに使えなくなる」ことを意味するものではありません。現在の環境では当面動作し、サポートも継続されます。しかしその一方で、これ以上進化しないこと、そして将来のリリースでは削除される可能性があることを示しています。

そして Deprecationは、単なる機能整理ではありません。それはMicrosoftが「これからの Dynamics 365において、前提にしない設計」を明確に示す行為でもあります。言い換えれば、Deprecationの一覧は、未来のアーキテクチャを逆算するためのヒント集だと捉えることができるものだと感じています。（今後のトレンド把握のためにとても重要）

特に、長期利用を前提とした ERP/CRM導入、グローバルテンプレート設計、アドオンやISV開発、そしてCopilotやAI Agentを見据えた業務設計においては、「使えるかどうか」ではなく、「前提にしてよいかどうか」が重要になります。よって、本稿では、Dynamics 365 2026 Wave 1に関する連載の第一弾として、今回公開された Deprecationsを起点に、「各アプリケーションでどのような方向性の機能が整理されつつあるのか」「それはどのような思想転換を意味しているのか」「設計者・IT リーダーは何を前提に考えるべきなのか」という視点で整理していきたいと考えています。

まずは Dynamics 365全体を俯瞰しながら、「なくなっていく機能」に共通する方向性をまとめ、そのうえで、各アプリケーションごとに詳しく見ていきます。

「何が増えたか」ではなく、「何を前提にしなくなったのか」

2026 Wave 1は、その問いに向き合うための重要な転換点だと言えるのではないでしょうか。日々製品をご利用いただいているお客様には、できるだけ早くお伝えすべき内容でもありますし、これからのご提案においても、将来にわたって利用が継続できる機能に絞ってご紹介していきたいという思いがあります。

ということで本稿では、まず「Deprecations（将来的に廃止される機能）」にフォーカスし、いつものように室長の勝手な解釈で書いていきます。最後までお付き合いいただければ幸いです。

Deprecationを横断して見えてくる、共通する方向性

今回公開されたDeprecationsをDynamics 365全体で俯瞰すると、単発の機能廃止ではなく、明確な「方向性」をもった整理であることが見えてきます。それは、2026 wave 1全体で強調されているCopilot/AI Agentを前提としたアーキテクチャへの移行とも、強く整合しています。ここでは、各アプリケーションに共通して見られる「なくなっていく機能の方向性」を整理します。

UI操作を前提とした業務設計からの脱却

Deprecationの多くは、「人が画面を開き」「手動で入力し」「画面上で判断して処理を進める」

といった UI 操作を前提とした業務体験に紐づいています。これは単なるUI改修や操作性の問題ではありません。Microsoftは、「業務はUIで行うもの」という前提そのものを見直し始めているように見えます。CopilotやAI Agentが前提となる世界では、人は「操作する存在」ではなく、判断を委ね、結果を確認する存在へと役割が変わります。その文脈に合わないUI前提の機能が、整理対象になっていると捉えることができます。

この内容は、前回のBlogで“勇気をもって、深くほった”つもりなので、👉こちら👈をご覧ください。

アプリ単体で完結する機能の整理

もう一つの共通点は、特定のアプリケーション内に閉じた機能や設計が、徐々に前提でなくなっている点です。Dynamics 365はすでに、「Dataverseを中核としたデータ統合」「Power Platformによる拡張」「Copilotによる横断的な体験」を前提としたプラットフォームへと進化しています。

その中で、「アプリ固有のロジック」「他アプリやサービスと連携しづらい機能」「独自概念で成立していた仕組み」は、将来像と整合しなくなりつつあります。Deprecationは、その再編プロセスの一部と見ることができます。

「人が頑張ること」で成立していたプロセスの終わり

Deprecationには、「手動更新」「人によるチェック前提」「一覧を見て判断する運用」といった、人依存で成立していた業務プロセスに関係するものも多く含まれています。これは裏を返せば、Microsoftが「人が頑張る前提の業務設計」からの脱却を本気で進めている、ということでもあります。CopilotやAI Agentが業務を理解し、判断し、実行する。人はそれを監督・調整する立場になる。その前提に立ったとき、従来型の機能やプロセスは、役割を終えつつあるのです。

Deprecationが示すのは「過去の否定」ではない

重要なのは、これらの機能が「悪かった」「間違っていた」という話ではない、という点です。それらは、「当時の技術」「当時の業務」「当時のユーザー体験」において、最適解だったものです。

しかし、2026 wave 1は、前提条件そのものが変わったことを示しています。Deprecationは、過去を否定するためのものではなく、未来に進むための整理だと捉えるべきでしょう。

第1章－1｜Business Central（w1）Deprecated Features 解説

―各機能は、なぜ役割を終えつつあるのか―

レガシー Excelレポート（Role Center上のExcel Reports）

Business Centralにはこれまで、Business ManagerやAccountantのRole Centerから直接利用できる、いわゆる従来型のExcelレポートが用意されていました。貸借対照表（Balance Sheet）、損益計算書（Income Statement）、キャッシュフロー計算書（Statement of Cash Flow）、売掛金・買掛金のエージングレポート（Aged AR/AP）、顧客残高明細（Customer Statements）など、会計業務における基本的な帳票が Excel形式で提供されていたことを覚えている方も多いでしょう。

2026 Release Wave 1では、これらのレガシー ExcelレポートがRemoved/Replacedの対象となり、廃止の方向性が明確に示されました。代替手段としては、新しいExcel Layoutベースのレポートや、Power BIを用いた分析レポートが公式に位置づけられています。Microsoftがこれらの従来型ExcelレポートをDeprecatedとした理由は明確です。帳票の修正や拡張にはALやVBAへの依存が避けられず、保守性が低いこと。また、現代のデータ活用ニーズに対して、静的な帳票ではできることが限られていること。そして何より、より柔軟で拡張性の高い分析手段が既に用意されている、という点です。これは単なる帳票整理ではありません。Business Centralにおけるこの変更は、「レポートを作る ERP」から「データを分析し、活用する ERP」への明確な転換を意味しているように思えます。

2. Business Central API v1.0（旧 API）

Business Centralが初期から提供してきたREST API v1.0も、今回のDeprecationの重要な対象の一つです。API v1.0は、複合キーや非 GUIDキーを用いた設計で、実行時に計算されるフィールドを多く含んでいました。UIとの親和性や、人が理解しやすい構造を重視した設計だったとも言えます。

2026 Wave 1において、API v1.0はDeprecatedとされ、API v2.0 への移行が前提となりました。API v2.0では、GUID（SystemId）をベースとした一貫性のある識別子が採用され、実行時計算を排した設計へと進化しています。Microsoftが旧APIをDeprecatedとした背景には、実行時計算によるパフォーマンスの問題、複合キーによる扱いづらさ、そして大規模連携や監査・拡張を見据えた場合にGUIDベースの設計が不可欠である、という判断があります。ここで明確に見えるのは、UIや人間にとって分かりやすい設計よりも、システム連携に最適化された設計を優先するという思想です。Business Centralはこの判断によって、「APIファーストなERP」へと完全に舵を切ったと言えるでしょう。

3. 国別・ローカル専用機能の整理（Moved）

Business Centralにはこれまで、特定の国や地域でのみ利用される会計・業務機能が数多く存在していました。税制や商習慣への対応として、国別アプリケーションやローカライズ機能が用意されてきた背景があります。今回のDeprecationでは、そうした国別・ローカル専用機能の一部が、w1（世界共通バージョン）へ移動されたり、他の機能に統合されたりする形で整理されています。これは「削除」というよりも、「位置づけの変更（Moved）」に近い動きです。この判断の背景にあるのは、ローカル専用である必然性が薄れてきたこと、重複実装による保守コストを下げたいという意図、そして何より単一コードベースを維持したいというMicrosoftの強い意思です。この動きは、Business Centralがグローバルテンプレート前提のERPであることを、改めて明確に示しています。国ごとに異なるERPを前提とする時代から、共通基盤の上で差分を管理する時代への移行が進んでいると言えるでしょう。

4. 役割を終えたアプリ・機能（Removed/Replaced）

Deprecationの中には、特定のアプリや機能そのものが役割を終えたと判断された例も含まれています。代表的なものとして、Microsoft が提供してきた AMC Fundamentals Appが挙げられます。このアプリは将来のリリースで削除され、外部ベンダーが主体となるアプリへと置き換えられる予定です。ここで重要なのは、「機能が不要になった」というよりも、Microsoft自身がその領域を持ち続ける必要はないと判断した点です。MicrosoftはBusiness Centralを取り巻くエコシステムの中で、自らが担うべき領域と、パートナーや外部ベンダーに委ねるべき領域を、より明確に切り分け始めています。これは、Business Centralがプラットフォームとして成熟し、「すべてを内製する ERP」から「エコシステムを前提とした ERP」へと進化していることの表れでもあります。

サマリー｜Business Central (w1) Deprecationから見える全体傾向

ここまで見てきた個々のDeprecated機能は、一見するとそれぞれ独立した変更のように見えるかもしれません。しかし、それらを横断的に眺めていくと、Business Centralがどこに向かおうとしているのかは極めて明確です。

まず浮かび上がるのは、「画面と帳票を中心に据えた ERP」からの脱却です。Role Center上に用意されていたレガシー Excelレポートが整理されたことは、その象徴的な出来事だと言えるでしょう。Microsoftはもはや、「決められた帳票を出すこと」をERPの主戦場とは捉えていません。代わりに、Excel LayoutやPower BIを前提とした柔軟な分析、すなわち「データをどう使い、どう意思決定につなげるか」という観点に重心を移しています。これは単なる帳票の置き換えではなく、ERPに求められる価値そのものが変化していることを示しています。

次に見えてくるのが、APIファーストなERPへの完全な移行です。旧 API（v1.0）の整理に象徴されるように、Business Centralは「人にとって分かりやすい構造」よりも、「システム連携にとって一貫性があり、安定している構造」を優先するフェーズに入りました。GUIDや SystemIdを前提とした設計は、UIとは独立したサービスとしてERPを扱うための必然的な選択であり、画面を前提とした連携は、明確に過去のものになりつつあります。

三つ目の大きな流れは、国別ERPからグローバル ERPへの転換です。ローカル専用機能がW1（世界共通版）に統合されたり、整理されたりしている背景には、単一コードベースを前提としたグローバル運用という思想があります。Business Centralは、「国ごとに違う ERP」を許容するフェーズを終え、テンプレート化と横展開を前提とするプロダクトへと進化しています。この変化は、グローバル導入やマルチカントリー展開を検討する企業にとって、非常に重要なメッセージを含んでいます。

さらに、Microsoft 自身が「持つべきでない領域」を明確に切り分け始めている点も見逃せません。特定のアプリや機能が外部ベンダー主体へと移管・置き換えられている事例は、Microsoftが「すべてを自分たちで作る」立場から、「プラットフォームとエコシステムを提供する」立場へと完全に移行したことを示しています。これは、Business Centralが成熟期に入ったことの表れでもあります。

これらを総合すると、Business CentralにおけるDeprecationは、単なる「なくなる機能の一覧」ではありません。それは、UIに依存せず、帳票に縛られず、国別に分断されず、そして人の操作を前提としない―そうした “次の ERP像”に向けて、前提条件を静かに入れ替えていくプロセスそのものだと捉えることができます。

第1章－2｜Business Central（Platform）Updates 解説

―クライアント／サーバー／データベース層で何が変わろうとしているのか―

アプリケーションレベルのDeprecationに加えて、Business Centralではクライアント、サーバー、データベースといったプラットフォーム層においても、明確な整理が進められています。これらは普段あまり意識されにくい領域ですが、実はBusiness Centralの設計思想を最も端的に表している部分でもあると考えています。

Microsoftが提供するUIページをAPIとして公開する仕組み

Business Central ではこれまで、Microsoftが提供する標準ページをODataやSOAPのエンドポイントとして公開し、外部システムと連携することができました。Base ApplicationやSystem Applicationに含まれるページを、そのままWebサービスとして利用していたケースも少なくありません。

この仕組みは、プラットフォームレベルで明確にDeprecatedとされ、段階的に削除されていくことが示されています。まずSOAPエンドポイントとしての公開が制限され、その後、Microsoftが提供するページをODataエンドポイントとして公開する機能自体が廃止される方向となりました。

Microsoftがこの機能を廃止する理由は非常に一貫しています。UIページは本来APIとして設計されたものではなく、UIの変更は互換性を壊す変更とは見なされないため、結果として連携が不安定になります。また、UI向けに最適化された構造は、パフォーマンスや一貫性の面でもシステム連携には適していません。

このDeprecationが意味するのは、「UI は UI、APIはAPI」という明確な線引きです。Business Centralは、画面を流用した連携や、便宜的な Webサービス公開を許容するフェーズを終え、正式に定義されたAPIを前提とするプラットフォームへと移行していると言えるでしょう。

プラットフォーム運用・管理におけるレガシー手法の整理

プラットフォーム層では、オンプレミス環境を中心に利用されてきた、いくつかの運用・管理手法も整理対象となっています。古い形式のライセンスファイルや、専用の管理ツールなど、従来の運用モデルを前提とした仕組みは、PowerShellや新しい管理手法へと置き換えられています。

これらの変更は、単にツールが変わったという話ではありません。Business Centralの運用モデルそのものが、「個別環境を人が管理する」前提から、「自動化・スクリプト化・一貫管理を前提とする」方向へと移行していることを示しています。

データベース・スキーマ整理に見られる思想

クライアントやサーバーに加えて、データベースレベルでもDeprecationや削除が継続的に行われています。長期間Obsolete（使われなくなった）状態にあったテーブルやフィールドが完全に削除される流れは、単なるクリーンアップではありません。

Microsoftは、データベース構造においても「将来使われない前提のものを残さない」方針を明確にしています。これは、パフォーマンスや保守性の観点だけでなく、将来の拡張やAI活用を見据えた場合に、意味を持たないデータ構造を前提にしないという意思表示でもあります。

サマリー｜Platform Deprecationから見える全体傾向

Business Centralのプラットフォーム層におけるDeprecationを総合すると、そこにあるメッセージは非常に明確です。それは、「便宜的に使えていたもの」や「昔は許されていた前提」を、これからの設計では許容しない、という姿勢です。

UIページをそのままAPIとして公開する仕組みが整理されたことは、UIとAPIを厳密に分離するという意思の表れです。レガシーな運用・管理手法が置き換えられているのは、個人の経験や手作業に依存しない運用モデルへ移行していることを示しています。そして、データベース構造の整理は、「将来の拡張やAI活用に耐えうる前提条件だけを残す」という、長期的な視点に基づく判断です。

第2章－1｜Dynamics 365 Finance Deprecated Features 解説

― Removed/Deprecated Featuresから読み解く、会計ERPの再定義ー

Dynamics 365 Financeでは、Business Central以上に明確な形で、「役割を終えた機能」と「これから前提にすべき考え方」の切り分けが進められています。Microsoft LearnのRemoved or Deprecated Features in Dynamics 365 Financeには、Financeにおいて削除済み、あるいは将来的に削除予定の機能が、リリースごとに整理されています。以下では、その中でも思想的な転換点を示している代表的な機能を取り上げ、順に見ていきます。

Finance InsightsにおけるBudget Proposal機能

Finance Insightsに含まれていたBudget Proposal機能は、これまで予算編成の支援機能として提供されてきました。過去実績をもとに予算案を提示し、計画作成を支援することを目的とした機能です。Budget Proposal機能は Deprecatedとされ、将来的に削除されることが明示されています。Microsoft Learnでは、その理由として、利用率が低かったことに加え、内部的に依存していたコンポーネント（Data Lake Writer）が既に Deprecatedとなっている点を挙げていました。また、この機能はBusiness Performance Planningへと置き換えられる位置づけになっています。

ここで重要なのは、単に予算機能が減ったという話ではありません。Microsoftは「Finance単体の補助機能としての予算策定」ではなく、ドライバー型計画、ワークフロー承認、ExcelやPower BI、Dataverseとの連携を前提とした、より広い計画基盤へと軸足を移しています。これは、予算を“会計の延長”として扱う時代が終わりつつあることを示しています。

国・地域固有の規制レポート（例：オランダ向け Audit file）

Dynamics 365 Financeでは、各国・地域の規制に対応するための専用レポートや Electronic Reporting（ER）形式が提供されてきました。例えば、オランダ向けの Audit file（XML Auditfile Financieel）もその一つです。

このAudit fileに関するERフォーマットはDeprecatedとされ、より新しい規格（XAF 4.0）への移行が前提となっています。Microsoft Learnでは、規制側の変更により旧フォーマットが公式に廃止されていることを理由として挙げていました。この変更は、ローカル機能の単純な廃止ではありません。Financeにおいては、各国固有の要件を個別実装で抱え続けるのではなく、標準化されたフレームワーク（ER）上で規制変化に追随するという設計思想がより強くなっているようです。

規制・制度そのものが廃止された機能への追随

Financeでは、特定の国における制度や報告義務そのものが廃止された場合、それに対応する機能も速やかに整理されます。たとえば、イタリアにおける Esterometro関連フォーマットは、制度の廃止に伴いDeprecated/Removedの対象となっています。

ここから読み取れるのは、Dynamics 365 Financeが「過去の制度との互換性」を重視するERPではない、という点です。Financeは、現在有効で、かつ将来も維持される制度・規制を前提に設計されるプロダクトであり、歴史的経緯のために機能を残し続けることはしないのでしょう。

会計業務を“個別機能の集合”として扱う考え方の終焉

Removed/Deprecated Featuresを通して一貫して見えるのは、Financeが「個別機能を足し合わせて業務を成立させる ERP」から離れつつある点です。Finance Insightsの整理、ローカル規制機能の再編、計画機能の外出しは、すべて同じ方向を向いています。それは、会計・財務を業務プロセス全体の中で再定義するという方向性です。計画、実績、分析、レポーティングを分断された機能としてではなく、統合されたデータ基盤とプロセスの中で扱う。そのために、役割を終えた機能は迷いなく整理されていきます。

サマリー｜Dynamics 365 Finance Deprecationから見える全体傾向

Dynamics 365 FinanceにおけるRemoved/Deprecated featuresを総合すると、そこにあるメッセージは明確です。MicrosoftはFinanceを「会計処理を行うシステム」から、「経営判断と業務計画を支える中核プラットフォーム」へと進化させようとしています。

その過程で、単体で完結する補助機能や、特定制度・特定技術に強く依存した機能は整理されつつあります。予算策定はより高度な計画基盤へ、規制対応は標準化されたフレームワークへ、分析や意思決定はExcelやPower BI、Dataverseを含むエコシステムへと重心が移っています。

第2章－2｜Dynamics 365 SCM Deprecated Features 解説

―Removed/Deprecated Featuresから読み解く、SCM の再定義―

Dynamics 365 Supply Chain Managementでは、機能追加以上に「何を前提にしなくなったのか」が、はっきりと示されています。Microsoft LearnのRemoved or Deprecated Features in Dynamics 365 Supply Chain Managementは、SCMがどのような思想で整理されているのかを読み解くための重要な資料です。以下では、SCMの方向性を象徴するRemoved/Deprecated機能を取り上げていきます。

Inventory On-hand mobile app（Preview）

Inventory On-hand mobile appは、在庫のオンハンド情報をモバイル端末から確認するためのプレビュー機能として提供されていました。倉庫や現場で素早く在庫状況を把握することを目的としたアプリケーションです。

このモバイルアプリは、プレビュー段階のままRemovedとされ、Microsoftが管理・提供する機能としては継続されないことが明示された非常にレアなケースとなりました。Microsoft Learnでは、プレビュー機能として提供していたものの、開発とサポートを継続しない判断を下したことが理由として示されています。

この判断は、「モバイルで在庫を見たい」というニーズ自体を否定するものではありません。むしろ、SCMにおいては、特定用途向けの専用アプリをMicrosoftが一律に提供するのではなく、Power Platformやオープンなサンプルを活用して、各社が自社業務に合わせて実装することを前提とする方向へ進んでいることを示しています。企業内の内製化促進、パートナーにビジネスのうまみを残したと言っていいでしょう。

Data Integratorテンプレート（Field Service連携）

Supply Chain ManagementとField Serviceを連携させるために提供されていたData Integratorテンプレートも、Deprecatedの対象となっています。これらのテンプレートは、作業指示や在庫、プロジェクト情報などを同期するための簡易的な連携手段として利用されてきました。このテンプレートがDeprecatedとされた理由として、Microsoft Learnでは、よりシンプルで統合されたField Service体験へ移行するためであることが説明されていました。

ここで示されているのは、「データを同期する」こと自体を目的とした連携の終焉です。SCMでは、テンプレートによる場当たり的な同期ではなく、業務プロセスと財務連携を前提にした統合が重視されるようになっています。

Copilotを含むプレビュー機能の整理

SCMでは、一部のCopilot関連プレビュー機能や、実験的に提供されていた機能が、一般提供に至らず整理されるケースも見られます。Microsoft Learnでは、これらの機能について「プレビューとしての開発を継続しない」という判断が下されたと書いてありました。これはCopilot戦略の後退ではなく、むしろその逆です。Microsoftは、SCMにおいてもAI機能を「試験的にばらまく」段階から、「業務プロセスに組み込める形で提供する」段階へ移行しており、位置づけが曖昧な機能は整理されていると読むべきでしょう！

サマリー｜Dynamics 365 Supply Chain Management Deprecationから見える全体傾向

Dynamics 365 Supply Chain ManagementにおけるRemoved/Deprecated featuresを総合すると、そこにあるメッセージは明確です。SCM は、「個別機能を追加していくシステム」から、「業務プロセスを成立させるための基盤」へと進化しています。

プレビュー段階のモバイルアプリが整理されたことは、Microsoftが現場向け UIを一律に提供する立場を取らないことを示しています。Data Integratorテンプレートの廃止は、データ同期そのものではなく、業務と財務をつなぐ統合体験を重視する姿勢の表れです。そして、実験的なAI機能の整理は、SCMにおけるCopilot活用をより現実的で持続可能な形に収束させていく過程だと捉えられます。

第2章－3｜Dynamics 365 FinOps（Platform）Updates 解説

―プラットフォームDeprecationから読み解く、運用と統治の再設計―

Dynamics 365 FinanceおよびSupply Chain Managementを含むFinance & Operationsアプリケーションでは、アプリケーション機能だけでなく、プラットフォームレベルにおいてもDeprecationが段階的に進められています。Microsoft LearnのRemoved or Deprecated Platform Featuresは、その変化を最も端的に示すドキュメントです。ここでは、プラットフォームDeprecationの中でも、設計思想の転換点を示している代表的な項目を見ていきます。

Lifecycle Services（LCS）におけるプロジェクト作成の凍結

Dynamics 365 Finance & Operationsの導入・運用において、Lifecycle Services（LCS）は長らく中核的な役割を担ってきました。環境管理、Issue管理、実装支援など、多くのプロセスがLCSを前提として設計されていたことを記憶している方も多いと思います。

このLCSについて、Microsoftは新規顧客向けのプロジェクト作成を凍結することを明示しました。既存プロジェクトがすぐに使えなくなるわけではありませんが、LCSは今後、プラットフォーム管理の中心ではなくなっていきます。代替として位置づけられているのが、Power Platform Admin Center（PPAC）です。

この変更の背景にあるのは、Dynamics 365をFinanceやSCMだけの製品群としてではなく、Power Platformを含む統合基盤として管理していくという戦略です。環境管理やガバナンスをアプリごとに分断するのではなく、単一の管理基盤で横断的に扱うという方向性が、ここではっきりと示されています。

Data Integratorテンプレートの廃止と統合体験への移行

Finance & Operationsと他のDynamics 365アプリケーション（たとえば Field Service）を連携させるために、Data Integratorテンプレートが用意されていた時期がありました。これらのテンプレートは、データ同期を比較的容易に実現する手段として利用されてきました。しかし、このData IntegratorテンプレートはDeprecatedとされ、将来的に利用できなくなることが示されています。Microsoft Learnでは、その理由として、よりシンプルで統合された体験へ移行するためであることが説明されていました。ここで重要なのは、「連携ができなくなる」という話ではない点です。むしろ、テンプレートベースの一時的な連携ではなく、業務プロセスとデータモデルを前提にした統合へと設計思想が移っていることが読み取れます。

プラットフォーム管理・運用の自動化前提への移行

Finance & OperationsプラットフォームのDeprecationを俯瞰すると、LCSに限らず、「人が操作して管理する」ことを前提とした仕組みが整理されていることが分かります。管理ポータルの集約、Power Platform Admin Centerへの統合は、その象徴的な動きです。これは、運用負荷を下げるための改善であると同時に、ガバナンスと自動化を前提にしたプラットフォーム運営への転換でもあります。環境管理、更新、監視といった活動を、属人的な運用から切り離す意図が明確に表れています。

サマリー｜Finance & Operations Platform Deprecationから見える全体傾向

Finance & OperationsのプラットフォームレベルにおけるRemoved/Deprecated featuresを総合すると、そこにあるメッセージは非常に明確です。それは、「個別製品ごとに閉じた運用モデル」からの脱却です。

Lifecycle Servicesに依存した管理、テンプレートベースの連携、アプリ単位で分断されたガバナンスは、これからの前提ではありません。Microsoftは、Power Platformを中心とした統合管理、業務プロセス前提の連携、そして自動化・一貫管理を前提とした運用モデルへと、確実に移行しています。

第3章｜Dynamics 365 Sales Deprecated Features 解説

―Deprecationから読み解く、「営業を支援する CRM」の再定義ー

Dynamics 365 SalesにおけるDeprecationは、単なる UI や機能整理ではありません。Microsoft LearnのDeprecations in Dynamics 365 Salesには、Salesがこれからどのような役割を担うべきか、そして何を前提にしなくなったのかが、非常に明確に表れています。

ここでは、Salesの方向性を象徴するDeprecationをいくつか取り上げながら、その意味を読み解いていきます。

旧来のUIコントロールや表示前提機能の整理

Dynamics 365 Salesではこれまで、特定のUIコントロールや表示形式を前提とした機能が数多く存在していました。階層表示を行うためのHierarchy Controlなどは、その代表例です。これらの機能は、フォーム上での視覚的な把握を重視した設計で、営業担当者が画面を見ながら情報を整理することを前提としていました。

しかし、こうしたUI前提のコントロールはDeprecatedとされ、段階的に利用できなくなる方向が示されています。Microsoft Learnや関連する告知では、利用率の低さや、モダンUIとの整合性、アクセシビリティの問題などが理由として挙げられていました。

この変更が意味するのは、Salesが「画面をどう見せるか」を中心に進化するプロダクトではなくなった、という点です。営業活動の本質はUIの工夫ではなく、データとプロセスにある、という考え方が前提になりつつあります。

レガシーな営業支援機能と手動前提プロセスの見直し

Salesにはこれまで、営業担当者の操作や判断を前提とした支援機能が多く組み込まれてきました。活動履歴の入力、進捗の更新、フォーキャストの調整など、人が画面を操作することを前提としたプロセスが中心でした。

Deprecationの流れを見ると、こうした「人が入力し、人が判断する」ことを前提とした補助機能が、積極的に整理されていることが分かります。Microsoftは、SalesにおいてもCopilotやAI Agentを前提とした営業プロセスへの転換を進めており、その文脈に合わない機能はDeprecationの対象になっています。

これは、営業担当者の仕事を奪うという話ではありません。むしろ、入力や整理といった作業から人を解放し、判断や顧客対応といった本来価値のある活動に集中させるための再設計だと捉えるべきでしょう。

Sales単体で完結する設計からの脱却

Dynamics 365 SalesのDeprecationを俯瞰すると、「Sales単体で完結する CRM」という前提が、もはや成立しなくなっていることが見えてきます。従来は、Sales内でデータを保持し、Sales内で分析し、Sales内で意思決定を行う設計が主流でした。

しかし現在は、Dataverseを中核としたデータ統合、Customer InsightsやPower BIとの連携、さらにはMicrosoft 365 Copilotとの統合が前提となっています。Salesに閉じた独自機能や独立した分析機能は、こうした横断的なアーキテクチャと整合しないため、整理対象となっています。

サマリー｜Dynamics 365 Sales Deprecationから見える全体傾向

Dynamics 365 SalesにおけるDeprecationを総合すると、そこにあるメッセージは明確です。Sales は、「入力して管理する CRM」から、「営業活動を横断的に支援するデータ基盤」へと役割を変えつつあります。

UIコントロールの整理は、画面中心の設計からの脱却を意味しています。手動前提の営業支援機能の見直しは、CopilotやAI Agent を前提とした営業プロセスへの移行を示しています。そして、Sales単体で完結する設計が前提でなくなっていることは、CRMがより大きな業務・データエコシステムの一部として位置づけられていることを示しています。今の自分の仕事においても、そうあるべきだと感じる事がとても多いので、あるべき方向性だと感じています。

第4章｜Dynamics 365 Customer Service Deprecated Features 解説

―Deprecationから読み解く、「対応するサポート」から「導くサービス」への転換ー

Dynamics 365 Customer ServiceにおけるDeprecationは、UIや機能単位の整理にとどまらず、顧客対応という行為そのものの再定義を強く感じさせる内容になっています。Microsoft LearnのDeprecations in Dynamics 365 Customer Serviceには、これから前提にすべきサポートの姿が明確に表れています。以下では、Customer Serviceの方向性を象徴する代表的なDeprecationを取り上げ、その意味を読み解いていきます。

AIによる「補助的な提案」機能の整理

Customer Serviceにはこれまで、ナレッジ記事のキーワードや説明文をAIが自動提案するなど、いわば「人の作業を部分的に助ける」タイプのAI機能が存在していました。これらは、既存の業務フローを前提に、その一部を効率化することを目的としたものでした。

しかし、こうしたAIによる補助的な提案機能はDeprecatedとされ、Copilotを用いた新しい体験へと置き換えられる方向が示されています。Microsoft Learnでは、既存のAI機能が段階的に廃止され、Copilotを前提とした生成・支援モデルへ移行することが明示されています。

この変更は、単にAI機能が入れ替わったという話ではありません。Customer ServiceにおけるAIの役割が、「部分最適な補助」から「業務全体を横断的に支援する存在」へと変わったことを意味しています。

独立したツール・コンポーネントの整理

Customer Serviceでは、専用ツールとして提供されてきたコンポーネントもDeprecationの対象となっています。D365 Service MCP Serverはその代表例で、これまで独立した形で提供されていたツールがDeprecatedとされ、新しいCustomer Service MCP Serverへ統合されることが示されています。

この動きは、「ツールを追加することで機能を拡張する」という従来型のアプローチからの転換を表しています。Microsoftは、Customer Serviceを複数の独立したコンポーネントの集合としてではなく、一貫した体験を提供する単一のサービス基盤として再構築しようとしています。

分析・可視化における旧来モデルの見直し

Customer ServiceやContact Centerでは、統合ルーティングに関する履歴分析ダッシュボードなど、アプリ内に組み込まれた分析機能が提供されてきました。これらの機能は、画面上で状況を確認することを前提としたものでした。

こうした履歴分析ダッシュボードはDeprecatedとされ、より高度な分析はAzure Application Insightsなどの外部基盤を前提とする方向が示されています。

この変更が示しているのは、Customer Serviceにおいても「内蔵された簡易分析」で完結させる考え方の終焉です。分析は専用の基盤で行い、Customer Serviceは業務の実行と体験に集中する、という役割分担がより明確になっています。

旧世代のAI分類・トピック機能の整理

Customer Serviceには、ケースや会話内容をAIによって分類・クラスタリングするための旧来型のトピック機能が存在していました。これらは一定の効果を発揮してきましたが、ルールやモデルの制約が大きく、柔軟性に欠ける側面もありました。

これらの旧世代AIトピック機能はDeprecatedとされ、将来的に利用できなくなることが明示されています。Microsoft Learnでは、これらをCopilotベースの新しい分析・支援モデルへ移行する方針が示されています。

この流れは、Customer ServiceにおけるAI活用が「固定モデルによる分類」から「文脈を理解し、行動を提案するAI」へと進化していることを示しています。

サマリー｜Dynamics 365 Customer Service Deprecationから見える全体傾向

Dynamics 365 Customer ServiceにおけるDeprecationを総合すると、そこにあるメッセージは非常に明確です。Customer Serviceは、「問い合わせに対応するためのツール」から、「顧客体験全体を導くサービス基盤」へと役割を変えつつあります。

補助的なAI機能が整理され、Copilotを前提とした支援モデルへ移行していることは、AIの位置づけが根本的に変わったことを示しています。独立したツールやコンポーネントが統合されているのは、分断された管理や運用を前提としないためです。そして、分析機能が外部基盤へ移行している点は、Customer Serviceが「すべてを内包するアプリ」である必要はない、という明確な割り切りを示しています。

第5章｜Dynamics 365 Contact Center Deprecated Features 解説

―Deprecationから読み解く、「チャネルを処理する」から「体験を設計する」への転換ー

Dynamics 365 Contact CenterにおけるDeprecationは、Customer Service 以上に「運用前提の見直し」を強く感じさせる内容になっています。Microsoft LearnのDeprecations in Dynamics 365 Contact Centerには、これからのコンタクトセンターがどのような前提で設計されるべきかが、はっきりと示されています。以下では、Contact Centerの方向性を象徴するDeprecationを順に見ていきます。

音声ワークストリームにおけるポストコールサーベイ設定の整理

Dynamics 365 Contact Centerでは、音声ワークストリームのLanguageタブから直接ポストコールサーベイを有効化する設定が提供されていました。これは、音声対応の直後に簡易的なフィードバックを取得するための、比較的手軽な設定方法でした。

このポストコールサーベイのトグル設定はDeprecatedとされ、今後はCopilot Studioを用いてフィードバックサーベイを構成することが推奨されています。Microsoft Learnでは、既存の設定方法が廃止され、より柔軟で拡張性の高い設計へ移行することが明示されています。

この変更が示しているのは、「設定項目を用意しておけば足りる」という発想からの脱却です。Contact Centerにおける顧客フィードバックは、固定的なオプションではなく、業務や体験設計の一部として扱われるべきだ、という考え方が前提になりつつあります。

チャット応答の下書き生成（Preview）の廃止

チャットチャネルにおいては、エージェントの応答を支援するために、AIが下書きを生成するプレビュー機能が提供されていました。この機能は、エージェントが文章を考える負荷を下げることを目的としたものでした。

しかし、この下書き生成機能はプレビュー段階のままDeprecatedとされ、将来的に削除されることが示されています。Microsoft Learnでは、プレビュー機能としての開発を継続しない判断が下されたことが明記されています。

ここから読み取れるのは、Contact CenterにおけるAI活用が「単純な文面生成」に留まらないという点です。Microsoftは、個別チャネルごとの補助機能ではなく、より包括的に文脈を理解し、対応を導くAI体験へと進もうとしています。

音声チャネルにおけるローカルホスティングの非推奨化

Contact Centerでは、従来の音声チャネルにおいて、一部の国や地域でローカルホスティングが利用されてきました。これは、通信規制やデータ所在要件への対応を目的とした運用形態でした。

このローカルホスティングの仕組みはDeprecatedとされ、段階的に廃止されていくことが示されています。Microsoft Learnでは、今後はグローバルクラウド展開を前提とした音声体験へ移行する必要があることが説明されています。

この変更は、単なるインフラ構成の見直しではありません。Contact Centerが「国や環境ごとに別物として構築されるシステム」から、「グローバルに一貫した体験を提供する基盤」へと進化していることを示しています。

サマリー｜Dynamics 365 Contact Center Deprecationから見える全体傾向

Dynamics 365 Contact CenterにおけるDeprecationを総合すると、そこにあるメッセージは非常に明確です。Contact Centerは、「チャネルをつなぎ、問い合わせを処理するための仕組み」から、「顧客体験を一貫して設計・改善するための基盤」へと役割を変えつつあります。

ポストコールサーベイの設定がCopilot Studioへ移行していることは、体験設計を固定的な設定項目として扱わない姿勢の表れです。チャット下書き生成の整理は、断片的なAI活用を見直し、より文脈理解を重視した支援モデルへ進む過程だと捉えられます。そして、音声チャネルのローカルホスティング廃止は、Contact Centerをグローバルクラウド前提で再設計するという強い意思を示しています。

第6章｜Dynamics 365 Field Service Deprecated Features 解説

―Deprecationから読み解く、「現場を支援する」から「業務を統合する」への転換ー

Dynamics 365 Field ServiceにおけるDeprecationは、現場向け機能の整理にとどまらず、Field Serviceが担う役割そのものの変化を強く示しています。Microsoft LearnのFeature Deprecations – Dynamics 365 Field Serviceには、今後前提にすべきField Serviceの位置づけが、はっきりと表れています。以下では、Field Serviceの方向性を象徴するDeprecationを順に見ていきます。

Dynamics 365 Guides/Remote Assistアプリケーションの廃止

Dynamics 365 GuidesおよびRemote Assistは、現場作業者を支援するためのアプリケーションとして提供されてきました。ARやリモート支援を活用し、作業手順の可視化や遠隔支援を行うことを目的としたソリューションです。

これらのアプリケーションはDeprecatedとされ、将来的に提供が終了することが明示されています。Microsoft Learnでは、GuidesとRemote Assistが一定の役割を果たしてきたものの、今後はより統合されたField Service体験へ移行する方針が示されています。

この変更が意味するのは、個別アプリによって現場作業を補助するアプローチからの転換です。Field Serviceは、専用ツールを追加することで現場を支援するのではなく、業務プロセス全体の中で現場作業をどう位置づけるかを重視する段階に入っています。

Finance and Operations との従来型統合の廃止

Dynamics 365 Field Serviceには、これまでFinance and Operationsアプリケーションとの統合機能が用意されていました。作業指示、在庫、プロジェクト、請求などを連携させるための仕組みです。

この統合機能はDeprecatedとされ、将来的に利用できなくなることが示されています。Microsoft Learnでは、従来型の統合に代わり、よりシンプルで統合されたField Service体験を提供する方向性が示されています。

ここで重要なのは、Field ServiceとFinanceを切り離すという話ではありません。むしろ、個別の連携機能に依存する統合モデルそのものが見直されていると捉えるべきです。Field Serviceは、業務全体をまたいだデータとプロセスの中に組み込まれる存在へと再定義されています。

Microsoft 365連携（Outlook/Teams/Planner等）の整理

Field Serviceでは、Microsoft OutlookやTeams、Viva Connections、Plannerなどとの個別連携が提供されてきました。これらは、現場作業やスケジュール管理を Microsoft 365側から補助するための仕組みでした。

これらの個別連携はDeprecatedとされ、将来的にサポートされなくなることが示されています。Microsoft Learnでは、今後は Microsoft 365 内でより統合されたField Service体験を提供する方針が示唆されています。

この動きは、「ツールをつなぐ」発想からの脱却を意味します。Field Serviceは、外部ツールとの点的な連携によって成り立つのではなく、統合された体験の一部として提供されるべきものへと変わりつつあります。

Field Service標準レポートの廃止

Dynamics 365 Field Serviceには、標準で利用できるレポートがいくつか用意されていました。これらは、稼働状況やパフォーマンスを把握するための基本的な可視化手段として使われてきました。

これらの標準レポートも Deprecatedとされ、将来的にサポートされなくなることが示されています。Microsoft Learnでは、より柔軟な分析については Power BIなどの外部分析基盤を利用することが前提とされています。

この変更は、Field Serviceが「レポートを内包するアプリ」である必要はない、という明確な割り切りを示しています。分析と業務実行を分離し、それぞれに最適な基盤を使うという思想が前提になっています。

サマリー｜Dynamics 365 Field Service Deprecationから見える全体傾向

Dynamics 365 Field ServiceにおけるDeprecationを総合すると、そこにあるメッセージは明確です。Field Serviceは、「現場を個別に支援するための機能群」から、「業務プロセス全体の中で現場作業を統合する基盤」へと進化しています。

専用アプリの廃止は、ツールを増やすことで現場を支援する発想の終焉を示しています。FinanceやMicrosoft 365との従来型統合の整理は、点と点をつなぐ連携モデルからの脱却を意味します。そして、標準レポートの廃止は、分析をField Serviceの内部に閉じ込めないという明確な意思表示です。

第7章｜Dynamics 365 Project Operations Deprecated Features 解説

―Deprecationから読み解く、「プロジェクトを管理する」から「業務として統合する」への転換ー

Dynamics 365 Project OperationsにおけるRemoved/Deprecated Featuresは、派手さはありませんが、プロジェクト管理という領域の捉え方が大きく変わっていることを示しています。Microsoft LearnのRemoved or Deprecated Features in Dynamics 365 Project Operationsには、その変化が静かに表れています。以下では、Project Operationsの方向性を象徴するDeprecationを見ていきます。

調整トランザクションを制御するパラメーターの廃止

Project Operationsではこれまで、「常に調整トランザクションを作成するかどうか」や、「調整日をプロジェクト日付として扱うかどうか」といった、会計処理の挙動を制御するためのパラメーターが用意されていました。これらは、期末調整や過去期間修正といった実務に対応するための仕組みでした。

これらのパラメーターはDeprecated、もしくは非表示化され、システム側で常に調整トランザクションを作成する挙動へと統一されました。Microsoft Learnでは、その理由として、監査や会計上の整合性を確保するため、調整トランザクションは常に必要であることが挙げられています。

この変更は、ユーザーが設定で挙動を制御する余地を減らすものですが、その代わりに、会計・監査要件を満たすことをシステム側が保証する設計へ移行したことを意味しています。

会計期間クローズを前提とした旧来パラメーターの整理

「調整日を新しいプロジェクト日付として使用する」といったパラメーターは、会計期間がクローズされた後でも調整を行うために設けられていました。しかし、現在ではトランザクションの会計日付を適切に制御できるため、このような回避的な設定は不要になっています。

その結果、こうしたパラメーターはDeprecatedとされ、段階的に整理されています。Microsoft Learnでは、機能そのものが不要になったことが理由として説明されています。

ここから読み取れるのは、Project Operationsが「例外処理を設定で吸収する」設計から離れつつあるという点です。プロジェクト会計においても、標準的で一貫した処理が前提になっています。

複数資金ソース対応に関する設計の見直し

Project Operationsでは、複数の資金ソースを持つプロジェクトに対応するための設定や機能が存在していました。一部の機能についてはDeprecationが検討されましたが、Microsoft Learnでは最終的に機能自体は維持されることが明示されています。ただし、関連する一部の機能は将来的に必須化される予定であり、設定による分岐を減らす方向性が示されています。これは、柔軟性を残しつつも、業務要件を標準プロセスに寄せていくというMicrosoftの姿勢を表しています。

サマリー｜Dynamics 365 Project Operations Deprecationから見える全体傾向

Dynamics 365 Project OperationsにおけるDeprecationを総合すると、そこにあるメッセージは明確です。Project Operationsは、「プロジェクトごとに例外を設定して運用するシステム」から、「会計・監査・業務プロセスを前提に統合されたプロジェクト基盤」へと進化しています。

設定で挙動を切り替える余地が減っているのは、自由度を奪うためではありません。むしろ、プロジェクト会計という複雑な領域において、正しさと一貫性をシステム側で担保するという設計思想への転換だと捉えるべきでしょう。

第8章｜Dynamics 365 Commerce Deprecated Features 解説

―Deprecationから読み解く、「店舗とECを管理する」から「コマース体験を統合する」への転換ー

Dynamics 365 CommerceにおけるRemoved / Deprecated Deaturesは、店舗、EC、バックオフィスをまたぐコマース体験の設計思想そのものが変わりつつあることを示しています。Microsoft LearnのRemoved or Deprecated Features in Dynamics 365 Commerceは、その変化を最も正直に表したドキュメントです。以下では、Commerceの方向性を象徴するDeprecationを見ていきます。

テナントディレクトリ内でのユーザー ID 作成機能の廃止

Dynamics 365 Commerceでは、これまでCommerce Headquartersから直接、テナントディレクトリ内に新しいユーザーIDを作成する機能が提供されていました。これは、店舗スタッフやバックオフィス担当者のユーザー管理をCommerce側で完結させるための仕組みでした。

この機能はDeprecatedとされ、将来的に完全に利用できなくなることが示されています。Microsoft Learnでは、その理由として、Finance and Operationsアプリケーションからテナントのユーザーディレクトリへ直接アクセスさせないことで、プラットフォーム全体のセキュリティを向上させることが挙げられています。今後は、ユーザーIDはMicrosoft Entra ID側で作成し、Commerce側では既存のIDを関連付ける運用が前提となります。

この変更が意味するのは、Commerceが「ユーザー管理まで抱え込むアプリ」である必要はない、という明確な割り切りです。ID管理はEntra IDに集約し、Commerceは業務と体験に集中するという役割分担が、ここではっきりと示されています。

機能フラグ前提の地域固有機能の整理

Commerceでは、特定の国や地域向けに、機能フラグを用いて有効化・無効化する仕組みが提供されてきました。イタリア向けの Retail POSにおける顧客情報管理機能などが、その一例です。

これらの機能はDeprecatedとされ、理由としては「機能が既に標準で提供されており、フラグによる制御が不要になった」ことが挙げられています。

この変更は、地域固有要件を否定するものではありません。むしろ、Commerceにおいては、ローカル要件を標準機能として吸収し、例外扱いを減らすという設計方針がより強くなっていることを示しています。

Commerce内包型の管理・分析機能の見直し

Removed/Deprecated featuresを俯瞰すると、Commerce内に閉じた形で提供されていた管理機能や分析機能が、段階的に整理されていることが分かります。これは、Commerceを「すべてを内包する巨大なアプリ」として成長させるのではなく、Power Platformや Power BI、Entra IDといった周辺基盤と役割分担する方向へ進んでいることの表れです。

この思想は、Business CentralやFinance、Field Serviceなど、他のアプリケーションで見られたDeprecationの流れとも明確に一致しています。

サマリー｜Dynamics 365 Commerce Deprecationから見える全体傾向

Dynamics 365 CommerceにおけるDeprecationを総合すると、そこにあるメッセージは非常に明確です。Commercは、「店舗とECを個別に管理するシステム」から、「顧客・商品・価格・決済を横断的に統合するコマース基盤」へと進化しています。

ユーザーID管理がEntra IDに集約されていることは、セキュリティとガバナンスをプラットフォームに委ねるという判断です。地域固有機能の整理は、例外を減らし、標準化されたコマース体験を広げていく姿勢を示しています。そして、Commerce内包型の管理・分析機能が見直されている点は、分析や自動化をより適切な基盤に委ねるという、成熟したアーキテクチャへの移行を意味しています。

第9章｜Dynamics 365 Customer Insight-Data Deprecated Features 解説

―Deprecationから読み解く、「顧客データを集める」から「価値ある洞察を生む」への転換ー

Dynamics 365 Customer Insights–DataにおけるRemoved/Deprecated featuresは、顧客データ基盤の役割そのものが変わりつつあることを明確に示しています。Microsoft LearnのRemoved or Deprecated Features in Dynamics 365 Customer Insights–Dataには、「何をやらないと決めたのか」がはっきりと書かれています。以下では、Customer Insights–Data の方向性を象徴するDeprecationを見ていきます。

アカウントエンゲージメントエンリッチメントの廃止

Customer Insight–Dataでは、アカウント単位でのエンゲージメント情報を付加するためのエンリッチメント機能が、パブリックプレビューとして提供されていました。これは、外部データや行動情報をもとに、企業アカウントの理解を深めることを目的とした機能です。

このアカウントエンゲージメントエンリッチメントはRemovedとされ、提供が終了しました。Microsoft Learnでは、プレビュー機能は顧客価値とサービス維持コストのバランスを見ながら継続可否を判断していることが理由として示されています。

この判断は、Customer Insights–Dataが「できることを増やすためにプレビュー機能を抱え続ける」プロダクトではない、という姿勢を明確に示しています。価値が証明され、スケールできるものだけを残すという、基盤プロダクトとしての成熟が感じられます。

HEREエンリッチメントおよび企業データエンリッチメントの整理

Customer Insights–Dataには、外部プロバイダーと連携して位置情報や企業情報を補完するエンリッチメント機能が用意されていました。HEREエンリッチメント（位置情報を補完・強化するための機能）や拡張された企業データエンリッチメントは、その代表例です。これらの機能はRemovedとされ、代替としてAzure Mapsエンリッチメント、あるいはLeadspaceやDun & Bradstreetなどの外部サービスが推奨されています。

この変更が意味するのは、Customer Insights–Dataが「あらゆる外部データを内包する基盤」ではない、という明確な線引きです。データ統合の中核は担うものの、専門性の高いデータ供給については、外部エコシステムに委ねるという設計思想が前提になっています。

Teamsボット機能の廃止

Customer Insights–Dataには、Teams上でインサイトを確認したり通知を受け取ったりするためのボット機能が存在していました。このTeamsボットは、ユーザーが日常的に利用するツールからインサイトにアクセスできることを狙った機能です。

この Teamsボット機能はRemovedとされ、現在は利用できなくなっています。Microsoft Learnでは、代替としてBot Framework SDKやPower Virtual Agents（Copilot Studio）を用いたカスタムボットの構築が案内されています。

ここから読み取れるのは、「製品内蔵の簡易ボット」でユースケースを満たす時代が終わったという点です。Customer Insights–Dataは、通知や対話のレイヤーまで抱え込むのではなく、標準プラットフォーム上で拡張することを前提にしています。

サマリー｜Dynamics 365 Customer Insights–Data Deprecationから見える全体傾向

Dynamics 365 Customer Insights–DataにおけるDeprecationを総合すると、そこにあるメッセージは非常に明確です。Customer Insights–Dataは、「顧客データをできるだけ多く集め、何でも内製で補完する基盤」から、「統合と洞察に集中する中核データ基盤」へと進化しています。

プレビュー機能が整理されているのは、実験的な機能を抱え続けないという判断です。外部エンリッチメント機能の整理は、専門性の高い領域をエコシステムに委ねるという姿勢を示しています。そして、Teamsボットの廃止は、体験レイヤーを製品に内包しないという、明確なアーキテクチャの割り切りです。

第10章｜Dynamics 365 Customer Insight-Journey Deprecated Features 解説

―Deprecationから読み解く、「施策を配信する」から「リアルタイムで顧客と対話する」への転換ー

Dynamics 365 Customer Insights–JourneysにおけるRemoved/Deprecated Featuresは、マーケティングオートメーションの考え方そのものが転換点を迎えていることを如実に示しています。Microsoft LearnのRemoved or Deprecated Features in Dynamics 365 Customer Insights–Journeysには、「何をコアとし、何を切り離すのか」というMicrosoftの意思がはっきりと表れています。以下では、Journeysの方向性を象徴するDeprecationを見ていきます。

AI支援によるテーマ生成・効果分析機能の整理

Customer Insights–Journeysでは、メールやフォーム、ブランドプロファイルをAIによって支援的に装飾・最適化する機能や、マーケティング効果を分析するための一部分析機能が、パブリックプレビューとして提供されてきました。

これらのAI支援テーマ機能やマーケティング効果分析機能はDeprecatedとされ、提供が終了しています。Microsoft Learnでは、これらの機能がプレビューとして継続的に評価された結果、顧客価値とサービス維持コストのバランスの観点から整理されたことが説明されています。

この判断が示しているのは、Journeysが「小さなAI機能を数多く内包するプロダクト」を目指していないという点です。JourneysにおけるAIは、部分的な補助ではなく、顧客との対話全体を設計・実行するための中核として位置づけ直されています。

ソーシャル投稿機能の廃止

Customer Insights–Journeysには、従来のアウトバウンドマーケティングの文脈で、ソーシャルメディアへの投稿を管理する機能が含まれていました。これは、キャンペーン施策の一部としてソーシャルチャネルを扱うための機能です。

このソーシャル投稿機能はRemovedとされ、リアルタイムJourneysには追加されないことが明示されています。Microsoft Learnでは、その理由として、需要や利用率が低かったことに加え、リアルタイムオーケストレーション戦略の中核ではないことが挙げられています。

この変更は、マーケティング施策の幅を狭めるものではありません。むしろ、Journeysが「すべてのチャネルを自前で管理するツール」ではなく、顧客とのリアルタイムな関係性を制御する基盤であることを明確にしています。

LinkedInリード生成機能の廃止

Customer Insights–Journeysには、LinkedInのリード生成機能と連携するための標準機能が存在していました。しかし、この機能は Removedとされ、利用できなくなっています。

Microsoft Learnでは、その理由として、LinkedIn側のAPI変更が挙げられています。将来的にリアルタイムJourneysに組み込まれる可能性は否定されていませんが、現時点では標準機能としては提供されていません。

ここから読み取れるのは、Journeysが外部プラットフォームとの個別連携を恒久的に抱え込む設計ではない、という点です。必要に応じてカスタム連携を構築する余地は残しつつも、製品のコアはあくまでオーケストレーションに置くという姿勢が貫かれています。

Fabric連携を前提とした分析機能への移行

マーケティング効果分析に関する一部の標準分析機能が整理された背景には、Microsoft Fabricとの統合があります。Microsoft Learnでは、分析についてはFabricを活用したカスタムレポーティングが推奨されています。

これは、Journeysが「分析まで内包するマーケティングツール」である必要はない、という明確な割り切りを示しています。分析は分析基盤で行い、Journeysはリアルタイムな顧客体験の制御に集中する、という役割分担です。

サマリー｜Dynamics 365 Customer Insights – Journeys Deprecation から見える全体傾向

Dynamics 365 Customer Insights–JourneysにおけるDeprecationを総合すると、そこにあるメッセージは非常に明確です。Journeysは、「キャンペーンを設計し、配信するためのマーケティングツール」から、「顧客とリアルタイムで対話し、関係性を継続的にオーケストレーションする基盤」へと進化しています。

支援的なAI機能や内包型の分析機能が整理されているのは、Journeysが部分最適の集合体になることを避けているからです。ソーシャル投稿や特定プラットフォーム連携の廃止は、チャネル管理を目的としないという明確な意思表示です。そして、Fabric連携を前提とした分析への移行は、データ基盤とオーケストレーション基盤を分離する、成熟したアーキテクチャへの移行を意味しています。

第11章｜Dynamics 365 Human Resource Deprecated Features 解説

―Deprecationから読み解く、「人事システムを持つ」から「人事をプラットフォームに委ねる」への転換ー

Dynamics 365 Human ResourcesにおけるRemoved/Deprecated Featuresは、他の業務アプリ以上に「Microsoftがどこまで自分たちで持たないのか」を明確に示しています。Microsoft LearnのRemoved or Deprecated Features in Dynamics 365 Human Resourcesは、人事領域におけるプロダクト戦略の転換点を静かに語っています。以下では、Human Resourcesの方向性を象徴するDeprecationを見ていきます。

米国給与（US Payroll）における税更新サポートの終了

Dynamics 365 Human ResourcesおよびFinanceには、米国向けの給与（US Payroll）機能が組み込まれており、これまでは税制変更に対応する更新も提供されてきました。

しかし、このUS Payroll機能に対する税更新の提供はDeprecatedとされ、一定のリリース以降は新しい税更新が行われなくなることが明示されています。Microsoft Learnでは、給与機能そのものは引き続き動作するものの、将来の税制変更には対応しない点が説明されています。

この変更が意味するのは、給与計算という高度にローカルかつ規制依存の領域を、Microsoftが自前で継続的にメンテナンスしないという明確な判断です。Human Resourcesは、給与を「内製機能」として抱えるのではなく、専門のISVや外部サービスと連携する前提へと移行しています。

Human Resources（スタンドアロン）環境におけるLCSプロジェクト作成の終了

かつてDynamics 365 Human Resourcesは、Finance and Operationsとは独立したスタンドアロン構成として提供されていました。そのため、Lifecycle Services（LCS）上でHuman Resources単体のプロジェクトを作成し、環境を管理することが可能でした。

このスタンドアロン構成での新規LCSプロジェクト作成はDeprecatedとされ、現在はサポートされていません。Microsoft Learnでは、Human ResourcesがFinance and Operationsのインフラへ統合されたことが、その背景として説明されています。

この変更は、単なる管理手順の変更ではありません。Human Resourcesが「単独で完結する業務アプリ」ではなく、Finance and Operationsと同じ基盤上で動作する一機能領域として再定義されたことを意味しています。

Human Resources（スタンドアロン）における本番環境プロビジョニングの終了

スタンドアロン構成のHuman Resourcesでは、専用の手順で本番環境をプロビジョニングすることができました。しかし、この方式もDeprecatedとされ、現在はFinance and Operationsのインフラ上での環境プロビジョニングに統一されています。Microsoft Learnでは、これもインフラ統合の一環として説明されています。ここから読み取れるのは、Human Resourcesを特別扱いしない、という Microsoftの姿勢です。人事も財務やSCMと同様に、共通基盤上で運用・管理される業務領域になっています。

サマリー｜Dynamics 365 Human Resources Deprecation から見える全体傾向

Dynamics 365 Human ResourcesにおけるDeprecationを総合すると、そこにあるメッセージは非常に明確です。Human Resources は、「人事業務を完結させるための単独アプリ」から、「業務プラットフォームの中で人材情報を扱う基盤」へと進化しています。

給与税更新の終了は、ローカルかつ高頻度で変化する領域を自前で抱えないという判断です。スタンドアロン構成の終了は、人事を Finance and Operationsの一部として再定義したことを示しています。そして、環境管理やプロビジョニングの統合は、人事も他業務と同じガバナンスの下で扱うという姿勢の表れです。

第12章｜Dynamics 365 Universal Resource Scheduling Deprecated Features 解説

―Deprecation から読み解く、「個別最適な割当」から「横断的な計画基盤」への転換ー

Universal Resource Scheduling（URS、Common Scheduler）は、Dynamics 365の複数アプリケーションにまたがって利用される、共通のスケジューリング基盤です。Field Service、Project Operations、Customer Serviceなどで、リソースの割当やスケジュール調整を支える役割を担ってきました。Microsoft LearnのFeature Deprecations for Universal Resource Schedulingには、この共通基盤がどのように再定義されつつあるのかが示されています。

スケジューリング関連機能の段階的整理

Universal Resource Schedulingでは、これまでスケジュールボードやスケジュールアシスタントを中心に、さまざまな補助機能が提供されてきました。これらは、リソース割当をより細かく制御するための機能群です。

Deprecationの対象となっているのは、こうしたスケジューリング機能そのものというよりも、特定の前提や旧来の使い方に依存した挙動です。Microsoft Learnでは、将来のリリースに向けて、一部の機能がDeprecatedとされ、より新しいスケジューリング体験へ移行する準備が進められていることが説明されています。

この整理は、「スケジュールができなくなる」という話ではありません。むしろ、スケジューリングを個別アプリのローカルな機能として扱う前提を見直していると捉えるべきです。

アプリ固有の割当ロジックから共通基盤への集約

URSが導入された背景には、Field ServiceやProject Operationsなど、アプリごとに異なる割当ロジックを持たせていた過去があります。Universal Resource Schedulingは、それらを共通化することで、一貫したリソース管理を実現するための基盤でした。

Deprecationの流れを見ると、この共通基盤をさらに進化させ、「人が細かく操作するスケジューリング」から、「制約条件と最適化を前提にした計画基盤」へと移行しようとしていることが分かります。旧来の操作前提や例外的な設定は整理され、より標準化された挙動が前提になっています。

Copilot/自動化前提のスケジューリングへの布石

Universal Resource Scheduling(URS)のDeprecationを、他章で見てきたCopilotやAI活用の流れと重ねると、方向性は一貫しています。スケジューリングは、将来的に「人がドラッグ & ドロップで調整する作業」ではなく、「条件を与えれば最適案を提示・実行する領域」へと移っていきます。

URSにおけるDeprecationは、そのための前提条件を整理する動きだと捉えることができます。旧来の UI や操作モデルに依存した機能を残したままでは、AIや自動最適化を前提とした進化は難しいからです。

サマリー｜Universal Resource Scheduling Deprecationから見える全体傾向

Universal Resource SchedulingにおけるDeprecationを総合すると、そこにあるメッセージは明確です。URSは、「各アプリの裏側で使われる補助機能」から、「業務横断で計画と最適化を担う中核基盤」へと進化しています。

個別アプリ固有の前提や、人の操作に強く依存した挙動が整理されているのは、自由度を下げるためではありません。むしろ、スケジューリングを自動化・最適化できる領域へ引き上げるための整理だと捉えるべきでしょう。

最終章｜Deprecation を“終わり”ではなく“設計の入口”にする

最後までお付き合いいただき、本当にありがとうございました。

ここまで、Dynamics 365 2026 wave1の発表と同時に公開された Deprecations（将来的に廃止される機能）を起点に、各アプリケーションで「何が前提でなくなっていくのか」を横断的に見てきました。Deprecationは「今すぐ使えなくなる」ことを意味するものではなく、当面は動作し、正式に削除されるまではサポートも継続されます。しかし同時に、それは「これ以上進化しない」こと、そして将来のアップデートで削除され得ることを意味します。

この“二面性”こそが、Deprecationの本質だと私は感じています。使えるからといって安心して設計の中心に据え続けると、数年後に「作り直し」が確定してしまう。一方で、早い段階から前提を入れ替えておけば、将来の変化は“痛み”ではなく“自然な進化”として受け止められる。Deprecationは、機能整理の一覧というよりも、Microsoftが次の世代へ移るために「前提条件を静かに切り替えている」ことを示すサインなのだと思います。

そして、ここまで見てきた内容を一言でまとめるなら、Dynamics 365全体が「UIで業務を完結させる世界」から離れ、CopilotやAI Agentを前提とした「業務を実行するプラットフォーム」へ寄っている、という点に尽きます。

UIを工夫し、人が入力し、人が一覧を見て判断する運用は、過去の最適解だったからこそ広く普及しました。しかし 2026 wave1の Deprecationsは、その前提条件そのものが変わってきたことを示しています。過去を否定するのではなく、未来へ進むための整理です。

では、ここからが本題です。こうした変化に対して、実際のユーザー企業、そしてITベンダー（導入パートナー／ISV）は、どんな“実務の手”を打つべきでしょうか。ここで重要なのは、「どの機能が消えるか」を暗記することではありません。自社の環境や提案の中に、Deprecationと衝突する前提が含まれていないかを点検し、必要なら“設計を入れ替える”ことです。

まずユーザー企業側（情報システム部門・業務部門）にとって最初の一歩は、「影響の棚卸し」を“仕様”ではなく“依存関係”として行うことだと考えます。画面や帳票、連携、運用のどこで、Deprecatedな仕組みを「当たり前」として使っているのか。特に外部連携は、UIや旧API、テンプレート的な同期方式など「便利だから」という理由で採用されていることが多い領域です。ここを放置すると、将来のアップデートで現場が突然困る形になります。逆に言えば、連携や運用の依存関係を先に整理できれば、Deprecationは“怖い話”ではなくなります。

次に、ユーザー企業がやっておくと効くのは、「代替手段を“使ってみる”」ことです。ドキュメント上の代替機能が、現場のプロセスやデータ品質と噛み合うかどうかは、読んだだけでは判断できません。だからこそ、Sandboxでの試行や、業務の一部を切り出した小さな検証が重要になります。Deprecationは、いつかやらなければならない移行を、前倒しで“安全に”実施できるチャンスでもあります。

一方、ITベンダー側（導入パートナー／SI／ISV）にとっての最大のポイントは、「提案の差別化軸」を“カスタマイズ”から“前提設計”へ移すことだと思います。これまでの提案は、画面や帳票、運用の細部を作り込むことで価値を出す場面が多くありました。しかし、Microsoft自身が UI 前提や内包型の補助機能を整理し、プラットフォームの役割分担を明確にしている以上、提案価値は「どこを作るか」ではなく「何を前提にするか」へ移っていきます。

例えば、分析はアプリ内の標準ダッシュボードではなくデータ基盤側で設計するのか、連携はUI流用ではなく正式API前提で設計するのか、業務は“人が入力する”前提ではなく“AIが実行し人が監督する”前提へ寄せるのか。これらは機能の多寡ではなく、設計思想の問題です。

また、ベンダー側は「お客様の環境を守る」責任も負っています。Deprecationを知らずに提案・実装してしまうと、数年後に“技術的負債”が顧客に残ります。逆に、Deprecationを踏まえて「今は動くけれど、将来の前提ではない」と明確に説明し、移行計画や回避設計まで含めて提案できれば、それは信頼そのものになります。Copilot/Agent時代の提案力とは、派手なデモよりも、こうした“設計の誠実さ”に宿ると私は思っています。

ここまでの連載を通じて、私が一貫して伝えたかったのは「使えるかどうか」ではなく「前提にしてよいかどうか」という視点です。Deprecationは、今日の業務を壊すためにあるのではありません。むしろ、明日の設計を誤らないために、Microsoftが早めに提示してくれている“地図”です。だからこそ、怖がるより先に、読み解き、前提を入れ替え、次の設計に活かす。これが、2026 wave1をきっかけにできる最も健全な向き合い方だと考えています。

Business Central（BC）については、 2026 wave1の内容をBlogに詳細に取り上げていますので、次回からは、Dynamics 365の他のアプリケーションについて、2026 wave1の「新機能」を順に整理していく予定です。

Deprecationで「前提にしない設計」を押さえたうえで、新機能で「これから前提にすべき設計」を積み上げていく。そうすることで、単なるリリースノートの紹介ではなく、設計と提案に効く形で2026 wave1を読み解いていけるはずだと思うからです。

次回以降も、現場で使える視点に落とし込みながら、一緒に“次の前提”を整理していければと思います。

いやぁ、なんだか今回のDeprecationsリストを見ていると、マイクロソフトとして、本気で『Project Code Green』をやろうとしているのではないだろうか？と察してしまいます。

ん？Project Code Green？

Microsoft社は2001年に北米でGreat PlainsとSolomonを買収、2002年には欧州でNavisionとAxaptaを買収し、ビジネスソリューションの中堅・中小企業のマーケットポジションを獲得したと言えます。CRMは独自開発。これらのERP/CRMを全部統合（コードグリーン）していきたいという思いはあったものの、各製品を利用中のお客様があること、アプリケーション単位で開発基盤、言語が違う事を考えたときに、短期勝負は非現実的だというご判断があったとは思います。また、お客様によりご満足いただくために、各々の製品で、機能拡張を継続してきたというのが事実なのでしょう。実は、当時のMicrosoft Businss Solutionsのリーダーは、今のCEOであるサティア・ナデラ氏でした。いやぁ、サティア氏若い！そして、この頃からキレキレ！

ローコード領域（Power Platform）のリーダー、チャールズ・ラマナ氏が、マイクロソフトのビジネスアプリケーション領域全体（Dynamics 365 CRM/ERP含め）を見るようになり、そしてCopilot｜AIも自分の責任の範囲に入った。今後のAIエージェントへの期待を考えると、今回のMicrosoftの動きは、個人的には非常に納得感があるものです。

私の想像は以下のとおりです。

1. 20年越しの「技術的制約」の解消

当時の「Project Green」が挫折した最大の理由は、「異なるデータベース構造とUIを無理やり一つにする技術が追いつかなかった」ことでした。NavisionもAxaptaも独自の言語とアーキテクチャを持っており、統合は難しかった。

2026年の現実: Dataverseという共通データ基盤と、Copilotという「UIに依存しない操作レイヤー」が登場したことで、もはや「ソースコードを一つにする」必要さえなくなりました。AIがバラバラなデータを解釈し、一つの窓口（Natural Language UI）で処理してくれる。

結論: 物理的な統合ではなく、「概念的な統合（Virtual Integration）」によって、当時の理想が完成するのではないか？

2. 「UIの終焉」＝「Greenの最終形態」

「Project Green」の当初のビジョンは、どの製品を使っていても同じ操作感（Look & Feel）を提供することも目的だったはず。

今回の廃止情報（API v1.0の廃止、レガシーレポートの削除など）が示しているのは、「人間が操作するUIそのものを最小化する」というさらに先のステップです。

今後は「No UI（AI Agentによる自律動作）」というチャレンジも可能となる。ここから5年―10年の期間で「製品の壁」が消滅していくのではないか？

3. 歴史の「再定義」

レガシー（Navision/Axapta/Great Plains/Solmonの残滓）を引きずった設計が、AI時代の足かせになるからではないか？

今回の廃止祭りは、単なる「掃除」ではなく、「新しい生命（AIネイティブなERP/CRM）を芽吹かせるための、古い土壌の入れ替え」のような気がしてなりません。