ユタラボ
🧰 Codex／AI開発術

AI生成コードの検品チェックリスト｜動いた後に見る12項目

AIが生成したコードをそのまま採用せず、仕様、境界値、秘密情報、権限、表示、アクセシビリティ、再現性の順に検品する12項目を解説します。

AI生成コードは、画面が表示されたりテストが1件通ったりしても、検品完了とは限りません。頼んでいない変更、異常な入力、別ユーザーのデータへ触れる権限漏れまで確認して、初めて採用を判断できます。ここでは受け取り直後に使える12項目を、変更範囲、影響の大きい箇所、再現可能な証拠の順に整理します。

動くと正しいは別

「起動した」「正常な値を1回入力できた」は、動作確認の一部にすぎません。正しさには、依頼した仕様に合うこと、想定外の入力を安全に処理すること、権限のない操作を拒否すること、既存機能を壊さないことも含まれます。

まずAIの説明ではなく実際の差分を見ます。変更ファイル、追加された依存関係、設定値、削除された処理を一覧にし、依頼と照合します。日常的な変更は差分を中心に、認証など影響の大きい機能は周辺のデータの流れまで確認します。

AIへの依頼段階から合格条件を明示すると、検品もしやすくなります。書き方はCodexへの依頼テンプレートで整理しています。複数担当へ分けた場合は、個別の差分だけでなく結合後の動作も必要です。並列化で開発を速くする方法も合わせて確認してください。

検品の順番を決める

12項目を一度に眺めるのではなく、次の4段階に分けると抜けを見つけやすくなります。前の段階で重大な不合格が出た場合は、先へ進む前に修正範囲を確定します。

段階主な確認対象合格の証拠不合格時の対応
1. 変更範囲仕様、差分、依存関係依頼と変更ファイルの対応表頼んでいない変更を分離する
2. 動作正常値、境界値、失敗時入力、期待結果、実結果再現条件を固定して修正する
3. 安全性秘密情報、認証、権限検索結果と権限別の試験結果影響範囲を確認し、採用を止める
4. 利用品質表示、キーボード操作、再現性実画面と実行ログ修正後に同じ手順で再検査する

仕様差分を確認する

最初の検品は「何を作ったか」ではなく、「依頼と何が違うか」の確認です。依頼文から、入力、処理、出力、変更禁止範囲、合格条件を抜き出し、差分と照合します。

たとえば「メールアドレスを保存するフォーム」なら、未入力、形式違い、二重送信、保存失敗、既存データの扱いまで仕様を分解します。仕様にない動作は、AIの判断で正解にせず採否を決めます。

特に見落としやすいのは、頼んでいない変更です。共通CSS、認証設定、環境変数、パッケージの更新などが混ざっていたら、必要性を説明できるまで分離します。コード量の多さではなく、変更の影響範囲を基準に見ると判断しやすくなります。

入力境界を試す

正常値だけを通すテストは、利用者が実際に遭遇する失敗を拾いにくいものです。入力には最小値、最大値、その直前と直後、空欄、形式違い、重複、非常に長い文字列を用意します。ファイルを扱うなら、拡張子だけでなく内容、容量、ファイル名、保存先も確認対象です。

最小テスト表は次のように作れます。期待結果を先に書き、実行後に実結果を埋めると、AIの出力に合わせて判定を変えるのを防げます。

入力・状況期待結果実結果
正常な代表値保存され、完了表示が出る未実行
空欄保存せず、修正箇所を示す未実行
上限ちょうど仕様どおり受け付ける未実行
上限を1つ超える安全に拒否し、理由を示す未実行
同じ操作を連続実行二重登録などが起きない未実行
保存先や通信が失敗秘密を出さず、再試行方法を示す未実行

自動テスト自体が仕様を間違えていれば、不具合は残ります。失敗するはずの入力が本当に失敗するかも確かめます。

秘密と権限を見る

セキュリティ確認では、入力がどこから来て、どこで処理され、データベース、ログ、画面、外部APIのどこへ渡るかを追います。OWASPのSecure Code Review Cheat Sheetは、入力検証、認証、認可、秘密管理などをレビュー対象として挙げています。さらにOWASP ASVSは、Webアプリの技術的なセキュリティ制御を検証する要件集として利用できます。認証や決済を含む変更では、一般的なチェックリストだけで終えず、該当するASVS要件まで確認します。

APIキー、トークン、パスワード、個人情報がソース、テスト、ログ、エラー表示へ入っていないか検索します。環境変数の参照先、デバッグ出力、生成物、コミット履歴も確認します。

ログイン済みかどうかと操作権限があるかは分けて試します。一般ユーザーが管理機能を呼べないか、URL中のIDを他人のIDへ変えても読めないか、拒否処理がサーバー側にもあるかを確認します。GitHubのpush protectionは対応する秘密をpush時に遮断しますが、公式資料には検知範囲の限界も示されています。人の差分確認と組み合わせてください。

表示とアクセシビリティを見る

画面の検品では、幅の広いPCだけでなく、狭い画面、文字拡大、長い日本語、英数字の連続、エラー表示を確認します。ボタンが画面外へ出ないか、文章が重ならないか、読み込み中に操作できない状態が伝わるかを実画面で見ます。

マウスを使わず、Tabキーでリンク、入力欄、ボタンへ順番に移動し、EnterキーやSpaceキーで操作します。現在どこにフォーカスがあるか見えることも重要です。W3CのWCAG解説では、キーボード操作可能な画面に、フォーカス位置が見える動作モードを求めています。

入力欄とラベルの結び付き、色だけに頼らないエラー表示、画像の代替テキストも確認します。WCAG 2.2の達成基準3.3.1は、自動検出した入力エラーについて、該当項目を特定し、内容を文字で説明することを求めています。ラベルの意味や操作順は、実際のキーボード操作を通して判断します。

再現可能な証拠を残す

最後に、次の12項目をそのまま作業票へコピーし、各項目へ「合格」「不合格」「対象外」と証拠を記録します。「たぶん大丈夫」は合格に含めません。

  • 1. 依頼した入力・処理・出力と実装が一致している
  • 2. 変更ファイルと依存追加が許可範囲に収まっている
  • 3. 既存機能の代表的な操作が壊れていない
  • 4. 空欄、最小値、最大値、上限超過を試した
  • 5. 形式違い、長文、重複、連続操作を試した
  • 6. 通信、保存、外部サービスの失敗を安全に扱える
  • 7. ソース、設定、ログ、生成物に秘密情報がない
  • 8. 認証だけでなく操作対象ごとの権限を検査した
  • 9. PC、狭い画面、文字拡大で表示を確認した
  • 10. キーボードだけで移動・実行でき、フォーカスが見える
  • 11. 実行コマンド、入力、期待結果、実結果を保存した
  • 12. 不合格箇所を修正後、同じ手順で再検査した

証拠には、コマンド、終了コード、対象差分、テスト結果、確認環境を残します。NISTのSecure Software Development Frameworkは、要件やリスクに合わせて安全な開発活動を整える成果ベースの枠組みです。この12項目も、認証や決済など対象のリスクに応じて追加してください。

よくある質問

AI生成コードは、テストが通れば採用してよいですか

テスト通過だけでは判断できません。テストが仕様を十分に表しているか、頼んでいない変更がないか、権限や秘密情報に問題がないかも確認します。

コードが読めない初心者は、何から確認すればよいですか

まず変更ファイルの一覧、実行したコマンド、正常時と失敗時の結果をAIに示させます。そのうえで、依頼文と画面の動作が一致するかを確認し、不明な差分は採用前に説明を求めます。

AIが生成したコードのセキュリティ確認はどこまで必要ですか

扱うデータと機能のリスクに応じて変わります。認証、決済、個人情報、ファイルアップロード、外部公開を含む場合は、秘密情報の検索と権限別テストに加え、OWASP ASVSなどの要件へ照らした確認が必要です。

不具合が見つかったら、AIへどう修正を頼めばよいですか

再現手順、期待結果、実結果、変更してよい範囲をセットで渡します。修正後は新しい手順へ置き換えず、同じ再現手順と周辺機能のテストをもう一度実行します。

関連記事

一次情報の確認メモ

続き（結論と実データ）はnoteに置いています

ここでは手順のところまで書きました。実際に出た数字、うまくいかなかった条件、そのまま使える設定ファイルは、 note の記事にまとめてあります。

noteで続きを読む Xをフォローする

🧰 開発術

Codexにコードレビューを任せる手順｜差分・再現・合格条件の渡し方

Codexへコードレビューを頼むときに、差分、再現手順、重大度、誤検知の確認、修正後の終了条件をどう渡すか、テンプレート付きで解説します。
🧰 開発術

Codex完全ガイド｜依頼・AGENTS.md・権限・レビュー・検証を一から組み立てる

Codexで安全にコードを変更するために、依頼文、AGENTS.md、サンドボックス、レビュー、テスト、ログ、引継ぎを一つの流れで解説します。
🧰 開発術

AIにコードを直させた後の回帰テスト｜前に動いた機能を壊していないか確かめる

AIによるコード修正後に、元の不具合が直ったことと既存機能を壊していないことを、影響範囲、正常系・異常系、近いテスト、全体テストの順で確かめる手順です。