AIはスキル習得を妨げるのか：Anthropicの実験が示す「使い方」の重要性
仕事の資料作りや、プログラミング言語の習得など、何か新しいスキルを素早く身につけたいときあなたは最近どうしているだろうか。おそらく、画面の端にあるAIチャットに質問を投げかけるのがすっかり日常になっているのではないだろうか。
AIは瞬時に答えてくれて、コードも数秒で生成してくれる。本当に便利な時代だ。
しかし、その便利さと引き換えに、物事を根本から理解し応用する能力を少しずつ失っているとしたら──？
この問いに、Anthropicの研究者が初めて厳密な無作為化比較試験（RCT）で答えを出した。結果は、AIを使ったグループの学習テストスコアが17%低下（Cohen's d=0.738）というもの。ただし、AIの使い方次第でスコアは24%〜86%まで大きく分かれることも明らかになった。
どんな研究か（背景と課題）
AIコーディングツールがタスク完了速度を向上させるという報告は多いが、スキル形成（skill formation）への影響を因果関係として明らかにした研究はほとんどない。従来の研究は観察研究が多く、「AIを使ったから学習効果が下がった」と断言するには不十分だった。
この研究が問うのは：新しいライブラリを学ぶ際にAIアシスタントを使うと、実際に理解度・スキルは下がるのか？
特に懸念されるのは、デバッグスキルの喪失だ。AI生成コードが増えるほど、人間がそのコードを検証・修正する能力が求められる。しかし学習段階でAIに頼りきると、その検証に必要なスキル自体が形成されない可能性がある。
実験設計：厳格な無作為化比較試験
今回の実験が優れているのは、単なるアンケート調査ではなく厳密なRCTを採用した点だ。
対象となったのは、Pythonの経験はあるものの「Trio」という非同期処理ライブラリを初めて学ぶ開発者たち。非同期処理というのは、概念を掴むのに独特のメンタルモデルが必要な領域だ。料理に例えると、お湯が沸くのをじっと待つのではなく、沸かしている間に別の作業を進め、沸騰したらすぐ鍋に戻る——そんな複数のタスクを頭の中で同時に管理するような考え方で、直感的な把握が難しい。
- 参加者: 52名のプロ・フリーランス開発者（AIアシスタント経験あり）
- 設計: 無作為化比較試験（RCT）、被験者間デザイン
- タスク: PythonライブラリTrioを使った2つのコーディング課題（制限時間35分）
- 評価: タスク完了時間 ＋ 27問の学習評価クイズ（概念理解・デバッグ・コード読解）
- 治療群（AI条件）: AIアシスタント・ウェブ検索・指示書を使用可（n=26）
- 対照群（AI無し）: ウェブ検索・指示書のみ（n=26）
主要な実験結果
| 指標 | AI使用グループ | AI未使用グループ |
|---|---|---|
| クイズスコア（平均） | 約50% | 約60% |
| スコア差 | −17%（p=0.010） | — |
| 効果量 | Cohen's d=0.738（大） | — |
| タスク完了時間（中央値） | 19分 | 23分 |
| 時間差の有意性 | 有意差なし（p=0.391） | — |
| 遭遇エラー数（中央値） | 1件 | 3件 |
成績評価でいえば、A判定がC判定に落ちる2段階分の差だ。しかもこれは、短期のテストの話ではない。「そのライブラリを理解できたかどうか」という、本質的な差だ。しかも、タスクの完了時間には統計的に有意な差はなかった。つまり、AIを使ってもほぼ速くならず、スキルだけが身につかない、という結果だった。
スコア低下の内訳を見ると、デバッグ問題で最も大きな差が生じていた。コード読解では差が小さく、概念理解・デバッグで顕著に開いた。経験年数（1〜3年・4〜6年・7年以上）に関わらず、全グループでAI無しの方がスコアが高かった。
摩擦はバグではなく、機能だ
なぜデバッグ能力が特に低下したのか。ここに、この研究が示す最も深いインサイトがある。
カーナビに完全に頼りきって車を運転していると、何度同じ道を通っても、ルートが全く頭に入らない。交差点の目印を自分で探すというプロセスをスキップしているからだ。いざGPSが切れると、自分がどこにいるのか全くわからなくなる。
これが、AIが学習に与えた影響の本質だ。実際のデータを見ると、AI無しグループはタスク中に中央値で3回のエラーに直面していた。RuntimeWarning（コルーチンの未awaitエラー）やTypeError（非同期関数の誤用）など、Trioの根幹概念に直結するエラーだ。彼らはそのエラーを解消するために、ドキュメントを読み込み、コードのどこが間違っているかを自力で格闘した。
一方、AIグループが直面したエラーの中央値はたったの1件。AIが完璧に動くコードを提示してくれるため、壁にぶつかる機会そのものが奪われてしまっていた。
摩擦はバグではなく、機能だ（Friction is a feature, not a bug）。
学習プロセスにおけるエラーやつまずきは、避けるべきネガティブな出来事ではなく、脳の中に新しいメンタルモデルを構築するために不可欠な仕組みだったのだ。
6つのAI使用パターンとスコアの分布
AIグループのうちスクリーン録画が取得できた25名を質的分析（手動アノテーション）した結果、24名が以下の6パターンに分類され、スコアに大きな開きが生じた。
低スコアパターン（クイズ平均24〜39%）
| パターン | n | 完了時間 | クイズスコア | 特徴 |
|---|---|---|---|---|
| AIに丸投げ | 4 | 19.5分 | 39% | コード生成のみ要求、貼り付けて完了 |
| 漸進的AI依存 | 4 | 22分 | 35% | タスク1では自力、タスク2は全依存 |
| 反復AIデバッグ | 4 | 31分 | 24% | エラーをそのままAIに貼り付け、5〜15クエリ繰り返す |
高スコアパターン（クイズ平均65〜86%）
| パターン | n | 完了時間 | クイズスコア | 特徴 |
|---|---|---|---|---|
| 生成→理解 | 2 | 24分 | 86% | コード生成後、「このコードはどう動くの？」と追加質問 |
| コード＋説明の複合 | 3 | 24分 | 68% | 「コードを書いて＋各行を説明して」を一緒に要求 |
| 概念質問のみ | 7 | 22分 | 65% | コード生成は要求せず、概念・仕組みだけ質問 |
脳に汗をかいているかが唯一の分かれ道
ここで研究が示した非常に重要な発見がある。「物理的にコードをコピペしたか、手で打ったか」は学習効果にほぼ影響しなかったのだ。
決定的な違いを生んでいたのは、認知的負荷（cognitive load）の有無だった。
「AIに丸投げ」と「生成→理解」は表面上よく似ている。どちらもAIにコードを生成させ、そのコードを使う。違いは一点だけ──後者は「生成後に理解を確認する質問を追加する」かどうかだ。その一手間が、スコアの差（39% vs 86%）を生んだ。
つまり、AIを使って作業のショートカットをしてもいいが、理解へのショートカットをしてはいけない。AIをコードの自動販売機として扱うのではなく、自分の理解を深める対話相手として使うこと。それが、スキルを失わずにAIを活用する唯一の方法だった。
AIは思考の代行者にも、思考の触媒にもなる。どちらになるかは、ユーザーの姿勢で決まる。
限界と今後の課題
- チャット型AIのみを対象: エージェント型AIツール（コードを自律的に書くもの）では、ユーザーが頭を悩ませてプロンプトを打ち込む機会すら奪われる。認知的負荷がさらに低下し、スキル喪失がより深刻になる可能性が高い
- 実験期間が短い: 実際のスキル形成は数ヶ月〜数年にわたる。長期的な縦断研究が必要
- 参加者の動機: 実際の仕事でのスキル習得とは動機が異なる可能性がある
- プロンプトスキルの測定なし: AI使用歴のみ自己申告で、プロンプト技術の差を測定できていない
- 人間によるアシスト比較なし: AIと比較してペアプログラミングや指導者からのサポートがスキル形成にどう影響するかは未検討
まとめ
- AIアシスタントは、平均的にはスキル習得を低下させる傾向が確認された: RCTにより、AIアシスタント使用でクイズスコアが17%低下することが因果的に示された。タスク完了時間への有意な効果はなかった
- 摩擦こそが学習の燃料: AIによってエラーに直面する機会が減ることで、Trioの根幹概念を習得するチャンスが失われた。うまくいかない経験が、最終的には深い理解につながる
- コピペか手打ちかより、「脳に汗をかく」かが重要: 決め手は物理的な作業量ではなく、AIのアウトプットに対して自ら考え・質問し続けるかどうかだった
- エージェント型AIはさらなるリスク: 本研究はチャット型AIを対象としているが、チャット型でもこれだけのスキル低下が起きる。人間の思考プロセスをより多く代替するエージェント型AIでは、スキル喪失が一層加速する可能性がある
最後に
AIはアウトプットへの近道にはなる。しかし、コンピテンスへの近道にはならない。
この研究は「AIを使うな」という主張をしているわけではない。ChatGPT Study ModeやClaude Codeの教育モードのように、学習を支援するAIの活用様式が今後さらに重要になることを示している。重要なのは生産性だけでなく、スキル習得のサステナビリティをAI時代の指標として組み込むことだ。
次にAIにコードを書かせるとき、あなたはこう問い返しているだろうか。 「なぜこのコードは動くのか？」