静かに進む、現代のソフトウェアエンジニアの認知的萎縮

出典: The Slow and Quiet Cognitive Atrophy of a Modern Software Engineer

ここ数ヶ月、AIへの依存が人に何をもたらすのかという記事をたくさん読んできました。そのなかで繰り返し出てくるのが「認知的萎縮（cognitive atrophy）」という言葉です。AIに頼りすぎるうちに、自分の技術が少しずつ錆びついていく。そういう話です。

多くの指摘に共通していたのは、問題を自分の手で解かなくなるという一点でした。エンジニアはまずAIに「どうすればいい？」と聞いてしまう。考えるという、いちばん大事な工程をまるごと飛ばしてしまうわけです。

この記事の冒頭にブリューゲルの《盲人の寓話》（1568年）を掲げたのは、そのためです。先頭の盲人に導かれた盲人たちが、列をなしたまま次々と転んでいく絵。数百年前に描かれた光景が、いまの私たちにそのまま重なります。違うのは一点だけ。私たちは、自分から目をつぶっているということです。

プロンプト → 承認 → 繰り返し

この流れにレビューがないことに気づいたでしょうか。そこが問題です。

「これくらいの小さな変更なら別にいいだろう」と思うかもしれません。けれどその小さな変更を何度も何度も繰り返していくうちに、それは確実に積み上がっていきます。長い目で見れば、AIなしではもうコードが書けない自分に、いつか気づくことになります。

私たちは、生成されたコードを意図的に見なくなっているのです。

AIの書くコードはきれいで、同時によくできた嘘でもあります。UIは整っていて、テストも通る。そのテストもAIが書いたものですが。コードベース全体が虹と太陽でできているような気分になります。そのまま承認して次へ進みたくなるのも無理はありません。でも、私たちはその程度の存在ではないはずです。

スキルが鈍るのはこの業界に限った話ではありません。使わない技能はどんなものでも衰えます。人に指示を出すほうが、自分でやるよりずっと簡単です。そして指示を出すことと、実際に手を動かすことは、まったく別の行為です。

自分で実装すると、脳が強制的に動き出します。エッジケースが見えてくる。UXについて考えるようになる。どのテストに意味があるかを判断するようになる。どのコードが重要かが分かるようになる。自分でやることの価値はここにあります。AIは繰り返し作業の補助として使えばいい。思考そのものを丸ごと外注してしまうのとは、話がまったく違います。

もちろん、人間の書いたコードが完璧だという話ではありません。大半の私たちは天才プログラマーではないし、人間ならではのミスも混じります。でも、だからこそ価値があるのです。

そこには人間がついているからです。

誰かがその判断を引き受けていて、責任の所在がはっきりしていて、文脈を持っている。問題が起きたとき、その人はゼロから始めるわけではありません。自分で建てたものなら、自分で直せます。悩んで、間違った前提を置いて、それでも最後に答えにたどり着く。この過程こそが本当の理解をつくります。次に同じ問題にぶつかったとき、今度は一人で解ける可能性が高い。結果として速くなるのです。

AIは学ぶために使い、自分の穴をあえて暴かせる道具にする。疑い、吟味し、検証しながら使う。思考そのものを手放さずにAIと付き合うには、そのほうがずっと健全です。すべてを委ねてしまうなら、自分はAIのためにタブキーを押すロボットだと宣言したほうが早いでしょう。

盲信はドミノを倒す

レビューされていないAI生成コードがPRとして出された瞬間、ドミノが倒れはじめます。ジュニアはAIを信じ、シニアはジュニアを信じ、やがてそのコードは本番環境に届きます。これは認知的萎縮を招くだけでなく、偽の信頼まで生み出します。

どうして私たちは、ここまで来てしまったのでしょうか。

速さは、コードの質を測る物差しだったことは一度もありません。コードベースはもろいものです。昔からずっとそうでした。たった一つの誤った実装が、無数のエラーを呼び込みます。

AIは、見事に説得力のあるコードを並べてみせます。書いた本人は、それを理解しないまま「動く」という錯覚にとらわれる。コードがpushされた時点で、文脈はもう失われています。目を通して成功率を上げる代わりに、動くことに賭けているだけです。

シニアは「この変更は妥当か」を考える前に、「この人はそもそも自分が送ったものを理解しているのか」「そもそも読んだのか」と疑うことになります。

1000行を超えるスロップを、好きこのんで読む人がいるでしょうか。

AI生成コードを読むのを避ける態度は伝染します。レビュアーのほうも面倒になって、中身を見ないまま承認してしまう。

人間とはそういうものです。一度に大量の変更が持ち込まれれば、品質チェックは均一には働きません。全部飛ばすか、重要そうなところだけ拾い読みするか、さらに悪ければAIレビューエージェントに丸投げするか。不確実性が重なっていくだけです。

AIは優秀です。ただし補完として使うかぎりにおいてです。代替ではありません。正しく、責任を持って使う道具です。全員にこのやり方を強制することはできませんが、自分から始めることはいつでもできます。送る前に読む。PRを理解する。意図を持ってpushする。

目指すべきは、PRを「レビューできる状態」にすることです。完璧である必要はありません。大事なのは、それが自分のものであり、レビュアーに聞かれたとき即座に説明できることです。コードの隅々まで語れて、最後に「なぜ？」に答えられること。

その次に、もう一組の目が入ります。磨きをかけ、細かい（あるいは大きな）修正を入れ、リファクタリングを求める。変更について議論することで、文脈は自然にチームへ伝わっていきます。

うまくいけば、周りもいずれついてきます。ついてこなくても、少なくとも自分は認知的萎縮から逃れられます。

人の頭は、挑まれないと鈍る

認知的萎縮に抗うには、意識して頭に負荷をかける方法を見つけるしかありません。いまのワークフローだけでは足りない、とデータは示しています。脳は運動させる必要があります。

私がやっているのは、毎日最低ひとつコーディング課題を解き、その様子を録画し、誰かに教えるつもりで思考過程を声に出して説明することです。カメラに向かって喋りながら画面を映しているだけの動画が、いまはひとつのフォルダに溜まっています。

これは自分の穴をさらけ出す作業で、私はそこが気に入っています。録画を見返すと、詰まっている箇所や、説明の途中で言葉が止まっている箇所がはっきり分かります。間違いや沈黙は、いまの自分の実力がどのあたりかを容赦なく突きつけてきます。でもこの仕組みの何よりいいところは、改善の対象が目に見える形で残り、そのあいだ脳が働き続け、新しい結びつきが生まれていくことです。

効果は、はっきり出ました。

最初の録画と今の自分の説明を比べると、明らかに切れ味が増していて、使っている言語や概念への理解も深くなっています。比較できる形が残っているのがいいのです。ゲームと同じで、キャラクターのステータスが伸びていくのが見えると、もっと積みたくなります。

コーディング課題のほかに、自分の仕事をベストプラクティスや実装手法と突き合わせて点検することも習慣にしています。まずは自分でドキュメントや実例、別のアプローチをネットで探す。自分なりの考えがまとまってから、AIにぶつけて理解を一段深める。この順番です。

AIが非推奨のメソッドを提案してきたこともあります。

事前に自分で調べていなければ、まず気づけなかったでしょう。指摘したときのAIの返事はこうでした。

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

ああ、やっぱり当てにならないな、と思った瞬間でした。

当たるときは当たるし、外すときは外す。そして前提知識がないほど、外したことに気づけません。そもそも彼ら自身が、プロンプトを打ち込む前から「間違えることがあります」と画面の下に表示しているわけです。

ここに書いたのはあくまで私に合ったやり方で、あなたには別のやり方があるはずです。大事なのは、頭を鈍らせない程度の負荷をかけ続けることです。

認知的萎縮は、思考を外注すると決めたその瞬間から忍び寄ってきます。そして気づくのは、AIなしでは以前のようにコードが書けなくなった自分を見つけたときです。

規律は、究極の自己尊重である

偽善者になるつもりはないので正直に書きます。AI生成コードを一度も使ったことがない、なんてことはありません。使いました。そして、好きになれませんでした。

localhostを開いたら、バグに出迎えられました。腹が立ったのはバグそのものではありません。どこを見ればいいのか分からないことでした。

無力感と、当事者意識のなさ。それが全部を覆っていました。

そのコードを書いたのは私ではなく、AIです。だからまたプロンプトを投げました。返ってきたのは、先に確認すべき項目が3つから5つ。消耗しました。このやり方は私には向いていません。それでも直らないと、また別の確認項目と修正案のリストが出てきて、要するに新しい解決策を延々と生成し続けるだけでした。

経験が足りないのだとか、プロンプトが悪いのだとか、アーキテクチャや文脈を書いたマークダウンを用意していないからだ、と言われれば、それはそのとおりかもしれません。

でも、「動く」コードをAIに書かせるためにそこまでやる気があるのなら、最初から自分で書けばいいのではないでしょうか。

いいよ、自分でやる。そう思って、やりました。

デバッグして、やり直して、調べて、直して、壊して、また直して、必要だったコンポーネントを作り上げるまで15〜30分。苦労はありました。でもそれは、前に進んでいると分かる種類の苦労でした。感覚としては、実際に梯子を登っているのに近い。手応えがあるのです。

そして何より、始める前より自分が賢くなっていました。コードは自分のもの。間違いも自分のもの。解決策も自分のもの。最後に残った理解は、ちゃんと身体に残るものでした。

このやり方における唯一の敵は、自分の規律です。

以前、こんな言葉を読みました。「規律は究極の自己尊重である」。読んだ瞬間に引っかかって、ずっと頭に残っています。ここにもそのまま当てはまると思います。

コードを生成することが日に日に簡単になっていく世界では、近道をせずに学び続ける規律そのものが武器になります。どんな営みにも基礎は必ずあります。規律をもってそこに投資することが、自分への敬意になり、やがて周りのエンジニアからの敬意にもなっていきます。

目を開けよう

答えは単純です。

認知的萎縮に抗うには、自分の頭でもっと考えること。頭を使えば使うほど、苦労して身につけた技術は残ります。

AIを捨てろと言っているのではありません。それこそ、せっかくの資源の無駄遣いです。言いたいのは、責任を持って使おう、ということです。思考を置き換えるものではなく、思考をさらに引き上げる道具であり補助として使う。

AIは強力ですが、ソフトウェアづくりのあらゆる判断を明け渡していい相手ではありません。それは認知的萎縮への直行便です。AIは、使う側のエンジニアの良い習慣も悪い習慣も同じように増幅します。どんな道具とも同じで、使い方を誤れば出てくるものはいずれ歪みます。

結局のところ、質を大事にし続ける新しい世代のエンジニアでいましょう。完璧で、しかも速く出す必要はありません。大事なのは、それが自分のものであること。説明できること。何かあったときに自分で直せること。そして、自分なりのやり方で伸び続けていること。便利さを、思考を手放す言い訳にしないでください。

だから、目を開けましょう。

---