AIチャットボットに個人情報を入力する前の確認項目

問い合わせ対応をAIチャットボットに任せるとき、最初に迷うのが「お客様の名前や連絡先を入力してよいのか」という線引きです。便利そうだからと、集められる情報をすべて入力する必要はありません。先に、何を扱い、どこで止め、誰が確認するかを決めておくことが、安全な導入の出発点になります。

中小企業では、社長や店長、問い合わせ担当者がサービス選定から日々の返信まで兼ねることがあります。その状態で「個人情報に気をつける」という抽象的な方針だけを置くと、忙しい時間帯に判断がぶれます。名前は入力してよいのか、住所はどう扱うのか、問い合わせ履歴はいつ削除するのか、担当者へ引き継ぐときに会話をどこまで共有するのか。こうした判断をあらかじめ表にしておくと、担当者が変わっても同じ基準で運用しやすくなります。

この記事では、AIチャットボットへ顧客情報を入力する前に確認すべき項目を、実務で使いやすい順番に整理します。法律上の適用や必要な手続きは、事業内容、情報の種類、委託先との関係などによって異なります。ここで示す項目を確認の土台にし、判断が必要な場合は契約資料、サービス提供者の公式情報、個人情報保護委員会の情報や専門家の見解と照合してください。

最初に決めるのは「入力するか」ではなく三つの境界

個人情報を扱うかどうかを、サービス名だけで判断するのは困難です。同じチャットボットでも、公開ページで質問を受け付ける場合と、会員向けに個別相談へ対応する場合では、必要な情報と確認事項が変わります。まず、次の三つの境界を分けて考えます。

• 入力の境界：回答に本当に必要な情報だけを集め、不要な氏名・住所・番号は入力しない
• 回答の境界：個別の契約、返金、本人確認、専門的な判断はAIだけで結論を出さない
• 保存の境界：記録が必要な理由、閲覧できる担当者、保存期間、削除方法を先に決める

たとえば、営業時間やサービス概要を案内するだけなら、個人を特定する情報を受け取らない設計にできます。一方、予約変更や契約状況の確認では、本人を識別する情報が必要になる場合があります。その場合も、チャット欄へ自由入力してもらうのか、別の安全な窓口へ案内するのかを決めてから公開します。

入力データを三段階に分類する

最初に行うのは、社内で実際に使われている問い合わせ例を集め、入力情報を三段階に分ける作業です。分類名は自社の運用に合わせて変更できます。重要なのは、設定担当者が迷ったときに表を見て同じ判断をできることです。

Aは「公開されている情報なら何でも入力してよい」という意味ではありません。公開情報でも、質問と組み合わさることで個人を推測できる場合があります。Bに入れる情報は、何のために必要なのかを一文で説明できるか確認します。説明できない情報は、Aの公開情報で代替できないか見直すか、Cとして受け取らない方が運用しやすくなります。

Cの範囲は、会社や業種によって変わります。ここで挙げた項目を一律の法的判断として扱わず、自社が受け取る情報と業務上のリスクに合わせて定義してください。迷う情報を「とりあえずB」に集めると、保存・閲覧・削除の負担が後から増えます。

分類表を一時間で作る小さな手順

1. 直近の問い合わせから、実際に入力される項目を二十件ほど抜き出します。記録がなければ、想定質問を担当者で書き出します。
2. 各項目に「回答に必要か」「公開情報だけで代替できるか」「入力された場合に誰が対応するか」を記入します。
3. A・B・Cのいずれかを仮置きし、判断が分かれた項目には理由を一行で残します。
4. 最後に、公開前の確認担当者と更新日を表へ記入します。判断を変えたときは、変更理由も記録します。

たとえば「予約の希望日」は、空き状況の確認には必要でも、チャットボットだけで予約を確定できるとは限りません。「希望日を聞く」ことと「予約を確約する」ことを分け、前者は条件付き、後者は有人対応へ渡す設計にします。情報の分類と回答権限を別々に記録すると、入力できる情報ならAIが判断してよい、という誤解を防げます。

サービス提供者に確認する項目

入力する情報が決まったら、利用するサービスの公式資料、管理画面、契約内容を確認します。「セキュリティ対策があるか」とだけ尋ねるより、情報がどの場面で扱われるかを分けて質問する方が、社内で判断しやすくなります。

• 処理の目的：入力内容が回答、履歴、分析、サポートなど、どの目的で扱われるか
• 第三者提供や委託の範囲：サービス提供者以外の事業者が処理に関わる場合、どの資料で確認できるか
• AIモデルへの利用：入力内容や会話履歴が、モデルの改善や学習などに使われるか。設定や契約で選択できるか
• 保管場所と移転：データがどの地域・環境で処理または保管されるか、変更時に通知されるか
• 管理者向け機能：組織内の権限を分けられるか、操作履歴や会話履歴を誰が確認できるか
• 削除と問い合わせ：削除依頼の方法、削除対象、反映までの扱い、確認窓口がどこに書かれているか

回答が資料に見つからない場合は、都合よく補完しません。「公開情報では確認できない項目」として、提供者へ質問した日、回答者、回答内容を残します。仕様がプランや契約によって異なる可能性がある場合は、一般的なサービス紹介ではなく、自社が申し込む条件の資料を基準にしてください。

契約と社内説明を同じ表で確認する

契約確認では、利用規約だけを読んで終わりにせず、自社が誰から何を預かり、サービス提供者へどの処理を委ねるのかを整理します。法的な委託関係や必要な通知の要否は事業ごとに異なるため、ここでは結論を決めず、契約担当者や専門家へ確認するための材料を作ります。

「サービス上で削除できる」と書かれていても、バックアップや請求・障害対応の記録など、対象外の情報がある場合があります。削除の意味を一つにまとめず、画面から見えなくなること、サービス側の保存が終わること、社内に残った写しを消すことを分けて確認します。

保存期間・アクセス権・削除を公開前に決める

個人情報を入力するかどうかは、入力画面だけでなく、その後の記録の扱いまで見て判断します。入力後に誰でも履歴を読める、削除担当が決まっていない、保存期間が「必要な間」のまま、といった状態では、公開後の確認ができません。

保存期間は、長くすれば安心というものではありません。回答の引き継ぎや事実確認に必要な期間と、目的を終えた後の扱いを業務ごとに確認します。期間をすぐ決められない場合は、まず「いつ見直すか」を設定し、担当者が定期的に必要性を判断できるようにします。

アクセス権は、管理者全員にすべての会話を開く前提にしないことが重要です。設定変更が必要な人、問い合わせに返信する人、品質確認をする人では、必要な範囲が異なる場合があります。サービスに細かな権限分けがあるかは、実際の契約条件と管理画面で確認し、難しい場合は入力情報を減らすなど別の対策を検討します。

削除テストも公開前に一度行います。テスト用の情報を入力し、管理画面、エクスポートしたファイル、社内メモやメールに残らないかを確認します。削除後に何が見えなくなったか、確認できない部分がどこに残るかを記録しておくと、問い合わせを受けたときの説明がぶれません。

中小企業向けの導入手順：小さく試して境界を確認する

担当者が少ない会社ほど、最初からすべての問い合わせを対象にしない方が確認しやすくなります。情報の分類とサービス確認を終えたら、次の順で試験運用を組み立てます。

1. 対象業務を一つに絞る：公開情報で答えられる質問や、営業時間・サービス概要の案内など、根拠を確認しやすい範囲から始めます。
2. 入力項目を最小化する：氏名や連絡先を必須にする前に、匿名の質問だけで目的を達成できないかを確認します。
3. 停止条件を文章にする：本人確認、契約変更、返金、苦情、専門的判断など、AIが結論を出さない質問を例文で登録します。
4. テスト質問を作る：通常の質問、情報が足りない質問、入力させない情報を含む質問、担当者へ渡す質問を用意します。
5. 担当者が結果を確認する：回答の正しさだけでなく、入力を求めすぎていないか、保存・削除の案内が適切か、停止条件で止まったかを確認します。
6. 変更履歴を残す：ナレッジや回答ルールを変えた日、理由、確認した質問、承認者を短く記録します。

AIが入力を受け取れるからといって、その情報を保存してよいとは限りません。保存しない方針でも、担当者が画面を見たり、手作業で転記したりするなら、その経路も確認が必要です。入力、表示、引き継ぎ、社内保存、削除までを一つの流れとしてテストしてください。

回答の根拠や保留条件を設計するときは、AIの回答精度とハルシネーション対策のガイドも参考になります。個人情報を扱う場合も、根拠を確認できない質問を無理に処理しないという判断が重要です。

有人対応へ切り替える条件を先に決める

有人対応は、AIが失敗した後の逃げ道ではなく、導入時点で設計する受け皿です。お客様が個人情報を入力しようとしたとき、AIが判断できないとき、個別対応が必要なときに、どの窓口へ何を伝えるかを決めます。

切り替え条件と引き継ぐ情報

• 本人確認書類、認証情報、決済情報など、チャットへ入力させない情報が書かれた
• 契約、返金、解約、補償、個別の料金など、条件を確認しないと結論が変わる
• 健康、法務、安全、苦情など、担当者の判断や専門窓口が必要になる
• 登録された情報に根拠がない、資料同士が食い違う、または更新日を確認できない
• お客様が回答に納得せず、同じ質問を繰り返している

担当者へ渡す情報は、会話全文をそのまま共有せず、対応に必要な最小限に整理します。相談の目的、確認済みの条件、AIが回答した内容、未確認の事項、希望する連絡方法を基本にし、不要な個人情報は転記しません。担当者が個別情報を見なければ対応できない場合は、どの安全な窓口で本人確認を行うかを案内します。

切り替え条件と引き継ぎ項目は、有人対応へ引き継ぐ方法でさらに整理できます。公開前には、担当者が不在の時間帯、返信までの目安、緊急時に使う別窓口を実際の案内文へ反映してください。すぐに返信できない場合は、即時対応と誤解させない表現にします。

情報を受け取ってしまった場合の停止手順

入力させない情報が届いたときに担当者が迷わないよう、短い停止手順を用意します。その場で事故かどうかを断定する必要はありません。まず拡大を止め、事実を確認できる状態にします。

1. 会話の継続を止める：情報を追加で求めず、指定窓口へ案内します。設定上、回答を停止できるかも確認します。
2. 共有を広げない：会話を社内チャットやメールへ不用意にコピーせず、確認担当者を限定します。
3. 事実を記録する：発生日時、入力された情報の種類、表示・保存された場所、実施した操作を記録します。
4. 提供者と社内責任者へ確認する：削除、アクセス制限、ログ確認など、契約や公式案内に沿って問い合わせます。
5. 再発防止を見直す：停止文、入力欄の案内、分類表、権限、保存と削除の手順を更新し、同じテストを再実施します。

「削除したつもり」で終わらせず、サービス上の表示、社内に保存した写し、担当者へ渡った情報をそれぞれ確認します。必要な報告や連絡があるかは、情報の内容と関係するルールによって変わります。社内の責任者、専門家、公式情報をもとに判断してください。

公開前チェックリスト

最後に、設定を公開する前に担当者同士で確認します。項目が埋まらない場合は、機能を増やすより対象業務を狭める方が、条件を確認しながら進めやすくなります。

• 入力データをA・B・Cに分類し、迷った項目の理由を残した
• サービスの処理目的、AIモデルへの利用、第三者・委託先、保管場所を確認した
• 契約資料と、自社がお客様へ説明する内容に差がないか確認した
• 保存期間、見直し日、アクセス権、退職・異動時の対応を決めた
• 削除の対象、依頼方法、実施者、完了確認、社内の写しを整理した
• AIが答えない質問と、有人対応の窓口・時間・引き継ぎ項目を決めた
• 通常・不足情報・入力禁止情報・有人対応のテストを実施した
• 変更履歴と、公開後にログを確認する担当者を決めた

ナレッジに登録する情報の整理や更新が必要な場合は、ナレッジ登録とOCR編集のガイドも確認してください。個人情報を含む資料を登録する前に、公開用の情報、社内確認用の情報、登録しない情報を分けることが重要です。

よくある質問