「Devでは動くのにStagingでは動かない」— AIだけでは解決できなかった本番運用の壁
GIIP FDE Boxを使って、Google Drive・Stripe・Claude・AI Chatbotを連携した実際の有料Webサービスを構築した顧客の事例です。Devでは正常に動いていたのに、Stagingへデプロイした途端に外部サービス連携が動かなくなりました。
AIはコードを高速に書けます。しかし「コードが動く」ことと「実際の顧客に課金してサービスを提供し続ける」ことは別の問題です。この事例は、その差がどこに現れるかを具体的に示しています。
実際に課金・運用されている本番サービスの事例事例の背景 — これはデモではありません
顧客はGIIP FDE Boxを、単なる開発補助ツールではなく実際の事業開発プラットフォームとして使っています。
GIIP FDE Boxを使ってゼロからWebサービスを構築し、次のような外部サービスを連携しました。
- Google Drive連携
- Stripe Payment連携
- Claudeを使ったデータ分析
- AI Chatbot
- その他の外部APIおよび認証サービス
- エンドユーザー向け課金機能
重要なのは、これが単発のデモではないという点です。実際のエンドユーザーにサービスを提供し、課金して売上を発生させる商用Webサービスを、GIIP FDE Boxを使って開発・運用しています。
発生したIncident
サービスはDevelopment環境では正常に動作していました。
しかし変更をStaging環境にMerge/Deployした後、一部の外部サービスが正常に応答しなくなりました。顧客はGIIPに原因の相談を持ちかけました。
単に「Stagingで動かなくなり、GIIPが直した」と書くのは正確ではありません。なぜこの種の問題が起きうるのかを、開発者でない人にも理解できる形で説明します。
Root Cause — コードではなく「環境」の話
外部サービスを連携する際には、一般的に次のような値が必要になります。
連携に必要な値の例
GOOGLE_CLIENT_IDGOOGLE_CLIENT_SECRETSTRIPE_SECRET_KEYCLAUDE_API_KEYDATABASE_URLCALLBACK_URLWEBHOOK_SECRET開発環境では、こうした設定やSecretを`.env`のようなファイルに保存することが多くあります。そしてセキュリティ上の理由から、`.env`は通常`.gitignore`に登録し、Gitリポジトリにはコミットしません。
そのためコードだけをDev→Stagingへ Merge/Deploy すると、コードは移動しても、実行に必要な Environment Configuration や Secret は移動しないという状況が起こり得ます。
実際の障害原因が100%「.envの欠落」だったと確定されたわけではありません。GIIPはDev/Stagingの環境差異とSecret/Configuration管理構造をまず疑い、環境依存設定の管理方式を変更したことで問題が解決した、という経緯です。
GIIPが提案した構造
Application
↓
Local / Server の .env
↓
Google / Stripe / Claude / External APIs
環境ごとに人が手作業で`.env`を作る必要があるため、Dev/Staging/Production間でConfiguration Driftが発生しやすい構造です。
GIIP Management UI
↓
Central Configuration Management
↓
Secret / Credential Storage
↓
DEV / STAGING / PRODUCTION
↓
Google / Stripe / Claude / External APIs
適用した原則
- 暗号化保存
- Secret Manager / Vault / KMS等の活用が可能な構成
- 環境別の権限分離
- Secret値を画面にそのまま再表示しない
- アクセスログの記録
- Production Secretへのアクセス権限を制限
- Secret Rotationが可能な構造
顧客は管理画面から必要な設定を登録し、各環境で適切な値を使える構造に変わりました。ポイントは「.envの中身をDBに入れた」ことではなく、Configuration ManagementとSecret Managementをアプリケーションコードから分離したことです。
このストーリーの流れ
① AIがサービスを作った
Google Drive、Stripe、Claude、AI Chatbot、Database、Web Application。GIIP FDE Boxを使って顧客はこれらを組み合わせ、実際の有料サービスを作りました。
② Devでは正常に動いた
開発環境ではすべての連携が期待どおりに動作していました。
③ Stagingへデプロイすると動かなかった
同じコードをStagingへ展開した瞬間、一部の外部連携が応答しなくなりました。
④ AIにコード修正を繰り返させるだけでは解決しない場合がある
問題はコードではなく、Environment / Configuration / Secret / Deployment Architecture 側にあり得るからです。
⑤ GIIPの経験ベースのSupportが問題の見方を変えた
「コードが間違っているのではなく、DevとStagingの実行環境は本当に同じか？」という問いから調査が始まりました。
⑥ 構造そのものを改善した
環境ごとのファイルコピーに依存する方式から、中央Configuration/Secret Management方式へ変更しました。
⑦ Staging問題が解決し、Productionでの再発リスクを事前に除去した
Stagingで顕在化した問題を、Productionで繰り返す前に構造ごと取り除きました。
システムの深いところまで理解しているSupporterが一緒にいるからこそ、GIIP FDE Boxには意味がある。インフラや開発の経験がない人がAIを使ってサービスを作るとき、こうした構造的なアドバイスまで提供してくれるサービスは多くない、という趣旨のフィードバックを受けています。
実際の顧客からのフィードバック（要旨・意訳）
以下は実際の顧客フィードバックの要旨です。発言内容の一言一句が確認されたものではないため、直接引用（かぎ括弧での逐語引用）ではなく要旨として記載しています。
「30年の経験」とのつながり
AIは次のような作業を非常に速くこなせます。
しかし実際のProduction Serviceでは、次のような問題が発生します。
これらはコードを生成する能力だけでは解決しません。GIIPが言う「30年の経験」は、まさにこの領域に適用されます。
今回の事例で顕在化したのは、まさにこの領域の問題でした。GIIP FDE Boxには、AIの実行力に加えて、こうした領域を実際に運用してきたエンジニアリング経験が組み込まれています。
一般的なAI Coding Agentとの違い
| AI Coding Agent | GIIP FDE Box |
|---|---|
| コード作成 | コード作成 |
| 機能実装 | 機能実装 |
| API連携 | API連携 |
| テスト | テスト |
| — | Dev/Staging/Production運用 |
| — | Infrastructure |
| — | Configuration Management |
| — | Secret Management |
| — | Monitoring |
| — | Performance |
| — | Production Troubleshooting |
| — | Experience-based Support |
コードを完成させることがゴールではありません。サービスを動かし続けることがゴールです。
よくある質問
なぜDevでは動くのにStagingでは動かないことがあるのですか。
コード自体は同じでも、実行に必要なEnvironment Configuration（環境変数・Secret・接続先URLなど）がDevとStagingで揃っていない場合があるためです。特に`.env`のようにGitで管理していない設定は、コードのMerge/Deployだけでは自動的に移動しません。まず「コードの差」ではなく「環境の差」を疑うことが有効です。
`.env`ファイルはGitにコミットすべきですか。
一般的には推奨されません。`.env`にはAPIキーやDB接続情報などのSecretが含まれることが多く、リポジトリにコミットすると漏えいリスクが高まります。多くのプロジェクトが`.gitignore`で除外していますが、その結果として環境間でSecretをどう同期するかという別の課題が生まれます。
Dev・Staging・Production間でAPIキーはどう管理すべきですか。
環境ごとに手作業でファイルをコピーするのではなく、中央のConfiguration/Secret Managementの仕組みを介して環境ごとに適切な値を配布する構造が望ましいです。暗号化保存、環境別の権限分離、アクセスログ、Secret Rotationが可能な設計が基本的な考え方になります。
AI Coding AgentはProductionインフラまで管理できますか。
AI Coding Agentはコード作成・機能実装・API連携・テストといった開発作業を高速化することには優れています。一方でDev/Staging/Productionの環境差異、Secret Management、監視、障害対応といった運用領域は、コード生成能力だけでは十分にカバーされないことがあります。
AI Coding AgentとGIIP FDE Boxの違いは何ですか。
AI Coding Agentは主にコード作成・機能実装・API連携・テストを担います。GIIP FDE Boxはそれに加えて、Dev/Staging/Production運用、Infrastructure、Configuration/Secret Management、Monitoring、Production Troubleshootingを、30年のProduction経験に基づくSupportとともに提供します。
AIで開発する時代に、なぜProduction経験が重要なのですか。
AIはコードを生成する速度を大きく高めますが、Environment Difference・IAM・Network・Deployment・Scaling・Failure Recoveryのような運用上の問題は、コード生成とは別の種類の判断を必要とします。今回の事例のように、原因が「コードではなく環境設計」にあるケースを切り分けるには、実際に本番運用を経験した視点が有効です。
関連ページ
「なぜDevでは動くのにStagingでは動かないのか」を独立したKB記事として掘り下げる構想がありますが、本ページ公開時点ではまだ作成されていません。公開され次第、本ページから相互リンクします。
AIでサービスを作っている。でも本番運用が不安ですか？
GIIP FDE Boxは、開発だけではなくDev/Staging/Production、インフラ、DB、監視、障害対応までサポートします。