こんばんは。室長こと、吉島良平（Microsoft MVP for Business Applications| Microsoft Regional Director) です。今日は大晦日ですね。皆さま、いかがお過ごしでしょうか？

ご家族でゆっくり過ごせていれば最高ですね。31日もお仕事という皆さま、本当にお疲れ様です。皆さんのご努力のおかげで、日本のオペレーションは今日も回っています。ありがとうございます！

紅白歌合戦も始まり、いよいよ今年も残りわずか。本稿は2025年の総括です。最後までお付き合いいただければ幸いです。

DXは、もう導入の話ではありません

― Dynamics 365 CRM / ERP × Power Platform × AI を、現場で回し続けた2025年 ―DX365LIFE Year End Report 2025

序章｜2025年をどう振り返るか

2025年を振り返って、「大きく変わった年だった」と感じる人は、それほど多くないかもしれません。AIもCopilotも、話題としては一段落しました。ですが、現場を見ていると、別の変化が確実に起きていました。それは、整理が始まった年だったということです。

導入するかどうか、試すかどうか――そうした議論は、ほぼ終わりました。Dynamics 365 CRM / ERP や Power Platform は、「入れるかどうか」ではなく、『業務として回っているかどうか』が問われる段階に入っていました。DXは構想フェーズを抜け、2025年は、明確に運用の年でした。

この一年、DX365Lifeでは59本の記事を公開しました。主な関心は、まさにこの「導入から運用へ」という現場の重心移動にあります。内容は大きく五つに分かれますが、どれも“業務にどう乗せるか”という視点で書いてきました。

Dynamics 365 2025 Wave 1／Wave 2 のアップデートです。Sales、Field Service、Finance、SCM、Human Resources、Business Centralといった主要アプリケーションを横断し、単なる機能紹介に終わらない解説を心がけました。たとえば「Financeは何処に向かっているのか？」では、操作手順や仕様ではなく、業務プロセスにどう組み込めば“運用の質”が高まるのかを掘り下げています。知識を増やすためのレビューではなく、日々の業務改善に直結する視点を提供することを考えていました。

二つ目は、Power Platform のガバナンスと設計です。Dataverse、ALM、DLP、Managed Environments を軸に、ガイドライン → 運用ルール → 監査という三層で“民主化”を支える方法論を提示しました。CoE（Center of Excellence）の役割や、作ってよいもの／いけないものの線引きも、抽象論ではなく運用に足がついた書き方にしています。自由を認めることと、共有資産（データ構造・プロセス標準）を守ることは両立する、その具体策を示してきました。

三つ目は、Microsoftイベントのまとめ（Ignite／AI Tourなど）です。Copilot の進化、AIエージェントの方向性、Dynamics 365 と Power Platform のロードマップを、“現場でどう活かすか”に変換してお届けしました。新機能を覚えることが目的ではありません。既存業務のどこに差し込むと、手戻りが減り、判断が早くなるのか――そこに焦点を当てています。

四つ目は、オートモーティブ業界のイベントレポート。Technosoft Automotive Days 2025 では、グローバルDMS戦略と DX運用の設計原則を、登壇企業の実例を交えて整理しました。Japan Mobility Show では、「体験設計 × データ統合」という切り口で、モビリティDXの未来像を描いています。業界特化の事例であっても、Dynamics 365／Power Platform の活用と運用の設計に落ちると、他業界にも転用可能だという手応えがありました。

そして五つ目が、セミナーやイベントを通じたDXのご紹介です。Directions Asia や社内外の勉強会でお話しした内容を、記事としてまとめました。Copilot が現場に定着する条件、Power Platform の運用ガイドライン、Dynamics 365 のグローバル展開事例――“やってみた”ではなく“回し続ける”ための要点を、短い文脈でも過不足なく伝えるよう努めています。

以上の流れを一年追いかけてみて、結論として見えてきたのは、「DXはプロジェクトではなく、業務品質の話になっている」という現実です。Dynamics 365、Copilot、Power Platform は、単なる導入キーワードではなく、DX運用の基盤として静かに定着し始めた――その変化を、現場から観測した一年でした。

第1章｜Copilotは、業務を変えたのでしょうか

結論から言えば、Copilotが業務を“勝手に”変えることはありませんでした。2025年を通じて見えてきたのは、Copilotは整理された業務に対して「増幅器」として働くという現実です。つまり、Copilotの効果は、業務の成熟度をそのまま映し出す鏡のようなものでした。

Copilotが自然に使われていた現場には、いくつかの共通点があります。まず、成果物が明確であること。見積書や議事録、ケース応対記録、作業報告、請求書コメントなど、アウトプットの型が決まっている業務では、Copilotは違和感なく入り込みました。次に、手順が言語化されていること。Dynamics 365のビジネスプロセスフローが「何を先に、何を後に」という順序を示している場合、Copilotはその流れに沿って提案できます。そして、判断基準が共有されていること。SLAや優先度、承認ルールが運用ルールとして明文化されている業務では、Copilotの提案は現場に受け入れられやすくなります。

たとえば、Dynamics 365 SalesとCopilotを組み合わせた事例では、ミーティングの要約からアクション抽出、案件や取引先の更新、次回予定の自動提案までがスムーズに回っていました。単なる「会話の要約」ではなく、データ更新の起点として使えた現場ほど、効果が持続したのです。

Customer Serviceでは、ケース履歴の要約や類似ケースの知識記事検索、返信案のドラフト作成にCopilotが活躍しました。ここで重要だったのは、返信の評価基準をテンプレート化してCopilotに渡すこと。謝罪の有無、原因説明の明確さ、次の一手の具体性といった軸を事前に定義することで、品質のブレが減りました。Field Serviceでも同様です。作業報告の要約や消耗品の補充提案、次回訪問の推奨など、業務コードや部品マスタが整理されている現場では、Copilotの推奨精度が目に見えて高まりました。

逆に、Copilotがほとんど使われなかった業務には、三つの兆候がありました。目的が曖昧で、ドキュメントのゴールが揺らいでいること。前提が不一致で、用語定義や判定ルールの解釈が人によって異なること。そして、責任が曖昧で、承認者や最終判断の所在が不明なことです。この場合、「AIが使えない」という声が上がりますが、実際には業務が未整理であることの裏返しでした。

では、Copilotの価値をどう測るか。2025年に現場で使われ始めた指標が「アシスト率」です。これは、Copilotが生成した案を採用した回数を、Copilotを呼び出した回数で割ったものです。さらに、編集量の平均（文字数や修正点数）、反映までのリードタイムといった付帯指標を組み合わせることで、Copilotの定着度を定量化できます。週次レビューで「採用されなかった理由」を棚卸することも重要です。用語の不一致、KPIの不在、データの欠落――改善すべき対象はAIではなく、業務の土台にあることがほとんどでした。

最後に強調したいのは、Copilotに効くのは凝ったプロンプトではなく、業務の前提です。用語辞書を一枚にまとめること、返信案の評価軸をテンプレート化すること、タスク分解の標準を定義すること。こうした準備があるだけで、Copilotは現場に溶け込み、業務の質を底上げする存在になります。

第2章｜民主化の落とし穴：Power Platformを回す条件

2025年、Power Platformの評価は企業によって大きく分かれました。成功した企業と、混乱を招いた企業。その差を決めたのは、技術力ではなく「設計とガバナンス」でした。Power Platformは、よく「民主化ツール」と呼ばれます。しかし、実際には、業務設計ができる組織にとってのみ民主化される基盤です。自由にすれば回るわけではありません。むしろ、自由を与えすぎると、現場はすぐに「影アプリ」と「データの分断」に悩まされます。

成功した企業には、共通する構造がありました。まず、ガイドライン → 運用ルール → 監査という三層のガバナンスが整っていたことです。ガイドラインでは、Power Platformの目的や役割分担を明確にします。Dynamics 365とPower Apps／Power Automateの境界を定義し、品質基準を共有する。次に、運用ルール。Dataverseのスキーマ設計、セキュリティロール、DLPポリシー、接続制限――これらを最初から決めておくことで、アプリ乱立を防ぎます。そして最後に、監査。利用状況を可視化し、孤立したアプリを検知し、レビューや廃止のワークフローを回す。この三層が揃っている企業では、Power Platformは「現場の自律性」を支える武器になっていました。

一方で、ガバナンスを軽視した企業では、Dynamics 365と乖離したアプリが増え、重複マスタや個人所有の影アプリが氾濫しました。顧客マスタを複製したアプリ、案件計測を独自定義したアプリ――こうした「作ってはいけないもの」が放置されると、DXは逆に複雑化します。だからこそ、成功企業は「作ってよいもの／いけないもの」を明文化し、CoE（Center of Excellence）でレビューを定期化していました。四半期ごとの棚卸し、再利用可能コンポーネントのカタログ化、設計原則の教育――こうした地味な取り組みが、Power Platformを「混乱の温床」ではなく「業務改善の加速装置」に変えていたのです。

もう一つ重要なのは、Managed EnvironmentsとALM（ソリューション管理）です。開発・テスト・本番の環境を分離し、Deployment Pipelinesで移送を標準化する。CanvasアプリやModel-drivenアプリ、Power Automateのフローをソリューション単位で管理する。命名規則を決め、発見性を高める。こうした基本ができていないと、Power Platformは「便利な個人ツール」で終わってしまいます。

そして、Power Automateの使い方にも注意が必要です。通知やエスカレーション、リマインドといった「瞬間処理」には最適ですが、重い業務ロジックをフローに詰め込むのは危険です。失敗時のリトライや逆戻り手順を定義しないまま本番投入する――こうした事例は、2025年も後を絶ちませんでした。境界を明確にすること。業務の中核はDynamics 365側に寄せ、Power Automateは補助に徹すること。これが、運用を安定させる鍵です。

結論として、Power Platformは「民主化の手段」ではありません。業務設計力のある組織だけが、結果的に民主化を享受できるのです。2025年を通じて見えたのは、ガバナンスを軽視した自由は、必ず混乱を生むという現実でした。

第3章｜DXが進んだ企業に共通していた構造

2025年、DXが進んだ企業には派手な成功ストーリーはありませんでした。むしろ、静かで地味な取り組みが積み重なっていたのです。しかし、その構造をよく見ると、共通点は驚くほど明確でした。

まず一つ目は、業務が説明できることです。これは単なる「業務フローがある」という話ではありません。起点から終了条件までを一枚の図で示し、主要ステップと成果物が誰にでも理解できる状態になっていること。さらに、用語辞書が整備されていることも重要です。顧客、案件、注文、請求――こうした言葉の定義が部門間で一致している企業では、システムの導入やAIの活用がスムーズに進みました。加えて、判定ルールが明確であること。優先度や承認、SLAの判断基準が「誰が、いつ、どう判断するか」まで文書化されていると、業務のブレが減り、CopilotやPower Platformの提案も的確になります。

次に、KPIが絞られていることです。成功企業は、KPIを欲張りませんでした。売上、粗利、受注率、在庫回転、CSAT――多くても5つ程度に絞り込み、先行指標と遅行指標を明確にしました。そして、そのレビューをIT会議ではなく、定例業務の場で行う。これにより、DXは「ITの話」ではなく「業務の話」として定着していきました。

さらに、ロール構造の明確化も共通点です。Process Ownerは業務の型を守り、Product Ownerはシステムの機能価値を高め、Data Stewardはデータ品質を毎日監視する。この三者が役割を分担し、責任を持つことで、DXは個人依存から脱却しました。推進者が異動しても業務が回り続ける――これが、DX定着のサインです。

最後に、変更管理の仕組みです。成功企業は、CAB（Change Advisory Board）を設け、変更の目的、影響、逆戻り手順を事前にレビューしました。リリースは段階的に行い、「小さく出して、早く戻せる」体制を整えました。そして、変更の影響を測る指標――誤入力率、承認リードタイム、エスカレーション率――を事前に定義し、可観測性を確保しました。これにより、DXは「やってみて終わり」ではなく、「測って改善する」サイクルに乗ったのです。

結論として、DXが進んだ企業は、特別なツールや派手なプロジェクトで成功したわけではありません。業務を説明できること、KPIを絞ること、役割を明確にすること、変更を管理すること――こうした基本を徹底した企業だけが、DXを「一過性のイベント」ではなく「日常の品質改善」に変えることができました。

第4章｜うまくいかなかったDXの話

2025年、DXの失敗事例も数多く見えました。そして、その多くが「悪意」ではなく、むしろ善意から始まっていたことが印象的です。企業は本気でDXを進めようとしていました。しかし、距離感を誤ると、現場は静かに離れていきます。

よくあるパターンの一つは、専門部署の孤立です。DX部門を立ち上げ、最新技術を積極的に導入する――その姿勢自体は間違っていません。しかし、部門が「手段の最適化」に走りすぎると、肝心の「業務の最適化」が後回しになります。現場の課題を理解しないまま、ツールや機能を押し付けると、DXは「ITのプロジェクト」に見えてしまい、業務側の共感を失います。

二つ目は、成功事例の横展開神話です。ある部門でうまくいったPower PlatformのアプリやCopilotの活用事例を、そのまま他部門にコピーする――これもよくある失敗です。業務構造が違えば、成功の条件も違います。テンプレートを移植するだけでは、現場にフィットしません。むしろ「なぜうまくいったのか」を構造的に分析し、その要素を再設計する必要があります。

三つ目は、先に全社標準を決めるアプローチです。標準化は重要ですが、現場の例外を無視して「一律ルール」を押し付けると、標準は「使われない標準」になります。結果、現場は標準を避け、独自のやり方を続ける――DXは形だけ残り、実態は分断されたままです。

こうした失敗の背景には、期待値のズレがあります。導入完了と価値創出を同じものと見なしてしまうこと。導入完了とは、機能提供や教育、データ移行が終わった状態です。しかし、価値創出は別物です。KPIが改善し、手戻りが減り、顧客体験が向上する――ここまで到達して初めてDXは意味を持ちます。2025年、失敗したプロジェクトの多くは、この二つを混同していました。

では、どう回復するか。現場でよく使われたのが90日プランです。最初の14日間で診断を行います。用語辞書や判定ルール、業務E2E図を再構成し、データ品質（重複率、欠損率、更新遅延）を可視化します。次の30日間で是正。高頻度・高影響の領域――顧客、案件、在庫――から順に改善し、通知や承認のガードレールを標準化します。最後の45日間で定着。定例業務会議に「議題テンプレ」を導入し、CoEで「作ってよいもの／いけないもの」を明文化。さらに、変更の影響を指標で測る文化を根付かせます。

このプロセスを経ると、DXは「失敗からのリカバリー」ではなく、「改善のサイクル」に変わります。重要なのは、技術を変えることではありません。期待値を再設定し、現場との距離を縮めることです。DXの失敗は、機能不足ではなく、コミュニケーション不足から生まれる――2025年に見えた現実です。

第5章｜DXを回していたのは、どんな人だったのでしょうか

「DX人材」という言葉は、2025年も多くの場面で使われました。しかし、現場で見えた実像は、その言葉が示す華やかさとはほど遠いものでした。DXを回していたのは、特別な肩書きや派手なスキルを持つ人ではありません。むしろ、地味で、しかし確実に業務を動かす力を持った人たちでした。彼らに共通していたのは、3つの理解と1つの会話力です。まず、Dynamics 365の画面を理解していること。どの画面で、誰が、何を入力し、どのデータが更新されるのか――この基本を押さえている人は、現場の混乱を防ぎます。

次に、Power Platformの限界を知っていること。どこまでノーコードで対応でき、どこからコード化やデータ設計が必要になるのか。その境界を理解している人は、無理な構築を避け、運用を安定させます。そして、業務そのものを理解していること。成果物、責任、判定ルール、KPI――これらを把握している人は、システムを「業務の道具」として使いこなせます。

最後に、会話力です。他部署と合意形成できる言語化能力。これは、2025年のDXを動かす最大のスキルでした。たとえば、営業部門が「案件の優先度の決め方が人によって違う」と言い、カスタマーサービス部門が「エスカレーションの条件が部門ごとに微妙に違う」と指摘する場面。ここでDX担当者が「用語辞書と判定ルールを一枚にまとめて、週次で再確認しましょう。Copilotの採点軸にも反映します」と提案できるかどうか。この一言が、AIの定着率を左右します。
育成と評価の指標も、スキル単体ではなく、関係性と仕組み化への貢献に重きが置かれました。週次の運用ふりかえりで用語と判定ルールを再確認する習慣を作れるか。他者が継続できる仕組みを残せるか。KPI改善への寄与と、仕組み化への貢献――この二つが、2025年のDX人材を評価する軸でした。

結論として、DXを回していたのは「特別な人」ではありませんでした。Dynamics 365の画面を理解し、Power Platformの限界を知り、業務を説明でき、他部署と話ができる人。スキルよりも、関係性。そして、仕組みを残す力。2025年に見えたDX人材の実像は、地味ですが、確実に組織を動かす存在でした。

第6章｜2026年を室長はどう見るか

2026年、DXはさらに目立たなくなるでしょう。2025年は「運用の年」でしたが、2026年は「品質の年」になると考えています。AIエージェントはDynamics 365 CRM / ERPの限定された業務領域から入り、Copilotの差は個人ではなく組織単位で広がります。なぜなら、AIの出力品質は、データ品質と業務整理度に依存するからです。

DXはプロジェクトではなく、業務品質の話になります。誤入力率、承認リードタイム、重複データ、顧客満足――こうした現場指標を測定し、改善するサイクルがDXの本質になります。2026年のキーワードは「Agent × Process × Governance」です。AIエージェントは、整備されたプロセスでしか価値を出せません。プロセスは、成果物の型と判定ルールを事前に固定する必要があります。そして、ガバナンスは、変更の影響を計測可能にし、段階的に広げる仕組みを持つこと。

2026年の導入は「スモールスタート」が基本です。ケース返信案、作業報告の要約、見積の初稿――こうした狭い業務から始め、用語辞書、評価軸テンプレート、逆戻り手順を整えたうえで展開します。測定指標はアシスト率、編集量、反映リードタイム。週次レビューで拡張可否を判断し、スプリント単位で進める。DXは、派手な名前を付けられることもなく、静かに業務に溶け込んでいきます。それでいいのです。むしろ、それが成熟の証です。

第7章｜室長は、なぜDX365Lifeを書き続けるのか、そしてDXはどこへ向かうのか

ここで改めて問います。なぜDX365Lifeを書き続けるのか。その理由はシンプルです。Dynamics 365やPower Platformに関わる中で、同じ構造の失敗を何度も見てきたからです。技術は変わります。CopilotやAIエージェントが登場し、業務の自動化は進化を続けています。しかし、組織がつまずくポイントは驚くほど変わりません。用語が揃っていない、判定ルールが曖昧、責任の所在が不明――こうした基本が整っていない限り、どんな最新機能も「宝の持ち腐れ」になります。

だからこそ、記録し、言語化し、残すことに意味があります。何が起き、どこで詰まり、どう判断したのか。それを整理しておくだけで、次にDynamics 365やPower Platformを触る人の判断は少し楽になります。DX365Lifeは、そのための記録です。記事を書くときに心がけているのは、現場の声を主語にすること。システムではなく業務を主語に書くこと。事例から原則を抽出し、再現可能なテンプレートや指標を添えること。こうした積み重ねが、DXを「一過性のイベント」ではなく「日常の品質改善」に変えると信じています。

そして、DXはどこへ向かうのか。答えは「静かな成熟」です。DXは、語るものではなくなります。評価のために語るものでもありません。現場で起きている変化は、往々にして地味で、説明しづらいものです。だからこそ、記録しておく意味があります。成功の理由よりも、なぜ回り続けているのか。なぜ破綻しなかったのか。その構造を淡々と残していく。それが、次に同じ立場でDXを担う人の判断を少しだけ楽にするからです。

DXは、来年も続きます。特別なイベントではなく、日常の中で静かに進化していきます。それでいいのだと思います。

ここまで読んでくださいました皆さまに、室長が日々活用するチェックリストを共有させていただきます。

付録A｜DX運用チェックリスト（v2025）

DXを「導入」から「運用」へ移すために、最低限押さえておきたいポイントがあります。まず、用語辞書です。顧客、案件、注文、請求――こうした言葉の定義が部門間で一致しているかどうか。これが曖昧なままでは、どんなシステムも混乱を招きます。次に、判定ルール。優先度、承認、SLAの判断基準を文書化し、誰が、いつ、どう判断するかを明確にします。業務の流れも見える化が必要です。起点から成果物、終了条件までを示した業務E2E図を公開し、全員が同じ絵を見ている状態を作ります。そして、KPIは欲張らないこと。5つ以内に絞り、先行指標を必ず含める。レビューは週次で行い、CopilotやAIの提案が「採用されなかった理由」を棚卸します。改善すべきはAIではなく、業務の前提です。さらに、変更管理の仕組みも欠かせません。CAB（Change Advisory Board）で、変更の目的、影響、逆戻り手順を事前にレビューします。最後に、可観測性。誤入力率、承認リードタイム、重複データ――こうした指標をダッシュボード化し、運用の質を測り続けることが、DXを「続ける力」になります。

付録B｜Power Platformガバナンス・クイックガイド

Power Platformは「民主化の手段」ではありません。業務設計力のある組織だけが、結果的に民主化を享受できます。そのために必要なのが、ガバナンスの基本です。まず、環境戦略。開発、テスト、本番を分離し、Deployment Pipelinesで移送を標準化します。次に、ソリューション管理。Canvasアプリ、Model-drivenアプリ、Power Automateのフローをソリューション単位で管理し、命名規則を決めて発見性を高めます。DLPポリシーで禁止コネクタを定義し、データ流出を防ぐことも必須です。CoE（Center of Excellence）は、単なる「監視役」ではありません。四半期ごとの棚卸し、再利用可能コンポーネントのカタログ化、設計原則の教育――こうした活動を通じて、現場の自由と組織の秩序を両立させます。そして、忘れてはいけないのが「作ってはいけないもの」リスト。重複マスタや独自KPIを含むアプリは、DXを分断する最大の要因です。例外はCABで審査し、逆戻り手順を必ず定義する。これが、Power Platformを「混乱の温床」ではなく「業務改善の加速装置」に変える鍵です。

付録C｜Copilot導入プレイブック（8週間）

Copilotを現場に定着させるには、いきなり全社展開するのではなく、段階的な導入が不可欠です。ここでは、8週間で進めるプレイブックを紹介します。

Week 1–2：準備
最初の2週間は、基盤づくりに集中します。用語辞書を整備し、評価軸のテンプレートを作成し、タスク分解の標準を定義します。Copilotに効くのは、凝ったプロンプトではありません。業務の前提が整理されているかどうかです。言葉の意味が揃い、判断基準が明確になっていることが、AIを活かす第一歩です。

Week 3–4：試行
次の2週間は、狭い範囲で試します。ケース返信、会議要約、作業報告の要約――こうした「型がある業務」に限定して導入します。成功の条件はシンプルです。業務に型があること。曖昧な業務にAIを入れても、混乱が増えるだけです。

Week 5–6：測定
試行が終わったら、必ず測定します。アシスト率（採用回数÷呼び出し回数）、編集量、反映リードタイム――この3つを指標に、Copilotの定着度を評価します。そして、採用されなかった理由を棚卸しします。多くの場合、問題はAIではなく、業務の整理不足にあります。

Week 7–8：拡張
最後の2週間で、成果のある範囲だけ段階的に広げます。逆戻り手順を徹底し、失敗を「学び」に変える仕組みを作ります。Copilotは魔法ではありません。整備された業務に対してのみ、力を発揮します。この原則を忘れないことが、成功の鍵です。

皆さま、1年間本当にありがとうございました！

2026年が、皆さまにとって、最高のDX365Lifeになることを祈念して、本稿をもって、私から2025年度の最後のエールとさせていただきます！