Post
JA EN

「とにかく作って壊す」が最強の学習法だった——失敗の高速サイクルとAIによる加速

Posted
By
38 min read
「とにかく作って壊す」が最強の学習法だった——失敗の高速サイクルとAIによる加速
  • 想定読者： ソフトウェアエンジニア（特にプログラミングで成長してきた実感がある人）
  • 前提知識： プログラミング経験（言語問わず）
  • 所要時間： 約10分

概要

「賢者は歴史に学び、愚者は経験に学ぶ」——ビスマルクに由来するとされる言葉だ（原文のニュアンスは「愚者は自分の経験から学ぶが、私は他人の経験から学ぶことを好む」に近い）。いずれにせよ、教科書やベストプラクティスから学ぶのが賢い方法で、自分で失敗して学ぶのは愚かな方法とされる。

教科書やマニュアルを読まなかったわけではない。読んだ。ただ、読んだだけでは「学んだ」という感覚が得られなかった。知識としては頭に入る。でも、自分のものになった気がしない。自分の手で作ってみて、壊れて、なぜ壊れたか考えて、作り直す——このサイクルを経て初めて「ああ、わかった」という感覚が来る。振り返ると、自分は手を動かして学ぶタイプなのだと思う。

ベストプラクティスは「知って」いた。でも、知っていることと自分のプロジェクトで最適解を見つけられることは別だった。

この「作る→壊す→考える→作り直す」のサイクルには、学術的な裏付けがある。Kolbの経験学習理論は、具体的経験と内省の繰り返しが学習の本質だと主張し1、Kapurの「生産的失敗」研究は、正解を教わる前に自力で失敗した学習者のほうが概念理解で有意に優れることを12,000人超のデータで示している2。

そして今、AIがこのサイクルを加速している。面白いことに、失敗の対象が変わった。AIがコードを書いてくれるようになった結果、「コードの書き方」で失敗することは減った。代わりに「何を作るか」「どう構造化するか」という上流の判断で失敗し、学ぶ場面が増えた。失敗のサイクルが速くなり、しかもそのサイクルがより本質的な判断力の鍛錬に向かっている。

これは「AIを上手く使っている」のか？ 違う。トークン効率もプロンプト設計も気にしていない。ただ使い倒しているだけだ。しかし複数の大規模研究は、スキルが高い人ほどAIの恩恵が小さいことを示している3。優秀な人がAIの使い方を最適化している間に、愚直に壊して学ぶ人のほうがサイクルを回している——この逆説が、本記事のテーマだ。

「知っている」と「わかっている」の距離

かつてLaravel 6を使っていた頃の話だ。フレームワークの作法は理解していた。MVCも、SOLID原則も読んだ。問題は、知識として知っていることと、自分のプロジェクトでどう適用すべきかがわかることは、まったく別の能力だったということだ。

ネットで「Repositoryパターン」を知り、すべてのモデルに適用した。結果、シンプルなCRUDに4層の抽象化がかぶさる過剰設計が出来上がった。次のプロジェクトでは逆にシンプルに倒した。そこで初めて「抽象化にはコストがある」という判断基準が自分の中にできた。Serviceクラスの粒度でも、巨大Service → 過剰分割 → ちょうどいい粒度と3回作り直した。パフォーマンスチューニングでも、ベストプラクティスを機械的に適用して別の問題を生んだ。

パターンは共通している。ベストプラクティスを知る → そのまま適用する → 問題が出る → なぜかを考える → 自分のコンテキストに合った形を見つける。 教科書が教えてくれるのは「何を」の部分だ。「いつ・どの程度・なぜそうすべきか」は、自分で試して壊さないとわからなかった。

なぜ「壊す」と学べるのか

生産的失敗——正解の前に失敗したほうが深く学べる

Manu Kapur（ETH Zurich）の「生産的失敗（Productive Failure）」研究が面白い。従来の教育は「正しい方法を教える→練習する」の順だが、Kapurはこれを逆転させた。「まず自力で取り組ませる（失敗する）→ その後で正しい方法を教える」。

Sinha & Kapur（2021）のメタ分析は、12,000人超・166実験の比較で、生産的失敗群が概念理解と応用力で有意に優れていることを示した2。効果量g=0.36、設計原則の遵守度が高い場合はg=0.58にまで上がる。しかも効果が出るのは、手続き的知識（解き方を覚えること）ではなく概念理解と転移（なぜそうなるかの理解と、新しい場面への応用）だ。

これは先ほどの体験と一致する。Repositoryパターンの書き方は教科書で覚えられる。だが「このプロジェクトにはどの程度の抽象化が適切か」は、過剰設計で苦しんだ経験から判断できるようになった。

経験学習サイクル——回転数が学びを決める

Kolbの経験学習理論（1984年）は、学習は4段階のサイクルで進むと提唱している1。

flowchart TB
    CE["具体的経験<br>作ってみる・壊れる"]
    RO["内省的観察<br>なぜ壊れたか考える"]
    AC["抽象的概念化<br>原則を理解する"]
    AE["能動的実験<br>作り直す"]

    CE --> RO --> AC --> AE --> CE

重要なのは、このサイクルの回転数だ。1回の失敗で学べることは限られる。3回、5回と回すことで理解が深まる。Ericssonの意図的練習研究（1993年）も、スキル習得の鍵は単なる反復ではなく即時フィードバックを伴う意図的な反復であることを示している4。フィードバックが速いほど、サイクルは速く回る。

ここに、AIが入ってくる。

AIが変えたもの

失敗の対象が上がった

AIを使い始めて、失敗の対象が変わった。

かつての失敗は「コードの書き方」だった。どのパターンを使うか、どう実装するか、パフォーマンスをどう出すか。AIがコードを書いてくれる今、その種の失敗はほぼなくなった。

代わりに増えたのは、もっと上流の失敗だ。そもそも何を作るべきか。どういうアーキテクチャで組むべきか。どこまで作り込むべきか。ユーザーが本当に欲しいものは何か。コードは正しいのに、作るものが間違っている。

面白いのは、この上流の失敗も「作って壊す」サイクルで学べるということだ。AIがコード実装を引き受けてくれるおかげで、「作ってみて、触ってみて、違うと気づいて、方向を変える」が設計・要件レベルで高速に回せるようになった。かつては一つのアーキテクチャを試すのに数週間かかった。今はAIと一緒に1日で複数のアプローチを試して、比較して、判断できる。

サイクルの構造は同じだが、回転速度が上がり、失敗のレイヤーが一段上がった。

失敗のコストが下がった

Kapurの生産的失敗が示したのは、失敗そのものが学習の必要条件だということだ2。失敗は学習の障害ではなく、学習の燃料だ。AIは、この燃料を安く大量に供給してくれる。

「自分で選んだ熱湯」だけが人を強くするで使った比喩を借りれば、AIは熱湯の温度を変えるのではなく、熱湯に浸かるサイクルの回転数を上げてくれる。同じ温度の熱湯に、もっと多く、もっと速く浸かれるようになった。

「上手く使う」と「使い倒す」の違い

優秀な人ほどAIの恩恵が小さい逆説

複数の大規模研究が、直感に反する結果を示している。Harvard/BCGの研究ではトップ層のコンサルタントの成果改善が17%だったのに対し、平均以下の層は43%改善した。Brynjolfssonらのカスタマーサポート研究でも、低スキル層の生産性向上（34%）が全体平均（14%）を大きく上回っている3。

なぜ優秀な人のほうが恩恵が小さいのか。

一つには、高いスキルを持つ人ほど「正しいやり方」が自分の中にあり、AIの出力との摩擦が大きいことがある。検証コストが自分で書くコストを上回る。

しかしもっと根深い問題がある気がしている。優秀な人ほど、AIの「使い方」を最適化しようとしてしまうのではないだろうか。トークンの消費をいかに抑えるか。プロンプトをどう構造化すれば最小限のやり取りで正確な出力が得られるか。APIコストをどう管理するか。

これらは確かに技術的には重要だ。しかし学びという観点では本質から外れている。AIの使い方を最適化している時間は、何かを作って壊して学んでいる時間ではない。ツールの効率を上げることと、自分の判断力を上げることは別の活動だ。

「使い倒す」とはどういうことか

愚直に「作って壊して考える」タイプの人は、そもそもAIの使い方を最適化しようとしない。トークンがいくら飛ぼうが、プロンプトが雑だろうが、とにかく作りたいものにぶつけてみる。壊れたら原因を考えて、次に進む。AIの使い方が洗練されていないぶん、学びのサイクルそのものは止まらない。

「AIを上手く使う」は、ツールの効率を追求する姿勢だ。「AIを使い倒す」は、学びのサイクルを止めない姿勢だ。どちらが「賢い」かは場面による。しかし成長という観点では、サイクルの回転数がすべてだ。

ただし、研究は重要な条件も示している。Alanazi et al.（2025年）の35件の対照研究によるメタ分析では、AIツールがタスク完了時間の短縮と成績向上には有意に効果がある一方、「理解の深さ」への効果は統計的に有意ではなかった5。さらにAI支援で新しいライブラリを学んだ開発者の理解度テストが17%低下したという報告もある6。

AIを使い倒しても、「なぜそうなるのか」を自分で考えなければ、サイクルは回らない。 壊れたときにAIに「直して」と頼むだけなら、Kolbのサイクルの「内省的観察」と「抽象的概念化」——つまり学びの核心——がスキップされている。

学べるサイクル: AIを使い倒して作る → 問題に気づく → 自分で「なぜ？」を考える → 判断基準が自分の中にできる → また作る

学べないサイクル: AIに作らせる → 問題が出る → AIに直させる → また作らせる

違いは一つだけだ。「なぜ？」を自分で考えるフェーズがあるかどうか。

なお、本記事は「学びたいが、やり方を模索している人」を想定して書いている。そもそも学ぶ意思がない場合や、答えだけを得られればよいという場合には、このサイクル自体が回らない。それは動機づけの問題であり、本記事のスコープとは異なる。

業務外だから壊せる

ここまで「失敗して学べ」と書いてきたが、前提条件がある。失敗しても大丈夫な環境が必要だ。

仕事では失敗を容易に許すわけにいかない。本番環境を壊したら顧客に迷惑がかかる。だから業務コードで「とりあえず作って壊す」を気軽にやるわけにはいかない。業務ではベストプラクティス——つまり「歴史」——から学ぶのが正しい。

しかし業務外なら話は別だ。個人プロジェクトでは、失敗のコストが文字通りゼロだ。誰にも迷惑をかけない。締め切りもない。心理的安全性が完全に確保された状態で、思い切り壊せる。

Kapurの研究でも、生産的失敗が機能する条件として「心理的安全性がある環境」が挙げられている2。失敗が罰されない環境でなければ、人は失敗を避ける。失敗を避ければ、サイクルは回らない。

ただし、ここで一つ注意がある。「安全に失敗できる」は「簡単に成功できる」ではない。

心理的安全性と認知的困難は別の軸だ。業務外の個人プロジェクトは「失敗しても誰にも迷惑をかけない」という意味で安全だが、取り組む問題の難しさ自体は変わらない。自分の設計が破綻したときの「なんでこうなる」という悔しさは、誰に見せるわけでもなくても発生する。「自分で選んだ熱湯」だけが人を強くするの言葉で言えば：

  • ぬるま湯: 問題が簡単すぎる → 成長しない
  • 適温の熱湯を安全な場所で: 問題は難しいが、失敗しても大丈夫 → 成長する
  • 沸騰を危険な場所で: 問題が難しく、失敗したら終わり → 萎縮する

安全なのは環境であって、問題が簡単になるわけではない。 重要なのは、熱湯の温度（認知的な挑戦）を維持したまま、火傷しても治療費がかからない場所（心理的安全性）を確保することだ。

AIが効いてくるのはここだ。かつて業務外で何かを作ろうとすると、環境構築だけで半日、動くものができるまで数日かかった。仕事で疲れた後にそれをやるのはハードルが高かった。AIがそのハードルを劇的に下げた今、「業務外で失敗し放題の実験場を持つ」ことのコストが、かつてないほど低くなっている。

業務ではベストプラクティスを守る。業務外では手を動かして壊す。教科書で得た知識を、自分の手で「わかった」に変換する場所を持つ。このハイブリッドが、自分にとって一番しっくりくるスタイルだ。

余談: この記事自体が「作って壊す」だった

実はこの記事も、一発で書けたわけではない。AIと一緒に書いたのだが、最初のドラフトは初心者レベルの失敗談を詳細に書いて的外れだった。次にコード例を大量に入れて技術記事のようになった。視点を足すたびにパッチワークになっていき、最終的に一から書き直した。

記事の中身そのものが「作る→壊す→考える→作り直す」のサイクルを回していた。AIがドラフトを高速で書いてくれるから、壊して書き直すコストが低い。だから気軽に「違うな、やり直そう」と言える。これがまさに、本文で書いた「失敗のコストが下がると、サイクルの回転数が上がる」の実例だった。

まとめ

「とにかく作って壊す」は、頭の悪い学習法ではない。学習科学が裏付ける、効果的な学習メカニズムだ。

  • Kapurの研究は、正解の前に失敗を経験した群が概念理解で有意に優れることを12,000人超のデータで実証した（g = 0.36〜0.58）2
  • Kolbの経験学習理論は、具体的経験→内省→概念化→実験のサイクルが学習の本質であると示した1
  • Ericssonの研究は、即時フィードバックを伴う意図的な反復がスキル習得の鍵であることを示した4

AIはこのサイクルを加速する。失敗のコストを下げ、フィードバックを即時化し、サイクルの回転数を上げる。しかも失敗の対象がコードレベルから設計・要件レベルに上がることで、より本質的な判断力が鍛えられる。

AIの使い方を最適化する必要はない。トークン効率を気にする暇があったら、もう一回壊して考えたほうがいい。ただし、一つだけ条件がある。「なぜ壊れたか」を自分で考えること。 この「なぜ」だけは外注できない。

自分にとってAIは、熱湯の温度を下げてくれる装置ではない。同じ温度の熱湯に、もっと速く飛び込み直せるようにしてくれる踏み台だ。使い倒せばいい。どうせ壊すんだから。

「自分で選んだ熱湯」だけが人を強くするでは、自己決定理論とストレス科学のエビデンスから「成長する苦労の条件」を検証しました。本記事は、その条件を実際のプログラミング学習で実践するとどうなるか——という体験と科学の交差点を描いたものです。

関連記事

このテーマに関連する他の記事もご覧ください：

参考資料

本文中の引用番号に対応する参考資料を番号順に記載しています。

その他参考資料（本文中で番号引用なし）

  1. Experiential Learning: Experience as the Source of Learning and Development - Kolb, D. A., Prentice Hall (1984; 第2版 2015). 経験学習理論の原典。「具体的経験→内省的観察→抽象的概念化→能動的実験」の4段階サイクルを提唱。【信頼性: 高】 ↩︎ ↩︎2 ↩︎3

  2. When Problem Solving Followed by Instruction Works: Evidence for Productive Failure - Sinha, T. & Kapur, M., Review of Educational Research, Vol.91, No.5, pp.761–798 (2021). DOI: 10.3102/00346543211019105. 査読済み。12,000人超・166実験比較のメタ分析。生産的失敗群が概念理解と転移でg=0.36（設計原則遵守が高い場合g=0.58）の有意な優位性を示した。Kapurの研究体系では心理的安全性が生産的失敗の設計条件の一つとして位置づけられている。【信頼性: 高】 ↩︎ ↩︎2 ↩︎3 ↩︎4 ↩︎5

  3. AIスキルギャップ研究2件の統合引用。(1) Generative AI at Work - Brynjolfsson, E., Li, D. & Raymond, L. R., The Quarterly Journal of Economics, Vol.140, No.2, pp.889–942 (2025). 査読済み。5,179人のカスタマーサポートを対象。低スキル層の生産性が34%向上（全体平均14%）。(2) Navigating the Jagged Technological Frontier - Dell’Acqua, F. et al., Harvard Business School Working Paper (2023). 758人のコンサルタントを対象。平均以下の層の成果が43%改善（トップ層は17%）。【信頼性: 高】 ↩︎ ↩︎2

  4. The Role of Deliberate Practice in the Acquisition of Expert Performance - Ericsson, K. A., Krampe, R. T., & Tesch-Römer, C., Psychological Review, Vol.100, No.3, pp.363–406 (1993). DOI: 10.1037/0033-295X.100.3.363. 査読済み。引用数9,000件超。意図的練習の定義——即時フィードバック、明確なタスク、反復機会、誤りの活用——を確立したセミナル論文。ただしMacnamaraのメタ分析（2014年, DOI: 10.1177/0956797614535810）は、意図的練習がパフォーマンス分散を説明する割合は領域により異なる（ゲーム26%、音楽21%、教育4%）ことを示しており、唯一の要因ではない。【信頼性: 高】 ↩︎ ↩︎2

  5. The Influence of Artificial Intelligence Tools on Learning Outcomes in Computer Programming: A Systematic Review and Meta-Analysis - Alanazi, M., Soh, B., Samra, H. E., & Li, A., Computers, Vol.14, No.5, p.185 (2025). DOI: 10.3390/computers14050185. 査読済み。35件の対照研究。AIツールはタスク完了時間の短縮（SMD = −0.69）と成績スコア向上（SMD = 0.86）に有意に効果がある一方、「学習の成功」への効果は非有意（SMD = 0.16, p = 0.41）。【信頼性: 高】 ↩︎

  6. AI Coding and Skill Formation — AI支援を使って新しいコーディングライブラリを学習した開発者は理解度テストで17%低下。高スコア群はAIを「理解を深める対話相手」として使用、低スコア群は「コード生成の完全委任」パターン。報道: InfoQ (2026). 【信頼性: 中〜高】（元研究の詳細な方法論が公開情報からは確認困難なため） ↩︎

キャリア・働き方
学習 プログラミング AI 経験学習 失敗 成長
This post is licensed under CC BY 4.0 by the author.