service-itsm-agentic-setup-agentforce-studio-configure

Agentforce for IT Service を有効化するための前提条件

Agentforce for IT Service の Salesforce Go 機能トグルである Einstein Generative AI、Agentforce Studio、親となる包括トグル、およびパス固有のエージェントテンプレート（Fulfiller または Employee）を、すべて Salesforce CLI（sf） から有効化します。これらのトグルは Fulfiller／Employee エージェントを作成するための前提条件です。この 書き込み可能なステップでは、Setup Discovery の Connect API ルート POST /connect/setup/discovery/feature/{apiName}/enable を介してトグルを有効にします。各トグルは 冪等に有効化され（すでに ENABLED の場合はスキップ）、依存関係を先に有効化し、書き込みの前に明示的な確認を必須とします。

ステップ	スキル	内容
1. 検証	service-itsm-agentic-setup-agentforce-studio-validate	トグルを読み取り → READY／NOT-READY（書き込みなし）
2. 設定（このスキル）	service-itsm-agentic-setup-agentforce-studio-configure	無効になっているトグルを有効化
3. エージェントを作成	service-itsm-agentic-setup-fulfiller-agent-configure	Fulfiller エージェントを作成して有効化

通常、このスキルは検証スキルの NOT-READY レポートからの引き継ぎで実行されますが、直接実行することもできます。

ヘルパースクリプト scripts/classify-enable-plan.mjs は、バッチ処理された /features/status のレスポンスを読み取り、依存関係の順序に従って有効化プラン（書き込み前）と機能ごとの最終判定（書き込み後）を決定論的に算出します。これは検証スキルの classify-readiness.mjs コントラクト（作成標準 A9）を踏襲しており、判断ロジックは文章ではなくスクリプトに記述されています。

対象範囲

• 対象：Einstein Generative AI（sales-cloud-einstein-generative-ai）、Agentforce Studio（sales-cloud-agent-studio）、親となる包括トグル（service-cloud-agentforce-for-itsm）、およびパス固有のテンプレート（fulfiller の場合は service-cloud-it-fulfiller-agent、employee の場合は service-cloud-requestor-agent と service-cloud-it-service-employee-agent）を、POST .../feature/{apiName}/enable を介して有効化します。書き込みの前後に /features/status から組織ごとの現在の状態を読み取り、依存関係を先に有効化し、再クエリで有効化状態が維持されていることを確認して、機能ごとに ENABLED／ALREADY-ENABLED／FAILED の判定を提示します。書き込みは冪等で、すでに ENABLED の場合はスキップします。
• 対象外：Agentforce ライセンスのプロビジョニング（設定 > 会社情報 > 権限セットライセンス）、ユーザーへの権限セットの割り当て、エージェントの作成、設定、有効化（service-itsm-agentic-setup-fulfiller-agent-configure）、書き込みを伴わない読み取り専用の前提条件検証（service-itsm-agentic-setup-agentforce-studio-validate）、組織全体のマルチエージェントオーケストレーション切り替え（Headless360 専用設定であり、Connect の機能ではありません）。

---

どちらのパスを選びますか？

ユーザーが fulfiller エージェントの前提条件を有効化するのか、employee エージェントの前提条件を有効化するのかを判断します。不明な場合は AskUserQuestion で確認します。検証スキルで使用するパス選択と同じです。

• fulfiller → sales-cloud-einstein-generative-ai → sales-cloud-agent-studio → service-cloud-agentforce-for-itsm → service-cloud-it-fulfiller-agent
• employee → sales-cloud-einstein-generative-ai → sales-cloud-agent-studio → service-cloud-agentforce-for-itsm → service-cloud-requestor-agent → service-cloud-it-service-employee-agent

Einstein Generative AI は Agentforce Studio の依存関係です。検証スキルが直接報告するトグルではありませんが、無効になっている場合は先に有効化する必要があります。分類スクリプトは、両方のパスでこれを有効化プランに含めます。

---

前提条件

validate スキルと同じです（対象組織と API サーフェスを共有しています）。満たされていない場合、sf は認証エラーまたは 401／403／404 を表示します。状態を捏造せず、生のエラーを提示して停止してください。

1. sf CLI がインストールされ、対象組織に認証済みであること（sf org display -o <alias> で Connected と表示されること）。すべての呼び出しで --target-org <alias> を使用してください。アクセストークンを手作業で取り出したり渡したりしないでください。
2. API v67.0 以降であること：connect/setup/discovery 機能 API は v67.0 で利用できます。バージョンは URL パスで固定されています。最低バージョンより下に手作業で変更しないでください。
3. PATH 上に node ≥ 18 があること（分類スクリプトの実行に使用します）。
4. 組織に Agentforce ライセンスがあること（accessCheck）。ライセンスがない場合、読み取り時に 403 または enableBlockedReasons として表示されます。

---

操作の概要

操作	コマンド	戻り値
機能トグルを読み取る	sf api request rest ".../connect/setup/discovery/features/status" --method POST --body '{"featureApiNames":[...]}' --target-org <alias>	{items:[{apiName,status,enableBlockedReasons[],dependencyStatuses[]}]}
トグルを 1 つ有効にする	sf api request rest ".../connect/setup/discovery/feature/{apiName}/enable" --method POST --body '{}' --target-org <alias>	{success:boolean} — エンドポイントに意味のある本文は不要ですが、--body '{}' を明示的に渡す必要があります（注意事項を参照）

どちらも sf api request rest から呼び出せる Connect API ルートです。Headless360 ディスパッチャーは不要です。コマンドの完全な形式、レスポンスエンベロープ、エラーの分類については references/cli-invocation.md を参照してください。

アクセストークンを取り出さないでください。 sf api request rest を直接使用してください。対象組織の CLI 保存済みセッションが使われます。sf org display から accessToken を取り出し、それを使って HTTP リクエストを手作業で組み立てないでください。

重大：エージェントの設定を切り替えるために IPCManagement updateOrgPref を使用しないでください。 このコントローラーの書き込み許可リストはエージェントの prefNames を拒否します（Invalid prefName、500）。これらのトグルを書き込む正しい方法は、Setup Discovery の POST /feature/{apiName}/enable エンドポイントのみです。

---

アーキテクチャ — 有効化の仕組み

手順	処理内容	使用するツール
パスを選択	fulfiller と employee のどちらかを判定します（不明な場合は質問します）	AskUserQuestion
現在の状態を読み取る	選択したパスのトグルについて機能ステータスをまとめて POST し、ファイルに保存します	Bash（sf api request rest）
計画を立てる	scripts/classify-enable-plan.mjs <file> <agentType> [exitStatus] を実行し、依存関係順の pending リストを生成します	Bash（node）
書き込み前に確認	pending リストをそのまま提示し、明示的な「yes」を求めます	AskUserQuestion
有効化	order 内の各 apiName について、再読み取りと再分類を行います。ブロックされていなければ .../feature/{apiName}/enable を POST し、結果を記録します	Bash（sf api request rest + node scripts/record-enable-result.mjs）
検証	/features/status を再読み取りし、分類スクリプトを再実行します	Bash（sf + node）
報告	scripts/classify-final-report.mjs を before／results／after ファイルに対して実行し、最終判定を出します	Bash（node）

---

ワークフロー

<alias> を対象組織のエイリアスに置き換えてください。<agentType> は fulfiller または employee です。

フェーズ 1 — 現在の状態を読み取る

1. 選択したパスで必要なすべてのトグルについて、機能ステータスをまとめて POST し、標準出力をファイルに保存します。--json は追加しないでください。リクエスト本文は一度だけ一時ファイルに書き込み、フェーズ 1、4、5 では --body "$(cat ...)" を使ってそのまま再利用してください。再入力したり、[...] のようなプレースホルダーに置き換えたり、シェル変数に依存したりしないでください。各 Bash 呼び出しは新しいシェルで実行される場合があり、通常の変数は未設定になるためです。

   cat > /tmp/feature-status-body.json <<'EOF'
   {"featureApiNames":["sales-cloud-einstein-generative-ai","sales-cloud-agent-studio","service-cloud-agentforce-for-itsm","service-cloud-it-fulfiller-agent","service-cloud-requestor-agent","service-cloud-it-service-employee-agent"]}
   EOF
   
   sf api request rest "/services/data/v67.0/connect/setup/discovery/features/status" \
     --method POST \
     --body "$(cat /tmp/feature-status-body.json)" \
     --target-org <alias> > /tmp/enable-status-before.json 2>/tmp/enable-status-before.err
   echo $? > /tmp/enable-status-before.exit
   

   終了ステータスを取得してください。|| true で握りつぶさないでください。

Phase 2 — 計画（ヘルパースクリプト）

2. 取得したファイルに分類器を実行して、依存関係の順序に従った有効化プランを算出し、その出力を保存します。Phase 6 では生の /features/status レスポンスではなく、このファイルを使用します。

   node "<skill_dir>/scripts/classify-enable-plan.mjs" /tmp/enable-status-before.json <agentType> "$(cat /tmp/enable-status-before.exit)" > /tmp/enable-plan-before.json
   

   { agentType, readState, features, order, alreadyEnabled, pending, blocked, unconfirmed, verdict, reasons, rawError } が出力されます。verdict: "ALL-ENABLED" は対応が不要であることを意味します。Phase 6 に進んでください。verdict: "NEEDS-ENABLE" は、有効化する項目が pending（order 順）に列挙されていることを意味します。blocked には、enableBlockedReasons が空でない pending のトグルが列挙されます（この読み取り時点で）。order 内の前の依存項目が有効になっていないためにブロックされているトグルは、その依存項目が有効になれば有効化できるようになります。そのため、Phase 4 ではループ全体に対してこのスナップショットを信用するのではなく、各トグルを試行する直前に再確認します。unconfirmed には、レスポンスにない必須トグル、またはこの分類器が認識しないステータスを持つ必須トグルが列挙されます。unconfirmed が空でなく、pending が空の場合、verdict は "ALL-ENABLED" ではなく "CANNOT-CONFIRM" になります。readState: "error" ⇒ rawError を提示して停止します。readState: "not-wired" ⇒ CANNOT-CONFIRM と報告して停止します。

Phase 3 — 書き込み前の確認ポイント（必須）

3. blocked に含まれる項目を除いた、正確な pending リストを提示し、続行する前に AskUserQuestion を使ってユーザーから明示的な「yes」を得てください。組織設定を有効化すると、組織の状態が変更されます。明示的な「yes」が得られた場合にのみ Phase 4 に進んでください。「no」の場合は停止し、書き込みを一切行わずに現在の状態を報告します。

Phase 4 — 有効化（依存関係の順に処理し、各トグルの前に再確認）

4. order を順番どおりに処理します（Einstein GenAI → Studio → 親 → 子テンプレート）。各 <apiName> の有効化を試みる前に、再読み取りして再分類してください。これにより、Phase 2 で blocked だった子項目も（Studio／親がまだ無効だったことだけが理由の場合）、その依存項目が有効化された後に有効化できるようになります。Phase 2 のスナップショットを根拠に、以降ずっと対象外にすることはありません。

   sf api request rest "/services/data/v67.0/connect/setup/discovery/features/status" \
     --method POST \
     --body "$(cat /tmp/feature-status-body.json)" \
     --target-org <alias> > /tmp/enable-status-loop.json 2>/tmp/enable-status-loop.err
   echo $? > /tmp/enable-status-loop.exit
   node "<skill_dir>/scripts/classify-enable-plan.mjs" /tmp/enable-status-loop.json <agentType> "$(cat /tmp/enable-status-loop.exit)"
   

   この出力から features["<apiName>"].signal を確認します。

   • PASS → すでに ENABLED です。対応は不要なので、order 内の次の apiName に進みます。

   • FAIL かつ enableBlockedReasons が空 → 直ちに有効化します。

     sf api request rest "/services/data/v67.0/connect/setup/discovery/feature/<apiName>/enable" \
       --method POST \
       --body '{}' \
       --target-org <alias> > /tmp/enable-<apiName>.json 2>/tmp/enable-<apiName>.err
     node "<skill_dir>/scripts/record-enable-result.mjs" /tmp/enable-<apiName>.json <apiName> /tmp/enable-results.json
     

     /enable エンドポイント自体には意味のあるボディは不要ですが、--body フラグをまったく指定せずに sf api request rest --method POST を実行すると、Error (SfError): No 'mode' found in 'body' entry で失敗します。必ず --body '{}' を明示的に指定してください。record-enable-result.mjs はレスポンスを読み取り、ENABLED／FAILED に分類して、apiName をキーに /tmp/enable-results.json に結果を蓄積します。これは Phase 6 で使用する、各トグルの決定論的な記録です。

   • FAIL かつ enableBlockedReasons が空でない → この反復で再確認した後もブロックされたままです（ライセンス不足など、単なる順次処理ではない実際のブロッカー）。POST は行わず、order 内の次の apiName に進み、ブロッカーを Phase 6 でそのまま報告します。

   • この <apiName> の読み取りで CANNOT-CONFIRM／ERROR → ループを停止して読み取りエラーを提示します。残りのトグルについて推測してはいけません。

   1 つのトグルの失敗によって、プランの残りがブロックされることはありません。ループを続けてください。

Phase 5 — 有効化の検証

5. Phase 1 の読み取りを再実行し（同じ /tmp/feature-status-body.json を使用）、新しいファイルに保存します。そのファイルに分類器を再実行し、Phase 6 用に出力を保存します。

   sf api request rest "/services/data/v67.0/connect/setup/discovery/features/status" \
     --method POST \
     --body "$(cat /tmp/feature-status-body.json)" \
     --target-org <alias> > /tmp/enable-status-after.json 2>/tmp/enable-status-after.err
   echo $? > /tmp/enable-status-after.exit
   node "<skill_dir>/scripts/classify-enable-plan.mjs" /tmp/enable-status-after.json <agentType> "$(cat /tmp/enable-status-after.exit)" > /tmp/enable-plan-after.json
   

   verdict: "ALL-ENABLED" ⇒ order 内のすべてのトグルが ENABLED と確認されています。成功です。pending／blocked／unconfirmed に残っている項目は、Phase 6 で正確に分類する必要があります（FAILED と CANNOT-CONFIRM のどちらか）。

フェーズ 6 — 判定の集約（ヘルパースクリプト）

6. フェーズ 2 の分類器の出力（生の /features/status レスポンスではなく、/tmp/enable-plan-before.json）、フェーズ 4 で蓄積した結果（フェーズ 2 がすでに ALL-ENABLED／CANNOT-CONFIRM／ERROR で、フェーズ 4 が実行されなかった場合は -）、およびフェーズ 5 の分類器の出力（/tmp/enable-plan-after.json）を、最終アグリゲーターに渡して実行します。

   node "<skill_dir>/scripts/classify-final-report.mjs" /tmp/enable-plan-before.json /tmp/enable-results.json /tmp/enable-plan-after.json
   

   { features: { <apiName>: { finalStatus, reason } }, order, overall, reasons } が出力されます。finalStatus は ALREADY-ENABLED | ENABLED | FAILED | CANNOT-CONFIRM | ERROR、overall は SUCCESS | PARTIAL | FAILED | CANNOT-CONFIRM | ERROR です。これをそのまま出力形式に反映してください。説明文で機能ごとの判定や全体の要約を再導出しないでください（作成標準 A9）。overall: "SUCCESS" の場合は、次の手順に進むために service-itsm-agentic-setup-fulfiller-agent-configure（fulfiller）または service-itsm-agentic-setup-employee-agent-configure（employee）を案内してください。

---

ルール／制約

制約	理由
POST /connect/setup/discovery/feature/{apiName}/enable のみを使って有効化する	IPCManagement の updateOrgPref 書き込み許可リストでは、エージェントの prefNames が拒否されます（Invalid prefName）。これが唯一の正しい書き込み経路です
フラットなカタログ一覧ではなく、POST /features/status から機能ごとの最新状態を読み取る	/status でのみ、組織ごとの ENABLED／NOT_ENABLED、enableBlockedReasons[]、dependencyStatuses[] を取得できます
分類器の order に従って、子機能より先に依存機能を有効化する	Einstein GenAI／Studio より先に子機能を有効化すると、依存関係が満たされていないことによるブロッカーが表示されます
フェーズ 4 のループの先頭で一度だけ確認するのではなく、切り替えの直前に毎回状態を読み直して再分類する	先行する依存機能がまだオフだったことだけが理由で blocked になっていた子機能は、その依存機能自身の /enable が反映された時点で有効化可能になります。フェーズ 2 のスナップショットを一度だけ使うと、実際にはブロックされていなかった子機能を FAILED と誤判定してしまいます
冪等にする：すでに ENABLED の機能には /enable をスキップする	分類器の alreadyEnabled リストが正しい状態を示します。有効化済みの機能に対する有効化は {success:true} を返しますが、不要です
/enable の POST を行う前に、必須の書き込み確認チェックポイントを設ける	組織設定の有効化は組織の状態を変更します。ユーザーは pending リストの内容を明示的に承認する必要があります
現在の（再確認後の）enableBlockedReasons が空でない切り替えを有効化しようとしない	enableBlockedReasons が空でない場合、書き込みは失敗します。失敗が確実な POST は実行せず、ブロッカーを報告してください
unconfirmed が空でない場合、pending が空でも verdict: "CANNOT-CONFIRM" とする	必須の切り替えがレスポンスにない場合や、ステータスを認識できない場合、pending に何も残っていないという理由だけで ALL-ENABLED と報告してはいけません
分類と切り替えごとの結果記録は、説明文ではなく、Bash 経由で呼び出す scripts/classify-enable-plan.mjs、scripts/record-enable-result.mjs、scripts/classify-final-report.mjs で行う	固定された機能ステータスに対して、決定表に基づく判定と集約を行います（作成標準 A9）
読み取り／書き込みには sf api request rest を使い、アクセストークンを決して抽出しない	sf api request rest は、--target-org に対して CLI に保存されたセッションを使用します
sf api request rest に --json を渡さない	一部の Connect エンドポイントではサポートされていません。標準出力の生の本文はすでに JSON です
これらは Connect API の機能です。Headless360 ではなく SF CLI を使用する	Connect／Tooling の同等機能があるため、SF CLI を優先します（Headless360HostedMcpServer の org-perm ゲートを回避できます）

---

注意点

問題	解決方法
sf api request rest --method POST に --body フラグを指定しないと、No 'mode' found in 'body' entry エラーが発生する	/enable エンドポイント自体は意味のある本文を受け取りませんが、CLI ではこのフラグが必須です。必ず --body '{}' を明示的に指定してください（CLI 2.140.6 と 2.145.6 で確認済み）
組織で機能 API 名を利用できない、またはライセンスがない	有効な名前を列挙するカタログエンドポイントはありません。Phase-1 の /features/status 読み取りでは、有効化を試みる前に enableBlockedReasons[] を通じて利用不可またはライセンス未取得の機能が示されます
/features/status に dependencyStatuses[] が未達の状態で NOT_ENABLED と表示される	一覧にある依存関係を先に有効化してください（Studio の前に Einstein GenAI、親／子の切り替えの前に Studio）
エージェント設定に対する updateOrgPref が 500 Invalid prefName を返す	書き込み先が誤っています。代わりに Setup Discovery の feature/{apiName}/enable エンドポイントを使用してください
sf api request rest から認証エラーが返される	対象組織のセッションを再認証する必要があります（sf org login web）
認証／権限／空の本文による読み取り失敗を「未接続」として扱う	分類器の第 3 引数に取得した $? を渡してください。CANNOT-CONFIRM となるのは 404 が確認された場合のみです。それ以外はすべて ERROR となるため、rawError を表示して停止します
pending が空であることを理由に ALL-ENABLED と報告する	unconfirmed も確認してください。必須の切り替え項目が応答にない場合や、認識できないステータスの場合は、ENABLED と NOT_ENABLED のどちらも確認できていません
変更前後の JSON から、機能ごとの判定や全体の判定を文章で導き出す	scripts/classify-final-report.mjs を実行してください。集計は固定の比較ロジック（作成基準 A9）であり、判断に委ねるものではありません
Phase 1 で機能ステータスのリクエスト本文をシェル変数に設定し、Phase 4／5 でも利用できると想定する	各 Bash 呼び出しは変数が未設定の新しいシェルで実行される場合があり、空の本文が黙って送信されることがあります。本文を一度 /tmp/feature-status-body.json に保存し、各フェーズで --body "$(cat /tmp/feature-status-body.json)" を使って読み込んでください

---

検証チェックリスト

• エージェントの経路（充足者／従業員）を判定しました（不明な場合は質問しました）。
• Phase 1 で sf api request rest を介して /features/status を読み取り、ファイルに保存し、終了ステータスを取得しました。
• 書き込みを行う前に、scripts/classify-enable-plan.mjs で pending（依存関係順）、blocked、unconfirmed の各リストを算出しました。
• /enable の POST を行う前に、Phase-3 の確認時点でユーザーが pending の正確なリストを明示的に承認しました。
• Phase 4 ではループ全体で一度だけではなく、各切り替えの前に再読み取りと再分類を行いました。これにより、先行する依存関係の有効化でブロックが解除された子項目も試行されました。
• 試行した各 /enable POST の応答を scripts/record-enable-result.mjs で記録し、ループ全体で蓄積しました。
• 有効化後に /features/status を再読み取りし、分類器を再実行して、機能ごとの最終判定を確認しました。
• scripts/classify-final-report.mjs（文章ではなく）を実行して、変更前／結果／変更後のファイルから機能ごとの最終ステータスと全体の概要を算出しました。アクセストークンは一度も抽出していません。

---

出力形式

レポートはライブの Markdown として出力してください。コードフェンスで囲んではいけません（フェンスで囲んだ表では、生の | パイプ文字が表示され、表になりません）。これはステージ 1（基盤）で、ステージ 2（エージェントのインストールと有効化）はこれを基盤として構築します。各 Status は ENABLED / ALREADY-ENABLED / FAILED / CANNOT-CONFIRM のいずれかです。次の形式を厳密に守ってください。

Agentforce for IT Service — Stage 1: Enable Platform Features（service-itsm-agentic-setup-agentforce-studio-configure 経由）

• 組織： <org-alias>（API v67.0）
• エージェントのパス： fulfiller | employee

#	プラットフォーム機能	Status
1	Einstein Generative AI	<status>
2	Agentforce Studio	<status>
3	Agentforce for IT Service	<status>
4	<path-specific toggle(s)>	<status>

判定： SUCCESS | PARTIAL | FAILED | CANNOT-CONFIRM | ERROR

次の手順：

• SUCCESS の場合：「ステージ 1（基盤）が完了しました。ステージ 2 に進み、service-itsm-agentic-setup-fulfiller-agent-configure（fulfiller）／employee-agent スキルを使用して、<path> エージェントをインストールして有効化してください。」
• PARTIAL/FAILED/CANNOT-CONFIRM/ERROR の場合：該当する切り替え項目と理由（enableBlockedReasons、ステータス未確認、または読み取りエラー）、および修正手順を列挙してください。

scripts/classify-final-report.mjs の overall と各機能の finalStatus を <status> セルにそのまま代入してください。再計算してはいけません。分類器の一時的なレスポンス取得ファイル以外に、ファイルは生成されません。

分類器が出力した行ラベルをそのまま使用してください。Requestor、Specialized、parent を追加してはいけません。

---

参照ファイル一覧

ファイル	読み取りのタイミング
references/cli-invocation.md	すべてのフェーズ — sf api request rest の読み取り／書き込み呼び出し形式、レスポンスのエンベロープ、機能の API 名、分類器の仕様、エラーの分類体系