AIが書いたコードのテストとレビュー：鵜呑みにしないための基本動作
この記事の結論
- AIコーディングエージェントは自信ありげに「動くコード」を出してきますが、それがすべて正しいとは限りません。
- この記事では「なぜ動いただけでは足りないのか」「テストはどこから書くか」「レビューで何を見るか」「テストとレビューの使い分け」「失敗パターン」を扱います。
- 最終更新 2026-09-11／読了目安 約9分。
AIコーディングエージェントは自信ありげに「動くコード」を出してきますが、それがすべて正しいとは限りません。鵜呑みにせず確認するための、テストとレビューの基本動作を解説します。
最終更新: 2026-09-11・読了目安 約9分
なぜ「動いた」だけでは足りないのか？
簡単に言うと、AIが出したコードは「まだ確認していない下書き」です。読んで、動かして、想定外の入れ方を1つ試すまでは完成として扱わない。それだけで事故の大半は防げます。
AIコーディングエージェントに機能を作らせると、一見きれいに動いているように見えることがよくあります。しかし「今試した操作では問題が起きなかった」ことと、「あらゆる状況で正しく動く」ことは別物です。想定外の入力、通信が失敗したとき、同時に複数の操作が行われたときなど、たまたま試さなかった場面で不具合が出るケースは珍しくありません。
AIは、もっともらしく見えるコードを自信満々に提示することがあります。文法的に正しくても、意図と違う動きをする・特定の条件で例外的に壊れる、といったことは十分に起こり得ます。だからこそ、「動いたから完成」ではなく「確認したから完成」という基準に切り替えることが重要です。
テストはどこから書けばよいのか？
テストとは、「こう入力したら、こう返ってくるはず」という確認作業を、再現できる形で残しておくことです。手動で毎回同じ操作を繰り返して目視確認するよりも、条件と期待する結果をあらかじめ書いておくことで、変更のたびに機械的に確認できるようになります。
| 種類 | 何を確かめるか | 具体例（メモ保存機能なら） |
|---|---|---|
| 正常系 | 想定どおりの使い方で正しい結果が返るか | 本文を入力して保存すると、一覧に1件増える |
| 異常系 | 想定外の状況で適切にエラー処理されるか | 空のまま保存すると、保存されずエラーが表示される |
| 境界値 | 境目で挙動が崩れないか | 0件のときの一覧表示、文字数上限ちょうどの保存 |
正常系・異常系・境界値という分類は、JSTQB（Japan Software Testing Qualifications Board）など第三者認定機関でも整理されている基本的な考え方で、体系的に学びたい場合の参照先になります。より計画的にテストと向き合いたい場合はテスト駆動開発（TDD）をAIと進める方法も参考にしてください。
AIにテストコード自体を書かせることもできます。ただし「実装したAI自身にテストも書かせて安心する」のは落とし穴です。実装のバグに合わせたテストを書いてしまえば、通っても意味がありません。期待する動作は自分の言葉で先に整理しておきましょう。
レビューでは何を見ればよいのか？
テストで動作を確認するのと並行して、コードの中身についても最低限の目視レビューを行いましょう。専門的な文法を全部理解する必要はありません。次の観点だけでも、大きな見落としをかなり防げます。
| 観点 | 見つけ方 | 見逃すとどうなるか |
|---|---|---|
| 入力チェック | ユーザーからの入力を無条件で扱っていないか | 想定外の入力で壊れる・悪用される |
| 秘密情報の直書き | パスワードやAPIキーがコードに書かれていないか | 公開リポジトリごと鍵が外部に出る |
| エラー処理 | 失敗したときに黙って処理が終わっていないか | 失敗に誰も気づかないまま動き続ける |
| 変更範囲 | 頼んでいない箇所まで書き換えられていないか | 直したつもりが別の機能を壊す |
セキュリティに関わる観点をさらに詳しく確認したい場合はAIが生成したコードのセキュリティ確認：最低限のチェックリストもあわせてご覧ください。不安な点があれば、そのままAIに「このコードの、この部分は何をしているか説明して」と聞き返すのも有効です。説明が曖昧だったり、質問への回答がコロコロ変わったりする場合は、実装自体を疑うサインになります。
初心者が陥りやすい失敗パターンは？
- 失敗：見た目が動けば即公開してしまう → 異常系のテストをせず公開し、想定外の入力でエラーが起きる。公開前に最低限の異常系確認を挟みましょう。
- 失敗：エラーメッセージを読まずにAIに丸投げする → 原因の手がかりを自分で捨ててしまうことになります。エラー文はまず自分でも目を通し、AIへの質問にそのまま含めましょう。
- 失敗：修正のたびに全体を再確認しない → ある箇所を直したら、別の箇所が壊れていた、というのはよくある話です。変更のたびに、関連する箇所も含めて再確認する習慣が必要です。
- 失敗：仕様があいまいなままテストを書く → 何が正しいかの基準がなければ、テストも当てずっぽうになります。仕様駆動開発で先に受け入れ基準を明確にしておくと、テストの精度も上がります。
テストとレビューはどう使い分けるのか？
2つは代わりになりません。テストは「動きが期待どおりか」を機械が何度でも確かめる仕組み、レビューは「そもそもこの作り方でよいか」を人が判断する工程です。時間がないときは、壊れると影響が大きい処理からテストを書き、公開前の最終確認にレビューを置きます。
| 比べる観点 | テスト | レビュー |
|---|---|---|
| 確かめること | 入力に対する結果が期待どおりか | 作り方・安全性・変更範囲が妥当か |
| 実行するもの | 機械（毎回同じ条件で自動） | 人（文脈を踏まえて判断） |
| 得意 | 作り直したときの後戻り検知 | 秘密情報の直書きなど設計上の問題 |
| 苦手 | 書いていない条件は何も守らない | 毎回すべてを同じ精度で見るのは難しい |
公的な資料でも、開発工程に確認作業を組み込むこと自体が推奨されています（NIST SP 800-218、IPA「安全なウェブサイトの作り方」）。
「確認する習慣」が最大の防御になる
AIコーディングエージェントの実力は日々上がっていますが、それでも「人が最終確認をする」工程を省略してよい段階には達していません。テストとレビューは面倒に感じるかもしれませんが、慣れれば数分の作業です。小さな習慣の積み重ねが、公開後のトラブルを大きく減らします。同じ確認を繰り返し行うなら、合格の条件を書き出して定期的に測る評価（Evals）の形にしておくと、品質が落ちたときに気づけるようになります。
参照した一次情報
- JSTQB（ソフトウェアテスト技術者資格認定）：テスト技法の用語と体系。
- NIST SP 800-218（SSDF v1.1）：開発工程に確認を組み込むための実践のまとめ。
- IPA「安全なウェブサイトの作り方」：入力チェックなど、レビューで見る観点の背景。
よくある質問
Q1. テストがなくても最低限レビューだけで十分ですか？
レビューだけでは動作の確認まではできません。可能であれば正常系・異常系・境界値の3点だけでもテストを用意し、レビューと組み合わせて確認することをおすすめします。
Q2. 実装したAI自身にテストを書かせても大丈夫ですか？
実装のバグに気づかないまま、それに合わせたテストを書いてしまうことがあるため注意が必要です。期待する動作は自分の言葉で先に整理し、テストの妥当性は人が確認しましょう。
Q3. レビューで専門知識がなくても見るべきポイントはありますか？
入力チェックの有無、秘密情報の直書きがないか、エラー処理が書かれているか、変更範囲が妥当かの4点を確認するだけでも、大きな見落としをかなり防げます。
Q4. テストは何件くらい書けばよいですか？
件数の正解はありませんが、1つの機能につき正常系1件・異常系1件・境界値1件の3件から始めると続けやすくなります。壊れたら困る箇所と、実際に壊れた箇所を優先して足していくのが現実的です。
Q5. AIが書いたテストが全部通っているのに不具合が出るのはなぜですか？
テストが確認しているのは「テストに書いた条件」だけだからです。仕様があいまいなまま書かれたテストや、実装に合わせて書かれたテストは、実装の誤りをそのまま正解として固定してしまいます。期待する動作を先に人の言葉で決めてから、テストがその条件を本当に確認しているかを読み返してください。