はじめに
問い合わせと一口に言っても、その中身はさまざまです。「返品したい」と「この商品は自分に合いますか?」では、返すべき情報も、望ましい文章のトーンもまったく違います。
すべての問い合わせを同じプロンプトで処理しようとすると、下書きはどっちつかずになります。そこで返信下書きシステムでは、まず問い合わせの意図を分類し、意図に応じて回答の型を切り替えています。
この記事では、意図分類の考え方と、意図別に回答パターンを出し分ける仕組みを解説します。
なぜ意図を分類するのか
問い合わせの「型」は限られている
数多くの問い合わせを見ていると、実は内容は数種類の型に収れんします。返品・交換、配送状況の確認、在庫の問い合わせ、商品選びの相談——。この型ごとに、確認すべき情報も回答の構造も決まっています。
型を先に見極めておけば、AIに「この問い合わせは配送状況の確認だから、注文ステータスを軸に答えて」と的確な指示を出せます。逆に型を見極めないまま処理すると、返品の話に在庫案内が混ざるような、ちぐはぐな下書きになりがちです。
意図別に必要な情報も変わる
意図が分かると、注入すべき文脈も変わります。配送状況なら注文ステータスと配送先、返品なら購入日と返品ポリシー、商品相談なら在庫と商品スペック——というように、優先して見るべき情報が意図ごとに違うんです。
分類を最初に行うことで、後続の文脈収集や回答生成を意図に最適化できます。
意図の分類と回答の出し分け
LLMによる意図の判定
意図の分類はLLMに任せています。問い合わせ文を渡し、あらかじめ定義した意図カテゴリのどれに当てはまるかを判定させます。ルールベースのキーワードマッチと違い、「届かない」「まだ来ない」「発送された?」といった多様な言い回しを、同じ「配送状況」の意図として拾えるのが利点です。
一つの問い合わせに複数の意図が含まれることもあります(「返品したいが、その前に在庫を確認したい」など)。その場合も主たる意図を軸にしつつ、副次的な意図を補足として扱えるようにしています。
意図別テンプレートの適用
判定した意図に応じて、回答テンプレートを切り替えます。テンプレートといっても穴埋め文ではなく、「この意図のときはどんな順序で、どんなトーンで書くべきか」をAIに伝える指針です。
たとえば返品なら「まず受付を伝え、次に手順を番号付きで示し、最後に不明点の窓口を案内する」といった構成の型を渡します。これにより、意図ごとに一貫した品質の下書きが出せます。
商品相談には接客ナレッジを追加注入
商品相談は特別扱いしています。単に商品情報を返すだけでは足りず、「どんな用途か」「予算は」「これまで何を使っていたか」を引き出しながら提案する、接客的な対話が求められるからです。
そこで商品相談と判定された場合は、商品診断の会話パターンをまとめた接客ナレッジをプロンプトに追加で注入します。ベテラン販売員がどう質問を重ね、どう提案につなげるかのパターンを学ばせることで、下書きが「マニュアル対応」から「相談に乗る対応」へと変わります。
チケット本文をLLMに渡す
返品・配送・在庫・商品相談などのカテゴリに判定
回答の構成とトーンの指針を切り替える
商品診断の会話パターンをプロンプトに注入
意図に最適化された返信下書きを出力
分類設計で意識していること
「分類できない」を許容する
すべての問い合わせがきれいに型に収まるわけではありません。複雑なクレームや、複数の話題が絡む問い合わせは、無理に型へ押し込めるとかえって下書きが崩れます。
そこで「どの型にも自信を持って分類できない」ケースを想定し、その場合は汎用的な下書きに留めるか、オペレーターの判断に委ねる設計にしています。無理に自動化しないことも、品質を守る一つの選択です。
テンプレートは育てるもの
意図別テンプレートは、一度作って終わりではありません。実際の下書きとオペレーターの修正内容を見ていると、「この意図のときはこの一文を足したほうがいい」といった改善点が見えてきます。運用しながらテンプレートを磨いていくことで、修正の手間がじわじわ減っていきます。
分類は手段であって目的ではない
意図分類の目的は、あくまで「良い下書きを出すこと」です。分類の精度そのものを追い求めるより、分類結果が回答の質にどう効いているかで判断するのが実務的です。
まとめ
問い合わせの意図を分類し、意図別に回答の型を出し分けることで、下書きの精度は大きく上がります。
- 問い合わせの型を先に見極め、注入する情報と回答の構成を最適化する
- LLM分類は多様な言い回しを同じ意図として拾えるのが強み
- 商品相談には接客ナレッジを追加注入し、相談に乗る対応へ引き上げる
- 分類できないケースを許容し、テンプレートは運用で育てる
意図別に生成した下書きを、人がどうレビューして送信するか。次は下書き承認フローとオペレーター体験の設計で運用面を解説します。文脈の集め方は顧客文脈の注入を、全体像はハブ記事をご覧ください。