何が共有しづらいのか
社内ツールのプロトタイプをlocalhost:3000で動かして「確認してください」とSlackに書いても、同じネットワークにいないメンバーや在宅勤務者はそのURLにアクセスできない。毎回スクリーンショットを送る方法では、テーブルのソート操作やモーダルの開閉などインタラクションを伝えられない。URLで共有することで、操作感まで含めた本来のプロトタイプ体験を届けられる。
Claude Codeが社内ツールのHTMLを生成する際、プロンプトに含めたユースケースの例（「営業が案件ステータスを管理する」など）をそのままダミーデータとしてテーブルに埋める。案件名や担当者名が実在の業務に紐付いたものでなくても、社外の人がアクセスできる状態でアップロードすることにリスクを感じる場合は、ダミーデータを架空のものに置き換えてから共有する。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
URL化する前の確認点
社内ツールのプロトタイプにはCRUD操作のUIが含まれることが多い。「保存」ボタンや「削除」ボタンが本物のAPIに繋がっていないかを確認する。Claude Codeがfetch()でREST APIを呼ぶコードを自動生成している場合、そのURLが本番環境のエンドポイントでないことを確認してから発行する。開発環境のAPIでも、外部からアクセスされると予期しないデータ変更が起きる。
社内ツールのUIがIE/Edgeなど特定のブラウザ要件を持つ環境向けに設計されている場合、ChromeでURLを開くと表示が異なる可能性がある。レビュアーに「Chromeでの表示を前提にレビューしてください」と明示するか、事前に複数ブラウザで確認して差異がないことを確かめてからURLを共有する。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
認証と期限の決め方
同一チームの開発メンバーのみに見せるプロトタイプなら、会社ドメイン（例：`@yourcompany.co.jp`のメールアドレスを持つ人のみ）でのアクセス制限が最も運用しやすい。チームに新メンバーが加わっても、会社のメールアドレスを持っていれば自動的にアクセスできるため、アクセスリストを更新する手間が不要だ。
「今週中に確認してほしい」という短期レビューには、URLの有効期限を金曜日の終業時刻に合わせて設定する方法が実践的だ。期限が明確だとレビュアーも先延ばしにしにくくなり、期限後は自動で失効するため古いプロトタイプが残り続けるリスクも消える。
- 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
- 特定の相手だけ: パスワードまたはメール認証を使う
- 会社内だけ: 会社ドメイン認証を検討する
- 短期レビュー: 期限を設定して古いURLを残さない
共有後のフィードバック回収
社内ツールのプロトタイプレビューでは「このツールで自分の今の業務フローのどのステップが楽になるか」を聞くと、実用性に関する具体的な意見が得られる。「使いやすいですか？」という抽象的な問いよりも、実際の業務に引きつけた質問の方がフィードバックの質が上がる。
エンジニアとビジネス担当者が混在するレビュアーグループに同じURLを共有する場合、見てほしい観点を役割別に分けると良い。「エンジニアの方へ：APIとのつなぎ込みで懸念点があれば指摘してください」「業務担当者の方へ：このUI上でご自身の業務フローを1周できますか？」のように役割を分けた依頼文を添えると、両者から質の高いフィードバックが得られる。
- 確認してほしい観点を3つ以内に絞る
- 期限と返信先を明記する
- 修正後も同じURLで見られるか伝える
- 最終版と途中版が混ざらないようタイトルを付ける
よくある質問
プロトタイプのURLを共有したが相手のブラウザでCSSが崩れている報告があった。原因は？
相対パスで参照しているCSSファイルがZIPのフォルダ構造と一致していないか、CDNからのCSS読み込みがブラウザのセキュリティ設定でブロックされている可能性が高い。全ファイルを同一フォルダに置いてZIPにまとめ直すか、CSSをHTML内にインライン化すると解決しやすい。
Claudeが生成したコードにfetch()が含まれているが、本番APIに繋がっていないか確認する方法は？
ブラウザの開発者ツールのNetworkタブを開いた状態で全操作を一巡し、外部への通信が発生していないか確認する。本番ドメインへのリクエストが表示された場合は、そのURLをローカルのモックエンドポイントか空の関数に差し替えてから再アップロードする。
レビュー期間中に大きな仕様変更が入った場合、既存のURLはどうすればよいか？
既存URLを期限切れにして無効化し、修正後のプロトタイプを新規URLで発行するのがシンプルだ。旧URLへのアクセスが自動で新URLにリダイレクトされるわけではないため、レビュアーへの通知で「旧URLは廃止しました。新URLはこちらです」と明確に伝える。