---
title: "1Password CLIの使い方：op run・op read・op injectで.envの平文をなくす手順とCIのサービスアカウント運用"
url: "https://www.issoh.co.jp/tech/details/17930/"
published: 2026-09-29
updated: 2026-10-27
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# 1Password CLIの使い方：op run・op read・op injectで.envの平文をなくす手順とCIのサービスアカウント運用

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系の版確認

[公式の導入手順](https://www.1password.dev/cli/get-started)は、macOSはHomebrew、Windowsはwinget、Debian系LinuxはAPTリポジトリの追加を案内しています。[リリースノート](https://releases.1password.com/developers/cli/)の最新は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の指定

[シークレット参照の公式ページ](https://www.1password.dev/cli/secret-references)による書式は`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のリファレンス](https://www.1password.dev/cli/reference/commands/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エージェントにパスワードを渡さない仕組みと実装判断](/tech/details/18850/)で扱っています。

### op injectによるテンプレートからの設定ファイル生成と削除

環境変数を読まないツールには、[設定ファイルへの注入](https://www.1password.dev/cli/secrets-config-files)を使います。テンプレートの値を参照に置き換えておき、`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](https://www.1password.dev/sdks)が挙げる言語は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の認証情報も端末に平文で残りがちです。[シェルプラグイン](https://www.1password.dev/cli/shell-plugins)は、これらのCLIが認証情報を使うときに1Passwordから渡し、Touch IDなどで承認させる仕組みです。[公式のセキュリティ解説](https://www.1password.dev/cli/shell-plugins/security)によると、承認するとそのターミナルのウィンドウやタブとの間にセッションが張られ、セッション中は追加の承認なしで使えます。

### AWS CLIの長期キーを\~/.aws/credentialsから外すプラグイン設定

[AWS CLI用プラグインの手順](https://www.1password.dev/cli/shell-plugins/aws)は、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は生体認証のダイアログに応答できない非対話の環境で、個人のアカウントに依存させると退職や権限変更で止まります。[サービスアカウント](https://www.1password.dev/service-accounts)は、個人に紐付かず、指定した保管庫だけに権限を持つ機械用のアカウントで、最大100個まで作れます。

### OP\_SERVICE\_ACCOUNT\_TOKENの設定と読めない保管庫

[サービスアカウントとCLIの併用手順](https://www.1password.dev/service-accounts/use-with-1password-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
```

[サービスアカウントの作成手順](https://www.1password.dev/service-accounts/get-started)には、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](https://github.com/1Password/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移行の判断](/tech/details/16939/)、読み込んだ値をステップ間で受け渡す方法は[GitHub Actionsの環境変数｜env・vars・secretsの使い分けと受け渡し](/tech/details/16921/)で整理しています。

### レート制限と名前指定・ID指定で変わるリクエスト数

[レート制限の公式ページ](https://www.1password.dev/service-accounts/rate-limits)の値は次のとおりです。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で安全に管理する仕組み・使い方・移行手順](/tech/details/12633/)が参考になります。

保管庫の分け方を決める前に、社内のパスワード運用ルールを[パスワード管理のベストプラクティス：NIST SP 800-63B-4の要件と総務省・NISCの推奨、企業ポリシーの決め方](/column/details/13508/)で確認しておくと、CI用と個人用の境界を引きやすくなります。`.env`の置き換えからCIのシークレット移行、パイプライン全体の整理までを進めたい場合は、[DevOps・CI/CD導入支援](https://www.issoh.co.jp/service/system/devops/)として設計から実装まで引き受けています。

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

本番のアプリケーションが起動時や実行中に秘密情報を取りに行く構成では、サービスアカウント認証の1Password CLIを使いません。サービスアカウントの枠はBusinessでもアカウント全体で1日50,000リクエストで、コンテナの起動数に比例して消費されます。[公式の比較](https://www.1password.dev/secrets-automation)では、自社で運用するConnectサーバーはデータを手元にキャッシュするため、最初の取得後は回数の制限なく読み直せるとされています。1Passwordで本番まで寄せるならConnectを、IAMロールと結び付いたアクセス制御や自動ローテーションが要るならクラウドのサービスを検討します。

AWS上のシステムなら[AWS Secrets Managerとは？料金・ローテーション設定と採用判断を実装者目線で解説【2026年版】](/tech/details/15888/)、DB認証情報を都度発行する動的シークレットが要るなら[HashiCorp Vaultとは？シークレット管理の仕組み・動的シークレット・Kubernetes連携と採用判断を実装者目線で解説](/tech/details/15580/)が候補です。避けたいのは、手元で便利だった`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系の書式に置き換えてください。

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

[サービスアカウントの管理手順](https://www.1password.dev/service-accounts/manage-service-accounts)に沿って、1Password.comの「Developer」から対象のサービスアカウントを開き、「Revoke Token」で猶予を残さず失効させ、新しいトークンで処理を立て直します。旧トークンの有効期限を決めて差し替える「Rotate Token」は、漏えいしていない通常の更新で使う機能です。調べる範囲は、そのサービスアカウントに付与した保管庫とEnvironments、それぞれの権限です。保管庫に入っていたクラウドのキーなどは外部のサービス側でも失効・再発行してください。

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

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

## 関連記事

- [1Password for Agentsとは：AIエージェントにパスワードを渡さない仕組みと実装判断](/tech/details/18850/)
- [GitHub ActionsのSecrets管理｜置き場所の選定と漏えい経路・OIDC移行の判断](/tech/details/16939/)
- [HashiCorp Vaultとは？シークレット管理の仕組み・動的シークレット・Kubernetes連携と採用判断を実装者目線で解説](/tech/details/15580/)
- [AWS Secrets Managerとは？料金・ローテーション設定と採用判断を実装者目線で解説【2026年版】](/tech/details/15888/)
- [dotenvxとは｜.envを暗号化してGitで安全に管理する仕組み・使い方・移行手順](/tech/details/12633/)

---

出典: [1Password CLIの使い方：op run・op read・op injectで.envの平文をなくす手順とCIのサービスアカウント運用](<https://www.issoh.co.jp/tech/details/17930/>)（株式会社一創）
