AI活用

Base44で生成した社内ツール風プロトタイプをレビュー用URLにして共有する方法

Base44で生成した社内ツール風プロトタイプは、実際の業務フローを模倣した画面遷移やモックデータが含まれているため、社外に送り出す前のリスク管理が特に重要だ。ローカルで動かしながら関係者にスクリーンショットを送るだけでは操作感が伝わらず、かといってソースごとクラウドに置くと情報漏洩の懸念が出る。認証付きの静的URL共有サービスを使えば、操作体験を保ちながら安全にレビューできる。

何が共有しづらいのか

社内ツールプロトタイプはナビゲーション・テーブル・モーダルなどの複合的なUI要素を持つため、静的HTMLファイルでも依存するJSライブラリが多い。ファイルをzipで送ると展開後のフォルダ構造が変わってパスが壊れるケースがあり、受け手が「開けない」と報告してくるトラブルが起きやすい。HTTP(S)で配信されるURLで渡すのが確実だ。

また、モックデータとして社員名・部署名・顧客IDなどが仮データとして含まれていることがある。共有前に実在する固有名詞が使われていないかを確認しないと、受け取った社外パートナーが実データと混同するリスクがある。ダミーデータは明示的に「山田太郎(仮)」のような形式にしておくと誤解を防げる。

  • 相手がログインなしで開ける状態か確認する
  • PCとスマホで最低1回ずつ表示を確認する
  • 内部情報・個人情報・不要な外部送信が残っていないか見る
  • レビュー期限と修正時の差し替え方を決めておく

URL化する前の確認点

プロトタイプのHTMLに含まれるiframeタグを確認する。社内のConfluenceページやJiraチケットをiframeで埋め込んでいる場合、社外ネットワークからはアクセスできずエラーが表示される。iframeは削除またはプレースホルダ画像に差し替え、ページ単体で完結した状態にしてから共有する。

LocalStorageやSessionStorageに認証トークンやユーザーIDを書き込むロジックが残っていないかもチェックする。ブラウザのDevToolsでApplicationタブを開きStorage項目を確認すれば数秒で分かる。また、`fetch`や`axios`の呼び出し先が本番APIドメインになっていれば、モックレスポンスを返すJSオブジェクトに差し替えてからアップロードする。

  • HTML内の外部script・form action・iframeを確認する
  • APIキーやトークンらしき文字列がないか検索する
  • 画像・CSS・JSのパスが公開後も解決できるか見る
  • noindexと認証を混同せず、必要なら両方設定する

認証と期限の決め方

社内ツールのプロトタイプを社内メンバーだけでレビューする場合は、会社ドメイン認証が最適だ。メールドメインでアクセスを制限することで、URLが外部に漏れても自社ドメイン以外のメールアドレスでは開けない。一方、社外コンサルタントも交えてレビューする場合は、参加者全員に使えるパスワード認証に切り替える。

プロトタイプレビューのサイクルは通常1〜3週間なので、共有URLの有効期限もそれに合わせて設定する。期限後は自動失効するため、廃止されたプロトタイプが長期間アクセス可能な状態で残るリスクを避けられる。バージョンアップのたびに新しいURLを発行するより、同URLで上書き更新できるサービスのほうが関係者の混乱が少ない。

  • 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
  • 特定の相手だけ: パスワードまたはメール認証を使う
  • 会社内だけ: 会社ドメイン認証を検討する
  • 短期レビュー: 期限を設定して古いURLを残さない

共有後のフィードバック回収

社内ツールのプロトタイプレビューでは「実際の業務でこの画面遷移は自然か」「このボタンラベルは操作内容と一致しているか」など業務フロー視点の質問を送ることで、有益なフィードバックが集まりやすい。スクリーンショットに番号を振って「3番の画面について教えてください」と指定すると、回答者が混乱しない。

プロトタイプは複数回改訂されることが多いため、フィードバックシートにバージョン列を設けてどの版への意見かを記録する。「先週と同じ指摘をしたが直っていない」という状況を防ぐには、修正した点を次の共有時に変更ログとして添付するのが有効だ。

  • 確認してほしい観点を3つ以内に絞る
  • 期限と返信先を明記する
  • 修正後も同じURLで見られるか伝える
  • 最終版と途中版が混ざらないようタイトルを付ける

よくある質問

社内ツールプロトタイプにモックの社員名が入っているのですが、共有して問題ありませんか?

実在する社員名や顧客名は共有前に架空のダミー名に置き換えることを推奨します。受け取った相手が実データと誤認するリスクを防ぎ、情報漏洩懸念も回避できます。

社外コンサルタントと社内メンバーが混在するレビューではどの認証が適切ですか?

全員が使えるパスワード認証が最もシンプルです。ドメイン認証は自社メールを持たない社外パートナーが弾かれるため、混在レビューには向きません。

プロトタイプのiframeが社外ネットワークで表示されない場合の代替策は?

iframeをスクリーンショット画像に差し替えるか、該当箇所に「この領域はXXXシステムが表示されます」というプレースホルダテキストを置くと、操作感を損なわずに共有できます。

関連記事

「AI活用」の記事をもっと見る →