sf-ai-agentforce-conversationdesign について
sf-ai-agentforce-conversationdesignは、Salesforce Agentforceのエージェントを設計・改善するチーム向けの対話設計手法、ガイド、テンプレートです。ペルソナ、トピック、指示、会話フロー、安全対策、エスカレーション、120点満点の品質評価を扱います。
主な機能
- 01エージェントのペルソナとトーン設計
- 02トピック構成と分類方法
- 03階層型の指示作成フレームワーク
- 04会話フローと発話テストの設計
- 05エスカレーション・安全対策・品質評価
活用シーン
- 01新規エージェントの対話構造を設計
- 02既存エージェントを評価し改善を計画
- 03トピック分類のテスト発話を作成
- 04エスカレーション条件と安全境界を定義
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ jaganpro/ sf-skills --skill sf-ai-agentforce-conversationdesignインストール後、Claude Code で/sf-ai-agentforce-conversationdesignを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
CREDITS.mdLICENSEREADME.md.claude/hooks.yamlassets/escalation-matrix.mdimprovement-plan.mdpersona-document.mdquality-scorecard.mdtopic-architecture.mdutterance-library.csvhooks/scripts/instruction-quality-validator.pyreferences/anti-patterns.mdcontinuous-improvement.mdconversation-patterns.mdescalation-patterns.mdguardrail-hierarchy.mdhealthcare-escalation.mdindustry-frameworks.mdinstruction-writing-guide.mdpersona-design-guide.mdquality-assessment.mdquality-metrics.mdretail-topic-architecture.mdscoring-rubric.mdservice-agent-persona.mdtopic-architecture-guide.md詳細
SF-AI-Agentforce-ConversationDesign スキル
「ユーザーが会話に失敗するのではありません。会話がユーザーを失望させるのです。」
会話設計とは、自然に感じられ、問題を効率的に解決し、予期しない事態にも適切に対応するエージェントとのやり取りを設計する技術です。このスキルでは、業界のフレームワーク(Google、IBM、PatternFly)とSalesforce固有の実装パターンを組み合わせ、体系的な会話設計手法をSalesforce Agentforceに導入します。
⚡ クイックスタート
新しいエージェントを作成しますか? こちらから始めてください。
- ペルソナを設計する → ペルソナ設計ガイド
- トピックを設計する → トピックアーキテクチャガイド
- 指示を書く → 指示の作成ガイド
- 設計を評価する → 品質スコアカード
既存のエージェントを改善しますか? こちらから始めてください。
📚 ドキュメントマップ
Tier 1 — まずはこちら
| ドキュメント | 目的 |
|---|---|
| このファイル(SKILL.md) | 評価基準、手法の概要、基本原則 |
| README.md | クイックスタート、前提条件、導入 |
Tier 1.5 — リファレンスガイド(抜粋)
| ドキュメント | 目的 |
|---|---|
| 評価基準 | 8カテゴリにわたる詳細な基準表 |
| 品質評価 | 評価プロセス+簡易ヘルスチェック |
| 継続的な改善 | 反復サイクル、KPI、発話分析 |
Tier 2 — 設計ガイド
| ドキュメント | 目的 |
|---|---|
| ペルソナ設計ガイド | エージェントの個性、トーン、コミュニケーションスタイルの定義方法 |
| トピックアーキテクチャガイド | ボトムアップのトピック設計、分類の説明、スコープの境界 |
| 指示の作成ガイド | すべきこと、すべきでないこと、例を含む3段階の指示フレームワーク |
Tier 3 — リファレンス資料
| ドキュメント | 目的 |
|---|---|
| 会話パターン | IBMの5つのパターンとAgentforce実装の対応 |
| 業界フレームワーク | Google、IBM、PatternFly、Salesforceのフレームワーク対応 |
| アンチパターン | よくある間違い、その例と修正方法 |
| ガードレールの階層 | 安全性を確保する4層のガードレールモデル |
| エスカレーションパターン | トリガーカタログとOmni-Channelルーティング |
| 品質指標 | KPIの定義、ベンチマーク、測定方法 |
Tier 4 — テンプレートと例
| ドキュメント | 目的 |
|---|---|
| ペルソナドキュメント | 記入式のペルソナテンプレート |
| トピックアーキテクチャ | トピックマッピング用ワークシート |
| 発話ライブラリ | 発話を体系的に収集するためのテンプレート |
| エスカレーションマトリックス | エスカレーション判断マトリックス |
| 品質スコアカード | 120点満点の評価テンプレート |
| 改善計画 | 優先順位付けされた改善テンプレート |
| サービスエージェントのペルソナ | 例:SaaSカスタマーサービスのペルソナ |
| 小売トピックアーキテクチャ | 例:小売エージェントのトピック階層 |
| ヘルスケアのエスカレーション | 例:ヘルスケアのエスカレーションマトリックス |
🏆 スコアリングシステム(120 点)
8 つのカテゴリすべてについて、基準ごとの詳細な内訳は references/scoring-rubric.md をご覧ください。
カテゴリの概要
| # | カテゴリ | 点数 | 配点比率 |
|---|---|---|---|
| 1 | ペルソナとトーン | 15 | 12.5% |
| 2 | トピックアーキテクチャ | 20 | 16.7% |
| 3 | 指示の品質 | 20 | 16.7% |
| 4 | ダイアログフローの設計 | 15 | 12.5% |
| 5 | 発話の網羅性 | 15 | 12.5% |
| 6 | エスカレーションの設計 | 15 | 12.5% |
| 7 | ガードレールと安全性 | 10 | 8.3% |
| 8 | 継続的な改善 | 10 | 8.3% |
| 合計 | 120 | 100% |
評価スケール
| 評価 | スコア範囲 | 説明 |
|---|---|---|
| A | 108-120 | 本番環境に対応できる、卓越した設計 |
| B | 96-107 | 優れた設計、軽微な不足あり |
| C | 84-95 | 適切だが、的を絞った改善が必要 |
| D | 72-83 | 大きな不足があり、本番環境に対応できない |
| F | <72 | 大幅な再設計が必要 |
🎭 ペルソナの設計
ペルソナは、エージェントの性格、コミュニケーションスタイル、行動上の制約を定義するものであり、一貫性がありブランドに沿ったやり取りの基盤となります。
ペルソナの構成要素
- アイデンティティ — 名前、役割、部門、対象ユーザー
- トーンのレジスター — カジュアル、中立、またはフォーマル(Agentforce の設定)
- 性格特性 — 応答スタイルを形作る 3~5 個の特性
- コミュニケーションスタイル — 文の長さ、語彙レベル、共感の示し方
- 制限事項 — エージェントが明確に行わないこと
- メッセージ — ウェルカムメッセージとエラー/フォールバックメッセージ(各 <=800 chars)
Salesforce での実装
Agent Builder → Agent Settings → Instructions (Agent-Level)
Agent Builder → Agent Settings → Tone (Casual/Neutral/Formal)
Agent Builder → Channels → Welcome Message / Error Message
ペルソナは主にエージェントレベルの指示に記述します。入社初日の新入社員を指導するように書きましょう。具体的な作業手順ではなく、その人がどのような人物で、どのようにコミュニケーションを取るかに重点を置きます。
詳細: ペルソナ設計ガイド | テンプレート: ペルソナドキュメント | 例: サービスエージェントのペルソナ
🏗️ トピックアーキテクチャ
トピックは、ルーティング用の分類説明に基づいて関連するアクションをまとめます。ボトムアップで設計します。すべてのアクションを列挙 → ユーザーの意図ごとに分類 → 分類説明を記述 → 意味上の区別が明確かテスト、の順で進めます。
アーキテクチャのルール
| ルール | ガイドライン | 理由 |
|---|---|---|
| トピック数 | エージェントあたり <=10 | トピックが多いほど、分類の曖昧さが増します |
| トピックあたりのアクション数 | トピックあたり <=5 | トピックの焦点を絞り、テストしやすくします |
| 分類の重複 | 共通する語彙を <30% にする | 類似したトピック間での誤ルーティングを防ぎます |
| スコープの境界 | 対象外の項目を明示的に列挙する | 不明な意図に対するハルシネーションを防ぎます |
分類説明
エージェント設計で最も重要な文章です。ルーティングの精度を左右します。
✅ GOOD: "This topic handles questions about existing order status, including
tracking information, estimated delivery dates, and order modification
requests. It does NOT handle new order placement or returns."
❌ BAD: "Order stuff"
テスト: 2 つの説明を読んだだけで、どの発話がどちらに該当するかすぐに判断できますか?
詳細: トピックアーキテクチャガイド | テンプレート: トピックアーキテクチャ | 例: 小売業向けトピックアーキテクチャ
✍️ 指示の作成
指示は 3 つのレベルで機能します。エージェントレベル(ペルソナ、全体ルール、200~500w)、トピックレベル(ワークフローのロジック、100~300w)、アクションレベル(呼び出す条件と方法、50~150w)です。
コア原則
- 決定論よりガイダンス — あらゆる判断をハードコードするのではなく、推論を導きます。「共感を優先し、2~3回のやり取りで解決しない場合はエスカレーションする」とし、怒りを示すキーワードごとにスクリプトを作成するのは避けます。
- 肯定的な表現 — 「アカウントの詳細にアクセスする前に、必ず本人確認を行ってください」とし、「本人確認をせずにアクセスしてはいけません」とはしません。
- ビジネス原則を示し、決定木にしない — 指示にしきい値を伴う
if...then...elseが含まれる場合は、Flow/Apex に記述します。 - ハードコードではなくナレッジ — ポリシーには Knowledge アクション(RAG)を使用し、指示にポリシーの文面を直接記載しないでください。
詳細: 指示の作成ガイド
🔄 対話フローパターン
すべての会話は、6段階のライフサイクルに従います:挨拶 → 分類 → 情報収集 → 処理 → 応答 → 終了。
主な設計ルール:
- 段階的な情報提示:1回の応答につき選択肢は最大2~3個にします。選択肢がそれ以上ある場合は、まず条件を絞り込む質問をします。
- コンテキストの保持:以前のやり取りを参照し、すでに提供された情報を再度尋ねないようにします。
- エラーからの復旧:すべての段階について、確認を求めるプロンプト、曖昧さを解消する手順、適切なフォールバックを定義します。
- 明確な終了:達成した内容を要約し、追加のサポートを提案して、会話のトーンに合った別れの言葉を伝えます。
📝 発話の設計
発話はトピックアーキテクチャのテストケースであり、分類の説明によって正しく振り分けられることを検証します。
カテゴリと目標数
| カテゴリ | 目的 | トピックごとの目標数 |
|---|---|---|
| 通常ケース | 主な意図を明確に表現 | >=5 |
| 類義表現 | 別の語彙で表現 | >=3 |
| 境界ケース | 曖昧、複数の意図を含む | >=2 |
| 敵対的ケース | インジェクション、操作(全体) | >=5 |
| 対象範囲外 | 一致してはならない(全体) | >=5 |
**プロセス:**実データ(CRM のケース、チャットログ)から始める → 類義表現を考案する → 境界ケースを追加する → 敵対的ケースを含める → Testing Center でテストする → 失敗をもとに反復改善する。
テンプレート: 発話ライブラリ
🚨 エスカレーションの設計
エスカレーションは失敗ではありません。お客様が必ず解決にたどり着けるようにする安全策です。
トリガーカタログ
| トリガーの種類 | 条件 | 優先度 |
|---|---|---|
| 明示的な要求 | お客様が人間のエージェントを希望 | P1 |
| 安全性 | 自傷、脅迫、緊急事態、法的問題 | P1 |
| 感情 | お客様の不満や怒り | P2 |
| 複雑さ | 解決に至らないまま6回を超えるやり取り | P2 |
| ポリシー | 要求がエージェントの権限を超えている | P2 |
| 技術的問題 | アクションの失敗、システムエラー | P3 |
エスカレーション時には、会話の記録、お客様の識別情報、問題の概要、実施したアクション、エスカレーションの理由を引き継ぎます。Agentforce には、Omni-Channel 経由で振り分ける事前構築済みの Escalation Topic が用意されています。
詳細: エスカレーションのパターン | テンプレート: エスカレーションマトリックス
🛡️ ガードレールと安全性
安全性は4つのレイヤーで確保します:Einstein Trust Layer(プラットフォーム — 有害性の検出、PII のマスキング、自動処理)、Topic Classification(第一の防御策としての対象範囲の境界)、Instructions(行動上の制約 — 「法律や医療に関する助言を決して提供しない」)、Flow/Apex(ビジネスルールの決定論的な適用)。
重要なルール: 安全性が特に重要な判断を、指示だけに頼って行ってはいけません。指示は確率的なものです。金額の上限、コンプライアンスチェック、承認ゲートは必ず Flow または Apex に実装してください。
詳細: ガードレールの階層
📊 品質評価と継続的改善
評価プロセスの全容と、5つの質問による簡易ヘルスチェックについては、references/quality-assessment.md を参照してください。
Monitor → Analyze → Fix → Retest → Deploy の反復サイクル、KPI の目標値、発話分析のプロセスについては、references/continuous-improvement.md を参照してください。
⚠️ アンチパターン
| # | アンチパターン | 影響 | 対策 |
|---|---|---|---|
| 1 | 否定的な指示 | LLM の推論を混乱させます | 肯定的な表現に言い換えます |
| 2 | 過度な制約 | 硬直的で壊れやすい応答になります | 指針となる原則を使います |
| 3 | 指示へのビジネスルールの記載 | 適用に一貫性がなくなります | Flow/Apex に移します |
| 4 | モノリシックなトピック | 分類の精度が低下します | 焦点を絞ったトピックに分割します |
| 5 | 分類の重複 | 誤った振り分けにつながります | 説明を明確に区別します |
| 6 | エスカレーション経路の不足 | 会話が行き詰まります | すべての失敗モードに対するトリガーを定義します |
| 7 | 発話テストの欠如 | 分類が未検証になります | 発話ライブラリを作成します |
| 8 | ポリシーのハードコーディング | 情報が古くなります | Knowledge アクションを使います |
| 9 | コンテキストの無視 | 同じ質問を繰り返すことになります | 会話の状態を活用します |
| 10 | ハッピーパスのみのテスト | 本番環境で壊れやすくなります | エッジケースと敵対的なケースをテストします |
詳細: アンチパターン — 修正前後の例をすべて確認できます。
🔗 チェーン統合
このスキルは Agentforce 開発チェーンの最初のステップです。
| このスキルから | スキルへ | 引き継ぐ内容 |
|---|---|---|
| トピックアーキテクチャ | sf-ai-agentscript | トピック名、アクション、分類の説明 |
| 指示セット | sf-ai-agentscript | エージェントスクリプト用の3段階の指示 |
| 発話ライブラリ | sf-ai-agentforce-testing | マルチターンテスト用のテストケース |
| エスカレーションマトリクス | sf-flow | エスカレーションフローのロジック |
| アクション定義 | sf-apex / sf-flow | アクション実装の要件 |
📎 クレジットと参考資料
- Google の会話デザインガイドライン
- IBM のナチュラル・カンバセーション・フレームワーク
- Red Hat の PatternFly AI デザインシステム
- Salesforce の会話型 AI デザインガイド
- Salesforce Architect:エージェント型パターンと分類体系
クレジットの詳細は CREDITS.md をご覧ください。