AIエージェント時代に起きている「シークレット管理の混乱」

2025年後半あたりから、企業でのAIエージェント活用が一気に加速しましたよね。GitHub Copilot、Cursor、Anthropic Claude、OpenAIのAPIを使ったカスタムエージェント——エンジニアだけでなく、マーケティングやカスタマーサポートの現場でもAIエージェントが日常的に使われるようになってきています。

で、ここで大きな問題が起きています。

従来、企業のアイデンティティ管理は「人間」を中心に設計されてきました。人事部門や情報システム部門がユーザーIDを管理し、誰がどのアプリケーションやデータにアクセスできるかを統制する。Active DirectoryやOkta、Azure ADといったIdPを中心に、SSO（シングルサインオン）やMFA（多要素認証）を組み合わせて、認証・認可の仕組みを構築してきたわけです。

ところがAIエージェントは、この管理体系の「外」で動いてしまっています。

具体的にどういうことかというと、エンジニアが個人の開発マシンでAIエージェントを動かすとき、そのエージェントに必要なAPIトークンやシークレットを、自分で発行して、自分で管理しているケースがほとんどなんですよね。.envファイルにAPIキーをべた書きして、それをGitの.gitignoreに入れて管理する——正直、心当たりのある方も多いのではないでしょうか。

この状態が何を意味するかというと、

• 企業のセキュリティチームが、社内でどんなAIエージェントが動いているか把握できない
• どのエージェントがどのサービスに対してどんな権限を持っているか分からない
• 退職者のマシンに残ったAPIトークンが有効なまま放置される
• シークレットのローテーションが個人任せになっている

これ、ぶっちゃけかなり怖い状態です。

Ragateでも多くの企業のクラウドインフラやAI導入を支援していますが、「AIエージェントのシークレット管理どうしてますか？」と聞くと、明確なポリシーを持っている企業はまだまだ少ないのが現状です。人間のID管理はきっちりやっているのに、AIエージェントの認証情報は「野良」状態——これがいま、多くの企業で起きている現実です。

1Password Unified Accessとは何か

こうした課題に対して、パスワードマネージャとして世界的に利用されている1Passwordが、2026年3月に「Unified Access」を発表しました。

一言で言うと、人間のアイデンティティ管理とAIエージェントのシークレット管理を、1つのプラットフォームで統一的に管理するという機能です。

1Passwordは現在、18万以上の企業で利用されており、13億以上のシークレットを管理しています。これまでは主に人間向けのパスワード管理・パスキー提供が中心でしたが、Unified Accessによって、AIエージェントやマシンアイデンティティも同じ管理基盤の中に取り込むことになります。

Unified Accessの3つの柱

Unified Accessは大きく3つの機能で構成されています。

これまで「人間用のパスワードマネージャ」と「開発者向けのシークレット管理」は別のツールで管理されることが多かったのですが、Unified Accessはこれを1つのプラットフォームに統合するというアプローチを取っています。

主要なAIプラットフォームとの連携

特に注目すべきは、発表時点で多くの主要AIプラットフォームとの連携が発表されていることです。

AnthropicやOpenAIと直接連携しているのは、かなりインパクトがあります。CursorやGitHubとの統合も、日々の開発ワークフローにシームレスに組み込めるという点で実用性が高いです。

Just-in-Timeアクセスの仕組みと重要性

Unified Accessの中核にあるのが「Just-in-Time（JIT）アクセス」の概念です。これ、地味に見えてめちゃくちゃ重要な機能なので、少し深掘りして解説します。

従来の「常時アクセス」モデルの問題

これまでのAIエージェントの認証モデルは、こんな感じでした。

1. エンジニアがAPIトークンを発行する
2. そのトークンを.envファイルや環境変数にセットする
3. AIエージェントは常にそのトークンを保持して動作する
4. トークンの有効期限は長期間（下手すると無期限）

つまり、AIエージェントは起動している間ずっと、すべての権限を持ち続けている状態です。これは「always-on」アクセスモデルと呼ばれます。

何が問題かというと、

• エージェントが侵害された場合、そのトークンで広範囲にアクセスされる
• トークンが漏洩しても、検知が遅れる
• 必要以上の権限を持ったまま動き続ける

AWSのIAMベストプラクティスでも「最小権限の原則（Principle of Least Privilege）」が繰り返し強調されていますが、AIエージェントの世界では、この原則がほとんど適用されていないのが現実です。

JITアクセスが解決すること

Just-in-Timeアクセスは、このモデルを根本から変えます。

要するに、「AIエージェントにシークレットを渡しっぱなしにしない」というのがJITアクセスの本質です。

これはクラウドネイティブの世界ではすでに馴染みのある考え方ですよね。AWSのSTS（Security Token Service）による一時的な認証情報の発行や、IAM Roles Anywhereによる短期トークンの仕組みと、概念的にはまったく同じです。それを、AIエージェントの世界にも持ち込んだのがUnified Accessと言えます。

AIエージェントセキュリティの具体的リスク

ここからは、もう少し具体的に、AIエージェントのシークレット管理が「野良」状態になっている場合にどんなリスクがあるのか整理してみます。セキュリティに携わっている方には当たり前の話かもしれませんが、意外と見落としがちなポイントもあるので確認していただければと。

.envファイルの漏洩リスク

開発者がローカルマシンに保存する.envファイルは、AIエージェントのシークレット管理における最大のリスクポイントの1つです。

# 典型的な .env ファイルの例
OPENAI_API_KEY=sk-proj-xxxxxxxxxxxxxxxxxxxxx
ANTHROPIC_API_KEY=sk-ant-xxxxxxxxxxxxxxxxxxxxx
GITHUB_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxxx
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
DATABASE_URL=postgresql://user:password@prod-db.example.com:5432/mydb

このファイルが.gitignoreに入っていなくてGitHubにプッシュされてしまうケースは、今でも定期的に発生しています。GitHubのSecret Scanningが検知してくれることもありますが、プライベートリポジトリでは設定次第で検知されないこともあります。

さらに怖いのは、AIエージェント自身がコードを生成する際に、.envファイルの内容をログやコミットメッセージに含めてしまう可能性があることです。AIエージェントは「このトークンは秘密だ」という概念を本質的には理解していません。

長期間有効なAPIトークン

多くのSaaSやクラウドサービスでは、APIトークンの有効期限を「無期限」に設定できてしまいます。一度発行されたトークンが何ヶ月も何年もローテーションされずに使われ続けるのは、セキュリティ上かなりまずい状態です。

SSH鍵の管理問題

SSH鍵もまた、AIエージェント時代に見落としがちなリスクです。開発者のマシンに保存されたSSH秘密鍵は、AIエージェントからもアクセス可能です。エージェントがGitの操作やサーバーへのデプロイを行う際にSSH鍵を使用しますが、その鍵が適切に管理されているかどうかは、多くの場合チェックされていません。

1PasswordのUnified Accessでは、SSH鍵もVaultに格納し、必要な時にだけエージェントに提供する仕組みを提供しています。1PasswordのSSHエージェント機能は以前から存在していましたが、これがAIエージェントにも拡張されるのは大きな前進です。

AWS環境でのシークレット管理との比較・統合

AWS環境でシークレットを扱っている方なら、「AWS Secrets ManagerやParameter Storeがあるのに、なぜ1Passwordが必要なの？」と思うかもしれません。ここは整理しておく必要があります。

AWSネイティブのシークレット管理

AWSには優れたシークレット管理サービスがすでに存在しています。

これらはすべて、AWSリソースへのアクセスを管理するためのものです。Lambda関数がRDSのパスワードを取得したり、ECSタスクがS3バケットにアクセスしたり——AWS内のワークロード間の認証・認可には非常に強力です。

1Password Unified Accessとの住み分け

では、1PasswordのUnified Accessは何が違うのか。

ポイントは、これらは競合ではなく、補完関係にあるということです。

AWS Secrets Managerは「AWSクラウド内のシークレット管理」を担い、1Password Unified Accessは「デバイスからクラウドまでの横断的なシークレット管理」を担います。実際の運用では、1PasswordのVaultにAWSのアクセスキーを格納し、AIエージェントがAWSリソースにアクセスする際にJITで取得する——といった組み合わせが考えられます。

このように、1Password Unified AccessとAWS Secrets Managerを組み合わせることで、デバイスからクラウドまでの一貫したシークレット管理が実現できます。

ゼロトラストアーキテクチャとの関連

1Password Unified Accessの設計思想は、ゼロトラストアーキテクチャの原則と深くリンクしています。

ゼロトラストの基本原則とUnified Access

NIST SP 800-207で定義されているゼロトラストの基本原則を、Unified Accessの文脈で整理してみます。

ゼロトラストアーキテクチャを導入している企業にとって、Unified Accessは「AIエージェントをゼロトラストの管理対象に含める」ための自然な拡張になります。

実装・導入の考え方

とはいえ、いきなり全社導入するのは現実的ではありません。段階的なアプローチが重要です。

フェーズ1：可視化と現状把握

• 社内でどんなAIエージェントが利用されているかの棚卸し
• 開発者のデバイスに存在するシークレットの洗い出し
• .envファイル、SSH鍵、APIトークンの管理状態の確認

フェーズ2：ポリシーの策定

• AIエージェントの利用に関するセキュリティポリシーの策定
• シークレットのローテーション頻度の定義
• どのエージェントにどの権限を付与するかのマッピング

フェーズ3：ツールの導入

• 1Password Unified Access（またはそれに準じるツール）の導入
• 既存のIAMやIdPとの連携設定
• AIエージェントのシークレットをVaultに移行

フェーズ4：運用と改善

• 監査ログのモニタリング体制の構築
• インシデントレスポンス手順にAIエージェント関連を追加
• 定期的なポリシーレビューとアップデート

Ragateでの支援経験からも、「小さく始めて段階的に広げる」というのがセキュリティ施策の導入では一番うまくいくパターンです。まずは開発チームの一部で試行して、課題を洗い出してから全社展開するのが現実的かと思います。

エンジニアが今すぐできること

Unified Accessの導入有無にかかわらず、AIエージェントのシークレット管理について、エンジニアが今日からできることをチェックリスト形式でまとめます。

即時対応チェックリスト

コマンドラインで今すぐ確認

開発マシンに露出したシークレットがないか、簡易的にチェックするコマンドをいくつか紹介します。

# .envファイルの存在を確認（ホームディレクトリ以下）
find ~/ -name '.env' -not -path '*/node_modules/*' -not -path '*/.git/*' 2>/dev/null

# SSH鍵の一覧と権限を確認
ls -la ~/.ssh/

# SSH鍵にパスフレーズが設定されているか確認（設定済みならパスフレーズ入力を求められる）
ssh-keygen -y -f ~/.ssh/id_rsa > /dev/null 2>&1

# Git履歴にシークレットが含まれていないか確認
git log --all --diff-filter=A -- '*.env' '*.pem' '*.key'

# AWS認証情報ファイルの権限を確認
ls -la ~/.aws/credentials 2>/dev/null

これらのコマンドで何か見つかったら、すぐに対処してください。特に.envファイルがGit管理下に入っている場合は、履歴からの完全削除（git filter-branchやBFG Repo-Cleanerの使用）が必要になります。

AWS環境での推奨設定

AWSを使っている場合、以下の設定も確認しておくことをお勧めします。

# IAMアクセスキーの最終使用日を確認
aws iam get-access-key-last-used --access-key-id AKIAIOSFODNN7EXAMPLE

# IAMユーザーのアクセスキー一覧
aws iam list-access-keys --user-name your-username

# 90日以上使用されていないアクセスキーを検出（IAM Credential Report）
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d | \
  awk -F',' '$5 != "N/A" && (systime() - mktime(gensub(/[-T:+]/, " ", "g", $5))) > 7776000 {print $1, $5}'

特に、長期間ローテーションされていないIAMアクセスキーは、真っ先に対処すべきリスクです。AWS Security Hubを有効にしていれば、これらは自動的に検出されてアラートが出ますが、まだ導入していない場合は検討してみてください。

まとめ

1PasswordのUnified Accessは、「人間とAIエージェントのアイデンティティを統一管理する」という、AIエージェント時代に必要不可欠なアプローチを提示しています。

ここまでの内容を振り返ると、

• AIエージェントの普及により、企業のシークレット管理に「管理外の認証情報」が急増している
• 1Password Unified Accessは、人間・エージェント・マシンの認証情報を単一のプラットフォームで管理する
• Just-in-Timeアクセスにより、「常時保持」から「必要な時だけ提供」へとモデルを転換する
• AWS Secrets ManagerやIAMとは競合ではなく補完関係にある
• ゼロトラストアーキテクチャの原則をAIエージェントにも適用する自然な拡張になる

個人的な意見として、この動きは不可逆なトレンドだと思っています。AIエージェントは今後さらに増え、より多くの業務を人間から引き受けるようになります。そのとき、エージェントのアイデンティティ管理が「人間とは別のサイロ」で行われている状態は、セキュリティ上もガバナンス上も持続可能ではありません。

Ragateとしても、AWSを中心としたクラウドインフラの設計・構築を支援する中で、AIエージェントのセキュリティは今後ますます重要なテーマになると考えています。今回の1Password Unified Accessの発表は、そうした課題に対する1つの有力な解答です。

まずは上のチェックリストから始めてみてください。.envファイルの確認、APIトークンの棚卸し、SSH鍵のパスフレーズ確認——小さなところから、確実にセキュリティを改善していきましょう。

参考リンク

• 1Password公式ブログ：Introducing 1Password® Unified Access
• Publickey：1Passwordが人間とAIエージェントのアイデンティティを統一管理する「Unified Access」発表