GitLab Pagesで公開したページを社外レビューに回すときの注意点

できること

GitLab Pagesのパブリックプロジェクトは、URLを知っている人であれば誰でもアカウントなしで閲覧できます。社外クライアントに「このURLで確認してください」とメールを送るだけで、ブラウザからすぐに開けます。PCとスマートフォンの両方で確認できるため、レスポンシブデザインのレビューにも使えます。

GitLab CI/CDによる自動デプロイを設定していれば、修正をコミットするたびにPagesに反映されます。「修正しました、同じURLで確認してください」という一言で差し替えを伝えられます。

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

できないこと

パブリックプロジェクトのGitLab Pagesは、URLが漏れれば誰でも閲覧できます。Slackに誤投稿・メールの誤送信・URLのスクリーンショット共有など、想定外のルートで情報が広がるリスクがあります。特にリリース前の製品デザインや価格改定前のLPを共有する場合は深刻です。

プライベートプロジェクトのGitLab PagesはGitLabアカウント認証が必要です。社外クライアントをメンバーに招待する必要があり、「GitLabのアカウントを作ってプロジェクトの招待メールを承諾してからURLを開いてください」という案内は、ITリテラシーが高くないクライアントには大きな摩擦となります。

認証と期限の違い

GitLab Pagesで最も手軽に「特定の人だけ」を実現しようとすれば、プロジェクトをプライベートにして相手をゲストメンバーとして招待する方法になります。ただしこの場合、GitLabアカウントの作成・メールでの招待承諾・ロールの設定という3ステップがかかります。相手が複数いる場合や入れ替わりがある場合、管理コストが増大します。

一時共有URLサービスであれば、ファイルをアップロードした後に「誰でも見てよいか」「パスワードが必要か」「いつまで有効か」を選ぶだけです。相手がGitLabアカウントを持っていなくても、パスワードを入力するだけで閲覧できます。メール認証を使えばアクセスしたメールアドレスがログに記録されるため、「誰が確認したか」の証跡も残ります。

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

差し替え・レビュー運用

GitLab Pagesを使った社外レビューで最も多い失敗は、「最終版と修正途中の版のURLが混在する」ことです。CIパイプラインが動いているため、開発者がコミットするたびにPagesが更新されます。社外レビュアーが確認したタイミングによって、見ているバージョンが異なるケースが発生します。

社外レビュー専用の共有URLを使う場合は、「社内でOKが出た版だけをアップロードする」というルールを作ることで、レビュアーが常に承認済みバージョンを確認できます。レビュー観点は「確認してほしい3点」に絞り込んでURLと一緒に送ることで、フィードバックの質が上がり修正回数を減らせます。

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

向いているケース早見表

GitLab PagesのURLをそのまま社外共有しても問題ないのは、公開可能なOSSドキュメント・発表済みのプロダクト情報・相手がGitLabアカウントを持っているエンジニア同士の技術レビューなど、情報の機密度が低いケースに限られます。

機密性が少しでもある社外レビューでは、GitLabのインフラはそのままに、共有用URLだけ専用サービスで発行する使い分けが安全です。ギガサイト便はGitLabとは独立したサービスなので、GitLabのアカウント設定を変えることなく社外共有のセキュリティを高められます。