AIでコード生成は加速、でも人間の確認が追いつかない問題。t-wadaが示す「レビュー解体」という答え - エンジニアtype

生成AIは「コードを書く」というエンジニアの仕事を急速に変えた。AIと相談しながら実装を進めるだけでなく、作業を丸ごとAIエージェントに預ける場面も増えている。

では、コードを書く時間が短くなれば、開発はその分楽になるのだろうか。大量に生まれたコードの正しさを誰が判断するのか。その確認を省力化できたとして、人間はソフトウエアを理解し続けられるのか。

テスト駆動開発の実践者として、長年ソフトウエア開発を見つめてきた和田卓人（t-wada）さんと共に、2026年上半期までの変化をたどりながら、これからの開発に残る課題を考えてみよう。

「プログラミングの終わり」が意味するもの

私は四半世紀にわたりこの業界を見てきましたが、約70年のソフトウエアエンジニアリングの歴史を振り返っても、直近の2年間ほど変化の激しい時期はなかったと感じています。

その転換を象徴する出来事が、2025年２月初頭に続けて起きました。

25年2月4日、技術書の金字塔であるオライリーメディアの創業者、ティム・オライリー氏が『The End of Programming as We Know It』というタイトルの記事を発表しました。業界のレジェンドが「The End of Programming（プログラミングの終わり）」と題した文章を出す。長年プログラマーとしてキャリアを重ねてきた私にとっても、大きな衝撃がありました。

ただ、見落としてはいけないのは後半の「as We Know It（われわれが知る形での）」。プログラミングという行為そのものではなく、「これまで私たちが親しんできたプログラミングの姿」の終焉。そして、まったく新しい形へと再定義されていくことが示唆されているのです。

このオライリー氏の記事に先立つこと1日、25年2月3日には、OpenAIの共同創業者であり元CTOでもあるアンドレイ・カーパシー氏が、X上でとあるポストを投稿しました。そこに記載されていたキーワードこそ、「バイブコーディング」です。

There’s a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It’s possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like "decrease the padding on the sidebar by half" because I’m too lazy to find it. I "Accept All" always, I don’t read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I’d have to really read through it for a while. Sometimes the LLMs can’t fix a bug so I just work around it or ask for random changes until it goes away. It’s not too bad for throwaway weekend projects, but still quite amusing. I’m building a project or webapp, but it’s not really coding – I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.

— Andrej Karpathy (@karpathy) February 2, 2025

自然言語でAIに要望を伝え、返ってきたものを使いながらアプリを作る。コードを細かく読んだり、自分でエラーを追ったりする従来の開発の常識を塗り替える新たなトレンドが、瞬く間に世界中を席巻していったのです。

「AIに書かせるか否か」は、もう論点じゃない

2024年末頃は「AIにコードを書かせるべきか、それとも自分で書くべきか」という議論が盛んでしたが、「AIにコードを書かせる」ことはもはやマストになりました。25年末以降、現場の関心は「使うかどうか」から「どう使うか」へ移っています。

ソフトウエア開発の現場では大きく二つの使い方が確立されました。私はこれを「伴走」と「委託」と呼んでいます。

「伴走」は、コーディングエージェントと対話しながら二人三脚で開発するスタイルです。何を作るべきか、どう作るべきかも含めてやり取りする。私自身、基本的にはこちらを主軸にしています。

「委託」は、自律的なAIたちに開発を任せ切るアプローチです。タスクを預けておき、「作っておいて」と依頼し、後から確認する進め方ですね。

AIが自律的にコードを生成していくため、スピードは圧倒的に「委託」が速い。ですが、人間が途中のプロセスを把握しにくく、レビューの負荷がかかります。

一方、「伴走」は人間が常に状況を把握できるため、意図しないトラブルや暴走を防ぐことができます。

ただし、「伴走」は人間の時間に依存するためスケールしにくいのもまた事実。それぞれの特性を理解した上で、適材適所で使い分けていくことが、エンジニアや組織に求められているのです。

最後のボトルネックは「レビュー」

26年現在、ソフトウエア開発ライフサイクル（SDLC）の前提そのものが、根本から覆ろうとしています。

従来のSDLCは、人間が仕様を考え、コードを書き、レビューし、テストし、運用することを軸に組み立てられてきました。ところがコーディングエージェントの進化によって、コードを書く速度や量といった「物的生産性」では、AIは完全に人間を凌駕したのです。

かつては人間がハンドルを握り、AIが助手席に座る「コパイロット」の時代でしたが、現在はAIがドライバー（主務）であり、人間はアドバイザー（指揮・監督）。AIを前提とした開発体制への組み替えが、今年後半の大きなテーマとなります。

AIが高速に大量のコードを書けるようになった現在のソフトウエア開発における最大のボトルネックは、間違いなく「コードレビュー」にあります。だからといって、安易にレビューをやめてしまえば品質の崩壊を招くだけです。

では、どうすべきか。ヒントは、これまでコードレビューが担っていた役割を解体し、五つの工程へ分散させることにあります。

1. 上流の仕様レビュー

ソフトウエア業界は「完璧な要件定義を行う」ことを理想としながら、何度も敗北を喫してきました。完璧な要件定義など人間に不可能だったからです。

しかしAIを使えば、仕様の矛盾や抜けを以前より細かく検討しやすくなります。仕様レベルでの不具合を上流で塞ぐことが、後工程のレビュー負荷を直接的に軽減します。

2. テスト駆動開発

私は20年以上にわたり国内でTDDの啓蒙活動を行ってきましたが、過去最高の普及を見せたのがまさに昨年でした。

AIに実装後のテストを書かせると、自分が書いたコードに都合のいいテストを作ることがあります。ですが「先にテストを書かせ、それをパスするようにコードを実装させる」というTDDの手順を踏ませると、ハーネスとしての効果が上がります。「想定通り動くか」の確認をテストコードに肩代わりさせることで、人間のレビュー業務を代替するのです。

3. 型システムと制約によるガードレール

AIは、与えられた文脈の中では整ったコードを書けても、システム全体への影響を見落とすことがあります。ですが、自動テストによる動的な検査に加え、型システムや静的解析ツールなどによる静的な検査を組み合わせることで、AIが全体を見通せない場合でも問題を機械的に見つけやすくなるのです。

4. ビジネスの影響度に基づくリスクマッピング

AI以前の時代にも、レビューには既に濃淡がありました。これはAI時代になっても変わりません。ビジネスへの影響度が低い領域はAIにレビューを委ね、万が一障害が起きても即座にロールバックできる「MTTR（平均修復時間）の短縮」に舵を切る。ビジネスリスクに応じた強弱をつけることで、人間が介入すべき領域を削ぎ落としていきます。

5. 継続的な理解の形成

コードレビューは単なる品質チェックではなく、シニアからジュニアへの技術継承やチーム文化を育む場でもありました。省力化すれば、この機会も減ります。

現在、一人の人間に対して複数のAIエージェントが対話を求めてくる時代になり、個人のキャパシティは限界を迎えています。だからこそ、今後は人間側がチームを組み、AIとのやり取りやプロンプトの設計、AIへの回答内容をリアルタイムで議論・共有するアプローチが重要になります。開発のプロセスそのものをチームで開示し合うことで、レビューに頼らない新たな学びの場を創出するのです。

技術的負債は減っても、認知の負債は増える

これまで、ソフトウエア開発の現場における負債といえば、保守性に乏しいコードや設計を指す「技術的負債」がその代表格でした。しかし、現在はLLMやコーディングエージェントの能力が上がり、技術的負債は解消されつつあります。

では、開発の現場から問題が消え去ったのかといえば、決してそうではありません。いま私たちは、まったく異なる次元の新たな負債に直面しています。それが「認知負債」です。

人間がキーボードを叩いてコードを書いていた時代、コードを書くプロセスそのものが、エンジニアの頭の中に「システムの本質を理解するメンタルモデル」を形成させていました。しかし今や、人間が理解していなくともAIが実装を終えてしまう。「理解」と「生成」のスピードが完全に乖離してしまったのです。

短期間で生産性を上げたい組織と、手っ取り早くスピードを出して個人実績をアピールしたいエンジニア。その間で、「理解の置き去り」を許容する悪魔の共犯関係が成立してしまったのです。

負債のメタファという概念を生んだウォード・カニンガム氏は、開発を通じて学び得た「人間の理解」をコードに反映し続けないことこそが負債なのだと示唆しました。それから約30年。今や「人間側の理解が追いつかない」という認知負債が、組織の未来を脅かす静かな時限爆弾として埋め込まれつつあるのです。

ここで覚えておきたいのが、DevOpsの権威ある調査機関DORAが発表した「AIは増幅器である」という結論です。

DORAレポートの2025年版が出た。AIは増幅器であり、組織の能力を映す鏡。高パフォーマンス組織の強みを増幅し、より速く革新的にする。低パフォーマンス組織の機能不全を増幅し、さらなる混乱と不安定さを生み出す。AI導入の成否はツールではなくシステム（組織）の問題。 https://t.co/aWKIzXNUYv

— Takuto Wada (@t_wada) October 8, 2025

開発組織の地力が高ければ、AIは爆発的な革新をもたらします。しかし、もともと機能不全を起こしていた組織にAIを投入すれば、混乱と不確実性が増幅されるだけ。つまり、AIは組織の「強み」も「弱み」も等しく増幅する。AIを導入すれば全員の能力が底上げされるというのは幻想なのです。

AIが止まったとき、人間に操縦できるのか

ここで、今から40年以上も前、1983年に認知心理学者のリザンヌ・ベインブリッジ氏が発表した著名な論文「Ironies of Automation（自動化の皮肉）」をご紹介しましょう。

当時、自動化とは「機械」によるものを指しました。自動化によって人間の日常的な出番が減っても、機械が対応できなくなったときには人間が介入しなければならない。しかも、そのとき求められるのは、普段より難しい判断です。

飛行機の自動操縦を思い浮かべてください。平時の操縦から遠ざかっていた人間が、警報の鳴る非常時に突然、操縦を引き継ぐ。必要な状況把握と技能を、その場で一瞬にして取り戻せるでしょうか。

ソフトウエア開発でも、同じ問いが生じます。AIが日々の実装を担い、人間が途中の判断を知らないまま進んだとします。それでも障害が起きたときには、人間が原因を見極め、手を打たなければならない。

しかもAIの精度が上がって失敗が減るほど、人間が難しい問題を経験する機会も少なくなる。普段は任せておきながら、いざというときだけ高度な判断を求める。その役割を担える人を、どう育て続けるのか。

ここに、レビューを効率化する話だけでは解けない問題があります。

レビューを手放しても、「理解」は手放せない

いま開発現場で目に見える課題は、コードレビューの負担をどう減らすかです。しかし、その裏側では、人間の理解をどう維持するかが問われています。

アンドレイ・カーパシー氏が引用した「思考は外注できても、理解は外注できない」という言葉は、この違いを端的に表しています。

This is the the quote I’ve been citing a lot recently.

— Andrej Karpathy (@karpathy) April 30, 2026

AIに実装を任せ、テストや仕組みの確認を一部担ってもらうことはできます。しかし、そのコードが何を意味し、システム全体にどう作用するのかという「人間の理解」だけは、どこまで技術が進化しようとも委託することは不可能なのです。

AIという強力な増幅器を手にした私たちは今、「理解」という人間本来の知性を手放さずにどこまでスケールできるかという、いまだかつてない試練の前に立っています。

レビューからの解放を進めつつも、システムを理解するための営みを意識して残すこと。それこそが、この先にある新たな課題だと考えています。

編集／秋元 祐香里（編集部）

---

Page 2