GUIDE ／ 学習の意思決定 ／ 更新 2026-10-04
なぜ『動くコード』より『読めるコード』の価値が上がるのか
「読みやすいコードを書きましょう」という助言は、もう聞き飽きたほど当たり前になっている。だからこの記事は、その当たり前をもう一段掘り直すところから始めたい。問うべきは「読みやすいコードはなぜ大事か」ではなく、「なぜ今、その価値がこれまでより上がっているのか」のほうだ。昔から大事だったはずのものが、なぜ急に高く取引されるようになったのか。答えは、コードという商品の性質そのものが、AIによって二つに裂かれ始めたことにある。
「動く」と「読める」は、もともと別の性質だった
長らく、「動くコード」と「読めるコード」はほとんど同じものとして扱われてきた。両方を人間が自分の手で書く限り、動くコードを書くのに必要な手間と、読めるコードを書くのに必要な手間が、そこまで大きく離れていなかったからだ。変数名を考え、処理の単位を関数に切り、意図をコメントに残す作業は、動くようにするための試行錯誤とほぼ地続きで発生する。だから「まず動けば十分、読みやすさは余力があれば」という優先順位が現場の体感とずれなかったし、「動くコードを書ける人は、だいたい読めるコードも書ける」という経験則も、おおむね成立していた。
ところがAIが「動く」を書く部分を引き受け始めると、この地続きの関係が切れる。AIにとって、要件を満たして一応動くコードを生成する限界費用(ある生産物をもう一つ追加で作るときにかかる追加コスト)は、ほぼゼロに近づいていく。人間が一行ずつ試行錯誤して到達していた「動く」という状態に、AIは一瞬で到達できてしまう。すると、「動く」と「読める」が同じコストで手に入るという、これまで暗黙に信じていた前提そのものが崩れる。動くことは安くなり、読めることだけが高いまま取り残される。二つはもともと別の性質だったのに、人間が両方を一人で背負っていたせいで、同じ値段に見えていただけなのだ。
読みやすさは「読む人」のためではなく「書き換える人」のための入り口
ここで、読みやすさという言葉の意味を一度置き直したい。読みやすいコードというと、つい「読む人にやさしい」という意味で捉えてしまうが、それは半分しか当たっていない。読みやすさの本質的な役割は、鑑賞のためではなく、後から誰か(人間でもAIでも構わない)がそのコードにもう一度入り込み、安全に変更を加えるための入り口を用意することにある。これを「再突入性」と呼んでおく。変数の意図が読み取れ、処理の境界がはっきりしていて、依存関係が追いやすいコードは、半年後にそこへ戻ってきた別の誰かが、全体を壊さずに一部だけを直せる状態を保っている。逆に、動くことだけを目的に書かれたコードは、今は正しく動いていても、次に誰かが手を入れようとした瞬間、何がどこに影響するのか分からず、変更そのものが事故になりやすい。これは一般に技術的負債(将来の変更コストを前借りして、今の実装を早く終わらせた分のしわ寄せ)と呼ばれる状態でもある。入りやすさこそが読みやすさの生む本当の価値であり、見た目の美しさとはあまり関係がない。
動くコードは在庫、読めるコードはオプションである
この違いは、別の比喩で言い換えるとさらに見通しがよくなる。動くコードは、作った瞬間から価値を持つが、要件が変わればすぐに古びていく「在庫」に近い。今日の仕様を満たしているだけの在庫は、仕様が変わった瞬間にただの死蔵品になる。一方、読めるコード、つまり再突入性の高いコードは、「将来必要になったときに安く変更できる権利」そのものであり、金融でいうオプション(将来の一定の条件で売買できる権利。行使しなくても、権利そのものに価値がある)の性質に近い。オプションの価値は、実際に使われなくても消えない。むしろ、将来どれだけ頻繁に条件が変わりそうかによって、その権利の価値は上下する。変更がもう一度も起きないなら、再突入性への投資はほとんど無駄になる。だが変更が何度も、しかも予測できないタイミングで起きるなら、そのたびに安全に入り直せる状態を先に用意しておいたことの価値は跳ね上がる。
AIが上げているのは「動く」の供給量ではなく、変更の頻度
ここでAIの役割を正しく位置づけ直すと、AIがもたらす最大の変化は、単に「動くコードを安く量産できるようになった」ことではない。その安さが、プロトタイプを試す回数、やり直す回数、仕様を変える回数そのものを増やしているという点にある。これまでは一度書いたコードを捨てて作り直すコストが高かったから、仕様変更はできるだけまとめて行う運用が合理的だった。動くコードが限界費用ほぼゼロで手に入る環境では、試して捨てて、また試すイテレーション(小さな変更を繰り返す反復のサイクル)の回転数そのものが上がる。オプションの価値が「将来どれだけ条件変化が起きそうか」で決まるのだとすれば、イテレーションの回転数が上がるほど、再突入しやすいコードに払うべき割増価値(プレミアム)は大きくなる一方になる。動くコードが安くなったことと、読めるコードが高くなったことは、同じ一つの変化の裏表にすぎない。
時間を投じる基準は「何度突入し直されるか」
ここまでの整理を、自分の時間の使い方に落とすなら、判断基準は一つに絞れる。今自分が書いているコード、あるいは今AIに書かせているコードに対して、「将来もう一度、自分や誰かが安全に入り直せるか」を問うことだ。動くかどうかはAIが担保してくれる場面がこれから増えていくが、再突入できるかどうかは、そうはならない。命名や構造の整理に時間を割くかどうか迷ったときは、「このコードは、この先何度変更され得るか」で考えればいい。ほぼ変更が起きない使い捨てのコードに再突入性を求めるのは過剰投資だが、長く変更され続けることが分かっているコードでそれを省くのは、将来の自分やチームから、安く変更できる権利をあらかじめ奪っていることになる。「動く」をどれだけAIに任せられるようになっても、「安く入り直せる」を設計しておく仕事は、人の側に残り続ける。
tasklogは、こうした「何を学び、どこに時間を割くべきか」を考えるときの手がかりとして、実際に読まれ、引用されている技術書や学び方の記事を集めて置いている場所だ。保守性や設計の考え方に関する本を探すときも、数字は自分の目で確かめてみてほしい。