Salesforce 管理者が Agentforce でトピック、アクション、ガードレールを設定する方法

Salesforce のシステム管理者が Agentforce で自律型エージェント（autonomous agents）を設定する際は、Agentforce Builder 内で構造化された業務領域、実行可能なビジネスツール、および多層型のガバナンス制御を確立します。決定論的なディシジョンツリーに従う従来のルールベースのチャットボットとは異なり、Agentforce は Atlas Reasoning Engine に依存してユーザーの意図を動的に解釈し、行動計画を策定し、自律的にタスクを実行します。これらの自律型エージェントが企業の境界内で確実かつ安全に動作することを保証するために、管理者は 3 つの基本的な構成要素を設定する必要があります。それは、作業の分類と範囲を定義するトピック（topics）、ビジネスロジックを実行するアクション（actions）、そして行動制約、データプライバシー、人間へのエスカレーションパスを適用するガードレール（guardrails）です。

アーキテクチャの基盤：Atlas Reasoning Engine

自律型エージェントを効果的に設定するには、管理者は Agentforce がユーザーとの対話をどのように処理するかを理解する必要があります。Agentforce の中核にあるのは Atlas Reasoning Engine であり、継続的な「推論・行動・観察」（reason-act-observe）ループを通じてエージェントの行動を調整します。

• 意図分類（Intent Classification）： エンドユーザーが問い合わせを送信すると、Atlas はエージェントに割り当てられたすべてのアクティブなトピックの分類説明と照らし合わせてメッセージを評価します。
• コンテキストの組み立て（Context Assembly）： トピックが選択されると、Atlas はそのトピックの自然言語による指示、利用可能なアクション、会話履歴、および Salesforce CRM や Data Cloud を通じて取得された関連顧客データを取り込みます。
• 計画の策定（Plan Formulation）： 推論エンジンは、ユーザーのリクエストを満たすためにどのアクション（必要な場合）が求められるかを評価し、会話から抽出する必要があるパラメータを決定します。
• アクションの実行と観察（Action Execution and Observation）： エージェントは選択されたアクション（在庫レコードの照会やケースステータスの更新など）を実行し、返された出力を観察します。追加のステップが必要な場合、エンジンは目標が達成されるかエスカレーション境界がトリガーされるまで推論を続けます。

Atlas はスクリプト化された対話ツリーに従うのではなく動的に推論するため、管理者は静的な分岐パスを構築する必要がありません。その代わりに、管理者は境界、ツール、および目標を定義し、エンジンが解決に向けた最適なパスを自律的に探索できるようにします。

ステップ 1：Agentforce Builder でのトピック（Topics）の設定

トピックはエージェントの主要な機能領域として機能します。関連する機能をグループ化し、コンテキストを提供し、エージェントが動作を許可される境界を定義します。

Builder へのアクセスとトピックの作成

1. Salesforce の 設定（Setup） で、「クイック検索」（Quick Find）ボックスを使用して Agentforce Agents（リリース構成によっては Einstein Agents）に移動します。
2. リストから対象のエージェントを選択し、Open in Builder をクリックします。
3. Agentforce Builder の左側のナビゲーションパネルで、Topics タブを選択します。
4. New Topic をクリックしてカスタムトピックを一から作成するか、標準の事前構成済みドメインテンプレート（Order Management、Billing Inquiries、Case Escalation など）から選択します。

トピックメタデータと分類スコープの定義

各トピックには、Atlas Reasoning Engine が受信プロンプトをどのようにルーティングするかに直接影響する 3 つの重要な設定フィールドが必要です。

• トピック名（Topic Name）： ビジネス機能を識別する明確で説明的なラベル（例：Billing_and_Invoices や Appointment_Scheduling）。
• 分類説明（Classification Description）： どのユーザー意図、クエリ、リクエストがこのトピックに該当するかを説明する詳細なセマンティック解説。Atlas は意図の類似度を計算する際にこの説明に大きく依存します。例えば、「請求に関する質問」のような短いラベルではなく、次のように記述します：「顧客の請求書、請求履歴、支払い方法、領収書のリクエスト、請求に関する異議申し立て、サブスクリプション更新料金に関する問い合わせを処理する。」
• スコープ（Scope）： エージェントがこの領域内で解決できることと解決できないことの概要を示す簡潔な要約。これは、モデルが推論を開始する際の即時コンテキスト境界として機能します。

トピックレベルの指示（Instructions）の作成

トピックの指示は、トピックがアクティブになった後にエージェントが従うべき具体的な行動ガイドラインと手順ステップを提供します。管理者は、明確で命令形の自然言語で指示を作成する必要があります。

• 順序のガイダンス（Sequential Guidance）： 標準的な操作手順を概説します（例：「1. 顧客に注文 ID（Order ID）を尋ねる。2. 注文 ID が既存のレコードと一致することを確認する。3. 配送ステータスを取得し、配達スケジュールを要約する。」）。
• 条件ロジック（Conditional Logic）： 特定のシナリオに対する処理ルールを定義します（例：「注文ステータスが『配達完了』であるにもかかわらず、顧客が荷物を受け取っていないと述べている場合は、荷物紛失のエスカレーションフローを開始する。」）。
• スタイルとトーンの指示（Style and Tone Directives）： コミュニケーションの好みを指定します（例：「簡潔でプロフェッショナルな回答を提供する。請求書の項目を説明する際は、専門用語を避ける。」）。

管理者は焦点を絞った設計を目指すべきです。通常、エージェントあたり 10〜15 個の個別のトピックを設定し、分類説明間のセマンティックな重複を最小限に抑えることで、エンジンが迷ったりリクエストを誤分類したりしないようにします。

ステップ 2：アクション（Actions）のアタッチと設定

アクションは、エージェントが情報を取得し、レコードを作成または更新し、外部のビジネスロジックを実行するために呼び出す機能ツールです。アクションがなければエージェントは会話することしかできませんが、アクションがあればエージェントは実際の作業を実行できます。

管理者が利用可能なアクションの種類

管理者は、トピックにいくつかのタイプのアクションをアタッチできます。

アクションパラメータとメタデータの設定

トピックにアクションを追加する際、管理者は正確な自然言語による説明を用いてパラメータ定義を設定する必要があります。

1. アクションの選択： トピック詳細ビューで Add Action をクリックし、対象の Flow、Apex メソッド、プロンプトテンプレート、または外部サービスを検索します。
2. アクションの説明の定義： そのアクションが何を達成し、いつ呼び出すべきかについての明確な説明を提供します。Atlas はこの説明を読み取って、アクションが現在の推論計画のステップに適合するかどうかを判断します。
3. 入力パラメータのマッピング： 必要な各入力パラメータ（caseId、customerId、billingZipCode など）について、エージェントが進行中の会話コンテキストから値を抽出するか、ユーザーに直接要求するか、静的なシステム変数を渡すかを指定します。
4. 出力処理の定義： エージェントがアクションの戻り値をどのように処理するかを設定します。出力を要約メッセージとしてユーザーに直接返すか、後続のアクションのコンテキストとして推論ループに戻すかを指定します。
5. 確認の要求（状態変更操作）： 支払いの処理、契約のキャンセル、スケジュールされたサービス予約の削除など、機密性が高い操作や元に戻せない操作については、管理者は確認要件を有効にして、エージェントがアクションを実行する前にユーザーに明示的に確認を求めるように強制できます。

ステップ 3：多層型ガードレール（Guardrails）の実装

自律型エージェントには、ハルシネーション、データ漏洩、ポリシー違反、不正なデータ変更を防ぐための強固なガバナンスが必要です。管理者は、会話の指示、決定論的ロジック、アクセス権限、プラットフォームの信頼制御という 4 つの異なるレイヤーにわたってガードレールを実装します。

1. 自然言語による指示を通じた会話ガードレール

第一の防御線は、トピックの指示内で否定的な制約を明示的に述べることです。管理者は、指示を従業員に与える標準作業手順書（SOP）のように扱う必要があります。

• 明示的な禁止事項： エージェントが決して行ってはならないことを明確に規定します（例：「スーパーバイザーの承認なしに、50 ドルを超えるクレジットや返金を約束してはならない。」）。
• プライバシーの保護： 機密性の高い顧客の入力の処理方法をエージェントに指示します（例：「顧客に完全なクレジットカード番号、銀行口座情報、または政府発行の身分証明書番号を求めてはならない。顧客がこれらの情報を自発的に提供した場合でも、会話の中で繰り返してはならない。」）。
• 円滑なエスカレーションのトリガー： エージェントが処理を停止し、Omni-Channel を介して人間の担当者に顧客を引き渡す必要がある正確な基準を指定します（例：「ユーザーが法的措置に言及した場合、管理職との対話を 2 回要求した場合、または侮辱的な言葉を使用した場合、直ちに Transfer to Agent アクションを呼び出す。」）。

2. 決定論的ロジックのガードレール

LLM は会話のニュアンスを理解することに優れていますが、ミッションクリティカルな計算や決定論的なビジネスポリシーは、決して生成的な推測に委ねるべきではありません。管理者は、重要なロジックを決定論的なコードに移行することで、厳格な境界を適用する必要があります。

• 計算と検証に Flows と Apex を使用する： 顧客生涯価値に基づいて割引が厳格な階層に従う必要がある場合は、計算を自動起動フロー（Autolaunched Flow）または Apex メソッド内にカプセル化します。生成的に割引を計算させるのではなく、エージェントにそのアクションを呼び出させます。
• 出力の検証： レコードがデータベースにコミットされる前に、入力規則とフローの決定要素を使用して無効な入力パラメータを拒否します。

3. 権限とアクセス制御のガードレール

Agentforce エージェントは、特定の実行コンテキスト内でアクションを実行します。管理者は、エージェントのアイデンティティ全体で最小権限の原則を徹底する必要があります。

• 専用のエージェントユーザーとプロファイル： すべてのエージェントは専用の Salesforce ユーザーレコードの下で動作します。管理者は、そのエージェントの運用範囲専用に調整されたプロファイルと権限セットを作成する必要があります。
• オブジェクトレベルおよび項目レベルセキュリティ（FLS）： エージェントの権限セットが、割り当てられたトピックに必要な特定の標準オブジェクトおよびカスタムオブジェクトに対する Read または Edit アクセス権のみを付与していることを確認します。Modify All Data や広範な管理者権限を決して付与してはなりません。
• 共有ルール（Sharing Rules）： エージェントユーザーが組織全体のデフォルト（OWD）およびロールベースの共有ルールを遵守し、承認されたテリトリーや部門以外の顧客レコードを取得できないことを確認します。

4. プラットフォームレベルのガードレール：Einstein Trust Layer

Agentforce は Salesforce の Einstein Trust Layer 上で動作し、管理者の設定を最小限に抑えながら組み込みのセキュリティ機能を提供します。

• データの保持ゼロ（Zero-Data Retention）： Einstein Trust Layer は、サードパーティの基盤モデルがプロンプトで送信されたエンタープライズ顧客データを保持したり、それに基づいてトレーニングを行ったりしないことを保証します。
• 自動化されたデータマスキング： 個人を特定できる情報（PII）—社会保障番号、メールアドレス、電話番号など—は、プロンプトが Salesforce の信頼境界を離れる前に自動的に検出され、マスキングされます。
• 有害性およびプロンプトインジェクションの防御： 受信したユーザー入力と生成されたモデル出力は、有害な言葉、ヘイトスピーチ、およびエージェントの指示をハイジャックしようとするプロンプトインジェクション攻撃についてスキャンされます。
• 監査証跡とオブザーバビリティ： 取得されたグラウンディングデータ、送信されたプロンプト、モデルの中間推論、最終的な応答を含むすべての対話は、コンプライアンスとガバナンスのレビューのために Data Cloud の監査レコードにログ記録されます。

ステップ 4：テスト、オブザーバビリティ、および継続的な改善

エージェントを実際の顧客向けまたは社内向けのチャネルに導入する前に、管理者はその推論パスを検証し、指示を改善する必要があります。

会話プレビューパネルの使用

Agentforce Builder には、管理者がリアルタイムで会話をシミュレートできるインタラクティブな Preview パネルが含まれています。

1. 「ハッピーパス」のテスト： 標準的なユーザーからの問い合わせを入力して、エージェントが意図を正しく分類し、適切なトピックを選択し、対応するアクションを呼び出すことを確認します。
2. 推論トレースの検査： プレビューウィンドウの推論サマリーをクリックして、エージェントの内部思考プロセスを確認します。どのトピックが選択されたか、どの指示が応答に影響を与えたか、および呼び出されたアクションにどの入力パラメータが渡されたかを検査します。
3. エッジケースとガードレールのテスト： スコープ外の問い合わせ、曖昧なリクエスト、敵対的なプロンプト（エージェントに指示を無視させたり内部システム設定を開示させたりするなど）を意図的に送信します。エージェントがスコープ内に留まり、会社の方針を適切に引用するか、人間の担当者にエスカレーションすることを確認します。

本番環境での導入と監視

設定とサンドボックスでのテストが完了したら、次の手順を実行します。

• チャネルの有効化： エージェントをアクティブ化し、Salesforce Service Cloud Messaging、Experience Cloud サイト、モバイルアプリ、社内 Slack ワークスペースなどの導入チャネルに割り当てます。
• Agentforce Command Center： たわみ率（自己解決率）、トピックの分布、アクションの成功率、エスカレーションの頻度などのリアルタイムのパフォーマンス指標を監視します。
• 継続的なプロンプト調整： エージェントが時期尚早にエスカレーションしたり意図を誤分類したりしたセッションログを確認します。トピックの分類説明を改善し、明確化のための否定的な指示を追加して、時間の経過とともに曖昧さを排除します。

きめ細かなトピックを体系的に定義し、堅牢な呼び出し可能アクションを付与し、多層型のガードレールで保護することにより、Salesforce のシステム管理者は生成モデルを信頼性の高い自律型デジタルワーカーへと変革し、企業基準を保護しながら組織の効率性を高めることができます。