service-itsm-agentic-setup-agentforce-coordinate

ITSM 向け Agentforce セットアップオーケストレーター

利用可能な機能を提示し、専門の子スキルに作業を委任して進捗を追跡することで、Salesforce Service Cloud ITSM における Agentforce Studio、IT Service Fulfiller エージェント、IT Service Employee エージェント、専門の従業員エージェント、および従業員エージェントから人間へのエスカレーションのセットアップをユーザーに案内します。

目標

ITSM における Agentforce 機能の設定を調整する役割を担います。設定可能な機能のメニューをユーザーに提示し、選択された機能に応じて適切な子スキルを呼び出します。各機能の設定が完了したら、ユーザーが完了するまで、進捗を更新したメニューに戻ります。

動作

1. 会話からコンテキストを抽出する

選択肢を提示する前に、チャット履歴を確認して以下を把握します。

• ユーザーがすでに設定した機能（スキップするか、完了済みとして表示します）
• ユーザーが述べた希望や制約（例：「Agentforce Studio だけを有効にする」「Studio はすでに有効になっています」）
• 対象の組織（言及されている場合）
• どの機能が適切かを判断するためのビジネスコンテキスト

2. 対象の組織を確認する

Agentforce のセットアップでは、実際の組織に対して変更が行われます（機能の有効化、エージェントの作成と有効化）。子スキルに作業を委任する前に、対象の組織をユーザーに確認し、その組織に変更を加えることを明確に伝えます。本番環境を安全に変更できると決めつけず、対象の組織について明示的な確認を求めます。

3. Agentforce の機能メニューを複数選択式で提示する

利用可能な機能と完了済みの機能を、順序に沿った2つのセットアップ段階に分けてユーザーに提示します — ステージ1：プラットフォーム機能を有効化する（Agentforce Studio の有効化）と、ステージ2：エージェントテンプレートをインストールして有効化する（Fulfiller エージェントと Employee エージェント）です。この分離は重要です。ステージ1では組織レベルのプラットフォーム設定／環境設定を有効化し、ステージ2ではテンプレートからエージェントをインストールして有効化します。これらは異なる種類のアクションであり、区別のない1つのリストではなく、明確に異なる段階として示す必要があります。メニューに表示するのは、子スキルが機能する機能のみです。examples/output-templates.md の Feature menu テンプレートを使用してください。ユーザーの選択は1回の複数選択プロンプトで収集します（ツールが利用可能な場合は multiSelect: true を指定して AskUserQuestion を使用し、そうでない場合は 1, 2 のような番号のリストで返信するようユーザーに求めます）。複数選択肢のラベルには、Feature menu の表の項目名を完全に同じ表記で使用してください。各項目の括弧書きと「Agent」という語およびその大文字小文字も含め、変更してはいけません（Agentforce Studio enablement (Foundation for all agents)、IT Service Fulfiller Agent、IT Service Employee Agent、Specialized Agents for Employee、Employee Agent escalation）。これにより、選択肢と表の項目が食い違わないようにします。各項目のDescription 列は、Salesforce Setup → Agentforce for IT Service ページの文言と一致させます（Fulfiller および Employee のエージェントテンプレートの説明と、Specialized Agents for Employee のテキストは一字一句そのまま使用します）。インストールするテンプレートを検討するユーザーが、ここでも Setup でも同じ目的と範囲を確認できるようにするためです。製品説明を言い換えたり、短縮したりしてはいけません。ステージ2の3つのエージェント項目では、製品説明の直後に、インストール時の動作を記した短い Setup: 行を付けます（Fulfiller および Employee エージェントには Setup: creates the agent from this template and activates a version.、Specialized Agents for Employee には Setup: pick one specialized template (e.g. Password Manager, Onboarding), then create and activate that standalone agent. Re-run this item to add more. を使用します。Specialized Agents for Employee では、まずユーザーに希望する特化テンプレートを確認し、その名前を子スキルに渡します）。これにより、1つの行に目的、範囲、インストール時の動作をまとめて示せます。ステージ1の項目（Agentforce Studio enablement）はテンプレートのインストールではなく、プラットフォームを有効化するトグルなので、Setup: 行は付けません。AskUserQuestion を表示する際は、同じ Description の文言（製品説明＋Setup: 行）を各選択肢の description フィールドに設定し、選択画面でも詳細を確認できるようにします。実行できないプレースホルダー機能は表示しないでください。

レポートファイル（ハーネス／非対話型の実行）。 ${outputDir} が指定されている場合（ハーネスの生成ファイル保存先ディレクティブによる指定）、AskUserQuestion を表示する前に、メニューの内容（帰属情報のヘッダー＋ステータス付きの機能表＋委譲先＋依存関係の表示＋複数選択プロンプトそのもの）を ${outputDir}/report.md に書き込んでください。これにより、ハーネスが確認待ちのゲートで停止した場合でもレポートファイルが必ず存在します。各機能の処理完了後には、ステータスを更新した表で同じファイルを上書きしてください。チャット画面でユーザーと対話的に実行する場合は、これらの書き込みを省略してください。${outputDir} が明示的な出力先として渡された場合に限り、書き込みを行います。

4. 依存関係の順序に従って子スキルに委譲する

Studio 優先ルール (無条件)。 Agentforce Studio の有効化 (#1) がユーザーの選択に含まれていて、まだ実行されていない場合は、ユーザーが番号を並べた順序に関係なく、常に最初に実行します。Fulfiller Agent (#2)、Employee Agent (#3)、および Specialized Agents for Employee (#4) はすべて Studio が有効化されていることに依存しており、先に試みると失敗します。Studio がどのエージェントよりも先に実行されるように、キューを黙って並べ替えます。このルールは交渉の余地がなく、ユーザーが 2 つの機能 (Studio + 1 つのエージェント) を選択した場合でも、すべてを選択した場合でも適用されます。Employee Agent escalation (#5) はセットアップ後のアクションであり、これも Studio より先に実行されることはありません。

ユーザー順序ルール (#2、#3、#4 のみの間)。 Fulfiller Agent (#2)、Employee Agent (#3)、および Specialized Agents for Employee (#4) は互いに独立しており、いずれも他方に依存しません。複数が選択されている場合は、ユーザーが並べた順序で実行します (指定がない場合のデフォルトは 2 → 3 → 4)。このルールは #2、#3、#4 の間の順序付けのみ に適用され、上記の Studio 優先ルールを上書きすることは決してありません。

Employee 後の escalation ルール (#5 は #3 に依存)。 Employee Agent escalation (#5) は Employee エージェントの有人へのハンドオフを構成するため、まず Employee Agent (#3) が存在し、Active であること が必要です。#5 が選択されている場合は、委任する前に #3 がこの実行で正常に完了している (またはすでに完了している) ことを確認してください。そうでない場合は、#5 より前に #3 をキューに入れます。#5 も Studio (#1) より先に実行されることはありません。

作成後のランタイムアクセスルール (無条件)。 このセッションで Stage 2 エージェント (#2、#3、#4) のいずれかがライブの判定 (CREATED/ALREADY-CREATED/ACTIVATED) を返した場合は常に、キューの 最後 に自動の Stage 3 ランタイムアクセス ステップを追加します — これは Studio 優先の事前要件を反映した事後要件です: 常に追加され、メニューから選択されることは決してありません — そして最後の Stage 2 エージェントの後に 一度 service-itsm-agentic-setup-agent-runtime-access-assign に委任し、新たにライブになったすべてのエージェントを対象とします (付与はそれ自体の target-user + confirm-to-write ゲートによって管理されます。Stage 3 が保証するのは オファー であり、サイレントな付与では決してありません)。これは交渉の余地がありません。ライブのエージェントのアクションは、これが設定されるまで、ユーザー権限の欠如により失敗します。Studio のみが実行された場合、またはどのエージェントもライブにならなかった場合 (FAILED/PARTIAL/PENDING CONFIRMATION/DECLINED、あるいはキューを停止した Stage 2 の検証) は、追加しないでください。ナレーション + ステータスマッピング: examples/output-templates.md の Runtime access hand-off。

#	機能	ステージ	子スキル
1	Agentforce Studio の有効化 (すべてのエージェントの基盤)	1	service-itsm-agentic-setup-agentforce-studio-configure
2	IT Service Fulfiller Agent	2	service-itsm-agentic-setup-fulfiller-agent-configure
3	IT Service Employee Agent	2	service-itsm-agentic-setup-employee-agent-configure
4	Specialized Agents for Employee	2	service-itsm-agentic-setup-employee-agent-configure
5	Employee Agent escalation	Post	service-agentforce-human-escalation-configure (IT シナリオの入力を渡します: agent IT_Service_Employee_Agent、queue General_IT_Queue、CONTEXT_OBJECT=MessagingSession)
—	ランタイムアクセス (Stage 2 の作成/有効化の後に自動。ユーザーが選択するものではありません)	3	service-itsm-agentic-setup-agent-runtime-access-assign
IT Service Employee Agent と Employee 向けの Specialized Agents。 どちらも同じ子スキル service-itsm-agentic-setup-employee-agent-configure に委任します。違いは、インストールするテンプレートです。IT Service Employee Agent は、幅広く、すぐに利用できる従業員エージェントをインストールします（特化先が指定されていない場合に子スキルが使用するデフォルト）。Employee 向けの Specialized Agents は、代わりに特化型のものをインストールします。ただし、子スキルが特化型のパスを選ぶのは、特化型テンプレート名を指定された場合だけです。何も指定しないと、子スキルは何も通知せず幅広いエージェントにフォールバックし、IT Service Employee Agent を再作成します。そのため、Employee 向けの Specialized Agents に委任する前に、ユーザーがどの特化型従業員エージェントを希望するかを尋ねてください。一般的な例（Password Manager、Certificate Management、Onboarding、Hardware Request）を提示し、ほかにも選択肢があることを伝え、不完全または曖昧な名前は子スキルに確認させてください。その後、名前を指定した特化先とともに委任します（選択したテンプレートによってエージェントが決まります）。名前を指定した特化先なしに、Employee 向けの Specialized Agents に委任してはいけません。この場合に限り、重複した幅広いエージェントが作成されます。特化型テンプレート自体は Stage 1 で有効化されます。この項目では、そのうちの 1 つを使ってエージェントを構築し、有効化します。

service-itsm-agentic-setup-agentforce-studio-configure は、service-itsm-agentic-setup-agentforce-studio-validate に委任する代わりに、独自の読み取りと分類による事前チェック（書き込み前に現在のトグル状態を読み取る）を実行します。このスキルは、書き込みを行わずに準備状況を確認するためにユーザーが直接呼び出せる、別個の読み取り専用エントリーポイントです。このオーケストレーターは、上記の委任フローの一部としてこれを呼び出す必要はありません。

5. 各機能の完了後

子スキルが完了したら、次の手順を実行します。

1. 検証 — node "<skill_dir>/scripts/verify-child-verdict.mjs" <studio|fulfiller|employee|escalation|runtime> <verdict> を実行して、子スキル独自の決定的な判定結果を検証します。文章で成功／失敗の比較を再導出してはいけません。<verdict> には、classify-final-report.mjs の Studio の overall フィールド、Fulfiller／Employee Agent の Phase 8 の集約判定、エスカレーションのリーフの status（CONFIGURED／ALREADY-CONFIGURED）、またはランタイムアクセススキルの Phase 7 の集約判定を渡します。終了コード 0 は次へ進むことを意味し、終了コード 1 は停止し、失敗を平易な言葉で伝えることを意味します。キュー内の次の機能に進んではいけません。 部分的にしか有効化されていない Studio（例：親の包括的な機能がまだブロックされているのに Einstein GenAI は有効で、overall: PARTIAL）では Fulfiller／Employee Agent の作成も失敗するため、このスクリプトは次への進行判定において PARTIAL を FAILED と同じように扱います。
2. ステータスを更新 — 完了した機能を「Done」としてマークします。
3. 次の論理的なステップを提案 — 別の機能が利用可能な場合は、依存関係の順序に基づいて推奨します。
4. メニューを再提示 — ステータスを更新し、examples/output-templates.md の Post-feature progress テンプレートを使用します。
5. Stage 2 のキューが空になった後の Stage 3。 Stage 2 のエージェントがキューに残っておらず、このセッション中に少なくとも 1 つが稼働状態になったら、追加された Stage 3 を一度だけ（上記のルールに従って）委任し、verify-child-verdict.mjs runtime <verdict> で検証します。終了コード 0 ⇒ Stage 3 Done → 完了サマリー、終了コード 1 ⇒ 停止し、平易な言葉で伝えます。

6. 完了サマリー

ユーザーが完了したと伝えたとき（または利用可能な機能がすべて設定されたとき）は、examples/output-templates.md の Completion summary テンプレートを使用して最終サマリーを提示します。

---

セットアップの段階と推奨順序

セットアップは2 つの連続した段階で実行され、その後にオプションのセットアップ後エスカレーションが続きます。ステージ 1 （プラットフォーム機能の有効化）は、ステージ 2（エージェントテンプレートのインストールと有効化）より先に完了する必要があります。 エスカレーションは、従業員エージェントが有効になった後にのみ実行されます。

Stage 1 — Foundation: enable platform features
  1. Agentforce Studio enablement (Foundation for all agents)   (turn ON org-level Agentforce + Einstein GenAI feature toggles)

Stage 2 — Agent templates: install & activate   (only after Stage 1)
  2. IT Service Fulfiller Agent          (install from template, commit, and activate the agent)
  3. IT Service Employee Agent           (install the broad employee agent from its template and activate it)
  4. Specialized Agents for Employee     (install a specialized employee agent — user picks the template — and activate it)

Stage 3 — Runtime access   (AUTO — after any Stage 2 agent goes live, not a menu pick)
  •  Grant the live agent(s)' runtime feature permissions + an Agent Access permission set

Post-setup — Human escalation   (only after item 3 is active)
  5. Employee Agent escalation           (configure canEscalate, outbound routing, a staffed General IT queue, and failure-threshold directives)

ステージ 1（Agentforce Studio の有効化）は基盤です。すべてのエージェント（および専用の従業員テンプレート）が基盤とする、組織レベルの Agentforce と Einstein GenAI の切り替えを有効にするため、最初に有効化してください。これを行う前にエージェントのインストールや有効化を試みると、失敗します。3 つのステージ 2 項目は相互に独立しているため、ステージ 1 の完了後であれば、自由な順序で実行できます。また、従業員向け専用エージェントは、IT Service Employee Agent の直後に配置されています。どちらも同じ子スキルから従業員エージェントを構築するためです（幅広く対応するデフォルトのものと、ユーザーが選択する専用テンプレート）。従業員エージェントのエスカレーション（稼働中の従業員エージェントに対するセットアップ後の操作）とステージ 3（ランタイムアクセス）（ステージ 2 のエージェントが稼働すると自動的に行われ、メニューから選択するものではありません）には、それぞれ上記のルールが適用されます。

ルール

• セットアップのヘッダーには必ず「(via service-itsm-agentic-setup-agentforce-coordinate)」を表示します
• 何かを行う前に、必ず機能メニューを表示します。ユーザーが希望する機能を決めつけてはいけません
• 機能メニューは必ず複数選択形式で表示し、1 回のやり取りで 1 つ以上の機能を選択できるようにします
• ユーザーが選択していない機能は、決してセットアップしません。（明示的な選択によってユーザーの意図を確認でき、途中でキャンセルされた場合の不完全な設定を防げます。一括リクエストについては、「すべてをセットアップ」ルールの順次確認ループを使用してください。）
• 動作する子スキルがない機能は、決して表示しません
• ユーザーが「すべてをセットアップ」または「すべて」と言った場合は、利用可能な機能を推奨順に 1 つずつ進め、各ステップの間で確認します
• 会話全体を通じて進捗を追跡し、完了済みの機能を「未完了」として再表示しません
• Employee 向け特化型エージェント（#4）は再選択可能です。実行するたびに、ユーザーが選んだテンプレートから異なる特化型従業員エージェントを作成します。作成したエージェントにはDoneのマークを付けますが、追加の特化型エージェントを作成するために、#4 は引き続き選択可能な状態にします。完了した #4 を、1 回限りの項目のように完全に終了したものとして扱わないでください。ユーザーが #4 を再度選択した場合は、次に使用する特化型テンプレートを尋ねます
• Employee Agent のエスカレーション（#5）は、IT Service Employee Agent（#3）がこの実行中に正常に完了したか、すでに完了済みであることを必要とするセットアップ後のアクションです。#3 が完了する前に #5 を委任してはいけません
• 現在の機能が失敗した、または一部しか完了しなかった場合は、キュー内の次の機能に進んではいけません。進行を止め、失敗の内容を平易な言葉で伝えます
• Agentforce Studio の有効化時に、組織に Agentforce ライセンスがないと報告された場合（accessCheck）、フロー全体を停止します。これはライセンス／エディションの要件であり、API では付与できません。Fulfiller も Employee Agent も、このライセンスなしでは正常に動作しません
• 子スキルに委任する前に、必ず対象の組織を確認し、その組織が変更されることを明示します
• ユーザー向けの出力に、内部の技術用語を含めてはいけません。これには Salesforce のレコード ID や組織 ID、生の HTTP ステータスコード（403、500 など）、API エラーコード（FUNCTIONALITY_NOT_ENABLED、DUPLICATE_VALUE など）、内部エンドポイント／API 名、開発者名（sales-cloud-agent-studioなどの機能の apiName）、CLI／ツール内部情報が含まれます。すべて平易で人間にわかりやすい表現に置き換えます。次のステップを示す箇所で子スキル名を表示するのは問題ありません
• ユーザー向けの文章で、機能を単独の項目番号で呼んではいけません。#1～#5 のラベル（およびメニューの#列）は、このスキルの並べ替え／委任ルールと、メニューでの選択時（ユーザーが1, 2と返信する場合）に使う内部的な略記にすぎず、機能名ではありません。ユーザーが読むすべてのメッセージ（オプトアウト／スキップ、前提条件／ブロック、進捗、次のステップ、完了の概要）では、機能を省略せず正式名称で記載し、単独の番号や#4、#1–#3のような範囲表記を使ってはいけません。特に、ステージ 1 の切り替えがスキップされた場合は、ブロックされた機能と引き続き利用可能な機能をそれぞれ明記し、「#4 はブロック、#1–#3 は実行可能」とは書かないでください。examples/output-templates.md の文章中の機能名を参照してください
• Requester エージェント、カスタムトピックパック、エージェントのメトリクスダッシュボードなど、まだ利用できない Agentforce 機能についてユーザーから尋ねられた場合は、これらの機能はこのオーケストレーターではまだ利用できず、対応する子スキルがマージされ次第追加されることを伝えます

検証チェックリスト

このスキルでメニューや概要を出力する前に、以下の各項目を頭の中で確認してください。未チェックの項目があれば、送信前に出力を修正してください。

• ヘッダー行が (via service-itsm-agentic-setup-agentforce-coordinate) で終わっている
• 子スキルを実行する前に、対象の組織についてユーザーに確認し、その組織が変更されることを伝えている
• 次にキューされた機能へ進む前に、現在の機能の子スキルの結果が完全な成功であることを確認している。失敗または部分的な結果の場合は、キューの処理を停止している
• 動作する子スキルがある機能のみを表示し、プレースホルダー機能は非表示にしている
• 機能メニューは複数選択として提示している（ユーザーが特定の機能をすでに指定している場合のみ、単一選択にする）
• 各機能行の Status 列には、会話で実際に追跡されている状態（Not done、In progress、Done）を反映しており、固定の既定値を使っていない
• 各機能行の Description は Salesforce Setup → Agentforce for IT Service ページの文言に一致している（Fulfiller と Employee のエージェントテンプレートの説明は言い換えずにそのまま使用する）。Stage 2 の3行はそれぞれ末尾に短い Setup: インストール行があり、AskUserQuestion の選択肢の説明にも同じ文言を使用している
• Specialized Agents for Employee の行が Stage 2 の項目として、IT Service Employee Agent の直後に表示されている。また、どの特殊テンプレートを使うかユーザーに先に尋ねずに #4 を service-itsm-agentic-setup-employee-agent-configure に委任していない（名前を渡さない場合、子スキルは広範なエージェントを既定で選択し、#3 と重複します）。さらに、Setup: インストール行が含まれている
• Employee Agent のエスカレーション行が Stage 2 エージェントの後に表示される Stage 3 項目として含まれている。また、IT Service Employee Agent（#3）が Active になる前に #5 を service-agentforce-human-escalation-configure に委任していない
• 完了の概要では、examples/output-templates.md の基準に従ってヘッダー行と締めくくりの行を選択している（すべて Done → Complete、Not done または In progress がある → Finished）
• 機能を設定するのは、ユーザーが明示的に選択した場合のみ（または、ユーザーが「すべて」／「全部」と依頼した場合に、確認を取りながら順に進める場合のみ）
• Stage 2 のエージェント（Fulfiller、Employee、または Specialized Agents for Employee）に委任する前に、Studio の有効化が完了していることを確認している
• Stage 2 のエージェントが稼働した場合は、Stage 3 のランタイムアクセスを一度だけ追加し、service-itsm-agentic-setup-agent-runtime-access-assign に委任している（それ以外の場合は省略）
• 次のアクションでは機能をインラインで設定せず、子スキルに委任している
• 出力に Salesforce のレコード ID を含めず、人が読める名前のみを使用している
• ユーザー向けの文章で、単独の項目番号や範囲（#4、#1–#3）によって機能を示していない。すべての機能を正式名称で示し、数字はメニューの選択番号としてのみ使用している

---

参照ファイル一覧

ファイル	読み込むタイミング
examples/output-templates.md	動作手順 3、5、6 — 機能メニュー（2段階、複数選択）、機能の進捗報告、完了の概要テキストブロック
scripts/verify-child-verdict.mjs	動作手順 5 — Bash（node）で実行し、キューを進める前に子スキルの判定結果を確実に確認する