AIにコードを書かせる。
いまでは、それほど特別な開発スタイルではなくなりました。
AIコーディングエージェントに仕様を渡し、実装を生成させる。関連ファイルを調べ、コードを変更し、テストを実行し、必要なら修正まで任せる。
人間はコードを一行ずつ書く代わりに、要件を決め、タスクを分解し、生成されたコードをレビューする側へ回ります。
コードを書く時間が減るなら、そのぶん設計やプロダクトを考える時間を増やせる。AIの生成能力が上がれば、これまで人手では難しかった規模の変更も短時間で処理できます。
かなり合理的です。
ただ、生成速度だけを上げたときに残る問題があります。
AIがコードを書く速度は上がっても、人間の理解や判断まで同じ速度で高速化するとは限りません。
この差が広がるほど、コードレビューの意味も変わってきます。
AIはコードを書ける。でも、人間はそのコードを理解しなければならない
AIコーディングの大きな強みは生成速度です。
従来なら、開発者は仕様を確認し、設計し、関連するファイルを探し、コードを書き、テストして、エラーを読み、修正するという工程を進めていました。
AIエージェントなら、その一部をまとめて委譲できます。
人間
↓
仕様・要件・計画を決める
↓
AI
↓
調査・実装・テスト・修正
↓
人間
↓
レビュー・判断
Lars Faye氏が2026年4月に公開した「Agentic Coding is a Trap」で扱っているのも、このような開発スタイルです。
人間が要件や計画を作り、AIエージェントが実装し、人間がその成果物をレビューしながら方向づける。
Faye氏は、この方法には生成速度以外のコストもあると指摘しています。AIの非決定性を扱うための周辺システムの複雑化、スキルの衰退、ベンダーロックイン、トークンコストの変動などです。
その中でも、この記事で掘り下げたいのがAIを監督するためにも、高度な開発能力が必要になるという問題です。
コード生成量が増えても、レビュー能力は自動では増えない
AIが大量のコードを短時間で生成できるようになると、当然ながらレビュー対象も増えます。
AIが大量にコードを書く
↓
Pull Requestを作る
↓
人間が理解する
↓
人間がレビューする
AIが数分で数多くの変更を作れても、人間が同じ数分でその変更を理解できるとは限りません。
Communications of the ACMでAmy Buttell氏が2026年9月4日に公開した「Leverage Code Review for Sustainable AI Coding Development」も、この問題を扱っています。
記事では、AIが生み出すコード量が開発者のレビュー能力を上回りつつある状況を踏まえ、ピアレビューの役割がむしろ大きくなっていると論じられています。
AI以前のコードレビューにも、欠陥の発見、品質向上、チーム内の知識共有、コーディング規約の維持といった役割がありました。
AIによる実装が増えると、そこへもう一つの役割が強く加わります。AIが生成したソフトウェアを、本番へ入れてよいのか検証するリスク管理の工程です。
Atomic Gravityの創業者Tolga Tarhan氏は、レビューの位置づけが変わっていると説明しています。以前のように開発の最後でシニアエンジニアが確認する「ゲート」ではなく、開発プロセス全体を通して継続的に行うものになっている、という考え方です。
Threadaの創業者Nick Balnaves氏が紹介するレビュー体制も、一つのレビューですべてを見る形ではありません。
- 変更されたファイルに応じた自動チェック
- バグ、セキュリティ上の後退、誤った前提を探す独立した批判的レビュー
- 実際のワークフローを通したエンドツーエンドの検証
実装だけをAIで高速化するのではなく、検証側も複数の層へ分ける発想です。
レビューもAIに任せれば、人間の問題は解決するのか
コードの生成量が増えるなら、レビューにもAIを使うのは自然です。
AIが実装
↓
自動テスト
↓
静的解析
↓
AIレビュー
↓
人間によるレビュー
↓
Merge
単純なバグ、規約違反、テスト不足などを機械に確認させ、人間は設計やリスクの判断へ集中できます。
これはかなり合理的です。
それでも、人間による判断が残るなら最後に一つ問いが残ります。
人間は何を根拠に「このコードをMergeして大丈夫」と判断するのでしょうか。
数千行の生成コードを見て問題を判断するには、コードベース全体の構造、設計、性能、保守性、既存仕様などへの理解が必要です。
Faye氏も、AIエージェントを効果的に使うには、批判的に考え、アーキテクチャレベルで判断できる開発者が必要だと指摘しています。
ここで少し妙な構造が生まれます。
AIをうまく使うには技能が必要
↓
AIに任せる仕事が増える
↓
その技能を使う機会が減る
↓
技能が衰える可能性がある
↓
AIを監督する力にも影響する
Faye氏はこれを「skilled orchestrator paradox」として扱っています。
Anthropicの「How AI Is Transforming Work at Anthropic」でも似た問題が指摘されています。Claudeを効果的に利用するには監督が必要ですが、その監督には、AI利用によって使う機会が減りうるコーディング能力そのものが必要になるという「paradox of supervision」です。
AI支援で理解度が下がったRCTもある
技能の話は感覚論だけではありません。
Anthropicは2026年1月、52名のソフトウェアエンジニアを対象に、AI支援がコーディング技能の形成へ与える影響を調べたランダム化比較試験（RCT）を発表しています。
参加者は「AI支援あり」と「手作業」の2群に分かれ、初めて使うPythonライブラリを使った課題に取り組みました。
その直後に行われた理解度テストでは、AI支援群の平均スコアが50％、手作業群が67％。差は統計的に有意でした（p=0.01）。とくに差が大きかったのはデバッグに関する問題です。
作業時間はAI支援群のほうがやや短かったものの、こちらの差は統計的に有意ではありませんでした。
この実験だけで「AIを使うとプログラミング能力が落ちる」と一般化することはできません。
対象は52名で、特定の課題を用いた短期的な実験です。Anthropic自身も、この結果が長期的な技能形成まで予測するかどうかは今後の研究課題だとしています。
それでも、少なくとも成果物を完成させることと、その過程で理解を形成することは別に測る必要があると分かります。
成果物を得ることと、経験を得ることは同じではない
経験の浅い開発者が、新しい技術を使って何かを実装するとします。
自分で取り組むなら、仕様を理解し、設計し、コードを書きます。当然、うまく動かないこともあります。
仕様を理解する
↓
設計する
↓
コードを書く
↓
動かない
↓
ログを見る
↓
原因を考える
↓
修正する
↓
また失敗する
↓
理解が深まる
効率だけを見れば、かなり面倒です。
同じエラーに何時間も悩むこともあります。設計を間違えて作り直すこともあります。
ただ、あとでコードをレビューするときに効いてくるのは、こうした失敗の記憶だったりします。
AIへ大部分を任せれば、別の流れにできます。
仕様
↓
AI
↓
完成したコード
↓
レビュー
成果物は早く手に入ります。
しかし、その間に人間が経験したものまで同じとは限りません。
コードを読むだけで、作る・壊す・直す経験を代替できるか
コードレビューにも学習効果はあります。
他人のコードから知らなかった設計方法を学べますし、自分なら選ばなかった実装を読むことで、新しい考え方に触れることもあります。
ただ、自分で問題を解くときの経験とは種類が違います。
バグを作り、原因を探す。設計が失敗する。ログとコードを読みながら仮説を立てる。修正したら別の問題が出てくる。
こうした試行錯誤を繰り返すことで、明文化しにくい判断材料も蓄積されます。
Faye氏は「Agentic Coding is a Trap」で、若手開発者が生成コードのレビュー中心へ移ることで、コードを直接扱う摩擦や学習機会が減ることを問題視しています。
コードを読むことに意味がない、という話ではありません。
読む経験だけで、作る・壊す・直す経験までどこまで置き換えられるのか。
AI時代の育成を考えるなら、ここはかなり慎重に見たほうがよさそうです。
AIが生み出す「Expert Novice」という問題
Faye氏は2026年7月22日の「AI Coding will Prevent Expertise」で、この問題をさらに掘り下げています。
そこで紹介されるのが「Expert Novice」、専門家のように見える初心者という考え方です。
AIを使えば、経験の浅い開発者でも、経験豊富な開発者が作ったように見える成果物を生成できる場合があります。
ベテランが作ったように見える成果物
≠
ベテランと同じ知識・判断力
AIの大きな利点であると同時に、成果物だけを見て技能を判断しにくくなる理由でもあります。
Faye氏は、この議論の中でJames Prather氏らがICER 2024で発表した「The Widening Gap: The Benefits and Harms of Generative AI for Novice Programmers」を紹介しています。
研究対象はプログラミング初心者21人。参加観察、インタビュー、アイトラッキングを組み合わせた研究です。
AIツールを積極的に使った参加者の多くでは、計画段階を飛ばし、「理解していないのに理解したつもりになる」illusion of competenceが観察されました。
逆に、AIの提案をあえて無視すべき場面を判断する「negative expertise」を身につけた参加者は、より良い学習につながったと報告されています。
これは2024年の初心者を対象にした観察研究であり、先ほどのAnthropicによる実務エンジニア向けRCTとは対象も方法も違います。結果をそのまま同一視することはできません。
ただ、どちらもAIを使って成果を出す能力と、対象を理解する能力を分けて考える必要性を示しています。
「摩擦」は全部なくしたほうがいいのか
AIの魅力は、面倒な作業を減らせることです。
ところがソフトウェア開発には、生産性の面では邪魔に見えても、学習では意味を持つ時間があります。
なぜ動かない？
↓
ログを見る
↓
仮説を立てる
↓
コードを読む
↓
修正する
↓
また失敗する
↓
別の仮説を立てる
↓
原因が分かる
Faye氏は、こうした考え方を「Friction is a Feature」と表現しています。
熟練は説明を読んだだけで完成するものではなく、経験、反復、試行錯誤、失敗を通じて形成されていく。そうした摩擦の中で、開発者の直感や「taste」も育つという議論です。
「この実装、なんとなく危ないな」と感じることがあります。
言語化すると設計原則や過去の障害事例、性能特性などへ分解できるとしても、その場では一瞬の違和感として現れることもあります。その判断の背景には、過去にコードを書き、壊し、直した経験が積み重なっています。
AI時代のコードレビューには、技能を維持する役割もある
コードレビューの役割を整理すると、品質保証だけではありません。
品質保証
このコードは期待どおり動くのか。バグやセキュリティ上の問題を持ち込まないかを確認します。
設計判断
動けばよいだけではなく、この実装を既存のコードベースへ取り込んでよいのかを判断します。
知識共有
なぜこの変更が必要なのか、既存システムとどう関係するのかをチーム内で共有する場所にもなります。
人間側の理解を維持する
AIがコードを書く量が増えるほど、人間自身がコードを書く時間は減ります。
そのうえコードを読む時間まで減らせば、AIの出力を評価するための土台まで弱くなりかねません。
コードレビューは、AIの成果物を検査する工程であると同時に、人間がコードベースとの接点を保つ場所にもなり得ます。
AIの生成量より、人間が理解できる量を基準にする
AIが1時間で1万行のコードを生成できたとしても、その1万行を人間が理解できないなら、開発プロセス全体が1万行分高速になったとは言えません。
Faye氏も、一度にレビューできる以上のコードを生成しない使い方を挙げています。
変更が大きすぎるならタスクを分割する。必要なら途中で手動のリファクタリングも行う。
開発速度の上限をAIの生成能力だけで決めず、人間が理解できる変更量も制約として扱うという考え方です。
小さな単位でAIに実装させる
↓
人間が変更を理解する
↓
テストする
↓
レビューする
↓
次の変更へ進む
AIを使わない開発へ戻る必要はありません。
AIの速度を使いながら、人間の理解を置き去りにしないための運用です。
AIに何を任せ、人間は何を経験し続けるのか
Faye氏自身も、LLMを使わないことを主張しているわけではありません。
仕様や計画の作成、調査、ドキュメント、アドホックなコード生成などへLLMを使いながら、人間自身も実装へ関わり続ける方法を提案しています。
「AI Coding will Prevent Expertise」では、コードを完成させるだけでなく、インタラクティブなドキュメント、チュートリアル、ソクラテス式の問いかけなど、学習を促すAI利用にも触れています。
定型的なコード生成、ドキュメント作成、テストの補助などはAIへ任せやすいでしょう。
一方、初めて扱う難しい問題について、調査、設計、実装、デバッグ、判断のすべてをAIへ任せ、最後に出来上がったコードだけを見る使い方では、人間側の経験が大きく抜け落ちます。
Faye氏が示すチェック項目にも、AIがなくても自分でその作業をできるか、理解を深めるために使っているのか、それとも答えを早く得るためだけに使っているのか、生成物を自分で説明・監査できるか、といった問いがあります。
AIの利用率を高くすること自体を目標にするより、どの仕事を委譲しても人間側の理解が失われにくいかを見る必要があります。
AI時代にコードレビューは誰のためにあるのか
コードレビューは、もちろんソフトウェアの品質を守るためにあります。
AIが書いたコードでも、人間が書いたコードでも、バグや危険な設計を本番へ入れてよい理由にはなりません。
ただ、AIによってコード生成が高速化すると、レビューにはもう一つの役割が見えてきます。
人間に求められる仕事が「コードを書く」から「コードを理解し、評価し、判断する」へ移るなら、その判断力を維持する機会も必要になります。
そして判断力は、完成したコードを眺めるだけで自然に育つとは限りません。
自分で書く。失敗する。デバッグする。設計をやり直す。なぜ動かなかったのかを考える。
そうした経験が、あとからコードを見るときの判断材料になります。
AIに任せる仕事が増えるほど生産性は上げられる。その一方で、人間が経験する仕事が減れば、AIを監督するための技能を育てる機会も減ります。
コードレビューを最後の品質チェックだけにしてしまうと、この問題は扱えません。
AIが生成したコードを確認しながら、人間自身もそのコードを理解する。なぜこの設計なのかを考え、本当にMergeしてよいのかを判断する。
コードレビューは、AIが書いたコードの品質を保証するだけでなく、人間がコードとの接点を維持するための「摩擦」にもなります。
AIが書けるコードの量は、これからさらに増えていくでしょう。
そのとき開発チームが管理しなければならないのは、生成できる量だけではありません。
人間が理解し、責任を持って判断できる量を、どこまで保てるか。
AI時代のコードレビューは、その境界を守る工程になっていくのかもしれません。
よくある疑問
AIがコードレビューもすれば、人間のレビューは不要になりますか？
自動テスト、静的解析、AIレビューを組み合わせれば、人間の負担を減らせます。ただし、既存システムとの整合性や設計上の妥当性、変更を本番へ入れるリスクなど、最終的な判断まで完全に代替できるとは限りません。
AIを使うとプログラミング能力が落ちると証明されたのですか？
そこまで一般化できる研究結果ではありません。AnthropicのRCTでは特定条件下でAI支援群の理解度が低い結果になりましたが、対象人数や課題には制約があり、長期的な技能形成への影響は今後の研究課題とされています。
AIコーディングを使わないほうがいいのでしょうか？
この記事で参照した論考も、AIを使わないことを主張しているわけではありません。レビューできない量を一度に生成しない、学習すべき問題まですべて委譲しないなど、人間が理解と判断に関わり続ける使い方が論点になっています。
参考・参照元
- Judy Hanwen Shen, Alex Tamkin（Anthropic）, “How AI assistance impacts the formation of coding skills”（2026年1月29日）
- Anthropic, “How AI Is Transforming Work at Anthropic”（社内エンジニアへの聞き取りに基づくレポート、2026年）
- James Prather, Brent N. Reeves, Juho Leinonen, Stephen MacNeil, Arisoa S. Randrianasolo, Brett A. Becker, Bailey Kimmel, Jared Wright, Ben Briggs, “The Widening Gap: The Benefits and Harms of Generative AI for Novice Programmers”（ICER ’24、2024年）
- Lars Faye, “Agentic Coding is a Trap”（2026年4月）
- Lars Faye, “AI Coding will Prevent Expertise”（2026年7月22日）
- Communications of the ACM, Amy Buttell, “Leverage Code Review for Sustainable AI Coding Development”（2026年9月4日）
コメント