PRごとに環境を作る「Preview Environment」の仕組み

はじめに

これまでの開発で検証環境を使用することは多々あると思います。複数人で開発を行う場合に、「ちょっと試してみたいけど、他のメンバーが使用していないか？」や「検証環境でエラーが出てるけど、誰か壊した？」など他のメンバーのことを気にしなければならない場面に遭遇したことのある人は多いと思います。しかし、私は、PRごとに検証環境を自動生成する仕組み(Preview Environment)に出会いました。これが想像以上に快適だったので、仕組みとメリット、そして注意点についてまとめてみます。

Preview Environmentとは？

Pull Request（PR）単位で、自動的に専用の検証環境を立ち上げる仕組み

のことです。

実務では、機能追加やバグ修正ごとにPRを作成します。
そのPRが作られると、自動的にその変更内容だけを反映した専用環境が立ち上がります。
例えば、PR #123 を作成すると、

コードがビルドされる
インフラが一時的に作成される
https://pr-123.example.com のようなURLが発行される

という流れになります。

このURLを共有すれば、レビュー担当者やQA、デザイナーが
ローカル環境を用意することなく、その機能を実際に触って確認できます。
つまりPreview Environmentとは、「レビュー前に、本番に近い状態を“触れる形”で確認できる仕組み」と言えます。
また、開発者視点としては、自分のコード変更のみが反映された検証環境が構築されるため、以下の点でメリットがあると考えます。

他の人の修正が混ざって動作確認しづらい
今誰がその環境を使っているのか分からない
データが上書きされてしまう

Preview Environmentを実現する設計の考え方

① labeledイベントで“必要なときだけ”環境を作る

Preview Environmentは便利ですが、
PRが作られるたびに無条件で環境を作るとコストが急増してしまいます。

そのため、PR作成時ではなく、
"labeled" などの特定ラベルが付与されたときだけ環境を生成するように設計すると無駄なコストを避けながら、本当に必要な検証環境の構築が可能になります。

# PRにラベルが付与された時にワークフローを動かすイベント
on:
  pull_request:
    types: [labeled]

② PR番号を環境識別子として利用する

環境の一意性を担保するために、PR番号をそのままリソース名やURLに利用します。

PR #123 の場合

環境名：preview-pr-123
URL：https://pr-123.example.com

GitHub Actionsでは、以下のようにPR番号を取得できます。

# PRの番号を取得する
${{ github.event.pull_request.number }}

これをTerraformの変数として渡すことで、

サブドメイン名
Kubernetes namespace
ECSサービス名
S3バケット名

などをPR番号ベースで生成できます。

この設計により、他PRとの衝突を防止できる
削除対象が明確になる（PR番号＝削除キー）
人が見ても理解しやすい

というメリットがあります。

また、この設計の重要なポイントは、「削除を前提に環境を設計している」ことです。
PR番号をリソース名やURLに組み込むことで、PRがクローズされたタイミングで同じ番号を使って terraform destroy を実行すれば、そのPR専用に作成されたリソースのみを正確に削除できます。

PRを閉じる
GitHub Actionsが起動
PR番号を取得
その番号に紐づくリソースをdestroy

という一連の流れを自動化できます。
手軽に構築・削除できるため、他メンバーを気にせず検証できます。
また、不要環境の放置によるコスト増加も防げるため、安心して開発やテストが実施できます。

また、PRを一度クローズした後でも、reopenすることで検証環境を立ち上げることが可能です。そのため、一度環境を削除したとしても、必要に応じて再構築できる柔軟な運用が実現できます。

③ サブドメイン設計で運用をシンプルにする

URLもPR番号ベースで設計します。

# PR番号をサブドメインにする
https://pr-123.example.com

一見単純ですが、この設計には実務的な強みがあります。

URLを見るだけでPR番号が分かる
チーム内で共有する際にどの修正が入っているURLか判別しやすい

意外とチームで開発する際には、PR番号などの規則性のもと検証環境のURLまで管理されているということは、小さな工夫ですが、「どのURLがどの変更内容に対応しているのか？」と迷うことがほとんどなくなります。
この“迷わない設計”があることで、レビューや検証のテンポが安定し、結果的に開発効率の向上につながっていると感じました。

まとめ

Preview Environmentは、単に便利な仕組みというだけでなく、チーム開発における「摩擦」を減らすための設計だと感じました。
PRごとに独立した検証環境を持てることで、他のメンバーの作業状況を気にする必要がなくなり、確認やレビューの流れがスムーズになります。また、PR番号を軸に環境を管理することで、「作る」と「消す」を明確に制御でき、コスト面のリスクも抑えることができます。
特に印象的だったのは、削除までを前提に設計されている点です。環境を立ち上げるだけでなく、PRのライフサイクルに合わせて確実に削除できる仕組みがあることで、安心して検証環境を活用できます。
今後もこのような仕組みをインプットしながら、チーム全体の開発体験（Developer Experience）を向上させる設計や開発手法を身につけ、あらゆるプロジェクトに還元していきたいと思います。