0-02 挫折しない学び方とAIの使い方

このページはプロモーション（広告）を含みます。

研究で効果が確かめられた学び方と、AIを「答えを出す機械」ではなく「家庭教師」として使うルールを身につけ、自分の学習計画を立てます。

この章でできるようになること

• 効果の高い学習法（想起練習・分散学習）と低い学習法（再読・ハイライト）を区別し、自分の学習に取り入れられる
• 予想→実行→説明のループと、解答例→穴埋め→自力の順で演習を進められる
• AIに説明・クイズ・段階的なヒントを頼み、丸投げを避ける使い方ができる
• 詰まったときに、エラーを読む→最小の再現→仮説→1つ変えて試す、の手順で進められる
• 自分の目的と使える時間から、具体的な学習計画を立てられる

前の章で、この課程が目指す仕事と全体の地図を見ました。この章では、その長い道のりをどう歩くかを決めます。プログラミングの独学は、途中でやめてしまう人が多いことで知られています。やめる理由の多くは才能ではなく、学び方と計画の問題です。

この章で扱うのは3つです。1つ目は、研究で効果が確かめられている学び方と、効果が薄いのに多くの人がやってしまう学び方の違い。2つ目は、AIを学習に使うときのルール。AIはうまく使えば最高の家庭教師になりますが、使い方を誤ると、学んだつもりで何も身につかない状態を作ります。3つ目は、詰まったときの具体的な手順と、自分の時間に合った学習計画です。

この章の内容は、課程のすべての章で使います。特に「予想してから実行する」と「AIに答えではなくヒントを求める」の2つは、今日から習慣にしてください。

効く学び方と効かない学び方

再読は「分かったつもり」を作る

試験の前に教科書を何度も読み返し、大事なところに蛍光ペンを引く。多くの人がこの方法で勉強してきました。ところが、学習法の研究をまとめた有名な論文（Dunlosky ら、2013年）では、この「再読」と「ハイライト」は効果が低いと評価されています。要約を書くことも、効果は限定的とされました。

なぜ効果が低いのでしょうか。再読すると、文章が見慣れたものになり、すらすら読めるようになります。この「すらすら感」を、人は「理解した」と取り違えます。しかし、本を閉じて同じ内容を説明しようとすると、言葉が出てきません。読めることと、思い出せることは別の能力です。

効果が高いのは「思い出す練習」と「間を空けること」

同じ論文で効果が高いと評価されたのは、次の2つです。

1. 想起練習（retrieval practice）：見ないで思い出す練習。小テストを解く、本を閉じて説明してみる、白紙にコードを書いてみる。思い出そうとする行為そのものが、記憶を強くします。正解できなくても、思い出そうとした後に答えを確認すると、ただ読むより記憶に残ります。
2. 分散学習（distributed practice）：同じ内容を一度にまとめて学ぶのではなく、日を空けて何度か学ぶこと。1日に3時間続けるより、1時間ずつ3日に分けるほうが長く記憶に残ります。

この2つは、年齢や教科を問わず効果が確認されています。ただし、研究の多くは学生を対象にしたもので、社会人がプログラミングを独学する場面を直接調べた研究は多くありません。それでも、この課程では最も信頼できる根拠として、この2つを学習の仕組みの中心に置いています。

忘れ方を数字で見る

間を空けて復習すると何が起きるのか、単純なモデルで眺めてみます。ここで使う式は、説明のために作ったおもちゃのモデルで、実際の人間の記憶を測ったデータではありません。「復習するたびに忘れにくくなる」という傾向だけをつかんでください。

アプリで実行できるコード

import math

def retention(days_since_review, strength):
    # 記憶の残り具合（0〜1）。strength が大きいほど忘れにくい（説明用の単純なモデル）
    return math.exp(-days_since_review / strength)

print("一度だけ学んだ場合（strength=2）")
for day in [1, 3, 7, 14, 30]:
    print(f"  {day:>2}日後: {retention(day, 2):.0%}")

print("復習を重ねて strength が 20 まで育った場合")
for day in [1, 3, 7, 14, 30]:
    print(f"  {day:>2}日後: {retention(day, 20):.0%}")

コードの細部は今は読めなくて構いません。出力の2つの表を比べてください。一度学んだだけの記憶は1週間ほどでほとんど消えますが、復習で強くなった記憶は2週間後でも半分ほど残ります。間隔反復（spaced repetition）と呼ばれる復習法は、この性質を利用して「忘れかけたころに思い出す」ように復習の日を決めます。このアプリのクイズの復習も、この考え方で動いています。

解答例から始め、少しずつ手を離す

もう1つ、初学者に効果が確かめられている方法があります。いきなり白紙から問題を解くのではなく、まず解答例をよく読み、次に一部が空欄になった問題を埋め、最後に自力で解く、という順番です。

プログラミングは、文法、データの形、処理の順番、エラーの意味など、同時に頭に入れることが多い分野です。人間が一度に意識できる量（作業記憶、working memory）には限りがあり、白紙からだと容量があふれてしまいます。解答例はその負担を減らします。

さらに、解答例の各部分に「① 入力を用意する ② 変換する ③ 結果を確かめる」のような小目標のラベル（サブゴールラベル）を付けると、理解が深まることが分かっています。大学生307人を対象にした研究では、ラベル付きの解答例で学んだ学生のほうが、より完全な答えを書き、構造の理解も深かったと報告されています。この課程の本文と演習は、この順番とラベルを意識して作っています。

アプリで実行できるコード

# ① 入力を用意する：3回分のクイズの点数
scores = [70, 85, 90]

# ② 変換する：合計を求め、回数で割って平均を出す
total = sum(scores)
average = total / len(scores)

# ③ 結果を確かめる：手計算（70+85+90=245、245÷3≒81.7）と一致するか
print("合計:", total)
print("平均:", round(average, 1))

# から行末まではコメント（comment）で、Pythonは無視します。人間が読むためのメモです。sum(...) は合計、len(...) は個数を返します。ここで注目してほしいのは文法より構造です。どんなプログラムも、多くは「入力を用意する」「変換する」「確かめる」の組み合わせでできています。AIが書いた長いコードを読むときも、まずこの3つの区切りを探すと、全体が見えやすくなります。

予想・実行・説明のループ

ループの3つの手順

この課程で最も多く登場する学習の型が、次のループです。

1. 予想する：出力を紙に書く
2. 実行する
3. 比べる：予想と結果
4. 説明する：自分の言葉で

予想するのは、想起練習の一種だからです。頭の中でコードを1行ずつたどり、変数の値を追いかける。これはまさに、AIが書いたコードを読むときに必要な力そのものです。予想が当たれば理解を確認でき、外れれば理解が欠けている場所がはっきりします。外れた予想こそ、学びの材料です。

試してみます。実行ボタンを押す前に、表示される数を予想してください。

実行前に出力を予想する

x = 10
x = x + 5
y = x * 2
x = 0
print(y)

ポイントは、4行目で x を 0 にしても、y は変わらないことです。y = x * 2 は「その時点の x の値を使って計算し、その結果に y という名前を付ける」という意味で、後から x が変わっても y は追いかけて変わりません。表計算ソフトのセルの数式は、参照先が変わると自動で再計算されます。その感覚で読むと予想が外れます。

説明する

結果を見たら、最後に「なぜそうなるか」を自分の言葉で説明します。声に出しても、メモに書いても構いません。うまく説明できないところがあれば、そこが次に学ぶべきところです。

説明の相手を想像すると、説明しやすくなります。例えば「プログラミングを知らない同僚に、このコードが何をしているかを話す」と考えます。専門用語を使わずに説明しようとすると、自分がどこを本当は分かっていないかが浮かび上がります。この方法はファインマン・テクニックという名前で広く知られています。その名前の方法を直接検証した実験は多くありませんが、自分で説明する行為は想起練習の一種であり、試す価値は十分にあります。

説明は、AIにも聞いてもらえます。自分の説明をAIに渡し、「間違っているところや、曖昧なところを指摘してください」と頼みます。このときも、AIの指摘をそのまま受け入れるのではなく、コードを実行して確かめます。

次の予想は少し難しくなります。

実行前に出力を予想する

words = ["返品", "配送", "返品", "支払い", "返品"]
count = 0
for w in words:
    if w == "返品":
        count = count + 1
print(count, len(words))

for w in words: は「words の要素を1つずつ w に入れて、下の字下げされた部分を繰り返す」、if w == "返品": は「w が『返品』と等しいときだけ、下の行を実行する」という意味です。どちらも Part 1 で詳しく学びます（→ 1-05 条件分岐、→ 1-06 繰り返し）。今は文法を覚えなくてよいので、1回ずつ w と count の値を紙に書き出してたどってみてください。この「値を書き出してたどる」作業は、デバッグの基本の動作でもあります。

このアプリの使い方

学習の流れを作る機能

このアプリは、ここまでに紹介した学び方を自然に実行できるように作っています。主な機能と、その使い方を説明します。

1つの章の進め方

1つの章は、次の順で進めると効果的です。

最後の手順は、想起練習そのものです。まとめを先に読むと「そうそう」と納得して終わりますが、先に自分で書き出すと、思い出せなかった項目がはっきりします。そこが復習すべき場所です。

1章を1回で終える必要はありません。本文と演習を2日に分け、2日目の最初に1日目の内容を思い出してから演習に入ると、分散学習の効果も得られます。

演習の進め方

演習は、易しいものから難しいものへ並んでいます。レベル1は本文の例をほぼなぞれば解ける問題、レベル2は少し応用が必要な問題、レベル3は複数の考え方を組み合わせる問題や、仕様から自分で作る問題です。

詰まったら、ヒントを1つだけ開きます。ヒントは方向を示す1段階目と、ほぼ答えに近い2段階目に分かれています。1段階目を読んだら、もう一度自分で考えてください。いきなり模範解答を見ると、解答例を読むのと同じ効果しかありません。それでも構わない場面はありますが、その場合は模範解答を閉じてから、もう一度自力で書き直してください。それで想起練習になります。

コードを書かない演習（仕様を書く、計画を立てるなど）では、記述欄に自分の答えを書いてから模範解答と比べます。模範解答は唯一の正解ではありません。自分の答えに足りない観点がないかを確かめる材料として使ってください。

メモの書き方

メモには、本文を写すのではなく、次のようなことを書くと効果的です。

• 予想が外れたコードと、外れた理由
• 自分の言葉で書いた、その章の要点の説明（3行程度）
• まだよく分からないこと（次にAIに質問する材料になる）
• 自分の仕事に使えそうなアイデア

AIを家庭教師にするルール

丸投げは学習を止める

前の章で、Anthropic の実験を紹介しました。AIの支援を受けながらプログラミングを学んだグループは、理解度テストで平均50%と、AIなしのグループ（67%）を下回り、特にデバッグの問題で差が大きくなりました。

この結果は「AIを使うな」という意味ではありません。同じ実験で、AIに概念の説明を求めたり、コードと一緒に説明を求めたりした人は、理解をよく保っていました。差を生んだのは使い方です。コードを丸ごと書かせて貼り付けると、自分の頭を使う過程が丸ごと抜け落ちます。学習とは、まさにその過程のことです。

5つのルール

この課程では、学習中のAIの使い方として次のルールを勧めます。

1. まず自分で考える。最低でも10分は自力で取り組み、自分なりの予想や仮説を持ってからAIに聞く。
2. 答えではなくヒントを求める。「答えは言わずに、考える方向だけ教えて」と頼む。足りなければ、もう一段だけ具体的にしてもらう。
3. 説明させ、自分も説明する。AIの説明を読んだら、自分の言葉で言い直し、それが正しいかをAIに確かめてもらう。
4. クイズを出させる。章を読み終えたら、AIに理解度を確かめる問題を出してもらい、本文を見ずに答える。
5. 説明できないコードは使わない。Simon Willison の原則「他人に説明できないコードはコミットしない」を、学習でも守る。AIが書いたコードは、1行ずつ説明できるまで自分のものにしない。

私はPythonを学習中の初学者です。次の演習に取り組んでいます。
答えのコードは書かないでください。代わりに、私が自分で解けるように、考える方向を示すヒントを1つだけください。
私がもう一度質問したら、もう少し具体的なヒントを1つください。

演習の内容：
{演習の問題文}

私が書いたコード：
{自分のコード}

私が考えていること・詰まっているところ：
{自分の考え}

私はプログラミング初学者で、「{章のタイトル}」という内容を学びました。要点は次のとおりです。
{自分のメモ、または章のまとめ}

この内容の理解を確かめる問題を5問、1問ずつ出してください。
暗記ではなく、「このコードの出力は何か」「なぜそうなるか」「どこが誤りか」を問う問題にしてください。
私が答えたら、正誤と理由を説明してから次の問題に進んでください。最後に、私の弱点を1つ指摘してください。

AIが間違えること

AIは家庭教師として優秀ですが、間違えます。初学者が特に注意すべき点を挙げます。

• 存在しない関数やオプションを、もっともらしく説明することがある。
• 料金、モデル名、ツールのコマンドなど、変化の速い情報は古いことが多い。
• 間違いを指摘されると、根拠なく同意して説を変えることがある（追従、sycophancy）。
• 長いコードを書かせると、頼んでいない機能まで加えることがある。

対策は、検証できるものは自分で実行して確かめることです。このアプリでは、AIの説明が正しいかどうかを、コードを実行して数秒で確かめられます。「AIがこう言ったから」ではなく「実行したらこうなったから」を判断の根拠にしてください。

学習の段階に合わせて使い方を変える

AIへの頼り方は、学習の段階で変えていきます。最初から最後まで同じ使い方をするのではなく、自分の力が育つのに合わせて、任せる範囲を少しずつ広げます。

この表のとおり、課程の後半では、コードの多くをAIに書かせます。それが実務の姿だからです。ただし、それができるのは、前半で「読める・直せる・説明できる」力を自分で育てたからです。前半でAIに頼りすぎると、後半でAIの出力の誤りに気づけなくなります。前半は遠回りに見えても、自分の手と頭を使う期間だと考えてください。

詰まったときの手順

4つの手順

プログラミングでは、必ず詰まります。詰まるのは才能がないからではなく、プログラミングという作業がそういうものだからです。大事なのは、詰まったときに何をするかの手順を持っていることです。

実例で手順をたどる

具体例で手順をたどります。次のコードは、CSVから読み込んだ点数の合計を出そうとしています。

score_a = "80"   # CSV から読んだ値（文字列）
score_b = 90
total = score_a + score_b
print(total)

実行すると、次のエラーが出ました。

Traceback (most recent call last):
  File "main.py", line 3, in <module>
    total = score_a + score_b
TypeError: can only concatenate str (not "int") to str

① エラーを読みます。最後の行に TypeError（型のエラー）とあり、「str（文字列）には str しかつなげられない（int ではなく）」と書いてあります。その上の行には、3行目の total = score_a + score_b で起きたことが示されています。

② 問題を小さくします。このコードは既に十分小さいので、エラーの起きる3行目に関わる値だけを調べます。

③ 仮説を立てます。「score_a が文字列で、score_b が整数なので、+ が使えないのではないか」。

④ 1つだけ変えて試します。まず仮説を確かめるために、値の型を表示します。

アプリで実行できるコード

score_a = "80"
score_b = 90
print(type(score_a), type(score_b))

仮説どおり、片方が str、もう片方が int です。そこで、score_a を整数に変換する、という1か所だけを変えます。

アプリで実行できるコード

score_a = "80"
score_b = 90
total = int(score_a) + score_b
print(total)

直りました。ここで終わらずに、なぜ直ったのかを説明できるか確かめます。「CSVから読んだ値は文字列なので、計算に使う前に int で整数に変換する必要がある」。これを説明できれば、次に同じ種類のエラーに出会ったとき、すぐに対処できます。エラーの読み方とデバッグは、→ 1-08 エラーを読み、直す と → 3-06 AIと一緒にデバッグする で本格的に学びます。

AIに質問するときのテンプレート

手順を踏んでも解決しないときは、AIに質問します。そのとき、AIに渡す情報の質が、答えの質を決めます。「動きません」だけでは、AIは推測で答えるしかありません。

Pythonを学習中の初学者です。次のエラーの原因を理解したいです。修正済みのコードを丸ごと書くのではなく、原因の説明と、私が自分で直すためのヒントをください。

やりたいこと：
{何をしようとしているか}

コード（エラーが起きる最小の形）：
{コード}

エラーメッセージ（全文）：
{エラーメッセージ}

期待した結果：
{期待した出力}

実際の結果：
{実際の出力やエラー}

自分で試したこと：
{試したことと、その結果}

環境：
{例：アプリ内のPython / Mac の Python 3.13 / Google Colab}

このテンプレートを埋めようとするだけで、半分くらいの問題は自分で解決します。「期待した結果」と「実際の結果」を書き分けると、違いがはっきりし、原因に気づくことが多いからです。

学習計画を立てる

必要な時間を見積もる

ここからは、自分の学習計画を立てます。まず、目的別ルートごとに、おおよその学習時間を見積もります。数字は目安で、すでにプログラミング経験がある人はもっと速く、まったく初めての人は Part 1 に時間がかかります。

アプリで実行できるコード

import math

# ルートごとの見積もり（時間）。必須章は1章3.5時間、推奨章は3時間で計算
routes = {
    "app（LLMアプリ・エージェント開発）": 57 * 3.5 + 19 * 3 + 150,
    "auto（業務でAI活用）": 16 * 3.5 + 15 * 3 + 30,
    "ml（MLエンジニア志望）": 38 * 3.5 + 35 * 3 + 150,
}

for name, hours in routes.items():
    w10 = math.ceil(hours / 10)
    w20 = math.ceil(hours / 20)
    print(f"{name}: 約{hours:.0f}時間 / 週10時間で{w10}週 / 週20時間で{w20}週")

最後の数（150 や 30）は、総合プロジェクトの時間です。auto ルートでは推奨39章のうち15章ほどを選ぶ想定にしています。

計算上は、app ルートで週10時間なら約40週、つまり9〜10か月です。ただし、仕事が忙しい週や体調を崩す週は必ずあります。余裕を見て、週10時間なら9〜12か月、週20時間なら5〜6か月を目安にしてください。auto ルートなら、週5時間でも半年ほどで必須の内容を終えられます。

毎日少しずつ、復習から始める

分散学習の研究が示すとおり、週末にまとめて10時間やるより、毎日1時間半を続けるほうが記憶に残ります。おすすめの1回の学習の流れは次のとおりです。

1. 復習：10分
2. 前回のメモを読む：5分
3. 新しい章：60分
4. 振り返り：メモを書く 5分

最初の10分の復習が、分散学習と想起練習を同時に実行する仕組みです。アプリの復習でクイズを解き、前回の章の要点を本を閉じて思い出します。復習の日程は、間隔を少しずつ広げるのが基本です。

アプリで実行できるコード

from datetime import date, timedelta

learned = date(2026, 10, 5)      # 学んだ日
intervals = [1, 3, 7, 14, 30]    # 何日後に復習するか

for days in intervals:
    review_day = learned + timedelta(days=days)
    print(f"{days:>2}日後: {review_day}")

date(2026, 10, 5) は日付を表す値、timedelta(days=1) は「1日分の長さ」を表す値です。日付に長さを足すと、その分だけ後の日付になります。

月をまたぐ計算がどうなるか、予想してから実行してください。

実行前に出力を予想する

from datetime import date, timedelta
d = date(2026, 10, 25) + timedelta(days=7)
print(d)
print(d.month)

timedelta を使うと、月末の日数（10月は31日まで）を自分で考えなくても、正しい日付が求まります。日付の計算を自分で「日の数字に7を足す」ように書くと、月末で誤った日付を作ってしまいます。これは実務のコード、特にAIが書いたコードでもよく見る誤りです（→ 1-10 モジュールと標準ライブラリ）。

習慣にするための工夫

計画を立てても、続かなければ意味がありません。続けるための具体的な工夫を挙げます。

• 時間と場所を固定する。「毎朝7時から、台所のテーブルで」のように決めておくと、始めるかどうかを毎回迷わずに済みます。
• 最初の5分のハードルを下げる。疲れている日は「復習のクイズだけ」でも構いません。ゼロの日を作らないことが、1日に長くやることより大切です。
• 進捗を見える形にする。アプリの進捗表示を使い、終えた章が増えていくのを確認します。
• 小さな成果物を作る。数週間に一度、自分の業務で使える小さなスクリプトを作ってみます。学んだことが役に立つ実感は、強い動機になります。
• 人とつながる。成人のプログラミング学習者を調べた研究では、途中でやめた人ほど、他者とのつながりの不足を感じていた傾向が報告されています（小規模な研究なので、参考程度に）。学習仲間やSNSで進捗を報告するだけでも違います。

挫折ポイントを先に知っておく

多くの人が止まる3か所

長い課程では、多くの人が同じ場所で止まります。先に知っておけば、「自分だけができない」と思わずに済みます。

1つ目は Part 1 の後半、関数とクラスです（→ 1-07 関数、→ 1-12 クラスとオブジェクト）。それまでの章は「上から順に実行される」コードでしたが、関数とクラスでは、定義した場所と実行される場所が離れます。頭の中で処理を追うのが急に難しくなります。

乗り越え方：予想ブロックで、どの行がどの順で実行されるかを紙に番号で書き出します。分からないときは、関数の中に print を入れて、いつ呼ばれたかを表示させます。完全に理解できなくても、「関数は入力を受け取って結果を返す箱」として使えれば、先に進んで構いません。使っているうちに分かってきます。

2つ目は Part 2 の環境構築です（→ 2-01 ターミナルとシェル、→ 2-03 Python プロジェクトの作り方）。ブラウザの中で全部動いていた世界から、自分のMacのターミナルに出ていきます。「command not found」のような、コードと関係のないエラーで何時間も止まることがあります。

乗り越え方：次の章（→ 0-03 Macの開発環境を整える）の手順を1つずつ確かめながら進めます。環境のエラーは、AIに質問すると解決しやすい種類の問題です。エラーメッセージの全文と、実行したコマンドと、Macの情報（チップの種類とmacOSのバージョン）を渡してください。

3つ目は Part 6 の RAG の評価です（→ 6-09 RAG(3)：検索と回答を評価する）。作ったものが「動く」段階から「どれだけ正しいか測る」段階に進むと、評価用のデータを作る地道な作業と、統計の考え方が必要になります。成果が見えにくく、手応えが減る時期です。

乗り越え方：この段階こそ、他の学習者と差がつく場所だと知っておいてください。前の章で見たとおり、求人で最も重視されているのが評価です。小さな評価セット（20件）から始め、数字が改善していくのを見ることを楽しみにしてください。

週に一度の振り返り

毎週1回、10〜15分の振り返りの時間を取ります。日曜の夜など、決まった時間にしておくと続きます。振り返りでは次の3つを確認します。

• 今週終えた章と、計画との差。遅れていたら、原因（時間が取れなかった、内容が難しかった）を1行で書く。
• 今週いちばん分からなかったこと。来週の最初に、AIに質問するか、該当の章を復習する。
• 来週の予定。カレンダーに学習の時間を実際に入れる。

計画からの遅れは、責める材料ではなく、計画を直す材料です。毎週少しずつ直していけば、計画は自分の生活に合ったものになっていきます。

止まってしまったら

それでも止まってしまうことはあります。1週間以上空いてしまったら、次のように再開します。

• 罪悪感を持たない。空白期間はほぼ全員に起きる。
• 新しい章に進まず、直前に終えた章の理解度チェックから始める。
• どうしても分からない章は、印を付けて先に進み、後で戻る。必須の章でも、7割分かれば先に進んでよい。後の章で使いながら理解が追いつくことはよくある。

演習

import math

def weeks_needed(total_hours, hours_per_week):
    return math.ceil(total_hours / hours_per_week)

print(weeks_needed(400, 10))
print(weeks_needed(415, 10))

from datetime import date, timedelta

def review_dates(learned, intervals):
    result = []
    for days in intervals:
        d = learned + timedelta(days=days)
        result.append(str(d))
    return result

print(review_dates(date(2026, 10, 5), [1, 3, 7]))

scores = [72, 80, 82]
total = 0
for s in scores:
    total = total + s
average = total / len(scores)
print("平均:", average)

Pythonでエラーが出ます。直してください。

足りないもの：
- 何をしようとしていたか（目的）
- 実際のコード
- エラーメッセージの全文
- 期待した結果と実際の結果
- 自分で試したこと
- 実行環境
- 「直して」だけだと完成したコードが返ってきて、学びにならない。どう答えてほしいかの指定がない

書き直した質問：
Pythonを学習中の初学者です。次のエラーの原因を理解したいです。修正済みのコードを丸ごと書くのではなく、原因の説明と、自分で直すためのヒントをください。

やりたいこと：CSVから読んだ2つの点数を足して合計を出したい。

コード：
score_a = "80"
score_b = 90
total = score_a + score_b
print(total)

エラーメッセージ：
Traceback (most recent call last):
  File "main.py", line 3, in <module>
    total = score_a + score_b
TypeError: can only concatenate str (not "int") to str

期待した結果：170 と表示される
実際の結果：上の TypeError が出る

試したこと：score_b を "90" にしたらエラーは消えたが、8090 と表示された。

環境：アプリ内の Python（ブラウザ）

（例：営業事務として働く人の計画）

1. ルート：app。今の部署の問い合わせ対応を自動化した実績を作り、1年後にAIエンジニア職へ社内異動か転職をしたい。迷ったときは app、という本文の方針にも従う。
2. 時間：週10時間。平日（月〜金）は朝6:30〜7:45の75分を5日で約6時間。土曜の午前に2時間、日曜の夜に2時間。日曜は1週間の復習とメモの整理に使う。
3. 目標時期：app は約400時間。週10時間で約40週。仕事の繁忙期（3月と9月）に進みが落ちることを見込み、12か月後の2027年10月を完了目標にする。Part 1 を終える目標は2か月後。
4. 1回の流れ：最初の10分でアプリの復習クイズ、5分で前回のメモを読む、50〜60分で新しい章、最後の5分で自分の言葉で要点をメモに3行書く。予想ブロックは必ず予想を書いてから実行する。
5. 挫折ポイント：関数とクラスで止まりそう。そのときは予想ブロックの実行順を紙に番号で書き、1章に2週間以上かかったら7割の理解で先に進む。環境構築で詰まったら、エラーの全文とMacの情報をAIに渡して質問する。残業で1週間空いたら、新しい章ではなく前の章の理解度チェックから再開する。
6. 3か月後の成果物：毎朝手作業で集計している問い合わせ件数のCSVを読み、種類別に件数を数えて表にするPythonスクリプト。後に P2（問い合わせの自動分類）に発展させる。

理解度チェック

a = 3
b = a * 2
a = 10
print(b)

まとめ

• 再読とハイライトは「分かったつもり」を作る。効果が高いのは、思い出す練習（想起練習）と、日を空けて学ぶこと（分散学習）。
• 初学者は、解答例 → 穴埋め → 自力の順で進めると負担が少ない。「入力を用意する・変換する・確かめる」のような小目標で区切ってコードを読む。
• 予想 → 実行 → 比べる → 説明する、のループを習慣にする。外れた予想が学びの材料になる。
• AIは家庭教師として使う。まず自分で考え、答えではなくヒントを求め、説明させ、クイズを出させる。説明できないコードは使わない。
• AIの説明は、実行と公式ドキュメントで確かめる。判断の根拠は「AIがこう言った」ではなく「実行したらこうなった」。
• 詰まったら、エラーを読む → 最小の再現 → 仮説 → 1つ変えて試す。AIへの質問は、期待した結果・実際の結果・試したことを含めて渡す。
• app ルートは週10時間で9〜12か月、週20時間で5〜6か月が目安。毎日少しずつ、復習から始める。
• 関数とクラス、環境構築、RAGの評価は多くの人が止まる場所。7割分かったら先に進んでよい。

参考資料

いずれも任意です。英語の資料は、AIに要約を頼みながら読んでも構いません。

• Which Study Strategies Make the Grade?：Dunlosky らの学習法の評価を紹介した記事（英語）
• Anthropic「How AI assistance impacts the formation of coding skills」：AIの支援と技能習得の実験（英語）
• Simon Willison「Not all AI-assisted programming is vibe coding」：説明できないコードをコミットしない、という原則（英語）
• Raspberry Pi Foundation の研究セミナー紹介：サブゴールラベルと認知負荷（英語）