AIの速さに確認が追いつかない問題を、和田卓人さんが解説。「レビュー解体」と、任せても手放せない理解

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、エンジニアtypeに載った和田卓人さんの記事「AIでコード生成は加速、でも人間の確認が追いつかない問題。t-wadaが示す「レビュー解体」という答え」を紹介するね。私が持ち帰ったのは、AIに仕事を任せる時、作り始める前に「何ができたら合格か」と「どう確かめるか」をセットで渡す、という使い方です！

和田卓人さん（エンジニアtype・「AIでコード生成は加速、でも人間の確認が追いつかない問題。t-wadaが示す「レビュー解体」という答え」・「AIに書かせるか否か」の節より）

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

今回紹介するのは、エンジニアtypeに載った和田卓人さん（t-wadaさん）の記事です。和田さんは、テスト駆動開発の実践者として長年ソフトウエア開発を見つめてきた方です。公開は2026年10月5日。

コードの話です。この記事を、AIに作業を任せる私の頼み方に引き寄せて読んでいきます。

和田さんは、2024年末頃は「AIにコードを書かせるべきか、それとも自分で書くべきか」という議論が盛んだったと振り返ります。25年末以降は、関心が「使うかどうか」から「どう使うか」へ移った、という流れです。

その「どう使うか」を、和田さんは2つに分けています。1つ目は「伴走」。コーディングエージェントと対話しながら、二人三脚で進めるやり方です。2つ目は「委託」。

自律的なAIに任せ切って、「作っておいて」と頼み、後から確認するやり方です。

速さは、委託が圧倒的です。でも、人間が途中のプロセスを把握しにくいので、レビューの負荷がかかります。伴走は、人間が常に状況を把握できるので、意図しないトラブルや暴走を防げます。

ただし、人間の時間に依存するので、スケールしにくい。和田さん自身は、基本的にはこの伴走を主軸にしています。

私なら、AIに任せている仕事を並べて、伴走の仕事と委託の仕事に分けるところから始めます。分け方で、確認にかける時間の置き場所が変わるからです。

和田卓人さん（エンジニアtype・「AIでコード生成は加速、でも人間の確認が追いつかない問題。t-wadaが示す「レビュー解体」という答え」・「最後のボトルネックは「レビュー」」の節より）

AIが高速に大量のコードを書けるようになった現在のソフトウエア開発における最大のボトルネックは、間違いなく「コードレビュー」にあります。

和田さんは、2026年の今、ソフトウエア開発の前提が根本から覆ろうとしていると書いています。従来は、人間が仕様を考え、コードを書き、レビューし、テストし、運用する流れでした。

ところが、コードを書く速度や量では、AIが人間を完全に上回りました。かつては、人間がハンドルを握り、AIが助手席に座る「コパイロット」の時代。

今は、AIがドライバー（主務）であり、人間はアドバイザー（指揮・監督）です。

そうなると、詰まる場所は、書く所ではありません。確かめる所です。

だからといって、レビューをやめれば解決、でもありません。和田さんは、安易にレビューをやめてしまえば品質の崩壊を招くだけです、と書いています。

では、どうするか。和田さんが示すのは、レビューが担っていた役割を解体して、5つの工程へ分散することです。この記事の中心は、ここです。次の章から、順番に見ていきます。

私なら、まず、自分のところに確認待ちで溜まっているAIの成果物がいくつあるかを数えます。

和田卓人さん（エンジニアtype・「AIでコード生成は加速、でも人間の確認が追いつかない問題。t-wadaが示す「レビュー解体」という答え」・5つの工程の「2. テスト駆動開発」より）

ですが「先にテストを書かせ、それをパスするようにコードを実装させる」というTDDの手順を踏ませると、ハーネスとしての効果が上がります。

5つの工程の2つ目が、テスト駆動開発（TDD）です。和田さんは、二十年以上、国内でTDDの啓蒙活動を続けてきました。過去最高の普及を見せたのがまさに昨年だった、と書いています。

ポイントは、順番です。AIに、実装した後でテストを書かせると、自分が書いたコードに都合のいいテストを作ることがあります。

先にテストを書かせて、それをパスするようにコードを実装させる。この順番にすると、ハーネスとしての効果が上がります。「想定通り動くか」の確認をテストコードに肩代わりさせて、人間のレビュー業務を代替する。

和田さんの整理は、そこまでです。

私なら、AIに仕事を渡す前に、「何ができたら合格か」を先に書いて渡します。後から全部を見る代わりに、先に決めておく。TDDの順番を、AIへの頼み方に置き換える考え方です。依頼文の書き方は、最後の章でまとめます。

似た考えを、私は別の記事に書いています。

AI氣道『Claude Modsで、Claude Codeの「終わり」を別の判定者に言わせるやり方』より

「「終わった」を言う人は、作った本人以外に置く。」

作った側の自己申告だけで合格にしない、という考えは、『Claude Modsで、Claude Codeの「終わり」を別の判定者に言わせるやり方』で書いています。

ただ、和田さんが書いているのは、テストを先に書く順番の話です。作った本人以外に「終わった」を言わせる私のやり方は、私の運用で、TDDの代わりではありません。同じ向きの考えとして、並べているだけです。

和田卓人さん（エンジニアtype・「AIでコード生成は加速、でも人間の確認が追いつかない問題。t-wadaが示す「レビュー解体」という答え」・5つの工程の「4. リスクマッピング」より）

ビジネスへの影響度が低い領域はAIにレビューを委ね、万が一障害が起きても即座にロールバックできる「MTTR（平均修復時間）の短縮」に舵を切る。

5つのうち、2つ目のTDDは前の章で見ました。残りの4つを、短く並べます。

• 1つ目は、上流の仕様レビュー。AIを使えば、仕様の矛盾や抜けを以前より細かく検討しやすくなります。仕様の段階で不具合を塞げば、後のレビュー負荷が直接軽くなります。
• 3つ目は、型システムと制約によるガードレール。自動テストによる動的な検査に、型や静的解析ツールなどによる静的な検査を組み合わせます。AIが全体を見通せなくても、問題を機械的に見つけやすくなります。
• 4つ目は、ビジネスの影響度に基づくリスクマッピング。影響が低い所はAIにレビューを委ねて、障害が起きても即座に戻せる体制へ。人間が介入する領域を削ぎ落とします。
• 5つ目は、継続的な理解の形成。これは、後の章の話につながります。

私が一番気になったのは、4つ目です。見る場所に濃淡をつける。これは、AI以前からレビューにあった話で、AI時代になっても変わらない、と和田さんは書いています。

似た読みを、私は別の記事に書いています。

AI氣道『博報堂テクノロジーズが週次リリース+81%を実現したAI駆動開発の全ステップを社員2人が解説。「なにを人間が見るか」の決め方が一発でわかる』より

「重ねる数を増やすほど、人間が最後に見る場所は狭く、深くなっていく。」

検査を重ねて、見る場所を絞る、という読みは、『博報堂テクノロジーズが週次リリース+81%を実現したAI駆動開発の全ステップを社員2人が解説。「なにを人間が見るか」の決め方が一発でわかる』で書いています。

博報堂テクノロジーズの事例を読んだ時の、私の読みです。検査の数を競う話ではなく、どこを人間が最後に見るかを決める話だと思いました。

私なら、確認することを全部書き出して、2つに分けます。間違えると影響が大きいもの。間違えても、すぐ戻せるもの。人間が見るのは、影響が大きい方だけに絞ります。

和田卓人さん（エンジニアtype・「AIでコード生成は加速、でも人間の確認が追いつかない問題。t-wadaが示す「レビュー解体」という答え」・「技術的負債は減っても、認知の負債は増える」の節より）

「理解」と「生成」のスピードが完全に乖離してしまったのです。

5つ目の「継続的な理解の形成」の背景が、この章です。和田さんは、これまでの開発現場の負債といえば、保守しにくいコードや設計を指す「技術的負債」だったと言います。

LLMやコーディングエージェントの能力が上がって、技術的負債は解消されつつあります。

ただ、問題が消えたわけではありません。まったく異なる次元の新たな負債が出てきた、と和田さんは書いています。それが「認知負債」です。

人間がキーボードを叩いてコードを書いていた時代は、書く過程そのものが、頭の中に「システムの本質を理解するメンタルモデル」を作っていました。今は、人間が理解していなくても、AIが実装を終えてしまいます。

和田さんは、負債のメタファを生んだウォード・カニンガム氏にも触れています。開発を通じて学び得た「人間の理解」をコードに反映し続けないことこそが負債だ、という示唆です。それから約30年。

今の形で、その問いが戻ってきた、という流れです。

私なら、任せている仕事を1つ選んで、どこで間違うと誰が困るのかを、1行で書いてみます。1行で書けない仕事は、先に中身を確かめ直す候補にします。

和田卓人さん（エンジニアtype・「AIでコード生成は加速、でも人間の確認が追いつかない問題。t-wadaが示す「レビュー解体」という答え」・「技術的負債は減っても、認知の負債は増える」の節の中でDORAに触れた部分より）

AIは組織の「強み」も「弱み」も等しく増幅する。

認知負債の話の中で、和田さんが「覚えておきたい」と挙げたのが、DORAの調査です。DevOpsの調査機関DORAが発表した、2025年版の結論は「AIは増幅器である」でした。

和田さん自身も、2025年10月8日のXの投稿で、こう書いています。AIは増幅器であり、組織の能力を映す鏡。高パフォーマンス組織の強みを増幅し、低パフォーマンス組織の機能不全を増幅する。

つまり、開発組織の地力が高ければ、AIは革新をもたらします。もともと機能不全を起こしていた組織にAIを入れれば、混乱と不確実性が増えるだけです。

和田さんは、AIを導入すれば全員の能力が底上げされるというのは幻想なのです、と書いています。

私なら、AIに任せる前に、任せたい仕事を2つに分けて書きます。今うまく回っている所と、いつも詰まっている所です。まずは、うまく回っている所から任せます。

和田卓人さん（エンジニアtype・「AIでコード生成は加速、でも人間の確認が追いつかない問題。t-wadaが示す「レビュー解体」という答え」・「レビューを手放しても、「理解」は手放せない」の節より）

そのコードが何を意味し、システム全体にどう作用するのかという「人間の理解」だけは、どこまで技術が進化しようとも委託することは不可能なのです。

最後の2つの節で、和田さんの話は、効率の話から、理解の話に移ります。

1983年、認知心理学者のリザンヌ・ベインブリッジ氏が、「Ironies of Automation（自動化の皮肉）」という論文を発表しました。

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

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

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

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

そして結論です。

アンドレイ・カーパシー氏が引用した「思考は外注できても、理解は外注できない」という言葉を引いて、AIにテストや仕組みの確認を一部担ってもらうことはできても、「人間の理解」だけは委託できない、と書いています。

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

私の読みです。「理解を残す」とは、全部自分で見るという意味ではないと思います。私は、別の記事に、こう書いています。

AI氣道『AIに任せる範囲はどこまで？6万人が使うSNSアプリを作る開発者が、Claude Codeで決めている線引き』より

「確認を減らす方向は、作業のほう。減らさないのは、判断の理由です。」

確認を減らす場所と、減らさない場所を分ける、という線引きは、『AIに任せる範囲はどこまで？6万人が使うSNSアプリを作る開発者が、Claude Codeで決めている線引き』で書いています。

ただ、和田さんの言う「理解」は、判断の理由を残すことだけではありません。システムの仕組みそのものを、人間が理解し続けることです。判断の理由の記録だけでは、その代わりにはなりません。

私の線引きは、和田さんの結論の全部ではなく、一部に重なる、と考えています。

最後に、私ならこうします、という手順です。AIに渡す依頼文に、次の3行を足します。作り始める前に決めておく条件と、作り終えた後に返してもらう確かめ結果と、自分で書く判断の理由です。

和田さんは、AIが書く速さに人間のレビューが追いつかない問題を、レビューの役割を5つの工程へ分散することで解こうとしていました。そして、レビューを手放しても、「理解」は手放せないと結んでいます。

私が持ち帰ったのは、2つです。作り始める前に、合格の条件と確かめ方をセットで渡すこと。確認が通っても、何を任せていて、どこで間違うと誰が困るのかは、手元に残すことです。

最初の一歩は、次にAIへ渡す仕事の依頼文に、「何ができたら合格か」を1行足すことです。10分でできます！

この記事で学んだことを誰かに教えて恩送りして学びを深めよう！