問い合わせフォームの送信先・保存先・通知先を見直す

会社のホームページにある問い合わせフォームへ、顧客が氏名、メールアドレス、電話番号、相談内容を入力する。

送信ボタンを押すと、担当者へメールが届く。

この流れだけを見て、「問い合わせ内容は担当者のメールボックスに保存されている」と考えていないでしょうか。

実際には、問い合わせフォームの入力内容が複数の場所へ残ることがあります。

• WebサーバーやWordPressのデータベース
• フォームサービスの管理画面
• 担当者のメールボックス
• 共有メールボックス
• 顧客管理システム
• 営業支援サービス
• チャットツール
• 自動化サービス
• アクセスログやエラーログ
• サーバーやクラウドのバックアップ
• 制作会社や運用委託先の管理環境

反対に、メール送信だけでフォーム内容を処理し、Webサイト側には何も保存していない構成もあります。

つまり、問い合わせフォームを管理するには、少なくとも次の三つを分けて確認しなければなりません。

確認対象	意味
送信先	入力内容を実際に受け渡すメール、API、CRMなど
保存先	入力内容が一定期間以上残るデータベース、メール、バックアップなど
通知先	「問い合わせが来た」と知らせる担当者、チャット、スマートフォンなど

送信先、保存先、通知先は同じとは限りません。

本記事では、中小企業が問い合わせフォームからの情報漏えい、問い合わせの見落とし、不要な個人情報の長期保存を防ぐために、確認すべき項目を整理します。

問い合わせフォームは「一通のメール」ではない

一般的な問い合わせフォームは、次のような経路で処理されます。

入力者
↓
Webサイト・フォームプラグイン
↓
メール、データベース、CRM、チャット、外部サービス
↓
営業担当者、総務担当者、制作会社、委託先

例えば、担当者へメールを送ると同時に、WordPress内へ問い合わせ内容を保存し、営業用チャットへ通知し、CRMへ顧客情報を登録する構成があります。

この場合、一件の問い合わせから、少なくとも次の四つのコピーが生まれます。

1. WordPress内の保存データ
2. 担当者へ届いたメール
3. チャットへ投稿された通知
4. CRMに登録された顧客情報

さらに、各システムのバックアップにも残る場合があります。

メールの削除だけでは、問い合わせ内容を完全には削除できません。

2026年夏に公表されたフォーム保存用プラグインの脆弱性

2026年6月、WordPress用プラグイン「Database for Contact Form 7, WPforms, Elementor forms」のバージョン1.5.1以下について、任意のファイルを削除される可能性がある脆弱性、CVE-2026-9843が公表されました。

外部の未認証者が細工したフォームデータを送信し、そのデータを管理者が閲覧または編集することによって、サーバー上のファイルが削除される可能性があるものでした。NVDには、条件によっては設定ファイルの削除からコード実行につながる可能性も記載されています。

同じプラグインのバージョン1.5.1以下については、2026年7月にも、一定の構成でサーバー上のファイルを不正にコピーされる可能性があるCVE-2026-9145が公表されています。

プラグインの公式変更履歴では、バージョン1.5.2で任意ファイル削除の問題が修正されたとされています。

これは、Contact Form 7、WPForms、Elementor Formsそのものが一律に危険だという意味ではありません。

問題となったのは、送信内容をデータベースへ保存する特定の追加プラグインと、その特定バージョンです。

ここから分かるのは、「フォーム本体のプラグインだけを更新すればよい」とは限らないことです。

フォームに関連する次の構成要素をすべて把握する必要があります。

• フォーム本体
• 送信内容を保存する追加プラグイン
• ファイルアップロード用プラグイン
• CRM連携プラグイン
• 自動返信・リダイレクト用プラグイン
• CAPTCHA・迷惑送信対策
• SMTP・メール送信用プラグイン
• Webhookや自動化サービス

まず「フォーム台帳」を作る

問い合わせフォームを点検するとき、管理画面を一つずつ開くだけでは、確認漏れが起こります。

最初に、会社のWebサイトにあるフォームを一覧にします。

対象は「お問い合わせ」だけではありません。

• 資料請求
• 見積依頼
• 採用応募
• セミナー申込み
• メールマガジン登録
• アンケート
• 予約受付
• 修理・サポート依頼
• 個人情報に関する相談窓口
• セキュリティ事故の連絡窓口
• 会員登録
• ファイル提出
• 無料診断
• キャンペーン応募

問い合わせフォーム台帳の記載例

項目	記録する内容
フォーム名	問い合わせ、採用、資料請求など
公開ページ	フォームが設置されているページ
利用目的	何のために情報を取得するか
入力項目	氏名、メール、電話番号、相談内容など
必須・任意	各項目が必須か任意か
送信先	メール、CRM、Webhookなど
保存先	WordPress、フォームサービス、メールなど
通知先	担当者、共有メール、チャットなど
自動返信	有無、返信内容
ファイル添付	有無、許可形式、容量
利用プラグイン	フォーム本体、保存、SMTP、CAPTCHAなど
外部連携	CRM、チャット、自動化サービスなど
運用委託先	制作会社、保守会社、フォーム事業者
保存期間	いつまで保存するか
削除方法	どのシステムから、誰が削除するか
業務責任者	問い合わせ業務を管理する人
技術管理者	フォーム設定を管理する人
最終テスト日	最後に送信試験をした日
次回確認日	次の点検予定日

フォーム台帳は、公的制度上の正式な帳票ではありません。

しかし、Webサイト、クラウド、メール、委託先を横断して問い合わせ情報を管理するための実務資料になります。

既存のSaaS・クラウド台帳へ「問い合わせフォーム」を一サービスとして追加する方法もあります。

手順1　利用目的と入力項目を照合する

個人情報保護委員会の通則ガイドラインでは、個人情報の利用目的をできる限り具体的に特定することが求められています。

また、本人がホームページの入力画面へ個人情報を入力する場合は、原則として、送信前に利用目的を明示する必要があります。利用目的は、送信ボタンを押す前に本人の目に留まる位置へ表示するか、1回程度の操作で確認できるページへのリンクを配置することが望ましいとされています。

例えば、「お問い合わせへの回答のため」という目的であれば、次の項目で足りる場合があります。

• 氏名
• 返信先メールアドレス
• 問い合わせ内容

会社名や電話番号が必要な業務もありますが、すべてのフォームで必須にする必要はありません。

入力項目ごとに確認する質問

入力項目	確認する質問
氏名	匿名や会社名だけでは対応できないか
メールアドレス	回答に本当に必要か
電話番号	電話連絡を行う業務なのか
住所	資料発送等に必要なのか
生年月日	本人確認等の明確な理由があるか
会社名・部署	法人向け業務に必要か
自由記述	不要な個人情報を書き込まれないか
添付ファイル	ファイル提出が本当に必要か

取得項目を必要最小限にすることは、本稿の実務上の提案です。

入力項目を減らせば、漏えい時の影響だけでなく、利用者の入力負担や社内での削除対象も減らせます。

自由記述欄には注意書きを付ける

自由記述欄には、会社が求めていない情報まで入力される可能性があります。

例えば、利用者が次の情報を書き込むことがあります。

• 病歴や健康状態
• マイナンバー
• クレジットカード番号
• 銀行口座
• パスワード
• 顧客名簿
• 他社の営業秘密
• 人事上の相談
• 身分証明書の情報

自由記述欄の近くには、次のような注意書きを表示します。

パスワード、クレジットカード番号、マイナンバー、健康情報など、回答に不要な機密情報は入力しないでください。

注意書きを表示しても、利用者が必ず守るとは限りません。

そのため、不要な情報が入力された場合の削除、担当者への連絡、保存範囲の確認手順も決めておきます。

手順2　送信先メールアドレスを確認する

フォームからのメールが、現在誰へ届いているかを確認します。

• 現在の担当者
• 共有メールボックス
• 部署のメーリングリスト
• 旧担当者
• 退職者
• 制作会社
• 個人メール
• 旧ドメインのメールアドレス
• 無効になったメールアドレス

フォームの設定画面では一つの宛先しか表示されていなくても、その先で自動転送やグループ配信が行われている場合があります。

8月28日公開分の「その共有メール、誰に届いていますか？自動転送・フィルタ・代理権限を月1回点検する方法」と組み合わせ、メールボックス側の転送設定まで確認してください。

フォームメールの設定で確認する項目

• To、Cc、Bccが固定されているか
• 利用者が宛先を自由に指定できないか
• 件名へ自由記述をそのまま入れていないか
• Fromに入力者のメールアドレスを直接使っていないか
• Reply-Toへ適切な入力値を設定しているか
• 改行コード等を適切に処理しているか
• メール送信用プラグインが更新されているか
• 送信失敗時の記録が残るか

IPAは、問い合わせフォームなどで外部入力をメールヘッダーへ直接出力すると、任意の宛先へのメール送信や迷惑メールの中継へ悪用される可能性があるとして、To、Cc、Bcc、Subjectなどを原則として固定値にすることを推奨しています。

手順3　フォーム内容がWebサイト内に保存されるか確認する

WordPressのフォームは、使用するプラグインによって保存方法が異なります。

例えば、Contact Form 7は、標準状態では送信されたメッセージを保存しないと公式に説明しています。送信内容をWordPress内へ保存する場合は、Flamingoなどの保存用プラグインを追加します。

Flamingoの公式説明では、フォームから収集した送信内容を、Webサイトをホストするサーバー上のデータベースへ保存するとされています。

これは、保存することが悪いという意味ではありません。

メール障害が起きても問い合わせを確認できるという利点があります。

一方で、保存する場合は次の管理が必要です。

• WordPress管理画面へ誰が入れるか
• 問い合わせ内容を閲覧できる権限
• 管理者アカウントの多要素認証
• プラグインの更新
• 保存期間
• 削除方法
• CSV出力の権限
• バックアップへの保存
• 委託先のアクセス
• 不正アクセス時のログ

「メールにも保存し、WordPressにも永久保存する」という設定を、目的なく続けないことが重要です。

手順4　保存期間と削除対象を決める

問い合わせ内容について、個人情報保護法がすべての企業へ一律の保存年数を定めているわけではありません。

個人情報保護委員会の通則ガイドラインでは、利用目的の達成に必要な範囲で保存期間を設定し、利用する必要がなくなった個人データは遅滞なく消去するよう努めることが示されています。法令で別の保存期間が定められている場合は、その期間を優先します。

例えば、問い合わせフォームの保存期間は次の要素から決めます。

• 回答が完了するまでの期間
• 契約へ移行する可能性
• 苦情や対応履歴を確認する必要性
• 法令上の保存義務
• 契約上の保存条件
• 再問い合わせへの対応期間
• 事故調査に必要なログ期間

保存期間を決める例

問い合わせの種類	保存方法の例
一般的な問い合わせ	回答完了後、社内基準で定めた期間を経て削除
見積・商談	顧客管理システムへ必要情報だけ移し、フォーム原文は削除
採用応募	採用手続と再応募対応に必要な期間を定める
苦情・事故連絡	対応記録として必要な期間を法令・契約と照合
迷惑送信	対策に必要な情報だけを残し、本文は削除を検討

削除するときは、次の保存先をまとめて確認します。

• WordPressのフォームデータ
• メールボックス
• CRM
• チャット
• スプレッドシート
• 添付ファイル
• エクスポートしたCSV
• 制作会社の作業データ
• バックアップ

バックアップから直ちに個別データだけを削除できない構成もあります。

その場合は、バックアップの保存期間、復元時の再削除手順、アクセス権限を確認します。

手順5　通知先には全文を送らない

問い合わせ通知を、チャットやスマートフォンへ送っている会社があります。

通知先の例は次のとおりです。

• Microsoft Teams
• Slack
• Chatwork
• LINE WORKS
• SMS
• スマートフォンのプッシュ通知
• タスク管理サービス
• 営業支援システム

通知へ問い合わせ内容の全文を載せると、そのチャットやスマートフォンも新しい保存先になります。

本稿では、通知は次の程度にとどめる方法を推奨します。

新しい問い合わせを受信しました。
受付番号：20260830-001
種別：見積依頼
管理画面または共有メールボックスで確認してください。

氏名、電話番号、相談内容、添付ファイルを通知へ載せなければ、チャット側へ保存される個人情報を減らせます。

通知先へ全文を送る必要がある場合は、そのサービスの利用者、外部ゲスト、保存期間、端末通知、エクスポート権限を確認します。

手順6　自動返信メールの内容を見直す

問い合わせを受け付けた際、入力者へ自動返信メールを送る構成があります。

自動返信は受付確認に役立ちますが、入力内容の全文をそのまま返信する設定には注意が必要です。

入力者がメールアドレスを誤入力していた場合、問い合わせ内容が別人へ送られる可能性があるためです。

自動返信に入れる内容の例

• 受付を完了したこと
• 受付番号
• 問い合わせ種別
• 回答までの目安
• 営業時間
• 緊急連絡には対応できないこと
• 会社の正式な連絡先
• 返信メールへ機密情報を書かない注意
• 心当たりがない場合の連絡先

相談内容、住所、電話番号、健康情報などの全文を再掲する必要があるかは、業務ごとに判断します。

また、自動返信を使っている場合は、送信元ドメインのSPF、DKIM、DMARCも確認してください。

手順7　ファイルアップロードは必要なフォームだけにする

採用応募、修理依頼、事故報告などでは、履歴書、画像、ログ、PDF等をアップロードさせる場合があります。

ファイルアップロード機能は便利ですが、通常の文字入力フォームより確認事項が増えます。

OWASPは、アップロード機能について、許可する拡張子の限定、ファイル形式の確認、ファイル名の変更、容量制限、Web公開領域外への保存、ウイルス検査、利用者権限の制限などを推奨しています。

最低限確認する項目

• 本当にファイル提出が必要か
• 許可する拡張子
• 最大ファイルサイズ
• ファイル名の扱い
• 保存場所
• Webから直接閲覧できないか
• マルウェア検査
• 担当者が開く端末
• メール添付するか
• 保存期間
• 削除方法

Contact Form 7の公式資料では、アップロードファイルを一時フォルダへ移動し、メール送信後に削除する標準的な処理が説明されています。ただし、追加プラグインや独自設定を使う場合は、実際の保存場所と削除動作を個別に確認する必要があります。

履歴書や大容量ファイルをメール添付で送るより、アクセス制御されたファイル受け渡しサービスを利用した方が管理しやすい場合もあります。

手順8　迷惑送信対策が実際に動いているか確認する

CAPTCHAやボット対策の画像がフォーム上に表示されていても、サーバー側で検証していなければ、フォーム送信処理を直接呼び出される可能性があります。

Cloudflareは、Turnstileについて、ブラウザ側のウィジェット表示だけでは保護にならず、サーバー側からSiteverify APIを呼び出してトークンを検証することが必須だと説明しています。

確認する項目は次のとおりです。

• CAPTCHAやTurnstileがサーバー側でも検証されているか
• 失敗した送信を拒否しているか
• 同じ送信元からの大量送信を制限しているか
• 異常な送信数を記録しているか
• 正常な利用者が送信できなくなっていないか
• 開発・検証用のキーが本番へ残っていないか
• 秘密鍵がWebページへ露出していないか
• 使用ドメインが制限されているか

CAPTCHAだけですべての迷惑送信や攻撃を防げるわけではありません。

入力値検証、更新管理、送信回数制限、ログ監視と組み合わせます。

フォームのプラグインと外部連携を一覧にする

WordPressでは、フォーム本体とは別のプラグインが動いていることがあります。

確認対象

分類	例
フォーム本体	Contact Form 7、WPForms、Elementor Formsなど
データ保存	問い合わせ内容をWordPressへ保存する追加機能
SMTP	外部メールサーバーから送信する機能
自動返信	入力者への返信
ファイル管理	添付ファイルの保存・転送
迷惑送信対策	CAPTCHA、Turnstile、フィルタ
CRM連携	顧客管理サービスへの登録
Webhook	外部システムへの送信
自動化	チャット通知、スプレッドシート登録
アクセス解析	フォーム完了イベントの記録

IPAは、安全なWebサイトの運用には、Webサイトを構成するCMS、フレームワーク、プラグイン等を把握し、脆弱性情報を確認して更新する必要があるとしています。

「制作会社に任せている」という回答だけでは不十分です。

自社側でも、使用製品、バージョン、更新責任者、緊急連絡先を説明できるようにします。

制作会社・運用会社へ確認したい12項目

確認項目	質問内容
使用製品	フォーム本体と追加プラグインの名称は何か
バージョン	現在のバージョンは何か
更新責任	誰が脆弱性情報を確認し、更新するか
送信先	現在どのメール・APIへ送信しているか
保存先	Webサーバーやデータベースへ保存されるか
保存期間	いつ削除されるか
閲覧者	制作会社の誰がフォーム内容を閲覧できるか
外部連携	CRM、チャット、Webhook等へ送っているか
添付ファイル	どこへ保存し、どのように検査するか
ログ	送信・閲覧・設定変更の記録を確認できるか
事故連絡	異常時にいつ、誰へ連絡するか
契約終了	データ、アカウント、バックアップをどう処理するか

Webサイトの運用を委託しても、自社が取得した顧客情報の管理をすべて委託先任せにできるわけではありません。

委託先の選定、契約、運用中の確認、契約終了時の削除まで管理する必要があります。

月次点検では実際にテスト送信する

設定画面を見るだけでなく、実際にフォームを送信します。

テストには、他の問い合わせと区別できる受付番号を入れます。

テスト送信
識別番号：FORM-20260830-01

確認する内容

1. 送信完了画面が正しく表示されたか
2. 担当者へメールが届いたか
3. 旧担当者や想定外の人へ届いていないか
4. 自動返信が届いたか
5. 迷惑メールフォルダへ入っていないか
6. WordPress管理画面へ保存されたか
7. CRMやチャットへ登録されたか
8. 添付ファイルがどこへ保存されたか
9. ログへ送信記録が残ったか
10. 保存データを実際に削除できたか

「メールが届いた」だけで試験を終わらせないことが重要です。

送信から保存、通知、削除まで一連の流れを確認します。

本稿では、重要な問い合わせフォームは月1回、その他のフォームは四半期またはサイト変更時に確認する方法を提案します。これは法令上の一律義務ではありません。

月1回確認したいフォーム管理の数字

指標	確認する意味	目指す状態
公開中のフォーム数	管理対象を把握できているか	台帳と一致
所有者不明のフォーム数	誰が必要性を判断するか	0
送信先不明のフォーム数	誰へ届くか分かるか	0
保存先不明のフォーム数	どこへ残るか分かるか	0
退職者・旧委託先への通知数	古い宛先が残っていないか	0
保存期限超過件数	不要な個人情報が残っていないか	0
更新期限超過プラグイン数	脆弱な構成が残っていないか	0
個人情報を含むチャット通知数	通知先へ不要なコピーがないか	必要最小限
添付ファイル対応フォーム数	高リスク機能を把握しているか	すべて承認済み
送信テスト失敗数	問い合わせを見落とさないか	0
削除テスト未実施数	実際に消去できるか	0
管理者不明の外部連携数	Webhook等を管理できているか	0

誤った送信先や公開状態を発見した場合

問い合わせ内容が旧担当者へ送られていた、管理画面が認証なしで閲覧できた、外部チャットへ全文が投稿されていたといった問題を発見した場合は、単に設定を直して終わらせないでください。

初動の例

1. フォームの停止または問題のある連携を停止する
2. 現在の設定、画面、ログを保存する
3. 影響を受けたフォームを特定する
4. 問題が続いていた期間を確認する
5. 対象となる問い合わせ件数を確認する
6. 含まれていた個人情報の種類を確認する
7. 実際の閲覧者・受信者を確認する
8. 不要な権限、転送、連携を停止する
9. 関係するパスワードやAPIキーを変更する
10. 個人情報保護委員会への報告や本人通知の要否を判断する
11. 委託先・取引先への連絡要否を判断する
12. 対応の時系列を記録する

すべての誤設定が、直ちに報告対象の漏えい等へ該当するわけではありません。

個人データが含まれていたか、第三者が閲覧・取得した可能性があるか、報告対象事態に該当するかを確認して判断します。個人情報保護委員会は、漏えい等が発生した場合に、内部報告、事実関係の調査、影響範囲の特定、再発防止策、関係者への通知等を進める考え方を示しています。

事故対応の全体像は、既存記事「事故が起きたら何をする？中小企業の情報セキュリティ対策ガイドライン第4.0版 STEP3後半を解説」と併せて確認できます。

30日でフォーム管理を整える

期間	実施すること	完成させるもの
第1週	公開中のフォームを洗い出す	フォーム一覧
第1週	入力項目、利用目的、業務責任者を確認する	フォーム台帳の初版
第2週	送信先、保存先、通知先を確認する	データ経路図
第2週	プラグイン、外部連携、バージョンを確認する	構成・更新一覧
第3週	退職者、旧委託先、不要な通知先を削除する	変更記録
第3週	保存期間と削除方法を決める	保存・削除基準
第4週	テスト送信と削除試験を行う	試験記録
第4週	誤送信・不正アクセス時の初動を確認する	初動チェック表

最初からすべてのフォームを詳細に調べるのが難しい場合は、次の順番で進めます。

1. 採用応募
2. 見積・商談
3. 個人情報相談
4. ファイル添付があるフォーム
5. 一般問い合わせ

個人情報の種類が多いフォームや、添付ファイルを受け取るフォームから優先してください。

経営者が確認したい五つの質問

経営者がWordPressやプラグインの細かな設定を理解する必要はありません。

Web担当者や制作会社へ、次の五つを質問してください。

1. 会社のWebサイトにあるフォームをすべて一覧にできるか
2. 入力内容が、メール以外のどこへ保存されるか説明できるか
3. 退職者、旧担当者、制作会社へ現在も通知されていないか
4. 問い合わせデータの保存期間と削除方法が決まっているか
5. 最後にテスト送信し、保存先と削除まで確認したのはいつか

この五つに答えられないからといって、直ちに情報漏えいが起きているとは限りません。

しかし、問い合わせフォームから取得した情報を、会社として管理できていない可能性があります。

まとめ

問い合わせフォームは、Webサイト上に置かれた単なる入力欄ではありません。

顧客の情報を取得し、社内や委託先のシステムへ渡す、業務システムの入口です。

確認すべきなのは、担当者へメールが届くかどうかだけではありません。

1. 何の目的で情報を取得するか
2. どの項目を入力させるか
3. どこへ送信されるか
4. どこへ保存されるか
5. 誰へ通知されるか
6. どの外部サービスへ連携されるか
7. いつ削除するか
8. 誰が設定と更新を管理するか

最初の一歩として、会社の問い合わせフォームから、実際に一件のテスト送信を行ってください。

そして、次の質問へ具体的に答えます。

この問い合わせ内容は、送信ボタンを押した後、どこを通り、誰に届き、どこへ残るのか。

この経路を一枚の表にできれば、問い合わせフォームを「制作会社が作ったページ」から、「会社が管理する情報受付窓口」へ変えることができます。

ライトハウスコンサルタントでは、中小企業のWebサイト、クラウド、メール、アカウント、委託先を含めた情報セキュリティの現状整理を行っています。フォームの保存先が分からない、制作会社へ何を確認すべきか分からない、個人情報を含む問い合わせがどこへ残るか不安な場合は、「中小企業セキュリティ現状診断」またはお問い合わせページからご相談ください。