はじめに
「なんでここでこの型を使ってるの？」
同僚にそう聞かれたとき、自分の口から出たのは「一旦調べさせてください」だった。実装を担当しているのは自分なのに、その場でパッと説明できない。動いている。テストも通っている。でも、なぜそう書いたのかと聞かれると言葉に詰まる。AIコーディングツールが普及してから、AIによる実装が増えてきた弊害が少しずつ表れ始めている。
AIコーディングツールを使い始めてから、生産性は明らかに上がっていた。新しいライブラリの導入も、エラーの解消も、以前なら半日かかっていた作業が数十分で終わる。そしてそれは事実ではある。ただ自分が「コードを書けるエンジニア」ではなく、「コードをAIに生成してもらって書けている気がするエンジニア」 になりつつあることに気づいた。
「分かったつもり」はなぜ起きるのか
振り返ってみると自分の場合、主に以下の4つの要因が重なっていた。
-
コンテキスト不足
使っているライブラリの設計思想や、そのツールがなぜそのAPIデザインを採用しているのかを理解しないまま、AIに質問して要件定義に沿って作ってもらっている。表面的には動くエラーもないが、根本的な理解が伴っていない。 -
「動く＝正しい」の誤認
エラーが出ない、テストが通る。それだけで「理解できている」と錯覚していた。しかし、エラーが出ないことと、なぜその実装が正しいのかを説明できることは全く別の話。 -
思考の外注
本来のエンジニアリングとして新しい機能を実装するとき「どういう設計にしよう」「このデータフローならどのパターンが合うだろう」と、まずその人自身の頭で考えていたのであろう。ところがAIを使い始めてからは、その工程がまるごと「AIにissueを渡して、計画を立てさせて、ルールを参照させて実装形式を統一させる」という流れに置き換わっていた。
自分がやっているのは設計判断ではなく、AIが上手く動くための環境整備になっていた。問題の分解や設計判断といった、実務経験を通じて本来身につけるべきスキルを、気づかないうちにAIに委ねてしまっていたのだ。
- 振り返りの時間を取らない
これが実務では一番大きい要因かもしれない。業務には期限がある。「動いたならOK」で次のタスクに進み、自分が書いたコードを振り返る時間を確保しない。納期がある中で、理解を深めるための時間は意識的に作らないと永遠に生まれない。結果として「なんとなく動いている」コードをなんとなくわかっているつもりで、自分自身のスキルとして身につかない。
海外でも同じ議論がされている
この問題意識を持っているのは自分だけではなかった。海外でも同じテーマが研究・議論されている。
Anthropicの実験：AI利用者はスコアが17ポイント低かった
InfoWorldの記事では、Anthropicの研究チームが52人のジュニア開発者を対象に行った実験が紹介されている。
実験では、開発者を「AI使用グループ」と「AI不使用グループ」に分け、未経験のPythonライブラリを使った課題に取り組ませた後、理解度テストを実施した。結果、AI使用グループはAI不使用グループよりテストスコアが17ポイント低かった。 特にデバッグやコードの読解力において大きな差が出ていた。
興味深いのは、AI利用者自身がその状態を自覚していた点だ。彼らは「怠けてしまった」「理解にまだ多くのギャップがある」と報告していた。一方、AIを使わなかったグループは課題を「楽しかった」と感じ、ライブラリへの理解が深まったと実感していた。
ただし、AIを使った全員のスコアが低かったわけではない。AIにコード生成だけでなく「なぜそう書くのか」という概念的な質問をしていた開発者は、高いスコアを維持していた。 つまり、問題はAIを使うこと自体ではなく、使い方にあるということだ。
「インテリジェンス・ブラウンアウト」という概念
Rithwik Shetty氏の記事では、Andrej Karpathyが提唱した**「インテリジェンス・ブラウンアウト（intelligence brownout）」**という概念が紹介されている。
これはAIシステムが完全停止するのではなく部分的に使えなくなる状態を指すが、その時に感じるのは単なる不便さではなく、自分の判断力そのものが揺らぐ感覚だという。
AIが使えなくなった瞬間に、タイピング速度だけでなく、自分で考えて判断する力まで失われていたことに気づく。これは「ツールが使えない不便さ」ではなく「思考の依存」の問題だ。「AIは単なるツールではなく、判断プロセスそのものに影響を与える存在だ」という指摘は重い。
あなたは今どのステージにいる？
ここまで読んで「自分も当てはまるかもしれない」と感じた人もいると思う。以下は、自分のAI依存度と理解度を測るための指標だ。上から順に確認して、自分が今どの段階にいるか把握してみてほしい。
Stage 1：理解の可視化
-
チェック： AIが書いたコードを、各行の意味を含めて口頭で説明できるか？
「この変数はなぜ必要か」「この型はなぜ選ばれたか」「例外ケースはどうなるか」。これらに答えられないなら、まだ「分かったつもり」の段階にいる。まずはAIが出したコードに自分でコメントを書いてみることから始められる。
Stage 2：分解
-
チェック： 使っているライブラリの内部コードやドキュメントを読んだことがあるか？
ライブラリをブラックボックスのまま使っている状態。公式ドキュメントを読む、型定義を確認する、内部の実装を覗いてみる。そうした一歩が、表面的な利用から脱却するきっかけになる。
Stage 3：再実装
-
チェック： AIなしで同じ機能を自力で書けるか？
「書けない」は「理解していない」の最も明確なサインだ。まったく同じものを一言一句再現する必要はないが、処理フローを擬似コードで書き出せるか、別のアプローチで実装できるかが試金石になる。
Stage 4：設計思考
-
チェック： コード単体ではなく、設計の意図を説明できるか？
「なぜこの責務分離にしたのか」「なぜこのディレクトリ構成なのか」「なぜこの依存関係なのか」。個々のコードではなく、アーキテクチャレベルで語れるようになると、理解の質が一段上がる。
Stage 5：批評（ゴール）
-
チェック： AIが出したコードの問題点を即座に指摘できるか？
「これは将来壊れる」「スケールしない」「密結合になっている」「テストが困難」「型安全でない」。こうした判断を自分の経験と知識に基づいて下せる状態が最終目標だ。このレベルに達すると、AIは脅威ではなくレバレッジになる。
まとめ
AIは間違いなく強力なツールだ。生産性を上げ、パターンを網羅し、知らなかったアプローチを教えてくれる。
しかし、それを「生成装置」として使い続ける限り、自分自身の技術力は積み上がらない。バグの原因を追えない、設計が説明できない、面接で詰まる。そうした問題は、AIを使い始めた直後には見えにくいが、確実に蓄積されていく。
最終的に目指すべきは、「AIにコードを書かせる人」ではなく「AIが書いたコードをレビューできる人」 だ。
そのために必要なのは、特別な訓練プログラムではない。生成されたものをそのまま受け入れず、検証し、理解することだ。例えば、AIにコードを書かせた直後に、以下のようなプロンプトを投げるだけでも理解度は大きく変わる。
このコードの設計上のトレードオフ（メリット・デメリット）を教えてください。この実装で考慮漏れになりやすいのは何ですか？なぜ他のアプローチではなく、このやり方を推奨したのですか？
InfoWorldの記事で紹介されていた専門家の言葉が印象に残っている。
The risk of skill atrophy is real, but it’s not inevitable. It’s a choice
多分英訳したら以下のようになるのですが、「スキルの衰退は現実の問題だが、それは避けられないものではなく、選択の問題だ」 。
AIとの付き合い方を見直すことは、エンジニアとしての自分自身を見直すことでもある
参考文献
- AI use may speed code generation, but developers' skills suffer - InfoWorld
- Relying on AI without losing yourself - Rithwik Shetty
- Measuring AI's impact on coding skill acquisition - Anthropic Research
株式会社シンシアでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。
※ シンシアにおける働き方の様子はこちら
シンシアでは、年間100人程度の実務未経験の方が応募し技術面接を受けます。
その経験を通し、実務未経験者の方にぜひ身につけて欲しい技術力（文法）をここでは紹介していきます。