ステージング環境とは？公開前にテストする方法

ステージング環境とは、アプリの非公開コピーで、できるだけ本番に近い状態に作られており、実際のユーザーが見る前に変更をテストする場所です。独自のデータベース、テストデータ、テスト用のAPIキーを使うため、そこで機能が壊れても、データを誤って変更しても、チーム外の人には影響しません。ステージングで変更が正しく動いたら、お客様が使っている公開中のアプリである 本番（production） にリリースします。

AIで作る場合になぜステージングが重要なのか

AIで作ると、変更がとても速く進みます。機能を追加したり、ページを書き直したり、データ構造を変えたりするのに数分しかかかりません。その速さは、一見問題なさそうな変更がいつの間にか決済を壊したり、「ちょっとした整理」で顧客データの列が消えたりするまでは、非常にありがたいものです。

変更を本番に出す前に確認できる場所があると、次のことに役立ちます。

• 顧客より先に不具合を見つける。 大きな変更のたびに、会員登録、決済、主要な操作を試せます。
• 実際に近い条件でテストする。 ステージングは本番と同じように動くべきです。同じ構成、似た設定にしておくことで、問題が後になってではなく、そこで表面化します。
• 実データを守る。 データベースの変更、インポート、一括編集は、まずテストデータでリハーサルできます。
• 作業中の内容を見せる。 クライアントやチームメイトは、変更を公開せずにレビューできます。

身近なたとえ

劇場の本番前の通し稽古（ドレスリハーサル）を考えてみてください。

• 開発は稽古場です。俳優はセリフを試し、止めて、やり直し、いろいろ試します。
• ステージングはドレスリハーサルです。衣装も舞台も照明も、本番の初日と同じ状態ですが、有料の観客だけがいません。
• 本番は初日の公演です。ミスはすべての観客の前で起こります。

初日には見たくない問題の多くは、ドレスリハーサルで表面化します。衣装替えに時間がかかりすぎる、照明の合図が違う、といったことです。まさにそれがステージングの役割です。

3つの一般的な環境

各環境の違いは主に 設定 にあります。どのデータベースに接続するか、どのキーを使うか、どのURLで動くか、です。だからこそ、良いアプリは、これらの設定を 環境変数とシークレット から読み込み、コードに直接書き込みません。同じコードを、異なる設定で、あらゆる環境で動かせるようになります。

具体例：予約アプリのキャンセルルールを変更する

有料の顧客がいるサロン予約アプリを運営しているとします。キャンセルは48時間前ではなく24時間前まで可能にし、返金は自動にしたいとします。

1. 開発環境で作る。 AIビルダーに変更を依頼します。キャンセルのロジックと、決済プロバイダーへの返金処理を更新してくれます。

2. ステージングにリリースする。 ステージングは同じコードを動かし、テストの予約が入ったステージング用データベースと、決済プロバイダーの テストモード のキーに接続します。

3. 実際の操作を試す。 あなたと同僚で次のことを確かめます。

• 明日のテスト予約を入れて、30時間前にキャンセルする。返金されるはず。
• 10時間前にキャンセルしようとする。わかりやすいメッセージとともに拒否されるはず。
• 返金が、決済プロバイダーのテスト用ダッシュボードに表示されるか確認する。
• 確認メールに、48時間ではなく24時間と書かれているか確認する。

4. 不具合を見つける。 ステージングで、ルールがサロンのタイムゾーンではなくサーバーのタイムゾーンを使っていることに気づきます。そのため締め切りが1時間ずれています。修正して、もう一度テストします。

5. 本番にリリースする。 ここで初めて、変更が実際の顧客に届きます。タイムゾーンの不具合はすでに見つかっています。

ステージングがなければ、手順4は実際の顧客の返金で起きていたかもしれません。

主な用語

よくある誤解

• 「ステージングは本番のデータベースを共有してよい」。 これは最も危険な近道です。レコードを削除したり編集したりするテストは、実際の顧客に影響します。ステージングには独自のデータベースを用意しましょう。
• 「ステージングで動けば、本番で壊れることはない」。 ステージングはリスクを減らしますが、なくすわけではありません。実際のトラフィック、実データ、外部サービスは、それでも予想外の事態を起こすことがあります。ロールバックの手段は残しておきましょう。
• 「ステージングは高価でなければならない」。 小さくても構いません。必要なのは本番と同じ構成であって、同じ規模ではありません。
• 「現実的にするために本番の決済キーをステージングで使う」。 決済プロバイダーのテストモードを使いましょう。現実的であることは、本物のお金を使うことを意味しません。
• 「ステージングは大規模なチームだけのもの」。 安全な場所でまず試す、という考え方は、1人のプロジェクトでも役立ちます。儀式の大きさは、賭けの大きさに応じて調整できます。
• 「ステージングは誰でも試せるように公開すべき」。 非公開または保護された状態にし、検索エンジンにインデックスされないようにしてください。そうすれば、本物のアプリと間違えられることがありません。

AIビルダーへの頼み方

• 「データベース、APIキー、サイトのURLなど、環境ごとの設定はすべて環境変数から読み込むようにしてください。」
• 「本番以外のデータベースに現実的なテストデータを入れる、シードスクリプトを追加してください。」
• 「公開すると言うまで、決済プロバイダーはテストモードを使ってください。」
• 「この変更を公開する前に、確認すべき操作と、各操作で何が起こるべきかを一覧にしてください。」
• 「この変更は既存のデータに影響しますか？ まずマイグレーションを見せてください。」
• 「本番以外のサイトのコピーが検索エンジンにインデックスされないようにしてください。」

手順を追ったセットアップは、ステージング環境のセットアップ方法 をご覧ください。リリースが頻繁になってきたら、コードからステージング、本番までの流れを自動化することが CI/CD の役割です。

Mythexでのリリース前テスト

Mythexには「ステージングと本番」を切り替えるスイッチはありません。公開すると、公開URLが1つできます。この点はドキュメントにも明記されています（複数サービスのアプリ）。代わりに、作っている段階と公開する段階を明確に分けられます。

• プレビュー は、作業中にアプリを非公開のクラウドサンドボックスで動かします。変更はまずここに表示され、公開中のアプリには反映されません。
• 共有 は、プレビューリンク を作成し、クライアントやチームメイトがMythexのアカウントなしで、あなたが公開せずに作業中の内容をレビューできるようにします。このリンクは、作成時点のサンドボックスの状態を、作業途中の変更も含めて表示します。いつでも削除できます。
• 公開 は、プロジェクトのスナップショットを撮ってデプロイします。再度公開するまで、公開中のアプリは以前のままです。
• チェックポイント は、エージェントが成功するたびに保存されるので、変更がうまくいかなかったときにプロジェクトのファイルを元に戻せます。

プレビューはリハーサルとして使いましょう。ローンチまで決済プロバイダーはテストモードのままにし、公開のたびに主要な操作を一通り確認してください。実際の顧客が関わるようになったら、データを書き込んだり削除したりするテストをする前に、プレビューがどのデータベースとキーを使っているかをエージェントに確認しましょう。ステージング用の別データベースを完全に分けたい場合は、プロジェクトに合った選択肢をエージェントに説明してもらうか、Proプランなら、プロジェクトをエクスポートするか、GitHubに同期して、自分が管理するインフラで動かしてください。

よくある質問