客先固有の値をリポジトリに入れないための設定ファイル分離

🧨直書きが事故になる瞬間

サーバーパスや端末固有の値を本体に直書きすると、端末の入れ替えやフォルダ変更で必ず動かなくなる。

自動化スクリプトには、ほぼ必ず「その環境でしか正しくない値」が出てきます。

共有フォルダのサーバーパス。出力先のディレクトリ。端末ごとに違うドライブレター。担当者名を含んだ保存先。

こういう値をスクリプト本体に直接書くと、その場では確かに動きます。

問題は、あとからやってきます。

端末を入れ替えた。フォルダ構成が変わった。別の担当者の環境で動かしたい。——そのたびにパスが合わなくなって、動かなくなる。

しかも本体を書き換えるので、直すたびに「どこをいじったか」が分からなくなっていきます。

受託だと、納品後のこういう小さな詰まりが積み重なって、じわじわ信頼を削ります。

🗂️config.local に切り出す

環境に依存する値だけを別ファイルに集め、ロジック本体は一切それを直書きしないようにする。

対策はシンプルです。環境に依存する値だけを、別ファイルに集める。

受託した自動化スクリプトでも、サーバーパスや出力先といった値は config.local に寄せ、ロジック本体では一切それらを直書きしないようにしました。

本体がやるのは「設定ファイルを読み込む。無ければ、分かるエラーで止まる」。それだけです。

あわせて、値の一覧と意味を書いた config.local.example をリポジトリに置きます。

これはサンプルなので、実値は入っていません。だからコミットしても安全です。

新しい端末で展開するときは、この example を config.local にコピーして、その環境のパスを埋めるだけ。

「何を設定すればいいか」がファイルとして残るので、口頭の引き継ぎに頼らずに済みます。

🚫.gitignore で管理対象から外す

切り出した実値ファイルは .gitignore で追跡から外し、サンプルだけをリポジトリに残す。

切り出した config.local は .gitignore に登録して、Git の管理対象から外します。

これで、実際のサーバーパスや端末固有の値がリポジトリに入らなくなる。履歴にも残りません。

管理するのは、あくまでサンプルの config.local.example の方だけ。この切り分けが肝です。

「実値は無視、サンプルは追跡」——この組み合わせは、フレームワークの世界でも標準的なやり方です。

Next.js でも 環境変数のドキュメント で .env.local を Git 管理から外すことが推奨されています。

名前や仕組みは違っても、「環境ごとに変わる値はコードと分けて、リポジトリには入れない」という発想は共通です。

📦実値はどこから取るか — 運用の設計

リポジトリに入れないと決めたら、本物の値は既設端末かオフライン保管の控えから取る、と出どころを固定する。

リポジトリに入れないと決めた瞬間、次の問いが立ち上がります。

「では、本物の値はどこに置くのか」。

受託の現場だと、クラウドの秘密管理サービスをいつでも使えるとは限りません。

その受託先のケースでは、すでに稼働している既設端末の config.local をそのまま参照するか、オフラインで保管してある控えから値を取り出す、という段取りにしました。

地味に見えて、これは大事な設計です。

値の出どころを「既設端末」か「オフライン保管の控え」と決めておくと、新しい端末を立ち上げるときの手順が一本道になります。

誰かの記憶や、チャットのログを掘り返す必要がなくなる。引き継ぎの属人性が下がります。

ここまで含めて、はじめて設定ファイル分離が運用として回り始めます。

💡まとめ — 小さな作法が移行を軽くする

設定ファイルを分けておくという地味な作法が、半年後の移行や再展開の重さを大きく変える。

• 環境依存の値は本体に直書きしない。 サーバーパスや端末固有の設定は config.local に切り出す。
• 実値は .gitignore で外し、サンプルだけ追跡する。 config.local.example が「何を設定するか」の手順書になる。
• 値の出どころを運用として決めておく。 既設端末やオフライン保管の控えから取る、と道筋を固定する。

派手な機能ではありません。でも、この一手間を最初に仕込めるかどうかで、あとの再展開はずいぶん楽になります。

i-Willink は受託の自動化でも、こうした「運用で詰まらない構造」を最初から仕込むことを大切にしています。