AIで営業メールを作る前の個人情報の線引き｜集めた経路で変わる

「氏名を消してから貼れば大丈夫ですよね」「社名と部署だけなら個人情報ではないので、そのまま入れて問題ないはずです」——法務に確認する前に、現場でこう決まってしまっている場面をよく見ます。ここには2つの取り違えがあります。個人情報かどうかは氏名の有無だけで決まるわけではなく、入れてよいかどうかを実際に分けているのは、その連絡先をどの経路で手に入れたかと、取得したときに何と書いたかです。この記事では、AIで営業メールを作るという実務に絞って、生成AIに渡してよい情報の線引きと、それを運用として定着させる手順を整理します。

誤解を先に外す：氏名を消せば自由になるわけではない

最初に、現場でよく使われている3つの割り切りを確認します。氏名を消したから大丈夫、社名だけなら個人情報ではない、社内で使うだけだから問題ない。この3つは、どれも部分的には正しく、全体としては成り立ちません。判断の基準を1つずらしているためです。

氏名を消しても、部署名と役職と会社名が揃えば、その会社の中では誰のことか分かる場合があります。他の情報と照合して特定の個人を識別できるかどうかで見るので、氏名の欄を空にしたことは決定的な条件になりません。営業の連絡先は、まさにこの「揃えば分かる」型の情報です。

社内で使うだけ、という割り切りにも穴があります。生成AIは多くの場合、社外の事業者が運営する仕組みです。手元の画面に貼り付ける動作は社内の操作に見えますが、入力した内容は社外の事業者の設備に届いています。社内で使う道具かどうかではなく、入力した内容がどこへ行くかで見ます。

この記事では、この3つの割り切りを順に置き換えていきます。置き換える先は法令の条文ではなく、営業メールを作る作業の中で「どの欄までなら貼ってよいか」という形の判断です。法令の細目そのものは主題にしません。

線引きの起点は、その連絡先をどこから手に入れたか

実務で使える起点は1つです。その連絡先が、どの経路で自社に入ってきたか。法人営業で扱う連絡先は、ほぼ4つの経路に収まります。名刺交換、資料請求やウェビナー申込などの申込フォーム、購入したリスト、そして公開情報から集めたものです。

集めた経路	利用目的の書かれ方	生成AIに渡す前に見るもの	営業メールを送るときの前提
名刺交換	多くの場合、明示されていない	取得時の状況から見て案内が範囲内か	自ら書面で通知した相手として扱える場合がある
申込フォーム	同意欄と説明文に明示されている	その説明文に案内が含まれているか	説明文の範囲で送れる
購入したリスト	自社では取得していない	提供元が本人に何と説明したか	提供元の説明と拒否の記録を確認する
公開情報	本人への説明が存在しない	個人が特定できる形か、法人の代表窓口か	拒否の表示がないかを個別に見る

表を見ると分かるとおり、同じ「会社名と氏名とメールアドレス」でも、経路が違えばやってよいことが変わります。手元のデータの中身は同じなので、データだけを見ていては線を引けません。台帳に経路の欄が無い会社は、まずその欄を足すところから始めます。

経路の欄は、後から復元するのが非常に難しい情報です。5年前に入った連絡先が名刺由来なのか購入リスト由来なのか、いま調べても分からないことが多い。経路が分からない連絡先は、いちばん狭い扱いに寄せるしかありません。つまり生成AIに渡さず、案内も送らない。これを避けるために、いま入ってくるものから経路を記録します。

経路1：名刺交換でもらった連絡先

展示会やウェビナー後の名刺交換でもらった連絡先です。法人営業でもっとも量が多く、もっとも扱いが曖昧になりがちな経路です。名刺には利用目的が書かれていないため、取得したときの状況から範囲を判断することになります。

メールを送ること自体については、総務省と消費者庁の「特定電子メールの送信等に関するガイドライン」の考え方が使えます。広告宣伝を含むメールは、あらかじめ同意した相手にのみ送れるのが原則です。ただし例外があり、既に取引関係にある相手と、名刺など書面で自らメールアドレスを通知した相手には、この原則がそのままは当てはまりません。名刺交換はこの例外に触れる場面です。

ただし送ってよいことと、生成AIに渡してよいことは別の問題です。名刺の情報を生成AIに貼り付けて文面を作らせる場合、見るのは送信の可否ではなく、その情報の利用目的として想定していた範囲に、外部の仕組みに入力することが含まれるかです。名刺交換の場面で「文面の作成のために外部の仕組みへ入力します」と説明していることは、まずありません。

だからこの経路では、実務的な妥協点を置きます。氏名と会社名を含む行をそのまま貼らず、業種と規模と役職の段階といった属性だけを渡して文面の型を作らせ、氏名や会社名は自社の仕組みの側で差し込む。手間としては1工程増えるだけで、判断の負荷は大きく下がります。

経路2：資料請求やウェビナー申込で登録された連絡先

2つ目は、自社のフォームから入ってきた連絡先です。この経路がいちばん扱いやすい理由は単純で、取得したときに利用目的を書いているからです。書いた文がそのまま、後からできることの範囲になります。

確認するのは1点だけです。そのフォームの説明文に、営業の案内を送ることが含まれているか。「お問い合わせへの回答のため」とだけ書いてあるフォームから入った連絡先に、後から製品の案内を送るのは範囲の外になります。ここは古いフォームほど危うい部分で、5年前に作った申込ページの文言をいま読み直すと、案内について何も書いていないことがよくあります。

生成AIに渡す部分についても、同じ考え方を当てます。「当社サービスのご案内のため」と書いていれば、案内文を作る作業はその目的の達成に必要な範囲に入ると読めます。個人情報保護委員会が2023年6月2日に出した注意喚起でも、個人情報を含む入力をする際は特定された利用目的を達成するために必要な範囲内であることを十分に確認することとされています。書いてあるかどうかを確認するのが先で、渡すかどうかはその後です。

実務としては、フォームの説明文を年に1回見直す作業を、営業の年間予定に組み込みます。見直すのは3行で足ります。何のために取得するか、どこに提供する可能性があるか、外部の仕組みを使って処理する場合があるか。この3行が揃っていれば、生成AIを使う判断はほぼ迷いません。

経路3：購入したリストと、公開情報から集めた連絡先

3つ目と4つ目をまとめて扱います。この2つに共通するのは、自社が本人に何も説明していないという点です。説明していない以上、自社が書いた利用目的というものが存在しません。判断の材料が1つ足りない状態から始まります。

購入したリストでは、提供元が本人に何と説明したかを確認します。提供元の説明の範囲を超えて自社が使うことはできません。あわせて、提供元が本人からの停止の申し出をどう受け付けているか、拒否の記録が引き継がれるかも確認します。ここが確認できないリストは、費用の安さに関係なく使わないという判断があり得ます。

公開情報から集めた連絡先は、法人の代表窓口かどうかで扱いが分かれます。総合受付のアドレスは個人を特定しませんが、担当者名の入ったアドレスは特定します。ページに送信を断る趣旨の表示があれば、その時点で対象から外します。この確認は集めるときに機械的に行い、後から人が個別に判断する形にはしません。

生成AIに渡すかどうかについては、この2経路はもっとも慎重に置きます。実務では、社名と業種と公開されている事業内容だけを渡し、担当者の氏名とアドレスは渡さない。文面の宛名は自社の仕組みで差し込みます。判断に迷う経路ほど、渡す欄を減らすことで迷いを消すのが現実的な運用です。

利用目的の範囲：入り口に書いた文が、AIに渡せる範囲を決める

4つの経路を見てきて分かるとおり、判断の中心にあるのは利用目的の書き方です。ここを1章使って整理します。個人情報を扱うときは、取得の時点で利用目的を特定し、その達成に必要な範囲を超えて扱わないのが原則です。生成AIへの入力も、この原則の中で判断します。

実務で問題になるのは、目的を「マーケティング活動のため」のように広く書いた場合です。広く書けば何でもできそうに見えますが、広すぎる書き方は、本人にとって何をされるか分からないため、特定したことにならないと評価される余地があります。逆に細かく書きすぎると、業務が少し変わるたびに範囲の外に出ます。

落としどころとして、3つの層で書く形をおすすめします。1層目は何のために使うか（例：当社サービスのご案内および関連情報の提供）、2層目は誰に渡る可能性があるか（例：当社が業務を委託する事業者）、3層目は処理の形（例：外部の情報処理サービスを利用して処理する場合があります）。3層目があると、生成AIの利用について毎回悩む必要がなくなります。

既に取得済みの連絡先について目的を広げたい場合は、変更の手続きが必要になります。目的の変更は、当初の目的と関連性を持つと合理的に認められる範囲でのみ行えるのが原則で、それを超える場合は本人の同意が要ります。取得済みの分をまとめて広げるという処理は、実務上はほぼ使えないと考えたほうが安全です。だから入り口の文が効いてきます。

生成AIに入れる行為は「提供」にあたるのか

ここが本題です。個人データを含む内容を生成AIに入力したとき、その事業者に対する「提供」にあたるのか。あたるなら、原則として本人の同意が必要になります。営業メールの作成でこの判断が必要になる場面は、毎日発生します。

個人情報保護委員会が2023年6月2日に公表した注意喚起は、この点を扱っています。整理は明快で、提供事業者が入力された個人データを学習用のデータに加工して機械学習に利用している場合、入力は提供事業者への提供と評価される可能性があるとされています。そのうえで、事業者が当該個人データを機械学習に利用しないこと等を十分に確認すること、と求めています。

裏返すと、判断の分かれ目は「入力した内容が、応答を返す以外の目的に使われるか」です。ここは料金の種別や契約の形態によって変わります。同じ名前の仕組みでも、個人向けの契約と法人向けの契約で扱いが違うことがよくあります。確認するのは製品名ではなく、いま自社が結んでいる契約の条項と設定の状態です。

関連して、外部の仕組みに保存させる行為が「提供」に当たらないと整理される場合もあります。事業者側がその個人データを取り扱わないこととなっている場合です。ただし生成AIでは、応答生成以外の目的で入力内容が扱われるなら、この整理はそのままでは使えません。契約書に「学習には利用しない」と書かれているかを、確認した日付とともに記録しておきます。契約は改定されるので、一度確認して終わりにはできません。

外部サービスに入る情報を、3つに仕分ける

判断を毎回やり直さないために、渡す情報をあらかじめ3つに仕分けます。この仕分けが、後の運用のすべての土台になります。仕分けの単位は、データの種類ではなく画面の入力欄です。営業の現場で扱えるのは、抽象的な区分ではなく具体的な欄だからです。

1つ目は渡してよい情報。業種、従業員規模の区分、公開されている事業内容、役職の段階、過去に案内した回数といった、個人が特定されない属性です。文面の型を作るにはこれで足りることがほとんどです。2つ目は差し込みで足す情報。氏名、会社名、部署名、メールアドレス。これらは生成AIには渡さず、出来上がった文面に自社の仕組みが後から差し込みます。

3つ目は渡さない情報です。商談で聞いた社内の事情、他社との比較の内容、価格の交渉経過、担当者個人に関する評価。これらは秘密保持の観点でも、個人情報の観点でも外に出しません。秘密保持契約に触れる内容は、個人情報の判断とは別に効いてきますので、2つの基準を同時にかけます。

この3分類を、画面の欄名で書いた1枚の表にして配ります。「顧客台帳の第4列は渡してよい、第7列は差し込み、第12列は渡さない」という粒度です。抽象的な原則を配ると解釈が分かれますが、列番号で書けば分かれません。表は台帳の項目が増えるたびに更新します。

同意が要る場面と、要らない場面

同意という言葉は現場で混同されがちなので、3つの場面に分けて整理します。混同したまま議論すると、必要のない場面で同意取得を求め、必要な場面で見落とすという逆転が起きます。

1つ目はメールを送ることについての同意。広告宣伝を含むメールを送るには原則として事前の同意が必要で、名刺など書面で自らアドレスを通知した相手や、既に取引関係にある相手は例外として扱われます。ただしこの例外に当たる場合でも、送信を断られた後は送れません。2つ目は取得した目的の範囲を超えて使うことについての同意。入り口に書いた文の外に出る使い方をするときに必要になります。

3つ目が本記事の中心で、第三者への提供についての同意です。生成AIへの入力が提供にあたると評価される場合、原則として本人の同意が必要になります。ここで実務が取る現実的な道筋は、同意を集めることではなく、そもそも提供にあたらない形に運用を寄せることです。入力内容を学習に使わない設定と契約を確認し、個人が特定される欄は渡さない。この2つで、同意の問題そのものを回避します。

なお、海外の生成AI提供事業者に個人データを渡す場合は、外国にある第三者への提供として別の手当てが必要になります。先の注意喚起の解説でも、この点と、安全管理措置として保存先の国の制度を把握しておくことが挙げられています。どの国の設備で処理されるかを、契約の確認と同時に記録しておきます。

送る側の規則：断られた後の扱いまで決めておく

生成AIの話から一度離れて、送る側の規則を確認します。文面をAIで作ろうが人が書こうが、この部分は変わりません。むしろAIで作れるようになって通数が増えると、ここが最初に破綻します。

原則はオプトインです。広告宣伝を含むメールは、あらかじめ同意した相手にのみ送れます。例外として、既に取引関係にある相手と、名刺など書面で自らアドレスを通知した相手が挙げられています。法人営業の実務は、この例外の上に成り立っている部分が大きい。だから例外の範囲を超えたときに、いちばん大きな問題が起きます。

そして例外に当たる場合でも、送信を断られた後は送れません。ここで実務的に難しいのは、断りが本文の中に自然な文章で書かれてくることです。「今後の配信は不要です」という一文が、返信メールの3行目に入っている。この一文を拾い損ねると、断った相手に翌月また案内が届きます。生成AIに反応を分類させる場合、この分類だけは取りこぼしを許さない設定にします。

実装としては、拒否の判定を機械の判断に任せず、拒否の候補として上げさせて人が確定する形にします。判定を厳しくすると誤って除外する件が増えますが、その損失は、断った相手に送り続ける損失よりはるかに小さい。除外の台帳は、営業の担当が変わっても引き継がれる場所に置きます。

運用に落とす5手順

ここまでの判断を、明日から動く手順に変えます。関係者は営業部門と情報システム部門と法務の3者で、初回は2時間、以降は月に30分です。全部を一度に整えず、この順番で埋めます。

5手順のうち、順番を入れ替えてよいのは2番目と3番目だけです。1番目の経路の欄が無いまま4番目の分類表を作っても、どの行にどの分類を当てるかが決まりません。経路の記録が、この運用全体の土台になります。逆に言えば、1番目さえ動いていれば、残りは後から追いつけます。

定着させる：月に1度、入力された中身を見る

手順を決めた後にほぼ必ず起きるのが、決めた表が参照されなくなることです。理由は単純で、守っているかどうかを誰も見ていないからです。定着のために置く仕掛けは1つで足ります。月に1度、実際に何が入力されたかを見る時間を作ります。

見るのは全件ではありません。その月に入力された内容から無作為に20件を抜き、3分類の表に照らして、渡さない欄が混ざっていないかを確認します。20件で1件でも混ざっていれば、表の書き方か周知の仕方に問題があります。混ざっていた欄の名前を記録し、翌月に同じ欄が出ないかを見ます。

この点検を成立させるには、入力の記録が残っている必要があります。記録が残らない使い方、たとえば個人の端末で個人の契約の仕組みを使うといった形は、点検の対象外になってしまいます。点検できない経路を1つでも残すと、実質的にすべての線引きが無効になります。使ってよい仕組みを限定するのは、便利さの制限ではなく点検を成立させるためです。

あわせて、点検の結果を数字で残します。抜いた件数、混ざっていた件数、混ざっていた欄の名前。3か月分並べると、周知が効いているかが見えます。混入が3か月続けてゼロなら、渡してよい欄を1つ増やすことを検討します。締めるだけの運用は続かないので、緩める条件も同時に決めておきます。

2026年に成立した改正で、何が変わるか

最後に、制度の側の動きに触れます。個人情報保護法の改正法が2026年7月10日に成立し、同月17日に公布されました。令和8年法律第56号です。施行は、公布の日から起算して2年を超えない範囲内で政令で定める日とされており、罰則に関する部分は公布から6か月を経過した日からとされています。

重要なのは、本記事で扱った判断が、施行までのあいだに自動的に変わるわけではないという点です。いま決めるべきことは、いまの規律に沿って決めます。そのうえで、改正で方向が変わる部分を頭に入れておきます。

営業の実務に効きそうな変更は3つあります。1つ目は課徴金制度の新設です。個人データの第三者提供の制限に違反した場合などが対象に含まれ、過去10年以内に課徴金命令を受けていると加算される仕組みも置かれています。2つ目は、統計の作成など大量の情報から傾向を分析する目的について、一定の公表と書面の合意を条件に同意が不要となる規定が新設されたことです。この規定はAIの開発等を含む形で整理されていますが、営業メールの文面作成がそのまま当てはまるわけではありません。

3つ目は、取得の状況から見て本人の意思に反しないことが明らかな場合について、同意を不要とする方向の見直しが入ったことです。ただし規則で定める場合に限られます。いずれも施行前で、細目は今後の政令と規則で決まります。現時点でやるべきことは、制度に合わせて運用を先回りで変えることではなく、経路の記録と分類の表を作っておくことです。土台があれば、施行時の対応は表の更新で済みます。

やってはいけない使い方

相談を受けた中で繰り返し出てくる形を並べます。どれも悪意があって起きているわけではなく、判断の基準を1つずらした結果です。着手前に読み合わせておくと、大半は避けられます。

• 氏名だけを消して、会社名と部署名と役職を残したまま貼り付ける。揃えば誰か分かる形で残っている
• 経路の分からない古い連絡先を、名刺由来と仮定して扱う。仮定した記録が残らないので、後から検証できない
• 個人の契約で使っている仕組みに、業務の顧客情報を貼り付ける。入力の記録が残らず、月次の点検が成立しない
• 「学習に使われない」という説明を一度確認しただけで運用を固定する。契約も設定も改定される
• 配信を断られた返信を、機械の分類だけで処理する。本文中に書かれた断りを取りこぼす
• 利用目的を「マーケティング活動のため」とだけ書く。広すぎて、何をされるか本人に分からない
• 3分類の表を抽象的な原則で書く。現場で解釈が分かれ、結局は参照されなくなる

• 購入したリストは、提供元が本人に何と説明したかを書面で受け取る。受け取れない場合は使わないという判断があり得る
• 海外の事業者に渡る場合は、処理される国を記録する。安全管理措置として、その国の制度を把握しておくことが求められる
• 秘密保持契約に触れる内容は、個人情報の判断とは別に効く。2つの基準を同時にかける
• 点検で見つかった混入は、担当者の責任にしない。表の書き方か周知の問題として扱わないと、次から報告が上がらなくなる

よくある質問

氏名を伏せ字にすれば、生成AIに貼っても問題ありませんか

伏せれば安全になるとは言い切れません。会社名と部署名と役職が残っていれば、その会社の規模によっては誰のことか分かります。他の情報と照合して特定の個人を識別できるかどうかで見るため、伏せ字は判断の1要素にすぎません。実務では、伏せるより渡す欄そのものを減らし、氏名や会社名は出来上がった文面に自社の仕組みで差し込む形が確実です。手間は1工程増えるだけです。

入力した内容が学習に使われない設定なら、何を入れても大丈夫ですか

大丈夫とまでは言えません。学習に使われないことは、提供にあたるかどうかの判断で重要な要素ですが、それだけで利用目的の範囲の問題が消えるわけではないためです。取得したときに書いた文の範囲を超える使い方であれば、学習の有無に関係なく範囲の外に出ます。設定の確認と、入り口の文の確認は、別々に行います。

名刺でもらったアドレスに、AIで作った案内を送ってよいですか

送ることと、生成AIに渡すことを分けて考えます。送る側については、名刺など書面で自らアドレスを通知した相手は例外として扱われる余地がありますが、断られた後は送れません。生成AIに渡す側については、名刺交換の場面で外部の仕組みへの入力を説明していることはまずないため、氏名と会社名を含む行はそのまま渡さず、属性だけを渡す形にします。

2026年の改正で、いまの運用を作り直す必要がありますか

いますぐの作り直しは不要です。改正法は2026年7月17日に公布されましたが、施行は公布の日から起算して2年を超えない範囲内で政令で定める日とされており、細目は今後の政令と規則で決まります。いま作るべきなのは、経路の記録と、台帳の列ごとの3分類の表です。この土台があれば、施行時の対応は表の更新と契約の再確認で済みます。制度に合わせて先回りで運用を変えるほうが、混乱が大きくなります。

まとめ

AIで営業メールを作るときの線引きは、手元のデータを眺めても引けません。引く場所は入り口のほうです。その連絡先を名刺交換で得たのか、申込フォームから得たのか、購入したのか、公開情報から集めたのか。経路が違えば、同じ形のデータでもできることが変わります。台帳に経路の欄が無ければ、そこから始めます。

生成AIに入れる行為が提供にあたるかは、提供事業者がその内容を応答生成以外の目的で扱うかで変わります。2023年6月2日の注意喚起は、機械学習に利用している場合は提供と評価される可能性があるとしたうえで、利用目的の範囲内であることを十分に確認すること、機械学習に利用しないこと等を十分に確認することを求めています。実務が取る道は、同意を集めることではなく、提供にあたらない形に運用を寄せることです。

運用として決めるものは3つに絞れます。台帳の列ごとに渡してよい欄と差し込む欄と渡さない欄を割り当てること、使う仕組みを点検できるものに限定すること、そして月に1度20件を抜いて実際の入力内容を見ること。混入が3か月ゼロなら渡してよい欄を1つ増やし、混ざったら表の書き方を直す。2026年7月に公布された改正法の施行はまだ先ですが、この土台があれば、そのときの対応は表の更新で足ります。線を引くのは慎重さのためではなく、迷わずに使える範囲を確定させるためです。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。