1Password CLIは、1Passwordの保管庫にある秘密情報をopコマンドで読み出す公式ツールです。.envにはop://で始まるシークレット参照だけを書き、値は実行時に置き換えます。この記事では2026年10月21日公開の2.41.1を使い、導入とサインイン、op run・op read・op injectの使い分け、AWS CLIのシェルプラグイン、GitHub Actionsのサービスアカウントとレート制限を扱います。op runのマスクで隠れない出力と、PHPから値を読むときの注意は、op 2.41.1とPHP 8.5.8を、ローカルに立てた1Password Connect APIのモック（ダミーの値を返す検証用サーバー）につないで実行した結果です。
まとめ：1Password CLIで平文の.envをなくす手順とCI導入の判断基準
手元ではデスクトップアプリ連携でサインインし、.envの値をシークレット参照に書き換えてop run経由でアプリを起動します。これで、これから作る.envとリポジトリには平文の秘密情報が入らなくなります。過去のコミット履歴やバックアップ、ログに残った値は別に消して、値そのものもローテーションしてください。環境変数を読まないツールの設定ファイルはop injectで生成し、使い終わったら消してください。
op runのマスクは補助です。base64に変換した値や、数文字ずつ分けて書き出した値、ファイルに書いたログは平文のまま出ます。ログに出さない設計は別に必要です。
CI/CDではサービスアカウントのトークン1本だけをCI側に置きます。Teamsプランの読み取りは1トークンあたり1時間1,000回までで、公式の表では名前で指定したop readは1回で3リクエストになり、保管庫とアイテムの両方をIDで指定すると1リクエストに減ります。本番アプリが実行時に秘密情報を取りに行く用途には、1Password CLIを使いません。
1Password CLIのインストールとデスクトップアプリ連携でサインインする手順
CLI単体でも動きますが、開発者の端末ではデスクトップアプリとの連携が公式の推奨です。マスターパスワードをターミナルに打たずに済み、Touch IDやWindows Helloで認証できます。
Homebrew・winget・aptでの導入と2.41系の版確認
公式の導入手順は、macOSはHomebrew、Windowsはwinget、Debian系LinuxはAPTリポジトリの追加を案内しています。リリースノートの最新は2026年10月21日の2.41.1です。
# macOS
$ brew install 1password-cli
# Windows（PowerShell）
PS> winget install 1password-cli
# 導入できたか版を確かめる
$ op --version
2.41.1
直近の版で手順に効く変更は次の3つです。
- 2.38.1（2026年7月30日）：名前で指定した
op readやop item getの通信が1往復減った - 2.40.0（2026年10月1日）：
op runのヘルプに「マスクはベストエフォートで、隠すことを保証しない」と明記された - 2.41.0（2026年10月12日）：
op runが--environmentで1Password Environmentsの変数を読めるようになった
APTの手順は署名鍵とdebsigポリシーの登録を含むので、公式ページのコマンドをそのまま使ってください。古い記事で見かけるop get itemはCLI 1系の書式で、2系ではop item getと書きます。
デスクトップアプリ連携の有効化とop vault listでの認証確認
デスクトップアプリの「設定」から「開発者」を開き、「1Password CLIと連携」を有効にします。ターミナルで保管庫の一覧を取ると、アプリ側に認証のダイアログが出ます。
# 初回はアプリ側で Touch ID や Windows Hello の確認が出る
$ op vault list
ID NAME
xxxxxxxxxxxxxxxxxxxxxxxxxx development
yyyyyyyyyyyyyyyyyyyyyyyyyy Private
# 複数アカウントを持っている場合は選んでサインインする
$ op signin
No accounts configuredやop signinの案内が出たときの対処
連携もサインインもしていない状態で参照を解決しようとすると、2.41.1は次のメッセージで止まります。終了コードは1です。
$ op read "op://development/postgres/password"
No accounts configured for use with 1Password CLI.
- Turn on the 1Password desktop app integration to sign in ...
- Add an account manually with 'op account add' ...
- Authenticate using a 1Password service account by setting the 'OP_SERVICE_ACCOUNT_TOKEN' ...
- Use 1Password CLI with a Connect server by setting the 'OP_CONNECT_HOST' and 'OP_CONNECT_TOKEN' ...
手元ならアプリ連携を有効にするのが近道です。メッセージどおりop account addで手動登録した場合は、op signinが出力するのはセッショントークンを設定するシェルのコマンドなので、eval $(op signin)のように実行させます。そのまま打つと「Output of ‘op signin’ is meant to be executed by your terminal」という案内が出ます。この方式はトークンが環境変数に残るので、手元ではアプリ連携を選んでください。
CIでfailed to DecodeSACredentials: illegal base64 dataと出たら、OP_SERVICE_ACCOUNT_TOKENの値が壊れています。でたらめな値を入れて実行すると、2.41.1はこのメッセージを終了コード9で返しました。CIのシークレットに登録するとき、引用符や改行まで一緒に貼っていないかを確かめてください。
シークレット参照op://の構文とop read・op run・op injectの使い分け
1Password CLIの中心は、保管庫・アイテム・フィールドをURIで指すシークレット参照です。参照の文字列そのものは秘密ではないので、リポジトリにコミットできます。
op://vault/item/field構文とattribute=otp・ssh-formatの指定
シークレット参照の公式ページによる書式はop://<保管庫>/<アイテム>/[セクション/]<フィールド>で、セクションは省略できます。末尾に?attribute=otpを付けるとワンタイムパスワードの現在値が、?ssh-format=opensshを付けるとSSH秘密鍵がOpenSSH形式で返ります。
# 2段階認証のワンタイムパスワードを取る
$ op read "op://development/GitHub/Security/one-time password?attribute=otp"
# SSH 秘密鍵を OpenSSH 形式で取る
$ op read "op://development/deploy key/private key?ssh-format=openssh"
参照は手で書くより、デスクトップアプリでフィールドの右のメニューから「シークレット参照をコピー」を選ぶほうが確実です。アイテム名に空白や記号が入っていても、アプリが正しい形で書き出します。
op readで値を1つ取り出すときの改行と–out-file
op readは値を標準出力に出します。2.41.1で出力をダンプすると、値の後ろに改行（0a）が1つ付いていました。ファイルにリダイレクトしてAPIキーとして読ませると、末尾の改行まで値に含まれて認証に失敗するツールがあります。そういうときは-n（--no-newline）を付けます。
$ op read "op://development/postgres/password" | xxd
00000000: 5333 6372 3374 2d50 6135 350a S3cr3t-Pa55.
# 改行なしで出す
$ op read -n "op://development/postgres/password"
# 鍵や添付ファイルはファイルへ直接書く（パーミッションは既定で 0600）
$ op read --out-file ./key.pem "op://app-prod/server/ssh/key.pem"
アイテムの複数のフィールドをまとめて取りたいときはop item getを使います。--fields label=username,label=passwordで欲しいフィールドだけに絞れます。パスワードのような隠しフィールドを値のまま出すには--revealが要ります。
op runで.envの参照を実行時に解決する優先順位
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>
同じ変数名が複数の場所にあるときの優先順位は、1Password Environments（--environment）、--env-file、シェルの環境変数の順です。--env-fileを2つ渡すと、後に書いたファイルが勝ちます。参照を含まない.envだけなら、op runはサインインしていなくてもそのまま子プロセスを起動します。AIエージェントのMCP設定から平文トークンを外す使い方は1Password for Agentsとは：AIエージェントにパスワードを渡さない仕組みと実装判断で扱っています。
op injectによるテンプレートからの設定ファイル生成と削除
環境変数を読まないツールには、設定ファイルへの注入を使います。テンプレートの値を参照に置き換えておき、op injectで実ファイルを作ります。参照は{{ }}で囲む書き方と、囲まない書き方のどちらでも解決されました。接続文字列のように1行に複数の値を並べるときは{{ }}で囲みます。下の例は値に#・/・%・@などの記号を含まない前提です。記号を含むパスワードをURIに埋め込むとURLエンコードが要るので、その場合はユーザー名とパスワードを別のキーに分けて書くほうが安全です。
# config.yml.tpl
user: {{ op://$APP_ENV/postgres/username }}
url: postgres://{{ op://$APP_ENV/postgres/username }}:{{ op://$APP_ENV/postgres/password }}@db:5432/app
# 本番の保管庫から値を埋めた config.yml を作る
$ APP_ENV=prod op inject -i config.yml.tpl -o config.yml
$ ls -l config.yml
-rw------- ... config.yml
出力ファイルのパーミッションは既定で0600（--file-modeで変更可）でした。それでも中身は平文です。公式も不要になったら消すよう書いているので、.gitignoreへの追加と、処理の最後での削除をセットで組み込んでください。
値の渡し先と平文がディスクに残るかで選ぶ3コマンドの比較
| コマンド | 値の渡し先 | 平文がディスクに残るか | 向く用途 |
|---|---|---|---|
| op run | 子プロセスの環境変数 | 残らない | アプリ起動・テスト・マイグレーション |
| op read | 標準出力・ファイル | 出力先次第 | スクリプトで値を1つだけ使う |
| op inject | ファイル | 残る（削除が必要） | 環境変数を読まないミドルウェア |
迷ったらop runから始めてください。op readの結果をexportで親シェルに入れると、そのシェルから起動したすべてのプロセスに値が見え、op runで得られる範囲の限定が失われます。
op runのマスクで隠れる出力と平文で出る出力の実測
2.40.0から、op runのヘルプには「マスクはベストエフォートで、アプリが値を変換して出力したり、別々の書き込みに分けたりすると平文が出うる」と書かれています。どこまで隠れるかを、2.41.1とローカルに立てた1Password Connect APIのモック（値はS3cr3t-Pa55）で確かめました。
op runの出力形式別のマスク結果
| 子プロセスの出力 | 結果 |
|---|---|
| printenv（標準出力） | 隠れた |
| echo で標準エラーへ | 隠れた |
| JSONの文字列に埋め込む | 隠れた |
| URLエンコード（記号なしの値） | 隠れた |
| base64に変換 | 平文相当で出た（UzNjcjN0LVBhNTU=） |
| 逆順に並べ替え | 出た |
| 4文字ずつ改行して出力 | 出た |
| 末尾を切った部分文字列 | 出た（S3cr3t） |
| ファイルへ書き込み | 出た（マスク対象外） |
今回の入力では、値がそのままの形で出たときは隠れ、変換・分割・部分的に出したときは隠れませんでした。デバッグ用にbase64で出したり、エラーメッセージに値の一部が入ったりすれば漏れると考えてください。ログに秘密情報を出さない設計は別に用意してください。
PHPのvar_dump()で出すと、値は隠れてもstring(11) "<concealed by 1Password>"と元の文字数が残りました。パスワードの長さも手がかりになるので、マスクされた出力をそのまま公開の場所に貼らないでください。
op run — echo “$VAR”が参照文字列を出す展開順のつまずき
シェルで参照をexportしておき、op run -- echo "$DB_PASSWORD"と打つと、出てくるのは値ではなくop://development/postgres/passwordという参照の文字列です。$DB_PASSWORDはop runが起動する前に、親のシェルが展開してしまうためです。
$ export DB_PASSWORD="op://development/postgres/password"
# 親シェルが先に展開するので参照のまま出る
$ op run --no-masking -- echo "$DB_PASSWORD"
op://development/postgres/password
# 子のシェルで展開させると値が入る
$ op run --no-masking -- sh -c 'echo "$DB_PASSWORD"'
S3cr3t-Pa55
curl -H "Authorization: Bearer $TOKEN"のように引数に変数を書く場合も同じで、sh -c '...'の単引用符で親シェルの展開を止めます。
PHPなどSDKのない言語から1Passwordの値を読む方法
1Passwordの公式SDKが挙げる言語はGo・JavaScript・Pythonの3つで、PHPは入っていません。それ以外の言語からは、op runで環境変数として渡すか、op injectで設定ファイルを作るのが現実的です。
PHPには、環境変数の読み方で結果が変わる注意点があります。op runで渡した値を3つの方法で読むと、次のようになりました（PHP 8.5.8）。
<?php
var_dump(getenv('DB_PASSWORD')); // string(11) "S3cr3t-Pa55"
var_dump($_ENV['DB_PASSWORD'] ?? null); // NULL
var_dump($_SERVER['DB_PASSWORD'] ?? null); // string(11) "S3cr3t-Pa55"
$ op run --no-masking --env-file=./.env -- php t.php
$_ENVだけが空なのは、配布されているphp.iniのvariables_orderが"GPCS"で、環境変数を表すEを含まないためです。php.iniを読まずに起動（php -n）すると既定値の"EGPCS"になり、$_ENVにも値が入りました。開発機と本番でphp.iniが違うと、片方だけ値が読めない事態になるので、getenv()で読むのが安全です。
LaravelのようにフレームワークがPHP側で.envを読む場合、op://の参照を書いた.envをop runを通さずに読み込むと、参照の文字列がそのまま値として入ります。参照を書いたファイルは.env.1passwordのように別名にし、op run --env-file=.env.1password -- php artisan migrateのように起動経路を決めておくと事故が減ります。
シェルプラグインでAWS CLIやghの認証を1Password経由に切り替える設定
アプリの秘密情報とは別に、AWS CLIやGitHub CLIの認証情報も端末に平文で残りがちです。シェルプラグインは、これらのCLIが認証情報を使うときに1Passwordから渡し、Touch IDなどで承認させる仕組みです。公式のセキュリティ解説によると、承認するとそのターミナルのウィンドウやタブとの間にセッションが張られ、セッション中は追加の承認なしで使えます。
AWS CLIの長期キーを~/.aws/credentialsから外すプラグイン設定
AWS CLI用プラグインの手順は、Mac版かLinux版の1Passwordアプリと、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など端末上の写しを消すよう求めています。消し忘れると、プラグインを通らない経路で古いキーが使われ続けます。同じページにはMFAと複数ロールの設定手順もあります。長期キー自体を減らしたい場合は、AWS側のSSOやOIDCへの移行が先です。
2.41.1で対応する90コマンドとclaude・codex・ghの例
2.41.1でop plugin listを実行すると、90のコマンドが並びました。AWSはawsのほかにcdk・sam・eksctlも対象で、gh（GitHub）、psql・pg_dump（PostgreSQL）、mysql、stripeのほか、claude（Anthropic）とcodex（OpenAI）も含まれます。
$ op plugin list
EXECUTABLE NAME REQUIRED FIELDS
akamai Akamai Client Secret, Host, Access Token, Client Token
claude Anthropic API Key
argocd Argo CD Auth Token
aws AWS Access Key ID, Secret Access Key
...
Bash・Zsh・fish限定でPowerShellは対象外となる制約への対処
シェルプラグインが動くのはBash・Zsh・fishの3つです。CLI本体はWindowsのPowerShellで使えますが、プラグインは使えません。Windowsではop run -- aws ...の形で環境変数として渡すのが確実です。AWS用プラグインの要件はMac版かLinux版の1Passwordアプリとの連携なので、WSLのBashを使うだけでは条件を満たしません。チームにWindowsとmacOSが混在しているなら、手順書はop runで統一したほうが問い合わせが減ります。
GitHub ActionsなどCI/CDからサービスアカウントで秘密情報を読む実装
CIは生体認証のダイアログに応答できない非対話の環境で、個人のアカウントに依存させると退職や権限変更で止まります。サービスアカウントは、個人に紐付かず、指定した保管庫だけに権限を持つ機械用のアカウントで、最大100個まで作れます。
OP_SERVICE_ACCOUNT_TOKENの設定と読めない保管庫
サービスアカウントとCLIの併用手順のとおり、環境変数OP_SERVICE_ACCOUNT_TOKENにトークンを入れるだけで認証されます。トークンは作成時に1回しか表示されないので、その場でCI側のシークレットへ登録してください。
$ export OP_SERVICE_ACCOUNT_TOKEN="<作成時に1回だけ表示されたトークン>" # CI のシークレットから渡す
$ op user get --me # Type: SERVICE_ACCOUNT と出れば認証できている
$ op run --env-file="./.env.ci" -- npm test
サービスアカウントの作成手順には、CLI 2.18.0以降が必要なことと、組み込みのPersonal・Private・Employeeの保管庫と既定のShared保管庫には権限を付けられないことが書かれています。CIで使う値は、CI用に新しく作った保管庫へ移しておきます。OP_CONNECT_HOSTとOP_CONNECT_TOKENが設定されていると、1Password Connectの設定がOP_SERVICE_ACCOUNT_TOKENより優先されます。
load-secrets-action v5でワークフローに秘密情報を渡すYAML例
GitHub Actionsでは、公式のload-secrets-actionがCLIの導入まで行います。最新は2026年8月18日のv5.0.1です。action.ymlではexport-envの既定がfalseなので、後続のステップで環境変数として読むならtrueを指定します。
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 が環境変数として読める
ほかのジョブに値が漏れない書き方やOIDCへの移行判断はGitHub ActionsのSecrets管理｜置き場所の選定と漏えい経路・OIDC移行の判断、読み込んだ値をステップ間で受け渡す方法はGitHub Actionsの環境変数｜env・vars・secretsの使い分けと受け渡しで整理しています。
レート制限と名前指定・ID指定で変わるリクエスト数
レート制限の公式ページの値は次のとおりです。1時間の枠はトークンごと、1日の枠はアカウント内の全サービスアカウントの合算です。
| プラン | 1時間（トークンごと） | 1日（アカウント合算） |
|---|---|---|
| 1Password・Families | 読み1,000／書き100 | 読み書き1,000 |
| Teams | 読み1,000／書き100 | 読み書き5,000 |
| Business | 読み10,000／書き1,000 | 読み書き50,000 |
公式の表では、op readとop item getは名前で指定すると3回の読み取りになり、保管庫とアイテムをIDで指定すると1回に減ります。Connectのモックで通信を数えても同じで、op://development/postgres/passwordは保管庫の検索・アイテムの検索・本体の取得の3回、IDで書いた参照は1回でした。参照を2つ書いた.envをop runに渡すと、6回の通信が出ました（op runはサービスアカウントの公式表に載っていないので、回数はConnectでの値です）。
# 名前で指定（保管庫の検索 → アイテムの検索 → 取得）
DB_PASSWORD="op://app-cicd/postgres/password"
# ID で指定（取得のみ）。ID はデスクトップアプリの「シークレット参照をコピー」の
# 形式設定か op item get の出力で確かめる
DB_PASSWORD="op://<保管庫ID>/<アイテムID>/password"
Teamsで、1回のジョブが名前指定のop readを10回実行すると30リクエストです。166ジョブで4,980回になり、167ジョブ目の途中で1日5,000回を超えます。IDで指定すれば1ジョブ10リクエストで、500ジョブで上限に達します。残量はop service-account ratelimitで確かめられるので、ジョブの冒頭に入れておくと、上限で落ちたときの切り分けが速くなります。
1Password CLI・Vault・Secrets Managerの用途別採用基準
開発者の手元と小規模CIで平文を消す目的なら1Password CLIで足りる条件
社員がすでに1Passwordを使っていて、平文の.envやチャットでのキー共有をやめたく、CIが発生させるリクエスト数がTeamsの上限（トークンごとに1時間の読み取り1,000回、アカウント全体で1日5,000回）に余裕を持って収まるなら、1Password CLIを採用してください。新しいサーバーを立てずに、既存の保管庫と権限管理をそのまま使えます。暗号化した.envをGitで共有する方式と比べたい場合はdotenvxとは｜.envを暗号化してGitで安全に管理する仕組み・使い方・移行手順が参考になります。
保管庫の分け方を決める前に、社内のパスワード運用ルールをパスワード管理のベストプラクティス：NIST SP 800-63B-4の要件と総務省・NISCの推奨、企業ポリシーの決め方で確認しておくと、CI用と個人用の境界を引きやすくなります。.envの置き換えからCIのシークレット移行、パイプライン全体の整理までを進めたい場合は、DevOps・CI/CD導入支援として設計から実装まで引き受けています。
本番アプリの実行時取得や動的シークレットが要るなら採用しない理由
本番のアプリケーションが起動時や実行中に秘密情報を取りに行く構成では、サービスアカウント認証の1Password CLIを使いません。サービスアカウントの枠はBusinessでもアカウント全体で1日50,000リクエストで、コンテナの起動数に比例して消費されます。公式の比較では、自社で運用するConnectサーバーはデータを手元にキャッシュするため、最初の取得後は回数の制限なく読み直せるとされています。1Passwordで本番まで寄せるならConnectを、IAMロールと結び付いたアクセス制御や自動ローテーションが要るならクラウドのサービスを検討します。
AWS上のシステムならAWS Secrets Managerとは？料金・ローテーション設定と採用判断を実装者目線で解説【2026年版】、DB認証情報を都度発行する動的シークレットが要るならHashiCorp Vaultとは？シークレット管理の仕組み・動的シークレット・Kubernetes連携と採用判断を実装者目線で解説が候補です。避けたいのは、手元で便利だったop runをサービスアカウント認証のまま本番のコンテナ起動に持ち込み、リクエスト数を見積もらずにデプロイが集中した日に上限へ達して起動が止まる構成です。
よくある質問
1Password CLIは無料で使えますか？
CLI自体は無料でダウンロードできますが、読み出す先の1Passwordアカウントは有料プランの契約が前提です。個人プランでもop runやop readは使えます。サービスアカウントの1日の読み書き上限は、個人・Familiesが1,000回、Teamsが5,000回、Businessが50,000回なので、CIのジョブ数でプランを選んでください。
Windowsでも1Password CLIは使えますか？
使えます。wingetで導入でき、Windows Helloでの認証、op run・op read・op injectはPowerShellで動きます。使えないのはシェルプラグインで、対応はBash・Zsh・fishです。PowerShell中心のチームはop runで環境変数として渡す手順に統一してください。
op get itemやop listが動かないのはなぜですか？
CLI 1系の書式だからです。2系は「対象→動作」の順で、op item get・op item list・op vault listのように書きます。古いスクリプトや記事のコマンドは、2系の書式に置き換えてください。
サービスアカウントのトークンが漏れたらどうすればよいですか？
サービスアカウントの管理手順に沿って、1Password.comの「Developer」から対象のサービスアカウントを開き、「Revoke Token」で猶予を残さず失効させ、新しいトークンで処理を立て直します。旧トークンの有効期限を決めて差し替える「Rotate Token」は、漏えいしていない通常の更新で使う機能です。調べる範囲は、そのサービスアカウントに付与した保管庫とEnvironments、それぞれの権限です。保管庫に入っていたクラウドのキーなどは外部のサービス側でも失効・再発行してください。
1Password CLIとHashiCorp Vaultはどちらを選べばよいですか？
開発者の手元と小規模なCIで平文をなくす目的なら1Password CLIで足ります。本番アプリが実行時に大量に取りに行く、DB認証情報を都度発行したい、シークレットの基盤を自社で持つ必要がある場合はVaultを選びます。人が扱う値は1Password、本番システムの値はVaultやクラウドのシークレット管理、と分けて併用する構成もとれます。
