環境ごとの .env で同じ値を何回も直している ── 環境を 1 つの project にまとめ、共通の値は Common に 1 つ置く

上原正吉（EarthLink Network Co., Ltd.）。AI会社・AI社員による業務自動化と、人の逐次介入なしに24時間自動開発を回す仕組みを自社で実践しています。開発ノウハウと具体的な設定方法、運用して分かった改善点を公開しています。

環境ごとの .env で同じ値を何回も直している ── 環境を 1 つの project にまとめ、共通の値は Common に 1 つ置く

この記事は、連載「dotvault の使い方 ── .env を手で配るのをやめ、CI・チーム・AI エージェントに 1 コマンドで配るまで」の第 3 回です。この連載が終わる時に、dotvault を誰でも無料で使える形で公開する予定です。

私は、npm script に環境ごとの起動コマンドを書いて、実行の仕方で環境を分けていました。値は環境ごとに別々の .env にあり、development・staging・production と、環境の数だけ置き場所が分かれます。

困るのは、全環境で同じ値です。外部サービスの公開キーや、メールの送信元のアドレスのように、どの環境でも同じ値を使う key は、環境の数だけ書くことになります。その値を変える時は、全部の置き場所を直す必要があります。1 つ直し忘れると、その環境だけ古い値のまま動きます。

この回では、環境ごとの値を dotvault の 1 つの project にまとめます。dotvault では、環境ごとに分かれていた .env が、1 つの project の中の development・staging・production の環境としてまとまり、管理コンソールの 1 か所で、環境を切り替えて値を見られます。全環境で同じ値は、Common という場所に 1 つだけ置けます。Common に置いた値は、どの環境を pull しても .env に入るので、変える時は 1 か所を直すだけです。2 回目で作った demo-app を、そのまま使います。

結論

• 環境ごとに分かれていた .env は、1 つの project の中の development・staging・production の環境としてまとまります。 環境ごとの値は、管理コンソールの Keys タブで環境を切り替えて、1 か所で管理できます。自分で名前を付けた環境（この回では preview）も、Settings タブから足せます。
• 全環境で同じ値は、Common（_shared）に 1 つだけ置きます。 Common の値はどの環境の pull にも入るので、同じ値を 2 か所で直さなくて済みます。環境ごとに違う値が要る時は、その環境に同じ名前の key を置けば、環境側の値が勝ちます。
• 環境どうしの差分は Compare envs… で見比べ、足りない key はその場で写せます。 すでに環境に入っている key は、Promote to Common で、選んだ環境の値を Common の値にして 1 つにまとめられます。標準の 3 つの環境にあった同じ名前の key は消え、Common に 1 つだけ残ります。自分で足した環境の key は残ります。
• CLI では -E → DOTVAULT_ENV（無ければ APP_ENV）→ project-config.json の defaultEnv の順で環境が決まります。
• 使い終わった project は、管理コンソールで Archive してから Delete します。

本文（読了 約10分）

前提と注意

• 読者。 2 回目の「ローカルで直した値が CI に反映されていない ── どの環境でも dotvault pull 1 回で同じ .env をそろえる」で、demo-app に 3 つの key を入れて dotvault pull まで通した状態から続けます。2 回目を読んでいなくても、画面の流れは追えます。
• 版と環境。 画面は、本番の app.dotvault.io と CLI 0.15.7 で撮りました。端末は 2 回目と同じ Node 20 の Linux コンテナです。0.15.8 からは、.env に書かれる区切りの行が # BEGIN: dotvault (managed by dotvault) になります。この回の環境の指定（-E・DOTVAULT_ENV・defaultEnv）の動きは、0.15.8 でも同じだと確かめました。
• 端末の画面は再構成です。 実際の出力を文字どおりに写し、見やすい形に組み直しています。生の出力はそのまま保存しています。終了コードは、記録した値を echo $? の行の形で示しています。
• 画面は英語です。 管理コンソールの表示言語は、2 回目の付録の手順で日本語にできます。
• デモのアカウントです。 project 名、key の名前、値は、この連載のために作ったデモのものです。値は本物ではありません。
• 用語。 この記事では、API キーやパスワードのように外に出してはいけない値をまとめて「secret」と書きます。「環境」は、development・staging・production のように、同じ key に別の値を持たせる単位です。「key」は、.env の 1 行の 名前=値 の名前のほうです。

1. 環境ごとの .env を、1 つの project の中の環境としてまとめる

環境ごとに分かれていた .env は、dotvault では 1 つの project の中の環境になります。2 回目で作った demo-app には、development・staging・production の 3 つの環境があります。これは dotvault の標準の環境で、消すことはできません。Keys タブの上に環境の切り替えが並び、押した環境の key の一覧が出ます。環境ごとの値を、この 1 つの画面で見て、直せます。

この画面には、標準の 3 つに加えて、この回の途中で足す preview と、全環境で同じ値を置く Common (_shared) が写っています。順に作っていきます。

2. 環境どうしの差分を見比べて、足りない key を写す

環境を 1 つの project にまとめると、環境どうしを並べて見比べられます。2 回目の時点では、3 つの key は development にしか入っていません。staging や production にも同じ名前の key が要るかどうかは、見比べないと分かりません。Keys タブの「⇄ Compare envs…」を押すと、右側に 2 つの環境を選ぶ引き出しが出ます。

「Only in development」の下に、development にしか無い key が並びます。1 つずつ写すなら各行の Copy to、全部なら見出しの横の Copy all to です。この記事では、先に staging に Copy all to で 3 つを写しました。写した後に staging と development で見比べると、差分が無いことが 1 行で出ます。

この 2 枚は、次の節で API_BASE_URL を Common に移した後に撮りました。Common に移した key は見比べに出ないので、key は 2 つ（DATABASE_URL と SMTP_PASSWORD）と出ています。

写すのは key の名前と、その時点の値です。写した後に development 側の値を変えても、staging には伝わりません。環境ごとに別の値を持たせるための仕組みなので、これは意図した動きです。全環境で同じ値にしておきたい key は、写すのではなく、次の節の Common に置きます。

3. 全環境で同じ値の key は Common に 1 つだけ置く

この記事のデモでは、API_BASE_URL をどの環境でも同じ値の key として扱います。実際の project では、冒頭で挙げた外部サービスの公開キーや、メールの送信元のアドレスのような key を置く場所です。環境ごとに同じ値を書くと、変える時に全部の環境で変えることになります。そのための場所が Common（画面では Common (_shared)、CLI では _shared）です。Common に置いた key は、どの環境を pull しても一緒に書き出されます。値は Common の 1 つだけなので、変える時も 1 か所を直すだけです。

すでに環境に入っている key は、key を選んで右側の「⬆ Promote to Common (_shared)」を押すと Common に移せます。押すと確認の画面が出ます。

確認画面に書いてあるとおり、development の値が Common の値になります。標準の 3 つの環境（development・staging・production）にあった同じ名前の key は消えて、Common に 1 つだけ残ります。自分で足した環境の key は消えずに残り、Common より優先されます。実際に押した後の development と Common を見ると、こうなります。

development の一覧から API_BASE_URL が無くなったのは、そのためです。pull した .env には、Common の値として今までどおり入ります（5 節で確かめます）。

環境ごとに別の値が要る時は、その環境で同じ名前の key を足します。環境側の値が Common より優先されます。これも 5 節で、preview に別の値を置いて確かめます。

Common がまとめるのは、1 つの project の中で、環境に共通の値です。project をまたぐ共通の値は、6 回目の Global Keys で扱います。

4. 自分で名前を付けた環境を足す

標準の 3 つで足りない時は、同じ project の中に環境を足します。足した環境も、ほかの環境と同じ画面で並べて管理できます。Settings タブの Environments で足します。名前は小文字の英数字とハイフンで、先頭は英字、32 文字までです。足す時に「Copy keys from an existing env」で既存の環境を選ぶと、その環境の key がそのまま写ります。この記事では preview を、development から写して足しました。

足した環境には Rename と Delete が付きます。標準の 3 つと _shared には付きません。Rename を押すと、新しい名前を入れる画面が出ます。説明に「この環境名を参照する key と権限は、すべて新しい名前に書き換えられる」とあります。

key か権限が残っている環境は消せません。preview に key が入ったまま Delete を押して確認すると、「This environment still has keys or permissions. Remove those first.」と出て、消えません。消したい時は、先にその環境の key を全部消し、その環境に付けた権限も外します。

この後、preview に API_BASE_URL を別の値（https://preview.example.com/v1）で足しました。Common の値と環境の値のどちらが勝つかを、次の節で見るためです。

5. CLI で環境を指定する

管理コンソールの 1 か所にまとめた値を、端末では環境の名前を指定して取り出します。dotvault list demo-app で、環境ごとの key の数が出ます。自分で足した preview も表に出ます。

production に key を入れた覚えが無いのに 1 と出ています。これが Common の数え方です。Common に置いた API_BASE_URL が、どの環境にも入って数えられています。

環境を指定して pull するには -E（--env）を付けます。指定せず、後で書く環境変数も無い時は、project-config.json の defaultEnv（2 回目の init で development）が使われます。

dotvault pull
dotvault pull -E preview
dotvault pull -E production

見てほしいのは 3 点です。

1. development の pull に API_BASE_URL が入っています。 development の一覧からは消えましたが、Common の値として入っています。Common の 1 つの値が、どの環境の .env にも入るということです。
2. preview の pull では API_BASE_URL が preview の値です。 環境に同じ名前の key があれば、環境側が Common に勝ちます。
3. 書き出した .env には、どの環境から取ったかは書かれません。 結果の行には毎回 env=… が出ます。作業を始める前に、使う環境で pull し直すのが確実です。

環境は環境変数 DOTVAULT_ENV でも指定できます。CI や npm script のように、コマンドを変えずに環境だけ切り替えたい時に使います。-E と両方ある時は -E が勝ちます。DOTVAULT_ENV が無い時は、環境変数 APP_ENV も環境の指定として読みます。アプリが自分の設定に APP_ENV を使っていると、-E も DOTVAULT_ENV も無い時に、defaultEnv ではなくその値の環境が pull されます。dotvault の環境は DOTVAULT_ENV で指定するのが確実です。

優先順をまとめると、-E → DOTVAULT_ENV（無ければ APP_ENV）→ project-config.json の defaultEnv です。defaultEnv が使われるのは、-E も 2 つの環境変数も無い時だけです。同じ画面の最後に、dotvault init をもう一度打った時の出力も載せました。project-config.json があるフォルダでは上書きせずに止まり、作り直したい時だけ --force を付けます。

指定	書き方	向いている場面
コマンドの引数	dotvault pull -E staging	手元で一時的に別の環境を見る
環境変数	DOTVAULT_ENV=staging dotvault pull	CI や起動スクリプトで、コマンドを変えずに切り替える
設定ファイル	project-config.json の defaultEnv	そのフォルダの普段の環境。init の既定は development

defaultEnv に書けるのは、development・staging・production のどれかです。preview のように自分で足した環境は、毎回 -E（か DOTVAULT_ENV）で指定します。

6. 使い終わった project を片付ける

環境と値をまとめた project は、使い終わったら project ごと片付けます。Settings タブのいちばん下に Danger zone があります。Archive this project を押すと確認が出て、承認すると project は管理画面の一覧から消えます。Archive は元に戻せます。Delete は、Archive した後にだけできます。

一覧の絞り込みを「Archived only」にすると、Archive した project が出て、Unarchive と Delete… のボタンが付きます。

Delete… を押すと、project の名前を打ち込む画面が出ます。名前が一致するまで Delete permanently のボタンは押せません。消えるのは、今の値だけでなく、4 回目で扱う値の履歴も含めた全部です。

この画面は、demo-app を消さないために、別に作った scratch-app で撮りました。Delete permanently を押すと、「All (incl. archived)」で見ても一覧から無くなります。demo-app は Unarchive して、4 回目でも使います。

project の archive と delete は、管理コンソールで行います。CLI の dotvault project にあるのは create と list です。

まとめ

環境ごとに別々に持っていた .env は、dotvault では 1 つの project の中の環境としてまとまり、管理コンソールの 1 か所で管理できます。全環境で同じ値は Common に 1 つだけ置けば、どの環境の pull にも入るので、同じ値を 2 か所で直さなくて済みます。

次回

4 回目は「値を間違えて上書きしてしまった ── key を書く・取り出す・版を戻す」です。key を画面と CLI の両方から書き、値を取り出し、版の一覧から前の版に戻すところまでを、画面と一緒に進めます。

---

dotvault は、.env や設定ファイルの secret をサーバー側に置き、権限のある人・CI・AI エージェントが 1 コマンドで受け取るサービスです（https://dotvault.io）。この連載が終わる時に、dotvault を誰でも無料で使える形で公開する予定です。公開したら、この連載の手順どおりに使い始められます。

興味のある方は、ぜひ「いいね」と記事の購読をお願いいたします。

自社プロダクトは https://www.eln.ne.jp/products にまとめています。

筆者について

上原正吉。EarthLink Network Co., Ltd. 代表。AI社員に日々の業務を任せ、開発では人が逐一指示しなくても作業が進むHOOTL（Human Out Of The Loop）の仕組みを自社で実践しています。このブログでは、業務自動化と24時間自動開発のノウハウ、具体的な設定方法、日々の運用で見つかった問題と改善を共有します。

また、AIで業務や開発を組み替えたい会社・チーム向けに、AI活用のコンサルティングも受け付けています。ご相談は www.eln.ne.jp からどうぞ。

---

EarthLink Network は、会社の全業務を AI で回すために、必要になったものを自社で作っています。いま作っているプロダクトの一覧と概要は、こちらにまとめています。

→ EarthLink Network が自社でつくっている18のプロダクト

会社と各プロダクトの詳細は、公式サイト www.eln.ne.jp をご覧ください。