ERP/CRM UIの終焉|役割変更

おはようございます。皆さま、いかがお過ごしでしょうか?
室長こと、吉島良平(Microsoft MVP for Business Applications | Microsoft Regional Director)です。
私は今日の夜からバンコク(タイ国の首都)に出張なので、荷物の準備をしながら、ワールドベースボールを見ながら、今日は書いています。
日本はベネズエラと準々決勝です。アクーニャ・JR選手にホームランを打たれたと思ったら、即大谷選手のホームランで追いつく。いやぁ、エキサイティングな好ゲームになりそうな気配です。
ベネズエラと聞くと、中学生の時に地理で学んだマラカイボ湖油田と、昔ジャイアンツに所属していたルイス・サンチェス投手を思い出してしまいます。はい、古い、その通り!年齢がばれてしまいますね(笑)

そうそう、Microsoft 365 E7が5月からリリースされるようですね。ほ、欲しい…. こうした発表を見ていると、改めて、「AI を使う時代」ではなく「AI が業務の中で動く時代」に、私たちは完全に入ったのだと感じます。
ERP/CRM UIの終焉(役割変更)―AI時代にMicrosoft Dynamics 365はどこへ向かうのか―
さて、前稿では、2026 Wave 1のアップデートについて、評価や解釈を極力挟まず、追加・変更された機能を一覧として網羅しました。まずは「何が入ったのか」を正確に揃えることが、次の議論の前提になると考えたからです。同時に、最近はAIに要約してもらって内容を把握される方も多いので、一次情報にできる限り、自分なりの視点を織り込んでお届けしました。
今日はその続きとして、AI時代における Microsoft Dynamics 365(CRM/ERP)全体の進化を、ユーザーとパートナーが“自分の言葉で説明できる形”に整理してみたいと思います。先に結論から書きます。それは、ERP/CRM UIの終焉(役割変更)です。Dynamics 365は今、「人が画面を操作する業務アプリケーション群」から、AIが文脈を理解し、業務を実行するためのプラットフォームへと、明確にフェーズを移し始めています。
「ERP/CRM UIの終焉(役割変更)」という言葉は、少し強く聞こえるかもしれません。ですが、これは UIが不要になる、あるいは画面が消えるという話ではありません。『UI が“業務の中心”である前提が崩れ始めている』という意味です。これまでのERP/CRMは、「人が画面を開き、入力し、判断し、次の操作を選ぶ」という流れを前提に設計されてきました。業務プロセスの起点も終点も、常にUIにありました。ところが今、Microsoftが各プロダクトで揃えてきているピースを見ると、その前提そのものが変わり始めていることが分かります。
MVPとして、そしてRegional Directorとして
ここで少し、書き手としての立ち位置を補足しておきます。前稿は、Microsoft MVPとしての視点で書いた記事でした。個々の機能や変更点を正確に捉え、「現場で何が変わるのか」「実装としてどう受け止めるべきか」を、技術者・ユーザーの目線で整理することを意識しています。
一方で、今回の記事は、Microsoft Regional Directorとして、もう一段引いた視点から書いています。単一プロダクトの進化ではなく、Microsoftが業務アプリケーション全体を、どの方向に再設計しようとしているのか。そしてその変化が、企業の業務設計やパートナーの役割に、どのような影響を与えるのか。「ERP/CRM UIの終焉(役割変更)」という言葉も、新機能の評価やトレンド論ではなく、業務システムの構造が変わり始めていることへの問題提起として、受け取っていただければと思います。
AIが誤った処理をしたとき、人間がそれを検知・修正する場としてUIは依然として重要で、むしろ「例外処理と監査の場としてUIがより高度化する」という方向性もあり得ます。エンドユーザーのITリテラシーや、規制産業(金融・医薬など)でのガバナンス要件を考えると、「会話だけで業務が回る世界」への移行は、業種によってかなり温度差があるので、「UIの終焉」というフレームはやや先走り気味かもしれません。
UIの外で業務が動き始めている
象徴的なのが、CopilotとAIエージェントの位置づけです。Copilotはもはや、「画面の横で提案してくれる便利機能」ではありません。業務の文脈を理解し、タスクを組み立て、実行まで担う存在として再定義されつつあります。「メールやTeamsの会話」「ドキュメントやファイル」「スケジュールや過去の業務履歴」こうした情報を横断的に理解したうえで、「次に何をすべきか」を判断し、必要な処理をシステム側に投げます。このとき、人は必ずしもERP/CRMの画面を開いていません。業務の起点はOutlookやTeamsにあり、判断はCopilotが行い、実行は ERP/CRM 側で完了しています。UI は、「例外処理」「結果の確認」「ガバナンス上の承認」といった場面で使われる存在へと、役割が変わり始めています。
UIが存在しない業務はどのように実現されるのか
ここまで「ERPやCRMにおいてUIは本質ではない」という話をしてきました。しかし、実際の業務がどのように変わるのかを具体的にイメージすることはまだ難しいかもしれません。
営業活動を例に考えてみます。従来のCRMでは、営業担当者はCRMの画面を開き、顧客を検索し、案件情報を入力し、見積を作成するといった操作を行います。必要に応じてERPにデータを連携させ、受注処理や売上処理を進めていきます。この一連の流れは、人間がUIを操作することを前提に設計されています。
しかしAIエージェントが業務を仲介する世界では、この流れは大きく変わります。営業担当者はCRMの画面を操作する代わりに、「この顧客の見積を作成してほしい」とAIに依頼します。AIエージェントはその意図を理解し、CRMから顧客情報を取得し、ERPから価格情報や商品情報を取得し、見積書を作成します。そして必要に応じてERPにトランザクションを登録します。
この場合、営業担当者はCRMやERPのUIを直接操作する必要はありません。人間は業務の意図を伝えるだけで、実際のシステム操作はAIエージェントが行います。
つまり業務の中心は「UI操作」ではなく「意図の伝達」に変わります。そしてERPやCRMは、人間が直接操作するシステムではなく、AIエージェントが利用する業務基盤として機能するようになります。
Agent Architectureという新しいシステム構造
この変化は単なるUIの変化ではありません。『人ではなくAIが業務の起点になる前提で再設計された構造』のことです。今後、企業システムのアーキテクチャそのものが変化していきます。
これまでの業務システムは、人間がアプリケーションのUIを操作することを前提に設計されてきました。ユーザーはERPやCRMの画面を開き、必要な情報を入力し、システムの機能を呼び出しながら業務を進めていきます。つまり人間がシステムの中心にいる構造です。
しかしAIエージェントが業務を仲介するようになると、この構造は大きく変わります。ユーザーは個別のアプリケーションを操作する代わりにAIエージェントに業務の意図を伝えます。AIエージェントはその意図を理解し、必要な情報を取得し、複数の業務システムをAPI経由で操作しながら業務を実行します。
このような構造では、ERPやCRMは単独のアプリケーションとして利用されるのではなく、AIエージェントが利用するサービスの一部になります。AIエージェントがCRMから顧客情報を取得し、ERPから価格や在庫情報を取得し、必要な処理を組み合わせながら業務を実行するのです。
つまり従来の「人間→UI→アプリケーション」という構造は、「人間→AIエージェント→API→業務システム」という構造へと変わっていきます。このような構造は近年「Agent Architecture」と呼ばれることもあります。
Microsoft 365 E7
ここで、冒頭で触れた Microsoft 365 E7の話に戻ります。
E7は、CopilotやAIエージェントを「試すための機能」ではなく、業務の実行主体として組織に組み込むことを前提にしたスイート製品です。人と同じようにIDを持ち、アクセス権限を管理され、セキュリティや監査の対象になるAIエージェントを、“便利なツール”ではなく“デジタルな業務担当者”として扱う設計になっています。つまり Microsoft は、「人がUIを操作して業務を回す世界」から、「人とAIが役割分担しながら業務を進める世界」へ、業務基盤そのものを移行させようとしているわけです。
ERP/CRMに求められる役割の変化
この変化の中で、ERP/CRMに求められる役割も変わります。重要になるのは、「正確なデータ構造」「一貫した業務ルール」「明確なガバナンス」「安全に呼び出せるAPI」です。
つまり、「使いやすい画面」よりも「AIが迷わず実行できる業務モデル」が重要になってきたわけです。
Dynamics 365 Business Central 2026 Wave 1(Update 28.0)では、「Copilot/エージェント前提の機能拡張」「Model Context Protocol(MCP)による標準化された接続」「開発・テスト・運用の見直し」といった変化が、一気に揃いました。これは、「人が操作するERP」から「AIに実行される業務基盤」への転換を、実装レベルで示し始めたということです。
では、「実装レベル」とは具体的に何を指しているのか、少し補足しておきたいと思います。
v28.0でMicrosoftが優先したのは、AIをさらに賢くすることではありませんでした。Payables Agentが処理したメールをメールボックス上で識別できるようにする、全エージェントのタスクを一か所で横断的に見られる専用ペインを設ける、AIが生成したコンテンツを業務画面上でそのまま確認・修正できるようにする、そして何か問題が起きたときにエージェントのタスクを一括で止められるようにする。追加されたのは、こういった機能群です。
見ていただくと分かる通り、どれも新しい自動化を増やすものではありません。AIが何をしたのかを人が把握し、必要なら介入できる構造を整えることに、このアップデートは集中しています。
さらに、MCPのトラブルシューティング機能がAL開発環境に組み込まれた点も見逃せません。AIエージェントがAPIを通じて業務を実行する世界では、「どこまでAIに任せるか」の境界を構造として定義できなければ成立しない。その境界を整備するためのMCPが、PoC段階を超えて運用・保守の対象になったことを意味しています。加えて、Copilot拡張で自社のAIリソースを利用できる道も開かれました。MicrosoftはCopilotをMicrosoft管理のAIに囲い込まず、企業ごとのAI戦略をERPに組み込む入口を、実装として提供しはじめたわけです。
自動化の範囲を広げる前に、可視化・統制・介入・拡張の土台を先に固める。前稿で整理したv28.0の機能群をひとつひとつ見ていくと、Microsoftが選んだのはその順序だったことがよく分かります。50年以上UIを中心に設計されてきたERPが、AIを前提とした業務基盤へと転換するには、この順序が必然だったのだと思います。
Business Centralは、Dynamics 365が向かおうとしている未来を、最も早く、最も具体的な形で体現しているプロダクトだと感じています。コンパクトに全方向をカバーする製品だからこそ、そのイメージが掴みやすいのです。
この変化は、システムの設計思想だけの話ではありません。ERPが「触るもの」から「AIが実行するための業務基盤」になるということは、その基盤を設計する人間の役割も、必然的に変わるということです。UIをどう作るかではなく、AIが迷わず動けるような業務モデルをどう定義するか。その問いに答えられる人材こそが、次の時代のパートナーに求められる価値の中心になります。
v28.0/2026 Wave 1から見た大きな潮流|時代に見合う働き方の実現のために
これは、新機能が増えた、便利になったという話ではありません。ERPの使い方そのものが変わり始めている、という話です。
これまでは、基本的に次のように使われてきました。
「メニューを開く」「画面を表示する」「項目に入力する」「処理を実行する」
つまり、
「メニュー」→「 画面」→「 入力」→「 処理」
という流れです。業務の起点も、操作も、判断も、すべてUIを中心に設計されたシステムでした。ERP= 業務画面と言っても、ほとんど違和感がなかったと思います。
ところが、Copilotが業務の中に入ってくると、この前提が変わります。Copilot前提の業務は、次のような流れになります。
「ユーザー」→「 Copilot」→「ERPデータ」→「処理」
つまり、会話が業務の起点になる ERPです。人は、最初からERPの画面を開きません。
例えば、営業担当が Copilotにこう聞くとします。「今月の売上、どう?」
Copilotは、「売上分析」「粗利分析」「未回収債権」といった情報をMicrosoft Dynamics 365 Business Centralから取得し、要点をまとめて回答します。さらに続けて、「回収が遅れている顧客は?」と聞けば、「Customer Aが45日遅延しています」と返ってくる。そして最後に、「フォローのメールを送って」と言うと、「メール文面を生成」「Outlook経由で送信」ここまで、ERPのUIを一切開かずに完結します。
この流れを見ると、ERPの役割が変わっていることが分かります。これまで→「ERP = 業務画面」、現在→「ERP = API + データ」、これから→「ERP = AI が参照・実行する業務基盤」
つまり、人が操作するためのシステムから、AIが使うためのシステムへ。ERPは「触るもの」ではなく、AIが業務を理解し、実行するための知識ベースになりつつあります。
この変化は、Business Central単体の話ではありません。Microsoftは今、明確に次の構造を作っています。すべてが、一本の業務導線でつながっています。
「Business Central(正確な業務データ)」→「Microsoft Fabric(横断的なデータ群)」→「Copilot(文脈を理解して業務を組み立てる)」→「ユーザー(会話で業務を進める)」
なぜ、これは ERP業界にとって大きなインパクトなのか?
理由はシンプルです。ERPは、50年以上にわたって UI中心だったからです。その前提が、AI中心へと切り替わろうとしている。これは、画面設計の話でも、機能追加の話でもなく、業務システムの構造そのものの転換なのです。
ERPは「System of Record」として残る
このような変化が起きると、「ERPは不要になるのではないか」と考える人もいるかもしれません。しかし実際には逆で、ERPの役割はむしろより重要になります。
AIエージェントが業務を実行するためには、信頼できる業務データが必要です。顧客情報、商品情報、価格情報、在庫情報、会計情報など、企業活動の基盤となるデータはどこかに正確に管理されていなければなりません。
その役割を担うのがERPです。
ERPはこれまで「人間が操作する業務システム」として認識されることが多かったですが、AI時代においては「企業の正しいデータを保持する基盤」としての役割がより明確になります。こうした役割は一般的に「System of Record」と呼ばれます。
人間はUIを操作する代わりにAIエージェントに業務の意図を伝え、AIエージェントがERPやCRMなどのシステムを横断的に利用して処理を実行します。その際、ERPは企業活動の中核データを保持する信頼できる基盤として機能します。
つまりERPのUIは変化するかもしれませんが、ERPそのものが消えるわけではありません。むしろAI時代において、ERPは企業データの中心としてこれまで以上に重要な存在になっていくと考えられます。
UIレスERPの具体的なイメージ
では、「UIが業務の中心ではなくなる」とは、実際にどういう世界なのでしょうか。
これまでのERPやCRMは、ユーザーが必ず画面を開くことを前提に設計されていました。営業なら案件画面を開いて更新し、経理なら請求書入力画面に金額を打ち込む。人間がUIを操作することが、業務の大前提でした。
CopilotやAIエージェントが業務の中に入ってくると、その前提が変わります。営業担当がCRMを開かなくても、「この顧客の見積を作って」と一言伝えるだけで、AIが顧客情報を取得し、価格条件を参照し、見積書まで生成する。経理でも、メールやPDFで届いた請求書をAIが読み取り、ERPに自動登録し、人間は例外と承認だけを確認する。そういう世界です。
業務の入り口が「画面操作」から「AIとの対話・自動処理」へ移行したとき、ERPのUIは脇役になります。人が画面を開くのは、例外処理、確認、監査、分析—そうした場面だけになっていくでしょう。
これからのERPアーキテクチャ
この変化は、ERPのアーキテクチャそのものにも影響します。
従来の構造はシンプルでした。「ユーザー→ ERP画面→業務ロジック→データベース」、人が起点で、UIが窓口でした。
AIエージェントが業務の入り口になる世界では、これが変わります。「ユーザー→ AIエージェント→API →ERPロジック→データ」。UIを介さず、エージェントがAPIを通じて業務ロジックとデータに直接アクセスする構造です。
このとき重要になるのは、使いやすい画面ではありません。正確なデータモデル、整合性のとれた業務プロセス、そして安全に呼び出せるAPI。ERPは「操作するアプリケーション」から、「企業データと業務ロジックを提供するプラットフォーム」へと、役割を変えていきます。
「ERPのUIが終わる」というより、「UIを中心としたERP時代が終わり、データとエージェント中心の時代が始まる」と言った方が正確かもしれません。そして、その転換を実装レベルで可能にするピースが、次に触れるMCPです。
MCP が「必然のピース」になる
ここまで見てきた流れの中で、次に避けて通れないのが Model Context Protocol(MCP)の話です。MCPは、新しいAPI仕様や連携方式として語られることが多いのですが、実際に起きている変化は、もう少し本質的です。
MCPがもたらしているのは、「AI がどこまで業務を実行してよいのか」という境界を、システム側で定義できるようになったという点にあります。これまでのERP連携は、人が画面で判断し、その結果をシステムに入力することを前提に作られてきました。自動化はあっても、最終的な判断と実行の責任は常に人にありました。
一方、MCPを前提にすると、AIエージェントが業務の文脈を理解したうえで、どのデータにアクセスし、どの操作を実行できるのかを、業務モデルとして明示できます。これは単なる技術進化ではなく、ERPとAIの責任分界点が初めて構造として整理されたことを意味します。だからこそMCPは、「あると便利な技術」ではなく、会話中心のERPを成立させるための必然のピースなのです。
少し具体的に考えてみましょう。
「顧客情報の参照はAIに許可する」「発注処理は人間の承認を必須とする」
こうした業務上の境界を、MCPはシステムの構造として定義できます。AIが勝手に発注してしまうリスクを、運用ルールではなくアーキテクチャとして制御できる。これが、ERPをAIに安全に開放するための、実装レベルでの答えです。
ビジネスパートナー/開発ベンダーへの影響
この変化は、ビジネスパートナー/開発ベンダーの価値にも、確実に影響します。これまで評価されてきたのは、使いやすいUIを作ること、画面操作を前提に業務フローを整えることでした。どこをクリックすれば次に進めるのか、どの項目を入力すればよいのかを分かりやすく設計することが、価値の中心にありました。しかし、会話を起点にAIが業務を実行する世界では、その前提が変わります。重要になるのは、業務ルールをどう定義するか、データにどんな意味を持たせるか、どこまでをAIに任せ、どこを人が担うのか、そしてその境界をどうガバナンスとして表現するかです。
ここで起きているのは、「作る/作らない」という話ではありません。価値の重心が、UIの実装から業務の設計へと移動している、という変化です。この書き方をしているのは、「これまでのやり方はもう通用しない」と言いたいからではありません。むしろ、これまで積み上げてきた知識や経験が、より上位の設計レイヤーで活きるようになった、という話だと捉えています。
Directions Asia 2026 | 5月13日‐5月15日|ベトナムホーチミン開催
ここまでの話は、リリースノートを読んだり、ドキュメントを追ったりするだけでは、なかなか腹落ちしません。実装している人、同じ課題を持つパートナー、そしてMicrosoftのプロダクトチームが、同じ前提・同じ言葉で議論する場が必要になります。

アジアオセアニア領域にお住いの方にとっては、その場所が、Directions Asia(マイクロソフトのパートナー向けイベント)となります。Business Central 2026 wave1|V28.0を軸にしながら、CopilotとERP/CRM/Power Platformの関係、MCPがもたらす設計の変化、そしてパートナーの役割がどう変わるのかを、体感することができます。Directions Asiaは、単なる情報収集の場ではなく、これからの仕事のやり方を言語化するための場です。
終項|まとめ
今回書いてきた内容は、「何かを結論づける」ためのものというより、これからどう考え、どう向き合うかを整理するための視点だと思っています。
業務ユーザーは「覚えるUI」から解放される。
ITは「画面設計」ではなく「業務設計」で評価される。
パートナーは「作る人」から「任せ方を設計する人」になる。
ERP/CRMのUIがどうなるのか、AIが業務の中でどんな役割を担うのか。その答えは一つではありませんし、きっとこれからも変わり続けるはずです。だからこそ、同じ関心を持つ人たちと、同じ前提で、同じ言葉を使って話すことが大切になります。
もしDirections Asiaに参加されるなら、現地でそんな話題について、ゆるく意見交換できたら嬉しいですね。
最後までお読みいただきありがとうございました。
UIが消えるのではない。“人がUIに合わせて働く時代”が終わるだけだ。
以上、室長でした。
