何が共有しづらいのか
社内ツールのプロトタイプはHTMLファイルをそのまま社内メールに添付することが多いが、添付ファイルはセキュリティポリシーでブロックされるケースが増えている。URLで共有すれば添付なしでリンクを送るだけで良く、モバイルからも同じURLで操作できる。
Gemini CLIが出力するプロトタイプには、指示したサンプルデータ（例：「社員数が10名の会社のダッシュボードを作ってください」）がそのままHTMLに入っていることがある。その数値や組織名が現実の自社に近いと、関係者が本番データと誤解するリスクがある。共有前にデータが明らかにダミーとわかる内容か確認する。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
URL化する前の確認点
社内ツールプロトタイプのHTMLで`localStorage.setItem`や`sessionStorage`を使っているコードがある場合、レビュアーがブラウザに意図しないデータを書き込む可能性がある。ストレージへの書き込み処理はコメントアウトするか、読み込み専用のモックデータ（定数配列）に差し替えてから公開する。
複数タブやページで構成されるプロトタイプは、Gemini CLIがページ間のリンクを相対パスで生成することが多い。アップロード先のパス構成によってはリンク先が404になるため、フォルダごとZIPにまとめてアップロードするか、単一HTMLにSPAとして統合してからURL化する。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
認証と期限の決め方
社内業務フローを反映したプロトタイプは事業の内部情報に近く、社外漏洩を防ぐために会社ドメイン認証は必須と考える。人事・経理などセンシティブな業務フローを含む場合は、さらにメール認証で閲覧者を担当者に限定し、アクセスログで誰が確認したかを追跡できる状態にする。
プロトタイプの有効期限は部署間のレビュー会議日程に合わせて設定する。会議の前日に期限が切れると当日に確認できなくなるため、会議日の翌日を期限にするのが現実的だ。レビューが2週間以上続く場合は期限を延長するか、最新版のURLを再発行して古いURLを無効化する。
- 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
- 特定の相手だけ: パスワードまたはメール認証を使う
- 会社内だけ: 会社ドメイン認証を検討する
- 短期レビュー: 期限を設定して古いURLを残さない
共有後のフィードバック回収
社内ツールのプロトタイプレビューでは「このツールを使って自分の業務のどのステップが変わるか」をレビュアーに考えてもらうのが効果的だ。「現在は何分かかっている作業がこのツールで何分になりますか」という具体的な質問を添えると、ROI試算に使えるフィードバックが集まる。
部署ごとに異なる業務視点があるため、共有先を部署ごとに分けて依頼内容も変えると質の高いフィードバックが得られる。例えば営業部門には「顧客情報への素早いアクセス」、経理部門には「承認フローの分かりやすさ」という異なる観点を依頼すると、それぞれの部署が本当に困っている点が浮かび上がる。
- 確認してほしい観点を3つ以内に絞る
- 期限と返信先を明記する
- 修正後も同じURLで見られるか伝える
- 最終版と途中版が混ざらないようタイトルを付ける
よくある質問
Gemini CLIが生成したプロトタイプにlocalStorageへの書き込みがある場合の対処法は？
`localStorage.setItem`の呼び出し行をコメントアウトし、初期データを`const mockData = [...]`のような定数として直接定義してください。レビュアーのブラウザにデータが残らないため、複数人が同じURLで独立してレビューできます。
社内ツールのプロトタイプで人事情報が含まれる場合、誰まで閲覧を許可すべきですか？
人事・経営層など情報取扱いの権限がある担当者に限定してください。メール認証で個別招待し、アクセスログで閲覧者を把握できる状態にしたうえで、レビュー完了後は速やかにURLを無効化してください。
部署ごとに異なる観点でレビューしてもらうには、URLを分けるべきですか？
HTMLの内容が同じなら同一URLを使って構いません。ただし閲覧者が誰かをアクセスログで把握したい場合は部署ごとに別URLを発行してください。依頼メッセージで各部署の確認観点を変えることが重要です。