WordPressでサイトを作るとき、お問い合わせフォームの実装方法はほぼ必ず話題になります。一般的には以下のようなプラグインを使うケースが多く見られます。
- Contact Form 7
- MW WP Form（現在はSnow Monkey Formsに移行）
- その他フォーム系プラグイン
ただ、私の場合は原則としてフォーム系プラグインを使わない方針をとっています。その実務上の理由を整理します。
フォームプラグインを否定したいわけではない
フォームプラグイン自体が悪いわけではありません。以下のようなメリットがあるのは事実であり、条件によっては最適な選択になります。
- 手軽に導入できる
- 管理画面で完結する
- 非エンジニアでも触りやすい
それでも毎回使っていない理由
私がフォームプラグインを使わない理由は、コードで管理したほうが実務上楽だと感じているからです。ここで言う「楽」とは、以下の3点を指します。
- 実装が楽
- 管理が楽
- 数年後に見返したときも分かりやすい
また、Contact Form 7 などのフォームプラグインは、wp_mail() という WordPress の関数を使って以下の流れでメールを送信しています。
wp_mail()
↓
PHPMailer（wp_mail() が内部で使用しているライブラリ）
↓
サーバの MTA（mail / sendmail / postfix など）プラグインごとにUIや設定方法の違いはありますが、メール送信のコア部分の構造自体は大きく変わりません。それならば PHPMailer を自前で設置して使うほうが、カスタマイズ性や拡張性が高くなります。WordPress本体の更新による影響を受けにくく、プラグインのアップデートによってメール送信ができなくなるリスクも抑えられます。
⚠️ PHPMailerを直接導入する場合の注意： Composerでの依存管理を推奨します。手動設置の場合はバージョンアップを手動で行う必要があり、更新を怠ると既知の脆弱性が放置されるリスクがあります。定期的に PHPMailerのリリース情報 を確認してください。
プラグインだと「把握する場所」が増える
フォームプラグインを使うと、以下のように確認すべき場所が分散しがちです。
- HTMLはどこにあるか
- バリデーションは設定画面か
- メール文面は管理画面か
- フックは functions.php か
一方、コードで書いていれば構造が一目で分かります。
- このファイルがフォーム
- この処理が送信
- この部分がバリデーション
後から自分が触る場合でも、他の人が引き継ぐ場合でも、この把握しやすさの差は小さくありません。
MW WP Form の開発終了アナウンスがあったことも影響している
以前、定番プラグインだった MW WP Form について開発終了のアナウンスが出たことがありました（※現在は同開発者による「Snow Monkey Forms」があります）。現在もプラグイン自体は公開されていますが、以下の点は外から判断しづらい部分があります。
- 今後どこまで継続的にメンテナンスされるのか
- WordPressやPHPの将来バージョンに追随できるのか
この件をきっかけに、フォームという重要な機能を特定のプラグインに依存するリスクを強く意識するようになりました。
フォームは「止まると困る」機能
フォームは壊れてもすぐ気づきにくい一方で、止まると機会損失が大きい機能です。
- メールが届いていない
- スパムだけ届いている
- アップデート後に動かなくなった
こうしたトラブルの切り分けで、プラグイン・WordPress本体・サーバ設定を行き来するのは大きな負担になります。
管理画面から文言を変えたい、という要望について
フォームプラグインを使う理由として「管理画面から文章を変更したい」という要望もよく聞きますが、必ずしもフォームプラグインが必須とは限りません。
例えば、以下のような文言はカスタムフィールドとして用意しておき、フォームのコード側で読み込めば、管理画面から自由に変更できます。
- フォームの説明文
- 注意書き
- 送信完了メッセージ
- メール本文の一部
構造や処理はコードで管理しつつ、変更頻度の高い文言だけを管理画面に切り出す形にすることで、以下のメリットが得られます。
- どこを触ればいいか分かりやすい
- 設定が散らばらない
- 数年後に見ても把握しやすい
プラグインを使うと、どうしても制約が出てくる
フォームプラグインを使うと、プラグイン側の仕様に合わせる必要が出てきます。例えば、以下のような細かい調整を行いたい場面です。
- HTML構造を細かく調整したい
- クラスの付け方を統一したい
- バリデーションの挙動を少しだけ変えたい
- 分岐条件を要件どおりに書きたい
こうした調整をしようとすると、次の流れになりがちです。
- 用意されている設定では足りない
- フィルターやフックを探す
- 結局、プラグインの内部仕様を追うことになる
それなら最初から HTML・バリデーション・送信処理をコードで書いてしまったほうが、結果的に早く分かりやすいケースが多くあります。「ある程度まで簡単にできる」代わりに「それ以上の調整がしづらい」というトレードオフも、フォームプラグインを使わない理由の一つです。
自作フォームでやっていることは最低限
自作するといっても特別なことをしているわけではなく、フォームとして最低限必要な処理だけをシンプルに実装しています。
- フロントとバックエンドのバリデーション
- トークンを使った簡易CSRF対策
- PHPMailerなどを使ったメール送信
- 必要最低限のスパム対策
それでもプラグインを使うケースはある
もちろん、すべての案件で自作するわけではありません。以下のような条件であれば、フォームプラグインを選ぶほうが合理的です。
- 管理画面から構造自体を頻繁に変えたい
- 非エンジニアがフォーム仕様を触る
- 要件がシンプルである
- 短期案件でスピードを優先したい
まとめ
フォームプラグインを使わない理由は、以下の実務上の判断に基づいています。
- コードで管理したほうが分かりやすい
- プラグイン依存や制約を減らしたい
- 数年後の自分や他の人が触りやすい
これまでの経験から、現在はコードで直接管理する方法を基本としています。
