何が共有しづらいのか
Cursor Agentが業務システムのプロトタイプを生成する際、プロンプトに含めた業務フロー（「在庫が0になったら自動で発注」など）を説明するコメントアウトやUI上の説明文がHTMLに残る。このコメントが業務プロセスの詳細を記述したものであれば、URLを不特定多数に公開するとプロセスの内部情報が漏れる可能性がある。共有前にHTMLコメントを一通り確認して、外部に見せられない情報がないかをチェックする。
社内ツールは複数のユーザーロール（管理者・一般ユーザーなど）に応じてUIが異なることが多い。Cursor Agentがロールごとのビューを複数HTMLとして生成した場合、「どのHTMLがどのロール向けか」が分かりにくい状態になりがちだ。共有時にファイル名やコメントでロールを明示するか、index.htmlにロール選択の導線を追加してから共有する。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
URL化する前の確認点
社内ツールのプロトタイプには外部APIへのfetch呼び出しが含まれることが多い。Cursor Agentがプロンプトのコンテキストから本番のAPIエンドポイントを推測して書き込む場合があるため、JavaScriptファイルに`https://`で始まるURLがないかを全ファイル検索で確認する。見つかった場合は`console.log('API skipped')`に差し替えてからアップロードする。
社内ツールのUIにはデータテーブルや検索フィルターが多用されることが多い。Cursor Agentが生成したJavaScriptでクライアントサイドのソートや検索を実装している場合、データ件数が多すぎるとブラウザが重くなる。レビュー用には5〜10件程度のダミーデータに絞り、パフォーマンス問題ではなくUI設計を評価してもらえる状態にしてからURLを発行する。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
認証と期限の決め方
プロジェクトの関係者（社内の複数部署＋外部ベンダー）に一斉にプロトタイプを確認してもらう場合、社内向けには会社ドメイン認証、外部ベンダー向けにはパスワード認証か個別メール認証と分けて設定すると、一本のURLで関係者全員をカバーしながらアクセスを制限できる。
スプリント単位で更新するプロトタイプの場合、スプリント終了日にURLが失効するよう期限を設定する運用が効果的だ。次のスプリント開始時に新URLを発行してチームに周知する流れを繰り返すことで、古いプロトタイプが社内Wikiに蓄積されて「最新版はどれ？」という混乱を防げる。
- 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
- 特定の相手だけ: パスワードまたはメール認証を使う
- 会社内だけ: 会社ドメイン認証を検討する
- 短期レビュー: 期限を設定して古いURLを残さない
共有後のフィードバック回収
社内ツールのプロトタイプに対するフィードバック依頼では「このツールで今週中に何の業務タスクが完了できそうですか？」という問いを設定すると、実用性に直結した評価が集まる。抽象的なUIの好き嫌いではなく、業務遂行という基準でレビューしてもらうことで、開発の優先順位をつけやすい具体的な意見が返ってくる。
フィードバックをもらった後の修正履歴を管理するために、共有したURLのバージョンと変更点をNotionのページや社内Wikiにまとめておく。「あのときのフィードバックが反映されたか」を後で確認できる状態にしておくと、プロトタイプの改善が堂々巡りになることを防げる。
- 確認してほしい観点を3つ以内に絞る
- 期限と返信先を明記する
- 修正後も同じURLで見られるか伝える
- 最終版と途中版が混ざらないようタイトルを付ける
よくある質問
Cursor Agentが生成したプロトタイプを社内Wikiに埋め込んで表示させることはできるか？
多くの社内WIki（ConfluenceやNotionなど）はiframeの埋め込みをサポートしている。ギガサイト便で発行したURLをiframeのsrc属性に指定すれば、Wikiページ内でプロトタイプをインタラクティブに操作できる。ただしiframe内でのCookieセッション認証はブラウザのサードパーティCookie制限で動作しない場合がある。
プロトタイプのURLを承認者（役員）に確認してもらう際の注意点は？
役員がスマートフォンで確認することを想定し、モバイル表示を事前に確認してからURLを送る。操作説明を一文添え、「このリンクを開くとプロトタイプが見られます」とだけ書けば十分だ。長い説明書を添付するよりもシンプルに伝える方が確認してもらいやすい。
社外のシステム開発会社にプロトタイプのURLで要件確認をしてもらう場合、どの認証を選ぶべきか？
開発会社の担当者のメールアドレスが事前に分かっている場合はメール認証が最適だ。担当者が変わった場合も許可リストを更新するだけで対応できる。メールアドレスが不明または複数人いてリストが作れない場合はパスワード認証とし、パスワードを別経路で伝える。