Next.jsで学ぶReact講座（完全初心者向け・30日） | 第5章：仕上げと次の一歩 – エラーメッセージの読み方

React Next.js
2026.01.10
スポンサーリンク

エラーは「敵」じゃなくて「ヒント」

ここまで来ると、もうあなたは「Next.js × React でアプリを作れる人」です。
ここから先で一番“差”がつくのは、

エラーが出たときにどう向き合うか

です。

エラーが出るたびに「最悪…」で止まるのか、
「なるほど、どこがダメか教えてくれてる」と読みにいけるか。

エラーメッセージは、あなたを責める文章じゃありません。
「ここが怪しいよ」「こう直すといいよ」というヒントの塊です。
その読み方と、実務でも通用するデバッグの習慣を、ここで一気に整理します。

エラーメッセージの読み方

最初に見るべきは「一行目」と「赤い一文」

ブラウザの画面やターミナルに赤文字が出たとき、
まず目を向けてほしいのは「一番上の一行」です。

例えば、React だとこんな感じのエラーがよく出ます。

TypeError: Cannot read properties of undefined (reading 'map')
ReferenceError: xxx is not defined
Too many re-renders. React limits the number of renders to prevent an infinite loop.

この一行目には、だいたい次の情報が入っています。

何タイプのエラーか（TypeError / ReferenceError / SyntaxError など）
何をしようとして失敗したか（undefined の map を読もうとした、変数が定義されていない、など）

最初の一行目を“日本語に翻訳”してみる癖をつけましょう。

例：
Cannot read properties of undefined (reading 'map')
→「undefined の ‘map’ プロパティを読もうとしている。つまり 〇〇.map(...) の〇〇が undefined だよ」

つぎに「どのファイルの何行目か」を探す

エラーの一行目を見たら、次にチェックするのは「場所」です。

ブラウザのエラーやターミナルには、だいたいこういう情報が出ます。

at TodoList (src/app/todos/TodoList.tsx:23:15)

ここから読み取れるのは、

どのファイルか：src/app/todos/TodoList.tsx
何行目か：23 行目付近

という情報です。

慣れてきたら、こういう流れで見ると効率がいいです。

一行目で「何系のエラーか」をざっくり掴む
ファイル名と行番号を見て、「どのコードが怪しいか」を特定

ここまでできれば、半分以上は勝ちです。

よく出るエラーと直し方のパターン

1. Cannot read properties of undefined / null

例：
TypeError: Cannot read properties of undefined (reading 'map')
TypeError: Cannot read properties of null (reading 'value')

これは、
「〇〇.△△ ってアクセスしようとしたけど、〇〇が undefined / null だよ」
という意味です。

よくあるパターンとしては、

todos.map(...) と書いているけど todos が undefined
event.target.value と書いているけど event や target が想定と違う

対応するときは、次のように考えます。

「今 undefined になっているのはどの変数か？」
「その変数は、どこでどんな値が入る想定だったか？」
「初期値を入れ忘れていないか？ props を渡し忘れていないか？」

React では特に、配列やオブジェクトの初期値が空のままアクセスしてしまうケースが多いので、

配列なら useState([])
オブジェクトなら useState({ ...初期値 })

のように「最低限、アクセスできる形」の初期値をセットしておくと安全です。

2. xxx is not defined

例：
ReferenceError: todos is not defined
ReferenceError: handleClick is not defined

これは、
「その名前の変数（または関数）が、そのスコープに存在しない」
という意味です。

だいたい次のようなミスが原因です。

スペルミス（hadnleClick と書いてしまった）
宣言していない変数を使っている
別ファイルから import し忘れている

対応はシンプルで、

その名前を宣言している行があるか探す
スペルが完全に一致しているか確認する
コンポーネントを別ファイルに切り出したときは export / import を確認する

特に、props の受け取り忘れや、関数名の綴り間違いはよくあるので、
エラーを見たら「変数名のスペルチェック」を一度してみてください。

3. Too many re-renders（無限レンダリング）

例：
Error: Too many re-renders. React limits the number of renders to prevent an infinite loop.

これは、
「レンダリング → state 更新 → レンダリング → state 更新…が止まらないループになっている」
というエラーです。

よくあるのは、こういうコードです。

const [count, setCount] = useState(0);

function Counter() {
  setCount(count + 1); // ❌ コンポーネントの本体で setState
  return <p>{count}</p>;
}
TSX

または、さっき学んだ useEffect のところのように、

useEffect(() => {
  setCount(count + 1);
}, [count]); // ❌ 自分が依存している state を自分で更新し続けている
TSX

対処の考え方はこうです。

コンポーネントの本体（return の外）で setState を呼んでいないか？
useEffect の依存配列と、その中の setState の関係がループになっていないか？

state 更新は、基本的に

イベントハンドラの中（onClick, onChange など）
初回だけ実行する useEffect（依存配列 []）の中

に閉じ込めるイメージを持っておくと、無限ループはかなり減ります。

スタックトレースの見方

「エラーまでの呼び出し履歴」

エラーメッセージの下に、ずらっと

at ComponentName (xxxx.tsx:行:列)
at ...

と並んでいる部分があります。これが「スタックトレース」です。

ざっくり言うと、

この関数からこの関数が呼ばれて
さらにこのコンポーネントの中でエラーになりました

という「呼び出しの履歴」です。

全部読む必要はありません。
初心者のうちは、

一番上の 2〜3 行だけ見る

で十分です。

例：

TypeError: Cannot read properties of undefined (reading 'map')
at TodoList (src/app/todos/TodoList.tsx:23:15)
at TodoPage (src/app/todos/page.tsx:10:5)

これを日本語にすると、

「TodoList コンポーネントの 23 行目あたりで map を読もうとしてコケた。
TodoPage から TodoList が呼ばれている」

と読み取れます。

最初に注目すべきは「自分が書いたファイル名が出ているところ」です。
node_modules の中や Next.js の内部ファイルは、とりあえず無視で構いません。

自力で直す思考法

1. まず「何が起きているか」を文章にする

いきなりコードをいじる前に、
エラーメッセージを見て「状況説明」を自分の言葉でしてみてください。

例えば、

「TodoList の 23 行目で、何かの変数が undefined なのに .map している」
「LoginForm の 15 行目で email って変数を使ってるけど、その変数は宣言されてない」

といった感じです。

人間は「曖昧なまま」だと頭が止まります。
一度、自分の言葉で状況をはっきりさせることで、
どこを調べればいいかが見えてきます。

2. 「正しい状態」と「今の状態」のギャップを見る

次に考えるのは、

本来こうなっていてほしい
でも実際はこうなっている

というギャップです。

例えば undefined エラーなら、

本当は todos は配列（[]）であるべき
でも今は undefined になっている

なぜか？

初期値を入れていない
親コンポーネントから props を渡していない
API のレスポンスを待たずにアクセスしている

という候補が浮かびます。

「どうなっていてほしいか」をはっきりさせると、
useState の初期値、props の渡し方、fetch のタイミングなど、
見るべきポイントがクリアになっていきます。

3. 「どこまで動いているか」を小さく確認する

困ったときに強いのが、「分割して確認する」やり方です。

コンソールログを入れる
console.log("ここまできた", todos);

UI を一時的に簡単にしてみる
怪しい部分だけコメントアウトして、エラーが消えるか試す

たとえば、

todos.map(...) の前に console.log(Array.isArray(todos), todos); を入れてみると、
「本当に配列なのか」「中身は何なのか」が一発で分かります。

「どこからおかしくなっているか」の境界線を探すイメージです。

デバッグ習慣（普段から身につけたいこと）

習慣1：エラーを「ちゃんと読む」クセ

当たり前に見えるかもしれませんが、
意外と多くの人が「赤くて怖いので閉じる」「なんとなく再起動する」だけで終わらせがちです。

最低限、次の 3 つは毎回確認する習慣をつけましょう。

一行目のメッセージ（何系のエラーか）
一番上の自作ファイルのファイル名と行番号
自分の頭で日本語にする

ここまでやった上で「分からない」となったら、検索や質問に進む。
この順番を守ると、エラー対応能力が一気に上がります。

習慣2：一度に複数の場所をいじらない

バグっているときほど「あれもこれも」触りたくなりますが、
これはデバッグの世界では一番やってはいけない行動です。

修正は「できるだけ小さく、1 ステップずつ」に絞る。
何かを変えたら、その結果をすぐ確認する。

これを守らないと、

直したつもりが別の場所を壊している
どの変更が効いたのか分からない

という沼にハマります。

習慣3：再現手順を言語化する

「どういう操作をするとこのエラーが出るのか」を
自分でステップにしてみるのも重要です。

  1. ページを開く
  2. 入力欄に文字を入れる
  3. 追加ボタンを押す → ここでエラー

というように、再現手順を言葉にできると、
「どのタイミングの処理が怪しいか」がかなり絞れます。

実務では「バグ報告」はすべてこの「再現手順」から始まるので、
今のうちからその癖をつけておくと、現場に出たときにかなり楽です。

まとめと、ここから先の一歩

ここまでのポイントをまとめると、

エラーメッセージは「敵」ではなく、「どこが怪しいかを教えてくれるヒント」。まずは一行目とファイル名・行番号を見る。
よく出るエラー（undefined のプロパティ読み、変数未定義、無限レンダリング）はパターンで覚え、「何をしようとして失敗しているのか」を日本語にする。
スタックトレースは全部読む必要はなく、「自分が書いたファイルが最初に出てくる場所」だけを注目して見る。
自力で直すには「状況説明 → 期待する状態とのギャップ → どこまで動いているかの確認」という順番で考え、コンソールログや一時的なコメントアウトで境界線を探す。
デバッグ習慣として、「エラーをちゃんと読む」「一度にたくさんいじらない」「再現手順と言語化」を普段から意識しておくと、実務レベルに近いデバッグ力になる。

もし今、「最近出たエラーでまだモヤモヤしているやつ」があれば、
そのエラーメッセージと状況をそのまま書いてみてください。

それを一緒に分解しながら読んでいくと、
この記事で話した「読み方・考え方」が、一気に“自分の武器”として定着していきます。

スポンサーリンク
タイトルとURLをコピーしました