AIがコードを書くこと自体は、もう珍しい話ではなくなった。
GitHub Copilot、Claude Code、Codex、ChatGPT。
名前を挙げ始めればきりがないし、どれが優れているかという話も、もはや本質ではない。
重要なのは、「AIが実装に関与する」という前提が、すでに日常になってしまったという事実だ。
この状況で、決まって聞こえてくる言葉がある。
AIに実装を任せると、実装力が落ちる。
直感的には理解できる。
実際、以前ほど自分の手でコードを書かなくなった、という感覚を持つ人も多いだろう。
だが、この言葉を聞くたびに、どうしても引っかかるものがあった。
それは、「実装力」という言葉があまりにも曖昧なまま使われている、という違和感だ。
実装力とは、いったい何なのか。
そして、AIに実装を任せることで、本当に失われている能力はどれなのか。
それを分解せずに語られる実装力低下論は、どうにも雑に感じられた。
「実装力」という言葉が議論を壊す
実装力という言葉は、とても便利だ。
便利すぎるがゆえに、思考を止める。
コードを書く速さも、設計力も、バグを潰す能力も、経験から来る勘も、すべてを一つの言葉に押し込めてしまう。
結果として、「実装力が落ちる」という一言で、複雑な変化がまとめて処理される。
だが、実装という行為は、そんな単純なものではない。
実装とは、仕様を理解し、それを構造に落とし込み、コードとして表現し、動かし、壊し、直し、将来の変更に耐える形に整えるまでの一連の営みだ。
その中には、性質の異なる能力がいくつも絡み合っている。
それらを分解せずに「実装力が落ちた」と言うのは、運動をしなくなった人に対して「体力が落ちた」と言うのと同じだ。
体力と一言で言っても、筋力もあれば、心肺機能もあり、柔軟性もある。
どれが落ちたのかを言わなければ、対策のしようがない。
実装という行為を冷静に分解する
そこでまず、実装という行為を、できるだけ感情を排して分解してみる。
仕様を正確に理解する力。
それをどういう構造で表現するかを考える設計力。
頭の中の処理を、コードとして書き下す力。
動かしてみて、ズレやバグを見つけて修正する力。
そして、将来の変更や拡張に耐えられる形を作る構造設計力。
これらは互いに関連してはいるが、同一の能力ではない。
AIに実装を任せたとき、それぞれに起きる変化も、同じではない。
仕様理解は、むしろ誤魔化しが効かなくなる
まず、仕様を理解する力について考える。
AIに実装を任せると、この能力が落ちると思われがちだが、実際は逆に近い。
AIは、曖昧な仕様をそのまま受け取ってくれない。
入力は何か。
出力はどうあるべきか。
どこまでが正常系で、どこからが例外なのか。
前提条件は何か。
これらを言語化しなければ、AIは平然と「それらしく動く何か」を出してくる。
その結果、仕様をきちんと理解していない側が、AIの出力に振り回される。
人間同士なら、「察してくれる」ことがある。
だがAIは察しない。
察しないからこそ、理解していない部分が露呈する。
仕様理解が甘いまま実装していた人ほど、AI時代には苦しくなる。
逆に言えば、AIは仕様理解の甘さを隠させてくれない存在だ。
設計は、結局人間の仕事から逃れられない
設計についても、同じことが言える。
AIは、与えられた前提の中でコードを書くことはできる。
だが、どこに責務の境界を引くか、どの変更を将来許容するか、といった判断は、前提そのものを決める行為だ。
その前提は、プロダクトの文脈やチームの事情、技術的制約の中で決まる。
これをAIに丸投げすることはできない。
むしろ、AIに実装を任せるほど、「どこまでをAIに任せ、どこからを人間が決めるのか」という設計判断の重要性は増す。
設計が衰えるどころか、逃げ場がなくなる。
確実に鈍るのは「即座に書く力」
ここでようやく、「確実に衰える能力」に話が及ぶ。
それは、思考を即座にコードに変換する力だ。
頭の中で処理を組み立て、それをほとんど無意識のままコードとして書き下す。
IDEと指が一体化しているような感覚。
この即応力は、使わなければ確実に鈍る。
AIが代わりにコードを書いてくれるなら、自分で書く必要は減る。
必要が減れば、筋肉と同じで衰える。
ただし、重要なのは、これが「消える能力」ではないという点だ。
久しぶりに自転車に乗るとふらつくが、少し走れば思い出す。
それと同じで、書く力は鈍るが、失われるわけではない。
デバッグと違和感は、ますます人間の領域になる
一方で、AI時代に重要性が増す能力もある。
それが、デバッグや調整、そして「違和感」を感じ取る力だ。
AIが書くコードは、動くことが多い。
テストも通ることがある。
だが、どこか気持ち悪い。
この気持ち悪さは、仕様と実装、構造と振る舞いのズレから生まれる。
それを感じ取れるかどうかは、人間側の理解にかかっている。
AIは動くコードを書く。
動くが、正しいとは限らない。
その差分を埋める役割は、結局人間に残る。
構造の責任は、最後まで人間が負う
構造についても同じだ。
このコードは、来月の変更に耐えられるか。
半年後に読んだとき、理解できるか。
責務は分離されているか。
AIは、そこまでの未来を見ない。
見ないというより、見せられていない。
構造が将来どう壊れるかを想像し、その責任を引き受けるのは、最終的に人間しかいない。
本当に衰える能力の正体
ここまでを冷静に見れば、結論はそれほど複雑ではない。
AIに実装を任せることで本当に衰えるのは、
思考を即座にコードへ落とす反射的な書く力だ。
それ以外の能力は、衰えるというより、誤魔化しが効かなくなるか、要求水準が上がる。
AIによって伸びる能力がある
そして、見落とされがちだが重要なのは、AIを使うことで確実に伸びる能力があるという事実だ。
自分が書いていないコードを読む機会が増えることで、レビュー視点が鍛えられる。
設計を言語化しなければAIが動かないため、考えを言葉にする力も鍛えられる。
AIは、思考を曖昧なままにしておくことを許さない。
本当に危険なのは「分からないまま動く」状態
AI時代における最大のリスクは、
なぜ動いているのか分からないまま、コードが動いている状態だ。
この状態に陥ると、障害対応ができない。
改修が怖くなる。
技術的負債を負債として認識できなくなる。
AIが危険なのではない。
理解しないまま使うことが危険なのだ。
結論：奪われるのではなく、再配分される
AIはエンジニアの能力を奪う存在ではない。
能力の配分を、強制的に変える存在だ。
手を動かす時間は減り、
考える責任と説明責任は増える。
その変化を理解せずに使えば、確かに危険だ。
だが、理解した上で使えば、これほど強力な道具はない。
「実装力が落ちる」という雑な言葉で思考を止めるのではなく、
どの能力がどう変わっているのかを、冷静に見極めること。
それが、AI時代における最低限の知性だと思っている。
コメント