WordPressで問い合わせフォームを実装する際、定番のプラグイン「Contact Form 7（CF7）」。デフォルトでは「メールを送信して終わり」の仕様ですが、フックを活用して送信されたデータをカスタム投稿タイプへ自動的に下書き保存（インサート）するカスタマイズを施すことで、フォームの枠を超えた強力なバックエンドシステムへと拡張できます。
本記事では、このカスタマイズの概要、実務での具体的な4つの実装例、さらに一歩進んだ応用例について解説します。
💡 機能：メール送信と同時にデータベースへ自動格納（Flamingoとの違い）
このカスタマイズの根本にあるのは、「メール送信」という一過性の処理を、「データベースへの蓄積・コンテンツ化」という資産化の処理へと変換する機能です。
CF7のデータ保存プラグインとしては「Flamingo」が有名ですが、あえて「カスタム投稿＋インサート」の手法を選ぶのには、クライアントワーク特有の明確な理由があります。
🚨 Flamingoの技術的仕様と、あえてカスタム投稿を選ぶ理由
-
データの正規化と「検索・絞り込み」の限界
Flamingoは内部的に
flamingo_inboundというカスタム投稿タイプで保存されるため、技術的にはフロントエンドへのデータ出力・公開自体は可能です。しかし、送信データが1つのシリアライズされた配列（メタデータ）として丸ごと格納されるため、「特定の条件で絞り込む」「項目順にソートする」といったフロント側での複雑な検索・抽出システムを組む場合、SQLレベルでの高速なフィルタリングが極めて困難になります。カスタム投稿＋カスタムフィールド（ACFやSCF）の構成であれば、項目ごとにデータが正規化されて保存されるため、高速で柔軟な絞り込みが可能です。 -
管理画面の運用フロー（承認・編集）の欠如
Flamingoの管理画面は、あくまで「届いたメールの受信履歴（ログ）」としてデザインされています。実務の運用フローにおいて、「ユーザーが投稿した内容を、管理者が内容チェック・誤字脱字の修正（推敲）をしてから公開する」というステップを踏む場合、FlamingoのUIはコンテンツの編集やステータス管理（下書き/公開）を行うように作られていないため、コンテンツ管理システム（CMS）としての運用が破綻しやすくなります。
- メッセージログとコンテンツデータの混在リスクサイト内に複数のフォーム（求人応募、問い合わせ、資料請求など）が存在する場合、Flamingoはそれらすべてのログを同じ場所に蓄積します。そこから特定のフォームデータだけをフィルタリングしてフロントのコンテンツとして扱うのは、設計を無駄に複雑にし、開発ミスによる「見せてはいけない個人情報の誤表示」といったセキュリティリスクを引き起こす原因になります。
プラグインを無駄に増やしてサイトを重くすることなく、使い慣れたCF7だけで「管理・公開・拡張」が自由自在なデータベースを構築できるのが、この機能の真髄です。
🛠 実装例：クライアントワークで即戦力になる4つの実例
クライアントへの提案や要件定義において、この機能をどのようなシステムとして組み込むべきか、具体的な4つのユースケースを挙げます。
1. 求人サイトの「企業向け・求人掲載申し込み」
企業が求人情報を掲載したいときに、専用のフォームから入力してもらうケースです。
-
CF7の入力項目: 会社名、職種、給与、勤務地、仕事内容
-
カスタム投稿への反映: 送信と同時に「求人情報（
recruitment）」というカスタム投稿に下書き状態で保存されます。管理者は内容を確認して公開ボタンを押すだけで、サイト上に求人ページが生成されます。
2. ポータルサイトの「口コミ・スポット登録申請」
地域の飲食店や観光スポットをユーザーに投稿してもらうポータルサイトでのケースです。
-
CF7の入力項目: 店舗名、カテゴリ、住所、おすすめポイント、店舗画像
-
カスタム投稿への反映: 「スポット情報（
spots）」というカスタム投稿に保存されます。画像はアイキャッチ画像やカスタムフィールドに自動で紐付けられ、管理者のチェック後にサイトへ掲載されます。
3. 社内ポータル・会員サイトの「日報やブログの投稿」
Webの知識がない社内スタッフや会員に、WordPressの管理画面（ダッシュボード）に入らせず、フロントページから記事を投稿させたいケースです。
-
CF7の入力項目: タイトル、本文、カテゴリ選択、投稿者名
-
カスタム投稿への反映: 「スタッフブログ（
staff_blog）」などのカスタム投稿に直接保存（または即時公開）されます。管理画面へのアクセス権限を渡さなくて済むため、セキュリティや誤操作の防止になります。
4. イベントの「参加申込・出席者リストの管理」
フォームから送信されたデータを、メール受信だけでなくWordPress内で「名簿」として一元管理したいケースです。
-
CF7の入力項目: 参加者氏名、メールアドレス、懇親会の出欠、質問事項
-
カスタム投稿への反映: 「イベント申込者（
applicants）」という非公開のカスタム投稿に保存します。メールの不達や紛失のリスクがなく、WordPressの管理画面だけで「誰が申し込んだか」を一覧で確認・検索できるようになります。
🚀 応用例：一歩進んだ高度なデータ連携と自動化
基本のインサート機能に加え、他のWordPress要素と組み合わせることで、さらに強力な仕組みへとアップデートできます。
1. 「カスタムフィールド自動格納」
各種フォームの入力データをただのテキストとして本文に突っ込むのではなく、項目ごとに分解してACFなどのカスタムフィールドに個別に格納します。これにより、「特定の地域や給与帯の求人だけを絞り込む」「未対応の申込者をソートする」といった、高度なデータ管理をWordPress内で構築可能になります。
2. カスタムタクソノミー（カテゴリ・タグ）の自動紐付け
フォーム側で選択された「職種」や「店舗カテゴリ」といったチェックボックスやセレクトボックスの情報を連動させ、インサート時に自動でカスタムタクソノミーへ紐付けます。投稿画面を開いて右サイドバーからカテゴリを探して手動でチェックを入れる、という手間と選択漏れを完全にゼロにします。
3. 定型HTML（テーブルや見出し）への自動整形流し込み
フォームのテキストエリアに入力された文字を、あらかじめシステム側で用意しておいた <h2> や <table> などのマークアップ構造の中に流し込んだ状態で記事化します。これにより、外部の企業や一般ユーザーがフォームからどんな風に投稿しても、自サイトのトンマナやデザインに完全に統一された綺麗な構成のレイアウトが自動で仕上がります。
📈 まとめ：制作会社とクライアント双方の運用工数を削減
-
クライアント・運用者: WordPressの複雑な管理画面やブロックエディタを一切触ることなく、使い慣れた「お問い合わせフォーム」のUIだけで安全かつ正確にコンテンツを追加・蓄積できる。
-
制作会社・エンジニア: 高額なスクラッチ開発や、プラグインを過剰に導入してサイトを重くすることなく、使い慣れたCF7とフックの制御だけで要件を満たす動的システムを低コストで構築できる。
Webサイトを単なる「問い合わせ窓口」として終わらせず、リリース後の更新効率やセキュリティ、データの資産化を見据えた「バックエンドの最適化設計」を行うことで、サイトの運用価値は最大化されます。ワンランク上のクライアント提案や、業務効率化の体制を作りたい方は、ぜひこの仕組みを導入してみてください。