アベイラビリティマッチング入門：制約ソルバーはどのように担当者を決定するのか

アベイラビリティマッチング（対応可否判定）は、カレンダーに空きがあるかどうかではなく、技術者が実際に案件を引き受けられるかどうかを決定します。スキル、保有資格、移動時間、休憩、顧客の対応可能時間帯のすべてがその結論に影響します。地域のサービス車両フリート向けにスケジューリング機能を構築する開発会社にとって、真に重要な問いは明確です。「すべての必須条件を満たす技術者と開始時間はどれか？」という点です。

クライアントの配車・ディスパッチチームが理由を説明できる回答と、提案段階の候補枠を確定した約束として早計に扱わないシステム連携が必要です。本ガイドでは、制約条件を分解し、具体例に沿って検証プロセスを追いながら、日常運用に接続する前に引き継ぎ処理をテストする方法を解説します。

この仕組みが解決する課題

単にカレンダー上の時間枠が空いているだけでは、技術者が直前にどこにいるのか、要求された作業に必要な資格を保有しているか、あるいは提示しようとしている訪問時間に間に合う移動時間が確保されているかはわかりません。カレンダーの空き時間だけを確認する予約フォームでは、顧客が時間を選択した後に、ディスパッチャーがそれらの判断を行わなければならなくなります。

拠点間では、この認識のズレが調整上の問題を引き起こします。ある営業所からは技術者が空いているように見えても、別の営業所では次の訪問に移動が必要であることを把握している場合があります。顧客は到着予定時間帯を見つめ、現場リーダーは確保すべき休憩時間を重視します。自社アプリケーションは、これらすべての関係者に対して同一の稼働日を正しく表現しなければなりません。

まず、対応資格（条件）と希望（優先順位）を区別することから始めます。必須資格は対応資格の条件であり、それがなければ技術者はその案件の候補になりません。直前の訪問地の近くで作業したいという希望は、条件を満たす候補者の中から選択する際には役立ちますが、必須条件を打ち消してはなりません。

この区別はテストによって確認できます。

広域で運用する車両フリートの場合、汎用的な対応可否フラグの中に拠点間の境界を紛れ込ませないようにしてください。どの技術者がどのエリアを担当できるか、どの制約が必須であるかをクライアントに確認します。未解決のルールは未解決として記録してください。システム連携によって、不足している情報が勝手に「予約許可」へと変換されてはなりません。条件を満たす担当者が誰もいないという結果も有用な回答です。オフィス側は、実行不可能な訪問を顧客に約束してしまう前に、案件内容の変更や別の時間枠の提案を行えるからです。

内部動作の仕組み

割り当て候補を「技術者」「案件」「時間帯」の組み合わせとしてモデル化します。次に、その割り当てに対して必須条件を検証します。制約ソルバーによるスケジューリングは、必ず満たさなければならない条件の判定から始まります。実現可能性が確定して初めて、残りの選択肢の中で優先順位を考慮する設計にすべきです。

• スキル：技術者が作業に必要な能力を備えていること。
• 資格：提案された割り当てに対して、必要な資格が有効であること。
• 移動時間：直前の予定から現地に到着し、さらに次の予定へと移動できること。
• 休憩：一日の稼働時間の中で必要な休憩が確保されていること。
• 対応可能時間帯：提案された訪問が顧客の指定する受け入れ時間帯に収まっていること。

各時間項目を明確に定義します。顧客の時間帯指定は到着時刻を制約するものなのか、それとも作業全体がその時間内に収まる必要があるのか。案件の所要時間には作業時間のみが含まれるのか。定義の仕方によって結論が変わります。実装する前にディスパッチャーに定義を承認してもらってください。技術的に整合性のあるモデルであっても、実際の運用ルールと異なっていれば意味がないからです。

移動時間は予定と予定の間に存在します。

隣接する訪問予定に依存するモデルである場合、移動時間をすべての予約に固定されたおまけのように扱わないでください。同様に、案件候補を直前の予定とだけ照合すると、直後の予定に支障が出る可能性があります。

モデル化に関する背景知識については、最適化ドキュメントを参照してください。ただし、この一般的なリファレンスと自社連携機能の挙動は区別して考えてください。特定のエンドポイントがどのフィールドを受け付けるか、あるいは何を保証しているかを決定するものではありません。

候補が存在しない「空の集合」と「リクエストの失敗」は区別してください。空の集合は提供された条件を満たす割り当てが存在しないことを意味しますが、リクエストの失敗は使用可能な回答が得られていない状態であり、アプリケーション側で異なる対応が必要です。両方を単に「対応不可の日」として表示すると、運用上の原因特定が難しくなり、修復を担当するチームから連携エラーが隠れてしまいます。

具体的なステップ

地域フリートの一日の稼働における修理リクエストの例を考えてみましょう。この案件には特定のスキルと有効な資格が必要です。顧客は指定した時間帯での訪問を許可しており、候補となる技術者のスケジュールにはすでに他の訪問や休憩が入っています。これらの条件は仮定のシナリオです。

カレンダー上は空きがあるように見えるものの、必要な資格を保持していない技術者から検討します。この候補は除外します。到着時間帯を広げても資格の不適合は解決しませんし、他の案件を移動させても結果は変わりません。ディスパッチャーが無関係な変更に時間を費やさないよう、インターフェースには除外の理由を保持・表示すべきです。

別の技術者は適切な資格を持ち、修理作業自体の時間も十分確保されています。しかし、直前の訪問地からの移動時間を考慮すると、顧客の対応可能時間帯に収まりません。この候補も提示された条件を満たしていません。カレンダーの空き枠に移動時間が含まれていなかったためです。

次に、資格を満たし、ルート上も顧客の対応可能時間帯内に現地へ到達できる技術者を考えます。提案された訪問全体を、休憩時間および次の予定と照合します。もしこの作業によって休憩が押し出されたり、次の訪問が実行不可能になったりする場合、その割り当てはやはり不可となります。到着できるだけでは十分ではありません。

条件を満たす候補を保持します。複数の候補が残り、クライアントが運用の優先嗜好に基づいて順位付けを行いたい場合は、割り当てを許可可能にする「条件」と、より望ましいものにする「優先嗜好」の区別を維持してください。優先の理由と除外の理由は明確に分けましょう。配車担当者は、別の選択肢が「許可されている」のか「禁止されている」のかを知る必要があります。

これらのアベイラビリティマッチングの例は、受入テストのシナリオにもなります。資格を変更したり、対応可能時間帯を移動させたり、直前の訪問を変更したりして、他の入力条件はそのまま保持します。テストを実行する前に、結果として何が変わるべきかをディスパッチャーに確認してください。これにより、「一見もっともらしい結果ならOK」とするのではなく、事前に合意した期待値と結果を正確に比較できます。

日常運用への影響と意味

配車チームは、返却された時間枠が何を意味するのかを理解する必要があります。現在のスケジュールから計算された候補枠は、自動的に確定された予約ではありません。アプリケーションが顧客の選択を確定処理する前に、その日の別の変更が同じ技術者に影響を与える可能性があります。

この区別に基づいて引き継ぎ処理を設計してください。予約プロセスがドキュメント通りの挙動で確定するまでは、提案された選択肢を仮の状態として表示します。確定に失敗した場合は、顧客またはディスパッチャーが次に取るべき行動を案内してください。稼働日が停止しているかのように、過去の検索結果を表示し続けないでください。

各入力データの管理責任者を定めておきます。資格記録、顧客の訪問制限、予定所要時間の変更などには、それぞれ責任者が必要です。ルールが古くなっていると、ソルバーはディスパッチャーが意図した問いとは異なる問いに回答することになります。誰も保守管理を担当していない入力データを、自動化を促進しただけで解決することはできません。

クライアントからアベイラビリティマッチングの改善方法について相談されたら、割り当てが拒否されたケースを実際に配車を行う担当者とともに見直してください。本当に不可能なケースと、誤った入力や理解の誤りによるルール設定を明確に区別します。制限の厳しい対応時間帯設定は、すべての候補者が除外されたとしても正しい決定である場合があります。一方で、技術者が実際に資格を保持していても、資格記録が未登録であればシステム上は誤りとなります。

アベイラビリティマッチングソフトウェアを評価する際は、「稼働率向上」といった大まかな謳い文句ではなく、こうした具体的な挙動の説明に基づいて評価してください。システム連携が何を返すのか、自社アプリケーションで何を保持すべきか、ディスパッチャーが何を確認できるかを検証します。これらのアベイラビリティマッチングのポイントを、予約ワークフローの受入基準へと落とし込んでください。

アベイラビリティマッチングのコストを検討する際は、初期開発と、システム連携や運用ルールの継続的なメンテナンス作業を分けて考えてください。明確になっていないスコープに対して見積もりを出さないようにしましょう。拠点への導入展開には、初期接続の稼働だけでなく、障害や仕様変更に対応する明確な責任者が必要です。

実際に試してみましょう

テストスケジュールから代表的な案件を取り出し、ディスパッチャーの言葉で必須条件を書き出してみます。承認されたテストデータを使用してください。単一の時間枠だけで検証するのではなく前後にある訪問予定も含め、どの割り当てが許可されるべきか、またその理由は何かをクライアントに特定してもらいます。

システム連携の作業にあたっては、UIを構築する前にmatching-slots 技術リファレンスを参照し、ドキュメントに記載されたリクエストとレスポンスを確認してください。パラメータ名を推測したり、マッチング処理によって予約まで確定されると決めつけたりしないようにしましょう。予約確定のステップが別にある場合は、設計上で明確に区別してください。

フィールドオペレーションのクライアント向けにこれを構築する開発会社であれば、納品スコープと合わせてCrisphive パートナープログラムをご確認ください。架空の取引条件を作成したり、テストで実証されていない成果を約束したりすることなく、スケジューリング構築、クライアントの入力責任、およびサポート引き継ぎ体制を定義しましょう。

必須条件を1つだけ変更して同じテストを実行し、候補リストをクライアントの期待する回答と比較します。予約の妨げとなる不一致があれば記録しておきます。ワークフローを顧客向けのアベイラビリティ判定に接続する前に、ディスパッチャーとルールを解決しておきましょう。