mcpField
S
service-itsm-teams-employee-agent-configure

service-itsm-teams-employee-agent-configure

github.com/forcedotcomエージェントワークフロー1.1k1.2k 回インストール1 日前に更新
リポジトリ

service-itsm-teams-employee-agent-configure について

Microsoft Teams ITSM クライアント内で埋め込み Agentforce Employee Agent が返信できるよう、Messaging-in-App-and-Web 環境を構築するスキルです。API で認証、ルーティング、デプロイ、Agent アクセスを設定します。

主な機能

  1. 01検証付きメッセージングチャネルの構成
  2. 02ルーティングフローとフォールバックキューの設定
  3. 03Teams_AgentForce デプロイの作成と公開
  4. 04ポータルユーザーへの Agent Access 付与
  5. 05トークンとルーティング経路の検証

活用シーン

  1. 01Teams ITSM で Agent の返信を有効化
  2. 02従業員 Agent のメッセージングデプロイを構成
  3. 03Teams で参加後に返信しない Agent の診断

MCP 対応

このスキルは設定に Salesforce API を使用します。README には MCP サーバーまたはクライアントとの関係は記載されていません。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/forcedotcom/sf-skills --skill service-itsm-teams-employee-agent-configure

インストール後、Claude Code で/service-itsm-teams-employee-agent-configureを入力して読み込まれたか確認します。

同梱ファイルassets/Teams_AgentForce.EmbeddedServiceConfig-meta.xmlreferences/teams-embedded-employee-agent.md

詳細

Microsoft Teams に埋め込まれた Agentforce Employee Agent を設定する

埋め込み Agentforce エージェント(「IT Service Employee Agent」)が、Microsoft Teams の ITSM カスタムクライアント(「Salesforce Employee Assist」→「Ask AI Agent」)内で実際に応答するようにします。Teams カスタムクライアントは実行時に、esDeveloperName を使って Messaging-in-App-and-Web(MIAW)デプロイメントを読み込みます。この値は、コミット済みの Core 設定(service-cloud-requestor-agent-miaw.configuration.json/Teams アプリマニフェスト)で Teams_AgentForce に固定されています。そのため、Embedded Service Deployment の名前は正確に Teams_AgentForce にする必要があり、組織ごとに変更することはできません。

Teams ITSM で最も難しく、ドキュメントも不足している部分です。実際の組織で動作を確認した、ゼロから構築するための詳しい手順は次のとおりです。

→ references/teams-embedded-employee-agent.md

手順は一度に1つずつ実行してください。 これらの手順では、実際に状態を変更する API 呼び出しが行われます。1つの操作を実行し、その結果を表示して、成功したことを確認してから次に進んでください。複数のセットアップ呼び出しを1つの並列ブロックにまとめて実行しないでください。

対象範囲

  • 対象:Teams カスタムクライアントが読み込む MIAW チャネルとデプロイメントを、API のみ(設定 UI のクリック操作なし)で構築します。ユーザー検証が ON(認証モード = Auth)に設定された Web 拡張メッセージングチャネル、その認証を支える Enhanced Chat User Verification Key Set(PublicKeyCertificateSet、タイプ JWKS_URL、エンドポイント <Org>/id/keys、発行者 = Employee Site URL)、Teams_AgentForce カスタムクライアント Embedded Service Deployment、さらに、routeWork アクションのターゲットとして実在する Active 状態の Agentforce Employee Agent を指定する Omni-Flow ルーティングフローを構築します。ポータルユーザーにエージェントへのアクセス権を付与する Agent Access 権限セットを作成して割り当てます(これが、エージェントが実際に応答するようにする手順です)。API を使ってトークン/ルーティングの連鎖を最初から最後まで検証し、「参加後に退出する/応答がない」という症状を診断します。
  • 対象外:Teams 機能の Salesforce Go ページでのトグル有効化、および Azure/SSO/名前付きクレデンシャルの設定(service-itsm-teams-configure)。従業員ポータル/サイトの作成(experience-portal-create)。認証 ON + Key Set の連鎖と Agent Access の割り当てをすべて確認済みで、それでもセッションがキューに割り当てられたままエージェントが応答しない場合に限った、Agentforce エージェント独自の GenAI プランナー/Omni-Channel プレゼンス/キャパシティの修正。この残存ケースはエージェントの実行時の問題であり、Agentforce Employee Agent チームの担当です(参考資料の「参加後に退出する」セクションを参照してください)。

前提条件

  • Teams ITSM 機能が有効で、従業員ポータルサイトが稼働していること(先に service-itsm-teams-configure と experience-portal-create を実行してください)。Employee Site URL(例:https://<org>.my.site.com/empPortal)と、組織の My Domain URL が必要です。
  • 実在する Active 状態の Agentforce Employee Agent があること(SELECT Id FROM BotDefinition WHERE Type='InternalCopilot' AND AgentType='AgentforceEmployeeAgent' を実行し、Active 状態の BotVersion があることを確認してください)。存在しない場合は、先に作成してください。service-cloud-it-service-employee-agent Go 機能を有効にすると自動でプロビジョニングされる場合がありますが、保証はされません(検証結果:ある組織では機能が有効になったものの、何もプロビジョニングされませんでした)。デプロイする確実な方法は service-itsm-agentic-setup-employee-agent-configure です(提供されている Employee テンプレートの Agent Script を読み込み、NGA ネイティブのバンドルとしてエージェントを作成・公開・有効化します)。同等の基盤となる方法は、EmployeeCopilot__AgentforceEmployeeAgent に対して ITSM Connect の agent-templates install + activate を実行することです。まずエージェントをデプロイしてから、このスキルを実行して Teams に埋め込んでください。両方の方法と注意事項については、参考資料の「前提条件:IT Service Employee Agent が存在している必要があります」セクションを参照してください。

「エージェントが参加してから退出する」原因(構築前にお読みください)

チェーン全体が正常につながっている場合にのみ、エージェントは応答します。どこかのリンクが欠けていると、「エージェントが会話に参加した後、退出し、応答しない」という典型的な症状が発生します。以下はすべてこのスキルで修正できます:

#要件欠けている場合の症状修正方法
1チャネルの認証モードが「Auth」であり(User Verification が ON)、Key Set が関連付けられている/unauthenticated/access-token → BAD_REQUEST「Set the auth mode to false」(認証が ON でも Key Set がない → クライアントが未認証エンドポイントにフォールバック);または /eventrouter/v1/sse で 401(Key Set のエンドポイントまたは issuer が間違っている)JWKS_URL Key Set(endpoint <Org>/id/keys、issuer = Employee Site URL)を関連付け、チャネルにリンクします。認証を OFF にしないでください
2ポータルユーザーに、IT Service Employee Agent を有効にする Agent Access 権限セットがあるトークンが発行され SSE が接続されるものの、エージェントが参加してから、ConversationEntry が 0 件のまま退出するAgent Access → エージェントを含む権限セットを作成して割り当てます
3Teams_AgentForce ESD が存在し、公開されているSELECT Id FROM EmbeddedServiceConfig WHERE DeveloperName='Teams_AgentForce' → 0 行。Teams は存在しないデプロイメントを読み込めませんAPI タイプの ESD をメタデータデプロイし、Connect で公開します(手順 3)

**これは、このスキルの以前のバージョンの説明を覆すものです。**以前のバージョンでは、User Verification を OFF にし、Key Set を決して関連付けないよう指示していました。これは、認証を ON にしたのに Key Set を忘れたビルドでの診断結果でした。そのため、Teams クライアントは未認証エンドポイントを使用し、「Set the auth mode to false」というエラーが発生しました。検証済みで、製品として推奨されている修正は 認証 ON + JWKS_URL Key Set です(稼働中のスクリーンショットで確認済み)。これにより、クライアントはチャネルが想定する認証済みトークンフローを使用します。

認証 ON + Key Set、Agent Access の割り当て、ESD の作成と公開をすべて確認しても、エージェントがまだ応答しない場合は、Agentforce Employee Agent チーム(エージェントの Omni プレゼンス/キャパシティ/GenAI プランナー)へ最後の手段としてエスカレーションする前に、service-itsm-teams-debug に引き継いでください(その AGENTFORCE 合否チェックリストで、トークン/ルーティング/ESD/エージェントのチェーン全体を確認できます)。検証済みの組織では、上記の修正可能な原因を解消するだけで十分でした。

検証済みの手順(概要 — API のみで完了し、手作業は不要です。XML 全体と API 呼び出しはリファレンスを参照してください)

次の順序でデプロイします — 最初に Key Set、次にそれを参照するチャネル、最後に ESD です。 すべてのデプロイで、--api-version 67.0 を指定した分離環境の sfdx-project.json を使用します。一度に 1 つずつ手順を実行してください。

  1. Enhanced Chat User Verification Key Set — <type>JWKS_URL</type>、<jwksEndPoint> = <Org_Url>/id/keys、<jwtIssuer> = Employee Site URL を指定した PublicKeyCertificateSet をメタデータデプロイします。ディレクトリは PublicKeyCertificateSet/、サフィックスは .PublicKeyCertificateSet-meta.xml にする必要があります。 (JWKS_URL はエンドポイント URL モードです。Jwks はアップロード済みキーのモードで、URL は受け付けません。)
  2. Messaging channel、デプロイタイプは Web、ドメインは Employee Site URL — sessionHandlerFlow が IT Service Employee Agent を対象とするルーティングフロー、sessionHandlerQueue がフォールバックキュー(例:chatqueue)となる MessagingChannel(messagingChannelType=EmbeddedMessaging)をメタデータデプロイします。User Verification を ON にして、次のブロックで Key Set をリンクします。 <embeddedConfig><authMode>Auth</authMode><messagingAuthorizations>…publicKeyCertificateSetName…</messagingAuthorizations></embeddedConfig> ESD を公開する前に、チャネルを有効化します(MessagingChannel.IsActive=true)。ルーティングフローとフォールバックキューは前提条件です。Route_To_MIAW_AEA がテンプレートからインストールされている場合は、プレースホルダー ID が設定されているため、参照先を変更してください。存在しない場合は、作成してください。sfdc_livemessage Omni サービスチャネルは標準で、事前に存在します(作成せず、クエリで確認してください)。リファレンス §A/§E/§F を参照してください。
  3. Teams_AgentForce Embedded Service Deployment(ESD)を作成 — Teams クライアントが esDeveloperName で読み込むデプロイです。手順 2 のチャネルを参照する <messagingChannel> を含む、名前が正確に Teams_AgentForce の API タイプ ESD をメタデータデプロイし、次のエンドポイントに POST を送信して公開します。 POST /services/data/v67.0/connect/embeddedservice/embeddedserviceconfig/publish/<esdId> ({} → isSuccess:true。公開ルートは v67.0 です。)リファレンス §C/§D を参照してください。この ESD がない場合、ログインは成功してもエージェントは応答しません。 次のクエリで確認してください。 SELECT Id FROM EmbeddedServiceConfig WHERE DeveloperName='Teams_AgentForce'(Tooling)。
  4. 権限セットを作成(例:「Agent Access」)し、IT Service Employee Agent を有効にして、ポータルユーザーに割り当てます(RBAC による権限付与です。割り当て前に確認してください)。リファレンス §G を参照してください。
  5. まったく新しい Teams チャットから再テストします — 既存のセッションは、引き続き古いデプロイに紐付けられています。

POST /connect/service-itsm/createMessagingChannel は使用しないでください。独自のデフォルト設定が強制されるため、フロー/キュー/開発者名と、認証および Key Set の正確な接続を制御できるよう、チャネルは自分で作成してください。正確な API 本文、オブジェクト名、検証クエリ、注意事項の全一覧はリファレンスを参照してください。

関連スキル

スキル代わりに使用する場面
service-itsm-teams-configureSalesforce Go ページのトグルで Teams 機能を有効にし、Azure/Entra アプリおよび SSO/Named Credentials を設定する場合 — 最初に実行してください。このスキルから、埋め込みエージェントの設定のためにこのスキルへ引き継がれます
experience-portal-createこのスキルで URL を使用する従業員サービス用ポータル/サイトを作成する場合
service-itsm-teams-debug構築済みのエージェントが応答しない理由(またはその他の Teams ITSM の問題)を診断する場合 — AGENTFORCE の合否チェックリストを実行し、修正策を報告します
service-itsm-channels-coordinateTeams、Slack、Swarming、Notifications、Portal を横断するトップレベルのメニュー

コメント