AI活用

Makeシナリオで生成したフォーム付きページをレビュー用URLにして共有する方法

MakeシナリオでHTMLフォームを生成した場合、フォームの送信先がMakeのWebhookに設定されていることがほとんどだ。そのURLをそのままレビュワーに共有すると、テスト入力が本番のシナリオを動かしてしまう。フォームのUXを確認してもらいながら本番シナリオを守る方法を解説する。

何が共有しづらいのか

MakeシナリオのHTMLフォームは、`<form action="https://hook.eu1.make.com/xxx">`のようにMakeのWebhook URLが直接埋め込まれている。レビュワーがテスト入力して送信すると、即座にMakeのシナリオが起動し、メール送信・Slack通知・スプレッドシートへの書き込みが実行される。公開前に`action`属性の値をブランクに変えるか、`event.preventDefault()`で送信を止めてアラートを表示するJavaScriptを追加してから共有する。

Makeで生成したフォームに入力バリデーション(必須チェック、メール形式チェックなど)が実装されている場合、スマートフォンのソフトウェアキーボードがフォームフィールドを隠してしまい、エラーメッセージが表示されている間にユーザーが次の操作をできない状態になることがある。iPhoneのSafariで各フィールドを実際に入力してエラーが見えるかを確認しておく。

  • 相手がログインなしで開ける状態か確認する
  • PCとスマホで最低1回ずつ表示を確認する
  • 内部情報・個人情報・不要な外部送信が残っていないか見る
  • レビュー期限と修正時の差し替え方を決めておく

URL化する前の確認点

MakeのフォームHTMLにファイルアップロード欄(`<input type="file">`)が含まれている場合、アップロード先のストレージ(Google DriveやDropboxなど)へのAPIキーが埋め込まれているケースがある。そのキーが漏洩するとレビュワー以外のユーザーもストレージに書き込めてしまう。ファイルアップロード欄はレビュー版では削除し、「実装中の機能」という注釈テキストを代わりに表示する。

フォームに電話番号入力欄があり、国際電話番号フォーマットに対応するライブラリ(intl-tel-inputなど)を使っている場合、CDNからのスタイルシートが読み込まれないと入力欄が崩れる。ローカルで動作確認できていても、CDNブロック環境では表示が変わる可能性がある。ライブラリのCSS/JSをHTMLにインライン化してからアップロードすることで環境差異を防ぐ。

  • HTML内の外部script・form action・iframeを確認する
  • APIキーやトークンらしき文字列がないか検索する
  • 画像・CSS・JSのパスが公開後も解決できるか見る
  • noindexと認証を混同せず、必要なら両方設定する

認証と期限の決め方

フォームのレビューは「入力体験を実際に操作して確認してもらう」という性質上、スマートフォンでのアクセスが多い。パスワード認証を設定する場合、レビュワーがスマートフォンで長いパスワードを入力する手間を考え、6〜8文字の短いパスワードを設定するか、メール認証でリンクをクリックするだけでアクセスできる方式を採用するのが実用的だ。

フォームの入力フローのレビューは、最初の公開から5営業日以内に完了することが多い。それを超えると「いつのバージョンに対するフィードバックか」が分からなくなる。5営業日を期限に設定し、フィードバックを受けてMakeシナリオを修正して再生成したら、新しい版のURLをアナウンスして旧版のURLを明示的に失効させる。

  • 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
  • 特定の相手だけ: パスワードまたはメール認証を使う
  • 会社内だけ: 会社ドメイン認証を検討する
  • 短期レビュー: 期限を設定して古いURLを残さない

共有後のフィードバック回収

フォームのレビューでは「送信できた/できなかった」という結果報告だけでなく、「どの入力欄で一番時間がかかったか」「エラーが出たときに何をすればいいか分かったか」というプロセスについてのフィードバックが重要だ。共有メッセージに「入力から送信まで通しで操作してみて、迷った場面を具体的に教えてください」と書き添えると有益なコメントが得やすい。

フォームのテスト送信後に「ありがとうございました」というサンクスページが表示されるフローになっている場合、送信先をブロックしているとサンクスページに遷移しない。「このレビュー版ではフォーム送信後にサンクスページには進みません。送信ボタンを押した後のメッセージ表示(ポップアップ)を送信完了の目印にしてください」とあらかじめ案内しておく。

  • 確認してほしい観点を3つ以内に絞る
  • 期限と返信先を明記する
  • 修正後も同じURLで見られるか伝える
  • 最終版と途中版が混ざらないようタイトルを付ける

よくある質問

フォームのWebhook URLをレビュー版では削除しているため、実際の送信フローを確認できないと言われた場合はどうしますか?

本番とは別のテスト用Makeシナリオを作成し、テスト用WebhookのURLをレビュー版のフォームに設定する方法がある。テストシナリオは送信データをログに記録するだけの最小構成にすれば、本番の処理を動かさずに送信フロー全体を確認できる。

フォームのモバイル表示を確認するのに、実機がなくても方法はありますか?

ChromeのDevToolsでデバイスエミュレーションモード(F12→スマホアイコン)を使えば、iPhone・Androidの各サイズで表示確認ができる。ただしソフトウェアキーボードの挙動は実機でのみ正確に確認できるため、重要な入力フローは実機テストを推奨する。

フォームにreCAPTCHAが含まれている場合、レビュー用の別ドメインで動作させる方法は?

Google reCAPTCHAの管理コンソールでレビュー用ドメインを許可リストに追加すれば動作する。ドメインの追加は数分で反映されるため、レビューURLが確定したタイミングで追加し、レビュー終了後に削除する手順で管理する。

関連記事

「AI活用」の記事をもっと見る →