AI生成コードをそのまま公開する前に確認すること

公開前レビューは、証拠が残る順番で進める

各段階で「確認できた」「不明」「停止」のいずれかを決めます。不明な項目を残したまま次へ進むと、最後の公開判定で戻りが発生します。

1. 依存関係を固定する 確認証拠：package.json とロックファイル、更新方針、利用中の依存関係一覧を照合する。
   停止条件：バージョンが再現できない、不要なパッケージが残る、影響範囲を説明できない既知の問題がある。
   具体例：AIの提案を試すためだけに追加したライブラリが本番の依存関係へ残っている。
   条件別判断：実行経路に関わる未対応の問題は延期し、未使用なら削除して再確認する。
2. 秘密情報を配布物から分ける 確認証拠：リポジトリの履歴、ビルド成果物、環境変数の設定、エラーログを確認し、保管場所・参照権限・失効担当を記録する。
   停止条件：APIキーやパスワードがコード、履歴、ブラウザへ渡る成果物、ログのいずれかに残る。または漏えい時の失効手順がない。
   具体例：生成されたサンプルのキーを環境変数へ移したが、過去のコミットと例外ログには値が残っている。
   条件別判断：値が露出したら公開を止めて失効・再発行し、変数名と保管場所だけを証拠に残す。
3. 入力と例外の境界を試す 確認証拠：空値、長文、想定外形式、境界値を送るテスト結果と、返すステータス・エラーメッセージを記録する。
   停止条件：入力値で処理が継続できない、スタックトレースや秘密が返る、想定外例外を利用者向けにそのまま表示する。
   具体例：id=abc や極端に長い本文で、SQLエラーや内部パスがレスポンスに出る。
   条件別判断：期待する不正入力は安全なエラーで拒否し、予期しない例外は詳細をログへ分離してから再テストする。
4. 認証と認可をサーバー側で分けて確認する 確認証拠：未ログイン、一般利用者、別利用者、管理者の操作表と、直接APIを呼んだ結果を記録する。
   停止条件：画面で隠しているだけでAPIが通る、別利用者の対象を読める・変更できる、認証と権限の担当や失敗時の処理が不明である。
   具体例：画面では自分の注文だけ表示していても、/api/orders/other-id のIDを変えると取得できる。
   条件別判断：認証・認可の拒否をサーバーが証明できなければ延期し、利用者・対象・操作ごとの拒否テストを追加する。
5. ログで追跡できる状態にする 確認証拠：成功・認証失敗・認可拒否・例外のサンプルログ、マスキング結果、通知先と対応担当を確認する。
   停止条件：秘密や個人情報が記録される、重要操作の結果を追えない、異常を検知しても通知先・対応者が決まっていない。
   具体例：デバッグ用にフォーム全体をログへ出し、障害通知が作成者の個人チャットにしか届かない。
   条件別判断：不要な値を出すログは止めてマスキングし、テストイベントが担当者へ届くまで公開しない。
6. 第三者が引き継げる資料を残す 確認証拠：構成、変数名、デプロイ、ロールバック、復旧、テスト、連絡先をREADMEへまとめ、作成者以外が手順を再現した記録を残す。
   停止条件：秘密の値が資料に書かれている、停止・復旧手順がない、担当者不在時の連絡先や責任範囲が不明である。
   具体例：作成者のローカル設定と記憶がないとデプロイもロールバックもできない。
   条件別判断：別の担当者が再現できるまで延期し、値ではなく保管場所と更新方法を資料化する。

条件別の公開判断

「問題が見つからない」ではなく、確認結果から次の行動を決めます。自動スキャンの問題なしという結果だけでは、公開可とは判定しません。

このページの範囲と次に読むもの

AI生成コードは、生成手段ではなく本番へ置くコードと運用の確認対象です。AIの回答、テストの一度の成功、自動スキャンの結果は補助情報であり、正式な脆弱性診断や安全性の保証ではありません。

7領域を網羅的に点検する場合は公開前セキュリティチェックリスト、本番化の環境・復旧の順序は本番公開までの流れ、確認手法の違いは公開前チェックと脆弱性診断の違いをご覧ください。引き継ぎ資料の整備はアプリ開発・運用の引き継ぎ、他のテーマはガイド一覧から選べます。

不明な項目を、公開前に整理する

構成や証拠が分からない項目は「不明」のままで構いません。現状と停止条件を整理したい場合は、無料で状況を相談する（自動診断や予約画面ではありません）をご利用ください。