ソフトウェアエンジニアのNolan Lawson氏が、Claude・Codex・Cursor Bugbotを組み合わせた独自のPRレビュースキルを公開し、「AIコーディング＝大量高速生成」という通説に正面から異を唱えた。

「AIで速く書く」という誤解

AIコーディングツールの普及とともに広まっているのが、エージェントに指示を出して数百行のPRを一気に生成し、ほぼレビューなしでマージする手法——いわゆる「スロップキャノン（slop cannon）」スタイルだ。「10倍の生産性」を謳う言説のほとんどは、このアプローチを前提にしている。

しかしLawson氏の主張は真逆だ。LLMは大量のコードを「速く」生成するためではなく、「丁寧に」活用することで本来の力を発揮する、というものだ。そしてその裏付けとなる具体的なワークフローを公開した。

複数モデルでバグを炙り出す

Lawson氏が構築したのは、Claudeサブエージェント・Codex・Cursor Bugbotの3モデルを並列実行するPRレビュースキルだ。

各モデルが独立してPRのバグを洗い出し、重大度（Critical／High／Medium／Low）でランク付けする。その後、各モデルの知見を統合・精査して最終レポートを出力する。複数の異なるモデルを組み合わせることで、単一モデルが犯しやすいハルシネーション（誤検知）を劇的に減らせるのが最大の利点だ。

検出対象はバグだけではない。KISS・DRY原則への違反、アクセシブルでないHTML／JSX、SQLクエリのインデックス不足なども対象として定義できる。実際の運用では「偽陽性はほぼゼロ、見つかるバグの量は処理しきれないほど」とLawson氏は述べている。

実際のワークフロー

Lawson氏の具体的な進め方はこうだ。

  • CriticalとHighを全件修正 — エージェントに適切な解決策を指示しながら修正を繰り返し、CriticalとHighがゼロになるまで続ける
  • 費用対効果の低い修正はスキップ — 狭いエッジケースのために100行書き換えるような改修は見送る
  • 設計が根本的に間違っているPRは廃棄 — Criticalが山積みなら、アプローチ自体を見直す

注目すべきは、このプロセスで開発速度が上がるわけではない点だ。それどころか、レビュー中に既存コードのバグが次々と発見され、本来のPRとは無関係な修正やテスト追加に追われることも多い。「10倍の生産性」とは程遠いが、Lawson氏はそれを「コードベースの健全性を高める副次効果」として肯定的に捉えている。

日本のIT現場への影響

このアプローチが日本のエンジニアにとって特に意味を持つのは、コードレビューの文化的文脈においてだ。

日本の開発現場ではレビューは重要視されているが、レビュアーの負荷は慢性的に高い。AIを使った多段階バグ検出を導入することで、人間のレビュアーが本当に価値を発揮できる設計判断・アーキテクチャ議論に集中できる環境が生まれる可能性がある。

また、新機能追加のPRをきっかけに既存コードのバグを体系的に洗い出せるため、通常の開発サイクルの中で技術的負債を減らすループを作りやすい。「ビジネス要件を満たすギリギリのコードを速く出す」文化から「品質を着実に積み上げる」文化への転換を検討しているチームには、試す価値のある手法だ。

筆者の見解

「AIを使えば10倍速くなる」という言説が独り歩きしている現状には、率直に言って違和感がある。速度向上を主目的にした使い方は、短期的には生産性が上がって見えるが、技術的負債を急増させるリスクと表裏一体だ。

Lawson氏のアプローチは逆説的だが本質を突いている。LLMの強みは「量の生成」ではなく「視点の多様性」にある。複数モデルが独立してコードを検証するアーキテクチャは、エージェントが自律的に判断・実行・検証を繰り返す「ハーネスループ」の考え方にも通じる。単発の指示で生成して終わりではなく、ループで品質を高め続ける設計——これが次のフロンティアだと考えている。

開発速度よりも「コードを本当に理解した上で書いているか」を問うこの視点は、AIが普及するほど重要になる。ツールの使い方次第で、AIはコードの品質を下げる「スロップキャノン」にも、品質を高める「精密な検査機」にもなる。どちらを選ぶかは、エンジニア自身の設計次第だ。

出典: この記事は Using AI to write better code more slowly の内容をもとに、筆者の見解を加えて独自に執筆したものです。