コードは書けても、AIの出力を読めない人が増えている理由

AIにコードを書かせる時間が増えるほど、よく聞く助言がある。「実装はAIに任せて、人間はレビューに回ればいい」。レビューという言葉を使うと、誰でも最初からできる作業のように響く。だが実際に、AIに書かせることへ慣れ始めたばかりの人のそばで見ていると、詰まっている場所はたいてい「書けない」ではなく「読めない」ところにある。AIが出してきた数十行の差分を前に、どこから疑えばいいのか分からず、結局「動いているなら良い」とそのまま流してしまう。この詰まりは、書く練習をどれだけ重ねても自然には解消しない。

「読む力」は書く力の"ついで"には育たない

長くコードを書いてきた人なら、読む力も自然に高いはずだ、という前提は根強い。しかし書くときに使っている頭の使い方と、読むときに使っている頭の使い方は、実はかなり違う。

書く作業は、自分の中にある仮説――こう実装すればこの要件を満たすはずだ――を、手を動かしながら確かめていく作業だ。途中で違和感があれば、その場で自分で直せる。仮説の主導権は、最初から最後まで自分の手元にある。

一方、読む作業は、他人(今ならAI)がすでに下した無数の小さな判断を、手がかりの少ない状態から後追いで再構成する推理に近い。なぜこの変数名が選ばれたのか、なぜこの条件分岐がここに置かれているのか、本人に聞かない限り分からない前提が、コードの外側にいくらでも隠れている。書く力が「仮説を形にする力」なら、読む力は「隠れた前提を推理する力」であり、求められる頭の使い方そのものが別物だ。書く練習だけを積んでいても、この推理の筋力は育たない。

読む行為は増えているのに、「読む練習」という言葉はまだ追いついていない

この非対称を裏づける手がかりが、Qiitaの投稿傾向にある。「AIコードレビュー」という語を含む投稿は、2026年の10か月足らずで、すでに2025年の年間件数の3倍を超えている。AIの出力を検証する行為そのものへの関心は、今年に入って明らかに跳ね上がった。

ところが同じ期間を見ても、「コードリーディング」という言葉そのものを含む投稿は、2025年の年間件数にまだ届いていない。読む行為は爆発的に増えているのに、それを名前のついた練習対象として語っている投稿は、むしろ増えていないのだ。みんながAIの出力を読んで検証しているのに、誰もそれを「読む練習」として意識的に扱っていない――このねじれこそが、読む力が書く力の"ついで"として放置されがちな理由の一端だろう。名前のない技能は、意図して鍛える対象にもなりにくい。

読む力を独立して鍛えるなら、何をすればいいか

読む力を書く力と別の技能として扱うなら、練習の形も当然別にする必要がある。抽象的な心構えではなく、今日から時間を区切って組み込める形で四つ挙げる。

差分レビューは、結果を見る前にやる。 AIが出したコードの差分(diff)を見た瞬間、実行する前に「ここで壊れるとしたらどこか」を一つ指差して言い切る。当たっても外れても、そのあとに実際の挙動と照合する。実行結果を先に見てしまうと、この訓練は成立しない。文法的に正しいコードの中から、仕様的に怪しい場所を拾う感覚は、この順番を守ってこそ育つ。

コメントを隠して、仕様を一文で言い切る。 チームメイトやAIが書いた関数を、コメントやPRの説明文を隠した状態で読み、「これは何をしようとしているコードか」を自分の言葉で一文にする。終わったら元の説明と見比べて、ズレていた部分を数える。ズレが大きいほど、自分がまだ構文を目で追うことしかできておらず、意図までは読めていないという診断になる。

自分のPRを出す前に、他人のPRを3つ読む。 直近にマージされた他人のPRを3つ選び、レビューする側として読む。実際にコメントするかどうかは問わない。「自分だったらここを指摘する」という箇所をメモするだけでいい。これを先にやっておくと、自分がPRを書くときの視点が変わる。レビューされる側として「ここは聞かれる」と先に気づけるようになるからだ。

マージ済みのPRのレビュー履歴を遡って読む。 規模の大きいオープンソースのリポジトリで、実際にマージされたPRのレビューコメントのやり取りを読む。何が最初に疑われ、どういう説明で通ったのかというパターンが、何本か読むうちに見えてくる。これは書いても身につかないが、読む回数を重ねることでしか蓄積されない経験だ。

いずれも「とにかく書く量を増やす」練習とは別の時間の使い方になる。AIがどれだけ早くコードを出してくれても、それを検証できる目を持つ人がチームに一人もいなければ、量産されたコードはそのまま負債になっていくだけだ。レビューを素通りした一行は、その場では何も起こらない。半年後、誰かが仕様変更でそこに触れたときに初めて、なぜここがこうなっているのか誰も説明できない、という形で返ってくる。書く練習に偏っていた学習時間の一部を、意図して「読む練習」に付け替えておくことは、その返ってくる瞬間を減らすための、今からできる備えだ。

tasklogは、実際に読まれ・引用されている技術書を集めて置いている場所だ。読む力を鍛える一冊を探すときの手がかりに、一度のぞいてみてほしい。

https://s-tasklog.com/books/general

(数値出所:Qiita API集計、2026年10月時点のスナップショット。2026年分は年間未確定の暫定値)