Dynamics 365 Field Serviceのスケジュール最適化を担当している管理者は、2026年7月1日に更新された「Scheduling Operations Agent overview (preview)」を確認しておくべきです。結論から言うと、この更新は強制移行や即時の本番切り替えを求めるものではありません。プレビュー段階のScheduling Operations Agentを使い、ディスパッチャーが技術者の予定を対話的またはバッチで最適化できるようにするための概要、前提条件、制限、設定ポイントが整理されています。
特に重要なのは、プレビュー機能であること、利用前に管理者設定が必要なこと、Copilot Studioメッセージ容量やロール設計に影響すること、リージョンごとに展開時期が異なることです。既存のField Service運用にすぐ置き換えるのではなく、まずは検証環境または限定チームで、予約ステータス、優先度、作業時間、テリトリ、スキル情報の整合性を確認するのが現実的です。
Scheduling Operations Agentとは何か
Scheduling Operations Agentは、Dynamics 365 Field Serviceで技術者のスケジュールを最適化するためのエージェント機能です。ディスパッチャーがスケジュールボード上で手作業により調整していた作業を支援し、既存予約、未対応の要件、技術者の稼働時間、休憩、スキル、テリトリなどを踏まえて、より適切な予定案を提示します。Microsoft Learnの該当ページは2026年7月1日に更新されており、記事自体も「prerelease documentation」、つまり正式リリース前の変更可能なドキュメントとして扱われています。(Microsoft Learn)
想定されている利用シーンは、単なる自動割り当てではありません。たとえば、当日キャンセルで空いた時間に近隣の作業を入れる、技術者の作業遅延による後続予約のずれを調整する、低優先度の予約より新しく発生した高優先度作業を前倒しする、病欠から復帰した技術者の予定を再構成する、複数技術者の負荷をならしつつ移動時間を減らす、といった現場寄りの調整に使います。(Microsoft Learn)
重要なのは、Scheduling Operations Agentが「人の判断を完全に置き換える機能」ではない点です。エージェントは候補となるスケジュールを生成しますが、提案内容を確認して適用する流れが基本です。また、Do Not Moveに設定された予約は移動せず、技術者の勤務時間と休憩も尊重します。(Microsoft Learn)
2026年7月1日更新で押さえるべきポイント
今回の公式情報で管理者が最初に確認すべきポイントは、次の4つです。
| 確認項目 | 管理者が見るべき理由 | 実務上の判断 |
|---|---|---|
| プレビュー機能であること | Microsoftはプレビュー機能を本番利用向けではなく、機能制限がある可能性があるものとして説明している | 本番全面展開ではなく、限定ユーザーで検証する |
| 最適化方式 | 対話型最適化とバッチ最適化で用途が異なる | 当日調整は対話型、広範囲の再配置はバッチを検討する |
| 料金・容量 | Copilot Studioメッセージ容量を消費する | 利用部門、対象リソース数、実行頻度を見積もる |
| データ品質 | 予約ステータス、優先度、スキル、テリトリなどが結果に影響する | 先にマスターデータと予約ルールを整理する |
Microsoftは、プレビュー機能について「正式リリース前に早期アクセスとフィードバックを得るためのもの」と説明しており、本番運用にそのまま組み込む前に検証が必要です。Scheduling Operations Agentを有効化すると、対話型最適化とバッチ最適化の両方が利用対象になります。(Microsoft Learn)
影響範囲：誰に関係する変更か
Scheduling Operations Agentの影響を受けるのは、Field Serviceの画面を使うディスパッチャーだけではありません。実際には、管理者、業務責任者、ライセンス・課金管理者、データ管理者まで関係します。
| 対象者 | 主な影響 | 確認すべきこと |
|---|---|---|
| Field Service管理者 | 機能有効化、ロール、チーム権限、予約ステータス設定が必要 | 環境バージョン、権限、対象テーブル、カスタムテーブルのアクセス権 |
| ディスパッチャー | スケジュール提案を確認し、適用または破棄する運用に変わる | どの予約を動かしてよいか、どの条件を優先するか |
| 業務部門責任者 | 優先度や移動時間、稼働率のバランスを決める必要がある | 高優先度作業をどこまで優先するか |
| ライセンス・課金管理者 | Copilot Studioメッセージ容量を消費する | プリペイド容量または従量課金のどちらを使うか |
| グローバルIT部門 | リージョン、言語、タイムゾーンの差分を考慮する | 展開対象国、利用言語、スケジュールボードのタイムゾーン |
特にグローバル展開では、地域ごとの利用可否とロールアウト時期を分けて考える必要があります。Scheduling Operations AgentはDynamics 365 Field Serviceと同じAzureリージョンで利用可能とされていますが、Azure Governmentと中国は対象外とされています。一方でUniversal Resource Scheduling自体のバージョン展開はリージョンごとに段階的に行われ、2026年7月時点のリリーススケジュールでは日本、アジア太平洋、英国、シンガポールなどがStation 3に含まれています。(Microsoft Learn)
このため、「Universal Resource Schedulingの更新が来ていること」と「Scheduling Operations Agentがその環境で利用可能であること」は同じ意味ではありません。実際の環境で機能トグル、リージョン、バージョン、ライセンス条件を確認してください。
対話型最適化とバッチ最適化の違い
Scheduling Operations Agentには、大きく分けて「interactive optimizations」と「batch optimizations」の2種類があります。どちらもスケジュール最適化ですが、使うタイミングと運用設計が異なります。
| 種類 | 向いている場面 | 主な操作 | 注意点 |
|---|---|---|---|
| 対話型最適化 | 当日中のキャンセル、遅延、少人数の予定調整 | Copilotサイドペイン、スケジュールボード、リソース一覧から実行 | プレビュー時点では最大5人の技術者を対象にした即時調整向け |
| バッチ最適化 | 多数のリソース、予約、要件をまとめて再配置したい場合 | scope、goal、planを作成して非同期実行 | 自動適用にする前にReview before applyで検証する |
対話型最適化は、最大5人の技術者の予定をその場で調整する用途に向いています。Copilotサイドペインで「Suggest a schedule」のようなプロンプトを入力したり、スケジュールボード上でリソースを選択して実行したりできます。提案内容は、適用前にリスト、Gantt、地図などで確認できます。(Microsoft Learn)
一方、バッチ最適化は、より広い範囲を非同期で最適化するための仕組みです。管理者またはディスパッチャーは、最適化対象を定義するscope、最適化の考え方を定義するgoal、実行条件をまとめるplanを設定します。planでは、結果を確認してから適用するか、自動適用するかを選べます。(Microsoft Learn)
実務では、いきなり自動適用を使うより、まずは「Review before apply」で結果を確認する運用から始めるべきです。Microsoftも、目標や重み付けの調整は反復的なプロセスであり、狭いscopeから始めて徐々に広げることを推奨しています。(Microsoft Learn)
管理者が行う主な設定変更
Scheduling Operations Agentを使うには、単に画面上の機能をオンにするだけでは不十分です。前提バージョン、場所と地図の設定、課金モデル、セキュリティロール、予約ステータス、優先度などを確認する必要があります。
前提条件を確認する
公式ドキュメントでは、環境がField Service version 8.8.133.214以降、Universal Resource Scheduling version 3.12.149.15以降であること、Location and map settingsが有効であること、Dynamics 365 Field Serviceアプリの管理者ロールを持っていることが前提条件として示されています。(Microsoft Learn)
管理者は、まず次の順に確認すると無駄がありません。
| 順番 | 確認内容 | 見落とすと起きやすい問題 |
|---|---|---|
| 1 | Field ServiceとUniversal Resource Schedulingのバージョン | 機能が表示されない、動作が公式手順と異なる |
| 2 | Location and map settings | 移動時間やルート最適化の精度に影響する |
| 3 | 管理者ロール | 機能トグルや設定画面にアクセスできない |
| 4 | 対象リージョン | グローバル環境で一部拠点だけ使えない可能性がある |
| 5 | Copilot Studioメッセージ容量 | 最適化実行時に容量不足でAI機能が使えない |
課金モデルと容量を設計する
Scheduling Operations Agentを含むDynamics 365のCopilotおよびエージェント機能は、Microsoft Copilot Studioメッセージを消費します。公式ドキュメントでは、Scheduling Operations Agentの1回の最適化要求が、含まれるリソース数に応じてメッセージを消費すると説明されています。(Microsoft Learn)
課金モデルには、事前購入したCopilot Studio message packを使うプリペイド容量と、実際の利用量に応じて課金されるpay-as-you-goがあります。両方のモデルを同じ環境で使うこともでき、その場合はプリペイド容量が先に消費されます。(Microsoft Learn)
管理者は、少なくとも以下を決めてから展開すると安全です。
- どの国・拠点・チームで使うか
- 1日に何回程度、最適化を実行するか
- 1回の実行で何人の技術者を対象にするか
- 対話型最適化とバッチ最適化のどちらを中心に使うか
- 容量不足時に誰が通知を受け、誰が追加購入または再割り当てを判断するか
容量が不足するとAI機能が利用できなくなるため、検証段階でも使用量の監視は必須です。(Microsoft Learn)
機能を有効化する
機能の有効化は、Field ServiceアプリのResourcesエリアから行います。公式手順では、Resourcesエリアで「Scheduling Parameters」から「Resource Scheduling」に移動し、「Agents」タブで「Scheduling Operations Agent (Preview)」をオンにします。(Microsoft Learn)
この設定をオンにすると、対話型最適化とバッチ最適化の両方が有効になります。したがって、機能をオンにする前に、誰が使えるか、どの予約を動かしてよいか、どの優先度ルールを採用するかを先に決めておく必要があります。
セキュリティロールを割り当てる
Scheduling Operations Agentには、利用者向けに2つのセキュリティロールが用意されています。これらは既存ロールを置き換えるものではなく、Field Service – Dispatcherなど、既存のスケジューリング関連テーブルへアクセスできるロールと組み合わせて割り当てます。(Microsoft Learn)
| ロール | 割り当てる相手 | できること |
|---|---|---|
| Scheduling Operations Agent Administrator | scope、goal、planを作成・管理する管理者 | 最適化設定の作成、編集、削除、結果確認 |
| Scheduling Operations Agent User | 最適化を実行するディスパッチャー | 対話型最適化、既存planの実行、結果確認 |
さらに、エージェント自体は「Scheduling Operations Agent Team」に属するアプリケーションユーザーとして動作します。標準のスケジューリングテーブルは既定で読み書きできますが、カスタムテーブル、Field ServiceやProject Operationsの追加テーブル、独自クエリで参照するテーブルを使う場合は、Scheduling Operations Agent Teamにも適切なセキュリティロールを割り当てる必要があります。(Microsoft Learn)
列レベルセキュリティを使っている場合も注意が必要です。scopeやクエリで参照する列にフィールドセキュリティプロファイルが設定されている場合、Scheduling Operations Agent Teamをそのプロファイルに追加しないと、フィルター条件が正しく反映されず、期待しない結果になる可能性があります。(Microsoft Learn)
予約ステータスと優先度の設定が結果を大きく左右する
Scheduling Operations Agentの導入で最も失敗しやすいのは、AI機能そのものではなく、既存データの設定です。特に、予約ステータスのOptimization MethodとPriority Valueは、結果に直接影響します。
Booking StatusのOptimization Methodを設定する
Booking Statusには、エージェントがその予約を動かしてよいかを示すOptimization Methodというプロパティがあります。設定しない場合、エージェントはそのステータスの予約をDo Not Moveとして扱います。つまり、ScheduledやCommittedなどのステータスにOptimization Methodを設定していないと、エージェントが予定をほとんど動かせず、期待した最適化結果が出ない可能性があります。(Microsoft Learn)
| Optimization Method | 意味 | 適した例 |
|---|---|---|
| Optimize | エージェントが予約を移動または削除できる | まだ移動可能なScheduled、Committedなど |
| Do Not Move | 到着予定時刻を保持する | 作業中、移動中、顧客と時刻確約済みの予約 |
| Ignore | 既存予約を上書きして新しい予約を作成できる | Canceledなど、予定として扱わない予約 |
実務では、標準ステータスだけでなく、現場用に「Locked」のようなステータスを作り、Optimization MethodをDo Not Moveにしておくと便利です。ディスパッチャーが「この予約だけは動かさない」と判断したときに、明示的にロックできます。Microsoftも同様の考え方をTipとして示しています。(Microsoft Learn)
Priority Valueを設定する
Priority Valueは、エージェントが予約や要件の重要度を判断するための数値です。1から100までの値を設定でき、数値が高いほど優先度が高いものとして扱われます。公式ドキュメントでは、Priority Valueが75の高優先度予約は、Priority Valueが50の高優先度予約より優先される例が示されています。(Microsoft Learn)
注意すべきは、極端な値を付けすぎないことです。たとえば「Low = 1」「Medium = 10」「Emergency = 100」のように差を広げすぎると、Emergencyが移動時間や効率を大きく犠牲にしてでも選ばれやすくなります。まずは値の差を分かりやすくしつつ、過度に広げない設計が現実的です。(Microsoft Learn)
ゴール設計では「何を最適化するか」を明確にする
Scheduling Operations Agentでは、goalが最適化の方向性を決めます。goalは、目的を表すobjectivesと、対象リソースが要件を満たすかを判断するconstraintsを組み合わせたものです。(Microsoft Learn)
標準で用意されるbuilt-in goalsには、Maximize UtilizationやFront-load High-Priority Workなどがあります。built-in goalsは読み取り専用で、Microsoft側の更新により変わる可能性があります。一方、custom goalsは管理者が作成・編集でき、目的の重み付けや制約の既定値を調整できます。(Microsoft Learn)
| 目的 | 向いている運用 | 注意点 |
|---|---|---|
| 稼働率を高めたい | 技術者の空き時間を減らしたい | 移動時間や優先度とのバランスが必要 |
| 高優先度作業を前倒ししたい | 障害対応、緊急保守、VIP顧客対応 | 移動時間が増える可能性がある |
| 既存予約をなるべく維持したい | 顧客連絡済みの予定を大きく変えたくない | 最適化の自由度は下がる |
| 移動時間を減らしたい | 広域訪問、交通費削減、CO2削減 | 優先度の高い作業が後回しになる場合がある |
| スキルやテリトリを厳密に守りたい | 資格必須作業、地域担当制 | 対象候補が減り、予定が埋まりにくくなる |
custom goalでは、objectivesに1から10のweightを設定します。ただし、weightは絶対値ではなく相対的な重要度です。公式ドキュメントでも、ある目的を極端に高く設定すると他の目的を犠牲にする可能性があることが示されています。(Microsoft Learn)
最初は、目的を絞った小さなscopeで実行し、Review before applyで結果を確認してください。たとえば、特定テリトリの3人の技術者、翌営業日の8時間、優先度が高い未対応要件だけに絞ると、結果の妥当性を判断しやすくなります。
制限事項とトラブルを事前に把握する
プレビュー段階のScheduling Operations Agentには、最適化規模や対象リソースに制限があります。導入前にここを確認しておかないと、「実行できない」「一部の要件が落ちる」「結果が期待と違う」といった問題が起きやすくなります。
| 項目 | 対話型最適化 | バッチ最適化 |
|---|---|---|
| リソース数 | 最大5 | 最大50 |
| 既存予約と未対応要件の合計 | 最大120 | 最大4,000 |
| リソースあたりの予約数 | 記載なし | 最大2,000 |
| 最適化範囲 | 将来の任意の72時間 | 最大14日 |
公式の制限ページでは、プレビュー中の制限として上記の値が示されています。制限を超える場合、エージェントは関連性が高いレコードを残し、残りを対象外にすることがあります。既存予約だけでジョブ数の上限を超える場合は、最適化自体が失敗します。(Microsoft Learn)
また、Crew、Equipment、Pool、Facilityタイプのリソース、requirement groups、multiday requirements、1勤務日または1シフトあたり4つ以上の休憩などは制限事項として示されています。プレビュー機能は更新により変わる可能性があるため、特に複雑なリソース種別を使っている組織は、対象環境での実機確認が欠かせません。(Microsoft Learn)
よくあるエラーとしては、対象レコードが多すぎて一部が切り捨てられる、既存予約が多すぎる、時間範囲が技術者の勤務時間と重ならない、予約に親のresource requirementがない、場所や期間などのデータが不正、最適化後に予約や要件が変更された、結果が72時間を超えて古くなった、などがあります。(Microsoft Learn)
移行期限はあるのか
2026年7月1日時点の公式ドキュメントでは、Scheduling Operations Agent overviewに関して、既存機能からの強制移行期限や廃止期限は明示されていません。したがって、この記事の範囲では「いつまでに移行しなければならない」とは言えません。
ただし、移行期限がないから何もしなくてよい、という意味ではありません。Scheduling Operations Agentは、Universal Resource SchedulingやSchedule Boardのデータ構造、予約ステータス、優先度、テリトリ、スキル、作業時間に強く依存します。将来的に正式リリースや機能拡張が行われた際にすぐ評価できるよう、今のうちにスケジューリングデータを整理しておく価値があります。
特に次のような組織は、早めに検証を始めると効果を判断しやすくなります。
- 技術者数が多く、当日調整に時間がかかっている
- キャンセルや緊急作業が多く、手動での差し替えが頻繁に発生する
- 訪問先が広域に分散し、移動時間の最適化が課題になっている
- 優先度の高い作業を前倒ししたいが、判断基準が属人化している
- 複数国・複数タイムゾーンでField Serviceを運用している
グローバル展開で注意すべき点
グローバル環境では、リージョン、言語、タイムゾーン、データ品質の差が結果に影響します。
まず、リージョン展開は段階的です。Universal Resource Schedulingのリリーススケジュールでは、各Stationごとに現在のバージョン、次バージョン、予定日が示されています。日本を含むStation 3は、2026年7月時点の表でUnited Arab Emirates、Japan、Asia Pacific、United Kingdom、Singaporeと同じグループに分類されています。(Microsoft Learn)
次に、言語です。FAQでは、エージェントがスケジューリング関連のプロンプトを判定するテストは英語で行われたと説明されています。一方、スケジュール提案に使う最適化アルゴリズム自体は言語非依存とされていますが、すべての言語がサポートされるわけではありません。(Microsoft Learn)
日本語環境で使う場合は、Copilotサイドペインからの自然言語指示だけに依存せず、スケジュールボードやリソース一覧からの実行も含めて検証すると安全です。現場担当者向けには、「何を入力すればよいか」よりも、「どの条件で実行し、結果をどう確認するか」を教育した方が定着しやすくなります。
タイムゾーンも重要です。対話型最適化では、最適化のTime zoneを選択でき、スケジュールボードから起動した場合はそのタイムゾーンが既定になり、それ以外の入口ではユーザー設定のタイムゾーンが使われます。(Microsoft Learn)
複数国で同じField Service環境を使っている場合は、次のような検証が必要です。
| 検証項目 | 確認内容 |
|---|---|
| タイムゾーン | 技術者、ディスパッチャー、スケジュールボードのタイムゾーンが期待通りか |
| 作業時間 | 各国の勤務時間、休日、休憩が正しく登録されているか |
| テリトリ | 国・地域・拠点ごとの担当範囲が実運用と一致しているか |
| スキル | Characteristicsが古い資格情報のままになっていないか |
| 優先度 | 国ごとに優先度の意味がばらついていないか |
導入時の実務チェックリスト
Scheduling Operations Agentを有効化する前に、次の順番で確認すると、トラブルを減らせます。
| フェーズ | やること | 完了基準 |
|---|---|---|
| 事前確認 | 対象環境のField ServiceとUniversal Resource Schedulingのバージョンを確認 | 前提バージョンを満たしている |
| 環境設定 | Location and map settingsを有効化 | 地図・移動時間を使う前提が整っている |
| 課金設計 | Copilot Studioメッセージ容量または従量課金を確認 | 容量不足時の対応者が決まっている |
| 権限設計 | Administrator/Userロールと既存Dispatcherロールを整理 | 最小限の利用者に割り当て済み |
| データ整理 | 作業時間、休憩、Start/End Location、テリトリ、スキルを確認 | 代表リソースで不整合がない |
| ステータス設定 | Booking StatusのOptimization Methodを設定 | Scheduled、Committed、Canceledなどの扱いが明確 |
| 優先度設定 | Priority Valueを設定 | 極端すぎない数値レンジになっている |
| 検証 | 小さなscopeでReview before applyを使う | 提案結果を業務責任者が判断できる |
| 展開 | 対象チームを段階的に拡大 | 実行頻度、容量、結果品質を監視できている |
この中で特に重要なのは、予約ステータスと優先度です。AIの提案が不自然に見える場合でも、原因がエージェントではなく、Do Not Move扱いの予約が多すぎる、Priority Valueが未設定、テリトリやスキルが実態と合っていない、というケースがあります。Microsoftの改善ガイドでも、結果品質はリソース、要件、既存予約のデータ設定に依存すると説明されています。(Microsoft Learn)
失敗しやすいポイントと回避策
Scheduling Operations Agentの導入でよくある失敗は、機能をオンにすること自体をゴールにしてしまうことです。実際には、スケジューリング業務の判断基準を設定に落とし込む作業が必要です。
| 失敗例 | 原因 | 回避策 |
|---|---|---|
| ほとんど予定が動かない | Booking StatusのOptimization Methodが未設定でDo Not Move扱いになっている | ScheduledやCommittedなど、動かせるステータスをOptimizeにする |
| 高優先度作業ばかり選ばれる | Priority Valueやgoalのweightが極端 | 値の差を抑え、1つずつweightを調整する |
| 移動時間が不自然 | 住所、Start/End Location、テリトリが不正確 | 代表データを地図上で確認する |
| 結果が現場感と合わない | scopeが広すぎる、無関係な要件を含めている | テリトリやスキルで対象を絞る |
| 適用時に警告が出る | 最適化後に予約や要件が変更された | 最新状態で再実行し、古い結果を適用しない |
| グローバル拠点で混乱する | タイムゾーンや言語設定の差を未検証 | 拠点別に検証シナリオを作る |
特に、バッチ最適化を自動適用にする場合は慎重に判断してください。Apply automaticallyは便利ですが、最初から使うと、現場が意図しない予定変更に気づきにくくなります。まずはReview before applyで結果を確認し、業務ルールに合うgoalとscopeを固めてから自動化を検討するのが安全です。
管理者が次に取るべき行動
Scheduling Operations Agent overviewの更新は、Dynamics 365 Field Serviceのスケジュール最適化が、よりエージェント型の運用に近づいていることを示しています。ただし、現時点ではプレビュー機能であり、強制移行期限が示されているわけではありません。
管理者が今すぐ行うべきことは、次の3つです。
まず、対象環境で前提バージョン、リージョン、Location and map settings、Copilot Studioメッセージ容量を確認します。次に、予約ステータス、Priority Value、技術者の作業時間、テリトリ、スキル情報を整理します。最後に、小さなscopeでReview before applyを使い、現場責任者と一緒に提案結果の妥当性を評価します。
Scheduling Operations Agentは、設定が整っていれば、キャンセル対応、遅延調整、高優先度作業の前倒し、複数技術者の負荷平準化に役立つ可能性があります。一方で、データが不正確なまま有効化すると、期待しない提案や運用混乱につながります。プレビュー段階では、機能の新しさよりも、既存のField Service運用ルールをどこまで明確に設定へ反映できるかが成功の分かれ目です。
コメント