1Password CLIで.envの秘密情報を管理する｜opxの使い方

公開: 2026年4月9日更新: 2026年10月26日約10分で読めます

1Password CLIを使うと、.envファイルにAPIキーの値を書かず、op://で始まる参照だけを書いておける。コマンドを実行するときに、1Password CLIの op run --env-file=.env（または、それを呼ぶ筆者自作のラッパー opx）が参照を1Passwordの値に置き換えて環境変数として渡すので、.envに秘密の値を直接保存せずに済む。ただし実行したプログラムが値を画面やログに出せば残るので、出力側の扱いは別に気をつける。筆者の環境では設定は30分ほどで終わった。

.envファイルに平文でAPIキーを書いている。開発者なら一度はやったことがあるはずだ。

# .env（よくある状態）
OPENAI_API_KEY=sk-proj-abc123def456
DATABASE_URL=postgres://admin:P@ssw0rd@db.example.com:5432/myapp
STRIPE_SECRET_KEY=sk_live_xxxxxxxxxxxxxxxx

.gitignoreに入れているから大丈夫？新しいメンバーに.envをSlackで送っていないか。退職者のローカルマシンにAPIキーが残っていないか。CIのシークレット設定と.envの値がズレていないか。

1Password CLIの op run と、それを短く呼ぶための筆者自作のラッパー opx を使うと、.envからシークレットの平文を排除できる。ファイルに書くのは1Passwordへの参照URLだけ。実際の値はopx経由で実行時に注入される。

APIキーやパスワードが、いつの間にかファイルやチャットに散らばっている。この状態は、事故が起きるまで誰も気に留めない。気づいた時には、もう漏れている。

仕組み

opxは、筆者が自分用に作った1Password CLI（opコマンド）のラッパーだ。npmのパッケージでも1Password公式の機能でもない。中身は op run --env-file=.env -- <コマンド> を呼ぶ数行のシェルスクリプトで、.envファイル内のop://参照を1Passwordの実際の値に置き換え、環境変数に注入した上でコマンドを実行する。値の解決そのものは公式の op run が行っている。

.env の op:// 参照 → opx が検出 → 1Password から値を取得 → 環境変数に注入 → コマンド実行

つまり、.envファイルを見ても秘密情報は一切わからない。1Passwordへのアクセス権限がある人だけが、実行時に値を取得できる。

セットアップ手順

1. 1Password CLIのインストール

# macOS（Homebrew）
brew install 1password-cli

# 確認
op --version

2. 1Password CLIにサインイン

# 初回サインイン
op signin

# アカウントを確認
op account list

1Passwordのデスクトップアプリで、設定 > 開発者の「1Password CLIと連携」（Integrate with 1Password CLI）をオンにすると、Touch IDなどの生体認証でサインインできる。毎回マスターパスワードを入力する必要はない。

3. opx（自作ラッパー）を用意する

opxはインストールするものではなく、自分で用意する短縮コマンドだ。npmに同じ名前のパッケージがあるが、1Passwordとは関係のない別物なので入れないこと。公式のコマンドだけで使うなら、毎回次のように書けば同じことができる。--env-file を付けないと op run は.envを読まないので、ここは省略しない。

# 公式の op run を直接使う
op run --env-file=.env -- npm run dev

毎回これを打つのが面倒なので、筆者は同じ動きをするシェルスクリプトを opx という名前でPATHの通った場所に置いている。同じものを手早く用意するなら、最小の形はシェル関数1行で足りる（筆者のスクリプトは、.envが無いときはそのまま実行する分岐などを足している）。

# ~/.zshrc などに追記
opx() { op run --env-file=.env -- "$@"; }

4. 1Passwordにシークレットを登録

1Passwordのvault内に「Secure Note」または専用のアイテムを作成し、各シークレットをフィールドとして登録する。

Vault: Development
Item: MyApp Secrets
Fields:
  - OPENAI_API_KEY: sk-proj-abc123def456
  - DATABASE_URL: postgres://admin:P@ssw0rd@db.example.com:5432/myapp
  - STRIPE_SECRET_KEY: sk_live_xxxxxxxxxxxxxxxx

各フィールドの参照URLは、1Passwordアプリでアイテムを開き、フィールドの「参照をコピー」で取得できる。

.envファイルの書き換え: Before → After

Before（平文）

# .env
OPENAI_API_KEY=sk-proj-abc123def456
DATABASE_URL=postgres://admin:P@ssw0rd@db.example.com:5432/myapp
STRIPE_SECRET_KEY=sk_live_xxxxxxxxxxxxxxxx
AWS_ACCESS_KEY_ID=AKIA1234567890ABCDEF
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG+bPxRfiCYEXAMPLEKEY
SENDGRID_API_KEY=SG.xxxxxxxxxxxxxxxxxxxx

After（op://参照）

# .env
OPENAI_API_KEY=op://Development/MyApp Secrets/OPENAI_API_KEY
DATABASE_URL=op://Development/MyApp Secrets/DATABASE_URL
STRIPE_SECRET_KEY=op://Development/MyApp Secrets/STRIPE_SECRET_KEY
AWS_ACCESS_KEY_ID=op://Development/MyApp Secrets/AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY=op://Development/MyApp Secrets/AWS_SECRET_ACCESS_KEY
SENDGRID_API_KEY=op://Development/MyApp Secrets/SENDGRID_API_KEY

op://の形式は op://<vault名>/<アイテム名>/<フィールド名>。

この.envファイルはGitにコミットしても安全だ。参照URLだけなので、1Passwordへのアクセス権がなければ値を取得できない。

使い方

開発サーバーの起動

# Before: 平文.envを読み込む
npm run dev

# After: opx経由で起動
opx npm run dev

# または op run を使う場合
op run --env-file=.env -- npm run dev

opxが.envのop://参照を解決し、環境変数として注入した状態でコマンドを実行する。アプリケーション側のコード変更は不要。process.env.OPENAI_API_KEYでそのまま取得できる。

特定のコマンドだけ実行

# マイグレーション実行
opx npx prisma migrate deploy

# テスト実行（DB接続が必要な場合）
opx npm test

# シークレットが不要なコマンドにはopx不要
npm install    # opx不要
npm run lint   # opx不要
git push       # opx不要

値の確認（デバッグ用）

# 特定のシークレットの値を確認
op read "op://Development/MyApp Secrets/OPENAI_API_KEY"

# .envの参照が解決できたかを確かめる（値は初期設定で伏せ字になる）
op run --env-file=.env -- env | grep -E "OPENAI|DATABASE|STRIPE"

値そのものを確かめたいときは、上の op read で1件ずつ確認する。

チーム導入の手順

Step 1: Vaultの設計

Production Vault（本番用）
  ├── API Keys（外部サービス）
  ├── Database Credentials（DB接続情報）
  └── SSL Certificates（証明書）

Development Vault（開発用）
  ├── API Keys（テスト用キー）
  └── Database Credentials（ローカルDB）

Staging Vault（ステージング用）
  └── （本番とは異なるキーを使用）

Vaultを環境ごとに分けると、開発者に本番のシークレットへのアクセス権を与えずに済む。

Step 2: アクセス権限の設定

1Passwordのチーム機能で、Vaultへのアクセスを役割ベースで管理する。

役割	Development Vault	Staging Vault	Production Vault
開発者	読み取り	読み取り	アクセス不可
リードエンジニア	読み取り/書き込み	読み取り/書き込み	読み取り
CTO/インフラ	フル	フル	フル

Step 3: オンボーディング手順の整備

新しいメンバーが参加したときの手順:

1Passwordのチームに招待
Development Vaultへのアクセス権を付与
1Password CLIをインストール（brew install 1password-cli）
op signinでサインイン
プロジェクトをクローンしてop run --env-file=.env -- npm run dev（opxを用意していればopx npm run dev）

.envファイルをSlackで送る必要がない。1Passwordのアクセス権を付与するだけで、環境構築が完了する。

Step 4: 退職者のアクセス削除

1Passwordのチームから外せば、今後1Password経由で値を取り出せなくなる。ただし在籍中に見られた値はキーを変えない限りそのまま使えるので、その人がアクセスできたVaultの主要なキーはローテーションする。

CI/CDとの統合

GitHub Actions

# .github/workflows/deploy.yml
name: Deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Load secrets from 1Password
        uses: 1password/load-secrets-action@v5
        with:
          export-env: true
        env:
          OP_SERVICE_ACCOUNT_TOKEN: ${{ secrets.OP_SERVICE_ACCOUNT_TOKEN }}
          OPENAI_API_KEY: op://Production/MyApp Secrets/OPENAI_API_KEY
          DATABASE_URL: op://Production/MyApp Secrets/DATABASE_URL

      - name: Deploy
        run: npm run deploy

GitHub Actionsの場合、1Passwordのサービスアカウントトークンを1つだけGitHub Secretsに登録する。個別のシークレットをGitHub Secretsに登録する手間がなくなる。

他のCIサービス

CircleCIやJenkinsにも1Password公式のインテグレーションがある。それ以外のCI（GitLab CIなど）では、サービスアカウントとCLIを使って同じように組める。

コスト

1Passwordの料金（2026年10月時点、いずれも年払い）:

プラン	月額（年払い）	主な機能
Teams Starter Pack	月$24.95（10人まで定額。追加料金で最大20人まで）	少人数チーム向け、Vault共有、管理コンソール
Business	1人あたり$8.99	SSO統合、カスタムロール、監査ログ
Enterprise	要問合せ	専任サポート、SLA

開発チーム5人の場合でも、Teams Starter Packなら月$24.95（10人分の枠）。1つのAPIキーの漏洩リスクを考えれば、十分にペイする投資だ。

補足: 経営層への説明

技術的なメリットは明確だが、経営層への説明にはビジネスリスクの観点が必要になる。

APIキー漏洩のコスト: OpenAI APIキーが漏洩すれば、数時間で数十万円の不正利用が発生しうる
コンプライアンス: ISO 27001やSOC 2の要件として、シークレットの管理は必須項目
退職時のリスク: 平文の.envファイルが退職者のPCに残る問題を構造的に解決

「1Passwordの月額費用」と「漏洩時の損害額」を比較すれば、投資判断としては明快だ。

まとめ

1Password CLI（と自作ラッパー opx）で.envの平文シークレットを排除する手順:

1Password CLIをインストール（5分）
シークレットを1Passwordに登録（15分）
.envをop://参照に書き換え（10分）
op run --env-file=.env --（または自作のopx）経由でコマンドを実行する運用に切り替え

全体で30分程度の作業で、シークレット管理のリスクが大幅に下がる。新しいプロジェクトを始めるとき、最初に.envをop://形式で書く習慣をつけるのが一番楽だ。

秘密情報の管理は、うまくいっている時は誰も褒めてくれない。でも一度漏れると、取引先の信用まで巻き込む。中小企業ほど専任の担当がいないぶん、仕組みで守る設計が要る。難しい話に聞こえるかもしれないけど、正しいツールを入れて運用を決めるだけで、リスクの大半は下げられる。自社の情報管理が今どうなっているか不安な人は、現状の棚卸しから一緒にやろう。まずは現在地を知るだけで十分。無料の診断（6問・約1分）で、どの業務からAIに任せられるかの目安がその場で出る。

自動化の現在地を診断する（無料・6問・約1分）