この記事の要点
自作のメールフォームと外部サービスの埋め込みの違いは、機能ではなく「不具合とセキュリティへの対応を誰が持つか」です。自作は言語のバージョン変更やサーバー側の対応状況の変化で、作った当初は問題がなかったものが後から壊れます。外部フォームを埋め込めば、その改善は提供側で進みます。自作を続けるなら、送信時にデータベースへメールを保管し、月1回など決め打ちでテストする運用までを含めて設計します。
公開日 2026-10-10
問い合わせフォームは、自作と外部サービスの埋め込みで何が違う？
違いは入力項目や見た目ではなく、不具合対応とセキュリティ強化を誰が持ち続けるかです。自作のメールフォームはプログラムなので、動かし続ける責任が自社側に残ります。外部サービスを埋め込む形にすれば、不具合の改善やセキュリティの強化は提供する会社側で進みます。
問い合わせフォームは「設置して終わるもの」ではなく「動き続けていることを確認し続けるもの」です。ここを誰が持つかで、自作と外部埋め込みの差が出ます。
| 観点 | 自作のメールフォーム | 外部サービスの埋め込み |
|---|---|---|
| 動かなくなったときの対応 | 自社または制作を依頼した側が調査・修正する | 提供会社側で不具合の改善が進む |
| セキュリティへの対応 | 自社側で継続して手を入れる必要がある | 提供会社側で強化が進む |
| 壊れる主なきっかけ | 使っている言語のバージョン変更、サーバー側の対応状況の変化 | サイト側の環境変化の影響を受けにくい |
| 送信内容の控え | データベースに保管する仕組みを自分で持たないと残らない | 送信内容が管理画面側に残る形かどうかを確認して選ぶ |
| 見た目や項目の自由度 | 一般的に自由度は高い | サービスの仕様の範囲で組む |
自由度を取るか、動き続けることを取るか、という選び方になります。問い合わせや申し込みの受け口は、止まった時間がそのまま機会の損失になるので、自由度より継続性を優先する判断があり得ます。
作ったときは問題なかったフォームが、あとから壊れるのはなぜ？
原因はフォームそのものの変更ではなく、フォームが置かれている環境の変化です。使用している言語のバージョンが変わる、サーバー側の対応状況が変わる、といったことで、もともと不具合がなかったものが後から不具合を起こします。頻度は高くありませんが、起きるものとして扱うほうが扱いやすいです。
メールフォームは、見た目は入力欄の並びですが、中身はプログラムです。プログラムで作っているものは不具合が出るもの、という前提に立つと、対応の順番が変わります。壊れるきっかけとして実務で挙がるのは次の2つです。
- 使用している言語のバージョン変更：以前の書き方が通らなくなり、送信処理が途中で止まる
- サーバー側の対応状況の変化：これまで動いていた前提が変わり、メール送信の部分だけが動かなくなる
どちらも、サイトの原稿を直したりデザインを変えたりしたタイミングでは起きません。何もしていない期間に、外側が変わることで起きます。だから「触っていないから大丈夫」という判断が効かない領域です。
「どういうときに気づきますか」と後から追いかける視点よりも、最初から不具合は起きるものと判断して定期的にテストをする視点のほうが、現実的だと考えています。
自作をやめて外部フォームを埋め込むのは、どんな場合？
保守を続けられる体制があるかどうかで決まります。フォームを誰が見ているか曖昧な状態なら、自作をやめて外部のメールフォームを埋め込む形に寄せたほうが、放置しても壊れたままにならずに済みます。セキュリティのリスクが高まっている中で、改善が提供側で進むことは大きな差になります。
判断の目安は、次のどれに当てはまるかです。
- フォームのプログラムを誰が保守しているか、すぐに答えられない
- サイトを作ってから数年、フォーム周りに手を入れていない
- サーバーの契約や設定を管理している人が社内にいない
- 問い合わせや申し込みが、売上の入口になっている
ひとつでも当てはまるなら、外部のメールフォームを埋め込む形で対応していく選択が現実的です。自作をやめると、言語のバージョン変更やサーバー側の変化に自分で追いつく必要がなくなり、不具合の改善やセキュリティの強化は提供する会社側で進みます。
逆に、自作のままにしておく合理性があるのは、保守する人が決まっていて、環境の変化を追える場合です。その場合も、動いていることを確認する運用は別に必要になります。なお、Webサイトの脆弱性対策の考え方については公的機関が資料を公開しているので、最新の公式情報で確認してください。
フォームが壊れていることには、どうやって気づく？
気づくきっかけは主に3つです。自社サイト以外の告知サイトからは問い合わせが入るのに自社サイトのフォームからだけ入らない、アクセス解析上はフォームをクリックした人が多いのに送信まで至っていない、送信はされているのにメールが受信箱に届いていない、という状態です。
フォームが壊れているときは、問い合わせが「全体的に少ない」のではなく「ある経路だけ消える」という形で出ます。
- 自社サイトのフォームからだけ入らない：他の告知を出したサイトからは問い合わせが入っているのに、自社サイトからは入らない。この状態になったら、フォームを疑う段階です。
- クリックはあるのに送信がない：アクセス解析を入れている場合、申し込みページやフォームをクリックした人は多いのに、送信まで至っていない、実際にメールが来ていない、というケースです。
- 送信されたのにメールが届かない：フォームからメールを送信したのに、受信箱にそのメールがない。古いサイトで起きやすい形です。
3つに共通するのは、何も起きていないように見えることです。エラー画面が出るわけではないので、気づくまでの時間がそのまま空白になります。だから、気づき方を磨くより、定期的に自分で確認する形に寄せたほうが早く見つかります。
送信したのにメールが届かない問題は、どう防ぐ？
メールを送信したときに、データベース側にもメールを保管したうえで送信する仕組みを持っておくのが有効です。データベース側を見れば、どういうメールを送ったのか後から追えるため、届かなかった場合でも内容が失われません。外部サービスを使う場合は、送信内容が管理画面側に残る形かどうかを確認して選びます。
メールは、送信処理が成功しても受信箱まで届くかどうかは別の話です。そのため、届くことだけに頼らない設計にしておきます。
控えを残す仕組み
- 送信時にデータベースへ内容を保管してから、メールを送る
- 後から管理画面やデータベース側を見て、送信された内容を追える状態にする
- 外部フォームを使う場合は、送信データが残る仕様かどうかを導入前に確認する
この仕組みがあると、「メールが届かない」状態が起きたときに、その期間に来ていた問い合わせの内容が分かります。失注を止められるかは別ですが、気づいた時点で連絡を取り直せるかどうかは大きく変わります。
申し込みや問い合わせの数を増やす施策の前に、入ってきたものを落とさない状態をつくる。順番としてはそちらが先です。
フォームのテストは、どのくらいの頻度でやればいい？
告知を出したタイミングで一度テストすること、そのうえで月1回など頻度を決め打ちしてテストしておくことを勧めています。感覚的に「気になったら確認する」ではなく、日付で決めるほうが続きます。テストをしていれば、不具合が出たときにも比較的早く対応でき、被害も少なく済みます。
テストの中身は難しいものではありません。実際に送って、届くところまでを見るだけです。
- 告知やセミナー案内を公開したら、自分でフォームから送信する
- 受信箱に届いたかを確認する（迷惑メール側も見る）
- 自動返信を設定しているなら、送信者側にも届いたかを確認する
- データベースや管理画面に送信内容が残っているかを確認する
- 月1回など日付を決めて、同じ確認を繰り返す
不具合は起きるものという前提に立てば、やることは「原因を当てる」ではなく「点検の予定を持つ」になります。自作をやめて外部フォームの埋め込みに寄せたうえで、月1回の点検を運用ルールにする。この2つで、問い合わせの受け口が静かに止まっている期間をかなり短くできます。
まずは今月の点検日を決めて、カレンダーに入れるところから始めてください。
よくある質問
自作のメールフォームは、すぐに外部サービスへ切り替えたほうがいいですか？
保守を続けられる体制があるかどうかで判断します。フォームのプログラムを誰が見ているか曖昧な状態なら、外部のメールフォームを埋め込む形に寄せたほうが、不具合の改善やセキュリティの強化が提供する会社側で進むため有利です。保守する人が決まっていて環境の変化を追えるなら、自作のままでも運用できますが、その場合も動作確認の運用は別に必要になります。
フォームは触っていないのに壊れることがあるのですか？
あります。原因はフォーム側の変更ではなく、使用している言語のバージョン変更やサーバー側の対応状況の変化です。もともと不具合がなかったものが後から不具合を起こします。頻度は高くありませんが、起きるものとして前提に置いておくほうが対応が早くなります。
フォームの不具合を疑うべきなのはどんな状況ですか？
他の告知サイトからは問い合わせが入っているのに、自社サイトのフォームからだけ入らない状況になったときです。あわせて、アクセス解析でフォームをクリックした人は多いのに送信に至っていない場合、送信はされたのにメールが受信箱に届いていない場合も、フォームを疑う対象になります。
メールが届かなかった問い合わせの内容は、後から分かりますか？
送信時にデータベース側にもメールを保管する仕組みを入れていれば、どういうメールを送ったのかを後から追えます。外部フォームを使う場合は、送信内容が管理画面側に残る仕様かどうかを導入前に確認しておくと、同じことができます。
参考・出典
- 情報処理推進機構（IPA）（2026年9月時点）
関連記事
行政書士にいつ頼めばいい？依頼タイミングをホームページに書く
「顧問やってます」は書かないと伝わらない｜士業の業務内容の書き方
士業のプロフィールの書き方｜経歴で勝負できないなら思いを書く