この記事には広告を含む場合があります。
記事内で紹介する商品を購入することで、当サイトに売り上げの一部が還元されることがあります。
フォーム送信後の処理は、最初からコードで作り込む必要はありません。JetFormBuilderには、メール通知、投稿作成、記録保存、リダイレクト、条件付きの実行など、管理画面から組める送信後アクションがあります。まずは標準設定で作り、あと一歩だけ足りない場面にだけ小さなコードを足すのが安全です。
この記事では、Elementorで作った「相談申し込みページ」にJetFormBuilderの相談フォームを置き、希望メニューによって通知先を変える例で解説します。たとえば「サイト改善相談」は制作担当へ、「広告運用相談」は集客担当へ、「保守相談」はサポート担当へ送る、という実務の分岐です。
標準の条件付きメール通知で足りるなら、それが一番管理しやすいです。複数の条件が増え、担当者の割り当てや文面の整形をまとめたいときだけ、Call HookとCode Snippetsで送信後の小さな分岐処理を足します。
JetFormBuilderの公式ページでフォーム機能の全体像を確認してから進めると、入力項目、送信後アクション、条件分岐、保存処理の役割がつながりやすくなります。

この記事で分かること
- JetFormBuilderの送信後アクションをどこまで標準設定で作るか
- 相談フォームに用意する入力項目と保存用のデータ項目
- 希望メニューごとに通知先を切り替える設定例
- Call HookとCode Snippetsで小さなPHPを足す考え方
- Elementor側でフォームと完了導線をどう見せるか
- 個人情報、通知、権限まわりで複雑にしすぎない境界
まず何を作るのか
今回作るのは、制作会社や個人制作者のサイトに置く「相談申し込みフォーム」です。ユーザーは、名前、メールアドレス、希望メニュー、相談内容、希望連絡方法を入力します。送信後は、申込者へ控えメールを送り、管理者用の記録を残し、希望メニューに応じて担当者へ通知します。
静的なElementorページだけで作る場合、ページ上の案内文とフォームは作れます。けれども、送信後の運用はメールボックスに寄りがちです。相談種別が増えると、担当者への転送、対応漏れの確認、過去相談の検索が手作業になります。ここでJetFormBuilderを使うと、フォームの入力画面だけでなく、送信後の処理までWordPress側で組み立てられます。
ただし、最初からCRMのような大きな仕組みにしない方がいいです。この記事では、通知先の切り替えと記録保存に範囲を絞ります。顧客管理、契約管理、請求、会員権限まで一気に作ると、フォームの話ではなく業務システムの設計になります。
どのデータを持たせるのか
フォームに置く入力項目と、WordPress内に保存する記録項目は似ていますが、完全に同じではありません。申込者が入力する項目は少なく、管理者があとから見る項目は少し増やします。JetEngineを併用するなら、相談記録用のデータの箱(CPT)を作り、JetFormBuilderの送信後アクションでそこへ保存できます。
| 設定項目 | 値の例 | 使い道 |
|---|---|---|
| データの箱 | consultation_entry |
相談申し込みを1件ずつ保存 |
| Label | 相談申し込み | 管理画面で見つけやすくする |
| 公開設定 | 非公開運用 | 申込内容を一般公開しない |
| サポート | Titleのみ | 本文ではなく入力項目で管理する |
入力項目は、あとから一覧で確認する単位に分けます。1つの「相談内容」だけに全部入れてしまうと、担当者別やメニュー別の確認ができません。反対に、最初から細かすぎる項目を20個も作ると、ユーザーが入力しにくくなります。最初は次のくらいが現実的です。
| 画面ラベル | フィールド名 | 型 | サンプル値 |
|---|---|---|---|
| お名前 | applicant_name |
Text | 山田 太郎 |
| メール | applicant_email |
Text | sample@example.com |
| 希望メニュー | service_type |
Select | site_renewal |
| 相談内容 | message |
Textarea | 既存LPの改善相談 |
| 希望連絡方法 | contact_method |
Radio | メール |
| 対応状況 | entry_status |
Select | 未対応 |
| 内部メモ | staff_note |
Textarea | 管理者だけが記入 |

まず標準の送信後アクションで組む
JetFormBuilderでは、フォーム送信後に実行する処理を「送信後アクション」として並べます。今回の基本形は、次の順番です。
- 申込者へ控えメールを送る
- 管理用の記録を保存する
- 希望メニューに応じて担当者へ通知する
- 完了ページへ移動する、または完了メッセージを表示する
公式ドキュメント上でも、送信後アクションにはメール送信、投稿作成・更新、記録保存、Call Hookなどが用意されています。メール通知だけで足りるなら、まずはSend Emailアクションを複数作り、それぞれに条件を付けます。たとえば、希望メニューが site_renewal のときだけ制作担当へ送る、maintenance のときだけ保守担当へ送る、という作り方です。
| アクション名 | 条件 | 宛先の例 | 役割 |
|---|---|---|---|
| 控えメール | 常に実行 | %applicant_email% |
申込者へ内容を返す |
| 制作担当通知 | service_type = site_renewal |
制作担当 | サイト改善相談を受ける |
| 集客担当通知 | service_type = ads_support |
集客担当 | 広告相談を受ける |
| 保守担当通知 | service_type = maintenance |
保守担当 | 保守相談を受ける |
| 相談記録の保存 | 常に実行 | consultation_entry |
後から一覧で確認する |
この段階では、コードはまだ不要です。条件が3つ程度で、担当者も固定なら、標準設定の方が画面から確認しやすく、あとで別の制作者が見ても意図が分かります。

コードを足すべき場面
コードを足すのは、標準設定のアクションが増えすぎるときです。たとえば、希望メニューが8種類あり、地域や予算感でも通知先を変える場合、Send Emailアクションを大量に並べると管理しにくくなります。条件の変更漏れも起きやすくなります。
このとき、JetFormBuilderのCall Hookアクションを使うと、フォーム送信後に任意のWordPressフック名を呼び出せます。記事では、フック名を netchild_jfb_route_notification として、Code Snippetsプラグインに同じ名前の処理を登録する例にします。
Call Hookは便利ですが、フォームの入力値を扱うコードになります。実運用では、入力値のサニタイズ、メールアドレスの検証、個人情報をログに残さないこと、停止しやすい配置にすることを必ず確認してください。

Call Hookで担当者通知をまとめるPHP例
以下は、希望メニューに応じて通知先を切り替える最小例です。配置場所はCode Snippetsプラグイン、または子テーマの functions.php です。初心者は、エラー時に無効化しやすいCode Snippetsプラグインの方が扱いやすいです。
JetFormBuilder側では、送信後アクションにCall Hookを追加し、Hook Nameに netchild_jfb_route_notification と入力します。フォームのフィールド名は、下のコードと同じ service_type、applicant_name、applicant_email、message に合わせてください。
add_action( 'netchild_jfb_route_notification', function () {
$service = isset( $_POST['service_type'] )
? sanitize_key( wp_unslash( $_POST['service_type'] ) )
: '';
$name = isset( $_POST['applicant_name'] )
? sanitize_text_field( wp_unslash( $_POST['applicant_name'] ) )
: '';
$email = isset( $_POST['applicant_email'] )
? sanitize_email( wp_unslash( $_POST['applicant_email'] ) )
: '';
$message = isset( $_POST['message'] )
? sanitize_textarea_field( wp_unslash( $_POST['message'] ) )
: '';
if ( ! $service || ! $name || ! is_email( $email ) ) {
return;
}
$routes = array(
'site_renewal' => 'renewal-team@example.com',
'ads_support' => 'marketing-team@example.com',
'maintenance' => 'support-team@example.com',
);
$to = isset( $routes[ $service ] )
? $routes[ $service ]
: 'info@example.com';
$subject = sprintf( '相談フォーム: %s', $service );
$body = sprintf(
"お名前: %s\nメール: %s\n希望メニュー: %s\n\n相談内容:\n%s",
$name,
$email,
$service,
$message
);
$headers = array(
sprintf( 'Reply-To: %s <%s>', $name, $email ),
);
wp_mail( $to, $subject, $body, $headers );
} );
このコードは、フォームから来た値をそのまま信用せず、sanitize_key()、sanitize_text_field()、sanitize_email()、sanitize_textarea_field() で整えてから使います。送信先も、フォーム入力値から直接受け取るのではなく、サーバー側の配列に固定しています。ここが大事です。ユーザーが見えない入力項目を書き換えても、任意のメールアドレスへ送れない形にしておきます。
実サイトでは、上の example.com の宛先を自社の担当者メールに置き換えます。送信テストは本番公開前にステージングサイトで行い、メールが迷惑メールに入らないか、Reply-Toが意図どおりか、未分類のメニューが info@example.com 相当の共通窓口へ届くかを確認してください。
Elementor側ではどう表示するのか
Elementor側では、相談ページの本文、フォーム、送信後の案内を分けて考えます。ページ上部では「どんな相談を受け付けるのか」を説明し、その下にJetFormBuilderのフォームを配置します。フォームの上には、希望メニューの選び方を短く書く程度で十分です。
完了後の見せ方は2つあります。1つはフォーム下に完了メッセージを表示する方法、もう1つはサンクスページへ移動する方法です。広告流入やアクセス解析を重視するなら、サンクスページに移動させる方が計測しやすいです。通常の問い合わせなら、ページ内の完了メッセージでも問題ありません。
相談記録をJetEngineのデータの箱に保存している場合、管理者向けの一覧ページをElementorで作ることもできます。公開ページではなく、管理者だけが確認する前提のページです。Listing Itemに「お名前」「希望メニュー」「対応状況」「送信日」を置き、Listing Gridで並べると、メールボックスを探すより確認しやすくなります。
運用すると何が楽になるのか
この仕組みで楽になるのは、フォーム送信後の手作業です。メールを見て担当者へ転送する、相談種別をメモする、対応済みかどうかを別のシートに書く、といった作業を減らせます。特に、複数人で問い合わせ対応をするサイトでは、誰に通知されたかをルール化できるのが効きます。
ただし、通知先を自動で切り替えたからといって、対応管理が完全に自動化されるわけではありません。返信の品質、個人情報の扱い、担当者の不在時の代替ルール、対応期限は別途決める必要があります。JetFormBuilderはフォームと送信後処理を作る道具であり、社内ルールそのものを設計してくれるわけではありません。

どこから複雑になりすぎるのか
フォームまわりは、便利にしようとするとすぐに複雑になります。希望メニュー、地域、予算、担当者の空き状況、既存顧客かどうか、資料添付の有無、会員権限、決済まで一度に入れようとすると、フォームではなく業務システムの領域です。
最初の実装では、次の範囲に抑えるのがおすすめです。
- 希望メニューで通知先を分ける
- 申込者へ控えメールを送る
- 相談記録をWordPress内に保存する
- 対応状況だけ管理者が更新できるようにする
- 個人情報は必要最小限にする
逆に、ログインユーザーの個人情報、決済、予約枠、ファイル添付、外部CRM連携まで扱うなら、権限設計、スパム対策、保存期間、プライバシーポリシー、バックアップ、通知失敗時の再送方法まで見直してください。JetFormBuilderやJetEngineを入れれば、セキュリティ設計や運用設計が不要になるわけではありません。

この構成が向いている人・向いていない人
向いているのは、Elementorで相談ページやサービスページを作っていて、問い合わせ後の処理を少し整えたい人です。メール通知を分けたい、相談記録を残したい、担当者への転送を減らしたい、という段階なら、JetFormBuilderと少しのコードで十分に現実的です。
向いていないのは、最初から複雑な顧客管理システムをWordPressだけで作ろうとしているケースです。複数部署の承認、機密情報、決済、契約管理、外部システム連携が絡むなら、専用サービスや開発者による設計も検討した方が安全です。
まとめ
JetFormBuilderのカスタムコード拡張は、標準設定を置き換えるものではありません。まずは送信後アクション、条件付きメール通知、保存処理で作り、管理画面上の設定が増えすぎたときだけ、Call HookとCode Snippetsで小さくまとめます。
今回の相談フォーム例では、希望メニューに応じた通知先切り替えを扱いました。入力項目を分け、保存する記録を決め、Elementor側ではフォームと完了導線を整える。ここまでできると、静的な問い合わせページから一歩進んだ運用が作れます。
JetFormBuilderの送信後アクションを確認しながら、自分のサイトでまず1つだけ自動化するなら、通知先の分岐から始めるのが分かりやすいです。

