Dynamics 365 Field Service 2026 wave 1の計画を眺めて、まず感じるのは、今回もまた「分かりやすい新機能」や「派手な自動化」を前面に押し出したアップデートではない、という点です。スケジューリングが速くなる、入力が楽になる、アプリが軽くなる。そうした改善は確かに積み重ねられていますが、それだけで今回のwave 1を語るのは、少し表層的に感じます。

この機能は、新しい操作や派手なUIを追加するものではありません。Android端末上でフォームが表示されるまでの時間を、確実に短くすることに焦点を当てています。入力項目が多い作業指示、資産情報、チェックリスト。現場では「見る」「判断する」「入力する」を素早く繰り返す必要がありますが、その最初の一歩であるフォーム表示が遅いと、すべてが後手に回ります。今回の改善は、そのボトルネックを地道に取り除こうとしています。

例えば、現地に到着して状況を確認し、すぐに作業内容を開きたい場面で、フォームが一瞬で立ち上がるかどうかは大きな違いです。通信状況が万全でない環境ではなおさらで、「待たされる」こと自体が判断ミスや入力漏れにつながることもあります。読み込みが速くなることで、作業員は画面を待つのではなく、現場を見る時間を確保しやすくなります。

2025wave2まででも、モバイル体験の改善は進められてきましたが、実際の現場では「理屈より体感」が評価基準になります。25%という数字そのものよりも、「明らかに軽くなった」「前より迷わず使える」という感覚が重要です。今回のwave1は、その体感をきちんと積み上げようとしているように見えます。

2026wave1全体の流れで見ると、この改善もまた、Field Serviceを「操作するシステム」から「判断を邪魔しない基盤」へ近づける一手だと言えます。AIやエージェントがどれだけ賢くなっても、現場で画面が開かない、入力がもたつくようでは意味がありません。フォーム表示の高速化は、派手ではありませんが、現場判断の質を下支えする非常に重要な要素です。

留意点としては、速度改善だけで現場体験が完成するわけではない点です。フォームの設計そのものが複雑すぎれば、いくら速く表示されても迷いは減りません。ただ、今回の改善は、その前提となる「待たされない」状態を確実に作ろうとしています。Field Serviceが向かっているのは、現場で考える時間を増やし、画面を待つ時間を減らす方向です。その姿勢が、この一見地味な改善からもはっきりと伝わってきます。

この機能は、フォーム上の参照項目をタップしたときに、詳細画面へ遷移してしまう挙動を抑制します。つまり、「確認したい」「選びたい」だけなのに、意図せず別画面に飛ばされてしまう動きをなくし、フォーム内での作業に集中できるようにします。一見すると地味ですが、現場作業においては非常に実務的な意味を持ちます。

例えば、作業指示書や資産情報、顧客情報を確認しながら入力を進めている場面で、参照項目のタップが画面遷移につながると、作業の流れが途切れます。特に屋外や移動中、時間に追われている状況では、「戻る」という操作自体が判断のリズムを乱す原因になります。今回の改善は、その無駄な分岐を意図的に減らそうとしています。

2025wave2まででも、参照項目への遷移は「できること」として提供されていましたが、現場では必ずしも歓迎されていませんでした。詳細を見たいときもあれば、単に値を確認したいだけのときもあります。その両方を同じ操作に紐づけてしまうと、結果として誤操作やストレスが増えます。この機能は、「今は何をしたいのか」という利用者の意図に寄り添う方向へ、一歩踏み出しています。

2026wave1全体の流れで見ると、この改善もまた、Field Serviceを「多機能なシステム」にするためのものではありません。むしろ、余計な判断や操作を減らし、現場で考えるべきことに集中できる状態を作るための調整です。AIや自動化が進む一方で、こうした基本操作の精度を高めている点に、今回のwave1の誠実さを感じます。

留意点としては、参照先にすぐ飛べないことが不便に感じられるケースもある点です。そのため、どのフォーム、どの項目でこの挙動を採用するのかは、運用や設計次第になります。ただ、今回の改善が示しているのは、「何でもできる」よりも「迷わずできる」ことを優先する姿勢です。

Disable clickthrough on lookup values in formsは、派手な新機能ではありません。しかし、現場での一つ一つの操作を丁寧に見直し、「判断を邪魔しないUI」に近づけようとする意図がはっきりと表れています。Field Serviceが向かっているのは、現場の判断を加速させるシステムであって、画面操作に気を取らせるシステムではない。その方向性を、この小さな改善は静かに物語っているように感じます。

この機能は、フォーム上のlookupフィールドに対して、よりシンプルな操作感を持つ専用のコントロールを使えるようにします。標準のlookupと比べて、画面の情報量が抑えられ、タップ数が減り、探して選ぶという行為そのものが軽くなります。とくにモバイルでの利用を前提に設計されており、Field Serviceの現場作業に寄り添ったUIです。

例えば、作業中に関連する資産を選び直す、顧客や設置場所を確認する、部品や品目を指定するといった場面で、lookupが重いと判断のテンポが崩れます。選択画面に飛び、戻り、もう一度探す。この繰り返しは、現場では「少し面倒」では済まず、入力漏れや誤選択につながることもあります。簡略化されたlookupは、そのつまずきを減らし、選択操作を作業の流れの中に自然に溶け込ませようとしています。

これまでのField Serviceでは、lookupは多機能である一方、モバイルでは「操作が多い」「見づらい」「意図せず別画面に入りやすい」といった摩擦が残りがちでした。その結果、現場では最低限の入力だけを済ませたり、後からまとめて修正したりといった運用に寄ることも少なくありませんでした。今回の改善は、そうした現実を前提に、まずは“迷わせない”ことを優先しています。

2026 wave 1では、この簡略化されたlookupコントロールを、フォームや項目単位で選んで適用できます。すべてを一気に変える必要はなく、現場で特に使用頻度の高いlookupから段階的に入れ替えることもできます。また、Web側の操作感を無理に変えず、モバイルだけを現場向けに最適化できる点も実務的です。

留意点としては、この改善は「速くする」機能というより、「迷わせない」ための機能である点です。どのlookupに適用するかを誤ると、逆に運用が分かりにくくなる可能性もあります。また、UIが軽くなるほど、lookup先のデータ品質や命名規則の影響が表に出やすくなります。探しやすい名前、重複の少ないマスター、整理されたビューが揃っているほど、この改善は効いてきます。

Add simplified lookup controlは、派手な新機能ではありません。しかし、現場で毎日何十回も行われる操作を丁寧に見直し、「判断を邪魔しないUI」に近づけようとする姿勢がはっきりと表れています。Field Serviceが向かっているのは、機能を増やす方向ではなく、現場で考える時間を増やし、画面操作に取られる時間を減らす方向です。その意図を、この小さな改善は静かに物語っているように感じますね。

この機能は、モバイル画面上で使いやすい簡易ノート入力コントロールを提供し、作業レコードの画面を離れることなく、テキストや画像、動画をその場で記録できるようにします。ノートはタイムラインに直接保存されるため、後から振り返る際にも文脈が分断されにくくなります。メモを「後処理」ではなく、「作業の一部」として扱える設計です。

例えば、現場で設備の状態を確認した瞬間に写真を残す、口頭での顧客説明内容をその場で短く記録する、作業中に気づいた注意点を忘れないうちにメモする。こうした行為は、従来であれば手間がかかるため省略されがちでした。簡略化されたノート入力は、その場で残すという選択を現実的にし、結果として記録の鮮度と質を高めます。

これまでのField Serviceでもノートや添付は可能でしたが、多くの場合は画面遷移が多く、「今は作業に集中したい」という現場の感覚と噛み合わない場面がありました。そのため、重要な情報が記憶頼りになったり、曖昧なまま記録されたりすることもあります。今回の改善は、そうしたズレをUIレベルで解消しようとしています。

2026 wave 1全体の流れで見ると、この機能もまた、Field Serviceを「記録を後で整えるシステム」から「判断と記録が同時に進む基盤」へ近づける一手だと感じます。AIや自動化が進んでも、現場で何が起きていたのかは、人が残した一次情報に依存します。その入口を軽くすることは、後工程の品質にも直結します。

留意点としては、ノートが取りやすくなるほど、何を残すかのルールや粒度が重要になる点です。すべてを記録しようとすると逆にノイズが増えますし、使い方が揃っていないと後から読み取りにくくなります。この機能の価値は、「たくさん書ける」ことではなく、「必要なことを、必要なタイミングで残せる」ことにあります。

Add notes with the simplified mobile note‑taking controlは、派手な新機能ではありません。しかし、現場の判断と記録を切り離さず、その場で完結させようとする姿勢は、2026 wave 1のField Service全体の方向性とよく一致しています。現場で考え、気づき、残す。その一連の流れを邪魔しないための、静かですがとても重要な改善だと個人的には感じています。

この機能は、複数の予約を選択し、それらを同じ時間オフセットで一括して前後に移動できるようにします。例えば、午後の作業をすべて1時間後ろ倒しにする、今日予定していた作業をまとめて翌日にずらす、といった調整を、個別に編集することなく行えます。1件ずつドラッグして直す、開始時刻を手入力で修正する、といった繰り返し作業を減らすことが狙いです。

これまでのField Serviceでは、スケジュール変更はできるものの、「まとめてずらす」操作は意外と手間がかかりました。その結果、ミスを恐れて最小限の調整に留めたり、現場に無理をお願いしたりといった判断につながることもあります。一括オフセット移動は、そうした判断の歪みを減らし、「状況に合わせて計画を引き直す」ことを現実的にします。

例えば、朝一の作業が長引いた場合、その後の予定をすべて少しずつ後ろにずらす判断は、現場では自然ですが、システム上でそれを反映するのは簡単ではありませんでした。この機能によって、ディスパッチャーは全体を俯瞰しながら、「今日はこの流れで行こう」と判断を更新しやすくなります。作業時間や予約の詳細を保ったまま位置だけを動かせる点も、実務上の安心感につながります。

2026 wave 1全体の流れで見ると、この改善もまた、Field Serviceを「最適化された固定計画」から「変化を前提にした運用」へ寄せる一手だと感じます。AIによるスケジューリングや最適化が進んでも、現実の現場では計画どおりに進まないことの方が多い。そのときに、人が全体を見て判断し、素早く計画を引き直せる余地があるかどうかが重要です。

留意点としては、一括で動かせるからこそ、影響範囲を意識した運用が必要になる点です。顧客への連絡や、SLAへの影響、作業員の稼働時間など、スケジュール変更が波及する先は少なくありません。この機能の価値は、計画を雑に動かすことではなく、「変化に対して迷わず対応できる」ことにあります。

Move multiple bookings at once by a set offsetは、派手な新機能ではありません。しかし、Field Serviceが判断の仕事になっている現実を正面から受け止め、「まとめて考え、まとめて動かす」ための道具を用意した改善だと感じます。計画を守ることより、現実に合わせて計画を更新すること。その姿勢が、2026 wave 1のField Serviceにははっきりと表れているように思います。

この機能は、複数の予約をまとめて選択し、それらを一括で別のリソースに再割り当てできるようにします。1件ずつ予約を開き、担当者を変更し、保存する、という繰り返し作業を行う必要はありません。作業時間や開始・終了時刻はそのままに、担当リソースだけを切り替えられる点が、実務上の大きなポイントです。

例えば、特定の技術者が急遽対応できなくなった場合、その人に割り当てられていた一連の作業を、まとめて別の技術者やチームに引き継ぐ必要があります。従来は、ミスを恐れながら個別に変更するしかなく、判断自体が遅れることもありました。一括再割り当てによって、ディスパッチャーは全体を俯瞰しながら、「この作業群はこの人に任せよう」と判断を素早く反映できます。

2025wave2まででも、再割り当ては可能でしたが、「まとめてやる」ための操作は十分に整っているとは言えませんでした。その結果、現場ではスケジュールをいじらずに無理をお願いしたり、負荷の偏りを承知のうえで放置したりといった選択が生まれがちでした。今回の改善は、その歪みを減らし、「人を入れ替える」という判断をシステム上でも自然な操作にしています。

2026 wave 1全体の流れで見ると、この機能もまた、Field Serviceを「固定された割り当て前提」から「変化を前提にした運用」へ寄せる一手だと感じます。AIによる最適化が進んでも、最終的に誰に任せるかを決めるのは人です。その判断を、手間や操作ミスで鈍らせないための配慮が、この改善には込められています。

留意点としては、一括で再割り当てできるからこそ、スキル要件や資格、地域制約といった前提条件をきちんと設計しておく必要がある点です。誰にでも移せる状態では、かえって品質が下がる可能性もあります。この機能の価値は、割り当てを雑にすることではなく、「適切な人に、まとめて任せる」判断を支えることにあります。

Move multiple bookings at once to new resourceは、派手な新機能ではありません。しかし、Field Serviceの現場で日常的に起きている判断を、システムが素直に受け止められるようにする、非常に実務的な改善だと感じます。時間だけでなく、人の配置を柔軟に見直せること。その余地を広げることこそが、2026 wave 1のField Serviceが向かっている方向なのだと思いました。

この機能は、スケジュールボード上のマップ表示を、画面全体に広げて表示できるようにします。リストやガント表示に押し込められていた地図を主役に据え、リソースの位置、予約の分布、エリアごとのカバレッジを、余計な情報に邪魔されずに確認できます。ディスパッチャーが空間的な把握を前提に判断できる状態を、意図的に作っています。

例えば、特定の地域に作業が集中していないか、逆に手薄になっているエリアはどこか、移動距離が無理な割り当てになっていないか。こうした判断は、表やリストではなく、地図で見た瞬間に分かることが多くあります。全画面マップは、その「気づき」を逃さず拾える視界を提供します。

これまでのスケジュールボードでもマップは表示できましたが、他のパネルと並列に扱われるため、どうしても情報量が限られていました。その結果、細かな調整や全体俯瞰は、頭の中で補完する必要がありました。今回の改善は、「地理情報を補足情報として扱わない」という明確なメッセージを感じさせます。

2026 wave 1全体の流れで見ると、この機能もまた、Field Serviceを「時間軸だけで最適化する世界」から、「空間を含めて判断する世界」へ寄せる一手だと感じます。AIによる最適化や自動割り当てが進んでも、最終的に「この配置で本当に大丈夫か」を判断するのは人です。その判断に必要な視界を、システムがしっかり用意しようとしています。

留意点としては、地図が主役になるほど、表示する情報の取捨選択が重要になる点です。すべてを一度に見せようとすると、かえって判断しづらくなることもあります。全画面マップは、使う場面を選び、「いまは地理を見る」と意識的に切り替えて使うことで真価を発揮します。

View full screen map mode on schedule boardは、派手な新機能ではありません。しかし、ディスパッチャーの視点に立ち、「考えるための視界」を広げることに真正面から向き合った改善です。Field Serviceが向かっているのは、操作を増やすことではなく、判断をしやすくすること。その方向性を、この全画面マップは静かに、しかしはっきりと示しているように感じますね。

この機能は、スケジュールボード上に週番号を表示できるようにします。日付や曜日だけでなく、「週」という単位を明示することで、ディスパッチャーは時間軸をより構造的に捉えられるようになります。特に、複数週にまたがる計画や、月末・月初、年度切り替えといった境界を扱う場面で、判断の前提が揃いやすくなります。

例えば、「この作業は今週中に終わらせるべきか」「来週にまとめて回した方がよいか」といった判断は、実質的には週番号ベースで行われていることが多いはずです。しかし、これまではその判断を頭の中で補完する必要がありました。週番号が明示されることで、「第◯週はこう動く」という認識を、画面上でそのまま共有できます。

これまでのスケジュールボードでも、日単位・時間単位の調整は十分にできましたが、週をまたぐ視点はやや弱い部分がありました。その結果、「思っていた週と違った」「調整したつもりが一週ずれていた」といった、地味だが影響の大きいズレが起きることもあります。今回の改善は、そうしたズレをUIレベルで未然に防ごうとしています。

2026 wave 1全体の流れで見ると、この機能もまた、Field Serviceを「細かな操作の集合」から「構造的に計画を考える場」へ寄せる一手だと感じます。AIが最適化を提案する場面が増えても、人が最終的に見るのは、「この週、この負荷、この配置でいけるかどうか」です。その判断の前提となる時間軸を、より明確に示そうとしています。

留意点としては、週番号の表示が増えることで、情報量が増えたと感じる人もいるかもしれません。ただ、この機能は「見せるため」ではなく、「迷わせないため」のものです。週単位で計画を考える場面で意識的に使うことで、その価値がはっきりします。

Show week numbers on schedule boardは、非常に地味な改善です。しかし、Field Serviceが扱う計画の粒度が日から週へ、週から複数週へと広がる中で、「いまどの週を見ているのか」を明確にすることは、判断の質を下支えする重要な要素です。時間を正確に扱うことは、作業を管理するためではなく、判断を揃えるためにある。その方向性を、この小さな改善は静かに示しているように感じます。

この機能は、集約表示された予約ビュー上で、予約全体ではなく、構成されているセグメントの一部だけをキャンセルできるようにします。つまり、「この作業は生きているが、この区間は不要になった」という現場の判断を、予約を作り直すことなく、そのままシステムに反映できます。全体かゼロか、という極端な選択を迫られない点が重要です。

例えば、午前中の作業は予定どおり完了したが、午後に予定していた追加対応が不要になった場合。従来であれば、予約をいったんキャンセルして作り直すか、無理に完了扱いにするか、といった歪んだ対応になりがちでした。この機能によって、不要になったセグメントだけを取り消し、残りは正しく残す、という現実に即した処理が可能になります。

これまでのField Serviceでは、予約はひとまとまりの単位として扱われることが多く、「途中までやった」「一部だけ変わった」といった状態をきれいに表現するのが難しい場面がありました。その結果、実態と記録がズレたり、後続の請求や分析に影響が出たりすることもあります。今回の改善は、そのズレをUIレベルで解消しようとしています。

2026 wave 1全体の流れで見ると、この機能もまた、Field Serviceを「理想的な計画前提のシステム」から「現実に合わせて調整され続けるシステム」へ寄せる一手だと感じます。現場では、計画どおりに進まないことの方が多い。その中で、「どこまでを生かし、どこからを止めるか」という判断を、無理なく記録できることは非常に重要です。

留意点としては、部分キャンセルができるからこそ、セグメントの設計や意味づけがより重要になる点です。どこで区切っているのか、各セグメントが何を表しているのかが曖昧だと、判断も記録も分かりにくくなります。この機能の価値を最大限に活かすには、「予約をどう分けているのか」という設計思想が問われます。

Cancel segments of a booking in aggregate viewsは、派手な新機能ではありません。しかし、「全部やるか、全部やめるか」ではなく、「必要なところだけを残す」という、人間の自然な判断をそのまま受け止められるようにした改善です。Field Serviceが向かっているのは、計画を守るためのシステムではなく、現実に合わせて計画を更新し続けるための基盤です。その方向性を、この“部分キャンセル”という機能はとても分かりやすく示しているように感じます。

この機能は、複数のリソースをまとめて対象とし、スケジュール全体を見渡しながら最適化を支援します。特定の予約だけを動かすのではなく、複数の技術者、複数の作業を含めて、「いまの条件下で、全体としてどう配置するのがよいか」を考えるための材料を提示します。人の判断を置き換えるのではなく、判断の前提を整理する役割に徹しています。

例えば、急な欠員や想定外の作業増加が発生したとき、誰か一人に負荷を寄せるのではなく、複数のリソースを少しずつ組み替える方が現実的な場合があります。Scheduling Operations Agentは、そうした状況で、時間、場所、作業内容といった条件を踏まえながら、全体のバランスを見直すヒントを提供します。ディスパッチャーは、その結果を見て、「この案でいく」「ここは人の判断で変える」といった選択ができます。

これまでの最適化は、どうしても「この予約を誰に割り当てるか」「この時間をどう埋めるか」といった局所的な視点になりがちでした。その結果、全体としては無理のある配置になっていた、というケースも少なくありません。この機能は、最適化を一度引いて眺め、「全体として無理がないか」を確認するための視点を提供します。

2026 wave 1全体の流れで見ると、この機能もまた、Field Serviceを「自動で決めるシステム」ではなく、「判断を助ける基盤」へ寄せる一手だと感じます。Agentという名前が付いていますが、最終的に決めるのは人です。AIは、見落としやすい偏りや非効率を浮かび上がらせる役割に留まっています。

留意点としては、最適化の結果をそのまま受け入れるのではなく、前提条件を理解したうえで使うことが重要になる点です。スキル、顧客との関係性、現場の暗黙知といった要素は、数値化しきれない部分も多くあります。この機能の価値は、「正解を出す」ことではなく、「考えるべき範囲を広げる」ことにあります。

Optimize multiple resources with Scheduling Operations Agentは、派手な自動化ではありません。しかし、Field Serviceの現実が「一人ずつ最適化する世界」から「全体を見て調整する世界」に移っていることを、非常に素直に反映した機能だと感じます。個々の作業を詰めるより、全体の無理を減らす。そのための視点を、システムがそっと差し出してきている。2026 wave 1のField Serviceが向かおうとしている方向性が、この機能からもはっきりと読み取れるように思います。

この機能は、作業員が入力した作業時間や工数を、あらかじめ定義されたプロジェクトルールに基づいて承認できるようにします。誰が見るか、どの条件なら承認できるか、どこで差し戻すかといった判断を、人の感覚だけに委ねず、「このケースではこのルール」という前提を持たせる点がポイントです。時間承認を、属人的な確認作業から、設計されたプロセスへ近づけています。

例えば、特定の作業タイプは即時承認でよいが、別の作業は上長確認が必要、といったルールを持っている組織は多いはずです。これまでは、その判断を運用ルールやチェックリストで補ってきたケースも少なくありませんでした。この機能によって、プロジェクトルールを基準に承認フローを揃えられるため、「人によって判断が違う」「忙しいときは流れてしまう」といったブレを減らしやすくなります。

2025 wave 2まででも、時間入力や承認そのものは可能でしたが、Field Serviceとプロジェクト管理、会計・請求のルールが頭の中でつながっていないと、確認作業が重くなりがちでした。その結果、承認が遅れる、修正が後から大量に発生する、といった問題につながることもあります。今回の改善は、「時間はあとで整えるもの」ではなく、「最初からルールに沿って通すもの」という前提を強めています。

2026 wave 1全体の流れで見ると、この機能もまた、Field Serviceを「現場だけで完結する仕組み」から、「後工程まで見据えた基盤」へ寄せる一手だと感じます。現場での判断と、バックオフィスでの判断を切り離さず、同じルールでつなごうとしています。作業員の入力、承認者の判断、最終的な請求や分析が、一つの流れとして揃いやすくなります。

留意点としては、プロジェクトルールの設計が曖昧だと、この機能の効果が出にくい点です。どの時間をどう扱うのか、何を例外とするのかが整理されていないと、承認は結局人の判断に戻ってしまいます。この機能は魔法の自動承認ではなく、「判断基準を揃える」ための道具です。

Approve field time entries using project rulesは、派手なUI改善でも、現場を劇的に変える機能でもありません。しかし、Field Serviceの仕事が「現場で終わるものではない」以上、時間の扱いをどう揃えるかは避けて通れないテーマです。現場の記録を、そのままビジネスの判断につなげる。そのための地味ですが重要な一歩として、この機能は2026 wave 1らしい位置づけにあると感じます。

Create work orders from project tasks

この機能は、プロジェクト上で定義されたタスクを起点に、Field Serviceの作業指示を直接作成できるようにします。つまり、「計画としてのタスク」と「現場で実行される作業」を、別物として扱うのではなく、一続きの流れとしてつなげようとしています。プロジェクト側で考えた内容を、現場用に書き直す手間や解釈のズレを減らすことが狙いです。

例えば、設備更新や定期メンテナンスのように、プロジェクト単位で計画されつつ、実行はフィールド作業になるケースでは、「このタスクは現場で誰が、いつ、どんな形でやるのか」を改めて整理する必要がありました。今回の改善によって、プロジェクトタスクをそのまま作業指示の起点にできるため、計画段階の意図を保ったまま、Field Serviceに引き渡しやすくなります。

これまでの運用では、プロジェクト管理とField Serviceが並走しているようで、実際には人が間に入ってつなぎ直している場面も多くありました。その結果、「計画どおりにやったはずなのに、現場では違う理解だった」「作業が終わってから、どのタスクに紐づくのかを後で整理した」といったズレが生まれがちでした。この機能は、そのズレをシステム側で吸収しようとしています。

2026 wave 1全体の流れで見ると、この改善もまた、Field Serviceを「単発の現場作業管理」から「上流の計画と地続きの実行基盤」へ寄せる一手だと感じます。現場で起きていることを、後からプロジェクトに合わせるのではなく、最初から同じ前提で扱う。そのことで、進捗管理やコスト把握、振り返りが自然につながります。

留意点としては、プロジェクトタスクの設計が曖昧だと、そのまま作業指示に落とすことが逆に負担になる可能性がある点です。どのタスクが現場作業に相当するのか、どこまでを一つの作業指示として扱うのか、といった整理は必要になります。この機能は、設計を省略するものではなく、「設計した内容を、そのまま活かす」ための仕組みです。

Create work orders from project tasksは、派手な自動化ではありません。しかし、計画と実行を分けて考える前提を崩し、「考えたことを、そのまま現場に渡す」流れを作ろうとしています。Field Serviceが向かっているのは、現場だけを最適化する世界ではなく、計画から実行、振り返りまでを一続きで扱える世界です。その方向性を、この機能はとても分かりやすく示しているように感じます。

この機能は、フィールドスケジューリングの画面上で、プロジェクトタスクの文脈を確認できるようにします。単に作業指示の時間や場所を見るだけでなく、「この作業はプロジェクト全体の中でどんな位置づけなのか」「前提条件や依存関係は何か」といった情報を踏まえて判断できる状態を作ります。スケジュールを、点ではなく流れとして捉えるための補助線です。

例えば、ある作業が遅れると、後続のタスクや別チームの作業に影響が出るケースがあります。従来であれば、その関係性はプロジェクト管理側を見に行くか、担当者の記憶に頼るしかありませんでした。この機能によって、スケジューリングの場でその文脈が見えるようになり、「ここは無理に詰めるべきではない」「ここは優先して人を厚くするべきだ」といった判断がしやすくなります。

これまでのField Serviceでは、スケジューリングはどうしても“当日の最適化”に寄りがちでした。時間と距離、空き状況をもとに、その場をどう回すかを考える。一方で、その作業がプロジェクト全体のどこに位置しているかは、別の画面、別の役割の情報として切り分けられていました。今回の改善は、その分断を少しずつ埋めようとしています。

2026 wave 1全体の流れで見ると、この機能もまた、Field Serviceを「現場単位の最適化」から「計画と実行をつないだ判断の場」へ寄せる一手だと感じます。AIやエージェントが提案を出すにしても、その前提となる文脈が共有されていなければ、人は納得して判断できません。プロジェクトタスクの背景を見せることは、判断の納得感を支えるための重要な要素です。

留意点としては、プロジェクトタスク側の設計が曖昧だと、この機能の価値が十分に発揮されない点です。タスクの粒度や依存関係が整理されていないと、表示される文脈も判断に使いづらくなります。この機能は、設計を代替するものではなく、「設計された前提を、現場に正しく伝える」ためのものです。

Show project task context for field schedulingは、派手なUI変更でも、自動化機能でもありません。しかし、スケジューリングを「今日を回す作業」から「全体を見て判断する仕事」へ引き上げる、重要な一歩だと感じます。Field Serviceが向かっているのは、現場だけで完結する世界ではなく、計画・実行・調整が同じ文脈で語られる世界です。その方向性を、この機能はとても静かに、しかし確実に示しているように思います。

Customer Service や Contact Center、Field Service を通して見えてきたのは、AIが主役になる世界ではなく、人の判断をどう支えるか、という一貫した思想でした。では、顧客体験そのものを設計する Customer Insights – Journeys では、その思想はどう表れているのでしょうか。