本文へ移動
CASE STUDY 17 / CONTACT OPERATIONS / WORDPRESS

問い合わせフォームを、
送信機能ではなく運営基盤として見直す。

フォームは、画面からメールが一通届けば完成ではありません。必要な情報とファイルを受け付け、送信者と管理者へ通知し、迷惑送信を抑え、環境更新後も保守できる状態までを一つの受付業務として検討します。

THEME
Contact Operations
CASE EXAMINED
京都御所西 小川金正堂
IMPLEMENTATION
Contact Form 7 / Turnstile
EVIDENCE STATUS
Audited / Publication Ready
CENTRAL QUESTION

「送信できる」の先に、何が必要か。

問い合わせフォームを、入力欄と送信ボタンではなく、受付・通知・返信・添付・保護・保守まで続く業務として、どう設計するべきか。
CASE CONTEXT

既存フォームは、PHP更新と受付要件の両面で見直しが必要になった。

小川金正堂の既存WordPressにはMW WP Formによる問い合わせ環境がありました。

2026年6月14日、PHP更新の事前検証で既存フォームの互換性問題を確認しました。一方、問い合わせでは、一般的な連絡だけでなく、見積依頼やロゴ・参考画像・PDF等の資料を受け付ける可能性があり、添付ファイル、必須項目、承諾、通知方法も検討対象になりました。

したがって課題は、古いプラグインを新しいプラグインへ交換することではありませんでした。問い合わせを受けて社内で対応を始められる状態を、現在のPHP環境と迷惑送信対策を含めて再構築する必要がありました。

ANALYSIS

フォームは、顧客と社内業務の境界にある。

フォーム品質は画面だけでは判定できません。入力する人、通知を受け取る人、返信する人、添付を扱う人、保守する人の全工程が成立している必要があります。

Intake

問い合わせの種類に応じて、必要項目、必須条件、添付、承諾を定義する。

Notification

管理者通知と自動返信を分け、誰が何を受け取るかを確認する。

Protection

正規の問い合わせを妨げず、Bot・スパム送信を抑える。

Maintainability

PHP、WordPress、プラグイン更新後も検証・変更できる構成を選ぶ。

分析上の結論:問い合わせフォームの成果は「メールが届いた」ではありません。必要な情報を安全に受け付け、送信者へ受付を返し、社内が対応を開始でき、その状態を保守できることです。

DECISION FRAMEWORK

受付・通知・保護・保守から選ぶ。

01

Define

問い合わせの用途、必要項目、添付、承諾、完了後の動きを定義する。

02

Compare

既存フォームと候補を、確認画面だけでなく制御・互換性・保守性で比較する。

03

Build

入力、通知、返信、添付、迷惑送信対策を一つの受付フローとして構築する。

04

Verify

入力から受信まで実際に通し、公開後の業務で使えることを確認する。

IMPLEMENTATION

CASEで行われたフォーム再構築。

6/14

既存フォームの互換性を検証

PHP更新後の複製環境でMW WP Formの互換性問題を確認し、既存構成のまま本番更新しない判断をしました。

6/19

問い合わせ要件を整理

問い合わせ、見積依頼、資料添付を想定し、必須項目、ファイル受付、確認・完了、管理者通知、自動返信、迷惑送信対策を整理しました。

調査

フォーム候補とサーバー条件を比較

添付形式・容量の制御、確認画面、サンクスページ、追加依存、PHP互換性を比較し、サーバー上限とフォーム側の制御を分けて確認しました。

構築

Contact Form 7で受付環境を再構築

必須項目、添付ファイル、承諾項目、管理者通知、自動返信を含むフォームを構築しました。

保護

Cloudflare Turnstileを設定

正規の送信を維持しながら自動送信を抑えるため、フォームへTurnstileを組み込みました。

7/4

送信確認後に本番反映

入力、添付、管理者通知、自動返信、迷惑送信対策を確認し、PHP 8.3更新とともに本番環境へ反映しました。

VERIFIED RESULTS

一次情報で確認できた受付環境。

CONFIRMED / REQUIREMENTS

問い合わせを業務要件として整理した

受付用途、入力項目、添付、承諾、通知、返信、スパム対策、保守条件が調査・要件整理資料に残っています。

Evidence: お問い合わせフォーム調査・要件整理仕様書 Version 1.0 / 2026-06-19

CONFIRMED / MIGRATION

MW WP FormからContact Form 7へ移行した

PHP更新で確認された互換性問題へ対応し、本番で利用するフォーム構成を変更しました。

Evidence: 検証記録・本番反映記録 / 2026-06-14〜07-04

CONFIRMED / OPERATING FLOW

受付後の通知・返信まで構築した

必須項目、添付ファイル、承諾、管理者通知、自動返信を含む受付フローを実装し、送受信を確認しました。

Evidence: フォーム構築・送信テスト記録 / 2026-07-04

CONFIRMED / ABUSE CONTROL

Turnstileによる迷惑送信対策を組み込んだ

Contact Form 7と組み合わせてCloudflare Turnstileを設定し、本番フォームへ反映しました。

Evidence: 設定・本番反映記録 / 2026-07-04

FINDINGS

問い合わせ環境を選ぶ実務上の示唆。

画面より先に受付業務を定義する

何を受け取り、誰が対応を始めるかで、必要な項目と通知は変わります。

既存機能を削除前に検証する

フォームはPHPやメールと依存するため、単純な入れ替えでは完了しません。

添付は形式と運用を同時に決める

受け取れることだけでなく、必要性、制限、受信後の扱いを要件にします。

送信者側と管理者側を両方試す

完了表示だけでなく、自動返信と管理者通知の受信まで確認します。

LIMITS

このCASEが証明しないこと。

  • 調査資料に記載されたすべての候補機能・候補プラグインを本番導入したことを意味しません。
  • 調査時に想定したファイル形式・容量の全値を、現行本番設定値として断定しません。公開時は設定記録と再照合します。
  • 確認画面を追加する候補として調査したプラグインを、採用・本番導入したとは記載しません。
  • Turnstileによって迷惑送信を完全に防止できること、迷惑送信件数が減少したことは証明していません。
  • 問い合わせ数、成約率、対応時間の改善は測定していません。
  • 認証キー、メールアドレス、受信内容、添付ファイル、管理画面情報は公開しません。
EVIDENCE AUDIT

調査候補と本番実装を分ける。

主張品質区分根拠・処理
既存フォームにPHP互換性問題があった検証結果WordPress保守管理資料 Version 1.2、2026-06-14
添付を含む問い合わせ要件を調査した調査・要件事実お問い合わせフォーム調査・要件整理仕様書 Version 1.0、2026-06-19
Contact Form 7へ移行した実装・本番反映事実構築・本番反映記録、2026-07-04
添付、承諾、管理者通知、自動返信を構築した実装・テスト事実フォーム構築・送信テスト記録、2026-07-04
Turnstileを本番フォームへ設定した実装事実設定・本番反映記録、2026-07-04
フォームは受付業務の基盤である分析要件、実装、通知、返信、保護、保守の連続から導いた解釈
調査した全候補を導入した非該当比較対象と採用構成を分離。候補を実装事実にしない。
迷惑送信が減少した未測定導入後件数の比較記録がないため主張しない。

重要な識別:CASE STUDY 16は既存WordPress更新の変更管理を研究します。本記事は、その工程で再構築した問い合わせ受付の要件・実装・運用を研究します。

事実境界:仕様書の比較・想定は調査事実、本番で構築・テスト・反映した項目は実装事実として分離しています。

公開許可:2026年2月16日の実績公開許可と、2026年6月10日のPROJECT全体公開許可を確認しています。

判定:互換性問題、要件整理、Contact Form 7への移行、受付・通知・返信・添付・Turnstile、送信確認、本番反映まで追跡でき、未採用候補と未測定効果を除外したPublication Readyです。