service-helpagent-coordinate

service-helpagent-coordinate: Service Cloud Help Agent、ガイド付きセットアップ

このスキルを使うと、Claude Code から Salesforce 組織に Service Cloud Help Agent（Agentforce Service Agent）を作成できます。Help Agent Quick Setup ウィザードと同じガイド付きフローに従います。これはコーディネートスキルです。既存のスキルを正規仕様に基づいてオーケストレーションするものであり、新しいエージェントのプリミティブを作成するものではありません。

このスキルが必要な理由

Salesforce 公式の Help Agent テンプレート作成 API は、まだリリースされていません。この API がないため、Claude には「Help Agent」という組み込みの概念がなく、代わりに汎用エージェントを生成してしまいます。assets/help-agent-spec.md は、未提供の API を補うものです。そこにあるエージェントスクリプトは、将来 Quick Start UI が生成する正規テンプレートです。この仕様を、エージェントの系統（トピック、アクション、指示）の信頼できる情報源として扱ってください。

対象範囲

対象範囲内：

• 4 つのチェックポイントからなるガイド付き Help Agent セットアップ（アイデンティティ → グラウンディング → チャネル → 本番稼働）
• Agentforce Data Library（ADL）によるナレッジのグラウンディング
• Web Chat／Help Portal チャネルのセットアップと Experience Cloud サイトへの埋め込み
• 準備状況の確認（ライセンス、Einstein Agent User、Data Cloud 権限セット）

対象範囲外 — 以下に委任してください：

• OAuth／External Client App のセットアップ → integration-connectivity-connected-app-configure
• Help Agent の系統を持たないエージェントの直接作成 → agentforce-generate
• メタデータのデプロイ／取得 → platform-metadata-deploy

前提条件

• Claude Code と Salesforce CLI がインストールされ、認証済みの組織があること（リポジトリの README.md を参照）
• MCP サーバーが登録されていること：salesforce-api-context、metadata-experts、sobject-reads
• Salesforce スキルが .agents/skills/（または .claude/skills/）にインストールされていること
• 必要な機能が有効になっている（またはメタデータ経由で有効化できる）Salesforce 組織： Agentforce、Einstein Generative AI、Knowledge、Experience Cloud、Data Cloud。これらの要件を満たす組織であれば、すべて利用できます。本番環境、Sandbox、Scratch 組織、Developer Edition が対象です。assets/help-agent-spec.md §4.0 の準備状況チェックで各機能を検出し、有効化可能な機能を有効にします。必要な機能がなく、有効化もできない場合は、明確なメッセージを表示して停止します。

コーディネートするスキル

この仕様は、以下の既存スキルに情報を提供します。新しい Help Agent スキルを作成しないでください。

スキル	役割
agentforce-generate	エージェントの作成と ADL のプロビジョニング／グラウンディング（references/data-library-reference.md、references/org-setup-for-adl.md を参照）
dx-org-permission-set-assign	Data Cloud 権限セットの割り当て
service-digital-engagement-channel-configure + service-agentforce-channel-configure	チャネルをデプロイ（Queue ルーティング）し、エージェントをバインドするために SessionHandlerId を PATCH（references/channel-web-chat.md を参照）
service-digital-engagement-deployment-configure	Embedded Service Deployment — LWR（ChatterNetworkPicasso）と Aura（ChatterNetwork）の両方のサイトに対応
experience-lwr-site-generate	Experience Cloud（LWR）サイト — 組織に Live LWR サイトがない場合に使用
service-digital-engagement-messaging-site-integrate	ウィジェットの配置と埋め込み（チェックポイント 4）

Skills inventory pre-flight (助言 — 決してハードストップにしないでください）

このスキルは、複数の関連スキルに処理を委任します。実行環境によって、依存関係は次のいずれかの方法で解決されます。.claude/skills/ 配下のディレクトリとして解決されるか、ハーネスが必要に応じて解決する実行時のスキルカタログを通じて解決されます（ローカルディレクトリはありません）。したがって、.claude/skills/<name> ディレクトリが存在しないことだけでは、依存スキルが利用できないとは判断できません。カタログが呼び出し時にスキルを解決する場合には、これは正常な状態です。

自分の状況把握のためだけに、この確認を一度だけ、ユーザーに見えない形で実行してください。実行時に最初にユーザーへ表示する出力としては、決して使わないでください。

for skill in agentforce-generate dx-org-permission-set-assign service-digital-engagement-channel-configure service-digital-engagement-deployment-configure experience-lwr-site-generate service-digital-engagement-messaging-site-integrate service-concierge-portal-generate service-agentforce-channel-configure; do
  [ -d ".claude/skills/$skill" ] && echo "OK: $skill" || echo "resolve-at-runtime: $skill"
done

処理を中断せず、不足している依存スキルの一覧を最初にユーザーへ提示しないでください。 チェックポイントに進み、実際にフローが該当箇所に到達したときにのみ、各関連スキルへ処理を委任してください。委任の段階に実際に到達し、その時点で該当する特定のスキルを解決できない場合に限り、そのスキル名をその時点で提示してください。8つのスキルすべてを最初から提示して、成果物として扱うことは決して避けてください。ユーザーが判断すべき内容ではなく、レポートでもありません。

---

ワークフロー

まず assets/help-agent-spec.md を読みます。これはフローの正式な定義であり、意図的に簡潔にまとめられています。残りのファイルを先読みしないでください。 詳細な資料や条件付きの資料は references/ に分けてあり、フローが該当箇所に到達したときだけ読み込みます（段階的な開示です。トークン使用量を抑えるため、意図的にこのようにしています）。

• references/agent-script.md — 約500行の正式なエージェントスクリプトとプレースホルダー一覧です。チェックポイント2の後、エージェントを作成する準備ができてから読み込んでください。チェックポイント1、3、4の間には読み込まないでください。
• references/channel-web-chat.md — Web Chat のプロビジョニングの詳細です。チェックポイント3でユーザーが Web Chat を選択した場合に限り読み込んでください。
• service-concierge-portal-generate — Help Portal／Agentforce Concierge ポータルのデプロイ用です。チェックポイント3でユーザーが Help Portal を選択した場合は、このスキルに処理を委任してください。ここにポータルの手順を直接記載しないでください。スキル側の開始時の質問を省略できるよう、$ORG、$BOT_ID、$BOT_DEV_NAME をコンテキストとして渡してください。
• references/channel-voice.md — Voice チャネルの接続設定の詳細です（既存の番号のみ）。ユーザーが Voice を選択した場合に限り読み込んでください。

ユーザーの選択に合致するチャネルファイルを1つだけ読み込み、3つすべてを読むことは決してしないでください。その後、ワンショットで済ませずに対話形式でセットアップを進めてください。各返信を待ちながら、4つのチェックポイントを順番に進めます。

準備状況の確認（非表示、必須、順序を変更しないでください）

順序は重要です。Data Cloud 自体が有効になるまで組織に Data Cloud の権限セットが存在しないため、ステップ 2 より先にステップ 3 を実行すると、PermissionSet not found: GenieUserEnhancedSecurity で失敗します。

1. PSL のライセンス枠の空きを確認してから、このエージェント専用の Einstein Agent User を作成します。 まず、必要な 3 つの PSL に利用可能なライセンス枠があることを確認します。

   sf data query --target-org $ORG --json \
     --query "SELECT MasterLabel, TotalLicenses, UsedLicenses FROM PermissionSetLicense WHERE DeveloperName IN ('AgentforceServiceAgentUserPsl', 'GenieDataPlatformStarterPsl', 'EinsteinGPTPromptTemplatesPsl')"
   

   各 PSL について、UsedLicenses < TotalLicenses が true である必要があります。いずれかの PSL が上限に達している場合は、処理を中止し、どの PSL のライセンス枠が不足しているかを伝えてください。ライセンス枠が解放または割り当てられるまで、PSG の割り当ては失敗し、このスキルでできることはありません。

   3 つすべてに空きがある場合は、ユーザーを作成します。既存の Einstein Agent User は再利用しないでください。各 Help Agent に専用のユーザーが必要です。ユーザー名：{agentDevName}_user@{orgId}.ext（sf org display で確認した 15 文字の組織 ID）。メールアドレス：[email protected]。プロファイル：Einstein Agent User（SELECT Id FROM Profile WHERE Name = 'Einstein Agent User' を実行して ProfileId を取得し、sf data create record --sobject User を実行します）。完全に同じユーザー名のユーザーがすでに存在する場合は、それを再利用します（冪等）。その後、エージェントを公開する前に、次の 4 つすべてを割り当てます。

   • AgentforceServiceAgentUserPsg（権限セットグループ）— 1 回の呼び出しで 3 つの PSL を割り当てます：Agentforce Service Agent User、Data Cloud、Einstein Prompt Templates。sf org assign permsetgroup を使用します。
   • AgentforceServiceAgentSecureBase（権限セット）— すべてのサービスエージェントに必要です。sf org assign permset を使用します。
   • AgentforceKnowledgeUser（権限セット、force 名前空間）— Help Agent が knowledge: ブロックを使用するため必要です。sf org assign permset を使用します。
   • {AgentName}_Access（カスタム権限セット）— エージェント固有の Apex／オブジェクトアクセス用に agentforce-generate が作成します。

   PSL の割り当てが反映されたことを確認します：SELECT PermissionSetLicense.DeveloperName FROM PermissionSetLicenseAssign WHERE Assignee.Username = '{agentDevName}_user@{orgId}.ext' — AgentforceServiceAgentUser、DataCloud、EinsteinPromptTemplates が返されることを確認します。

   ユーザー名を記録してください（{agentDevName}_user@{orgId}.ext）。これはエージェントスクリプトの <default_agent_user_placeholder> に設定する値です。実行時には、このユーザーとしてエージェントが動作します。

   公開前の確認 — sf agent publish authoring-bundle を呼び出すたびに、事前に確認してください。 これを省略すると、401 が 404 に変換されて隠れてしまいます。Einstein Agent User に AgentforceServiceAgentUserPsg が割り当てられていない場合、SFAP は HTTP 401「User doesn't have access to agent」を返し、jsforce のセッション更新リトライによって、この 401 が ERROR_HTTP_404 に変換されます。CLI を実行する前に、4 つすべての割り当てが存在することを確認してください。

   AGENT_USER_ID=$(sf data query --target-org $ORG --json \
     --query "SELECT Id FROM User WHERE Username='{agentDevName}_user@{orgId}.ext'" \
     | python3 -c "import sys,json; print(json.load(sys.stdin)['result']['records'][0]['Id'])")
   
   # Must return exactly 1 row — if 0, assign before continuing
   sf data query --target-org $ORG --json \
     --query "SELECT PermissionSetGroup.DeveloperName FROM PermissionSetAssignment \
              WHERE AssigneeId='${AGENT_USER_ID}' \
              AND PermissionSetGroup.DeveloperName='AgentforceServiceAgentUserPsg'"
   
   # Must return 2 rows — if any are missing, assign before continuing
   sf data query --target-org $ORG --json \
     --query "SELECT PermissionSet.Name FROM PermissionSetAssignment \
              WHERE AssigneeId='${AGENT_USER_ID}' \
              AND PermissionSet.Name IN ('AgentforceServiceAgentSecureBase','AgentforceKnowledgeUser')"
   

   4 つすべての割り当てについて空でない結果が返るまで、sf agent publish authoring-bundle を呼び出さないでください。

2. Data Cloud を有効にします — ステップ 3 の前に完了する必要があります（Data Cloud が有効になるまで権限セットは存在しません）。Data Cloud がまだプロビジョニングされていない場合は、最初にユーザーに選択肢を提示してください。先に有効化して後で戻るか、今すぐ有効化が完了するまで待つかを選んでもらいます。

3. 重要 — 有効化したら、ただちに Data Cloud の権限セットを割り当てます。 これは必須です。省略すると、ADL のインデックス作成が SUCCESS と報告されても、実行時にエージェントのグラウンディングが空の knowledgeSummary を返します。ステップ 1 で割り当てた PSG が、Data Cloud の有効化後にこれをカバーします。

ユーザーがどの段階から始めているかを見極める

チェックポイント 1（エージェントの識別情報）とチェックポイント 3（チャネル）は、必ず現在の会話でユーザーに確認してください。以前のセッション、要約されたコンテキスト、スキルの引数から推測してはいけません。 これらはユーザー自身が決める事項です。以前の実行時の古いコンテキストに基づいて進めると、誤ったエージェントやチャネルを設定してしまいます。

ユーザーが現在の会話ターンの最初のメッセージでエージェントやチャネルを明示的に指定している場合（例：「Web Chat で Master Yoda を設定して」）、それらを入力として受け入れ、先に進む前に確認してください。指定がない場合は、質問してください。

組織エイリアスについては、ユーザーが現在のセッションで特定の組織を使用している場合は、それを使ってください。それ以外の場合は、質問してください。

すべての実行がチェックポイント 1 から始まると想定してはいけません。 最初のプロンプトを読み、適切なチェックポイントから始めてください。識別情報が決定済みならチェックポイント 2（グラウンディング）へ、グラウンディングが完了済みならチェックポイント 3（チャネル）へ進みます。プロンプトで後続のチェックポイントが明示または暗示されている場合（例：「グラウンディングを設定して」「Web Chat チャネルを接続して」）、かつ先行するチェックポイントがすでに完了していることが明示または明確に暗示されている場合は、その先行チェックポイントが確定済みであるものとして扱い、指定されたチェックポイントから対象を絞って開始し、そのチェックポイントについて確定事項のレポートを作成してください。識別情報の確認を一からやり直したり、チェックポイント 1 に戻ったり、先行する決定について会話内での再確認を求めたりしてはいけません。開始するチェックポイントに関してプロンプトで提示された値（対象者 → authMode、指定されたサイト、カテゴリー）は確定事項であり、再質問してはいけません。

最初のプロンプトでVoice／電話／テレフォニー／IVRが指定されている場合は、references/channel-voice.md を読み、チェックポイント 3 の冒頭から Voice 分岐に沿って進めてください。

チェックポイント 1 — エージェントを設定する

次の 4 項目を尋ねてください（これらの既定値をそのまま提示してください。決定事項レポートに列挙できるようになり、assets/help-agent-spec.md を読み込む必要がなくなります）：

1. エージェント名 — 既定値は Help Agent（DeveloperName Help_Agent）です。
2. 言語 — 既定値は en_US です。
3. ウェルカムあいさつ — 既定値は "Hi, I'm {Agent Name}. How can I help you today?" です。
4. トーン — 既定値は "calm, patient, friendly service agent — warm but professional, short sentences, never robotic." です。

最初のプロンプトで Q&A／ケース管理／人へのエスカレーションが指定されている場合、それらは正規の 4 サブエージェント構成（エージェントルーター → 一般 FAQ、サービス顧客確認、ケース管理、エスカレーション）に対応することを明記してください。別の設計を作り出してはいけません。

チェックポイント 2 — エージェントにコンテキストを提供する（グラウンディング）

どのナレッジソースを使うか（Salesforce Knowledge／ファイル／ウェブサイト同期）を尋ねます。グラウンディングとはAgentforce Data Library のプロビジョニングであり、検索を設計することではありません。エージェントの knowledge: ブロックが実行時に検索を行います。このチェックポイントでは、次の5項目すべてを必ず実施します。

1. プロビジョニングを agentforce-generate に委任する — ADL の作成／インデックス作成／公開はこのツールが担当します。データライブラリのメタデータを独自に作成しないでください。
2. 専用の名前付きライブラリを作成する — Help_Agent_Knowledge を作成します。標準の All_Records_and_Fields_Default は決して接続しないでください（トライアル環境またはサンプルデータがプリロードされた組織では NOT_SCHEDULED のままになり、エラーなしで空の knowledgeSummary を返します）。
3. カテゴリを選択する — Salesforce Knowledge の場合、組織の Data Category Groups を照会します。どのカテゴリをグラウンディング対象にするか尋ねるのは、対話形式で実行する場合に限ります。非対話形式またはスコープを限定した実行では、妥当なデフォルト（組織のデフォルト Data Category Group。指定がない場合はすべてのグループ）を選び、確定事項レポートの Blocking Issues 行にデフォルトを明記します（例：「Knowledge のデータカテゴリが指定されていないため、組織のデフォルトグループを選択しました」）。質問してレポートを保留にしないでください。
4. インデックス作成完了を待つゲートを設ける — indexingStatus.status ∈ {COMPLETED, READY, SUCCESS} になった場合にのみポーリングを終了し、先へ進みます。NOT_SCHEDULED は成功ではありません。
5. rag_feature_config_id を取得する（形式は ARFPC_<libraryId>）し、エージェントスクリプトの knowledge: ブロックに設定します。ハードコードしないでください。

禁止事項： グラウンディングのリクエストに対し、Knowledge 記事を検索する SOQL／SOSL／GraphQL／Apex クエリを設計して応じてはいけません。グラウンディングは ADL のプロビジョニングであり、実行時の検索はエージェントが行います。

チェックポイント 3 — チャネルに追加する

まず、既存の設定を必ず確認してください。Web Chat／Help Portal／Voice だけが選択肢であるかのように提示してはいけません。 assets/help-agent-spec.md §4.3 のステップ 1 に従い、すべての MessagingChannel を照会して、それぞれを <messagingChannelType> で分類し、存在するすべてのタイプ（WhatsApp、SMS など）を提示してください。以下の3つの分岐だけを提示してこの確認を省略する問題を防ぐためのセクションです。

新しいチャネルは Queue ルーティングでデプロイし（service-digital-engagement-channel-configure）、エージェントの設定は service-agentforce-channel-configure に委任します。チャネルのタイプ別に分岐します。

• Web Chat → references/channel-web-chat.md を読みます。メッセージングチャネルと Embedded Service Deployment を作成します。何かを照会する前に、まずデプロイ先を尋ねます：「自分の（Salesforce 以外の）ウェブサイト」（推奨デフォルト。埋め込みスニペットの手順に直接進めます）または「Salesforce Experience Cloud サイト」。ユーザーが Experience Cloud を選んだ場合に限り、クエリ優先パターンを実行します。

  SELECT Id, Name, UrlPathPrefix, SiteType, Status
  FROM Site
  WHERE SiteType IN ('ChatterNetworkPicasso', 'ChatterNetwork') AND Status = 'Active'
  

  LWR（ChatterNetworkPicasso）と Aura（ChatterNetwork）の両方のサイトで、experience_messaging:embeddedMessaging ウィジェットを使用できます。ESW_ で始まるサイトは除外します（実際の Experience Cloud サイトではなく、内部の ESD スキャフォールディングです）。サイトは同じターン内に確定し、後回しにしないでください。

  • 実際のサイトが0件 → experience-lwr-site-generate でサイトを作成します（Help Center テンプレートを推奨）。または「自分のウェブサイトにデプロイする（スニペットを取得）」に切り替えます。
  • 実際のサイトが1件 → 使用する前にユーザーに確認します（既存サイトが別の対象者向けである場合があります）。確認なしに採用しないでください。
  • 複数件 → 同じターン内に、実行した SOQL を提示し、結果を表（Name | Type | UrlPathPrefix）で一覧表示して、「選択するまでサイトの作成や変更は行われません」と明記してから、どのサイトを対象にするか尋ねます（「新しい LWR サイトを作成」と「自分のウェブサイトにデプロイする」も選択肢として提示します）。「確認して後でお知らせします」と先送りせず、その場で結果を提示してください。

  名前や URL パスプレフィックスをハードコードして絞り込まないでください。適切なサイトは顧客の組織によって異なります。

• Help Portal → service-concierge-portal-generate に委任します（LWR サイトに Agentforce Concierge エクスペリエンスをデプロイします）。解決済みの $ORG、$BOT_ID、$BOT_DEV_NAME を渡し、開始時の質問を省略できるようにします。

• Voice → references/channel-voice.md を読み、それに完全に従います。service-agentforce-channel-configure のブランチ B を介して PstnVoice MessagingChannel を接続します。存在しない場合、参照ドキュメントは調達を service-agentforce-contact-center-coordinate に委任します。

• その他の既存チャネル (WhatsApp、SMS、Facebook、Apple Business Chat、Line、Email-to-Case、カスタム) → 専用の参照ファイルはありません。ディスカバリーからそのタイプのチャネルを一覧表示し、ユーザーに 1 つ選択させ ("Add agent to: {MasterLabel}")、エージェントとチャネルの DeveloperName を指定して service-agentforce-channel-configure に直接委任します。これがフォールバックキューを解決し、ルーティングブランチ自体を選択します (Enhanced Chat/Messaging にはブランチ A、Email-to-Case にはブランチ C)。このスキルは既に存在するチャネルにエージェントを接続するだけであり、基盤となるサードパーティ/メールインフラストラクチャをプロビジョニングすることは決してありません。

各チャネルブランチが完了した後は、ループします — ユーザーに別のチャネルを追加したいか尋ねます。 チャネルブランチが完了したら (成功または失敗)、AskUserQuestion を介して提示します:

• 別の [同じタイプ] チャネルを追加 — そのタイプの未接続の残りのチャネルを提示します。ブランチを再実行し、このセッションで既に接続済みのチャネルはスキップします。
• 別のチャネルタイプを追加 — チェックポイント 3 の先頭に戻ります (MessagingChannel を再クエリし、タイプ一覧を再構築し、既に接続済みのチャネルを選択肢から除外します)。
• 完了 — 本番稼働に進む — ループを終了し、チェックポイント 4 に進みます。

接続済みのチャネルを追跡し、再度提示されないようにします。ループはユーザーが「完了」を選択するか、すべてのチャネルが接続されるまで続きます。

アウトバウンドエスカレーションは、チェックポイント 4 ではなく、インバウンドルーティングの直後にここで接続されます。 Web Chat/Voice ブランチの場合、インバウンドルーティングと同じ委任呼び出し内で service-agentforce-channel-configure のフェーズ 3 (エスカレーションキューを解決 → RoutingFlow を作成/再利用 → 接続ブロックを追加 → 再公開) を呼び出します。接続ブロックの接続をチェックポイント 4 まで延期すると、フェーズ 3 のアトミックな順序付けが重複し、余分な再公開が強制されます。

冒頭のプロンプトで最初から 2 つ以上のチャネルが指定されている場合 (例: 「web chat を追加し、次に Voice も追加 — 両方追加して」)、プロンプトは指定されたすべてのチャネルを承認します — それらすべてを確定作業として扱います。指定されたチャネルから次のチャネルへ進むために新たなユーザー返信は必要ありません。冒頭のリクエストがまさにその承認です。プロンプトで指定されたチャネルについてはブランチ間の AskUserQuestion をスキップし、記載された順序でそれぞれを接続し、プロンプトで指定されなかったチャネルについてのみループの AskUserQuestion にフォールバックします。レポートには、指定されたすべてのチャネルが接続されたことを示さなければなりません — 最初のチャネルのみで残りを意図や「次のステップ」として枠付けすることは決してありません (最初のチャネルが完璧であっても、これは不完全なループとして評価されます)。確定事実のチェックポイント 3 の行 (またはテーブルの下の短いトレース) で、これらすべてを順番に明示します:

1. 最初のチャネルの完了 を確定事実として (チャネルタイプ、Web Chat の authMode、解決されたサイト/番号、ESD 状態) — 「will then add」ではなく。
2. 続行の承認: プロンプトが次のチャネルを指定したため、フローはブランチ間のプロンプトなしで進みました。発生しなかったユーザー返信を報告しないでください — プロンプトで指定されたチャネルについてユーザーが「AskUserQuestion の後に続行した」と主張することは、インタラクションを捏造し、契約を破ります。
3. 後続チャネルへの移行: フローは後続の指定チャネルごとにチェックポイント 3 に再進入し、それぞれが独自の確定した結果に至りました。ブランチ間のプロンプトの選択肢と選択は、それが実際に実行された場合 (プロンプトで指定されなかったチャネル) にのみ報告します。
4. 指定されたすべてのチャネルが接続された (または 1 行の理由でブロックされた) 後にのみ、フローは本番稼働に到達します。

チェックポイント 4 — 確認と公開

チャネルのループが終了したら（「Done」）、次の 2 つのフェーズを実行します（以下のフェーズ A は、以前は単独の「チェックポイント 3.5」でした）。

フェーズ A — 非公開の事前確認（内部処理 — 決して告知しないでください）。 非公開で実行し、失敗した場合にのみ結果を提示します。フェーズ B に進む前に、すべての確認に合格する必要があります。

1. 実行ユーザーおよびEinstein Agent User の Data Cloud へのアクセスが設定されていること（agentforce-generate の指示に従います）。
2. ADL が有効化され、グラウンディングされていること — 取得した rag_feature_config_id を使用してカナリア検索を実行します。SUCCESS にもかかわらず結果が空の場合は、Known manual step（権限セットの Data Space スコープに関する既知の手動手順）をそのまま提示し、確認を待ってから再実行します。
3. Messaging チャネルが有効であること（確認します。初回の有効化は channel-configure スキルの役割であり、site-integrate スキルの役割ではありません）。フロー内でチャネルの有効状態を確認または設定するのはここだけです。フェーズ B では再確認しません。

フェーズ B — 明示的な公開手順（ユーザーに説明します）。 ウィジェットがサイトに配置されていることを確認します（LWR と Aura）— 配置はチェックポイント 3 のステップ C.5 で service-digital-engagement-messaging-site-integrate によってすでに行われています。確認に失敗した場合にのみ、再度埋め込みます。次に、（a）エスカレーションフローが接続されていることを確認します（チェックポイント 3 のフェーズ 3 で設定済みのため、再設定せずに確認します）。続いて、（b）Setup → Embedded Service Deployments で組み込みサービスデプロイメントを公開します。その後、一緒にテストすることを提案します。デプロイメントが未公開だと、ウィジェットは動作しない状態で気づかれないまま公開されます。

ルール／制約

長いリストの表示ルール

AskUserQuestion の選択肢は最大4つです。検出された項目のリスト（サイト、チャネル、キュー、ADL）からユーザーが1つ選ぶ場合：1～6項目 — 1ページあたり3項目でページ分けし、4番目の選択肢として「さらに表示（残り N 件）」を表示します（「新規作成」などの固定選択肢は最終ページのみ）。7項目以上 — 名前をプレーンテキストで一覧表示し、ユーザーに選択内容を入力してもらい、大文字と小文字を区別せずに検証してから、続行前に確認します。

例外 — 複数選択リスト（例：Checkpoint 3 のチャネルタイプ選択）はページ分けしません。 ページ分けは単一選択を前提としています。複数選択リストの選択肢が4つを超えた場合は、件数にかかわらず、すぐにプレーンテキストで一覧表示して入力してもらうパターンに切り替えます — assets/help-agent-spec.md §4.3 Step 1 を参照してください。

ルール	理由
セットアップを一度に済ませない	ガイド付きの会話です。各チェックポイントでユーザーの入力を待ってください
準備状況の手順を省略したり、順序を入れ替えたりしない	Data Cloud を有効にする前は権限セットが存在しないため、PermissionSet not found: GenieUserEnhancedSecurity が表示されます
ADL の取得結果が空のまま Checkpoint 4 Phase A を進めない	気づかないまま壊れたエージェントが作成されます
サイト名や URL パスのプレフィックスをハードコードしない	適切なターゲット LWR サイトは顧客の組織によって異なります。まず問い合わせてから判断してください
ESW プレフィックス付きのサイトをウィジェットのデプロイ先として提示しない	ESW_* サイトは内部 ESD エンドポイントの基盤です。ユーザーにサイトの選択肢を提示する前に、後処理で除外してください
Embedded Service Deployment は必ず Connect API 経由で V2 として作成し、Metadata のデプロイだけで作成しないでください。また、V2 ESD は experience_messaging:embeddedMessaging LWR コンポーネント経由で埋め込んでください	Metadata API はレガシー V1（WebV1、Setup では 「Web (v1)」）をデフォルトで使用するため、Enhanced Web Chat が機能しなくなります。v67.0 以降の Connect API で clientVersion: WebV2 を指定して作成してください。顧客ウィジェットは deploymentName をキーとする LWR コンポーネント経由でマウントされます。6つすべての属性の形式、Tooling-API によるパッチ適用方法、ゲストブラウザーでの検証については references/channel-web-chat.md を参照してください
Help Agent 専用の ADL を必ず作成し、標準の All_Records_and_Fields_Default ライブラリは決して接続しないでください	トライアル環境またはサンプルデータが事前ロードされた組織では、標準ライブラリが NOT_SCHEDULED のまま停止してインデックスが作成されません。エージェントを接続すると、実行時の knowledgeSummary が空になりますが、エラーは表示されません。Checkpoint 2 で Help_Agent_Knowledge を作成し、接続する前に indexingStatus ∈ {COMPLETED, READY, SUCCESS} になるまで待ってください
Embedded Service Deployment を公開し、チャネルを有効化せずに Checkpoint 4 を終えないでください	ウィジェットの提供には両方が必要です。ESD を Connect API の deployment/setup 呼び出しで作成した場合、すでに公開されています — 「Published on:」 が表示され、タイトルに (v1) のサフィックスがないことを確認してください
Web Chat、Help Portal、Voice には専用の分岐があります。それ以外の既存のチャネルタイプ（WhatsApp、SMS、Facebook、Apple Business Chat、Line、Email-to-Case、Custom）は service-agentforce-channel-configure を使って汎用的に接続します	検出（§4.3 Step 1）では、存在するすべてのチャネルタイプを提示する必要があります。ほかのタイプが存在するのに、専用の3つの分岐しか提示しないことを防ぐのが、このチェックポイントの目的です。Web Chat では、デプロイ後のアサーションを必ず実行してください（MessagingChannel を再取得して embeddedConfig.authMode をアサートします。デフォルトは UnAuth）。選択を誤ると、ゲストに表示されないウィジェットが気づかないままデプロイされます。authMode は値のみ（authMode: UnAuth）で報告し、アサーションの説明はしないでください。レガシーの esw.min.js / Live Agent V1 スニペットは決して出力しないでください

出力要件

成果物は単一の report.md です。これは設計書ではなく、決定された内容と実施した内容をまとめた状況レポートです。形式は2種類あります。フローでステップを実行した場合は、具体的に決定した値を表に記載する確定事項レポート、ユーザーが決定権を持つ判断段階にある場合は、選択肢を提示し、内容を捏造しない意思決定ガイドレポートです。意思決定セルで曖昧な表現（「後で記録」「保留」「作成予定」など）を使わないでください。不透明なIDを捏造しないでください。依頼の対象ではないチェックポイントに、障害をでっち上げないでください。完全なテンプレート、形式ごとのルール、1つの意思決定に関する説明（準備状況の順序、authMode）、および「決して含めてはならない」採点対象の失敗リストは references/output-report-format.md に記載されています。レポートを作成する前にお読みください。

参照ファイル一覧

ファイル	読むタイミング
assets/help-agent-spec.md	必ず最初に読む — フローの正式な仕様です。設計上の意図により小規模にまとめられており、以下のファイルへの参照があります
references/agent-script.md	エージェント作成時のみ（チェックポイント2の後）— エージェントスクリプトとプレースホルダーの正式な仕様です
references/channel-web-chat.md	チェックポイント3でユーザーが Web Chat を選択した場合のみ
service-concierge-portal-generate（外部スキル）	チェックポイント3でユーザーが Help Portal を選択した場合のみ — インラインで記述せず、委任してください
references/channel-voice.md	ユーザーが Voice を選択した場合のみ（PstnVoice チャネルを接続します。既存のものがない場合は調達を委任します）
references/output-report-format.md	最終的な report.md を作成する直前 — 2種類のレポート形式、テンプレート、採点対象の失敗リストを確認します