Dopplerで環境変数を安全に一元管理する方法 - .envファイルの課題と移行手順

チーム開発で .env ファイルを Slack で共有したり、本番用の環境変数を手作業でサーバーへコピーしたりした経験はないでしょうか。環境変数の管理が属人化すると、設定ミスや機密情報の漏洩といった事故に直結します。

Doppler は、環境変数とシークレットをクラウド上で一元管理できるプラットフォームです。プロジェクト・環境ごとの変数管理、CLI 経由の安全な注入、変更履歴の追跡などを一つのダッシュボードで提供しています。

.env ファイルによる環境変数管理の落とし穴

多くの開発プロジェクトでは .env ファイルを使って環境変数を管理しています。しかし、プロジェクト規模やチーム人数が大きくなるにつれ、いくつかの深刻な問題が表面化します。

バージョン管理から除外される

.env ファイルは .gitignore に記載するのが定石です。結果として Git の管理対象外となり、環境変数の変更履歴を追跡する手段がありません。誰がいつ何を変更したかを後から確認できず、障害時の原因特定が困難になります。

チーム間の同期が難しい

新しいメンバーがプロジェクトに参加するたびに「.env を送ってほしい」というやり取りが発生します。Slack や DM で機密情報を送受信することになり、セキュリティ上のリスクが生まれます。.env.example を用意しても、実際の値は別途共有が必要です。

環境ごとの管理が煩雑

開発・ステージング・本番で異なる値が必要な場合、.env.development、.env.staging、.env.production のように複数ファイルを管理しなければなりません。フレームワークによって読み込みの優先順位や命名規則が異なるため、設定ミスの温床になります。

誤操作による上書き・削除リスク

echo "VALUE" > .env のようなコマンドで既存の .env を丸ごと上書きしてしまう事故は珍しくありません。ローカルにしか存在しないファイルのため、バックアップもなく復旧が困難です。

Doppler の概要と主な機能

Doppler は 2018 年に Brian Vallelunga によって創業されたシークレット管理プラットフォームです。Y Combinator、Sequoia Capital、CRV などから資金調達を行い、月間 3,000 万回以上のシークレット読み込みを処理しています（出典: Doppler）。

プロジェクトと環境の階層管理

Doppler ではプロジェクト単位でシークレットを管理し、各プロジェクトの中に Development（dev）、Staging（stg）、Production（prd）などの環境を作成できます。環境ごとに独立した変数セットを持つため、「開発環境のデータベース URL を誤って本番に適用した」といった事故を構造的に防げます。

my-project/
├── dev          # 開発環境
│   ├── dev_personal  # 個人用ブランチ
│   └── dev_ci        # CI用ブランチ
├── stg          # ステージング環境
└── prd          # 本番環境

シークレット参照（Secret Referencing）

ある変数の値を別の変数から参照できる仕組みです。たとえば、データベースの接続文字列を構成する DB_HOST、DB_PORT、DB_NAME を個別に管理しつつ、DATABASE_URL で ${DB_HOST}:${DB_PORT}/${DB_NAME} のように組み合わせることが可能です。値の変更が一箇所で済むため、整合性を保ちやすくなります。

変更履歴とロールバック

すべての変更がタイムスタンプ・変更者・差分つきで記録されます。問題が発生した場合、任意のバージョンにワンクリックでロールバックできます。Team プラン以上では 90 日間のアクティビティログが保存されます。

自動シークレットローテーション

Team プラン以上で利用できる機能です。データベースパスワードや API キーを定期的に自動更新し、長期間同じ認証情報を使い続けるリスクを軽減します。

RBAC（ロールベースアクセス制御）

メンバーごとにプロジェクト・環境レベルのアクセス権限を設定できます。「開発者は dev 環境のみ閲覧・編集可能、prd 環境は管理者のみ」といった制御が可能です。Enterprise プランではカスタムロールも作成できます。

Doppler CLI のセットアップ手順

インストール

macOS（Homebrew）

brew install gnupg
brew install dopplerhq/cli/doppler

Linux（Debian / Ubuntu）

sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl gnupg

curl -sLf --retry 3 --tlsv1.2 --proto "=https" \
  'https://packages.doppler.com/public/cli/gpg.DE2A7741A397C129.key' \
  | sudo gpg --dearmor -o /usr/share/keyrings/doppler-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/doppler-archive-keyring.gpg] \
  https://packages.doppler.com/public/cli/deb/debian any-version main" \
  | sudo tee /etc/apt/sources.list.d/doppler-cli.list

sudo apt-get update && sudo apt-get install doppler

Windows（winget）

winget install doppler.doppler

インストール後、バージョンが表示されれば成功です。

doppler --version

認証とプロジェクト設定

# ブラウザが開き、Dopplerアカウントでログイン
doppler login

# プロジェクトと環境を選択（対話式）
doppler setup

doppler setup を実行すると、カレントディレクトリに .doppler.yaml が作成され、プロジェクトと環境の紐付けが保存されます。

シークレットの取得と注入

# 全シークレットを一覧表示
doppler secrets

# 特定のシークレットの値を取得
doppler secrets get DATABASE_URL

# アプリケーション起動時にシークレットを環境変数として注入
doppler run -- node server.js
doppler run -- python manage.py runserver
doppler run -- cargo run

doppler run は子プロセスに対して環境変数を注入するコマンドです。アプリケーション側は process.env.DATABASE_URL のように通常の環境変数アクセスで値を取得できるため、コードの変更は不要です。

Docker コンテナとの連携

米国の開発現場では Docker コンテナへの環境変数注入に Doppler を活用するパターンが広まっています。.env ファイルをコンテナイメージに含める必要がなくなるため、イメージのセキュリティが向上します。

docker run での使用

# Dopplerのサービストークンを使ってシークレットを注入
doppler run -- docker run -e DATABASE_URL -e API_KEY my-app

docker-compose での使用

# docker-compose.yml
services:
  app:
    build: .
    env_file:
      - .env  # ← 従来の方法

Doppler CLI を使う場合は env_file の代わりに、Doppler からエクスポートした値を利用できます。

# .envフォーマットでエクスポート
doppler secrets download --no-file --format env > .env.doppler

# または doppler run 経由で docker-compose を実行
doppler run -- docker-compose up

Kubernetes との連携

Doppler は Kubernetes 向けに Secrets Operator を提供しています。Kubernetes の Secret リソースを自動的に Doppler と同期し、Pod が常に最新のシークレットを使用できるようにします。

# Doppler Kubernetes Operatorのインストール（Helm）
helm repo add doppler https://helm.doppler.com
helm install doppler-operator doppler/doppler-operator

CI/CD パイプラインとの連携

GitHub Actions

Doppler のサービストークンを GitHub の Repository Secret に登録し、ワークフロー内で doppler run を使います。

# .github/workflows/deploy.yml
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Doppler CLI
        uses: dopplerhq/cli-action@v3
      - name: Run tests with secrets
        run: doppler run -- npm test
        env:
          DOPPLER_TOKEN: ${{ secrets.DOPPLER_TOKEN }}

その他の CI/CD サービス

Doppler は GitLab Pipeline、CircleCI、Jenkins、Terraform Cloud など主要な CI/CD サービスとのインテグレーションを公式に提供しています。いずれもサービストークンを設定するだけで利用を開始できます（出典: Doppler Integrations）。

クラウドサービスへのシークレット同期

Doppler の「Config Syncs」機能を使うと、Doppler 上のシークレットを外部サービスへ自動的に同期できます。対応サービスの一例は以下のとおりです。

カテゴリ	対応サービス
クラウド	AWS Secrets Manager / Parameter Store、GCP Secret Manager、Azure Key Vault
ホスティング	Vercel、Heroku、Netlify、Railway、Render、Fly.io
コンテナ	Kubernetes（Secrets Operator）、Docker
CI/CD	GitHub Actions、GitLab、CircleCI、Jenkins
監視・ログ	Datadog、Splunk、Sumo Logic

同期設定はダッシュボードから数クリックで完了します。Doppler 側で値を更新すると、連携先にも自動反映されるため、手動でのコピー作業が不要になります。

.env ファイルとの共存

既存プロジェクトを Doppler に完全移行する前の段階では、.env ファイルとの共存も可能です。

# Dopplerのシークレットを .env フォーマットでダウンロード
doppler secrets download --no-file --format env > .env

# 逆に .env ファイルの内容を Doppler にインポート
doppler secrets upload .env

既存の .env を doppler secrets upload で一括インポートした後、doppler run に切り替えていく段階的な移行が現実的です。

他のシークレット管理ツールとの比較

Doppler 以外にも環境変数・シークレットを管理するツールは複数あります。プロジェクトの規模やインフラ構成によって最適な選択肢は異なります。

観点	Doppler	HashiCorp Vault	AWS Secrets Manager	Infisical
提供形態	SaaS（クラウド）	セルフホスト / HCP Vault（SaaS）	AWS マネージド	SaaS / セルフホスト
無料枠	3 ユーザーまで無料	OSS 版は無料	従量課金（無料枠なし）	5 ユーザーまで無料
セットアップ難度	低（CLI インストール + login）	高（サーバー構築・Unseal 手順）	中（AWS 環境が前提）	低（Doppler と同程度）
開発者体験	CLI・ダッシュボード中心	API・CLI 中心	AWS CLI / SDK	CLI・ダッシュボード中心
マルチクラウド	対応（AWS / GCP / Azure 同期）	対応	AWS 中心	対応
動的シークレット	Enterprise のみ	対応（主要機能）	ローテーションで代替	未対応
向いている規模	スタートアップ〜大企業	大規模・高セキュリティ要件	AWS 中心の組織	スタートアップ〜中規模

HashiCorp Vault はオンプレミス環境や高度なセキュリティ要件がある組織に適しています。動的シークレット（一時的な認証情報を自動生成）に強みがある一方、初期構築とメンテナンスの工数が大きい点が課題です。

AWS Secrets Manager は AWS を中心としたインフラで完結する場合に有力な選択肢です。Lambda や ECS などの AWS サービスとのネイティブ連携が強みですが、マルチクラウド環境では管理が分散しがちです。

Infisical は Doppler と同様に開発者体験を重視した SaaS 型のシークレット管理ツールです。オープンソース版（セルフホスト可能）がある点が Doppler との大きな違いです。

料金プラン

Doppler の料金プランは 3 種類です（2026 年 3 月時点、出典: Doppler Pricing）。

プラン	料金	主な特徴
Developer	最初の 3 ユーザー無料、追加は $8/月/人	プロジェクト 10 個、環境 4 個、サービストークン 50 個、3 日間ログ
Team	$21/月/人	プロジェクト 250 個、環境 15 個、SAML SSO、RBAC、自動ローテーション、90 日間ログ
Enterprise	カスタム	カスタム権限、動的シークレット、ログフォワーディング、99.95% SLO

個人開発や小規模チーム（3 人以下）であれば Developer プランの無料枠で十分にカバーできます。チーム規模が拡大し、アクセス制御や監査ログが必要になったタイミングで Team プランへ移行するのが一般的です。

モノレポ構成での活用

複数サービスをひとつのリポジトリで管理するモノレポ構成では、サービスごとに異なる環境変数が必要です。Doppler ではプロジェクトをサービス単位で分割し、ディレクトリ単位で doppler setup を実行することで対応できます。

monorepo/
├── frontend/        # doppler setup → project: frontend
│   └── .doppler.yaml
├── backend/         # doppler setup → project: backend
│   └── .doppler.yaml
└── worker/          # doppler setup → project: worker
    └── .doppler.yaml

各サービスのディレクトリで doppler run を実行すれば、そのサービスに紐づくシークレットのみが注入されます。

導入時の注意点とベストプラクティス

シークレットの命名規則を統一する

プロジェクト間で命名規則がバラバラだと、どの変数がどの用途かが分かりにくくなります。SERVICE_PROVIDER_PURPOSE（例: AWS_S3_BUCKET_NAME、STRIPE_API_SECRET_KEY）のような規則を定めておくと管理しやすくなります。

サービストークンの権限を最小限にする

CI/CD やデプロイ用のサービストークンは、必要な環境・操作のみに限定して発行するのが原則です。本番環境への書き込み権限を持つトークンが CI 環境に残っている状態は、事故の原因になります。

ローカル開発では個人ブランチ環境を活用する

Doppler の各環境にはブランチ（派生環境）を作成できます。開発メンバーが個人用のブランチ環境を持つことで、他のメンバーの開発環境に影響を与えずに変数を変更できます。

既存プロジェクトへの段階的導入

一度にすべてを移行する必要はありません。まずは新規プロジェクトから Doppler を適用し、既存プロジェクトは .env との共存モードで段階的に移行する方法が現実的です。

まとめ

.env ファイルによる環境変数管理は、個人開発の段階では手軽ですが、チーム開発や複数環境の運用では限界があります。Doppler を導入すると、環境変数の一元管理、アクセス制御、変更履歴の追跡、CI/CD やクラウドサービスとの自動同期が実現します。

Developer プランなら 3 ユーザーまで無料で利用できるため、まずは小さなプロジェクトで試してみるのが効果的です。CLI インストールから初回の doppler run までは 10 分程度で完了します。

Doppler 公式サイト: https://www.doppler.com/

.env ファイルによる環境変数管理の落とし穴#

バージョン管理から除外される#

チーム間の同期が難しい#

環境ごとの管理が煩雑#

誤操作による上書き・削除リスク#

Doppler の概要と主な機能#

プロジェクトと環境の階層管理#

シークレット参照（Secret Referencing）#

変更履歴とロールバック#

自動シークレットローテーション#

RBAC（ロールベースアクセス制御）#

Doppler CLI のセットアップ手順#

インストール#

認証とプロジェクト設定#

シークレットの取得と注入#

Docker コンテナとの連携#

docker run での使用#

docker-compose での使用#

Kubernetes との連携#

CI/CD パイプラインとの連携#

GitHub Actions#

その他の CI/CD サービス#

クラウドサービスへのシークレット同期#

.env ファイルとの共存#

他のシークレット管理ツールとの比較#

料金プラン#

モノレポ構成での活用#

導入時の注意点とベストプラクティス#

シークレットの命名規則を統一する#

サービストークンの権限を最小限にする#

ローカル開発では個人ブランチ環境を活用する#

既存プロジェクトへの段階的導入#

まとめ#