動くコードほど、理解されなくなる——AIコーディングの逆説
2026.06.15執筆者：DigKnow株式会社 CTO 桑原 脩
そのコードは動いています。テストも通り、本番でも問題を起こしていません。では「なぜこの設計なのか」——即答できる人は、チームに何人いるでしょうか。少し前まで、「動くコード」とは「誰かが理解して書いたコード」のことでした。動いていること自体が、理解されていることの証拠だったのです。AIコーディングの普及とともに、この等式が静かに崩れ始めています。動くこととわかることが、別々のものになっていく構造を考えます。
AIが賢くなるほど、人間が読める範囲は狭くなる
ここ数年、私はClaude CodeをはじめとするAIコーディングツールを毎日使っています。賢くなっているのを肌で感じます。雑な指示でも文脈を汲んでくれますし、複数ファイルにまたがる修正も一発で通ります。一年前と比べると、頼める仕事の粒度がまるで違っています。
ただ、賢くなったAIに「もっと大きな仕事」を任せられるようになった分だけ、私の頭が一行ずつ追っているコードの割合は確実に下がっています。「だいたい合ってる」「テストも通った」「マージしよう」——このフローで、一日に流れていくコードの量は明らかに増えました。
ここに、ひとつの非対称が生まれています。AIの能力は伸びていきますが、人間が一日に読み込める情報量は、生物として変わりません。賢いAIに任せれば任せるほど、書かれたコードのうち「私自身が一行ずつ読み込んだ部分」の比率は下がっていきます。これは怠慢の話ではなく、むしろAIを使いこなしている証拠でもあります。問題は、その使いこなしの先で起きている、見えにくい変化のほうにあります。
「だいたい合ってる」が、もっとも危ない
AIがまだ未熟だった時期、出力されたコードに対して人間は懐疑的でした。「変な書き方をしているかもしれない」「動かないかもしれない」と疑いながら、一行ずつ目で追っていたはずです。この疑いの行為そのものが、結果的にコードを「読み込む」ことになっていました。
AIの精度が上がると、この疑いが薄れていきます。出力されたコードは、ほとんどの場合「だいたい合ってる」状態にあります。動きます。テストも通ります。レビューでも問題が見つかりません。だから一行ずつ目で追う必然性が、構造的に減っていきます。
ここで起きているのは、品質の劣化ではありません。むしろ品質は上がっています。劣化しているのは、書かれたコードを「読む」という行為そのものなのです。
「だいたい合ってる」コードは、致命的なバグを生みません。代わりに、誰の頭の中にも完全には入っていないコードを生み出します。書かれた時点では問題を起こしませんが、半年後・一年後に手を入れる必要が出たとき、誰にも答えられない問いを残します。「ここ、なぜこの順序で処理してる？」「この分岐、何のため？」——書いた本人を含めて、誰も即答できません。
AIがダメだったときには、人間がコードを読まざるをえない構造がありました。コードを読ませていたのは、失敗への疑いだったのです。AIが賢くなったことで、その構造が消えてしまいました。理解の機会を奪っているのは、失敗ではなく成功——正しく動くことそのものが、読む理由を消していきます。
抽象度の上がるAIと、下がる人間の触覚
もうひとつ、別の角度から見えてくる現象があります。AIが扱える抽象度が上がるほど、人間がコードに対して持っている「触覚」が、徐々に効かなくなっていくという話です。
少し前のAIは関数単位の生成が中心でした。「この処理を関数にして」と指示すると、その関数だけが返ってきます。人間は受け取った関数を読んで、既存コードに組み込んでいました。組み込む過程で、人間の側にも「この関数がどこで何をしているか」という地図が自然に作られていました。
いまのAIは、もっと大きな単位で動きます。「この機能を実装して」と頼むと、複数ファイルにまたがる変更が一気に返ってきます。動作は確認できます。でも、変更の全体像を頭の中で再構成するコストは、人間側にとっては以前より重くなっています。
組み込みのプロセスがAIに吸収された分、人間が「触覚」を働かせる場面が減ったということです。「なんとなくこの設計はおかしい」「ここに違和感がある」という感覚は、コードを自らの手で組み立てる経験のなかで育ってきました。AIが組み立てを巻き取ると、触覚を鍛える機会も巻き取られていきます。これは特に、若手エンジニアの育成に効いてきます。AIが優秀になればなるほど、その判断力が育つ場が縮小していく——という構図が、ここでも起きています。
「動く」と「理解されている」の距離が、年々開いていく
ここまでの話を整理すると、AIコーディング時代に進行しているのは、こういう変化です。
書かれたコードのうち、「動く」状態にあるものの比率は上がっています。AIが優秀になり、テストも自動化され、CIが整備されるなかで、現場に出てくるコードはどんどん安定していきます。一方で、「人間によって完全に理解されている」状態にあるものの比率は、下がっています。この二つの曲線が、年々離れていきます。
以前は、この二つはほぼ同じカーブを描いていました。動くコードを書くためには、人間がそのコードを理解している必要があったからです。AIコーディング以前の世界では、動作と理解は実質的に同じ意味でした。「動いているのに、誰も理解していない」という状態は、以前なら矛盾だったのです。
AIコーディングが進むと、この二つの曲線は別物になっていきます。「動く」は維持されますが、「理解されている」は維持されません。動くコードほど疑われず、疑われないコードほど読まれない——「動くコードほど理解されなくなる」という逆説は、この等式の崩壊から生まれています。両者の差分は、現場でじわじわと積み上がっていきます。前回の記事で書いた「読める人」の問題は、この差分の長期版でもあります。
逆説が深まり続ける、本当の理由
ここまで読んで、「人間が理解していなくても、AIが理解しているなら、それでいいのではないか」と思う方もいるかもしれません。実際、いま現場で起きているのは、その方向の慣性に近いと感じます。
ただ、AIが「理解している」というとき、その理解はコードの構文と振る舞いを再構成できる、という意味での理解です。「なぜこの設計を選んだか」という、コードの外にある意思決定の経緯までは、AIも持っていません。なぜこのライブラリなのか、なぜこの抽象化なのか——こうした「なぜ」は、コードを読んでも、AIに聞いても、同じように答えが返ってきません。
「AIが理解しているから大丈夫」という安心感が、新しい形のブラックボックス化を生んでいます。整理すると、これはAIが悪いという話ではありません。AIは、求められた仕事を高い精度でこなしているだけなのです。
逆説が深まり続けている理由は、AIの進化に対して、人間側の理解の仕組みがアップデートされていない、というギャップのなかにあります。コードを書くプロセスは、AIによって何度も塗り替えられました。でも、書かれたコードを「誰がどう理解し、どう次の世代に渡すか」という仕組みは、ほとんど変わっていません。レビューも、ドキュメントも、引き継ぎも、AIがなかった時代の方法のまま運用されています。
書く側だけが何倍も加速しているのに、読む側・残す側は据え置きのままです。この不均衡を放置したまま、AIの性能だけがさらに上がっていきます。[AIがコードを10倍速く書く世界]で書いた実装速度と理解速度の乖離は、この逆説の別の言い方でもあります。減っているのは、コードの品質ではありません。コードを「腑に落ちたもの」として理解している人の数なのです。
まとめ
かつて「動くコード」とは「誰かが理解して書いたコード」のことでした。AIコーディングの普及とともに、この等式が崩れ始めています。「だいたい合ってる」コードは疑いを生まず、正しく動くことそのものが読む理由を消していきます。結果として、「動く」コードと「理解されている」コードの曲線は年々離れていきます。逆説を深めているのは、書く側だけが加速し、読む側・残す側の仕組みが取り残されていることにあります。
あなたが先週マージしたコードのうち、ご自身の手で一行ずつ読み込んだものは、何パーセントでしょうか。その比率は、一年前と比べて上がっているでしょうか、それとも下がっているでしょうか。
次回以降、業界特有の構造のなかで仕様がどう揮発していくのかというテーマについて、順を追って掘り下げていきます。