「本番環境判定」は何のためにあるのか
「本番環境判定」は、
「今このコードは“お客さんが触っている本番”なのか、それ以外（開発・検証）なのか」
を判定するためのユーティリティです。
業務システムでは、同じコードが
開発環境（ローカル・開発サーバー）
ステージング環境（テスト用サーバー）
本番環境（実際のユーザーが使う環境）
で動きます。
そして、本番だけは特別扱いしたいことがたくさんあります。
本番ではデバッグログを出したくない。
本番では危険なボタン（強制リセットなど）を出したくない。
本番ではモック API ではなく、必ず本物の API を使いたい。
これを安全に、かつ分かりやすくコードに落とし込むために
「本番環境判定ユーティリティ」を用意します。
基本の考え方：環境名から「本番かどうか」を決める
本番環境判定の本質はシンプルです。
「今の環境名が production かどうか」
をどこかで判定するだけです。
よく使われる情報源は、次のようなものです。
Node.js の process.env.NODE_ENV
Vite などの import.meta.env.MODE
自前の設定ファイル（config）に書いた env: "production"
これをそのままアプリのあちこちで if に書くのではなく、
「本番かどうか」を返す小さな関数に閉じ込めるのがポイントです。
Node.js / ビルド環境での本番判定ユーティリティ
process.env.NODE_ENV を使う基本形
まずは、サーバーサイドやビルド済みフロントでよく使う形から。
function isProd() {
const env = process.env.NODE_ENV || "development";
return env === "production";
}
使い方はとてもシンプルです。
if (isProd()) {
console.log("本番環境です");
} else {
console.log("本番以外（開発・テスト）です");
}
ここでの重要ポイントは、
"production" という文字列をアプリ本体に直接書かない
「本番かどうか」の判定ロジックを isProd に閉じ込める
ということです。
将来、環境名の付け方を変えたくなったり、
「本番扱いしたい環境」を増やしたくなったときも、
直すのは isProd の中だけで済みます。
フロントエンドでの本番判定（Vite / Webpack など）
import.meta.env や process.env をラップする
Vite なら import.meta.env.MODE、
Webpack 系なら process.env.NODE_ENV がフロントにも埋め込まれます。
Vite の例だと、こんな感じです。
function isProd() {
const mode = import.meta.env.MODE || "development";
return mode === "production";
}
React + Webpack などなら、先ほどの process.env.NODE_ENV 版をそのまま使えます。
大事なのは、
「どのツールを使っていても、アプリ側は isProd() しか知らない」
という状態にしておくことです。
ビルドツールを変えたときも、isProd の中身だけ差し替えれば、アプリ本体はそのまま動きます。
本番環境だけ挙動を変える具体例
例1: デバッグログを本番では封印する
本番で console.log を大量に出すのは避けたいので、
ログ用のユーティリティを本番判定付きで用意します。
function debugLog(...args) {
if (isProd()) return;
console.log("[DEBUG]", ...args);
}
使う側は、ただ debugLog を呼ぶだけです。
debugLog("ユーザー情報", user);
開発・検証環境ではログが出る。
本番環境では何も出ない。
という挙動になります。
ここでの深掘りポイントは、
「呼び出し側は“本番かどうか”を意識しない」ようにしていることです。
環境判定はユーティリティの中に閉じ込める、という設計がとても大事です。
例2: 本番だけ本物の API を使う
開発中はモック API を使い、本番では本物の API を使いたいケース。
function createApiClient() {
if (isProd()) {
return createRealApiClient();
} else {
return createMockApiClient();
}
}
const api = createApiClient();
アプリ本体は api を使うだけで、
「今が本番かどうか」は意識しません。
async function loadUser() {
const user = await api.getUser();
// 本番なら本物の API、開発ならモックが呼ばれる
}
「本番判定を直接 if に書かない」ことの意味
初心者がやりがちなのは、
アプリのあちこちにこう書いてしまうことです。
if (process.env.NODE_ENV === "production") {
// 本番用
} else {
// 開発用
}
これをいろんなファイルに散らばせると、
後から環境の扱いを変えたくなったときに、全部探して直す羽目になります。
それを避けるために、
環境名は一箇所で受け取る
「本番かどうか」を返す isProd を用意する
アプリ本体は isProd() だけを見る
という構造にしておくことが、業務コードとしてはとても重要です。
本番判定に頼りすぎない、という視点も大事
便利だからといって、何でもかんでも
本番なら A
本番以外なら B
と分岐し始めると、
環境ごとに挙動がバラバラになり、テストも難しくなります。
本番判定を使うのは、主に次のようなところに絞るのが健全です。
ログ・デバッグ機能の ON/OFF
モックと本物の切り替え
危険な操作（データ削除・強制リセットなど）のガード
ビジネスロジックそのものは、
できるだけ環境に依存しないように書く。
「本番だからロジックを変える」のではなく、
「本番だから“見せ方”や“安全装置”を変える」という意識を持つと、
長期的にメンテしやすいコードになります。
小さな練習で感覚をつかむ
簡単なスクリプトを書いて、NODE_ENV を変えながら動きを見てみてください。
function isProd() {
const env = process.env.NODE_ENV || "development";
return env === "production";
}
console.log("NODE_ENV:", process.env.NODE_ENV);
console.log("isProd():", isProd());
これを
NODE_ENV=development node app.js
NODE_ENV=production node app.js
NODE_ENV=test node app.js
のように実行してみると、
「環境変数 → isProd → 挙動の違い」という流れが体感できます。
その感覚をそのままフロントにも持ち込んで、
自分のプロジェクト用に
export function isProd() { ... }
を一つ決めておく。
それができた瞬間、あなたのコードは
「場当たり的な本番分岐」から
「設計された本番環境判定ユーティリティ」に一段レベルアップします。