AI エージェント時代のシークレット管理 2026 - 1Password Service Accounts × MCP 実践ガイド

OpenAI Codex や Claude Code が API キーや DB クレデンシャルを欲しがる時代に、.env ファイルを手渡ししているとログ漏洩や誤コミットが頻発します。1Password が 2026 年に強化した Service Accounts + MCP サーバー の組み合わせは、AI エージェントに最小権限で資格情報を渡しつつ、コンテキストウィンドウへの混入を抑える現実解です。本記事では設計の勘所と Codex / Claude Code 連携の実装手順、運用上の落とし穴を弊社の AI 受託開発での経験を交えて整理します。

なぜ AI エージェント時代に従来のシークレット管理が破綻するのか

AI コーディングエージェントは、人間の開発者と違って (a) コンテキストに渡された文字列を要約・引用しやすく、(b) シェルコマンドや Web API を勝手に叩き、(c) チャットログとして長期保存される、という 3 つの厄介な性質を持ちます。

.env ファイル直渡しの 3 つの失敗パターン

1. コンテキスト混入: エージェントが cat .env を実行すると、その出力が LLM のコンテキストに丸ごと載り、後続のメッセージで引用されるリスクがある
2. 誤コミット: .gitignore を整備していても、エージェントが補助ファイルを git add . する流れで巻き込むケースがある
3. 権限境界の崩壊: 1 つの .env に Stripe・Slack・OpenAI のキーをまとめて入れると、エージェントが本来不要なサービスにもアクセスできてしまう

1Password が提唱する Trusted Access Layer は、これらの問題を「資格情報をエージェントの記憶から切り離す」というアーキテクチャで解決しようとしています。具体的には MCP プロトコル経由でランタイム注入し、エージェントの応答や標準出力に値そのものが現れないようにします。

人間用 IAM では非人間 ID を扱いにくい

従来の SSO / SAML / OAuth は「人がブラウザでログインする」前提で設計されているため、ヘッドレスで動くエージェントには相性が悪い。1Password Service Accounts は最初から 非人間 ID (non-human identity) として設計されており、トークン 1 本でスコープ付きアクセスを発行できます。後述の通り CI/CD のシークレット注入には 1Password Secrets Automation の運用設計が参考になり、AI エージェントもその延長線上で扱えます。

1Password は「AI エージェントは Intent (意図) / Identity (主体) / Interaction (やりとり) のすべてが従来の IAM 前提を崩す」として、エージェント時代のアクセス基盤を再設計中であると公式に発信しています。

1Password MCP サーバーと Service Accounts の関係

ここからは技術スタックを 1 枚図で整理します。MCP (Model Context Protocol) は AI クライアントが外部ツールに接続するための共通プロトコルで、1Password はその MCP に準拠したサーバー実装を提供しています。

構成要素のロール分担

op CLI を直接使う方法と比較すると、MCP サーバー方式は「AI ツールが標準化されたインターフェースで credential を取り出せる」「設定ファイルが 1 か所にまとまる」「監査ログが 1Password 側で取得できる」というメリットがあります。

Service Accounts のスコープ設計

Service Account はトークン発行時に アクセスできる Vault と 権限 (read/write) を選びます。実務では以下のように Vault を切り分けるのが効きます。

• Dev-AI-Agents Vault: Codex / Claude Code が読む用。開発環境の API キーのみ
• CI-Production Vault: GitHub Actions / CircleCI が読む用。本番デプロイ用クレデンシャル
• Personal-Tokens Vault: 個人作業用。Service Account からは触れない

1Password Business のグループ機能と組み合わせると、開発チームごとに別 Vault を割り当ててクロスチーム漏洩を防げます。中規模以上の組織で AI エージェントを全社展開する場合、この設計が運用上の生命線になります。

トークンの取り扱いルール

Service Account トークンは「短期間・スコープ最小・ローテーション可能」の 3 原則で扱います。

1. トークンは 90 日ごとにローテーション (1Password 管理画面から再発行 → 古いトークン無効化)
2. トークンを .env に書かない (op CLI または OS のキーチェーンに保管)
3. 監査ログ (1Password Business / Enterprise) で異常アクセスを週次レビュー

Codex / Claude Code との具体的な連携手順

ここからは実際の設定例です。OpenAI Codex 環境と Claude Code 両方で動作確認済みの最小構成を示します。

Codex 環境での設定

OpenAI Codex は環境ごとに MCP サーバーを切り替えられます。設定画面の MCP タブで以下の JSON を入力します。

{
  "mcpServers": {
    "1password": {
      "command": "op",
      "args": ["plugin", "run", "--", "mcp-server"],
      "env": {
        "OP_SERVICE_ACCOUNT_TOKEN": "ops_eyJzaWdu..."
      }
    }
  }
}

トークンは Codex 側で暗号化保存され、エージェント自身は値を直接見ません。リクエスト時には 1password://get/Dev-AI-Agents/openai-api-key のようなリソース URI でアクセスします。

Claude Code での設定

Claude Code はプロジェクトルートに .mcp.json を置く方式です。

{
  "mcpServers": {
    "1password": {
      "command": "op-mcp",
      "args": ["serve"],
      "env": {
        "OP_SERVICE_ACCOUNT_TOKEN": "${OP_SERVICE_ACCOUNT_TOKEN}"
      }
    }
  }
}

ホスト OS の環境変数からトークンを引き継ぐ書き方にすると、リポジトリへのコミット時に値が漏れません。チーム共有する場合は .mcp.json だけコミットし、トークンは各メンバーがローカルで管理します。

Service Account を発行する手順

1. 1Password Business / Enterprise の管理画面にログイン
2. 「Developer Tools」→「Service Accounts」→「Create Service Account」
3. 名前 (例: codex-dev-agent)、有効期限 (90 日推奨)、アクセス可能 Vault を選択
4. トークン (ops_...) を発行 → この画面でしか表示されない ので即座にコピー
5. ローカルマシンの OS キーチェーン (macOS なら Keychain、Linux なら secret-tool) に保存
6. OP_SERVICE_ACCOUNT_TOKEN=$(op read 'op://...' ) のように MCP 起動時に読み込む

「.env をエージェントに読ませる方式から、1Password MCP の Service Account 経由に切り替えると、ログに credential が一切現れなくなる。Codex 環境ごとに別の Service Account を割り当てるのが最低限の運用」と開発者のユーザー @ken5scal が言及しています。

運用上の注意点と落とし穴

MCP + Service Accounts を導入したからといって、すべての漏洩リスクが消えるわけではありません。実運用で踏み抜きやすい地雷を整理しました。

Tool 呼び出し結果のログ問題

MCP は credential を環境変数や stdin 経由でエージェントに渡しますが、エージェントが echo $OPENAI_API_KEY や printenv を実行すると、その標準出力が LLM のコンテキストに戻ってしまいます。

Service Account の権限肥大化

導入初期は「全 Vault に読み取り権限」を付けがちですが、運用 3 か月で「あの Service Account が何を見られるか分からない」状態になります。月次で以下の棚卸しを行うのが定石です。

• 各 Service Account が直近 30 日でアクセスしたアイテム一覧 (監査ログ)
• 不要な Vault 権限の剥奪
• 90 日以上ローテーションされていないトークンの強制更新

AWS Secrets Manager との二重管理

1Password を 1 次ソースにして AWS Secrets Manager に同期する構成は便利ですが、現状の同期は基本一方向 (1Password → AWS) です。AWS 側で直接編集された値は次回同期で上書きされるため、編集ポイントを 1Password に限定するルールを徹底します。

チーム導入で押さえるべきガバナンス設計

10 人を超える開発チームで AI エージェントを使う段階になると、技術的な設定よりもガバナンス設計の方が難しくなります。

SSO / SCIM との接続

1Password Business は Okta / Microsoft Entra / Google Workspace との SSO 接続と SCIM プロビジョニングに対応しているため、入社・退職時の Service Account 払い出しと回収を自動化できます。チームの規模感別の料金は 1Password Business プラン徹底比較 2026 で整理しているので、合わせて参照してください。

Service Account のオーナーシップ

Service Account には「誰がメンテナンスするか」のオーナーを必ず明示します。退職者の個人アカウント名義で作られた Service Account が放置され、退職後に動き続けるのは典型的な事故パターンです。

弊社の AI 受託開発でも、LLM プロバイダ (OpenAI / Anthropic / xAI) の API キーや顧客の SaaS 認証情報を 1Password の Service Accounts で集中管理し、エージェントへの注入を MCP 経由に統一する設計を採用しています。Developer Tools 全般の運用は 1Password で SSH キー管理を一元化する 2026 で関連トピックを掘り下げているので、SSH キー側の整備と合わせて読むと運用設計が立体的になります。

まとめ

AI エージェント時代のシークレット管理は、.env ファイルベースから Service Accounts + MCP サーバー ベースへの移行が現実解になりつつあります。1Password の Trusted Access Layer はその先行例として、Codex / Claude Code / Cursor などの主要 AI ツールと標準プロトコルで繋がる強みがあります。技術的な設定は数十分で終わりますが、Service Account のスコープ設計とローテーション運用、エージェント出力のマスキングまで踏み込まないと真価は発揮されません。Business / Enterprise プランで提供される監査ログと SSO / SCIM を組み合わせ、人と機械の両方をひとつのアクセス基盤に乗せる構えを 2026 年中に整えるのが、AI 開発を本格化する組織の現実的なロードマップです。

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

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