GitLab Pagesと認証付きHTML共有サービスの違い｜レビュー用途で選ぶ基準

できること

GitLab PagesはGitLab CI/CDパイプラインの一環として静的ファイルを自動デプロイします。`.gitlab-ci.yml`にpagesジョブを定義するだけでビルドと公開が連動し、mainへのマージ時に本番反映・featureブランチのMR時にプレビュー生成という運用を自動化できます。

GitLab.comのPagesはHTTPS付きで無料提供されています。カスタムドメインの設定もダッシュボードから行え、Let's Encryptの証明書自動更新も対応しています。社内のGitLabセルフホスト環境でもPagesを有効にすれば、同様の機能を閉じたネットワーク内で利用できます。

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

できないこと

GitLab Pagesには、GitLab.comのパブリックプロジェクトの場合、URLを知っている人は誰でも閲覧できる状態になります。プライベートプロジェクトのPagesはGitLabのアカウント認証が必要になりますが、相手がGitLabアカウントを持っていない場合は閲覧できません。社外クライアントに「GitLabアカウントを作ってください」と依頼するのは現実的ではありません。

公開期限を自動的に切る機能も標準では存在しません。CI/CDパイプラインに手動でジョブを追加すれば日時指定の削除は実現できますが、設定に時間がかかります。案件単位でURLの有効期限を管理したい用途には不向きです。

認証と期限の違い

GitLab PagesにはAccess Control機能があり、プロジェクトのメンバーだけがPagesにアクセスできるよう設定できます。しかしこれはGitLabアカウントと紐付いた認証であり、社外クライアントをGitLabのプロジェクトメンバーとして招待しなければなりません。招待メールの送受信・アカウント設定など、クライアント側にも手間が生じます。

ギガサイト便のような一時共有サービスでは、ファイルをアップロードした直後にパスワードと期限をまとめて設定し、URLを発行します。クライアントはGitLabのアカウント不要でパスワードを入力するだけで確認できます。会社ドメイン認証を使えば、特定の企業ドメインのメールアドレス保有者だけに絞ることも可能です。

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

差し替え・レビュー運用

GitLab Pagesで差し替えを行う場合、コミットをプッシュしてCIパイプラインが完了するまで反映を待ちます。GitLab.comのランナーを使う場合、パイプラインのキューによっては3〜10分かかることもあります。頻繁な微修正があるレビューフェーズでは待ち時間が積み重なります。

一時共有URLサービスへの差し替えはZIPの再アップロードのみで完了し、URLは変わりません。クライアントが同じブックマークで最新版を確認できるため、「URLが変わりました」の連絡が不要になります。GitLab Pagesを社内インフラとして使いながら、外部提出は別ツールで行う役割分担が最も運用コストを下げます。

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

向いているケース早見表

GitLab Pagesが適するのは、GitLabを開発インフラとして採用している組織の社内ステージング・OSSドキュメントのパブリック公開・セルフホストGitLabを使うエンタープライズのイントラネット向け静的配信などです。

認証付き一時共有サービスが適するのは、GitLabアカウントを持たない社外クライアントへのデザインレビュー提出・期日付きの承認フロー・情報漏洩を避けたい競合秘匿コンテンツの確認依頼などです。どちらを使うかよりも「誰に見せるか・いつまで見せるか」を最初に決めることが重要です。