OpenAIのCodexを搭載したGitHub Copilotの登場以来、ソフトウェア開発の現場は劇的な変革の時を迎えている。GoogleのSundar Pichai CEOが「Googleの新規コードの4分の1以上がAIによって生成されている」と述べるほど、AIコーディングアシスタントの普及は加速している。生産性の向上、定型業務の自動化、そしてエラーの減少——これらAIがもたらす恩恵は計り知れない。
しかし、この急速な「効率化」の背後で、エンジニアの成長にとって本質的な何かが失われつつあるとしたらどうだろうか。
ドイツの名門、ザールラント大学（Saarland University）のソフトウェア工学研究グループが発表した最新の実証研究は、衝撃的な事実を突きつけている。それは、「AIアシスタントを使用するプログラマーは、人間のパートナーと組む場合に比べて質問の頻度が著しく低下し、コードに対する健全な批判精神を失い、学習の深度が浅くなる傾向がある」という警鐘だ。
ペアプログラミングと「知識の空白」
伝統的なペアプログラミングの効用
ソフトウェア工学において「ペアプログラミング」——2人の開発者が1台のコンピュータを前に共同作業を行う手法——は、単なるコード作成の手法以上の意味を持つ。ドライバ（コードを書く人）とナビゲータ（全体を俯瞰し指摘する人）の対話を通じて、バグの減少だけでなく、「知識の伝達（Knowledge Transfer）」が自然発生的に行われるからだ。
経験の浅い開発者が熟練者に質問し、熟練者がその背景にある論理を説明する。このプロセスにおいて、開発者は自らの「知識の空白（Knowledge Gap）」を埋め、新たなメンタルモデルを構築していく。これは構成主義的学習理論において、最も効果的な学習形態の一つとされる。
「AIペアプログラマー」という幻想
MicrosoftやGitHubは、Copilotを「AIペアプログラマー」と位置づけている。もしAIがあらゆる質問に答え、コードを提案してくれるなら、人間のパートナーは不要になるのではないか？ ザールラント大学のSven Apel教授とAlisa Welter氏らの研究チームは、この仮説を検証すべく、厳密な比較実験を行ったのだ。
実験設計：人間 vs AI、対話の質的比較
研究チームは、19名のコンピュータサイエンス専攻の学生（学部後半から修士課程初期）を対象に、以下の2つのグループに分けて実験を行った。
- 人間同士のペアプログラミング（Human-Human）: 2人が協力して課題に取り組む。
- AI支援ペアプログラミング（Human-AI）: 1人の開発者がGitHub Copilotを使用して課題に取り組む（思考発話法を用いて思考を言語化する）。
課題は、PythonとSQLAlchemy（データベース操作ライブラリ）を用いたパスワードマネージャーアプリの機能拡張である。参加者は既存の約400コードベースを理解し、データベース連携や文字列操作を含む機能を実装する必要があった。
研究チームは、録音された会話と画面操作のログを分析し、「知識伝達エピソード（Knowledge Transfer Episode）」——知識の空白が生じ、それを埋めようとする一連のやり取り——を抽出・定量化した。
AIがもたらす「沈黙」と「盲信」
分析の結果、両グループ間には、知識伝達の頻度、質、そして対話の方向性において決定的な差異が確認された。
1. 圧倒的な「対話量」の差
まず注目すべきは、知識伝達エピソードの数である。
- 人間同士のペア: 1セッションあたり中央値で33.5回のエピソードが発生。
- AI使用ペア: 同17回の発生にとどまった。
これは、AIを使用する開発者が、人間のパートナーと作業する場合に比べて、約半分しか「問うこと」や「確認すること」を行っていないことを示している。人間同士であれば、些細な疑問や確認事項が頻繁にやり取りされる（「この関数はどう動く？」「ここでコミットが必要か？」など）。しかし、AI相手では、開発者は能動的に問いかける閾値が高くなり、結果として学習の機会（トリガー）自体が減少してしまうのである。
2. 「健全な懐疑心」の欠如と「盲信（Trust）」の罠
本研究で最も懸念すべき発見は、知識伝達の「結末（Finish Type）」に関するデータである。研究チームは、エピソードの終わり方を「同化（Assimilation：完全に理解した）」「信頼（Trust：理解はしていないが受け入れた）」などに分類した。
- 人間同士: 相手の提案に対し、「なぜそうなるのか？」と食い下がり、納得するまで議論する傾向が強い（Assimilationの比率が高い）。
- AI使用: 「Copilotがそう言うなら正しいだろう」という、検証なき受容（Trust）の比率が、人間ペアの2倍以上に達した。
Apel教授はこの現象を「建設的な懐疑心（Constructive Scepticism）の欠如」と指摘する。AIが生成したコードを一見して「それらしい」と判断し、その論理的正当性や副作用を吟味することなく採用してしまう。これは、短期的なタスク完了には寄与するが、長期的には「なぜ動いているかわからないコード」を量産し、深刻な技術的負債（Technical Debt）を積み上げるリスクを意味する。
3. 会話の焦点：実装（Code）か、設計（Design）か
知識伝達の内容（Topic Type）においても、両者には明確な断絶が見られた。
- AI使用: 会話（思考発話）の84%が、具体的な「コード記述（Code）」に集中していた。
- 人間同士: コードそのものだけでなく、「プログラム全体の構造」「ドメイン知識」「バグの原因究明」など、より抽象度の高いトピックへ議論が広がる傾向があった。
人間同士のペアプログラミングでは、作業中に「脱線（Lost Sight）」が発生しやすいという欠点がある一方、その脱線が予期せぬ学びや、システム全体への深い洞察につながることが多い。対照的に、AIとの作業は非常に直線的で効率的だが、視野が狭窄（トンネルビジョン化）しやすく、目の前のコード補完に終始してしまう傾向が強いことが浮き彫りになった。
「データベースのコミット忘れ」が示すAIの功罪
しかし、本研究はAIを一方的に否定しているわけではない。AI独自の学習支援の形も確認されている。その象徴的な例が、実験中の「データベースの変更をコミットする」という工程だ。
多くの参加者はSQLAlchemyの経験が浅く、変更を確定するための session.commit() の記述を忘れがちであった。人間同士のペアでは、二人ともこの知識が欠けている場合、エラーの原因究明に長い時間を費やすことになった。
一方で、Copilotは文脈から判断し、ごく自然に session.commit() をコード補完として提案した。開発者はその提案を見て「ああ、コミットが必要だったのか！」と気づき、他の関数にもその知識を適用することができた。
研究チームはこれを、AIによる「サブリミナルな知識伝達」と評価している。AIは明示的に「ここでコミットが必要です」とは教えないが、正しいコードパターンを提示することで、開発者に”気づき”を与えることができる。ただし、これは開発者がその提案の意味を理解しようとする姿勢（建設的懐疑心）を持っている場合に限られる。
なぜAIは「深い学び」を阻害するのか？：認知科学的考察
この研究結果は、我々が「学習」という行為をどう捉えるべきかについて重要な示唆を与えている。
1. コンフォートゾーンの維持
人間同士の対話では、相手の理解度に合わせて説明を変えたり、あえて異論を唱えたりすることで、思考の「揺らぎ」が生じる。構成主義的には、この認知的な葛藤こそが深い理解への入り口である。しかし、AI（特にLLM）はユーザーの意図を汲み取りすぎ、「心地よい正解」を即座に提示するよう最適化されている。摩擦のない体験は、ユーザーを認知的なコンフォートゾーンに留まらせ、深い思考の機会を奪う可能性がある。
2. 「説明」の不在
Copilotのようなコード補完ツールは、基本的に「What（何を書くか）」を提示するが、「Why（なぜそう書くか）」を（明示的に求めない限り）説明しない。人間ペアの強みは、コードを書くプロセスそのものを言語化し、共有できる点にある。AIによるオートコンプリートは、このプロセスをスキップさせ、結果だけを提供する。結果だけを見て「分かったつもり」になること（流暢性の錯覚）が、学習深度の低下を招いていると言えるだろう。
AI共生時代に求められる「メタ認知」
ザールラント大学の研究は、AIコーディングアシスタントが「単純作業の効率化」には極めて有効である一方で、「複雑な問題解決」や「深い知識の習得」においては、人間の代替にはなり得ないことを示唆している。
エンジニア・学習者への提言
- 「なぜ？」を問い続ける意志: AIの提案をそのまま受け入れるのではなく、常に「なぜこの実装なのか」「別の方法はないのか」を自問する習慣、すなわち「建設的懐疑心」を意識的に維持する必要がある。
- ハイブリッドな学習戦略: 定型的なコード生成にはAIを活用しつつ、アーキテクチャ設計や複雑なバグシューティングにおいては、人間のメンターや同僚との対話を重視するべきである。
- 明示的な説明要求: AIを使用する際、単にコードを出力させるだけでなく、「このコードの動作原理を説明して」「この実装の潜在的なリスクは？」といったプロンプトを投げかけ、擬似的に対話的な学習環境を作り出す工夫が有効だ。
組織・教育機関への提言
新人研修やプログラミング教育において、AIツールの使用を禁止するのは現実的ではない。むしろ、「AIの出力を批判的に評価するスキル（レビュー能力）」こそを、新たなコアスキルとして教育カリキュラムに組み込むべきである。
AIは「魔法の杖」ではなく、あくまで「鏡」である。使う人間の知識レベルと問いかける力以上の答えは返ってこない。このツールを、思考を停止させる松葉杖にするか、思考を加速させる自転車にするかは、我々がAIの提案に対してどれだけ「うるさい小姑」になれるかにかかっているのかもしれない。
論文
参考文献
- Saarland University: Software developers show less constructive scepticism when using AI assistants
- bbb
研究の要旨