結論：第一候補は「必要機能を最小構成で満たすプラグイン」
名称や人気だけで選ばず、保存の有無、メール設定、スパム対策、権限、個人データの書き出し・削除、障害調査に必要な記録を比較してください。一般的な問い合わせなら、氏名または会社名、返信先メール、用件、本文程度から始め、運用上の必要が確認できた項目だけを追加します。
第一候補にする条件
担当者が設定を理解でき、ステージングで送信を再現でき、保存場所と閲覧権限を説明でき、更新が継続されている候補です。無料か有料かではなく、必要な受付証跡を無理なく維持できることを優先します。
選ばない方がよい条件
誰も見ないDBへ無期限保存する、訪問者のメールアドレスをFromに使う、成功画面だけで到達確認を終える、CAPTCHAだけで安全と言い切る、機密情報を自由記述や添付で収集する運用は避けます。
公開できる状態
正常送信、入力エラー、スパム、メール不達、二重送信を試し、受付記録と受信メールを突合し、削除試験、権限確認、代替連絡先の表示まで完了した状態です。
個人情報の流れを先に描く
送信ボタンを押した後、値はWordPressだけに留まるとは限りません。メール配送、DB、CRM、チャット通知、アクセスログ、迷惑送信判定サービス、バックアップへ複製される可能性があります。項目ごとに取得目的と保存先を記録し、プライバシーポリシーと実装を一致させます。
フォームへ書かせない情報を明記する
パスワード、秘密鍵、カード番号、マイナンバー、診療情報などは、通常の問い合わせフォームで集めない方針を画面に示します。どうしても機微な情報が必要なら、目的に適した認証・暗号化・権限・監査を備えた別経路を設計してください。
表は横にスクロールできます。
| 処理点 | 確認するデータ | 主なリスク | 公開前の証拠 |
|---|---|---|---|
| 入力画面 | 各フィールド、添付、同意、IP・端末情報 | 過剰取得、入力内容の覗き見、誤送信、機密情報の記載 | 取得目的、必須理由、HTTPS、ラベル、エラー、注意書き |
| WordPress処理 | 送信値、nonce、スパム判定、処理ログ、一時ファイル | 脆弱な拡張、過大ファイル、保存場所不明、管理画面の権限過多 | 更新状況、許可形式・容量、保存設定、権限一覧 |
| 通知メール | 宛先、件名、本文、Reply-To、添付 | なりすまし判定、誤宛先、転送・端末への複製、添付拡散 | 同一ドメインFrom、固定宛先、実受信、ヘッダー、配送ログ |
| DB・CRM | 問い合わせ本文、担当、対応履歴、エクスポート | 無期限保存、広い閲覧権限、CSV持ち出し、削除漏れ | 保持期限、最小権限、削除・書き出し試験、監査記録 |
| 外部サービス | 迷惑送信判定、メールAPI、分析、Webhook、バックアップ | 国外処理、再委託、障害、利用目的外の複製 | 送信項目、所在、契約、保持、削除、障害時の代替 |
5候補は順位ではなく運用条件で選ぶ
すべてのサイトに同じ最適解はありません。既存テーマとの表示確認、必要な連携、保存方針、担当者の習熟度をステージングで確かめます。下表は候補を絞る入口であり、現行の無料・有料境界や外部送信仕様は公式ページで再確認してください。
表は横にスクロールできます。
| 候補 | 向く条件 | 保存の確認 | 導入時の重点 |
|---|---|---|---|
| Contact Form 7 | フォームとメール設定を自分で組み、構成を小さく保ちたい。 | 既定構成では個人データをDBへ書き込まない。保存が必要ならFlamingo等の保存先と権限・期限を別に設計する。 | 同一ドメインFrom、Reply-To、メールタグ、スパム連携、実受信を確認する。 |
| WPForms Lite | 画面操作でフォームを組み、通知・確認画面を設定したい。 | フォーム単位の保存設定と、現在のライセンスで閲覧・復旧できる範囲を確認する。 | 通知宛先、保存無効化、スパム対策、エントリーの削除・書き出しを試す。 |
| Ninja Forms | メール、成功表示、保存などの処理をアクション単位で管理したい。 | 新規フォームのRecord Submissionアクションを確認し、不要なら停止、必要なら期限と閲覧者を決める。 | Admin Emailを含む各アクションが有効か、From・Reply-To・件名・受信結果を確認する。 |
| Gravity Forms | 条件分岐や業務連携を含む有料フォーム基盤を運用できる。 | エントリー、添付、連携先、アドオンごとの保存と削除範囲を設計する。 | ライセンス、権限、Webhook失敗、再送、連携先の個人情報処理を確認する。 |
| Formidable Forms | 入力データを一覧・計算・表示などの業務機能へ展開したい。 | 問い合わせ以上のデータベース用途になりやすいため、表示範囲、権限、保持、削除を先に決める。 | 公開ビューへの漏えい、計算・条件分岐、エクスポート、無料・有料境界を確認する。 |
安全なフォームを最小構成で組む
本番へ直接追加せず、ステージングでフォーム、メール、保存、外部連携を一式作ります。既存フォームの置換では、旧URLと新URLを並行監視し、未処理の問い合わせがないことを確認してから切り替えます。
- 1
目的と受付責任者を一文で決める
「見積依頼へ回答する」「採用応募を受け付ける」のように利用目的を限定し、受信担当、代理担当、対応期限、休日の扱い、代替連絡先を決めます。目的が違う問い合わせはフォームを分けます。
- 2
必須項目を減らす
返信に必要なメールアドレスと用件から始めます。電話、住所、部署、添付を必須にする前に、取得しないと対応できない理由を確認します。自由記述には入力してはいけない情報を表示します。
- 3
ラベルとエラーを操作できる形にする
placeholderだけで項目名を示さず、可視ラベルを関連付けます。必須、形式、文字数、許可ファイル、容量を送信前に示し、エラー後も入力値とフォーカス位置を維持します。キーボードと390px幅で確認します。
- 4
HTTPSと添付制限を確認する
フォーム、確認・完了ページ、外部APIをHTTPSに統一します。添付が不要なら無効化し、必要なら拡張子だけでなくMIME、容量、個数、保存場所、ウイルス検査、公開URL化の有無を確認します。
- 5
プライバシー説明を送信前へ置く
取得項目、利用目的、保存先、第三者・委託先、保持、問い合わせ窓口を実装に合わせて案内します。プライバシーポリシーへのリンクだけで説明を終えず、送信の直前に目的を短く表示します。
- 6
公開URL以外でも検証する
ログアウト、スマートフォン、Cookie制限、JavaScript失敗、遅い回線、複数ブラウザを試します。キャッシュ、WAF、CDN、同意管理が送信エンドポイントを遮断しないか確認します。
通知メールと迷惑送信対策を別々に検証する
画面に「送信しました」と出ても、管理者の受信箱へ届いた証拠にはなりません。フォーム処理、WordPressのメール呼び出し、ホストまたはメールAPI、受信側の判定を分けて観測します。迷惑送信対策は一つに依存せず、正規利用者を拒否しないことも試します。
メール設定
- Fromはサイトと同じドメインの固定アドレスにし、訪問者のメールはReply-Toへ設定する。
- To、Cc、Bccを固定宛先と権限者に限定し、退職者・共有転送先を定期点検する。
- SPF、DKIM、DMARCと、利用するSMTPまたはメールAPIの認証・ログを確認する。
- 自動返信には受付番号と次の連絡目安を記載し、入力内容や機密情報を必要以上に複製しない。
迷惑送信対策
- nonce、時間条件、honeypot、レート制限、WAF、内容判定をリスクに応じて重ねる。
- CAPTCHAや外部判定へ送るデータ、Cookie、外部ドメイン、障害時の挙動を確認する。
- 短文、外国語、共有IP、支援技術、JavaScript制限でも正規送信できるか試す。
- 拒否時は理由と再試行方法、別の連絡手段を表示し、無限再送を防ぐ。
重複・不達監視
- 送信ボタンを処理中に無効化し、再読み込み・戻る操作で二重受付しないか確認する。
- 受付番号、時刻、フォームID、配送結果を個人情報を増やさない形で突合できるようにする。
- バウンス、API失敗、認証失敗、急な受付数ゼロ、スパム急増を通知する。
- 通知が止まったときにDBまたは代替経路から未処理分を回収できるか決める。
保存・閲覧権限・削除を一つの運用にする
保存しない場合はメール不達時に問い合わせを失う可能性があり、保存する場合は漏えい・持ち出し・削除漏れの責任が増えます。どちらが安全かは業務要件で決まります。メールだけ、DBだけに依存せず、必要な証跡と最小保持を両立させます。
保存前
- DB、メール、CRM、チャット、ログ、外部判定、バックアップの全コピーを列挙する。
- 役割ごとに閲覧・書き出し・削除権限を分け、管理者権限を配布しない。
- 法令・契約・紛争対応を踏まえて保持期限と削除責任者を決める。
運用中
- 問い合わせ本文を個人端末や無管理の表計算へコピーしない。
- CSV書き出しを記録し、保存先、共有範囲、削除日を管理する。
- 権限変更、プラグイン更新、連携先追加のたびにデータマップを更新する。
削除・開示
- 本人確認を行い、同姓・転送先・共有アドレスによる誤開示を防ぐ。
- WordPressの書き出し・消去ツールは参加プラグインとWordPress内が中心で、外部サービスは別確認する。
- 削除後に検索、ゴミ箱、メール、CRM、ログ、バックアップ復元時の再出現を確認する。
個人情報保護委員会の通則編は、利用目的に必要な範囲で正確性を保ち、利用する必要がなくなった個人データを遅滞なく消去するよう努めること、保存期間の設定などを示しています。具体的な保存期間や削除可否は一律ではないため、適用法令と業務上の保存義務を確認してください。
公式画面で設定境界を確認する
製品バナーではなく、送信先・送信元と個人データ管理の実際の確認点を見ます。画面構成は更新されるため、画像内の位置を暗記せず、同じ意味の設定を現行版で探してください。
送信テストは受付から削除まで通す
テスト用の個人情報を使い、画面の表示だけでなく保存レコード、管理者通知、自動返信、配送ログ、担当者の処理、期限後の削除を同じ受付番号で突合します。本番の実在顧客データをテストへ流用しません。
正常系
- ログアウト状態で必須最小項目を入力し、一度だけ送信できる。
- 完了表示に受付結果、次の連絡目安、代替連絡先がある。
- 管理者通知と自動返信が複数の実受信箱へ届き、Reply-Toが正しい。
- 保存する設計ではDB・CRMの値とメールが一致し、権限者だけが閲覧できる。
異常系
- 空欄、不正形式、長文、HTML、URL連投、禁止形式・過大添付を安全に拒否する。
- 連打、戻る、再読み込み、通信切断で二重受付や不明な完了表示にならない。
- スパム判定、メールAPI停止、認証失敗、保存失敗を監視し、受付を失わない。
- エラーに内部パス、SQL、APIキー、メール設定、入力済み個人情報を表示しない。
運用系
- 担当者が受付を検索し、対応済みにし、権限外ユーザーが閲覧できない。
- 書き出し依頼と削除依頼を本人確認付きで処理できる。
- 保持期限後にDB、ゴミ箱、メール、外部連携から削除できる。
- バックアップ復元後も過去の削除記録を尊重する手順がある。
不達・漏えい・障害時は受付を止めて証拠を守る
原因が分からないままフォームを再設定すると、未処理データやログを失うことがあります。影響範囲を確定し、代替窓口を出してから復旧します。
- 1
受付状態と代替手段を表示する
受付を安全に継続できない場合はフォームを停止し、電話や別システムなど管理できる代替窓口と復旧見込みを示します。送信済みか不明な利用者へ、むやみな再送を促しません。
- 2
変更を止めて時刻と証跡を保全する
発覚時刻、最終正常受付、フォーム設定、更新履歴、配送・WAF・アクセスログ、DB件数、連携先の状態を保存します。個人情報を含むログの共有先は限定します。
- 3
受付処理と配送処理を切り分ける
成功表示、DB保存、WordPressメール呼び出し、メールサービス受理、バウンス、受信側隔離を順に確認します。DBにある未通知分は重複連絡を防いで再処理します。
- 4
漏えいの可能性を評価する
不正閲覧、誤送信、公開URL、権限逸脱、外部流出の対象項目・件数・期間を調べます。個人の権利利益を害するおそれがある漏えい等は、適用法令に従い報告・本人通知の要否を速やかに判断します。
- 5
修正後に全シナリオを再試験する
設定変更だけで完了にせず、正常・異常・スパム・不達・権限・削除を再実行します。未処理問い合わせを回収し、利用者への案内、原因、再発防止、監視条件を記録します。
公開判定チェックリスト
一つでも担当や証拠が曖昧なら、公開前に解消します。
画面と安全性
- HTTPS、可視ラベル、エラー、キーボード、390pxを確認
- 取得項目、添付、文字数を最小化
- スパム拒否と正規利用者の通過を確認
到達と受付
- From、Reply-To、SPF・DKIM・DMARCを確認
- 管理者通知、自動返信、配送ログを突合
- 重複、不達、受付数ゼロを監視
個人情報
- 全保存先と外部送信先を説明
- 閲覧・書き出し・削除を最小権限化
- 保持期限、本人確認、削除試験を記録
確認した一次資料
2026年7月25日に確認しました。WordPressと各プラグインの機能・画面は変わるため、導入時と更新前に再確認してください。
- Contact Form 7公式「Setting up mail」
- WordPress.org「Contact Form 7」プライバシー説明
- WordPress公式「WordPress Privacy」
- 個人情報保護委員会「個人情報保護法ガイドライン（通則編）」
- WPForms公式「How to Create GDPR Compliant Forms」
- Ninja Forms公式「Creating a New Form」
- Ninja Forms公式「Email Action Troubleshooting」
- WordPress.org「Flamingo」
- WordPress.org「WPForms Lite」
- WordPress.org「Ninja Forms」
- Gravity Forms公式サイト
- WordPress.org「Formidable Forms」
よくある質問
成功メッセージが出ればメールも届いていますか？
いいえ。フォーム処理が成功しても、その後のホスト、メールAPI、DNS認証、受信側判定で止まることがあります。管理者の実受信、配送ログ、バウンスを確認してください。
お問い合わせ内容はDBへ保存した方が安全ですか？
一律には決まりません。保存すればメール不達時の回収に役立つ一方、閲覧・持ち出し・削除・漏えいの管理対象が増えます。受付の継続性と最小保持を比較し、保存先、権限、期限、削除を決めてください。
CAPTCHAを付ければ迷惑送信対策は完了ですか？
完了ではありません。回避される場合や正規利用者を拒否する場合があります。nonce、honeypot、レート制限、WAF、内容判定、監視を組み合わせ、誤判定と外部送信データも確認します。
自動返信メールへ問い合わせ全文を載せてもよいですか？
転送、共有端末、誤入力したアドレスへ個人情報を複製するため、必要性を検討してください。受付番号、受付時刻、次の連絡目安を中心にし、機密情報や添付をそのまま返さない設計が安全です。
WordPressの個人データ消去で外部サービスも消えますか？
自動では網羅されません。WordPress公式も、参加プラグインとWordPress内のデータが中心で、第三者サービスなどは別対応が必要になり得ると説明しています。メール、CRM、Webhook、ログ、バックアップを個別に確認してください。
関連する運用ガイド
まとめ：フォームの完成条件は「受け付け、守り、消せる」こと
必要な情報だけを取得し、同一ドメインFromと正しいReply-Toを設定し、スパム対策と実受信を試し、保存先・権限・保持・削除を運用してください。成功画面ではなく、受付記録から担当者の受信、利用者への確認、期限後の削除まで通った証拠で公開可否を判断します。
監修
Finite Field 編集部
WordPress運用、メール配送、サーバー、個人データの境界を分けて検証し、再現できる公開条件へ編集しています。
WordPressフォームの個別開発・運用支援
既存フォームの不達・スパム・個人情報運用を整理したい方へ
フォーム設定、メール認証、保存先、権限、外部連携、保持・削除、障害時の回収方法を確認し、必要な改修範囲をご案内します。
お問い合わせフォーム運用を相談する状況と権限、契約サービスを確認したうえで対応可否をご案内します。迷惑送信ゼロ、全メール到達、法令適合、漏えい防止、データ復旧を事前に保証するものではありません。