多くのプロンプトエンジニアリングは、正確性と指示の網羅性を重視しています。本番環境で最大の成果を生むのは、対話そのものを設計の中心課題として扱うことです。
トリガーと行動を組み合わせた意図を指定すれば、抜け出せない台本を与えるのではなく、判断の方法をモデルに示せます。プロンプト内の配置自体が一つの指示になります。アイデンティティは冒頭、行動のニュアンスは中間、厳格な制約は末尾に置き、本当に重要な内容は冒頭と末尾の両方に置きます。
口調を説明するのではなく、その口調でプロンプトを書くことは、特に大きな効果を期待できる改善策です。
最も一貫性の高いエージェントは、会話の各場面をそれぞれ異なるやり取りとして扱うプロンプトを備えています。各場面に適した形へ変化しながらも、全体を通して同じ口調だと明確に分かります。
場合によっては、思考するエージェントと発話するエージェントを分けることで、応答の一貫性と根拠が高まり、内部の推論が応答に漏れるのを防げます。
以前、言語学と認知心理学の知見に基づく新たなプロンプト設計のパラダイムを紹介しました。エージェントが動作できる、明確な境界を持つ問題領域を作ることの重要性と、その領域に顧客対応 AI に不可欠な対話というメタタスクを組み込む必要性について解説しました。
今回は、これらの原則を本番環境に導入する中で、プロンプトが実際にどう変わり始めたかを紹介します。
稼働中の顧客対応システムでプロンプトを数百回改良してきましたが、最大の成果は、指示や例を増やすことでも、一般的なプロンプトエンジニアリングの慣例に従うことでも得られませんでした。成果を生んだのは、対話を問題の中心として受け入れることでした。
継続的な探究とテストを通じて、いくつもの有効な手法が生まれました。プロンプトを変更して会話の成否を観察し、失敗の原因をガイダンスの有効性、プロンプトの構成、言葉の使い方までさかのぼって検証しました。その結果、エージェントが会話における自らの役割をどう解釈するか、次の行動をどう決めるか、変化する文脈の中で口調をどれほど一貫して保てるかを改善する、再現可能なパターンが得られました。
以下で紹介するのは、普遍的なフレームワークでも、プロンプト設計が「解決済み」だという主張でもありません。機能的な正確さだけでなく、ブランドを担えるほど一貫性があり、自然で筋の通った応答を目指したとき、本番環境で有効だった知見を 5 つのパターンに凝縮したものです。
エージェント型システムの構成方法は数多くありますが、複数のエージェントを連携させるワークフローは今も広く使われています。特にこうしたシステムで最も安定した改善につながったのは、思考するエージェントと会話するエージェントの分離でした。
意図のオーケストレーション、分類、知識抽出、ツール利用は、すべて裏方の処理です。顧客向けの応答は表側の業務です。同じエージェントが 1 回のターンで両方を担うと、内部の推論やロジックが応答に漏れることがあります。その結果、応答は歯切れが悪く、過剰な条件が付き、相手のニーズよりも処理手順のロジックを中心に構成されるようになります。
この一つの制約だけで、驚くほど多くの効果が得られます。応答が実際の会話に根差したものになり、文脈のリセットを防ぎ、私たちが「差分だけを伝える」と呼ぶ形に近づきます。つまりエージェントは、ユーザーを前進させるために本当に必要な最小限の新情報だけを加えます。
どの種類の応答を返すかという判断も重要です。発話するエージェントに、何かを書く前に応答の型を選ばせると、最も一般的な会話上の失敗を確実に減らせることが分かりました。型には、回答、確認、誘導、保留があります。問題は文章の質ではなく、応答自体を間違えることです。
ただし、最新のフロンティアモデルは、適切な条件下ではこのパターンの前提を覆し始めている点にも注目すべきです。それでも、さまざまな理由から小規模または旧世代のモデルを使う開発者は多く、その場合は裏方の処理と顧客対応を分離することを強く推奨します。
推論を行わないモデルでは、フューショット例が有効です。具体的ですぐに使え、モデルも適切に反応するためです。問題は過学習です。モデルに例を与えると、言葉、リズム、構成に固執し、状況が変わっても同じ応答によく似たものを繰り返し生成します。
意図せず、モデルが抜け出せない台本を書いてしまうのです。
より長く有効な代替手段は、実行意図やヒューリスティックです。特定の場面で何を言うかをモデルに示す代わりに、より汎用的なトリガーと行動の組み合わせを与えます。X が起きたら Y を行う、という形です。
重要な違いは、例を重ねて X と Y の範囲を徐々に狭め、硬直化させるのではなく、例が不要になるほど正確な指示によって、それぞれの境界を明確に定めることです。これによりエージェントは、テンプレートとのパターン照合ではなく、実際の会話の変化に応じられます。
実際には、例というより、実行可能な経験則として記述します。
重要な情報が不足している場合は、確認の質問を一つする
回答に根拠がない場合は、その旨を率直に伝え、実行可能な最善の次の手順を提示する
依頼がガードレールに抵触する場合は、簡潔に断り、大げさにせず別の方向へ誘導する
華やかではありませんが、応答例のライブラリよりはるかに堅牢です。モデルに何を繰り返すかではなく、どう判断するかを教えられるからです。
プロンプト内の配置によって、その内容の重みが変わります。これは、さまざまなモデルと導入環境で一貫して確認されているパターンです。プロンプトの冒頭と末尾は、ほかの部分より際立って認識されます。中間に置くのは細かなニュアンスです。まさにニュアンスにふさわしい位置です。
私たちは、この点を踏まえてプロンプトを構成しています。エージェントの役割と自己認識は冒頭に置き、何よりも先にアイデンティティを確立します。中間には、会話がどのように進むか、応答を導くヒューリスティック、エージェントが対処すべき状況の範囲など、行動の詳細を置きます。厳格な制約と譲れない条件は末尾に置き、モデルが真っ先に意識できるようにします。
本当に重要な内容は、冒頭と末尾の両方に置きます。句読点や書式に関する厳格な指定など、具体的な出力ルールを情報量の多いプロンプトの中間に一度だけ記載すると、日常的に見落とされることがあります。末尾で繰り返すことで、その指示が守られやすくなります。
新近効果に関しては、構造化出力を使用する場合、それが実質的にプロンプトの最後の指示になる点にも注目すべきです。構造化出力の説明フィールドは応答の質に影響し、プロンプトのほかの部分より強い出力規約として機能します。
口調の指定にもフューショット例を使わないほうがよいと分かりました。これは、顧客対応エージェントに加えた変更の中でも、特に大きな効果を上げています。
代わりに、プロンプト全体を実際に使いたい口調で書きます。口調の説明でも、それらしい形容詞の羅列でもありません。最初の行から最後の行まで、実際の口調を完全な文章で表現します。プロンプトそのものが実例になります。私たちはこれを「脱スクリプト性」と呼んでいます。モデルに入力の口調を模倣させながら、プロンプト自体と同じ範囲にある、より多様な言葉や表現を使えるようにする手法です。
こうして、一貫した口調の中に多様性を生むようプロンプトで導きます。これは、明示的な指示を最小限に抑えながら、あらゆるエージェントのタスクの中心に対話を据える戦略の一部です。
口調について明示的な例を使う場合は、「してはいけないこと」を示します。たとえば、「全角ダッシュは使わない。絶対に。決まり文句も、ポリシーの羅列も避ける。一文で話が完結するなら、説明を重ねない」といった具合です。否定的な制約は、肯定的な理想像よりも正確で、しかも自由を損ないません。モデルが陥りやすい失敗を具体的に示せるからです。
書式も重要で、応答の調子を決めます。箇条書き、見出し、括弧付きの指示が並ぶプロンプトは、モデルを整然とした事務的な出力へ導きます。会話らしい出力を求めるなら、入力を略記だらけの仕様書のように見せるべきではありません。
口調を指定するプロンプトの多くは、結局は個性の指定に陥ります。エージェントにどのような話し方をさせるか、形容詞を並べて説明する方法です。温かみがある。プロフェッショナル。親しみやすく簡潔。これらは間違いではありません。しかし、会話で口調がどう受け取られるかを実際に左右するのは言語使用域です。つまり、同じ根本的なキャラクターが異なる社会的状況でどう振る舞うかです。
問い合わせの処理中に表示する待機メッセージが、最終回答のように聞こえてはいけません。ガードレールに基づく応答を、雑談と同じテンションにしてはいけません。不満を抱える顧客に、気軽に情報を見ている顧客と同じ愛想やユーモアで応じるべきではありません。
これが、ブランドボイスと会話設計の違いです。ブランドボイスがキャラクターを表すものだとすれば、会話設計は状況の変化に応じてそのキャラクターがどう振る舞うかを決めるものです。これを正しく設計するには、単に AI の出力を手がけるコピーライターであってはなりません。会話の中で口調がどう移り変わるかを設計しているのです。
ここまでのパターンは、技術的にはどれも複雑でないと気付くでしょう。それこそが狙いでもあります。エージェント型システムのアーキテクチャは重要です。しかし会話の質を高めるには、プロンプトの設計と改善に相当な時間をかける必要があります。
単に機能する AI と、本当に会話できる AI の隔たりは、技術設計だけでは埋まりません。人間の対話で言語と注意がどう働くかを深く理解し、エージェントが扱う問題領域の中心に対話を据えることで埋められます。
AI プロダクトチーム、エンジニア、エクスペリエンスデザイナーは、顧客対応 AI の会話設計に、卓越した技術と同等の厳密さで取り組むべきです。会話の相手に見えるのは、モデルでも、複数エージェントの連携でも、ツール呼び出しでもありません。そこにあるのは、自然に感じられるかどうか、信頼を築くか損なうかを左右する一つのやり取りだけです。
結局、アーキテクチャそのものを体験する人はいません。人が体験するのは会話です。
会話こそがプロダクトです。