「AI エージェントに API キーを渡す」という、これまで現場で雑に行われてきた作業が 2026 年に大きく問われています。HashiCorp Vault 2.0 が IBM ライフサイクル下で初のメジャー更新となり、特に Identity Federation 機能がエージェント時代の鍵を握る存在になりました。
これまで Vault は「人間と機械（サービスアカウント）」の二分法で設計されていました。しかし AI エージェントは 人とサービスの中間 に位置し、「動的に生まれて消える ID」という特殊な性格を持ちます。Vault 2.0 + Identity Federation はこの新しい第三の存在を 1 級市民として扱う設計です。本記事では、これを起点とした受託案件の標準アーキテクチャを整理します。
なぜ「シークレット管理 × エージェント」が新テーマなのか
エージェント案件で繰り返し起きる典型的な事故を整理します。
| ありがちな実装 | 起きる問題 |
|---|---|
.env に API キーを直書きしてエージェントに読ませる | 漏洩したら全権限が露出 |
| エージェント単位に永続トークンを払い出す | 退職・退役時に剥がし忘れる |
| 全エージェントに共通サービスアカウント | 監査で「誰がやったか」追えない |
| 環境変数経由で渡す | プロセスダンプ / ログから抜かれる |
Vault 2.0 + Identity Federation は、これらに対し 「エージェントを Vault のネイティブ ID として扱う」 という根本解を提供します。
OpenAI Privacy Filter & Trusted Access for Cyber — エンタープライズの「AI ガバナンス」受託設計指針 2026 で書いた AI ガバナンスと相補的に、「実行時の権限・シークレット」 の側を Vault が担う構図です。
アーキテクチャ全体像
弊社が標準として提案する Vault 2.0 中心の構成は次の 4 層です。
- Identity Plane：IdP（Okta / Azure AD）+ Vault Identity Federation で人 + エージェントの統一 ID
- Secret Plane：DB / API / SaaS の認証情報を 動的・短命 に発行
- Policy Plane：HCL ポリシーで「ID × 用途 × 環境」の三軸統制
- Audit Plane：すべての発行 / 利用 / 失効を SIEM に集約
ポイントは、エージェントが 「Vault に問い合わせて、その瞬間だけ使えるトークン」を取得する設計です。漏洩しても寿命が短く、失効も即時に効きます。
受託案件で頻出する 3 シナリオ
シナリオ A：開発エージェントの本番 DB アクセス
「開発エージェントが本番 DB の読み取りを行うが、書き込みは一切させない」案件。Vault の Database Secrets Engine を使い、毎回エージェント専用の短命ユーザーを発行します。
- 期間：2〜3 ヶ月
- 効果：永続パスワード廃止、ローテーション工数ゼロ化
- 注意：DB 側の最大コネクション数を Vault の発行ペースで超えないように設計
シナリオ B：マルチテナント SaaS のテナント別シークレット
「SaaS のエンドユーザーごとに、自分のテナントの API キーだけ使えるエージェント」を組む案件。Vault の Namespaces + Identity Group で、テナント境界を Vault の ID 体系に直接落とし込みます。
エンジニアリング工数 90% 削減 — 社内開発エージェント基盤の構築ステップ 2026（Spotify 事例から） で書いた内製化基盤に、シークレット管理層として Vault を据える構成です。
シナリオ C：オンプレ + クラウド + SaaS の横断シークレット管理
「オンプレの基幹 DB / クラウドの SaaS / 各種 API キーを Vault に集約し、人とエージェントの両方に統制を効かせる」案件。Identity Federation で IdP のグループ変更が即座に Vault 権限に反映されます。
# vault-policy.hcl の例
path "database/creds/orders-readonly" {
capabilities = ["read"]
allowed_parameters = {
ttl = ["1h"]
}
}
# エージェント ID 専用のポリシー
path "secret/data/agents/customer-support/*" {
capabilities = ["read"]
required_parameters = ["agent_run_id"]
}「HCL でポリシーをコード管理」できることで、レビュー・自動テスト・履歴を Git でトラックできます。
移行ステップ（4 フェーズ）
| フェーズ | 期間 | 目的 |
|---|---|---|
| 1. シークレット棚卸し | 3〜4 週間 | 既存の .env / Parameter Store を全部 Vault 候補に整理 |
| 2. パイロット 1 部門 | 4〜6 週間 | 1 アプリ + 1 エージェントを Vault 化 |
| 3. 横展開 + Identity Federation | 2〜3 ヶ月 | IdP 統合 + 動的シークレット拡張 |
| 4. 監査 + ローテーション自動化 | 継続 | SIEM 連携 + ポリシーの定期レビュー |
特にフェーズ 1 で 「シークレットの所有部門」と「利用部門」を分離 できるかが成否を分けます。「全部インフラ部門が握る」状態だと、開発スピードが落ちます。
よく踏む 5 つの落とし穴
1. Vault の可用性設計
Vault が落ちると、エージェントの動作が止まります。HA + Auto Unseal + 複数リージョン を初期から織り込みます。
2. トークン TTL の短すぎ / 長すぎ
短すぎると更新が頻発してパフォーマンス劣化、長すぎると漏洩リスクが上がります。用途別 TTL マトリクス（DB 読み取り 1h / 書き込み 15min / 管理操作 5min など）を最初に決めます。
3. Identity Federation の更新タイミング
退職・異動から Vault への反映までのラグが半日以上あると、現場リスクが残ります。1 時間以内反映を SLO として設計します。
4. アプリ側のリトライ設計
短命トークンは期限切れで失敗するため、アプリ側でのリトライ + 再取得 をライブラリ層で吸収します。
5. 緊急時のバイパス手順
Vault 障害時に「全部止まる」を避けるため、緊急時の限定的なバイパス手順（人間の承認 + 短命固定トークン）を運用設計に含めます。
Cloudflare Mesh で組む「人 × ノード × AI エージェント」プライベートネットワーク受託構築ガイド 2026 で書いたネットワーク統制と組み合わせると、「ネットワーク × ID × シークレット」の三層ガバナンスが成立します。
競合スタックとの棲み分け
| 競合 | Vault 2.0 との関係 |
|---|---|
| AWS Secrets Manager | AWS 中心ならこちらで足りる、マルチクラウドは Vault が圧倒的 |
| Azure Key Vault | Azure 中心ならこちら、横断は Vault |
| GCP Secret Manager | GCP 中心ならこちら、横断は Vault |
| Doppler / Infisical | 開発体験は良いが、エンタープライズの監査要件は Vault に分がある |
弊社の受託案件では、「クラウド標準のシークレットマネージャは残しつつ、横断統制と動的シークレット発行は Vault で集約」 が多くの大企業で現実的なパターンです。
受託案件の単価帯
| 案件の型 | 期間 | 単価帯 | 提供物 |
|---|---|---|---|
| シークレット管理アセスメント | 3〜4 週間 | 100〜220 万円 | 棚卸し + Vault 化計画 |
| パイロット PoC（1 部門 + 1 エージェント） | 6〜8 週間 | 350〜800 万円 | Vault 設計 + 動的シークレット導入 |
| 全社 Vault 基盤構築 | 4〜6 ヶ月 | 1,500〜4,500 万円 | 設計・移行・監査・教育 |
提案書では 「永続パスワード残数 → ゼロ」 を経営層に、「ローテーション工数の削減」 を運用部門にそれぞれ刺さるよう二段構えで書くのが効果的です。
まとめ — シークレットは「持つ」から「借りる」へ
これまでのシークレット管理は「鍵を持って保管する」発想でした。Vault 2.0 + Identity Federation の世界観は、「必要な瞬間に Vault から借りて、すぐ返す」という発想への転換です。AI エージェントが本格化するほど、この借用モデルでないと運用が破綻します。
弊社では、Vault 2.0 のアセスメント、Identity Federation 統合、動的シークレット導入、SIEM 連携、運用設計までをワンストップで提供しています。「.env 直書きをやめたい」「エージェントに本番 DB を安全に触らせたい」というご相談は、お問い合わせフォーム からお声がけください。
