何が共有しづらいのか
管理画面モックにはデータグリッドやモーダルダイアログなどのインタラクティブな要素が含まれることが多く、静的スクリーンショットでは動作を確認できない。URLで共有すると、行クリックで詳細パネルが開く動作や、ドロップダウンの展開状態なども実際に操作してレビューしてもらえる。
Gemini CLIで出力された管理画面HTMLは、TailwindのPlayCDNや外部アイコンライブラリ（Font Awesome等）を参照していることがある。これらのCDNURLが変更・廃止されると表示が崩れるため、共有前にCDNのURLが現在も有効かブラウザで確認しておく。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
URL化する前の確認点
管理画面モックのHTMLでは、ユーザー名・メールアドレス・権限ロールなどのダミーデータがテーブルに入力されていることが多い。「admin@company.co.jp」のような実在しそうなメールアドレスが含まれていると、見た人が実際のデータと誤解する可能性がある。`user@example.com`や「テストユーザー」など、明らかにダミーとわかる値に統一する。
Gemini CLIが生成したJavaScriptにlocalStorageへの書き込みや`window.open`呼び出しが含まれている場合、公開後に意図しない挙動を引き起こすことがある。DevToolsのSourcesタブでJSを確認し、副作用のある処理があれば削除またはコメントアウトしてから公開する。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
認証と期限の決め方
管理画面モックはサービスの内部設計を反映しているため、競合他社や関係者外への漏洩リスクが特に高い。社内レビューなら会社ドメイン認証、外部ベンダーとのレビューならパスワード認証を選び、パスワードはレビュー終了後すぐに変更するか無効化する。
機能追加のたびにモックを更新する場合、バージョン番号を付けたURLを都度発行し、過去バージョンは期限を設定して自動無効化する運用が管理しやすい。v1・v2と積み重ねるのではなく、レビューが終わったバージョンは明示的に閉じることで、社内Confluenceなどに古いURLが残り続けることを防げる。
- 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
- 特定の相手だけ: パスワードまたはメール認証を使う
- 会社内だけ: 会社ドメイン認証を検討する
- 短期レビュー: 期限を設定して古いURLを残さない
共有後のフィードバック回収
管理画面レビューでは「情報の優先順位が適切か」「よく使う機能にすぐアクセスできるか」という観点でのフィードバックが開発に直結する。「ユーザー管理ページで最初に目に入る情報は何ですか」という具体的な質問を添えると、UIの視線誘導についての有益なコメントが返ってきやすい。
フィードバックを収集する期限は、次のスプリント開始前日に設定するのが現実的だ。共有メッセージに「○月○日までにSlackスレッドへ返信ください。それ以降の意見は次バージョンで反映します」と明記すると、フィードバック収集が長引く問題を防げる。
- 確認してほしい観点を3つ以内に絞る
- 期限と返信先を明記する
- 修正後も同じURLで見られるか伝える
- 最終版と途中版が混ざらないようタイトルを付ける
よくある質問
管理画面モックのテーブルデータに実在しそうなメールアドレスが含まれている場合の対処法は？
全ての実在しそうなメールアドレスを`user1@example.com`のような例示用ドメインに置き換えてください。HTMLをテキストエディタで開き「@」で検索すると漏れなくチェックできます。
外部ベンダーとの管理画面レビュー後にURLを無効化するタイミングはいつですか？
レビューミーティング当日の終了後すぐに無効化するのが理想です。共有ツールの有効期限機能でミーティング翌日の0時を期限にあらかじめ設定しておけば、手動での削除を忘れても自動で閉じられます。
管理画面モックをバージョン管理しながら共有するには？
URLのファイル名やパスにv1・v2などのバージョン番号を含めて発行してください。各バージョンに個別の有効期限を設定し、最新バージョンのURLだけをSlackやドキュメントにリンクしてその他は無効化する運用が整理しやすいです。