「APIキーは.envに」はもはや通用しない AIエージェントの“内通者化”をどう防ぐ？：Agent時代の必須知識 APIから読み解くAIの裏側（2）

AIエージェントの活用が広がるのと同時に、APIキーやトークンなどの認証情報も増殖。セキュリティリスクは高まり、従来の認証情報の管理方法は限界を迎えつつあります。では、どう守ればよいのでしょうか。

[草薙昭彦（Postman）, 編集：遠藤文康，＠IT]

　AIエージェントがツールを呼び出し、データソースに接続し、自律的に仕事をこなす――。こうしたAIエージェントの動作を裏側で成り立たせるのがAPIの呼び出しです。AIエージェントの活用範囲が広がり、連携するツールやデータソースが増えるほど、呼び出すAPIも増えます。それに伴い増殖するのが、APIキーやアクセストークンといった認証情報です。

　第1回では、増殖するAPIキーやトークンなどの認証情報がもたらすセキュリティリスクを取り上げました。焦点の一つが、.envファイルなどを通じて環境変数からAPIキーを読み込ませる方法でした。従来広く使われてきたこの方法が、AIエージェントが自律的に多数のサービスへとアクセスする時代になぜ通用しなくなるのかを解説しました。

　APIキーの保管場所の問題にも触れました。ツール汚染（Tool Poisoning）や間接プロンプトインジェクションなど、AIエージェントの利用が招く攻撃も登場しています。

　ではこれらのリスクがある中で、どう守ればよいのでしょうか。今回はその対策を考えます。

「APIキーは.envに」が内通者を生む：対策の全体像

　対策は大きく3つの層に分けて整理すると、見通しがよくなります。第一に、認証情報を安全に保管する層。第二に、必要なときに必要な分だけ、短命でスコープを絞った資格情報を動的に発行する層。第三に、誰が・どのユーザーの権限で・何にアクセスしたかを記録し監査する層です。

　ここで押さえておきたいのが、シークレットマネージャーとトークンボールトの違いです。

　シークレットマネージャーは、保管した文字列を要求に応じて返します。便利ですが、返された鍵をそのままエージェントが握る点は.envと本質的に変わりません。一方トークンボールトは、OAuthフローを自ら実行し、トークンを暗号化して保管・更新し、必要な呼び出しにだけ注入します。モデルには生の鍵を一切見せません。エージェント時代に向くのは、後者の発想です。

観点	シークレットマネージャー	トークンボールト
モデルに渡すもの	保管した鍵の文字列	短命・スコープ限定のトークン
有効期限	なし（長寿命）	あり（短命）
権限範囲	広いまま	アクションに絞る
OAuthフローの実行	行わない	サーバ側で実行する
生の鍵をモデルが見るか	見る	見ない

　選択肢も出そろってきています。OSS・セルフホスト系では「Infisical」「HashiCorp Vault」、OAuthトークンの保管に特化した「Nango」などがあり、マネージドベンダー系では「AWS Secrets Manager」「1Password」「Aembit」「WorkOS」「Arcade」といった名前が挙がります。共通する思想はシンプルです。エージェントに鍵そのものを渡すのをやめ、アクションごとにスコープを絞った期限付きの資格情報を、その都度手渡す。要点はこの一点にあります。

　忘れてはならないのが、第三の層である監査と失効です。短命トークンの利点は、漏れても寿命が尽きれば自動的に無効になる点にありますが、それは、異常に気付いて即座に止められる仕組みとセットで初めて意味を持ちます。どのエージェントが、いつ、どの権限で、何を呼んだか。この記録が残っていれば、侵害の予兆を検知でき、疑わしいトークンをその場で失効させられます。逆に記録がなければ、事故が起きたことにすら気付けません。

　第1回では、.envなどを通じてAPIキーをエージェントからアクセス可能な状態にすることが、クレデンシャルの流出につながるリスクを取り上げました。外部から与えられた指示に従い、AIエージェントはいわば「内通者」のような存在になります。.env流出が危ういのは、盗まれた鍵が長寿命である上に、そもそも、いつ盗まれ、何に使われたかを追うすべがないからです。

設計のポイント：APIをラップし、ゲートウェイで制御する

　では、APIを設計・運用する側は、具体的に何をすればよいのでしょうか。有効な型が一つあります。既存のREST APIをエージェントに直接触らせるのではなく、MCPサーバでラップし、それをゲートウェイとして機能させるパターンです。

　このゲートウェイが担うのは、大きく3つの役割です。まず、エージェントのIDを、そのアクションに必要な分だけスコープを縮小した短命トークンに交換する。次に、「一つのAPI＝一つのツール」という素朴な対応付けをやめ、複数のエンドポイントを「顧客を照会する」「顧客情報を更新する」といった高レベルの意図（インテント）として定義し直す。これは自動で束ねられるものではなく、どのエンドポイントをどの意図にまとめるかを設計者が決める作業です。そして、通過する全ての呼び出しについて、誰が・どのユーザーコンテキストで・何にアクセスしたかを記録する。

　こうすれば、エージェントは生の認証情報に一度も触れずに仕事をこなせます。ここは、APIを人間の開発者向けのドキュメントとしてではなく、エージェントという新しい利用者向けの制御面として設計し直す発想が、そのまま効いてくる領域です。

　インテント単位で定義することには、もう一つ効用があります。エージェントに見せるツールを、本当に必要な操作だけに絞れるため、危険な操作をそもそもエージェントの選択肢に入れずに済みます。ルートやツールごとのアクセス制御は、エージェントごと・チームごとに公開範囲を絞る形で実現できます。さらに、読み取り専用の操作と、状態を変更する操作を意図の段階で分けておけば、権限の設計そのものが攻撃面を狭めます。

　そして、決済の確定や共有範囲の変更といった不可逆・高権限の操作については、人間の承認を挟む（Human-in-the-loop）仕組みをゲートウェイ層で扱う、という設計が提唱されています。エージェントのコードやプロンプトの良しあしに頼るのではなく、鍵とアクセスを管理する層で線を引く。これが、非決定的な相手に対して最も実効性のある守り方です。

問うべきは、アクションを制御できているか

　調査会社Gartnerは、2028年までに、人間の認証情報をAIエージェントと共有することを許している組織の90％が、セキュリティとコンプライアンス上の問題から、その設計を作り直すために大きな投資を迫られる、と予測しています。同じレポートでGartnerは、人間の認証情報の共有を禁止し、全てのAIエージェントに、責任を負う人間の持ち主がひも付いた固有のIDを持たせよ、と繰り返し勧めています。裏を返せば、いま多くの現場が、やり直しが避けられないと分かっている方式のまま走っている、ということです。

　だからこそ、問いを立て直す必要があります。うちのAPIキーは安全に保管されているか、ではありません。うちのAPIを、エージェントが発見・利用できる状態にした上で、正しいアクセスだけを与えられているか。この問いに即答できないのであれば、AIエージェントのアクションを制御できているとは言えません。そしてそれは、AIエージェント運用の入り口に過ぎないのです。

---

　次回は、視点を、管理の不備から無駄な消費へと広げます。エージェントは、見えないところで、トークンを、つまりコストを、費やし続けています。次回のテーマは、この無自覚なトークン浪費です。

出典・参考文献

[1] Gartner「Cybersecurity Trend: IAM Adapts to Secure and Enable AI Agents」（Nathan Harris、Homan Farahmand、2026年1月14日）

著者紹介

草薙 昭彦（くさなぎ あきひこ）

Postman株式会社　テクノロジーエバンジェリスト

東京大学大学院工学系研究科電子情報工学専攻修士課程修了。サン・マイクロシステムズ、オラクル、EMCを経て近年は外資系ITスタートアップでサービス導入や啓蒙活動に従事。デジタルツインやデータビジュアライゼーションに関心があり、制作した交通デジタルツインアプリ「Mini Tokyo 3D」は数々の賞を受賞。