チャットボットのセキュリティ｜導入前に確認する5項目と、お客様が個人情報を入力したときの扱い

ホームページにチャットボットを置こうと社内で話を進めると、ほぼ必ずこの一言が返ってきます。「セキュリティは大丈夫なの?」。上司から、法務から、情報システムの担当から。聞かれた側は、ベンダーの資料にある「暗号化」「認証取得」の文字を頼りに「大丈夫だと思います」と答えるしかなく、そこで検討が止まってしまうことが少なくありません。先に結論を書きます。チャットボットのセキュリティは、AI が賢いかどうかでも、認証マークがあるかどうかでもなく、「お客様が入力した文章が、どこを通り、どこに残り、誰が読めるか」という通り道で決まります。通り道を言葉にできれば、ベンダーに何を確かめればよいかが分かり、自社側で何を決めなければならないかも見えてきます。この記事では、チャットボットのセキュリティで守る対象は何か、リスクの正体を 5 つに分けるとどうなるか、導入前にベンダーへ確かめる 5 項目を「聞く一言」つきでどう置くか、お客様が個人情報を入力してしまったときにどう扱うか、公開のときに自社側で決める 3 つは何か、そして資料に無いことを言わせない答え方の設計までを、明日から使える順番で整理します。

チャットボットのセキュリティとは ── 守る対象は「お客様の生の文章」

社内のサーバーや PC のセキュリティと、ホームページに置くチャットボットのセキュリティは、守る対象が違います。前者が守るのは自社の情報資産ですが、後者が守るのはお客様が入力した、そのままの文章です。チャットボットは、お客様が「何に困っているか」を自分の言葉で書く場所なので、そこには注文番号や契約の状況、ときには氏名や電話番号が、こちらが求めていなくても流れ込んできます。チャットボットのセキュリティとは、この「お客様の生の文章」が、入力されてから答えが返るまでの間にどこを通り、どこに残り、誰が読めるかを、設計として決めておくことです。

通り道は、大きく 3 つの場面に分かれます。1 つ目は入力される場面。お客様の画面からチャットボットへ文章が送られる、その瞬間です。ここで問題になるのは、通信が暗号化されているか、そして「そもそも何を集める設計か」です。2 つ目は送られ、残る場面。入力された文章は、答えを作るために AI の仕組みへ送られ、会話ログとして保管されます。ここで問題になるのは、送り先で学習に使われないか、ログが何日残るか、誰がそれを見られるか、です。3 つ目は答える場面。チャットボットは資料を元に答えを返しますが、その資料に社内向けの情報が混ざっていれば、お客様に言ってはいけないことを言ってしまいます。ここで問題になるのは、何を元に答え、何を元にしないか、です。この 3 つの場面を順に押さえると、セキュリティの話は「不安」から「確認項目」に変わります。

社内で生成 AI を使うときのルールと、何が違うのか

生成 AI の社内ガイドラインを整えた会社なら、「入れてよい情報・入れてはいけない情報」の線は既に引いているはずです。その考え方は、「生成AIの社内ガイドラインの作り方」で書いたとおり、使う人が社内の人であることを前提にしています。ところがチャットボットでは、入力するのが社外のお客様です。ルールを読んでもらうことも、守ってもらうことも、前提にできません。だからチャットボットのセキュリティは「入力する人を教育する」のではなく、「何が入力されても困らないように、集めない・残さない・見せない側で受け止める」という発想になります。社内ルールが「人の側の線」なら、チャットボットの対策は「仕組みの側の線」です。両方あって初めて、会社としての線になります。

チャットボットのセキュリティリスク 5 つ ── 何が、どこで起きるか

「チャットボットのセキュリティリスク」と検索すると、さまざまな脅威の名前が出てきます。名前を覚えるより、通り道のどこで何が起きるかで整理したほうが、対策とつながります。実務で押さえておきたいリスクは次の 5 つで、それぞれに「小さくする設計」が対応しています。

5 つを並べると、気づくことがあります。AI の賢さが原因になっているものが 1 つも無いのです。どれも「何を集め、どこへ送り、どこに残し、誰に見せ、何を元に答えるか」という設計の問題で、裏返せば、設計で小さくできます。そしてもう 1 つ。5 つには、製品側で決まるものと自社側で決まるものが混ざっています。ベンダーに「大丈夫ですか」と聞いて「大丈夫です」と返ってきても安心できないのは、質問が製品側にしか向いていないからです。次の章では製品側の確認を、その次の章では自社側の決めごとを書きます。

導入前に確認する 5 項目 ── ベンダーへ「聞く一言」まで

チャットボットを選ぶときの基準は、「チャットボットの選び方」で 5 つに整理しました。その 4 つ目が「セキュリティとデータの扱い」です。あの記事では確認すべき 3 点を 1 つのカードに収めましたが、実際にベンダーの前に座ると、「どう聞けばよいか」で手が止まります。資料には「万全のセキュリティ」「暗号化対応」と書いてあり、形容詞は豊富でも、こちらが知りたい「何を・何日・誰が」が書かれていないことが多いからです。だからここでは、5 つの項目それぞれに「聞く一言」を添えます。この一言に、名詞と数字で答えが返ってくるかどうかが、そのベンダーの設計の解像度です。

5 項目の答えは、口頭で済ませず、メールか議事メモに残してください。「万全です」ではなく「会話本文のみ取得・既定 90 日で自動削除・閲覧は管理者ロールのみ」のように、名詞と数字で残ります。これがそのまま、社内で「セキュリティは?」と聞かれたときの答えになり、プライバシーポリシーに書く内容の下書きにもなります。

チャットボットと個人情報 ── 入力されてしまったときの扱いと、公開時に決める 3 つ

製品側の確認が済んでも、セキュリティはまだ半分です。残りの半分は、公開のときに自社側で決めることで、これが抜けていると、どれだけ良い製品を選んでも柵になりません。出発点は、1 つの事実を受け入れることです。お客様の入力は、止められません。「個人情報は入力しないでください」と案内しても、困っているお客様は注文番号や電話番号を書きます。それを責める設計ではなく、書かれることを前提に、書かれても困らない側で受け止める設計にします。公開のときに自社側で決めるのは、次の 3 つです。

• ①案内文。チャットの最初の画面で、「個人情報(氏名・住所・電話番号など)は入力しないでください。お手続きが必要な場合は担当者がご案内します」と、短く伝えます。目的は禁止ではなく、「ここに書かなくても用件は進む」と知らせることです。案内が無いと、お客様は「書かないと答えてもらえないのでは」と考え、むしろ書き込みます。
• ②プライバシーポリシーの 1 項目。チャットボットで取得する情報(会話本文のみ、など)、保管期間、答えを作るために外部の AI へ送られること、その送り先で学習に使われないこと、ご本人からの開示等の求めへの対応窓口を、1 項目にまとめて追加します。項目 01〜05 でベンダーから名詞と数字で引き出した答えが、そのまま下書きになります。ベンダーが文案の雛形を持っていることも多いので、聞いてみてください。
• ③保管期間と、見られる人。製品の既定が「90 日で自動削除」なら、自社としてその期間でよいかを決めます(業種によっては、もっと短くしたい、あるいは契約で指定したい場合があります)。そして自社側で会話ログを読める人を、役割で決めて名前を残します。改善のために会話を読む担当と、読まない担当を分けておくと、「誰が見たか分からない」状態を避けられます。何を記録に残すかの考え方は、「問い合わせ対応の記録の残し方」で書いた項目設計がそのまま使えます。

案内の書き方と置き場所 ── 最初の一言に、ひとこと足す

案内文は、別のページに書いても読まれません。置き場所は、チャットボットの最初の一言です。「チャットボットの利用率を上げる方法」で、最初の一言には「答えられる範囲の宣言・質問の例・入力の仕方」を入れると書きました。そこに 1 文、「個人情報は入力せず、ご用件を文章でお書きください」を足すだけです。長い注意書きは読まれず、押す手を止めるだけなので、1 文に収めます。入力欄のすぐ上に小さく常時表示する形も効きます。どちらの場合も、「書くな」ではなく「書かなくて大丈夫」という伝え方にしてください。

本人確認が要る用件は、チャットで完結させない

「契約内容を確認したい」「登録している住所を変えたい」という用件は、本人であることを確かめないと答えられません。本人確認をチャットボットでやろうとすると、お客様に個人情報を入力させることになり、項目 01 の「集めない設計」と正面からぶつかります。ここは割り切って、本人確認が要る用件は、チャットボットでは「用件の受付と案内」までにして、確認と手続きは人(または認証済みのマイページ)へ渡す設計にします。チャットボットは「どの用件か」を切り分けて、「この手続きはお電話で本人確認のうえ承ります」「マイページからお手続きいただけます」と案内すれば十分に役に立っています。どこまでを AI に任せ、どこから人に渡すかの線の引き方は、「チャットボットの有人切り替え設計」で詳しく書きました。

法令は、どう当てるか ── 「確認項目」として持ち、解釈は専門家と

「チャットボット 個人情報保護法」という検索が多いのは、個人情報を預かる以上、法令への当てはめが気になるからだと思います。この記事では、法令の解釈を断定しません。一般に、お客様が入力した氏名や連絡先は、取得した以上は個人情報として扱う必要があるとされ、取得の目的・保管・第三者への提供(外部の AI へ送ることが提供にあたるか、委託にあたるか)・ご本人からの開示等の求めへの対応を、自社の規程とプライバシーポリシーで定めておくことが求められます。ここで大事なのは、ベンダーから引き出した名詞と数字(何を取得し、どこへ送り、何日残すか)が揃っていれば、専門家への相談が 1 回で済むということです。「よく分からないがたぶん大丈夫」で相談に行くと、宿題を持ち帰ることになります。業種ごとのガイドラインや監督官庁の規程がある場合は、それも確認項目に加えてください。

答え方のリスク ── 資料に無いことを言わせない

通り道の 3 つ目、「答える場面」のセキュリティです。ここは「情報が漏れる」とは少し形が違いますが、お客様との信頼に直結します。チャットボットが社内向けの情報を答えてしまう、あるいは資料に無いことをもっともらしく答えてしまう、という事故です。対策は、答えの出どころを 3 つの柵で管理することです。

1 つ目は、答えの元になる資料を「お客様に見せてよいもの」に限ること。チャットボットに読み込ませる資料は、社内の FAQ やマニュアルをそのまま渡すと、原価や社内の判断基準、未発表の予定が混ざっていることがあります。渡す前に、「この 1 行をお客様に読まれても困らないか」の目で 1 度通してください。社内向けの資料とお客様向けの資料を分けて持つのが、最も確実です。2 つ目は、資料に無いことは答えず、人へ渡すこと。生成 AI は、資料に無い質問にも、それらしい文章を作れてしまいます。それを「賢い」と見るか「危ない」と見るかで、設計が分かれます。お客様向けの窓口では後者で、資料に答えが無ければ「担当者におつなぎします」で終わる設計を選びます。誤りを事故にしないための業務側の設計は、「生成AIのハルシネーション対策」で整理しています。3 つ目は、資料を更新する側の権限です。資料を書き換えられる人が多いほど、社内向けの一文が紛れ込む入口も多くなります。更新できる人を絞り、更新の記録が残る形にします。「やってはいけない」を指示文に書くのではなく、「できない」を権限で作るという考え方は、「AIエージェントのセキュリティ」で書いたものと同じで、チャットボットの資料にもそのまま当てはまります。

公開後は、月に 1 度、2 つのことを見てください。1 つは、お客様が実際に何を入力しているか。案内文を置いても個人情報が書かれ続けているなら、案内の文言か置き場所を直します。本人確認が要る用件が多いなら、人へ渡す線を手前に引き直します。もう 1 つは、権限の棚卸しです。担当者の異動や退職で、管理画面に入れる人が増えていないか、読める人が変わっていないかを確かめます。セキュリティは公開の日に完成するものではなく、通り道を 1 度描いておけば、見直しは短い時間で済みます。問い合わせ削減の全体の中でチャットボットがどこに位置するかは、「問い合わせ削減の方法【完全ガイド】」にまとめています。

コルットの場合 ── 集めない・残さない・学ばせない・見せない、を最初から

コルットは、ホームページに専用のタグを 1 行貼るだけで設置できる AI チャットボットです。この記事で書いた 5 項目に、製品の設計としてどう答えているかを、公開している事実の範囲で書きます。項目 01「集めない設計か」── チャットの会話で IP アドレス・Cookie・メールアドレスを取得しない、最小収集の設計です。項目 02「何日残り、誰が見られるか」── 保管するのは会話本文のみで、既定では 90 日で自動削除されます(保管期間は契約で指定できます)。自社の会話ログを管理画面で読めるのは管理者の役割に限られます。項目 03「外部の AI に送るか」── 答えの生成には Google の Gemini API を使い、入力データは AI の学習に利用されません。項目 04「通信と管理画面」── 通信は常時 TLS で暗号化され、管理画面はワンタイム PIN と役割ごとの権限で守られています。基盤は国際的なセキュリティ認証を取得したクラウド(Cloudflare)です。項目 05「何を元に答えるか」── 社内のナレッジ(マニュアル・規定・対応ログ)を元に答え、答えられない質問は有人対応へエスカレーションします。

2 ヶ月の無料モニターでは、電話で多い用件の聴き取りから、どのページに入口を立てるか、最初の一言(この記事の案内文を含みます)、答えられないときの行き先までを一緒に設計したうえで公開します。社内で「セキュリティは?」と聞かれたときに名詞と数字で答えられる状態を、費用をかけずに作れます。

よくある質問