AIにコーディングを任せると理解度は落ちるか — 52人のRCTが示す頼み方の差
Anthropicが開発者52人で行った無作為化試験では、AI支援の群の理解度テストが17%低くなりました。丸投げと、説明を求める使い方の差をClaude Codeの設定に落とします。
AIにコードを書かせると、速くなる代わりに自分の理解度が落ちるのか。Anthropicが2026年1月に公開した無作為化試験（RCT）は、この問いに数字で答えています。AI支援の群は、直前に使った概念のクイズで、手で書いた群より17%低い点でした。ただし、AIを使えば必ず低くなるわけではありません。差を分けたのは、AIに何を頼んだかです。
この記事では、試験の中身と結果を整理し、新しいライブラリや言語を覚えたい場面でClaude Codeにどう頼めば「丸投げ」を避けられるかを書きます。
試験は何を測り、どんな結果だったか
対象は、Pythonを週1回以上、1年を超えて使っている52人のソフトウェアエンジニアです。多くは経験の浅い層で、AIコーディング支援には多少なじみがあり、課題の題材であるPythonライブラリTrioは未経験という条件で集められました。Trioは非同期プログラミングの概念を理解する必要があるライブラリです。
進め方は3段階です。ウォームアップ、Trioを使った2つの機能のコーディング、そしてクイズ。クイズがあることは事前に伝えられ、できるだけ速く解くよう促されました。AI群にはサイドバーにAIアシスタントが付き、参加者のコードを読めて、頼まれれば正解のコードをいつでも出せる設定でした。
AI群と手書き群の差
クイズの平均点（AI群）
50%
手書き群は67%
効果量
d=0.738
p=0.01
完了時間の差
約2分
AI群が速いが有意差なし
クイズは、デバッグ、コードの読解、コードの記述、概念の4種類の問いで構成されました。評価は、AIが書いたコードを監督するうえで重要なデバッグ、読解、概念に重みを置いています。差が最も大きかったのはデバッグの問いです。コードが誤っていることに気づき、理由を説明する力に、最も開きが出ました。
速度の面は意外な結果です。AI群は約2分速く終えましたが、統計的に有意ではありませんでした。AIへの質問を組み立てる時間が長く、最大で11分（割り当て時間の30%）をかけて15回ほど質問した参加者もいたためです。
丸投げと説明の要求で、点数はどう分かれたか
参加者の画面録画を人手で注釈し、AIとの関わり方を分類した結果が、この試験でいちばん使える部分です。クイズの平均が40%を下回った低得点の型と、65%以上だった高得点の型に分かれました。
| 型 | 人数 | 関わり方 | 傾向 |
|---|---|---|---|
| AI delegation | 人数4 | 関わり方コードの作成を全面的にAIへ任せる | 傾向最速。エラーはほぼ無し |
| Progressive AI reliance | 人数4 | 関わり方最初は1〜2問聞き、やがて全部任せる | 傾向2つ目の課題で概念を習得できず |
| Iterative AI debugging | 人数4 | 関わり方デバッグや検証をAIに頼る | 傾向質問は多いが遅く、低得点 |
| Generation-then-comprehension | 人数2 | 関わり方生成させた後で追加質問して理解を確かめる | 傾向速くはないが理解度は高い |
| Hybrid code-explanation | 人数3 | 関わり方コード生成と説明をまとめて頼む | 傾向説明を読む時間がかかるが理解につながる |
| Conceptual inquiry | 人数7 | 関わり方概念の質問だけをして、コードは自分で書く | 傾向高得点の型では最速、全体でも2番目 |
注目したいのは、AI delegationとGeneration-then-comprehensionの対比です。コードを生成させて貼り付けるところまでは、ほぼ同じ動きでした。違ったのは、生成の後にAIへ追加の質問をして自分の理解を確かめたかどうかだけです。
Iterative AI debuggingにも注意が要ります。質問の数は多いのに、AIを理解の確認ではなく問題の解決役にしたため、点が伸びませんでした。質問が多いことと、考えていることは別物です。
手書き群にはエラーが多く出ました。そのうちTrioの概念に関するエラーは、クイズの出題範囲と直接重なります。研究者の仮説は、自力でエラーを解いた経験がデバッグ力を育てた、というものです。Conceptual inquiryの群も多くのエラーに遭遇しましたが、自力で解決しています。
この結果をどこまで読んでよいか
結論を広げすぎないための条件があります。
- 標本は小さい（52人）。研究者自身が結果を暫定的としている
- 測ったのは課題の直後の理解度。クイズの点が長期の技能習得を予測するかは未解決
- 型の分析は因果を示さない。高得点の型は学習に向く行動と結びつく、というところまで
- 題材は新しいライブラリの習得。既に慣れた作業の生産性とは別の問い
最後の点は、同じAnthropicの別の研究と矛盾しません。Claude.aiの利用データを使った観察研究では、一部のタスクが最大80%速くなる例が出ています。そちらは、参加者が既に技能を持つ作業の生産性を測ったものです。今回は新しいことを学ぶときの話で、問いが違います。慣れた作業は速く、新しい技能の習得は妨げられるという両立もありえますが、さらなる研究が必要とされています。
もう一つの注意点は、道具の違いです。試験で使ったのはサイドバー型の対話アシスタントで、Claude Codeのようなエージェント型の製品とは異なります。論文の脚注は、エージェント型では影響がより大きく出ると見込んでいます。
新しい言語やライブラリを覚えるとき、Claude Codeにどう頼むか
試験の高得点の型を、Claude Codeへの頼み方に直すと次の3つになります。いずれも、試験の型をそのまま再現するものではなく、考え方を借りた使い方の例です。
先に概念を聞き、実装は自分で書く
Conceptual inquiryに相当する頼み方です。コードは書かせず、概念の説明と、確認のための問いだけを返させます。
Trioのnurseryとキャンセルスコープの考え方を、コードを書かずに説明して。
説明の後で、理解を確かめる質問を3つ出して。実装は私が書く。生成させた後に、必ず理解の確認を挟む
Generation-then-comprehensionの型です。コードを出させた後、自分の言葉で説明し、間違っていれば直させます。
今のコードの動作を、私が説明するから聞いて。間違いがあれば指摘して。
そのうえで、このコードが失敗する入力を2つ挙げて、なぜ失敗するか説明して。デバッグが最も差の出た領域だったため、「失敗する入力を考えさせる」「壊れた箇所を自分で見つけてから聞く」といった頼み方は、理解を保つ効果が期待できます。
説明つきの出力にそろえる
毎回頼むのが面倒なら、出力スタイルで既定を変えられます。組み込みのExplanatoryは、コードの前後に2〜3点のInsightブロックを添えます。Learningは、さらに重要な判断点にTODO(human)コメントを残し、数行を利用者に書かせて待ちます。ファイルを直接編集して選ぶ場合の書き方は次のとおりです。
{
"outputStyle": "Learning"
}値は大文字小文字を区別します。learningのように小文字で書くと、Defaultのスタイルになります。/output-style learningなら大文字小文字は無視されます。スタイルは、次のメッセージから反映されます。
LearningとExplanatoryは、設計上Defaultより応答が長くなり、出力トークンが増える点も覚えておくところです。切り替え手順はClaude Code output styleを/output-styleか/configで切り替えるに、プラグイン版の仕組みはClaude Codeのlearning output styleプラグインで学習モードにするにあります。
学習中のプロジェクトだけCLAUDE.mdで縛る
出力スタイルは全体の既定を変えます。特定のリポジトリだけ、学習のためのルールを足したいときは、CLAUDE.mdに書く手もあります。たとえば、新しいライブラリを試す練習用リポジトリでは、次のような規約が考えられます。
## このリポジトリの進め方（学習用）
- 新しい概念が出たら、実装の前に3文で説明する
- 動くコードを出す前に、私が自分で書く機会を提案する
- 私が書いたコードのレビューでは、答えを直接書かず、気づくための問いを返す
- 私が理解を言葉にしたら、間違いを指摘するこれは試験の型を再現するための一例です。効果が実証された設定ではなく、Conceptual inquiryとGeneration-then-comprehensionの考え方を規約にした形にすぎません。CLAUDE.mdと出力スタイルの役割の違いはClaude Codeのoutput styleとCLAUDE.md・Skillsは何が違うかで比べています。
速さを取る場面と、学びを取る場面を分ける
全部の作業で学習モードにする必要はありません。慣れた作業まで遅くなるからです。分け方の目安を表にしました。
| 場面 | 向く頼み方 | 理由 |
|---|---|---|
| 初めて触るライブラリを覚える | 向く頼み方概念質問、Learning | 理由試験の題材と同じ状況 |
| 理解したい既存コードを引き継ぐ | 向く頼み方Explanatory、説明つきの生成 | 理由読解の力を保つ |
| 定型作業・見慣れた修正 | 向く頼み方生成を任せる | 理由技能が既にあり、研究が示した理解度低下の対象外に近い |
| 不具合の原因調査 | 向く頼み方自分で仮説を立ててからAIに確認 | 理由デバッグ力が最も差の出た領域 |
学びたい場面でだけ負荷を戻す、という使い分けです。速さが大事な作業は任せて構いません。ただし、AI delegationの群が最速だったことは、速さと学習がこの試験では引き換えだったことも示しています。
Claude Codeのようなエージェント型では何が変わるか
試験のAIアシスタントは、サイドバーで質問に答え、頼まれればコードを出す形でした。Claude Codeは、ファイルを読み、編集し、コマンドを実行して作業を進めます。人が書く部分がさらに減るため、論文の脚注は、技能形成への影響がより大きく出ると予想しています。これは実測ではなく予想です。
実務での含意は、設定を変えなくても「任せた範囲」が広がりやすいことです。差分を読まずに承認し続けると、AI delegationの型に近づきます。変更を受け入れる前に、何をしたコードかを自分の言葉で言えるかを確かめる習慣が、試験の高得点の型と同じ働きをします。
組織で使うときの論点
研究者は、AIを大規模に導入する管理者に向けて、エンジニアが学び続けられる仕組みや設計上の選択を意識するよう述べています。経験の浅い人ほど、時間の制約から「できるだけ速く」を優先して丸投げに寄りやすいためです。AIが書いたコードを検証する力は、そもそも自分で技能を育てた人にしか備わらない、という懸念が背景にあります。
個人の習慣としては、Claudeを使いすぎない・依存しないための工夫が扱う「自分で考える時間を残す」と同じ方向の話です。ここで違うのは、コーディングの習得という具体的な技能で、数字の裏付けがあることです。
困難にぶつかる経験自体も学習の一部です。研究者は、認知的な努力や、苦しく行き詰まることが習得を促す可能性が高いと述べています。AIが詰まりを先回りして消すと、その機会も一緒に消えます。
まとめ
試験が示したのは、AIを使うこと自体ではなく、理解を作業から切り離す使い方が点を下げる、という傾向です。Claude Codeでは、概念を先に聞く、生成の後で自分の説明を確かめる、LearningやExplanatoryに切り替えるの3点が、その差を埋める現実的な手段になります。新しい技能を身につけたい期間だけ切り替え、慣れた作業では任せる。この使い分けで足ります。