AIが生成したプルリクエストのマージ前チェックリスト
Rui Li
AIコーディングエージェントが作成したプルリクエストは、完全に準備が整っているように見えることがある。差分はきれいで、リンターは通り、存在するテストはグリーンだ。しかし、それらのどれも、実際に誰かがクリックして操作したときに機能が動作するかどうかを教えてくれない。
ここでは、AIが生成したPR専用のチェックリストを紹介する。人間が一行ずつ書いたコードよりもこの種のコードで頻繁に現れる失敗パターンに対応している。
想定外のファイルで何が変わったかを差分で確認する
AIコーディングエージェントは変更をその全体にわたって追跡するのが得意であり、それは通常は強みだ。しかし同時に、期待していたファイルだけでなく差分のすべてのファイルを注意深く確認すべき理由でもある。
「チェックアウトに割引コードフィールドを追加する」というリクエストは、チェックアウトフォーム、注文確認メールのテンプレート、そして他の3つのフローで共有されているバリデーションユーティリティに触れるかもしれない。3番目の変更は素早く眺めただけでは見落としやすく、まさに無関係な何かを壊す種類の編集だ。
コードを読む前にファイルリスト全体を確認しよう。予期していなかったファイルが変更されていた場合、それは最後に理解すべきことではなく、最初に理解すべきことだ。
グリーンのテストスイートだけを信用しない
AIが生成したPRでテストスイートが通ることは、コードが内部的に一貫していることを示す。コードが正しいことを示すわけではない。
この区別が重要なのは、AIコーディングエージェントがテストを書く方法によるところが大きい。実装を生成したのと同じ機能理解から書かれるからだ。エージェントが要件を誤解していた場合、エージェントが書くテストはその同じ誤解を期待される動作としてエンコードすることが多い。テストは通る。バグはグリーンのチェックマーク付きでリリースされる。
コード層のテストは維持する価値がある。ただ、マージしようとしているPRに対してそれだけでは十分ではない。
ユーザーが実際に操作する方法で機能を実行する——コードの実装方法ではなく
これは、コードレビューとユニットテストの両方が見落とすものを発見するステップです。つまり、機能を要求した人が実際に使う方法で、エンドツーエンドの動作を確認することです。
AIコーディングエージェントが1日に複数のPRを生成するようになると、すべてのPRに対してこれを手動で行うのはスケールしません。そこでTestSpriteがこのチェックリストに組み込まれます。Claude CodeまたはCursor内のMCPサーバーを通じて接続し、1つの指示でアプリケーションを起動し、実際のユーザーセッションと同じ方法で新機能を実行します。割引コードの入力、フォームの送信、注文合計に割引が正しく反映されているかの確認、確認メールに正しい金額が表示されているかの確認まで行います。
他の検証ツールはコードを読んで推測します。TestSpriteはあなたのアプリを開いて実際に使います。
GitHub Actionsインテグレーションを設定しているチームの場合、このステップはPRが開かれた瞬間にプレビューデプロイメントに対して自動的に実行され、誰かがコードのレビューを開始する前に結果がPRコメントとして投稿されます。
PRが変更していない部分の製品動作を検証する
AIが生成したPRで最もリスクの高い障害は、多くの場合、差分に一切記載されていない箇所に現れます。フォームの入力バリデーション方法の変更が、3つ先の画面で使われている共有コンポーネントに影響を与えることがあります。バックエンドのフィールド名の変更が、古いフィールド名を参照しているフロントエンドビューをサイレントに破壊することもあります。
PRのタイトルに記載された特定のフローだけを検証するマージ前チェックでは、このカテゴリの問題をまったく検出できません。TestSpriteの探索エージェントは、開発者が変更されたと考えるフローだけでなく、テスト実行中に製品のより広い範囲をカバーします。これこそが、このクラスの障害をマージ後ではなくマージ前に発見できる理由です。
シナリオ：オンライン家庭教師マーケットプレイスがサイレントな返金バグを発見
オンライン家庭教師マーケットプレイスを開発する小規模チームが、Claude Codeを使用して、生徒がレッスンをキャンセルし、通知のタイミングに応じた日割り計算での部分クレジット返金を受け取れる機能を追加しました。
PRは完成しているように見えます。キャンセルフローは機能し、クレジットは生徒のアカウントに表示され、エージェントが作成したテストはすべてパスします。
マージ前に、開発者がトリガー指示を実行します。TestSpriteのエージェントがテストレッスンを予約し、いくつかの異なる通知タイミングでキャンセルし、クレジット金額を日割りルールと照合します。ほとんどのケースは正しく機能します。しかし1つのケースで問題が発生します。ちょうど24時間のカットオフ時点でのキャンセルで、比較ロジックが包含的な不等号を使うべきところで厳密な不等号を使用していたため、返金額が部分レートではなくゼロに丸められてしまいます。
これは1文字のバグであり、差分をざっと読んでいる開発者なら見過ごしてしまうような種類のエッジケースです。実際のキャンセルを実際の境界時刻で実行したからこそ発見できました。
失敗の説明には正確なシナリオが記載されています。24時間時点でのキャンセル、期待される部分クレジット、実際のクレジットはゼロ。修正は1行で済みます。開発者がそれを適用し、同じ指示を再実行して確認し、境界ケースをカバーした状態でマージします。
認証と権限のリグレッションを専用にチェックする
AIが生成した共有ロジックへの変更は、意図せぬ副作用としてアクセスルールを緩めたり厳しくしたりすることがあります。たとえば、家庭教師マーケットプレイスの予約権限のリファクタリングによって、誤って生徒が別の生徒のプライベートレッスンノートを閲覧できてしまう可能性があります。
これは「テストが検出したはずだ」という思い込みではなく、専用のチェックが必要な項目です。認証済みフローのテストには適切な権限レベルの実際の認証情報が必要ですが、TestSpriteのAuto-Authが各実行前にパスワードエンドポイントとOAuthリフレッシュフローを自動的に処理するため、テスト認証情報のセットアップが面倒だからといってスキップされることなく、実際の認証済みセッションに対して権限チェックが実行されます。
まとめ
クリーンな差分、パスするリンター、グリーンのテストスイートは、AIが生成したPRの最低条件であり、ゴールではありません。コードベースを真に保護するチェックリストには、機能のエンドツーエンド実行、PRが変更していない箇所の確認、そして経験豊富なQAエンジニアが行うような境界ケースの検証が含まれます。
TestSpriteは、そのチェックリストをIDE内からの1つの指示に変換します。MCPサーバー、Webポータル、またはすべてのPRに対するGitHub Actionsを通じて接続されます。
TestSpriteをPRワークフローに追加し、AIが生成したすべてのプルリクエストにマージ前のプロダクトレイヤーチェックを実装しましょう。