はじめに
Claude Code、コードを書かせるだけで使ってませんか？それ、正直めちゃくちゃもったいないです。
Claude Code のすごいところは、手を動かしてくれる相棒であると同時に、隣に座ってる先生でもあること。実装を丸投げするんじゃなくて、「教えてもらう」「シニアの頭の中を盗む」道具として使うと、成長スピードが本当に変わります。
昔の自分はこうでした。何か新しいことを始める → 調べる → よくわからん → 挫折 → 諦める。この無限ループ。ドキュメント開いても用語がわからなくて、その用語を調べたらまた知らない用語が出てきて、気づいたら心が折れてる。あの頃ほしかったのはコードそのものより、「わからんところを、わかるまで何回でも噛み砕いてくれる人」だったんですよね。
その役割、今は Claude Code がやってくれます。聞き続けるだけで、24時間ずっとそばにいてくれる専属の先生がいるようなもの。使わない手はないです。
というわけで、Claude Code を「先生」に変える厳選プロンプトを5つ紹介します。
そもそも、なんでChatGPTじゃなくてClaude Codeなの？
「同じ質問ならWebのチャットに投げればよくない？」って思いますよね。ここが最初のキモです。
Claude Code はターミナル（やエディタ）の中で動くので、目の前の自分のコードやファイル、エラーをそのまま読んで話ができます。「このエラー直して」と言えば、一般論じゃなくて「あなたのそのファイルの、その行」を前提に返してくれる。
つまり教材が「そのへんの入門書」じゃなくて「自分のプロジェクトそのもの」になるわけです。これが学習ツールとして Claude Code を選ぶ理由。以下のプロンプトも、この「文脈を読める先生」って強みを活かす前提で作ってます。
ちなみにプロンプトは日本語で載せてますが、英語でも普通に効きます。好きな方でどうぞ。
① 初心者向けチューターモード
まったく知らない分野に飛び込むときの最初の一手。専門用語の壁で心が折れないように、とことん噛み砕いてもらいます。
あなたは世界一わかりやすい講師です。
この専門的な内容を、小学生でも理解できるように説明してください。
専門用語を使う場合は、必ずその意味もあわせて説明してください。
どんなとき使う？：新しいライブラリや概念、意味不明なエラーに初めて出会ったとき。ここで「わかったフリ」して進むと後で絶対詰まるので、先に土台を固めるモードです。返ってきた説明に「その例え、もうちょい具体的に」「別の言い方で」ってどんどん追撃できるのがチャットのいいところ。
② エラー解決特化モード
エラーって、実は最高の教材なんですよね。ただ直すだけだと何も残らないので、「なんで起きたのか」ごと理解しちゃいましょう。
このエラーの原因を特定してください。
「原因は何か」「なぜ起きるのか」「どう直すのか」の順に説明し、
修正後のコードもあわせて提示してください。
どんなとき使う？：エラーで手が止まったとき。スタックトレースを貼るだけでもいいけど、Claude Code なら該当ファイルを直接読ませられます。コツは「なぜ起きるのか」を必ず説明させること。ここをサボると、次に似たエラーが出たときにまた同じ質問をするハメになります。原因が積み上がってくると、そもそもエラーを踏まなくなってきますよ。
③ 現役エンジニア思考モード
正直、答えのコードより価値があるのが「そこにたどり着くまでの考え方」。シニアエンジニアの頭の中を覗かせてもらいましょう。
この機能を実装するとき、シニアエンジニアならどう考えるかを
ステップバイステップで説明してください。
設計思想・保守性・拡張性の観点も含めて解説してください。
どんなとき使う？：実装する前の設計フェーズ。「どう書くか」より「なんでその設計にするのか」を言語化させると、判断のモノサシごと盗めます。設計思想・保守性・拡張性をわざわざ指定してるのがポイントで、これがないと「とりあえず動くコード」だけ返ってきがち。出てきた設計に「この選択のトレードオフは？」って重ねて聞くと、さらに解像度が上がります。
④ レビュー＆改善モード
自分で書いた（or AIに書かせた）コードを、辛口の先輩にレビューしてもらう感覚のモードです。
このコードを厳しめにレビューしてください。
可読性・保守性・パフォーマンス・セキュリティの観点から改善点を指摘し、
改善版も提示してください。
どんなとき使う？：とりあえず動くものができた後の仕上げ。「厳しめに」って入れておくと、忖度なしでバシバシ問題点を出してくれます。観点を4つ（可読性・保守性・パフォーマンス・セキュリティ）に固定してるので、レビューの抜け漏れが減るのも地味に効く。改善版をそのままコピペするんじゃなくて、「なんでこっちの方がいいの？」を毎回確認すると、レビューの基準が自分の中に溜まっていきます。
⑤ 学習ロードマップ生成モード
最後は、学習そのものを設計してもらうモード。ゴールから逆算して最短ルートを引いてもらいます。
私の現在のレベルは〇〇です。
〇〇を作れるようになることがゴールです。
最短で達成するための学習ロードマップを作成してください。
各ステップで学ぶべき内容と、実践課題もあわせて提示してください。
どんなとき使う？：「何から手をつければいいの…」って途方に暮れたとき。〇〇を具体的に埋めるほど精度が上がります（例：「今のレベルは HTML/CSS がなんとか書ける程度」「ゴールは自分用の家計簿アプリを Next.js で作れるようになること」）。実践課題まで出させるのが大事で、読むだけで満足して終わる挫折パターンを防げます。
5つ組み合わせると「学習ループ」になる
単発でも効きますが、順番につなげると1個の学習サイクルになります。
- ⑤ ロードマップでゴールと全体像を決める
- 各ステップで① チューターモードを使って、知らない概念を潰す
- ③ エンジニア思考モードで設計を学びながら実装する
- 詰まったら② エラー解決モードで原因ごと理解する
- できたコードを④ レビュー＆改善モードで磨く
- 次のステップに戻って、また①〜⑤を回す
これを回してるだけで、「調べる → 挫折 → 諦める」が「聞く → わかる → 作る」に置き換わっていきます。
使うときの注意点だけ
先生としてはめちゃ優秀ですが、万能ではないです。ここだけ気をつけて。
- 鵜呑みにしない：それっぽく間違えることがあります。特にライブラリのバージョン差やセキュリティ周りは、公式ドキュメントで裏を取るクセを。「厳しめにレビューして」って言うのと同じ目線を、AIの答えそのものにも向けると健全です。
- 写経して終わりにしない：改善版をそのまま貼って満足すると、③④の意味が半減します。「なぜ？」を一回は自分の言葉で説明できるか確かめましょう。
- 機密情報はちょっと慎重に：業務コードや個人情報が入ったファイルを読ませるときは、使ってるプランや環境のデータの扱いを一応確認しておくと安心です。
おわりに
実装をAIに任せられる時代だからこそ、差がつくのは「自分がどれだけわかってるか」です。だからコードを書かせて終わりにするんじゃなくて、わからないことをわかるまで何回でも聞ける先生として使い倒してほしい。
24時間、隣に専属の先生がいる。これを活かさないのはもったいなさすぎます。まずは今ちょうど詰まってるエラーに、②のプロンプトを投げてみてください。