問い合わせを生成AIで整理したいとき、最初に決めるのは自動返信の指示文ではありません。どの問い合わせをどこまで読ませ、どこで人へ戻すかを先に決める判断表です。

先に結論です。初回試行は、AIに分類候補と原文の根拠を出させるところで止めます。返信、外部送信、担当者の自動割当、CRM・チケット更新にはつなぎません。

この記事で使う3ラベル、要確認フラグ、5件程度の試行、記録テンプレートは、初回検討を小さく切り出すための編集上の提案です。公的資料が定める標準でも、5件で分類精度や安全性を保証する方法でもありません。

まず決めるのは、分類の後に何をしないか

問い合わせの分類と、返信や担当割当を決めることは別の仕事です。分類だけなら、公開または合成した短文で、文面に現れた根拠を確認するところから始められます。

一方で、顧客への返信、緊急度や優先度の決定、契約条件の判断、担当者の確定、業務システムへの書込みは、入力・権限・社内ルール・人の責任が別に関わります。初回試行では、この後工程を対象外にします。

公的資料が示す論点と、この記事の提案を分ける

個人情報保護委員会の生成 AI サービスの利用に関する注意喚起等は、個人情報を含むプロンプトを入力する場合の必要範囲や、提供者のデータ利用条件を確認する論点を示しています。また、生成AIの応答には不正確な内容が含まれ得るため、利用規約やプライバシーポリシーを確認して判断するよう注意を促しています。

デジタル庁の行政向け資料は、生成AI出力の誤りが影響し得る業務、人による出力の適切性判断、利用ルール、リスク発生時の手順を考える補助的な背景になります。ただし、政府情報システム向けの資料であり、民間中小企業へそのまま適用される一律の基準ではありません。

したがって、ここからの3ラベルと手順は、公的資料の転記ではなく、上の論点をLevel 1の初回試行へ縮めた記事上の提案です。

3ラベルの判断表

最初にラベル名と行き先を人が決めます。ラベルは、AIに最終判断を委ねるためではなく、次に誰が何を確認するかをそろえるためのものです。

ラベル(記事の提案) 目安 次の行き先
定型情報 公開情報や社内で確認済みの定型案内に関する問い。個人情報、契約の例外、追加の事実確認が残っていない 人が原文と案内の根拠を確認する。返信や送信は人の業務として別に判断する
担当者の確認が必要 契約、料金、例外、利用条件、事実関係など、文面だけでは決められない要素がある 担当者または社内の確認役へ戻す。AIには返信文や担当者の決定をさせない
対象外・追加情報待ち 窓口の対象外、必要情報の不足、入力許可の不明、高影響・緊急に関わる内容 AIへの入力または結果の利用を止め、人の確認先へ戻す

ここでいう「要確認」は4つ目のラベルではありません。原文に根拠がない、境界が曖昧、推測が必要、または確認者が決まっていない場合に付ける停止フラグです。ラベルを無理に確定させないために使います。

仮想例:5件の短文を3ラベルに置く

次は実在の顧客文面ではない仮想例です。検証用に作った短い文であり、実在データの入力可否や業務効果を示すものではありません。

No. 仮想の問い合わせ 分類候補 人が確認すること
1 営業時間と問い合わせ窓口を教えてください。 定型情報 公開されている案内と原文の根拠を照合する
2 契約期間の途中でプランを変更できますか。 担当者の確認が必要 契約条件と例外の有無を確認する
3 見積書に含まれる作業範囲を確認したいです。 担当者の確認が必要 見積書や社内の確定情報へ戻る
4 担当者の個人携帯へ資料を送ってください。 対象外・追加情報待ち 個人情報や外部送信に関わるため、入力・送信を止める
5 今朝から使えず、納品に影響しています。 対象外・追加情報待ち 障害・緊急対応に関わるため、AIの判定で処理を進めず人へ戻す

4と5のような内容は、AIが緊急度や優先度を数値化して決める対象ではありません。人が入力前に停止対象と判断し、必要な社内手順へ戻します。

最小試行は、5件を分類だけで終える

1. 入力してよい短文を先に選ぶ

実在の個人情報、顧客情報、従業員情報、契約情報、営業秘密、認証情報を含まない公開または合成の短文を、5件程度用意します。入力許可が分からない場合は、合成に置き換えると決めつけず、その文を使わずに人へ戻します。

公開・合成の短文を選ぶことは、初回試行の範囲を小さくするための提案です。合成データなら、どのサービスでも必ず安全という意味ではありません。利用サービスの条件と社内ルールが確認できない場合は停止します。

2. 3ラベルと停止フラグを、AIへ渡す前に決める

ラベル名、目安、次の行き先、対象外の条件を表にします。特に、個人情報や入力許可不明の文、契約や高影響判断、苦情・事故・不正・緊急対応に関わる文は、AIに分類させる前に戻し先を決めます。

3. AIには分類候補と根拠だけを返させる

使う指示文は、次の程度に絞ります。

次の問い合わせを、定型情報、担当者の確認が必要、対象外・追加情報待ちのいずれかの候補に分類してください。

返すものは、ラベル候補、根拠になった原文の短い箇所、判断できない理由だけにしてください。原文に根拠がなければ、要確認としてください。

返信文、緊急度、優先度、担当者、顧客への送信、CRM・チケット更新は出力しないでください。

この指示文は記事上の試行例です。公的資料が定めたプロンプトではありません。5件を一度に処理するか1件ずつ処理するかよりも、入力範囲と人の確認を固定することを優先します。

4. 人が原文へ戻って照合する

AIの候補をそのまま採用せず、元の問い合わせと突き合わせます。確認するのは次の4点です。

  • ラベルを支える文言が、原文のどこにあるか
  • AIが原文にない事実や意図を足していないか
  • 個人情報、高影響、緊急、入力許可不明に当たらないか
  • 次の返信、送信、担当割当、業務システム更新へ進もうとしていないか

どれか一つでも確認できなければ、要確認フラグを付けて人へ戻します。信頼度の数値だけで採否を決めません。

5. 結果を記録し、1回で止める

各件について、ラベル候補、根拠、確認者、確認日、未確認事項、停止理由を残します。最初の試行で見るのは、分類精度や工数削減ではなく、どの条件で人へ戻ったかです。

記録テンプレート:根拠へ戻れる形にする

次の欄を表計算や社内の記録様式へ移して使います。記入例の文面は仮想例です。

項目 記録する内容
試行日 YYYY-MM-DD
入力ID・出所 合成文 No.2、または公開情報の出所
入力許可 公開/合成/不明。不明なら停止
ラベル候補 3ラベルのいずれか、または要確認
原文の根拠箇所 AIが示した箇所と、人が照合した箇所
人の判断 継続、要確認、対象外・追加情報待ち
未確認事項 契約条件、事実関係、入力許可など
確認者・確認日 社内で決めた確認者と日付
停止理由・戻し先 停止した条件と、戻した責任者・窓口

保存方法と保存期間は、このテンプレートで固定しません。社内ルール、業務、利用サービスの条件に合わせて決めます。記録を残したことだけで、監査、正確性、安全性、法的適合性が保証されるわけではありません。

ここで止める:入力・出力・業務接続を分ける

次のいずれかに当たる場合は、AIへ入力しないか、結果を使わずに人へ戻します。

  • 個人情報、顧客情報、従業員情報、契約情報、営業秘密、認証情報を含む
  • 医療、法務、金融、雇用、与信、安全確保に関わる判断が必要
  • 苦情、事故、不正、障害、緊急対応に関わる
  • 文面だけでは事実確認ができない、情報が足りない、入力許可が分からない
  • AIの出力をそのまま返信、外部送信、緊急度・優先度の決定、担当者の自動割当につなげる
  • CRM、チケット、業務システム、権限、API、AIエージェント本番運用へ接続する

止めた後の戻し先は、担当者、業務責任者、情報管理の責任者など、社内で事前に決めた確認先です。迷う件を「たぶん定型」として通さないことが、この初回試行の停止線になります。

1回後に見直すのは、分類の数ではなく止まった理由

5件を試したら、次の件数を記録します。

  • 定型情報として人が確認できた件
  • 担当者の確認へ戻った件
  • 対象外・緊急として止めた件
  • 情報不足で止めた件
  • AIの候補と人の判断が一致しなかった件

これらは試行の観測記録であって、分類精度、生産性、売上、顧客成果の指標ではありません。5件で精度が分かった、本番運用へ進める、と判断する材料にもなりません。

見直すのは、ラベルの目安が重なっていないか、確認者が決まっていたか、停止理由を記録できたかです。境界が決まらないなら、ラベルを増やしてAIの処理範囲を広げる前に、社内ルールと戻し先を決めます。

まとめ:最初の一歩は、分類候補を人の確認へ戻せる形にする

まず、公開または合成した短文を5件程度用意し、3ラベルと要確認フラグを人が先に定義します。AIにはラベル候補と原文の根拠だけを返させ、1件ごとに人が照合し、返信・送信・書込みへ進めずに記録します。

この手順で停止条件や確認者を決められない場合は、ツール導入や業務接続を進めず、社内の責任者へ戻してください。検索需要、読者反応、記事canonicalへのクリック、分類精度、工数、業務成果、MASTER key株式会社とAX事業部の認知は、この原稿だけでは検証されていません。

参照元