第4回フィールドサービス編|Dynamics 365+Copilot|Where we are ? ― Copilotが変える「仕事の時間」と「顧客への向き合い方」

こんばんは。室長こと、吉島良平(Microsoft MVP for Business Applications | Microsoft Regional Director)です。

一昨年度のことです。夏のある日、自宅のエアコンが突然止まりました。

修理を依頼すると「本日の午後2時から6時の間に伺います」という返答。

午後2時から待ち続けて、技術者が来たのは5時45分でした。

状況を確認してもらうと「これは特定の部品が必要です。今日は持ち合わせていないので、来週また来ます。」

そして翌週、また同じ「午後2時から6時」の窓を空けることになりました。

技術者は親切でした。

でも、どこかに情報が欠落していた。事前に何の部品が必要かが分かっていれば、1回の訪問で解決できたかもしれない。

到着時間の見通しがあれば、半日待たずに済んだかもしれない。

私が半日待っていたその時間、ディスパッチャー側では何が起きていたのでしょうか。

スケジュール調整、部品確認、顧客への連絡、技術者との調整—顧客には見えない作業が、現場の裏側で動いていたはずです。

ということで、第4回のテーマは、Dynamics 365 Field Service のCopilotとAgentです。


キャンセルが1件出た瞬間、ディスパッチャーの画面は「手動最適化」の戦場になる

「今日の午後2件目、顧客の急な都合でキャンセルになりました」—そのメッセージが届いた瞬間から、ディスパッチャーの作業が始まります。

キャンセルされた予約のクローズと状態管理
空いた時間枠に収まる案件の検索(スキル・エリア・優先度を確認)
前後の予約との移動時間・順序を再計算
関係する技術者への変更通知
顧客への再スケジュールまたはキャンセル連絡
場合によっては、他の技術者への再割り当てと引き継ぎ

これは1件のキャンセルで発生する作業です。

フィールドサービスでは、1日の中でこうした変化が何度も起きます。

天候、交通、突発故障、顧客都合—どれも事前には読めない。

それでも、サービスを届け続けなければならない。

Dynamics 365 Field ServiceのCopilotとAgentは、この「必要だが繰り返し発生する作業」を変えることに集中しています。

今回は、その全体像をお伝えします。

このシリーズ「Dynamics 365 + Copilot|Where we are?」は、各ロールごとにCopilot・Agentの現在地を整理する全12回のシリーズです。3層の全体像は第0回(プロローグ)にまとめています。

📅 本記事の情報は 2026年8月20日時点 のものです。GA・PRP・Previewの状態、および各機能の利用条件は変更される可能性があります。最新状況はMicrosoft Learnおよび公式リリースノートでご確認ください。


📖 本稿でいう「Copilot」「Agent」「製品」の整理
Copilot
主に人が業務を進める際のAI支援を提供する機能です。自然言語での質問、ワークオーダーサマリー、現場での音声・テキスト入力、点検テンプレートの自動生成など、ディスパッチャー・テクニシャン・管理者の「検索・入力・記録」を支援します。
AI Agent
特定の目的・データ・ルール・ツールを与えることで、分析・提案・実行までを担えるAIの実行主体です。Field ServiceではScheduling Operations Agentが代表例です。通常は人によるレビューと承認を前提とした運用が可能ですが、バッチ最適化では自動適用を含む運用オプションも提供されます。なお、定期実行・自動スケジューリングを行う「Automate optimizations」機能は2026年9月以降のPreviewおよび2027年3月のGAが計画されており、2026年8月時点では提供前です。組織のガバナンス方針に応じた設定が必要です。

⚠️ Agentだからすべて自律実行するわけではありません。管理者設定、承認フロー、権限制御によって実行できる処理は異なります。

📌 本稿ではDynamics 365 Field ServiceにおけるMicrosoft標準のCopilot機能とAI Agentを扱います。Microsoft 365 Copilot単体の一般機能や、Copilot Studioで個別構築するカスタムAgentは対象外です(第三章でカスタムAgentの例は紹介します)。

📌 Field Serviceの主要ロールと今回の対象範囲
ディスパッチャー / サービスマネージャー

ワークオーダーの受付・管理、技術者のスケジューリング、進捗確認、顧客対応の調整を担います。CopilotのサイドペインとワークオーダーサマリーがWebアプリで支援し、Scheduling Operations Agentがスケジュール最適化を担います。

フィールドテクニシャン(現場技術者)

顧客先で実際に作業を行う現場担当者です。モバイルアプリでワークオーダーを確認し、作業内容を記録します。CopilotのAIワークオーダー更新(音声・テキスト入力)がこの層の記録業務を支援します。

点検テンプレート作成はService Administrator / Manager向けの機能です。Microsoft 365 Copilot連携はM365ライセンスを持つすべての業務ユーザーが対象となります。


Field Serviceの業務フローで見る—CopilotとAgentはどこに入るか

フィールドサービスの業務は、問い合わせ受付からワークオーダー作成、スケジュール計画、現場作業、記録・報告、品質評価まで一本の流れでつながっています。

CopilotとAgentをこの流れに当てはめると、「何が担当者支援」で「何が業務プロセス支援」なのかが見えやすくなります。

ワークオーダーライフサイクルとAI支援
① 問い合わせ受付・ワークオーダー作成
顧客からの問い合わせや資産状態のアラートからワークオーダーが生成されます。Copilotサイドペインを使えば、既存の顧客・資産情報を自然言語で照会しながら、ワークオーダーの内容を素早く整理できます。
↓
② スケジュール計画・リソース割り当て
適切な技術者を選び、スケジュールを組む工程です。Scheduling Operations Agentが技術者のスキル・場所・優先度・移動時間を考慮して、最適なスケジュール案を提案します。承認後に反映されます。
↓
③ 現場到着前の準備
技術者が訪問前にワークオーダーサマリーを確認することで、資産の過去履歴・作業内容・必要部品を短時間で把握できます。「現場に行ってから初めて状況を知る」というロスを減らします。
↓
④ 現場作業・記録
技術者がモバイルアプリで作業内容を記録します。AIワークオーダー更新(Preview)により、「センサー交換完了、部品3個使用」と話しかけるだけでフィールドが自動入力され、確認後に反映されます。点検はCopilotが生成したデジタルテンプレートを使って実施できます。
↓
⑤ 報告・クローズ・インサイト
作業完了後のクローズと報告です。ワークオーダーサマリーにはコスト・価格・請求の概要が含まれます。Microsoft 365 Copilot連携により、TeamsやOutlookからField Serviceのデータを自然言語で照会できます。
CopilotとAgentは「業務フロー全体」に分散して価値を出す。一点集中型の導入より、フロー全体で見て設計することが重要。

この流れで見ると、Copilotは主に「担当者が今行っている作業を速くする」役割を持ち、Scheduling Operations Agentは「スケジュールの最適化という意思決定そのもの」を支援します。

⚠️ 利用可否はライセンス、環境、管理者設定、提供リージョンによって異なります。各カードの「前提」は主な確認項目であり、導入時には最新のMicrosoft Learnおよびライセンス条件をご確認ください。


前半:ディスパッチャーと管理者のための標準Copilot機能

Dynamics 365 Field Serviceには、Webアプリ・モバイルアプリそれぞれにCopilot機能が搭載されています。

ディスパッチャーや管理者は主にWebアプリ側を使い、フィールドテクニシャンはモバイルアプリ側を使います。

機能ごとに利用するインターフェースが異なる点に注意してください。

Webアプリ全体で使えるCopilot—自然言語でField Serviceデータを照会する

💬 Copilot サイドペイン(自然言語Q&A)
GA

Field Service Webアプリのヘッダーにあるアイコンから開くサイドペインです。ワークオーダー・サービスアカウントの情報、最近の変更点、現場訪問の準備内容などを自然言語で質問できます。定義済みプロンプトライブラリも用意されており、「この顧客のワークオーダー一覧」「このワークオーダーに誰が予約されているか」「このワークオーダーで使った部品は何か」といった照会が可能です。

こんな場面で: ディスパッチャーが複数のワークオーダーを横断して情報を確認したいとき。サービスマネージャーが顧客のサービス履歴を素早く把握したいとき。

前提: 追加のCopilotライセンスは不要。ただし管理者によるCopilot有効化と対象環境が必要 / Field Serviceアプリと対象Dataverseデータへのアクセス権限を持つセキュリティロールが必要(標準ロールはField Service – Dispatcher / Field Service – Resource。カスタムロールを利用する場合はCopilotおよびデータへの権限を個別確認すること) / テナントと環境が別リージョンの場合はリージョン間データ移動の許可が必要

ワークオーダーの状態を30秒で把握する

📋 ワークオーダーサマリー(Work Order Summary)
GA

ワークオーダーフォームまたは予約レコードから「Generate」ボタンを押すと、Copilotがそのワークオーダーの概要を生成します。生成内容はワークオーダーのライフサイクルステージによって変わります。未スケジュール時は「スケジュールに必要な情報」、スケジュール済みは「現場準備に必要な資産情報・過去作業履歴」、進行中は「現在の作業状況」、完了・投稿済みは「コスト・価格・請求の概要」が含まれます。サマリーのコンテンツは保存されず、生成したユーザーのみが参照できます。

こんな場面で: 朝のスタート時に引き継いだワークオーダーの状況を素早く把握したいとき。サービスマネージャーが顧客への報告前に内容を確認したいとき。

⚠️ 注意:Work Order Summaryは作業指示の確認を完全に置き換えるものではありません。利用者が参照できるデータの範囲と入力データの品質に生成結果が依存します。オンライン利用が前提であり、オフライン環境では利用できません。英語以外の言語(日本語を含む)では生成品質を検証したうえで利用することを推奨します。

前提: 管理者がField Service設定 > Features でワークオーダーサマリー機能を有効化する必要がある / 有料Field Service環境が必要(現時点ではTrial環境では利用できない、または利用制限があります)

現場で話しかけるだけで、ワークオーダー更新案を作成する(モバイル)

🎤 AIワークオーダー更新(AI-powered Work Order Update)
Preview

Field Service Mobileアプリ(新UX)の機能です。テクニシャンが作業内容をテキストまたは音声で説明すると、CopilotがワークオーダーのフィールドへのAI推奨更新を提案し、確認後に反映されます。例えば「温度センサーを交換しました。部品を3個使用、作業時間は90分です」と話しかけると、予約ステータス・製品数量・サービス時間などが自動で入力候補として表示されます。更新できるフィールドは予約ステータス・予約時間・作業タスク完了・製品数量・製品ラインステータス・サービス時間・サービスラインステータスです。

こんな場面で: 現場テクニシャンが作業完了後に両手が使えない状態で記録をしたいとき。紙やメモ経由でのデータ転記をなくしたいとき。

前提: Preview機能(本番環境での利用は推奨されない)/ 有料Field Serviceライセンス環境が必要(現時点ではTrial環境では利用できない、または利用制限があります)/ Field Service Mobileの新UXが有効であること / 管理者がField Service Mobile設定 > Features で「Work order update」を有効化する必要がある

紙・PDFの点検チェックリストをデジタルテンプレートに変換する

📄 点検テンプレート作成(Create Inspections with Copilot)
Preview

サービス組織が長年使ってきた紙の点検票・PDF・チェックリストをField Serviceに取り込む機能です。管理者が「Create with Copilot」から画像またはPDFをアップロード(最大3枚・PDFは最大3ページ)すると、Copilotが内容を解析して点検テンプレートの下書きを生成します。管理者が内容を確認・調整して公開すると、テクニシャンがモバイルアプリのワークオーダー上で点検を実施できるようになります。

こんな場面で: 年単位で使い続けてきた紙の点検票をデジタル化したいとき。新しいサービスメニューに合わせた点検テンプレートを素早く作りたいとき。

前提: Preview機能 / Dynamics 365 Field Service バージョン 8.8.142.320以降が必要 / 管理者がField Service設定 > Features > Copilot in Field Service で「Create inspection templates」を有効化 / 2026年8月時点ではUKおよびItalyのリージョンでは利用不可

TeamsやOutlookからField Serviceデータを照会する

🔗 Microsoft 365 Copilot連携(Dataverse探索)
GA

Microsoft 365 Copilot(TeamsやOutlookなど)から、権限のあるField Service関連データを自然言語で参照できるようになる機能です。2026 Release Wave 1で提供が開始され、2026年3月にPublic Preview、2026年5月にGAとなっています。「先週クローズされた未完了ワークオーダーの一覧を教えて」「この顧客の最後の訪問はいつか」といった問い合わせをM365 Copilotに投げると、ユーザーの権限範囲内でField Serviceの関連データから回答が得られます。管理者・ディスパッチャーがField Serviceアプリを開かずに状況確認できる体験を提供します。

こんな場面で: 会議中にTeamsからその場でワークオーダーの状況を確認したいとき。マネージャーが朝のレビューをOutlookのCopilotサイドバーから行いたいとき。

前提: Dynamics 365 EnterpriseまたはPremiumライセンスを前提に、利用するMicrosoft 365 Copilot機能の範囲を確認すること。Dataverseデータへのグラウンディングと、Work IQを含むM365 Copilotのフル機能では必要条件が異なるため、対象シナリオごとに最新のDynamics 365 Licensing Guideを参照のこと / 管理者による連携設定が必要 / 利用可能なデータ範囲はユーザーのField Serviceセキュリティロールに準拠

ここまでを一言でまとめると

Field ServiceのCopilot機能は、「Webアプリでの情報照会・サマリー」「モバイルでの記録入力」「管理者向けテンプレート生成」「M365からのデータ照会」と、使う場面・インターフェースがそれぞれ異なります。「すべてのCopilotが同じ条件で使える」と考えると設計がズレます。機能ごとにインターフェース・ライセンス・管理者設定を個別に確認してください。


後半:Field Service の標準 AI Agent

現時点でDynamics 365 Field ServiceのMicrosoft標準AI Agentとして位置づけられているのが、Scheduling Operations Agent(スケジューリング最適化エージェント)です。

冒頭で説明したような「1件のキャンセルで発生するスケジュール再調整」を、Agentが自動で最適化案として提示します。

ただし、2026年8月時点でPreview段階です。正式リリース(GA)は2027年3月を予定しています。

🤖 Scheduling Operations Agent(スケジューリング最適化エージェント)
Preview

ディスパッチャーは1日の大半をスケジュールボード上で手動調整に費やしています。技術者が増えるほど複雑になる「誰に・何を・いつ・どの順番で」という意思決定を、Agentが支援します。

インタラクティブ最適化(リアルタイム対応)

ディスパッチャーがスケジュールボードから1名以上の技術者を選択し、Agentに最適化を依頼します。Agentは提案されたスケジュールをレビュー画面に表示し、ディスパッチャーが内容を確認・承認してから実際の予約に反映されます。キャンセルが発生した技術者のスケジュール補填、遅延による後続予約の再調整、複数技術者の負荷均衡などに活用できます。

バッチ最適化(大規模・非同期処理)

「スコープ(対象技術者・要件の定義)」「ゴール(最大化する目標:高優先度の作業をこなす / 移動時間を最小化 など)」「プラン(実行スケジュール)」の3つを設定することで、より大規模な最適化を非同期で実行できます。結果は適用前にレビューすることも、自動適用することも設定できます。
⚠️ 2026年8月時点の注意: 定期実行・自動スケジューリングを行う「Automate optimizations」(複数リソースを対象とした自律的な最適化の定期実行)は、2026年9月以降のPublic Preview・2027年3月のGA計画であり、現時点では提供前です。「バッチ最適化=自動で定期実行される」と読まないようご注意ください。

ガバナンス設計の重要性: Agentは「Do Not Move」マークが付いた予約を動かしません。技術者の就業時間・休憩も考慮します。インタラクティブ最適化では人がレビューして承認してから変更が反映されます。バッチ最適化では自動適用を含む運用オプションも提供されるため、組織のガバナンス方針に応じた設定が必要です。

前提: Preview機能(GA予定:2027年3月)/ Azure GovernmentおよびChinaリージョンを除くAzureリージョンで利用可能 / 対象リージョンへの段階的ロールアウト中 / 管理者によるAgent設定(スコープ・ゴール・プランの構成)が必要

👁️ Agent Feed(エージェント監視フィード)
Preview

Agent Feedは、Field ServiceアプリのサイドマップTOPに表示される「Agentが生成したタスク」の監視インターフェースです。Power Apps MCPサーバーを使って構築・接続されたAgentの活動を、「対応が必要(Needs Attention)」と「完了(Completed)」の2セクションに分けて表示します。ユーザーはAgentのタスクをレビュー・承認・却下・完了操作することができます。Insightsパネルでは7/14/30日間のAgentとユーザーの協働状況を集計して可視化できます。

活用のポイント: カスタムAgentはCopilot StudioやPower Platformを使って構築できます。AgentをPower Apps MCPサーバーに接続し、Agent Taskおよびhuman-in-the-loopの設計を行うことで、Agent FeedへのAgentアクティビティ表示と承認・却下操作が可能になります。ただしAgent Feed自体はPreviewであり、対象Agentの構成・リージョン・言語(現時点では英語のみ)・Power Apps MCPサーバーとの接続条件を事前に確認したうえで利用してください。

前提: Preview機能 / 現時点では英語のみ対応 / Power Apps MCPサーバーに接続されたAgentのみがAgent Feedに表示される / 2026年5月1日以降、旧型のActivity-basedフィードは非対応

ここまでを一言でまとめると

Field ServiceのAI Agentは現時点では「スケジュール最適化」に特化したScheduling Operations Agent(Preview)が中心です。Scheduling Operations Agentは、通常は人によるレビューと承認を前提とした運用が可能です。ただしバッチ最適化では自動適用を含む運用オプションも提供されるため、組織のガバナンス方針に応じた設定が求められます—これがField ServiceにおけるAI Agentの現在地です。

1つのAgentを「ライセンス」ではなく「利用条件」で見る

1つのAgentを「ライセンス」ではなく「利用条件」で見る
Agent名 製品上の位置付け ライセンス以外に確認するポイント
Scheduling Operations Agent
(スケジューリング最適化エージェント)
Dynamics 365 Field Service 標準のAI Agent(Preview)。スケジュールボードに統合されており、インタラクティブ最適化とバッチ最適化の2モードを持つ。従来のRSO(Resource Scheduling Optimization)Add-inとは異なるアーキテクチャで動作するが、同じ「スケジュール最適化」領域に関係するため、既存RSO利用企業は現在のRSO構成・最適化目標・対象リソースとの比較を行い、移行・併用方針を検討することを推奨する。 ① 対象リージョンへの段階的ロールアウト中のため、利用可能タイミングをField Service Version historyで確認すること
② スコープ・ゴール・プランの管理者設定が必要
③ インタラクティブ最適化と バッチ最適化でそれぞれ有効化手順が異なる
④ 「Do Not Move」ルール等の制約設定の理解と運用設計が必要

ライセンスと管理者設定の現実

Field Serviceでは、「Copilotを使うために別のAIライセンスが必要か」という問いへの答えは、機能によって異なります。

Field Service本体のライセンスで利用できるCopilot機能がある一方で、スケジュール最適化・Microsoft 365 Copilot統合・カスタムAgentは、それぞれ別の利用条件・ライセンス・容量を確認する必要があります。

「ライセンスを持っている」だけでは、CopilotもAgentも動きません。

Field Serviceにおける利用条件を、次の5つのレイヤーで整理します。

Field Service Copilot・Agent 利用条件の5つのレイヤー

Layer 1 Field Serviceの基本ライセンス
Field Serviceを利用するユーザーには、ロールに応じたライセンスが必要です。Dispatcher・Frontline Worker・Resource Administrator など、実際の業務ロールと必要な権限を確認します。「Field Serviceを導入している組織にいる」ことと、「すべてのユーザーが同じ機能を利用できる」こととは異なります。

Layer 2 Field Service標準Copilot
Copilotサイドペイン・ワークオーダーサマリー・AIワークオーダー更新・点検テンプレート作成などのField Service標準Copilot機能は、Microsoft LearnではField Serviceライセンスに含まれ追加ライセンス不要とされています。ただし、管理者設定・セキュリティロール・環境バージョン・リージョンの確認は別途必要です。Microsoft 365 Copilot連携(Teams・Outlookからの照会)は、M365 Copilotライセンスが別途必要です。

Layer 3 Agent実行基盤
Field ServiceのAgent利用は、機能の種類によって実行基盤が異なります。Scheduling Operations AgentはCopilot Studioのメッセージを消費する従量課金型の仕組みで動作します。1回の最適化リクエストで消費するメッセージ数は、対象リソース数に比例します。プリペイド容量(Copilot Studio message pack)またはPay-as-you-goモデルで管理します。Copilot Studioで構築したカスタムAgentをAgent Feedに接続して使う場合も同様にCopilot Studio容量が必要です。Resource Scheduling Optimization(RSO)Add-inはScheduling Operations Agentとは別の仕組みであり、最適化リソース数に応じた別途ライセンスが必要です。

Layer 4 システム構成
Field ServiceのCopilot・Agent機能を有効にするには、Power Platform管理センターでのAI機能有効化・DLPポリシー確認・クロスリージョンデータ移動の許可が必要です。Sales編のようなEntra IDアプリ登録やServer-to-Server(SSS)認証設定は、Field Service標準機能では必要ありません。機能ごとに有効化手順が異なります(ワークオーダーサマリーはField Service設定、モバイル更新はMobile設定、点検テンプレートはFS Features > Copilotから有効化)。

Layer 5 提供条件
GA機能は安定稼働していますが、Preview機能は本番利用推奨外です。Scheduling Operations AgentはGA予定2027年3月・段階的ロールアウト中。点検テンプレート作成はUK・Italyリージョンでは2026年8月時点で利用不可。AIワークオーダー更新は現時点で英語以外の言語制限あり。Agent Feedは英語のみ対応。提供リージョンとロールアウト状況はField Service Version historyで確認してください。

📌 Sales編との違い:Field Service固有の注意点

Field ServiceではSales編のようなEntra IDアプリ登録やSSS認証は標準機能には不要です。一方、Scheduling Operations AgentはCopilot Studioのメッセージ(消費ベース課金)を使用します。1回の最適化でリソース数に比例したメッセージを消費するため、最適化スコープ・頻度・リソース数に応じたキャパシティ設計が必要です。プリペイド容量またはPay-as-you-goモデルを導入前に確認してください。

「Field ServiceにCopilotが入った」と言われたとき、実際に何が使えるのかは環境・設定・ロールによって変わります

Field ServiceのCopilot機能は、「ライセンスを持っていれば自動で使える」ものと「管理者が機能ごとに個別で有効化しなければ使えない」ものに分かれます。またPreview機能は本番利用推奨外であり、機能・提供リージョン・動作が変わる可能性があります。導入前に必ず機能ごとの前提条件を確認してください。

提供状態(GA / Preview)の整理

機能別・提供状態テーブル(2026年8月20日時点)
機能 提供状態 主な利用インターフェース 管理者設定
Copilot サイドペイン(自然言語Q&A) GA Webアプリ デフォルト有効(Power Platform管理センターでの確認推奨)
ワークオーダーサマリー GA Webアプリ 管理者による個別有効化が必要
AIワークオーダー更新(モバイル) Preview モバイルアプリ(新UX) Mobile設定 > Features で有効化
点検テンプレート作成 Preview Webアプリ(設定エリア) FS Settings > Features > Copilot で有効化
M365 Copilot連携(Dataverse探索) GA 2026年5月〜 Microsoft 365 Copilot M365ライセンス必要・管理者設定必要
Scheduling Operations Agent Preview GA予定:2027年3月 スケジュールボード・Webアプリ 管理者がScope・Goal・Plan設定必要
Agent Feed(エージェント監視) Preview Webアプリ(サイトマップ) Power Apps MCPサーバー接続が必要

導入前の4つの確認事項

導入前の4つの確認事項

【Copilot前提設定】Power Platform管理センターの確認

Field ServiceのCopilot機能は、Power Platform管理センターでAI/Copilot機能が有効になっていることが前提です。管理者が無効化している環境ではCopilotアイコンが表示されません。またDLPポリシーや環境設定によってCopilot関連機能が制限されていないかも確認が必要です。

【環境・バージョン要件】有料ライセンス環境とバージョン確認

ワークオーダーサマリーとAIワークオーダー更新は、現時点ではTrial環境では利用できない、または利用制限があります。有料のField Serviceライセンス環境が必要です。点検テンプレート作成はバージョン8.8.142.320以降が必要です。環境のバージョンを事前に確認してください。

【リージョン・データ移動】クロスリージョン設定の確認

テナントと環境が異なるAzureリージョンに存在する場合、Copilot機能を使うためにリージョン間データ移動(Cross-region data movement)の許可設定が必要です。Scheduling Operations AgentはAzure GovernmentおよびChinaリージョンでは利用不可です。また点検テンプレート作成は2026年8月時点ではUKおよびItalyでは利用不可です。

【機能別管理者設定】機能ごとの個別有効化が必要

Field ServiceのCopilot機能は「Field Serviceを導入すれば全部自動で使える」ではありません。ワークオーダーサマリーはField Service設定から有効化、AIワークオーダー更新はMobile設定から有効化、点検テンプレート作成はSettings > Features > Copilot in Field Serviceから有効化する必要があります。Scheduling Operations AgentはScope・Goal・Planの構成が別途必要です。機能ごとに担当管理者との連携を計画してください。

導入前に確認しておきたいチェックリスト

□ Power Platform管理センターでCopilot機能が有効になっていることを確認したか
□ DLPポリシーや環境設定によってCopilot関連機能が制限されていないか
□ テナントと環境が別リージョンの場合、リージョン間データ移動を許可済みか
□ 利用予定の機能が自組織のField Serviceバージョン・環境タイプで対応しているか
□ Field ServiceアプリとCopilotへのアクセス権限が、適切なセキュリティロールで付与されているか(カスタムロールの場合は権限の個別確認が必要)
□ ワークオーダーサマリーを管理者がField Service設定で有効化したか
□ モバイルアプリのAIワークオーダー更新を管理者がMobile設定で有効化したか
□ 点検テンプレート作成を管理者がCopilot in Field Service設定で有効化したか
□ Scheduling Operations Agentのスコープ・ゴール・プランを設計・設定したか
□ Preview機能の本番環境利用について、組織内リスク確認と合意を得ているか

※本章のライセンス・提供状態・機能名は2026年8月20日時点のMicrosoft Learnおよびリリースプランに基づきます。GAおよびPreviewの状況は今後変更される可能性があります。最新情報はMicrosoft Learn – Dynamics 365 Field Serviceでご確認ください。

ここまでを一言でまとめると

Field ServiceのCopilot・Agent導入でよくある誤解は「ライセンスがあれば全部使える」という前提です。実際には、機能ごとに管理者設定が必要なものが多く、バージョン要件・リージョン制限・Trial環境での制約も存在します。「使えるかどうか」を機能単位・環境単位で確認することが、現実的な導入計画の第一歩です。

Dynamics 365 Field Service の3層マッピング

① 標準Copilot

① Field Service標準Copilot機能(基本ライセンス利用可の機能とM365 Copilot等の追加条件がある機能が混在)

• Copilot サイドペイン GA
• ワークオーダーサマリー GA
• AIワークオーダー更新 Preview
• 点検テンプレート作成 Preview
• M365 Copilot連携 GA

② 標準Agent

Field Service 標準搭載(管理者設定・段階的ロールアウト)

• Scheduling Operations Agent Preview
インタラクティブ最適化
バッチ最適化
(GA予定:2027年3月)

③ カスタムAgent

Power Platform / Copilot Studio で自社実装

例)部品・在庫管理Agent
資産の部品消費を追跡し、
在庫が閾値を下回ると
自動で発注候補を起票
例)予防保全提案Agent
IoTデータから資産劣化を検知し
予防保全WOを自動生成
例)顧客到着通知Agent
技術者の位置情報をもとに
顧客に到着予定を自動通知

③カスタムAgentは Copilot Studio + Power Platform で構築できます。Power Apps MCPサーバーへの接続とAgent Task設計を行うことで、Agent Feedでの監視・承認が可能になる場合があります(Agent FeedはPreview・英語のみ・接続条件の事前確認が必要)。

まとめ

Dynamics 365 Field ServiceにおけるCopilotとAgentの現在地を整理しました。

Copilot側では、Webアプリでの自然言語照会とワークオーダーサマリーがGAとして安定稼働しており、モバイルでの音声・テキスト入力によるワークオーダー更新と点検テンプレート作成がPreviewとして提供されています。

Agent側では、スケジューリングの自動最適化を担うScheduling Operations AgentがPreviewとして提供開始されており、2027年3月のGAに向けて機能拡充が進んでいます。

大切なのは、Field ServiceのCopilotとAgentがどのような運用設計で動くかを、組織ごとに明確にすることです。

Copilotは基本的に人の作業を支援するものですが、Scheduling Operations Agentのバッチ最適化では自動適用オプションも存在します。

「AIがどこまで実行し、人がどこで判断するか」をガバナンス設計として意識することが、Field Service AI導入の重要な前提です。

「現場で何かが起きるたびに、ディスパッチャーが手動で画面を動かす」という状況は、今後のScheduling Operations AgentのGA・機能拡充によって変わっていきます。

今は「現在地を知ること」と「Previewで小さく試すこと」が、最初の一歩です。

💬 一つ聞いてもいいですか?

あなたのチームのディスパッチャーは、1日に何件の予約を手動でスケジュール変更していますか? さらに、技術者数・スキル条件・移動距離・顧客との約束時間・既存予約—ディスパッチャーが同時に考慮しなければならない条件は何項目ありますか? Scheduling Operations Agentの価値は、単純な変更件数だけでなく、人が同時に判断しなければならないスケジューリングの複雑さが高いほど大きくなります。

フィールドサービスの仕事は、現場で起きることをコントロールできない大変さがあります。

天候、渋滞、突発故障、顧客の急なキャンセル—どれも事前には読めない。

それでも、技術者を動かし、顧客のもとにサービスを届け続けることが求められる。

ディスパッチャーは毎日その不確実性と向き合いながら、スケジュールボードを動かしています。

Copilotが変えられるのは、その不確実性に対応するための「情報処理と記録」の時間です。

Agentが変えられるのは、「スケジュールを動かす」という繰り返しの意思決定の一部です。

現場で本当に必要な判断は、これからも人が担います。

でも、その判断に使える時間が増えたとき、サービスの質は変わるはずです。

フィールドサービスの皆さん、Let’s Enjoy our DX365LIFE!

ところで、Field ServiceのワークオーダーコストをそのままFinanceで原価管理・請求・収益認識まで処理したい場合、実はDynamics 365 Project Operations が間に入る構造になります。

Field ServiceとFinanceは直接ではなく、Project Operationsという「プロジェクト会計層」を通じてつながる—この構造が、次回の話の土台になります。

次回は第5回 Project Operations 編です。プロジェクトを動かす人たちのために。

dx365jp
  • dx365jp
  • 25年ほど、Microsoft Dynamics 365 【ERP(NAV/AX)+CRM】の導入コンサルティングに従事し、日本を含む34か国において導入コンサルティングを経験してきました。グローバル環境における“プロジェクト”と“マーケティング”を生業としております。

    最近は、【CRM/MKTG(攻めのDX)⇔ ERP(守りのDX)】+【ローコード】というDX365な活動に奮闘中です。Microsoft Dynamics 365 ビジネスで地球を92周中です。#DX365 #DynamicsIoT

    Microsoftの運営する外部技術者グローバル組織「Microsoft MVP(*日本163名/世界3674名)・ Microsoftのトラスティッドアドバイザーである「Microsoft Regional Director (*日本4名/世界167名)」として、複数のITコミュニティーにて活動中。(*2026/08/08時点)

    プロフィールはこちら→bit.ly/Dynamics365JP