Ai code verification

AI Code Verification

AIが生成したコードは構文的には整っているが、確信を持って微妙に間違っていることが多い。「もっともらしいが検証されていない実装」（trust-then-verify gap）は最大の失敗パターンであり、検証ループを自分で閉じない限り、この確認は常に人間の仕事として残り続ける。

鉄則（Iron Law）

1. 「完了した」ではなく「チェックが通った」を完了の定義にする。 実行可能な検証（テスト・ビルド・lint・実行結果）がないまま「動くはず」で報告しない。
2. importやメソッド呼び出しの実在を仮定しない。 生成直後に定義へジャンプして確認する。存在しないAPIを平然と使うのがAI生成コードの典型的な失敗モード。
3. 依存関係は追加前に必ず実在確認する。 LLMが提案するパッケージ名の一定割合は実在しない。lockfileにない名前は fail closed（追加を許可しない）。
4. 抽象化は rule of three で判定する。 3つの具体的ユースケースが揃うまで共通化・抽象化しない（AIが起こしがちな「早すぎる抽象化」への検証観点。恒常的な設計規律としては deep-module-design を参照）。
5. 自己レビューはバイアスがかかる。 実装した本人（同一コンテキスト）による確認だけで完了とせず、可能ならフレッシュな視点での再検証を挟む。

作業手順

ステップ1: 検証基準を先に決める

1. 実装前に「何が確認できれば完了と言えるか」を明確にする（期待する入出力、テストケース、ビルドコマンド）。
2. 検証手段が用意できない変更は、着手前にどう検証するかを決めてから進める。

ステップ2: ハルシネーションAPIを検出する

1. 生成コードが呼び出しているimport・メソッド・クラスについて、実在を仮定せず定義にジャンプ（grep/検索）して確認する。
2. 新規コードが既存コードベースの慣習に沿っているか確認する。学習データ由来の別アーキテクチャ・別フレームワークの流儀を持ち込んでいないか疑う。

ステップ3: 依存関係の追加を検証する（slopsquatting対策）

1. 新しい依存関係を提案したら、レジストリ（npm/PyPI等）に実在するか確認する。
2. メンテナの妥当性（登録者、ダウンロード数、最終更新日）を確認してから追加する。
3. lockfileにない名前でのインストールは許可しない。
4. 既にプロジェクトで使っているライブラリの中から選ぶことを優先し、未検証の新規パッケージの提案は最小限にする。

ステップ4: テストの実効性を確認する

1. 各テストについて「バグを仕込んだら本当に落ちるか」を自問する。
2. モックが期待値をハードコードしているだけの同語反復テスト（tautological test）になっていないか確認する。実装の出力をそのままアサーションにコピーしていないかを見る。
3. 幸せパスだけでなく、null入力・タイムアウト・空結果・並行アクセス・部分失敗などの異常系を必ず辿るテストがあるか確認する。

ステップ5: 検証ループを実行し証拠を残す

1. テスト実行・ビルド・lintを実際に走らせる。
2. UI変更は元デザインとスクリーンショットを比較し、差分をリストして修正する。
3. ビルド失敗や検証失敗を、症状の抑制（テストを緩める、エラーを握りつぶす）で片付けない。根本原因を特定してから直す。
4. 実行結果（テスト出力、コマンドの戻り値、スクリーンショット）を完了報告の証拠として提示する。

ステップ6: アドバーサリアルレビュー（独立視点での再検証）

1. 実装が一段落したら、可能であれば独立したコンテキスト（サブエージェント等）に差分と検証基準だけを渡し、計画とのギャップを報告させる。実装時の試行錯誤や理由づけは見せない。
2. レビュー観点は「正しさ・要件充足に関わるギャップ」に限定する。スタイル選好や好みの書き方の指摘は無視してよいと明示する。
3. 指摘は全て追いかける必要はない。正しさに関わるものだけ対応する（レビュー担当は指摘を見つけるよう仕向けられているため、過剰対応・過剰設計を防ぐ）。

チェックリスト

生成直後:

• すべてのimport・API呼び出しの実在を確認したか（存在を仮定していないか）
• 新規依存関係はレジストリで実在・妥当性を確認したか
• lockfileにない依存を無検証で追加していないか

完了報告前:

• テスト・ビルド・lintを実際に実行し結果を確認したか
• テストは「バグを仕込んだら落ちる」実効性があるか（同語反復になっていないか）
• 異常系（null・タイムアウト・並行・部分失敗）を辿るテストがあるか
• 抽象化は3ユースケース揃う前に導入していないか
• 独立視点での再検証（アドバーサリアルレビュー）を挟んだか、または挟めない理由が明確か

アンチパターン集

やりがちな思考	現実
「このAPIは存在するはず、よく使われる名前だし」	LLMは尤もらしい名前を生成するのが得意なだけで、実在の保証にはならない。定義にジャンプして確認する
「パッケージ名を思いついたのでそのままインストールしよう」	存在しないパッケージ名は攻撃者に先回り登録される（slopsquatting）。lockfile照合とレジストリ確認を先にする
「テストが全部greenだから完了」	greenであることと実効性があることは別。バグを仕込んでも落ちない同語反復テストが紛れていないか確認する
「念のため共通化しておこう」	3ユースケース揃う前の抽象化は過剰設計になりやすく、後の変更を逆に難しくする
「自分で書いたコードだから自分で見れば十分」	同一コンテキストでの自己レビューは実装時の推論に引きずられる。フレッシュな視点でしか気づけない齟齬がある
「ビルドが通らないのでとりあえずエラーを握りつぶそう」	症状の抑制は根本原因を隠すだけ。原因を特定してから直す

出典

• Anthropic Engineering: Claude Code Best Practices — https://code.claude.com/docs/en/best-practices （"Give Claude a way to verify its work", "Add an adversarial review step"）
• Tenki Blog: Reviewing AI Generated Code: A Practical Checklist — https://tenki.cloud/blog/reviewing-ai-generated-code-checklist
• GitHub Docs: Review AI-generated code — https://docs.github.com/en/copilot/tutorials/review-ai-generated-code
• Snyk: Slopsquatting mitigation strategies — https://snyk.io/articles/slopsquatting-mitigation-strategies/
• Snyk: Package Hallucination — https://snyk.io/articles/package-hallucinations/