Dynamics 365 Customer Serviceの2026年4月更新でまず押さえるべき点は、単なる概要ページの更新に見えて、実際にはCustomer Serviceの運用軸が「ケース管理中心」から「Copilot Service workspace、統合ルーティング、Copilot agentsを含むサービス運用基盤」へ整理されていることです。特にIT管理者やプロダクトオーナーは、新機能の細かな有無だけでなく、今後どのアプリを標準にし、どの管理センターで設定を集約し、どこまでAI活用を前提に設計するかを見直すタイミングと捉えるべきです。
Microsoft Learnの「Welcome to Dynamics 365 Customer Service」は、2026年4月21日に更新されています。公式ページでは、ケース管理、ナレッジベース、統合ルーティング、チャネル横断の会話管理、AIによる分析、Teams連携、SLA、エンタイトルメント、レポート、サービススケジューリングなどがCustomer Serviceの主要用途として整理されています。(Microsoft Learn)
Dynamics 365の最新動向: Welcome to Dynamics 365 Customer Serviceで何が変わったか
今回の更新は、製品の大型リリースノートというより、Dynamics 365 Customer Serviceの全体像を現在のMicrosoftの方向性に合わせて再整理した更新と見るのが実務的です。
GitHub上のMicrosoftDocs履歴では、2026年4月21日に該当ドキュメントへ2件の編集があり、ms.dateが2026年4月21日に更新されています。本文上は「Copilot agent overview」が「Copilot agents in Customer Service」に変更され、Copilot agentsの説明がより具体化されています。さらに、Service Agentへのリンク修正も行われています。(GitHub)
つまり、今回の更新ポイントは「Customer Serviceに何ができるか」の再掲だけではありません。管理者視点では、次の3点が重要です。
| 更新ポイント | 実務上の意味 | 確認すべき担当者 |
|---|---|---|
| Copilot agentsの説明が具体化 | Customer ServiceがMicrosoft 365 Copilotと連携するAI支援基盤として位置付けられている | IT管理者、AI活用推進担当、CS部門責任者 |
| Copilot Service workspaceが中心アプリとして明確化 | マルチセッション、会話、チャネル対応を使う現場では優先的に検討すべき | プロダクトオーナー、業務設計担当 |
| Copilot Service admin centerによる管理集約 | ルーティング、チャネル、エージェント体験、サービス条件などの設定場所を整理する必要がある | Dynamics管理者、Power Platform管理者 |
2026年4月更新の要点は「Customer Serviceの入口」がAI前提に整理されたこと
Dynamics 365 Customer Serviceは、従来からケース管理、問い合わせ履歴、ナレッジ管理、SLA管理などを担うCRM領域の中核サービスです。今回の公式ページでは、これらの基本機能に加えて、統合ルーティング、音声を含むチャネル横断の会話管理、AIによるインサイト、Microsoft Teams連携が同じ文脈で並んでいます。(Microsoft Learn)
これは、問い合わせ管理を「チケットを登録して処理する仕組み」としてだけ見ている企業にとって重要な変化です。今後の設計では、次のような観点が欠かせません。
- ケースをどのチャネルから受け付けるか
- メール、チャット、音声、SNSなどの会話をどこで一元管理するか
- 担当者への割り当てを手動にするか、統合ルーティングで自動化するか
- ナレッジを人が検索するだけでなく、Copilotが参照できる形に整備するか
- 問い合わせ対応の品質を、SLAやダッシュボードでどう可視化するか
特にグローバル拠点を持つ企業では、チャネル、言語、タイムゾーン、担当チームが分散しやすくなります。そのため、Customer Serviceを単なる部門アプリではなく、サポート業務の共通プラットフォームとして設計することが重要です。
Copilot Service admin centerが管理の起点になる
公式ページでは、Customer Serviceの管理に「Copilot Service admin center」が示されています。ここでは、Customer Serviceの各種機能をライセンスモジュールに応じて構成・管理でき、カスタマーサポート、オペレーション、エージェント体験に関する機能を一元的に扱えると説明されています。(Microsoft Learn)
別の公式ドキュメントでは、Copilot Service admin centerはケース、キュー、ナレッジ記事、チャネル、統合ルーティング、エージェント体験プロファイルなどを設定する管理アプリとして説明されています。また、チャネル設定のガイド、管理設定の検索、タスク指向のサイトマップ、機能別の概要ページなどが用意されています。(Microsoft Learn)
管理者が最初に確認すべきことは、機能一覧を読むことではなく、自社の運用設定がどこに集約されているかです。古い管理画面や個別アプリに設定が散らばっていると、ルーティング、権限、チャネル、ナレッジ、SLAの変更時に影響範囲を見誤りやすくなります。
管理者が見直すべき設定領域
| 領域 | 確認内容 | 放置した場合のリスク |
|---|---|---|
| ユーザーとロール | エージェント、管理者、スーパーバイザーの権限が適切か | Copilotやチャネル設定にアクセスできない、または過剰権限になる |
| キューとルーティング | ケースや会話が正しい担当者に配分されるか | 対応遅延、重複対応、属人化が起きる |
| チャネル | チャット、音声、メッセージングの設定が現行運用と一致するか | 顧客接点が分断され、履歴が追えない |
| ナレッジ | 記事の公開状態、検索対象、更新責任者が明確か | Copilotや担当者が古い情報を参照する |
| SLA・エンタイトルメント | 優先度、契約条件、対応期限が業務ルールと一致するか | レポート上の達成率と実態がずれる |
| エージェント体験 | 画面、セッション、テンプレート、マクロが現場に合っているか | 高機能でも使われないシステムになる |
Copilot Service workspaceを標準アプリ候補として見るべき理由
今回の公式ページの比較表では、エージェント向けアプリとして、Copilot Service workspace、Omnichannel for Customer Service、Customer Service Hub、Customer Service Team Memberが並べられています。その中で、Copilot Service workspaceはマルチセッション、ケース管理、会話、チャネル、音声チャネル、ナレッジ管理、分析、サービススケジューリング、IoT連携、拡張性、Unified Interface対応を幅広くカバーしています。(Microsoft Learn)
実務上は、次のように判断すると分かりやすいです。
| 利用シーン | 向いているアプリ | 判断基準 |
|---|---|---|
| 複数の問い合わせや会話を同時に処理する | Copilot Service workspace | マルチセッション、チャネル対応、会話管理が必要 |
| 基本的なケース管理とナレッジ管理が中心 | Customer Service Hub | チャットや音声を扱わない、既存運用を継続したい |
| 限定的な参照・更新のみ | Customer Service Team Member | フル機能のエージェントではなく、軽い業務参加が中心 |
| 旧Omnichannelアプリを利用中 | Copilot Service workspaceへの移行検討 | Omnichannel for Customer Serviceアプリは非推奨扱い |
Copilot Service workspaceは、ブラウザーのタブのような操作感で、担当者が複数のケースや会話を1つのワークスペース内で扱えるアプリです。公式ドキュメントでは、1つのアプリ内で複数セッションを処理でき、Smart Assist、スクリプト、マクロなどの生産性機能も利用できると説明されています。(Microsoft Learn)
既存環境で特に注意すべき移行ポイント
すでにCustomer Service HubやOmnichannel for Customer Serviceを利用している場合、単に「新しいアプリを開けるようにする」だけでは不十分です。画面、ビュー、フォーム、ダッシュボード、業務プロセスフロー、サイトマップ、JavaScriptカスタマイズの挙動まで確認する必要があります。
Microsoftの非推奨情報では、Omnichannel for Customer Serviceのエージェント向けアプリは2023年4月に非推奨となり、2024年6月までサポートされたと説明されています。また、Customer Service Hubについても、Enterpriseライセンスの新規組織では2025年2月から利用できない旨が記載されています。既存組織ではサポート継続の記載がありますが、新規導入や刷新ではCopilot Service workspaceを前提に検討するのが自然です。(Microsoft Learn)
Copilot agentsとService Agentの位置付け
2026年4月更新で特に注目したいのが、Copilot agentsに関する記述です。公式ページでは、Dynamics 365 Customer ServiceのCopilotには、Microsoft 365 CopilotをCustomer Service固有の機能で拡張するAI-powered agentsが含まれると説明されています。これらのエージェントは、ケース、顧客レコード、やり取りなどの組織データを使い、担当者がワークフローを離れずに情報検索、要約、アクション実行を行えるよう支援します。(Microsoft Learn)
Service Agentの公式ドキュメントでは、Service AgentはMicrosoft 365 Copilot agentとして、Dynamics 365 Customer Serviceや接続されたナレッジソースのデータを利用し、ケースのレビュー、ナレッジ取得、ケース操作などを支援すると説明されています。なお、このドキュメントではプレビュー機能であり、変更される可能性があることも明記されています。(Microsoft Learn)
ここで重要なのは、Copilot agentsを「便利なチャット機能」として導入しないことです。実務では、次の準備が成果を左右します。
- ケース分類や優先度のルールが整理されている
- 顧客レコードとケース履歴が正しく関連付いている
- ナレッジ記事の内容が最新で、責任者が決まっている
- SharePointなど外部ナレッジの公開範囲が適切に管理されている
- Copilotが実行できる操作と、人の承認が必要な操作を分けている
例えば「この顧客の未解決ケースを要約して」「このケースに関連するナレッジを探して」「優先度を更新して」といった使い方は、データが整っていれば現場の時短につながります。一方で、ナレッジが古い、ケースのステータスが運用上あいまい、権限設計が粗い環境では、AIを入れても確認作業が増えるだけになりがちです。
統合ルーティングとチャネル管理は優先度を上げて確認する
公式ページでは、Customer Serviceの用途として「unified routingを使って作業項目を効率的にルーティングする」「音声を含むチャネル横断の会話を管理する」ことが挙げられています。(Microsoft Learn)
これは、サポート組織の設計に直結します。たとえば、次のような現場では統合ルーティングの見直し効果が大きくなります。
- メール、チャット、電話の受付チームが分かれている
- 優先顧客や契約プランごとに対応SLAが異なる
- 多言語対応で担当者スキルによる割り当てが必要
- 問い合わせ量が増える時間帯に手動配分が追い付かない
- ベテラン担当者に難しい案件が集中している
統合ルーティングを使う場合は、単に「自動割り当てを有効化する」だけではなく、キュー、スキル、キャパシティ、優先度、営業時間、SLA、エスカレーション条件をセットで設計する必要があります。
ルーティング設計で失敗しやすいポイント
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
| スキル定義が細かすぎる | 対応可能な担当者が少なくなり、キューが詰まる | 最初は大分類で始め、実績データを見て調整する |
| 優先度の基準が曖昧 | ほぼ全件が高優先度になり、SLA管理が崩れる | 契約、影響範囲、緊急度で判定基準を明文化する |
| チャネルごとに運用が別々 | 顧客履歴が分断され、対応品質がばらつく | ケースと会話履歴の紐付けルールを統一する |
| 例外対応を考慮しない | 休暇、障害、繁忙期に割り当てが破綻する | キャパシティ、営業時間、バックアップ担当を設定する |
| 分析指標を後回しにする | 改善すべきボトルネックが見えない | 初期段階からキュー滞留、再割当、SLA違反を確認する |
ナレッジベースはCopilot活用の前提データになる
Dynamics 365 Customer Serviceでは、ナレッジベースで情報を共有できることが基本機能として示されています。(Microsoft Learn)
従来のナレッジ管理では、「担当者が検索して読む」ことが主な利用方法でした。しかしCopilot agentsやService Agentを使う前提では、ナレッジはAIが参照する業務データになります。つまり、記事の品質がそのまま回答品質や提案品質に影響します。
ナレッジ整備で優先すべきなのは、記事数を増やすことではありません。まずは、問い合わせ件数が多いテーマ、SLA違反が起きやすいテーマ、新人が迷いやすいテーマから整備するのが現実的です。
ナレッジ記事の実務チェックリスト
- タイトルだけで問題領域が分かる
- 対象製品、対象プラン、対象バージョンが明記されている
- 解決手順が番号付きで書かれている
- エスカレーション条件が明確
- 最終更新日と責任者が分かる
- 顧客向け説明と社内向け補足が混在していない
- 古い回避策が残っていない
特にグローバル展開では、英語記事を各国語に翻訳するだけでは不十分です。地域ごとの契約条件、サポート時間、法務・セキュリティ表現が異なる場合は、ナレッジの公開範囲と承認フローも設計する必要があります。
IT管理者とプロダクトオーナーが次に取るべき行動
今回の更新を受けて、IT管理者やプロダクトオーナーは、公式ページを読むだけでなく、自社環境に落とし込んで確認することが重要です。以下の順に進めると、影響範囲を整理しやすくなります。
| 順番 | 作業 | ゴール |
|---|---|---|
| 1 | 利用中アプリを棚卸しする | Customer Service Hub、Omnichannel、Copilot Service workspaceのどれを使っているか把握する |
| 2 | 管理画面を確認する | Copilot Service admin centerに設定を集約できているか確認する |
| 3 | チャネルとルーティングを見直す | 問い合わせの入口、キュー、担当者割当の設計を整理する |
| 4 | Copilot利用前提のデータ品質を確認する | ケース、顧客情報、ナレッジ、権限を点検する |
| 5 | 移行・改善ロードマップを作る | 既存アプリ継続、段階移行、AI活用の優先順位を決める |
特に、既存のカスタマイズが多い環境では、Copilot Service workspaceへの移行を「画面変更」と軽く見ない方が安全です。フォーム、ビュー、ダッシュボード、JavaScript、業務プロセス、セキュリティロール、レポートの依存関係を洗い出してから進める必要があります。
今回の更新をどう捉えるべきか
2026年4月21日更新の「Welcome to Dynamics 365 Customer Service」は、表面的には概要ページの更新です。しかし、内容を追うと、MicrosoftがCustomer ServiceをCopilot Service workspace、Copilot Service admin center、Copilot agentsを中心にしたサービス運用基盤として整理していることが分かります。
すでにDynamics 365 Customer Serviceを使っている企業は、まず利用中アプリと管理設定を棚卸ししてください。新規導入や刷新を検討している企業は、最初からCopilot Service workspaceを中心に、チャネル管理、統合ルーティング、ナレッジ、SLA、Copilot活用を一体で設計するのが現実的です。
次に取るべき行動は明確です。自社のサポート業務を「ケース処理」だけでなく、「顧客接点、担当者体験、AI活用、運用品質の改善」まで含めた業務基盤として見直しましょう。今回の更新は、その見直しを始めるための良いチェックポイントです。
コメント