採用 · July 21, 2026 · 約10分
カスタマーサポートのプロンプトエンジニアリング
カスタマーサポートのプロンプトエンジニアリングは本質的に編集です。AI下書きをポリシーに基づいて根拠づけ、トーンを修正し、送信前に過剰な約束を削除します。
← 「採用の5つのピラー:アセスメントが測定するもの」の一部
目次
サポートチームを率いているなら、これはあなたのためのものです。サポートはAIが実際の成果物——顧客が読む返信——を下書きし始めた最初の業務のひとつだからです。カスタマーサポートのプロンプトエンジニアリングは「AIに返信を書かせられるか」ではなく、「すでに不満を持っている顧客が読む前にAIが誤った箇所に気づけるか」です。リスクは即座に現れます。一つの過剰な約束や誤ったポリシーの詳細が受信箱に届き、返金の争い、悪いレビュー、またはチャーンしたアカウントになります。これは職種別プロンプトエンジニアリングシリーズのカスタマーサポート編であり、AI Sandboxが最も明確に浮き彫りにするシグナルの一つです。
プロンプトは仕事の半分、編集がもう半分
優れたサポートプロンプトは2つのことを行います。返信が推測ではなく事実に基づくよう、関連するポリシーをモデルに渡すこと。そして返信がロボットのように読めないよう、トーン——温かく、率直に、ミスを認める——を明示することです。しかし、うまくプロンプトされた下書きでも編集者は必要です。モデルは相手に同意しようとするよう設計されており、それこそが過剰な約束(「すぐに返金いたします」)がポリシーの裏付けのない返信に紛れ込む仕組みです。それに気づくことが、サポートの席におけるAI fluencyであり、テンプレートが自動化できない部分です。
成熟したサポート担当者の特徴は、巧みなプロンプトではありません。最初の下書きを最終的なものとして扱わないことです。彼らは生成されたすべての返信を、本物の怒った顧客がまさに受け取ろうとしているものとして読みます——実際にそうだからです。その習慣は履歴書では見えず、面接でも偽ることが難しいため、実際のワークフローを反映した課題で観察する必要があります。また複利効果もあります。意図的に編集する担当者は、製品のポリシーとモデルの本能がどこで乖離するかを学び、そのギャップを予め解消するようプロンプトで先手を打ちます。時間とともに下書きの修正量が減っていきます。
具体例:怒りの請求チケット
顧客が予期しない請求について怒っています。弱いアプローチはAIに「謝罪文を書いて」と頼み、返ってきたものをそのまま送信します。強いアプローチはモデルにプラン、返金ポリシー、トーンを与え——ポリシーが認めないことを約束することを明示的に禁じます。そのうえで担当者は下書きを読み、冷淡に聞こえる一文を和らげ、モデルが独自に追加した返金の約束を削除します。同じツール、同じ顧客、まったく異なる結果——その違いは最後の人間のステップです。
## TASK
Draft a reply to the customer message below.
## CONTEXT
- Plan: Pro (monthly). Refund policy: pro-rated, within 14 days only.
- Tone: warm, direct, no corporate filler. Own the mistake.
## RULES
- Promise nothing the policy above doesn't allow
- If their case isn't covered, say so plainly and offer the next step2つのバージョンが生み出すものを見てください。弱いプロンプトは「ご不満を完全に理解しております」で始まり、モデルが緊張を解消しようとするため「これを正すために全額返金いたします」と申し出る、流暢な謝罪文を返します。美しく読めます。しかし2点で誤っています。返金はプロ按分であって全額ではなく、請求は14日間の期間外に発生しています。そのまま送信すれば、チームが損失を出して履行するか撤回しなければならないコミットメントを生み出します。強いプロンプトは実際のポリシーに基づいた下書きを返し、担当者はまだ最後の仕上げを行います——堅い冒頭をトリミングし、請求のショックを認める一文を人間らしく追加し、返信がポリシーの許容範囲内に収まっていることを確認します。強いバージョンが行わないことに注目してください。ポリシーの陰に隠れません。温かみのない境界線は技術的には正確でも悪い返信です。熟練した担当者は境界線と共感を同じ一文に込めます——モデルにはできない判断で、この顧客がどれだけの信頼を積み上げてきたかをモデルは知らないからです。
- 優れた例:ポリシーとトーンを提供し、ポリシーと照合して正確さを検証し、真の共感に調整し、モデルが紛れ込ませた過剰な約束を削除する。
- 弱い例:ポリシーが誤っているかトーンがずれている、または両方の問題を持つ汎用AI謝罪文を送信し、顧客が返信してきてはじめて気づく。
第2のシナリオ:グレーゾーンのデータ削除リクエスト
請求チケットはポリシーが明確なルールであるため採点が簡単です。優れた採用者と優秀な採用者を分けるシナリオはグレーゾーンです。ポリシーがリクエストに正確に対応していない場合です。解約後に「私のデータをすべて、今すぐ削除してください」と要求する顧客を例に取ります。ポリシーではアカウント削除は認めていますが、請求記録は法定期間保持され、一部のデータはより遅いサイクルのサードパーティプロセッサに存在します。弱い担当者はモデルに削除を確認させ、「お客様のデータは完全かつ永久に削除されました」という自信に満ちた回答を受け取り、送信します——これは単純に事実ではなく、一部の法域では履行可能な主張です。より優れた担当者は、モデルの整然とした確認よりも正直な答えの方がより微妙であることを認識し、今削除されたもの、いつまで保持されるもの、次のステップは何かを明確にするよう下書きを編集します。これは同じスキルの上位版です——作り上げられた返金ではなく作り上げられた確実性を捕捉することです。
グレーゾーンのチケットはモデルの積極性が最も危険な場面です。最も安心に聞こえる方向に曖昧さを解消しようとするからです。担当者の仕事は、顧客が受け取る権利のある曖昧さを保持することです。それを取り繕ってはなりません。これはプレッシャー下での誠実さについての判断であり、現実的なアセスメントシナリオが表面化するよう設計された行動そのものです——ポリシーが一つの明確な答えを与えるチケットでは見ることができません。課題を設計する際は、整然とした答えと真実の答えが分岐する少なくとも一つのプロンプトを含め、候補者が整然とした答えに手を伸ばすかどうかを確認してください。
経験レベル別の評価基準
同じ課題でも経験レベルによって読み方が異なり、経験レベルを無視したルーブリックはジュニアを洗い流すかシニアを甘く評価するかのいずれかになります。エントリーレベルの担当者には、下書きを下書きとして扱うこと——ポリシーと照合して読み、明らかな過剰な約束を捕捉し、モデルが最初に生み出したものをそのまま送信しないこと——が基準です。直感を採用しており、まだ磨きではありません。中級担当者には、トーンの編集と共感の一文が促されることなく決まること、そしてほぼ正確なポリシーの微妙な言い換えに気づくことが期待されます。シニア担当者またはチームリードには、天井がさらに高くなります。グレーゾーンのチケットをきれいに処理し、モデルが誤った理由を単に修正するのではなく言語化し、エラーの再発を防ぐコンテキストをプロンプトに前置きします。実際に採用しているレベルに対して評価してください。
実際に効果のあるベストプラクティス
- ポリシーに基づいて根拠づける。関連するポリシーをプロンプトに貼り付け、下書きがモデルのルール推測ではなく事実から始まるようにする。
- トーンを明示的に指定する。「温かく、率直に、ミスを認める」と「無指定」では非常に異なる返信が生まれます——そしてトーンは顧客が覚えているものです。
- 過剰な約束を事前に禁じ、それでも確認する。積極的なモデルはポリシーが認めない誠意を作り上げ、指示だけでは保証できません。
- 送信前に必ず編集する。下書きはスタート地点です。正確さと共感に関する人間の判断が成果物です。
- 軽い監査証跡を保持する。何を変更したかとその理由を記録することで、チーム全体でパーソナライゼーションの筋肉が鍛えられ、コーチングが具体的になります。
優れたサポート採用者の特徴は、巧みなプロンプトではありません——最初の下書きを絶対に送信しないことです。彼らはすべてのAI返信を、本物の怒った顧客がまさに受け取ろうとしているものとして読みます。実際にそうだからです。
機能レベルでの評価ルーブリック
スキルが編集であるため、プロンプトを単独で採点することでは測定できません。本物に近いチケットを前にした候補者の行動を見て、4Dフレームワーク——委任(Delegation)、説明(Description)、識別(Discernment)、勤勉(Diligence)——にマッピングされる4つの能力に対して行動を読み取る必要があります。各能力には観察可能な最低ラインと天井があり、その間が採用シグナルの存在する場所です。
- 委任(Delegation)——モデルに何を任せるかを知ること。最低ライン:チケット全体をフレーミングなしで貼り付けるか、ツールの使用を完全に拒否する。天井:下書きは委任するが、正確さと共感の判断は確実に人間が保持する。
- 説明(Description)——モデルをどのようにセットアップするか。最低ライン:「謝罪文を書いて」。天井:具体的なポリシー、トーン、ポリシーが認めないことを約束する明示的な禁止を提供する。
- 識別(Discernment)——下書きの誤りを見つけること。最低ライン:誤字脱字のみを確認する。天井:作り上げられた返金、誤ったポリシー期間、すでに怒っている人に冷淡に読める一文を捕捉する。
- 勤勉(Diligence)——フォローアップ。最低ライン:問題に気づくが時間的プレッシャーのもとでそのまま送信する。天井:すべての問題を修正し、ポリシーと照合して主張を検証し、確認後に送信する。
キーストロークではなく機能レベルでルーブリックを設定する価値は、ツールの変更を生き延びることです。モデルの裏にあるアシスタントが何であれ、識別と勤勉の天井でスコアを取る候補者は、翌四半期にも過剰な約束を届けない人です。それが持続的なシグナルであり、正しいプロンプトテンプレートを使ったかどうかではなく行動を見る理由です。
よくある失敗パターン
- 下書きそのまま送信:たまたまポリシーが誤っている流暢な返信を信頼する。
- トーンの指示なし:すでに怒っている人に対して冷淡または冷酷に感じる技術的に正確な答え。
- モデルが追加した過剰な約束を見逃す——最もコストが高いサポートのミス。今や履行または撤回しなければならないコミットメントだからです。
- 過剰な編集:AIがレバレッジを発揮しないほど大きく書き直すこと。これは量をこなす場面では独自の非効率性です。
- 自信に満ちたポリシー要約への盲目的な信頼:モデルが利用規約をわずかに誤って言い換え、担当者がソースを確認せず、微妙なエラーが事実として送信される。
これらはそれぞれ異なる根本原因を持っており、コーチングにとって重要です。下書きそのまま送信は勤勉のギャップです。トーンの指示なしは説明のギャップです。過剰な編集は通常委任のギャップで、担当者がモデルを得意な部分に信頼することを学んでいない場合に起きます。漠然とした「もっと注意して」ではなく特定のギャップを名指しすることが、失敗した編集を教えられる瞬間に変えるものです。これは評価が使う分類法と同じであるため、アセスメントと業務上のコーチングが同じ言語を話します。
サポート返信の過剰な約束は、送信された瞬間に責任になります。「今日返金いたします」や「お客様のデータは完全に削除されました」は、チームが履行するかまたは撤回しなければならないコミットメントになります——どちらも下書きでそれを捕捉する10秒よりも高いコストがかかります。
サポート採用における位置付け
プロンプト編集スキルはいくつかのシグナルの一つに過ぎません。サポートの候補者評価では、ポリシーの理解、プレッシャー下での状況判断、そして虐待的な顧客に対して担当者を冷静に保つ行動特性も評価する必要があります。これらを5つのピラーとしてフレーミングしており、AI fluencyはその中で最も新しいもの——ほとんどの採用プロセスがまだ測定方法を見つけていないものです。他のピラーを置き換えるものではありません。候補者は下書きを完璧に編集しながらも、本当に敵対的な顧客に崩れたり、ポリシーを完璧に読みながらもグレーゾーンのケースで固まったりすることがあります。5ピラーの視点の意義は、一つの検定しやすいスキルに過度に集中するのではなく、トレードオフを明確に見ることです。より広いスコアカードを作成している場合、カスタマーサポート担当者の採用方法で全体像を説明しており、採用の5つのピラーでパーツがどのように組み合わさるかを説明しています。
Illustrative weights — configurable per role, locked at the first candidate for comparability.
評価の方法
多肢選択クイズは過剰な約束を捕捉するかどうかを伝えられません。AIを禁止することはもはや存在しないワークフローをテストします。実際に使うツールを使った現実的なサポートシナリオを候補者に与え、編集を観察します——これがAI Sandboxアセスメントの機能です。評価はワークサンプルであり、自己報告ではないため、シグナルは現実に近い課題での候補者の実際の行動です。貼り付けたポリシー、削除した過剰な約束、和らげた冷淡な一文、送信前に検証した主張。スキルをプロキシから推測するのではなく、実際に起きている様子を観察します。これが正直なテストである理由はAI採用で、または職種調整アセスメントの作成をご覧ください。
評価記録は、読む人が何を探すべきかを知っている場合にのみ有用です。そのためインタビュアーがトランスクリプトを開く前にブリーフしてください。AI Sandbox課題を初めて読む採用マネジャーの直感は、流暢な最終返信を賞賛することですが、それはまさに採点すべき間違ったものです——磨かれた返信はモデルが機能することを証明しますが、候補者が機能することは証明しません。彼らを下書きと送信バージョンのデルタに向け、すべてのトランスクリプトに3つの具体的な質問をするよう指示してください。モデルは何を誤ったか、候補者はそれを捕捉したか、トーンを壊さずに修正したか。AIの多用は赤信号ではなく、少用は美徳ではありません。シグナルはその上に重ねられた人間の判断の質です。パネルに同じ4Dの語彙を使わせることで、個人の印象ではなく候補者間で比較可能なメモになります。
サポートでは、AIが1日に100通の返信を書けます。採用したい人は、それぞれを読んで「もし自分が顧客だったら、これはうまく届くだろうか?」と問いかけ、答えがノーなら修正する人です。
執筆者
Aayesha Patel · Co-founder, Hanzomon Inc
Co-founder of Hanzomon. Writes about skills-based hiring, fair assessment and building a better candidate experience.