AIで作ったアプリを本番公開するまでの流れ

PoCと本番の差を先にそろえる

PoCは仮説や使い勝手を確かめる段階です。本番は、利用者・データ・権限・障害対応を含めて、決めた運用を繰り返せる状態を目指します。画面が動くことやAIを使ったことだけでは、本番公開の判断材料になりません。

• PoC：試す目的、仮のデータ、限られた利用者、手作業の復旧でも検証できる。
• 本番：本番用の環境とデータを分け、誰が何をできるか、異常時に誰が戻すかを説明できる。
• 切り替えの基準：機能の成功だけでなく、失敗時の挙動と運用担当が証拠で確認できる。

公開前に確認する順序と合格の証拠

上から順に進めると、後の確認をやり直す範囲を抑えられます。「合格」は安全性の保証ではなく、定めた確認を実施し、結果と残課題を第三者が追える状態です。

1. 環境を分ける本番のDB、ドメイン、秘密情報、外部サービスの接続先を開発用と区別します。合格の証拠は、値そのものを載せない環境・変数・権限の一覧と切り替え手順です。
2. 利用者と権限を試す未ログイン、一般利用者、管理者などの役割ごとに閲覧・変更・削除を試します。合格の証拠は、許可と拒否の期待結果、実際のレスポンス、対象データを記録したテスト表です。
3. データと秘密情報を確認する入力値、個人情報、APIキーがログ・エラー・分析イベントへ出ないこと、バックアップの保管先と保持方針を確認します。合格の証拠は、マスキング方針、秘密の参照先、データ取扱いの確認記録です。
4. 復旧と監視を試すバックアップから検証環境へ復元し、エラー通知とアクセスログをテストします。合格の証拠は、復元結果、所要時間、通知先、確認担当を含む復旧手順です。
5. 担当者と公開判定を決める公開・停止・復旧の判断者、連絡先、未解決リスクの担当と期限を決めます。合格の証拠は、公開判定メモと、作成者以外でも手順を追えるREADMEです。

一つでも該当したら公開を延期する条件

期限を決めた未対応と、内容が分からない「不明」は同じ扱いにしません。判断できない重要項目は、確認できるまで公開日を固定しないのが実務上の停止条件です。

• 本番と開発の接続先や秘密情報の境界を説明できない。
• 権限の拒否テスト、個人情報の扱い、ログのマスキングを確認できない。
• バックアップはあるが、復元結果や復旧担当を確認できない。
• 重大な未解決リスクに担当者・期限・影響範囲がない。
• 契約・審査・高い安全要件があり、必要な正式診断や第三者確認が終わっていない。

条件別の公開判断表

最低限そろえる成果物

形式はスプレッドシートやREADMEでも構いません。大切なのは、別の担当者が同じ確認をたどれ、判定時点の事実と残課題が分かることです。

• 環境・接続先一覧：本番と開発の違い、変数名、秘密の保管場所、変更手順。
• 権限テスト表：役割、操作、対象、期待結果、実測結果、実施日、担当者。
• データとログの方針：保存する項目、マスキング、閲覧権限、削除・保持の手順。
• 復旧手順：バックアップの場所、復元の順番、テスト結果、連絡先、判断者。
• 公開判定メモ：確認済み、未確認、残課題、期限、担当、公開・延期の決定。

具体的な失敗例から逆算する

• デモ用のキーで公開する：本番環境に開発用の接続先やキーが残り、停止後にどこを差し替えるか分からない。公開前に値を記録せず、参照先と切り替え手順を確認します。
• 画面だけで権限を判定する：ボタンを隠しただけでAPI側の拒否を試していない。役割ごとに直接リクエストを送り、許可・拒否の結果を残します。
• バックアップ取得を復旧と呼ぶ：ファイルが存在することだけ確認し、復元後に動くか試していない。検証環境で復元し、所要時間と手順を記録します。
• 作成者しか対応できない：障害時の連絡先やデプロイ方法がチャットに散らばり、担当者不在時に止まる。READMEを作り、別の人が手順を追えるか確認します。

詳細確認と相談の入口

このページで「不明」になった項目は、担当ページで確認方法を深掘りできます。AIを使ったこと自体を脆弱性と断定せず、実装と運用で確認できる事実に分けて進めます。

• 公開前セキュリティチェックリスト：秘密情報、DB、権限、個人情報、復旧、ログ、引き継ぎの項目一覧。
• 公開前チェックと脆弱性診断の違い・費用：手動確認、コードレビュー、自動スキャン、正式な診断の範囲と成果物。
• ガイド一覧：AI生成コードの確認、公開後の保守、アプリの引き継ぎ。