何が起きたか
著者はPR #17（CIマトリクスに3行追加・1行削除）とPR #13（Dockerfileのベースイメージ変更とspec追加、2ファイルで39行追加・1行削除）をAnthropicのコードレビュースキルとCodeRabbitでレビューした。結論は正しいが理由が誤っている例や、接頭辞しか検証しないテストなど、5つの再発パターンが浮かび上がった。
なぜ重要か
git ls-filesで追跡ファイルを確認する、結論と理由を分けて検証する、変更前の状態を確認する、テスト名と実装を照合する、差分の外を見る——著者のチェックリストは、AIレビューを最終回答ではなく検証すべきシグナルとして扱うべきだと示している。
こういう要約が、毎朝あなたのメールに届きます。
著者の出発点は単純な観察だった。AIレビューボットはチームが対応しきれないほどコメントを出すため、本当の問いはどのコメントを信頼するかになる。ここで使われた2本のプルリクエストは意図的に小さく抑えられている。PR #17はCIマトリクスの数行を変えただけ、PR #13はDockerfileのベースイメージを差し替えて2ファイルにspecを追加しただけだ。その規模でも5つの異なるパターンが現れたため、著者は問題がリポジトリの複雑さではないと論じる。
パターンには共通の形がある。CIマトリクスの例では、Ruby 3.5のエントリを削除すると、失敗するチェックが、決して報告されない必須チェックに置き換わっていただろう。ジョブ名がマトリクスのエントリに紐づいており、リポジトリのルールセットがRuby 3.4、Ruby 3.5、CodeQLを要求しているからだ。著者は、差分を読んでもこれは分からず、確認にはルールセット自体へのアクセスが必要だと指摘する。RuboCopの例では、rake defaultが失敗するというレビューの結論は正しかったが、示された原因は誤っていた。著者は実行を再現し、RuboCop 1.92.2で152件のoffenseを見つけた。これらの例は、著者の最終チェックリストがコメントの説得力ではなく証拠の所在から始まる理由を示している。
著者はまた、この手法を自分自身に適用したことにも触れている。AIレビューは、元の原稿が5つのパターンをすべて単一の依存関係更新プルリクエストに帰していたが、実際は2つの別々のPRから来ていたこと、引用された差分がgit showの出力と一致していないことを指摘した。著者はこれらの点を修正し、最初の5件のレビューコメントのうち3件が、著者自身が警告していたパターンを指摘していたと述べている。
業界と使っているAIツールを選ぶと、仕事に関係するニュースが毎朝届きます。
登録無料・Googleアカウントなら30秒・いつでも解除できますAITodayについて →
この記事についてわからないことをAIに質問できます。AIはこの記事・AIToday の過去記事・Wikipedia を読み、出典を付けて答えます。Q&Aはこのページに公開され、他の読者も読めます。
このようなAIの動きを、御社の業界・競合に合わせて毎日届ける法人プランもあります → 詳しく見る
CPC AI Inc.の尹氏は3〜5日でMVPを出す工程を示した
InflabのYakpoong氏が約7カ月のCodeRabbit利用を振り返り、誤字や引数の誤り、console.log/System.out.println、BIGINTルールに反するINTEGER外部キーをAIレビュ…
同じCanonical Zephyrの記事で、Haiku/Sonnet/Opusの4分業は約207秒で198,658トークン、Opus 1体は約168秒で74,381トークンだった
AI LaboがVM215上でgemini-3.8-flashに同一タスクを解かせたところ、Mode Aは5大アーキテクチャ規約のうち4件のみ遵守し、Hook方式のMode Bは5件全てを遵守した
筆者は非公開のGitHubリポジトリをZennに連携し、エージェントに環境構築とCLAUDE.mdのルールファイルの下書きを作らせ、筆者自身の記事をエージェント作成PRの第1号として公開した
DokuProのQiita記事が、PythonのrequestsとBeautifulSoup4でスクレイピングのパイプラインを組み、instruction/outputペアをファインチューニング用のJSONLファイルに書…
