コードのレビューとテスト
コーディングエージェントは大量のコードを生成できるため、技術的負債も生み出しかねません。迅速に開発を進めることは重要ですが、品質基準は高く維持する必要があります。手書きのコードかエージェントが書いたコードかにかかわらず、マージするコードに求める基準は同じであるべきです。
AI が生成したコードは正しく見えても、微妙な誤りを含んでいることがあります。既存のパターンに従い、コンパイルでき、作成したテストに合格していても、エッジケースを見落としたり、セキュリティ上の問題を抱えていたり、コードベース内の別の場所にあるロジックを重複させたりすることがあります。
だからこそ、コードレビューは非常に重要です。高品質なコードベースを維持し、問題が本番環境に到達する前に検出するには、適切なプロセスを整備する必要があります。コードレビューを成功させるために投資することも、エンジニアとしてのあなたの役割です。
自己レビュー
他の人に見てもらう前に、コードを確認しましょう。
エージェントの作業を監視しましょう。 diffビューには、変更が加えられるたびに表示されます。エージェントが誤った方向に進んでいる場合は、Stop をクリックするか、Cmd Shift BackspaceCtrl Shift Backspace を押してキャンセルし、方向を修正してください。完了まで待つ必要はありません。大幅に方針を修正する場合は、機能の開発で説明したように、変更を元に戻し、プランを見直してから再実行してください。
エージェントにすべての変更をまとめて確認するよう依頼しましょう。 プロンプトで @Branch を指定すると、エージェントに現在のブランチの完全なdiffが渡されます。「このブランチの変更を確認して」や「今取り組んでいる内容は？」のように依頼すると、エージェントに豊富なコンテキストを与え、複数のファイルにまたがる問題を検出できます。
たとえば、エージェントに自身の作業を確認するよう依頼できます。
ピアレビューに備える
エージェントは一度に多くのコード変更を加えることがあります。その結果、数百行にわたる変更を含む大きなコミットが1つできてしまうことがあります。これは誰にとってもレビューが大変です。
明確な説明を付けた、小さく意味のあるコミットを使用することをおすすめします。各コミットは1つの論理的な変更を表します。人間のレビュアーは、大量のコード変更を読み解く代わりに、コミット履歴を順に確認できます。
このようなコミットの整理は手作業では面倒ですが、エージェントは得意です。例:
- まずは自由に機能を作りましょう。作業を繰り返している間は、コミットの整理を気にする必要はありません。
- すべてが動作したら、コミット履歴をレビューしやすい単位に再構成するようエージェントに依頼します。
- エージェントは
mainにリセットし、すべての変更を確認したうえで、説明的なメッセージを付けた整理されたコミットを作成するための論理的な順序を計画します。 - 最終的なdiffが元の変更内容と一致することを検証するため、変更が失われることはありません。
このプロンプトを使用してスキルを作成すると、チームの誰もが機能の完成後に /rework-commits を実行できます:
Create a skill file at .cursor/skills/rework-commits/SKILL.md with this content: # Split branch into reviewable commits Rework a branch into a sequence of small, semantic commits for review. ## Important - Prepend `GIT_EDITOR=true` to all git commands you run, especially ones looking at diffs, so you avoid getting blocked ## Instructions 1. **Check for uncommitted changes**: Abort if there are any. 2. **Check rebase status**: Verify the branch is rebased on top of `main`. Abort if not. 3. **Save recovery point**: Tell the user the current commit hash in case we need to `git reset --hard` to it later. 4. **Save the original diff**: Save the full git diff to `/tmp/original-diff.patch` before making changes. 5. **Reset to main**: Run `git reset main` to unstage all changes. 6. **Plan the commits**: Read through ALL changes carefully. Plan a logical breakdown into small, sequential, semantic commits. Write a TODO for each in `/tmp/split-todos.md`. Order: database/schema changes first, backend second, frontend last. 7. **Create the commits**: Work through the TODOs one by one. Write excellent commit descriptions for human reviewers. 8. **Validate**: Compare the current diff against `/tmp/original-diff.patch` to ensure no changes were lost or altered. 9. **Cleanup**: Delete temporary files once validation passes. ## Notes - If validation fails, tell the user and provide the original commit hash for recovery - Each commit should be self-contained and represent a logical unit of work - Commit messages should explain the "why" behind the changes
Try in Cherri CodeAgent Review
エージェントがタスクを完了したら、Review をクリックし、Find Issues をクリックして専用のコードレビューを実行します。エージェントが提案された編集内容を1行ずつ分析し、問題となる可能性のある箇所を検出します。
すべてのローカル変更を対象にするには、Source Control タブを開き、Agent Review を実行して main ブランチと比較します。変更全体にわたる問題を検出できます。
これは、変更内容を確認するようエージェントに手動でプロンプトを送るのと似ています。効果的に活用できるよう、プロンプトを慎重に設計しています。
プルリクエスト向け Bugbot
Bugbot はソース管理プロバイダーと連携し、プルリクエストを自動で確認します。PR 上で直接フィードバックを提供するツールの一つです。
Bugbot はプッシュ時に PR を確認します。変更したコードがコードベースの他の部分とどう連携しているかを含め、変更のコンテキスト全体を読み取り、本番環境に到達するバグを探します。形式上の問題を検出するリンターとは異なり、Bugbot は null ポインター例外、競合状態、エラー処理の不足、セキュリティ上の問題といったロジックエラーを見つけます。
Bugbot が問題を見つけた場合、修正案も提示できます。autofix を有効にすると、プルリクエストのコメントから直接修正をコミットできます。
追加ルール を指定して Bugbot をカスタマイズすることもできます。これについては、次のエージェントのカスタマイズに関するセクションで詳しく説明します。
検証可能な目標
コードの正しさを確保するには、エージェントが自らの作業を検証できるよう、明確な手がかりを与える必要があります。
- テストは挙動のリグレッションを検出します
- 型チェックは構造上のエラーを検出します
- リンティングはスタイルやパターンの違反を検出します
こうしたチェックを多く導入するほど、より安心してエージェントに作業を委任できます。エージェントと併せて、テストカバレッジとリンティングルールを備えた型付き言語を使用することをおすすめします。
AI が生成したコードに対して最も強力なセーフティネットとなる組み合わせはどれですか？
エージェントにテストを書かせる
以前は、十分なテストカバレッジを確保するには多大な労力が必要でした。ほとんどのチームでは、何かが壊れてからテストを追加するか、一定のカバレッジ率を確保するために厳格なプロセスを設けていました。
エージェントを使えば、テストの作成がはるかに手軽になります。エージェントにテストを書かせてから、正しいことを確認できます。エージェントはブラウザを通じて手動テストも行えるため、通常は手作業で確認するUIの状態やフローをチェックできます。
高品質なテストがあれば、リグレッションを起こさずにエージェントに自律的に作業させたり変更を加えさせたりする際も、より安心できます。
テスト生成に適したプロンプト:
- 「チェックアウトフローの e2e カバレッジを得る方法を計画してください。どのシナリオをテストすべきですか？」
- 「payments API の統合テストを設定してください。
src/__tests__/にある既存のテストインフラストラクチャを使用してください。」 - 「割引機能に関する現在のテストでカバーされていないエッジケースは何ですか？」
- 「
PaymentService.tsで修正したバグのリグレッションテストを書いてください。」
エージェントは、テストインフラストラクチャをゼロから設定することも支援できます。Web アプリケーションで Playwright が設定されていない場合は、プロジェクトのセットアップ、設定ファイルの作成、最初のテストの作成をエージェントに依頼できます。
Cloud Agents
これまで、エディター上でローカル実行されるエージェントを使用してきました。Cloud Agents はリモートのサンドボックスで実行されるため、ノートパソコンを閉じて、後で結果を確認できます。
仕組みは次のとおりです。
- タスクを説明し、関連するコンテキストを提供する
- エージェントがリポジトリをクローンし、ブランチを作成する
- エージェントが自律的に作業し、完了するとプルリクエストを作成する
- 完了すると、Slack、メール、またはWeb インターフェースで通知を受け取る
- 変更を確認し、準備ができたらマージする
Cloud Agents は、別の作業中に見つかったバグの修正、既存コードのテストカバレッジ、ドキュメントの更新、リファクタリングなど、通常はToDoリストに追加するようなタスクに適しています。
Cloud Agent を使った大規模テスト
効果的なパターンの 1 つは、Cloud Agent を使って多数のバリエーションを並行してテストすることです。複数の Cloud Agent を起動し、アプリケーション全体でさまざまなエッジケース、エラー条件、入力の組み合わせを試せます。
たとえば、新しい割引コード機能を追加したとします。Cloud Agent を起動して、すべての割引タイプをテストし、無効な入力を試し、割引の重ね掛けなどの組み合わせをテストし、エッジケースの境界値での挙動を確認できます。
各 Cloud Agent は、テストケースと結果を含むブランチを作成します。その後、失敗したケースを再現可能なローカルテストケースとして集約し、マージ前に修正できます。
フィードバックループを高速化する
より多くのコーディングエージェントを使い始めると、ボトルネックはシステム内で最も遅い部分に移ります。多くの場合、テストスイートの完了待ち、コードベース全体に対する型チェックやリンティングの実行、またはCIパイプライン内のその他のステップが該当します。
エージェントとの会話のたびに、こうしたコストが発生します。テストの実行に10分かかり、10個のエージェントを並行して起動すると、合計でほぼ2時間待つことになります。テストを50%高速化すれば、毎回ほぼ1時間を節約できます。
こうした改善は、すべてのセッション、すべてのブランチ、すべてのエージェントで繰り返し効果を発揮します。効果の大きい変更の例を以下に示します。
- テストスイートの高速化
- 依存関係ツリーの整理
- CIパイプラインの最適化
- 型チェックの高速化
- ビルド時間の短縮
これらはチームが後回しにしがちなタスクですが、エージェントがこうしたコマンドを1日に何十回も実行する場合、その効果は積み重なります。テストの高速化に1時間を投資すれば、長期的には数百時間を節約できます。
最も良い点は、エージェントにこの作業を任せられることです。エージェントにテストをプロファイリングさせ、修正すべき最も遅いテストを見つけるよう依頼できます。依存関係を監査し、未使用のものを削除するよう依頼することもできます。これらは範囲が明確で、結果を検証しやすいタスクであり、まさにエージェントが最も得意とする作業です。
よくある失敗パターン
テストに通っていても、コードが正しく動作するとは限りません。テストが誤った挙動を確認している可能性もあります。エージェントが正常系では動作するコードを書いていても、すべてのエッジケースを考慮していない場合があります。
コードの変更内容を理解することが重要です。変更が大きすぎて無理なく確認できない場合は、自分にとってもエージェントにとっても確認しやすい、より小さな単位に分割することを検討してください。
次のステップ
これで、新機能のリリース、問題発生時のデバッグ、コード品質を確保するための確認方法を理解できました。最後に、特定のコードベースに合わせてエージェントをカスタマイズし、ワークフローを効率化しましょう。