問い合わせフォームの個人情報の扱い方｜保管・削除・委託先管理の実務チェックリスト

問い合わせフォームの個人情報は、「集めない・置かない・見せない」の順で減らすのが実務の最短ルートです。暗号化やツール導入より先に、フォーム項目の棚卸しと保管ルールを決めるほうが効きます。

この記事は、中小企業の問い合わせ担当者・Web 担当・情シスの方に向けた実務チェックリストです。私たちはフォームに届く営業メールを選別する SaaS を運営し、自社を含む複数の実サイトで日々のフォーム送信を扱っています。その運用で実際に困ったことを軸に書きました。

なお本記事は一般的な情報であり、法的助言ではありません。個別の判断は専門家にご確認ください。根拠は個人情報保護委員会（PPC）のページにリンクしています。

全体像:5 つのチェックで、守る対象そのものを小さくする

そもそも保持していない情報は漏れません。次の順番なら、コストのわりに効果の大きいものから片付きます。

条文の全体像は個人情報保護法ガイドライン（通則編）にまとまっています。表に挙げた各条文が事業者にどこまでを求めているかは、問い合わせフォーム運用で押さえる個人情報保護法の 6 つの義務で整理しています。

チェック 1:集めない項目を決める。とくに要配慮個人情報は原則、同意なしに取得できません

まず「その項目、本当に必要ですか」を全項目に問い直すのが最も効きます。

「要配慮個人情報」とは、人種、信条、社会的身分、病歴、犯罪の経歴など、不当な差別や偏見が生じないよう特に配慮を要する情報です（法 2 条 3 項）。これらは原則として本人の同意なく取得できず、オプトアウトによる第三者提供も認められていません（PPC の解説）。

厄介なのは自由記述欄です。「お問い合わせ内容」という一つのテキストエリアに何が書かれるかは、設計側ではコントロールできません。Hajik が分析した実フォームデータ（美容商社（国内最大手・上場）の 3 種類のフォーム合計 1,894 件・約 20 か月分）では、本物の問い合わせは「この商品の在庫はありますか」のような一行で、型番や納期といったそのサイトでしか成立しない固有名詞が入ります。一方で営業の文面は定型的です。注意したいのは、短い＝いらない送信ではないという点です。本物ほど短いことがあるため、文字数で機械的に切り捨てる運用にすると、拾うべき問い合わせを落とします。なお、業種・規模・フォームの性格によって比率も内容も大きく変わります。あくまで一社・一時点のサンプルです。

そこで実務は 2 段構えになります。入口を絞る（氏名・会社名・メール・用件で足りるなら、電話番号も住所も生年月日も置かない）。そして入ってきたものを落とす（自由記述に混入した機微情報は、届いた後ではなく届く前に落とす）。

私たちのサービスでは、クレジットカード番号・マイナンバー・銀行口座・パスポート番号・健康情報の 5 種を、送信者のブラウザの中で除去してからサーバーに渡しています。サーバーに一度でも到達すれば、ログにもバックアップにも残るからです（セキュリティのページ）。

チェック 2:保管期間と削除の運用を決める。放置すると受信箱が最大の個人情報データベースになります

個人データは、利用する必要がなくなったときは遅滞なく消去するよう努める、と法 22 条が定めています。

努力義務ですが、実務的な意味は大きいです。問い合わせフォームの個人情報が本当に溜まっている場所は、多くの場合データベースではなくメールの受信箱で、その経路のどこにも消去のタイミングが設計されていない、という状態が非常によくあります。

最初にやるべきは、削除ルールを決めることではなく、溜まっている場所を全部書き出すことです。

WordPress で運用している場合、この「フォームツール側のデータベース」は誰でも送信できる入口の真下にあります。誰がその管理画面を開けるか、エクスポートできるかまで含めた守り方はWordPress のセキュリティ対策にまとめています。 | 手動コピーのスプレッドシート | 権限が広く、退職者が残りがち | 作成の可否そのものを再検討 | | チャットツールへの通知連携 | 検索可能な状態で長期保存される | 通知に本文を含めるかどうか |

保管期間そのものに法定の一律ルールはありません。用件の性質ごとに期間を決めて文書化し、自動アーカイブや自動削除とセットにします。仕組みがないと、ルールだけが形骸化します。

チェック 3:アクセスできる人を限定する。安全管理措置は 4 つの側面で考えます

安全管理措置（法 23 条）は「暗号化すること」ではなく、組織・人・物理・技術の 4 側面をそろえることを指します。通則編ガイドラインの別添では、基本方針の策定と取扱いに係る規律の整備に加えて、この 4 分類で講ずべき内容が示されています。あわせて、従業者の監督（法 24 条）も事業者の義務です。

中小企業で現実に穴になりやすいのは、技術ではなく「誰が見られるか」の管理です。私たちが複数サイトの運用で実際に直面したのも、ほとんどがこの領域でした。

• 問い合わせ通知が 全社共有のメールアドレス に届いていて、必要のない部署も本文を読める。
• 退職者のアカウントが停止されているだけで、共有メールボックスの権限が残っている。

対策は地味です。閲覧権限を持つ人のリストを作り、半年に一度見直す。投資ゼロで実効性が上がります。

技術面については、私たちは保管データをエンドツーエンド暗号化（E2EE）しています。フォームの内容はブラウザの中で暗号化してから保存するため、保管されたデータを運営側が復号することはできません。一方で、営業メールかどうかを判定する瞬間だけは、精度を確保するために内容をそのまま AI に渡しています（機微情報 5 種はブラウザ内で除去済み）。外部サービスを選ぶときは、この「保管時に復号できるか」と「処理時に何を見るか」を必ず切り分けて確認してください。

漏れたときの手順は、漏れる前に決めておく（法 26 条）

漏えい等が発生し、個人の権利利益を害するおそれがあるときは、委員会への報告と本人への通知が必要です。報告対象は、要配慮個人情報が含まれる場合、財産的被害が生じるおそれがある場合、不正の目的をもって行われたおそれがある場合、1,000 人を超える場合の 4 類型です（PPC の解説）。報告は 2 段階で、発覚後に速やかに（おおむね 3〜5 日以内）行う速報と、原則 30 日以内（不正の目的によるおそれがある場合は 60 日以内）の確報があります。

やることは 1 つだけです。「誰が委員会に報告するか」を今のうちに決めて、連絡先を書いておく。 発生してから調べ始めると、速報の期限は簡単に過ぎます。あわせて、漏えいの起点になりやすいのは、知らない差出人の添付やリンクを窓口担当が開いてしまう経路です。その見分け方はフィッシングメールの見分け方と窓口のチェック手順にまとめています。宛先間違いや TO/CC/BCC の取り違えといった自社側の誤送信も、内容によっては同じ報告対象になり得ます。先に決めておく運用ルールと起きた後の手順はメール誤送信の対策にまとめています。

チェック 4:外部サービスに預けるなら、委託先の管理が自社の義務になります

個人データの取扱いを外部に委託する場合、委託先に対する必要かつ適切な監督を行う義務は委託した側にあります（法 25 条）。

通則編ガイドラインでは、この監督の中身として、適切な委託先の選定、委託契約の締結、委託先における個人データの取扱状況の把握、の 3 点が示されています。PPC もウェブサイト構築・運営の委託に関する注意喚起資料を出しています。

問い合わせフォーム 1 つの裏側には、意外な数の委託先がぶら下がっています。フォーム SaaS、メール配信、CRM、チャットツール、アクセス解析、スパム・営業メール判定ツール。それぞれについて最低限、次を確認してください。

国外保管が絡む場合は、外国にある第三者への提供編ガイドラインを確認してください。

この表は、自分たちが委託先の側でもあるので自戒を込めて書いています。私たちは送信範囲・暗号化の境界・AI に渡る範囲を機能ページで明示しています。同じ粒度で答えられるかを確認してください。

チェック 5:プライバシーポリシーは「置いてある」だけでは足りません

プライバシーポリシーは、利用目的の公表（法 21 条）と保有個人データに関する公表事項（法 32 条）を満たすための実務上の手段です。問い合わせフォームを持つ会社が実際に書くべき項目は、プライバシーポリシーの書き方と必須 9 項目で根拠条文つきに整理しています。

法 32 条 1 項が本人の知り得る状態に置くよう求めているのは、おおむね次の事項です。

• 事業者の氏名または名称・住所、法人の場合は代表者の氏名
• すべての保有個人データの利用目的
• 開示等の請求等に応じる手続（手数料を定めた場合はその額）
• 保有個人データの安全管理のために講じた措置（公表により支障が生じるものを除く）
• 苦情の申出先
• 認定個人情報保護団体に加入している場合は、その名称と苦情解決の申出先

問い合わせフォーム固有の実務ポイントは 2 つです。1 つは、送信ボタンのすぐ上に利用目的とポリシーへのリンクを置くこと。フッターリンクだけでは送信者は読みません。もう 1 つは、外部サービスを追加したらポリシーも更新すること。ツールを増やすたびに委託先は増えているのに、ポリシーは初回公開のまま、という状態が非常に多いです。

なお、ポリシーに書けば何をしてもよいわけではなく、当初の利用目的の範囲を超える利用には別途の対応が要ります。

FAQ

reCAPTCHA を入れれば、問い合わせフォームの個人情報対策になりますか

なりません。役割が違います。reCAPTCHA はボットによる自動送信を止める仕組みで、これは実際によく機能します。私たちが分析した実フォームデータは reCAPTCHA v3 を通過した送信のみでしたが、明らかなボットスパムは事実上ゼロでした。ただし、集めた個人情報をどう保管し、誰が見て、いつ消すかという運用には関与しません。ボット対策そのものはreCAPTCHA との比較で整理しています。

営業メールとして届いた送信者の情報は、雑に扱ってもいいですか

いけません。営業目的の送信であっても、氏名・会社名・メールアドレスは個人情報です。保管期間や削除のルールは、本物の問い合わせと同じ枠組みに乗せてください。あわせて、「この会社は営業だから」という企業単位の決めつけもおすすめしません。同じ会社からの連絡でも、受け手の状況によっては本物の商談です。

問い合わせデータは何年保管すればよいですか

法律が一律の年数を定めているわけではありません。見積・商談の記録は取引に必要な期間、単純な質問対応は対応完了後の短期間、採用応募は次の募集までの期間、といった具合に用途で分けて文書化します。重要なのは年数の正解を当てることではなく、決めた期間で実際に消える仕組みを作ることです。

問い合わせ内容を AI に渡すのは問題がありますか

渡すこと自体が一律に問題になるわけではありませんが、確認すべき点があります（個別の可否は自社の利用目的や契約内容によります）。利用目的の範囲に収まっているか、AI サービスが委託先として適切に管理されているか、入力内容が再学習に使われないか、国外に保管されないか。とくに再学習の可否は契約や利用規約で明示させてください。

小さな会社でも、ここまでやる必要がありますか

安全管理措置は、事業の規模や取り扱う情報の性質、リスクの大きさに応じて「必要かつ適切な」ものを講じることとされています。従業員 5 名の会社と 5,000 名の会社で同じ体制が求められるわけではありません。ただし、チェック 1 とチェック 2 は規模に関係なくコストほぼゼロで効果が出ます。まずこの 2 つからで十分です。

まとめ

明日やることは 2 つです。フォーム項目を全部書き出して、削れる項目に線を引く。 そして 問い合わせが溜まっている場所を全部書き出す。 高価なツールより先に、この棚卸しから始めてください。

残るのは、届いた問い合わせをどう仕分けるかという課題です。仕分けの仕組み化は営業メールを自動で仕分ける運用の作り方、対策全体の考え方は問い合わせフォームの営業メール対策の実務ガイドにまとめています。

Hajik（ハジク）は、GrowGroup株式会社が運営する日本語特化の B2B SaaS です。script タグ 1 行で、問い合わせフォームに届く営業メールを選別します。効果は 99% 以上の遮断、残り約 1% は人が判断する前提の設計です。自社フォームの現状を知りたい方は無料診断からどうぞ。実際の判定を試すなら14 日間の無料トライアルをご利用ください。