開発環境・ステージング環境・本番環境とは
開発環境・ステージング環境・本番環境とは、システムを「作る場所」「本番と同じ条件で確かめる場所」「実際の利用者が使う場所」という目的ごとに分けて用意した、それぞれの動作環境のことです。
平易に言えば、料理店の「試作用の台所」「開店前のリハーサル」「営業中の厨房」の違いです。試作の台所では失敗しても誰も困りません。リハーサルでは本番と同じ器具と段取りで確かめます。営業中の厨房で新しい料理をいきなり試す店はありません。システムでも同じように、作業の目的と影響範囲に応じて場所を分けます。
ステージング（staging）は英語で「舞台に上げる準備」を意味し、本番前の最終確認の場を指します。会社によっては「検証環境」「テスト環境」「STG」と呼ぶこともあります。本番環境は英語で production と呼ばれ、「プロダクション」「prod」と略されます。
仕組み・ポイント
三つの環境の役割と特徴を比べると、次のようになります。
| 環境 | 目的 | 使う人 | データ | 求められる性質 |
|---|---|---|---|---|
| 開発環境 | 機能を作り、動かしてみる | 開発者 | 架空の試験用データ | 速く試せる、壊してもよい |
| ステージング環境 | 本番と同じ条件で最終確認する | 開発者、発注者、テスト担当 | 本番に近い試験用データ | 本番と同じ構成・設定 |
| 本番環境 | 利用者にサービスを提供する | 利用者、運用担当 | 実際のデータ | 安定、安全、監視されている |
規模によっては、開発環境とステージング環境の間に「テスト環境（結合テスト用）」を置いたり、反対にMVPでは開発環境と本番環境の二つだけで始めたりすることもあります。重要なのは、本番環境で直接作業や試験をしないことです。
環境を分ける際のポイントは、ステージング環境をできるだけ本番環境に近づけることです。OSやミドルウェアのバージョン、設定値、外部サービスとの接続方式が違うと、「ステージングでは動いたのに本番で動かない」という事態が起きます。コンテナやIaC（Infrastructure as Code）を使うと、同じ構成を複数の環境で再現しやすくなります。
実務での使い方・具体例
ある会社が開発会社に依頼して業務システムを作っている場面を考えます。週に一度、新しい機能が追加されます。
環境を分けた運用の流れは次のとおりです。
- 開発者が開発環境で機能を作り、自分で動作を確認する
- コードの確認（レビュー）が済んだら、ステージング環境に反映する
- 発注側の担当者がステージング環境で画面を操作し、要件どおりかを確認する
- 問題がなければ、決めた日時に本番環境へ反映する（デプロイ）
- 本番で不具合が見つかれば、前の状態に戻す（ロールバック）
発注側が確認しておきたいこと
発注側にとって、ステージング環境は「完成品を事前に触れる場所」です。契約や見積もりの段階で、次の点を確認しておくと安心です。
- 発注側が触れるステージング環境は用意されるか、URLとアカウントはどう配られるか
- ステージング環境のデータは誰が用意するか（本番データを使う場合の扱い）
- 本番反映の前に、誰の承認を得るルールにするか
- 環境ごとのクラウド費用はどのくらいかかるか、使わない時間は止められるか
特にステージング環境の費用は見落とされがちです。本番と同じ構成を常時動かすと、本番に近い費用がかかります。夜間や休日は停止する、性能は小さめにするなど、確認の目的を損なわない範囲で抑える方法を開発会社と相談しておきます。
よくある誤解と注意点
- 本番データをそのまま検証に使う：個人情報を含む本番データを検証環境に複製すると、情報管理の範囲が広がり、漏えいのリスクが増えます。加工したデータや架空のデータを使うのが原則です。
- 環境ごとに外部連携先を分けていない：ステージング環境から本番の決済サービスやメール配信につながっていると、試験のつもりで実際の請求やメールが送られてしまいます。連携先も試験用に切り替えます。
- ステージングが放置されて本番と乖離する：本番だけ設定を変えて、ステージングを更新しないことがよくあります。変更は同じ手順で両方に反映します。
- 秘密情報を共通にしている：データベースのパスワードやAPIキーを全環境で同じにすると、開発環境から漏れた情報で本番に入られる恐れがあります。環境ごとに別の値を使います。
- 環境の区別が画面で分からない：本番とステージングの画面が同じだと、操作を取り違えます。ステージングには目立つ表示を出すなど工夫します。
関連用語
- デプロイ：作ったプログラムを各環境に反映する作業
- ロールバック：本番で問題が起きたときに前の状態へ戻すこと
- IaC（Infrastructure as Code）：環境の構成をコードで管理し、同じ環境を再現する手法
- 回帰テスト（リグレッションテスト）：ステージングで行うことの多い、既存機能が壊れていないかの確認
- 実践記事：受入テストの進め方：発注側が用意するテストケースと検収の基準
Otsumuに相談できること
本番環境で直接修正している状態から抜け出したい、発注側が事前に確認できる環境を用意してほしい、といったご相談に対応しています。システムの規模に合った環境の分け方と、反映までの流れを一緒に設計します。詳しくはシステム開発をご覧ください。
30分の無料相談で、現在の開発と運用の進め方を伺います。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01