「APIキーは.envに」の時代は終わった。AIエージェントの"内通者化"をどう防ぐか
「APIキーは.envに」が通用しなくなった、その構造的理由
AIエージェントが自律的に動き、複数のサービスをまたいで仕事をこなす。その裏側で起きていることを一言で言うなら、「APIキーやアクセストークンの増殖」だ。
エージェントが接続するツールやデータソースが増えるほど、認証情報も増える。そしてその管理に、多くの現場がいまだに .env ファイルを使っている。これが問題の出発点だ。
.env ファイルによるAPIキー管理は、人間の開発者が限られたサービスに手動でアクセスする時代の産物だ。その前提が、AIエージェントの登場で根底から崩れている。エージェントは自律的に判断し、多数のサービスに連続してアクセスする。外部から与えられた指示（プロンプトインジェクションやツール汚染）によって、エージェントはいわば「内通者」のように振る舞う可能性がある。
.env が危うい理由は2つある。ひとつは「長寿命」であること。有効期限のないAPIキーは、盗まれてもそのまま使い続けられる。もうひとつは「追跡不能」であること。いつ盗まれ、何に使われたかを追う手段がない。この二重の欠陥が、エージェント時代には致命的になる。
3層の防御モデルと「シークレットマネージャー vs トークンボールト」の違い
では、どう守るか。@ITの元記事（草薙昭彦氏、Postman）は対策を3層に整理している。
- 認証情報を安全に保管する層
- 必要なときに必要な分だけ、短命でスコープを絞った資格情報を動的に発行する層
- 誰が・どのユーザーの権限で・何にアクセスしたかを記録し監査する層
ここで重要な区別がある。「シークレットマネージャー」と「トークンボールト」は、似て非なるものだ。
シークレットマネージャーは、保管した文字列を要求に応じて返す。便利だが、返された鍵をそのままエージェントが握る点は .env と本質的に変わらない。一方のトークンボールトは、OAuthフローをサーバ側で自ら実行し、短命かつスコープを絞ったトークンだけをエージェントに渡す。モデルには生の鍵を一切見せない。
両者の違いをまとめると以下のようになる。
| 観点 | シークレットマネージャー | トークンボールト |
|---|---|---|
| モデルに渡すもの | 保管した鍵の文字列 | 短命・スコープ限定のトークン |
| 有効期限 | なし（長寿命） | あり（短命） |
| 権限範囲 | 広いまま | アクションに絞る |
| OAuthフローの実行 | 行わない | サーバ側で実行する |
| 生の鍵をモデルが見るか | 見る | 見ない |
具体的なツールとしては、OSS・セルフホスト系では「Infisical」「HashiCorp Vault」「Nango」、マネージドベンダー系では「AWS Secrets Manager」「1Password」「Aembit」「WorkOS」「Arcade」といった選択肢が挙げられている。共通する思想はシンプルだ。エージェントに鍵そのものを渡すのをやめ、アクションごとにスコープを絞った期限付きの資格情報を、その都度手渡す。
そして忘れてはならないのが第3層の「監査と失効」だ。短命トークンの利点は、漏れても寿命が尽きれば自動的に無効になる点にある。だがそれは、異常に気付いて即座に止められる仕組みとセットで初めて意味を持つ。記録がなければ、事故が起きたことにすら気付けない。
MCPサーバーをゲートウェイにする設計パターン
では、APIを設計・運用する側は何をすべきか。元記事が提示する「有効な型」がある。
既存のREST APIをエージェントに直接触らせるのではなく、MCPサーバーでラップし、それをゲートウェイとして機能させるパターンだ。
このゲートウェイが担う役割は3つ。
まず、エージェントのIDを短命トークンに交換する。アクションに必要な分だけスコープを縮小した上で渡す。
次に、「一つのAPI＝一つのツール」という対応付けをやめ、インテント単位で定義する。「顧客を照会する」「顧客情報を更新する」といった高レベルの意図として複数のエンドポイントをまとめ直す作業だ。これは自動化できない。どのエンドポイントをどの意図にまとめるかは、設計者が判断する必要がある。
そして、通過する全ての呼び出しを記録する。誰が、どのユーザーコンテキストで、何にアクセスしたか。この粒度のログがあって初めて、監査が機能する。
インテント単位で定義することには、もう一つ重要な効用がある。エージェントに見せるツールを本当に必要な操作だけに絞れるため、「危険な操作をそもそもエージェントの選択肢に入れない」設計が可能になる。さらに、読み取り専用の操作と状態を変更する操作を意図の段階で分けておけば、権限設計そのものが攻撃面を狭める。
決済の確定や共有範囲の変更といった不可逆・高権限の操作については、ゲートウェイ層でHuman-in-the-loopを実現する設計も提唱されている。エージェントのコードやプロンプトの良しあしに頼るのではなく、鍵とアクセスを管理する層で線を引く。これが、非決定的な相手に対して実効性のある守り方だ。
ここからは見方の話：問いを立て直す必要がある
Gartnerは、2028年までに「人間の認証情報をAIエージェントと共有することを許している組織の90%が、セキュリティとコンプライアンス上の問題から、設計を作り直すために大きな投資を迫られる」と予測している。同時に「人間の認証情報の共有を禁止し、全てのAIエージェントに、責任を負う人間の持ち主にひも付いた固有のIDを持たせよ」と勧告している。
この予測が示していることは、ある意味シンプルだ。「今の設計が間違いだと分かっている。でも多くの組織はそのまま走っている」。
ここで問いを変える必要がある。
「うちのAPIキーは安全に保管されているか」ではない。
「うちのAPIを、エージェントが発見・利用できる状態にした上で、正しいアクセスだけを与えられているか」
この問いに即答できないのであれば、AIエージェントのアクションを制御できているとは言えない。
もうひとつ、判断軸として持っておきたい視点がある。新しいAIエージェントツールが出たとき、その「安全機能」がプロンプト設計に依存しているのか、それとも権限層で制御しているのかを確認することだ。「賢いプロンプトがあれば悪用を防げる」という設計は、防御にならない。エージェントは非決定的だ。プロンプトで制御する話か、権限で制御する話かを切り分けることが、同種のニュースを読むときの基本的な軸になる。
実務的な示唆と、次に来る論点
今すぐ確認すべきことを3点に絞る。
1. .env で渡している認証情報に有効期限があるか確認する。
長寿命のAPIキーを使っている場合、それが漏れたときに止める手段があるかを問い直す。
2. エージェントが呼び出したAPIの記録が残っているかを確認する。
「何かあったときに調べられるか」ではなく、「異常をリアルタイムで検知できるか」まで含めて問うこと。
3. エージェントに渡している権限の範囲を確認する。
読み取りと書き込みが混在していないか。不可逆な操作にアクセスできる状態になっていないか。
次に問題になるのは、MCPサーバーの接続が増えるほど権限マップが複雑になる点だと思う。個々のエージェントの権限を管理していても、MCPサーバーを経由することで実質的な権限範囲が広がっていく。接続するサーバーが増えれば増えるほど、「このエージェントは最終的に何にアクセスできるか」の全体像が見えにくくなる。設計段階でのスコープ管理と、実行時の監査ログの両方が必要になってくる。
「APIキーの管理」という話題は、一見地味に聞こえる。しかし本質は、AIエージェントに何をどこまで任せるかという設計思想の問題だ。エージェントは自律的に動く。だからこそ、動いていい範囲を人間が設計で定義しなければならない。コードの良しあしや、プロンプトの精巧さに頼るのではなく、構造で制御する。その発想の転換が、エージェント時代のセキュリティの出発点になる。
