1Password op CLIでシークレットを一元管理する開発フロー｜APIキーを探す前に引く

開発をしていると、APIキーやトークンが必要になる場面が次々と出てくる。GA4、広告API、各種SaaS。そのたびに「あのキーどこだっけ」と探し回り、見つからなければ「再発行してください」と頼む。これを毎回やっていると、地味に時間を食う。

しかもAPIキーを .env にベタ書きしたり、チャットで共有したりするのは、セキュリティ的に最悪の運用です。

この記事で扱うのは、1Password CLI（op）でシークレットを一元管理する開発フロー。「キーを探す前に、まず1Passwordを引く」を習慣にすると、探す時間も漏洩リスクも消えていきます。

補足: 用語を1行で

• op CLI ＝ 1Passwordの保管庫をターミナルから引く道具。GUIを開かずにコマンドで値を取り出せる
• vault ＝ 1Password内のアイテムを分類する保管庫の単位。開発用・個人用などで分けられる
• op:// 参照 ＝ 実値の代わりに「どの保管庫のどのアイテムのどの欄か」だけを書く住所表記

結論：シークレットは1Passwordに集約し、opコマンドで引く

最初に要点を置いておきます。

• APIキー・トークン・認証情報はすべて1Passwordに集約する
• コードや.envに直書きせず、op コマンドで実行時に取得する
• キーが必要になったら、grepや記憶に頼らず、まず op item list で1Passwordを引く
• .env には実値ではなく op:// 参照を書く

「キーがどこにあるか」を探すのではなく、「1Passwordにあるはず」を前提に最初から op で引く。これだけで運用が変わります。

なぜ「まず1Passwordを引く」のか

シークレット管理で一番もったいないのは、1Passwordに入っているのに、grepや記憶で探して見つからず、結局「再発行してください」と頼んでしまうパターンだ。値はそこにあるのに、二重発行で管理対象が増える。

実話：ある開発セッションで、外部サービスのトークンも広告APIのトークンも、すべて1Passwordに入っていた。それなのに確認を怠り、「発行してください」と依頼してしまったことが1セッションで何度かありました。あとから引いたら全部あった。

教訓ははっきりしています。APIキーが必要になったら、grepより先に op item list を実行する。これを最初の一手に固定するだけで、探す時間も依頼の手間も消えるわけです。

opコマンドの基本フロー

Step 1: vault（保管庫）を一覧する

op vault list

1Passwordは「vault」という単位でアイテムを分けている。開発系のキーは専用vault（例: Dev-Secrets）に集約しておくと探しやすい。

Step 2: アイテムを探す

# vault内の全アイテムを一覧
op item list --vault=Dev-Secrets

# キーワードで絞り込み
op item list --vault=Dev-Secrets | grep -i "ads"

Step 3: フィールド構造を確認する

アイテムのどの欄に値が入っているかを確認します。

op item get "Sample Ads API" --vault=Dev-Secrets --format=json | python3 -c "
import json, sys
d = json.load(sys.stdin)
for f in d.get('fields', []):
    print(f.get('label'), '=', (f.get('value') or '')[:40])
"

Step 4: 値を取得する

op read "op://Dev-Secrets/Sample Ads API/credential"

op://vault/item/field の形式で、特定の欄の値だけを取り出せる。住所を指定して中身を引くイメージです。

実行時にだけ取得する（直書きしない）

シークレット管理の肝は、値をコードや.envに直書きしないこと。代わりに実行時に op で取得します。

パターン1: 環境変数に注入して実行

export OPENAI_API_KEY=$(op read "op://Dev-Secrets/OpenAI/credential")
python my_script.py

このやり方なら、実値はシェルのプロセス内にしか存在せず、ファイルには一切残らない。

パターン2: .env に op:// 参照を書く

.env には実値ではなく、参照だけを書きます。

# .env（これ自体はコミットしても安全。実値は入っていない）
OPENAI_API_KEY=op://Dev-Secrets/OpenAI/credential
ADS_TOKEN=op://Dev-Secrets/Sample Ads API/credential

op run -- your-command で実行すると、op:// 参照が実値に解決されて環境変数に注入される。.env をうっかりコミットしても、中身は住所表記なので実値は漏れない。.env ファイルの設計をもう少し踏み込んで知りたい人は、1Passwordとopxで.envを安全に管理する方法も合わせて読んでほしい。

パターン3: Secret Managerに移送

クラウドで動かすなら、1Passwordから取得した値をクラウドのSecret Managerに登録します。

op read "op://Dev-Secrets/API Key/credential" | \
  gcloud secrets create my-api-key --data-file=-

ローカル開発は1Password、本番はSecret Manager、という使い分けになる。

チームでの運用

チームで使う場合、1Passwordのvaultをメンバーで共有すれば、全員が同じ参照（op://...）でアクセスできる。個人ごとにキーを配り直す手間が要らなくなります。

• 新メンバー：vaultに招待されれば、すぐ全シークレットにアクセスできる
• キーのローテーション：1Password側で値を更新すれば、全員に即反映
• 退職者対応：vaultアクセスを外せば、その人だけアクセス不可になる

チャットでキーを共有して、ローテーションのたびに全員へ再通知、という運用から解放される。

持ち帰り：シーン別「どのコマンドを打つか」早見表

迷ったときに上から順に当てはめれば、grepや記憶に頼らずに済むはずです。

アンチパターン3つ

アンチパターン1: APIキーをgrepや記憶で探す

「あのキーどこだっけ」とコードベースをgrepするより、まず op item list。1Passwordにあるはず、を前提に動く。

アンチパターン2: .env に実値を直書きする

.env に実値を書くと、うっかりコミットで漏洩する。op:// 参照を書き、op run で解決すれば実値はファイルに残らない。

アンチパターン3: 見つからないとすぐ「再発行依頼」する

再発行する前に、必ず1Passwordを確認する。たいてい既にあるので、再発行は二重管理の元になる。

まとめ：「探す」より「引く」

シークレットを安全かつ手早く管理するフローは、次の4点に集約されます。

1. APIキーは全部1Passwordに集約する
2. 必要になったら、grepより先に op item list で引く
3. コードや.envに直書きせず、op で実行時取得する（.envにはop://参照）
4. チームではvault共有で、招待・ローテーション・退職対応を一元化

「キーがどこにあるか探す」のは時間の無駄で、見つからずに直書きするのは漏洩リスク。1Passwordを一次情報源にして op コマンドで引くフローに統一すれば、探す時間も漏洩リスクも消えていく。

開発環境・シークレット管理でお困りなら

APIキーがあちこちに散らばっている、.envが誰の手元で何が正なのか分からない、退職者が触れていた認証情報の棚卸しができていない。こうした状態は、ツールではなくフローの問題で、設計を整えれば解消できます。

f2t.jpでは、開発環境の整備から安全なシークレット管理フローの設計まで一貫してお手伝いしています。お問い合わせフォームからご相談ください。