AIにアプリの実装を任せる場面が増えていますが、「動いているように見えるコード」と「本番投入できるコード」の間には大きな溝があります。この記事は、AI支援で作られたコードをどこまで信用してよいか判断したいエンジニアやSRE（システム信頼性エンジニアリング担当者）、PMに向けて、クラウド運用の観点から受け入れ判断の軸を整理します。
題材になるのは、Slackクローンのデモアプリ「Orbit」の開発事例です。ChatGPTで要件の曖昧さを洗い出し、Claudeで仕様書（PRD、Product Requirements Documentの略）を整理し、Grok Buildで実装するという3段構えのワークフローで作られました。ただしOrbitはサインイン機能がなく、デモ用の共有データを使い、プロセスが再起動するとデータが消える、という制約付きの「デモ」であって本番アプリではありません。この「デモと本番の境界線」をどこに引くかが、今回の判断ポイントです。
どんな場面でこの判断が必要になるか
AIにコードを書かせるプロジェクトでは、実装が完成した瞬間ではなく「これを本番環境にデプロイしてよいか」を決める瞬間に判断が必要になります。
たとえば、テスト環境ではAPIのレスポンスも画面遷移も問題なく動いているように見えるが、実際にはセッション管理や認証、障害時のデータ永続化が検証されていない、というケースです。Orbitの実装ノートでは、機能単位のAPIテストとコンポーズ（合成）テストは通過した一方で、より広い範囲のベースラインテストでは失敗があり、ブラウザ操作の一連の流れ（ユーザージャーニー）はブロックされたままだったと報告されています。ここで「テストが一部通ったから本番投入してよい」と早合点すると、障害対応の現場でしわ寄せが来ます。
判断軸1: 状態管理とデータ永続化の設計
まず確認すべきは、アプリがどこにデータを保持しているかです。
Orbitはプロセスに紐づいた永続化（process-scoped persistence）を採用しており、プロセスが再起動するとデータが消えます。オンプレ環境からクラウドに移行する際、こうしたインメモリ設計をそのまま本番のコンテナ環境やKubernetesクラスタに持ち込むと、Podの再スケジューリングやオートスケーリングのたびにユーザーデータが消失するリスクがあります。
判断のチェックポイントは、データストアが外部化されているか（RDS、Redis、S3などのマネージドサービスに切り出されているか）、そしてヘルスチェックや再起動時にデータが保持される設計になっているかです。AIが生成したコードにこの外部化が含まれているかは、コードレビューで必ず目視確認する必要があります。
判断軸2: 認証・アクセス制御の有無
Orbitにはサインイン機能がなく、一つの共有デモオーナーで全ユーザーがアクセスする構成になっています。
これは検証用途としては合理的な割り切りですが、本番運用では致命的な欠陥です。クラウド環境における障害対応やセキュリティインシデントの多くは、アクセス制御の抜け漏れから発生します。認証がない状態でインターネットに公開されたアプリは、監視ツールがアラートを上げる前に不正アクセスの被害が広がる可能性があります。
確認すべきは、IAM（Identity and Access Managementの略、権限管理の仕組み）やOAuthなどの認証基盤が実装計画に含まれているか、そして誰が「デモ止まり」と「本番相当」の境界を最終判断するプロセスになっているかです。
判断軸3: 監視とテストカバレッジの粒度
AIが実装した機能に対して、どのレベルのテストが通っているかを見極める軸です。
Orbitの場合、機能単位のAPIテストや個別コンポーネントのテストは通過していますが、エンドツーエンド（画面操作からAPI応答まで一連の流れを通して検証すること）のブラウザジャーニーはブロックされたままでした。これは監視設計にも直結する問題です。個別のAPIが正常応答を返していても、実際のユーザー操作の流れの中で例外が起きるケースを監視できていなければ、障害の根本原因分析（RCA、Root Cause Analysisの略）で「どのAPIも正常だったのに、なぜユーザーは操作できなかったのか」という壁にぶつかります。
確認方法として、CI/CDパイプラインのテストレポートを開き、ユニットテスト・統合テスト・E2Eテストのそれぞれの通過率とスキップ理由を確認することをおすすめします。スキップされたテストがある場合、それが本番投入前に埋めるべき穴かどうかを明示的に判断する必要があります。
判断軸4: 運用コストとスケール前提のギャップ
AIが生成したアーキテクチャが、想定するトラフィック規模に見合っているかを確認する軸です。
デモアプリは単一プロセス・単一インスタンスで十分に動作しますが、本番では複数リージョンでの冗長化やオートスケーリングが前提になる場合があります。AIに実装を依頼する段階で「想定ユーザー数」「同時接続数」「データ保持期間」といった非機能要件を渡していなければ、生成されたコードはスケールを考慮しない構成になっている可能性が高いです。
| 判断軸 | デモ・検証段階でよい状態 | 本番投入前に必須の状態 |
|---|---|---|
| データ永続化 | プロセス内メモリでも可 | RDS/Redis等の外部ストアに分離 |
| 認証 | 共有アカウントで代替可 | IAM/OAuth等のアクセス制御を実装 |
| テスト範囲 | API単体テストのみでも可 | E2Eジャーニーまで通過を確認 |
| スケール設計 | 単一インスタンスで可 | 非機能要件を明示し冗長化を設計 |
ケース別の推奨
社内検証やプロトタイプのデモとして関係者に見せる段階なら、Orbitのような構成のまま進めて問題ありません。むしろ早い段階でAIに要件の穴を埋めさせ、UIとAPIの挙動を確認できるスピードは大きな利点です。
一方、外部ユーザーがアクセスするステージング環境以降に進める場合は、上記4つの判断軸すべてについて「デモ止まりの実装のままか」を棚卸しする必要があります。特にデータ永続化と認証は、後から追加するとアーキテクチャの手戻りが大きくなりやすい部分です。早い段階でクラウドのマネージドサービス（RDSやElastiCacheなど)に接続する設計に切り替えることをおすすめします。
あえて見送るべき条件
障害対応の体制がまだ整っていない状態で、AI生成コードを本番リリースするのは見送るべきです。
監視ダッシュボードやオンコール体制がない状態でリリースすると、E2Eジャーニーの穴が本番で初めて発覆し、根本原因分析に着手できないまま復旧作業に追われることになります。また、非機能要件（想定トラフィック、データ保持ポリシー、可用性目標）をAIに一度も伝えていない場合も、そのまま本番投入するのは避けたほうがよいでしょう。実装ノートやテストレポートに「ベースラインテストの失敗」や「ブロックされたジャーニー」といった記載がある場合は、それを解消するまでリリースを待つ判断が妥当です。
まとめ
AIが生成したコードの品質を判断するには、機能が動くかどうかではなく、データ永続化・認証・テストカバレッジ・スケール前提の4軸で棚卸しすることが出発点になります。
まず手元のプロジェクトで、CI/CDのテストレポートを開いてE2Eジャーニーの通過状況を確認してみてください。次に、データストアが外部サービスに分離されているか、認証基盤が実装計画に含まれているかをコードレビューでチェックします。この2つが揃っていない状態での本番リリースは、障害対応のコストを後から大きく跳ね上げる原因になりやすいので、リリース判断の前に必ず立ち止まって確認する価値があります。