1Password CLIの導入から実践活用まで｜シークレット管理・SSH・CI/CD連携を網羅

開発プロジェクトで .env ファイルにAPIキーやデータベースパスワードを平文で保存していませんか。チーム開発では認証情報の受け渡しにSlackやメールを使ってしまうケースも少なくありません。1Password CLI（op コマンド）は、こうしたシークレット管理の課題をターミナル操作で解決するツールです。

1Password CLIを使うと、1Passwordに保存された認証情報をコマンドラインから直接取得・注入できます。指紋認証やシステム認証と連携するため、マスターパスワードを毎回入力する手間もありません。

1Password CLIの概要と主要機能

1Password CLIは、1Passwordが提供するコマンドラインツールです。op コマンドを通じて、1Passwordに保存されたパスワード、APIキー、SSH鍵、証明書などにターミナルからアクセスできます。

主要な機能は以下の3カテゴリに分かれます。

1Password CLIの動作には、1Passwordアカウント（個人プラン以上）が必要です。サーバーやCI/CD環境ではサービスアカウントを利用して、個人アカウントに依存しない運用が可能です。

インストール手順（macOS・Linux・Windows）

macOS（Homebrew）

brew install 1password-cli

インストール確認:

op --version

Homebrewを使わない場合は、公式リリースページから .pkg ファイルをダウンロードして実行します。

Linux（APTベース：Ubuntu / Debian）

# GPG鍵の追加
curl -sS https://downloads.1password.com/linux/keys/1password.asc | \
  sudo gpg --dearmor --output /usr/share/keyrings/1password-archive-keyring.gpg

# リポジトリの追加
echo "deb [signed-by=/usr/share/keyrings/1password-archive-keyring.gpg] \
  https://downloads.1password.com/linux/debian/amd64 stable main" | \
  sudo tee /etc/apt/sources.list.d/1password.sources

# インストール
sudo apt update && sudo apt install 1password-cli

YUM / DNFベースのディストリビューション（RHEL / Fedora）では以下を使います。

sudo rpm --import https://downloads.1password.com/linux/keys/1password.asc
sudo yum-config-manager --add-repo \
  https://downloads.1password.com/linux/rpm/stable/x86_64/
sudo yum install 1password-cli

Windows

winget install 1password.1password-cli

手動インストールの場合は、ダウンロードページから op.exe を取得し、PATHの通ったディレクトリに配置します。

WSL（Windows Subsystem for Linux）での利用

WSL環境では、Linux向けのインストール手順に加えて、ホスト側の1Passwordデスクトップアプリとの連携が必要です。WSL2のディストリビューション内でAPTまたは手動でインストールした後、1Passwordデスクトップアプリ側の Settings > Developer > 「1Password CLIと連携」 を有効にします。

WSL環境ではTouch IDなどの生体認証が利用できないため、システム認証（Windowsのパスワードまたは PIN）を使用します。

デスクトップアプリとの連携設定

1Password CLIは単体でも動作しますが、デスクトップアプリと連携させることで生体認証が使えるようになります。

設定手順:

1. 1Passwordデスクトップアプリを開く
2. Settings（設定）> Developer（開発者）に移動
3. 「Integrate with 1Password CLI」（1Password CLIと連携）をオンにする

この設定により、op コマンド実行時にTouch ID（macOS）、Windows Hello（Windows）、またはシステム認証（Linux）でロック解除が可能になります。

連携を確認するには、以下のコマンドを実行します。

op vault list

認証ダイアログが表示され、ボルト一覧が返れば設定完了です。

シークレット参照構文（Secret References）

1Password CLIの中核となるのがシークレット参照構文です。1Passwordに保存されたシークレットの場所を URI 形式で指定します。

op://ボルト名/アイテム名/フィールド名

たとえば「Development」ボルトの「AWS」アイテムにある「access_key」フィールドを参照する場合は以下のように記述します。

op://Development/AWS/access_key

この参照構文は .env ファイルやCI/CDの設定ファイルにそのまま記述できます。平文のシークレットではないため、Gitリポジトリにコミットしても安全です。

op run / op read / op inject の使い分け

1Password CLIには、シークレットを取得・注入するための3つのコマンドがあります。用途に応じて使い分けます。

op read：シークレットの単体取得

特定のシークレットを標準出力に取得します。スクリプトで一時的に値を参照したい場面に適しています。

# シークレットを標準出力に表示
op read "op://Development/AWS/access_key"

# ファイルに出力
op read "op://Development/TLS/certificate" --out-file ./cert.pem

op run：環境変数へのシークレット注入

プロセス起動時に環境変数を1Passwordの値で置換します。.env ファイルにシークレット参照を記述しておけば、アプリケーション起動時に自動で実際の値が注入されます。

# .env ファイルの例
# DATABASE_URL=op://Development/Database/url
# API_KEY=op://Development/ExternalAPI/key

op run --env-file=.env -- node server.js

op run は子プロセスの標準出力をモニタリングし、シークレットの値が誤って出力されそうになるとマスキングを行います。

op inject：テンプレートファイルへのシークレット埋め込み

設定ファイルのテンプレートにシークレット参照を記述しておき、実行時に実際の値に置換します。

# config.template.yml の例:
# database:
#   host: op://Production/DB/host
#   password: op://Production/DB/password

op inject --in-file config.template.yml --out-file config.yml

3コマンドの選択基準

Shell Pluginsで既存CLIと連携する

Shell Pluginsは、AWS CLI・GitHub CLI・Terraform など60以上のサードパーティCLIツールの認証を1Password経由で行える仕組みです。認証情報を ~/.aws/credentials のような平文ファイルに保存する必要がなくなります。

対応ツールの例

AWS CLIとの連携設定例

# Shell Pluginの初期化
op plugin init aws

# 1Passwordにaws認証情報を保存して利用
aws s3 ls

aws s3 ls を実行すると1Passwordの認証ダイアログが表示され、指紋認証でAWSにアクセスできます。~/.aws/credentials にアクセスキーを平文保存する方式と比べて、認証情報の漏洩リスクを大幅に低減できます。

GitHub CLIとの連携

op plugin init gh
gh repo list

GitHub CLIのパーソナルアクセストークンも1Passwordに保存して、認証のたびに自動取得されるようにできます。

SSH Agent統合

1PasswordはSSHエージェントとしても機能し、SSH鍵をアプリ内で一元管理できます。鍵ファイルを ~/.ssh/ に平文で置く必要がなくなります。

設定手順

Step 1: 1Passwordデスクトップアプリで SSH Agent を有効化

1. 1Passwordアプリを開く
2. Settings > Developer > SSH Agent をオンにする

Step 2: SSH設定ファイルを更新

~/.ssh/config に以下を追加します。

# macOS
Host *
  IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"

# Linux
Host *
  IdentityAgent ~/.1password/agent.sock

Step 3: 動作確認

ssh -T git@github.com

1Passwordの認証ダイアログが表示され、承認するとSSH接続が確立されます。

Gitコミット署名への活用

1Password SSH Agentは、SSH鍵を使ったGitコミット署名にも対応しています。GPG鍵の管理に比べてセットアップが簡単です。

git config --global gpg.format ssh
git config --global user.signingkey "ssh-ed25519 AAAA..."
git config --global commit.gpgsign true

署名に使うSSH公開鍵は、1Passwordのアイテム詳細画面からコピーできます。

サービスアカウントの設定（CI/CD・サーバー向け）

サービスアカウントは、個人ユーザーに紐付かない認証方式です。CI/CDパイプラインや本番サーバーなど、対話的なログインができない環境で使用します。

サービスアカウントの作成

1. 1Password管理コンソール（Webブラウザ）にログイン
2. Developer > Directory に移動し、Infrastructure Secrets Management から Service Account を選択
3. サービスアカウント名を入力し、アクセスを許可するボルトと権限（読み取り・書き込み・共有）を設定
4. トークンが生成されるので即座に1Passwordに保存する（トークンは一度しか表示されません）

環境変数での認証

生成されたトークンを OP_SERVICE_ACCOUNT_TOKEN 環境変数に設定すると、op コマンドがサービスアカウントとして認証されます。

export OP_SERVICE_ACCOUNT_TOKEN="<your-service-account-token>"
op read "op://Production/Database/password"

サービスアカウントは最小権限の原則に基づいて設計されており、必要なボルトだけにアクセスを限定できます。なお、サービスアカウントの権限やボルトアクセスは作成後に変更できません。アクセス権を変更する必要がある場合は、新しいサービスアカウントを作成してください。

CI/CDパイプラインでの活用

GitHub Actionsとの連携

1Passwordは公式のGitHub Actionsを提供しています。

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@v2
        # 2025年12月時点でv3も利用可能
        with:
          export-env: true
        env:
          OP_SERVICE_ACCOUNT_TOKEN: ${{ secrets.OP_SERVICE_ACCOUNT_TOKEN }}
          DATABASE_URL: op://Production/Database/url
          API_KEY: op://Production/ExternalAPI/key

      - name: Deploy application
        run: ./deploy.sh

1Password/load-secrets-action は、シークレット参照を解決して環境変数に展開します。GitHub Secretsにはサービスアカウントのトークン1つだけを保存すればよく、個別のシークレットを登録する手間がなくなります。

汎用的なCI/CDスクリプト

GitHub Actions以外のCI/CDツール（GitLab CI、CircleCI、Jenkins等）でも、サービスアカウントトークンと op コマンドを組み合わせて同様の運用が可能です。

#!/bin/bash
# CI/CDパイプライン用スクリプト例
export OP_SERVICE_ACCOUNT_TOKEN="$CI_1PASSWORD_TOKEN"

# シークレットを取得してデプロイに利用
DB_PASSWORD=$(op read "op://Production/Database/password")
API_KEY=$(op read "op://Production/ExternalAPI/key")

# 環境変数として渡してデプロイ
DATABASE_PASSWORD=$DB_PASSWORD API_KEY=$API_KEY ./deploy.sh

Docker環境での利用

Docker環境でのシークレット管理には、主に2つのアプローチがあります。

アプローチ1: ホスト側で op run を使う

ホスト側で op run を使ってシークレットを環境変数に展開し、Docker コンテナに渡す方法です。Dockerfile の変更が不要で、最もシンプルです。

op run --env-file=.env -- docker compose up

.env ファイルにシークレット参照を記述しておけば、コンテナ内のアプリケーションが実際の値を受け取れます。

アプローチ2: 1Password Connect Server

本番環境やマイクロサービスアーキテクチャでは、1Password Connect Serverの利用が適しています。Connect Serverは2つのコンテナ（1password/connect-api と 1password/connect-sync）で構成され、REST API経由でシークレットを提供します。

# docker-compose.yml の例
services:
  connect-api:
    image: 1password/connect-api:latest
    ports:
      - "8080:8080"
    volumes:
      - ./1password-credentials.json:/home/opuser/.op/1password-credentials.json
  connect-sync:
    image: 1password/connect-sync:latest
    volumes:
      - ./1password-credentials.json:/home/opuser/.op/1password-credentials.json

Connect Serverはセルフホスト型であり、1Password.comとの通信はSync コンテナが担います。アプリケーションはローカルのREST APIにのみアクセスするため、ネットワーク制約のある環境にも適合します。

他のシークレット管理手法との比較

開発チームが利用できるシークレット管理手法は複数あります。プロジェクトの規模や要件に応じて最適なものを選択してください。

1Password CLIは、個人の開発環境からチーム開発、CI/CDパイプラインまで幅広くカバーできる点が特徴です。HashiCorp VaultやAWS Secrets Managerのようなインフラ寄りのツールと比較すると、ローカル開発体験との統合が優れています。

よく使うコマンドリファレンス

日常的に使用頻度が高いコマンドを用途別に整理します。

アイテム操作

# アイテム一覧の表示
op item list

# 特定のアイテムを取得（JSON形式）
op item get "Database Credentials" --format json

# 特定フィールドだけ取得
op item get "Database Credentials" --fields password

# アイテムの作成
op item create --category login \
  --title "New API Key" \
  --vault Development \
  --field username=admin \
  --field password=secret123

# アイテムの削除
op item delete "Old API Key"

ボルト操作

# ボルト一覧
op vault list

# ボルト内のアイテム一覧
op item list --vault Production

ユーティリティ

# 現在のサインイン状態を確認
op whoami

# サインイン（複数アカウント切替時）
op signin

# サインアウト
op signout

# JSON出力をjqで整形
op item get "API Key" --format json | jq '.fields[] | select(.label == "credential") | .value'

トラブルシューティング

「error initializing client: Could not connect to 1Password」

1Passwordデスクトップアプリが起動していないか、CLI連携が無効になっています。アプリを起動し、Settings > Developer > 「Integrate with 1Password CLI」がオンになっていることを確認してください。

「You are not signed in」

セッションが期限切れになっています。op signin で再認証するか、デスクトップアプリのロックを解除してください。サービスアカウントを使用している場合は、OP_SERVICE_ACCOUNT_TOKEN 環境変数が正しく設定されているか確認します。

Homebrew でインストールが失敗する

# Homebrewを最新に更新
brew update

# キャッシュをクリアして再インストール
brew cleanup
brew install 1password-cli

古いバージョンの1Password CLIが残っている場合は brew uninstall 1password-cli で削除してから再インストールします。

Shell Pluginが認証ダイアログを表示しない

Shell Pluginのソース読み込みがシェルの設定ファイルに追加されていない可能性があります。~/.bashrc または ~/.zshrc に以下が記述されているか確認してください。

source ~/.config/op/plugins.sh

WSL環境で op コマンドが動作しない

WSL内のLinux環境とホスト側のWindows環境は別です。WSL側に1Password CLIをLinux向け手順でインストールし、ホスト側のデスクトップアプリとの連携を有効にする必要があります。

セキュリティ上の留意点

1Password CLIを利用する際は、以下のセキュリティプラクティスを守ることを推奨します。

• サービスアカウントの権限は最小限にする: CI/CD用のサービスアカウントには、必要なボルトへの読み取り権限のみ付与します
• トークンのローテーション: サービスアカウントトークンは定期的にローテーションし、古いトークンは失効させます
• op run のマスキング機能を活用する: op run は子プロセスの出力にシークレットが含まれる場合に自動マスキングします。--no-masking オプションは本番環境では使わないでください
• 監査ログを確認する: 1Password Business以上のプランでは、CLIからのアクセスも含めた監査ログを確認できます
• .env ファイルにシークレット参照を使う: 平文の値ではなく op:// 形式の参照を記述し、op run 経由でアプリを起動します。これにより .env ファイルをGitにコミットしても情報漏洩のリスクがありません

まとめ

1Password CLIは、開発者のシークレット管理を根本的に改善するツールです。.env ファイルの平文保存から脱却し、op run でアプリ起動時にシークレットを安全に注入できます。Shell Pluginsを使えばAWS CLIやGitHub CLIの認証情報も1Passwordに集約でき、SSH Agent統合で鍵管理も一元化されます。

CI/CDパイプラインではサービスアカウントと公式GitHub Actionsを活用することで、チーム全体のシークレット管理を標準化できます。Docker環境では op run によるホスト側注入、または1Password Connect Serverによるセルフホスト型のREST API提供が可能です。

公式ドキュメント: 1Password CLI | 1Password Developer