エンジニアtypeは2026年10月5日付の記事で、プログラマーの和田卓人さん（t-wada）の「レビュー解体」を紹介しました。1 AIがコードを書く速さに人の確認が追いつかない問題への対策として、和田さんは、コードレビューが担ってきた役割を5つの工程に分けることを勧めています。1 レビューを機械に任せても、人がシステムを理解する役目までは手放せないとも述べています。1
この記事でわかること
- 5つの工程のうち、自動で確かめられるものと、人に残るものの違い
- 「認知負債」とは何か、2025年版のDORA報告は何を指摘したか
- AIにコードを書かせている会社が、今週のうちに確かめておきたい3点
レビューの負担は調査にも表れている
和田さんは、AIの書くコードの量と速さが人の処理を上回ったいま、最大のボトルネックは「コードレビュー」だと述べています。1 コードレビューとは、他の人が書いたコードを、リリース前に読んで確かめる作業です。
和田さんの見立てを裏づける調査もあります。 キッカケクリエイションが2026年2月に行ったインターネット調査では、業務でコードレビューを担当するITエンジニア322人のうち、86.3%が「レビュアーの負担が増えた」と答えました。2 レビューで問題として最も多く挙がったのは、「提出者本人がコードの内容を説明できなかった」で、49.5%でした。2
調査は1社が実施したもので、回答は自己申告です。 対象はレビュー担当者に限られます。バグの原因がAIの書いたコードかどうかも、回答者の判断です。2
レビューの役割を5つの工程に分ける
和田さんが挙げた5つの工程は、次のとおりです。1 右端の列は、筆者が職場の言葉に言い換えたものです。
| 工程 | 和田さんの説明 | 職場の言葉にすると |
|---|---|---|
| 1 上流の仕様レビュー | AIで仕様の矛盾や抜けを洗い出し、設計の段階で直す | 作らせる前に、完成の条件を文章で確かめる |
| 2 テスト駆動開発（TDD） | 先にテストを書かせ、そのテストを通るコードを書かせる | 完成の条件を、先にテストとして決めておく |
| 3 型システムと制約によるガードレール | 型システムなどの静的な検査を、実行して確かめるテストに組み合わせる | 機械で見つけられる誤りは、機械に見つけさせる |
| 4 ビジネスの影響度に基づくリスクマッピング（事業への影響の大きさによる色分け） | 影響の小さい領域はAIにレビューを委ね、すぐ元に戻せる体制にする | 影響の大きい部分だけ人が読み、小さい部分は戻せる準備をして任せる |
| 5 継続的な理解の形成（理解を保ち続ける） | AIとのやり取りやプロンプトの設計を、チームで見せ合う | 誰がどう指示して何が返ったかを、チームで共有する |
1〜3はAIやツールに確かめさせる工程、4は人が読む場所を絞る工程、5は人の理解を保つ工程です。 5つ目は機械に任せられません。4つ目も、人が読む場所は残ります。
テストは先に書かせる
2つ目の工程でテストを先に書かせるのは、実装のあとに書かせると、AIが自分のコードに都合のよいテストを作ることがあるためです。1 先にテストを書かせてから実装させれば、そのテストが、人が確かめるときの基準になります。
型と静的解析は見落としを拾う
AIは、指示された範囲では正しく動くコードを書けても、システム全体への影響を見落とすことがあります。1 型システムは、型の食い違い（数字を入れる欄に文字を入れるなど）を実行前に見つける仕組みです。 静的解析は、実行せずにコードの誤りを調べるツールです。 この2つを自動テストに加えれば、AIが全体を見通せなくても、誤りを機械が見つけやすくなります。1
レビューを機械に任せても人に残る「理解」
和田さんは、技術的負債（直しにくいコードや設計）はAIで減りつつあるものの、別の負債が増えていると述べています。 別の負債とは「認知負債」です。1 人が自分でコードを書いていた頃は、書く過程でシステムの全体像が頭に入りました。 いまはAIが実装まで済ませてしまうため、AIが書く速さに理解が追いつかない、というのが和田さんの指摘です。1
DORA（開発チームの成果を調べる研究プログラム）の2025年版の報告は、AIが組織にもともとある強みも問題も増幅すると指摘しています。3 和田さんはこの報告を引いて、AIを入れれば全員の能力が上がるというのは幻想だと述べています。1
エンジニアtypeの記事は、1983年のベインブリッジ氏の論文「自動化の皮肉」も紹介しています。 自動化で人が操作する場面が減っても、機械が対応できないときは人が引き受けなければならず、その判断は平常時より難しくなるという内容です。1 論文の原文は確かめておらず、記事に書かれている範囲で紹介しています。
AIにコードを書かせている会社が確かめておきたい3点
以下は、和田さんの提案を筆者が読み替えたものです。 たとえば、AIに予約管理の画面や社内の集計マクロを作らせている会社は、次の3点を確かめてみてください。
- 完成の条件を先に書いたか。 予約が二重に入らない、金額の合計が合う、といった条件を、作らせる前にテストとして決めます
- 人が読む範囲を決めたか。 お金・個人情報・外部への送信に関わる部分は人が読み、見た目だけの部分はAIに任せます
- コードを提出した人が、その動作を説明できるか。 調査で最も多く挙がった問題は、提出者が説明できないことでした。止まったときに直せる人がいるかが問われます
AIにレビューさせる手順は、AIレビューの検証を扱った記事にまとめています。 検査が機能するかをわざと壊して確かめる方法は、故障注入の記事で紹介しています。 AI任せの開発の全体像は、AI駆動開発とバイブコーディングの違いで整理しています。
- 外部の開発会社に頼んでいるなら、上の3点をそのまま発注先に確かめてみましょう
- ノーコードのツールで作っているなら、1点目の完成の条件を先に決めるところから始めるのが現実的です
- AIが書いたものを確かめられる人がいないなら、お金と個人情報に関わる部分の開発は、AIだけに任せないでください。先に確認する人を決めます
和田さんの5つの工程は、効果を測定した結果ではなく、プログラマー1人の提案です。 まずは影響の小さい部分で試すのが現実的です。
