結論：AIエージェントの本番化で最後に残る宿題は、たいてい鍵の管理
Google Cloudは2026年8月22日、IAMのリリースノートで、Agent Identity auth manager および Agent Identity APIs（Agent Identity API＝agentidentity.googleapis.com、Agent Identity Credentials API＝agentidentitycredentials.googleapis.com）の一般提供（GA）を告知しました。
リリースノートの説明は次のとおりです。Agent Identity auth managerは、3-legged OAuth、2-legged OAuth、APIキーによる外向きのツール認証を簡素化する、集中型の資格情報保管庫（credentials vault）と認証ブローカーを提供する。またこれらのAgent Identity APIsは、認証プロバイダとエージェントIDの管理について、従来のIAM Connectors API（iamconnectors.googleapis.com）を置き換える。
この記事は特定のクラウドの宣伝ではありません。この告知を材料に、AIエージェントをPoCから本番へ移すときに必ず出てくる「鍵の置き場所」という宿題を、発注側の言葉で整理します。対象読者は、AI活用を進めたい中堅企業の経営者、AI推進の担当役員、兼任情シスです。
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
対象業務、データ、権限、ログ、運用責任を確認し、PoC前に失敗要因と本番化条件を整理します。
PoCと本番の間に落ちている段差
AIエージェントのPoCは、多くの場合こう作られます。開発者の手元で、必要なサービスのAPIキーを取得し、設定ファイルか環境変数に書き、動くところまで持っていく。これは検証としては正しい進め方です。速さが目的だからです。
問題は、この構成がそのまま本番に持ち込まれやすいことです。動いているものを作り直すのは手戻りに見えるので、「とりあえずこのまま」で本番の日程が決まってしまいます。
しかし、PoCと本番では前提が3つ変わります。
1. 使う人が増える
PoCは作った人が使います。本番は、部署の複数名、あるいは全社が使います。同じ鍵を全員が共有する構成では、接続先のサービス側から見るとすべてが同じ主体の操作になります。誰の依頼で動いたのかを残すには、アプリケーションやゲートウェイの側で依頼者を記録する設計が別に要ります。
2. 動く期間が長くなる
PoCは数週間です。本番は年単位で動きます。その間に、担当者は交代し、委託先は変わり、利用するサービスも増えます。長期間有効な鍵が設定ファイルに残り続けるという状態は、時間が経つほど危険度が上がります。
3. 触れる範囲が広がる
PoCは限定されたデータで試します。本番では、顧客情報、契約、在庫、会計といった本物のデータにつながります。鍵が持つ権限の重さが変わります。
この3つの変化に対応せずに本番へ進むと、あとから直すコストが跳ね上がります。AIエージェントの本番化が止まる理由は、モデルの精度ではなく、この部分の設計であることがしばしばあります。
Agent Identityが変えている前提
Google Cloudのドキュメントによれば、Agent Identityは、SPIFFEという標準にもとづく、暗号的に裏づけられたIDをエージェントに付与する仕組みです。なお同ドキュメントが2026年8月26日時点で対応サービスとして挙げているのは Gemini Enterprise Agent Platform Runtime と Gemini Enterprise で、どこにデプロイしたエージェントでも使えるという話ではありません。エージェントは、そのIDを使ってMCPサーバー、クラウドリソース、エンドポイント、他のエージェントに対して認証を行い、自分自身として、あるいはエンドユーザーの代理として動作します。
サービスアカウントとの違いとして、ドキュメントは次の点を挙げています。
- エージェントIDは、既定では複数のワークロードに共有されない
- なりすまし（impersonation）ができない
- 開発者が長期間有効なサービスアカウントキーを生成できない
- Google Cloud向けに発行されるアクセストークンは、そのエージェント固有のX.509証明書に暗号的に紐づけられ、トークンの盗用を防ぐ
技術的な詳細はさておき、発注側が読み取るべきポイントは1つです。「1つの鍵を使い回す」「長く使える鍵を開発者が勝手に作れる」という構成を、既定で許さない方向へ寄せてきているということです。
正確に押さえておくと、ドキュメントが言っているのは、エージェントIDが既定では複数のワークロードに共有されないこと、そして開発者が長期間有効な「サービスアカウントキー」を生成できないことです。外部サービスのAPIキーそのものが消えるわけではありません。それらはauth managerが保管・仲介する対象として、引き続き存在します。変わるのは、鍵が個々のコードの中ではなく、管理された場所に置かれるという点です。
ここで参照したのはGoogle Cloudのドキュメントであり、他のクラウドが同等の仕組みを同じ形で提供しているかどうかは、本記事では確認していません。ただし、エージェントに個別のIDを持たせ、資格情報を1か所で管理するという設計が、一般提供の段階まで来ている実例としては提示できます。
なお、すべてが短命な資格情報に置き換わるわけではありません。ドキュメントによれば、エージェントに発行されるX.509証明書の有効期間は24時間ですが、外部ツールへ接続する際には、auth managerがAPIキーやOAuthトークンといった必要な資格情報を取り出して使います。外部サービスのAPIキーそのものが短命になるわけではなく、置き場所と取り出し方が管理された形になる、という理解が正確です。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
発注側が要求すべき5つの条件
自社でAIエージェントを開発する場合も、開発会社に委託する場合も、次の5点は要件として明示できます。特定のクラウドや製品に依存しない書き方にしてあります。
横にスクロールして確認できます
| # | 要求する条件 | 確認方法 |
|---|---|---|
| 1 | 資格情報をソースコードや設定ファイルに直接書かない | リポジトリ内に鍵らしき文字列がないことを確認する |
| 2 | 資格情報の保管場所を1か所に集約する | 「どこに何個あるか」を一覧で出してもらう |
| 3 | 発行される権限は、そのエージェントが必要とする範囲に限定する | 付与されている権限の一覧と、その根拠を説明してもらう |
| 4 | 担当者の交代・委託終了時に、失効の手順が定義されている | 手順書の提示を求める。口頭の説明は不可 |
| 5 | エージェントの動作ログから、誰の依頼による処理かを追える | 実際のログのサンプルを見せてもらう |
このうち4番が最も抜けます。導入時には誰も退職や契約終了の話をしないからです。しかし失効手順が定義されていなければ、関係が終わった後も資格情報が有効なまま残るおそれがあります。有効期限や自動ローテーションが効いていれば結果的に失効することもありますが、それは設計として失効を担保したことにはなりません。有効期限、更新の仕組み、失効の手順をセットで確認してください。
5番は、AIエージェントに固有の論点です。利用者ごとのIDで直接操作し、接続先がそのIDを記録する構成であれば、操作ログから人を特定できます。エージェントが代わりに操作すると、接続先には共有された資格情報しか届かず、そのログだけでは依頼者を特定できない構成になりがちです。依頼者のIDを別途、監査ログとして残す設計になっているかを確認してください。
鍵の棚卸しは、まずこの表から始める
棚卸しと聞くと大がかりに感じますが、AIエージェントや自動連携まわりの資格情報については、次の表を1枚作るところから始められます。技術者でなくても、聞き取りで埋められます。ここで足りなければ、有効期限、更新（ローテーション）の方法、最終利用日時、失効の状態といった列を足していきます。
横にスクロールして確認できます
| 列 | 記入内容 | この列で分かること |
|---|---|---|
| 接続先 | どのサービス・システムへつないでいるか | 影響範囲の広さ |
| 種類 | APIキー、OAuth、サービスアカウント、ID/パスワード、証明書、アクセストークンなど | 失効のしやすさ |
| 置き場所 | 設定ファイル、環境変数、秘密情報の保管サービス、担当者のPC | 持ち出されやすさ |
| 権限の範囲 | 読み取りのみか、書き込みや削除もできるか | 事故が起きたときの被害の重さ |
| 管理者 | 誰が発行し、誰が失効できるか | 担当者交代時に残るかどうか |
この表を作ると、たいてい2つのことが判明します。1つは、想定より数が多いこと。もう1つは、「管理者」の列に「不明」が並ぶことです。発行した本人がすでに社内にいない、あるいは委託先の誰かが作ったものが、そのまま動き続けている状態です。
管理者が特定できない行から着手します。ここで大事なのは、いきなり止めないことです。何が壊れるか分からないまま失効させると、業務が止まります。まず、その鍵が何に使われているかを特定し、代替を用意してから切り替える、という順序で進めます。
PoCを本番として受け入れるときの検収項目
AIエージェントのPoCが成功したあと、そのまま本番運用に移す判断をする場面があります。そのとき、業務面の成果だけで検収してしまうと、鍵まわりの宿題が残ります。
検収の場で確認する項目を、業務面と運用面に分けて提示します。
業務面（これは通常確認される）
- 想定した業務で、期待した結果が出るか
- 誤った結果が出たときに、人が気づける仕組みがあるか
- 処理できない依頼を、どう扱うか
運用面（ここが抜けやすい）
- 使われている資格情報の一覧が、発注側に提出されているか
- 各資格情報の権限が、必要な範囲に絞られているか
- 担当者の交代時に失効させる手順が、文書になっているか
- エージェントの処理ログから、誰の依頼かを追えるか
- 想定外の量の処理が走ったときに、止める手段があるか
最後の項目は、費用の観点でも重要です。従量課金型の外部サービスを呼び出す構成では、呼び出し回数がそのまま費用になります。設定の誤りやループによって想定外の回数が呼ばれれば、その分だけ請求が増えます。止める手段の有無は、セキュリティであると同時にコスト管理の論点です。
この検収項目は、PoCを始める前に共有しておくのが最も効果的です。後から追加すると仕様変更として扱われ、追加費用と日程の交渉になります。最初に「本番化するならこれを満たす」と伝えておけば、開発側もそれを前提に作ります。
「まだAIエージェントは入れていない」企業がやるべきこと
この記事の内容は、AIエージェントを導入していない企業にも関係します。理由は、すでに社内のどこかで似た構成が動いている可能性が高いからです。
- 業務効率化のために作られた自動連携（受注データの取り込み、日次のレポート送信など）
- 部署単位で契約している外部サービスと、社内システムをつないでいる仕組み
- 開発ベンダーが作った、定期実行される処理
これらは、AIかどうかにかかわらず、何らかの資格情報を使って外部と通信しています。「どこに、いくつ、誰が管理している鍵があるか」という問いは、AI導入の前に一度やっておく価値があります。この棚卸しがないままAIエージェントを追加すると、管理対象がさらに増えるだけです。
棚卸しの単位は、システムではなく「接続」です。システム単位で数えると1件に見えるものが、接続単位で数えると複数の鍵を持っていることがよくあります。
後から直すと、なぜ費用が跳ね上がるのか
「まず動かして、あとで整える」という進め方は、多くの場面で合理的です。ただし資格情報の設計に関しては、後から整えるときの費用が、最初から作る場合と比べて不釣り合いに大きくなります。理由は3つあります。
すでに業務が乗っている
PoCの段階なら、止めて作り直しても誰も困りません。本番稼働後は、切り替えのために業務を止める調整が必要になります。調整の対象が複数部署にまたがるほど、日程を合わせるだけで時間を要します。
どこで使われているか分からなくなっている
同じ鍵が、当初の用途以外にも流用されていることがあります。「便利だったので、別の処理でも使った」という経緯です。失効させると、把握していなかった処理が止まります。この調査が、改修そのものより時間を食います。
判断できる人がいない
作った担当者が異動している、委託先の担当者が変わっている、という状態では、「この権限は何のために付いているのか」に誰も答えられません。答えられないので、権限を絞る判断ができず、結局そのままにする、という結論になりがちです。
これらはいずれも、時間の経過とともに悪化します。つまり、この宿題は先送りするほど高くなる種類のものです。逆に言えば、いま動いているものが少ないうちに手を付ければ、費用は最も安く済みます。AIエージェントをこれから増やそうとしている企業にとって、今が最も条件の良いタイミングです。
「利用者の権限をどう引き継ぐか」は別の論点
本記事で扱ったのは、エージェント自身の資格情報をどこに置き、どう失効させるかという話です。これと隣接するが別の論点として、「同じエージェントを営業と経理が使うとき、それぞれが見てよいデータだけが返ってくるか」という、利用者の権限を下流まで引き継ぐ設計があります。
2つは両方とも必要です。資格情報が適切に管理されていても、エージェントが全社のデータに一律にアクセスできる構成であれば、部署をまたいだ情報の露出は防げません。逆に、権限の引き継ぎが設計されていても、鍵が設定ファイルに直書きされていれば、そこから丸ごと持ち出されます。
発注時には、この2つを分けて要求してください。1つの言葉でまとめると、どちらかが抜けます。利用者の権限継承については、AIエージェントに共通管理者IDを渡すなで扱っています。
GXOに相談できること
- 社内で使われている資格情報の棚卸し（接続単位での一覧化）
- AIエージェント導入前後の権限・鍵管理の設計レビュー
- PoCから本番へ移すときの、要件の追加と検収条件の整理
- 委託先に出す要求仕様への落とし込みと、提案内容の妥当性確認
FAQ
Google Cloudを使っていないと関係ありませんか
Agent Identityそのものは、Google Cloudの機能です。ただし本記事で扱った論点（鍵をどこに置くか、権限をどこまで絞るか、どう失効させるか、誰の依頼か追えるか）は、どの環境でも同じように問えます。他のクラウドや自社構築の環境で、どの仕組みを使ってこれらを満たすのかは、開発側に提示してもらう事項です。本記事では他社クラウドの機能を確認していないため、同等の仕組みがあるかどうかについては言及しません。
APIキーを環境変数に置くのは安全ではないのですか
ソースコードに直接書くよりは改善されます。ただし、環境変数は同じ環境で動く別のプロセスからも読めることがあり、また環境変数そのものには「誰が、いつ、どのキーを設定したか」を残す仕組みがありません。デプロイのログや構成管理の履歴に残っている場合はありますが、その有無は構成しだいです。Google Cloudのドキュメントが挙げているような、共有されない、なりすまされない、長期間有効な鍵を作れない、という性質までは得られません。段階としての改善であり、到達点ではないと考えてください。
既存のPoCを作り直す必要がありますか
必ずしも作り直しではありません。まず確認するのは、そのPoCを本番として使い続ける予定があるかどうかです。使い続けるなら、本記事の5条件を満たすように改修する範囲を見積もります。使い捨てるなら、次に作るものへ条件を反映させれば足ります。判断の前に、現状の鍵がどこに何個あるかを把握してください。
開発会社に任せているので分かりません
「資格情報がどこに、いくつあり、誰が管理しているか」の一覧の提出を求めてください。委託契約のもとで、発注者が求めてよい情報です。一覧が出てこない、あるいは作成に時間がかかると言われる場合、その状態自体が現状を示しています。
関連記事・サービス
参考情報
- Google Cloud IAM release notes（Google、2026年8月22日の項、2026年8月26日確認、一次情報）
- Agent Identity overview（Google、2026年8月26日確認、一次情報）
引用したのは、2026年8月26日時点でGoogle Cloudのリリースノートとドキュメントに掲載されていた記述です。クラウドの機能は提供条件も名称も変わります。実装の段階では、その時点の公式ドキュメントを読み直してください。また、ここで挙げた5つの要求条件は発注時の出発点であって、それを満たせば安全になるという意味ではありません。自社の扱うデータと業務に応じて、必要な条件は増えます。
