AI時代の開発パラダイム：コードレビューを捨て、CIで品質を担保する極意

1日500コミット。この数字を耳にして、皆さんは何を想像するだろうか。かつて我々エンジニアにとって、コミットログは「開発者の足跡」であり、レビューは「品質の最後の砦」であった。しかし、AIエージェントを並列稼働させ、爆速でコードが生成される現代において、人間がすべての差分を追うことは物理的に不可能だ。私は、この「人間の読む速度」と「AIの生成速度」の乖離を、単なる効率化の問題ではなく、開発プロセスの根本的な再設計が必要なサインだと捉えている。

多くのエンジニアが「レビューなしでリリースするなんて無責任だ」と反射的に拒絶反応を示すのは理解できる。しかし、それは「レビューでしかバグを検知できない」という脆弱な開発環境に依存しているからではないだろうか。私が実践しているのは、レビューという「事後的な検問」を廃止し、代わりに「壊れたら即座にCIが赤くなる」という強固なガードレールを構築することだ。これは精神論ではない。規約をコード化し、静的解析を極限まで厳格化し、テストの網羅性を機械的に強制する。この「先に減らす」アプローチこそが、レビューを不要にするための唯一の解であると私は確信している。

具体的には、規約を人間の記憶に頼るのではなく、グローバルおよびリポジトリ固有の『CLAUDE.md』に集約させている。特筆すべきは、リポジトリごとの規約が肥大化した場合、それは「規約が足りない」のではなく「開発スタックの統一が足りない」というサインであると見なす点だ。yarn、TypeScript、Vitest、ESLintといったスタックを徹底的に揃えることで、プロジェクト間のコンテキストスイッチを最小化し、AIが迷わずコードを書ける環境を整える。人間が読むためのコーディング規約は「〜すること」という曖昧な指示になりがちだが、AI向けには「いつ読むか」「何をすべきか」を明確に定義する必要がある。この「人間向け規約の廃棄」こそが、厳格な自動化を可能にするための第一歩なのだ。

コードレビューを手放すための最大の武器は、ESLintによる機械的な拒絶だ。私が設定しているルールは、人間のチームであれば間違いなく「厳しすぎる」と反発を招くものばかりである。関数は60行まで、ネストは4段まで、any型の禁止、非nullアサーションの禁止。これらをすべてエラーとして扱う。さらに、sonarjsを用いて循環的複雑度よりも「人間の読みにくさ」に近い指標を監視し、アサーションのないテストをCIで弾く。これらは、かつて人間が目視で指摘していた「コードの臭い」を、すべてCIのゲートに置き換えた結果である。

ここで重要なのは、例外の扱い方だ。安易なeslint-disableを許せば、規約は形骸化する。私は例外をインラインで消すことを禁じ、設定ファイルに「理由」と「期限」を明記することを義務付けている。これにより、半年後にその例外が本当に必要か、あるいは解消可能かを判断できる。妥協にも期限を設けるというこの姿勢は、技術的な負債を放置しないための強力な規約となる。

また、型システムを「もう一つの規約」として活用することも不可欠だ。typescript-eslintのstrict設定をベースに、any型や非nullアサーションを徹底的に排除する。特に、型情報を用いたlintルール（no-floating-promisesやawait-thenableなど）を導入し、バックログをゼロにしてからエラーに昇格させる「drainしてからratchetする」という運用方針をとっている。この「誰も読まない警告リストに1件足すことを許さない」という厳格な運用こそが、コードの品質を維持する鍵だ。人間なら「今それは本質じゃない」と妥協する場面でも、AIは文句を言わずに従う。この「社会的コストのゼロ化」こそが、AI時代の開発における最大の恩恵であると私は考えている。

テストについても、考え方を根本から変える必要がある。テストを増やすことよりも、「テストできる形に設計すること」が本質だ。ファイル読み書きやネットワーク通信といった副作用を伴う処理を末端に追いやり、ロジックをpure関数として切り出す。これは「テストしにくい」という言い訳を許さない設計の強制である。エージェントには、正常系だけでなく、エッジケース、コーナーケース、境界値、空入力、不正入力といったパターンを網羅的に書かせる。このコストは、AIが書く以上、人間が書くよりも遥かに低い。

テスタブルであることは、新しいコードだけのルールではない。既存のコードベースに対しても、リファクタリングの過程でpureなロジックを抽出し、テストを付与し続ける。これは「コードベースの性質」として取り戻すべきものだ。Claude Codeの組み込みコマンドなどを活用し、機械的にコードの純度を高めていく。人間がやれば数日かかるリファクタリングも、AIなら数分で完了する。このサイクルを回し続けることで、コードは常に「壊れにくい状態」を維持する。

さて、ここで我々エンジニアに突きつけられる問いがある。レビューという「人間による確認」を捨てたとき、我々は何を担保すべきなのか。それは「コードの正しさ」ではなく、「コードが正しく動くことを保証する環境の正しさ」ではないだろうか。もし、あなたのプロジェクトでレビューが形骸化しているなら、それはレビューのやり方が悪いのではなく、レビューに頼らざるを得ない環境そのものが時代遅れなのかもしれない。明日から、あなたは「レビューを効率化する」のか、それとも「レビューを不要にする環境を構築する」のか。どちらの道を選ぶにせよ、AIがコードを書く時代において、エンジニアの価値は「コードを書くこと」から「コードが正しく生成・検証されるシステムを設計すること」へと確実にシフトしている。この変化を恐れるか、それとも自らの武器として使いこなすか。その選択が、あなたのエンジニアとしての寿命を決定づけることになるだろう。