問い合わせを次担当へ渡す前に、コンテキスト・パケットを作る

問い合わせ引き継ぎは、要約ではなく判断材料を渡す

問い合わせ対応で引き継ぎが止まる原因は、前任者が文章を短くできなかったことだけではありません。「顧客は何を尋ねたのか」「回答の根拠はどこか」「まだ分からないことは何か」「誰がいつまでに決めるのか」が一つの文章に混ざるため、次の担当者が最初から原文を読み直すことになります。

ここでいうコンテキスト・パケットは、問い合わせ本文を別の場所へ複製する文書ではありません。原文を正本として残し、次担当が必要な文脈だけを参照できる作業台です。要約を更新しても、いつでも元の問い合わせへ戻れることを完了条件にします。

この考え方は、AI導入前に問い合わせの現在地と止まった理由を整理する問い合わせステータスの引き継ぎともつながります。ステータスを「確認中」と書くだけで終わらせず、何を待っているかまで渡すのがポイントです。

最初にそろえる9項目と、正本を分ける理由

パケットは情報を増やすための台帳ではなく、判断の入口をそろえるための枠です。シートやCRMへ実装する場合も、本文のコピーと作業上の項目を分けてください。

項目	書く内容	空欄の時の扱い
問い合わせID	原文と一意に結び付く番号	採番できるまで進めない
原文の正本	メール、フォーム、CRMの参照先	原文へ戻して確認する
要約	相手の依頼と現在の状態	推測を入れず不足と書く
根拠	契約、仕様、過去回答などの参照先	事実確認へ戻す
不足情報	次に聞くこと、確認できない条件	質問担当を決める
リスク	個人情報、契約、料金、苦情、不明事実	人間確認で止める
次担当	実際に確認・返信する人	共有だけで完了にしない
期限	確認または次回連絡の日時	優先度を決められない
状態	下書き、確認中、承認済み、送信済み	送信処理へ渡さない

例えば「返品できますか」という問い合わせなら、要約は質問を短く言い換えるだけです。根拠には該当する規約や注文情報、不足情報には購入日と商品状態、リスクには契約条件や苦情の有無を書きます。回答案が自然でも、根拠が空欄なら承認済みにはしません。

原文を正本にするのは、入力情報の重複と改変を減らすためです。パケット側に本文を複製すると、あとから原文と要約のどちらが新しいか分からなくなります。参照先を持つ設計なら、要約の誤りを見つけた時も原文へ戻って修正できます。

AIに任せる範囲と、人へ戻す境界

AIは、原文から候補を整理し、指定した項目へ下書きを入れる作業に向いています。ただし、要約が正しいか、根拠が十分か、返信してよいかをAIの出力だけで決めないでください。パケットに下書きと承認結果を別の欄で保存すると、便利さと責任の境界が見えます。

AIが補助できる作業	人が確認する作業
問い合わせの分類、要約の下書き	要約が原文と一致しているか
不足情報の候補、根拠候補の抽出	根拠の適用条件と最新性
返信案の文体調整、項目の転記	契約・料金・苦情・例外の判断
期限や担当の候補表示	誰が返信し、いつまでに連絡するか

個人情報、契約、価格、苦情、事実が不明な内容は、AIの文章が丁寧でも自動送信へ進めません。リスクを隠すために要約を丸めるのではなく、該当するフラグを残して確認先へ戻します。これはAIを使わない判断ではなく、AIの役割を整理と下書きに限定する判断です。

担当者の確認理由を残すと、同じ差し戻しが繰り返されにくくなります。例えば「契約期間が原文で確認できないため、契約担当へ戻す」と書けば、次の人は文章を直す前に不足情報を補えます。引き継ぎ後の質問を記録する方法も、パケットの不足情報を改善候補へ戻す材料になります。

30分でコンテキスト・パケットを試す5手順

新しい台帳を全社へ展開する前に、直近1週間の問い合わせを数件だけ使い、次の順番で検証します。

1. 正本を決める。メール、フォーム、CRMのどれを原文の参照先にするか、一つの問い合わせIDで結び付けます。
2. 9項目の空欄を確認する。要約を書く前に、根拠、不足情報、リスク、次担当、期限が取れるかを見ます。
3. AIの下書きを人が照合する。要約と返信案を原文へ戻って確認し、推測された内容を削除します。
4. 通常・境界・停止を分ける。情報がそろった一般的な質問、確認が必要な質問、契約や苦情を含む質問を別の状態で扱います。
5. 送信直前に再検査する。承認後に本文、宛先、添付、根拠が変わっていないかを確認し、変化があれば人間確認へ戻します。

5手順の目的は、AIの精度を数値化することだけではありません。次担当がパケットを開いた時、原文へ戻り、未決事項を見つけ、誰へ質問すればよいか分かるかを確かめます。空欄が多い時は入力フォームやCRMの項目が足りない可能性があります。

状態名は会社の実情に合わせて構いませんが、「下書き」と「送信済み」を一つの完了欄で管理しないことが重要です。承認後に返信案を編集したら、再び確認中へ戻すルールを決めます。これにより、承認した文章と実際に送った文章の差分を見失いません。

引き継ぎを止めないチェックリスト

チェックの空欄は担当者の能力不足ではなく、業務設計の未確定部分です。空欄を埋めるために推測で進めず、確認先と期限をパケットへ残します。判断できない状態を見えるようにすることが、引き継ぎを止めない最初の改善です。

問い合わせが増えた時も、パケットを複雑にしすぎないでください。最初は1週間分で、どの項目が頻繁に空欄になるかを確認します。不足情報が毎回同じならフォームの質問へ、根拠が揺れるならFAQや正本へ、承認待ちが続くなら役割分担へ戻します。ログやパケットは保存場所ではなく、業務を直す入口です。

AI導入後の判断ログを更新する時も、担当者、入力情報、業務範囲、AI設定、反応、例外の変化を合図にします。AI判断ログを更新する6つの合図を使い、パケットの前提が変わった時に古い判断を使わないようにしてください。

FAQ：問い合わせの引き継ぎ設計で迷うこと

問い合わせの引き継ぎに要約だけでは足りないのはなぜですか？

要約だけでは、何を根拠にしたか、不足している情報は何か、誰がいつまでに判断するかが抜けやすいからです。原文の参照先と未決事項を別の項目で残すと、次担当が確認を再開できます。

AIに問い合わせの返信を任せてもよいですか？

AIは整理と返信案の下書きまでに限定し、事実確認、例外判断、宛先と本文の送信承認は人が行います。個人情報、契約、料金、苦情、不明事実は人間確認へ戻します。

コンテキスト・パケットは何から始めればよいですか？

まず1週間分の問い合わせから、問い合わせID、原文の参照先、要約、根拠、不足情報、リスク、次担当、期限、状態を揃えます。空欄がある時は送らず、確認先へ戻してください。

まとめ：短い要約ではなく、判断を再開できる引き継ぎへ

問い合わせを次担当へ渡す時は、要約の短さよりも、原文へ戻れること、根拠と不足情報が見えること、リスクが人へ戻ることが重要です。9項目のコンテキスト・パケットを小さく試し、AIの下書きと人の承認を分けてください。

自社の問い合わせ、FAQ、CRMでどこに文脈の欠落があるかを整理したい場合は、Miraigentの無料診断をご利用ください。対象業務、入力情報、例外、人間確認、記録の戻し先を一緒に棚卸しし、次に直す一件を決めます。