JavaScript | 基礎構文：条件分岐 – ガード節（早期 return）

JavaScript JavaScript
2025.12.13
スポンサーリンク

ガード節（早期 return）を一言でいうと

ガード節は、
「ダメな条件を先に弾いて、良いパターンだけを最後にスッキリ書くための書き方」 です。

関数の最初で、

「この条件なら、ここで終わり（return）」
「この条件でもダメなら、ここで終わり」

と早めに抜けることで、
「本来やりたいメイン処理」を、ネストの少ないキレイな形で書けるようにします。

ここが重要です。
ガード節は「かっこいいテクニック」ではなく、
“ネスト地獄を避けるためのシンプルな考え方” です。
「良い条件を if で囲い込む」のではなく、「ダメな条件を先に return で追い出す」という発想への切り替えがポイントです。

まずは「ガード節がない」ネスト地獄を見てみる

ネストが深い if の典型例

例えば、「ユーザーが有効なら挨拶する」関数を、
素直に if の中に if を書くとこうなりがちです。

function greet(user) {
  if (user) {
    if (user.isActive) {
      if (!user.isBanned) {
        console.log("こんにちは、" + user.name + "さん");
      }
    }
  }
}
JavaScript

読むときに、
「if のかっこがどこまで続いているのか」を目で追わないといけません。

やっていることは単純で、

  • user が存在する
  • 有効なユーザー
  • 凍結されていない

なら挨拶する、というだけなのに、
コードからはその「シンプルさ」が伝わりにくい状態です。

「やりたいこと」が一番下に埋もれてしまう

上の例では、
本当に書きたいメイン処理である

console.log("こんにちは、" + user.name + "さん");
JavaScript

が、
ネストの一番奥に押し込められています。

ここが重要です。
ネストが深い if は、「本当にやりたい処理」をどんどん奥に押し込んでしまう という欠点があります。
人間が読みやすいのは、「メインの処理」が上のほう・浅いところにあるコードです。
そこで役に立つのが、ガード節（早期 return）です。

ガード節で書き直すとどう変わるか

ダメなケースから先に return する

先ほどの greet を、ガード節で書き直してみます。

function greet(user) {
  if (!user) {
    return;
  }

  if (!user.isActive) {
    return;
  }

  if (user.isBanned) {
    return;
  }

  console.log("こんにちは、" + user.name + "さん");
}
JavaScript

流れはこうです。

  1. user がいなければ、即 return（何もしないで終わり）
  2. user が非アクティブなら、即 return
  3. 凍結されていれば、即 return
  4. ここまで来たら「ちゃんとしたユーザー」なので、安心して挨拶できる

ネストが無くなり、
メイン処理が一番下にスッキリ置かれています。

ガード節の形を言葉にすると

ガード節のパターンは、ほとんどがこんな形です。

function func(...) {
  if (ダメな条件1) {
    return;
  }

  if (ダメな条件2) {
    return;
  }

  // ここまで来たら「全部OK」
  // メイン処理
}
JavaScript

「ここから先は、もう“正常な世界”しかない」
という前提でコードを書けるようになります。

ここが重要です。
ガード節の本質は、“正常な世界”を早く取り戻すことです。
ダメなものは早めに帰ってもらって、
残った「大丈夫なケース」だけでメインの処理を書く。
その切り替えが、コードの見通しを劇的によくします。

else 地獄をガード節で救出する

else が何段も続くパターン

次のような関数を考えます。
「料金プランに応じてメッセージを返す」例です。

function getMessage(plan) {
  if (plan === "free") {
    return "無料プランです";
  } else {
    if (plan === "basic") {
      return "ベーシックプランです";
    } else {
      if (plan === "premium") {
        return "プレミアムプランです";
      } else {
        return "不明なプランです";
      }
    }
  }
}
JavaScript

動きは合っていますが、
else の入れ子が深くて読みにくいです。

ガード節で「早めに返す」書き方

これをガード節で書き直すとこうなります。

function getMessage(plan) {
  if (plan === "free") {
    return "無料プランです";
  }

  if (plan === "basic") {
    return "ベーシックプランです";
  }

  if (plan === "premium") {
    return "プレミアムプランです";
  }

  return "不明なプランです";
}
JavaScript
  • 各パターンで「その場で return」
  • どれにも当てはまらなければ、最後の 1 行で「不明なプラン」

という、上から順に「早期に返していく」形 になっています。

ここが重要です。
ガード節は、「else を減らす」ためのパターンでもあります。
「この場合はここで終わり」と決めて return してしまえば、
その下でわざわざ else を書かなくてもよくなります。
結果として、階段状のネストが平らになり、読みやすくなるのです。

典型パターン：バリデーション（入力チェック）＋メイン処理

ガード節がもっとも活きる場面

フォームの送信処理などで、
「入力値が正しいかチェック → 正しければ保存」という流れはよく出てきます。

ガード節を使うと、こう書けます。

function submitForm(data) {
  if (!data.name) {
    console.log("名前は必須です");
    return;
  }

  if (!data.email) {
    console.log("メールアドレスは必須です");
    return;
  }

  if (!data.agreed) {
    console.log("利用規約に同意してください");
    return;
  }

  console.log("送信しました:", data);
}
JavaScript
  • name が無ければ、その場でメッセージを出して終了
  • email が無ければ、その場で終了
  • agreed が false なら、その場で終了
  • ここまで通り抜けたら、全て OK なので安心して送信処理

という流れです。

もしガード節を使わなかったら

同じ処理を、ネストだけで書くとこうなります。

function submitForm(data) {
  if (data.name) {
    if (data.email) {
      if (data.agreed) {
        console.log("送信しました:", data);
      } else {
        console.log("利用規約に同意してください");
      }
    } else {
      console.log("メールアドレスは必須です");
    }
  } else {
    console.log("名前は必須です");
  }
}
JavaScript

読み比べてみると、
どちらが落ち着いて読めるかは、一目瞭然 だと思います。

ここが重要です。
バリデーション（入力チェック）では、
「ダメなパターンが多い → それぞれ早めに return する」
という形が非常に相性がいいです。
「OK の流れ」を、ネストの一番奥に押し込まないこと。
これだけで、読めるコードになります。

早期 return の注意点と “やりすぎ問題”

return が多すぎて「出口」が分からなくなる

ガード節は便利ですが、
何でもかんでも早期 return に頼ると、今度は

  • 関数のあちこちに return が散らばる
  • 「どこで終わる可能性があるか」を追いにくくなる

という問題が出ます。

例えば、こういうのは少しやりすぎです。

function complex(value) {
  if (条件1) {
    // ...
    return;
  }

  // 中略（たくさん処理）

  if (条件2) {
    // ...
    return;
  }

  // さらに中略

  if (条件3) {
    // ...
    return;
  }

  // まだいろいろ書いてある…
}
JavaScript

「どこで終わるか」が脳内で追いきれなくなってきたら、
それは関数の責務自体が大きすぎるサインでもあります。
その場合は、関数を分割することも検討したほうがいいです。

メインの「成功パス」が見えるかどうかを基準にする

ガード節を使うときの目安は、

この関数の「成功パターン」が、
上から下にスッと追える形で書けているか？

です。

ガード節を使っても、
メインの処理より前の「チェック」が多すぎるなら、
そのチェック部分を別関数に切り出してしまうのも選択肢です。

function isValidUser(user) {
  if (!user) return false;
  if (!user.isActive) return false;
  if (user.isBanned) return false;
  return true;
}

function greet(user) {
  if (!isValidUser(user)) {
    return;
  }

  console.log("こんにちは、" + user.name + "さん");
}
JavaScript

ここが重要です。
ガード節は、「成功パターンを主役にする」ために使います。
使った結果、かえって成功パターンが見えにくくなったなら、
それは設計を一段階上から見直すタイミングです。

初心者として「ガード節（早期 return）」で本当に押さえてほしいこと

ガード節とは、「ダメな条件を先にチェックして、その場で return してしまう書き方」。
これにより、関数の中で「正常なパターン」だけを最後にスッキリ書けるようになる。

入れ子の if や else を減らせる。
特にバリデーション（入力チェック）や権限チェックなど、「ダメなパターンが多い」場面で威力を発揮する。

書き方の基本は、
「if (ダメ条件) { return; }」を上から順に並べていき、
最後に「メインの処理」を書く形。

ただし、早期 return が関数内に散らかりすぎると、逆に出口が多くなりすぎて読みづらくなる。
その場合は、チェック部分を別関数にして「isValidXxx」などでまとめてしまうと読みやすくなる。

ここが重要です。
ガード節は、“条件分岐の書き方”というより、“読みやすい関数を作るための考え方” です。
「この関数のメインの仕事は何か？」
「その仕事を始める前に、どんな条件で即終了していいか？」
を一度言語化してから、上から順にガード節を書いてみてください。
そうすると、あなたの if 文は「動くだけ」から「意図が伝わる」ものに変わっていきます。

最後に、小さな練習をおすすめしておきます。

  1. 自分で、ネストの深い if をわざと書いてみる（ユーザーのチェック、フォームのチェックなど）。
  2. その関数を、「ガード節（早期 return）」を使って書き直してみる。
  3. before / after を見比べて、「どこが読みやすくなったか」「どこはまだスッキリしないか」を自分の言葉で説明してみる。

この「書き直してみる」体験を一度しておくと、
現場でネスト地獄に遭遇したときに、「あ、これはガード節で救えるやつだ」と気づけるようになります。

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