1Password Secrets Automation 入門と CI 連携実践 2026 - Service Account・Connect・MCP の使い分け

1Password Secrets Automation は、API キーやデータベース認証情報を CI/CD やアプリ実行環境に「実値ではなく参照で渡す」ためのプラットフォームです。Service Account・Connect Server・op CLI・(2026 年新登場の) MCP サーバの 4 つを使い分けると、GitHub リポジトリ Secret に頼らない安全な配布が組めます。本記事は実装目線で全体像と使い分け基準を整理します。

Secrets Automation とは何を解決する仕組みか

Secrets Automation は、1Password Vault に保管したシークレットを、人間が画面でコピー&ペーストすることなく、CI/CD・サーバ・スクリプトへ自動配布する 1Password の上位機能群です。コア要素は次の 4 つ。

4 つの構成要素

• Service Account: API 経由で Vault にアクセスする専用アカウント。トークン 1 本で 1 つ以上の Vault を read/write¹
• Connect Server: Docker / Kubernetes で自己ホストする API サーバ。社内ネットワーク内から Vault に問い合わせ可能²
• op CLI / op inject: ローカル開発と一部 CI で利用するコマンドラインツール。テンプレートに op://vault/item/field を書くと展開³
• MCP サーバ (2026 新規): AI コーディングエージェント (Codex 等) 向けの参照解決レイヤ⁴

リポジトリ Secret と何が違うか

GitHub Actions のリポジトリ Secret や Vercel の環境変数に API キーを直接貼ると、3 つの構造的な問題が残ります。

1. 発行者の手元から離れた瞬間に追跡困難: 誰が見たか、いつコピーされたかが残らない
2. ローテーション漏れ: 退職者・退任管理者の権限取り消しが手作業に依存
3. 個別 CI ごとに同じ値を貼り直す: 環境数 × プロジェクト数で更新作業が膨らむ

Secrets Automation 側に一元化すると、Vault 内アイテムを更新するだけで全 CI ジョブに反映され、Service Account のアクセスログから「いつ・どのジョブが・どのシークレットを参照したか」が監査できます。

Service Account / Connect / op CLI の使い分け

3 つの主要な配布経路は適用範囲が違います。「迷ったら Service Account」が 2026 年現在のデフォルト判断です。

Service Account: GitHub Actions / Vercel 等の SaaS CI に最適

GitHub Actions・CircleCI・Vercel Build・Cloudflare Workers Builds のように SaaS 側で動くランナーから 1Password Vault に到達したい場合、Service Account + 公式 1password/load-secrets-action が最短ルートです¹。ワークフロー側はこう書きます (GitHub Actions):

- uses: 1password/load-secrets-action@v2
  env:
    OP_SERVICE_ACCOUNT_TOKEN: ${{ secrets.OP_SERVICE_ACCOUNT_TOKEN }}
    OPENAI_API_KEY: "op://Production/OpenAI/api-key"
    DATABASE_URL: "op://Production/Postgres/connection_string"
- run: npm run deploy

op://Vault名/Item名/フィールド名 形式の参照を env: に書くだけで、Action 実行時に実値へ自動解決されます。リポジトリ Secret として保持するのは OP_SERVICE_ACCOUNT_TOKEN ただ 1 つ。

Connect Server: 自己ホスト・閉域・大量並列向け

オンプレや閉域網からアクセスする、または 1 日数万リクエスト規模で Service Account のレート制限が読めない場合は、自己ホスト型の Connect Server を構築します²。Docker Compose または Helm Chart 公式テンプレートで op-connect-api と op-connect-sync の 2 コンテナを内部ネットワークに立てる構成が標準。load-secrets-action の connect-host 入力を内部 URL に向けると、Action は自前 Connect 経由で Vault に問い合わせます。

op CLI: ローカル開発とスクリプト向け

op CLI はローカル開発・ワンショットのスクリプト・CI の一部段階で活躍します³。代表的なパターン:

# テンプレート展開: env.tpl の op:// 参照を解決して .env を出力
op inject -i .env.tpl -o .env

# 単一値の取得: シェル変数に展開
export OPENAI_API_KEY=$(op read "op://Dev/OpenAI/api-key")

# Service Account で実行 (CI でもローカルと同じ手順)
export OP_SERVICE_ACCOUNT_TOKEN=ops_xxxxxxxxxxxx
op run -- node scripts/migrate.ts

op run は子プロセスに env を継承しつつ、終了時に環境変数を破棄する設計で、シェル履歴に実値を残しません。SSH キー管理を同じツールチェインで揃えるパターンは 1Password で SSH キー管理を一元化する 2026 で詳説しています。

「[訳] 1Password が OpenAI Codex 向け Environments MCP サーバを発表。シークレットはプロンプト・コード・コンテキストウィンドウに入らず、エージェントは参照のまま推論し、実行時にだけ解決する仕組み」(1Password Build 公式)

GitHub Actions に Service Account を導入する 7 ステップ

実装の最小構成を 7 ステップに分解します。所要時間は初回 30〜45 分です。

1. Vault を環境別に作成: Production / Staging / Dev の 3 つを推奨
2. Service Account を作成: 1Password 管理コンソール → Service Accounts → New。アクセス Vault と read / read+write 権限を指定
3. トークンを GitHub リポジトリ Secret に登録: OP_SERVICE_ACCOUNT_TOKEN 名で保存
4. ワークフロー YAML を編集: 1password/load-secrets-action@v2 を - uses: で呼び出し、env: に op:// 参照を書く
5. dry-run でログ流出をチェック: set -x を OFF にし、直接 echo "$DATABASE_URL" のような露出があれば修正
6. 監査ログを ON: 管理コンソール → Activity Log で Service Account リクエストが記録されているか確認
7. トークン有効期限を 90 日に設定: 自動失効 + Slack 通知でローテーション漏れを防ぐ

「[訳] シークレットが一度 LLM のコンテキストウィンドウに入れば、それはログに残り、再生成され、最終的に漏れる。1Password は実値を AI の世界に持ち込ませない設計を取ったが、これが正しいアーキテクチャ修正だ」(@buildwithhassan)

チーム導入で押さえる運用設計

Secrets Automation はチーム展開でこそ真価が出ます。中規模以上の組織が SSO・SCIM プロビジョニング・Okta / Azure AD 連携と組み合わせるなら 1Password Business プランが現実解です。

推奨ガバナンス設定

• 環境別の分離: Vault と Service Account を production / staging / dev で 3 セット
• 最小権限化: read のみで足りるジョブには write を渡さない
• トークン有効期限の標準値: 90 日 (長くて 180 日)
• 退職者対応: 退職通知から 1 営業日以内に Service Account を Revoke
• 監査ログ四半期レビュー: 直近 30 日アクセスのない Service Account を棚卸し

弊社では LLM プロバイダ API キーや SaaS 認証情報を 1Password Secrets Automation に集約し、AI 受託開発・データ基盤構築のクライアント案件で運用ノウハウを蓄積しています。組織規模別の単価試算は 1Password Business プラン徹底比較 2026 で 5・20・50・150 名のケースを整理しています。

2026 年新トピック: Codex 向け MCP サーバ統合

2026 年 5 月、1Password は OpenAI Codex などの AI コーディングエージェント向けに Environments MCP サーバを公開しました⁴。

何が新しいのか

従来の Secrets Automation は「アプリが実値を必要とするタイミングで Vault から取得する」前提でした。AI コーディングエージェントは挙動が異なり、環境変数を含む文脈をプロンプトに入れて推論する流れのため、シークレットがプロンプト → モデル出力 → ログに残るリスクがあります。

MCP サーバ統合では、エージェントは op:// 参照のままタスクを推論し、コマンド実行直前にだけ Connect / Service Account 経由で実値が解決されます。プロンプト・モデル出力・ログには実値が一切残りません。AI エージェント主導コーディングを業務利用する組織にとって、コンテキスト汚染を防ぐ現実的な標準解です。

「[訳] 1Password の MCP サーバは素晴らしい。Codex は今でも環境構築や prod/staging の比較、設定検証を実行できるが、シークレットがコンテキストに入ることはない。.env 直書きの運用に対する大きなアップグレード」(@Lovanaut)

まとめ: 1Password を「秘密情報の信頼ソース」に据える

1Password Secrets Automation は、GitHub Actions・Vercel・サーバ・AI エージェントといった分散した実行環境に対し、「Vault を唯一の信頼ソース」にしてシークレットを配布する仕組みです。

• 迷ったら Service Account + load-secrets-action
• 自己ホスト要件があれば Connect Server を別途構築
• ローカル開発は op CLI で揃える
• AI エージェントを使うなら 2026 年新登場の MCP サーバを評価

リポジトリ Secret 直貼りからの脱却は、初期工数 30〜45 分で年間数十時間の運用工数削減と、退職者起因のインシデント耐性向上を同時に得られる投資効率の高い改善です。

※情報は 2026-05-24 時点の内容です。最新情報は公式サイトをご確認ください。

※本記事には PR を含みます。