AI でプログラミングを学ぶなら、脳を AI に外注しない

Q: プログラミングの学習中に ChatGPT を使うのはズルですか？

受講しているコースが禁止していない限り、ズルではありません。リスクは、演習が教えようとしていたことを飛ばしてしまう点にあります。エラーや概念の説明を AI に頼むのは、家庭教師に質問するのと同じです。解答を書かせてしまうと、その演習ではもう何も鍛えられません。

Q: AI が書いたコードを本当に理解しているか、どうすればわかりますか？

助けを借りずに変更してみてください。機能を追加する、新しいエッジケースに対応する、ある 1 行を消したら何が起きるかを言ってみる、といった方法です。実行する前にコードの動きを予想できるなら、理解しています。実行して確かめることしかできないなら、見覚えがあるだけです。見覚えがあるという感覚は、その最中には理解と区別がつきません。これはまさに Soderstrom と Bjork が指摘しているずれです（Soderstrom & Bjork、2015 年）。

Q: プログラミングにおける認知的オフロードとは何ですか？

構造やアルゴリズム、修正方法を自分で考えるかわりに、AI に決めさせることです。スキルが身についたあとなら効率的なやり方です。まだスキルを身につけている途中だと、オフロードが練習の代わりになってしまいます。研究でも、オフロードが多いほど批判的思考が弱いという関連が示されています（Gerlich、2025 年）。

Q: 初心者はどの段階から AI コーディングツールを自由に使ってよいですか？

ループ、関数、map、struct、エラー処理、簡単な HTTP ハンドラーといった基礎を、何も調べずに書けるようになってからです。そこから先は、すでに理解している作業を AI が速くしてくれます。初めての並行処理のコードや初めてのデータベース層など、新しいことを始めるときには、そのたびに手で書くやり方に戻りましょう。

Q: AI はジュニア開発者に取って代わるのでしょうか？

価値を保ち続けるための道筋は、研究からはっきり見えています。Stanford の研究者たちは、AI が形式化でき、検証できる作業を引き受けつつある一方で、実際に手を動かすことでしか得られない理解、つまり暗黙知を置き換えるのは得意ではないと見ています（Stanford Digital Economy Lab、2025 年）。その部分は自分の手で伸ばせます。AI が書いたものをデバッグし、レビューし、説明できるジュニアは、ツールにはないものを持ち込めるうえに、AI を使えばさらに速く進めます。

プログラミングを学んでいるとき、完成したプログラムは副産物にすぎません。作っているのはメンタルモデル、つまりコードが何をしていて、なぜ壊れるのかという頭の中の像です。AI はコードなら数秒で書けます。でも、その像を代わりに作ってはくれません。学んでいる最中に考える作業まで AI に任せると、動くプログラムは手元に残っても、その理解は薄いままです。そしてその差は、あとで何かが壊れたときに表に出てきます。

要約

動くコードは、理解したという感覚を生みます。もともとつまずいていた初心者の中には、AI の助けを借りて課題を終えたあと「できたつもり（illusion of competence）」になり、実際より自分はうまくやれたと思い込む人がいました（Prather et al., ICER、2024 年）。
自分で生み出していないものは、記憶に残りにくくなります。LLM を使ってエッセイを書いた人は、数分後に自分の文章を引用するのに苦労しました。この研究はまだ査読を経ていません（Kosmyna et al., MIT Media Lab、2025 年）。
オフロードが多いほど、批判的思考は弱くなります。666 人を対象にした研究では、AI をよく使う人ほど批判的思考の得点が低く、認知的オフロードがこの関係を統計的に媒介していました（Gerlich, Societies、2025 年）。
エントリーレベルの仕事は変わりつつあります。22〜25 歳のソフトウェア開発者の雇用は、2022 年後半のピークから 2025 年 9 月までに 20% 近く減りました（Stanford Digital Economy Lab、2025 年）。
習慣が、考える作業を自分の手に残してくれます。まず自分で挑戦する。答えではなくヒントを求める。結果を自分で説明し直す。翌日、空のファイルから作り直す。

脳を AI に外注するとは、どういうことでしょうか？

脳を外注するとは、演習がそもそもやらせようとしている頭の作業を、AI にやらせてしまうことです。心理学ではこれを認知的オフロード（cognitive offloading）と呼びます。本来なら自分でする思考を、道具に肩代わりさせることです。計算なら電卓が、道順なら地図アプリがそれをしてくれます。経験豊富な開発者なら、ボイラープレートを任せてもほとんど損はありません。理解はすでに頭に入っているからです。ところが学習者にとっては、その頭の作業こそがスキルの源です。そこを手放すと、手元に残るのは出力だけで、ほかにはほとんど何も残りません。

どんなときに自分でコードを打ち、どんなときに提案を受け入れるかという、もっと絞った問いについては、対照試験を順に見ていく別の記事今でもコードは手で書くべき？があります。ここで考えるのは、アシスタントを使いながら学ぶときに頭の中で何が起きていて、それが 1 年後にどんなコストになるのか、という問いです。

動くコードができると、なぜ理解した気になるのでしょうか？

脳は、物事がどれだけスムーズに進むかを手がかりの 1 つにして、理解できているかどうかを判断します。そして AI は、何もかもをスムーズにします。プロンプトを貼り付ければコードが出てきて、それが動く。この流暢さは、実力と取り違えやすいものです。

学習科学の研究者たちは、このずれを何十年も測ってきました。Nicholas Soderstrom と Robert Bjork は研究をレビューし、練習中の成績は学習が起きたかどうかの「信頼できない指標であることが多い」と結論づけています。さらに「人は習得中の自分の成績を、長期的な学習の信頼できる目安だと誤って解釈することが多い」ことも見いだしました（Soderstrom & Bjork, Perspectives on Psychological Science、2015 年）。読み直すかわりに思い出そうとするなど、その場ではきつく感じる条件のほうが、長く残る学習につながることがよくあります。Bjork の研究室はこれを「望ましい困難（desirable difficulties）」と呼んでいます（Bjork Learning and Forgetting Lab）。

2024 年と 2025 年に行われた AI 利用の研究も、同じ方向を指しています。

つまずいている初心者は「できたつもり」で終わることがある

James Prather らは、生成 AI を使える状態で初心者プログラマーが問題を解く様子を、21 回のラボセッションで観察しました。観察に加えて、インタビューとアイトラッキングも使っています。21 人中 20 人の学生が問題を解き終えました。もともとつまずいていた学生はメタ認知の面での難しさを最初から抱えており、AI は「それを増幅し、さらには新たなメタ認知の難しさを持ち込むことがある」とされています。そのうちの何人かは「実際よりもうまくやれたと思い込み、できたつもりのまま課題を終えた」のです（Prather et al., ICER、2024 年）。一方、メタ認知のスキルが高い学生は AI をうまく使いこなしていました。論文のタイトル「The Widening Gap」（広がる格差）はここから来ています。

経験豊富な開発者も見誤ります。METR の 2025 年の試験では、AI を使った開発者の作業時間は 19% 延びたのに、本人たちは 20% 速くなったと信じていました（METR、2025 年）。この結果は今でもコードは手で書くべき？でより詳しく取り上げています。何年も経験がある人でさえ自分の進み具合を読み違えるのなら、初心者にはなおさら判断の手がかりがありません。

労力をかけないと、記憶にも残らない

MIT Media Lab の研究者たちは、54 人に LLM、検索エンジン、あるいは道具なしのいずれかでエッセイを書いてもらい、その間の脳活動を EEG で記録しました。道具なしのグループでは、脳のネットワークがもっとも強く、もっとも広くつながっていました。検索を使った人はその中間で、LLM を使った人の結合はもっとも弱いものでした。LLM を使った人は、数分前に書いたばかりのエッセイについて「自分の文章を正確に引用するのに苦労した」ともいいます（Kosmyna et al., MIT Media Lab、2025 年）。この研究はプレプリントで、まだ査読を経ていないので、初期の証拠として受け止めてください。対象はコードではなくエッセイですが、仕組みはこの記事のテーマそのものです。自分で生み出していないものは、記憶に残りにくいのです。

より大規模な調査でも、似た結果が出ています。Michael Gerlich は 666 人を調べ、「AI ツールの頻繁な使用と批判的思考力の間に有意な負の相関があり、その関係は認知的オフロードの増加によって媒介されている」ことを見いだしました。若い参加者ほど AI に頼る度合いが大きく、得点も低くなっていました（Gerlich, Societies、2025 年）。相関研究なので、AI が思考力を弱めることを証明するものではありません。ただ、オフロードが多いと答えた人ほど批判的思考の得点が低いことは示しています。

近道のツケはどこで回ってくるのでしょうか？

理解を飛ばしたことには、飛ばしたその日には気づきません。気づくのはあとになって、AI では足りないときや、AI が使えないときです。

理解していなかった panic をデバッグするとき

初めての Go のサービスで、インメモリキャッシュをアシスタントに書いてもらったとしましょう。すべてを初期化する NewCache コンストラクタがあって、どのテストでも問題なく動いていました。ところが、新しく追加されたコードパスが struct を直接作ります。

example.gogo
type Cache struct {
	items map[string]string
}

func (c *Cache) Set(key, value string) {
	c.items[key] = value
}

func main() {
	c := &Cache{}
	c.Set("session:42", "user-1893")
}

example.texttext
panic: assignment to entry in nil map

map を手で何十回か書いたことがあれば、すぐにピンとくるはずです。map のゼロ値は nil で、nil の map から読むのは問題ないのに、書き込むと panic になります。直し方は 2 つあります。1 つは Set に nil チェック（c.items = make(map[string]string)）を入れて、ゼロ値のままでも使えるようにすること。もう 1 つは、キャッシュが独立したパッケージにあるなら items を非公開のままにして、呼び出し側は NewCache を使うべきだとドキュメントに書くことです。ゼロ値がなぜこう振る舞うのかは Go の var と make の違いで解説しています。map のコードを受け入れたことしかなければ、見た目はまったく普通の行で起きた panic を前にして、どこから手をつければいいのか見当もつかないでしょう。

コードレビューの質問に答えられないとき

レビュアーから、ハンドラーでなぜポインタレシーバーを使っているのか、あるいは一度も読まない context.Context をなぜ関数に渡しているのか、と聞かれたとします。自分で書いたコードなら、答えられます。たとえその答えが「そこは間違えていました」であってもです。受け入れただけのコードだと、言えることが何もありません。同じ差は、考えを説明しながらコードを打つライブコーディング面接でも表に出ます。

自分が書いていないコードベースを読むとき

新人の開発者は、他人のコードを読むことに多くの時間を使います。リクエストがミドルウェアをどう通っていくかを追い、ある設定値がどこでセットされているかを探し、ワーカープールがなぜそのサイズなのかを突き止める。AI はファイルを要約してくれます。けれども、次にどこを見ればいいかがわかるのは、似たコードを書いたことがあって、自分がどこに何を置いたかを覚えているからです。

なぜ今、未経験・ジュニアの開発者ほど理解が重要なのでしょうか？

考えられる理由の 1 つは、AI が得意な作業と、かつてジュニアが採用されていた作業が重なっていることです。Stanford の Digital Economy Lab によると、22〜25 歳のソフトウェア開発者の雇用は 2022 年後半のピークから 2025 年 9 月までに 20% 近く減りました。一方で、経験を積んだ層の雇用は横ばいでした（Brynjolfsson, Chandar & Chen, Stanford Digital Economy Lab、2025 年）。2026 年 8 月の改訂版では、AI の影響を受けやすい職種で働く若年層の雇用は、本来の水準より 19% 低いと推定されています（Brynjolfsson, Chandar & Chen、2026 年）。

著者たちは、AI 以外の要因が関わっている可能性もあると注意を促しています。彼らの説明によれば、AI は「これまでエントリーレベルの採用を正当化してきた、形式化でき、検証できる作業を自動化しつつあるのかもしれない」一方で、「暗黙知を置き換える力はそれほど高くないのかもしれない」というのです。暗黙知とは、実際に手を動かして仕事をすることでしか得られない理解のことです。生成されたコードがなぜ正しいのか、なぜ間違っているのかを見抜く力も、これに含まれます。

なぜ試行錯誤こそが本当の学習なのでしょうか？

メンタルモデルが作られるのは、行き詰まっている間です。混乱して仮説を立て、試してみても、外れることが少なくありません。無駄に思えるその数分間に、学習は起きています。

実際のバグで考えてみます。複数の URL を並行して取得し、どれか 1 つでも失敗したら早めに返る関数を書いたとします。

example.gogo
type result struct {
	body string
	err  error
}

func fetchAll(ctx context.Context, urls []string) ([]string, error) {
	results := make(chan result)
	for _, u := range urls {
		go func() {
			body, err := fetch(ctx, u)
			results <- result{body, err}
		}()
	}

	var bodies []string
	for range urls {
		r := <-results
		if r.err != nil {
			return nil, r.err
		}
		bodies = append(bodies, r.body)
	}
	return bodies, nil
}

テストは通ります。ところが 1 週間後、サービスのメモリがじわじわ増え続け、最後には再起動してしまいます。自分の手で原因を突き止めるなら、だいたい次のような流れになります。runtime.NumGoroutine() を確認すると、数が増え続けています。goroutine プロファイルを取ると、何百もの goroutine が同じ行 results <- result{body, err} で止まっています。この channel から受信するのは誰のはずなのかと考えると、答えは誰もいない、です。fetchAll は最初のエラーで return しているからです。channel はバッファなしなので、残りの送信側はすべて永遠にブロックされます。

手っ取り早い修正は 1 行で済みます。results := make(chan result, len(urls)) とすれば、誰かが読むかどうかに関係なく、どの goroutine も送信して終了できます。context もキャンセルして、ほかのリクエストを早めに止めるのがよりよい修正です。その 1 行を探す過程では、1 行そのものより多くのことを学べます。バッファなしの channel への送信は受信側が現れるまで待つこと、早めの return が goroutine を置き去りにしうること、goroutine プロファイルでどこで止まっているかがわかることです。アシスタントなら最初から修正済みのバージョンを渡してくれたかもしれません。それでも正しいコードは手に入りますが、こうしたことは何も身につかなかったはずです。Concurrency Fundamentals コースでは、このようにブロックする channel のコードを実際に書いて直していきます。

AI を使いながら、脳を外注せずにプログラミングを学ぶには？

AI は、面倒見のいい先輩エンジニアのように扱いましょう。行き詰まったら説明を頼んだり、自分の考えを確かめてもらったりして、演習そのものは自分でやります。

まず自分で挑戦する。時間は区切る

助けを求める前に、1 つの問題に 20〜30 分は自分で取り組みましょう。何を試して、どこで詰まったかを書き留めておきます。このメモは 2 つの点で役に立ちます。問題をはっきり言葉にせざるを得なくなりますし、AI に完全な解答ではなくヒントを出してもらうための十分な文脈にもなります。

答えではなくヒントを求める

アシスタントには、どんな役割を果たしてほしいかを伝えましょう。作業を肩代わりさせるプロンプトと、自分が手を動かし続けられるプロンプトの違いは、たった 1 文であることがよくあります。

作業を肩代わりさせるプロンプト	自分が手を動かし続けられるプロンプト
「この nil map の panic を直して」	「Go を勉強中です。コードは書かないでください。これが panic する理由についてヒントを 1 つだけください。そのうえで、原因に近づけるような質問を 1 つしてください」
「goroutine がリークしないように、この関数を書き直して」	「これが私の関数です。書き直さないでください。負荷がかかったときに goroutine がリークするとしたら、まずどの行を見ますか？その理由も教えてください」
「Go でワーカープールを書いて」	「これからワーカープールを書きます。始める前に何を決めておくべきですか？よくある失敗も教えてください」
「Go の map を説明して」	「Go の map について 3 問クイズを出してください。正解かどうかは、私が答えるまで言わないでください」

右の列では、AI は説明したり質問したりするだけで、コードを書くのは自分のままです。

コードを自分の言葉で説明し直す

アシスタントからコードを受け取ったなら、すべての行を説明できるようになるまで先へ進まないでください。説明はコメントとして書いても、声に出して言ってもかまいません。説明できない行こそ、学びに行くべき行です。説明してみることは、何かを理解したのか、ただ見覚えがあるだけなのかを見分けるいちばん手っ取り早い方法でもあります。

翌日、空のファイルから作り直す

ファイルを閉じて、次の日に空のファイルを開き、何も見ずにもう一度解答を書いてみましょう。時間はかかりますし、ところどころで詰まります。その詰まったところが、まだ身についていなかった部分です。単語カードが効くのと同じ検索練習（retrieval practice）を、コードに当てはめているわけです。

基礎を学ぶ段階では AI を使わない

新しい言語に触れてから最初の数週間は、アシスタントなしで基礎を書きましょう。変数、ループ、slice、map、struct、エラー、そして最初の goroutine です。この時期に AI の補完を使うと、自分で考える前に 1 行ずつ埋められてしまいます。基礎が自然に書けるようになったら、すでに理解している部分についてはツールを再び使えばいいのです。最初の期間のより詳しい計画は 2026 年のプログラミング勉強法にまとめています。生成されたものかどうかに関係なく、コードのデバッグを難しくしてしまう習慣については初心者がやりがちなプログラミングのミス 13 選で取り上げています。

LevelUpGo は、自分でコードを書くことを中心に作っています。どの演習も、概念の解説の隣に AI 補完のない本物の Go エディタがあり、コードがコンパイルを通ってテストに合格して初めて完了になります。まずは Go Fundamentals トラックの最初のコース、Go Basics の無料レッスンから始めてみてください。そのあとは Training Ground の単発の演習で、腕がなまらないようにしておけます。

よくある質問

プログラミングの学習中に ChatGPT を使うのはズルですか？