「AIがあるから、メンターも教材もいらない。独学で十分」——この風潮は、半分は本当で、半分は危険です。
AIのおかげで、未経験者が独学で進める範囲は劇的に広がりました。エラーの解説、用語の翻訳、コードの生成、調べ物。数年前なら「詰まって数日」だったことが、数分で前に進むようになった。これは事実として、まず認めたい。
ただ実際に未経験者の学習を見ていると、「AIがあっても一人だと止まる」場所が確かに存在します。そしてそれは、AIの性能の問題ではなく、使い手側に判断基準があるかどうかの問題です。
この記事では、未経験者がAIと独学で詰まりやすい3つのポイントを、できるだけ具体化します。それぞれについて「AIでここまでは独学でいける／ここからは判断基準がないと止まる」の境界線を引いていきます。煽りではなく、独学の射程を正しく見積もるための地図だと思ってください。
なお、これは「つまずきの直し方」を並べる記事ではありません。直し方そのものより、一人で詰まる瞬間に何が欠けているのか＝学習設計の話に重心を置きます。
結論を先に
- 全部独学 or 全部おまかせ、の二択は誤り
- AIで独学できる範囲はどんどん独学していい（むしろ独学すべき）
- 止まるのは決まって「判断基準がない瞬間」——質問が作れない／答えの正誤がわからない／前提がズレているのに気づけない
- だから正解は「使い分け」。独学できる所は独学し、一人だと抜けられない瞬間だけ人に頼るのが結局いちばん速い
以下、3つの境界線を見ていきます。
境界線1: そもそも「何を聞けばいいか」がわからない時
AIは、適切な質問を投げれば的確に答えます。問題は、未経験者は質問自体を作れないことがあるという点です。「エラーが出ました、助けてください」だけでは、AIも当てずっぽうになります。
AIでここまでは独学でいける
エラーメッセージが手元にあるなら、それをそのまま貼るだけで、かなり進みます。コツは「メッセージ全文＋発生した状況」をセットで渡すこと。
# 悪い質問
ログインできません。直してください。
# いい質問（独学で十分到達できるレベル）
Next.js（App Router）で Supabase の signInWithPassword を使ったら
下のエラーが出ました。原因の候補と確認手順を、初心者向けに順番に教えてください。
エラー全文:
AuthApiError: Invalid login credentials
at ...（スタックトレースもそのまま貼る）
状況:
- 新規登録は成功している（usersテーブルに行が増えた）
- ログインフォームで同じメール/パスワードを入れると上記エラー
- メール認証は有効にしている
ここまでは、AIに丸投げで構いません。むしろ独学でどんどんやるべき領域です。
ここからは判断基準がないと止まる
止まるのは、エラーメッセージが出ない（or 読み方がわからない）時です。たとえば「画面は表示されるけど、データが反映されない」。例外も赤い文字も出ないので、何を貼ればいいかわからない。
この時に効くのが「最小再現（minimal reproduction）を作る」という発想です。これは経験者なら反射的にやりますが、未経験者はそういう手があること自体を知りません。ここが学習設計の論点で、最小再現は「技術知識」ではなく「問題の切り分け方という作法」です。作法は、知っていれば誰でも回せる。知らないと、AIにどれだけ高性能でも辿り着けない。
最小再現の作り方を、独学でも回せる手順に落とすとこうなります。
1. 動いている部分と動いていない部分を物理的に分ける
→ 1ファイル・数十行に切り出して、問題が再現するか確認する
2. console.log / print を「データが通る経路」に置いて、どこで値が変わるか観測する
3. 「期待した値」と「実際の値」を1行ずつ書き出す
例: 期待 = user.id が入る / 実際 = undefined
4. その差分（undefined になっている1点）をAIに渡す
ポイントは、4番に渡せる状態まで持っていけるかです。ここまで切り分けてあればAIは一発で答えますが、切り分け方を知らないと「全部のコードを貼ってどこか直して」になり、AIも的を外し、ループに入ります。AIが悪いのではなく、AIに渡す前提が崩れているのです。
境界線: エラーメッセージがある＝独学でいける。「症状はあるがメッセージがない」を最小再現に落とす作法は、誰かに一度教わると一気に楽になる典型例。
境界線2: AIの答えが「間違っている／古い」時に、それに気づけない
AIは堂々と間違えます。特に未経験者が踏みやすいのが「それっぽいけど古いAPI」と「存在しないオプションの捏造（ハルシネーション）」です。
AIでここまでは独学でいける
生成されたコードがそもそも動くかどうかは、独学で判定できます。動かしてエラーになれば、それをまたAIに返せばいい（境界線1のループ）。「動く/動かない」は機械が教えてくれるので、判断基準は要りません。
ここからは判断基準がないと止まる
問題は「動くんだけど、古い／非推奨のやり方」のケースです。動いてしまうので、エラーでは気づけません。半年後にライブラリを上げた瞬間に壊れる、という形で跳ね返ってきます。
未経験者がここで止まるのは、「何と照合すれば正しさを確認できるか」を知らないからです。検証の当て先を持つこと——これが独学と伴走の分かれ目になります。具体的な照合先は3つです。
照合先1: 公式ドキュメント
AIの答えの関数名・オプション名で公式ドキュメントを検索する。
ヒットしない / 「deprecated」と書いてある → 赤信号
照合先2: package.json の実際のバージョン
AIは「最新ではこう」と一般論で答えがち。
自分のプロジェクトのバージョンと噛み合っているか確認する。
// package.json — AIの回答が前提にしているバージョンと突き合わせる
{
"dependencies": {
"next": "16.0.3", // ← AIが15系の書き方で答えていないか
"@supabase/supabase-js": "2.x",
"@supabase/ssr": "0.x" // ← 旧 auth-helpers ではなくこちらが現行か
}
}
照合先3: 「いつ時点の情報？」を本人に聞き返す
プロンプト例:
「その書き方は @supabase/ssr のどのバージョン以降が前提ですか？
非推奨になった古いやり方があれば、併せて教えてください。」
たとえば Supabase 認証は、@supabase/auth-helpers から @supabase/ssr へと現行の推奨が移っています。AIが古い記事を学習していると、動くけど非推奨のコードを返すことがある。package.json のバージョンと公式ドキュメントに当てれば自分で気づけますが、「当てに行く」という発想と、当て先のリストがないと、気づけません。
ここも学習設計の論点です。「照合先を持つ」は知識量の話ではなく、正しさをどこで担保するかという習慣。一度この習慣がインストールされると、未知のライブラリでも同じやり方が効きます。検証用のミニチェックリストを置いておきます。AI生成コードを受け取ったら、これを1周する癖をつけると独学の射程が伸びます。
- 関数名・オプション名で公式ドキュメントを検索した（ヒットする/deprecatedでない）
-
package.jsonの実バージョンと、回答が前提にする書き方が一致している - 「いつ時点／どのバージョン前提の回答か」をAIに聞き返した
- 動くだけでなく「なぜこう書くのか」を1行で説明できる
境界線: 「動く/動かない」は独学で判定できる。「動くけど古い/危ない」は、照合先を持っているかどうかで分かれる。最初の数回だけ、当て先を一緒に確認してくれる人がいると、この目は早く育つ。
境界線3: AIから「見えていない前提」を、言語化して渡せるか
最後が、いちばん独学で溶けやすい領域です。ただし、これは「設定の直し方」の話ではありません（具体的なデプロイ設定のつまずきと直し方は別記事にまとめたので、実務でハマっている人はそちらへ）。ここで扱うのは、その一段手前——そもそもAIには見えていない前提があり、それを自分の言葉で渡せるかどうかという学習設計の話です。
なぜAIと噛み合わないのか
AIはあなたのプロジェクトの全体像を見ていません。見ているのは、あなたが渡した文字列だけです。だから「設定したつもり」と「実際の状態」がズレていると、AIは正しいことを言っているのに直らない、という地獄が起きます。原因は性能ではなく、前提の欠落です。
これは「コードのエラー」と違って、AI側から「その前提が抜けてますよ」と指摘してくれません。だから未経験者は、何が前提として欠けているのかに気づけないまま、延々とズレた答えを受け取り続けます。
"前提が見えない"が起きる3つの典型
設定の沼を「直し方」で並べるのではなく、どんな前提がAIから見えていないかという観点で整理すると、こうなります。
パターン1: 実行される「場所」の前提（ブラウザ or サーバー）
例: CORS で API 呼び出しが弾かれる
AIから見えていない前提:
- そのコードはブラウザで動くのか、サーバーで動くのか
- 呼び先のAPIが、その実行元（オリジン）を許可しているか
言語化して渡すべき情報:
「どこから呼んでいるか（Client/Server Component）」「呼び先のホスト名」
「ブラウザのコンソールに出ている CORS エラー全文」
パターン2: リクエストが通る「順番」の前提（誰が先に割り込むか）
例: ログイン済みなのにページに入れない / 無限リダイレクト
AIから見えていない前提:
- リクエストはページに届く前に middleware を通っている
- middleware が認証チェックでリダイレクトを返している可能性
言語化して渡すべき情報:
「middleware.ts の中身」「どのパスで起きるか」「リダイレクト先」
// middleware は「ページの手前」で全リクエストに割り込む。
// この前提を渡さないと、AIは page.tsx だけ見て「コードは正しい」と言う。
export const config = {
matcher: ['/dashboard/:path*'], // ← どこに割り込んでいるか、が前提
}
パターン3: 「どこで処理されるか」の前提（ビルド時 or 実行時 or 設定UI）
例: 画像が表示されない / next/image で外部画像がエラーになる
AIから見えていない前提:
- 外部ドメインの画像は設定ファイルで許可リストに入れる必要がある
- 「コードの問題」ではなく「設定の問題」のことがある
言語化して渡すべき情報:
「next.config の images 設定」「画像のホスト名」「出ているエラー全文」
3つに共通するのは、「AIから見えていない前提」を言語化して渡せるかが分かれ目だということです。前提さえ正確に渡せれば、独学で抜けられます。逆に、「どの前提が必要か」を知らないと、AIと噛み合わないまま時間だけ溶けます。
ここが学習設計として一番難しいのは、前提は「自分にとっては当たり前」なので、抜けていることに気づきにくいからです。第三者が画面を一緒に見て「あ、ここ Client から呼んでますね」「middleware 通ってますね」の一言で5分で終わる、という領域でもあります。伴走のコスパが特に高いのはここです。
境界線: 「何を設定するか」の地図は独学でいける。「自分の環境の実状態と、AIに見えていない前提のズレ」は、前提を言語化して渡す作法がないと止まる。直し方の暗記ではなく、前提を言語化する習慣が効く。
まとめ: 「独学の射程」と「人に頼る瞬間」を分ける
AIで独学できる範囲は、本当に広がりました。エラーが出ているもの、動く/動かないで判定できるもの、設定すべき項目の洗い出し——ここはどんどん独学していい。むしろ自分で手を動かさないと、判断基準が育ちません。
一方で、未経験のうちに一人だと止まりやすいのは、決まってこの3つです。
- 質問が作れない時（症状はあるがメッセージがない → 最小再現に落とす作法）
- 答えの正誤がわからない時（動くけど古い → 照合先を持つ目）
- 前提がズレている時（AIに見えていない前提を渡せない → 前提の言語化）
共通しているのは、どれも「コードを書く力」ではなく「判断基準を持っているか」だということ。そして判断基準は、最初の数回だけ誰かと一緒に通すと、一気に自分のものになります。
だから「全部独学 vs 全部おまかせ」ではなく、独学できる所は独学し、一人だと抜けられない瞬間だけ人に頼る。これが、未経験から最短で進むための使い分けだと思います。独学を否定するための記事ではありません。独学の射程を正しく見積もって、止まる所だけショートカットしよう、という話です。
未経験者向けの講座を運営しています。
未経験から Next.js + Supabase + Claude Code で Webアプリを作って公開するまで を、全20セッションで体系化した教材です。ここで書いた「判断基準を育てる」設計（最小再現・検証の当て先・前提の言語化）を、手を動かしながら身につけられる構成にしています。
- 無料体験版（git clone してすぐ動く・最初の数セッション分・⭐ Star もよろしくお願いします）→ https://github.com/ayies128/next-ai-camp-trial
- 教材完全版＋月5,500円のメンタリング（全20セッション＋詰まった瞬間だけチャットで質問し放題）→ https://menta.work/plan/20251?ref=qiita
- YouTube『AIエンジニア情報局』（AI×開発ニュースを1本5分でキャッチアップできる別運営チャンネル・無料）→ https://www.youtube.com/channel/UC1rXVD9WYsQPQEWZyd-A1KA/?ref=qiita
※ Qiita 読者の方には易しすぎる内容なので、初心者の知り合いへの紹介や社内研修の参考としてどうぞ。