最近「バイブコーディング」という言葉が出るほど、
AIエージェントに話しかけるとウェブサービスのコードが次々と生成されます。

しかし、一つだけ変わらないことがあります。

  • サーバーをどう分けるか

  • どこにデプロイするか

  • どうやってロールバック・管理するか

これは今もなお人間の責任です。
AIは「コード」はうまく書いてくれますが、「運用段階での事故」まで代わりにはなってくれません。

この記事では特にステージング(staging)環境の重要性を指摘し、
ステージングで何を必ず確認するべきかを整理していきます。

dev-staging-prodチェーン画像

1. AIがコードを代わりに書いても、デプロイは残る

Commandbox 광고

AIエージェントにこう言えば：

「Next.jsで簡単なTODOウェブアプリを作って」
「このAPIをPostgreSQLに接続して」

コードはすぐに出てきます。
しかしAIはまずこうは言いません。

「今、devサーバーではなくステージングサーバーにデプロイして、
運用と同じDB/キャッシュ/環境変数の構成をチェックしよう。」

なぜなら質問と指示を出す人がその経験を知らなければ、
AIもその方向で考えないからです。

結果として多くの初心者開発者が：

  1. devサーバーでうまく動いているのを見て

  2. すぐにprodサーバーにデプロイした結果

  3. DB/キャッシュ/環境変数/ドメイン設定の問題で爆発💣

その後に「わ…ステージングがこういうことだったんだ」と実感します。

2. devからprodへの直行が危険な理由

「コードはDockerイメージにまとめたので、どこでも同じでは？」
一見正しいようですが、実際の運用では次のような違いがあります。

  • どのDBを見ているのか

    • dev: dev-db, prod: prod-db

    • 接続文字列、セキュリティ設定、アカウント権限、データ量が異なる

  • キャッシュ/メッセージキュー

    • Redis、RabbitMQ、Kafkaなど、各環境別のアドレス、認証、容量

  • 環境変数

    • NODE_ENV, API_BASE_URL, PAYMENT_PROVIDER_KEY …

    • devでは空白またはダミーですが、prodでは実際のキーを使用

  • 外部連携

    • 決済、SMS、メール、SSO、外部APIなど

    • devはサンドボックス、prodは実環境

Dockerイメージが同じだからといって「環境」が同じではありません。
ウェブアプリケーションが完成しても、
デプロイと運用は完全に異なる領域と言っても過言ではありません。

したがってdevからすぐにprodにデプロイすることは、
「機能テストはローカルで終わらせたので、すぐに実顧客にベータテストをしよう」ということと違いありません。

3. ステージングはなぜ必須なのか？

Commandbox 광고

ステージング(staging)を簡単に言うと：

「運用環境と最大限似た構成のリハーサルステージ」

です。

  • prodと同じバージョンのアプリケーション

  • prodとほぼ同じインフラ構成

  • ただしテスト用のデータ・ドメイン・アカウントを使用

ステージングがなければ：

  • devでうまく動いていたコードがprodで壊れて

  • 原因を探していくと「環境の違い」がほとんどで

  • そのたびに緊急パッチ→すぐにprod再デプロイ→別の問題…

という悪循環が繰り返されます。

逆に、ステージングをうまく使うと：

  • 「この変更が実際の運用環境でどのように見えるか」
    見た目で事前に確認可能

  • インフラ設定、セキュリティ設定、データマイグレーションなどを
    実戦のようにリハーサルすることができる

  • QA、企画、デザイナー、事業担当者全員が
    運用前の画面と機能を事前に確認できる

特に初心者開発者ほど：

  • 自分のコードではなく「運用環境全体」を見る目を育てなければならず、

  • その訓練がまさにステージングで行われます。

4. ステージングで必ず確認すべきこと

では、ステージング環境では何を見なければならないのでしょうか？
項目ごとに整理していきます。

4.1 環境変数と設定値

  • DATABASE_URL

  • REDIS_URL / CACHE_URL

  • API_BASE_URL

  • SECRET_KEY, JWT_SECRET_KEY

  • 外部APIキー、Webhook URLなど

「devとprodの設定がどう異なるのか」を文書化し、
ステージングがprodと同じパターンに従っているかチェックする必要があります。

チェックポイント

  • ステージングのenvファイルや設定が
    prodと構造が同じか

  • 機密情報が環境変数/シークレット管理ツールにきちんと隠されているか

  • 設定値がハードコーディングされていないか

4.2 DBとデータマイグレーション

  • マイグレーションスクリプト（prisma migrate, django migrate, migration.sqlなど）が
    実際のprodと似たデータスキーマで正常に動作するかどうか

  • インデックス、ユニーク制約、FK制約などでエラーが発生しないか

  • ダミーデータが実際の画面と流れに問題を引き起こさないか

チェックポイント

  • ステージングDBに適切な量のテストデータがあるか
    （空のDBでのみテストするのは意味が薄いです。）

  • ロールバック戦略もステージングで一度練習しておくのが良いです。

4.3 認証・権限・セッション

  • ログイン/ユーザー登録フロー

  • OAuth/SSO（Google、Kakaoなど）連携

  • 権限（Role）に応じて異なる画面・API動作

チェックポイント

  • ステージングで実際の運用と同じ方式でログインできるか
    （仮のdev専用のログイン回避ロジックが含まれていないか）

  • 権限が異なるアカウント（管理者、一般ユーザーなど）ごとに
    メニュー/ボタン/アクションが正常に動作するか

4.4 外部連携：決済、SMS、メール、通知など

  • 決済（gateway）→サンドボックス/テストモード

  • SMS/カカオ通知→テストチャネル

  • メール送信→テストメール、実際の顧客に送信しないよう注意

チェックポイント

  • ステージングで実際の外部連携パスをそのまま使用しているか
    （ただし、実顧客対象ではなくテストアカウントで）

  • エラー状況（決済失敗、タイムアウトなど）の処理も併せて確認

4.5 フロントエンド + バックエンド統合動作

ローカルではフロントとバックがそれぞれうまく動きますが、
ステージング（実ドメイン/リバースプロキシ/SSL）に入ると異なる問題が発生します。

  • CORS設定

  • HTTPS/HTTP混在

  • クッキーのドメイン/セキュア設定

  • リバースプロキシ（Nginx、Traefikなど）のパスルーティング問題

チェックポイント

  • ステージングURL基準ですべてのページが動作するか
    （ローカル専用URLが隠れていないか）

  • ブラウザの開発者ツールのNetworkタブで
    CORS、301/302、4xx/5xxエラーがないか確認

4.6 パフォーマンスとリソース使用量

最初はパフォーマンスに問題がないように見えますが、
ステージングで少しでも負荷テストを行ってみると問題を事前に確認できます。

  • API応答時間

  • DBクエリ数、N+1クエリの有無

  • キャッシュミス時の性能

  • メモリ/CPU使用量

必ずしも大がかりな負荷テストツールである必要はありません。

  • ステージングでさまざまなユーザーロールで同時に何度か使用してみて

  • ログを見ながら遅い部分がないかチェックするだけでも
    十分に意味のある「ミニ負荷テスト」ができます。

5. ステージング環境の構成、どう始めるか？

最初から完璧である必要はありません。
小規模サービスの基準で、こういう形で始められます。

5.1 最小構成例

  • dev

    • ローカル開発環境（Docker Compose、ローカルDBなど）

  • staging

    • prodと同じクラウド/プラットフォームにデプロイ

    • ドメイン：staging.example.com

    • 別途DB/キャッシュ/ストレージ

  • prod

    • 実際の顧客が使用する運用環境

デプロイパイプラインも簡単に：

  1. mainにマージ→自動でステージングデプロイ

  2. ステージングでQA/セルフチェック

  3. 特定のタグ（v1.0.0）をプッシュ→prodデプロイ

これだけでも：

  • 「dev → すぐにprod」は根本的に排除されます。

  • 常にステージングを経由する習慣が作られます。

6. 初心者こそステージングを「過剰に」使おう

ほとんどの初心者開発者はステージングを軽視します。

  • 「devでうまくいってるから…」

  • 「ステージングで何を見ればいいかわからなくて…」

しかし実際には実力の差はコード品質よりも、
運用とデプロイをどれだけ安定的に扱えるかが大きく影響します。

  • 機能がうまく動いていることも重要ですが、

  • サービスが停止しないことはそれ以上に重要です。

ステージングはその両方をつなぐ安全装置であり、
開発者が「サービス運営の観点」を学ぶための最も良い実習場所です。

今後新しいウェブサービスを作る際は、こうしてみてください。

  1. 設計する時からprodとステージングを一緒に描いてみて

  2. デプロイ自動化もステージング→prod順序で設計して

  3. 重要な機能は必ずステージングで
    「実際の運用のように」何度も確認してからprodにデプロイする

AIがコードを代わりに書いてくれる時代こそ、
デプロイと運用の設計責任を持つ能力がより大きな差別化要因となります。
ステージングはその能力を育てる最も現実的なツールです。