WordPressお問い合わせフォームの作り方｜方法・プラグインを比較

WordPressへお問い合わせフォームを置く方法は、プラグイン、外部フォームサービス、独自開発の3つです。一般的な企業サイトならプラグインで始めやすいものの、確認画面、送信内容の保存、条件分岐、決済などの要件によって適した製品は変わります。

フォームは画面に表示されただけでは完成ではありません。通知メールと自動返信、送信データの扱い、スパム対策、スマートフォンでの入力、エラー時の案内まで試して初めて運用できます。問い合わせページを含むサイト全体の設計は「ホームページに必要なページ構成」も参考にしてください。

WordPressにお問い合わせフォームが必要な理由

フォームがあると、利用者はメールアプリを開かずに、決められた項目へ情報を入力できます。運営側も、氏名、返信先、問い合わせ種別などを一定の形式で受け取れるため、担当部署へ振り分けやすくなります。

公開メールアドレスだけを置く方法と比べ、入力チェック、同意確認、スパム対策を組み込みやすい点も利点です。ただし、フォーム自体がメール到達や個人情報保護を保証するわけではありません。受付後の保管、返信、削除まで運用を決める必要があります。

問い合わせ件数が少なくても、送信後に「受け付けたか分からない」状態を避けるため、完了表示と返信目安を用意します。電話や緊急窓口がある場合は、フォームで受け付けない内容も明記してください。

運用側では、受付番号、担当部署、初回返信期限、完了条件を決めます。複数人が同じ通知メールを見るだけでは、二重返信や対応漏れが起こります。問い合わせ管理システムを使わない場合でも、担当中、回答待ち、完了などの状態を共有できる仕組みを用意します。

障害時の代替窓口も必要です。フォームが停止したときに利用者が連絡できる電話番号や別メールを、重要度に応じて案内します。フォームページ自体が開かない障害と、送信メールだけが届かない障害は別に監視してください。

WordPressでお問い合わせフォームを作る3つの方法

方法	向くケース	長所	注意点
プラグイン	一般的な問い合わせ、資料請求	WordPress内で作成・設置しやすい	更新、互換性、メール設定が必要
外部フォームサービス	複数サイトの集約、高度な集計	送信基盤や管理画面をサービス側で持てる	外部送信、料金、デザイン制約を確認
独自開発	特殊な業務フロー、既存システム連携	要件に合わせて実装できる	セキュリティ、保守、テストの負担が大きい

プラグインは導入が早い一方、必要な機能が複数の追加プラグインに分かれることがあります。外部サービスはWordPress障害時にも受付を分離できる場合がありますが、個人情報がどこへ保存されるかを確認します。

独自開発では、入力検証、CSRF対策、メールヘッダー対策、レート制限、ログ、再送制御まで必要です。単にPHPで送信関数を呼ぶだけでは、安全な受付システムになりません。

外部サービスを選ぶときは、WordPressへ埋め込むだけか、自社ドメイン風の画面を使えるか、APIやWebhookで社内システムへ渡せるかを確認します。サービス障害や契約終了時に、フォームと過去データをどの形式で移せるかも重要です。

独自開発が必要に見えても、既存プラグインのフックや外部サービス連携で満たせる場合があります。反対に、医療、採用、決済など高い管理要件があるフォームを、安価さだけで汎用プラグインへ寄せるのも危険です。取得情報の機微性と停止時の影響から方法を選びます。

お問い合わせフォーム用プラグインの選び方

先に必要な機能を「必須」と「あると便利」に分けます。確認する主な項目は次のとおりです。

• ブロック編集か、タグ・ショートコード編集か
• 確認画面と完了画面が必要か
• 条件分岐、ファイル添付、複数宛先が必要か
• 送信内容をWordPress内へ保存するか
• 自動返信と管理者通知を別々に設定できるか
• reCAPTCHA、hCaptcha、Turnstileなどに対応するか
• 使用中のWordPress、PHP、テーマへ対応するか
• エクスポート、削除、保持期間の管理ができるか
• 開発元の更新とサポートが継続しているか

保存機能は便利ですが、漏えい時の影響も増えます。メールだけで受け取るのか、データベースにも残すのか、残すなら誰がいつ削除するのかを決めます。無料版と有料版の境界は変更されることがあるため、契約前に公式の現行機能を確認してください。

選定用のテストフォームを作り、代表的な要件を実際に試すと比較しやすくなります。日本語の氏名、長い住所、全角記号、スマートフォンの自動入力、ファイル添付、入力エラーを用意し、作成者だけでなく実際の対応担当者にも通知メールと管理画面を見てもらいます。

プラグインの更新が止まった場合の移行先も考えます。フォーム定義、送信履歴、迷惑メール設定をエクスポートできるか、ショートコードを削除した後にページへ文字列が残らないかを確認します。

WordPressお問い合わせフォームの主なプラグインを比較

プラグイン名だけで決めず、編集方法と送信データの扱いを比較します。

選択肢	作り方	送信内容の保存	向く運用
Contact Form 7	フォームタグとショートコード	標準では保存しない	シンプルなフォームを細かく設定したい
Snow Monkey Forms	ブロックエディター	現行仕様を要確認	画面を見ながらブロックで作りたい
WPForms Lite	ドラッグ＆ドロップ	Liteは通常WP内へ保存しない	テンプレートから短時間で作りたい
Forminator	ビジュアルビルダー	送信データを管理可能	フォーム以外に投票や計算も検討する
外部サービス	サービスの管理画面	サービス側の仕様による	複数サイトや社内処理と連携したい

保存先と保持期間は製品のバージョン、設定、契約によって変わります。導入テストでは、実際に送信し、WordPressのDB、メール、外部サービスのどこへ何が残るかを確認してください。

比較表の「保存」は、バックアップやメール配送事業者まで含む全保存先を表していません。WordPressで保存を無効にしても、通知メールの送信済みボックス、受信箱、サーバーログ、外部連携にデータが残る場合があります。データの流れを入口から削除まで図にすると、見落としを減らせます。

Contact Form 7が向くケース

Contact Form 7は、フォームタグで入力欄とメール本文を設定し、ショートコードで固定ページへ設置するプラグインです。複数のフォームを作成でき、HTMLやタグの構成を理解して調整したい人に向きます。基本操作は「Contact Form 7の使い方」で詳しく確認できます。

送信内容は標準ではWordPressのデータベースへ保存されません。保存が必要なら、同じ開発元のFlamingoなどを組み合わせます。Flamingoを使うと個人情報を含む送信内容がサーバーのDBへ残るため、閲覧権限と削除方針が必要です。

確認画面を当然に備える製品ではないため、要件に確認画面がある場合は現行の公式機能や拡張方法を調べます。フォームタグ名とメール本文のメールタグが一致しないと、通知へ値が入りません。

メール設定では、フォームに存在しないメールタグを使うと警告が出る場合があります。追加・削除した入力欄は、管理者通知と自動返信の両方へ反映します。利用者入力を件名へそのまま入れると長大化や制御文字の問題が起こり得るため、固定件名と問い合わせ種別など限定した値を組み合わせます。

Contact Form 7の設定をテーマファイルへ直接書き込む必要はありません。見た目を変えるCSSは、テーマ更新で消えない場所へ置き、必須表示やエラー色がテーマの配色でも読めるかを確認します。

Snow Monkey Formsが向くケース

Snow Monkey Formsはブロックエディター向けのメールフォームプラグインです。テキスト、メール、電話、URL、ファイル、選択、チェックボックス、日付などのブロックを組み合わせてフォームを作れます。Snow Monkey以外のテーマでも使用できますが、表示は使用テーマで確認します。

コードやフォームタグを直接編集するより、入力画面、確認、完了の構成をブロックで作りたい人に向きます。導入時は、利用中のWordPressとPHPがプラグインの現行要件を満たすかを公式配布ページで確認してください。

テーマのCSSと競合すると、ラベル、エラー、ボタンの余白が変わる場合があります。パソコンだけでなくスマートフォン、キーボード操作、エラー表示を試します。

ブロックで作れることと、業務要件を満たすことは分けて確認します。確認画面から戻ったときに入力値が残るか、二重送信を防げるか、ファイル添付をどこへ保存するかなど、実際の受付手順で試してください。

そのほかのフォームプラグイン・外部サービス

WPFormsはドラッグ＆ドロップ型のビルダーとテンプレートが特徴です。Liteでは通常、送信内容をWordPressデータベースへ保存しないため、保存が必要なら現行プランやLite Connectのデータ保管条件を確認します。

Forminatorはフォーム、投票、クイズ、計算、決済連携などを扱える選択肢です。高機能な製品ほど設定と外部連携が増えるため、使わない機能を理由なく有効にしないでください。

Googleフォームなどの外部サービスを埋め込む方法もあります。短時間で用意できますが、利用規約、送信先、Cookie、アクセシビリティ、デザイン、ドメイン制限を確認します。問い合わせ管理をCRMやチケットシステムへ集約するなら、WordPressへ保存しない構成も選べます。

お問い合わせフォームを設置する基本手順

どのプラグインでも、次の順序で進めると抜けを減らせます。

1. 問い合わせ種別と受付後の業務フローを決める
2. 必要最小限の入力項目を決める
3. ステージングへプラグインをインストールする
4. フォーム、管理者通知、自動返信を作る
5. 固定ページへフォームを設置する
6. プライバシーポリシーへの案内と同意欄を整える
7. 正常入力、入力エラー、スパム対策を試す
8. 宛先別の受信と返信を確認してから本番へ反映する

最初のフォームは、氏名、返信先メール、問い合わせ種別、本文程度に絞ります。住所や電話番号を「念のため」で必須にすると離脱と保管リスクが増えます。返信に本当に必要かを項目ごとに確認します。

入力項目には、ラベル、必須・任意、形式、最大長、エラー文、通知メールでの表示名を定義します。メールアドレスは確認入力を増やすだけでなく、自動返信の送達失敗を監視する方法も検討します。本文には最大長を設け、ファイル添付は拡張子だけでなくMIMEタイプと容量を制限します。

確認画面を入れるかは、入力内容の複雑さと誤送信の影響で決めます。確認画面がなくても、送信ボタンの直前に入力内容を見直せる配置、明確なボタン名、送信中の表示、二重クリック防止を整えられます。

設置ページには、送信内容、利用目的、返信目安、営業目的の扱い、緊急連絡には使えないことなど、実際の運用に合う案内を置きます。

メール送信設定とテストで確認する項目

WordPressのメール送信は、フォームが正常に処理されても、サーバー、DNS、迷惑メール判定の影響で届かないことがあります。管理者通知にはサイトと同じドメインの送信元を使い、返信先に利用者が入力したメールアドレスを設定する方法が一般的です。利用者のアドレスを送信元へ直接設定すると、なりすまし判定の原因になり得ます。

SPF、DKIM、DMARCなど、ドメインの送信認証もホスティングやメールサービスの案内に沿って整えます。大量送信や確実な到達が必要なら、トランザクションメールサービスとSMTPプラグインの利用を検討します。

テストでは以下を確認します。

• 管理者通知が正しい宛先へ届く
• 自動返信が利用者へ一度だけ届く
• From、Reply-To、件名が正しい
• 全入力値がメール本文へ反映される
• 添付ファイルの種類と容量制限が効く
• Gmailなど異なる受信サービスで迷惑メールにならない
• 送信完了とエラーが画面で区別できる

本番公開後も月1回など定期的にテストし、通知先変更やDNS変更のあとには必ず再確認します。

SMTPを使う場合は、WordPressからメールサービスまでの認証、メールサービスから受信者までの配送を分けて見ます。プラグイン上の「送信成功」は、最終受信箱への到達を保証しません。バウンス通知を受け取れる宛先を設定し、失敗率の急増を監視します。

自動返信へ問い合わせ全文を含めると、誤ったメールアドレスへ個人情報を送る可能性があります。受付番号と概要だけにする、機微情報を伏せるなど、内容に応じて設計します。自動返信を正式回答と誤解されない文面にし、返信可能なアドレスかどうかも明示します。

お問い合わせフォームのスパム対策

スパム対策は一つに依存せず、フォームの使いやすさを見ながら重ねます。選択肢には、ハニーポット、送信回数制限、IPや内容による判定、reCAPTCHA、hCaptcha、Cloudflare Turnstileなどがあります。

Google reCAPTCHAを使う手順と注意点は「reCAPTCHAでスパム対策」で確認できます。導入時は外部通信、プライバシーポリシーへの記載、Cookie同意の要否を、利用地域と自社方針に照らして確認してください。

難しい画像認証を毎回求めると、利用者も送信できなくなります。まず自動判定やハニーポットを使い、攻撃が増えたときに段階的に追加します。送信エラーをすべて同じ文言にすると切り分けにくいため、利用者向けの簡潔な案内と管理者向けログを分けます。

本文へ特定のURLや語句を含む場合の制限、同一送信元からの短時間連投、使い捨てメールなども判断要素になります。ただし、強すぎるルールは正当な問い合わせを捨てます。遮断数だけでなく、誤検知を確認できる隔離領域やログを用意します。

スパムが急増したら、フォームURL、時刻、送信元、本文の共通点を調べます。プラグインやWordPressの更新も確認し、攻撃元IPを一件ずつ永久遮断するだけで終えません。WAFやCDNで入口を制御する場合も、フォームが利用するREST APIや管理用通信を壊さないかテストします。

個人情報・同意・アクセシビリティの注意

取得する項目、利用目的、第三者提供、外部サービス、保管期間、問い合わせ窓口を整理し、実際の取り扱いに合うプライバシーポリシーを用意します。法的な要件は事業、地域、取得内容で異なるため、必要に応じて専門家へ確認してください。

同意チェックを置くだけで終えず、リンク先のポリシーを読めるようにし、必須か任意かを明示します。メールやDBの閲覧権限は対応者へ限定し、退職者のアカウントを止め、不要になった送信データを削除します。

アクセシビリティでは、入力欄ごとの見えるラベル、必須表示、具体的なエラーメッセージ、キーボード操作、十分な色の差を確認します。プレースホルダーだけで項目名を示すと、入力後に意味が分からなくなるため避けます。

エラーはページ上部の一覧だけでなく、該当入力欄との関係が分かるようにします。エラー発生後にキーボードの焦点が適切に移るか、読み上げで必須とエラーを認識できるかを確認します。日付や電話番号の入力形式を一つに限定する場合は、入力例をラベルの近くへ示します。

保存データの削除は、WordPress本体のDBだけでなく、バックアップ、メールボックス、外部サービスにも関係します。削除依頼を受けたときに、本人確認、対象特定、削除記録をどう行うかを事前に決めます。

メールが届かない・送信できない場合の対処

画面に送信完了が出るかで、フォーム処理とメール到達を分けます。

送信エラーになる場合は、必須項目、メール形式、ファイル容量、スパム判定、REST API、JavaScriptエラー、プラグイン競合を確認します。キャッシュや最適化機能がフォーム用スクリプトを遅延・結合して失敗することもあります。

完了表示は出るのにメールが届かない場合は、迷惑メール、宛先、FromとReply-To、サーバーのメールログ、SMTPログ、DNS認証を確認します。送信内容をDBへ保存していない構成では、メール障害中の問い合わせを後から復元できません。業務上の重要度に応じて、保存または外部受付の併用を検討します。

障害調査では、本番のフォームへ何度も個人情報を送らず、テスト用の内容と宛先を使います。発生時刻、フォーム名、表示メッセージ、メールサービスを記録すると、サーバー会社へ問い合わせやすくなります。

特定の端末だけ送信できない場合は、ブラウザ拡張、広告ブロック、Cookie、JavaScript、ネットワーク制限を切り分けます。すべての利用者で失敗するなら、直前のプラグイン更新、PHP変更、DNS変更、メールサービス障害を確認します。

送信ボタンを押すと二重に届く場合は、二重クリック、JavaScriptの再実行、キャッシュ、Webhookの再試行を調べます。受付側で一意のIDを付け、同じIDを重複登録しない設計にすると、外部連携時の二重処理も抑えられます。

よくある質問

まとめ

WordPressのお問い合わせフォームは、一般的な用途ならプラグイン、複数サイトの集約や外部業務との連携ならフォームサービス、特殊要件なら独自開発が候補です。編集方法だけでなく、確認画面、データ保存、スパム対策、保守状況で選んでください。

設置後は、正常送信、入力エラー、通知、自動返信、迷惑メール、スマートフォン、キーボード操作をテストします。取得する情報を最小限にし、閲覧権限と削除方針を決め、公開後も定期的に到達確認を続けることが安定運用につながります。