field-service-work-rule-designer-configure

Salesforce Field Service – 作業ルールデザイナー

スケジューリングポリシーの作業ルールを設計します。 このスキルでは、構造化されたインタビューを通じて、一度に1つずつ質問しながら作業ルールの設定を収集し、出力として workRules[] ブロックを生成します。Salesforce のレコードは作成しません。完了すると、sfs-service-objective-designer に引き継ぎます。

インタビューのフェーズ： スケジューリングポリシー → 作業ルール（このスキル）→ サービス目標 → レコード作成

---

作業ルール

作業ルールはハードフィルターです。 作業ルールに違反するサービスリソースを除外し、サービス予約の候補リストを絞り込みます。作業ルールはサービス目標よりも常に先に適用され、サービス目標は作業ルールを通過したリソースのみをスコアリングします。要件が「必須」であれば作業ルール、「優先」であればサービス目標です。

16 種類の作業ルール

各行の内容は、名前 — エンジン（DB/Apex）— 機能です。「DB w/ ESO」は、Enhanced Scheduling and Optimization が有効な場合に限りデータベースレベルでルールが実行され、それ以外の場合は Apex として実行されることを意味します。Apex ルールの実行前に候補を約20件に絞り込めるよう、DB ルールを少なくとも1つ含めてください。

作業ルール	エンジン	機能
Service Resource Availability	Apex — 必須	リソースが実際に利用可能であることを確認します。営業時間、移動時間、休憩、不在、既存の割り当てを考慮します。また、キャパシティベースのリソースについては、キャパシティも適用します。休憩、空き時間、残業、出発地から／出発地までの移動を設定できます。
Match Time Rule	Apex	予約の日付／時刻フィールドに基づいてスケジュール可能な時間帯を制限します。標準ルールとして、Earliest Start Permitted と Due Date（どちらも必須）、および Scheduled Start／Scheduled End（到着時間帯に基づく）が付属します。
Match Skills	Apex	予約で必要なスキルと、リソースに割り当てられたスキルを照合します。スキルレベルも適用できます。Skill Type Logic は All Skills Match (AND)（デフォルト）、または At Least One Skill Matches (OR) です（OR には ESO が必要です）。
Match Fields	DB w/ ESO	予約の1つのフィールドをリソースの1つのフィールドと照合します（1対1）。予約の1つのフィールドをリソースの複数の値と比較する場合は、代わりに Extended Match を使用してください。
Match Boolean	DB w/ ESO	リソースのチェックボックス項目が true（または false）であることを必須とします。**ポリシーごとに最大5つです。**標準の「Active Resources」が付属します。
Extended Match	Database	予約のフィールドとリソースの関連リストをジャンクションオブジェクトで結び付け、カスタム条件で照合します（例：対応可能な郵便番号、製品ライン）。
Match Territory	Database	予約のサービステリトリーのプライマリメンバーまたは再配置メンバーであるリソースに制限します。
Working Territories	Database	サービステリトリーのプライマリおよびセカンダリのメンバーシップを適用します。
Maximum Travel from Home	Database	リソースの拠点と、割り当てられた各予約との距離／移動時間に上限を設けます。
Required Resources	DB w/ ESO	必須として指定されたリソースへの割り当てを強制します（WO/WOLI の Resource Preference）。非常に制限が厳しいルールです。
Excluded Resources	DB w/ ESO	WO/WOLI で除外として指定されたリソースへの割り当てを防ぎます。
Count Rule	Apex	リソースごとに、1日あたりの割り当て数、作業時間、またはカスタム値に上限を設けます（例：スケジュール済み作業時間を8時間以下にする、トラックに積載する品目をN個以下にする）。Time Resolution は Daily です。ポリシーごとに、カスタムフィールドに基づくカウントルールを最大10個設定できます。
Work Capacity	Apex — ESO のみ	テリトリーごとの Work Capacity Limit レコードを適用します（例：テリトリーのキャパシティの80％を上限として設置作業を割り当てる）。
Service Appointment Visiting Hours	Apex	顧客の営業時間／訪問可能時間帯（例：平日の午前8時から正午まで）を適用します。全体に適用されるルールであり、関連性グループはありません。
TimeSlot Designated Work	Apex	特定の作業タイプ用に時間枠／シフトを確保します。その時間帯にスケジュールされるのは、その作業タイプのみです。全体に適用されるルールであり、関連性グループはありません。
Service Crew Resources Availability	Apex	クルータイプのリソースは、クルーが親レコードで指定された最小人数を満たす場合にのみ割り当てられるようにします。

要件のマッピング

ルールの一覧から始めるのではなく、まずビジネス上のニーズを確認し、次に各要件を満たすルールに対応付けてください。このマッピングをユーザーに順を追って説明します。

要件が次の場合	この作業ルールを使用
リソースに特定のスキル／習熟度レベルが必要	Match Skills；Extended Match
スキル以外のマッチング要素（例：サービス提供可能な郵便番号）	Match Boolean；Match Skills；Extended Match
日中の休憩／特定または複数の休憩	Service Resource Availability（複数の休憩、ESO の場合は作業ルールのエントリを追加）
残業が可能か。リソースが勤務時間外に移動できるか	Service Resource Availability
リソースごとの1日あたりの予約の最大数／時間	Count Rule
特定のリソースを必ず割り当てる必要がある	Required Resources
特定のリソースを割り当ててはならない	Excluded Resources
顧客に特定のサービス訪問時間帯がある	Service Appointment Visiting Hours
クルータイプのリソースが確実にスケジュールされるようにする	Service Crew Resources Availability
予約に到着時間帯／指定到着時刻がある	Match Time Rule
自宅からの移動距離を制限する／広い地域で移動コストを抑える	Maximum Travel from Home — 上限を距離または移動時間のどちらで設定するか確認してください（下記の注を参照）
1日の一部または全体について、特定の作業タイプをリソースに割り当てる	TimeSlot Designated Work
作業範囲をリソースのプライマリおよびセカンダリサービスエリアへの所属に制限する	Working Territories

必ず Service Resource Availability ルールを1つだけ含めてください。このスキルが出力する必須ルールはこれだけです。Earliest Start Permitted または Due Date は出力しないでください。これらは自動的にプロビジョニングされます。

到着時間帯の Match Time ルール（デフォルトのオプトイン設定ペア）。 顧客の到着時間帯を予約に反映させたいとユーザーが希望する場合は、確認を求めてください。同意した場合は、次のデフォルト設定で Match Time ルールを2つ出力してください。ユーザーに設定を入力させないでください。これらは標準の到着時間帯設定です。

設定	ルール A	ルール B
名前	Arrival Window Start	Arrival Window End
Service Schedule Time Property	SchedStartTime	SchedStartTime
Service Time Operator	Later than or Equal to	Before or Equal to
Service Time Property	ArrivalWindowStartTime	ArrivalWindowEndTime
Pass Empty Values	true	true

それぞれ、上記の4つの値を含む params（キーは serviceScheduleTimeProperty、serviceTimeOperator、serviceTimeProperty、passEmptyValues）を持つ Match Time 作業ルールとして出力してください。これらは必須の Earliest Start Permitted／Due Date ルールとは別のものです（これらは出力しないでください）。

休憩時刻の解釈と出力（時刻指定か、シフト開始からのオフセットか）： Service Resource Availability ルールでは、2種類の形式で休憩を表現します。このスキルが形式を決定し、データレイヤースキルが必要とする値を出力します。データレイヤースキルが変換すべき時刻を受け取ることはありません。次のように形式を選択してください。

• 絶対時刻で定められた毎日の固定休憩が1回（例：「毎日12:00に30分」）→ 絶対時刻の休憩として出力します：{ "mode": "absolute", "startClock": "12:00", "durationMinutes": 30 }。オフセット計算は不要で、勤務日の開始時刻も必要ありません。
• 勤務日の開始時刻からのオフセットで定められた休憩が1回以上（例：「シフト開始から3時間後に始まる30分の昼休憩」）→ それぞれを勤務日の開始時刻からの分単位のオフセット休憩として出力します：{ "mode": "offset", "earliestStartOffsetMinutes": 180, "latestEndOffsetMinutes": 240, "durationMinutes": 30 }。オフセット休憩では、earliestStartOffsetMinutes、latestEndOffsetMinutes、durationMinutesの3つすべてが必須です。ユーザーがすでにオフセットで休憩を指定している場合（例：「1日の開始から3時間後」）、そのオフセットがearliestStartOffsetMinutes（180）です。— 勤務日の開始時刻を尋ねないでください。不要です。
• 時刻で指定された休憩が複数ある場合（例：「10:00に15分、12:00に30分」）→ オフセット形式を使用する必要があります。つまり、それぞれの時刻を勤務日の開始時刻からのオフセットに変換します。日の開始時刻が分からなければ変換できないため、ユーザーにシフト／勤務日の開始時刻を尋ねてから、休憩ごとにearliestStartOffsetMinutes = (休憩開始時刻 − 日の開始時刻)を分単位で計算します。日の開始時刻が午前0時だと決めつけないでください（そうすると「10:00」が誤った600分のオフセットになります）。（日の開始時刻を尋ねるのは、この時刻指定の場合だけです。休憩がすでにオフセットで表現されている場合は尋ねないでください。）

すべてのオフセット休憩で、必ずlatestEndOffsetMinutesを出力してください。ウィンドウを捏造せず、ユーザーに直接尋ねてください。最も早い開始時刻はユーザーの指定（オフセット、または時刻から変換した値）から決めます。— その前後に許容範囲を勝手に設定しないでください（「±1時間」／「±2時間」の選択肢など）。ユーザーが休憩の開始時刻だけ（または終了期限を指定せずに休憩時間だけ）を示した場合、休憩が終了してよい最も遅い時刻を、ユーザーが使った同じ表現で明確に尋ねてください。オフセットが示された場合（「1日の開始から3時間後に開始」など）は、「1日の開始から何時間後までに終了してよいですか？」と尋ねて変換します（例：「開始から4時間後」→ 240）。時刻で示された場合は時刻を尋ね、日の開始時刻を使って変換します。ユーザーが休憩は固定で、時間の融通が利かないと言った場合は、latestEndOffsetMinutes = earliestStartOffsetMinutes + durationMinutesを設定します。3つのフィールドのいずれかが欠けたオフセット休憩は出力せず、終了期限を推測しないでください。休憩の要件を確実に変換するには複雑すぎる場合は、推測せずに確認の質問をするか、手動での方法を提案してください。

自宅からの最大移動 — 単位ではなく上限の種類を確認します。 要件でリソースが自宅から移動できる距離に上限がある場合、上限が距離によるものか、移動時間によるものかをユーザーに尋ねてください。この2種類は設定方法が異なり、データレイヤースキルでどちらかを把握する必要があります。paramsには値と種類を出力します：{ "maxTravelFromHome": 50, "maxTravelFromHomeType": "Distance" | "Travel Time" }。ユーザーの表現から種類を設定します。「50マイル」／「50 km」⇒ Distance、「45分」⇒ Travel Timeです。ただし、距離の単位（マイルかkmか）は尋ねたり出力したりしないでください。業務ルール設定には含まれません。単位は組織のロケール／距離設定で別途管理されるため、ルールに保存するのは数値のみです。Travel Timeの場合、値は分単位です。上限の値だけを出力しないでください。

ルールごとの設定

要件のマッピングで作成するルールが選択されたら、それぞれの詳細を設定します。Emit行にparamsの正確なキーが示されています。データレイヤースキルがマッピングできるよう、そのまま使用してください。ユーザーが選択したルールだけを設定し、それ以外はスキップします。

---

サービスリソースの稼働状況 (常に含まれます) 条件：常に含まれます。選択は不要です。 質問：

• 「残業が発生する場合はありますか？」（はい／いいえ）
• 「リソースは勤務時間外に自宅から／自宅まで移動できますか？」— はいの場合、自宅から最初の作業場所まで、および最後の作業場所から自宅までにかかる分数を尋ねます。「制限なし」＝120、「いいえ」＝どちらも0
• 休憩時間の聞き取り（休憩時間の解釈と出力を参照）

出力：{ "enableOvertime": true|false, "travelFromHomeMinutes": <number>, "travelToHomeMinutes": <number>, "breaks": [ … ] } 注：移動の値は分単位です。0＝勤務時間外の移動なし、120＝実質的に無制限です。ユーザーから稼働状況の詳細が提示されない場合は、基本値を出力します（enableOvertime: false。移動関連キーと休憩は省略）。

---

時間ルールの照合 (到着時間帯) 条件：要件マッピングで選択されている場合のみ。 質問：「予約では、お客様の到着時間帯を遵守する必要がありますか？」 出力：到着時間帯の表にあるデフォルトルールを2つ出力します。追加の質問はありません。

---

スキルの照合 条件：要件マッピングで選択されている場合のみ。 質問：「リソースには最低スキルレベル（習熟度）も求めますか。それとも、単にスキルを持っているだけで十分ですか？」 出力：{ "matchSkillLevel": true|false } 注：スキルタイプの AND／OR ロジックについては尋ねないでください。このスキルでは skillTypeLogic を設定しません。

---

フィールドの照合 条件：要件マッピングで選択されている場合のみ。 質問：「どのサービス予約フィールドを、どのサービスリソースフィールドと、どの演算子で照合する必要がありますか？」 出力：{ "serviceProperty": "<SA field>", "resourceProperty": "<resource field>", "booleanOperator": "=" } 注：演算子は =, >=, <=, >, < のいずれかです（デフォルトは =）。フィールド名はお客様が指定したものをそのまま使用します。

---

ブール値の照合 条件：要件マッピングで選択されている場合のみ。 質問：「リソース上のどのチェックボックスフィールドを true（または false）にする必要がありますか？」 出力：{ "resourceProperty": "<resource field>", "value": true|false } 注：「ブール値の照合」ルールは最大5つまでです。

---

自宅からの最大移動距離 条件：要件マッピングで選択されている場合のみ。 質問：「上限は距離ですか、それとも移動時間ですか？」（要件マッピングの上限タイプに関する注記を参照） 出力：{ "maxTravelFromHome": <number>, "maxTravelFromHomeType": "Distance"|"Travel Time" } 注：距離の単位（マイルとキロメートル）はルールに含まれません。組織のロケールによって決まります。移動時間の場合、値は分単位です。

---

作業地域 条件：要件マッピングで選択されている場合のみ。 質問：なし。ルールを選択するだけで十分です。 出力：{ "workingLocationEnablePrimary": true } 注：「地域の照合」に関する別個の質問はありません。聞き取りでは「地域の照合」単独のルールは出力されません。プライマリ地域／移転のみの対象範囲が必要な場合は、手動で設定するよう案内してください。

---

サービスクルーリソースの稼働状況 条件：要件マッピングで選択されている場合のみ。 質問：

• 「クルーのレコードだけでなく、個々のクルーメンバーの稼働状況とスキルもルールで評価しますか？」→ considerCrewMembership
• 「基本のクルーに追加できるリソースの最大数はいくつですか？」→ maxAdditionalResources（任意）

出力：{ "considerCrewMembership": true|false, "maxAdditionalResources": <number> }（未入力の場合は maxAdditionalResources を省略）

---

拡張照合 (アドバイスのみ — データレイヤースキルでは構築しません) 条件：要件マッピングで選択されている場合のみ。 質問：なし。収集するパラメーターはありません。 デプロイ前に次の設定を行うようユーザーに案内してください：

1. 正確に2つの主従関係（サービスリソースと照合対象オブジェクトへの関係）を持つジャンクションオブジェクト — パッケージ済みのトリガーでは正確に2つ必要です。それ以外の場合、ルールは失敗します
2. 照合を行うサービス予約の参照項目と、それと照合するジャンクションオブジェクト上の参照項目
3. これらを作成した後、Setup（Field Service Settings → Scheduling → Work Rules）でルールを手動で作成、設定する

対象のオブジェクト／フィールドをアドバイス文として prerequisites に記録してください。workRules[] には出力しないでください。 Count Rule ゲート：要件マッピングで選択されている場合にのみ適用します。 確認：ユーザーに制限を平易な言葉で説明してもらい、次のいずれかに分類します。

• countBy — "Appointments"（ジョブ数）、"Hours"（時間の上限）、または "Custom"（カスタム SA フィールドの合計）
• maxValue — 数値の上限（Hours の場合は時間に換算します）
• fieldHint — 合計する SA フィールド。通常の Appointments 数の場合は null です

出力：{ "countBy": "Appointments"|"Hours"|"Custom", "maxValue": <number>, "fieldHint": "<SA field>"|null } 注：時間解像度は常に Daily で、カウント対象は常に Service Appointment です。データレイヤーのスキルによって、両方が自動的に設定されます。ポリシーごとにカスタムフィールドのカウントルールを最大10個設定できます。countBy が Custom の場合、またはフィールドを対象とする Hours の場合、前提条件に「Service Appointment にフィールド <fieldHint> が存在することを確認してください。」を追加します。

---

選択のみのルール (設定フィールドはありません。各ルールはオン／オフのスイッチとして機能し、組織内の別の場所で定義された制約をスケジューラーに適用させます。要件マッピングで選択し、追加の質問は不要です)

必須リソース／除外リソース ゲート：要件マッピングで選択されている場合にのみ適用します。 出力：{} 前提条件：作業指示／WOLI にリソース設定レコードが存在する必要があります。このルールはそれらを適用しますが、作成はしません。

作業容量 (ESO のみ) ゲート：要件マッピングで選択されている場合にのみ適用します。 出力：{} 前提条件：WorkCapacityLimit レコードを、ポリシーの外部でテリトリーごとに設定する必要があります。

サービスアポイントメントの訪問時間 ゲート：要件マッピングで選択されている場合にのみ適用します。 出力：{} 注：時間帯について質問しないでください。これらはポリシー全体の値ではなく、OperatingHours レコードにあるアカウントごとのデータです。（関連性グループによるスコープ設定はありません。） 前提条件：各アカウントに訪問時間／営業時間が設定されている必要があります。また、作業指示の訪問時間がアカウントから解決される必要があります。

TimeSlot Designated Work ゲート：要件マッピングで選択されている場合にのみ適用します。 出力：{} 注：スロットと作業のマッピングについて質問しないでください。これはデータ設定です。選択肢は「Work Type」ではなく「作業の種類」と表現してください（指定の範囲は Work Type オブジェクトより広いためです）。（関連性グループによるスコープ設定はありません。） 前提条件：意図した作業を指定するよう、時間枠を設定する必要があります。

---

関連性グループ

関連性グループは、単一の作業ルールまたはサービス目標の適用対象を特定のアポイントメントまたはリソースに限定し、ポリシー全体には適用されないようにします。これにより、1つのポリシーで作業やリソースの種類ごとに異なるロジックを適用できます。たとえば、パートタイム従業員とフルタイム従業員で休憩や移動の上限を変えたり、価値の高いアカウントのスケジュールを優先したりできます。

仕組みと役割分担

関連性グループは、Boolean（true／false）フィールドによって機能します。Service Appointment オブジェクトと Service Territory Member オブジェクトにある標準またはカスタムの Boolean フィールドはすべて、ルール／目標の「Relevance Group」ドロップダウンから選択できます。作業ルールまたは目標では、対象を限定する Boolean フィールドを選びます。すると、そのフィールドが true のレコードにのみルール／目標が適用されます。基準は、Boolean フィールドを配置できる2つのオブジェクトです。

• Service Appointment 基準 — 評価対象の予約によって範囲を限定します（例：関連するアカウントのランクが Platinum の場合に true となる数式チェックボックス「Platinum Account」）。予約タイプを対象とする場合に使用します。
• Service Territory Member 基準 — 評価対象リソースのサービス区域メンバーによって範囲を限定します（例：「Part-Time」／「Full-Time」チェックボックス）。リソースのグループを対象とする場合に使用します。サポートされるのはプライマリおよび移転メンバーシップのみで、セカンダリメンバーシップはサポートされません。

設計では、基準（Service Appointment または Service Territory Member）と、対象サブセットを識別する Boolean フィールド名を決め、両方をビルド仕様のルール／目標に記録します（relevanceGroup: { basis, booleanField }）。このスキルが決めるのは、どのフィールドでどのルール／目標の範囲を限定するかだけです。レコードにグループを設定する作業は、データレイヤースキルの担当です。

Boolean フィールド自体は、ユーザーが用意する必要があります。この2つのスキルのいずれも作成しません。フィールドの作成はスキーマ変更（DDL）であり、レコードの true／false 値の設定にはフロー、数式、トリガー、またはデータロードが必要です。そのため、デプロイ前にユーザーへ次の対応を案内してください。（1）サブセットごとに、適切なオブジェクトにカスタム Boolean フィールドを1つ作成する（リソースのサブセットには Service Territory Member、作業のサブセットには Service Appointment）。（2）そのサブセットに含まれるレコードのみで true となるように設定する（フロー／数式／インポートを使用）。ルールの種類で必要な場合は、サブセットが相互に重複しないようにします。その後、ビルド仕様でフィールド名を参照し、データレイヤースキルが関連性グループとして設定できるようにします。

例（基本パターン）

Match Boolean ルール（または範囲を限定するその他のルール）を特定の予約タイプにのみ適用するには、Service Appointment に、その予約で true となる Boolean フィールドを特定するか、ユーザーに作成してもらい、ビルド仕様でルールの関連性グループとしてその名前を指定します。これにより、フィールドが true の予約にのみルールが適用されます。同じパターンを Service Territory Member の Boolean（例：Part-Time と Full-Time）に使うと、「Maximum Travel from Home」ルールを異なる上限で2つ作成できます。一方はパートタイムのリソース、もう一方はフルタイムのリソースを対象にします。

目標の場合、よくある例は ASAP と関連性グループを組み合わせることです。予約に数式チェックボックス「Platinum Account」を設定し、それを対象とする「Expedite Platinum Accounts」という名前の ASAP 目標を高い重みで設定します。これにより、より多くの移動を許容しながら、プラチナ案件をより早くスケジュールできます。範囲を限定した優先度の高い目標には、明確に高い重みを設定してください。そうしないと、ASAP のペナルティを理由に、エンジンがその予約自体をスケジュールしないことを選ぶ場合があります。

ルールまたは目標を一部のみに適用する方法（一般ルール）

これは、休憩や稼働状況だけでなく、すべての作業ルールおよびすべてのサービス目標に適用されます。ポリシー全体ではなく、特定のリソースまたは特定の作業だけにルールや目標を適用するよう求められた場合は、関連性グループを使います。このような意図を示す表現に注意し、必ず関連性グループを使用してください。

• 「特定の種類のリソースに適用」（例：「フランスのリソース」「パートタイムの技術者」「シニアエンジニア」「設置作業チーム」）→ Service Territory Member の関連性グループを作成します。Service Territory Member 上に、該当するリソースだけが true になる Boolean フィールドを作成し、そのルール／目標の関連性グループとして選択します。
• 「特定の種類の作業に適用」（例：「設置作業」「プラチナアカウントのアポイントメント」「緊急作業指示」「2 時間を超えるジョブ」）→ Service Appointment の関連性グループを作成します。Service Appointment 上に、該当するアポイントメントだけが true になる Boolean フィールドを作成し、そのルール／目標の関連性グループとして選択します。

必要な基準が該当するルール／目標でサポートされているか、必ず確認してください。Service Territory Member による絞り込みに対応していないルール／目標もあれば、Service Appointment による絞り込みに対応していないものもあります。関連性グループを提案する前に、そのルールまたは目標に関する関連性グループのサポートマトリックスを確認し、Enhanced Scheduling & Optimization（ES&O）のサポートだけを考慮して、従来型／非 Enhanced の列は無視してください。ES&O でそのルール／目標に必要な基準がサポートされていない場合は、その旨を伝え、架空の方法を作り出すのではなく、最も近いサポート対象の代替案を提案してください。

同じルール／目標について、異なる設定が必要なサブセットが 2 つある場合は、サブセットごとに 1 つのインスタンスを設計してください。統合したインスタンスを 1 つだけ作成してはいけません。1 つのルール／目標インスタンスは、対象となるすべてのレコードに適用されるため、「フランスはパターン A、それ以外はパターン B」という指定を 1 つのインスタンスで表現することはできません。代わりに、サブセットごとに 1 つずつインスタンスを指定し、それぞれ固有の Boolean フィールドで絞り込みます。また、グループ同士が重複しないようにしてください（Service Resource Availability のように対象が 1 つに限られるルールタイプでは、重複するとエラーになります。主なルールと注意点 を参照してください）。例：「フランスのリソースには午前 10 時に 15 分の休憩と、12 時から 2 時の間に昼休憩を設定し、それ以外のリソースには 12 時から 3 時の間に 30 分の休憩を設定する」場合は、Service Resource Availability ルールを 2 つ作成します。「Availability – France」は Break_Group_France__c という STM チェックボックスで絞り込み、「Availability – Standard」は Break_Group_Standard__c という STM チェックボックスで絞り込みます。それぞれのグループに属する休憩のみを設定し、すべてのリソースが必ずどちらか一方だけのグループに属するようにします。

シナリオが実際に複雑すぎる場合は、手動での設計を提案してください。複数のサブセット、曖昧な値、まだ存在しない関連性グループのフィールドが組み合わさっている場合は、仕様に単一の統合インスタンスを無理に含めないでください。上記の関連性グループ設計をユーザーに説明し、内容を調整してもらうか、曖昧でない部分だけを仕様化してください。もっともらしく見えても誤った統合ルール／目標を出力するのではなく、確認を促してください（どのサブセットか、リソースと作業のどちらか、それぞれを識別する Boolean フィールドは何か、そのルール／目標について ES&O でその基準がサポートされているか、など）。

主なルールと注意点

• 関連性グループは相互に排他的である必要があります。 関連性グループが重複する2つのルールがある場合、より制限の厳しいルールが優先されます。また、Service Resource Availability では、重複するとエラーが発生します。各リソースは、Service Resource Availability ルール1つだけでカバーする必要があります。
• 加算型のルールタイプ — 複数回指定でき、同じリソースや予定を正当に対象にできます：Count Rule、Extended Match、Match Boolean、Match Fields、Match Time。
• 単一カバレッジのルールタイプ — リソースや予定は、一度に最大1つのインスタンスだけでカバーする必要があります：Match Skills、Match Territory、Maximum Travel from Home、Required Resources、Service Crew Resource Availability、Service Resource Availability、Working Territories。（また、Match Territory と Working Territories の両方で同じリソースをカバーしないでください。）
• 全か無かのルール — 関連性グループは使用できません： TimeSlot Designated Work と Service Appointment Visiting Hours。また、Work Capacity は関連性グループをサポートしていません。
• 目的も関連性グループを指定して繰り返し設定できますが、同じタイプの2つの目的の条件を同時に満たすレコードがあってはいけません。ただし Resource Priority は例外です。各インスタンスが異なるリソース優先度フィールド（例：「Primary Priority」と「Secondary Priority」／「Tenure」）を参照する場合、同じ予定に対して正当に2回適用できます。
• ルールや目的を予定単位とテリトリーメンバー単位のどちらでスコープできるかは、Enhanced エンジンと非 Enhanced エンジンで異なります。スコープを設定する際は、対応表を確認してください。Group Nearby と Same Site の目的は、関連性グループを一切サポートしていません。

---

出力

すべてのルールを確認したら、workRules[] ブロックを出力し、平易な英語で要約を示します。要約には、ルール名、絞り込む対象、主なパラメーターを含めます。委任する前に、ユーザーに確認を求めてください。

次のステップに引き継ぐ workRules[] ブロック：

{
  "workRules": [
    {
      "type": "<rule type>",
      "name": "<policy name> - <rule label>",
      "mandatory": true | false,
      "params": { ... },
      "relevanceGroup": { "basis": "ServiceAppointment" | "ServiceTerritoryMember", "booleanField": "<field API name>" } | null
    }
  ],
  "prerequisites": [ "<advisory text for items the user must set up manually>" ]
}

---

引き継ぎ

ユーザーが作業ルールを確認したら、sfs-service-objective-designer に委任します。policy ブロックと workRules[] ブロックの両方をコンテキストとして渡してください。目的の設計者は、選択されたルールに基づいて関連する目的を提示します（例：Match Skills を選択した場合は、Skill Level と Skill Preference の目的を提案します）。

ここでサービス目的のヒアリングを開始しないでください。次のメッセージで移行してください：

"作業ルールが確定しました。次はサービス目的です。対象候補を順位付けする評価基準です。トレードオフに関する質問を1つずつ進めます。"