「.env」の平文放置を卒業する。1Password CLI、dotenvx、Infisicalで選ぶ安全なシークレット管理の現実解

「.env」の平文放置を卒業する。1Password CLI、dotenvx、Infisicalで選ぶ安全なシークレット管理の現実解

2026/10/11
目次
開閉

Web開発やバックエンド開発を進める中で、APIキー、データベースの接続URL、外部サービスのシークレットトークンなどを扱う機会は日常茶飯事です。

多くのプロジェクトでは、プロジェクトルートに .env や .env.local といったファイルを作成し、そこにキーを書き込んで dotenv 経由で読み込んでいるのではないでしょうか。

# よくある .env の中身(平文)
DATABASE_URL="postgres://user:super_secret_password@localhost:5432/mydb"
STRIPE_SECRET_KEY="sk_test_51Mz..."
OPENAI_API_KEY="sk-proj-abc123xyz..."

もちろん .gitignore に登録しているため、リポジトリに誤ってプッシュされるリスクはある程度防げているかもしれません。しかし、実務を長く続けていると、以下のような摩擦やヒヤリハットに一度は直面したことがあるはずです。

  • ブランチ切り替えや誤操作の際、Gitのステージングに .env が紛れ込んで冷や汗をかいた
  • チームの新メンバーが参加した際、Slackのダイレクトメッセージや暗号化ZIPでシークレットをやり取りする泥臭い運用が残っている
  • 会社のPC(MacBook Pro)と自宅のPC(Windowsノート)を行き来する際、鍵の同期や更新漏れで環境が動かなくなる
  • そもそも、ディスク上に生パスワードがプレーンテキストのまま放置されていること自体が落ち着かない

こうした「平文 .env ファイルへの依存」から脱却するための現実解として、現在エンジニアの間で有力視されている選択肢は、大きく分けて 3つのアプローチ(代表4ツール) に整理できます。

  1. ポインタ型(オンメモリ注入): ディスクに機密を1文字も残さず、生体認証でメモリにのみ流し込む 「1Password CLI」
  2. ファイル内暗号化型(Gitコミット可能): 従来の .env ワークフローのまま、値だけを公開鍵暗号で暗号化する 「dotenvx」
  3. 開発専用シークレット管理(SecretOps)プラットフォーム: クラウド環境とローカルをシームレスに同期する 「Doppler」 vs 「Infisical」

今回は、これら4つのツールの仕組みと特徴をファクトベースで比較し、現場の状況に応じた使い分けの現実解をまとめます。

セキュリティ設計を考えるエンジニア

アプローチ1:1Password CLI(op run)— ディスク上に機密を一切残さない

1つ目は、パスワードマネージャーの業界標準である1Passwordの公式CLIツール、1Password CLI(v2系)を活用する方法です。

基本思想:ファイルには「参照ポインタ(URI)」だけを書く

1Password CLIの最大の特徴は、「実値(シークレットそのもの)をディスクに書き出さない」 という点にあります。

.env の代わりに、「1Password内のどこに秘密情報があるか」を指し示す シークレット参照URI(Secret Reference) を記述したテンプレートファイル(.env.template)を用意します。

# .env.template (このファイルは Git にコミットしても完全に安全)
PORT=3000
DATABASE_URL="op://Development/Local-Postgres/connection_string"
STRIPE_SECRET_KEY="op://Development/Stripe-Test/credential"
OPENAI_API_KEY="op://Development/OpenAI/credential"

この op:// から始まる文字列は単なるポインタに過ぎないため、万が一誰かに見られても秘密そのものは漏洩しません。

そして、開発サーバーやバッチ処理を起動する際に op run を前置します。

op run --env-file=.env.template -- npm run dev

このコマンドを叩くと、OSの生体認証(MacならTouch ID、WindowsならWindows Hello)が呼び出され、認証が成功した瞬間に 起動したプロセスのメモリ空間にのみ実環境変数が展開 されます。

プロセスが終了すればメモリは解放され、ディスクのどこを探しても平文シークレットの痕跡は残りません。

前提条件とセットアップ

各OSのパッケージマネージャーからインストールできます。

macOS (Homebrew):

brew install 1password-cli

Windows (winget):

winget install AgileBits.1Password.CLI

インストール後、1Password デスクトップアプリ(v8以降)の 「設定」→「開発者」 から 「1Password CLI と連携」 にチェックを入れます。

Lowom 編集長 編集長
POINT MacでもWindowsでも指紋認証で完結
MacのTouch IDはもちろん、WindowsノートPCの指紋リーダーや顔認証(Windows Hello)でもまったく同様に認証ダイアログが立ち上がります。両OSを行き来する開発環境でも違和感なく操作感を一本化できます。

シークレット参照URIの取得も簡単で、1Passwordアプリの各アイテム詳細画面でフィールドの横にあるメニューから「シークレット参照をコピー」を選ぶだけです。構文仕様の詳細は 公式のSecret Referencesドキュメント を参照してください。


アプローチ2:dotenvx — 従来のワークフローのまま「値だけ暗号化」してGit管理

2つ目は、Node.jsで最も広く使われている dotenv の生みの親(Motdotla氏)が開発した次世代ツール、dotenvx です。

1Password CLIが「外部サービスに秘密を預けて参照する」のに対し、dotenvxは 「暗号化した秘密をリポジトリ内に同梱する」 というまったく異なる思想を持っています。

基本思想:キー名は見せ、値だけを暗号化する

従来の暗号化ツール(暗号化ZIPやGPGなど)はファイル全体を暗号化するため、差分(diff)が見えなくなったりコンフリクト解消が困難になるという問題がありました。

dotenvxは、.env ファイル内の 「値(Value)」の部分だけを公開鍵暗号(ECC)で暗号化 します。

# dotenvxで暗号化された .env の中身(Gitにコミット可能)
PORT=3000
DATABASE_URL="encrypted:BAQCAIdJ...=="
STRIPE_SECRET_KEY="encrypted:BAQCAKf8...=="
OPENAI_API_KEY="encrypted:BAQCAMx1...=="

キー名(PORT, DATABASE_URL など)は平文のまま読めるため、「どんな環境変数が必要なのか」が一目で把握でき、PRレビューでも差分が明瞭です。

セットアップと実践手順

dotenvxはnpm経由またはOSスタンドアロンバイナリとして手軽に導入できます。

# npm経由で導入する場合
npm install @dotenvx/dotenvx --save-dev

# またはスタンドアロンCLIとして導入
brew install dotenvx/brew/dotenvx

1. シークレットを暗号化して登録する

以下のコマンドで値を設定すると、.env 内の値が自動的に暗号化されます。

npx dotenvx set STRIPE_SECRET_KEY "sk_test_51Mz..."

このとき、初回実行時にプロジェクトルートへ .env.keys という復号鍵ファイルが自動生成されます。

# .env.keys (※このファイルは絶対に .gitignore に追加する)
DOTENV_PRIVATE_KEY_DEVELOPMENT="xxxxxxxxxxxxxxxxxxxx"

2. コマンドを実行する

実行時は dotenvx run を前置するだけです。

npx dotenvx run -- npm run dev

ローカル環境に .env.keys(または環境変数 DOTENV_PRIVATE_KEY)が存在すれば、自動的に暗号化された値をメモリ上で復号してプロセスへ渡してくれます。

コード側の変更は一切不要で、あらゆる言語(Python, Go, Rust等)でそのまま動作します。

Lowom 編集長 編集長
CAUTION 復号キー(.env.keys)の取り扱いに注意
暗号化された .env はGitにコミットして問題ありませんが、秘密鍵である .env.keys は絶対にリポジトリへコミットしてはいけません。必ず .gitignore に含まれていることを確認しましょう。

アプローチ3:チーム向けSecretOpsプラットフォーム(Doppler vs Infisical)

個人や少人数を超えて、複数チームで「開発(dev)」「ステージング(stg)」「本番(prd)」といった環境ごとの環境変数を厳密に一元管理したい場合に選ばれるのが、SecretOps(シークレット運用管理)専門のプラットフォームです。

この領域で代表的な2つの選択肢が、Doppler と Infisical です。

どちらもコマンドラインから doppler run -- ... や infisical run -- ... と実行することで、クラウドから最新の環境変数を取得してメモリ上にのみ注入する仕組みを備えています。

しかし、設計思想とアーキテクチャには決定的な違い があります。

Doppler:洗練されたフルマネージドSaaS(クローズドソース)

Dopplerは、業界で先行して普及した開発者向けシークレット管理サービスです。

  • 特徴: UIが洗練されており、GitHubやVercel、AWS等との自動同期連携が充実しています。インフラの管理が一切不要な「ゼロ運用」で即座に使い始められるのが最大の強みです。
  • 留意点: コアプラットフォームが 完全なプロプライエタリ(クローズドソースSaaS) です。セルフホスト(オンプレミス構築)は提供されておらず、すべての機密情報を外部のDoppler社クラウドに預ける必要があります。

Infisical:オープンソース(OSS)でセルフホスト可能な新世代基盤

これに対し、後発ながら急速に支持を広げているのが、Y Combinator出身のオープンソースプロジェクトである Infisical(GitHubリポジトリ) です。

Dopplerと同様の洗練されたUIやCLI(infisical run -- <command>)、環境別の変数管理機能を提供しながら、以下の決定的な強みを持っています。

  1. 完全なオープンソース & セルフホスト対応: DockerやKubernetes(Helmチャート)を使って、自社のAWSやGCP、オンプレミス環境内に丸ごとホストできます。
  2. データ主権と厳しいコンプライアンスへの適合: 「会社のセキュリティ規程上、外部のSaaSにデータベース接続文字列や本番シークレットを預けられない」というエンタープライズや受託・金融系の現場でも問題なく導入できます。
  3. エンドツーエンド暗号化(E2EE): ゼロナレッジアーキテクチャを採用しており、サーバー側にも平文シークレットが渡らない堅牢な暗号化設計が施されています。
  4. クラウド版(マネージドSaaS)も選択可能: 自前でインフラを管理したくない場合は、Doppler同様の公式マネージドSaaSプランを利用することも可能です。
Lowom 編集長 編集長
TIPS チーム導入ならInfisicalが優位な理由
Dopplerは個人やスタートアップが手軽に使うには快適ですが、チームや企業での長期運用を考えると、ベンダーロックインがなく、将来的に自社インフラへセルフホストできる選択肢を残せる「Infisical」のほうが圧倒的に自由度と信頼性が高いです。

4大ツールの徹底比較マトリクス

それぞれのツールの特徴を一覧で整理しました。

比較項目1Password CLIdotenvxDopplerInfisical(推奨)
カテゴリパスワードマネージャー統合ファイル内暗号化開発専用SaaS (SecretOps)オープンソースSecretOps
ソースコードプロプライエタリオープンソースコアはクローズドオープンソース (OSS)
ホスティング1Password クラウドローカル完結 (SaaS不要)SaaS専用セルフホスト可 / SaaS両対応
実行コマンドop run -- ...dotenvx run -- ...doppler run -- ...infisical run -- ...
注入方式メモリ上へのみ注入メモリ上へのみ注入メモリ上へのみ注入メモリ上へのみ注入
ディスクの状態ポインタURIのみ暗号化された値設定ファイルのみ(値なし)設定ファイルのみ(値なし)
主な認証手段生体認証 (Touch ID / Win Hello)復号秘密鍵 (.env.keys)Doppler トークン / ログインInfisical トークン / ログイン
無料枠・コスト1Password契約が必要完全無料無料枠あり(チームは有料)セルフホスト無料 / クラウド版あり
最適な規模個人〜既存1Password利用チーム個人〜小規模チーム・OSS中小スタートアップ小規模〜大企業・エンタープライズ

ローカルファーストなAPIテストとの相乗効果

ローカル環境でのシークレット管理が整うと、Webアプリの開発だけでなく、APIクライアントを使った検証作業の安全性 も一段引き上がります。

例えば、以前ご紹介したGitネイティブのAPIクライアント「Bruno」では、リクエスト定義をプレーンテキストでリポジトリ管理できます。

Brunoの環境変数定義に対しても、1Password CLIの参照ポインタを使うか、あるいはdotenvxやInfisicalで事前注入した環境変数を参照させることで、テスト用のBearerトークンや本番直結キーを一切コミットすることなく、安全にAPIリクエストを回すワークフローが完成します。

ローカル完結でリポジトリを安全に保つ考え方は非常に通じる部分がありますので、APIテストの運用に悩んでいる方はぜひあわせてご覧ください。


まとめ:自分のチームの「制約と規模」に合わせて選ぶ

セキュリティ対策の難しさは、「ルールを厳格にして手順を増やすと、現場で形骸化しやすい」という点にあります。どれだけ「平文 .env は禁止」と呼びかけても、毎回WebコンソールからAPIキーを探してコピペする運用では、誰かが手元にメモ帳を作ってしまうのが人間の心理です。

今回紹介したツールは、いずれも「平文ファイルをディスクに置かない」というゴールを達成しつつ、それぞれ異なる強みを持っています。

  • 1Password CLI: 既に個人や会社で1Passwordを契約しており、追加ツールなし・指紋認証で最も手軽に済ませたい 場合
  • dotenvx: 外部サービスのアカウントを増やさず、手元のGitリポジトリ内で完結させたい 個人開発やOSS
  • Infisical: チームで環境別(dev/stg/prd)のシークレットを一元管理したいが、外部SaaSへの依存を避け、オープンソースや自社インフラで安全に運用したい 場合

まずは現在進行中のプロジェクトで、平文のまま転がっている .env を見直し、チームの要件に合った現実的なアプローチを試してみてはいかがでしょうか。誤コミットの恐怖から解放される安心感は、想像以上に日々の開発の集中力を高めてくれるはずです。

Lowom 編集長
この記事を書いた人:Lowom 編集長 現役Webエンジニア

都内IT企業に勤める業界20年のWebエンジニア。業務効率化・自動化スクリプトや快適な開発環境の構築、厳選したツール・ガジェットの活用法など、手元で実際に検証したリアルな一次情報をお届けします。

運営者プロフィール詳細を見る