ADHDとプログラミング独学。続かないのは設計の問題として直せる

プログラミングの独学が途中で止まったとき、その理由を自分の性質に結びつけて説明したくなることがあります。集中が続かないから、興味が移るから、片づけられないから。

けれどその説明には、実務上の欠点がひとつあります。原因を自分の性質に置くと、直せる対象が一つも残らない。

この記事では、独学が止まる場所を具体的な地点として並べ、その地点ごとに「何を変えるか」を書きます。教材の紹介はしません。教材を替えても、止まる地点が同じなら結果は変わらないからです。

---

「続かなかった」を意志の問題にすると、直せるものが残らない

プログラミング学習について、日本で広く引用されている調査があります。株式会社侍が2019年8月13日から20日にかけて298名を対象に行った調査で、プログラミング学習経験者240名のうち87.5%が「挫折を経験した」と回答しています（PR TIMES／株式会社侍、2026年8月27日確認）。

注目すべきは挫折率そのものより、挫折の理由の内訳です。同じ調査で挙がった上位は次の2つでした。

さらに、独学で学んでいた人に限ると「気軽に聞ける環境になかった」は**49%**まで上がります。

この2つは、どちらも学習者の内面の話ではありません。「聞ける相手がいるか」は環境の条件で、「エラーが解決できたか」は情報へのたどり着きやすさの条件です。数字の上でも、脱落は環境側で起きています。

診断の有無にかかわらず、9割近くが同じ地点で止まっているという事実は、そのまま次のように読めます。**止まるのは標準的な出来事で、止まる場所には偏りがある。**であれば、対策も個人の心構えではなく、その場所ごとに用意できます。

なお、この記事は「ADHDだから独学が続かない」という前提を採りません。上の調査は診断の有無を分けていませんし、そもそも87.5%という数字は診断の有無で説明できる範囲を大きく超えています。関係があるのは診断名ではなく、フィードバックの間隔・作業の切り替え回数・成果の見えやすさといった、学習環境の設計変数のほうです。そしてこれらは全て、外側から動かせます。

---

独学が止まる地点は、だいたい5つに絞れる

止まり方を集めると、次の5つに収束します。

1. 環境構築で終わる — 手順の途中でエラーが出て、コードを1行も書かないまま日が暮れる
2. 写経は進むが、自分では書けない — 教材の通りに打てば動く。しかし白紙から書き始められない
3. エラーで止まり、そのまま再開できない — 1つの詰まりが数日空き、空いた分だけ戻りにくくなる
4. 作りたいものが無い — 文法は分かったが、次に何を作るかが決まらない
5. 進捗が見えない — 何時間か使ったのに、前に進んだ実感が残らない

大事なのは、この5つが別々の問題だということです。「続かない」とひとまとめにすると打ち手が1つも出てきませんが、5つに分ければ、それぞれに違う対処が付きます。

そして5つのうち4つは、教材を変えても解決しません。教材選びで解決するのは、せいぜい2番だけです。おすすめ教材の一覧を読んでも状況が変わらなかったとすれば、それは当然の結果でした。

以下、地点ごとに見ていきます。

---

環境構築と「写経は進むが書けない」を、先に外す

環境構築は、飛ばしてよい

最初の脱落地点は、ほぼ確実にここです。しかも環境構築はプログラミングそのものではありません。パスの設定やバージョンの食い違いは、実務では一度きりの作業で、学習の本体とは無関係です。それが最初に来ているのは、単に教材の順番がそうなっているだけです。

対処ははっきりしています。ブラウザーだけで書ける場所から始める。 GitHub の公式ドキュメントは、クラウド上でホストされた開発環境に「ブラウザー、Visual Studio Code、または GitHub CLI を使用して接続できます」と説明しています（GitHub Docs、2026年8月27日確認）。同種のブラウザー完結型の実行環境は他にも複数あり、無料枠の範囲や条件はサービスごとに違うので、始める時点の公式ページで確認してください。

自分のパソコンに環境を作るのは、作りたいものが決まって、そのために必要になった時で間に合います。順番を逆にしているせいで、多くの人が本体に触る前に離脱しています。

「写経は進むが自分で書けない」は、写経の量ではなく形の問題

教材の通りに打つ作業は、打ち込みの正確さを鍛えます。しかし白紙から書く作業に必要なのは、「作りたい状態」を手順に分解する力で、これは別の技能です。前者を何時間積んでも後者は伸びません。ここで「理解が足りない」と判断して教材を最初からやり直すと、同じ場所に戻ってきます。

やり方を変える方法は簡単で、写経したコードを、その場で1箇所だけ壊す／変えることです。

• 色を変える、文言を変える（動くはず、を確認する）
• 条件を反転させる（何が起きるかを予想してから実行する）
• 1行削って、どのエラーが出るか見る

これだけで、作業が「打ち込み」から「予想と検証」に変わります。しかも1回あたり数十秒で結果が返るため、次に述べる「進捗が見えない」問題にも同時に効きます。

---

エラーで止まる時間には、先に上限を決めておく

エラーで止まること自体は避けられません。問題は、止まっている状態が何時間も続き、その日が丸ごと消え、翌日に戻りにくくなることです。復帰が遅れる原因は、詰まったこと自体ではなく、詰まった時間の長さのほうにあります。

ここで有効なのは、能力を上げることではなく、時間の上限を先に決めておくことです。

15分ルール：同じエラーに15分かかったら、必ず外部の情報に切り替える。切り替え先はあらかじめ1つに決めておきます。決めておかないと、切り替えの判断自体が新しい負荷になります。

そのうえで、エラーの読み方を先に覚えると効果が大きく変わります。エラーメッセージは呪文ではなく、種別（name）と説明（message）と発生場所という決まった構造を持っています。MDN の JavaScript エラーリファレンスは、エラーを種別とメッセージで一覧化して解説しています（MDN Web Docs、2026年8月27日確認）。まず一次情報のリファレンスに当たる習慣を作ると、詰まりの多くは検索ですらなく参照で終わります。

生成AIに聞く場合も、聞き方を固定しておくと安定します。

次のエラーが出ました。原因の候補を3つ、可能性の高い順に挙げてください。**修正コードは出さないでください。**エラーメッセージのどの部分から何が読み取れるかを説明してください。

「修正コードは出さないでください」の一文が要点です。理由は次の章で扱います。

---

「作りたいものが無い」と「進捗が見えない」を、設計で埋める

題材が無いのは、興味の問題ではなく在庫の問題

「何を作りたいか」を先に決めさせる進め方は、決められない人をそこで止めます。順番を変えて、自分がすでに毎回やっている面倒な作業から取るほうが確実です。

• 毎月同じ形式で作っている表を、自動で作る
• 買ったものを記録して、月ごとに合計を出す
• 自分だけが使う、条件を入れたら候補が絞られるページ

いずれも「作りたいから作る」ではなく「現に困っているから作る」です。動機を内側から探さずに済み、完成の基準も外から決まります。作りたいものが浮かばないのは、内面の問題ではなく題材の在庫の問題なので、在庫を増やす側で対処できます。

進捗は、記録しないと消える

学習内容は積み上がっているのに、実感だけが残らない。この状態は珍しくありませんが、放っておくと3か月後に「何も進んでいない」という誤った結論になります。

対処は、進捗を目に見える形で外に出すことです。手間の少ない順に3つ。

3つ目の「詰まったこと」の記録が特に効きます。翌日に再開するとき、どこで止まったかを思い出す作業が最大の再開コストになるからです。ここを1行の記録で消すと、間が空いた後でも戻れます。

---

生成AIを独学に使うときの落とし穴

生成AIは、独学の弱点だった「気軽に聞ける相手がいない」を実際に埋めます。前述の調査で最大の挫折理由だった項目です。だからこそ、使い方を間違えたときの影響も大きくなります。

落とし穴1：答えが出すぎて、自分で書けるようにならない

AIに「このコードを書いて」と頼めば、動くコードが返ってきます。それを貼れば動くので、学習は進んだように見えます。しかしこの過程で鍛えられているのは依頼する力であって、白紙から書く力ではありません。前に述べた「写経は進むが自分では書けない」と同じ構造が、より速く強く起きます。

避け方は、AIの役割を先に固定することです。

• 詰まった時：答えではなく、原因の候補と読み方を聞く
• 書き始める前：手順の分解だけ頼み、コードは自分で書く
• 書いた後：レビューさせる（「この書き方の問題点を3つ」）

コードそのものを出させてよいのは、3番目の後です。

落とし穴2：出力が間違っていても気づけない

初学者にとって最も危険なのは、AIが自信のある調子で微妙に違う答えを返すことです。これは初学者だけの問題ではありません。Stack Overflow の2025年開発者調査では、AIツールを使う際の最大の不満として「ほぼ正しいが、少し違う解決策」を66%が挙げ、「AIが生成したコードのデバッグに時間がかかる」を45.2%が挙げています。信頼度も高くなく、出力の正確さを「強く信頼する」は3.1%、「ある程度信頼する」が29.6%である一方、「ある程度信頼しない」が26.1%、「強く信頼しない」が**19.6%**でした（Stack Overflow 2025 Developer Survey、2026年8月27日確認）。

同じ調査では、AIツールを使うか使う予定があると答えた人が84%、プロの開発者の**51%**が毎日使っていると答えています。つまり現場は、信頼しきってはいないが、毎日使っているという状態です。

初学者がここで不利なのは、「ほぼ正しいが少し違う」を検出する材料を持っていないことです。対策は2つあります。

1. 一次情報で照合する。 言語やライブラリの公式ドキュメント、MDN のようなリファレンスに、AIが挙げた関数名や書き方が実在するかを確かめる。実在しない名前を返すことは普通に起きます。
2. 動いたかどうかを判定基準にしない。 動いても間違っている書き方は多く、逆に正しくても環境の都合で動かないことがあります。判定は必ずドキュメント側で行う。

古い情報を返してくることも多いため、「いつ時点の情報か」を明示させるのも有効です。

落とし穴3：AIとの対話自体が目的化する

質問を作り、返答を読み、また質問する。この往復は手応えがありますが、成果物は増えていません。**1日の終わりに残ったものがコードでも記録でもないなら、その日は学習ではなく相談でした。**前章の「スクリーンショット1枚」が、この見分けにそのまま使えます。

---

独学に向かない条件を、正面から見ておく

ここまで対処を並べましたが、**独学が適さない条件は実在します。**能力の話ではなく、条件の話です。次のどれかに当てはまるなら、独学を選び続けること自体が不利になります。

体調に波がある時期。 独学は、止まった時に誰も気づきません。数週間空いた後で自力で戻る前提が置かれています。波の谷が読めない時期に、この前提は成立しにくくなります。

締切が外から来ないと進まない場合。 これは性格ではなく、報酬が届くまでの間隔の問題です。独学は「勉強した」と「役に立った」の間が数か月空きます。この間隔が長すぎる人にとって、独学は構造的に相性が悪い形式です。

フィードバックが無いと判断できない場合。 自分の書いたコードが妥当かどうかは、他人に見てもらわないと分かりません。前述の調査で、独学者の49%が「気軽に聞ける環境になかった」を挫折理由に挙げていたのは、この点です。生成AIはかなりの部分を埋めますが、**「今の自分の水準が就職の基準に届いているか」**という判断だけは、AIには出せません。基準を持っているのは、人を採用している側だからです。

該当した場合、選択肢は「諦める」ではなく「伴走がある環境に替える」です。

厚生労働省は就労移行支援について、就労を希望する障害のある人のうち一般企業に雇用されることが可能と見込まれる人に対して、一定期間、就労に必要な知識および能力の向上のために必要な訓練を行うものと説明しています（厚生労働省「障害者の就労支援対策の状況」、2026年8月27日確認）。事業所によってはAIやITに特化した訓練内容を持つところもあります。

これは独学より上等な方法という意味ではありません。単に、締切と他者の目とスケジュールが最初から入っている形式というだけです。上の3つの条件に当てはまるなら、その3つがそのまま埋まります。当てはまらないなら、独学のほうが速くて安く済みます。

制度の中身、費用、対象になる条件については支援と転職を使うにまとめています。見学だけして使わない判断も普通にありえます。

---

いまの仕事を続けたまま試す道

最後に、順番の話をします。

「プログラミングを独学して転職する」という道は、学習期間中の収入がゼロになるという前提を持っています。そのうえ、学び終わる時点でその技能が求められているかどうかは、始める時点では確定しません。負う側のリスクとしては、かなり重いほうです。

先に試せる、もっと軽い道があります。いまの仕事の中で、面倒な作業をAIで減らす。

• 定型のメールや報告書の下書きを作らせる
• 表の整形や集計の手順を組む
• 議事録や長い資料を要約させる

これには3つの利点があります。第一に、収入が止まりません。第二に、成果が数日で出るので、前に述べた「進捗が見えない」問題が起きません。第三に、これ自体が最も現実的な適性テストになります。手順に分解して、道具に投げて、結果を検証するという作業は、プログラミングの中身とほぼ同じだからです。この過程が面白いと感じたなら独学は続きやすく、苦痛だったなら、その情報は数か月かけて確かめるより先に手に入ったことになります。

具体的な手順とプロンプトはAIを味方にするに置いています。

---

独学が止まったことは、あなたについての情報ではなく、その進め方についての情報です。止まった地点を特定して、そこだけ条件を替える。替えても止まるなら、形式のほうを替える。どちらも、性質を変える必要のない対処です。