AIが作ったアプリケーションを本番に載せるまでに必要な作業

この文書の適用条件

そのまま実行できるコマンド

# 対象: 自組織のアプリケーションリポジトリ（言語不問）
# 権限: リポジトリの読み取り権限
# 変更作業: なし（検索のみ）
# Production 実行: 該当なし（手元またはCIで実行）

# 1) 代表的なキー名に値が直接代入されていないかを探す
#    環境変数から読んでいる行は除外して、残ったものを目視で確認する
grep -rInE "(api[_-]?key|secret|password|passwd|token|access[_-]?key)[[:space:]]*[:=]" --exclude-dir=.git --exclude-dir=node_modules --exclude-dir=vendor . | grep -vF -e "process.env" -e "os.environ" -e "getenv" -e ".example" -e ".sample"

# 2) 秘密鍵そのものが混入していないか
grep -rIn -- "-----BEGIN" --exclude-dir=.git .

# 3) 接続文字列の形（ユーザー名とパスワードが埋め込まれたURL）を探す
grep -rInE "(postgres|mysql|mongodb|redis|amqp)://[^:@/]+:[^@/]+@" --exclude-dir=.git .

# 4) 現在のコードから消しても履歴には残る。過去のコミットも確認する
git log --oneline -S "BEGIN PRIVATE KEY" | head -n 20

# 対象: Node.js / Python のアプリケーションリポジトリ
# 権限: リポジトリの読み取り権限とパッケージレジストリへの通信
# 変更作業: なし（監査のみ）
# Production 実行: 該当なし（CIまたは開発環境で実行）

# Node.js: ロックファイルを基準に既知の脆弱性を照合する
npm audit --audit-level=high

# Python: requirements もしくはインストール済み環境を監査する
pip-audit -r requirements.txt

# コンテナで配布する場合は、ベースイメージ側のパッケージも別途監査対象になる
# （アプリの依存監査だけではOSパッケージの脆弱性は検出されない）

結果の読み方

こういう状況で使います

• ローカルでは動くのに、本番に載せる段になって何から手を付ければよいか分からない
• 設定ファイルに本番のAPIキーが直接書かれている
• 開発環境と本番環境が同じデータベースを見ている
• エラーが起きても誰にも通知されず、ユーザーからの連絡で気づく
• デプロイはできるが、前のバージョンに戻す手順が無い
• 想定外のクラウド課金が月末に判明する

考えられる原因（可能性の高い順）

1. 01

   生成の目的が「動くこと」に置かれている

   AIに与える指示は多くの場合「この機能を実装して」であり、環境分離や監視のフックは指示に含まれません。指示に無いものは出力にも含まれないため、機能以外が体系的に抜けます。

2. 02

   サンプルコードの慣習をそのまま持ち込んでいる

   学習素材のサンプルは、簡潔さのために鍵を直書きし、エラー処理を省略し、単一環境を前提にしています。生成物がこの慣習を引き継ぐことがあります。

3. 03

   運用要件が要求として書かれていない

   可用性、復旧目標、ログ保持期間、コスト上限が決まっていないと、実装のしようがありません。要件が無い状態では抜けを検出することもできません。

4. 04

   本番と同等の検証環境が無い

   検証環境が無い、あるいは構成が本番と異なると、マイグレーションや切り戻しを試せません。試していない手順は本番で初めて失敗します。

確認手順

1. 1

   リポジトリ内のシークレットを検索する

   参照のみ

   上記の grep コマンドで直書きされた鍵を洗い出します。検出された鍵は失効させることを前提にしてください。

2. 2

   環境ごとの接続先を突き合わせる

   参照のみ

   各環境の設定ファイルまたは環境変数を並べ、データベース・外部API・ストレージの接続先が環境ごとに分かれているかを確認します。

3. 3

   依存パッケージを監査する

   参照のみ

   `npm audit` または `pip-audit` を実行し、深刻度の高いものから確認します。

4. 4

   認証が必要なエンドポイントを列挙して確認する

   低

   認証トークンを付けずに各エンドポイントを呼び、意図せず公開されているものが無いかを確認します。検証環境で実施してください。

5. 5

   検証環境でマイグレーションの巻き戻しを実行する

   中

   適用と巻き戻しを一度通し、データの欠損が起きないかを確認します。本番では実施しないでください。

6. 6

   バックアップから復元して起動する

   中

   取得済みバックアップを別環境に復元し、アプリが起動して主要な操作ができることを確認します。

対応方法

バージョン・環境による違い

これで解決しない場合に確認すること

• 認証前に到達できるエンドポイントを数える

  ヘルスチェック以外に認証不要のエンドポイントが無いかを確認します。あればレート制限と入力検証を優先します。

• ログに個人情報が含まれていないかをサンプリングで確認する

  直近のログを抽出し、メールアドレス・電話番号・トークンが出力されていないかを確認します。

• 依存先の外部APIが落ちたときの挙動を確認する

  外部APIのタイムアウト時にアプリ全体が応答不能になっていないかを確認します。

• 証明書の有効期限を監視対象に入れているか確認する

  自動更新の設定があっても、失敗時に気づく仕組みが無ければ同じ結果になります。

• 担当者以外が起動・停止できるかを確認する

  手順書を渡して別の担当者に実行してもらい、書かれていない前提知識を洗い出します。

この文書の根拠と限界

よくある質問

この文書がカバーする質問

• AIアプリケーションのサービス化チェックリストが知りたい
• AIが作ったコードを本番公開するには何が足りないのか
• AI生成アプリのセキュリティで最初に確認すべきことは何か

リスク表示の意味

• 参照のみデータと設定を変更しません。
• 低影響は限定的ですが、権限と負荷の確認が必要です。
• 中性能・ロック・コストに影響する可能性があります。
• 高障害・データ損失・復旧作業が発生する可能性があります。
• 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

上記の項目は、外部に委託せずに自組織で実施できます。判断が必要なのは、どの項目を今回のリリースまでに満たし、どれを次に回すかという優先順位付けです。GIIP では AI が生成したアプリケーションを本番へ載せる際、環境分離とシークレットの外出し、切り戻し手順の実測、監視の受け口の3点を先に満たしてから公開する運用にしています。優先順位の判断材料が足りない場合は、現在の構成を見たうえで不足箇所を整理することもできます。

関連サービス

• Dev / Stg / Prod の分離を設計する
• AIアプリの本番リリース支援
• AIプロダクション運用