サポートプロンプトに追加制約が必要な理由
サポートプロンプトは、失敗のコストが準最適な出力にとどまらず、ポリシー違反、法的責任、顧客関係へのダメージにまで及ぶため、ほとんどのプロンプトタイプより多くの制約が必要です。 3つの理由：
- ポリシーリスク： 企業を代表して発言するサポートエージェント（人間またはAI）は記録を作成しています。価格に関する誤った回答やポリシー上限を超える返金コミットメントは責任を生じさせます。
- トーンの感受性： 顧客サポートのインタラクションは多くの場合、フラストレーションの地点から始まります。間違ったトーンはP2チケットをP1チケットに変える可能性があります。
- エスカレーションの重要性： エスカレーションすべき時にしないサポートプロンプトは、法的苦情が含まれるチケットが早期に解決済みとなるリスクがあります。
サポート回答テンプレートの種類
4つのテンプレートタイプがほとんどのサポートオペレーションワークフローをカバーします：トリアージ、エスカレーション、解決、フォローアップ。 各タイプには独自の目標、出力構造、必要な制約があります。
- 1トリアージテンプレート：問題タイプ（請求/技術/一般/アカウント）を分類し、重大度（P1=業務停止、P2=機能的影響、P3=見た目/情報）を割り当て、正しいチームにルーティングします。出力フォーマット：分類ラベル+ルーティング決定+確認メッセージ草案。
- 2エスカレーションテンプレート：トリガー条件 — 法的脅迫、アカウントキャンセル要求、データ侵害の言及、同じ問題への繰り返しP1、明示的な人間要求。出力フォーマット：中立的な顧客メッセージ+エスカレーション理由付きチケットフラグ+ルーティング指示。
- 3解決テンプレート：構造化されたパス — 顧客の言葉で問題を再述し、関連ポリシー条項を適用し、具体的な解決策を提案し、顧客の確認を求めます。出力フォーマット：解決草案+使用したポリシー参照。
- 4フォローアップテンプレート：トリガー：チケットが解決済みとマークされてから48時間後。出力：解決が維持されているか確認し、満足度シグナルを求める短いフォローアップメッセージ。
例：悪いプロンプト vs 良いトリアージプロンプト
悪いプロンプト：
「顧客の問題を手伝う。」
良いプロンプト：
「あなたはB2B SaaS プラットフォームのレベル1トリアージ agent です。このカスタマーメッセージを分類：請金（Financeにルーティング）、技術（Techにルーティング）、アカウント（Account Managementにルーティング）、一般（直接処理）。重大度を割り当て：P1=業務ブロック、1時間以内回答、P2=機能的影響、4時間以内回答、P3=情報提供、24時間以内回答。出力：分類ラベル + 重大度 + ルーティング決定 + 顧客メッセージ。制約：問題を解決しない — トリアージのみ。メッセージが「弁護士」「訴訟」「アカウント削除」「データ侵害」「GDPR」を含む場合、P1として分類し、法的エスカレーションに直ちにルーティング。」
なぜ違いが重要か： 悪いプロンプトはAIに「手伝う」の意味を推測させます。良いプロンプトは分類ルール、重大度レベル、ルーティングロジック、出力フォーマット、エスカレーショントリガーを定義し、各決定が1000+チケット全体で予測可能で一貫性があります。
サポートプロンプトの一般的な間違い
- エスカレーション条件がない： エスカレーショントリガーのないプロンプトはAIがすべての入力を処理できると仮定します。できません。法的脅迫、削除要求、データ露出には人間判断が必要です。解決策： 3–5の明示的エスカレーショントリガーを追加。正確なキーワード（「弁護士」「アカウント削除」「データ侵害」）とアクションをリストします。
- 一般的共感（「フラストレーションを理解します」）： AIは定型句を使用し、顧客は自動化として認識します。信頼を損ないます。解決策： 感情ではなく具体的な問題を確認するよう指示。「CSVエクスポートがあなたのアカウントで空ファイルを返していることがわかります」は「フラストレーションを理解します」より共感的です。
- ポリシー幻覚 — 存在しないポリシーの発明： 参照ドキュメントなしでは、AIはもっともらしい但し不正なポリシーを生成します。幻覚した払戻ポリシーは責任です。解決策： 実ポリシーテキストまたは決定ツリーをプロンプトに含めます。制約を追加：「このプロンプトに含まれていないポリシーを参照しないでください。顧客要求がカバーされていない場合はエスカレーション。」
- 単純なチケットのみでトーンテスト： AIは丁寧で明確な要求を処理します。怒った顧客、下品な言葉、間違った顧客、エッジケースで失敗します。解決策： 15+の実チケットをテスト：5つ普通、5つ怒った/困難、5つエッジケース（請金紛争、製品欠陥、法的言及）。正確性、コンプライアンス、トーン、エスカレーションで評価。
- すべてのサポートチャネルで同じプロンプト： メール、チャット、電話転写には異なる出力フォーマット、トーンレジスター、長さ制限が必要。解決策： 各テンプレートのチャネル固有の変種を作成。チャット=より短く非公式。メール=より長く構造化。電話サマリー=agent ノートのためのバレットポイント形式。
サポートプロンプトのトーン共感制御
サポートプロンプトのトーンには3つの明示的な制御が必要：共感マーカー、フォーマリティレベル仕様、非難言語の制約。 明示的な制御なしでは、モデルのトーンデフォルトが異なります。
- 共感マーカー： モデルが問題を対処する前に顧客のフラストレーションや状況を認識するよう指示。パターン：共感ステートメント → 問題の再述 → 解決パス。これはAIが解決に直接ジャンプすることを防ぎます。
- フォーマリティレベル： ブランドガイドに基づいてフォーマリティレジスターを指定（例：「senior customer service representative の形式性と親しみやすさ」）。「フレンドリーになる」のような漠然とした指示に頼らないでください。
- 非難言語の制約： モデルに顧客に責任を帰する言語を避けるよう明示的に指示。これはnegativePromptingの形 — やることに加えて、避けるべきことをモデルに伝える。10の困難なチケット例でテストします。
🔍 困難なケースでテスト
10の困難なチケット例に対してトーンプロンプトを実行してください — 怒った顧客、下品な言葉、顧客が事実上間違っているケース。モデルが非難言語制約または共感マーカーをいずれのケースで失敗する場合、デプロイ前に制約を修正します。
ポリシーコンプライアンスガードレール
サポートプロンプトのポリシーコンプライアンスには3種類のガードレールが必要：主題制約、出力制約、キーワード検出に結び付けられたエスカレーショントリガー。 これらのガードレールはAIが対処できることと対処できないことの境界を定義します。
- 主題制約： AIが応答で対処してはいけない主題の明示的なリスト。典型的な例：法的解釈、医学的助言、標準ポリシー外の価格例外、内部プロセスの詳細。フォーマット：「これらの主題を対処しないでください：リスト。顧客メッセージがこれらに触れる場合は、中立的確認で応答し、チームにルーティングしてください。」
- 出力制約： AIが決してどのような状況でも生成してはいけない特定の出力。分類禁止：価格の約束（例「割引を提供できます」）、法的解釈（例「これは契約違反です」）、医学的助言（例「医師の診察を受けてください」）、非標準例外の確認。
- エスカレーショントリガー： 特定のキーワード — 「弁護士」「訴訟」「アカウント削除」「データ侵害」「GDPR違反」 — 検出時にAIを直ちに停止し、エスカレーション出力を生成するようにします。フォーマット：「顧客メッセージに以下のいずれかの単語を含む場合：キーワードリスト、解決を試みないでください。エスカレーション確認を生成し、チケットに理由をフラグ立てし、チームにルーティングしてください。」
🔍 ポリシー幻覚のリスク
プロンプトの実ポリシーテキストがないと、モデルはもっともらしく聞こえるが存在しないポリシーを発明します。幻覚した「30日間払戻」（あなたの実ポリシーが14日間の場合）は法的責任です。常にポリシーテキストまたは決定ツリーをプロンプトに含めます。
人間のエージェントへの引き渡しのタイミングと方法
5つのトリガー条件が常に人間のエージェントへの引き渡しをもたらすべきです：法的言語、アカウント削除、データ露出、同じ問題への繰り返しP1、人間への明示的な要求。 これらは交渉不可能なエスカレーションポイント — AIはいずれのケースでも解決を試みてはいけません。
- 法的言語： 「弁護士」「訴訟」「訴訟」「法的措置」を含むメッセージは直ちにエスカレーションをトリガーします。AIは法的フレーミングに従事してはいけません — 確認してルーティングするだけです。
- アカウント削除： アカウント削除要求は高リスク。AIは要求を確認し、ハンドオフを確認しますが、人間の承認なしに払戻オファーまたは削除処理を試みません。
- データ露出： データ侵害、不正アクセス、またはGDPR/CCPA懸念の言及はエスカレーションをトリガーします。これには規制上のタイムラインと法的含意があり、人間の決定を要求します。
- 同じ問題への繰り返しP1： 顧客が同じP1問題を2回以上報告し、未解決の場合、人間のエージェントがチケット履歴を確認する必要があります。AIはもう一つの解決サイクルを試みてはいけません。
- 人間への明示的な要求： 顧客が人間、manager、またはagentと話したいと言う場合、AIはこの要求を直ちに満たす必要があります。先に問題を解決しようとしてはいけません。
🔍 ハンドオフパターン
正しいハンドオフ出力パターン：(1) 顧客の問題を一文で確認。(2) agent へのコンテキストをチケットノートで要約。(3) エスカレーション理由でチケットにフラグ。(4) 正しいチームにルーティング。顧客メッセージは中立でプロフェッショナル — 「I'm routing this to our team who can best help you」 — ハンドオフへの謝罪なし。謝罪はAIが失敗したことを意味し、それは間違ったフレームワークです。
よくある質問
サポートプロンプトが他のプロンプトタイプより厳しい制約が必要な理由は？
サポートプロンプトはカスタマー向け、ポリシー敏感、法的に重要です。サポートの悪い回答は美的問題ではなく、ポリシー違反、責任、または顧客関係の喪失です。
サポートプロンプトに常に含まれるべきエスカレーショントリガーは？
すべてのサポートプロンプトには少なくとも5つのエスカレーショントリガーを含むべき：法的言語、アカウント取消、データ露出、同じ問題の繰り返しP1、人間エージェントへの明示的リクエスト。
サポートプロンプトをポリシー準拠についてテストしますか？
難しいチケット例10個に対してサポートプロンプトを実行する。各出力が正しいエスカレーションをトリガーするか、またはトピック制約を尊重するかをスコアリング。
AIが人間エージェントにハンドオフするとき、謝罪すべきですか？
いいえ。ハンドオフ謝罪はAIが顧客をがっかりさせたことを意味し、ハンドオフを負に枠組みします。正しいパターンは：問題を認める→コンテキストをサマライズ→チケットにフラグを立てる→ルーティング。
サポートAIはいつ人間エージェントにハンドオフすべきか？
5つの条件が即座の人間エスカレーション必須：(1)法的言語、(2)アカウント取消、(3)データセキュリティ懸念、(4)同一チケットでの繰り返しP1、(5)人間への明示的リクエスト。
日本でのサポートチーム向けの追加要件は？
日本のサポートチームはMETI AI Governance 2024ガイドラインに準拠する必要があります。モデル選択には日本語サポートとMETIコンプライアンスを確認してください。エスカレーション規則を日本の消費者保護法に合わせます。