はじめに

前回の記事では、MW WP Form の移行先プラグインを技術評価軸で比較しました。今回はその続きとして、MW WP Form のフォームを Form Plant へ自動移行する移行ツールの使い方と、移行で一番つまずきやすい「デザインの引き継ぎ」の考え方を、技術者向けに整理します。

はじめにお伝えしておくと、本記事は Form Plant という WordPress フォームプラグインを開発している立場（筆者 = Sofplant）から書いています。とはいえ移行は技術的な作業なので、自動で済む範囲・手作業が残る範囲・そもそも移行できない範囲を、できる限り正確に書きます。判断材料の一つとしてお読みください。

なお、操作の 1 手順ずつのスクリーンショットや、移行後の完全なチェックリストは、sofplant.com に完全ガイドを用意しています。本記事は「どういう仕組みで・何に気をつけて移行するか」というポイントに絞り、細かい手順はそちらへリンクで送る構成にしています。

背景

MW WP Form は 2023 年 9 月に開発終了がアナウンスされ、現在は株式会社 Web の相談所が脆弱性対応中心の保守を引き継いでいます。加えて、最近 MW WP Form の管理画面に、ファイル・画像アップロード（[mwform_file] / [mwform_image]）を v5.2（2026 年内リリース予定）で削除するという廃止予告が表示されています。ファイル添付を使っているフォームは、いずれ別の手段が必要になります。

この記事で扱う範囲

移行の話題は広いので、2 本に分けます。本記事（第 1 弾）と、続く第 2 弾の守備範囲は次のとおりです。

第 1 弾（本記事）: 移行ツールの仕組み / 移行の流れ / フィールド名とラベルの扱い / デザインをそのまま引き継ぐ考え方
第 2 弾（次回）: functions.php の mwform_* フックを fplant_* へ書き換える方法 / 設計の違いによる「移行できる点・できない点」

フックを使ったカスタマイズをしている方は、第 2 弾もあわせてご覧ください。本記事ではフックは「手動で書き換える必要がある」という事実に触れる程度にとどめます。

移行ツールの基本方針

具体的な手順に入る前に、移行ツールの性格を 3 点だけ押さえておきます。ここを理解しておくと、安心して試せます。

Form Plant 本体に同梱されており、追加費用も別プラグインも不要です。MW WP Form が有効化されている環境でのみ、管理メニュー（Form Plant → ツール → MW WP Form Migration タブ）に表示されます。
元のフォームを壊さず、コピーを作る方式です。 既存の MW WP Form のフォームを上書きするのではなく、新しい Form Plant のフォームを別途生成します。元フォームは公開状態のまま残るので、見比べながら作業でき、何度でもやり直せます。
移行で生成されるフォームは 最初から「公開」状態・標準デザイン適用です。移行したらすぐ送信テストまで試せる初期状態にしてあります。

何が自動変換され、何が手作業で残るか

移行ツールの全体像を、変換の扱いで分類すると次のようになります。Qiita 読者の関心が高いであろう「手作業が残る箇所」と「移行できない箇所」を特に意識して読んでください。

項目	移行の扱い
入力項目（フィールド構成・必須・選択肢）	✅ 自動変換
管理者メール・自動返信メールの設定	✅ 自動変換
メール本文の差し込みタグ（`{お名前}` → `{field:your_name}` 等）	✅ 自動変換
入力画面・確認画面の HTML テンプレート（構造）	✅ 自動変換（構造を保持）
カスタムメールタグ（`[mwform_custom_mail_tag]`）	⚠️ フィールドは自動変換。値を返すフック（`mwform_custom_mail_tag_` → `fplant_custom_mail_tag_value_`）は手動書き換えが必要
`functions.php` の `mwform_*` フック	⚠️ 手動で書き換え（第 2 弾で解説）
`[mwwp_formkey key="…"]` ショートコードの差し替え	⚠️ 手動（自動置換はしない／案内のみ）
フォームのデザイン CSS	⚠️ 標準デザインで生成（忠実に引き継ぐ場合は要調整）
送信データ（過去のお問い合わせ）	❌ 移行されない

特に強調しておきたいのが、次の 2 点です。

送信データ（エントリー）は移行されません。 移行されるのは「フォームの定義」だけで、過去にそのフォームから送られたお問い合わせ内容は対象外です。過去データが必要なら、移行後もしばらく MW WP Form を残すか、MW WP Form 側で先に CSV エクスポートしておいてください。

ショートコードの差し替えは手作業です。 ページ内の [mwwp_formkey key="…"] を移行ツールが勝手に書き換えることはしません（誤動作を避けるため、案内の表示にとどめています）。テストが済んでから、自分のタイミングで差し替える設計です。

完全な変換表（range スライダーや汎用ボタンの扱いなど細部も含む）は、完全ガイドの第 1 章にまとめてあります。

移行の流れとポイント

操作自体はシンプルです。一連の流れと、各段階で押さえておきたいポイントだけ示します（1 手順ずつのスクリーンショット付きの手順は、前述の完全ガイドにあります）。

Form Plant（v1.2 以上）と MW WP Form を両方有効にする。 移行タブは MW WP Form が有効なときだけ出ます。
移行タブでフォームを選んで実行する。 複数まとめて選べます。生成フォームのタイトルには移行元と日時が付くので（例: お問い合わせ(from MW WP Form 2026-06-02 14:30:00)）、同じフォームを 2 回移行しても上書きされず別々に並びます。
警告レポートを確認する。（後述）
まず非公開ページでテストする。（後述）
問題なければ本番ページのショートコードを手動で差し替える。

ポイント 1: 警告レポートを読む

移行が終わると、フォームごとに警告レポートが出ます。これは移行ツールの中核機能で、「自動変換しきれなかった点」「変換時に判断を加えた点」を 3 段階で可視化します。

info: 正常に処理したが念のため知らせたい変換（例: 日本語フィールド名を英数字キーに変換した）
warning: 移行はしたが設計差で完全一致しない、または要確認（例: range スライダーを number に変換した／汎用ボタンは移行されない）
error: 変換に失敗した箇所

レポートは移行後も移行タブの一覧から再表示できるので、その場で全部メモする必要はありません。warning が出たフィールドだけ後で重点的に見直す、という進め方が効率的です。

ポイント 2: いきなり本番に当てない

移行はコピー生成（元フォームを残す）なので、本番ページのショートコードを差し替える前に、非公開（または下書き）のテストページで検証するのが安全です。固定ページを 1 つ作って公開状態を「非公開」にすれば、ログイン中の管理者だけが本番と同じ URL の仕組みでテストできます。訪問者が見る本番フォームは MW WP Form のまま影響を受けません。

この段階で、入力 → 確認 → 送信 → 完了の一連の流れと、管理者メール・自動返信メールの受信まで一通り確認します。特に自動返信メールは要注意で、宛先に指定したフィールドが移行後のフォームに実在しないと、設定は入っているように見えても実際には送られないことがあります。テスト送信で必ず受信を確かめてください。

フィールド名とラベルの扱い — ここは移行直後に確認

移行で地味につまずきやすいのが、MW WP Form と Form Plant でフィールドの「名前」の持ち方が違う点です。ここはメールの差し込みタグやフックのフィールド名にも波及するので、移行方法の理解として押さえておきます。

MW WP Form のフォームタグ（例: [mwform_text name="お名前"]）には name 属性はありますが、「ラベル」という独立した設定はありません（画面に見えていた「お名前：」などの項目名は、テンプレートに手書きしたテキストでした）。一方 Form Plant には「フィールド名」（英数字のキー）と「フィールドラベル」（画面の表示名）の 2 つがあります。

移行ツールは、MW WP Form の name 属性をもとに、この 2 つを次のように埋めます。

フィールド名 = name 属性を英数字化した値（日本語なら辞書または連番で変換）
フィールドラベル = name 属性の値をそのまま（変換しない）

具体例で見ると分かりやすいです。

MW WP Form のフォームタグ	Form Plant のフィールド（移行後）
`[mwform_text name="お名前" class="wide" size="20"]`	フィールド名 `your_name` ／ラベル `お名前` ／クラス `wide` ／サイズ `20`
`[mwform_text name="fullname" class="wide" size="20"]`	フィールド名 `fullname` ／ラベル `fullname` ／クラス `wide` ／サイズ `20`

つまり、name に日本語を入れていた場合は、ラベルにその日本語がそのまま入ります（上の例なら「お名前」）。一方、name を fullname のような半角英数にし、「お名前：」という項目名はテンプレート側に手書きしていた場合は、フィールド名もラベルも fullname になり、画面に出していた「お名前：」は（標準レイアウトでは）ラベルとして引き継がれません。後者で日本語ラベルを出したい場合は、移行後にフォーム編集画面で各フィールドのラベルだけ設定し直してください（フィールド名はそのままで問題ありません）。

なお、テンプレートに手書きしていた「お名前：」などのテキスト自体は、HTML テンプレート（初期状態は off）の中に構造として保持されています。HTML テンプレートを on にすれば、元の項目名表示もそのまま復元できます。

日本語フィールド名の英数字化ロジック

Form Plant のフィールド名は英数字とアンダースコアのみです。MW WP Form で name を日本語にしていた場合、移行ツールは次の順で英数字キーに変換します。

すでに英数字のみなら、そのまま使う
よくある名前は辞書で英訳（お名前 → your_name、メールアドレス → email、電話番号 → tel、郵便番号 → zip、お問い合わせ内容 → inquiry など）
辞書にない名前は、フィールド型をもとにした連番で生成（例: お申込み日 → text_1）
名前が衝突したら末尾に _2、_3 を付与

連番フォールバック（text_1 など）になったフィールドは何の項目か分かりにくいので、移行後に分かりやすい名前へ変更しておくと、後のメンテナンスが楽になります。その際は、メール本文の差し込みタグやフックのフィールド名も合わせて更新してください。

なお、メール本文の差し込みタグも、この同じマップで自動変換されます。

MW WP Form	Form Plant
`{お名前}`（日本語名）	`{field:your_name}`
`{email}`（英数字名）	`{field:email}`

デザインをそのまま移行するには

ここからが本記事のもう一つの主題、デザインの引き継ぎです。結論から言うと、多くの場合は何もしなくて済みます。が、旧フォームの見た目を忠実に再現したい場合は、Form Plant と MW WP Form の「テンプレートの持ち方の違い」を理解しておくと一気に作業が楽になります。

デザイン移行の全体像は、次のフローで整理できます。多くの方は最初の分岐の「OK」で終わり、こだわる方だけ右下のルートへ進みます。

以降、この各分岐を順に見ていきます。

デザインにこだわらない場合は調整不要

v1.2 以上では、移行フォームは次の状態で生成されます。

入力画面・確認画面の HTML テンプレートは off（標準レイアウトで表示）
フォームデザインは Form Plant 標準の CSS が on

つまり移行直後から、項目を足し引きしてもレイアウトが自動で追従し、標準デザインでそこそこ整った見た目になっています。デザインにこだわりがなければ、CSS もテンプレートも触る必要はありません。

少し手直ししたい場合（プリセットと CSS 調整）

見た目をもう少し整えたい程度なら、フォーム編集画面の「レイアウト」タブにある「フォームデザイン」で完結します。HTML テンプレートを触らず、次の 3 つの方法が使えます。

プリセットを選ぶ（デフォルト CSS 設定）: 「デフォルト CSS 設定」のラジオで、シンプル 1（縦並び）／シンプル 2（横並び）／標準（装飾あり）／なし、から選べます。まずはここを切り替えるだけで全体の印象が変わります。
プリセットの CSS をダウンロードして差し替える（カスタム CSS 設定）: 各プリセットには「CSS をダウンロード」リンクがあり、元の CSS を落として手元で編集し、「カスタム CSS 設定」からアップロードして適用できます（複数ファイル可）。プリセットを土台に作り込みたいときに向いています。
インライン CSS で直接微調整: 「インライン CSS」のテキストエリアに CSS を直接書けば、ボタンの色や余白といった軽い調整はその場で完結します。

ここまでで足りる場合がほとんどです。次の「移行前のデザインを忠実に引き継ぎたい」ケースに進むのは、旧フォームの見た目を細部まで再現したいときだけです。

設計差: MW WP Form のテンプレートは 3 つの情報に仕分けられる

デザインを忠実に引き継ぐ際に理解しておきたいのが、テンプレートの扱い方の違いです。

MW WP Form では、入力・確認・完了を 1 つのテンプレート（post_content）で兼用し、その中にフィールド・レイアウト・ボタンが一緒くたに書かれていました。移行ツールは、この 1 つのテンプレートを読み解いて、Form Plant の対応する 3 種類の設定へ仕分けて保存します。

フィールド設定: 各項目の型・必須・選択肢などは、Form Plant のフィールド設定（モーダルで編集）になります。
HTML テンプレート: 項目の並びやレイアウトの骨格は、HTML テンプレートとして保存されます（初期状態は off で、標準レイアウトで表示）。
ボタン設定: 確認 / 戻る / 送信ボタンの文言などは、フォームのボタン設定へ移ります。

デザイン調整で主に触るのは、この真ん中の HTML テンプレートです。さらに、この HTML テンプレートは「入力画面用」と「確認画面用」の 2 つに分かれます。MW WP Form は 1 つのテンプレートを画面の状態で切り替えていましたが、Form Plant は最初から 2 枚に分かれている、という違いです。

分割された 2 つは、フィールドの並びやレイアウトの骨格は共通で、違うのは次の 2 点だけです。

フィールド部分: 入力画面は入力欄（[fplant_field name="…"]）、確認画面は値の表示（[fplant_value name="…"]）
ボタン部分: 入力画面は「確認へ進む / 送信」、確認画面は「戻る / 送信」

なので、デザインを調整したいときは、この 2 つのテンプレートを on にしてそれぞれ整えます。構造が同じなので、入力画面を整えたら同じ要領で確認画面側を揃えるだけです。実際のところ、多くのデザイン移行はこの 2 テンプレートを on にして CSS を少し足す程度で足ります。

CSS クラスは自動付与されない

もう一つ重要な点として、MW WP Form 用の CSS クラス（mw_wp_form など）は Form Plant では自動付与されません。 テーマやカスタム CSS で mw_wp_form 系のセレクタにスタイルを当てていた場合、そのスタイルは効きません。

理由は 2 つあります。クラスの付与先要素が MW WP Form と異なること（MW WP Form は外側の <div>、Form Plant は form タグ）、そして mw_wp_form_input のようなクラスは入力 / 確認 / 完了で切り替わる「状態クラス」であり、静的に固定すると挙動が食い違うことです。中途半端に似せるより、Form Plant の標準クラスに合わせて整える方が結果的に扱いやすい、という設計判断です。

MW WP Form でよく使った状態クラスが、Form Plant で何に対応するかを表にすると次のとおりです。

MW WP Form のクラス	役割	Form Plant での対応
`mw_wp_form`（常時）	フォーム全体の外枠	`fplant-form-wrapper`（外側の `<div>`、`id="fplant-form-{フォームID}"`）
`mw_wp_form_input`（入力画面）	入力中の状態	`fplant-form`（`<form>` タグそのものが入力画面）
`mw_wp_form_confirm`（確認画面）	確認中の状態	`fplant-confirmation`（確認時に JS が生成する別要素）
`mw_wp_form_complete`（完了画面）	送信完了の状態	`fplant-success`（完了メッセージ）／`fplant-custom-success-page`（完了ページ HTML を使う場合）

ここで押さえておきたいのが、状態の表し方が根本的に違う点です。MW WP Form は「1 つのコンテナに状態クラスを付け替える」方式でした（同じ <div> が入力時は mw_wp_form_input、確認時は mw_wp_form_confirm に変わる）。一方 Form Plant は、入力画面（.fplant-form）を隠して確認画面（.fplant-confirmation）という別要素を差し込む方式で、どちらも外枠の .fplant-form-wrapper の中で入れ替わります。

よって、確認画面だけにスタイルを当てていた .mw_wp_form_confirm .xxx { … } は、.fplant-confirmation .xxx { … } に書き換える、という対応になります。「状態クラスを 1 つの要素に付け替える」前提のセレクタは、そのままでは移植できません。

見た目を引き継ぐ現実的な選択肢は次の 3 つです。

方法 A（推奨）: 既存 CSS のセレクタを書き換える。 HTML 構造はほぼ同じなので、セレクタを Form Plant のクラス（fplant-form など）に合わせ直すのが一番素直です。開発者ツールで生成後の構造を確認して当て直します。
方法 B: プリセット / カスタム CSS 機能を使う。 ゼロから整えるなら、プリセットとフォームごとのカスタム CSS で作る方が早い場合もあります。「移行を機にデザインも刷新する」割り切りも一つの手です。
方法 C: form タグに任意クラスを付与する。 どうしても既存 CSS を活かしたい場合の手段ですが、要素の階層差と状態クラスの非再現で完全一致はしません。

入力フィールドの出力 HTML をオーバーライドできる

MW WP Form（v4 以降）には、入力フィールドの出力 HTML を、使用中のテーマのディレクトリに PHP ファイルを置くだけでオーバーライドできる機能がありました（作者自身が「テーマにファイルをおくだけで入力フィールドを上書きできる」と紹介していたものです）。たとえばテキストフィールドを <span class="text-field">…</span> で囲む、といった具合に出力構造そのものを差し替えられる仕組みです。これを使って入力欄の HTML を作り込んでいた場合でも安心で、Form Plant でも同じ仕組みが使えます。違いは、テーマディレクトリにコピーするフォルダ名が mw-wp-form/ から form-plant/ に変わるだけです。ファイルの並びまで同じなので、作り込んだテンプレートをほぼ同じ感覚で移植できます。

	MW WP Form	Form Plant
コピー元	`plugins/mw-wp-form/templates/form-fields/text.php`	`plugins/form-plant/templates/form-fields/text.php`
コピー先（テーマ）	`themes/テーマ/mw-wp-form/form-fields/text.php`	`themes/テーマ/form-plant/form-fields/text.php`

さらに Form Plant では、入力画面（form-fields/）だけでなく、確認画面のフィールド表示（confirm-fields/）や確認画面全体のレイアウト（confirmation.php）も同じ方式でオーバーライドできます。入力・確認のそれぞれを HTML レベルで作り込めるのは、先述の「テンプレート分離」の設計から来ています。テーマディレクトリ内では、次のような構成で置きます。

wp-content/
└── themes/
    └── お使いの子テーマ/
        └── form-plant/
            ├── form-fields/
            │   └── text.php       ← 入力画面のオーバーライド
            └── confirm-fields/
                └── text.php       ← 確認画面のオーバーライド

入力欄の HTML を自作するときは、name 属性を $field['name'] のまま保つこと、未選択を表す空 <option value=""> を残すこと、エラー装飾は CSS（fplant-field-has-error クラス）で行うこと、の 3 点に注意してください。詳細は完全ガイドの第 6 章とマニュアルのフィールドテンプレートのオーバーライドにまとめています。

まとめ

MW WP Form から Form Plant への移行は、移行ツールでフォーム定義・メール設定・画面テンプレートの大部分を自動変換できます。生成フォームは公開状態・標準デザインで作られるので、**まず「そのまますぐ動く」**ところから始められるのが特徴です。

移行方法のポイントを再整理すると、次のとおりです。

移行は元フォームを残してコピーを作る方式。まず 1 フォームだけ移行し、警告レポートと非公開ページでのテスト送信で確かめてから本番へ。
送信データは移行されないこと、ショートコードの差し替えは手作業であることは、あらかじめ押さえておく。
フィールド名とラベルの持ち方が違うため、移行直後にラベルの設定と自動返信の宛先フィールドを確認する。
デザインは、こだわらなければ調整不要。忠実に引き継ぐ場合は、テンプレートが入力 / 確認に分離されることと、mw_wp_form 系クラスが自動付与されないことの 2 点を理解しておくと作業が早い。

スクリーンショット付きの操作手順、移行後の完全なチェックリスト、フィールドの全変換表は、sofplant.com の完全ガイドにまとめてあります。

次回（第 2 弾）は、functions.php の mwform_* フックを Form Plant の fplant_* フックへ書き換える方法と、設計の違いによる「移行できる点・できない点」を扱います。フックでカスタマイズしている方は、そちらもご覧いただければと思います。