Microsoft の「Improve Scheduling Operations Agent results (preview) – Dynamics 365 Field Service」は、Scheduling Operations Agent の最適化結果が期待どおりにならないときに、どの設定やデータを見直すべきかを整理した管理者向けの公式ガイドです。結論から言うと、今回のポイントは「新しい画面を覚えること」ではなく、リソース、作業要件、既存予約、最適化目標、対象範囲を整え、エージェントが判断しやすい状態を作ることにあります。
特に影響を受けるのは、Dynamics 365 Field Service でスケジュールボードを使うディスパッチャー、Scheduling Operations Agent のロールや計画を管理する管理者、そしてフィールドサービスの最適化ルールを設計する運用担当者です。Microsoft Learn の対象ページは 2026年7月1日に更新されており、同機能はプレビューとして提供されています。Microsoft はプレビュー機能について、本番利用を前提とせず、機能が制限されたり変更されたりする可能性があると説明しています。(Microsoft Learn)
Microsoft の「Improve Scheduling Operations Agent results」で何が整理されたのか
今回の「Improve Scheduling Operations Agent results (preview)」は、Dynamics 365 Field Service の Scheduling Operations Agent が返すスケジュール候補を改善するための実務的なチェック項目をまとめた内容です。
Scheduling Operations Agent は、リソース、リソース要件、既存予約を評価し、最適化されたスケジュールを提案します。ただし、提案結果の品質は、勤務時間、休憩、開始・終了地点、テリトリー、スキル、優先度、予約ステータスなどのデータがどれだけ一貫して設定されているかに左右されます。(Microsoft Learn)
つまり、エージェントの結果が「なぜこの作業が選ばれないのか」「なぜ既存予約が置き換わるのか」「なぜ移動時間が不自然なのか」と感じる場合、AI そのものを疑う前に、まず Field Service 側の設定とマスターデータを確認する必要があります。
影響範囲：誰が何を確認すべきか
この更新の影響は、Scheduling Operations Agent を使うすべての組織に及びます。ただし、直接対応が必要になる範囲は役割によって異なります。
| 対象者 | 影響する業務 | 確認すべきこと |
|---|---|---|
| Field Service 管理者 | 機能有効化、ロール、容量、予約ステータス、優先度設定 | エージェントの有効化、セキュリティロール、Copilot Studio メッセージ容量、予約ステータスの Optimization Method |
| ディスパッチャー | 当日の再スケジュール、緊急対応、移動ルート最適化 | 提案結果をそのまま適用せず、既存予約や確約時間への影響を確認 |
| 業務設計担当者 | 最適化目標、スコープ、運用ルールの設計 | 目的の重み付け、テリトリー分割、優先度設計、検証手順 |
| グローバル運用担当者 | 複数地域・複数タイムゾーンの運用 | 勤務時間、タイムゾーン、言語サポート、地域別のデータ整合性 |
Scheduling Operations Agent は、インタラクティブ最適化とバッチ最適化の両方に対応します。インタラクティブ最適化はディスパッチャーがその場でスケジュールを調整する用途、バッチ最適化はスコープ、目標、時間範囲を組み合わせて大きめの対象を非同期で最適化する用途です。(Microsoft Learn)
管理者が最初に確認すべき前提条件
Scheduling Operations Agent を利用するには、環境側の前提条件を満たしている必要があります。Microsoft の設定ガイドでは、Field Service version 8.8.133.214 以降、Universal Resource Scheduling version 3.12.149.15 以降、位置情報と地図設定の有効化、Dynamics 365 Field Service アプリの管理者ロールが前提として示されています。(Microsoft Learn)
実務では、次の順番で確認すると抜け漏れを防げます。
- Field Service と Universal Resource Scheduling のバージョンを確認する
- 位置情報と地図設定が有効か確認する
- Field Service アプリで管理者権限を持つユーザーを確認する
- Scheduling Operations Agent を有効化する
- 管理者・利用者・エージェントチームの権限を設定する
- Copilot Studio メッセージ容量または従量課金の準備を確認する
特に見落としやすいのは、エージェント自身のアクセス権です。Scheduling Operations Agent はアプリケーションユーザーとして動作し、ユーザー権限とエージェント側の権限の両方が関係します。カスタムテーブルや追加の Field Service / Project Operations テーブルを最適化条件に含める場合は、Scheduling Operations Agent Team に必要なセキュリティロールを付与する必要があります。列レベルセキュリティを使っている場合は、対象のフィールドセキュリティプロファイルにもエージェントチームを追加しないと、フィルター条件が正しく反映されない可能性があります。(Microsoft Learn)
結果を改善するポイント：リソースと要件データをそろえる
Scheduling Operations Agent の結果品質を上げる第一歩は、リソースとリソース要件の基本データをそろえることです。
Microsoft は、リソース側では勤務時間と休憩、開始地点と終了地点、テリトリー、特性を一貫して設定することを推奨しています。リソース要件側では、From/To Date、Duration、Priority、Time From/To Promised、Territories、Characteristics などが重要です。(Microsoft Learn)
たとえば、同じ東京エリアの作業であっても、リソース側にテリトリーが設定されておらず、要件側だけにテリトリーが入っていると、期待した技術者が候補に入りにくくなります。逆に、スキルや資格を Characteristics で管理しているのに、作業要件側に必要スキルが入っていない場合、エージェントは「誰でも対応できる作業」と判断してしまいます。
実務で確認したいデータ例
| 項目 | 確認内容 | 失敗しやすい例 |
|---|---|---|
| 勤務時間・休憩 | リソースの実際の稼働時間と一致しているか | 昼休憩が未設定で、移動や作業が休憩時間に食い込む |
| 開始地点・終了地点 | 自宅、拠点、営業所などが正しく設定されているか | 終了地点が未設定で、帰着時間を考慮しにくい |
| テリトリー | リソースと要件の地域定義が一致しているか | 東日本・関東・東京など粒度が混在している |
| Characteristics | スキル、資格、対応機器が正しく紐づくか | 要件側に必要スキルがなく、経験のない担当者が候補になる |
| 優先度 | Priority Value が設定されているか | 表示上は高優先度でも、数値が未設定で最適化に反映されない |
最適化目標は「強い重み」を作りすぎない
Scheduling Operations Agent の結果は、設定した goal、つまり最適化目標に大きく左右されます。Microsoft は、新しい目標を試す際には Apply method を「Review before apply」に設定した plan を使い、予約を変更せずに提案結果を確認する方法を推奨しています。(Microsoft Learn)
実務上のポイントは、最初から広範囲に適用しないことです。小さなリソース群、短い時間範囲、絞り込んだ要件ビューで試し、結果を見ながら重みを調整します。いきなり全拠点・全技術者・全未割当作業を対象にすると、なぜその結果になったのかを解釈しにくくなります。
特に注意したいのは、目的の重み付けです。たとえば「高優先度の作業を先にスケジュールする」目的だけを極端に強くすると、移動距離や空き時間の悪化を許容してでも高優先度作業を優先する結果になり得ます。Microsoft も、目的同士にはトレードオフがあるため、重みを近い値から始め、一度に変更する目的は一つに絞る考え方を示しています。(Microsoft Learn)
スコープは小さく始める：大きすぎる最適化は失敗しやすい
Scheduling Operations Agent では、対象範囲を広げすぎると結果が遅くなり、解釈も難しくなります。Microsoft は、関係するリソース、要件、予約を絞り、同じテリトリーや同じスキルを持つまとまりごとに最適化することを推奨しています。(Microsoft Learn)
プレビュー期間中の制限値として、インタラクティブ最適化ではリソース最大5、任意の将来72時間ウィンドウ、既存予約と未割当要件を合わせたジョブ最大120が示されています。バッチ最適化では、リソース最大50、ジョブ最大4,000、リソースごとの予約最大2,000、最適化範囲最大14日です。これらの制限はプレビュー中のもので、機能の進化により変わる可能性があります。(Microsoft Learn)
| 種類 | 主な用途 | 制限の目安 |
|---|---|---|
| インタラクティブ最適化 | 当日・近い将来の手動調整、ディスパッチャーの即時判断 | リソース最大5、将来72時間、ジョブ最大120 |
| バッチ最適化 | 複数リソースや複数日の計画、管理者が設計した plan の実行 | リソース最大50、ジョブ最大4,000、最適化範囲最大14日 |
対象が制限を超えると、エージェントは関連度の高いレコードを保持し、それ以外を落とすことがあります。既存予約が優先され、その後に未割当要件が追加されます。既存予約だけでジョブ上限を超える場合は、最適化自体が失敗します。(Microsoft Learn)
既存予約の扱いを決めないと、予想外の置き換えが起きる
Scheduling Operations Agent は、既存予約も未割当要件と同じように評価します。そのため、ディスパッチャーが午前10時に提案を求めた場合、10時20分の既存予約が、より高優先度の作業に置き換えられるような結果が出ることがあります。(Microsoft Learn)
この挙動を避けるには、次のような運用ルールが必要です。
| やりたいこと | 推奨される対応 |
|---|---|
| 直近の予約を動かしたくない | カスタム時間範囲を使い、現在時刻から1〜2時間後を開始時刻にする |
| 特定の予約を固定したい | Booking Status の Optimization Method を Do Not Move にする |
| 当日のルート順だけを見直したい | 要件を含まない requirement view を選び、既存予約の順序最適化に絞る |
| キャンセル済み予約を上書き可能にしたい | 対象ステータスの Optimization Method を Ignore にする |
ただし、要件を含まないビューを使って既存予約だけを並べ替える場合でも、他の設定に合わない予約や、約束時間のウィンドウが期限切れになっている予約は削除される可能性がある点に注意が必要です。(Microsoft Learn)
Booking Status の Optimization Method は必ず設定する
設定変更で最も重要なのが、Booking Status の Optimization Method です。Microsoft の設定ガイドでは、Optimization Method は予約ステータスの新しいプロパティであり、エージェントが予約を移動または削除できるかを決めるものと説明されています。未設定の場合、そのステータスの予約は Do Not Move として扱われます。(Microsoft Learn)
| Optimization Method | 意味 | 主な利用シーン |
|---|---|---|
| Optimize | エージェントが予約を移動または削除できる | まだ開始していない Scheduled や Committed など |
| Do Not Move | 到着予定時刻を保持する | 移動中、作業中、完了済み、顧客に時刻を確約した予約 |
| Ignore | その予約を上書きして新しい予約を作成できる | Canceled など、最適化上は無視したい予約 |
実務では、標準ステータスだけでなく「Locked」のような予約ステータスを作り、Optimization Method を Do Not Move に設定しておくと便利です。ディスパッチャーが「この予約だけは動かさない」と明示できるため、現場判断と自動最適化を両立しやすくなります。(Microsoft Learn)
優先度は Priority Value で判断される
Scheduling Operations Agent が優先度を正しく判断するには、Priority Value の設定が必要です。Priority Value は 1〜100 の数値で、高い数値ほど高優先度として扱われます。Microsoft は、Level of Importance フィールドはエージェントに無視されると説明しています。(Microsoft Learn)
ここで避けたいのは、優先度の差を極端にしすぎることです。たとえば Low を1、Medium を10、Emergency を100にすると、緊急作業が中優先度の10倍重要な作業として扱われ、移動効率が悪くても緊急作業を強く優先する結果になりやすくなります。Microsoft も、優先度の値は区別しやすくしつつ、比較的狭い範囲に収める考え方を示しています。(Microsoft Learn)
おすすめは、最初から 1・50・100 のように大きく開くのではなく、たとえば Low 20、Medium 50、High 80 のように、業務上の重要度を反映しつつ過度な偏りを避ける設計です。緊急対応を別枠で扱う場合は、Priority Value だけでなく、専用ビュー、専用テリトリー、専用の最適化目標を組み合わせた方が制御しやすくなります。
よくある失敗と対処法
Scheduling Operations Agent の結果が期待どおりにならない場合、原因は大きく分けて「対象データが不適格」「範囲が広すぎる」「固定予約が多すぎる」「時間・場所・優先度の設定が不十分」のいずれかです。
Microsoft のトラブルシューティングでは、レコードの切り捨て、予約数過多、勤務時間と時間範囲の不一致、親要件のない予約、不正な位置情報や期間、結果の期限切れなどが代表的なエラー・警告として整理されています。(Microsoft Learn)
| 症状 | 主な原因 | 対処 |
|---|---|---|
| 一部の作業が候補に出ない | スコープが広すぎてレコードが切り捨てられた | 要件ビューを絞り、テリトリーや時間範囲を小さくする |
| 最適化が実行できない | 既存予約だけでジョブ上限を超えている | 期間を短くする、対象リソースを分ける |
| 勤務時間外に見える提案が出る | リソースの勤務時間、休憩、タイムゾーンが不整合 | 勤務時間とタイムゾーンを確認する |
| 予約がまったく拾われない | Priority Value や Optimization Method が未設定 | 優先度と予約ステータスを確認する |
| 固定予約が邪魔をして改善されない | Do Not Move の予約が重複・休憩・勤務外にかかっている | 固定する予約を見直し、時間範囲を調整する |
| 適用時に結果が反映されない | 最適化後に予約や要件が変更された | 再実行して最新状態で確認する |
| 結果が期限切れになる | 結果が72時間を超過、または対象時間範囲を過ぎた | 最適化を再実行する |
グローバル運用で特に注意したいポイント
グローバル向けに Scheduling Operations Agent を運用する場合、単に英語の公式ドキュメントを読むだけでは不十分です。拠点ごとの勤務時間、現地の休憩ルール、タイムゾーン、テリトリー設計、言語サポートを確認する必要があります。
Microsoft の FAQ では、プロンプトがスケジューリング関連かどうかを判定する能力は英語でテストされており、最適化アルゴリズム自体は言語非依存である一方、すべての言語がサポートされるわけではないと説明されています。また、Scheduling Operations Agent はオンラインでのみ動作し、オフラインでは利用できません。(Microsoft Learn)
日本、米国、欧州、アジア拠点をまたぐ運用では、次のような分け方が現実的です。
| 観点 | 推奨される運用 |
|---|---|
| タイムゾーン | 国・地域ごとに plan や time range を分ける |
| テリトリー | 移動可能な範囲に合わせて、営業地域・技術者拠点単位で分ける |
| 言語 | ディスパッチャーの操作言語と対応言語を事前に確認する |
| 祝日・勤務時間 | 国別カレンダーや勤務パターンをリソースに反映する |
| 権限 | 拠点別のデータアクセス制御と Scheduling Operations Agent Team の権限を合わせる |
移行期限はあるのか
2026年7月1日に更新された対象の Microsoft Learn ページでは、「Improve Scheduling Operations Agent results (preview)」に関する移行期限や強制切り替え日は示されていません。したがって、現時点で管理者が行うべきことは、移行期限に追われた切り替えではなく、プレビュー機能としての検証、設定の棚卸し、既存運用への影響確認です。(Microsoft Learn)
特に Resource Scheduling Optimization add-in など既存の最適化運用を持っている組織では、「すぐに置き換える」よりも、限定された地域・技術者・業務種別で比較検証する方が安全です。Scheduling Operations Agent の既知の制限として、Crew、Equipment、Pool、Facility タイプのリソース、requirement groups、multiday requirements、Resource Scheduling Optimization 固有フィールドなどはサポート対象外とされています。(Microsoft Learn)
導入・検証の進め方
Scheduling Operations Agent を実務に取り入れる場合は、次の順番で進めるとリスクを抑えられます。
| 手順 | 実施内容 | 判断基準 |
|---|---|---|
| 事前確認 | バージョン、地図設定、容量、ロールを確認 | 前提条件を満たしているか |
| 小規模スコープ作成 | 1拠点、少数リソース、短い時間範囲で検証 | 結果を人が説明できる範囲か |
| データ整備 | 勤務時間、休憩、テリトリー、スキル、優先度を修正 | 候補に出ない作業の理由が減るか |
| 予約ステータス設計 | Optimize、Do Not Move、Ignore を整理 | 固定すべき予約と動かせる予約が明確か |
| Review before apply で検証 | 予約を変更せず提案だけ確認 | 期待するルールに沿っているか |
| 段階的に拡大 | リソース数、期間、要件ビューを広げる | エラーや切り捨てが発生しないか |
最初から全社展開を目指すより、まずは「1つのテリトリー」「3〜5人程度の技術者」「翌日または当日の一部時間帯」のように狭く始める方が、原因分析と改善がしやすくなります。
管理者が今すぐ確認すべきチェックリスト
最後に、Microsoft の「Improve Scheduling Operations Agent results (preview)」を踏まえて、管理者が確認すべきポイントを整理します。
- Scheduling Operations Agent がプレビュー機能であることを関係者に共有する
- 本番運用に直結させる前に、Review before apply で提案結果を確認する
- Field Service と Universal Resource Scheduling のバージョンを確認する
- Copilot Studio メッセージ容量または従量課金の準備を確認する
- Scheduling Operations Agent Administrator / User ロールを適切に割り当てる
- Scheduling Operations Agent Team に必要なテーブル権限を付与する
- 勤務時間、休憩、開始地点、終了地点、テリトリー、スキルを整備する
- Booking Status の Optimization Method をすべて確認する
- Priority Value を 1〜100 の範囲で設計し、極端な差を避ける
- 最適化スコープを小さく始め、結果を見ながら段階的に広げる
- グローバル環境ではタイムゾーン、言語、地域別勤務ルールを分けて検証する
- 移行期限は示されていないため、強制移行ではなく検証計画として扱う
今回の更新で重要なのは、Scheduling Operations Agent を「AIが自動でよいスケジュールを作る機能」として丸投げしないことです。良い結果を得るには、エージェントが判断に使うデータを整え、動かしてよい予約と固定すべき予約を明確にし、狭い範囲で検証しながら目標の重みを調整する必要があります。
まずは現在の予約ステータス、優先度、リソースの勤務時間、要件ビューを棚卸しし、1つの拠点または1つの業務チームで Review before apply による検証を始めるのが現実的な第一歩です。
コメント