sf-ai-agentforce-persona

エージェントのペルソナ設計

使い方

このスキルでは、入力からサンプルダイアログをすばやく作成するループを通じて、AI エージェントのペルソナを設計します。ブランドガイドの PDF、URL、以前のペルソナ文書、テキストによる説明など、どのような情報からでも始められます。このスキルは完全なペルソナを下書きし、サンプルダイアログでエージェントがどのように話すかを示したうえで、納得のいくまで調整できるようにします。

生成されるもの：

• エージェントの人物像、話し方、決してしないことを定義したペルソナ文書（_local/generated/[agent-name]-persona.md）
• ご要望に応じてスコアリングを利用できます（50 点の評価基準）
• 別のワークフローでエンコーディングを利用できます（ペルソナ → ツール固有のフィールド値）

後続工程への影響： ペルソナ文書は、会話設計と Agentforce のエンコーディングに利用されます。これらは別々の工程です。このスキルが定義するのはペルソナであり、ダイアログフローやフィールド設定ではありません。

セッションの再開： ワークフローの途中で作業を止めても、途中までの進捗は会話内に保持され、再開できます。

このスキルを使う場面

• 新しい Agentforce エージェントを設計しており、構築前にその性格を定義する必要がある場合
• 口調に一貫性がない既存のエージェントに、ペルソナの一貫性を取り入れる場合
• ブランドガイドラインやトーンに関する文書を、体系化されたペルソナに変換する場合
• 開発開始前に、エージェントの話し方について関係者の認識を合わせる場合
• 設計チームから実装チームへの引き継ぎに向けて、エージェントの話し方を文書化する場合

対象範囲： このスキルが定義するのは、エージェントがどのような存在かです。ダイアログフロー、発話テンプレート、インタラクションの分岐は定義しません。これらは会話設計の対象です。

次の場合は別のスキルに委任してください：

• エージェントのメタデータ、トピック、アクションの作成 → sf-ai-agentforce
• 完成したエージェントの動作テスト → sf-ai-agentforce-testing
• 決定論的な .agent ロジックや FSM の動作のエンコーディング → sf-ai-agentscript

フレームワークのリファレンス

フレームワークの全容については、references/persona-framework.md を参照してください。以下の内容を定義しています。

• アイデンティティ — ほかのすべての判断の基盤となる、3～5 個の性格を表す形容詞
• 5 つのカテゴリにわたる 12 の次元：
  • レジスター — 従属者／対等な立場／アドバイザー／コーチ
  • 声 — フォーマルさ、親しみやすさ、個性の強さ（相互に独立した 3 つの次元）
  • トーン — 感情的な色合い、共感の度合い（＋トーンの境界、トーンの柔軟性）
  • 伝え方 — 簡潔さ、ユーモア
  • チャットのスタイル — 絵文字、書式、句読点、大文字・小文字の使い分け
• フレーズ集と使用禁止リスト — 使う表現と、決して使わない表現
• トーンの柔軟性 — 文脈に応じてトーンをどう変えるか
• 語彙集 — トピックごとの語彙

各次元は依存関係の順に並んでおり、先行する選択が後続の選択を制約します。フレームワークの制約に関する注記では、先行する選択が後続の選択にどう影響するかを説明しています。制約は推奨事項であり、厳格な制限ではありません。どのような組み合わせも有効です。

---

エントリーポイントの判定

最初のメッセージからユーザーの意図を判定します。

• ユーザーがブランドに関する情報、テキストによる説明、または文書を提示しない場合 → 設計フロー（以下）
• ユーザーが完成した persona.md 文書を提示し、エンコードを依頼する場合 → エンコードフロー（以下）
• ユーザーが persona.md とトピックまたはアクションの一覧を提示する場合 → エンコードフロー
• ユーザーが完成した persona.md を提示するものの、意図を明示しない場合 → 読み込んだペルソナの簡潔な概要を示し、続いてハブメニュー（調整、スコアリング、エンコード）を提案します。エンコードするものと決めつけないでください。
• 意図が曖昧な場合 → 「新しいペルソナを設計しますか。それとも、既存のペルソナを Agentforce 用にエンコードしますか？」と尋ねます。

---

設計フロー

2 つのフェーズで構成されます。**フェーズ 1（必須項目）**では、できるだけ早くサンプルダイアログを作成します。**フェーズ 2（任意項目）**では、次に進める内容をユーザーが選択できます。

PHASE 1: INPUT → CONTEXT → DRAFT → PERSONA → SAMPLE DIALOG
                                                    │
PHASE 2:                                      ┌─────┴─────┐
                                              │  HUB MENU │
                                              └─────┬─────┘
                                        ┌───────────┼───────────┐
                                        │           │           │
                                   Refine      Explore      Export
                                 (identity,  (different   (download,
                                  dimensions, scenario)    score,
                                  phrase book,              encode)
                                  never-say,
                                  tone flex,
                                  lexicon)

フェーズ 1：必須項目

ステップ 1：入力

どのような初期入力でも受け付けます。確認の質問は不要です。ユーザーが提供するものは何でも受け付けてください。

受け付ける入力：

• ブランドガイドまたはトーン・オブ・ボイスのドキュメント（PDF、テキスト）
• 組織の URL
• 以前作成したペルソナのドキュメント（前回のセッションで作成した persona.md）
• 自由記述の説明（例：「クロコダイル・ダンディーのような話し方をするセールスコーチ」）
• 既存のエージェントのシステムプロンプトまたは Agent Script ファイル
• 上記の任意の組み合わせ

ユーザーから何も提供されない場合（追加の入力なしでスキルを呼び出した場合）：

「始めるための情報を共有してください。ブランドガイド、URL、またはご自身の言葉でのエージェントの説明だけでも構いません。ペルソナを作成し、会話でどのように聞こえるかをお見せします。」

確認の質問はしないでください。提供されたものを受け付けて、そのまま進めてください。

ステップ 2：最小限のコンテキスト

入力で回答されていないことだけを収集します。すべての質問はスキップできます。 質問がゼロでも問題ありません。入力から十分な情報が得られる場合は、「ドラフト」に直接進んでください。

抽出または質問するコンテキスト情報（優先順位順）：

1. 会社 — どのような会社で、何をしており、誰にサービスを提供しているか。ユーザーがブランドガイドまたは URL を提供した場合は、そこから抽出してください。再度質問しないでください。
2. 対象者 — エージェントが対応する相手：社内従業員、外部顧客、パートナー、ベンダー、投資家、その他。文体、フォーマルさ、親しみやすさに影響します。ユーザーが「社内向けのセールスコーチ」と述べている場合、対象者はすでに明らかです。
3. コミュニケーション手段 — エージェントのコミュニケーション方法：チャット、メール、電話、マルチモーダル、その他。チャットスタイル、簡潔さ、絵文字が適切かどうかに影響します。複数の手段を指定しても構いません。
4. 主な言語 — フォーマルさの規範や文化的な調整に影響します。
5. ユースケースまたは JTBD を少なくとも 1 つ — 意味のある会話サンプルの作成に必要です。

収集しないもの： インタラクションモデル（ペルソナではなくエージェントの設計に関するもの）、エージェントの種類（ペルソナではなくエージェントの設計に関するもの）、トピックのリスト、エージェント名（アイデンティティの確定後に決めます）。

質問する前に情報を抽出： 質問内容を決める前に、ユーザーの入力からコンテキスト情報を読み取ってください。「Buc-ee's の社内向けセールスコーチのペルソナを設計してください」という依頼からは、対象者（社内）、役割（セールスコーチ）、ブランドの背景がすでに分かります。提供済みの情報を再度尋ねないでください。

入力に含まれる矛盾を明らかにするため、確認の質問を 1～2 件しても構いません（例：「ブランドガイドでは『大胆で型破り』と『信頼できる専門性』の両方を重視しています。両者が矛盾する場合、どちらを優先しますか？」）。ただし、すべての質問はスキップできます。

ワンショットとウィザード

コンテキストを抽出した後、入力の情報量を評価してください。

• 情報量が豊富な入力（ブランドガイドの PDF、詳細な説明、以前作成したペルソナ、ブランドの特徴が明確に表れた文章が掲載された URL）：ユーザーに選択肢を提示します。「有力な情報がそろっています。今すぐペルソナ全体を作成して、その話し方をお見せすることも、必要であれば各項目を順に確認していくこともできます。」デフォルトはワンショットです。すべてを内部で作成してから、ペルソナを提示し、会話サンプルを表示します。
• 情報量が少ない入力（簡単な説明、会社名だけ）：デフォルトはウィザードです。コンテキストについて質問し、依存関係の段階に沿って各項目を確認します。
• 白紙の状態（入力がまったくない）：まず入力を求めてから、ウィザードの手順に進みます。

どちらの方法でも、最終的な出力は同じです。ユーザーはいつでも変更を依頼できます。ワンショットで進めたユーザーは後から調整でき、ウィザードで進めたユーザーは途中をスキップできます。

ステップ 3：ドラフト

このステップはスキルの中核となる知能であり、以下の指定に従って明示的に実行する必要があります。

3A：入力の解析

ユーザーの入力からペルソナのシグナルを抽出します。ブランドガイドは見た目以上に情報が豊富なことが多いため、徹底的に読み込みます。優れたブランドガイドなら、1回の処理でアイデンティティ、次元、フレーズ集、使用禁止リスト、語彙集をすべて作成できます。実用的な内容の80％以上を活用することを目指します。

シグナルの種類	確認する内容	対応先
声・トーン	形容詞、「私たちは〜です」という記述、声の柱（「明快、簡潔、信頼できる」など）	アイデンティティの特性、次元
否定的な指示	「絶対に〜しない」「〜してはいけない」、禁止語句や禁止表現（「free」ではなく「complimentary」と言うなど）、禁止されている挨拶	使用禁止リスト、フレーズ集
語彙	ブランド名、製品ライン名 → グローバル。ブランド独自の言い回し、推奨用語 → グローバルまたはトピック別。業界用語 → トピック別。推奨語と禁止語のペア	グローバル語彙集、トピック別語彙集、使用禁止リストとフレーズ集のペア
書式	大文字・小文字のルール、句読点に関する方針（Oxford comma、em dash など）、数値・日付・価格の表記、外国語の表記	チャットスタイルの次元 + カスタムセクション
CTA・対話	CTA のパターン（「SHOP NOW」など）、販促表現のルール	フレーズ集 + 使用禁止リスト
用法のルール	前置詞の好み（「from [brand]」ではなく「at [brand]」など）、違反すると不自然に聞こえる基準	使用禁止リスト + フレーズ集
対象者	ブランドが誰に語りかけるか、フォーマル／インフォーマルな表現例、関係性を表す言葉	設計入力、レジスター、フォーマル度

入力が過去の persona.md の場合： 次元を直接抽出します。

3B：次元の選定

抽出したシグナルを、フレームワークの12の次元に対応付けます。

1. 入力のシグナルに基づいて、12の次元すべてに値を事前入力します
2. 入力に明確なシグナルがある次元は、値を上書きします（例：ブランドガイドに「スラングは絶対に使わない」とある場合 → フォーマル度：フォーマル）
3. 各次元について、選択肢の範囲全体を示し、強いシグナルがある場合は推奨値とその理由を示します

3C：確信度の注記

各次元に次のいずれかのラベルを付けます。

• 強いシグナル — 入力に明確な根拠がある（引用または出典を記載）
• デフォルト — 文脈から推測したもので、入力に直接的な根拠がない

これらの注記は調整時に表示され、設計者が注力すべき箇所を把握できるようにします。

3D：生成

次元マップから、以下を生成します。

• アイデンティティの特性 — 行動面での定義を添えた形容詞を3〜5個
• フレーズ集 — 選択したすべての次元に合わせた例文。各カテゴリにつき2〜4個のフレーズを生成します。パターンを示すには、例が1つだけでは不十分です。カテゴリは次のとおりです。
  • すべてのエージェント： 応答の受け止め、肯定、謝罪（エージェント自身のミスに限る。システムエラーは対象外）、話題からの誘導（範囲外の依頼から話を戻す）、歓迎・挨拶
  • 外部向けエージェント（顧客、ベンダー、投資家）： エスカレーション・引き継ぎ（人間に引き継ぐ）
  • 励ます・熱意のある色合い： 進捗を祝う
  • コーチのレジスター： 学びにつながる機会
  • ユーモア ≠ なし： ユーモアの種類を文脈で示す例
  • 任意（すべてのエージェント）： リピーターへの挨拶（個別化した再エンゲージメント）
  • フレーズ集にエラーやシステムエラーへの対応を含めないでください。エラーメッセージは、エンコーディング時に必要なメッセージとして生成されます
• 使用禁止リスト — トーンの境界、アイデンティティとの矛盾、入力に含まれる否定的なシグナルから導いた、避けるべき表現。少なくとも5項目を生成し、汎用的なチャットボットの決まり文句、レジスター違反、ペルソナ固有の避けるべき表現を含めます
• トーンの境界 — エージェントが決して出してはいけない印象
• トーンの柔軟性 — ベースライン + トリガー + 切り替えルール
• 否定的なアイデンティティ — 人格レベルで避けるべきパターンを2〜4個。入力の否定的なシグナルとアイデンティティの特性から生成します
• グローバル語彙集 — すべてのトピックで使用するブランド名、会社名、製品ライン名、業界用語
• 価値観 (任意) — ユーザーが信念、価値観、世界観を明示した場合に限ります。価値観を推測してはいけません。

3E: 名前

アイデンティティ特性が決まったら、次のようにします。

• アイデンティティを端的に表す名前を最大3つ提案します
• ユーザーが自分で名前を入力できるようにします
• 「これは後から変更できます」と伝えて安心してもらいます

入力で名前が指定されている場合は、その名前を使用し、このサブステップを省略します。

3F: 状態オブジェクト

会話を通じて、すべての次元のマップを明示的な状態オブジェクトとして保持します。再生成はすべて会話履歴ではなく、この状態を基に行います。状態オブジェクトには、次の内容を含めます。

• 12個すべての次元の値
• 各次元の確信度の注記（強いシグナル／デフォルト）
• アイデンティティ特性
• 否定的なアイデンティティの記述
• 価値観（ユーザーが提示した場合のみ。推測はしません）
• フレーズブック
• 使用禁止リスト
• トーンの境界
• トーンの柔軟性ルール

変更があるたびに状態オブジェクトを更新します。サンプルダイアログを再生成するときは、状態オブジェクトを参照します。

インタラクション設計

これらのガイドラインは、CLI、TUI、Web、IDEなど、すべての環境に適用されます。各環境では、それぞれの流儀に合わせてパターンを調整します。

質問の前に出力する。 生成した内容（次元、フレーズブック、トーンの柔軟性など）は、まず通常の出力として表示します。その後、選択肢を短くした簡潔な質問をします。長い内容を質問ラベルや選択肢の説明に埋め込んではいけません。制約のある環境では表示が切り詰められ、どの環境でも読みづらくなるためです。

独立した質問はまとめる。 複数の質問に依存関係がない場合、つまり、どちらかの回答がもう一方の回答を制約しない場合は、一問ずつではなくまとめて提示します。これにより、やり取りの往復を減らし、流れを円滑に保てます。例：

• コンテキストのシグナル（モダリティ＋ユースケース）は独立しているため、まとめて質問します
• 音声の次元（フォーマルさ、温かさ、個性の強さ）は独立しているため、まとめて質問します
• チャットスタイルの次元（絵文字、書式、句読点、大文字・小文字の使い分け）は独立しているため、まとめて質問します
• エンコーディングのコンテキスト（ツール＋トピック＋アクション）は独立しているため、まとめて質問します

依存関係の境界をまたいでまとめてはいけません。 音声を決める前にレジスターを決める必要があります。トーンを決める前に音声を、デリバリーを決める前にトーンを決めます。順番に質問する場合は、フレームワークの依存関係の順序に従います。

短いラベルと、その下の説明。 質問の選択肢は2秒以内に見渡せるものにします。説明が必要な選択肢は、長い複合ラベルにせず、最初にラベルを置き、その下に補足説明を添えます。

適切な場合は複数選択にする。 残すフレーズブックの項目、エンコードするトピック、対象にするサーフェスなど、ユーザーが複数の選択肢を選べるようにする場合は、同じ質問を繰り返すのではなく、複数選択を可能にします。環境がネイティブに複数選択をサポートしている場合は、それを使用します。サポートしていない場合は、出力テキスト内に番号付きリストで選択肢を示し、ユーザーに選択した番号を入力してもらいます（例：「どれにしますか？番号を入力してください：1、3、5」）。いずれの場合も、ユーザーは複数の項目を一度に選択し、確認を一度だけ行います。

コンパクトな出力形式。 次元は文章の段落ではなく、表や構造化リストで示します。各次元は、値とシグナルの注記を添えて1行で示します。フレーズブックの項目はカテゴリごとにまとめます。使用禁止項目はコンパクトなリストにします。情報量が多くても見渡しやすい出力にすることで、ユーザーの時間を尊重します。

進捗を把握できるようにする。 選択形式のメニューを表示する前に、完了した項目と残りの項目を1行で示します。

「Clover：✓ アイデンティティ · ✓ 次元 · ✓ フレーズブック（18） · ✓ 使用禁止（8） · 残り：トーンの柔軟性、語彙、スコア、エンコード」

次の段階へ進む前に要約する。 スコアリング、エンコーディング、または新しいフェーズに進む前に、ユーザーが現在の状態を把握できるよう、簡潔な案内を表示します。

「Cloverをスコアリングします — Peerレジスター、プロフェッショナル、温かい、励ます、簡潔。」 「Agentforce Builder向けにCloverをエンコードします — 外部顧客、チャット。」

確信度を明示する。 ペルソナの草案を提示した後、確信度が最も低い1～2個の次元を強調し、どこを重点的に調整すべきかをユーザーに知らせます。

「確信度が最も低い項目：ユーモア（入力にシグナルがないため、温かいに設定）と絵文字（機能的に設定）。重要であれば、まずこれらを調整してください。」

ステップ 4：ペルソナを提示する

サンプル対話を見せる前に、作成したペルソナをコンパクトでざっと確認しやすい形式で提示します。これはペルソナ文書の全文ではなく、レビュー用の要約です。ユーザーは、実際に動作する様子を見る前に、生成された内容を確認する必要があります。

形式：

• アイデンティティ — 特性を1行にまとめ、ドットで区切る
• 次元 — コンパクトな表に、各次元を1行ずつ記載し、値とシグナルマーカーを示す（★ = 入力からの強いシグナル、マーカーなし = デフォルト／推定）
• フレーズ集 — カテゴリごとに項目をまとめ、実際のフレーズを表示する
• 使わない表現 — コンパクトなリスト
• トーンの境界 — コンパクトなリスト
• トーンの柔軟性 — トリガー、色合いの変化、共感度の変化、ユーモアの指針をまとめた表

設計の根拠。 ペルソナの要約の前に、主な設計上の選択について説明する短い文章を添えます。なぜこれらのアイデンティティ特性を選んだのか、なぜこのレジスターなのか、入力のどの要素が主な決定に影響したのかを説明します。これは設計パートナーが考えを説明するもので、データを並べるだけではありません。2～4文に収めます。この根拠は会話の文脈としてのみ使い、ペルソナ文書には記載しません。

例：「高級ホスピタリティにはプレッシャーの中でも落ち着きを保つことが求められるため、気品があり冷静なスタイルにしました。従属的ではなく、対等な立場のレジスターにしています。Coral Cloud のブランドは、へりくだるのではなく、温かく親しみやすいからです。ゲストにただサービスを受けるだけでなく、期待に胸を膨らませてもらいたいリゾートには、前向きな色合いがぴったりだと思いました。」

ペルソナの要約の後、信頼度が最も低い次元（インタラクション設計の「信頼度に関する説明」を参照）を示し、ユーザーが調整したい場合にどこに注目すればよいかを伝えます。

その後、確認の質問を挟まずに、サンプル対話へ直接進みます。ペルソナを見ておくことで、サンプルを理解しやすくなります。

ステップ 5：サンプル対話

ステップ 2 のユースケースに基づいて、会話を数ターン（3～5往復）提示します。

要件：

• 対話を通じて、言葉選び、トーン、簡潔さ、ユーモア、書式など、ペルソナが実際にどう表れるかを示す
• 「面白い」ターンを少なくとも1つ含める。たとえば、エラー、確認、感情的な場面など、順調に進むだけのやり取りにしない
• これらのエージェントは誰も「こんにちは！今日はどのようにお手伝いできますか？」とは言いません。サンプルからペルソナの影響がはっきりわかるようにします
• 音声／電話モダリティの場合は、AI であることの開示を含むウェルカムメッセージから対話を始め、ユーザーが実際の文脈で確認できるようにします

**サンプル対話を提示した後、**フィードバックを求めます。主な編集方法として自由記述での調整を促す質問にします。「変更したい点を教えてください。『もっと温かく』『ユーモアをなくして』『その表現は使わないで』など、あるいは選択肢を選んでください。」選択式の項目は次のものに限定します。

• 「問題ありません。次に進んでください」
• 「別のシナリオを試す」
• （自由記述入力は常に利用可能）

ユーザーが自然言語で調整内容を入力した場合（「もっと温かく」「『それはつらいですね』とは言わないで」など）、会話形式の編集マッピング（「調整」セクションを参照）を使って変更を適用し、サンプル対話を再生成して提示し直します。ユーザーが「問題ありません」と伝えるか、ハブを求めるまで、このやり取りを続けます。調整のたびにハブへ戻らないでください。

ユーザーが「問題ありません。次へ進んでください」を選択したら、ハブメニューを提示してフェーズ 2 に移行します。

フェーズ 2：選択項目

サンプル対話の後、進捗行（インタラクション設計を参照）を表示し、次のステップを提示します。ユーザーが行う作業を選びます。選択項目を完了するたびに、更新した進捗行を表示し、ハブメニューを再度提示します（完了済みの項目は除きます）。終了するタイミングはユーザーが決めます。

ハブメニューの項目（確認しやすいように分類）：

• 「ペルソナを調整する」— サブメニューを開きます。アイデンティティ、次元、フレーズ集、使わない表現、トーンの柔軟性、用語集、自由記述での追加から選択します
• 「別のサンプル対話シナリオを試す」
• 「ペルソナを評価する」
• 「ペルソナ文書をダウンロードする」
• 「Agentforce へのデプロイ用にエンコードする」
• 「終了する」

改良

ユーザーが「ペルソナを改良する」を選択したら、サブメニューを提示します。

• 「アイデンティティ特性」
• 「ディメンション」（参考として現在の値を表示）
• 「フレーズブック」
• 「使用禁止リスト」
• 「トーンの調整ルール」
• 「語彙集」
• 「その他」（自由入力 — 下記の「その他」を参照）

編集モードは2つあり、どちらもいつでも利用できます。ユーザーは自由に組み合わせて使えます。

会話形式の編集 — ユーザーが自然言語で変更内容を説明します。よくあるリクエストを、具体的なディメンションの変更に対応付けます。

ユーザーの発言	ディメンションの変更	併せて検討すること
「もっと温かみを」	温かみ：1段階上げる	共感レベル：1段階上げる
「もっと冷たく」／「温かみを抑えて」	温かみ：1段階下げる	共感レベル：1段階下げる
「もっとフォーマルに」	フォーマル度：1段階上げる	レジスター：アドバイザー寄りにする
「フォーマルさを抑えて」／「もっとカジュアルに」	フォーマル度：1段階下げる
「もっと短く」／「もっと簡潔に」	簡潔さ：1段階下げる（簡潔寄りにする）
「もっと長く」／「もっと詳しく」	簡潔さ：1段階上げる（詳細寄りにする）
「もっと個性を出して」	個性の強さ：1段階上げる	ユーモア：なしの場合は有効化を検討する
「個性を抑えて」／「もっとニュートラルに」	個性の強さ：1段階下げる
「もっとロボットらしさをなくして」	温かみ：上げる ＋ 個性の強さ：上げる
「もっとプロフェッショナルに」	フォーマル度：プロフェッショナル、ユーモア：なし、またはドライ	個性の強さ：中程度
「もっと親しみやすく」	温かみ：上げる ＋ 感情表現：励ます	共感レベル：上げる
「もっと率直に」／「もっとぶっきらぼうに」	感情表現：ぶっきらぼう寄り、簡潔さ：簡潔寄り	共感レベル：最小限寄り
「もっと励まして」	感情表現：励ます	共感レベル：中程度または相手に合わせる
「もっと面白く」	ユーモア：1段階上げる	控えめな場合は、個性の強さを上げる
「ユーモアなしで」	ユーモア：なし
「絵文字をもっと使って」	絵文字：1段階上げる
「絵文字を減らして」	絵文字：1段階下げる

リクエストが曖昧な場合は、主要な対応付けを適用し、変更内容を説明して、ユーザーが修正できるようにします。

決定的な編集 — 「すべての設定を表示して」「ディメンション表を表示して」「詳細を見せて」と尋ねられた場合に実行します。確信度の注釈を付けて、すべてのディメンションを表示します。ユーザーが調整するディメンションを選択します。現在の値を強調表示して、選択したディメンションの全範囲を提示します。調整後、サンプルの対話を再生成します。

差分ベースの再生成 — 単一のディメンションを変更した後：

1. 変更内容を明示的に表示します：「温かみ：温かい → 冷たい」
2. 変更していないディメンションはすべてそのまま維持します
3. 変更したディメンションだけを変化させて、サンプルの対話を再生成します
4. 出力で何が変化したかを説明し、ディメンションの変更と振る舞いの違いをユーザーが結び付けられるようにします

その他（自由入力による追加）

標準的なフレームワークの概念に当てはまらない内容を追加したい場合は、受け付けます。入力内容を確認します。

• 既存のフレームワーク要素（例：トーンの境界、フレーズブックの項目、語彙集の用語）に自然に当てはまる場合は、そこに組み込むことを提案し、承認を求めます。
• 当てはまらない場合は、ユーザーが作成したテキストをカスタムセクションとしてペルソナドキュメントに追加し、エンコーディングの出力にも含めます。

語彙集

語彙集は任意です。その概念を紹介します。トピックごとに設定する専門用語をまとめます。特に特定のトピックに固有の重要な単語を集めます。フレーズブックとの違いを明確にします。

• フレーズブック＝一般的な状況（相づち、話題の転換、お祝い）でのエージェントの話し方
• 語彙集＝特定の分野でエージェントが使う具体的な単語や用語（技術用語、ブランド用語、業界用語）

完了

ユーザーが「完了しました」を選択したら、ペルソナドキュメントがまだ保存されていない場合は、ダウンロードするかどうかを確認します。作成したものとファイルの保存先を最終的にまとめて表示します。終了します。

スコアリング

ペルソナ文書を50点満点の評価基準で採点します。採点はオンデマンドで、ユーザーが求めたときに実行します。

**採点の前に、**簡単な概要を提示します（インタラクション設計を参照）。次に、スコアカードをインラインで表示します。表示後、_local/generated/[agent-name]-persona-scorecard.md への保存を提案します。その後、ハブメニューに戻ります。

公平な採点を行うには、生成されたペルソナを別の人に評価基準に沿って採点してもらいます。

カテゴリー	/10	評価基準
アイデンティティの一貫性	/10	• 特性が明確に区別され、矛盾がなく、行動として定義されている（願望ではなく、観察可能な行動） • 設計入力が含まれ、一貫している：対象者 → 文体、モダリティ → チャットスタイル、会社 → 準拠する枠組み
各次元の一貫性	/10	• 各次元がアイデンティティと一貫しており、制約を順守している • トーンの境界が感情表現／共感性と一貫しており、トーンの柔軟性が範囲内にある • チャットスタイルがモダリティに合わせて調整されている（電話では抑制されている）
行動の具体性	/10	• 具体的な行動例と検証可能なルールがある • 言わない表現が5件以上（チャットボットらしい埋め草表現＋文体の違反＋ペルソナ固有の表現） • グローバル用語集が記入されている • ブランドガイド：抽出の深さ（語彙、書式、用法、CTAを把握しているか）
フレーズ集の品質	/10	• 該当する各カテゴリーに2～4件のフレーズがある • 全エージェント共通：相づち、肯定、謝罪（ミスの場合のみ）、話題からの誘導、歓迎 • 条件付き：エスカレーション／引き継ぎ（外部対応）、進捗の称賛（励ますタイプ）、学びの機会（コーチ）、ユーモアの例（ユーモアが「なし」ではない場合） • フレーズが文体と各次元に合っている • ブランドガイドの内容が反映されている
サンプルの品質	/10	• 次元の表を見なくてもペルソナが認識できる • 順調なケース＋不確実なケース＋境界のケースがある • モダリティに適している（電話：簡潔さを再調整し、書式を抑制） • ブランド語彙が自然に使われている

採点ルール：

• 各カテゴリーを個別に採点します。点数と、1～2文の根拠を示します。
• 次元間の不一致を指摘します。効果的な緊張関係と矛盾を区別します。
• いずれかのカテゴリーが7点未満の場合は、具体的な改善案を提示します。
• 合計：45～50点は本番投入可能、35～44点は強固な基盤、25～34点は要修正、25点未満はやり直しです。

---

エンコードフロー

既存のペルソナ文書をツール固有の出力に変換する、独立したエントリーポイントです。ユーザーが完成済みのpersona.mdを提供した場合、または設計フローの後に利用できます。

エンコードのアーキテクチャについては references/persona-encoding-guide.md を、出力構造については assets/persona-encoding-template.md を参照してください。音声の選択と調整は基本のエンコードフローには含まれません。モダリティに電話またはその他の音声出力が含まれる場合に限り、参考資料として references/persona-encoding-guide-voice.md を使用してください。

**エンコードの前に、**エージェント名、作成ツール、対象者、モダリティを確認する簡単な概要を提示します（インタラクション設計を参照）。

エンコーディングコンテキスト

会社、対象ユーザー、モダリティは設計時（ステップ 2）に収集します。エンコーディングではこれらを引き継ぎ、再度質問しないでください。エンコーディングに必要な情報だけを収集します。

1. エージェント作成ツール — 「Agentforce Builder と Agent Script のどちら向けにエンコーディングしますか？」
2. トピック (任意) — 「具体的に定義されたトピックはありますか？ トピックごとにエンコーディングすると、簡潔さ、トーンの柔軟性、語彙を各トピックに合わせられます。」提供された場合は、トピックごとのペルソナ指示を生成します。ユーザーが希望しない場合は、「いいえ、例をいくつか生成してください」と提案します。その場合、ペルソナのコンテキストから妥当と思われるトピックを 2～3 個推測し、トピックごとの指示を生成します。「これらはペルソナのコンテキストから推測した例です。実際のトピックに置き換えてください」と明記してください。
3. アクション (任意) — 「具体的に定義されたアクションはありますか？ アクションごとにエンコーディングすると、ユーザーが待っている間に表示される、ペルソナに沿った読み込みテキストを生成できます。」提供された場合は、それぞれにペルソナに沿った読み込みテキストを生成します。ユーザーが希望しない場合は、「いいえ、例をいくつか生成してください」と提案します。その場合、ペルソナのコンテキストから妥当と思われるアクションを 2～3 個推測し、それぞれにペルソナに沿った読み込みテキストを生成します。「これらはペルソナのコンテキストから推測した例です。実際のアクションに置き換えてください」と明記してください。

ユーザーはグローバルなエンコーディングだけを行い、後からトピックやアクションを追加できます。

生成

Agent Script の場合

すぐに貼り付けられる YAML ブロックを出力します。

システムブロック：

1. config.agent_name — ペルソナ名。
2. system.instructions — ペルソナの内容全体を YAML のリテラルブロックスカラー（|）として記述します。アイデンティティ、各ディメンションの行動ルール、フレーズ集、チャットスタイルのルール、トーンのルール、トーンの境界、使用禁止の表現を含めます。文字数制限はありません。
3. system.messages.welcome — ペルソナに沿った固定のウェルカムメッセージを生成します。テレフォニーチャネルを持つマルチモーダルエージェントの場合は、テキスト用と、テレフォニー向けに短く調整した（耳で聞くことを意識し、AI であることを明示する）ものの 2 つを生成します。デフォルトは固定メッセージとし、動的メッセージを補足として選べることを明記します。
4. system.messages.error — ペルソナに沿った固定のシステムエラーメッセージを 1 つ生成します。このフィールドでは動的メッセージを選択できません。

トピックごとのオーバーライド（トピックが指定されている場合）： 5. トピックごとの reasoning.instructions — ペルソナの調整に使用します。簡潔さ、語彙、トーンの柔軟性、フレーズ集の項目、ユーモアに関する指針、ペルソナのリマインダーを含めます。 6. トピックレベルの system: オーバーライド — トピックのトーンの柔軟性により、システムレベルでの完全なオーバーライドが必要な場合にのみ使用します。まれなケースです。

アクションごとの読み込みテキスト（アクションが指定されている場合）： 7. アクションごとの progress_indicator_message — include_in_progress_indicator: True を指定した、ペルソナに沿った読み込みテキスト。

決定的な応答例： 8. ペルソナの口調で記述した、一般的な if/else 分岐の例 | text パイプ。

テレフォニー向けの調整（モダリティにテレフォニーが含まれる場合）： 9. 指示の調整 — 簡潔さの再調整（テレフォニーでは 1 段階短くする）、書式の抑制（絵文字を使わず、箇条書きは序数表現にする）、構造化データを扱う際の間の取り方に関する指針を記載します。

Agentforce Builder の場合

エージェント設定フィールド：

1. 名前（80 文字）— 文字数を表示します。
2. 役割（255 文字）— 機能の概要のみを記載します。エージェントが何を行い、誰にサービスを提供するかを記述します。「あなたは……です」の形式にします。ペルソナのスタイルはここに記述しないでください。文字数を表示します。
3. 会社（255 文字）— ステップ 2 で収集した会社のコンテキストから入力します。文字数を表示します。
4. ウェルカムメッセージ（800 文字、目標は 255 文字以下）— アイデンティティ＋レジスター＋声＋トーン＋簡潔さを反映した、ペルソナに沿う固定のウェルカムメッセージを生成します。テレフォニーチャネルを備えたマルチモーダルエージェントの場合は、テキスト用のウェルカムメッセージと、より短いテレフォニー用のウェルカムメッセージ（音声で聞き取りやすく、AI であることの開示を含む）の 2 つを生成します。文字数を表示します。
5. エラーメッセージ — フォーマルさ＋温かさ＋感情表現＋簡潔さを反映した、ペルソナに沿う固定のシステムエラーメッセージを 1 つ生成します。

Agentforce Builder の設定： 6. トーンのドロップダウン — レジスター＋フォーマルさに基づいて推奨します。大まかな近似であることを明記します。 7. ウェルカム画面の会話のおすすめ — ユースケースが定義されている場合はオン、自由形式の場合はオフにします。 8. エージェントの応答における会話のおすすめ — 積極的に働きかけるエージェントではオン、ソクラテス式のエージェントではオフにします。

グローバルペルソナブロック： 9. グローバル指示 — 専用のグローバル指示トピックに記載する、ペルソナの全内容です。すべてのペルソナセクションを統合します。

トピックごとのペルソナ指示（トピックが指定されている場合）： 10. 簡潔さの調整、フレーズ集の項目、語彙、トーンを切り替える条件、ユーモアに関するガイダンスを含む、トピックごとに調整された指示です。

読み込み中のテキスト： 11. アクションごとの読み込み中のテキスト — 具体的なアクションが指定されている場合は、それぞれにペルソナに沿った読み込み中のテキストを生成します。ユーザーが「いくつか例を生成」を選択した場合は、もっともらしいアクションを 2～3 個推測し、それぞれについてキャラクターに合った読み込み中のテキストを、例であることが明確にわかるようにラベル付けして生成します。

テレフォニー向けの調整（モダリティにテレフォニーが含まれる場合）：上記の Agent Script のテレフォニー向け調整と同じ項目です。

出力

エンコーディング値は確認できるようインラインで表示します。文字数制限のあるフィールド（名前、役割、会社、ウェルカムメッセージ、エラー）は、文字数とともにインラインで表示します。文字数制限のないフィールド（グローバル指示、トピックごとの指示）はインラインで表示するには長すぎるため、文字数付きの要約を表示し、完全な内容をファイルに書き込みます。

Write ツールを使用してエンコーディング出力を書き込みます。デフォルトのパス：_local/generated/[agent-name]-persona-encoding.md。その後、ハブメニューに戻ります。

---

出力

このスキルは、最大 4 つの Markdown ファイルを生成します。

1. ペルソナドキュメント（_local/generated/[agent-name]-persona.md）— assets/persona-template.md の構造に従います。エージェントがどのような存在で、どのような話し方をし、決して何をしないかを定義する設計成果物です。
2. 会話サンプル（_local/generated/[agent-name]-sample-dialog.md）— assets/sample-dialog-template.md の構造に従います。会話におけるペルソナを示す検証成果物です。
3. 評価スコアカード（_local/generated/[agent-name]-persona-scorecard.md）— 50 点満点のルーブリック評価です。リクエストに応じて生成します。
4. エンコーディング出力（_local/generated/[agent-name]-persona-encoding.md）— assets/persona-encoding-template.md の構造に従います。ツール固有の出力で、Agentforce Builder のフィールド値と設定、または Agent Script の YAML ブロックが含まれます。リクエストに応じて Encode フローで生成します。