dotenvx・lkr・aws-vault・1Password CLI — .env 代替ツール4種の選び方とベストプラクティス

AI エージェントが .env ファイルを読み取るリスクが現実のものとなり、平文の .env を代替するツールが続々と登場しています。本シリーズでは aws-vault、lkr、dotenvx + 1Password CLI をそれぞれ解説してきました。

しかし「結局どれを使えばいいのか」という疑問が残ります。本記事では、4つのツールの守備範囲・強み・限界を比較し、チーム構成や開発環境に応じた選択指針を提示します。

4ツールの守備範囲

最も重要な違いは管理対象の範囲です。

aws-vault と lkr は特定領域に特化したツールです。.env に含まれる全てのシークレットをカバーするには、dotenvx か 1Password CLI が必要になります。

各ツールの強みと弱み

aws-vault

1

$ aws-vault exec dev -- python manage.py runserver

最大の強みは STS による一時認証です。他のどのツールも「漏洩しても自動で失効する」認証情報は提供できません。aws-vault が発行する一時認証情報は、仮に AI エージェントに読まれても最短15分で失効します。

lkr

1

$ lkr exec -k openai:prod -- python ai_app.py

最大の強みは AI エージェント対策に特化した設計です。TTY ガードが lkr get --plain のパイプ経由実行をブロックし、runtime / admin の分離が不要なキーの注入を防ぎます。LLM API キーは AI エージェントに読まれた場合のリスクが特に高い（エージェント自身が使える）ため、この特化は合理的です。

dotenvx

1

$ dotenvx run -- python manage.py runserver

最大の強みは .env ワークフローとの互換性です。既存の .env をそのまま暗号化し、dotenvx run に置き換えるだけで移行できます。チームでは暗号化された .env を Git で共有し、秘密鍵は別チャネルで配布します。

1Password CLI

1

$ op run --env-file=.env -- python manage.py runserver

最大の強みはチーム共有とクラウド保管の両立です。Vault の共有機能で、チームメンバーが個別にセットアップする手間を省けます。1Password が既にチームで導入されていれば、追加コストなしで使えます。

4ツールの技術的比較

保存場所とセキュリティモデル

AI エージェント対策

最後の行が重要です。どのツールも、復号されたシークレットが環境変数に載った後の読み取りは防げません。これは全ツールに共通する根本的な限界です。

チーム運用

選択パターン

パターン A: 1ツールでシンプルに済ませる

推奨: dotenvx または 1Password CLI

1
2
3
4
5
6

# dotenvx の場合
$ dotenvx encrypt               # .env を暗号化
$ dotenvx run -- python app.py  # 復号して実行

# 1Password CLI の場合
$ op run --env-file=.env -- python app.py

メリット: 学習コスト・運用コストが最小。1つのツールで全シークレットをカバー。

デメリット: aws-vault の STS 一時認証や lkr の TTY ガードのような専門的な防御機能がない。

向いているチーム: 小規模チーム、.env からの移行を素早く済ませたい場合。

パターン B: 専門ツールを組み合わせる

推奨: aws-vault + lkr + dotenvx (or 1Password CLI)

1
2
3
4

# AWS 認証情報 → aws-vault
# LLM API キー → lkr
# DB・SaaS 等  → dotenvx or 1Password CLI
$ aws-vault exec dev -- lkr exec -- dotenvx run -- python manage.py runserver

メリット: 各ツールの専門的な防御機能を全て活用できる。セキュリティが最高。

デメリット: 3つのツールのインストール・設定・運用が必要。コマンドが長くなる。

向いているチーム: セキュリティ要件が厳しい環境、AWS と LLM の両方を多用するチーム。

パターン C: aws-vault + 1Password CLI（現実的なバランス）

推奨: AWS だけ専門ツール、残りは 1Password に集約

1
2
3

# AWS 認証情報 → aws-vault（STS 一時認証が他で代替不可）
# それ以外全て → 1Password CLI
$ aws-vault exec dev -- op run --env-file=.env -- python manage.py runserver

メリット: STS 一時認証の防御を維持しつつ、運用をシンプルに保てる。

デメリット: 1Password の有料プランが必要。

向いているチーム: 1Password を既に導入しているチーム、AWS を本番環境で使っているチーム。

パターン D: dotenvx + aws-vault（無料で堅実）

推奨: 有料ツールを避けつつ、AWS の防御を確保

1
2
3

# AWS 認証情報 → aws-vault
# それ以外    → dotenvx
$ aws-vault exec dev -- dotenvx run -- python manage.py runserver

メリット: 全て無料。dotenvx は Git で共有可能。aws-vault で AWS の STS 一時認証を確保。

デメリット: dotenvx の秘密鍵管理が必要。macOS 限定（aws-vault）。

向いているチーム: コストを抑えたいチーム、macOS 統一の開発環境。

ツール選定より重要なこと

正直なところ、どのツールを選ぶかより「.env に平文を置かない」ことの方がはるかに重要です。

どのツールも根本的な限界（復号後の環境変数は AI エージェントから読める）は同じです。ツール選定に悩む時間があるなら、以下の3つを先にやりましょう。

1. .env の平文を今すぐ排除する

どのツールでもいいので、まず平文の .env をなくします。

1
2
3

# 最も手軽な方法（dotenvx）
$ dotenvx encrypt
$ rm .env.bak  # 暗号化前のバックアップを削除

2. Claude Code の apiKeyHelper を設定する

Claude Code 自身の API キーは apiKeyHelper で動的取得にします。

1
2
3

{
  "apiKeyHelper": "lkr get anthropic:prod --force-plain"
}

または 1Password CLI を使う場合:

1
2
3

{
  "apiKeyHelper": "op read 'op://Development/Anthropic/api_key'"
}

3. deny ルールで .env 関連ファイルの読み取りをブロックする

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./.env.keys)",
      "Read(./secrets/**)",
      "Read(./**/credentials*)"
    ]
  }
}

4. プロセスを分離する

Claude Code にシークレットを渡さない運用が最も安全です。

1
2
3
4
5

# ターミナル1: Claude Code（シークレットなし）
$ claude

# ターミナル2: アプリ（シークレットあり）
$ aws-vault exec dev -- dotenvx run -- python manage.py runserver

判断フローチャート

.env に平文のシークレットがある？
  └─ はい → まず何でもいいから暗号化する（ここが最優先）
       │
       ├─ AWS を使っている？
       │    └─ はい → aws-vault を導入（STS 一時認証は代替不可）
       │
       ├─ LLM API キーを複数使っている？
       │    └─ はい → lkr の導入を検討（TTY ガードが有効）
       │
       ├─ チームで共有が必要？
       │    ├─ 1Password 導入済み → 1Password CLI
       │    └─ 未導入 → dotenvx（Git で共有）
       │
       └─ 個人開発？
            └─ dotenvx が最もシンプル

まとめ

• aws-vault の STS 一時認証は代替不可: AWS を使うなら、これだけは専門ツールを使う価値がある
• lkr は LLM API キーに特化した防御: TTY ガードと runtime/admin 分離は、AI エージェント時代に合理的な設計
• dotenvx は最も移行が容易: 既存の .env をそのまま暗号化でき、Git で共有可能。無料
• 1Password CLI は最も守備範囲が広い: 全種類のシークレットをチームで共有可能。ただし有料
• 全ツールに共通の限界がある: 復号後の環境変数は AI エージェントから読める。完全な防御は不可能
• ツール選定より平文排除が優先: どのツールでもいいので、まず .env の平文をなくすことが最も効果的
• 多層防御が現実解: ツール + apiKeyHelper + deny ルール + プロセス分離の組み合わせでリスクを最小化する

参考

• aws-vault × .env廃止でClaude Code時代のAWS認証管理
• lkr × LLM APIキーをmacOS Keychainで安全管理
• dotenvx暗号化 + 1Password CLI注入 × .env平文ゼロ開発環境
• Claude Code 時代の .env 管理 × 秘密情報の新しい守り方
• dotenvx 公式サイト
• LLM Key Ring (lkr) - GitHub
• aws-vault - GitHub
• Load secrets into the environment | 1Password Developer
• Claude Code Settings - 公式ドキュメント