生成AIは仕事のスピードを大きく高める一方で、「頼りすぎるとスキルが身につかなくなるのではないか」という不安も広がっています。ソフトウェアエンジニアを対象に行われた実験では、AIを使ったコーディングが習熟度を下げる可能性が示されましたが、その影響は「どう使うか」に大きく左右されることが分かりました。
実験で分かったこと：AIは生産性を上げるが、習熟度は下がりうる
ソフトウェアエンジニアを対象にしたAI利用実験の概要
研究チームは、ソフトウェアエンジニアにAIツールを使ってコーディングを行ってもらい、その効果を検証しました。目的は、AIが「仕事の速さ」と「スキルの習得・習熟度」にどのような影響を与えるかを明らかにすることでした。
実験の焦点は、単に「AIを使うかどうか」ではなく、「AIにどの程度依存しているか」「自分で考えるプロセスをどれだけ維持しているか」に置かれました。その結果、AIの活用の仕方によって、スキルの伸び方が大きく変わることが浮き彫りになりました。
AIでコーディング速度は向上、しかし「マスタリー」が低下
実験では、AIを使ったエンジニアは、コードを書くスピードやタスクの完了時間といった「見える生産性」は向上しました。一方で、問題の本質的な理解や、自力で解決できる範囲を示す「マスタリー（習熟度）」は低下する傾向が見られました。
特に、AIが提案するコードをほぼそのまま受け入れ、なぜその実装になるのかを深く考えない場合、時間が経つほど自分のスキルが伸びにくくなるリスクが指摘されています。短期的な効率と、長期的な成長とのトレードオフが浮き彫りになった格好です。
「依存度」がカギ：使い方次第で結果が変わる
一方で、AIを「答えをそのまま受け取る道具」としてではなく、「アイデアを広げたり、別の実装を比較するための補助」として活用したエンジニアは、習熟度の低下が比較的小さい傾向にありました。
つまり、AIは「学びを奪う存在」ではなく、「学習スタイルを変える存在」とも言えます。自分で考えるプロセスを省略しすぎるとマイナスに働き、検証・比較・改善のための材料として使えば、むしろ理解を深めるきっかけにもなりうるという示唆が得られました。
エンジニアや企業が意識したいAIとの付き合い方
個人のエンジニアが避けるべき「丸投げ」パターン
今回の実験結果から、個々のエンジニアが避けたいのは、AIへの「丸投げ」です。具体的には次のような使い方です。
- 要件を雑に投げて、提案されたコードをほとんど理解せずに採用する
- エラーやバグが出たときも、自分で原因を追わずAIに聞き続ける
- 既存コードの構造や意図を読む前に、AIに書き換えを依頼してしまう
こうした使い方を続けると、短期的には成果物が出ていても、時間が経つほど「自分で考え、設計し、改善する力」が育ちにくくなります。特にキャリア初期のエンジニアにとっては、成長機会を自ら手放してしまう可能性があります。
学びを深めるための「能動的なAI活用」
一方で、次のような使い方は、スキル向上と両立しやすいと考えられます。
- まず自分で方針やコードを書き、その後AIに代替案や改善点を聞いて比較する
- AIの提案に対して「なぜこの実装なのか」「他のやり方は？」と問い直す
- 知らないライブラリやアルゴリズムが出てきたら、その背景や仕組みを自分で調べる
AIを「答え」ではなく「問いを増やしてくれる相手」として扱うことで、実務のスピードを保ちつつ、理解を深めるサイクルを維持しやすくなります。
企業・チーム側の課題：短期効率と人材育成のバランス
企業にとってAIは、生産性向上の切り札になり得ますが、同時に「人材育成の質」をどう保つかという課題も突きつけます。特に、若手や中堅エンジニアが、設計やデバッグの基礎力を身につける前にAIに強く依存してしまうと、中長期的にはチーム全体の技術力が頭打ちになるリスクがあります。
そのため、コードレビューの場で「AIが書いたコードをどう理解しているか」を確認したり、あえてAIの利用を制限した学習・研修の時間を設けたりするなど、AI時代ならではの教育設計が求められます。
まとめ
ソフトウェアエンジニアを対象にした実験から、AIは仕事のスピードを上げる一方で、使い方によっては習熟度を下げてしまう可能性があることが示されました。ただし、それは「AIが悪い」という話ではなく、「どこまで自分で考え、どこからAIに助けてもらうか」というバランスの問題です。
これからのエンジニアに求められるのは、コードを書く能力だけでなく、「AIをどう設計し、どう制御し、どう学びに変えるか」というメタスキルです。AIと競うのではなく、AIと協働しながら、自分の専門性をどう高めていくか——その設計力こそが、キャリアの差を生む時代になりつつあります。
