Claude Managed Agentsの環境変数｜機密をAIに見せない新方式

「顧客情報やパスワードをAIに渡して、本当に大丈夫なのか」——AIによる業務自動化を検討するとき、誰もがこの不安を抱えます。

結論から言うと、2026年6月9日に発表されたClaude Managed Agentsの環境変数対応は、この不安への構造的な回答です。AIエージェントに機密情報の実物を一切見せないまま、APIキーが必要な業務を任せられるようになりました。

株式会社Fyveは、中小企業のAI活用を支援する立場から、この新機能の仕組みと限界を整理します。私は本機能をまだ試していないため、公式情報と第三者分析の調査に、シークレット管理ツールInfisicalを日常的に使っている実務経験を重ねてお伝えします。

今回の発表の全体像——Claude Managed Agentsに2つの新機能

Anthropicは2026年6月9日、公式ブログでClaude Managed Agentsのアップデートを発表しました。Managed Agentsは、Anthropicのクラウド上の隔離環境（サンドボックス）でAIエージェントを動かせる開発者向け基盤です。今回はそこに2つの機能が公開ベータとして加わりました。

1. 環境変数によるシークレットの秘匿化

vault（ボールト。認証情報を預ける保管庫機能）に、新しい登録タイプ「environment_variable」が追加されました。APIキーやパスワードといった認証情報（シークレット）を、変数名・値・接続を許可する宛先とセットで登録しておくと、エージェントの実行時に環境変数として利用できます。

最大の特徴は、エージェント自身はシークレットの実物の値を一度も見ないことです。この仕組みが本記事の主題です。

2. Scheduled deployments——決まった時刻にエージェントを自動実行

「どのエージェントを・どの実行環境で・どんな指示で・いつ動かすか」をひとまとめにして登録すると、指定スケジュールでエージェントが自動起動します。書式は標準的なcron形式（分単位まで指定できる定期実行の記法）で、タイムゾーンも指定可能。これまで必要だった自前のスケジュール実行サーバーが不要になります。

Managed Agents自体の基本（仕組み・料金・事例）は、以下の記事で解説しています。

Claude CodeClaude Managed Agentsとは？仕組み・料金・事例

まず混同を正す——Claude Codeの「Routines」とは別物

SNSでは今回の発表が「Claude Codeのアップデート」として拡散されましたが、正確ではありません。今回の機能はClaude Platform（API・開発者コンソール）側のもので、claude.aiやClaude Codeで使える定期実行機能「Routines」とは提供面が異なります。

重要なのは、Routines側には専用のシークレット保管機能が提供されておらず、環境設定に書いた値は編集権限を持つ人に見える平文として扱われると公式に明記されている点です。「Claude Codeの定期実行でもAPIキーを安全に隠せるようになった」という理解は誤りなので注意してください。

「AIに機密を見せない」仕組み——ネットワーク境界での差し替え

AIが扱うのはダミーの文字列だけ

vaultに登録したシークレットは、エージェントの実行環境の中ではダミーの文字列（プレースホルダ）に置き換えられています。エージェントがそのダミー値を使って外部サービスへ通信しようとした瞬間、通信の出口にあたるネットワーク境界で実物の値に差し替えられます。

Anthropicの開発者向け公式アカウントは「エージェントがシークレットの値を見ることは決してない（The agent never sees the secret value）」と説明しています。会話ログやイベント記録にも実物の値は現れません。

例えるなら、経理担当者に銀行の暗証番号を教えず、振込の最後の一押しだけを金庫番が代行するイメージです。担当者は業務を完遂できますが、暗証番号そのものは最初から知りません。

プロンプトインジェクションへの「構造的」防御

この設計が効くのは、プロンプトインジェクション（AIへの指示文に悪意ある命令を紛れ込ませ、機密を漏らさせる攻撃）への耐性です。従来は「漏らさないように振る舞わせる」運用上の対策が中心でしたが、この方式ではAIの作業記憶のどこにも実物のシークレットが存在しないため、騙されても漏らしようがありません。

書き込み専用・即時の更新反映・接続先制限

• 書き込み専用：一度登録した値はAPIの応答に二度と返らず、管理画面からも取り出せません
• 即時の更新反映：vault側で値を更新するだけで、実行中のエージェントにも再起動なしで新しい値が反映されます
• 接続先の二重制限：認証情報側で許可した宛先と、実行環境側で許可した宛先の両方に合致する通信だけに実物の値が付与されます

仕様の詳細はvaultの公式ドキュメントで公開されています。

過信は禁物——公式・第三者が指摘する限界

一方で「これで完全に安全」とは言えません。公式ドキュメントと第三者のセキュリティ分析が明記している限界を、導入判断の材料としてそのまま並べます。

• 守られるのはvault経由の認証情報だけ。指示文に直接書いたパスワードや、ファイルとして渡した認証情報は対象外です。セキュリティ企業のPluto Securityは「すべての認証情報をvault経由にすること。例外なし」と勧告しています
• 差し替えは送信時のみ。認証のやり取りで外部から返ってきたトークン（一時的な認証データ）は、そのまま実行環境内に入ります
• 署名計算には使えない。AWSのSigV4のように、値そのものを送らず計算結果だけを送る認証方式には対応していません
• 初期設定は緩い。新規の実行環境は通信先無制限・全ツール有効が初期値で、本番では通信先を明示的に絞る設定が推奨されています（Environmentsの公式ドキュメント）。設定して初めて発表どおりの安全性になります
• 規制対応の対象外。データ完全不保持（ZDR）や米国医療情報規制（HIPAA）の契約範囲には含まれません
• そのほかの制約：vault1つあたり認証情報20個まで・自社運用サンドボックス未対応・公開ベータ段階

また、許可された権限の範囲内でエージェントが悪用される可能性は残ります。接続先制限は被害範囲を狭めますが、ゼロにはしません（TechTimesの分析）。

Scheduled deploymentsで業務はどう変わるか

もう一つの新機能Scheduled deploymentsは、環境変数と組み合わせることで真価を発揮します。「認証情報を安全に持たせたAIエージェントを、無人で定時実行する」体制がワンセットで組めるからです。業務でいえば、次のような自動化が該当します。

• 毎週月曜の朝に、販売データを集計してレポートを下書きしておく
• 毎晩、自社システムのエラー記録を確認し、異常があれば要約を残す
• 毎朝、前日の問い合わせの一次仕分けを済ませておく

公式事例では、楽天が週次・月次レポートの自動生成や本番環境の記録監視に利用しているほか、採用・営業のフォローアップ自動化などが紹介されています。実行のたびにまっさらな新規セッションが立ち上がる仕様で、登録は組織あたり1,000件まで。スケジュール実行自体の追加課金はなく、通常のAPI利用料金の範囲内です（Scheduled deploymentsの公式ドキュメント）。

従来この種の自動化には、クラウドのスケジュール実行サービスや自前サーバーの構築・保守が必要でした。その「つなぎの仕組み」が不要になる点は、専任のシステム担当者を置けない中小企業にとって、実質的な参入障壁の引き下げです。

Infisical・1Passwordとの違い——置き換えではなく併用

シークレット管理というと、Infisicalや1Passwordのような専門ツールを思い浮かべる方もいるはずです。今回の機能はこれらの代わりになるのでしょうか。私の整理は「守備範囲が違うので、置き換えにはならない」です。

守備範囲の整理——実行時の注入と、発行から廃棄までの管理

Claude Managed Agentsの環境変数は、Anthropicのクラウド実行環境の中だけで機能する「実行時の注入の仕組み」です。一方、Infisicalや1Passwordは、シークレットの発行から共有・更新・廃棄までを組織全体で管理する「台帳」の役割を担います。手元の開発環境からCI/CD（ビルドや配備の自動化工程）、本番サーバーまで同じ保管庫を使い回せるのが価値です。

料金は2026年6月時点の各公式ページ（Infisical・1Password）に基づきます。プラン体系や為替で変わるため、導入時は最新情報を確認してください。

私がInfisicalを使っていて感じること

私自身、複数の小さなプロジェクトで共有の.envファイル（環境変数を書き並べた設定ファイル）を使い回す運用から始め、その限界を感じてInfisicalを併用するようになりました。現在は「infisical run」というコマンドで手元の作業時に環境変数を注入し、CI/CDやデプロイ連携でも同じ保管庫から値を取得しています。

この経験から言えるのは、.envファイルの平文管理は「AIエージェントに作業させる前提」では一段とリスクが上がるということです。AI支援ツールが作業フォルダ内の.envを読み得ることは以前から指摘されており、Claude Codeにも「シークレットを安全に渡す仕組みがほしい」という要望がGitHub上で長く議論されてきました。今回の機能は、その要望にプラットフォーム側で答えた形です。

なおInfisicalも、エージェントにはダミー値だけを持たせて中継サーバーが実物に差し替える「Agent Vault」という仕組みを公開しており、設計思想はClaudeのvaultとほぼ同じです。自社サーバーで運用したい場合の選択肢になります。1Passwordも2026年に入ってAIエージェント領域への対応を急速に進めており、Environmentsなどの開発者向け機能を拡充しています（こちらは私は未使用のため、調査に基づく紹介です）。

現実解は「正本は専門ツール、AIにはvaultで渡す」

結論として、組織のシークレットの正本（マスター台帳）はInfisicalや1Passwordで管理し、Managed Agentsで動かすエージェントには必要な値だけをvaultに登録する併用構成が現実解です。両者は競合ではなく、守る場所が違う防具と考えるのが正確です。

手元の開発環境でのAPIキー管理の実務は、以下の記事で詳しく解説しています。

Claude CodeClaude Code/MCPのAPIキー管理｜実務の現実解

Infisicalと1Passwordそのものの比較は、こちらをご覧ください。

Claude Code1Password vs Infisical｜AIコーディング時代の個人開発シークレット管理

「機密をAIに渡すのが不安」という声にどう答えるか

冒頭の不安に戻ります。私は商談やヒアリングの場で、「顧客情報や認証情報をAIに渡すのが不安で、自動化に踏み切れない」という声を実際に何度も聞いてきました。この不安は漠然とした感情論ではなく、「AIがどこまで見えるのか分からない」という情報不足から来る合理的な警戒だと感じています。

今回の機能が示したのは、「AIに見せない設計は技術的に成立する」という事実です。AIを信頼できるかという問いを、「そもそも見せない構造になっているか」という検証可能な問いに置き換えられます。AI導入の説明責任を負う経営者にとって、これは大きな変化です。

ただし前述のとおり、保護されるのはvault経由の認証情報に限られ、初期設定のままでは発表どおりの安全性にはなりません。公開ベータでもあるため、「導入すれば安心」ではなく「正しく設定すれば、人間の注意力に頼らない防御層が一枚増える」と捉えるのが正確です。

まとめ

• 2026年6月9日、Claude Managed Agentsに環境変数（vault）とScheduled deploymentsが公開ベータで追加された
• シークレットはネットワーク境界で差し替えられ、AI本体は実物の値を一度も見ない。プロンプトインジェクションへの構造的防御になる
• Claude CodeのRoutinesとは別物。Routinesには専用のシークレット保管機能はない
• 保護はvault経由のみ・初期設定は緩い・ベータ段階など限界もあり、「完全に安全」ではない
• Infisical・1Passwordとは守備範囲が異なり、置き換えではなく併用が現実解

「機密をAIに見せない」という設計思想は、今後のAI活用基盤の標準になっていくはずです。セキュリティを理由にAI自動化を見送ってきた企業こそ、判断材料が変わったタイミングだと言えます。