現代のソフトウェアエンジニアに静かに訪れる、ゆっくりとした認知の退化

ここ数か月、AI への依存がもたらす帰結について書かれた記事をずいぶん読んだ。その中で繰り返し出てきた発見が認知の退化だ。要するに、AI に頼りすぎることで、気づかないうちにスキルが衰えていくということ。

こうした振り返りの多くは、問題を直接解こうとしないことを指している。ソフトウェアエンジニアは、自分で案を考える前に、反射的に AI へやり方を尋ねる。これは思考という決定的なプロセスを飛ばしているということだ。上のアイキャッチ画像にこれを選んだのも、主にそれが理由だった。ピーテル・ブリューゲル『盲人引盲』（1568年）。

絵の中では、盲人の一団が、同じく見えない人物に導かれて歩き、最後には次々と倒れていく。何百年も前に描かれたこの絵は、今の世界をそのまま映している。唯一違うのは、_私たちが自ら進んで目を潰している_ということだけだ。

プロンプト > 受け入れる > 繰り返す

この流れにレビューの工程がないことに注目してほしい。そこが問題なのだ。このワークフローを問題ないと思うかもしれない。_「小さな変更だし、心配するようなものじゃない」_と言うかもしれない。それを何度も何度も繰り返すうちに、こうした 「小さな変更」 が積み上がっていく。長い目で見れば、AI なしではもう 「コードが書けなくなっている」 自分に気づくはずだ。

私たちは、生成されたコードに目を向けないことを、意図的に選んでいる。

そっぽを向く猿。

AI が生成したコードはきれいで、そして人を欺く。UI は良さそうに見えるし、テスト（これも AI が生成したものだ）も通る。コードベースのすべてが虹と太陽でできているかのようだ。エンジニアが変更を受け入れて、そのまま先へ進んでしまうのも無理はない。だが、それでいいはずがない。

スキルの退化はこの業界に限った話ではない。頻繁に使わなければ、どんなスキルもいずれ衰える。どうやるかを_口で指示する_ほうが、自分で_実際にやる_よりいつも簡単だ。そして多くの場合、人に指示することと、実際にそれを実装することは別物だ。

自分で手を動かしてタスクをこなせば、脳は否応なく考える。本当のエッジケースが見えてくる。UX についてもっと考えるようになる。どのテストに意味があるかも考える。コードのどこがより重要かも見えてくる。これこそ、自分の手を動かし、AI を反復作業の補助として使うことの価値だ。思考のすべてを AI に外注してしまえば、話はまったく別になる。

もちろん、人間が書いたコードも完璧ではないと言うことはできる。私たちのほとんどは_天才プログラマー_ではない。書くコードには_人の誤り_がつきものだ。だが、まさにそこが、それがすでに十分に価値を持つ主な理由でもある。

その背後には人がいる。

すでに責任を負う人がいる。すでに説明責任を負う人がいる。すでに文脈を握っている人がいる。何か問題が起きたとき、その人はゼロからではなく、すでに土台を持っている。コードはそもそも彼が作ったものだから、直すこともできる。もがき、誤った前提を置き、それでも正しい解にたどり着く——この過程こそが、本当に理解するための道だ。次に同じ問題にぶつかれば、今度は自分で解ける可能性が高く、効率も上がる。

AI を学習に使い、あえて自分の穴を露呈させる。疑い、吟味する。挑みながら検証する。これははるかに健全な AI の使い方で、思考のプロセスそのものを手放さずに済む。だが、仕事のすべてを AI に委ねるつもりなら、自分は AI のために Tab キーを押すロボットだと宣言したほうがいい。

盲信がドミノを倒す

レビューされていない AI 生成コードが PR レビューに上げられると、ドミノが倒れ始める。ジュニアエンジニアは AI を信じ、シニアエンジニアはジュニアエンジニアを信じ、コードはやがて本番環境に入る。これが生むのは認知の退化だけではない。偽りの信頼感も生み出す。

AI 生成コードを受け入れるときのドミノ効果。

どうしてここまで来てしまったのか。

速度は、コードの品質を測る最良の基準では決してなかった。コードベースは脆い。ずっと脆かった。一つの誤った実装が、連鎖的な誤りを引き起こす。

AI が書くコードは、完璧なまでに説得力がある。書いた本人は一瞥しただけで、「動く」という錯覚に陥り、それを本当には理解しない。この新しいコードが上げられた瞬間、文脈はすでに失われている。_実際に目を通す_ことで成功の確率を意図的に高めるのではなく、最初から動くことに賭けているのだ。

シニアエンジニアがまず考えるのは、この変更が良いかどうかではなく、ジュニアエンジニアが自分が何を提出したのかを分かっているか（そもそもこのコードを読んだのか）かもしれない。

千行を超えるゴミを読むのが好きな人なんているか？

AI 生成コードを読むことは_伝染する_。レビュアー自身も怠け、目を通さずに変更を受け入れてしまう。

結局これは人の本性だ。一度に持ち込まれる変更が多すぎれば、品質チェックを均等に続けることはできない。レビュアーは変更全体をざっと流し読みし、要点だけを見るよう誘惑される。さらに悪ければ、その上で AI レビューエージェントにも頼る。そこにまた一層の不確実性が加わる。

AI はとても便利だが、それはあくまで_補完_としてであって、_代替_としてではない。正しく、責任をもって使うべき道具だ。このワークフローを全員に強制することはできないが、自分から始めることはできる。送り出す前に読み、PR を理解し、意識をもって push する。

要点は、自分の PR を_「レビューされる準備ができた状態」にすることだ。完璧である必要はない。最も大事なのは_それが自分のものである_ことで、レビュアーに問われればすぐに擁護できる。コードの経緯を説明でき、最終的にはあの問いに答えられる。「なぜ？」_

次のステップは、別の誰かの目を自分のコードに通してもらうことだ。少し磨き、小さな（あるいは大きな）修正を加え、あるいはさらなるリファクタリングを求める。変更について議論するこのプロセスそのものが、チームメンバーへ文脈を_自然に引き継ぐ_方法なのだ。

正しくやれば、いずれ周りも追いついてくる。間違っていても、少なくとも自分を認知退化から救い出せる。

人の脳には挑戦が必要だ

認知退化に対抗するには、自分の脳に挑戦する方法を考えなければならない。データが示しているのは、今のワークフローでは足りないということだ。脳を鍛える必要がある。

個人的には、毎日少なくとも1問プログラミングの問題を解き、それを録画し、誰かに解き方を教えるように一歩ずつ自分の思考を説明している。以下は今までに録った動画の一部で、カメラに向かって話し、画面を見せているだけのものだ。

プログラミング問題のフォルダ。

これは自分の穴を露呈させる。そして僕はそれが気に入っている。録画を見返すたび、自分が詰まった箇所や説明が止まった箇所にすぐ気づく。ミスや沈黙は、いつも今の実際の実力を現実に引き戻してくれる。だがこのやり方の一番いいところは、具体的に改善できる対象を与えてくれると同時に、脳を活発に保ち、新しい接続を作らせてくれることだ。

明らかな進歩が見える。

一番初期の録画と今の説明の仕方を比べると、自分がより鋭くなり、使っている言語や概念への理解も深まったことがわかる。これは本物の比較材料になるし、僕は個人的にこちらの方が好きだ。ゲームと同じで、キャラクターの数値が時間とともに上がっていくのを見ると、練習を続ける意欲が湧く。

プログラミングの問題だけでなく、自分の作品も必ず見直し、ベストプラクティスと手法を何度も確認する。まずネットでドキュメントやサンプル、さまざまなやり方を探すのが役に立つとわかった。_自分なりの考え_を固めたあとで、AIを使って知識を補い、そのテーマへの理解を深める。

AIがすでに廃止された方法を勧めてきたことも、何度かあった。

こういうのは、事前に自分でそのテーマを調べていなければ気づけない。そして僕が指摘したとき、AIの答えはこうだった。

「おっしゃる通りです！」

そう……AIがどれだけ_頼りにならない_かに気づいたのはそのときだ。

当たることもあれば外れることもある。あるテーマについて最初ほとんど何も知らなければ、問題を見落とす可能性はもっと高くなる。つまり、こちらのプロンプトを打つ前に、彼ら自身がそう言っているのだ。

「間違えることがあります」と書かれたChatGPTの注意ラベル。

とはいえ、全体としてこれは僕に効いたやり方で、君には合わないかもしれない。大事なのは、脳が鋭さを保てる程度に、挑戦し続けているかどうかだ。

認知退化は、思考を外注すると決めた瞬間に静かに入り込んでくる。AIの助けがなければ以前のようにコードが書けなくなっていると気づいたとき、初めてそれに気づく。

自律は自尊心の究極の形だ

そう、AIが生成したコードを一度も試したことがないなんて、偽善的なことは言わない。試したし、気に入らなかった。localhostを開くと、いくつものバグが待ち構えていた。

イライラしたのはバグそのものではない。本当の問題は、どこから見ればいいのかまったくわからなかったことだ。

あの無力感、「これは自分のものではない」という感覚は、息が詰まるほどだった。

コードは僕が書いたのではなく、AIが書いた。だから続けて、もう一度プロンプトを試した。返ってきたのは三つから五つほどの事前チェック項目で、問題を解決するにはまずそれを検証しなければならない。_面倒すぎる。_このワークフローは僕には合わない。バグが直らないままだと、また新しい事前チェックと修正案のリストが出てくる。要するに、別の案を何度も何度も再生成しているだけだ。

AI生成コードのループを示す図。

プロンプトの書き方が悪い、アーキテクチャやその他のコンテキストを説明する正しいmarkdownファイルを渡していない、経験が足りないだけだと言うかもしれない。それはもっともだ。

だが、AIのコードを 「動く」 ようにするためにそこまで手間をかける気があるなら、自分でコードを書いたほうがいい。

よし、自分でやる。そしてやった。

15分から30分ほどかけて、デバッグし、試行錯誤し、学び、直し、壊し、また直して、必要なコンポーネントを作った。その過程には苦労があったが、前に進んでいるとわかる種類の苦労だった。本物のはしごを登っているような感覚だ。苦労が手触りとしてある。

さらに大事なのは、以前より多くを理解できたことだ。僕のコードは僕のものだ。僕のミスは僕のものだ。僕の解法は僕のものだ。そして最後に得た理解は残る。

この仕組みの中で、僕の唯一の敵は自分の自律だ。

自律についてこんな言葉を読んだことがある。「自律は自尊心の究極の形だ。」 読んだ瞬間に心に残ったし、ここに当てはめるのがぴったりだと思う。

コードを生成するのが日ごとに簡単になっていく世界で、手を抜かずに学べるという自律は_超能力_だ。基礎は、僕たちが関わるあらゆる物事の中に現れる。本物の自律をもって基礎に取り組めば、そこから自尊心を得られ、最終的には周りのエンジニアからの敬意も得られる。

目を開け

答えはシンプルだ。

認知退化に対抗するには、もっと自分で考えるべきだ。脳を鍛えるほど、苦労して築いたスキルを保てる。

AIを完全に捨てろと言っているわけではない。それは手元にある資源を無駄にするだけだ。言っているのは、責任をもってAIを使うことだ。道具として、補助として使い、思考を一段上に引き上げるのであって、置き換えるのではない。

AIは強力だが、ソフトウェアを作る過程のあらゆる判断を任せるほど強力ではない。それは認知退化への直通切符を自分に買うようなものだ。忘れないでほしい。AIは操作するエンジニアの良い習慣も悪い習慣も増幅する。どんな道具と同じで、使い方を間違えれば、最終的にアウトプットはおかしな方向へずれていく。

要するに、新しい世代のソフトウェアエンジニアの一人になろう、ということだ。品質をまだ気にかけている世代の。完璧である必要はないし、爆速で届ける必要もない。大事なのは、それが自分のものであること、自分の言葉で説明できること、壊れたときに自分で直せること、そして最終的には自分自身が成長し続けていることだ。便利さを、思考を外注する口実にするな。

だから目を開け。

『アベンジャーズ：ドゥームズデイ』でサイクロップスが目を開き、画面いっぱいに赤いレーザーを放つ。

ここまで読んでくれてありがとう。思ったより長くなってしまった。最後の画像は『アベンジャーズ：ドゥームズデイ』の予告編から、土壇場で入れることにしたものだ。締めに合うと思った。では。