MW WP Form の移行先プラグイン比較 — 確認画面・データ保存・日本語対応で選ぶ

Posted at 2026-05-26

MW WP Form の移行先プラグイン比較 — 確認画面・データ保存・日本語対応で選ぶ

はじめに

WordPress でお問い合わせフォームを構築する際、長らく国産プラグインの定番だった「MW WP Form」が 2023 年 9 月に開発終了を発表してから 2 年以上が経ちました。現在は株式会社 Web の相談所がメンテナンスを引き継いでいますが、脆弱性対応中心の保守モードで、新機能追加や WordPress 最新版への動作確認は行われていません。新規採用は推奨されない状況が続いています。

この移行需要を受けて、複数のフォームプラグインが「移行先候補」として挙がっています。しかし、技術的観点からの比較記事は意外と少なく、「とりあえず Snow Monkey Forms に移行した」「Contact Form 7 + アドオンで対応している」といった選択がされがちです。本記事では、MW WP Form が満たしていた技術要件をベースに、主要 4 プラグインを評価軸で比較し、要件パターン別の推奨判断を整理します。

なお、本記事は Form Plant という WordPress フォームプラグインを開発している立場から書いています。比較対象に Form Plant を含めますが、できる限り公平な技術評価を心がけ、要件に応じて他のプラグインが適している場合はその旨を明記します。判断材料の一つとしてお読みください。

また、本記事は 無料で利用できる範囲を前提に比較を行います。 有料プランや有料プラグインの機能は、原則として評価の対象外とします (プランによって機能差が大きく、価格も変動するためです)。「追加費用なしで、どこまで MW WP Form 相当のことができるか」という視点で読んでいただければと思います。

本記事で取り上げる比較対象は次の 4 プラグインです:

Snow Monkey Forms (キタジマタカシ氏作、事実上の後継候補)
Contact Form 7 (国内最大シェア)
WPForms (海外大手)
Form Plant (筆者開発)

余談になりますが、筆者自身も MW WP Form のヘビーユーザーでした。確認画面とデータ保存が標準で使え、日本のフォーム要件にもよく適合する MW WP Form には、多数の案件で本当に助けられました。長年にわたって優れたプラグインを無償で提供し続けてくださった作者のキタジマタカシ氏には、この場を借りて感謝を伝えたいと思います。本記事は、その MW WP Form が築いてきた資産をどう次につなげるか、という視点で書いています。

MW WP Form の現状 — 3 行でおさらい

MW WP Form の開発終了については既にご存じの方が多いと思うので、要点だけ整理します。

2023 年 9 月、開発終了が発表された — 現在は株式会社 Web の相談所が脆弱性対応のみを引き継いでおり、新機能追加や WordPress 最新版での動作確認は行われていません
「今すぐ使えなくなる」わけではない — 2026 年時点でも多くのサイトで動作していますが、WordPress 本体や PHP のバージョンアップで、いつ不具合が出てもおかしくない状態です
開発者・引き継ぎ先の双方が移行を推奨 — 特に制作会社に対しては、別プラグインへの移行が明確に推奨されています

開発終了の経緯は一次情報を当たるのが確実です。開発者の発表はキタジマタカシ氏の X (@inc2734)、引き継ぎ後の保守方針は株式会社 Web の相談所で確認できます。本記事では経緯の詳細は繰り返さず、「で、結局どこに移行するのか」という移行先選定にフォーカスします。

技術的な移行判断で押さえるべきは、次の 1 点に尽きます。「今動いているサイトをすぐ止める必要はないが、新規構築では採用しない。既存サイトも計画的な移行を検討する」 — この前提で、以降の移行先比較を読み進めてください。

移行先選定の 7 つの技術評価軸

「Snow Monkey Forms に移行すれば OK」「Contact Form 7 ならアドオンで何とかなる」といった単純な判断ではなく、自分のサイトの要件と移行先プラグインの特性を照らし合わせて判断するのが移行成功の鍵になります。ここでは MW WP Form が満たしていた要件と、現代のフォーム要件を踏まえた 7 つの技術評価軸を提示します。

各軸の説明では、「どんなサイトでこの軸が重要になるか」を意識して書いていきます。すべての軸が等しく重要なわけではなく、サイトの性質によって優先度は変わります。

軸 1: 確認画面の必要性

MW WP Form の代表的な機能の一つが、入力 → 確認 → 完了の 3 段階画面遷移でした。確認画面を求める背景には、ユーザー体験上の理由 (誤送信防止) と、運用上の理由 (お問い合わせ後の電話確認を減らす) の両方があります。

確認画面を別プラグインや独自実装で補う場合、プラグイン依存関係の管理や JavaScript の保守が増えます。長期運用するサイトでは、確認画面が標準装備されているかどうかは保守コストに直結します。

この軸が重要なケース: B2B のお問い合わせフォーム、採用応募フォーム、見積もり依頼フォームなど、誤送信が業務影響を持つフォーム

軸 2: 送信データの保存と CSV エクスポート

MW WP Form は送信内容を WordPress の DB に保存し、管理画面から一覧・検索・CSV エクスポートできました。これは「メール通知だけでは見落とす」「過去のお問い合わせを後から検索したい」というニーズへの回答です。

メール通知のみの設計では、メールが届かなかったり、誤って削除した場合に送信データが失われます。DB 保存があれば、メール障害があってもデータが残るというフェイルセーフの意味もあります。

この軸が重要なケース: 月数十件以上のお問い合わせがあるサイト、お問い合わせ内容をエクセル等で集計・分析するサイト、複数の担当者でお問い合わせを共有・管理するサイト

軸 3: バリデーションの粒度

「必須かどうか」だけでなく、文字数制限、メールアドレスのダブルチェック、独自のパターンマッチ、複数フィールドの連動チェック (パスワード確認、条件付き必須など) をどこまで設定で対応できるかを示す軸です。

設定 UI で対応できないバリデーションは、すべてフックでコードを書くことになります。シンプルなお問い合わせフォームなら問題ありませんが、要件が複雑になるとコード量が増え、保守の負担が高まります。

この軸が重要なケース: 採用応募フォーム (履歴書のように複雑な項目を扱う)、見積もり依頼フォーム (条件によって必須項目が変わる)、会員登録フォーム (パスワード、メールの再入力チェックがある)

軸 4: 日本ロケール対応

郵便番号からの住所自動入力、氏名のパーツ別 (姓 / 名) バリデーション、フリガナ用のフィールド、日本の住所テンプレート (都道府県 / 市区町村 / 番地 / 建物名) などです。海外製プラグインは日本ロケールへの配慮が薄く、外部 JavaScript やフックでの対応が必要になります。

特に郵便番号自動入力は、ユーザビリティへの影響が大きい機能です。MW WP Form ユーザーの多くは何らかの形で導入していたので、移行先で再現できるかは確認しておく必要があります。

この軸が重要なケース: 日本国内のユーザーをターゲットにするサイト全般。BtoC のお問い合わせフォーム、資料請求フォーム、来店予約フォームなど

軸 5: Classic Editor 環境を維持する必要があるか

WordPress 標準は Gutenberg (ブロックエディタ) ですが、案件の都合で Classic Editor を維持しているサイトは今も多くあります。テーマや他プラグインがブロックエディタに対応していない、運用担当者の慣れで切り替えていない、などの理由です。

この軸は「フォームプラグインがブロックエディタに対応しているか」ではなく、「Classic Editor 環境でも使えるか」という方向で評価します。現代のフォームプラグインはほぼブロックエディタに対応しているので、本当の差別化軸は Classic Editor 互換の維持力にあります。

この軸が重要なケース: 旧テーマで運用している既存サイト、Classic Editor 環境を維持したい受託案件

軸 6: スパム対策の戦略

MW WP Form の時代は、reCAPTCHA だけでスパム対策が成立していました。しかし近年、Google reCAPTCHA の無料プランに月間評価回数の制限が入るなどの変化があり、単一手段に依存するスパム対策はリスクが高まっています。

現代のスパム対策は、軽量手段 (ハニーポット、送信時間バリデーション、IP レート制限、使い捨てメールドメインブロック) と外部サービス (reCAPTCHA、Cloudflare Turnstile) を組み合わせる多層防御が定石です。フォームプラグインがどこまで設定だけで対応できるか、フックでの拡張が必要かは、運用コストに大きく影響します。

この軸が重要なケース: スパム送信が現状で多いサイト、お問い合わせ件数の多い B2C サイト、Cloudflare を既に運用しているサイト (Turnstile 対応の有無が効いてくる)

軸 7: カスタマイズ拡張ポイント

PHP フック、JavaScript フック、テンプレートカスタマイズ、CSS カスタマイズなど、コードで挙動を拡張する手段の自由度を評価します。本記事で比較する 4 プラグインはすべて何らかのフック機構を持っており、「フックがあるかないか」で差は出ません。本当の評価軸は「自分が必要とする拡張パターンが、どの種類のフックで実現できるか」「フックを使ったときのコード量と保守性」になります。

例えば、サーバーサイドで動的にバリデーションを変えたい場合は PHP フックが必要です。クライアントサイドでフィールド連動やリアルタイム入力ヘルプを実装したい場合は JavaScript の拡張ポイントが必要です。両方が必要なケースもあります。

この軸が重要なケース: 標準機能を超えるカスタマイズを行う制作会社・受託開発者、自社サービスの特殊な業務フローに合わせたフォームを構築したいケース

主要 4 プラグインの技術評価

ここからは比較対象の 4 プラグインを、機能・制約・想定読者の観点で評価していきます。

Snow Monkey Forms

開発者はキタジマタカシ氏 (株式会社モンキーレンチ) で、MW WP Form と同じ作者によるブロックエディタ専用のフォームプラグインです。2020 年 4 月の初版リリース以降、定期的にメジャーアップデートが続いており、現在 (2026 年 5 月時点) は v9 系まで進んでいます。ライセンスは無料です。

強み

確認画面、完了画面、プログレストラッカーが標準装備されていて、設定でオン/オフを切り替えるだけで動作する
ブロックエディタに完全対応しており、視覚的にフォームを構築できる
フックや DOM イベントによる一定のカスタマイズ手段が用意されている (ただしバリデーションルールの追加はできない。詳細は後述)
開発が活発で、メンテナンスの心配が少ない

制約 (技術面)

設定 UI 上でのバリデーションは「必須」「メール形式」などの組み込みルールのみ — 文字数チェック、メール形式以外のパターンチェック、独自ルールは設定できません。これは開発者本人がリリース時のブログで明言しています (開発者ブログ)。さらに、バリデーションルール自体をコードで追加するための PHP 拡張ポイントも公開されていません (既存ルールのエラー文言を書き換えるフックはあります)。独自のバリデーションが必要な要件には向かない設計です
送信データを DB に保存する機能がない — フォーム送信内容はメール送信のみで、WordPress 管理画面から過去の送信を一覧する仕組みはありません
Classic Editor 非対応 — ブロックエディタ専用のため、Classic Editor を維持しているサイトでは使えません
入力・確認・完了が同一 URL — JavaScript で画面切り替えを行う設計のため、コンバージョン計測には Google Tag Manager 等で工夫が必要です
郵便番号自動入力は標準装備されていない — YubinBango などの外部 JavaScript と連携する形になります

想定読者

シンプルなお問い合わせフォームで十分、ブロックエディタ環境で開発しており、送信データの DB 保存が不要、というケースに最適です。MW WP Form と同じ作者の安心感もあり、「定番からの自然な乗り換え先」という位置づけになります。

Contact Form 7

Takayuki Miyoshi 氏が開発する、世界的に高いシェアを持つフォームプラグインで、WordPress.org でのインストール数は 500 万を超えます。ライセンスは無料です。

強み

圧倒的なインストール数による情報量とサポート記事の豊富さ — 何かトラブルがあっても日本語の解決情報がすぐ見つかります
ショートコードベースで、固定ページ・投稿・ウィジェット・カスタムテーマファイルなど、どこにでも自由に配置できます
多数のサードパーティアドオンによるエコシステム — 確認画面、データ保存、決済連携などをアドオンで補完できます

制約 (技術面)

確認画面が標準装備されていない — Multi-Step Forms などの別プラグイン、または独自 JavaScript 実装で対応する形になります
送信データの DB 保存機能が標準装備されていない — Flamingo などのアドオンで対応するのが定番です
郵便番号自動入力も標準装備されていない — zipaddr-jp などの外部 JavaScript との連携が必要です

想定読者

情報量を重視する開発者、「フォーム本体は最小限、必要に応じてアドオンで補完」というスタイルに合う方に向いています。

なお、Contact Form 7 のシンプル設計は美徳でもあります。「フォーム本体は最小限」という思想は今も多くの開発者に支持されており、本記事は MW WP Form 移行という特定の文脈での比較に限定していることを念のため明記しておきます。

WPForms

米国 Awesome Motive 社が開発する世界的に大きなシェアを持つフォームプラグインで、無料版 (WPForms Lite) と有料版があります。インストール数は無料版で 300 万超です。

強み

ドラッグ&ドロップで直感的に構築できるフォームビルダー
有料版は決済連携 (Stripe / PayPal)、条件分岐、スプレッドシート連携、メールマーケティングツール連携など多機能
商用サポートが提供されている

制約 (技術面)

無料版では送信データの管理画面が使えない — 送信内容はメール通知のみで、WordPress 管理画面から過去の送信を一覧する Entries 機能は有料版限定です。MW WP Form の「データを管理画面で確認できる」体験を求める場合、無料版では実現できません
日本ロケール対応は弱い — 郵便番号自動入力、氏名のパーツ別 (姓/名) バリデーション、フリガナ用フィールドなどは標準装備されていません
ライセンス費用が継続的に発生 — 有料版は年額 $49.5 (Basic) から $299.5 (Elite) まで 4 段階。一番安い Basic プランでも 1 サイトのみの利用制限があるため、複数サイトを運用する制作会社は Plus プラン以上が必要になります
公式サイトとサポートは英語中心 — プラグイン UI 自体は日本語に対応していますが、ドキュメントや有料サポートは英語が前提です

想定読者

予算がある中規模以上のサイト、海外向けのフォーム需要が多いサイト、決済連携などの拡張機能を必要とするケース、商用サポートを必須とする企業。

Form Plant

筆者 (Sofplant) が開発するフォームプラグインで、2026 年初頭にリリースしました。本記事執筆時点の最新版は v1.1.1 です。ライセンスは無料です。

強み

確認画面、送信データ保存、CSV エクスポートがすべて標準装備 — MW WP Form の代表的な機能がそのまま再現できます
多層スパム対策が標準装備 — ハニーポット、送信時間バリデーション、IP レート制限、使い捨てメールドメインのブロック、Google reCAPTCHA (v2 / v3)、Cloudflare Turnstile の 6 種類を組み合わせ可能。reCAPTCHA や Turnstile のアカウント設定なしでも、軽量な対策だけで動かせます
日本ロケール対応が標準装備 — 郵便番号自動入力 (zipcloud API)、氏名のパーツ別バリデーション、住所テンプレート (日本 / 国際) などが設定 UI から利用可能
JavaScript フック API — window.fplant.addValidator() によるバリデーター登録 API と、フォームのライフサイクルイベント (fplant:init, fplant:beforeSubmit, fplant:success 等) を提供
ブロックエディタとショートコードの両方に対応 — Classic Editor 環境でも使用可能
iframe / JavaScript による外部サイト埋め込み — WordPress サイト以外のページ (別ドメインの LP、ヘッドレス CMS で構築されたサイト、静的 HTML サイトなど) にも、同じフォーム設定で設置できます。フォーム管理は WordPress 側で一元化したまま、出力先は自由に選べる構成です

制約 (技術面)

リリースから間もなく、ネット上の情報がまだ少ない — Contact Form 7 や Snow Monkey Forms のような実績のあるプラグインと比べると、トラブル時に検索して出てくる解説記事や Q&A はまだ限られています。公式ドキュメントは整備されていますが、「検索すれば何か見つかる」安心感を重視する場合は、この点を踏まえておく必要があります

想定読者

MW WP Form と同等の機能セット (詳細バリデーション + 確認画面 + データ保存 + 日本ロケール対応) を無料で確保したい方、Classic Editor 環境を含めて統一的に運用したい開発者に向いています。

機能カバレッジ比較表

ここまでの 4 プラグインの評価をマトリクス形式で整理します。一目で各プラグインの特性を把握するのに使ってください。

評価軸	MW WP Form	Snow Monkey Forms	Contact Form 7	WPForms (無料版)	Form Plant
確認画面	◯	◯	△	✗	◯
送信データ保存	◯	✗	△	✗	◯
詳細バリデーション (文字数等)	◯	✗	△	✗	◯
郵便番号自動入力	△	△	△	✗	◯
Classic Editor 環境での動作	◯	✗	◯	◯	◯
多層スパム対策	△	△	△	△	◯

凡例:

◯ 標準装備 — 設定 UI からそのまま利用可能
△ 拡張で実現可能 — 別プラグイン、アドオン、外部 JavaScript、またはフックでのコード追加で実現可能
✗ 実現困難 — 標準・拡張のいずれでも実現が難しく、公式に推奨される手段がない

この表は「無料で使える範囲」での評価です。 WPForms に✗が多めに見えますが、これは無料版 (WPForms Lite) を評価しているためで、WPForms 自体の優劣を示すものではありません。WPForms は有料版 (WPForms Pro) を前提とした製品設計で、有料版では確認画面や送信データ保存などに対応します。本記事は「追加費用なしでどこまでできるか」を比較軸にしているため、表では無料版の範囲で揃えて評価しています。

なお、本表には「ブロックエディタ対応」「フック拡張機構の有無」を含めていません。これらは現代の WordPress プラグインとしてはほぼ前提条件であり (MW WP Form を除けばブロックエディタは全プラグイン対応、フックも全プラグインが何らかの機構を提供)、表で差別化として並べる意味が薄いためです。フックの種類や使いやすさについては前章の各プラグイン解説をご参照ください。

要件パターン別の推奨判断

ここまでの評価をもとに、典型的な要件パターンごとの推奨判断を整理します。自分のサイトに最も近いパターンを起点に検討してください。複数のパターンに該当する場合は、最も優先度の高い要件を軸に判断するのが現実的です。

パターンA: シンプルなお問い合わせフォームで十分

フィールド数は 5 個程度、必須チェックだけで OK、送信データの DB 保存は不要。メール通知が確実に届けばよい、というケースです。

推奨: Snow Monkey Forms

MW WP Form と同じ作者によるプラグインで、運用感覚も近く、ブロックエディタで素早く構築できます。確認画面と完了画面も標準装備で、サイト訪問者への安心感も得られます。

パターンB: 詳細バリデーション + データ保存 + 日本ロケール対応が必要

文字数チェック、メールのダブルチェック、独自バリデーション、CSV エクスポートでの集計、郵便番号自動入力など、MW WP Form で活用していた機能を一通り再現したいケースです。

推奨: Form Plant

Form Plant は設定 UI から詳細バリデーション、データ保存、CSV エクスポート、郵便番号自動入力までを標準で対応しています。無料の範囲で MW WP Form の機能セットを一通り再現したい場合、現状では選択肢は限られますが、Form Plant はその要件を多くカバーします。なお、有料プランを許容できるなら WPForms Pro なども同等の機能範囲をカバーできますが、日本ロケール対応は有料版でも標準装備されていない点には注意が必要です。

パターンC: Classic Editor 環境を維持したい

既存サイトで Gutenberg に切り替えておらず、運用担当者の慣れやテーマ・他プラグインの都合で Classic Editor を継続したいケースです。

推奨: Form Plant、Contact Form 7 + アドオン

Snow Monkey Forms は Gutenberg 必須のため、このパターンでは候補から外れます。Form Plant はショートコードと Gutenberg ブロックの両方に対応しており、Classic Editor 環境でも問題なく動作します。Contact Form 7 もショートコードベースで Classic Editor 環境に強いですが、確認画面とデータ保存はアドオンで補う必要があります。

パターンD: シェア・情報量を最優先

検索すれば情報が見つかる安心感を最優先、サードパーティアドオンの選択肢が豊富、社内・外注先にも触ったことがある人が多い、という運用観点を重視するケースです。

推奨: Contact Form 7 + アドオン構成

Contact Form 7 は世界的に高いシェアを持つフォームプラグインで、日本語の解決情報も豊富です。確認画面 (Multi-Step Forms など)、データ保存 (Flamingo) はアドオンで対応する形になりますが、それぞれ実績のあるアドオンが揃っており、組み合わせれば MW WP Form に近い運用感を実現できます。

要件パターンに該当しないケースも当然あります。複数の要件が混在する場合や、特殊な業務フローに合わせる場合は、前章の各プラグインの強み・制約と、比較表を見比べて、自分のサイトに合うプラグインを判断してください。次の章では、移行作業を始める段階で実装観点で押さえておくべきヒントを整理します。

実装観点での移行のヒント

ここまでで「どのプラグインを選ぶか」の判断材料を整理してきました。本章では一歩進んで、実際に移行作業を始める段階で押さえておくべき実装観点のヒントを 3 つのテーマで整理します。

MW WP Form のバリデーションをどう移植するか

MW WP Form は文字数チェック、形式チェック、独自バリデーションが豊富で、これらをカスタマイズしていた現場も多いはずです。移行先で同等のバリデーションを再現する主な実装箇所は、いずれのプラグインも サーバーサイド (PHP フック) になります。クライアントサイドは UX 改善のための補助であり、セキュリティ上の検証は必ず PHP 側で行う必要があるためです (JavaScript は DevTools で容易にバイパスされます)。

まずは PHP フックでの実装例を見てみましょう。題材は「特定ドメインのメールアドレスのみ許可する」という典型的なカスタムバリデーションです。

ただし、ここで 1 点注意があります。Snow Monkey Forms は、バリデーションルール自体を追加するための PHP フックを公開していません。 バリデーションは「必須」「メール形式」などの組み込みルールに限定されており、「特定ドメインのみ許可」のような独自ルールをコードで追加する拡張ポイントは用意されていません (既存ルールのエラー文言を書き換えるフックはあります)。これはプラグインの設計思想であり、本記事で繰り返し述べてきた「Snow Monkey Forms はシンプルなお問い合わせフォームに最適」という位置づけとも一致します。サーバーサイドでのカスタムバリデーションが必要な要件では、Snow Monkey Forms はそもそも選択肢に入らないため、以下では Contact Form 7 と Form Plant の 2 プラグインの例を見ていきます。

Contact Form 7 の PHP フック例 (wpcf7_validate_<type> で型別バリデーションを拡張):

add_filter( 'wpcf7_validate_email*', function( $result, $tag ) {
    $value = isset( $_POST[$tag->name] ) ? trim( $_POST[$tag->name] ) : '';
    if ( ! empty( $value ) && ! preg_match( '/@example\.com$/', $value ) ) {
        $result->invalidate( $tag, '@example.com ドメインのみ使用できます' );
    }
    return $result;
}, 10, 2 );

Form Plant の PHP フック例 (フィールド名指定で完全上書き):

add_filter( 'fplant_validate_field_email', function( $error, $field, $value, $data, $form_id ) {
    if ( ! empty( $value ) && ! preg_match( '/@example\.com$/', $value ) ) {
        return '@example.com ドメインのみ使用できます';
    }
    return $error;
}, 10, 5 );

Contact Form 7 と Form Plant は、いずれも PHP フックを通じてサーバーサイドのバリデーションを自由に拡張できます。設計の細部に違いはあり、Form Plant はフィールド名指定 (fplant_validate_field_{$field_name}) とフィールドタイプ指定 (fplant_validate_field_type_{$field_type}) の両方を提供し、エラーメッセージのカスタマイズも個別フックで細かく分かれていますが、ここはケースバイケースで「自分の用途で使いやすい設計かどうか」を確認すれば十分でしょう。一方 Snow Monkey Forms は、前述の通りバリデーションルールの追加には対応せず、エラー文言のカスタマイズに限られます。

クライアントサイドでのバリデーション拡張も行いたい場合:

MW WP Form ユーザーの中には、JavaScript で即時バリデーションを実装していた方もいるでしょう。この用途では、3 プラグインのアプローチが大きく異なります。

Snow Monkey Forms: smf.beforesubmit などの DOM カスタムイベントが提供されており、addEventListener でフォーム送信前に介入できます。ただしバリデーター登録専用 API はないため、送信前イベントをフックして自前で全フィールドを検査し、エラー時は preventDefault() で送信を止める、という実装になります
Contact Form 7: wpcf7submit 等の DOM イベントが提供されています。位置づけは Snow Monkey Forms と同様で、バリデーター登録 API は提供されていません
Form Plant: バリデーター登録 API (window.fplant.addValidator()) と DOM カスタムイベント (fplant:validateField、cancelable) の両方を提供しています

Form Plant の JS バリデーター登録 API は、次のように使えます (フォームの name="email" フィールドにカスタムバリデーターを追加する例):

window.fplant.addValidator('email', function(value, fieldName, formData) {
    if (value && !value.endsWith('@example.com')) {
        return '@example.com ドメインのみ使用できます'; // エラーメッセージで失敗
    }
    return ''; // 空文字列で成功
});

第3引数の formData にはフォーム全体の入力値が渡るため、パスワード確認の一致チェックのような複数フィールドを連動させたバリデーションも宣言的に書けます。

他プラグインで同等のことを実現する場合、DOM イベントをフックしてフォーム全体を JavaScript で検査するコードを自前で書くことになり、コード量と保守コストが増えます。複雑なフォームでクライアント側にも踏み込んだバリデーションを行いたい場合は、この設計差が実装コストに効いてきます。

なお、Form Plant の JS バリデーション API はショートコード経由でフォームを設置した場合のみ利用可能です。iframe / JavaScript 埋め込みでは利用できないので注意してください (この場合は PHP フックでのサーバーサイドバリデーションに統一する形になります)。

郵便番号自動入力の移植

MW WP Form を日本国内向けサイトで運用していた場合、郵便番号自動入力を zipaddr-jp などの外部 JavaScript と組み合わせて実現していたケースが多いはずです。移行先での選択肢を整理します。

Snow Monkey Forms / Contact Form 7: 標準では郵便番号自動入力に対応していないため、外部 JavaScript (YubinBango / zipaddr-jp) を引き続き利用する形になります。MW WP Form で運用していた頃と同様の対応が必要です
Form Plant: 「郵便番号」「住所 (日本)」フィールドを配置するだけで、zipcloud API による自動入力が動作します。外部 JavaScript の組み込みや設定は不要です

実装の手数を減らしたい場合や、運用担当者が JavaScript を触れない環境では、標準装備で動く Form Plant のアプローチが楽です。一方、既存の zipaddr-jp 連携を活かしたいケースや、独自のジオコーディング処理を組み込んでいる場合は、外部 JavaScript を継続利用できる Snow Monkey Forms や Contact Form 7 の方が移植コストが低くなります。

フォームの設置場所の自由度

MW WP Form は [mwform_formkey key="N"] のショートコードに加えて、テーマの PHP テンプレートファイル内に直接コードを書いてフォームを出力することもできました。「投稿詳細ページの下部に必ずお問い合わせフォームを表示する」といった、テーマ側で制御する設置方法を使っていた場合は、移行先の対応状況に注意が必要です。移行先で「どこからフォームを出力できるか」は、プラグインごとに差があります。

各プラグインの対応状況を整理します。

Snow Monkey Forms: フォームの設置はブロックエディタ専用で、公式のショートコードは用意されていません。テーマの PHP テンプレートファイルへの直接埋め込みも公式には想定されていないため、投稿テンプレートにフォームを固定で出したいケースなど、コンテンツ本文以外の場所に設置したい場合は回避策が必要になります
Contact Form 7: ショートコード ([contact-form-7 ...]) で設置でき、do_shortcode() 経由でテーマの PHP ファイルからも出力できます。MW WP Form からの置き換え時は、ショートコード文字列を機械的に置換するだけで済むケースもあります
Form Plant: ショートコード ([fplant id="..."]) 、Gutenberg ブロックに加え、テーマの PHP ファイルからの出力にも対応しています。さらに iframe / JavaScript による外部サイトへの埋め込みもできるため、設置場所の自由度は高めです

テーマ側でフォーム設置を制御している既存サイトを移行する場合、この「どこから出力できるか」が移行のしやすさを左右します。逆に、すべて固定ページ・投稿本文にショートコードで設置しているシンプルな構成なら、この点はあまり気にしなくて問題ありません。

加えて、Form Plant では WordPress サイト以外のページにフォームを埋め込むことも可能です。例えば、メインサイトを Next.js やヘッドレス CMS で構築していて、お問い合わせフォームだけ WordPress 側で管理したいというケースでは、WordPress 側で作成したフォームを iframe または JavaScript スニペットで外部サイトに埋め込めます。MW WP Form では実現できなかったパターンですが、移行を機にサイト構成の柔軟性を上げるという観点では検討する価値があります。

参考までに、Form Plant が対応する 4 つの設置方法を図にすると次のようになります。フォームの管理は WordPress 側で一元化したまま、出力先を状況に応じて選べる構成です。

まとめ

MW WP Form 移行先の選定は、「どのプラグインが優れているか」ではなく「自分のサイトの技術要件にどれが合うか」で判断するのが本質です。本記事で紹介した 7 つの評価軸を要件と照らし合わせ、要件パターン別の推奨判断を出発点に検討してみてください。

要点を再整理すると、次のようになります。

シンプルなお問い合わせフォームで十分なら、MW WP Form と同じ作者による Snow Monkey Forms が運用感覚も近く、自然な移行先です
詳細バリデーション、データ保存、日本ロケール対応 (郵便番号、氏名のパーツ別など) を MW WP Form と同等に確保したい場合、現時点で無料の範囲で対応するプラグインは限られます。本記事の比較対象では Form Plant が該当します
Classic Editor 環境を維持したい場合、Snow Monkey Forms は候補から外れます。Form Plant または Contact Form 7 + アドオン構成が選択肢になります
シェアと情報量を最優先するなら、Contact Form 7 + アドオン構成が安心です

開発が脆弱性対応のみとなった MW WP Form を急いで止める必要はありませんが、「いつかは移行する」前提で技術的な準備を進めておくのが妥当な時期です。実装観点では、PHP フックでのバリデーション再現が、いずれのプラグインでも中心になります。クライアント側の即時バリデーションや、WordPress 以外への埋め込みなど、移行を機に新しくできることも検討範囲に入れると、判断の幅が広がります。

本記事が、移行検討の判断材料の一つになれば幸いです。質問・指摘・追加情報があれば、コメント欄でお待ちしています。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up