AIがコードを書く時代、修正できる人はどう育つのか

若手開発者がAIアシスタントに、使い慣れていないライブラリを使うよう頼み、動くコードを得て次に進む。機能ができあがっても、なぜ動くのかを本人が理解しているとは限らない。次にコードが壊れたとき、要件が変わったとき、あるいはアシスタントの修正が安全かどうかを判断するときに、それが問題になる。

ソフトウェアエンジニアのAlexandru Nedelcuは、9月22日のエッセイでこの懸念を提起した。開発者はコードを読み、判断を下し、失敗の結果を引き受けるなかで判断力を養う、と彼は論じる。一部の企業がAI禁止方針を公表するという予測は、確認された業界の変化ではなく、彼の意見だ。これとは別に、1月に公表された実験は、学習に関する問いを検証可能な形に絞っている。AIの支援を受けて作業を終えた直後、プログラマーは何を理解していたのか。Anthropicの研究報告

大きな変化

• 何が変わったか：AIによって、コードのロジックを自分でたどらなくても、完成したソフトウェアを提出しやすくなる。新人が説明や修正に必要な判断を練習する前に、AIが実装を提示できる。
• なぜ重要か：管理職は今日の成果を増やせても、若手社員が将来の障害を診断できる人材に育つ道筋を弱めるおそれがある。慣れていない概念を使う作業ではリスクが特に大きいが、慣れた仕事でのAI支援には価値がある。
• 今後の注目点：チームは、説明し、原因を診断し、AI支援の成果に対応する時間を確保して、学習を納品プロセスの一部として扱うようになるかもしれない。そうなれば、採用課題やコーディング製品では、速さだけでなく理解を示せることも評価される可能性がある。

タスクの完了と技能の習得は別の成果

、52人のプログラマーを対象とした無作為化研究では、参加者がTrioという未経験のPythonライブラリを使い、二つのコーディング課題に取り組んだ。半数はコーディング環境でAIアシスタントを利用でき、残りの半数は利用できなかった。参加者には後で小テストがあると伝えられていた。テストでは、作業直後に概念理解、コード読解、デバッグの力を測った。

AIを利用したグループの平均点は50％で、AIなしで作業したグループは67％だった。差は17パーセントポイントであり、相対的な17％の低下ではない。デバッグ問題で最も大きな差が出た。AIグループは平均で約2分早く終えたが、この時間差は統計的に有意ではなかった。これらは、一つのライブラリに短時間触れた後の即時テストの結果であり、開発者のキャリアや本番システムの品質を測ったものではない。研究結果とその限界

研究者は参加者のアシスタント利用方法も観察した。コード作成とデバッグをほぼ委ねる人もいれば、説明を求めたり、自分で概念を考えたりする人もいた。主体的に関わる傾向のあるグループほど得点が高かったが、こうした小集団は結果を見てから分類された。無作為に割り当てられたのはAIへのアクセスであり、特定の使い方ではない。説明を求めることは学習者に役立つかもしれないが、この研究から、あるプロンプトや作業手順が学習差を防ぐと証明することはできない。論文の利用状況分析

ライブラリが何を前提としているかを新人が学ぶのは、エラーが起きたときである。最初の実装と修正の両方をアシスタントに任せれば、開発者がそうした前提に触れる機会は減るかもしれない。これはデバッグの得点差を説明する一つの可能性だ。

速度も重要だが、作業によって答えは変わる

異なる条件下で、AI支援がコーディングを速めたという結果もある。GitHub Copilotを使った対照実験では、95人のプロのフリーランスにJavaScript製のHTTPサーバーを作る課題を割り当てた。完了した人に限ると、Copilotグループの平均所要時間は約71分で、対照グループは約161分だった。完了までの時間は55.8％短縮した。研究者はその後にプログラマーが何を学んだかを調べていない。これは範囲が定まった実装課題であり、未経験のライブラリを学んだ後に理解度テストを受ける課題とは異なる。

どちらの結果も管理職にとって参考になる。経験豊富な開発者がAIを使って反復作業を減らすなら、時間の節約は実際に得られるかもしれない。新しいシステムを学ぶ仕事では、成果の速さと理解の深さを別々に確かめる必要がある。AIを一律に禁止すれば、学習方法の問いに答えないまま、期待できる効果も手放してしまう。

Nedelcuのエッセイは、実験の結果を超えた議論をしている。保守性は数か月、数年かけて見えてくること、失敗への責任を通じて経験が育つことを彼は論じる。この研究は長期的な保守性を測っておらず、AI利用者がまったく学ばなくなるとも示していない。彼の問いかけは、組織にとって有益だ。チームが練習を伴う仕事をますます委ねるなら、将来のトラブル対応者は、どこで実践経験を積むのだろうか。Nedelcuのエッセイ

コードが動いた後に、学習者が理解を示せる機会を設ける

実践的な対応の一つとして、若手社員にAI支援付きの課題を与えた後、学習の成果とみなす前に、短い独力での確認を求める方法がある。これは私たちが提案する演習であり、どちらの研究でも検証された介入策ではない。

1. 説明する：アシスタントに尋ねず、コードの不慣れな部分がなぜ動くのか、何を前提としているのか、どんな場合に失敗するのかを説明してもらう。シニアエンジニアは、実際の変更に即した質問を一つ続けて尋ねられる。
2. 原因を診断する：安全なテスト用ブランチに、小さく現実的な不具合を仕込む。学習者に原因を見つけさせ、ありがちだが誤った修正案をどの観察結果によって退けたのか説明してもらう。目的はコマンドの暗記ではなく、筋道を立てて考えることだ。
3. 変更に対応する：要件を変え、実装とテストを修正してもらう。AIを使ってもよいが、新しい動作を説明し、さらに何を確認する必要があるかを述べられることが求められる。

たとえば、アシスタントが非同期処理を書いた後、レビュー担当者は、途中でキャンセルされたらどうなるかを尋ねられる。開発者は処理の流れを追い、変更された要件をテストできるはずだ。コードレビューだけで不具合を発見できても、学習者が次の問題に対応できないままかもしれない。この確認では、納品されたコードとともに知識も身についているかを問う。

日常のすべてのチケットを試験にする必要はない。未経験のライブラリ、繰り返し起こる障害、あるいは後に若手社員が担当する予定の作業に限って演習を行う方法もある。そこには勤務時間とシステムを知るレビュー担当者が必要だ。管理職がマージされたタスク数と節約時間だけを数えるなら、こうしたコストが真っ先に削られるかもしれない。そうなれば、今日の成果が伸びたとしても、育成の課題はさらに難しくなる。

徒弟的な学びをめぐる問いは、採用と製品設計にも及ぶ

若手の職務には、成果物の納品と監督下での実践が組み合わされてきた。AIを使うと、候補者がどのように考えたかを示さずに、完成度の高い機能だけを提示できる場合があり、この前提が変わる。採用側は、洗練されたリポジトリを独力の技能の証拠とみなす代わりに、小さな成果物を説明し、変更してもらうことができる。これは提案する採用方法であり、現在の採用動向を示す証拠ではない。すべての応募者にツールなしの作業を求めるのではなく、職務で実際に必要な能力を確かめるべきだ。

コーディング製品も同様の選択に直面する。アシスタントはすぐに答えを出すことを優先することも、前提を確認し、概念について質問し、解答を見る前に変更を試せるようにすることもできる。研究で観察された使い方を踏まえると、後者の設計は試す価値がある。ただし、特定のインターフェースのほうがよく教えられるとは、この研究から結論できない。企業にとっては、ツールがコードをどれだけ生成するかだけでなく、その出力を社員が学び、確認し、変更するのに役立つかも購入時に問うべきだ。

短いテストだけでは、5年後に誰が熟練者になるかはわからない。一方で、慣れていない作業では、実装が受け入れられたことは理解の証拠にならないと示している。自動化と次世代の人材育成の両方を目指すチームには、練習の余地を設け、人々が答えの変化にどう対応できるか確かめる必要がある。