業務アプリの本番とテスト環境の分け方：データベースとドライブは分け、AI の鍵は共通に

本番環境とテスト環境は、データベースと Google ドライブのフォルダを分け、AI（Gemini）の鍵だけは共通にする、と決めました。データのコピーは本番からテストへの一方向だけで、修正は必ずテストで確かめてから本番に出します。

不動産の業務アプリ（Kaitori Base）を作っていた2026年9月21日、手元の iPhone のアプリがテスト環境を向いたまま、お客様へのデモを迎えそうになりました。幸い気づきましたが、本番とテストの分け方を、その場その場で決めていたことが原因でした。

そこで、本番とテスト環境で「何を分けて、何を共通にするか」を設計書に書き、決まりにしました。この記事は、その決まりと理由の記録です。

本番環境とテスト環境で、分けたものと共通にしたもの

データベースは、必ず分ける

「表の形はほとんど変わらないから、データベースは共通でいい」と考えたくなります。けれども、開発中のアプリでは、表の形はしょっちゅう変わります。

ほかにも、共通にすると困ることがあります。

• テストのデータが本番に混ざる。自動のテストは、案件を作る。手で確かめる時も、査定などを作る
• 巻き戻せない。アプリを前の版に戻しても、データベースの形は新しいままになる
• アプリのサーバーの変更は、ほぼ必ずデータベースの形の変更を伴う。共通にした時点で、テスト環境の意味が無くなる

Google ドライブのフォルダも分ける

アプリは、物件の写真や資料を、会社の Google ドライブに保存します。ここも、本番とテストで一番上のフォルダを分けました。フォルダの名前は設定から読み、設定が無ければアプリのサーバーを動かしません。決まった名前に勝手に戻らないようにするためです。

AI の鍵は、共通にした

AI（Google の Gemini）の鍵は、本番とテストで共通にしました。分けなくても、データが混ざるなどの害は小さいからです。

データは、本番からテストへ一方向だけ

テスト環境が空っぽだと、本物に近い確かめ方ができません。そこで、本番のデータをテストへ写すことにしました。

修正は、必ずテストで確かめてから本番へ

サーバーへの送り方（デプロイの道具）は、送り先を引数で受け取ります。テストへはそのまま送れ、本番へは送る前に確認を求めます。本番に出してよいのは、テストで動きを確かめたものだけです。テストを飛ばして本番に出すことは、決まりで禁じています。

$ scripts/deploy.sh stg
（テストへ。確認なしで送る）
$ scripts/deploy.sh prod
（本番へ。送る前に確認を求める）

サーバーが動いているかの見張りも、両方の環境に置きました。ただし、知らせの届け先は分けています。テストの障害の知らせに埋もれて、本番の障害を見落とさないためです。

アプリの側の分け方

サーバーを分けても、アプリがどちらにつながっているかを間違えれば同じことです。冒頭の「テストを向いたままデモを迎えそうになった」は、アプリの側の問題でした。アプリの側では、接続先を切り替えるボタンを、オーナー本人のビルドにだけ入れています。

アプリ開発本番のアプリから「テスト環境に切り替えるボタン」を消した理由と、#if DEBUG では足りなかった話本番とテストの接続先を切り替えるボタンを、開発用と TestFlight 用のビルドにだけ出し、App Store 版には入れないことにしました。TestFlight のビルドは Debug ではないので #if DEBUG では分けられず、SWIFT_ACTIVE_COMPILATION_CONDITIONS の独自フラグで切った方法です。

まとめ

• データベースと Google ドライブのフォルダは、本番とテストで必ず分ける
• AI の鍵は共通でよい。ただし上限も共有することを覚えておく
• データは本番からテストへの一方向だけ。テストのデータは消えてもよいものとして扱う
• 修正は必ずテストで確かめてから本番へ。見張りの知らせの届け先も分ける