プロンプト設計の実践ガイド｜顧客対応AIの品質を上げる

顧客対応にAIを入れるとき、プロンプト設計は最初に手をつけたくなる作業です。しかし実務で効いてくるのは、書き方そのものではありません。書いたものをどう測り、どう守るかです。

本記事では、各社の公式ドキュメントと国内企業の実装例をもとに、顧客対応のプロンプト設計を整理します。数値はすべて出典と公表日を添えました。逆に、測定条件が開示されていない効果訴求は掲載していません。

顧客対応のプロンプト設計は、何から決まるのか

まず、決める順番を整理します。多くの現場では、いきなり文面から書き始めて手戻りします。

このうち後半2つは、後回しにされがちです。しかし最も手戻りが大きいのもこの2つです。したがって、本記事では評価と防御を独立した章として扱います。

プロンプト設計の前に決める3つのこと──顧客対応の範囲・境界・禁止事項

文面を書く前に、次の3点を言語化しておきます。

①どこまで任せるかの範囲

まず、AIに任せる問い合わせの種類を明示します。「よくある質問全般」といった曖昧な定義は避けてください。実際に、範囲が曖昧なまま運用すると、AIは知らないことにも答えようとします。

②人へ渡す条件

次に、有人へエスカレーションする条件を決めます。判断に迷わない形にするのがコツです。

• まず、参照した情報に該当する記載がなかったとき。
• 次に、顧客が明示的に人を求めたとき。
• さらに、感情的な表現や解約意向が検出されたとき。
• 加えて、金額・契約・個人情報の変更に関わるとき。

③絶対にさせないこと

最後に、禁止事項を挙げます。ここは「してよいこと」より優先度が高い項目です。特に、価格の約束、法的判断、他社製品の評価は、明示的に禁じておくのが安全です。

システムプロンプトに何を書き、何を書かないか

設計で迷いやすいのが、記述をどこに置くかです。実際に、ここには公式ドキュメントの指針があります。

公式ドキュメントが示す配置

Anthropicはカスタマーサポートチャット向けのユースケースガイドで、次のように述べています。システムプロンプトにはロール設定のみを置き、プロンプト本体は最初のUserターンに書くのがClaudeでは最も機能する、というものです。ただしこれは当該ユースケースガイド内の記述であり、ページに更新日の表示はありません。

また、長文入力の扱いについても記載があります。同社は、複数文書を含む長い入力では、質問を末尾に置くと応答品質が「in tests」で最大30％改善しうるとしています。ただし測定に用いたモデル・データセット・評価方法は開示されていません。したがって検証できないベンダー側の主張として扱ってください。

一方、OpenAIは推論モデル向けのガイドで逆の指針を示しています。これらのモデルは内部で推論を行うため、「ステップバイステップで考えて」「理由を説明して」といった思考連鎖の指示は不要だ、という内容です。ただし適用範囲は推論モデルであり、非推論モデルには当てはまりません。こちらのページにも更新日の表示はありません。

顧客対応のプロンプト設計テンプレート

この配置の利点は、情報と指示が分離されることです。実際に、参照情報を差し替えるだけで別の商材に転用できます。

プロンプトエンジニアリングとコンテキストエンジニアリングは何が違うのか

近年、コンテキストエンジニアリングという言葉が使われるようになりました。ただし、この2つは対立する概念ではありません。

Anthropicはコンテキストエンジニアリングを、LLMの推論時に最適なトークン（情報）の集合を選び取り、維持し続けるための戦略群と定義しています（2025年9月29日）。つまりプロンプト単体の書き方に閉じるのではありません。システム指示、ツール、外部データ、会話履歴を含むコンテキスト全体を、推論のたびに取捨選択し続ける営みだと位置付けています。

顧客対応の文脈でいえば、次のような問いがこれにあたります。会話が長くなったとき、どの履歴を残すか。ナレッジベースから何件を渡すか。ツールの定義をいくつ載せるか。つまりプロンプトの文面より、渡す情報の取捨選択が効いてくる領域です。

日本語の顧客対応で起きるプロンプト設計の問題

音声を伴う顧客対応では、入力そのものが揺れます。この揺れはプロンプトの工夫だけでは吸収しきれません。

電話自動応答SaaSのIVRyは、技術ブログでこう書いています。環境音やイントネーションなどの要素が含まれると、同じ発話内容でもアウトプットが変わることがあった、という内容です（2023年7月26日）。同社の対処は、プロンプトの改善ではありませんでした。認識させる発話内容そのものをシンプルにし、他の選択肢と区別しやすくするという設計変更です。

ここから引ける教訓があります。まず、入力の揺れは入力側で減らすこと。次に、揺れが残る前提で出力を検証すること。したがって、日本語特有の課題はプロンプトと入力設計の両方で扱う必要があります。

評価をどう作るか──顧客対応のプロンプト設計は測れないと改善できない

本記事で最も伝えたいのがこの章です。プロンプトは一度書いて終わりではありません。文面を直すたびに、別の場面が壊れていないかを確認する必要があります。

LINEヤフーの4観点

LINEヤフーは社内RAGサービス「SeekAI」の評価手法を公開しています（2024年8月19日）。同社はLLM-as-a-Judgeに、次の4観点で判定させています。

• まず、含有性。「あらかじめ想定されていた回答の内容が含まれているか？」
• 次に、相反性。「あらかじめ想定されていた回答と相反する内容があるか？」
• さらに、一致性。「あらかじめ想定されていた回答と同じトピックについて回答しているか？」
• 最後に、案内性。「元情報のURLが案内されているか？」

注目したいのは出力形式です。同社は点数ではなく真偽値で判定させています。実際に、5段階評価より真偽値のほうがぶれにくく、集計もしやすくなります。なお、これは2024年8月時点で公表された設計です。現在も同じ形で運用されているかは確認できていません。

能力評価と回帰評価を分ける

Anthropicは評価を2種類に分けています（2026年1月9日）。

この区別は実務で効きます。合格率が低い評価を見て慌てる必要はありません。慌てるべきなのは、回帰評価が落ちたときです。

では、評価用のテストケースはどう集めるのか。デジタル庁は「テキスト生成AI利活用におけるリスクへの対策ガイドブック（α版）」で、過去に実際にあったやりとりをそのままテストケースに含める手法を挙げています（2024年6月10日、現在もα版）。顧客対応であれば、応対ログがそのまま資産になります。なお生成AIの調達・利活用については、2026年6月12日にDS-920が別途公表されています。

顧客対応のプロンプト設計で最も重要──プロンプトインジェクション対策

顧客対応AIは、不特定多数からの入力を受け取ります。つまり攻撃者も入力できます。したがって、この章は必ず設計の初期に検討してください。

OWASPが示す位置づけ

OWASP GenAI Security ProjectのLLM Top 10では、プロンプトインジェクションがLLM01:2025として最上位に置かれています。2026年7月時点でも、LLM Top 10は2025年版が最新です。

対策の基本は、入力を信用しないことに尽きます。具体的には、次のような設計が挙げられます。

• まず、モデルの振る舞いを明示的に制約し、想定外の要求は拒否させること。
• 次に、出力の形式を定め、想定外の形式は通さないこと。
• さらに、権限を最小にし、AI経由で実行できる操作を絞ること。
• 加えて、高リスクな操作には人の承認を挟むこと。
• 特に、外部から取り込んだ情報とユーザー入力を、内部の指示と明確に分離すること。

エージェント化で位置づけが変わった

ここは見落としやすい変化です。同じOWASPが2025年12月9日に「Top 10 for Agentic Applications for 2026」を公表しました。この体系では、プロンプトインジェクションは独立項目ではありません。ASI01「Agent Goal Hijack」の主要な侵入経路として整理し直されています。

つまりAIエージェントを扱う場合、注入そのものより、注入によって目的が乗っ取られることを問題として見る必要があります。したがってLLM Top 10の2025年版だけを参照していると、現状を取り違えます。

プロンプトを長くする前に確認したいこと

精度が出ないとき、プロンプトを長くする対処に流れがちです。しかし、それが効かない場合もあります。実際に、原因が別の場所にあることは珍しくありません。

参考になる実証があります。PKSHAグループとTOPPANエッジは2024年9月、静岡銀行の行内規程類・マニュアル全34種、質問261問を対象とした検証結果を公表しました。ドキュメント正解率が87.3％から95.4％へ、チャンク正解率が63.2％から84.6％へ改善したというものです。改善のために行ったのは、プロンプトの調整ではありません。マニュアル側をAIが読み取りやすい形式に構造化することでした。

ただし注意点が2つあります。まず、これは2024年9月時点の実証であり、現在のRAG精度を示すものではありません。次に、比較対象とされた「一般的なRAG」の構成が開示されていません。それでも、改善の打ち手が入力データ側にあったという構図は参考になります。

まとめ：顧客対応のプロンプト設計は「書く」より「測る」

プロンプトの文面には、公式ドキュメントという先行事例があります。したがって、そこで差はつきにくくなっています。差がつくのは、評価をどう作るかと、攻撃をどう想定するかです。

着手するなら、次の順番をおすすめします。まず、任せる範囲と禁止事項を言語化すること。次に、過去の応対ログからテストケースを作ること。さらに、回帰評価を先に用意してから文面を書くこと。この順で進めれば、直すたびに壊れる状態を避けられます。

顧客対応AIの設計や評価の作り方でご相談があれば、vottiaまでお気軽にお問い合わせください。

執筆：阪口 凛空（vottia株式会社 インターン）。監修：池田 龍矢（vottia株式会社 マーケティング責任者）。vottia株式会社は「maestra」を提供しています。コンタクトセンター向けのAIエージェントプラットフォームです。本記事の記述はすべて各社・各機関の公表資料に基づき、参考リンクに一次ソースを掲載しています。最終更新：2026年7月27日。

Q. よくある質問

Q1. 顧客対応のプロンプト設計は誰が担当すべきですか

現場の応対を理解している人と、評価を作れる人の両方が必要です。文面だけならエンジニアでなくても書けます。しかし回帰評価の設計とテストケースの管理には、継続的な運用体制が要ります。実務では、SVがテストケースを持ち、エンジニアが評価基盤を持つ分担が現実的です。

モデルを変えたら書き直しになりますか

全面的な書き直しにはなりませんが、検証は必要です。特に推論モデルと非推論モデルでは、思考連鎖の指示に関する推奨が逆になります。回帰評価を用意しておけば、切り替え時の影響をすぐ確認できます。

Q3. プロンプトだけで回答精度は上がりますか

上限があります。参照する情報そのものが構造化されていない場合、文面の調整では届きません。静岡銀行の事例のように、入力データ側の整備が効くケースは少なくありません。まず参照情報の状態を確認することをおすすめします。

参考リンク

• Anthropic：Customer support chat（ユースケースガイド）
• Anthropic：Effective context engineering for AI agents（2025年9月29日）
• Anthropic：Demystifying evals for AI agents（2026年1月9日）
• OpenAI：Reasoning best practices
• LINEヤフー：SeekAIの回答自動評価（2024年8月19日）
• OWASP GenAI Security Project：LLM01:2025 Prompt Injection
• OWASP：Top 10 for Agentic Applications for 2026（2025年12月9日）
• IVRy：AI音声認識機能のQAにおける課題と工夫（2023年7月26日）

関連記事

• RAG（検索拡張生成）とは｜コンタクトセンター活用と課題
• AIエージェント×コンタクトセンター──国内事例まとめ
• 生成AI セキュリティ｜コンタクトセンター個人情報保護の対策