環境構築で npm install を打つと、黄色い文字がずらっと流れます。

npm warn deprecated inflight@1.0.6: This module is not supported...
npm warn deprecated glob@7.2.3: Glob versions prior to v9 are no longer supported
...

英語で、量が多くて、何かよくないことが起きているように見える。ここで手が止まってしまうことがあります。

でも、この画面のあとに npm run dev を打つと、普通に動くことがよくあります。

以前は「エラーが出たときにAIへどう渡すか」を書きましたが、今回はその手前の話です。そもそもエラーなのかどうかを、自分で見分けられるようにします。

Before：全部つぶそうとして半日溶かす

私が見てきた範囲だと、止まってしまうときの動きは似ています。

  1. 黄色い文字を見て「エラーが出た」と判断する
  2. 一番上のメッセージを検索する
  3. 出てきた記事のとおりにバージョンを上げてみる
  4. 別の警告が増える
  5. 3〜4を繰り返す

学習を始めたばかりの時期にこの沼にはまると、半日近く溶けることもあります。しかも最初から動いていたというオチになりがちで、そうなると得たものがありません。

原因は、「止まっているのか」と「気になるだけなのか」の区別がついていないことです。

見分け方：行の先頭のラベルを見る

黄色い文字の中身を読む前に、見る場所が2つあります。

1つ目：行の先頭についているラベル

npm の出力は、行ごとに種類が書いてあります。

npm warn deprecated glob@7.2.3: ...     ← warn ＝ 警告（お知らせ）
npm error code ERESOLVE                 ← error ＝ エラー（止まっている）

npm warn で始まる行はお知らせです。多くは deprecated（＝作者がもう推奨していない、今後更新されない部品を使っていますよ）ですが、それ以外の種類もあります。npm error で始まる行があれば、そちらが対処すべきものです（環境によっては npm WARN / npm ERR! と大文字表記になります）。

2つ目：終わりのほうに出るまとめ行

成功していれば、終わりのほうにこういう行が出ます。

added 342 packages, and audited 343 packages in 15s

2回目以降で内容に変化がないときは、代わりにこうなります。言い方は changed ... / removed ... になることもありますが、audited N packages in ○s を含む行が出ていれば成功です。

up to date, audited 343 packages in 1s

失敗していれば、これらの代わりにログの保存場所が出ます。

npm error A complete log of this run can be found in: ...

なお、このまとめ行のあとに続く N packages are looking for funding や found 0 vulnerabilities、3 vulnerabilities (1 moderate, 2 high) といった表示は、インストールが成功したかどうかとは別の話です。いちばん後ろの行だけを見ると、ここに引っかかって「失敗した」と誤解しやすいので注意してください。

ただし脆弱性の表示は「一生無視していい」という意味ではありません。学習中は後回しでOKですが、人に公開するアプリでは後で見る価値があります。

⚠️ よくある誤解なのですが、「入力待ちに戻ってきたから成功」ではありません。npm は失敗したときも入力待ちに戻ります。見るべきはラベルと、終わりのほうのまとめ行です。

自信がないときは、直後にこれを打つと分かります。macOS・Linux のターミナル（Windows なら Git Bash）の場合です。

echo $?

0 が出れば成功、それ以外の数字が出れば失敗です。Windows の PowerShell を使っている場合は、代わりにこちらを打ちます（同じく 0 なら成功）。

echo $LASTEXITCODE

After：先に「動くか」を確かめる

ラベルを見て npm error が無ければ、あとは順番を変えるだけで沼を避けられます。

  1. 警告しか出ていないなら、まず次のコマンドを打つ（npm run dev など）
  2. ブラウザで開いて、動くかどうかを見る
  3. 動いたら、警告は一旦そのままにして先へ進む
  4. 動かなかったときだけ、原因を調べる

「気持ち悪いから消したい」という気持ちは分かりますが、学習の段階では優先度が低いです。警告の多くは、自分ではなく使っているライブラリの中の話なので、こちらで直せないものも混ざっています。

それでも不安なときの確認の仕方

とはいえ「本当に無視していいのか」は気になります。そこはAIに判断を投げられます。

npm install を実行したら、以下の警告が出ました。
npm error で始まる行は無く、終わりのほうに「added 342 packages」と出て終了しています。
（※数字は実際に出たものに置き換えてください）

（警告をそのまま貼る）

次の3点を教えてください。
1. これは今すぐ対処が必要なものか、後回しでよいものか
2. 後回しでよい場合、放置すると将来どうなるか
3. 対処するとしたら、どのタイミングでやるのが自然か

ポイントは、「エラー行は出ていない」という事実を先に伝えることです。これを書かずに警告だけ貼ると、AIは「困っている＝止まっている」と受け取って、必要のない修正手順を出してくることがあります。

もう一つ、「今すぐか、後回しか」を聞く形にするのも効きます。「直してください」と頼むと直す方向の答えが返ってきやすいですが、優先度を聞けば「これは放置で構いません」という答えが返ってきやすくなります。

判断そのものを渡さないほうがいい

ここで身についてほしいのは、警告の読み方そのものよりも、「止まっているのか、気になるだけなのか」を自分で切り分けてから人（やAI）に相談するという順番です。

この切り分けができていないまま相談すると、相手も緊急度を測れません。逆に「動いてはいます。ただしこの表示が気になります」と添えて渡せるだけで、返ってくる答えの精度が上がりやすいです。

これはプログラミングに限りません。仕事でも、「止まっている」と「気になる」を分けて報告できる人は、相談が速く終わります。AIに何かを任せる場面が増えるほど、この切り分けを自分側で持っておく価値は上がります。

まとめ

  • 色や見た目ではなく行頭のラベルで見る。npm warn はお知らせ、npm error が対処すべきもの
  • あわせて終わりのほうのまとめ行（audited N packages in ○s を含む行が出ていれば成功）を見る。echo $?（PowerShell なら $LASTEXITCODE）が 0 なら成功
  • ⚠️「入力待ちに戻ったから成功」ではない（失敗しても戻ってくる）
  • 動いたなら、警告は一旦そのままで先に進んでいい
  • 不安なら「エラー行は出ていない」と伝えたうえで、直し方ではなく優先度を聞く
  • 大事なのは「止まっている／気になるだけ」を自分で切り分けてから相談する順番

面談なしで、今日から始められます

この講座は 未経験から Next.js + Supabase + Claude Code で Webアプリを公開するまで を全20セッションで体系化した教材付きプランです。無料相談を挟まず、申し込んだその日から教材で学習を始められます。AIが学習パートナーになって何度でも質問でき、つまずいた所だけチャットで直接サポートします。

  • 今日から始める（教材完全版＋月5,500円・チャット質問し放題・いつでも解約OK）→ https://menta.work/plan/20251?ref=menta-knowledge
  • いきなりは不安な方へ：無料の教材体験版もあります（最初の数セッション分）→ プラン詳細をご覧ください