bolna-voice-prompt

Bolna 音声プロンプトエンジニアリング

このスキルは、GPT-4.1 mini で動作する Bolna 音声エージェント向けに、本番環境で使えるプロンプトを作成します。形式は意図的に厳密に定められています。GPT-4.1 mini は通話時にこれらのプロンプトを実行するため、構造、変数表記、言語の順序が少しでも逸脱すると、信頼性が低下します。このファイルのルールは、動作を支える重要な要素として扱ってください。

このスキルの対象範囲

ユーザーが開始する、次の 2 つのワークフローを扱います。

1. ユースケースの説明から新しいプロンプトを作成する。 ユーザーが通話のシナリオ（採用スクリーニング、予約受付、NPS、更新、見込み顧客の適格性確認など）と、事前に読み込む変数があればその内容を説明します。出力：以下の正確な構造に従った完全なプロンプト。
2. トランスクリプトをもとに既存のプロンプトを修正する。 ユーザーが通話トランスクリプト（現在のプロンプトを添える場合もあります）を貼り付け、問題点を指摘します。出力：修正したセクション、または短い変更メモを添えた更新済みプロンプト全体。診断方法については references/transcript-workflow.md を参照してください。

エージェントの性別、主な言語、または通話の主な目的がユーザーの説明から明確でない場合は、作成前に要点を絞った質問を 1 つしてください。この 3 点が明確であれば、そのままプロンプト全体を作成してください。通話の方向、役職名、支店の対応範囲など、合理的に推測できる事項についてユーザーに次々と質問しないでください。

作成前：静的モジュールを必ず読み込む

セクション 1 の 2 つのサブセクション、# Conversational Naturalization (Acknowledgements & Flow Softening) と # Pronunciation and Script Normalisation は、すべてのプロンプトに一字一句そのままコピーする必要があります。references/static-modules.md を読み、新しいプロンプトに内容を貼り付けてください。これらのモジュールを言い換えたり、要約したり、短縮したり、「改善」したりしないでください。調整済みの内容であり、変更するとエージェントの動作に支障が出ます。

必須のセクション構成

すべてのプロンプトは、必ず以下の順序で構成してください。セクション番号は省略できません。セクション 1 では、必ず以下に示す名前のサブセクションを使用します。フローセクション（3 以降）には、その役割を示す名前を付けます。

SECTION 1: IDENTITY AND DEMEANOUR

セクション 1 は全体に適用され、以降のすべてを規定します。本番環境では SECTION 1: IDENTITY AND DEMEANOUR と SECTION 1: DEMEANOUR AND IDENTITY の両方が使われており、どちらも問題ありません。いずれかを選び、プロンプト全体で統一してください。SECTION 1: Demeanour & Identity（大文字と小文字が混在し、& を含む形式）も有効です。セクション名とサブセクション名では & も使用できます（下記の「特別な書式」を参照）。

# で始まる次のサブセクションを使用してください。以下が標準的な順序ですが、本番用プロンプトでは Tone と Goal の順序を入れ替えたり、Identity と Tone の間に Context や Environment を挿入したりすることがあります。各サブセクションの役割が明確であれば問題ありません。

• # Identity — 固定の角括弧付きラベルを記したヘッダー行で始まり、その後に説明文を置きます。ヘッダー行には、本番環境で使われている次の 2 つの形式があります。
  • You are [Agent_name: Shivani], [Gender: Female]
  • [Agent_name: Juhi], [Gender: Female] ここでの角括弧はラベル付きメタデータの慣例であり、コンテキスト変数ではありません。取得した値を当てはめようとしないでください。続く段落では、エージェントの役割、代理する会社、および通話全体を通じて変わらないアイデンティティに関する声明（AI であることを開示しない条項を含む）を記載します。
• # Tone — エージェントの話し方を 3〜4 行で説明します。クライアントのブランドイメージに合わせてください。プロフェッショナル、温かみのある、落ち着いた、自信のある、敬意のこもった、といった表現を用います。
• # Goal — 通話の主要な目的を、行動を示す形で 1 つ記載します。状況によって目的が異なる場合（例：面接の確認と日程変更）は、それぞれの目的を明記してください。
• # Guardrails — エージェントが必ず行うこと、決して行ってはならないこと、避けるべきことなど、厳格な行動上の境界を定めます。クライアント固有の制限（例：「Section 8 に記載のない料金は決して伝えない」）と、固定ルール（感嘆符を使わない、長々と話し続けない）を含めてください。
• # Language — 主に使う言語、副次的に使う言語、通話開始時に使う言語、および切り替えルールを記載します（通常は、発信者が話す言語に合わせ、通話中に発信者が言語を切り替えた場合はエージェントもそれに応じて切り替えます）。
• # Conversation Structure and Flow — 通話開始から終了までの進行、必須ステップと任意ステップの区別、FAQ や関連質問への対応後にメインの流れへ戻る方法、および前のセクションを再開してはならないことを記載します。
• # Handling Customer Queries — エージェントが返答前に話を聞くこと、回答を現在のセクションの目的に沿わせること、確認が必要な場合はそのまま繰り返すのではなく丁寧に言い換えること、範囲外の質問は上級担当者に引き継ぐことを記載します。この見出しの名詞（および Section 1 全体で使う名詞）は発信者の役割に合わせます。Porter では # Handling Partner Queries、Zepto／CureFoods の採用では # Handling Employee Queries、OEG では # Handling Candidate Queries、upGrad では # Handling Learner Queries を使用してください。プロンプト全体で発信者を表す名詞を 1 つ選び、一貫して使用します。

続いて、次の静的モジュールを追加します（references/static-modules.md からそのままコピーしてください）。

• # Conversational Naturalization (Acknowledgements & Flow Softening)
• # Pronunciation and Script Normalisation

静的モジュールの後に、ユースケースに必要な Section 1 の追加サブセクションを加えます。本番環境で使われている任意のサブセクションには、次のものがあります。

• # Context — 通話状況を簡潔に説明します（Whizzy、Zepto、CureFoods のような採用関連プロンプトで使用）。
• # Environment — 発信者が置かれていると考えられる環境を簡潔に説明します（Whizzy、Announcements で使用）。
• # Ambiguous Response Handling、# Speech Style、# Eligibility Criteria、# Edge Cases、# Discount Logic、# Objection Handling、# Upsell Triggers、# Numeric Expression Rules、# For Hindi Conversation（Schoolini で使われる、ヒンディー語での話し方を調整するパターン）。ユースケースに応じて必要なものを選んでください。

セクション 2：会話の開始

必須のすべての言語で、定められた順序（最初にヒンディー語／ヒングリッシュ、次に英語、3番目にその他の言語）で書かれた冒頭のセリフと、それに続く指示ブロックです。このセクションは必ず含めます。

セクション 3 以降：ユースケースのフローセクション

番号を順番に付け、内容に基づいて名前を付けます。たとえば、SECTION 3: INTENT DETECTION、SECTION 4: BASIC DETAILS COLLECTION、SECTION 5: ELIGIBILITY CHECK、SECTION 6: APPOINTMENT BOOKINGなどです。ここには、実際の質問、分岐、振り分けを含めます。

セクション X：クロージング

常に最後から2番目のセクションです。複数の分岐（BRANCH A: Successful Close、BRANCH B: Not Interested、BRANCH C: Rescheduling、BRANCH D: Wrong Numberなど）を設け、それぞれ対応する結果に基づいて名前を付けます。

セクション X：コンテキスト（必要な場合）

価格、製品カタログ、場所のデータ、ポリシーの事実をまとめた、構造化された JSON ナレッジベースです。フロー内で情報を参照する必要がある場合にのみ含めます。形式については references/section-templates.md に記載されています。

セクション X：FAQ（常に最後）

厳密な YAML 形式です。形式については references/section-templates.md に記載されています。

冒頭のセリフ、質問、クロージング、分岐の正確な形式を含むセクションテンプレートについては、references/section-templates.md を参照してください。

変数表記 — 混在させない

変数の種類は厳密に2つです。混在させると通話が機能しなくなります。

• 事前読み込み変数：通話前に判明しており、CRM／バックエンド／API から渡されます。アンダースコアを含む波括弧で表します：{full_name}、{contact_number}、{appointment_date}。波括弧内にスペースを入れないでください。
• コンテキスト変数：通話中に発信者の応答から取得するもの、または内部フラグを立てるために使うものです。アンダースコアを含む角括弧で表します：[name]、[contact_number]、[preferred_time]、[wants_callback]。角括弧内にスペースを入れないでください。

事前読み込み変数は、ユーザーが明示的に指定したものだけを使用してください。 余分な変数を作らないでください。ユースケースで必要なデータがユーザーから指定されていない場合は、会話内でコンテキスト変数として取得してください。

よくあるパターンとして、質問の冒頭で事前読み込み変数からコンテキスト変数に値を割り当てます。例：You have the values [name] = {referee_name}. これにより、値の取得元を明示しながら、以降のプロンプトで [name] を簡潔に参照できます。

スクリプトテキストの形式

スクリプトのセリフ（冒頭、質問、クロージング、定型応答）はすべて、定められた順序で両方の言語に記載します。ヒンディー語（またはヒングリッシュ）が常に最初、英語が常に2番目、その他の言語があれば3番目です。この順序を逆にしてはいけません。

Opening (Hindi): [Devanagari script]
Opening (English): [English text]

Question 1 (Hindi): [Devanagari script]
Question 1 (English): [English text]

Closing (Hindi): [Devanagari script]
Closing (English): [English text]

ユースケースが明示的にヒングリッシュ（ヒンディー語と英語を混ぜ、主にデーヴァナーガリー文字で書き、ローマ字の単語を含める形式）の場合は、ラベルを (Hindi) ではなく (Hinglish) とし、引き続き最初に記載します。

ヒンディー語の行でのデーヴァナーガリー文字のルール

• ヒンディー語の行はデーヴァナーガリー文字で記述します。
• インドの日常会話でよく使われる英語由来の単語は、ヒンディー語の行の中でもローマ字のままにします：app、WhatsApp、form、session、login、OTP、link、email、call、number、register、confirm、please、thank you、okay、sorry。これらを音訳しないでください。
• ヒンディー語の文で発音する頭字語は、1文字ずつデーヴァナーガリー文字で表記します。例：SSC → एस एस सी、UPI → यू पी आई、EMI → ई एम आई。（より広範なルールは # Pronunciation and Script Normalisation モジュールで扱います。）

スクリプトテキスト内の数字

スクリプトのセリフと FAQ の回答に含まれる数字はすべて、前後の言語に合わせて単語で表記します。「5000ルピー」ではなく「5000ルピー相当の金額を言葉で表記」します。「30パーセント」ではなく「30パーセント相当の割合を言葉で表記」します。「6か月」ではなく「6か月相当の期間を言葉で表記」します。料金、期間、割合、年齢、距離、給与額、試験の得点など、発話されるすべての数字に適用します。変数名や技術的な参照（例：Section 4 Question 3）の数字は、数字のままにします。

電話番号と識別子の数字の並びは、1桁ずつ読み上げ、references/reusable-modules.md のルールに従ってください。

指示文の作成ルール

スクリプト内の各セリフの後には、指示ブロックを続けます。指示は連続した段落形式の文章で記述します。指示段落内では、箇条書き、番号付きリスト、ダッシュ、その他いかなる形式の列挙も使用しません。

各指示はInstruction:（またはInstructions:。どちらも参考プロンプトで使用されていますが、1つのプロンプト内ではどちらかに統一してください）で始めます。指示には、次の内容を含めます。

• セリフの目的（この質問をする理由）。
• 想定される発信者の反応と、その解釈方法。
• あいまいな回答、回答の辞退、説明の要求、言語の不一致といったエッジケースへの対応。
• 正確なルーティングロジックを文章で記述します。例：「発信者が肯定的に回答した場合は、Section 4, Question 2 に進みます。辞退した場合は、Section 7, Branch B に進みます。対象外の質問をされた場合は、シニアカウンセラーに簡潔に対応を委ねてから、Section 4, Question 1 に戻ります。」

指示は受動態で記述し、発信者には見えないようにします。指示自体に言及してはいけません（「指示にあるように」は禁止です）。ヒンディー語が多く含まれるプロンプトでも、指示はすべて英語で記述します。発話されるヒンディー語のセリフのみ、デーヴァナーガリー文字で記述します。

標準の締めくくりの指示

シナリオに応じた独自のルーティングが必要な場合を除き、ほとんどの締めくくりの分岐で、次の文をそのまま使用します。これは、ADDA、Porter、OEG、upGrad、CureFoods、LPU、Schoolini の本番プロンプトで使用されている正確な文言です。

Instructions: Make sure that you are speaking the closing as it is. This closing statement is designed to professionally conclude the conversation, ensuring a respectful and neutral closure. The AI should deliver the closing message warmly and clearly, avoiding abruptness or over-promising about outcomes. Maintain a courteous tone throughout. No follow-up or probing is necessary here; the goal is to end the interaction smoothly and on a positive note. No additional follow-ups or questions are required at this point.

ヒンディー語のみの締めくくり、または共感を示す締めくくり（健康や家族の問題に対する Porter の共感的なバリエーションなど）では、冒頭の「Make sure that you are speaking the closing as it is.」をそのまま使用し、その後に、標準文の残りの部分より前に状況に応じた注記を加えます。

分岐と番号付け

• セクション内の直線的な質問には、Question 1、Question 2、Question 3 のように順番に番号を付けます。
• 質問の後に分岐が始まる場合、分岐内の最初の質問には、前の番号の続きの番号を付けます。（Question 3 で直線的な流れが終わり、Branch A が始まる場合、Branch A は Question 4 から始まります。）
• 同じ判断ポイントから複数の分岐が始まる場合、各分岐の最初の質問には、同じ番号を付けます。これらの分岐は同じポイントから派生するためです。
• 分岐ラベルはBRANCH A: [SHORT DESCRIPTION]、BRANCH B: [SHORT DESCRIPTION]のようにします。大文字表記が主流のスタイルです（ADDA、Porter、OEG、upGrad、Schoolini、LPU）。Branch A: Title Case Description（CureFoods）の形式も使用できますが、1つのプロンプト内では統一してください。締めくくりのセクションでは、分岐の説明に結果（Successful Close、Not Interested、Rescheduling、Wrong Number、Relative Answered、Out-of-Service Area）を記載します。深くネストした分岐には、ドット付きの接尾辞BRANCH A.1、BRANCH A.2を使用します（ADDA 方式。使用は最小限にします）。

コンテンツ生成ルールブロック

エージェントが定型文ではなく状況に応じて対応する必要がある場合は、角括弧で囲んだルールブロックでサブセクションを開始します。

[
Content generation rules:
- Rule one
- Rule two
- Rule three
]

プロンプト本文でダッシュや箇条書き形式を使用できるのは、ここだけです。ただし、内部で既にダッシュを使用している静的な Conversational Naturalization モジュールは除きます。Edge Cases、Objection Handling、Upsell Triggers、Discount Logic の各サブセクションは、必ずこれらのブロックのいずれかで開始してください。

エッジケースでは、ルールブロックの後に、各ケースを明確な Trigger、両言語での Response、ルーティング用の Instruction 段落として記述します。

異議への対応は、会話調で両言語を用い、最大三文にします。各異議に対する切り返しは最大一回です。通話相手が二回連続で断った場合は、丁寧に通話を終了するよう明記してください。

アップセルでは、トリガー条件と両言語でのアップセル応答を定義します。アップセルは一回の通話につき最大一回です。

割引ロジックでは、段階的なルールを本文の箇条書きではなく、コンテンツ生成ルールブロックの中に記述します。

FAQ セクション（YAML）

必ず含め、常に最後に配置し、YAML 形式にします。コンテンツ生成ルールブロックで開始します。

[
Content generation rules:
- This section includes answers to common questions callers may ask during the conversation.
- Always keep the answers to the point, clear, and aligned with the tone defined in Section 1.
- After answering an FAQ, the agent must smoothly return to the exact point in the conversation flow where the interaction was paused.
- If the caller asks something not listed here, the agent must not generate a speculative answer and should politely defer to the sales or support team.
]

続けて項目を列挙します。

- id: 1
  question:
    en: "[English question only]"
  keywords:
    - "keyword one"
    - "keyword two"
    - "keyword three"
  answer:
    en: "[English answer]"
    hi: "[Hindi answer in Devanagari]"

質問は英語のみで記述します。回答は両言語で記述します。FAQ ごとのキーワードは最大六つです。キーワードにはヒンディー語と英語を混在させてもかまいません。

コンテキスト JSON 形式と YAML の記述例については、references/section-templates.md を参照してください。

特別な書式と発話行のルール

これらのルールは、プロンプト内のすべての発話行と指示に適用されます。

• スクリプト化された発話文と指示段落で禁止される記号：!、/、@、%、#、&、$。これらの記号は、慣例的に使われるセクション名やサブセクション名では使用できます。たとえば # Conversational Naturalization (Acknowledgements & Flow Softening)、SECTION 1: Demeanour & Identity、SECTION 9: FAQ's、# Handling Customer Queries です。見出しマーカーは実行時に読み上げられないためです。この禁止事項は、TTS が読み上げるあらゆる行（Opening、Question、Closing、Response、FAQ の回答）と、ルーティングや書式設定の指示と誤解される可能性がある指示段落に適用されます。# 記号は Section 1 のサブセクションの見出しマーカーとして使用できます。
• **発話の会話行では - と — を使用しないでください。**ダッシュを使用できるのは、コンテンツ生成ルールブロック内と、静的な Conversational Naturalization モジュール内のみです（このモジュールでは内部で使用されています。そのまま転記してかまいません）。
• **発話行では感嘆符を使用しないでください。**いかなる場合も禁止です。Conversational Naturalization モジュールでも禁止されています。これは文体上の問題ではなく、TTS の読み上げ速度に関する問題です。
• **スクリプト化されたメッセージと FAQ の回答では、数字をすべて周囲の言語に合った単語で表記します。**詳しくは上記の「スクリプトテキスト内の数字」を参照してください。
• **エージェントの一回の発話につき、相づちは一つだけにします。重ねて使用しないでください。**決まった前置きではなく、謝罪、感謝、質問など、通話相手の直前の発言に応じた返答を使用します。
• **エージェントの性別は、すべての行を通して一貫させます。**エージェントが女性の場合は、ヒンディー語の動詞形と自称を最後まで女性形に統一します（हूँ、करूँगी、बताऊँगी）。会話上の手がかりから通話相手の性別を判断し、通話中に応じて調整します。
• **一方的に話し続けないでください。**二、三文ごとに通話相手の反応を確認します。
• **表は使用しないでください。**FAQ または YAML／JSON のセットを使用します。
• **指示、ガードレール、メタプロンプトの内容はすべて英語で記述します。**デーヴァナーガリー文字を使用するのは、発話されるヒンディー語の行のみです。指示やガードレールをヒンディー語で記述しないでください。

一貫性のルール

• 目標や指示をサブセクション間で繰り返さないでください。各サブセクションには、それぞれ一つの役割があります。
• サブセクション間で矛盾が生じないようにしてください。セクション1から締めくくりまで、口調、言語、アイデンティティを一貫させてください。
• 会話で使用する言語が決まったら、呼び出し側から別の言語を明示的に求められない限り、変更しないでください。

基盤となるモデル

ランタイムのLLMはGPT-4.1 miniです。このスキルの構成、詳しさ、命名規則はこのモデルに合わせて調整されています。Markdownの装飾を加えたり、凝った書式にしたり、絵文字付きの見出しを使ったり、参考パターンを言い換えたりしたい衝動は抑えてください。セクション名、指示の言い回し、発話文の構成、分岐表記など、参考スタイルにそのまま合わせてください。気の利いた表現より、地味でも一貫性を保つことが大切です。

ユースケースの説明を受け取ったときのワークフロー

1. 要件を読みます。エージェントの性別、主な言語、主な通話目標を確認します。この3点のいずれかが本当に不明確な場合に限り、焦点を絞った確認質問を1つだけします。
2. references/static-modules.md と references/section-templates.md を読み込みます。ユースケースに氏名、電話番号、メールアドレス、または数値の入力取得が含まれる場合は、references/reusable-modules.md にも目を通します。特定の日時での折り返し電話の予約、または評価スコアの算出が含まれる場合は、references/reusable-flows.md にも目を通します。
3. セクション1を作成します。角括弧で囲んだ Identity ヘッダー（You are [Agent_name: NAME], [Gender: Female/Male]）から始め、次に Identity の段落を置き、その後に残りのサブセクションを続けます。2つの静的モジュールはそのまま貼り付けます。ユースケースに必要な追加のセクション1のサブセクション（Context、Environment、Eligibility Criteria、Edge Casesなど）を加えます。
4. セクション2（Conversation Starter）を作成します。
5. セクション3以降に、通話のフローを名前付きの番号付きセクションとして割り当てます。
6. 関連するすべての分岐を含めた Closing セクションを作成します（最低限、Successful Close、Not Interested、Wrong Numberを必ず含め、ユースケースに応じてRescheduling、Relative Answered、Language Mismatchを追加します）。
7. フローに参照データが必要な場合に限り、Context（JSON、フラットなYAML、または見出し付きMarkdown。section-templates.mdを参照）を追加します。Contextセクションを含める場合は、"Answering User Questions"セクションも含めます。このセクションは、エージェントがセクションX（Context）とセクションY（FAQ）をどのように使用するかを説明する、content-generation-rulesブロックから始めます。これはContextセクションとは別のセクションです。
8. FAQ（YAML）を必ず作成します。

プロンプトはFAQで終わります。「Variables Reference」や末尾のメタデータブロックはありません。本番用プロンプトにそのようなものはありません。事前に読み込まれた変数は、最初に登場する箇所でインラインに導入し、用語集を設ける必要はありません。

セクションテンプレートや締めくくりの分岐の表現に迷ったら、独自に考案せず、references/section-templates.md を開いてください。

トランスクリプトを受け取ったときのワークフロー

references/transcript-workflow.md を読みます。要点は次のとおりです。

1. エージェントが成功した箇所と失敗した箇所を特定します。
2. 各失敗を、原因となったプロンプト内のセクションに対応付けます。通常は、ガードレールの欠如、分岐の弱さ、ルーティング指示の不明確さ、事前に想定されていない反論、または口調の逸脱が原因です。
3. 上記と同じ形式で、修正したセクション、または更新後のプロンプト全体を作成します。
4. 変更内容とその理由を、数文で簡潔に説明して終わります。

参考ファイル

• references/static-modules.md — そのまま貼り付ける必要がある、Section 1 の必須モジュール 2 つです。
• references/section-templates.md — セクションの種類ごとの完全なテンプレートと記入例です。角括弧付きの Identity ヘッダーを含む Section 1 のサブセクションパターン、Section 2 の導入文、Closing の分岐、Context の形式（JSON、フラットな YAML、見出し付き Markdown）、FAQ の YAML バリエーションが含まれています。
• references/reusable-modules.md — 実運用のプロンプトをもとにした、名前、電話番号、メールアドレス、数値表現の収集パターンです。
• references/reusable-flows.md — CureFoods、upGrad、Porter で同じ内容が使われている、日付・時刻の折り返し予約ブロック、採点式の面接評価パターン（CureFoods）、および「ユーザーの質問への回答」ゲートウェイパターン（ADDA、Porter）です。
• references/transcript-workflow.md — 文字起こしを診断し、問題をプロンプトのセクションに対応付ける方法です。
• references/multilingual.md — multilingual_config エージェントのプロンプトを作成するためのガイドです（1 つのエージェントに複数の言語エントリを設定し、それぞれに独自の STT／TTS と Section 1..N のプロンプトを指定します）。