生成AIに顧客情報を入力してよいか｜可否を判断する3つの軸

「機密情報は入力禁止」では、目の前の商談メモを判断できない

社内ルールを開くと、生成AIについて書かれているのは「機密情報は入力禁止」の一行だけ、ということがあります。ところが、その一行からは、いま画面に開いている商談メモを貼ってよいのかという答えが出てきません。このメモは機密なのでしょうか。自分で書いたただの覚え書きにも見えますし、相手が話した未公表の話が混ざっているようにも見えます。上司や情報システム部門に聞いても、即答が返ってこないか、「やめておいたほうがいい」で終わってしまいます。

検索して出てくる記事も、多くは「入力してはいけない情報」の列挙です。個人情報、機密情報、社外秘、認証情報、著作物といった分類が並びます。分類そのものは間違っていません。それでも手が止まるのは、目の前の商談メモが、その分類のどれにもきれいに収まらないからです。メモの中には、担当者の名前も、相手が漏らした価格の話も、自分の所感も、同じ一枚に混ざっています。

手が止まる原因は、読者の分類が甘いからではありません。分類する対象を取り違えているからです。顧客情報の可否は、情報の見た目や種類ではなく、その情報が誰との、どんな約束の中に置かれているかで決まります。そこで本記事は、順番を組み替えます。まず、誰の持ち物かで分けます。次に、何に使うのかを見ます。そのうえで、どの経路から入れるのかを見ます。最後に、そもそも判断が要らない形に落とせないかを考えます。この記事では「入れてよい情報リスト」は作りません。リストは必ず取りこぼしが出て、取りこぼしたときに現場が止まるからです。渡すのは、目の前の一件に当てて答えが出る判断の順番のほうです。

前提：入力した顧客情報はどこまで残り、誰が触れるのか

判断の軸を組み立てる前に、共通の地図を一枚だけ持っておきます。貼ったテキストがどこへ行き、どの段階で誰の手に触れ、どこまで消せるのかという地図です。ここを曖昧にしたまま可否を語ると、「学習させない設定にしたから大丈夫」といった、途中の一段だけを見た結論になりがちです。実際には、学習に使われないことと、保存されないことと、社内の誰にも見えないことは、それぞれ別の話です。下の表は、その別々の話を段階ごとに並べたものです。詳しい仕組みの解説はここでは広げず、以降の判断で参照するための最低限にとどめます。

段階	触れうる相手	残り方	プランによる違い
入力欄に貼った時点	自分の端末とブラウザ	下書きやキャッシュとして端末側にも残ります	個人利用でも法人契約でも変わりません
サービス提供元への送信	サービス提供元の運用担当	一定期間サーバーに保存されます	法人プランや閉域構成では、保存先と保存期間が契約で定まります
基盤モデルの学習利用	モデル提供元	学習に取り込まれた後に個別のデータだけを取り消す手立てはありません	個人向けの無料版は既定で学習に使われることがあり、法人プランやAPIでは既定で使わない扱いが一般的です
会話履歴の保存	同じアカウントを使う人、管理者	画面から削除しても、実際のデータが即時に消えるとは限りません	管理者が履歴の保存可否や保存期間を一括で決められるプランがあります
出力の二次利用	出力を貼り付けた先の閲覧者	貼り付け先の文書に残り続けます	プランでは制御できません

読み取るべき点は一つです。設定で止められるのは表の一段だけであり、送信と保存と社内共有は、設定とは別の理由で残ります。録音データや会議単位の扱いなど、AI議事録まわりの論点は別記事に譲ります。

顧客情報は自社の持ち物ではない——可否を誰が決められるかで3つに分ける

「顧客情報」を一語で扱っている限り、可否は決まりません。この一語の中には、性質のまったく違うものが同居しているからです。ここでは、入力してよいかを誰が決められるのかという基準で、顧客情報を三つに分けます。一つめは、顧客の個人データです。担当者の氏名、所属、連絡先、名刺情報、先方の人事の動きといった、特定の個人にたどり着く情報がこれにあたります。二つめは、顧客から預かった秘密です。未公表の仕様、価格、社内体制、来期の計画など、相手から渡された、あるいは相手の口から出た情報です。三つめは、自社が作った商談記録です。商談メモ、提案書、議事録、所感などがこれにあたります。

この分け方が効くのは、三つで決定権の所在が違うからです。自社の販促資料や社内の営業ノウハウであれば、入れるかどうかは自社だけで決められます。ところが顧客の個人データは、取得したときに本人へ伝えた利用目的の枠内でしか動かせません。顧客から預かった秘密は、守秘義務の契約条項を見なければ結論が出ません。そして三つめの商談記録は、書いたのは自社であっても、中身は一つめと二つめの塊です。多くの記事が持つ情報類型の表からこの三つめがこぼれ落ちるのは、見た目が完全に自社の文書だからです。

商談メモ・提案書は「自社が作った文書」でも、中身は預かり物が混ざる

商談メモを開いてみると、そこには自分が書いた文字しか並んでいません。だから「自社の文書だから自由に使ってよい」と扱いたくなります。しかし中身を一行ずつ見ていくと、性質が違うものが混ざっていることがわかります。先方の担当者名と役職があります。相手が雑談の中で漏らした社内の不満があります。「これはオフレコで」と前置きされた発注時期の話があります。他社から出ている見積の額があります。これらは、自分の手で書き取ったものではあっても、渡してよい相手を決める権利までが自分に移ったわけではありません。

書いた人と、渡してよい相手を決められる人は、別だということです。ここを取り違えた運用がいちばん事故を生みます。禁止事項として意識されている顧客リストや個人情報のファイルは、貼る前に手が止まります。ところが商談メモや議事録は、自分の作業物という感覚が強いぶん、疑いなく貼られます。実際には、預かり物がもっとも高い密度で集まっているのがこの中間物です。提案書のたたき台も同じで、相手のヒアリング内容を写して作った部分は、自社が作文した部分とは扱いが変わります。判断すべきは文書の作者ではなく、その一行の出どころのほうです。

3類型 × 誰の承諾が要るか の判定表

三つの類型を、決定権の所在で並べ直すと次のようになります。この表の役割は、可否そのものを出すことではなく、自分がいま「自社だけで決められる領域」にいるのか、それとも「誰かに確認しないと決められない領域」にいるのかを、貼る前に見分けることです。領域を取り違えたまま急いで判断してしまうことが、後から問題になる典型だからです。

類型	中身の例	入力の可否を誰が決められるか	貼る前の見分け方
顧客の個人データ	担当者の氏名・所属・連絡先、名刺情報、先方の人事の動き	自社だけでは決められません。取得時に本人へ伝えた利用目的の範囲で決まります	その一行から特定の個人にたどり着けるかで見ます
顧客から預かった秘密	未公表の仕様、価格、社内体制、計画、他社との取引状況	契約条項を見ないと決まりません。守秘義務の対象範囲と目的外使用の禁止条項が効きます	相手から渡された情報か、相手の口から出た情報かで見ます
自社が作った商談記録	商談メモ、提案書、議事録、所感	混ざっている中身ごとに分かれます。文書単位では決まりません	誰が書いたかではなく、その一行が誰由来かで見ます

三つめの行だけ、結論が「文書単位では決まらない」になっている点が要です。商談記録は、一枚まるごとの可否を出そうとすると必ず詰まります。詰まったときは、一枚を一行ずつに分解して、一つめと二つめの行がどこにあるかを探すほうが早く進みます。

可否は情報の種類だけでは決まらない——見落とされる「用途」の軸

そもそも、この問いは生成AIが持ち込んだ新しい問題なのでしょうか。預かった情報を別の場所へ動かす行為自体は、ずっと前から営業の日常にありました。聞いた話を提案書へ書き写し、社内の共有フォルダに置き、後任に引き継ぎ、別の部署の会議で例として話す。そのどれもが、相手の想定した範囲の内側にあるとは限らないまま、確認されずに通ってきたはずです。生成AIが変えたのは、その移動が社外のサービスを一度経由するようになり、これまで誰も見ていなかった動きに輪郭がついたことのほうだと言えそうです。だとすると、AI専用の禁止事項を積み上げても土台は埋まりません。問われているのは、預かった情報をどこまで動かしてよいのかという、以前からあったのに言葉になっていなかった線引きのほうです。

情報を種類で分けて、種類ごとに可否を振っていく。これはとてもわかりやすい方法ですが、この方法だけで表を完成させようとすると、いつまでも埋まらない欄が残ります。理由は単純で、まったく同じ一行のテキストが、何に使うかによって答えを反転させるからです。顧客の連絡先リストは、連絡を取るための文面づくりに使うなら想定の内側にありますが、同じリストを読み込ませて確度や与信を推定させるなら、話がまったく変わります。情報の中身は一文字も変わっていないのに、可否だけが変わるのです。

つまり、可否は情報が持っている属性ではなく、関係が持っている属性です。「顧客情報」というラベル自体が危険なのではありません。危険なのは、その情報を自社が預かっているという関係のほうです。顧客は「この用途でなら渡す」という条件を付けて渡しています。その条件の内側にいる限り、同じ一行は問題なく使えます。条件の外に出た瞬間に、同じ一行が問題になります。分類表がいつまでも埋まらないのは、読者の分類が甘いからではなく、分類する対象を取り違えているからです。分けるべきは情報の種類ではなく、誰との、どんな約束の中にいるかのほうです。

この章では、その約束の範囲を二つの角度から具体化します。一つは、取得したときに本人へ伝えた利用目的の範囲という角度です。もう一つは、AIベンダーが約束の内側の相手なのか、外側の相手なのかという角度です。

名刺交換で得た顧客リストを、AIでスコアリングしてよいか

名刺交換のときに、相手へ何と伝えたかを思い出してみてください。多くの場合は「ご連絡のために使わせていただきます」といった趣旨です。個人情報保護法は、個人情報を取得するときに利用目的を特定して本人に知らせることと、その目的の範囲を超えて取り扱うときには原則として本人の同意が要ることを定めています。ここで効いてくるのは、情報の機微さではなく、あのとき伝えた目的の広さのほうです。

そのリストを使って案内メールの文面を下書きさせるのであれば、連絡のためという目的の内側にとどまります。一方、同じリストを読み込ませて受注確度のスコアを付けたり、与信や取引継続の可能性を推定させたりすると、連絡のためという説明からは外れていきます。ここが厄介なのは、いくら安全側の設定を積み上げても、この軸が消えないところです。学習に使わない設定にしても、閉域の環境を用意しても、契約で保存期間を縛っても、目的の範囲そのものは一ミリも広がりません。セキュリティの問題ではなく、約束の範囲の問題だからです。判断に迷ったら、設定画面ではなく、取得時の説明文や申込フォームの利用目的欄を見にいくのが正しい順番です。

AIベンダーは「委託先」か「第三者」か

もう一つ、可否を分ける分岐があります。使っているAIサービスの提供元が、自社の手足として処理を任せている委託先なのか、それとも自社の外にいる第三者なのか、という区別です。この区別が効くのは、個人データを外部に渡すときの条件が変わるからです。委託であれば、委託先を適切に監督することを前提に、本人の同意なしに取り扱いを任せられます。第三者への提供にあたるのであれば、原則として本人の同意が要ります。同じ「入力する」という操作が、この区別によって、日常業務と例外処理に分かれます。

どちらにあたるかは、そのサービスの利用規約とデータの取り扱い方針の書きぶりで変わります。入力したデータを提供元が自社サービスの改善や学習に使うと書かれているか、再委託の範囲がどこまで開かれているか、データがどこに置かれるか。このあたりの条件が、自社の指示の範囲内で処理しているという説明が成り立つかどうかを左右します。ただし、これは案件ごとに考える論点ではありません。ツール単位、プラン単位で一度だけ確認して結論を出し、以後はその結論を使い回すべきものです。毎回の判断に持ち込むと、現場は必ず止まります。判断の回数を減らす設計については、後の章で扱います。

可否判断シート：情報 × 用途 × 経路 の3軸で決める

ここまでで軸が二つ出そろいました。誰の持ち物かという軸と、何に使うかという軸です。実務ではここに三つめの軸が加わります。どの経路から入れるのか、という軸です。同じ社名を同じ目的で入力しても、会社が契約している業務用アカウントから入れるのか、個人のブラウザで開いた無料版に貼るのかで、保存先も、学習に使われるかどうかも、管理者が後から追跡できるかどうかも変わります。前提の章で見た経路の地図が、ここで効いてきます。

この三つを順番に当てるのが、可否判断シートです。使い方は、まず持ち物の軸で類型を特定し、次に用途の軸で取得時の目的の内側かを見て、最後に経路の軸で使えるツールとプランかを確かめます。三つのうち一つでも詰まれば、その時点で「そのままは不可」です。大切なのは、不可という結論を出すときに、三軸のどこで詰まったのかを必ず言えるようにしておくことです。理由が言えない不可は、現場では守られません。

営業実務でよくあるケースの判定（商談メモ要約／提案書ドラフト／リスト整理ほか）

営業の一日に実際に出てくる場面を、三軸に当てて並べます。結論の欄は、そのまま可・加工して可・不可の三つに割っています。

場面	詰まる軸	結論
商談メモの要約	持ち物（自社の記録に預かり物が混ざります）	固有名詞と金額を落としてから、加工して可
提案書のたたき台生成	持ち物	自社の型と一般論だけならそのまま可。相手の未公表情報を使うなら加工して可
お礼メールの文面	用途（連絡のためという目的の内側です）	そのまま可。ただし本文に案件の具体的な中身を貼らないことが条件です
失注理由の整理	持ち物と用途	顧客名を伏せて傾向として扱うなら、加工して可
顧客リストの並べ替え・スコアリング	用途（取得時の目的を超える可能性があります）	取得時に伝えた利用目的を確認するまで不可
競合情報の下調べ	経路	公開情報だけならそのまま可。顧客から聞いた話を含めるなら不可
見積の妥当性チェック	持ち物（相手の価格情報にあたります）	金額と社名を落とし、構造だけを相談するなら加工して可

表を眺めると、不可になっているのは情報が生々しいからではなく、用途か経路のどちらかが約束の外へ出ているからだとわかります。逆に言えば、詰まった軸を一つ動かせば結論が変わる場面が多いということです。

「要確認」を放置しない——グレーの行き先を先に決めておく

シートを回すと、可でも不可でもない案件が必ず出ます。むしろ、判断に迷って検索した案件のほとんどが、ここに落ちます。多くのルールは、この三区分を作ったところで力尽きています。要確認に落ちた後、誰が、いつまでに、何を見て決めるのかが書かれていないのです。決めていないと、現場では二つのことしか起きません。待てない案件は誰にも言わずに使われ、待てる案件は使われないまま終わります。前者は事故の温床になり、後者は導入した意味を失わせます。

ですから、三区分を作るなら、要確認の行き先まで先に決めておく必要があります。決めるのは三つです。相談先を職名で一つに決めること。回答の期限を決めること。相談された側が何を見て答えるのかを決めることです。三つめが抜けると、相談を受けた側も同じところで迷い、結局「やめておこう」に流れます。見るべきものは、この記事で使ってきた三軸そのもの、つまり類型、取得時の利用目的、契約条項、そして使用するツールとプランです。

あわせて、要確認そのものを減らす手も打てます。頻出する場面は事前に判定して、可の側へ移しておくことです。商談メモの要約や、お礼メールの文面づくりのように、毎日発生する使い方は、条件付きで可と定め、その条件を具体的な操作の形で書いておきます。同じ問いを何度も上げなくて済む状態にすることが、要確認を機能させる前提になります。

毎回判断しないで済む形にする——判断の回数を減らす3手

判断の道具を渡したうえで、その道具を使う回数を減らす話をします。矛盾しているようですが、そうではありません。営業は一日に何度も生成AIに文章を貼ります。そのたびに複数の設問に答えていく運用は、数日で形骸化します。形骸化した運用は、守られていないのに守られていることになっているぶん、最初から無い運用よりも危険です。

そこで方向を切り替えます。貼るときに判断するのではなく、判断が要らない状態にしてから貼るのです。前の章の判定表で、不可や加工して可になった理由を思い出してください。多くは、顧客が特定できる要素が文中に残っていたことでした。であれば、その要素が最初から入っていなければ、判断する必要そのものが消えます。この章では、その手を三つに整理します。

入れない／落とす／置き換える の使い分け

一つめは「入れない」です。AIに渡す段階ではなく、メモを取る段階を変えます。商談メモを最初から匿名の呼び名で書き始め、社名や担当者名は別のファイルに置いておきます。書くときに一手間かかりますが、その後の何十回分かの判断がまとめて消えます。二つめは「落とす」です。貼る直前に、社名、氏名、金額、日付、固有の製品名を削ります。ここで大事なのは、手順を一つに固定することです。案件ごとに何を消すか考え始めた時点で、それは判断が復活したのと同じです。三つめは「置き換える」です。実名を仮の呼び名に置き換え、対応表は手元にだけ置きます。出力を実務で使うときに元へ戻せるので、加工しても成果物の完成度が落ちにくいのが利点です。

三つの使い分けは、その情報が出力の質に効くかどうかで決めます。効かないなら入れないか落とします。効くなら置き換えます。たとえば業種や事業規模の感覚は提案文の質に効くので、置き換えの対象になります。担当者の氏名は文面の質にほとんど効かないので、落とす対象です。

「匿名化したから大丈夫」が成り立たない場合

ただし、加工すれば必ず安全になるわけではありません。もっともよくあるのが、社名だけを伏せて安心してしまう形です。社名を仮名にしても、業種と地域と従業員規模と案件の金額帯が残っていれば、その組み合わせから相手が絞り込めてしまいます。特に、業界が狭い商材を扱っている場合、条件を三つ並べただけで一社に行き着きます。落とすべきは名前ではなく、組み合わせたときに一社を指す情報のほうです。

もう一つ、加工しても入力そのものが問題になる場合があります。健康状態や信条のように、取り扱いに本人の同意が求められる情報は、名前を伏せたとしても、業務上そこへ触れる必要があるのかという問いが先に立ちます。加工の前に、そもそも扱う場面かどうかを見るべきです。そして三つめに、加工に時間がかかりすぎるなら、その作業自体を疑ってください。丁寧に伏せ字を入れていくうちに、自分で書いたほうが速かったという結果になることがあります。判断を減らすための加工が新しい手間になっているなら、その用途はAIに渡さないという選択が正解です。

社内ルールに書くのは、禁止リストではなく判断の順番

ここまでの内容を社内ルールに落とすとき、禁止する情報の一覧を作りにいくと、必ず取りこぼしが出ます。新しいサービスが出るたび、新しい業務が増えるたびに古くなり、書かれていないものは可なのか不可なのかで再び現場が止まります。ルールに書くべきは、禁止の一覧ではなく判断の順番です。順番であれば、書かれていない場面が来ても当てられます。具体的には、次の四つを書けば足ります。

• 顧客情報の三つの類型と、それぞれの扱い。とくに顧客から預かった秘密は、確認が取れるまで入力しないと明記します。
• 使ってよいツールとプランの限定。どの経路なら業務で使ってよいのかを、名指しで書きます。
• 要確認になったときの相談先と、回答の期限。相談を受けた側が何を見て判断するのかまで書きます。
• 誤って入力してしまったときの連絡先と、連絡までの時間の目安。

あわせて、人の判断に頼らずツール側の設定で落とせる部分は、先に落としておきます。学習利用をオフにすること、履歴の保存期間を決めること、管理者から全員へ一括で適用すること、業務利用を会社のアカウントに集約することです。ガイドラインの条文構成や策定手順、雛形については別記事に譲ります。

入れてしまったとき、社内の後始末だけでは終わらない

すでに貼ってしまった、という状況から読み始めた方もいると思います。多くの記事は、この場面の対処として、会話履歴を消し、学習の設定をオフにし、上司や情報システム部門に報告し、再発防止を決める、という流れを示します。手順としては正しいのですが、すべて社内で完結しています。顧客情報の場合は、そこで終わりません。預かり物を約束の外へ出してしまったのですから、まず相手に言うのが筋かどうかを判定する必要があります。

初動は三つの順番で進めます。一つめは、何を送ったのかを特定することです。推測のまま報告すると、後から範囲が広がって話が覆ります。会話履歴と貼り付け元のファイルを突き合わせ、どの類型の情報が、どの経路で、いつ出たのかを押さえます。二つめは、削除と学習停止を依頼することです。前提の章で見たとおり、画面から消えることと、データが消えることは別です。実際の削除までにどれだけかかるのかは、事故が起きてから調べるのでは遅いので、平時に確認しておきます。

三つめが、社外へ言う必要があるかの判定です。ここでは三つを見ます。顧客本人への通知が要るかどうか。個人情報保護委員会への報告が必要な事態にあたるかどうか。そして、顧客企業と結んでいる契約に、事故が起きたときの通知義務が書かれていないかどうかです。守秘義務契約には通知の条項が入っていることが多く、社内で処理して終わりにすると、その条項のほうに違反します。この判定は営業担当が一人で下せるものではありませんから、二つめの段階で法務や情報システム部門に上げてしまうのが実務です。黙って消せば済むと考えて処理すると、後日の顧客監査や本人からの問い合わせで表に出たときに、漏らしたことより隠したことのほうが大きな問題になります。なお、録音や議事録ツールに起因する事故の扱いは別記事に譲ります。

まとめ：明日から使う判断の順番と、今日確認する3つ

判断の順番をもう一度置いておきます。第一に、誰の持ち物かを見ます。顧客の個人データ、顧客から預かった秘密、自社が作った商談記録のどれにあたるのか、そして自社だけで決められるのかを確かめます。第二に、何に使うのかを見ます。取得したときに相手へ伝えた目的の内側にいるかどうかです。第三に、どの経路から入れるのかを見ます。第四に、そもそも判断が要らない形にできないかを考えます。

今日のうちに確認できることは三つあります。自分が使っているツールのプランと学習利用の設定がどうなっているか。直近の数か月で、顧客から預かった秘密を貼っていないか。要確認になったときに誰へ相談するのかが決まっているか。

この記事の目的は、生成AIの利用を禁じることではありません。禁止だけを増やすと、隠れて使う人が出て、かえって見えないところで事故が起きます。目指すのは、堂々と使える範囲を自分の手で確定させることです。

あわせて読みたい

• 営業のための「クライアントに対するヒアリング」をスムーズにする4つのStep｜ヒアリングの質問例と深掘りの技術ーー相手が黙る瞬間を味方にする実践会話術