1Password CLIの使い方：op runでの秘密情報注入とCIのサービスアカウント運用

1Password CLIは、1Passwordの保管庫にある秘密情報をopコマンドから読み出す公式ツールです。APIキーやDBパスワードを.envに平文で置く代わりに、op://で始まるシークレット参照だけを書き、実行時に値へ置き換えます。導入とサインイン、参照の書き方、op run・op read・op injectの使い分け、AWS CLIを生体認証で動かすシェルプラグイン、GitHub Actionsでのサービスアカウント運用とレート制限までを、公式ドキュメントの記述に沿ってコード付きで扱います。

まとめ：1Password CLIで平文の.envをなくす手順とCI導入の判断基準

手元の開発環境では、デスクトップアプリ連携でサインインし、.envの値をシークレット参照に書き換えてop run経由でアプリを起動します。これだけでリポジトリと端末のディスクから平文の秘密情報が消えます。設定ファイルにしか書けない値はop injectで生成し、使い終わったら生成物を消してください。

CI/CDではサービスアカウントのトークン1本だけをCI側に置き、残りは1Passwordから読みます。注意点はレート制限です。Teamsプランでは1トークンあたり1時間に読み取り1,000回、全サービスアカウント合算で1日5,000回が上限なので、ジョブ数が多い組織はBusinessプランかVault・Secrets Managerを検討します。本番アプリが実行時に秘密情報を取りに行く用途には、1Password CLIを使いません。

1Password CLIのインストールとデスクトップアプリ連携でサインインする手順

CLI単体でも動きますが、手元の端末ではデスクトップアプリと連携させる構成が公式の推奨です。マスターパスワードをターミナルに打たずに済み、指紋やWindows Helloで認証できます。

Homebrew・winget・aptでのopコマンド導入と2.39系の版確認

公式の導入手順は、macOSはHomebrew、Windowsはwinget、Debian系LinuxはAPTリポジトリの追加を案内しています。リリースノートでは2026年8月14日の2.39.0が最新で、2系の中で小刻みに版が上がっています。

# macOS
$ brew install 1password-cli

# Windows（PowerShell）
PS> winget install 1password-cli

# 導入できたか版を確かめる
$ op --version
2.39.0

APTでの導入は署名鍵とdebsigポリシーの登録を含む長い手順なので、公式ページのコマンドをそのまま貼り付けてください。旧来のCLI 1系は2024年10月1日に非推奨となり、1系を前提にしたスクリプトは期待どおりに動かなくなっています。古い記事で見かけるop get itemは1系の書式で、2系ではop item getと書きます。

デスクトップアプリ連携で生体認証によりop vault listを通す設定

デスクトップアプリの「設定」から「開発者」を開き、「1Password CLIと連携」を有効にします。あとはターミナルで保管庫の一覧を取るだけで、認証のダイアログが出ます。

# 初回はアプリ側で指紋・Windows Hello などの確認が出る
$ op vault list
ID                            NAME
xxxxxxxxxxxxxxxxxxxxxxxxxx    development
yyyyyyyyyyyyyyyyyyyyyyyyyy    Private

# 複数アカウントを持っている場合は選んでサインインする
$ op signin

連携を有効にしないままeval $(op signin)でセッショントークンを環境変数に入れる方式もあります。ただしトークンがシェル履歴や子プロセスに残りやすいので、手元ではアプリ連携を選んでください。

シークレット参照op://の構文とop read・op run・op injectの選択

1Password CLIの中心は、保管庫・アイテム・フィールドをURIで指すシークレット参照です。参照文字列そのものは秘密ではないので、リポジトリにコミットできます。

op://vault/item/field構文とattribute=otpの指定

シークレット参照の公式ページによる書式はop://<保管庫>/<アイテム>/[セクション/]<フィールド>で、セクションは省略できます。末尾に?attribute=otpを付けるとワンタイムパスワードの現在値が、?ssh-format=opensshを付けるとSSH秘密鍵がOpenSSH形式で返ります。

# 値を1つだけ標準出力に出す
$ op read "op://development/GitHub/credentials/personal_token"

# 2段階認証のワンタイムパスワードを取る
$ op read "op://development/GitHub/Security/one-time password?attribute=otp"

参照は手で書くより、デスクトップアプリでフィールドの右のメニューから「シークレット参照をコピー」を選ぶほうが確実です。アイテム名に空白や記号が入っていても、アプリが正しい形で書き出します。

op runで.envの参照を実行時に解決し出力をマスクする仕組み

一番使う場面が多いのがop runです。op runのリファレンスによると、--env-fileで渡したファイルやシェルの環境変数に含まれる参照を解決し、その値を子プロセスの環境変数としてだけ渡します。

# .env（参照だけを書くのでコミットしてよい）
DB_PASSWORD="op://development/postgres/password"
OPENAI_API_KEY="op://development/OpenAI/credential"

# 子プロセスにだけ解決済みの値が入る
$ op run --env-file="./.env" -- node app.js

# 標準出力・標準エラーに値が出てもマスクされる
$ op run --env-file="./.env" -- printenv DB_PASSWORD
<concealed by 1Password>

マスクは既定で有効です。マスクを外して実行するときに指定するオプションが--no-maskingです。同じ変数名が複数の場所にあると、1Password Environments（--environment・ベータ機能）、--env-file、シェルの環境変数の順で優先されます。--env-fileを複数渡した場合は、後に書いたファイルが勝ちます。

op injectで設定ファイルのテンプレートから実ファイルを生成する流れ

環境変数を読まないツールには、設定ファイルへの注入を使います。テンプレートの値を参照に置き換えておき、op injectで実ファイルを作る流れです。参照の中に$APP_ENVのような変数を入れると、1つのテンプレートで開発と本番を切り替えられます。

# config.yml.tpl
database:
    username: op://$APP_ENV/mysql/username
    password: op://$APP_ENV/mysql/password

# 本番の保管庫から値を埋めた config.yml を作る
$ APP_ENV=prod op inject -i config.yml.tpl -o config.yml

生成されたconfig.ymlには平文が入ります。公式も不要になったら消すよう書いているので、.gitignoreへの追加と、処理の最後での削除をセットで組み込んでください。

3コマンドの値の渡し先による選び分けと平文がディスクに残る経路の比較

3つのコマンドは、値の渡し先と平文が残る場所で選びます。

迷ったらop runから始めてください。op readの結果をexportで親シェルに入れると、そのシェルから起動したすべてのプロセスに値が見えてしまい、op runで得られる範囲の限定が失われます。

シェルプラグインでAWS CLIやghの認証を1Password経由に切り替える設定

アプリの秘密情報とは別に、AWS CLIやGitHub CLIの認証情報も端末に平文で残りがちです。シェルプラグインは、これらのCLIを起動するたびに1Passwordから認証情報を渡し、指紋などで承認させる仕組みです。

AWS CLIの長期キーを端末の認証情報ファイルから外すプラグイン設定

AWS CLI用プラグインの手順はCLI 2.9.0以降が前提です。初期化コマンドが1Password内のアクセスキーを選ばせ、エイリアスを書いたplugins.shを作ります。

# 対話形式でアイテムと適用範囲（常に・このディレクトリだけ等）を選ぶ
$ op plugin init aws

# ~/.bashrc や ~/.zshrc に追記して、新しいシェルでも有効にする
source ~/.config/op/plugins.sh

# 以降は aws コマンドを打つたびに 1Password の承認が出る
$ aws sts get-caller-identity

公式は、1Passwordに保存したあと~/.aws/credentialsなど端末上の写しをすべて消すよう求めています。消し忘れると、プラグインを通らない経路で古い平文のキーが使われ続けます。長期キー自体を減らしたい場合は、AWS側のSSOやOIDCへの移行が先です。

Bash・Zsh・fish限定でPowerShellが対象外となる制約への対処

シェルプラグインが動くのはBash・Zsh・fishの3つで、公式のAWS用ページはmacOSとLinuxのみを対象としています。Windowsの開発者がPowerShellで同じことをしたい場合は、WSL上のBashで使うか、op run -- aws ...の形で環境変数として渡す方法に切り替えます。

チームにWindowsとmacOSが混在しているなら、手順書はシェルプラグインではなくop runで統一したほうが、問い合わせが減ります。

GitHub ActionsなどCI/CDからサービスアカウントで秘密情報を読む実装

CIには人のアカウントでサインインできません。サービスアカウントは、特定の保管庫だけに読み書きの権限を持つ機械用のアカウントで、組織あたり100個まで作れます。

OP_SERVICE_ACCOUNT_TOKEN設定とCLI 2.18.0以降の認証

サービスアカウントとCLIの併用手順によると、CLI 2.18.0以降で環境変数OP_SERVICE_ACCOUNT_TOKENにトークンを入れるだけで認証されます。トークンは作成時に1回しか表示されないので、その場でCI側のシークレットへ登録してください。

$ export OP_SERVICE_ACCOUNT_TOKEN="<作成時に1回だけ表示されたトークン>"   # CI のシークレットから渡す
$ op user get --me                            # サービスアカウントとして認証できたか確認
$ op run --env-file="./.env.ci" -- npm test

サービスアカウントはPersonal・Private・Employeeの保管庫にアクセスできません。CI用の値は共有保管庫へ移しておく必要があります。またOP_CONNECT_HOSTとOP_CONNECT_TOKENが設定されていると、1Password Connectの設定が優先されます。

load-secrets-action v5でワークフローに秘密情報を渡すYAML例

GitHub Actionsでは、公式のload-secrets-actionを使うとCLIの導入まで済みます。最新のメジャーはv5です。

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

      - 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 }}
          DB_PASSWORD: op://app-cicd/postgres/password

      - name: Run migration
        run: npm run migrate   # DB_PASSWORD が環境変数として読める

GitHub側に置くのはトークン1本だけになり、値のローテーションは1Password側で完結します。ほかのジョブに値が漏れない書き方やOIDCへの移行判断は、GitHub ActionsのSecrets管理と漏えい経路・OIDC移行の判断で整理しています。

1時間1,000回・1日5,000回のレート制限を超えないID指定の書き方

レート制限の公式ページの値は次のとおりです。1時間の枠はトークンごと、1日の枠は組織内の全サービスアカウントの合算で数えます。

Teamsで1回のジョブが10個の値を読むなら、1日500回のジョブ実行で上限に届きます。op item getやop item listは内部で複数回リクエストするため、リクエスト回数を減らすには、名前ではなく保管庫とアイテムのIDを使って対象を指定してください。残量はop service-account ratelimitで確かめられるので、ジョブの冒頭に入れておくと、上限到達による失敗を切り分けやすくなります。

1Password CLI・Vault・Secrets Managerの用途別採用基準

1Password CLIは、人が使うパスワード管理の延長で秘密情報を扱う道具です。本番システムのシークレット管理基盤とは設計の前提が違うので、用途で線を引きます。

開発者の手元と小規模CIで平文を消す目的なら1Password CLIで足りる条件

次の条件がそろうなら、1Password CLIを採用してください。社員がすでに1Passwordを使っていること、平文の.envやSlackでのキー共有をやめたいこと、CIの実行回数がTeamsなら1日数百回に収まることです。新しいサーバーを立てずに、既存の保管庫と権限管理をそのまま使えるのが最大の利点になります。

パスワードの運用ルールそのものを整えたい場合は、パスワード管理のベストプラクティスと企業ポリシー設計を先に読むと、保管庫の分け方を決めやすくなります。.envの置き換えからCIのシークレット移行、パイプライン全体の整理までを進めたい場合は、DevOps・CI/CD導入支援として設計から実装まで引き受けています。

本番アプリの実行時取得や動的シークレットが要るなら採用しない理由

本番のアプリケーションが起動時や実行中に秘密情報を取りに行く構成では、1Password CLIを使いません。サービスアカウントのレート制限は大量のコンテナが同時に起動する用途を想定しておらず、Businessプランでも1日50,000回で止まります。IAMロールと結び付いたアクセス制御や、自動ローテーションもクラウドのサービスのほうが揃っています。

AWS上のシステムならAWS Secrets Managerのローテーション設定と採用判断、DB認証情報を都度発行する動的シークレットが要るならHashiCorp Vaultの動的シークレットと採用判断が候補です。典型的な失敗は、手元で便利だったop runを本番のコンテナ起動にもそのまま持ち込み、デプロイが集中した日にレート制限で起動が止まるケースです。

よくある質問

1Password CLIについて問い合わせの多い点を、公式ドキュメントの記述に沿って答えます。

1Password CLIは無料で使えますか？

CLI自体は無料でダウンロードできますが、読み出す先の1Passwordアカウントは有料プランの契約が前提です。個人プランでもop runやop readは使えます。CI向けのサービスアカウントについて、公式の管理手順はTeamsとBusinessでの作成と権限設定を案内しています。1日の読み書き上限もTeamsの5,000回に対してBusinessは50,000回なので、ジョブ数で選んでください。

op runで渡した値がログに出ることはありますか？

既定では、子プロセスが標準出力や標準エラーに書いた秘密情報の値は「<concealed by 1Password>」に置き換えられます。ただし、プロセスがファイルや外部サービスへ直接書いたログはマスクの対象外です。--no-maskingを付けた場合もマスクは外れるので、CIのログ設定では付けないでください。

Windowsでも1Password CLIは使えますか？

使えます。wingetで導入でき、デスクトップアプリ連携によるWindows Helloでの認証、op run・op read・op injectはWindowsでも動きます。対象外なのはシェルプラグインで、公式が対応するのはBash・Zsh・fishです。PowerShell中心のチームはop runで環境変数として渡す手順に統一してください。

サービスアカウントのトークンが漏れたらどうすればよいですか？

サービスアカウントの管理手順に沿って、1Password.comのサイドバーの「Developer」から対象のサービスアカウントを開き、「Revoke Token」で失効させます。止められない処理がある場合は「Rotate Token」を使い、旧トークンの有効期限を決めたうえで、処理で使用するトークンを新しいものへ差し替えてください。サービスアカウントは付与した保管庫にしか触れないので、被害の範囲はその保管庫の中身に限られます。念のため、保管庫内の値そのものも順にローテーションしてください。

1Password CLIとHashiCorp Vaultはどちらを選べばよいですか？

開発者の手元と小規模なCIで平文をなくす目的なら1Password CLIで足ります。本番アプリが実行時に大量に取りに行く、DB認証情報を都度発行したい、監査要件でシークレットの基盤を自社で持ちたい場合はVaultを選びます。両方を併用し、人が扱う値は1Password、本番システムの値はVaultやクラウドのシークレット管理に分ける構成も一般的です。

関連記事

• HashiCorp Vaultとは？シークレット管理の仕組み・動的シークレット・Kubernetes連携と採用判断を実装者目線で解説：本番システム向けのシークレット管理基盤の選択肢です。
• AWS Secrets Managerとは？料金・ローテーション設定と採用判断を実装者目線で解説【2026年版】：AWS上のアプリが実行時に秘密情報を読む場合の標準構成です。
• GitHub ActionsのSecrets管理｜置き場所の選定と漏えい経路・OIDC移行の判断：サービスアカウントのトークンを置くCI側の設計です。
• GitHub Actionsの環境変数｜env・vars・secretsの使い分けと受け渡し：load-secrets-actionで読んだ値をステップ間で扱う方法が分かります。
• パスワード管理のベストプラクティス｜NIST最新指針と企業ポリシー設計を解説：1Passwordの保管庫設計の前提になる社内ルールの作り方です。