Contact Form 7 PayPal Stripe Add-onの脆弱性と最新版への更新手順
Contact Form 7 PayPal & Stripe Add-on のバージョン 2.4.9 以前には、PayPal 決済を本来の支払い金額や通貨と無関係に「支払い完了」として通過させてしまう脆弱性がある。最新版へ更新すれば対処でき、放置すると注文だけが成立して金銭が回収できない重大なリスクを抱えるため、至急確認する必要がある。
Contact Form 7 用 PayPal & Stripe Add-on にどんな脆弱性があるのか
この脆弱性は CVE-2026-9189 として採番されており、攻撃者が PayPal の正当な通知（IPN）に見せかけたリクエストを送信することで、実際の支払い金額や通貨、受取人の一致をまったく検証せずに「支払い済み」とマークできてしまう。プラグインは PayPal からの通知の署名検証は行っていたものの、肝心の取引金額・通貨コード・受取人メールアドレスの突き合わせを実装していなかったため、ゼロまたは極端に低い金額の注文が成立してしまう。
具体的には、フォーム送信時に生成される注文レコードに対して、PayPal のトランザクション ID と支払いステータスのみが照合され、注文時に設定された金額と実際に PayPal 上で決済された金額の比較が行われない。このため、正規のトランザクション ID を悪用、あるいは偽装した通知に対してプラグインが「正当な支払い」と誤認する状況が生まれていた。
PayPal 通知の受信 → 署名検証のみ実施 → 金額・通貨・受取人の検証なし → 0円でも「支払い完了」
PayPal 通知の受信 → 署名検証 → 金額・通貨・受取人を注文情報と突合 → 一致時のみ「支払い完了」
上の図が示す通り、修正後は金額・通貨・受取人の3点を必ず比較するロジックが追加されている。この検証が欠けていたことが、支払いバイパスを成立させる根本原因だった。
どのバージョンが影響を受けるのか
Contact Form 7 PayPal & Stripe Add-on のバージョン 2.4.9 以下が影響を受ける。2026年6月中旬時点で修正済みのバージョンがリリースされており、2.5.0 以降に更新すればこの脆弱性は解消される。
自分のサイトでどのバージョンを使用しているかは、WordPress 管理画面の「プラグイン」→「インストール済みプラグイン」一覧で確認できる。該当プラグインが有効化されている場合は、バージョン番号を直ちにチェックしておきたい。
最新版へ更新する具体的な手順
更新前にサイト全体のバックアップを取得しておくとなお安心だ。更新が完了したら、プラグイン一覧でバージョンが 2.5.0 以降に切り替わっていることを必ず確認する。
更新がすぐに実行できない場合の対処
何らかの理由で即時更新が難しい場合は、一時的に PayPal 決済機能を停止し、フォームそのものを別の決済手段に切り替えるなどの対策が有効だ。とはいえ、あくまで暫定的な措置であり、根本対策は最新版への更新以外にない。
プラグインを無効化すれば脆弱性は発動しなくなるが、フォーム経由の PayPal 決済も一切使えなくなる。その間に代替として WooCommerce の標準決済や別のフォームプラグインへ移行する判断も必要になるだろう。
よくある質問
Stripe 決済にも同じ問題はあるのか
この脆弱性は PayPal の通知処理に起因する問題であり、Stripe 側の処理ロジックには同様の不備は確認されていない。ただし、セキュリティ修正の一環で Stripe 関連のコードにも改善が加えられているため、プラグイン全体を最新に保つのが賢明だ。
すでに不正な取引が行われていないか調べる方法はあるか
PayPal の取引履歴と Contact Form 7 の送信ログを突き合わせ、注文金額と実際の決済金額が一致しているかを手動で検証する必要がある。プラグイン自体に取引監査の機能はないため、自社の売上レポートと PayPal の管理画面を定期的に照合する習慣をつけることを推奨する。
自動更新を有効にしていれば問題は起きなかったのか
自動更新が有効でも、WordPress.org のプラグインディレクトリに修正版が配信されるタイミング次第では数時間から数日のラグが生じる。さらに、サイトの更新設定によってはメジャーアップデートが自動適用されないケースもあるため、手動での確認を怠らないほうが安全だ。
このプラグインを使い続けるリスクは他にもあるか
Contact Form 7 のアドオンは多数の開発者によって提供されており、サポートや更新の頻度はプラグインごとにまちまちだ。決済を扱う以上、常に開発が継続され、すみやかにセキュリティパッチが提供されるプラグインを選ぶことが大前提となる。
この記事のポイント
- Contact Form 7 PayPal & Stripe Add-on 2.4.9 以前に支払いバイパスの脆弱性がある
- PayPal 通知の金額・通貨・受取人を検証しないため 0 円でも「支払い完了」になる
- 修正済みの最新版（2.5.0 以降）に更新すれば問題は解消される
- 更新前にバックアップを取り、バージョン番号を必ず確認する
- 決済系プラグインは常に最新を保ち、定期的なログ照合を習慣化する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Contact Form 7のPDF出力で条件分岐ショートコードが効かない時の直し方
Contact Form 7 から出力する PDF に条件分岐のショートコード（[if] や [hide-*] など）が反映されないとき、最も多い原因は Send PDF for Contact Form 7 プラグインが、Conditional Fields のような他プラグインのショートコードを PDF 生成時に評価しないことだ。この問題は、PDF テンプレート内で直接条件分岐を記述する代わりに [_mail_body] タグを使ってメール本文を丸ごと流し込むか、出力直前にショートコードを再評価するフィルターフックで解決できる
なぜ PDF 出力で条件分岐ショートコードが効かなくなるのか
Send PDF for Contact Form 7 は、フォーム送信時に生成されたデータを PDF テンプレートに差し込んで出力する。このとき、[text-123] のような Contact Form 7 の標準タグは正しく展開されるが、Conditional Fields が提供する [group] や [if] といった条件分岐用のショートコードは、PDF 生成のコンテキストでは実行されないことが多い
理由は主に2つある。ひとつは、これらのショートコードが WordPress の do_shortcode フックに登録されていても、PDF プラグインがテンプレートを処理する段階では、フォームの送信データや条件判定に必要なコンテキストが不足しているケースだ。もうひとつは、Conditional Fields のショートコードが「メール送信時」にのみ動作するように設計されており、PDF 作成時にはそもそも処理の対象外になっているパターンだ
[if kosten-an-arbeitgeber]この見積は雇用主向けです[/if]
※条件にかかわらずショートコードがそのまま表示される
この見積は雇用主向けです
※条件に合致したテキストだけが PDF に出力される
このデモのように、PDF テンプレート内に [if] や [hide-*] を直書きしても、Send PDF 側で解釈されずに終わってしまう。以前は偶然動いていたとしても、プラグインのバージョンアップで処理順序が変わると即座に壊れる原因になる
プラグイン更新後に突然動かなくなったのはなぜか
「以前は PDF で条件分岐が効いていたのに、更新したら動かなくなった」という声は非常に多い。これは、Send PDF for Contact Form 7 または Conditional Fields for Contact Form 7 の内部実装が変更され、テンプレートの評価タイミングやショートコードの登録順が変わったためだ
具体的には、Send PDF プラグインの旧バージョンでは、PDF テンプレート全体を do_shortcode で処理していたが、パフォーマンスやセキュリティの改善に伴ってその処理が省略されたり、独自の置換処理に切り替わったりすることがある。結果として、Conditional Fields のショートコードが一切処理されなくなる
また、Conditional Fields 側のアップデートで、[if] タグの内部実装が変わり、PDF 出力時に必要なデータが揃わなくなった可能性もある。どちらにせよ、PDF テンプレート内で直接条件分岐を記述する方式は、プラグインのバージョンに依存しやすく、根本的に不安定と言える
[_mail_body] タグでメール本文をそのまま PDF に流し込む
![[_mail_body] タグでメール本文をそのまま PDF に流し込む](https://www.aandgweb.co.jp/wp-content/uploads/2026/06/2026-06-19_pain_001_h2_003.webp)
最も簡単で安全な解決策は、PDF テンプレート内に [_mail_body] を記述することだ。このタグは、Contact Form 7 が送信する「メール本文」をそのまま PDF 内に差し込む。メール本文のほうでは、Conditional Fields の条件分岐が正常に評価されているため、結果的に PDF にも正しい内容が出力される
この方法を使えば、Conditional Fields に限らず、メール本文で動作するあらゆるショートコードが PDF に反映される。ただし、PDF 独自のレイアウトや追加情報（会社ロゴや利用者に合わせた細かな差し込み）が必要な場合は、[_mail_body] の前後に固定の HTML を加えることで対応できる
注意点として、[_mail_body] はメール本文をそのままコピーするため、メール用の改行やスタイルが PDF に持ち込まれる。どうしてもレイアウトを細かく制御したい場合は、次に紹介するフィルターフックを使った方法を選ぶ
functions.php で PDF 生成前に条件分岐を再評価させる
Send PDF for Contact Form 7 には、PDF の最終的な内容を上書きできるフィルターフックが用意されている。これを利用すれば、テンプレート内の [if] や [hide-*] を手動で再評価できる。テーマの functions.php に次のようなコードを追加すると、Conditional Fields のショートコードが PDF 出力時に正しく展開される
add_filter( 'cf7_send_pdf_template_html', function( $html, $form_id ) {
// フォームの送信データを取得し、ショートコードを再評価する
$submission = WPCF7_Submission::get_instance();
if ( $submission ) {
$posted_data = $submission->get_posted_data();
// 一時的に do_shortcode を再度適用
$html = do_shortcode( $html );
}
return $html;
}, 10, 2 );このコードは、PDF テンプレートが組み立てられた直後に do_shortcode を実行し、[if] や [group] といったショートコードをその場で評価する。投稿データが揃っているため、Conditional Fields の条件判定も正しく動く
ただし、[hide-*] のように独自のショートコードを使っている場合は、そのショートコードがどのプラグインで定義されているかを確認し、該当のプラグインが有効でなければ動作しない。もし自作のショートコードであれば、あらかじめ add_shortcode で登録しておく必要がある
さらに、Send PDF プラグインのバージョンによってはフック名が異なる可能性もあるため、公式ドキュメントを参照し、cf7_send_pdf_template_html の部分を適切なフックに置き換える。このフックが利用できない場合は、wpcf7_before_send_mail などのアクションを使って PDF 生成前にデータを補完する方法もある
よくある質問
[_mail_body] を使うとメールの HTML タグがそのまま PDF に出てしまうのでは？
はい、メールフォーマットが HTML の場合、その HTML が PDF に適用される。多くは問題にならないが、シンプルなテキスト PDF を望むなら、メール設定を「テキスト形式」に切り替えるか、フィルターフックで HTML タグを strip_tags で除去するといった工夫が必要になる
Conditional Fields の [group] ショートコードも [_mail_body] で有効になるのか？
なる。[_mail_body] は、メール送信時に CF7 が最終的に組み立てた本文をそのまま埋め込むため、[group] の条件判定もすでに解決された状態で出力される
functions.php にコードを追加しても PDF が変わらないのはなぜ？
フック名が正しいか、また対象のショートコードが本当に do_shortcode で評価可能な形式かを確認する。Conditional Fields の [if] が内部で別のロジックを使っているレアケースでは、CF7 のメールテンプレート用のフィルター（wpcf7_mail_components など）を利用してメール本文を直接 PDF に渡すほうが確実だ
独自の [hide-*] ショートコードを PDF で動かすにはどうすればいい？
該当のショートコードを定義しているコードがテーマの functions.php にあるなら、そのまま do_shortcode で評価される。もし別のプラグインに依存しているのであれば、そのプラグインが常に有効でなければならない。動作が不安定な場合は、[_mail_body] 方式に切り替えるのが無難だ
この記事のポイント
- PDF テンプレート内で [if] や [hide-*] が効かないのは、Send PDF がそれらのショートコードを処理しないため
- [_mail_body] タグを使えば、メール本文ですでに展開された条件分岐結果をそのまま PDF に流し込める
- functions.php のフックで do_shortcode を再実行すれば、PDF 出力直前に任意のショートコードを動かせる
- プラグイン更新後に動かなくなったのは、ショートコード処理のタイミングが変わったのが原因
- 安定運用には[_mail_body]方式を推奨。細かいレイアウトが必要ならフィルターフック方式を使う
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Contact Form 7でスパムメールが大量に届く時の根本対策
Contact Form 7から件名や本文が空、または広告だけのスパムメールが大量に届くようになった状態は、ハニーポット（honeypot）と呼ばれる手法やシンプルな送信条件の制限を組み合わせることで、高い精度でブロックできる。
なぜContact Form 7にスパムが届くのか
お問い合わせフォームを設置したばかりのサイトは、公開直後から自動巡回するスパムボットの標的になる。ボットはPHPで生成されたフォームの構造を解析し、name属性やclass名を把握したうえで、迷惑メールの配信やSEO用の被リンク売り込みなどを自動送信する。Contact Form 7は世界中で使われているため、ボット側も「どのフィールドに何を入れれば送信が通るか」を熟知している。そのため、標準の状態ではほとんどのボットが素通りしてしまう。
ボットが大量のスパムを送り込むことによって、メールサーバーの評判低下や共用サーバーのリソース浪費、管理用メールアドレスのブラックリスト入りといった二次被害が発生する可能性がある。件名や本文が空に近いメールが届くときは、すでにボットによる自動送信が常態化しているとみてよい。
このデモは、対策の有無でスパムの到達状況がどう変わるかを示したイメージだ。対策を入れない限り、ボットはフォームの構造を正確に読んで送信を成功させてしまう。
ハニーポットでボットを静かにブロックする方法
ハニーポット（honeypot）とは、人間には見えずボットだけが反応する「罠」のフィールドをフォームに仕込む対策を指す。reCAPTCHAのようにユーザーに手間をかけず、Ajaxの競合リスクも低いため、Contact Form 7との相性が非常によい。
CSSで見えないチェックボックスを設置する
ボットは画面に表示されるかどうかを判断せず、HTMLソース内のすべてのフィールドを機械的に入力しようとする性質を持つ。この行動を利用し、人間には表示されないチェックボックスをフォームに追加する。チェックボックスにチェックが入った状態で送信された場合は、ボットとみなして送信を破棄する、という仕組みだ。
参考までに、公式のContact Form 7は、独自の同意チェックボックスであるacceptance（承諾）タグに対して invert default:on という属性をサポートしている。これは「デフォルトでチェックが入っており、人間だけが外せる」という逆転ロジックを作れる機能だ。ボットはチェックを外す操作を行わないため、罠として機能する。
ただし、acceptanceタグを使う方法は、実際にはCSSでフォーム項目をサイト上で見えなくする処理と組み合わせて使う必要がある。そうしないと、サイトを訪れた人間が混乱する原因になるためだ。
この手順ではCSSで視覚的に完全に隠すため、サイト訪問者はこのチェックボックスを一切意識せずに送信できる。一方、ソースコードを解析して全フィールドを埋めようとするボットは、デフォルトでオンになっているチェックを外さないまま送信するため、Contact Form 7のバリデーションでエラー扱いとなりメールが飛ばない。
acceptanceタグのロジックに過度に依存しない
acceptanceの逆転ロジックは簡易なボットに対しては有効だが、高度なボットはチェックボックスの状態を操作できるケースも報告されている。また、CSSを解析してスタイルを操作するスクリプトには、非表示の項目を見抜かれてしまう可能性もある。そのため、ハニーポットはあくまで一次フィルターと捉え、次の追加対策と組み合わせることが現実的な防御線だ。
reCAPTCHA v3でユーザー負荷をかけずに判別する
Contact Form 7はGoogle reCAPTCHA v3のインテグレーションを公式にサポートしている。reCAPTCHA v3は「私はロボットではありません」のチェックボックスや画像選択のような操作をユーザーに一切求めず、ページ滞在中のマウスの動きやスクロールといった行動データをもとにスコアリングし、スパムの可能性が高い送信をブロックする仕組みだ。
設定はGoogle reCAPTCHAの管理画面でサイトキーとシークレットキーを取得し、WordPress管理画面の「Contact」→「Integration」からreCAPTCHAの項目にキーを入力するだけで完了する。v2の「チェックボックス方式」は一部の環境でAjax送信との競合を起こすことがあるが、v3はその心配が少ない。フォームに直接ウィジェットが表示されないため、デザインを損なわない利点もある。
このフローは、reCAPTCHA v3導入の全体像を示したものだ。v2と異なり、Widgetの操作ステップが存在しないため、サイトの表示速度やユーザー体験への影響を最小限に抑えつつ、高精度なボット検知を実現できる。
メール本文に日本語必須ルールを追加する
海外から大量に届くスパムの多くは、英語や中国語、あるいは記号だけで構成されている。日本語圏のサイトであれば、送信内容に日本語が含まれていることを必須条件にすると、ボットによる自動送信の大半を止められる。Contact Form 7には、特定の文字種を含んでいるかどうかを検証する正規表現（Regex）の機能は標準で備わっていないが、無料の専用プラグインで補うか、functions.phpにフィルターフックを追加して実装できる。
具体的には、wpcf7_validate_text* や wpcf7_validate_textarea* といったバリデーションフックを使い、本文フィールドにひらがな・カタカナ・漢字のいずれかが1文字でも含まれているかをPHPの正規表現でチェックする。条件を満たさない場合はエラーメッセージを返し、メール送信を中止させるという流れだ。この対応は海外発の機械的スパムには極めて有効で、実装の手間に対する防御効果が高い。
よくある質問
ハニーポットを仕込んでもスパムが続く場合は？
ハニーポットだけで防げない場合は、ボットがCSSを解析して非表示フィールドを識別している可能性がある。その場合は、フィールドを完全に非表示にするのではなく、画面上の見えない位置にずらす方法（positionで画面外に飛ばす）や、JavaScriptを使って動的にフィールドを生成する方式に切り替えると効果が上がる。また、reCAPTCHA v3や日本語必須ルールの併用を必ず検討する。
reCAPTCHA v2よりv3のほうが本当に優秀なのか
ボット検知精度はどちらも高いが、v3は操作性と表示速度の面で大きく優れている。v2の画像選択がユーザーの離脱を招いたり、Ajaxフォームとの競合で送信エラーを起こす場面が減るため、問い合わせフォームとの相性という観点ではv3の導入が望ましい。ただし、v3はサイト全体のスコアリングを行うため、プライバシーポリシーへの記載が必要になる。
Contact Form 7以外のフォームに切り替えたほうがよいか
スパム対策だけを理由にフォームプラグインを移行する必要はない。Contact Form 7は世界的に使われている分、ボットの標的になりやすい面はあるが、今回紹介した対策を適切に組み合わせれば実用上十分な防御力を確保できる。移行によって別の競合やカスタマイズの手間が発生するリスクを考えると、まずは手元のContact Form 7を強化する方針が合理的だ。
この記事のポイント
- Contact Form 7へのスパムは、ボットがフォーム構造を熟知しているために発生する
- ハニーポット（CSS非表示のチェックボックス）で、人間には影響なくボットをブロックできる
- reCAPTCHA v3を導入すると、ユーザー操作なしで高精度なスパム判定が可能になる
- メール本文に日本語の文字種を必須にするルールを追加すると、海外発スパムの大半を遮断できる
- 単一の対策に頼らず、複数の層を重ねることでボットの突破を防ぐ
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Contact Form 7新機能凍結、WPForms移行完全ガイド
WordPressの定番お問い合わせフォームプラグイン「Contact Form 7」が、今後新機能を追加しない方針を正式に発表した。開発者のTakayuki Miyoshi氏がWordCamp Asia 2026のステージ上で明らかにしたもので、バージョン6.2を最後にメンテナンスモードへ移行する。
既存のフォームが即座に壊れるわけではないが、機能凍結されたプラグインは徐々に競合から遅れをとる。サイトの成長に合わせてモダンなフォーム機能を求めるなら、今が移行の最適なタイミングだ。本記事ではWPFormsを使ったスムーズな移行手順を9つのステップで解説する。
Contact Form 7新機能凍結の真実とリスク
「Contact Form 7が廃止される」という見出しはややセンセーショナルだが、実態を正しく理解しておく必要がある。開発チームは完全な開発中止ではなく「フィーチャーフリーズ（新機能凍結）」を発表した。これはセキュリティパッチや致命的なバグ修正は継続する一方、新機能の追加やモダンな統合は一切行われない状態を指す。
上の比較にあるように、ビジネスサイトではすでに条件分岐やAIによるフォーム生成が当たり前になりつつある。放置すれば、古いフォームがサイト全体の印象を下げたり、コンバージョンの機会損失につながる可能性が高い。
WPFormsへの移行が推奨される理由
WP Beginnerの編集チームは、多数のフォームプラグインを試した結果、長年にわたりWPFormsを第一推奨としている。その理由はシンプルで、初心者にとっての圧倒的な使いやすさと、サイトの成長に伴って必要になる高度な機能が両立している点にある。特にContact Form 7からの移行を考えるユーザーには、ビルトインのインポートツールが強力な決め手となる。
- フォーム作成にHTML/PHP知識が必要
- デザインはテーマ任せで調整が難しい
- スパム対策は別途プラグインが必要
- エントリー保存機能は標準ではない
- ドラッグ＆ドロップで直感的に作成
- テーマに自然に溶け込むスタイル
- 独自のスパム防止機能を内蔵
- フォーム送信内容を管理画面で確認可能
WPFormsの無料版（Lite）にも、Contact Form 7のフォームを数クリックで読み込み、そのままエディタ上に再現するインポート機能が搭載されている。フィールドラベルや通知設定も自動で引き継がれるため、移行のためにコードを書く必要は一切ない。有料版にアップグレードすれば、2,100以上のテンプレートや条件分岐、決済統合などが追加され、フォームをより強力なマーケティングツールに変えられる。
9ステップで完了、CF7からWPFormsへの移行手順
ここからは実際の移行手順を解説する。所要時間は10分〜15分で、技術的な知識は不要だ。作業を始める前に、念のためサイト全体のバックアップを取っておくとより安全である。
プラグインのインストールとセットアップ
まずWPForms LiteをWordPress管理画面からインストールし、有効化する。無料版は公式リポジトリから入手可能で、予算を問わずすぐに移行を開始できる。有効化後、自動でセットアップウィザードが立ち上がるので、表示される手順に従って基本設定を完了させる。有料版にアップグレードする場合は、ここでライセンスキーを入力する。
インポートツールで既存フォームを読み込む
管理画面の「WPForms」→「ツール」に移動し、「インポート」タブを開く。「他のフォームプラグインからインポート」のドロップダウンで「Contact Form 7」を選択し、インポートボタンを押す。WPFormsがサイト内のすべてのCF7フォームを自動検出し、一覧表示してくれる。
移行したいフォームにチェックを入れるか、「すべて選択」で一括指定する。不要なテストフォームや重複があれば、このタイミングで整理しておくとサイトがすっきりする。選択後、再度インポートを実行すると、各フォームがWPFormsのドラッグ＆ドロップエディタ上に再構築される。
インポート結果の確認と微調整
インポートが完了すると、結果画面に各フォームのステータスが表示される。大半のテキスト、メール、ドロップダウンなどの標準フィールドは問題なく移行されるが、CF7独自のカスタムフィールドやショートコードが含まれている場合、「要確認」としてフラグが立つ。対象フォームを開き、必須項目やドロップダウンの選択肢、通知メールの送信先アドレスを中心に目視チェックしよう。
ページ上のフォームを置き換える
フォームの準備が整ったら、表示されているページや投稿を編集する。古いContact Form 7のブロック（またはショートコード）を削除し、新しくWPFormsブロックを追加。ブロックのドロップダウンから該当のフォームを選ぶだけで、エディタ内に実際のフォームが即座に表示される。WPFormsはテーマのスタイルを自動的に引き継ぐため、デザインが大きく崩れる心配はまずない。
動作テストと最終確認
公開前に、実際のブラウザでフォームを開き、テスト送信を必ず1回は行う。送信後、自分宛の通知メールが届くか受信トレイを確認する。もしメールが届かない場合は、サイト側のメール配信設定に問題がある可能性が高い。その際はSMTPプラグインを導入し、信頼性の高いメール送信経路を確保するのが一般的な解決策だ。
Contact Form 7の無効化と削除
すべてのフォームがWPFormsで正常に動いていることを確認したら、プラグイン一覧からContact Form 7を無効化する。サイト全体をもう一度巡回し、古いショートコードが残っていないか最終チェックしてから、完全に削除しよう。この手順を踏めば、サイトからCF7依存を完全に取り除ける。
移行後に試すべきWPFormsの先進機能
無事に移行が完了したら、Contact Form 7にはなかったWPFormsのユニークな機能をいくつか試してみる価値がある。特にビジネスサイトでは、これらが問い合わせ率や顧客体験を大きく変えるきっかけになる。
上記は会話型フォームの一例だが、これ以外にもAIフォーム生成（自然言語で「評価機能付きフィードバックフォーム」と指示するだけで自動構築）、見えないスパム検証、条件分岐、StripeやPayPalを使った決済フォーム、フォーム離脱者の部分入力データ取得など、CF7時代には考えられなかった機能が揃っている。
よくある質問
Contact Form 7は完全に放棄されたのか
技術的には放棄ではなくフィーチャーフリーズだ。Miyoshi氏はWordCamp Asiaで、バージョン6.2をもって新機能の追加を停止し、以降は深刻なバグ修正とセキュリティパッチのみを提供すると明言した。プラグインがリポジトリから消えるわけではないが、新機能やモダンな統合は今後一切追加されない。
移行しないと既存フォームは突然壊れるのか
すぐに壊れることはない。セキュリティパッチが提供される限り、WordPressのコア更新との互換性は当面維持される。しかし機能凍結により、数年後には他のプラグインやテーマとの相性問題が発生するリスクが高まる。加えて、競合が提供するモダンなフォーム体験との差は広がるばかりだ。
後継のContactable.ioを待つべきか
WP Beginnerの見解では、待つメリットはほとんどない。Contactable.ioの正式リリースは早くても2028年とされており、安定版が広く使えるようになるまでにはさらに時間がかかる。WPFormsのような実績あるプラグインに今移行しておけば、すぐに最新機能を享受でき、将来Contactable.ioが登場した際に再検討すればよい。
無料版のWPFormsでもCF7からの移行は可能か
可能である。WPForms LiteにはContact Form 7インポーターとドラッグ＆ドロップビルダーが標準搭載されており、大半のユーザーは無料版だけで十分に移行を完了できる。より高度な決済フォームやマーケティング連携が必要になった時点で、有料版へアップグレードすれば問題ない。
過去の送信データは引き継がれるか
引き継がれない。Contact Form 7は送信内容をデータベースに保存せず、メールで送信する仕様のため、インポートできるエントリーデータが存在しない。過去の送信内容を残したい場合は、メールアーカイブやFlamingoプラグインでCSVエクスポートしたデータを別途保管しておく必要がある。
この記事のポイント
- Contact Form 7はバージョン6.2で新機能凍結。セキュリティ修正のみ継続される
- モダンなフォーム機能（条件分岐、AI生成、決済統合）は今後も追加されない
- WPFormsへの移行は無料のLite版でも可能で、専用インポートツールが用意されている
- 9ステップの手順に沿えば、コードの知識なしで10〜15分程度で移行が完了する
- 移行後は会話型フォームやスパム防止など、CF7にない機能をすぐに活用できる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験