【コード哲学エッセイ】 設定値は隠す場所じゃなく境界だ

環境変数と設定ファイルが示す責任の切り方

デプロイの直前、画面の右下に小さく時計が進んでいく。
コーヒーは冷めかけている。
ログは、まだ何も言ってくれない。

「ステージングでは動いていたのに」

その一文は、僕のキャリアのなかで何度も繰り返される呪文のようなものでした。
原因を追うと、だいたい最後にたどり着くのは、見えない設定のほうです。

.env は金庫だと思っていた

フリーランスになって間もない頃、小さな Web サービスの保守を任されました。
開発は自分のパソコン、検証はステージング、公開は本番。
三つの世界が、同じコードを走らせているはずなのに、足元の床だけが違う。

当時の僕にとって、設定とは外から差し込む値でした。
とくに .env は秘密の入れ物。
API キーも DB の接続先も、とりあえずそこへ押し込めばリポジトリはきれいに見える。

隠せば安全だ。
隠せば汚れない。

そう信じていたのです。

本番だけ扉が開かない夜

あるリリースの夜、本番だけが静かに落ちました。
エラーメッセージは曖昧で、ログには「接続できません」とだけ残る。
ステージングの画面を開くと、同じビルド番号、同じコミットハッシュ。

差分を探すうちに、.env の一行が目に入りました。
ステージングにはあるのに、本番のホスト環境には無い変数。
名前は似ている。
綴りはほんの少し違う。

そのとき、胸の奥が冷えたのはサーバーが壊れたからではありません。
僕が設定を誰の責任でもない霧のなかに置いていたからでした。

隠すほど地図が消える

一人で書くうちは問題になりにくい。
頭のなかに暗黙の辞書があるからです。

APP_URL が本番と開発で違うこと。
メール送信を止めるフラグが検証だけに効くこと。
「あの変数、触るな」という口頭の禁忌。

それらは、説明されないまま環境にだけ生きている。

引き継ぎの日、次の担当の人が README を開き、.env.example を開き、それでも迷子になる光景を見てきました。
玄関は整っている。
けれど、部屋の仕切りが壁に書かれていない。

僕が恐れているのは、相手の理解力の不足ではありません。
昨日までの自分がとりあえず隠したことで、今日の誰かが立ち止まることです。

境界とは責任の線引きだ

いまの僕は、設定をこう捉えています。

設定値は、秘密をしまう場所ではなく責任が切り替わる境界だ。

アプリケーションの中で決めること。
インフラが渡すこと。
運用が触ること。
開発者がローカルだけで持つこと。

その境目が曖昧なままだと、バグはどこかの誰かのミスに逃げていきます。
境界がはっきりしていると、変更は名前のついた担当に帰ってくる。

環境変数と設定ファイルの役割分担

すべてを .env に寄せるのも、YAML を巨大にするのも、どちらも息が詰まります。
僕が大切にしているのは、二つの器の違いを設計として選ぶことです。

環境変数は、たいてい環境ごとに変わる値向きです。
接続先、機能フラグ、外部サービスの向き先。
デプロイのたびに差し替わるものは、外側に置いたほうがコードは素直に振る舞います。

設定ファイルは、たいていチームで共有する意味向きです。
タイムアウトの既定値、リトライ回数、ログの粒度。
「このサービスはこういう性格だ」と読める物語をリポジトリに残せる。

秘密は、どちらかというより第三の場所にいくべきです。
Vault、シークレットマネージャ、ホストが管理する資格情報。
.env は開発の入口として便利でも、本番の金庫代わりにはなりにくい。
そこを混同すると境界は再び霧になります。

僕が線を引くときの三つの問い

設定を増やす前に、僕は自分に三つだけ問います。

答えがはっきりしない値は、まだ早いのかもしれません。
ハードコードでいい。
ローカルだけでいい。
三回、同じ場所で迷子になってから、ようやく .env や config に昇格させても遅くはない。

逆に、答えだけはっきりしているのに「とりあえず隠す」設定ほど未来の夜を長くします。

見える境界は優しい

.env.example に一行だけコメントを添える。
config の先頭に「本番では上書きされる」と書く。
デプロイ手順の最初に、ここを触る人を明示する。

派手なリファクタリングより、小さな地図のほうが引き継ぎでは効くことが多いです。

境界は壁ではありません。
誰かを締め出すための柵でもない。
次の人が迷わず歩ける道しるべだと思っています。

僕がいまエディタの前で思うこと

設定を開くたび、僕は昔の自分に声をかけます。

「ここは隠す場所か
　それとも責任の境目か」

隠すことに安心した設定ほど、あとから説明を要求してくる。
境界として引いた設定は、たとえ値が間違っていても直す場所がはっきりしている。

デプロイの夜、コーヒーを温め直す回数はまだ減りきっていません。
それでも、「どこが違うのか」で立ち止まる時間だけは、少しずつ短くなってきた気がします。

設定値は秘密の倉庫ではない。
チームと環境とコードのあいだに引く、静かな線なのだと、今日も自分に言い聞かせています。

ひとりごと

若い頃の僕は、.env に全部押し込めば賢く見えると思っていました。
きれいなリポジトリの幻影に、少しだけ酔っていたのかもしれません。

いまもデプロイの夜は、緊張します。
それでも、「隠した」より「線を引いた」設定のほうが、朝にはっきりしていると感じるようになりました。

同じように、設定の霧のなかで立ち止まった誰かの小さな地図になればうれしいです。

Substack はじめました

ここまで読んでくださり、ありがとうございました。

X では短い言葉で、note では整理した文章で発信していますが、Substack では、もっと途中経過の思考や削りきらなかった葛藤、技術者として日々考えていることを書いています。

もし興味があれば、覗いてみてください。

会社員（元システムエンジニア）からフリーランスとなり、
15 年目に突入しました。

納期と障害対応に追われる毎日の中で、
「もっと自由に、もっと本質的にものづくりがしたい」
そう思ったのが独立のきっかけです。

現在は、技術と文章を軸に、
仕事がラクになる仕組みや続けられる働き方を発信しています。

あわせて読みたい

▼ コードを渡す日に、暗黙の設定を残したくないときに

README だけでは足りない奥の部屋。
引き継ぎで試される、説明と誠実さの輪郭を描いたエッセイです。

▼ 初見のリポジトリで、どこから読めばいいか迷ったときに

玄関を整えることと、中の地図を残すこと。
プロジェクトの第一印象を設計する視点がまとまっています。

▼ 失敗がどこで起きたかを教えてくれると感じたときに

エラーを敵ではなく案内役として迎える。
境界の設計と並べて読みたい、もう一本の線引きの話です。

次の一歩を一緒に決める作戦会議室へ

デプロイのたびに「本番だけ動かない」と立ち止まる夜は、一人だと長く感じます。

設定の切り方、引き継ぎの地図の残し方。
現場で使える具体物として、僕が試してきたやり方を作戦会議室でも共有しています。

同じように境界を引きたい方と一緒に線を太くしていきませんか。

参加する