定義と結論
AIの回答を検証するとは、文章が自然かどうかを評価することではありません。回答に含まれる主張を小さく分け、仕様、対象バージョン、実行結果、テスト、変更差分など、第三者が確かめ直せる証拠と照合する作業です。
AIの答えは結論ではなく、検証を始めるための仮説として扱います。
生成AIは、実在しないAPI、古いオプション、プロジェクトに入っていないライブラリを、もっともらしく説明することがあります。逆に、説明の一部が間違っていてもコードの一部だけは動く場合があります。そのため「全部正しいか」を一度に判断せず、「APIは存在するか」「この版で使えるか」「期待する入力で動くか」「失敗時も安全か」のように分解します。
なぜ証拠が必要なのか
AIは質問文からもっとも可能性の高い続きの文章を生成します。回答の流暢さと、事実の正しさは別です。また、開発では同じAPI名でもバージョン、実行環境、権限、設定によって結果が変わります。AIが一般論として正しくても、手元のプロジェクトには適用できないことがあります。
証拠を残す必要がある理由は三つです。
- 自分の思い込みを減らせる
- チームの人が同じ条件で再確認できる
- 後から依存関係や仕様が変わった時に判断をやり直せる
「動いた」は重要な証拠ですが、「正しい」「安全」「要件を満たす」のすべてを証明するものではありません。
登場人物と責任
学習者や実装担当者は、AIの提案を採用する前に対象環境と実行結果を確認します。レビュー担当者は、差分が要件に沿うか、不要な変更や危険な前提がないかを確認します。ライブラリの保守者や標準化団体が公開する公式資料は、APIや仕様を判断する一次資料です。テストは判断を自動で繰り返す仕組みですが、テストケースを選ぶ責任は人間に残ります。
AIを「責任を負う担当者」に置くことはできません。採用判断、秘密情報の扱い、本番への反映は、権限を持つ人が引き受けます。
証拠の種類と強さ
| 証拠 | 主に確認できること | 確認できないこと |
|---|---|---|
| 公式仕様・公式ドキュメント | APIの存在、引数、制約、推奨手順 | 自分のコードが正しく使っているか |
| lockfile・型・補完 | 導入済みバージョン、型上の整合 | 実行時の権限や外部サービスの状態 |
| 最小実行 | 特定条件での基本動作とエラー | 未実行の入力や同時実行時の挙動 |
| 自動テスト | 期待動作を繰り返し再現できること | テストに書かなかった要件 |
| 差分レビュー | 不要変更、秘密情報、危険操作 | 実行環境固有の不具合 |
| 本番相当環境 | 設定・ネットワークを含む統合 | 将来の全障害や全攻撃 |
証拠には役割があります。公式資料だけ読んでも実装ミスは見つからず、正常系の実行だけでは認可漏れを見つけられません。一つの強そうな証拠に頼るより、異なる弱点を持つ証拠を組み合わせる方が確実です。
検証の流れ
1. 主張を一文ずつ分ける
「このコードで安全に画像をアップロードできます」では広すぎます。「拡張子を制限する」「サイズ上限を設ける」「保存先を公開領域から分ける」「利用者本人だけが読める」のように分けます。主張が小さければ、必要な証拠も選べます。
2. 対象条件を固定する
言語、ランタイム、フレームワーク、パッケージのバージョン、OS、ブラウザ、認証方式を確認します。package.jsonだけでなくlockfileも見ます。「最新版なら使える」は、現在導入済みの版で使える証拠になりません。
3. 一次資料と照合する
検索結果の要約や個人ブログでAPI名を見つけても、最終的には公式ドキュメント、標準仕様、公式リポジトリのリリースノートへ戻ります。資料の日付、対象バージョン、非推奨表示も確認します。
4. 最小条件で実行する
アプリ全体を一度に動かす前に、入力と期待結果を小さくします。成功例だけでなく、空値、境界値、不正な型、権限なし、通信失敗も試します。実行したコマンド、終了コード、エラー全文を記録します。
5. テストと差分に残す
一度の手動確認は忘れられます。重要な期待動作は自動テストにし、変更前後の差分を読みます。AIが依頼していない設定変更、依存追加、認証の省略を混ぜていないかも確認します。
6. 採用範囲を明記する
AI回答の全体を採用する必要はありません。「説明は採用、コードは不採用」「正常系だけ採用し、エラー処理は既存実装を維持」のように範囲を決めます。
具体例：存在しそうなAPIを検証する
AIが「response.body.json()でJSONを取得できる」と回答したとします。まず主張を「Fetch APIのResponseからJSONを読むメソッド名」に限定します。MDNのResponse資料でjson()がResponse自身のメソッドであることを確認し、手元の型補完も確認します。最小コードでは次の形を試します。
const response = await fetch("/api/profile");
if (!response.ok) {
throw new Error(`HTTP ${response.status}`);
}
const profile = await response.json();
さらに、APIがHTMLのエラーページを返した時はjson()が失敗するため、NetworkパネルでContent-Typeと本文を確認します。この時点で「正しいメソッド名」と「常にJSONとして読める」は別の主張だと分かります。
主要パターンの使い分け
説明や概念の確認では、標準仕様と公式ドキュメントを先に使います。コード補完やコンパイルエラーが重要な型付き言語では、導入済みバージョンの型情報が強い証拠になります。アルゴリズムや変換処理は、入力と期待出力を固定した単体テストが有効です。認証、DB、外部APIは、権限なし・タイムアウト・重複実行を含む統合確認が必要です。
セキュリティに関わる変更では、正常にログインできるだけでは不足します。別ユーザーのIDを指定した場合、期限切れトークンの場合、入力に制御文字を含む場合も確認します。破壊的操作や本番データを使う検証はせず、隔離した環境とダミーデータを使います。
よくある誤解
AIが複数回同じ答えを出せば正しい
同じ前提から同じ誤りを繰り返すことがあります。AIへの再質問は別の証拠ではありません。
検索結果が多ければ正しい
同じ古い記事が転載・参照されている可能性があります。件数ではなく、仕様を管理する主体と対象バージョンを確認します。
テストが通れば完成
テストは書かれた条件だけを確認します。要件の読み違い、テスト不足、秘密情報のログ出力までは自動的に保証しません。
エラーが出なければ成功
処理が何もせず終了した、誤った保存先へ書いた、権限を広げて通した可能性があります。出力と副作用を確認します。
注意点とベストプラクティス
- AIへ秘密鍵、個人情報、本番ログを貼らない
- コマンドは意味を理解し、削除・上書き・権限変更を含まないか読む
- 公式資料でも対象バージョンと更新日を確認する
- 検証用データと本番データを分離する
- 失敗した検証も消さず、前提と結果を残す
- セキュリティ、決済、個人情報は担当者のレビューを追加する
証拠を集める目的はAIの間違い探しではなく、自分たちが採用判断を説明できる状態を作ることです。
デバッグと確認メモ
次の形式なら、後から別の人が追跡できます。
AIの主張:
対象バージョン・環境:
確認した一次資料:
実行したコマンド・テスト:
期待した結果:
実際の結果:
一致しなかった点:
採用した範囲:
残る未確認事項:
確認中に結果が食い違ったら、質問文を変えてAIに合わせさせるのではなく、バージョン、入力、環境変数、権限、再現手順を一つずつ固定します。スクリーンショットだけでなく、再実行できるテストやテキストログを優先します。ただしログに認証情報が含まれないようにします。
まとめ
AIの回答は、主張を分解し、対象条件を固定し、一次資料、型、最小実行、テスト、差分レビューで確かめます。どれか一つで安心せず、それぞれの証拠が確認できる範囲を理解して組み合わせることが重要です。
最終的な成果は「AIが正しかった」という感想ではありません。何を、どの条件で、どの証拠により採用したかを、別の人が再確認できる記録です。
