【新卒向け】AIを使った効率的な学習方法

AIで学習は速くなった。同時に「身につかない」も速くなった

わからないことを聞けば、数秒で丁寧な答えが返ってくる。かつては先輩の手が空くのを待つか、分厚い本の索引をめくるしかなかった場面で、いまは即座に前へ進める。AIによって学習のスピードが上がったのは間違いない。

ただ、この便利さには罠がある。答えをもらった瞬間の「わかった」という感覚と、実際に身についていることは、まったくの別物だという罠だ。

こんな経験はないだろうか。エラーをAIに貼ったら修正コードが返ってきて、貼り替えたら動いた。説明も読んで納得した。ところが1週間後、ほぼ同じエラーでまた手が止まる。読んだはずの説明は思い出せず、結局もう一度AIに聞く。進んだようでいて、自分の中には何も積み上がっていない。

この記事では「AIに聞けば速い」の一歩先、わかったつもりを防ぐAIの使い方を紹介する。

なぜ丸投げだと身につかないのか

理解とは、情報を受け取ることではない。受け取った情報を、自分がすでに知っていることと結びつけて、自分の頭の中で組み立て直す作業のことだ。

本を読んだだけ、動画を見ただけの知識がすぐ抜けてしまうのは、この組み立て直しをしていないからだ。読んで「なるほど」と思うことと、白紙の状態から自分で説明できることの間には、大きな距離がある。前者は他人の理解をなぞっているだけで、後者ではじめて自分の理解になる。

やっかいなのは、AIの説明が上手すぎることだ。わかりやすい説明を読むと、人は「自分はわかった」と感じる。しかし、そのわかりやすさはAIの能力であって、あなたの理解度ではない。スラスラ読めたという感覚を、身についた証拠だと勘違いしてしまう。これが「わかったつもり」の正体だ。

コピペも同じ構造を持つ。動くコードを貼り付けても、あなたの頭の中では何も組み立てられていない。動いたのはAIのコードであって、あなたの理解ではない。

だから、AI学習のコツは一つに集約される。**組み立て直しの作業を、自分の側に残すこと。**以下、その具体的な型を4つ紹介する。

身につく使い方 4つの型

型1: 説明させて、要約して、採点させる

一番基本の型。AIに説明してもらったら、そこで終わらせず、理解した内容を自分の言葉で書いて、AIに採点させる。

（説明を読んだあとに続けて）
いまの説明を自分の言葉で要約します。
間違いや抜けがあれば遠慮なく指摘してください。

「APIとは、プログラム同士がやりとりするための窓口のことで、
決められた形式でリクエストを送ると、決められた形式で結果が返ってくる。
中身がどう実装されているかを知らなくても使えるのが利点」

要約を書こうとして手が止まったら、それは理解できていないサインだ。読んで納得しただけの状態からは、自分の言葉は出てこない。この「書けない」に早く気づけることが、この型の最大の価値だと言っていい。

型2: あえて反論させる（ソクラテス式）

自分の理解が固まってきたら、今度はAIに攻撃側へ回ってもらう。

私は「ライブラリよりフレームワークの方が制約が強いぶん、
初心者に向いている」と考えています。
この意見に反論してください。私の理解の弱いところを突いてください。

反論に答えようとすると、自分がどこまで根拠を持って理解しているかが露わになる。答えられなければ、そこが理解の穴だ。質問を重ねて相手の理解を試すソクラテスの問答法を、AI相手なら誰にも気兼ねなく試せる。

型3: 自分のコードを自分で説明して、レビューさせる（ラバーダック）

書いたコードをただ「レビューして」と投げるのではなく、まず自分で1行ずつ説明してから見てもらう。

自分で書いたコードを、理解の確認のために自分で説明します。
説明が実際の動作と食い違っている箇所があれば指摘してください。

（コードを貼る）
このループは配列の全要素を走査して、
条件に合うものだけを新しい配列に集めている……つもりです。

プログラマの古典的な習慣に「ラバーダック・デバッグ」がある。机の上のアヒルのおもちゃに向かってコードを説明していると、説明の途中で自分の誤りに気づく、というものだ。声に出して説明する行為そのものが、頭の中の組み立て直しを強制する。AIはこのアヒルの上位互換で、説明を聞いたうえで、実際の動作との食い違いまで指摘し返してくれる。

型4: 「教えないで、ヒントだけ」と指示する

答えを見る前に、自分で考える時間を確保する型。AIは指示すれば答えを伏せてくれる。

このエラーを自力で解決したいので、答えは教えないでください。
まず、どこを調べるべきかのヒントを1つだけください。
それでもわからなければ、次のヒントを求めます。

思い出そうとする、考え出そうとする努力そのものが、記憶を強くする。最初から答えを見てしまうと、この効果は働かない。「あと少しで解けそうだったのに」という悔しさごと、答えは頭に残る。

写経・手を動かす学習との組み合わせ

ここまでの型は、手を動かす学習を置き換えるものではない。プログラミングの理解の最終的な置き場所は、読んだ説明の中ではなく、書いた経験の中にある。

おすすめの順序はこうだ。

1. まず自分で書いてみる（写経でもよい。ただし1行ずつ意味を考えながら）
2. 詰まったら、型4で「ヒントだけ」もらい、もう一度自分で書く
3. 動いたら、型3で自分の言葉で説明してレビューを受ける
4. 「この行を消したらどうなる？」「この引数を変えたら？」と改造実験をして、予想と結果のズレをAIと突き合わせる

特に4の改造実験は、写経を「なぞる作業」から「理解の検証」に変えてくれる。重要なのは、動かす前に予想を立てるという一手間だ。予想が外れた場所にこそ、自分の理解のズレが埋まっている。

やってはいけない使い方

検証なしの丸コピペ。 AIのコードは平然と間違う。存在しないAPIを呼び、古いバージョンの書き方を混ぜてくる。たとえ動いたとしても、そのコードが何をしているか説明できないなら、本番のコードに入れてはいけない。障害が起きたとき、誰にも直せないコードが残るだけだ。

エラーメッセージを読まずに貼る。 エラーメッセージは、何が・どの行で・なぜ失敗したかを教えてくれる一次情報だ。読まずに貼る習慣がつくと、エラーを読む力が永遠に育たない。まず自分で読み、仮説を立ててから聞く。この30秒の差が、1年後の実力の差になる。

機密情報・社内コードを貼る。 社外のAIサービスに入力した内容は、社外に出たのと同じだと考えること。顧客情報、認証キー、社内システムのコードをそのまま貼ってはいけない。ダミーデータに置き換える、会社が承認したツールだけを使う、判断に迷ったら貼らない。所属組織のセキュリティポリシーを必ず確認してほしい。

学習ログを残す — 最後の仕上げ

学んだことを定着させる仕組みとして、学習ログをすすめたい。Markdownのメモで十分だ。

# 2026-07-14 非同期処理

## 聞いたこと

await は Promise の完了を待つ。なぜ async の中でしか使えないのか？

## 理解したこと（自分の言葉で）

関数に async をつけるのは「この関数は途中で待つことがある」という宣言。
呼び出し側は、その待ち時間のあいだブロックされない。

## まだ怪しいところ

Promise.all と直列 await の使い分けの判断基準

ポイントは2つ。まず、AIの回答を貼り付けるのではなく自分の言葉で書くこと。貼り付けた瞬間、ここまで述べてきたコピペと同じものになる。次に、数日後に読み返して書き直すこと。書き直せなければ理解が消えかけているサインなので、もう一度型1からやり直せばいい。「まだ怪しいところ」の欄は、次にAIへ聞くことリストとしてそのまま使える。

まとめ

AIは、答えが返ってくる速さで学習を変えた。しかし理解の深さは、答えを受け取る速さではなく、自分の頭で組み立て直した量で決まる。この構図は、AIがどれだけ賢くなっても変わらない。

説明させたら要約して採点を受ける。反論させて穴を探す。自分のコードを自分で説明する。答えではなくヒントをもらう。手を動かし、予想を立てて改造し、自分の言葉でログに残す。

どの型にも共通するのは、AIに「答える係」ではなく「自分の理解を試す係」を任せていることだ。答えをもらう相手としてだけAIを使う人と、理解の検証相手として使う人。1年後に差がつくのは、間違いなく後者だ。