AI要約の前に、利用目的と原文の正本を決める

問い合わせ要約の目的は、文章を短くすることではありません。担当者が次の行動を判断できる状態にすることです。目的を決めずに要約すると、顧客の希望、期限、未確認事項、感情の強さ、添付資料の存在など、業務に必要な情報まで消えることがあります。

会社がAI導入前に決めるべきことは、「どのAIなら要約できるか」より先にあります。要約する問い合わせの種類、入力してよい情報、原文の保存場所、確認者、AIが処理を止める条件を決めます。入力範囲はAIに送ってはいけない情報の決め方、担当の分け方は生成AI導入後の責任者と役割分担と合わせて整理できます。

原文は、権限管理されたメール、フォーム管理画面、問い合わせ管理システムなどを正本にします。AIの要約を正本へ置き換えると、言い回しの強さや例外条件を後から確かめられません。一方で、原文を複数の表やチャットへ無制限にコピーする必要もありません。要約には原文IDや参照先を付け、閲覧権限のある人だけが戻れる設計にします。

問い合わせ要約の安全ルール7項目

項目先に決める内容危険な状態
目的振り分け、引き継ぎ、返信下書きなど一用途用途不明の全文要約
入力範囲業務に必要な最小部分署名や履歴も一括投入
伏せる情報氏名、連絡先、識別子、機微情報不要な個人情報を残す
抽出項目用件、希望、期限、未確認、次の行動自由文だけを保存
人間確認原文と要約を照合する担当AI出力を自動確定
停止条件苦情、契約、返金、安全など高影響案件も通常処理
記録原文参照、日時、確認者、修正理由要約だけが残る

個人情報は、すべて消せばよいわけでも、同意がありそうだから入れてよいわけでもありません。要約の目的に不要な情報を入力前に除き、必要な識別子は社内の問い合わせ番号へ置き換えます。利用するAIサービスの規約、データの扱い、保存設定、契約条件も確認します。

「個人情報を伏せる」と「顧客の判断材料を消す」は別です。たとえば納期希望や利用環境は対応に必要な場合があります。何を残すかは、データの種類だけでなく業務目的と影響で決めます。判断に迷う情報はAIへ渡す前に人へ戻します。

要約項目を固定し、事実と判断を分ける

自由な一段落要約は読みやすくても、AIが推測した優先度や感情を事実のように混ぜる可能性があります。要約欄を「問い合わせ種別」「顧客が明記した希望」「期限」「確認済み事実」「未確認事項」「次の担当」「原文参照」に分けると、何が書かれていて何が推測なのかを確認しやすくなります。

  1. 受付時にIDを付ける:氏名ではなく問い合わせ番号で作業を追う。
  2. 不要情報を入力前に除く:署名、過去の全履歴、関係のない添付を外す。
  3. 固定項目で抽出する:用件、希望、期限、未確認、次の行動だけを求める。
  4. 推測を禁止する:原文にない優先度、原因、感情、契約判断を書かせない。
  5. 人が原文と照合する:欠落、取り違え、過剰な断定を修正する。
  6. 確認済み要約だけを共有する:未確認のAI出力を担当者の確定メモにしない。

顧客が「急ぎではない」と書いた場合は事実として残せます。しかし、文面が短いから「怒っている」、質問が多いから「購入意欲が高い」と判断することは避けます。担当者の判断が必要なら、要約とは別の欄に、判断者と根拠を記録します。

返信作成までAIへ任せる場合も、要約と返信判断を一つの処理にしないでください。まず原文から事実を抽出し、人が確認した後に、承認済み情報を使って下書きを作ります。返信の確認条件はAI返信下書きに人間確認を残す方法で詳しく整理しています。

通常・境界・停止の3段階で振り分ける

すべての問い合わせを同じフローへ通すと、簡単な連絡まで確認待ちになり、高影響の案件は見落とされます。通常ケース、境界ケース、停止ケースの三段階を決めます。

  • 通常:営業時間、一般的なサービス範囲、資料請求など、承認済み情報で整理できる内容。
  • 境界:複数の要件、情報不足、過去対応との矛盾、強い不満など、担当者が分類を確定する内容。
  • 停止:契約、返金、事故、健康、安全、法令、本人確認、機微情報など、通常のAI要約から外して権限者へ戻す内容。

停止は失敗ではありません。AIが処理しない条件を先に決めておくことで、担当者は迷わず人へ戻せます。例外の種類と戻し先は生成AIが迷った時の例外対応ルールも参考になります。

境界ケースは、運用改善の材料です。同じ情報不足が続くならフォーム項目を見直し、同じ分類迷いが続くならFAQやカテゴリ定義を直します。AIの精度だけを調整せず、問い合わせの入口と正本を改善先に含めます。

確認者が見る5つの照合ポイント

確認者は文章の美しさではなく、業務上の欠落を見ます。第一に、問い合わせ種別が原文と一致しているか。第二に、顧客が求めることと、会社側が推測したことが分かれているか。第三に、日付、金額、数量、商品名などが正確か。第四に、未確認事項が消えていないか。第五に、次の担当と期限が具体的かです。

要約が短すぎる場合は、原文を追加投入する前に、抽出項目を見直します。「重要な点をまとめて」ではなく、「顧客が明記した希望、期限、未確認事項を、原文にない推測を加えず箇条書きにする」と指定します。それでも判断できない時は、人が原文を読みます。

修正した場合は、個人名ではなく理由を残します。たとえば「期限の欠落」「商品名の取り違え」「感情の推測を削除」「停止ケースへ変更」です。同じ理由が続けば、入力前処理、要約テンプレート、フォーム項目、担当分けのどこを直すかを決めます。

AIスキルや一般的なプロンプトはコピーしやすくても、「この表現なら苦情担当へ戻す」「この添付は要約せず原文確認にする」という判断は会社固有です。残すべきなのは会話の全文ではなく、次回の判断を助ける記憶です。これは記憶の保管ではなく、記憶の補完です。運用ログの型は小さな会社のAI活用ログ7項目にまとめています。

小さく試すための要約テンプレート

最初の一業務では、次の欄だけを用意します。「問い合わせID」「種別」「顧客が明記した希望」「期限」「確認済み事実」「未確認事項」「停止条件の該当」「次の担当」「原文参照」「確認者」です。AIには空欄を推測で埋めず、「記載なし」と出すように指示します。

試験期間中は、AI要約と人の要約を比べるだけでなく、欠落件数、誤分類件数、確認にかかった時間、停止できた件数を記録します。速さだけで評価すると、安全確認の負担を別の担当者へ移しただけになる場合があります。試す・直す・止めるの基準は生成AIの試験導入で決める成功基準も参照してください。

保存期間も決めます。要約ログを学習目的で残し続けるのではなく、問い合わせ対応に必要な期間、改善検証に必要な期間、削除責任者を分けます。原文と要約に異なる保存期間を設定する場合は、参照切れ後の扱いも決めます。

よくある質問

問い合わせ全文をAIへ入力してもよいですか?

原則として全文投入を前提にしません。利用サービスの規約、契約、社内ルールを確認し、要約目的に不要な個人情報や機密情報を除いた必要最小限の範囲にします。判断できない場合は入力前に担当者へ戻します。

AIの要約だけをCRMへ保存してよいですか?

要約だけでは誤りを検証できません。権限管理された原文の参照先、要約日時、確認者を残してください。原文をCRMへ複製する必要がない場合は、問い合わせIDで参照します。

どの問い合わせはAI要約から外すべきですか?

契約、返金、苦情、事故、健康、安全、法令、本人確認、機微情報など、誤要約の影響が大きい内容です。自社の業務に合わせて停止条件と戻し先を明文化します。

個人情報を伏せれば必ず安全ですか?

いいえ。組み合わせで個人を識別できる情報、社外秘、契約上入力できない情報もあります。伏せ字だけで完了とせず、利用目的、入力範囲、サービス設定、権限、保存期間を合わせて確認します。

次の一歩:問い合わせ一件を固定項目で要約する

今日の問い合わせ一件を選び、氏名など不要な情報を除いたうえで、用件、希望、期限、未確認事項、次の担当の五項目に分けてください。AI要約を原文と照合し、欠けた項目と修正理由を一つ残します。それが自社向け要約ルールの最小単位になります。

Miraigentの無料AI導入診断では、問い合わせの入口、入力してよい情報、正本、人間確認、停止条件、記録の戻し先を棚卸しします。要約ツールを増やす前に、一つの問い合わせ業務から安全な流れを決めたい企業向けです。