熊取町のお問い合わせフォーム不具合｜未着を切り分ける復旧手順

「フォームから送った」と電話で言われたのに、社内の受信箱には見当たらない。送信ボタンを押しても画面が進まない。自動返信は届くのに、担当者への通知だけ来ない。お問い合わせフォームの不具合は、利用者側では送信できたように見えることがあり、発見が遅れやすい障害です。

慌ててフォームやメール設定を同時に変えると、どの変更で直ったか分からなくなります。まず問い合わせの代替窓口を確保し、症状、発生時刻、到達地点を記録します。そのうえで、ブラウザ、Webサイト、送信処理、メール配送、受信設定、社内確認の順に切り分けます。

この記事では、熊取町で店舗、事務所、採用、見積もり、予約等の問い合わせをWebで受ける事業者に向けて、安全な初動、社内テスト、外注へ渡す資料、復旧の合格条件、再発防止を解説します。画面だけで原因を断定せず、個人情報や不正アクセスの兆候がある場合に通常対応を止める境界も明確にします。

最初の30分は「止血・記録・連絡」に使う

原因調査より先に、問い合わせを受けられる状態を作ります。問い合わせページの上部やサイト共通のお知らせに、電話等の代替方法、対応時間、返信目安を表示します。メールアドレスを公開する場合は迷惑メール対策や担当者の受信体制も確認します。

初動は次の順です。

フォームの新規利用を続けてよいか責任者が判断する
電話等の代替窓口と受付時間を案内する
発見日時、症状、申告者、影響するフォームを記録する
直前の更新、設定変更、契約変更、担当変更を確認する
サイト・メール・個人情報の担当者へ連絡する
調査中の変更を一つの窓口で管理する

「調査中」と表示する場合、復旧時刻を根拠なく約束しません。現在使える連絡方法と、既に送信した人が再連絡すべきかを具体的に示します。復旧後は暫定案内を外す担当と日時も記録します。

個人情報や不正アクセスの兆候があれば通常テストを止める

次の兆候がある場合は、テスト送信を繰り返したり、ログを削除したり、プラグイン等を無計画に更新したりしません。

他人の問い合わせ内容が画面やメールに表示された
本来と違う宛先へ個人情報が送られた
身に覚えのない管理者、送信先、転送設定がある
フォームから大量の迷惑メールが送信された可能性がある
サイトの改ざん、警告、未知のファイルや処理が見つかった
管理画面へ入れない、または操作履歴が不自然である
ログに機微な情報が過剰に残っている

この場合は、日時、画面、メールヘッダー、ログ等を可能な範囲で保全し、社内責任者、現在の保守先、サーバー・メール事業者、必要に応じてセキュリティ専門家へ連絡します。個人情報保護委員会は、一定の漏えい等について報告と本人通知が必要となる制度、報告方法、事例を公開しています。個別事案の報告要否は、扱った情報、原因、影響範囲等を確認して判断します。

症状を六つに分けると調査先が見える

「フォームが壊れた」という一語では、どこまで処理が進んだか分かりません。利用者が見た結果と、社内で確認できた結果を分けます。

症状	利用者側の見え方	最初に確認する場所	残す証拠
表示不能	ページが開かない・崩れる	URL、端末、ブラウザ、サイト状態	画面、時刻、URL
入力不能	項目を選べない・エラーが消えない	必須条件、入力形式、JavaScript	入力手順、項目、画面
送信不能	ボタン後に進まない・エラー	通信、アプリ、保護機能	エラー文、時刻、端末
完了表示のみ	完了したが何も届かない	送信ログ、保存先、メール配送	受付番号、送信時刻
自動返信未着	管理者通知は来る	返信先、認証、迷惑メール	宛先ドメイン、メールヘッダー
管理者通知未着	利用者には返信が来る	通知先、転送、受信ルール	宛先一覧、受信ログ

同じ送信で、自動返信と管理者通知は別のメールとして処理されることがあります。一方が届いたから、もう一方も正しいとは限りません。「どの画面まで進み、どの記録とメールが存在するか」を一件ずつ追います。

問い合わせが届くまでの経路を一本の図として考える

フォーム送信は、画面から受信箱へ直接届くわけではありません。おおむね次の経路を通ります。

利用者のブラウザが入力内容を送る
Webサーバー・アプリケーションが内容を検証する
データを保存し、受付番号やログを残す
メール送信サービスへ通知を渡す
受信側メールサーバーが受け入れる、拒否する、保留する
迷惑メール、隔離、転送、振り分けルールを通る
担当者が受信箱を確認し、対応済みを記録する

「完了画面が出た」は、1と2が一部成功した可能性を示すだけです。3以降を保証しません。逆に、メールが届かなくても、サイト内に送信記録が残っている場合があります。利用しているフォーム、CMS、サーバー、メールサービスの仕様に合わせて確認します。

テスト送信は識別できるダミー情報で行う

テストには実在顧客の氏名、電話番号、相談内容を使いません。専用メールアドレス等を用い、件名や本文へ「TEST」、日付、連番を入れて本番問い合わせと区別します。

記録する項目は次のとおりです。

テスト番号
実施日時とタイムゾーン
対象フォームのURL
端末、OS、ブラウザ、回線
入力した項目と添付の有無
完了画面、受付番号、エラー全文
自動返信の到着時刻
管理者通知の到着時刻
迷惑メール、隔離、転送先の結果
サイト内の送信記録・ログの有無
テスト後に行った変更

一度に複数の設定を変えず、一変更、一テスト、一記録で進めます。大量送信や短時間の連続試験は、迷惑メール判定やレート制限を招く可能性があります。保守先と件数・間隔を決めます。

端末・入力条件の違いを最小限で比較する

画面操作の不具合は、特定の端末や入力でだけ起きることがあります。最初から全機種を試すのではなく、差が分かる組み合わせを選びます。

比較	分かること	注意点
PCとスマートフォン	画面幅・タッチ操作の影響	同じ入力内容で比べる
通常表示とプライベート表示	キャッシュ・拡張機能の影響	ログイン状態が変わる
社内回線と携帯回線	ネットワーク・保護機能の影響	不正な回避をしない
短い入力と上限付近	文字数・形式の影響	実在情報を使わない
添付なしと添付あり	容量・形式・保護機能の影響	安全なテストファイルを使う

エラー表示は要約せず、そのまま記録します。ただし画面写真へ個人情報、管理画面URL、秘密鍵、パスワード等が写らないよう確認します。

メール未着は受信箱だけで判断しない

メールが見当たらない場合、送信されていない、受信側に拒否された、迷惑メールや隔離へ入った、転送で失敗した、振り分け先を担当者が見ていない等の可能性があります。

社内では次を確認します。

宛先の綴りと、現在の担当者・グループ
迷惑メール、隔離、削除済み、アーカイブ
転送先、共有メールボックス、振り分けルール
容量超過、アカウント停止、契約変更
自動返信と管理者通知の送信元・返信先
受信日時ではなく、テスト送信時刻での検索
メールヘッダーと配信エラー通知

受信できないからといって、同じ通知を複数の個人メールへ無制限に転送すると、個人情報の保管場所が増えます。必要な担当、保持期間、退職時の停止を決めます。

SPF・DKIM・DMARCは現在の送信元を確認してから触る

Gmailのメール送信者ガイドラインは、送信者にSPFまたはDKIM等の要件を示し、一括送信者にはSPF・DKIM・DMARC等の追加要件を示しています。認証が不足すると、迷惑メール分類や拒否の可能性があります。

ただし、DNSへ設定を一行追加すれば終わるとは限りません。自社ドメインから送るフォーム、通常メール、予約、請求、メール配信等の送信元を一覧にします。誤ったSPF変更やDMARC強制は、正常なメールまで止める可能性があります。

外注へは次を確認してもらいます。

From、Return-Path、DKIM署名の各ドメイン
フォームが利用する送信サービス・IP
SPFへ含めるべき全送信元
DKIM鍵と署名の管理者
DMARCレポートの受取先と確認担当
転送による認証への影響
TLS、DNSの正引き・逆引き等のサービス要件

設定変更前のDNSレコードを保存し、反映待ち時間、確認方法、戻す手順を決めます。メールサービスやDNSの管理者が不明なら、先に契約名義と権限を確認します。

フォームの安全性を「届くこと」だけで終わらせない

お問い合わせフォームは、利用者入力を処理し、管理者へ通知するWebアプリケーションです。IPAの「安全なウェブサイトの作り方」は、メールヘッダ・インジェクションを含む脆弱性と対策を解説しています。

復旧相談では、次の安全項目も範囲に含むか確認します。

宛先やメールヘッダーを利用者入力から自由に変更できない
サーバー側でも入力値を検証する
確認画面やエラー画面に他人の情報を出さない
連続送信・自動送信への対策を持つ
添付ファイルの形式、容量、保存、検査を決める
管理画面・ログ・データの閲覧権限を限定する
通信をHTTPSで保護する
CMS、プラグイン、実行環境を保守対象にする

見た目だけ直っても、送信先を外部入力へ依存させる等の危険な実装は残せません。根本修正と一時的な回避策を区別し、一時対応には終了条件を付けます。

入力エラーは利用者が直せる言葉で示す

送信機能が正常でも、利用者がエラーを解消できなければ問い合わせは完了しません。デジタル庁のウェブアクセシビリティ導入ガイドブックも参照し、次を確認します。

必須・任意を項目名で分かるようにする
入力形式や文字数を入力前に示す
エラー箇所の近くに理由と直し方を表示する
色だけでエラーを伝えない
正常に入力した内容をエラー時に保持する
キーボードと読み上げでも項目・エラーを追える
スマートフォンでボタンや入力欄が隠れない
送信中、完了、失敗の状態を区別する

セキュリティ対策のために「エラー」とだけ表示する場合も、利用者が再試行すべきか、時間を置くべきか、代替窓口へ進むべきかは示せます。内部構成や秘密情報を画面へ出さず、次の行動を案内します。

外注へ渡す調査票を一枚にまとめる

相談時に全情報がそろっていなくても構いません。分かる項目と未確認を区別します。

項目	書く内容	目的
影響範囲	対象URL、フォーム名、対象業務	優先順位を決める
症状	六分類と具体的な結果	調査先を絞る
発生時期	最終成功、最初の失敗、発見日時	変更履歴と照合する
再現条件	端末、入力、添付、回線	条件依存を判断する
到達状況	完了、保存、自動返信、通知	停止地点を探す
直前変更	CMS、DNS、メール、担当、契約	原因候補を整理する
管理権限	CMS、サーバー、DNS、メール	調査可否を確認する
希望	暫定復旧、原因特定、恒久対策	見積範囲を決める

パスワードや秘密鍵を調査票の本文へ書きません。作業者ごとのアカウント、最小権限、安全な受け渡し方法、停止期限を決めます。

見積もりは調査・復旧・恒久対策を分けて読む

「フォーム修正一式」では、何が完成するか判断できません。見積もりは少なくとも次へ分けます。

再現確認とログ・設定の調査
代替窓口・一時停止等の暫定対応
画面、入力、送信処理の修正
メールサービス、DNS認証、受信ルールの調整
セキュリティ上の原因・影響調査
PC・スマートフォン・複数宛先のテスト
バックアップ、反映、切り戻し
報告書、設定一覧、運用手順の引き渡し
復旧後の監視期間と再発時の対応

費用は、原因の数、管理権限の所在、ログの有無、外部サービス、個人情報、緊急度で変わります。調査だけで原因が特定できない場合の上限、次の承認点、追加費用の条件も確認します。

復旧の合格条件を送信前に決める

「一度届いた」だけでは、復旧判定として弱い場合があります。業務に合う代表条件を選びます。

条件	確認内容
基本送信	PC・スマートフォンで完了する
入力エラー	間違いを直せ、入力済み内容が保たれる
自動返信	正しい宛先、件名、内容、返信先で届く
管理者通知	指定担当・共有箱へ届き、対応できる
記録	受付番号、ログ、保存内容が一致する
例外	添付、長文、複数選択等の対象条件で動く
代替窓口	障害案内を外しても連絡方法が分かる
安全	他人の情報や内部エラーを表示しない