過去の対応履歴とFAQから回答案を作成する

処理の起点を決める

チケットが担当者に割り当てられたときを起点にします。UC-0018 の振り分け直後です。

担当者がチケットを開いた時点では遅すぎます。開いたときには既に回答案が用意されている状態にすることで、待ち時間がゼロになります。

入力データを集める

顧客が使っている製品バージョンを渡すことが重要です。 バージョンによって操作手順が違う場合、古いマニュアルを根拠にした回答は誤りになります。

データの取得方法を決める

準備フェーズの分割が、この構成の成否を決めます。 情報源ごとに分け方が違います。

過去チケットの扱いには、追加の処理が必要です。

1. 顧客情報のマスキング … 社名、氏名、メールアドレス、契約番号を伏せます。これを省くと、A社への回答がB社への回答案に混入します
2. 解決したチケットのみを対象にする … 「対応中」「エスカレーション」で終わったチケットの回答は、正しいとは限りません
3. 古いチケットの除外または重みづけ … 製品仕様は変わります。2年以上前のチケットは、既定で除外するか、大きく重みを下げてください
4. 誤回答の除外 … 「先ほどの回答を訂正します」というやり取りがあるチケットは、除外します

この前処理を省いて8万件をそのまま入れると、古い誤った回答が根拠として出てきます。

AIへ渡す前に整形する

1. 問い合わせからの検索クエリ生成 … 顧客の文章をそのまま検索すると、挨拶や背景説明がノイズになります。質問の核心部分を抽出してから検索します
2. 製品・バージョンでのフィルタ … 顧客の契約情報でフィルタします
3. 検索の実行 … ハイブリッド検索（ベクトル検索とキーワード検索の併用）を使います。製品名や機能名は表記の一致が重要なので、キーワード検索を併用しないと取りこぼします
4. 根拠の有無の判定 … 検索スコアが一定を下回る場合、根拠なしとして扱います

AIに処理させる

指示内容を固定する

あなたはカスタマーサポートの担当者を支援する担当者です。
以下の検索結果だけを根拠に、問い合わせへの回答案を作成してください。

【厳守事項】
- 検索結果に書かれていない内容を回答に含めないでください。
  一般的な知識やIT分野の常識で補わないでください。
- 回答の各段落について、根拠となる出典を必ず示してください。
  出典を示せない内容は書かないでください。
- 検索結果が問い合わせに答えていない場合、
  answerable を false にし、回答案を作らないでください。
  無理に関連づけた回答を作らないでください。
- 顧客が使用している製品バージョンは {version} です。
  異なるバージョンの手順を根拠にする場合、その旨を必ず注記してください。
- 返金、補償、契約内容の変更、値引き、納期の約束をしないでください。
  これらに関する問い合わせは needs_escalation を true にしてください。
- 障害・不具合の原因を断定しないでください。
  検索結果に既知の不具合として記載がある場合のみ、
  それを出典つきで示してください。
- 謝罪の文言を過剰に入れないでください。
  事実として自社に起因する事象が確認できる場合のみ、簡潔に記載します。

【顧客情報】
契約プラン: {plan} / 製品: {product} / バージョン: {version}

【問い合わせ】
{inquiry}

【検索結果】
{retrieved_documents}

「返金、補償、契約内容の変更、値引き、納期の約束をしない」の1行が、この構成でもっとも重要です。

AIが「今回は特別に返金いたします」と書いた回答案を、忙しい担当者が確認せずに送信すると、それは会社の意思表示になります。 撤回は困難です。これらの話題は、必ず人の判断とエスカレーションを経る設計にします。

「障害の原因を断定しない」も同様です。 「サーバー側の問題です」と回答してしまうと、後で顧客側の設定が原因だったと分かっても、既に伝えた内容は覆せません。

「謝罪を過剰に入れない」は、意外に重要です。 LLMは謝罪を多用する傾向があります。自社に非がない事象で謝罪すると、責任を認めたと受け取られることがあります。

出力形式を固定する

{
  "answerable": true,
  "draft_reply": "",
  "citations": [
    {
      "paragraph": 1,
      "source_type": "FAQ | マニュアル | 過去チケット",
      "source_id": "",
      "source_title": "",
      "source_url": "",
      "last_updated": "",
      "excerpt": ""
    }
  ],
  "version_mismatch": false,
  "needs_escalation": false,
  "escalation_reason": "",
  "uncovered_points": [],
  "confidence": "high | medium | low"
}

• citations の last_updated … 出典の最終更新日を必ず表示します。 3年前のマニュアルを根拠にした回答であることが、担当者に分かる必要があります
• uncovered_points … 問い合わせのうち、回答できていない部分。1件の問い合わせに3つの質問があり、2つしか答えられていない場合、これがないと担当者が気づきません

システムへ連携する

担当者の画面： 問い合わせ管理システムのチケット画面に、回答案と出典を表示します。出典は必ずリンクにして、元の文書を開けるようにします。

この構成では、回答案より出典のほうが重要です。 担当者が出典を開いて確認し、自分の言葉で回答を書くだけでも、検索の5分が削減されます。回答案は補助です。

学習ループ： 送信された回答を、翌日のバッチで検索インデックスに追加します。マスキング処理を経てから追加してください。

この部分は、問い合わせ管理システムの拡張性に依存します。画面へのカスタム表示ができない場合、別画面またはブラウザ拡張として提供する方法もあります。利用環境に応じた個別確認が必要です。

人が確認する

全件、人が確認して送信します。段階的な自動化もしません。

理由は、顧客へ直接届く文章だからです。誤った回答は、顧客の業務に影響を与え、信頼を損ないます。送信後の撤回はできません。

確認を実効的にするための設計が重要です。

1. 出典を必ずリンクで表示する … 出典を開けない回答案は、確認のしようがありません
2. confidence: low を目立たせる … 担当者が注意すべき案件を分かるようにします
3. uncovered_points を表示する … 答え漏れを防ぎます
4. ワンクリック送信を作らない … 回答案をそのまま送れるボタンを作ると、確認せずに送る運用が生まれます。必ず編集を経る設計にしてください

例外に対処する

記録を残す

• 問い合わせ内容
• 検索された根拠と、そのスコア
• AIの回答案と citations
• 実際に送信された回答
• 回答案と送信内容の差分
• 担当者が出典を開いたか

「回答案と送信内容の差分」が、この構成の唯一の実測指標です。 差分が小さいほど回答案が役立っています。差分が大きい状態が続くなら、検索の作り方かプロンプトに問題があります。

「出典を開いたか」の記録も重要です。 開かずに送信している状態が続くなら、それは確認が形骸化している兆候です。