会話型AIシステムのプロンプト方法

現在、LLMは会話型AIシステムの中核となっています。特にLLMは、会話型AIを、かつての複雑な電話ツリーを基盤としたものから、動的な機能と人間らしい体験を備えたものへと進化させます。ただし、LLMは万能薬のようなアップグレードではありません。デフォルトでは人間の会話向けに微調整されていないため、専用のプロンプト設計が必要です。

会話型AI向けにLLMをプロンプトする際、デベロッパーがよく犯す間違いがあります。それは、人間の従業員を教育するために使った手引きをそのまま再利用することです。一見わかりやすいこの方法も、うまくいくことはほとんどありません。LLMは一般的な人とは異なる前提を置き、デフォルトの口調や対応範囲も音声での対話には適していません。

ここでは、成功する会話型AIシステムを構築するためのLLMのプロンプト方法について、わかっていることを紹介します。さらに包括的で技術的なガイドは、ElevenLabsデベロッパードキュメントでもご覧いただけます。

従来のシステム

LLMが登場する前の会話型AIシステムでは、音声入力に応じてリクエストを振り分ける、複雑なロジックツリーが使われていました。この仕組みは、カスタマーサービスの電話番号（航空会社のホットラインなど）や決済システム（クレジットカードの電話サービスなど）で広く使われていました。

こうした旧来のシステムは反応が遅く、ロボットのように感じられ、人間からの入力もごく限られていました。質問に答えるため、電話に向かって「はい！」とぶっきらぼうに叫んだ経験がある方も多いでしょう。この不便な体験のため、多くのユーザーは生身のオペレーターにつなげてもらおうと、「システムを突破」しようとしていました。

ただし、こうした電話ツリーには利点もありました。範囲が限定されていたのです。会話がたどる経路は限られており、デベロッパーは許可されていない入力を無視するガードレールを簡単に実装できました。この制約はLLMの長所と短所の根底にもあります。電話ツリーの限定性を大きく超える一方で、予測不能でもあり、実現不可能な約束をする、顧客に怒る、機密データを漏らすといった問題のパンドラの箱を開けてしまう可能性があります。

デフォルトのギャップ

もともと人間向けに作られた手引きだけでLLMを学習させても、いくつかの根本的なギャップのために、成果は限定的です。こうしたギャップを理解すれば、それを補うプロンプトを設計できます。

トーンの不一致

LLMは、人間からのフィードバックによって構造化された回答を返すよう促す強化学習で訓練されています。そのため、LLMの回答は冗長になりがちで、箇条書き、強調ブロック、見出しが多く含まれる傾向があります。

しかし会話型AIでは、LLMは音声対話に特有の簡潔でフラットな性質を再現する必要があります。

推測によるギャップ

LLMには、質問する代わりに未知の情報を推測で補う傾向があります。その結果、ユーザーを誤解へ導く誤った前提を置いたり、返金を約束するなどコストのかかるミスにつながったりすることがあります。後ほど、ナレッジベースとガードレールを使ってLLMを適切な情報に基づかせ、誤った約束や許可されていないアクションの実行を防ぐ方法を見ていきます。

レイテンシー

LLMはプログラムから関数呼び出しを実行し、人に代わってデータを取得・書き込みできます。これは一般にLLMの大きな利点の一つですが、同時に、タスク実行中にコールエージェントが「時間を稼ぐ」ことを想定した従来のトレーニング指示が不要であることも意味します。ただし、関数呼び出しも瞬時に完了するわけではありません。遅延が予想される場合には、LLMがユーザーに正確に事前通知する必要があります（例：「確認しますので、少々お待ちください」）。

設定

個性

LLMは、指定したスタイルに合わせてトーンを調整することを比較的得意としています。親しみやすく、ユーモラスに、簡潔に、フォーマルに、あるいは複数のスタイルを組み合わせるよう設定できます。これはLLMをプロンプトする際の重要な入力です。

たとえば、不満を抱える航空会社の顧客を支援するカスタマーサービス向け会話型AIアプリケーションのデベロッパーは、次のようなプロンプトを使うかもしれません。

形式

LLMには、応答方法を明確に指示する必要があります。余分な埋め草のテキストを含めないよう、ユーザーに渡す回答を包み込む構造をLLMに与えるべきです。

たとえば、LLMに次のようにプロンプトできます。

この足場となる指示により、LLMは読み上げることを前提とした回答を提供しやすくなります。

ただし、LLMは書き言葉との違いが直感的にはわかりにくい要素でつまずくことがあります。よくある例が数字です。LLMが郵便番号を10023のように出力すると、テキスト読み上げモデルはこれを「一万二十三」と読んでしまいます。代わりに、「郵便番号は一、〇、〇、二、三です」のように、数字が何を表すかを示しながら、一桁ずつ読むようLLMに明示的にプロンプトする必要があります。

温度

温度は、会話型AI向けにLLMを設定する際の重要なパラメーターです。温度を低くすると、タスク指向の会話に適した、より焦点が絞られた決定論的な応答になります。一方、温度を高くすると、より創造的で多様な応答が生成されます。

低い温度は、一貫した応答が求められる会話型AIシステム（返金対応のカスタマーサービス窓口など）に適しています。一方、顧客により魅力的でリアルな印象を提供したいシステム（デジタルコーチなど）には、高い温度が適しています。

ナレッジベース

より大規模な知識の蓄積を参照する会話型AIシステムでは、プロンプトの長さを抑えるためにナレッジベースを活用すべきです。本番環境では通常、ベクトルデータベース（PineconeやElasticsearchなど）、またはLLMプロバイダーの直接接続されたナレッジストアを通じて実現します。

一般に、LLMの応答を事実に基づく承認済みの情報に結びつけるには、ナレッジベースが不可欠です。会話型AIシステムを構築する際は、プロダクト、サービス、ポリシー、手順に関する正確で最新の情報を含む包括的なナレッジベースをLLMに提供してください。これにより、LLMのハルシネーションや情報の捏造を防ぎ、会話全体で一貫性と信頼性のある応答を促せます。

プロセス

LLMはユーザーに代わって関数を呼び出すことが多いため、明示的に必要な入力も把握しておく必要があります。たとえば、ユーザーの美容院の予約を支援するLLMなら、次の情報を確実に取得する必要があります。

1. ユーザーの名前
2. 希望する日時
3. ユーザーの住所
4. ユーザーが希望するサービス

単純な実装では、LLMが一度の会話ターンでこれらすべての情報を尋ねてしまうことがあります。テキストでは問題ありませんが、会話では圧倒されかねません。

情報は通常、会話を通じて段階的に集めるため、LLMには一つずつ取得するよう促す必要があります。その結果、はるかに自然な会話体験になります。

ガードレール

権限

分散システムを構築する際は、サーバーがいつかクラッシュすることを前提にします。同様に、AIシステムを構築する際は、LLMがいつかミスをすることを前提にすべきです。そのミスの影響範囲を最小限に抑えるため、システムにはその仕事に必要な最小限の権限だけを与えてください。以下に、その方法の例を示します。

• 読み取り／書き込み権限を正しく設定する：LLMがデータソースから情報を読み取るだけでよい場合は、読み取り専用エンドポイントを与えてください。
• APIエンドポイントへのアクセスを制限する：LLMが特定のエンドポイントにのみアクセスする必要がある場合、ほかのエンドポイントにはアクセスできないようにしてください。
• ヒューマンインザループによるエスカレーション：高リスクなアクションを実行する必要がある場合は、アクションの実行前に「マネージャーの承認」を必要とするヒューマンインザループのワークフローを検討してください。

検証と確認

ツールの利用を通じてアクションを実行する会話型AI音声エージェントシステムを作成する際は、ユーザーから正しい情報を収集できていることを確認するために、検証・確認プロセスを組み込むと効果的です。現在でも、人間のエージェントと話すと、重要な情報を復唱して、正しく聞き取れたことや顧客が言い間違えていないことを確認します。LLMも同様のレベルでエラーチェックを行うとよいでしょう。

検証では、顧客から受け取った情報を、その情報に一般的に見られる形式と照合する必要があります。電話番号の桁数は正しいか。顧客が伝えた年齢は妥当な範囲か。有効な住所が提供されているか。

ユースケースに応じて、受け取ったすべての情報を確認することも、検証に失敗した情報だけを確認することもできます。また、情報を受け取るたびに確認するか、最後にまとめて確認するかも選べます。

最後に

会話型AIエージェントシステムを適切にプロンプトするには、正しい設定とガードレールのバランスを取り、効率を高めながら人と話しているように感じられる体験を生み出す必要があります。古いトレーニング資料を使ってLLMにプロンプトするだけの簡単な作業ではありません。LLMは、予測可能で効果的な結果を生むために、専用の構造と戦略を必要とするツールです。