AIが若手プログラマーのスキルを奪う？生産性向上と「能力低下」のジレンマに関する実証研究 • vonxai blog

GitHub CopilotやCursorといったAIコード生成ツールの普及により、ソフトウェア開発の現場は劇的に変化しています。経験の浅い開発者でも、自然言語で指示を出すだけで複雑な機能を実装できるようになり、生産性は飛躍的に向上しました。しかし、この便利さの裏側で、若手エンジニアが「自力で問題を解決する能力」を失いつつあるという懸念も浮上しています。表面的なコード生成の背後で、エンジニアとしての基礎体力は本当に維持されているのでしょうか。

本記事では、Pavel KyurkchievらがIMEA’2025で発表した論文「THE EASY CHOICE IN FRONT OF THE YOUNG PROGRAMMER: HIGH PRODUCTIVITY AND ATROPHIED COMPETENCE」に基づき、AIツールが若手開発者のスキル習得に与える影響と、その対策について解説します。

実証実験の概要：学生インターンによる8週間の開発

研究チームは、プログラミングを専攻する高校生10名（16〜17歳）を対象に、2025年6月から8週間（合計240時間）にわたるインターンシップ形式の実証実験を行いました。参加者はWeb開発の経験が浅い状態で、自身のスキルレベルを大きく超える「顧客満足度評価システム」の開発に取り組みました。

この実験の最大の特徴は、GitHub CopilotなどのAIツールの使用が積極的に推奨された点にあります。また、本インターンは同社で過去にも実施されており、AIツールを使用せずに同様の課題に取り組んだ過去のジュニア開発者の実績データが比較対象として存在します。

実験結果：35%の生産性向上と深刻な理解不足

プロジェクト終了後、定量的なデータと定性的な観察結果の両面から分析が行われました。その結果は、AIツールの強力なメリットと、教育上の深刻なリスクを同時に浮き彫りにしました。

開発スピードの劇的な向上

生産性の観点から見ると、AIツールの導入は明確な成功を収めました。比較対象となったのは、過去に同社で採用され、AIツールなしで類似プロジェクトを行ったジュニア開発者たちの実績データです。彼らは通常、プロジェクト完了までに8〜10週間（約360時間）を要していました。

これに対し、今回AIツールを使用したインターン生たちは、Web開発の経験が浅いにもかかわらず、わずか8週間（約240時間）で機能するプロトタイプを完成させました。

図表1：開発時間の比較

開発者タイプ	所要時間（目安）	備考
今回のインターン（AI使用）	約240時間（8週間）	過去のジュニア実績より30〜35%高速
従来のジュニア開発者（過去データ）	約360時間（8〜10週間）	AIなしで実施された類似プロジェクトの記録

このように、AIを活用することで開発期間を大幅に短縮できることが実証されました。特に、コードの生成量に関しては、以下の割合でAIが関与していました。

フロントエンド： テンプレートコード（コンポーネント、APIリクエスト）の 約70% がAIによって生成または大幅に修正された。
バックエンド： データアクセス層のコードの 40% がAI生成であった。

明らかになった「能力の空洞化」

一方で、プロジェクト期間中に行われた週次評価と最終試験の結果は、参加者の理解度に深刻な欠陥があることを示しました。

週ごとの口頭試問において、明確なパターンが観察されました。学生たちは「このメソッドは何をするか」という表面的な質問には答えられましたが、「なぜこのインターフェースを使うのか」「なぜこのパターンが必要なのか」という概念的な質問には答えられませんでした。頻出した回答は「AIが推奨したから」「AIがそう生成したから」というものでした。

最終試験の結果はさらに衝撃的でした。

図表2：最終試験の合格率

試験内容	詳細	結果
理論（口頭試問）	理論的な知識や自分が書いたコードの内容についての質問	正答率約45%（代替案提示時は15%未満）
実技（AIなし）	AIツールなしでの機能追加実装	9名中、合格者はわずか3名

AIツールを取り上げた途端、参加者の大半がタスクを完了できなくなりました。これは、AIによる生産性向上が、必ずしも個人のスキル向上を意味しないことを示唆しています。

依存のメカニズム：「コピー・ペースト・祈る」現象

研究チームは、AI依存によって引き起こされる具体的な行動パターンを特定しました。

観察された依存モデル

メンターの観察日誌からは、学生たちが陥った典型的な依存パターンが明らかになりました。

コピー・ペースト・祈る： 最も一般的な問題です。生成されたコードを深く分析することなくコピーし、エラーが出ないことを祈って実行します。
断片的な理解： コードの個々の断片は理解していても、システム全体の構造やアーキテクチャについての理解が欠如しています。
オラクル（神託）としてのAI： AIを絶対的な真実の源として扱い、神のように崇める態度です。AIの提案に対して疑問を持たず、全面的に同意してしまいます。

失われた基礎スキル

このような依存の結果、プログラマーとして不可欠な以下のスキルが著しく低下していることが確認されました。

デバッグ能力： 体系的に問題を解決するアプローチが身につかず、エラーが発生するとすぐにAIに解決策を求める「反射」が形成されました。
アーキテクチャ思考： 完成された解決策を受け取ることに慣れてしまい、トレードオフや拡張性、保守性について考える能力が育ちませんでした。
他者のコードを読む力： 大量のコードを生成しているにもかかわらず、他人が書いたコード（あるいはAIが書いたコード）を読み解く能力が失われていました。

解決策：AI時代における「ハイブリッド学習モデル」の提案

この研究は、AIツールの使用を禁止すべきだと結論付けているわけではありません。むしろ、AIのパワーを享受しつつ、基礎的な問題解決能力を維持するための「ハイブリッド学習モデル」を提案しています。このモデルは、プロジェクトの時間を4つのフェーズに分割し、それぞれに明確な目的を設定します。

図表3：ハイブリッド学習モデルの構成

フェーズ名	時間配分	目的と活動内容
1. 認知的構築	30%	AI禁止。基本機能の実装や紙上でのロジック構築（ホワイトボードコーディング）を行い、構文的・論理的な独立性を養う。検索は公式ドキュメントのみ許可。
2. 副操縦士としてのAI	15%	AI利用可。ただし「オートパイロット」ではなく「副操縦士」として扱う。コードをマージする前に「なぜ動くのか」をメンターに口頭で説明させる。
3. デジタルデトックス	35%	部分的にAI禁止。週3日の「AIなしデー」を設定。壊れたコードをAIなしで修正するデバッグセッションを行い、トラブル対応力を鍛える。
4. アーキテクトと監査役	20%	レビュー中心。 AIの使用は許可されるが、重点はコードレビューやアーキテクチャの議論に置く。生成されたコードのリファクタリングを行う。

このモデルの核心は、学習者がツールに支配されるのではなく、ツールをコントロールするエンジニアになることを目指す点にあります。特に「認知的構築」のフェーズで基礎を固め、「デジタルデトックス」でAIがない状況への耐性を維持することが重要視されています。

結論

本研究は、AIツールがアプリケーション開発時間を短縮する巨大なポテンシャルを持つことを確認しました。しかし同時に、無差別な導入は、若手エンジニアの「コードを理解し創造する力」を長期的に損なうリスクがあることも明らかにしました。

AIは強力な加速装置ですが、運転技術を持たない者が使えば事故につながります。教育機関やメンターの役割は、単に知識を伝達することから、AIが生成したものを批判的に評価し、正しく導く「批判的思考（クリティカルシンキング）」を育成することこそが、次世代のエンジニアに求められる真のスキルと言えるでしょう。

生成AIの導入や活用にお困りですか？弊社のサービスは、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください！

参考資料:

THE EASY CHOICE IN FRONT OF THE YOUNG PROGRAMMER: HIGH PRODUCTIVITY AND ATROPHIED COMPETENCE