エージェントにAPIキーを渡す、という怖さ
自律的に動くエージェントに、外部サービスのAPIキーを持たせたことはあるだろうか。
筆者は先日、まさにこれで痛い目を見た。スケジュール実行するZennの下書き生成エージェントにQiita投稿用のトークンを持たせようとして、設定ファイルに生の値を書いてしまい、公開リポジトリに露出させかけたことがある。修正はできたが、「モデルにキーの中身を見せる」設計そのものが危うい、という教訓が残った。
Anthropicも同じ課題に直面していたようだ。2026年6月9日、Claude Managed Agentsに「Vaults」の環境変数対応と、cronベースのスケジュール実行機能が追加された。エージェントに認証情報を持たせる部分を、プラットフォーム側の機能として切り出した格好だ。
結論から言うと
- Vaultsは、APIキーを環境変数名と許可ドメインの組として登録する仕組み。2026年6月9日にパブリックベータ入り
- エージェントのサンドボックスにはプレースホルダーしか渡らない。実キーは、許可ドメインへのリクエストが出た瞬間にネットワーク境界で注入される
- モデル自身は一度も本物のキーを見ない。プロンプトインジェクションでキーそのものを抜かれるリスクを構造的に減らす設計
- 同時に**スケジュール実行（cron）**も追加され、エージェントを自前でスケジューラを組まずに定期起動できる
- Notion・Browserbase・Sentryなど、HTTPヘッダーでキーを送るCLIであれば概ね対応
本記事は、Anthropic公式ブログとドキュメント、および関連メディアの記事をもとにした解説です。機能はまだパブリックベータであり、対応範囲や挙動は今後変わる可能性があります。
Vaultsの仕組み：キーを「見せずに使わせる」
一般的なやり方だと、エージェントに外部APIを叩かせるには、環境変数かプロンプトのどこかにキーを埋め込む必要がある。この場合、モデルの文脈にキーの文字列そのものが乗る。ログに残る、プロンプトインジェクションで抜かれる、うっかりコミットするなど、漏洩経路は複数ある。
Vaultsのアプローチは違う。
1. ユーザーがAPIキーを登録する
→ 環境変数名（例: SENTRY_API_KEY）+ アクセス許可ドメイン（例: sentry.io）
2. エージェントのサンドボックスには「プレースホルダー」だけが渡る
→ モデルが読めるのは変数名だけで、値の中身は見えない
3. サンドボックス内のCLIがそのAPIへリクエストを送る
4. リクエストが許可ドメインに向かっている場合のみ、
ネットワーク境界（サンドボックスの外側）で本物のキーが注入される
つまり、キーの実体はモデルのコンテキストにも、サンドボックスのメモリにも载らない。乗るのはリクエストが実際に送信される瞬間、かつ許可済みドメイン宛てのときだけだ。ドメインを絞っているので、仮にエージェントが騙されて意図しないリクエストを組み立てても、キーが漏れる先は登録済みドメインに限られる。
対応しているのは「キーをHTTPリクエストのヘッダーやクエリで送る」タイプのCLIで、Browserbase・KERNEL・Notion・Ramp・Sentryなどが挙げられている。
もう一つの目玉：スケジュール実行（Cron）
同時に発表されたのが、Managed Agentsのcronスケジュール機能だ。エージェントに定期実行のスケジュールを設定すると、発火のたびに新しいセッションが立ち上がってタスクをこなす。自前でスケジューラを構築・ホストする必要がない。
筆者はこの記事群を書くために、launchdで自前の日次エージェントを組んだ。zshrcからトークンを読ませるためのzsh -iラップや、実行ログのローテーション、失敗時の通知など、地味な配線が地味に面倒だった。Managed AgentsのVaults＋Cronは、その配線部分をプラットフォームの機能として肩代わりするという提案に見える。
実例：Notion・Milanaのユースケース
公式ブログが挙げる例は具体的だ。
- Notion：CLIをMCPツールと並行して展開し、APIトークンをモデルに一切渡さないままファイルアップロード機能をエージェントに持たせている
- Milana：AI「プロダクトエンジニア」を顧客のコードベースに安全に接続する際に、Vaultsの環境変数を使っている
どちらも「エージェントに強い権限を持たせたいが、キーそのものは渡したくない」という同じ緊張関係への回答だ。
手放しで安全、ではない
誠実に見ておくべき論点もある。
- 対応CLIが限定的：キーをHTTPリクエストで送る設計のツールでないと機能しない。独自の認証フローを持つツールは対象外
- ドメイン許可リストの運用：許可ドメインの設定を誤れば、意図しない宛先にリクエストが飛ぶ余地は残る。境界の信頼はAnthropicのサンドボックス実装に依存する
- まだパブリックベータ：仕様・対応範囲は変わりうる。本番のクリティカルパスに今すぐ乗せる判断は慎重に
「モデルがキーを見ない」ことは、「サンドボックスから何も漏れない」ことを保証しない。許可ドメインの設定は最小限にし、Managed Agentsに与える権限そのものも必要最小限にとどめるべきです。
まとめ
| 観点 | 従来（環境変数を直接渡す） | Vaults |
|---|---|---|
| モデルがキーを見るか | 見える | 見えない（プレースホルダーのみ） |
| キー漏洩の主な経路 | プロンプト・ログ・コミット | ネットワーク境界の設定ミスに限定 |
| アクセス範囲の制御 | アプリ側の実装次第 | 登録時にドメイン単位で制限 |
| スケジュール実行 | 自前で構築 | Cronとしてプラットフォームが提供 |
エージェントに何を持たせ、何を持たせないか——この設計判断は、今後のエージェント運用で一番地味で一番重要な部分になっていくはずだ。Vaultsは「キーを渡さずに使わせる」という発想を、プラットフォームの標準機能に押し上げた一例として見ておきたい。
この記事が役に立ったら、いいねと保存をお願いします！
あなたのエージェントは、APIキーをどう扱っていますか？自前のワークアラウンドがあれば、コメントで教えてください。
参考リンク
New in Claude Managed Agents: run agents on a schedule and store environment variables in vaults - Anthropic
Authenticate with vaults - Claude Platform Docs
Claude Managed Agents Add Cron Schedules and Credential Vaults - Tech Times