JavaScript Tips | 基本・共通ユーティリティ：環境 – 開発環境判定

「開発環境判定」とは何を判定するのか

まず言葉を整理します。
ここでいう「開発環境判定」は、ざっくり言うと

「今このコードは“本番”で動いているのか、“開発用”で動いているのか」

を判定するためのユーティリティです。

業務システムでは、同じコードでも

開発環境（ローカル、開発サーバー）
ステージング環境（テスト用サーバー）
本番環境（お客様が使う環境）

のように、複数の環境で動きます。
そして、環境によってやりたいことが変わる場面がたくさんあります。

ログを詳しく出すのは開発環境だけにしたい。
ダミー API を使うのは開発環境だけ、本番では本物の API を使いたい。
危険なデバッグ用ボタンは本番では絶対に表示したくない。

こういう「環境ごとの振る舞いの違い」を、
コードの中で安全に表現するために「開発環境判定」ユーティリティを用意します。

いちばん基本の考え方：環境名をどこかに持っておく

開発環境判定の本質はとてもシンプルです。

「今は development なのか、production なのか、test なのか」

という“環境名”をどこかに持っておき、
それを見て分岐する、というだけです。

フロントエンドでもバックエンドでも、よくあるのは

NODE_ENV という環境変数を使う
ビルド時に process.env.XXX を埋め込む
設定ファイル（config）に env: "development" のように書く

といったパターンです。

JavaScript のユーティリティとしては、
「環境名を見て、分かりやすいフラグを返す関数」を用意しておくのが定番です。

Node.js やビルド環境での基本形

process.env.NODE_ENV を使った判定

Node.js や、Webpack / Vite / Next.js などのビルド環境では、
process.env.NODE_ENV がよく使われます。

まずは、これをラップしたユーティリティを作ってみます。

function getEnv() {
  const env = process.env.NODE_ENV || "development";

  return {
    name: env,
    isDev: env === "development",
    isProd: env === "production",
    isTest: env === "test",
  };
}

function getEnv() {
  const env = process.env.NODE_ENV || "development";

  return {
    name: env,
    isDev: env === "development",
    isProd: env === "production",
    isTest: env === "test",
  };
}

使い方はこうです。

const env = getEnv();

if (env.isDev) {
  console.log("開発環境用のログを出す");
}

if (env.isProd) {
  console.log("本番環境なので、余計なログは出さない");
}

const env = getEnv();

if (env.isDev) {
  console.log("開発環境用のログを出す");
}

if (env.isProd) {
  console.log("本番環境なので、余計なログは出さない");
}

ここでの重要ポイントは二つです。

環境名を文字列のままバラバラに扱わないこと。
"development" や "production" を直接 if に書かず、isDev や isProd にまとめること。

これをやっておくと、
「環境名の表記を変えたい」「環境を増やしたい」となったときも、
getEnv の中身だけ直せば済みます。

フロントエンドでの開発環境判定（ビルドツール前提）

import.meta.env や process.env を使う場合

Vite や一部のツールでは import.meta.env.MODE、
Webpack 系では process.env.NODE_ENV がフロント側にも埋め込まれます。

例えば Vite なら、こんなユーティリティが書けます。

function getEnv() {
  const env = import.meta.env.MODE || "development";

  return {
    name: env,
    isDev: env === "development",
    isProd: env === "production",
  };
}

function getEnv() {
  const env = import.meta.env.MODE || "development";

  return {
    name: env,
    isDev: env === "development",
    isProd: env === "production",
  };
}

React + Webpack などなら、さきほどの process.env.NODE_ENV 版をそのままフロントでも使えます。

大事なのは、
「どのビルドツールを使っていても、“環境名を一箇所でラップする”」
という発想です。

環境ごとに挙動を変える具体例

例1: ログ出力を開発環境だけにする

本番環境で console.log を大量に出すのは、
パフォーマンスやセキュリティの観点からあまり良くありません。

そこで、ログ用のユーティリティを環境判定付きで用意します。

const env = getEnv();

function debugLog(...args) {
  if (!env.isDev) return;
  console.log("[DEBUG]", ...args);
}

const env = getEnv();

function debugLog(...args) {
  if (!env.isDev) return;
  console.log("[DEBUG]", ...args);
}

使う側は、ただ debugLog を呼ぶだけです。

debugLog("ユーザー情報", user);

debugLog("ユーザー情報", user);

開発環境ではログが出る。
本番環境では何も出ない。

という挙動になります。

ここでの深掘りポイントは、
「呼び出し側は環境を意識しない」ようにしていることです。
環境判定はユーティリティの中に閉じ込める、という設計がとても大事です。

例2: API のベース URL を環境ごとに変える

開発環境では https://dev-api.example.com、
本番では https://api.example.com を叩きたい、というケースはよくあります。

const env = getEnv();

function getApiBaseUrl() {
  if (env.isProd) {
    return "https://api.example.com";
  }
  return "https://dev-api.example.com";
}

const env = getEnv();

function getApiBaseUrl() {
  if (env.isProd) {
    return "https://api.example.com";
  }
  return "https://dev-api.example.com";
}

使う側はこうです。

async function fetchUser() {
  const baseUrl = getApiBaseUrl();
  const res = await fetch(`${baseUrl}/user`);
  return res.json();
}

async function fetchUser() {
  const baseUrl = getApiBaseUrl();
  const res = await fetch(`${baseUrl}/user`);
  return res.json();
}

これで、ビルド時に NODE_ENV だけ変えれば、
同じコードで開発環境・本番環境を切り替えられます。

「環境名を文字列でベタ書きしない」ことの重要性

初心者がやりがちなパターンは、
アプリのあちこちにこう書いてしまうことです。

if (process.env.NODE_ENV === "development") {
  // 何か
}

if (process.env.NODE_ENV === "development") {
  // 何か
}

これをいろんなファイルに散らばせると、
後から環境名を変えたくなったときに地獄を見ます。

例えば、「development ではなく dev にしたい」となったら、
全ファイルを探して置換しないといけません。

それを避けるために、

環境名は一箇所で受け取る。
そこから isDev や isProd のようなフラグを生やす。
アプリ本体は、そのフラグだけを見る。

という構造にしておくことが、業務コードとしてはとても重要です。

「開発環境判定」を使うときの注意点

一つだけ意識しておいてほしいのは、
「環境判定に頼りすぎない」ということです。

何でもかんでも

開発環境なら A
本番環境なら B

と分岐し始めると、
環境ごとに挙動がバラバラになり、テストも難しくなります。

開発環境判定を使うのは、主に次のようなところに絞るのが健全です。

ログやデバッグ用の機能。
モック API と本物 API の切り替え。
危険な操作（データ削除など）のガード。

ビジネスロジックそのものは、
できるだけ環境に依存しないように書く、という意識を持っておくと、
長期的にメンテしやすいコードになります。

小さな練習で感覚をつかむ

簡単な Node.js スクリプトを作って、
NODE_ENV を変えながら動きを確認してみてください。

例えば、次のようなコードです。

function getEnv() {
  const env = process.env.NODE_ENV || "development";

  return {
    name: env,
    isDev: env === "development",
    isProd: env === "production",
  };
}

const env = getEnv();

console.log("env.name:", env.name);
console.log("isDev:", env.isDev);
console.log("isProd:", env.isProd);

function getEnv() {
  const env = process.env.NODE_ENV || "development";

  return {
    name: env,
    isDev: env === "development",
    isProd: env === "production",
  };
}

const env = getEnv();

console.log("env.name:", env.name);
console.log("isDev:", env.isDev);
console.log("isProd:", env.isProd);

これを

NODE_ENV=development node app.js
NODE_ENV=production  node app.js
NODE_ENV=test        node app.js

のように実行してみると、
「環境変数 → ユーティリティ → フラグ」という流れが体感できます。

その感覚をそのままフロントエンドにも持ち込んで、
自分のプロジェクト用の

getEnv
isDev
isProd

を一つ決めておく。
それができた瞬間、あなたのコードは
「場当たり的な環境分岐」から
「設計された環境判定ユーティリティ」に一段レベルアップします。