- AIエージェントの活用に習熟するには、コードレビューの実力が重要
- 大規模言語モデルはコード生成は得意だが、深い判断力が不足しており、誤った方向に時間を浪費しがち
- 細かな文法だけを指摘する些末なレビューや、無批判に承認するハンコ押しレビューは、AI活用の助けにならない
- 良いコードレビューは構造的な視点を含み、より良い方法があるかを見極め、複雑な設計を避けさせる
- 結局のところAIコーディングは、**「ケンタウルス・チェス」**のように人間の判断と機械の生産性を組み合わせるモデルであり、コードレビュー能力がそのままAI活用力につながる
AIエージェントとコードレビューの関係
- AIエージェントを正しく使うことは、すなわちコードレビューのプロセスである
- コードレビューが上手い人は、Claude Code、Codex、CopilotのようなAIコードツールも効果的に活用できる
なぜコードレビュー力が重要なのか
- 大規模言語モデルは大量のコード生成には長けているが、熟練したソフトウェアエンジニアの判断力はまだ不足している
- そのため、監督なしで任せると、不必要または質の悪い設計に多くのリソースを浪費する傾向がある
AIエージェントの限界と設計ミス
- 例として、VicFlora Offlineプロジェクトの開発中、Codexはフロントエンドコードのリバースエンジニアリングに多くの労力を費やした
- 実際には、もっと単純なデータアクセス手法が存在していた
- AIエージェントを使っていると、だいたい1時間に1回くらいは何か怪しい作業をしていることが見つかる
- こうした問題を見つけた時点で自分で方向転換すれば、数時間分の作業を節約できる
- 別のアプリ開発の経験では、AIは単純な並列処理の作業に対しても、過剰なバックグラウンドインフラの構築を提案した
- 単にフロントエンドでノンブロッキングに処理すれば十分なのに、複雑なアーキテクチャを導入しようとする
- 単純さを保つために、継続的にAIを制御することが重要だ
- 非専門家がAIだけを信じて開発すると、コードベースの複雑さと非効率が蓄積し、かえって問題解決能力が急激に落ちる現象が起こる
コードレビューの本質と効果
- AIとの協業は、熱意はあるが経験の浅いジュニア開発者と協業するのに似ている
- AIは時間がたっても判断力が成長しないため、継続的な観察が必要になる
- コードレビューにおける最大のミスは、書かれたコードだけを見て、もっと良い代替案があるかを考えないこと
- 最適なコードレビューは構造的な観点から、システム全体の文脈を統合的に考慮する
- 不要なシステムを新しく作るよりも、既存システムを再利用する方法を優先すべきだ
- 細かなコードスタイルにばかり執着する「nitpicky」なレビュアーは、AIツールの真の活用を逃しかねない
- 「rubber-stamp」レビュアーのように批判なく通してしまうと、AIやジュニア開発者との効果的な協業は難しくなる
AIツール活用スキルについての考え
git などの従来ツールには明確な構造と操作法があるが、AIの基本構造は不透明だ
- 一部では、AIツールを全方位的に活用することがAI活用能力だと見なされている
- 実際には、熟練した利用者ほどより多くの可能性を引き出せる
- 現時点では、AIコードエージェントは多様な作業を手伝えるが、密接な監督が求められる
- **"ケンタウルス・チェス"**モデルのように、熟練した人間の方向づけとAIの提案が組み合わされれば、最適な生産性を達成できる
- AI活用の実力は、結局のところコードレビュー力と批判的な設計判断力にかかっている
- コードレビューのスキルが高いほど、agentic AIツール活用の効果は最大化される
最後の考えと展望
- AIエージェントは、時間の経過とともにますます熟練したエンジニアのように成長しているような感覚を与えることがある
- 今後数年以内には、AIとの協業体験が中堅エンジニアと協業する水準まで進化する可能性がある
- 現在は、さまざまなAIツール（Codex、Claude Code、Copilotなど）を活用して実験するのが望ましく、批判的に監督する能力が最も重要な差別化要因である
追加の意見
- Hacker Newsなどでは、「AIエージェントはどの水準まで役に立つのか」について議論があった
- 筆者は、コードレビューだけでAIがLinuxカーネル級の開発に貢献できるとは見ていない
- 一部には、スタイルや命名のようなコードレビュー手法が重要だという意見もある
- デザインの議論をコードレビューで行うことに批判的な見方もあるが、筆者はそれを否定的には見ていない
1件のコメント
Hacker Newsの意見
たとえ悪いプロセスでも品質管理さえしっかりしていれば良い結果が出る、という考えにはかなり懐疑的だ。要するに「ガラクタを吐き出し続けても、誰かが確認しさえすれば大丈夫」という話だが、現実でうまく機能しているのを見たことがない。アメリカの自動車産業でもこうした試みはあったが、成功例は思い浮かばない。想像してみると、チームリーダーである自分に上司が「有能な5人の代わりに完全な初心者25人を連れて、運よく何かうまく噛み合う成果物が出るのを待つ。君は全部レビューしろ」と言うようなもので、こんなのは話にならない。なのにAIがこのシナリオに入ると、多くの人が「ん？ もしかしたらいけるかも？」と考えてしまうのが不思議だ
経験が浅い、あるいはやる気の乏しい人のコードをレビューするのも非常に疲れる。精神的にも感情的にもものすごいエネルギーを消耗する。同じ機能を4回もレビューしていると嫌気が差して、品質がこれ以上上がりようのない段階で諦めてしまうことがある
これはデミング（Edward Deming）が日本で発展させ、西側諸国に広めた品質管理の模範とは正反対だ。品質は人から生まれるのではなく、プロセスから生まれる。欠陥の多い工程を選んでおいて、人間がミスを見つけてくれると期待するのは、品質が目標ならまったく良い方法ではない。LLMにはさまざまな使い道があるが、そのうち一部だけに利点がある。経営陣はAIですべての問題を解決できるという幻想に陥っており、AIの長所と限界をきちんと理解していないか、あるいはデミングの教訓を忘れてしまったように見える
進化はランダムな変異と選択によって起きるし、あらゆる複雑な生命の存在そのものがその例だ。自分の好む方法ではないが、流行のバズワードに熱狂して、合わない場所にも手当たり次第に試す傾向がある。調理器具の一部プラスチック部品の製造では、品質の悪い状態で成形した後、日雇い労働者が手作業でナイフを使って修正し、包装する方式が今も残っている。自分もこうした臨時の仕事をしたことがある。半導体のチップビニングや歩留まり管理も、失敗率が非常に高い例と見なせる。現実を見渡すだけでも、疑わしい工程は特別どころか、むしろ日常だ
「AIをうまく使える」と自己評価し始めると、「自分が解ける問題の範囲がものすごく広がった」という錯覚に陥りやすい。この現象はあらゆる汎用技術で見られる。昔、遺伝的アルゴリズムが流行したときも似たようなものだった。みんな「汎用」ツールを見つけると、そのツールで何でもできると勘違いする。実際には文脈が何もない状況で最適化を試みているだけだ。AIはこの現象がさらに極端に現れた例だ
どれだけプロセスが整っていても、ちゃんと動くシステムを作る方法そのものを学べるわけではない。繰り返し目にするパターンは、チームが長いこと迷走した末に、結局は問題解決の仕方を知っているエンジニアが自ら乗り出して、きちんと方向付けるというものだ
AIに要求パラメータを守らせるのは本当に難しい。いつもランダムにおかしな方向へ逸れていく。nftables のハイライト作業ではトークン230個、状態2,500個、状態遷移5万個超がある。AIに次の5つの明確なルールを与えても、すべてランダムな箇所で外してしまう。コーディング結果だけでなく、とても簡単な Vimscript すらまともに作れない。結局のところAIはドキュメント化用途にしか使っていない。それでも
rule、chain_block stmt、map_stmt_exprのように分解して説明するのはAIがかなりうまくなってきた。自分が欲しい構文パターンだけコピペして使えばよいAIコード生成はプロジェクト初期段階ではかなり有用だが、成熟したプロジェクトには懸念がある。最近、28万+ LOC の Postgres パーサーを Multigres にマージしたが、公開レビューなしで進められた。オープンソースのエコシステムでは、こういうことには警戒すべきだ。多くの人が学習や参照のためにこうしたプロジェクトに依存しているのに、十分なレビューなしでAIコードが入ると、教育的価値や依存先への信頼が損なわれる。コードレビューはバグを見つけるだけでなく、共同作業者が学び、設計理由を理解し、集合知を積み上げるための中核でもある。問題は速度ではなく、知識伝達のプロセスだ。なお、PR公開までにかかった時間についてはこちらを参照
自分のプロセスは大まかにこうだ
実行結果の途中途中でスナップショットを取って、そこへ戻ることもある
こうすると、素晴らしいレベルとは言えなくても、少なくとも自分の実装の基準点になる成果物は得られる
欠点はものすごく時間がかかることで、80%の場合は最初から全部自分1人でやったほうが速かっただろうと思う
1人でやるより遅く見える。AIコーディングをすると、まるで「一杯やりながら、君が書いたメモを見て適当に作ってみたよ。どう？」という感じの、中堅レベルの開発者が週末の夜通しで即興的に作った成果物を見ている気分になる。「NO、気に入らない」とひと言返して、それでもだいたい方向性が合っているなら、それをリファクタリングしながら月曜朝から始めるよりは少し速い、という感覚だ
こういう段階的ガイドを毎回見ると、結局は膨大な手間を追加しているだけで、そもそもAIに期待していた効率性が全部消えてしまう。実際、自分の経験ではほぼその通りだ。もちろんAIが役立つ瞬間もあるが、いつ・どこで役に立つかを見極めること自体が1つの重要なスキルだと思う
自分はもう少し低レイヤーで作業していて、だいたいいつもこんな感じだ:
たいてい、広すぎて長い目標を一度に渡すと、エージェントは作業完了のタイミングを誤って判断しがちだった
似ているが、もう少し単純化したプロセスを使っている。PRDまで渡し、自分が大まかなアーキテクチャも伝え、各コンポーネントの実装を望む形でやらせる。やはり時間はかなりかかるし、自分でやるほうが速いだろうが、もう手で延々とコーディングするのが面倒なので、LLMに関数単位でやらせてみようかと考えている
AIを大まかなアプローチ、ライブラリ、言語の特徴などを教えてもらうためだけに使っていたなら、本来の仕事は自分でやったほうがずっと速かったはずだ
コードレビューがうまいなら、AIエージェントはむしろ使わないほうがいいかもしれない
自分で Claude Code のようなエージェントに夢中になっている同僚たちのコードをレビューし、バグを修正しながら感じたのは、そのコードがまるで幻覚状態で書かれたかのように妙で、書いた本人がそのコードについてまったく説明できないことが多いということだった。それでも本当に良いコードを作る人もいるのだろうとは思うが、自分が実際に見たものはどれも失望させられるものだった。幸い、何人かは自分で気づいて、またちゃんとしたやり方に戻っていった。最近のエージェントベースのワークフローから出てくる成果物を批判的に見れば、答えは明らかだと思う。コードレビューがうまい人なら、この結論にもっと早くたどり着くだろう
自分がコードレビューをうまくできるなら、もっと腕を磨き続けたい
コードレビューも仕事の一部ではあるが、いちばん楽しい部分ではない。開発者は自分でコーディングする瞬間に満足感を得るのだから、AIツールは役に立つ面もあるが、予測不能なのにもっともらしく見えるので、かえってより入念なレビューが必要になり、負担が増す。なぜ私たちは楽しい部分を奪い、楽しくない要素だけ増やすような道具を作ったのだろう。「コードレビュー」専用エージェントはどこにいるのか気になる
実のところ、自分はコードの「記述」そのものはあまり楽しくない。問題を解き、新しいものを作り、システムを分解してよりよい構造に再構成するほうがずっと面白い。LLMを使ってコーディングすると、アイデアを実際に触れる成果物へ移すスピードが大幅に上がったように感じる。既存コードも型安全性が高まり、文書化が進み、複雑なリファクタリングが容易になる。LLMに問題解決そのものは期待せず、文脈集め、パターンの再適用、反復コードの自動化などを期待している。特に複数ファイルに分散したコードをいちいち自分で書かずにAIが自動生成してくれると、各変更点だけ確認すればいいので非常に楽だ
OpenAI Codex Cloud はコードレビュー機能を追加し、新しい GPT-5-Codex モデルはコードレビューに特化して訓練されている [Codexアップグレード紹介]。Gemini と Claude にも GitHub Actions 連携コードレビュー機能 や Claude GitHub連携 などが登場している。GitHub も独自に Copilot Code Review 機能をリリースした。CodeRabbit、Greptile、Qodo Merge のような専業スタートアップも多い
自分が本当にぞくぞくする瞬間は、実装の最中にその下に隠れた非常にエレガントな構造を発見し、それによってそれまでのプログラミングの仕方、ひいては生き方そのものまで変わってしまうようなときだ（こんなことは本当にめったに起こらないが）
ジュニア開発者ほどコードを直接書くのが好きで、シニアはむしろコードを減らすのを愛する。個人的にはコードレビューが自分の仕事の中でいちばん楽しい部分だ（自分の締切に追われていないときは）。コードレビューがつまらないという主張には同意しない
導入部では「大多数の開発者は新しく作ることを好む」と述べられていたが、実際には他人が作ったコードベースの上でパターンや構造を把握し、改善するのを好む人も多い。完全に新しいものを作る過程（初期設計→無限ループ）のほうがしんどい人もいることを考慮すべきだ。「楽しさを奪い、つまらなさだけ増やした」という問いに対しては、おそらく生産性向上が最も大きく感じられる部分に集中したからだろう。レビューAIなら CodeRabbit、GitLab Duo など、すでにさまざまな選択肢がある。RooCode のように Git diff を入力してコードレビューを任せるのも無理はない
この記事のタイトルは単純化しすぎているように感じる。コードレビューと設計レビューは別物だし、AIで試みるのはこの2つだけでもない。AIを活用するにはその領域の専門知識が必要で、コーディングに限ってもレビュー能力だけでは不十分であり、AIに任せた仕事がどの分野であれ、それを検証できる能力が必要だ。むしろAIが役立つのは、自分があまり知らない言語やフレームワークに触れるときだが、その場合はコードレビューも深くできなくなる。「コーディング」という言葉がAI/LLM時代に再び流行しているのも興味深い。最近の企業は単なるコーダーよりも、アーキテクチャ、要件分析、フルスタック開発、運用まで全部できるエンジニアを好むように見える
自分の正式な肩書きは「Software Engineer」だが、ここ5年間で
同僚たちとコードレビューをしながら、共通知識や基準が向上していくという考えがとても好きだ。だが、頑固で非協力的なAIのコードをレビューすることを思うだけで燃え尽きそうになる
仕事の中で最も退屈な部分が上手くなると、その仕事だけを一生やることになるのではないか、という気がしてしまう。正直嫌だ。そして記事で言っていたように、バグはそもそも入らないに越したことはない。入ってから見つかるのは常にリスクを伴う