AI活用

Create.xyzで生成した管理画面モックをレビュー用URLにして共有する方法

Create.xyzで管理画面のモックを生成したあと、それをどうやって関係者に見せるかで詰まるケースは少なくない。GitHubPagesへのデプロイは設定手順が煩雑で、Notionへの埋め込みではインタラクションが失われる。HTML単体をURLとして安全に配信できるサービスを使うと、モックの生成から共有まで数分で完結する。

何が共有しづらいのか

管理画面のモックには「注文ID:#00123」「売上合計:¥3,420,000」のようなリアルに見えるダミーデータが含まれやすい。Create.xyzがプロンプトに基づいて自動生成したサンプルデータでも、社外の目には実際の業績情報のように映ることがある。共有時は「すべてのデータはフィクションです」というバナーをページ上部に追加しておくと誤解を防げる。

管理画面モックを静的HTMLとして扱う場合でも、JavaScriptで動的に画面を切り替えるSPA的な構成になっていることが多い。このようなHTMLはサーバーを立てずにファイル共有するとルーティングが機能せず、「ページが見つかりません」という状態になる。URLとして配信することでこの制約を回避できる。

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

URL化する前の確認点

Create.xyzが生成する管理画面HTMLには、モック用のREST APIを叩く `fetch()` 呼び出しが含まれることがある。このAPIエンドポイントが実在のサービス(Airtable・Firebase・Supabaseなど)を指している場合、レビュアーのアクセスが実際のデータベースに読み取りリクエストを送信する。エンドポイントをモックサーバーURLに差し替えるか、fetchをコメントアウトしてからURLを発行する。

管理画面特有の確認点として、テーブルのソートやフィルタ機能が動くかどうかがある。JavaScriptでDOMを操作してソートを実装している場合、ライブラリのバージョンやCDN依存で動作が変わることがある。アップロード前にローカルのブラウザで一通りの操作を確認し、特に問題がある箇所はコメントとして共有URLの注釈に残しておく。

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

認証と期限の決め方

管理画面モックのレビュアーが社内のエンジニアやPMだけであれば、会社ドメイン認証が最も管理しやすい。一方、外部のUI/UXコンサルタントを招いてフィードバックをもらう場合は、個別のパスワードを発行して有効期限を設けた上でURL・パスワードを別々のチャネルで送る。

管理画面モックのレビュー期間は、仕様確定のタイムラインと合わせて設定する。スプリントのレビュー会議が金曜日に設定されているなら、会議の翌日(土曜日)の深夜に自動失効する設定にすると、古いURLが来週のスプリントに持ち越されずに済む。

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

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

管理画面のレビューでは「この操作は管理者だけに制限したい」「このカラムは不要」のような仕様変更要望が多く出る。これをUIフィードバックと混在させると対応方針が複雑になるため、「見た目・操作感の意見」と「機能要件の変更」を分けて収集するフォームやテンプレートを用意しておくと整理しやすい。

管理画面モックは多くの画面遷移を含むため、どの画面について言及しているかが曖昧なフィードバックが来やすい。共有するURLに `?page=users` のようなハッシュやパラメータで画面を指定できる仕組みがある場合は、フィードバック時にURLを添付してもらうよう依頼するとスレッドの追跡が楽になる。

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

よくある質問

Create.xyzで生成した管理画面モックに実際の会社ロゴを使っている。共有URLに貼っても著作権上問題ないか?

自社ロゴを使用する分には問題ないが、クライアントや他社のロゴを許可なく使用している場合は削除またはダミーロゴに置き換える必要がある。レビュー目的の内部共有であっても、認証なしの公開URLで配信すると著作権侵害のリスクが高まる。

モックの承認後、同じHTMLを本番環境のベースとして使える場合、レビューURLはいつ削除すべきか?

本番環境のURLが確定して関係者に通知した時点でレビューURLを失効させる。本番とレビューが同時に閲覧可能な状態は、外部から見たときに混乱を招く。承認完了のメッセージと同時に失効させる運用がわかりやすい。

管理画面の画面数が多く、1つのHTMLに全部入れると重い。複数に分割して共有する方法は?

HTMLを機能別に分割して(例:ユーザー管理画面・注文管理画面)それぞれ別のURLで発行する。共有メッセージにURLの一覧とどの画面を指すかを明示することで、レビュアーが迷わずに済む。

関連記事

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