何が共有しづらいのか
MakeのCode moduleで生成した社内ツールのHTMLは、JavaScriptの`fetch()`でMakeのWebhookを呼び出してデータを取得・更新する仕組みになっていることが多い。URLを共有してレビュワーが操作すると、Get/Post/Delete リクエストが本番のMakeシナリオに向かって発火する。公開前に`fetch()`の送信先URLを正規表現で検索（`/hook\..*\.make\.com/`）し、本番WebhookのURLをモック関数のURL（例: `https://httpbin.org/anything`）に全件置換してからアップロードする。
社内ツールプロトタイプに権限ロール（管理者/一般ユーザー/閲覧のみ）の表示切り替えが実装されている場合、URLを1本だけ送ると受け取った人が全権限を持つ管理者ビューしか見られないことがある。複数のURLを準備するか、URLパラメータで権限モードを切り替える仕組み（例: `?role=viewer`）を付けておき、各権限でどのように見えるかをセットで共有する。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
URL化する前の確認点
MakeシナリオのCode moduleにはNode.jsライクなコードが書けるため、環境変数として渡されたシークレットキーがHTML内に文字列連結でそのまま出力されているケースがある。Makeの実行結果HTMLをダウンロードし、`process.env`由来の値が展開されたシークレット文字列が残っていないかをブラウザのソース表示で確認する。
社内ツールの一覧画面がMakeのデータテーブルから取得した実データを表示している場合、そのデータに顧客の個人情報や取引先の金額が含まれることがある。公開前にデータ取得のAPIコールをブロックするか、ダミーJSON（50件程度の架空データ）を返すサービスワーカーを設定してから、個人情報がURLから閲覧できない状態を確認する。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
認証と期限の決め方
社内ツールのプロトタイプは業務フローの設計思想が詰まっており、競合企業に見られると業務効率化のアプローチが漏洩するリスクがある。社内に限定したドメイン認証でも十分だが、外部のMakeパートナーや受託開発者が関わるプロジェクトでは、許可するメールアドレスを個別に登録するメール認証の方が細かい制御ができる。
社内ツールのプロトタイプは開発サイクルが速いため、URLが変わるたびに共有し直す手間が発生しやすい。最初から期限を長め（30日）に設定しつつ、アクセスログで「誰がいつ最後に開いたか」を確認できるサービスを使うと、期限管理よりも実際の使用状況で有効期限を判断できる。
- 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
- 特定の相手だけ: パスワードまたはメール認証を使う
- 会社内だけ: 会社ドメイン認証を検討する
- 短期レビュー: 期限を設定して古いURLを残さない
共有後のフィードバック回収
社内ツールのプロトタイプには「実際に使う人（エンドユーザー）」と「承認する人（マネージャー）」の2種類のレビュワーがいることが多い。エンドユーザーには「この操作フローで毎日の業務が効率化できますか」を、マネージャーには「コスト削減の根拠となる機能が揃っていますか」を問うと、立場に応じたフィードバックが得られる。
操作フローのフィードバックは、テキストコメントよりも「どこで詰まったか」という操作ログの方が信頼度が高い。Loomのような画面収録ツールで操作を録画してもらい、特に「同じ場所を2回以上クリックしたシーン」「ページを行き来したシーン」を重点的に確認するとUIの問題箇所が明確になる。
- 確認してほしい観点を3つ以内に絞る
- 期限と返信先を明記する
- 修正後も同じURLで見られるか伝える
- 最終版と途中版が混ざらないようタイトルを付ける
よくある質問
MakeのCode moduleで生成したHTMLのダミーデータをJSONファイルで管理したい場合、どのようにHTMLから参照しますか？
同じディレクトリにdata.jsonを配置してfetch('./data.json')で読み込む方法が最もシンプル。ただしfile://プロトコルではCORSエラーになるため、URLで公開した環境で正しく動作するかを必ず確認してからアップロードする。
プロトタイプのフィードバックで「この機能はいらない」という意見が多かった場合、Makeシナリオ側も修正が必要ですか？
UIのプロトタイプ段階で機能を削除する判断であれば、HTML上からその機能のUIを取り除くだけでよく、Makeシナリオ本体の修正は後工程になる。シナリオとプロトタイプは分離して管理し、UI確定後にシナリオへの影響を評価する順序で進める。
httpbin.orgのようなテスト用エンドポイントをスタブとして使う場合、レスポンスデータをどう扱いますか？
httpbin.orgはリクエストの内容をそのままJSONで返すため、アプリが特定のレスポンス形式を期待している場合は表示が崩れる。その場合はMockoon等のローカルモックサーバーを使うか、fetchのレスポンスを上書きするJavaScriptのスタブを書いてHTMLに組み込む方法を選ぶ。