AI生成テストコードのレビュー観点7つ｜AIコードレビューはどこまで使えるか

AIにテストコードを書かせると、数分で動くものが出てきます。
実行すれば緑になり、一見すると問題ありません。

ところが、そのまま取り込むと危険なコードが混ざります。
「通るが、何も守っていないテスト」が生まれるためです。

最も多い問題は、AIが現在の実装をなぞって期待値を書くことです。
実装が間違っていれば、間違いを正解として固定します。

この記事では、AI生成テストコードのレビュー観点7つを解説します。
AIにコードレビューをさせる場合の実力と限界も整理しました。

なぜAI生成コードでもレビューが必要なのか

「AIのほうが人より正確なのでは」という声もあります。
実際、構文の誤りや典型的な書き間違いは、人より確実に避けられます。

それでもレビューが要るのは、テストコードが「仕様の写し」だからです。
コードとして正しくても、仕様と違えば無意味になります。

レビューの目的	AI生成コードでの重要度	理由
文法・書式の誤りを見つける	下がった	AIはほぼ間違えない
仕様と合っているか確かめる	上がった	AIは仕様の全体を知らない
抜けている観点を補う	上がった	渡した情報の外は出てこない
書き方を統一する	変わらない	指示しなければ揺れる
担当者の教育	下がった	コードを書く人が減る

見るべき場所が「書き方」から「意味」へ移った、と理解してください。
従来と同じ観点でレビューすると、時間をかけて何も見つけられません。

加えて、生成量が増えるほどレビューが工程の詰まりになります。
1件あたりの確認を軽くする工夫が、実務では欠かせません。

AI生成テストコードで起きる4つの問題

生成されたコードは、文法的には正しく書かれています。
問題が起きるのは、テストとしての意味の部分です。

問題	症状	気づきにくさ
実装をなぞった期待値	不具合があっても常に成功する	非常に高い
検証が甘い	画面が表示されたことしか見ていない	高い
壊れやすい要素指定	少しの変更で落ちるようになる	低い（すぐ落ちる）
実行順序への依存	単体で動かすと失敗する	中程度

上の2つは、テストが「常に成功する」ため発見が遅れます。
本番で不具合が出て初めて、守られていなかったと分かります。

レビューで見る7つの観点

次の7点を順に確認します。
上から順に、重要度が高い並びです。

観点1｜期待値は仕様から導かれているか

最重要の観点です。
期待値の根拠が仕様書にあるかを確認します。

判定方法は簡単です。
意図的にコードを壊し、そのテストが失敗するかを見ます。

壊しても成功するテストは、何も守っていません。
この確認だけは、必ず実施してください。

観点2｜検証の中身が十分か

「エラーにならないこと」だけを見ていないか確認します。
登録処理なら、保存された値まで確認すべきです。

不十分な検証	あるべき検証
画面が表示された	表示された内容が正しい
エラーが出なかった	期待した結果が得られた
ステータスが200	応答の項目と値が仕様どおり
件数が0件でない	件数が想定どおりの数

観点3｜異常系が含まれているか

生成されたコードは、正常系に偏ります。
境界値、未入力、権限なしの操作が抜けやすい部分です。

観点表と突き合わせて確認します。
作り方はテスト観点の洗い出し手順｜観点表と抜け漏れ防止にまとめています。

観点4｜要素の指定が壊れにくいか

自動生成では、その場限りの指定が使われがちです。
画面の構造に依存した指定は、少しの変更で落ちます。

避けたい指定	望ましい指定
自動生成されたクラス名	テスト用に付けた属性
「3番目のボタン」など位置指定	ボタンの役割と表示名
長い階層をたどる指定	要素そのものを直接特定する指定

観点5｜待ち方が適切か

固定秒数の待機が入っていないか確認します。
実行が遅くなるうえ、環境によって失敗します。

「要素が表示されるまで待つ」形に書き換えます。
これは実行の安定性に直結します。

観点6｜単体で実行できるか

前のテストが作ったデータに依存していないか確認します。
1件だけ実行して通るかを試せば分かります。

あわせて、実行後の後片づけも確認します。
データが残ると、2回目から失敗します。

観点7｜機密情報が書かれていないか

生成時に渡した情報が、そのまま残ることがあります。
本番のIDやパスワード、実在するメールアドレスは削除します。

観点別｜直す前と直した後

指摘の内容を、具体例で示します。
いずれも生成コードで実際によく見る形です。

例1｜検証が甘い

// 直す前：ページが開いたことしか見ていない
await page.click('#submit');
await expect(page).toHaveURL(/complete/);

// 直した後：登録された内容まで確認する
await page.click('#submit');
await expect(page).toHaveURL(/complete/);
await expect(page.getByRole('heading')).toHaveText('登録が完了しました');
await expect(page.getByTestId('registered-email')).toHaveText('test@example.com');

画面遷移だけの確認は、処理が失敗していても成功します。
「何が正しければ合格か」を書き足します。

例2｜壊れやすい要素指定

// 直す前：自動生成されたクラス名と位置に依存している
await page.click('.css-1x2y3z4 > div:nth-child(3) > button');

// 直した後：役割と表示名で特定する
await page.getByRole('button', { name: '申し込む' }).click();

前者はデザイン変更のたびに落ちます。
後者は表示名が変わらない限り動き続けます。

例3｜固定秒数の待機

// 直す前：3秒待つ。遅い環境では失敗する
await page.waitForTimeout(3000);
await expect(page.getByText('完了')).toBeVisible();

// 直した後：表示されるまで待つ
await expect(page.getByText('完了')).toBeVisible({ timeout: 10000 });

固定待機は、遅いと失敗し、速いと無駄に待ちます。
件数が増えるほど、実行時間の差が効いてきます。

AIにコードレビューをさせられるか

逆方向、つまりAIをレビュー側に使う方法もあります。
ただし、得意な指摘と苦手な指摘がはっきり分かれます。

指摘の種類	AIレビューの精度	理由
書き方の統一、命名	高い	コード内で完結して判断できる
固定待機など既知の悪い書き方	高い	パターンが明確
例外処理の漏れ	中程度	文脈の理解が要る
検証の甘さ	中程度	何を守るべきかの前提が要る
期待値が仕様と合っているか	低い	仕様書を渡しても解釈がずれる
業務上の抜け漏れ	非常に低い	明文化されていない前提を知らない

AIレビューは「一次チェック」として使い、合否の判断には使いません。
形式的な指摘を先に潰しておけば、人のレビューが本質に集中できます。

AIレビューを効かせる指示の書き方

「レビューして」だけでは、当たり障りのない指摘が返ります。
観点を指定すると精度が上がります。

• 「このテストが失敗する条件を列挙して」と聞く
• 「実装を壊しても成功してしまう箇所はあるか」と聞く
• 「固定待機と壊れやすい要素指定を指摘して」と観点を絞る
• 仕様書を渡し、「期待値と仕様の差分を挙げて」と依頼する

とくに2番目は有効です。
人が見落としやすい「守っていないテスト」を拾えることがあります。

AIコードレビューツールの選択肢

プルリクエストを自動でレビューするサービスが増えています（2026年8月時点）。
テストコードのレビューにも使えます。

ツール	形態	特徴
CodeRabbit	SaaS	プルリクエストに自動でコメントする。日本語での指摘に対応
GitHub Copilot のレビュー機能	SaaS	GitHubに統合されており、導入の手間が少ない
Qodo	SaaS	テスト生成とレビューの両方を扱う
Greptile	SaaS	リポジトリ全体の文脈をふまえた指摘
汎用の生成AI	対話	無償の範囲で試せる。観点を指定して使う

まず試すなら、手元の生成AIに観点を指定して聞くだけでも効果があります。
継続的に回すと決めた段階で、プルリクエストに統合する製品を検討します。

注意点は、社外にコードを送る前提になることです。
取り扱いの制約は、導入前に社内規程と照らして確認します。

人とAIのレビュー分担

両方を使うなら、順番と役割を決めます。
同じ観点を二重に見ても意味がありません。

段階	担当	見るもの
1．自動チェック	ツール	文法、書式、未使用の記述
2．一次レビュー	AI	固定待機、要素指定、命名、明らかな漏れ
3．本レビュー	人	期待値の妥当性、観点の網羅、業務上の抜け
4．動作確認	人	実装を壊してテストが落ちるか

レビューが形だけになる問題は、AIを入れても解決しません。
対処はレビューの形骸化を防ぐ｜バグが漏れる現場の立て直しで扱っています。

レビューを仕組みにする

担当者の意識に頼ると、確認は続きません。
手順として組み込みます。

• AI生成のコードは、生成物である旨をコミットに書く
• 取り込み前に、実装を壊して落ちることを1件は確認する
• 7つの観点をチェックリスト化し、レビュー時に使う
• 指摘が多い観点を記録し、生成時の指示に反映する

4番目を続けると、生成物の品質が上がります。
同じ指摘を繰り返さずに済みます。

生成時の指示に基準を書いておく

レビューで毎回指摘するより、生成時に条件を渡すほうが早く済みます。
指示文に次の内容を含めます。

• 要素は役割と表示名で指定する（自動生成のクラス名は使わない）
• 固定秒数の待機は使わず、表示されるまで待つ
• 各テストは単体で実行できるようにし、後片づけまで書く
• 期待値には、画面の表示だけでなく保存された値も含める
• 実在するメールアドレスや認証情報は使わない

この5行を定型文として保存し、毎回貼り付けてください。
指摘の件数が目に見えて減ります。

レビューにかける時間の目安

すべてを同じ深さで見る必要はありません。
対象の重要度で、確認の深さを変えます。

対象	確認の深さ
決済・個人情報など事業影響が大きい機能	7観点すべて＋実装を壊す確認
主要導線の機能	期待値と検証内容を重点的に確認
影響の小さい画面	AIレビューの指摘対応のみ

重要度の低い部分まで丁寧に見ると、レビューが滞ります。
滞れば、結局その場しのぎで通されるようになります。

レビューチェックリスト

そのまま使える形にまとめました。
プルリクエストの説明欄に貼り付けて、確認済みの項目に印を付ける運用が手軽です。

#	確認項目	確認方法	重要度
1	期待値の根拠が仕様にあるか	仕様書の該当箇所を示せるか確かめる	必須
2	実装を壊すと失敗するか	対象の処理を1行変えて実行する	必須
3	表示だけでなく結果を検証しているか	保存値や応答の中身を見ているか確かめる	必須
4	異常系が含まれているか	観点表と突き合わせる	高
5	要素の指定が壊れにくいか	自動生成のクラス名や位置指定がないか探す	高
6	固定秒数の待機がないか	待機処理を検索する	高
7	単体で実行できるか	1件だけ指定して実行する	中
8	実行後にデータを片づけているか	2回続けて実行する	中
9	機密情報が含まれていないか	実在するアドレスや認証情報を検索する	必須
10	テスト名から意図が読み取れるか	名前だけを見て何を守るか分かるか確かめる	中

時間がない場合は、1・2・3・9の4つだけ見てください。
この4つで、重大な見落としのほとんどを防げます。

2番の「壊して失敗するか」は、10件に1件でも実施する価値があります。
1件でも成功したままなら、他のテストも同じ状態である可能性が高いためです。

よくある質問

AIが書いたテストは信用できませんか

下書きとしては十分に使えます。
期待値だけを人が確認すれば、作成時間を大きく短縮できます。

レビューにどれくらい時間がかかりますか

生成が速い分、レビューが工程の中心になります。
作成時間の削減分を、レビューに回す前提で計画します。

カバレッジが高ければ安心ですか

いいえ。
検証が甘いテストでもコードは通過するため、数値だけでは品質を判断できません。

まとめ｜壊して落ちるかを必ず確かめる

AI生成テストコードのレビューは、観点を絞れば短時間で済みます。
すべてを疑う必要はありません。

• 最重要は「期待値が仕様から導かれているか」
• 実装を壊して失敗するかを確認すれば、多くは見抜ける
• 検証の甘さと異常系の欠落が、次に多い問題
• AIレビューは一次チェックに使い、合否判断はしない
• 指摘の傾向を記録し、生成時の指示に反映する

手元にAI生成のテストが1本でもあれば、実装を壊して実行してみてください。
成功したままなら、そのテストは守っていません。

次に読むならこの記事

• テストに使えるAIツール｜Playwright MCPと選び方
• テストのAI活用｜効く工程と始め方・限界
• Playwright MCPでE2Eテストを自動化する方法｜導入手順と使いどころ

テストの手戻りを減らしたい方へ

テスト仕様書のExcelテンプレートを無料で配布しています。自社で整備する場合も、外部に任せる場合も、まずは型を持つところから。

テスト仕様書テンプレートを無料DL テスト代行について相談する