よくある原因
送信先が意図と異なる問題の報告パターンは大きく3つです。「送信後に見知らぬURLに飛んだ」「送信したがページに何も変化がなかった」「エラーページが表示された」——それぞれ原因が異なります。最初の確認依頼で「送信後に何が起きたか」を詳しく教えてもらうことが診断の出発点になります。
相手が送信後のURLを覚えていない場合でも、ブラウザの戻るボタンで前のページに戻れるかどうかを確認してもらうことで情報が得られます。GETメソッドで送信した場合はURLにフォームデータが付くため、遷移先のURLを教えてもらうとaction属性がそのまま読み取れます。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
自分側で確認すること
相手から報告を受けたらすぐにHTMLのform action属性を自分で確認します。プレースホルダーが残っていないか・想定したエンドポイントのURLが正確に設定されているかを照合します。明らかにaction属性のミスなら相手に確認依頼を出す前に修正してURLを再共有するほうが速く解決できます。
修正後に自分でシークレットウィンドウからフォームを送信してNetworkタブで実際のリクエスト先を確認します。管理側のメールや受信ログにデータが届いていることを確認してから相手に「修正しました、再度お試しください」と伝えます。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
相手側で確認すること
確認依頼メッセージに含める質問：「①送信ボタンを押した後にどんなページ・画面が表示されましたか（URLまたはスクリーンショットをいただけると助かります）、②ブラウザは何をご使用ですか、③もう一度送信を試みる場合は送信前にブラウザのNetworkタブ（F12→Network）を開いた状態で実行し、表示されたURLをコピーして教えてください」。
相手がITに不慣れな場合、Networkタブの開き方は難しいため「送信後に表示された画面のスクリーンショットを送ってください」に絞ります。URLが写っていれば十分な情報が得られることがほとんどです。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
再発防止の運用
フォーム付きHTMLを公開する前に、自分で全ての送信パターン（正常・必須項目未入力・文字数超過など）をテストする習慣をつけます。特に送信後の遷移先ページまで確認し、意図したURLに遷移しているかを必ずチェックします。
確認依頼のテンプレートをNotionやメモアプリに保存し、フォームトラブルが報告されたときに即コピペで送れる状態を維持します。「状況を教えてもらう→自分で原因を調査する→修正して再共有する」という3ステップのフローをチームの標準手順として定めておくと、属人化を防ぎ誰でも対応できる体制が整います。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
よくある質問
相手から「送信したら404ページになった」と言われました。どう対応すればよいですか？
form actionに設定したURLにエンドポイントが存在しないか、パスのタイプミスの可能性が高いです。HTMLのaction属性を確認し、サーバー側でそのパスへのPOSTを受け付けているか確認してください。正しいパスに修正してHTMLを再公開するか、ギガサイト便のURL差し替え機能で最新版を配信します。
相手が送信後に「処理中」のままずっとページが変わらないと言っています。
サーバー側のエンドポイントが存在するがレスポンスを返していないか、JavaScriptのfetchがタイムアウトしている可能性があります。開発者ツールのNetworkタブでリクエストのステータスを確認してもらうか、別のシンプルなエンドポイントに差し替えて動作するかテストしてください。
確認依頼を出すことなくフォームの送信先問題を解決する方法はありますか？
ギガサイト便などのプレビュー機能を使い、共有前に自分で複数の端末・ブラウザからテスト送信を行うことで、多くの問題を公開前に発見できます。問題発覚後は同じURLで修正版を配信できるサービスを使うと、相手への再送が不要になりトラブル対応の工数を大幅に削減できます。