何が共有しづらいのか
フォーム付きページをHTMLファイルで渡すと、相手がローカルで開いた場合にブラウザがフォームのsubmitをブロックするケースがある一方、URLとして配信するとsubmitが通ってしまうケースがある。どちらの挙動になるかはブラウザとサーバー設定に依存するため、事前にテストしていないと本番送信が起きるリスクを見落とす。
Canva Codeはプロンプト次第でGoogle Forms埋め込みやFormspreeのactionを自動生成することがある。開発者がコードを確認せずにURLを共有すると、レビュアーがテスト送信した内容がそのまま受信ボックスに届く。HTMLを生成した直後に `form action` 属性を全検索する手順を必ずワークフローに組み込む。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
URL化する前の確認点
フォームのaction属性に `javascript:void(0)` や空の `#` を設定して送信を無効化しておくのが基本だ。さらに `<button type="submit">` を `type="button"` に変更するか、submitイベントをpreventDefaultで止めるJavaScriptを1行追加すると、UIを壊さずに誤送信を確実に防げる。
入力フィールドにautocomplete属性が残っていると、レビュアーのブラウザが過去の個人情報を自動入力してしまうことがある。デモページとして配信する際は `autocomplete="off"` をformタグに設定するか、フィールドのname属性をダミー名（`demo-email` など）に変えて実在フィールドとの衝突を避けるとよい。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
認証と期限の決め方
フォームページのレビューは社内のUI担当者やコピーライターが主な対象になることが多い。この場合はメール認証でアクセスを制限し、確認したいメンバーのメールアドレスをホワイトリストに登録する方法が管理しやすい。パスワードを使い回すリスクも避けられる。
フォームの本番リリース後もレビュー用URLが残っていると、古いUIを見た人が「これが本番だ」と勘違いするケースがある。プロジェクトの承認が完了したタイミングでレビューURLを即日失効させる運用を決めておき、期限設定機能を活用すると管理の抜け漏れが起きにくい。
- 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
- 特定の相手だけ: パスワードまたはメール認証を使う
- 会社内だけ: 会社ドメイン認証を検討する
- 短期レビュー: 期限を設定して古いURLを残さない
共有後のフィードバック回収
フォームUIのレビューでは「入力エラーメッセージの文言」「必須マークの位置」「送信ボタンのラベル」など細かい指摘が集中しやすい。コメントをGoogleスプレッドシートやNotionのテーブルに集約するルールを事前に決めておくと、修正漏れが防げる。
レビュアーに「送信ボタンは動きません」と明記した注釈をHTMLの目立つ場所に追加しておくと、「送信できなかった」という混乱を防ぎつつ、フォームのビジュアルやフローの確認に集中してもらえる。注釈はCSSで目立つ色のバナーにするのが効果的だ。
- 確認してほしい観点を3つ以内に絞る
- 期限と返信先を明記する
- 修正後も同じURLで見られるか伝える
- 最終版と途中版が混ざらないようタイトルを付ける
よくある質問
レビュアーがフォームを送信してしまった場合、データはどこに行くのか？
action属性に設定されたURLへPOSTリクエストが送信される。事前にaction属性を無効化していれば何も送られない。もし本番エンドポイントが残っていた場合は、そのAPI側のログを確認して不要な送信データを削除する対応が必要になる。
フォームの入力バリデーションも確認してもらいたいが、送信せずにテストできるか？
HTMLのブラウザネイティブバリデーション（required属性やpattern属性）はsubmitを試みた時点でフィードバックが出るため、action属性を無効化した状態でも確認できる。JavaScriptで動くカスタムバリデーションも同様に動作する。
フォームページを修正するたびにURLが変わると、テスト記録が散らばる。どうすれば防げるか？
同じスラッグで再アップロードすると同一URLのまま内容が更新されるサービスを使う。URLが固定されることでQAシートやSlackスレッドの参照先が一貫し、どの版をレビューしているかの混乱が起きない。