service-itsm-agentic-setup-incident-sla-configure

Incident SLA の設定（エンドツーエンド）

ユーザーに質問する前に、最初に行うこと： dispatch_readonly を使用して GET /services/data/v68.0/connect/setup/discovery/features を実行し、IT Service Enablement ゲート（Phase 1a）を読み取ります。apiName が正確に service-cloud-itsm-setup のものに絞り込みます。ステータスが ENABLED になるまでは、ほかのことは何も質問しないでください。

Service Cloud ITSM の完全な Incident SLA パイプラインを設定します。このパイプラインは、Entitlement のあるすべての Incident に、計算済みの TargetDate を持つ EntityMilestone を生成する一連の処理です。すべて、Salesforce がホストする headless-360 MCP サーバー（OAuth JWT の組織を使用）を通じて行います。組織レベルの IT Service Management の有効化（Phase 1a ゲート）、SLA Management for IT Service のセットアップ項目（Phase 1c ゲート）、および Incident Management（Phase 1b ゲート）が必要です。 カスタムパイプライン（順序どおりに実行する4つの書き込み）：MilestoneType（測定対象）→ SLA Policy（SlaProcess、Incident 対象、非アクティブ状態で作成、開始／終了条件）→ Milestone（時間トリガーと条件）→ ポリシーを有効化（createEntitlement=true。Entitlement が自動的にプロビジョニングされ、条件に一致する Incident が EntitlementId を通じて Incident ごとに SLA の対象になります。Account は不要です）。組織全体に適用する自動適用 entitlement 条件は、常に一致させる明示的なリクエストがある場合に限り、オプションの5つ目の書き込みとしてディスパッチします（Phase 4A の手順6）。デフォルトでは実行しません。（事前定義済み／OOB のシード分岐では異なり、手動では何も行いません。単一のシード呼び出しで、ポリシー、マイルストーン、Entitlement を含むアクティブな一式全体を一度にプロビジョニングします。Phase 2／Phase 4B を参照してください。） このスキルは、Incident SLA のすべての対話（ゲート、分岐、マイルストーン戦略、検証）を担当します。実際の書き込み操作は、承認済みの SLA リーフ機能（csp-sun/MilestoneTypes、create-sla-policy、create-milestone、create-milestone-action、activate-sla-policy、create-entitlement-criteria）に委任されます。これらの機能が承認済みの Connect コントラクトを管理するため、ここで形状を再導出するのではなく、それぞれを検出 → 詳細確認 → ディスパッチしてください。 Phase 1c の有効化（+ Versioning）と Phase 4B のシード書き込みは、itsm-shakti/SLASettings（SLA Management の設定画面を管理）に委任します。同じく、検出 → 詳細確認 → ディスパッチしてください。

対象範囲

• 対象範囲内：上記の SLA アーティファクト（MilestoneTypes、SLA Policy とそのマイルストーン、自動プロビジョニングされる Entitlement を伴う有効化、および組織全体に適用する常時一致のリクエストが明示された場合に限るオプションの自動適用条件）と Incident レコードでの SLA 対象状況の検証、SLA Management for IT Service のゲート管理（Phase 1c）、OOB の Standard Support for Incidents ポリシーとカスタムポリシーのどちらを使うかの案内（Phase 2、Incident のみ）。すべて headless-360 MCP を通じて行います。
• 対象範囲外：Case SLA／Entitlement、Assignment Rules、Escalation Rules、Notification Rules、Incident SLA に関係しない一般的な Entitlement の CRUD、SLA レポート。

---

出力規約 — すべてのメッセージに適用

Salesforce レコード ID（15／18 文字：55…、550…、0ny…、00…、Account 001…）を生のまま、またはマスクした状態（557VW…R3XVYA0 でも漏えいします）で、ユーザー向けのテキストに出力しないでください。途中の説明と最終レポートの両方に適用されます。作成した成果物だけでなく、検出して再利用した成果物にも適用されます。各成果物には、作成時に指定した名前、または再利用時に照合した名前を使い、ID は内部に保持してください（連鎖処理にのみ使用）。SOQL で検証または照合する場合は、検証済みの属性／名前を報告し、照会に使った ID は決して出力しないでください。ID の検索も同じ規則に従います。Business Hours（Phase 4A のステップ 1 で解決、ユーザーが選択、または作成されたもの）や既存のポリシーを解決すると {Id, Name} が返されます。解決した名前のみを説明し、返された ID は内部に保持してください。「Resolved "" (001VW…)」のように決して出力しないでください。例外は、停止時に限り、ID が含まれていても生のエラー本文をそのまま返してかまいません。手を加えないでください。

• 誤り： SLA policy created (552VW…) · Incident created (0ny…) · First Response → 557VW…R3XVYA0（再利用）
• 正しい： Created SLA policy "Standard Support for Incidents" · reusing the existing First Response milestone type · テスト Incident は Phase 6 まで「テスト Incident」とし、その後は IncidentNumber を使用します。マイルストーンは MilestoneType の名前で示します。

---

主なルート

読み取り → mcp__headless-360__dispatch_readonly、書き込み → mcp__headless-360__dispatch。どちらも生の HTTP {"url","method","body"?,"query_params"?} を受け取ります（{operation_id, arguments} ではありません）。{status_code, body} から body を読み取ってください。リクエスト／レスポンスの形式を含む完全なルート表は references/mcp-invocation.md を参照してください。

---

確認事項

コンテキストから推測できないことだけを質問してください（事前入力し、「（会話から）」と記載してください）。まず Phase 1a のゲート、次に Phase 1b の Incident Management ゲート、最後に Phase 1c のゲートを、この順番で解決してください。その後、（headless-360 は現在の OAuth セッションに紐づくため、どの組織かは尋ねないでください）マイルストーン戦略はどうしますか？（Phase 3b）、マイルストーンの条件はどうしますか？（デフォルトは Status != Closed とパターン固有のフィルター）。Account については尋ねないでください。Incident には Account フィールドがありません。エンゲージメントは EntitlementId を通じた Incident ごとの設定です。**Business Hours：**ユーザーの選択が曖昧な場合、または組織に存在しない場合（Phase 3a のステップ 4）に限り、質問してください。Predefined の経路では決して尋ねないでください。

デフォルトの提案：SLA Policy は Incident SLA Policy、提案するデフォルトの Business Hours（Phase 3c で確認）、有効化時に Entitlement を自動プロビジョニング（Account なし）、EntitlementId を通じた Incident ごとのエンゲージメント、Phase 3b で解決するマイルストーン戦略。

---

ワークフロー

順次実行 — 必ず読み取りを行ってから書き込みます。すべての呼び出しは mcp__headless-360__* を経由します。 各フェーズの詳細（読み取り、委任する書き込み、API の注意点）は references/workflow.md にあります。実行前に必ず読んでください。 フェーズの一覧と、必ず守るべきゲートは次のとおりです。

• 開始前 — セッション状態の再利用 このセッション内で、この組織に対して成功した dispatch_readonly の結果で、まだ書き込みに使われていないものだけを再利用します。ユーザーの発言はキャッシュの対象になりません。
• フェーズ 1a — IT サービス管理ゲート（service-cloud-itsm-setup）。ステータスが正確に ENABLED なら続行します。ブロック理由がなく、ステータスが正確に NOT_ENABLED の場合は、AskUserQuestion を使って「IT Service Enablement is off — enable it now?」と尋ねます（Yes/No。通常のテキストで尋ねてはいけません。No の場合は停止）。その確認を得てから IncidentMgmt SOR に委任し、続行前にその検証手順を実行します。ステータスが欠落している、エラー、ブロック中、またはそれ以外の場合は停止し、Setup を案内します。
• フェーズ 1b — インシデント管理ゲート（service-cloud-itsm-incident）。ステータスが正確に ENABLED なら続行します。NOT_AVAILABLE の場合は停止します。ブロック理由がなく、ステータスが正確に NOT_ENABLED の場合は、AskUserQuestion を使って「Incident Management is off — enable it now?」と個別に尋ねます（Yes/No）。IncidentMgmt SOR に委任し（Skill ではなく MCP 手順を使用）、ステータスが正確に ENABLED であることを検証します。No の場合は停止します。
• フェーズ 1c — SLA 管理ゲート。 SLA Management と恒久的な SLA Versioning スイッチの両方が対象です（書き込みは 2 回）。itsm-shakti/SLASettings に委任します。最初に両方のフラグを読み取ります。どちらかがオフの場合は、書き込みを行う前に必ず AskUserQuestion で、別々に 2 つの質問をします。Q1「SLA Management for IT Service is off — enable it now?」（Yes/No。SLA Management がオフの場合のみ）。次に Q2 SLA Versioning の永続化に関する確認（Enable / Stop。正確な文言は references/mcp-invocation.md を参照）。質問をまとめたり、回答を得る前に後続手順を案内したりしてはいけません。また、フェーズ 1a/1b での Yes や元の依頼を同意とみなしてはいけません。No の場合は必ず停止します。
• フェーズ 2 — 事前定義かカスタムか（Incident のみ）。まずシード済みポリシーを検出します。分岐の前に実際の Incident.Priority ピックリストを読み取ります（カスタム値がある場合はカスタムを推奨）。優先度マトリックスがオフの場合は警告します（デフォルトのティアのみが適用されます）。営業時間についての注記は、ユーザーが時間を指定した場合のみ行います。事前定義の場合は 4B → 5（依頼があった場合）→ 6 の順に進み、停止します。カスタムの場合は 3a → 3b → 3c → 4A → 5（依頼があった場合）→ 6 の順に進みます。
• フェーズ 3a — 事前確認。 ステップ 1 ではフェーズ 1b のインシデント管理の結果のみを再利用します。その後、SLA 操作を discover/describe し、Incident を describe し、営業時間を解決して、冪等性を確認します。Account は対象外です。401/403/404 の場合は、生のエラーを示して停止します。
• フェーズ 3b — マイルストーン戦略：examples/milestone-patterns.md に従います。
• フェーズ 3c — 確認：書き込みを行う前に、計画全体（営業時間の名称、すべてのマイルストーン）を確認します。
• フェーズ 4A — 作成：計画に含まれる場合は営業時間を最初に作成し（ステップ 1）、続いて MilestoneTypes → create-sla-policy → create-milestone ×N → activate-sla-policy の順に実行します。任意のステップ 6 の条件は、常に一致させるという明示的な依頼がある場合のみ使用します。
• フェーズ 4B — シード：save-selected-options（{"selectedOptions":["incident"]}）を使ってシードします。itsm-shakti/SLASettings に委任し、検証して営業時間に名前を付けます。
• フェーズ 5 — マイルストーンのアクション（依頼があった場合のみ）：名前が付いたすべてのマイルストーンに対して実行します。
• フェーズ 6 — 検証：SOQL と、EntityMilestone を持つ最低ティアではないテスト Incident を使って検証します。マトリックスがオフのまま、または再試行を 1 回行っても順序が 1 のままの場合は停止し、他のティアは未確認であることを報告します。

---

ルール／制約

制約	理由
IT Service Management の有効化（Phase 1a）を確認し、その後、Phase 1c の前にインシデント管理（Phase 1b、独立した Yes/No）を確認します。完全一致する apiNames のみを使い、類似名は使いません。ルールは上記のフェーズ一覧に従います	上位組織のゲートは、すべての ITSM 機能より上位にあります
最初にSLA 管理（Phase 1c）を確認します。2 回に分けて書き込みます（SLA 管理、その後、一方向のSLA バージョニング）。書き込み前に AskUserQuestion を 2 回に分けて実行します（Q1 は SLA 管理の Yes/No、次に Q2 は不可逆性の確認）。統合したり、以前のゲートでの Yes から推測したりしてはいけません。拒否・ブロック・検証失敗の場合は → HALT。実際の状態を再読み込みして報告します	バージョニングは取り消せません。書き込みを行っても状態は確認されません
**事前定義済み（OOB）**を最初に提示します（Phase 2、Incident のみ）。シードの前に検出し、選択された場合はシード → 検証 → 停止（カスタム版へのアップセルなし）	OOB シードは冪等ではなく、再シードすると重複します
変更を行う前に discover と describe を実行します	SLA の対象機能がないことや、Incident Mgmt が無効であることを早期に検出できます
マイルストーン戦略について質問（AskUserQuestion）します。Single を黙ってデフォルトにしてはいけません	実際の ITSM ポリシーには複数のマイルストーンがあるためです
共有名ごとに MilestoneType を 1 つ再利用し、異なる懸念事項ごとに別のものを用意します	実行時には MilestoneType をキーとしてマイルストーンが管理されます
複数マイルストーンの場合、マイルストーン作成に失敗したら中止します（ポリシーを中途半端な状態で関連付けない）	部分的な関連付けは、確認済みの計画と食い違います
優先度階層方式の場合、実行前にすべての Priority 値を実際の選択肢リストと照合します。一致しない標準行は削除または名前を変更し、組織が追加したカスタムの有効値ごとにマイルストーンを追加します	サーバーは任意の文字列を受け付けるため、不明な値は機能しないマイルストーンになります。対応するマイルストーンがないカスタム値には SLA が適用されません
所有するすべての書き込みを委任します。前提機能の有効化は IncidentMgmt SOR に、SLA の書き込みは承認済みの SLA リーフ（MilestoneTypes、create-sla-policy、create-milestone、create-milestone-action、activate-sla-policy、create-entitlement-criteria）に委任します。Phase 4A の手順 1 にある Business Hours の作成は、所有する SOR が提供されていないため、インラインのままにします	1 つの書き込みにつき契約上の所有者を 1 つにします。ここで所有者の契約を再定義すると、提供元の所有者との間に差異が生じます
Business Hours（カスタム）：指定されたスケジュール、説明されたカレンダー、またはタイムゾーンを尊重します（タイムゾーンのみの場合は、24×7（推奨）またはカスタム時間を尋ねます。該当するものがあれば再利用し、なければ Phase 3c の確認後に作成します）。有効なものが 0 件の場合は、24×7 の作成を提示します。IsDefault は設定せず、既存レコードも変更しません。事前定義済みの場合、シーダーは常に組織のデフォルトを使います。ユーザーが時間を指定した場合に限り警告します	デフォルトの 24×7、または顧客独自のカレンダーを使います。BusinessHours は API で削除できないため、作成前に確認します
カスタムフロー：有効化によって自動 Entitlement がプロビジョニングされます（activate-sla-policy：isActive と createEntitlement はクエリパラメーター）。該当する Incident には EntitlementId を介してIncident ごとに適用されます（手動の sObject Entitlement ではなく、Account も使いません）。create-entitlement-criteria による組織全体の自動適用条件は任意です。明示的に常時一致を求められた場合に限り設定し、デフォルトでは設定しません。OOB シードパス：シーダーを 1 回呼び出す（小文字の selectedOptions を使う save-selected-options）ことで、Entitlement を含む有効なバンドル全体がプロビジョニングされます。リーフごとの呼び出しも、手動の POST /sobjects/Entitlement も、activate PATCH も行いません	カスタムの場合、1 回の呼び出しで有効化とプロビジョニングの両方が行われるため、手動の POST /sobjects/Entitlement を実行すると重複します。OOB の場合、プラットフォームのシーダーがサーバー側でデフォルトのバンドル全体を構築して有効化するため、このスキルがリーフごとに再構築したり、手動で Entitlement をプロビジョニングしたりすることはありません
どのメッセージにもレコード Id を含めません（再利用した成果物を含む「出力の契約」を参照）。AskUserQuestion のラベルは顧客向けにします（「デモ」や内部向けのデフォルト値は使いません）	Id の漏えいや内部向けの表現は、顧客に対してプロフェッショナルでない印象を与えます
別の Incident ポリシーがすでに有効で、カスタム版が選択された場合 → 共存について説明するだけにします。カスタムポリシーは EntitlementId を介してIncident ごとに対象を指定し（Incident には対象を絞るための Account フィールドがありません）、追加で適用されます。既存の（事前定義済み／広範な）ポリシーは組織全体のポリシーとして維持されます。フォーク内でも終了レポートでも、既存ポリシーの無効化、Entitlement 条件の並べ替え、カスタムポリシーを全件一致／全件自動適用に拡張すること、またはポリシー間の「優先順位を決定／解決すること」を提示、計画、実行してはいけません。特定の Incident は EntitlementId を介して対象にし、既存のポリシーは有効なままにします（references/workflow.md → Coexistence を参照）	ユーザーが変更を求めていないポリシーの変更は対象外です。このスキルが設定するのは、新たに共存するカスタムポリシーであり、既存ポリシーの編集ではありません。ポリシーの無効化（activate-sla-policy は isActive=false を送信できます）や、別のポリシーの条件順位の変更は、稼働中の SLA を損なうおそれがあります。また、リーフにポリシー間の優先順位を調停する機能はありません（事前定義済みの場合、シードを取り消す方法はなく、手動削除のみです）。どちらも共存させることが意図されているため、そうしなければエージェントが対象外の無効化・並べ替え・優先順位のアップセルを独自に進めてしまいます
追加の API 特有の挙動については、references/mcp-invocation.md を参照してください。

---

検証チェックリスト

• IT Service Management の有効化ゲート（Phase 1a） — 正確な apiName service-cloud-itsm-setup を読み取り、正確な ENABLED を確認します。または、ブロック理由がなく正確な NOT_ENABLED を受け取った場合、IncidentMgmt SOR に委任して Yes／No の有効化確認を 1 回行い、検証ステップで正確な ENABLED が確認されます。辞退、ブロック、欠落、エラー、想定外のステータスの場合は、Phase 1b の前に HALTED になります。
• Incident Management のゲート（Phase 1b） — ライブ読み取りで正確な service-cloud-itsm-incident の ENABLED を確認します。または、NOT_ENABLED の場合、独自の Yes／No 確認を行った後に IncidentMgmt SOR へ委任します（NOT_AVAILABLE の場合は HALT）。検証ステップで ENABLED が確認されます。ユーザーの申告でも、よく似た別の値でもありません。
• SLA Management のゲート（Phase 1c） — SLA Management と SLA Versioning の両方を有効化します（書き込みは 2 回に分けます）。Q1（SLA Management の Yes／No）と、別途確認する Q2 永続性の承認 の後に限り、それぞれ AskUserQuestion で尋ねます。報告する状態は書き込み後の再読み取りで確認し、書き込み結果では確認しません。辞退、ブロック、検証失敗の場合は、Phase 2／3a の前に HALTED となり、成果物は作成されません。
• 事前定義とカスタムの選択肢を提示（Phase 2） — 機能が ON の状態で、標準提供の Standard Support for Incidents を最初に提示します。存在する場合は、再シードされていないことを報告します。選択された場合はシードし、2 つの MilestoneType、6 つのマイルストーン、Entitlement を作成して検証し、その後はカスタムの選択肢を提示しません。
• discover／describe で SLA Connect の ops を確認しました。
• Incident の describe で EntitlementId、SlaStartDate、SlaExitDate を含む 200 が返されました。
• 有効な Business Hours を解決し、確認済みプランで名前を指定しました。ユーザーが指定したスケジュール、一致するカレンダー、組織のデフォルト、ユーザーが選択したレコード、または Phase 3c で確認した作成済みのカレンダー（既存のカレンダーがない場合は 24×7）を使用し、その後 SOQL で有効であることを検証します。事前定義の場合は、シードされたポリシーの Business Hours を名前で報告します（または「なし」）。
• マイルストーン戦略を解決済み — Phase 3b のスキップ条件、または AskUserQuestion を使用します。Priority 階層別／カスタムの場合は、ディスパッチ前に各 Priority／条件の値をライブの選択リストと照合します。一致しない標準行を削除または名前変更し、カスタムの有効な Priority 値ごとにマイルストーンを追加します。
• 設定を確認済み、またはスキップ条件を満たしています（認証が事前に済んでいる／変更なし／事前確認済み／「はい」）。解決済みプラン（組織、SLA 名、名前で指定した Business Hours、エンゲージメントモデル＝EntitlementId による Incident 単位（Account なし）、マイルストーンごとの一覧）を Phase 4A の前に説明しました。
• 書き込みは順序どおりに SLA leaves に委任 しました。4 つのコア書き込みは、MilestoneType(s) → Policy → Milestone(s) → 有効化 + 自動 Entitlement です（組織全体に適用するオプション条件は、明示的に要求された場合に限ります）。マイルストーンの作成に失敗した場合は停止し、一部だけを関連付けることはありません。変更なしの場合は簡略化されます。
• マイルストーンアクション（Phase 5） — 要求された場合は、名前を指定した すべてのマイルストーン に関連付けました。各項目は 201 ではなく、body.success と actionMappings で確認しました。書き込み前に全体を説明しました。
• SLA Policy は作成レスポンスではなく SOQL で検証しました（変更なしの場合、Phase 3a の読み取りが検証になります）。
• テスト用 Incident に、正しい階層の TargetDate を持つ EntityMilestone が 1 つ以上あります（エンゲージメントの証明。Priority 階層別の場合は Priority も一致）。期待されるマイルストーンが存在します。Matrix がオフの場合、または 1 回再試行しても order-1 のままの場合は、「他の階層は確認していない」と報告し、Setup の Priority Matrix 設定を案内します。再作成を繰り返しません。SlaStartDate が設定されていることも確認になりますが、Entitlement が条件によって自動適用された場合は null のことがあり、失敗ではありません。変更なしの場合はスキップします。
• いずれのメッセージにもレコード Id を含めません — 途中の説明にも最終報告にも含めません。成果物は名前で、テスト用 Incident は IncidentNumber で示します（Output contract を参照）。
• 変更前／変更後と概要を提示しました。変更なしの場合は、既存の設定をそのまま記載し、「変更なし」と明記します。

出力形式

examples/output-templates.md のテンプレートを使用し、プレースホルダーはそのまま埋めてください。成功レポートには、曖昧さがないよう、SLA ポリシー、すべてのマイルストーン（MilestoneType 名＋時間＋条件）、エンタイトルメント（自動プロビジョニング、Account なし — Incident には Account フィールドがありません）、リクエストされたすべてのアクション（マイルストーンのティア／MilestoneType 名。マイルストーン Id は使わない）＋Warning／Violation の役割＋オフセット＋確認方法、検証セクション（SOQL で確認したポリシー＋テスト用 Incident の SlaStartDate／EntityMilestones、または正直な部分確認の注記）、成果物ごとの作成済み／再利用、およびスコープ行（Incident SLA のみ）を含めてください。レコード Id は一切記載しないでください。別の Incident ポリシーがすでに有効な場合は、共存関係を明確に述べてください（両方が有効なままになります。既存／定義済みポリシーは組織全体に適用される広範なポリシーのまま、カスタムポリシーは EntitlementId を介して Incident ごとに対象を限定します）。また、既存のポリシーを無効化または並べ替えること、カスタムポリシーをすべての Incident に自動適用するよう範囲を広げること、ポリシー間の「優先順位を決める」ことは提案しないでください。

---

参照ファイルの一覧

ファイル	読むタイミング
references/workflow.md	実行時 — Phase 1〜6 の全手順の詳細（各フェーズの読み取り、委任された書き込み、API の注意点）。制約の表と検証チェックリストは、この SKILL.md 本文に残っています
references/mcp-invocation.md	すべてのフェーズ — 呼び出し形式、テンプレート、レスポンスのエンベロープ、検出、注意点
examples/milestone-patterns.md	Phase 3b — 5 つの戦略：時間、条件、MilestoneType の再利用、フィルターの拡張
assets/attach-milestone.json	Phase 4A のステップ 4 — マイルストーンの POST 本文。id／timeTrigger／order を置き換え、filterItems を追加
assets/attach-milestone-action.json	Phase 5 — Warn／Escalate アクションの本文テンプレート（Field Update）。mcp-invocation.md の（Milestone Actions）と併用
examples/output-templates.md	出力形式 — 成功／部分確認レポートのテンプレート。プレースホルダーを埋め、レコード Id は記載しない

---

関連スキル

優先度マトリクス（Impact × Urgency → Priority）は別の設定であり、ここでは設定しません。 Priority 階層の戦略がリクエストされているものの、Incident.Priority に値がない場合は、まず Setup の Priority Matrix 設定を案内してください。その他の ITSM フロー（Major Incident Mgmt、カスタムフィールド）は対象外です。