検証では動いたのに本番だけエラーになり、開発・検証・本番の設定の違いを一覧で見比べて原因を落ち着いて探している一人運用の保守担当者
リリース・変更管理約16分

環境差で事故らない設定管理｜開発・検証・本番を一人運用で

「検証環境では問題なく動いたのに、本番に出したとたんエラーになった」。

保守運用をしていると、この場面に何度も出くわします。コードは同じ。手順も同じ。なのに本番だけ落ちる。原因を探しても、プログラムのどこにもおかしいところが見つからない——。

こういうとき、犯人はたいていコードではありません。環境ごとに違う「設定」です。接続するデータベースの場所、外部サービスのAPIキー、デバッグ表示のオン・オフ、メールの送信先。これらは環境（開発・検証・本番）ごとに違って当たり前で、その違いが手元で見えていないと、リリースのたびに「今度は大丈夫だろうか」と冷や汗をかくことになります。

この記事では、環境差を「見える化」して事故を防ぐ設定管理の考え方を、一人運用でも今日から始められる形で一緒に深掘りしていきます。大がかりな仕組みは要りません。まずは「どの設定が、どの環境で、どう違うのか」を1枚に書き出すところから始めれば十分です。

結論：環境差の事故は、「設定が違うこと」ではなく「違いが見えていないこと」から起きます。防ぐためにやることは4つ。①環境ごとに変わる設定を1枚のリストに洗い出す、②設定をコードから切り離し、環境ごとに分けて管理する、③パスワードやAPIキー（秘密の情報）はコードやGitに置かない、④本番へ出す前に「本番の設定を向いているか」を必ず1回確認する。まずは自分のシステムで「環境ごとに違う設定」を書き出す、その1枚から始めましょう。

環境の構成（開発だけ／開発＋本番の2つ／開発・検証・本番の3つ）や、使っているツール（.envファイル・設定ファイル・環境変数・管理画面）は現場によってさまざまです。この記事の考え方を出発点に、自分の環境のやり方に読み替えてください。本番に反映する前には、必ず検証環境や公式情報で確認しましょう。

そもそも「環境差」とは何か

まず、言葉を軽く整理しておきます。難しい話ではありません。

多くのシステムには、目的の違う「置き場所」がいくつかあります。これを環境と呼びます。

用語メモ：環境変数とは、プログラムの外側（OSやサーバー側）に置いておく設定値のこと。コードの中に直接書くのではなく、「この環境ではこの値を使ってね」と外から渡します。.env（ドットエンブ）ファイルは、その値をまとめて書いておくテキストファイルの通称です。どちらも「設定をコードの外に出す」ための入れ物、とだけ押さえておけば大丈夫です。

そして、これらの環境では同じコードでも設定が違います。開発では自分のPCのDBにつなぎ、本番では本番のDBにつなぐ。開発ではエラーを画面に全部出し、本番では出さない。この「同じコードなのに環境ごとに変える値」の違いが、環境差です。

環境差そのものは悪いことではありません。むしろ必要なものです。問題になるのは、その違いが管理されず、見えなくなっているときだけです。

なぜ環境差で事故が起きるのか

環境差の事故が「設定がコードに混ざっている」「秘密情報が散らばっている」「本番の設定を確認していない」の3つから起きることを示した図
環境差の事故は、この3つのすき間から生まれやすい

「気をつけているのに、なぜか環境差で事故る」。これは注意力の問題ではなく、仕組みのすき間から起きています。よくある原因はこの3つです。

この3つに共通するのは、「設定が今どうなっているか」を人が目で確かめられない状態だということです。裏を返せば、設定をコードから切り離し、環境ごとに整理して、出す前に見比べられるようにする——これだけで、環境差の事故の大半は防げます。次から、その具体的なやり方を見ていきます。

ステップ1：環境ごとに変わる設定を「1枚に洗い出す」

最初の一歩は、ツールの導入ではありません。自分のシステムで、環境ごとに違う設定を全部書き出すことです。これが土台になります。

いきなり完璧を目指さず、思いつくものから表にしていきます。よくある「環境ごとに違う設定」は、たとえばこんなものです。

設定の種類具体例なぜ環境で違うのか
データベース接続先ホスト名・DB名・ユーザー・パスワード環境ごとに別のDBを使うため
外部サービスのキー決済・メール送信・地図・SMSのAPIキー本番と検証で別アカウント・別キーを使うため
ドメイン・URL自サイトのURL、コールバック先環境ごとにアドレスが違うため
デバッグ設定エラー表示のオン・オフ、ログの詳しさ本番では詳細を隠す・ログを絞るため
メール送信先通知先アドレス、送信の有効・無効検証で本物の顧客に誤送信しないため
各種フラグ新機能のオン・オフ、外部連携の有無環境ごとに使う機能を変えるため

この表を、自分のシステムに合わせて埋めていきます。列に「開発／検証／本番」を足して、それぞれの値（または「ここに書く」というメモ）を入れれば、環境差の全体像が1枚で見えるようになります。

秘密の情報（パスワード・キー）は、この一覧に実際の値そのものは書かないでください。「本番用のキーがある」という項目の存在だけを書き、値の実物は後述の安全な置き場所で管理します。一覧はあくまで「何が環境ごとに違うかの地図」です。

この地図があるだけで、リリース前に「本番だと、この6項目が変わるんだな」と目で追えるようになります。まずはここまでで、事故の多くは見通せるようになります。

ステップ2：設定を「コードから切り離す」

洗い出しができたら、次は設定をコードの外に出すことを目指します。これは、環境差の事故を根っこから減らす、いちばん効く考え方です。

なぜ切り離すのか

設定がコードの中に書いてあると、環境ごとに「コードを書き換える」必要が出ます。書き換えは、そのままミスの入口です。一方、設定をコードの外に置いておけば、コードは全環境で同じまま、外側の設定だけを環境ごとに差し替える形になります。

これは、世界中で広く参照されている設計指針（The Twelve-Factor App の「Config」の項）でも、基本原則として挙げられている考え方です。難しく捉えず、「変わるものは外へ、変わらないものはコードに」と覚えておけば十分です。

どう切り離すか（現場での形）

具体的な入れ物は、使っている技術によって変わりますが、よくあるのは次の形です。

どれを使うにせよ、大事なのは「コードの中に接続先やキーを直接書かない」ことと、「環境ごとの設定は、はっきり別々に分ける」ことの2点です。今ベタ書きになっているなら、いきなり全部でなく、まずDB接続先とAPIキーだけを外に出すところから始めれば十分です。

ステップ3：秘密の情報は「コードやGitに置かない」

パスワードやAPIキーはコードやGitに置かず、安全な置き場所に分けて保管し、コードには入れ物の名前だけを書くことを示した図
秘密情報は別の金庫へ。コードには「どこを見るか」だけを書く

環境差の管理でいちばん注意したいのが、パスワード・APIキー・トークンといった「秘密の情報」の扱いです。ここは事故ると環境差だけでなく、セキュリティの問題にもなります。

守りたい原則はシンプルです。

なぜここまで気をつけるかというと、一度うっかりGitに入れた秘密情報は、後から消しても履歴に残るからです。公開リポジトリなら言うまでもなく、社内であっても、退職者のPCや古いクローンに残り続けます。「後で消せばいい」が効かない領域なので、最初から入れないのがいちばん確実です。

もし過去にコミットしてしまった疑いがあるなら、慌てて履歴だけ消すより先に、そのキー・パスワードを新しいものに切り替える（無効化する）のが本筋です。漏れた前提で作り直すのが、いちばん安全な初動です。

一人運用だと「自分しか触らないから」とつい緩みがちですが、ここだけは環境差の話を超えて、未来の自分と引き継ぐ誰かを守るための線引きです。難しく考えず、「秘密は金庫、コードには金庫の場所だけ」と覚えておきましょう。

ステップ4：本番へ出す前に「本番を向いているか」確認する

設定を切り離して整理できても、最後のひと押しが抜けると事故ります。それがリリース時の確認です。

環境差の事故は、多くが「本番に出す瞬間」に起きます。検証では検証用の設定で動くので、本番だけの設定ミスは、リリースするまで表に出てこないからです。だから、リリース手順の中に「設定の確認」を1工程として組み込んでおきます。

出す前に確認したいのは、たとえばこんな点です。

ポイントは、これを記憶や勘でなく、リストを見ながら確認することです。ステップ1の一覧が、ここでそのまま「本番リリース前チェックリスト」として効いてきます。作った地図を、出す直前にもう一度なぞる。それだけで「本番だけ設定が違った」という事故は、かなり防げます。

この確認は、リリース手順書（runbook）の中に1ブロックとして書いておくのがおすすめです。「進む手順」の前に「設定の確認」を置いておけば、忙しいときでも読むだけで抜けを防げます。

具体例：よくある3つの「環境差の事故」

現場では、こんな形で環境差の事故が起きがちです。原因と防ぎ方をセットで見てみましょう。

どれも「もっと注意していれば」ではなく、設定を外に出す・一覧を作る・出す前に確認するのどれかがあれば救えたものばかりです。人の注意力に頼らず、仕組みで受け止めるのがコツです。

影響：設定を整理すると、何が変わるか

環境差を管理できるようになると、目に見えるトラブルが減るだけでなく、日々の運用がぐっと楽になります。

逆に、設定がコードに混ざったまま・秘密情報が散らばったままだと、リリースのたびに神経を使い続けることになります。しかもその負担は、環境が増えるほど、時間が経つほど重くなります。早めに地図を作っておくことが、未来の自分の負担を軽くします。

明日やること：まず「環境差の一覧」を1枚つくる

いきなり全部を仕組み化しなくて大丈夫です。明日できる、いちばん小さな一歩はこれです。

  1. 自分のシステムで、環境ごとに違う設定を思いつくまま書き出す（DB接続先・APIキー・URL・デバッグ設定・メール送信先など）。ステップ1の表をたたき台にする。
  2. 表に「開発／検証／本番」の列を足し、それぞれの値（または管理している場所）を埋める。秘密の情報は、値そのものでなく「ここにある」という所在だけを書く。
  3. その中に、コードにベタ書きされている設定がないか探す。あれば、まずはDB接続先とAPIキーだけでも設定ファイルや環境変数に外へ出せないか検討する。
  4. 秘密情報がGitに入っていないかを確認する。入っていれば、.gitignore で除外し、必要ならキーの入れ替えを検討する。
  5. 作った一覧を、リリース手順書か作業メモに「本番リリース前チェック」として残す。次からは、出す前にこれをなぞる。

環境差の一覧を1枚つくるだけでも、「本番だけ設定が違うかも」という漠然とした不安が、「ここを見れば分かる」に変わります。完璧な設定管理の仕組みを一気に作ろうとせず、まずこの1枚から始めましょう。

「環境差で事故らない」チェックリスト

リリース前や、設定の棚卸しのときに使える確認項目です。コピーして、自分のシステムに当ててみてください。全部やる前提ではありません。まずは「これだけは」の3つから。

これだけは（最低ライン）

余裕があるとき（任意）

全部に○が付かなくても大丈夫です。上の3つだけ押さえれば、まずは「本番だけ設定が違った」という事故から抜け出せます。下の項目は、設定を棚卸しするときや手が空いているときに、少しずつ足していけば十分です。

よければ、こちらも

環境差の管理は、リリース手順・本番反映前の確認・変更の記録と地続きの仕事です。あわせて整えておくと、リリースのたびの不安がぐっと減ります。

環境ごとの設定を一覧に整理でき、本番リリースを落ち着いた気持ちで進められるようになった保守運用の担当者

「検証では動いたのに」で冷や汗をかくのは、あなたの確認が甘いからではありません。環境ごとの違いが、見えるところに置かれていないだけです。設定を1枚の地図にしておけば、その違いは確かに見えてきます。 今日は、環境ごとに違う設定を書き出す——その1枚から始めれば十分です。その小さな地図が、リリースのたびの不安から、あなたを少しずつ解放してくれます。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語