Dev, Test, Stage, Prod: ソフトウェア開発環境の使い分け

2026年8月23日

🐧 要するにどういう話か

システム開発するときに、開発環境と本番環境は分けると思うが、もっと分けるべきときもあるという話。

環境とは

環境(environment)とは、特定の目的に合わせて構築・調整された空間である。Dev, Test, Stage, Prodはすべてこの意味での環境であり、目的はコードやアプリケーションを可能な限り高い品質で構築・デプロイすることである。

ユーザー向けにアプリケーションを構築する場合、ローカルで開発してそのまま本番へデプロイするやり方では、コードの衝突や標準化されていないコードが生じ、品質が低下し、事業への信頼が損なわれる恐れがある。そのため、開発から本番までの間に複数の環境を挟むのが一般的である。

各環境の説明

Development (Dev)

Devは開発者がまず新しいコードをチェックインする初期の環境である。歴史的には開発者のローカルマシンだったが、現在はクラウド上のエフェメラル環境(本番に似たレプリカ)にデプロイされることもある。

  • コードの作成、コミット、ブランチ管理、ブランチのマージを行う場所
  • ローカルDBやダミーDBに接続し、実データに影響を与えないようにする
  • コード変更が基本的なレベルで動作するかを確認する
  • 最も不安定で、壊れたり落ちたりしやすい。テストがほとんど行われないこともある
  • 新機能の試行や実験の場であり、学習に適している

主な登場人物は開発者である。

Testing (Test)

Testは、Devでの初期チェックの後、コードが進む環境であり、QA（品質保証）やテスト活動の本拠地である。Devより管理された環境であり、機能・統合・回帰テストが行われる。

  • スモークテスト、統合テスト、回帰テスト、自動テスト、手動テストを実施する
  • 見つけたバグは開発チームに報告し、コードはビルド単位でタグ付けして欠陥を特定のビルドとして追跡できる

主な登場人物はQA担当者である。

Staging (Stage)

Stageは本番に可能な限り近いレプリカであり、最終検収テストのための環境である。本番と同じ規模のマシン、ハードウェア仕様、ソフトウェアバージョン、設定、統合を使い、場合によっては本番DBも使う。本番への公開前の最終チェックポイントである。

  • 最終検収テスト、UAT(ユーザー受け入れテスト)、クライアント向けのデモを行う
  • DBマイグレーション、設定変更、メジャーバージョンアップデートを検証する
  • 負荷テスト・ストレステストで本番の稼働状況を模倣する
  • 以前の段階が技術的な側面だったのに対し、ここでは実際のシナリオで動作するかを確認する
  • 安全な空間であり、ここで壊れても実際の顧客には影響しない

主な登場人物はQA担当者とステークホルダーである。

Production (Prod)

Prodはコードが一般に公開される本番環境である。顧客が操作するバージョンであり、実ユーザー・実データ・実収入に関わる。

  • 最も安定した環境であり、継続的にモニタリングされる
  • テストは非破壊なもの(データを変更せずにページをロードする等)に限られる。擬似ユーザーやテストデータは分析結果（アナリティクス）に影響を与えたり、セキュリティや政府の管理に抵触したりする可能性があるためである
  • スケール、キャッシュ、信頼性が最優先
  • 段階的ロールアウト、ブルー/グリーンデプロイ、カナリアリリースなどで更新を低リスクにする
  • ロギング、アラート、バックアップシステムを備え、問題が起きたらすぐに対応できる

主な登場人物はユーザーである。

使い分け

デプロイの流れ

flowchart LR A[Dev] --> B[Test] B --> C[Stage] C --> D[Prod]

各段階の役割は次の通りである。

  • Dev: 開発者がコードを作り、基本的な動作を確認する
  • Test: QA担当者が機能・統合・回帰テストを行い、バグをビルド単位で追跡する
  • Stage: 本番に近い環境で最終検収・UAT・負荷テストを行う
  • Prod: 公開し、非破壊テストとモニタリングで運用する

Devだけでは済まない理由

Devだけでは本番への関門にならない。

  • Devは最も不安定な環境であり、開発者が頻繁にコードをチェックインするため、壊れていたり落ちたりしやすい。実験の場所であって検証の場所ではない
  • Devは歴史的にアプリケーションの一部しか含まず、セキュリティ・サードパーティAPI・クラウドネイティブサービスが欠けていることが多い。このまま本番に送るとロールバックやボトルネックが頻発する
  • Devは本番のハードウェア・規模・統合を反映しないため、問題は本番で初めて顕在化する
  • ローカルで不安定なため、開発者以外(QA担当者・クライアント・ステークホルダー)がテストできない

Devのみだと、本番に残ったバグは実ユーザーが発見することになり、顧客の不満・収入の損失・セキュリティ問題につながる。Devの不足はTestとStageが補う。

TestとStageの差

TestとStageはどちらも本番前の環境だが、目的と使う人が違う。

  • Test: 管理された環境で、専用のQAチームがコードの技術的な正しさ(機能・統合・回帰)を検証する。見つけたバグは開発チームに報告し、ビルド単位で追跡する
  • Stage: 本番に可能な限り近いレプリカで、QA担当者・ビジネスオーナー・クライアントなどのステークホルダーが、要件を満たすか・実シナリオで動作するかを検収する(最終検収、負荷/ストレステスト、クライアントデモ)

つまり、Testは「正しく動くか」を技術的に検査する品質検査の場、Stageは「本番で要件を満たすか」を検収する最終確認の場である。スタートアップなどではTestを省略し、Stageがテストと検収の両方を受け持つ形が一般的である。

組織ごとの構成の違い

構成は会社によって変わる。DevとProdだけ、TestとProd、Dev/Stage/Prod、4環境すべてを使う会社がある。

  • スタートアップはDev/Stage/Prodが好まれる。速度がプロセスより優先され、環境が少ない分メンテナンス負荷が小さく、デプロイが頻繁で、必要なら素早くロールバックできる
  • 中規模以上、規制産業(金融・医療・宇宙・軍事)、専用QAチームを持つ組織はDev/Test/Stage/Prodを使う。開発と本番の間のレイヤーが増えるほど未テストのコードが本番に入るリスクが減り、プロセスが速度より優先され、時間をかけてでも一度で正しくすることを重視する

Stagingを省略するケース

小規模な組織は少ない環境から始め、組織がスケールするにつれて環境を増やす。Stagingを持たない場合、フィーチャーフラグやカナリアでProdへのトラフィックの1%だけを変更に当て、モニタリングで比較してからマージする手法もある。フィーチャーフラグは実行時に機能をON/OFFできるため、毎回デプロイする必要がない。

運用上の注意

  • Prod用に新しいビルドを作るのではなく、Stagingと同じビルドをデプロイする
  • 緊急時はStagingをスキップしてProdへリリースできるが、恒常的なやり方ではない
  • 「Prodが最も重要」とは限らない。Prodが多少停止しても耐えられる一方、Devが1時間止まると全社の開発が1日分止まる場合がある
  • 開発文化は「最小の変更でも数分でProdへリリースする」方向にシフトしている
  • Stageの構築は手間がかかるが、価値がある

📚 参考文献

付録：用語集

用語 定義
デプロイ 作成したアプリケーションやコードを、対象の環境（サーバーなど）に配備し利用可能な状態にする作業。
リポジトリ 開発したコードや資料などを一元管理する保存場所。バージョン管理システムにより、変更履歴の追跡や多人での共有が可能である。チェックインやコミットはリポジトリに対して行われる。
チェックイン 開発したコードをリポジトリに保存（反映）することを指す。一般的にはコミットとほぼ同義で使われる。
エフェメラル環境 一時的に作成・破棄される環境。クラウドでは本番に似たレプリカを一時的に構築して利用するのが特徴。
コミット 開発したコードの変更点をリポジトリに記録すること。変更に対する説明（メッセージ）を伴うのが一般的。
ブランチ リポジトリ内のコードの分岐。機能ごとに独立した開発を行うために使用される。
マージ 複数のブランチの変更を1つのブランチに統合すること。
QA Quality Assurance（品質保証）の略。ソフトウェアの品質を高めるための活動、特にテスト活動を指す。
スモークテスト コード変更後に主要な機能が概して正しく動作するかを素早く確認する簡易的なテスト。
統合テスト 個別に開発されたコンポーネントやシステムが、正しく連携して動作するかを検証するテスト。
回帰テスト 一部を変更・修正した後に、それ以外の機能がこれまでどおり正常に動作しているかを再確認するテスト。
ビルド ソースコードをコンパイルなどして、実行可能な形式（プログラム）へ変換すること。またその成果物の単位。
最終検収テスト 本番前に、要件どおりの製品かどうかを顧客などが最終的に検証・受領するテスト。
UAT(ユーザー受け入れテスト) User Acceptance Testの略。実際のユーザーが実シナリオでシステムを使い、業務要件を満たすかを検収するテスト。最終検収テストの一形態（手法の一つ）とみなせ、「受領判断までを含む広い活動」である最終検収テストの中に含まれる。
DBマイグレーション データベースのスキーマやデータを、あるバージョンから次のバージョンへ移行する作業。
負荷テスト システムに意図的に高い負荷をかけ、許容範囲内で正しく動作するかを検証するテスト。
ストレステスト 通常の範囲を超える高負荷をかけるなど、ストレス状態においてシステムがどう振る舞うかを検証するテスト。
段階的ロールアウト 変更対象を全ユーザーに一括ではなく、段階的に順次適用してリスクを分散させる手法。
ブルー/グリーンデプロイ 現行環境（ブルー）と新規環境（グリーン）の2つを用意し、切り替えることでダウンタイムなく安全にリリースする手法。切り替え方式を一括にするか段階的にするかを選択できる。
カナリアリリース リリース対象トラフィックの一部（例1%）のみを新バージョンに当て、異常がないか監視しながら徐々に拡大する手法。段階的ロールアウトの一種。
ロールバック 問題が発生した際に、変更前の状態へシステムを戻す作業。
フィーチャーフラグ 実行時に機能をON/OFFできるスイッチ。デプロイなしで機能の公開可否を制御できる。