service-itsm-agentic-setup-cmdb-discovery-configure

CMDB アセット検出を有効化する（Service Cloud ITSM）

service-cloud-itsm-discovery-integration 機能を有効にして、CMDB の アセット検出をオンにします。その後、IT Service Discovery Manager 権限セット（およびその権限セットライセンス）を割り当てて、ユーザーに Discovery ページへのアクセス権を付与します。これは CMDB セットアップの最終レイヤーです。ベースの CMDB 機能が有効になり、ユーザーに CMDB アクセス権があり、CMDB Foundation コンテンツバンドルがインストールされた後にのみ実行します。すべての呼び出しは、Salesforce がホストする Headless-360 MCP サーバー（サーバーキー headless-360）を経由し、4 つのメタツール（discover、describe、dispatch_readonly、dispatch）を使用します。組織は、現在の MCP セッションにバインドされた OAuth JWT から特定されます。このスキルが組織 ID、エイリアス、認証情報を扱うことはないため、ユーザーごとの MCP インストールなしで、本番環境とサンドボックス環境の両方に同じように適用できます。

このスキルが対象とするのはDiscovery レイヤーのみです。機能の有効化と、ユーザーへの Discovery ページアクセス権の付与を行います。それ以前の CMDB レイヤーは別のスキルで扱います。このファイルの末尾を参照してください。

CMDB スタック内での位置付け

CMDB は順序付けられたレイヤーで有効化され、各レイヤーはその前のレイヤーを前提とします。

Layer 0  Org SKU / license      Org perm ITSrvcsCnfgMgmnt (verify only — no API can set it).
Layer 1  Tenant provisioning    CMDB tenant must reach status PROVISIONED (async).
Layer 2  CMDB feature           Enable service-cloud-itsm-cmdb-integration (lifts the 403 gate).
Layer 3  User access            Assign the PSL + CMDB permission sets to the user(s).
Layer 4  Content bundle         Install the CMDB Foundation (base) content bundle.
Layer 5  Asset Discovery        Enable service-cloud-itsm-discovery-integration + assign the
                                IT Service Discovery Manager permission set  ← THIS SKILL

Discovery は最後に有効化することが推奨されていますが、ベースの CMDB 機能がすでに有効になっていることは必須ではありません。Discovery を有効にすると、その依存機能であるベースの CMDB 機能も連鎖的に有効になります。ただし、その機能自体の前提条件（例：CMDB テナントがプロビジョニング済みであること）を満たしている必要があります。事前チェックにおける enableBlockedReasons 配列が、ブロッカーを示す唯一の信頼できる情報です。ベースの CMDB 機能が単に NOT_ENABLED の場合は、enableBlockedReasons が空の状態で dependencyStatuses に表示され、ブロッカーにはなりません。そのため、直接有効化すると「エラーになる」とユーザーに伝えてはいけません。CMDB が先に有効になり、その後 Discovery が有効になると伝えてください。実際に有効化を妨げるのは、テナントがプロビジョニングされていない場合など、enableBlockedReasons が空ではない場合のみです。

機能を有効にすると組織レベルのゲートが解除され、Discovery 権限セットを割り当てるとユーザーが Discovery ページを利用できるようになります。 このスキルでは両方を実施します。組織で Discovery を有効にし（ステップ 2）、続いて対象ユーザーに、ライセンスが必要な ItSrvcDscvrMgrPermissionSet（「IT Service Discovery Manager」、対応する PSL は ItSrvcDscvrMgrPsl）を割り当てて、Discovery ページを実際に開いて利用できるようにします（ステップ 4～7）。この権限セットは、service-itsm-agentic-setup-cmdb-access-assign が CMDB のデータ用に割り当てる 4 つの Configuration-Item 権限セット（Reader／Owner／Type Reader／Type Manager）とは別のものです。それらだけを持つユーザーには、Discovery ページへのアクセス権がありません。割り当て手順は冪等です。ユーザーがすでに Discovery 権限セットとそのライセンスを持っている場合はスキップされ、完了済みとして報告されます。

対象範囲

• 対象範囲内：service-cloud-itsm-discovery-integration 機能の事前チェック、有効化、検証。また、その後の手順として、対象ユーザーが Discovery ページにアクセスできるよう、IT Service Discovery Manager 権限セット（およびその権限セットライセンス）を割り当てます。
• 対象範囲外：ベースの CMDB 機能の有効化／CMDB テナントのプロビジョニング（レイヤー 2 — service-itsm-agentic-setup-cmdb-configure）、CMDB のデータアクセス用の 4 つの Configuration-Item 権限セットの割り当て（レイヤー 3 — service-itsm-agentic-setup-cmdb-access-assign）、バンドルのインストール（レイヤー 4 — service-itsm-agentic-setup-cmdb-bundle-deploy）、CMDB レコードの CRUD、Service Graph Connector の設定、識別ルール、権限セットの作成や編集。

仕組み

すべての操作は headless-360 MCP ツールを通じて実行されます。読み取りには mcp__headless-360__dispatch_readonly、書き込みには mcp__headless-360__dispatch を使用します。どちらも HTTP リクエストをそのまま受け取ります：{"url": "<path>", "method": "GET|POST", "body"?: {...}, "queryParams"?: {...}}。{operation_id, arguments} ではありません。すべての呼び出しの正確な url／method／ body については、references/mcp-invocation.md を参照してください。4 つのツールは次のとおりです。

• mcp__headless-360__discover — インデックス化された操作カタログを対象とするセマンティック検索です。このスキルで使用する Setup／Connect ルートと /query／/sobjects/... REST ルートは、必ずしも検索結果の上位に表示されるとは限らず（インデックス化されていない場合もあります）。そのため、見つからなくてもルートが存在しないとは限りません。正確なパスを直接ディスパッチしてください（references/mcp-invocation.md を参照）。
• mcp__headless-360__describe — POST の前に、入力スキーマ全体と正規ルートを取得します。
• mcp__headless-360__dispatch_readonly — すべての読み取り（GET）に使用するディスパッチャーです。
• mcp__headless-360__dispatch — すべての書き込み（POST/PATCH）に使用するディスパッチャーです。

このスキルが認証情報を扱うことはありません。組織は現在の OAuth セッションに紐付けられています。dispatch* 呼び出しで認証エラーが返された場合は、headless-360 MCP 接続を再認証し（セッションが意図した組織を指していることも確認するよう）ユーザーに伝え、その後は停止してください。

Discovery の権限セット

ロール	権限セット（Name）	基盤となる PSL（DeveloperName）	付与される権限
Discovery Manager	ItSrvcDscvrMgrPermissionSet	ItSrvcDscvrMgrPsl	Discovery ページを開いて使用する

権限セットの Id と LicenseId は、ID をハードコードせず、実行時（ステップ 5）に解決してください。ID は組織ごとに異なります。

---

確認事項

会話から推測できないことだけを質問してください。

• どの組織ですか？ 対象の組織を確認し、この組織に変更を加えることを明確に伝えてください（Discovery 機能の有効化は書き込み操作です）。本番環境の場合は、明示的な確認を得てください。
• 誰に Discovery ページへのアクセス権を付与しますか？ IT Service Discovery Manager ロールを割り当てるユーザーです。依頼が「自分用に Discovery を有効にして」／「Discovery をセットアップして」の場合は、現在の（実行中の）ユーザーを既定としてください。別のユーザーの場合は、ユーザー名またはメールアドレスを指定してもらってください。

ユーザーがすでに伝えた内容を再度質問しないでください。事前に入力し、「（会話から）」と記してください。

---

ワークフロー

すべてのステップは順番に実行し、各ステップの確認を通過する必要があります。**確認に失敗した場合は先に進まないでください。**必ず書き込みの前に読み取りを行ってください。有効化の前に読み取り専用の事前確認を実行し、割り当ての前に割り当てに関する確認を実行してください。

ステップ 1 — Discovery 機能の状態を事前確認する（読み取り）

機能の API 名は service-cloud-itsm-discovery-integration です。

dispatch_readonly({ "url": "/services/data/v67.0/connect/setup/discovery/feature/service-cloud-itsm-discovery-integration/status", "method": "GET" })

• status == ENABLED → 機能はすでに有効です。検証（ステップ 3）に進み、その後アクセス権の付与（ステップ 4～7）に進んでください。
• status == NOT_ENABLED かつ enableBlockedReasons: [] → 有効化できます（ステップ 2）。確認を取る前に、dependencyStatuses を確認してください。そこにベース CMDB 機能（service-cloud-itsm-cmdb-integration）が NOT_ENABLED として記載されている場合、これはブロッカーではありません。Discovery を有効にすると、まずベース CMDB 機能が有効化され、その後 Discovery が有効化されます。ユーザーにはそのことを正確に伝えてください（「まず CMDB を有効にし、その後 Asset Discovery を有効にします」）。「エラーになる」や「依存関係エラーを返させる」と警告したり提案したりしないでください。どちらも起こりません。
• enableBlockedReasons が空でない → 停止し、各理由を分かりやすい言葉でユーザーに伝えてください。これらは、組織でまだ満たす必要のある実際の前提条件です（例：CMDB テナントがプロビジョニングされていないため、ベース機能を有効化できない）。ユーザーを先行する CMDB セットアップスキル（「よくある失敗」を参照）に案内し、有効化を試みないでください。
• この GET で 403 FUNCTIONALITY_NOT_ENABLED が返された場合 → ベース CMDB のゲート自体がまだ閉じています。組織では先に service-itsm-agentic-setup-cmdb-configure が必要です。停止して、ユーザーをそちらに案内してください。

ステップ 2 — アセット検出を有効にする（書き込み — まずユーザーに確認）

ステップ 1 ですでに ENABLED と報告されている場合は、このステップをスキップします。

dispatch({ "url": "/services/data/v67.0/connect/setup/discovery/feature/service-cloud-itsm-discovery-integration/enable", "method": "POST", "body": {} })
→ {"success": true}

ステップ 3 — 機能を確認する（読み取り — POST の応答だけを信用しない）

dispatch_readonly({ "url": "/services/data/v67.0/connect/setup/discovery/feature/service-cloud-itsm-discovery-integration/status", "method": "GET" })
→ expect status == ENABLED

status == ENABLED が、機能が有効になっていることを示す確定的な確認です。 有効になっていることを確認したら、以下のアクセス権付与の手順に進みます。機能が有効になっただけでは、どのユーザーにも Discovery ページへのアクセス権は付与されません。

ステップ 4 — 対象ユーザーを特定する（読み取り）

「現在のユーザー」／「自分」／「Discovery をセットアップ」する場合は、API ルートを読み取り、ID URL を解析します（USER_ID() は Apex 専用であり、REST クエリ API では拒否されるため使用しないでください。また、/chatter/users/me や /connect/user-profiles/me は Chatter／Communities がオフの場合に 403 になるため、頼らないでください）。

dispatch_readonly({ "url": "/services/data/v67.0/", "method": "GET" })

応答の identity フィールドは /<orgId>/<userId> で終わる URL です（ユーザー ID は最後のパスセグメントで、005 から始まります）。その ID を直接使用するか、User クエリで確認します。

指定したユーザーの場合（ユーザー名／メールアドレスが指定されている場合）：

dispatch_readonly({ "url": "/services/data/v67.0/query", "method": "GET", "queryParams": { "q": "SELECT Id, Username, Name, IsActive FROM User WHERE Username = '<username>'" } })

• 有効なユーザーがちょうど 1 人の場合 → Id を取得します。
• 結果が 0 件の場合 → 停止し、ユーザー名の確認を求めます。
• 2 件以上の場合 → 停止し、候補（Name + Username）を一覧表示して、どのユーザーかを尋ねます。

ステップ 5 — Discovery 権限セットを特定し、既存の割り当てを確認する（読み取り — 冪等性）

権限セットと、それに対応するライセンスを特定します。

dispatch_readonly({ "url": "/services/data/v67.0/query", "method": "GET", "queryParams": { "q": "SELECT Id, Name, LicenseId FROM PermissionSet WHERE Name = 'ItSrvcDscvrMgrPermissionSet'" } })

Id（権限セット）と LicenseId（割り当てる PSL）を取得します。totalSize == 0 は、その組織に Discovery のライセンスがないことを意味します。停止して、その旨を報告してください。続いて、ユーザーがすでに両方を持っているか確認します。

dispatch_readonly({ "url": "/services/data/v67.0/query", "method": "GET", "queryParams": { "q": "SELECT Id FROM PermissionSetAssignment WHERE AssigneeId = '<userId>' AND PermissionSetId = '<psId>'" } })
dispatch_readonly({ "url": "/services/data/v67.0/query", "method": "GET", "queryParams": { "q": "SELECT Id FROM PermissionSetLicenseAssign WHERE AssigneeId = '<userId>' AND PermissionSetLicenseId = '<pslId>'" } })

両方がすでに存在する場合、そのロールはすでに割り当て済みです。ステップ 6 をスキップし、完了済みとして記録します。

ステップ 6 — ライセンス、次に権限セットを割り当てる（書き込み — 事前に確認）

ステップ 5 ですでに割り当て済みと確認されたものはスキップします。まず PSL を割り当て、次に権限セットを割り当てます。

dispatch({ "url": "/services/data/v67.0/sobjects/PermissionSetLicenseAssign", "method": "POST", "body": { "AssigneeId": "<userId>", "PermissionSetLicenseId": "<pslId>" } })
dispatch({ "url": "/services/data/v67.0/sobjects/PermissionSetAssignment", "method": "POST", "body": { "AssigneeId": "<userId>", "PermissionSetId": "<psId>" } })

• 201 → 割り当て済みです。
• 400 DUPLICATE_VALUE → ユーザーはすでに持っています。失敗ではなく、成功（冪等）として扱います。
• ライセンス上限／空き枠なしのエラー → 割り当てを停止します。Discovery ライセンスに空き枠がないことをユーザーに伝えてください（空き枠のクエリについては references/mcp-invocation.md を参照してください）。再試行しないでください。

ステップ 7 — 割り当てを確認する（読み取り — POST の応答だけを信用しない）

ステップ 5 の 2 つの割り当てクエリを再実行します。PermissionSetAssignment と PermissionSetLicenseAssign の両方が totalSize == 1 を返した場合にのみ、ユーザーは Discovery ページにアクセスできます。

---

ルール／制約

制約	理由
ベースとなる CMDB 機能を有効にした後で実行することを推奨しますが、必須ではありません	Discovery はベースとなる CMDB 機能に依存しますが、その機能が NOT_ENABLED（enableBlockedReasons が空）の場合、有効化時に自動で連鎖して有効になります。この連鎖について伝え、「直接有効にするとエラーになる」とは決して言わないでください。有効化を実際に制御するのは、事前チェックの enableBlockedReasons です
有効化前に事前チェックの結果を読み、有効化後に読み取りで確認してください	この機能は状態を持ちます。POST の応答には実際の状態が反映されるまで時間がかかる場合があります
enableBlockedReasons が空でない場合は、有効化を試みないでください	これらは満たされていない前提条件です。その内容を伝え、ユーザーを先行する CMDB スキルに案内してください
有効化の後には、必ず Discovery-Manager の割り当てを行ってください	機能が有効になっても、ユーザーに Discovery ページへのアクセス権は付与されません。ページへのアクセス権を付与するのは権限セットです
割り当ての前に、ユーザーが必ず 1 件のレコードに特定されるようにしてください	誤ったユーザーや特定が曖昧なユーザーへの割り当ては、取り消しが困難であり、セキュリティ上の懸念があります
割り当ての前に既存の割り当てを読み取り、権限セットより先に PSL を割り当ててください	権限セットはライセンスに紐付き、ユーザーごとに割り当てられます。再割り当てすると DUPLICATE_VALUE が発生します。割り当てを有効にするには、ライセンス枠が確保されている必要があります
DUPLICATE_VALUE は成功として扱ってください	ユーザーがすでにそのアクセス権を持っていることを意味します。冪等であり、エラーではありません
権限セットの作成や編集は決して行わないでください	このスキルでは、標準の Discovery 権限セットの割り当てのみを行います
対象の組織、ユーザー、および各書き込み操作について、ユーザーに確認してください	これらは稼働中の組織に対する、実際に反映され取り消しが困難な変更です
内部用語をユーザーに決して見せないでください	レコード ID、組織 ID、HTTP ステータスコード（403／500／…）、API エラーコード（FUNCTIONALITY_NOT_ENABLED、DUPLICATE_VALUE、…）、オブジェクト名（PermissionSetLicenseAssign）、エンドポイント名、機能の API 名（service-cloud-itsm-discovery-integration）、開発者名（ItSrvcsCnfgMgmnt、ItSrvcDscvrMgrPsl、…）、およびツール内部の用語（dispatch、headless-360）をユーザー向けの出力に含めないでください。平易な言葉に置き換え、人間にわかりやすい名前や状態を使用してください

---

確認チェックリスト

• ステップ 1：有効化前の事前チェックで enableBlockedReasons: [] が表示された（または、すでに status == ENABLED だった）か？
• ステップ 2：有効化で success: true が返された（または、すでに有効だったためスキップした）か？
• ステップ 3：確認用の GET で status == ENABLED が表示されたか？
• ステップ 4：対象ユーザーを 1 件のレコードに特定できたか？
• ステップ 5：Discovery 権限セットとライセンスを特定し、既存の割り当てを確認したか（冪等性の確認）？
• ステップ 6：対象ユーザーに、権限セットとそのライセンスの両方を割り当てた（または、すでに割り当て済みだった）か？
• ステップ 7：書き込み後の読み取りで割り当てを確認したか（POST の応答だけに頼らず）？
• 対象の組織、ユーザー、および各書き込み操作について、事前にユーザーの確認を得たか？

---

出力に関する要件

CMDB Asset Discovery — Complete (via service-itsm-agentic-setup-cmdb-discovery-configure)

Target org: <org>
User: <name> (<username>)

  Asset Discovery ................... Enabled
  IT Service Discovery Manager ...... Assigned    (or: Already had access)

Asset Discovery is now enabled on this org and the user above can open and use the
Discovery page. This completes CMDB setup — the base feature, user access, content
bundle, and discovery are all in place.

To give additional users the Discovery page, re-run this and name each user (or use
service-itsm-agentic-setup-cmdb-access-assign for the underlying CMDB data roles).

ユーザー向けの出力には内部用語を含めないでください（レコード ID、HTTP ステータスコード、エラーコード、オブジェクト名、エンドポイント名、開発者名は使用しないでください）。開発者名ではなく、「IT Service Discovery Manager アクセス」と伝えてください。いずれかのステップで失敗した場合は処理を中止し、どの部分が成功しなかったか、それがユーザーにとって何を意味するかを平易な言葉で伝え、該当する修正方法を案内してください。生のエラー（403 や FUNCTIONALITY_NOT_ENABLED など）はコードをそのまま伝えず、意味が伝わる表現（「CMDB の設定がまだ完了していません」など）に置き換えてください。

---

よくある失敗（わかりやすい言葉で伝える）

症状	考えられる原因	ユーザーに伝える内容
事前チェックで enableBlockedReasons が空ではない	さらに深い前提条件が実際に満たされていません（例：CMDB テナントがプロビジョニングされていません。なお、NOT_ENABLED のみの基本 CMDB 機能は、この配列に値を追加しません。連鎖的に有効化されます）	各理由を伝えてください。まず CMDB のセットアップを完了します。service-itsm-agentic-setup-cmdb-configure（テナントと基本機能をプロビジョニング）を実行し、次に -access-assign（ユーザーアクセス）、-bundle-deploy（コンテンツバンドル）の順に実行してから、検出を再試行してください
検出を有効にする前は基本 CMDB 機能が NOT_ENABLED で、有効化するとそれも有効になった	想定どおりです。検出を有効にすると、基本 CMDB の依存機能も連鎖的に有効化されます。これは失敗ではありません	有効化する前に、まず CMDB が有効になり、その後 Discovery が有効になることをユーザーに明確に伝えてください。「エラーになります」と警告してはいけません
ステータス GET で 403 FUNCTIONALITY_NOT_ENABLED	基本 CMDB のゲートがまだ閉じています（CMDB 機能が有効になっていません）	検出の失敗ではありません。service-itsm-agentic-setup-cmdb-configure で基本 CMDB 機能を先に有効にしてから、再試行してください
セットアップの一部完了後も、有効化がブロックされる（enableBlockedReasons が空ではない）	組織に必要な依存機能が不足しています	各理由を伝えてください。前提条件を解決してから、再試行してください
有効化は成功を返したが、検証 GET が ENABLED ではない	状態の反映遅延、または下流の問題	少し待ってから検証 GET を再実行してください。状態が変わらない場合は、有効になっていないものとして扱い、調査してください
ItSrvcDscvrMgrPermissionSet の PermissionSet クエリで totalSize == 0	組織に Discovery のライセンスがありません	この組織では Discovery にアクセスできません。ライセンスが付与されているか確認してください
割り当て時に 400 DUPLICATE_VALUE	ユーザーはすでに Discovery ページへのアクセス権を持っています	エラーではありません。ロールがすでに割り当てられていることを伝えてください
割り当て時のライセンス上限／空きシートなしエラー	Discovery 権限セットのライセンスシートを使い切っています	使用中と利用可能なシート数を伝えてください。割り当てる前に、シートを空けるか、ライセンスを追加する必要があります
Discovery が ENABLED で機能も有効だが、ユーザーが Discovery ページを開けない	ユーザーに Discovery 権限セット（ItSrvcDscvrMgrPermissionSet ／ PSL ItSrvcDscvrMgrPsl）が割り当てられていません	このユーザーに対してこのスキルを再実行し（ステップ 4～7）、「IT Service Discovery Manager」アクセス権を付与してください
dispatch* の認証エラー	headless-360 MCP セッションが認証されていないか、トークンの有効期限が切れています	headless-360 MCP 接続を再認証し、セッションが意図した組織を参照していることを確認してください

---

スキル間の連携

場合	スキル
事前チェックで実際のブロッカーが報告される（enableBlockedReasons が空ではない。例：CMDB テナントがプロビジョニングされていない）	service-itsm-agentic-setup-cmdb-configure（レイヤー 0～2。テナントをプロビジョニングして基本機能を有効にしてから、ここに戻ります）。NOT_ENABLED のみの基本機能はブロッカーではありません。Discovery が連鎖的に有効化します
ユーザーに基盤となる CMDB データロール（Configuration Item Reader／Owner／Type Reader／Type Manager）が必要	service-itsm-agentic-setup-cmdb-access-assign（レイヤー 3。CMDB データアクセス。Discovery ページへのアクセスとは別です）

---

参照ファイル一覧

ファイル	読むタイミング
references/mcp-invocation.md	事前チェック、有効化、検証、ユーザー解決、Discovery-Manager 割り当ての各呼び出しに使う正確な dispatch* URL／メソッド／本文、レスポンスのエンベロープ、ライセンスシートのクエリ、エラー一覧を確認するとき