鍵を守っても『誰が使ったか』は分からない——AIエージェントの『なりすまし』を防ぐID設計

「同じAPIキーを、5つのエージェントで使い回していた」という現場

その企業では、社内で作られたAIエージェントが5つ稼働していました。見積もり作成、在庫確認、日報の要約、問い合わせの一次対応、そして経費精算の下書き作成です。担当者に「それぞれ別のクレデンシャルで動いていますか」と聞くと、少し間があってから「たぶん、最初に作ったキーをコピーして使い回しています」という答えが返ってきました。

理由を聞くと、拍子抜けするほど単純でした。最初の1つを動かすときに発行したAPIキーが、そのまま次のエージェントのテンプレートにも貼り付けられていたのです。悪意はなく、単に「動くから、そのまま使った」だけでした。ですが、この状態で異常なアクセスが検知されたとき、ログに残るのは「このキーが使われた」という事実だけで、「5つのうちどのエージェントが」までは分かりません。

結局その企業では、5つのエージェントをいったんすべて停止し、1つずつ個別に立ち上げ直しながら挙動を確認するという、遠回りの調査を強いられました。原因は最終的に、経費精算の下書き作成エージェントが、想定外の外部APIへ問い合わせを繰り返していたことだと判明しました。ですが、この特定作業に丸2日かかっています。もし5つのエージェントがそれぞれ別のクレデンシャルで動いていれば、ログを見た瞬間に原因は絞り込めていたはずです。私たちが痛感したのは、鍵が1本にまとまっていること自体が、調査のスピードを直接落とすという事実でした。

鍵を守っても解決しない、もう一つの問題

私たちは前回の記事で、APIキーを「渡さない設計」「短命化」「使い回さない設計」についてお伝えしました。鍵そのものを堅牢にすることは、間違いなく重要な一歩です。ですが、鍵を何重にも守っても、その鍵を握っている「誰」が複数いる状態では、統制は完成しません。

これは人間の世界に置き換えると分かりやすくなります。オフィスの入館証を1枚だけ発行し、複数の社員で使い回している状態を想像してください。入館ログには「入館証Aが使われた」としか残らず、実際に誰が入ったのかは分かりません。鍵の管理がどれだけ厳重でも、この「共有」がある限り、個人の行動には責任が紐づきません。AIエージェントの世界でも、まったく同じことが起きています。

「非人間アイデンティティ(NHI)」というカテゴリの誕生

海外のセキュリティ業界では、この課題に対応する考え方が急速に広がっています。「非人間アイデンティティ(NHI: Non-Human Identity)」です。サービスアカウント、API、そしてAIエージェントなど、人間以外の主体がシステムにアクセスする際に使うデジタルな身元のことです。

Security Boulevardの分析記事によると、Gartnerは2026年末までに企業アプリケーションの40%がタスク特化型のAIエージェントを含むようになると予測しています。同記事が引用するIBMの2025年報告書では、AIモデルやアプリケーションの侵害を経験した組織のうち97%が、そもそもアクセス制御を欠いていたことも明らかになっています。これは私たちの現場感覚とも一致します。エージェントが増えるほど、身元を個別に管理する仕組みが後回しにされがちです。

見えないところで増え続ける「非人間」たちの数

非人間アイデンティティの数は、すでに人間の従業員数を大きく上回っているという指摘もあります。1人の社員が使うツールの裏側には、連携用のAPIキー、自動化スクリプト、そして今はAIエージェントが何層にも積み重なっています。1つの業務を効率化するたびに、人間には見えない身元が静かに増えていく構造です。

私たちの現場経験では、この増加スピードに気づくのは、たいてい何かトラブルが起きた後です。棚卸しをして初めて「こんなに動いていたのか」と担当者が驚く場面を、私たちは何度も見てきました。前回の記事でお伝えした台帳作りは、この「見えない増加」を可視化する第一歩でもあります。ただし台帳に載せるだけでは、身元が個別に分かれているかどうかまでは保証されません。台帳の1行1行に「このエージェントは固有のIDを持っているか」という確認を添えて初めて、増加そのものに統制が効き始めるというのが私たちの考えです。

AIエージェントは「人間」でも「旧来のNHI」でもない

厄介なのは、AIエージェントが従来のNHI(サービスアカウントやAPIキー)とも、人間のユーザーとも性質が違う点です。サービスアカウントは決まった処理を決まった通りに実行するだけでした。ですがAIエージェントは、状況に応じて自律的に判断し、動的にアクセス先を広げていきます。人間なら不審な行動を上司が目視で気づけますが、AIエージェントの判断はログを読み解かない限り誰にも見えません。

私たちの現場経験では、この「動的さ」こそがIAM(アイデンティティ・アクセス管理)の従来の設計思想と相性が悪い部分です。人間向けのIAMは「誰が、いつ、どこからログインしたか」を軸に組まれています。ですがAIエージェントは、ログインという概念すら曖昧なまま、次々と別のサービスを呼び出していきます。既存の枠組みをそのまま当てはめようとすると、私たちの経験ではどこかで無理が生じます。

なりすましは「外部からの侵入」だけではない

「なりすまし」と聞くと、外部の攻撃者がキーを盗んで侵入する場面を想像しがちです。ですが私たちが注意すべきなりすましは、それだけではありません。社内の別のエージェントが、本来は別の役割のはずの鍵を使って越権的な操作をしてしまう「内部でのなりすまし」も同じくらい起きやすい問題です。

正直に言えば、これは意図的な攻撃よりも、設計の甘さから起きるケースのほうが多いというのが私たちの実感です。「とりあえず動くエージェントを、别の用途にも流用する」という現場判断が積み重なった結果、気づけばどのエージェントが何の権限で動いているのか、誰も正確に説明できなくなっています。海外の調査でも、悪意のある侵害のうちおよそ4件に1件がAI関連で、なりすましに類する手法が代表的な侵入経路の1つとされています。

ここで一つ、自己補足をしておきます。「内部でのなりすまし」という言葉は、誰かを疑うための表現ではありません。私たちがこの記事で伝えたいのは、性善説に頼らない設計をしておけば、誰にも疑いをかけずに済むということです。身元が個別に分かれていれば、異常が起きたときに疑われるのは特定の人ではなく、特定のエージェントの設計そのものになります。これは現場の心理的な負担を減らすという意味でも、実は効果の大きい設計だというのが私たちの見立てです。

海外の「AGENTフレームワーク」に学ぶ、5つの統制軸

海外のセキュリティ実務では、AIエージェントの身元を統制する枠組みとして、頭文字を取った5つの原則がよく紹介されています。エージェントごとに固有の暗号鍵を割り当てること。長生きする固定のシークレットではなく、その場限りの短命なクレデンシャルを発行すること。エージェントが引き起こせる被害の範囲をあらかじめ区切っておくこと。すべての操作を、最終的に責任を持つ人間まで遡れる形で記録すること。そして、役目を終えたエージェントの権限を漏れなく失効させることです。

このうち最後の「失効」は、私たちが前回お伝えした退役設計そのものです。裏を返せば、身元管理・鍵管理・退役設計は、それぞれ独立した課題ではなく、1つの設計思想の異なる側面だというのが私たちの理解です。どれか1つだけを整えても、抜け穴は残ります。

このフレームワークをそのまま日本企業に持ち込めるかというと、私たちの答えは半分イエスで半分ノーです。暗号鍵の個別割り当てや短命クレデンシャルの発行といった技術的な部分は、既存のクラウド基盤の機能をそのまま使えば実現できます。一方で「人間まで遡れる記録を残す」という部分は、技術だけでは完結しません。誰がそのエージェントの責任者なのかを組織図の上で決めておく、という地味な作業が先に必要になります。技術で解決できる部分と、組織で決めるべき部分を混同しないことが、私たちが現場で最初に伝えていることです。

私たちが自社で実践している、個別ID化という発想

私たちが自社のシステムでシークレットをVaultへ移行した際、平文で展開せずメモリ内だけで処理する形に切り替えた事例を前回お伝えしました。この移行作業の中で、機能単位でアクセス権を振り分けるロールベースアクセス制御(RBAC)を、財務経理・人事系まで含めて分離して運用する体制も同時に整えています。

エージェントについても同じ発想を適用し、権限は機能ごとに細かく分け、どのエージェントが何にアクセスできるかを一目で追える状態を保つようにしています。加えて、SECURITY DEFINER関数へのanon権限が自動付与されてしまう設定ミスを自社運用の中で検出し、封鎖した経験もあります。誰の権限でもない「抜け道」は、作ろうと思って作られるのではなく、こうした設定の隙間から静かに生まれるものだというのが私たちの実感です。

私たちは同じ時期に、テナント間でデータが漏れる経路をRAGの構成の中から検知し、是正した経験もあります。原因をたどると、複数の顧客のデータを扱う仕組みの中で、どの処理がどのテナントの権限で動いているかが曖昧になっていた部分に行き着きました。これはなりすましそのものではありませんが、根っこにある問題は同じです。「誰の権限で、何が動いているか」を常に一意に特定できる設計になっていなければ、意図しない越境は静かに起こり続けます。私たちが自社のプロダクトでこうした穴を先に見つけて塞ぐようにしているのは、同じ構造の問題を顧客の環境に持ち込まないためです。

今日からできること——共有アカウントの棚卸しから

大がかりな仕組みを新設する前に、まず取り組めることがあります。社内で動いているAIエージェントを一つずつ洗い出し、それぞれが個別のAPIキー・認証情報を持っているかを確認することです。「最初の1つをコピーして使い回している」エージェントが見つかったら、それが最優先の是正対象です。

次に、そのエージェントの操作ログに「どのエージェントが」という情報が残る形になっているかを確認してください。鍵の使用履歴だけでなく、エージェント名やセッションIDまで記録されて初めて、何かが起きたときに人間まで遡れる状態になります。海外の調査では、AI関連の身元を作成する時点で追跡していない組織が16%を超えるとされています。これは裏を返せば、8割以上の組織はすでに何らかの形で追跡を始めているということでもあります。まだ手をつけていないなら、今が着手のタイミングです。

洗い出しの具体的なやり方としては、まず各エージェントの設定ファイルや環境変数を確認し、同じ文字列のAPIキーが複数箇所に登場していないかを検索するところから始められます。私たちの経験では、この単純な文字列検索だけでも、共有されているクレデンシャルの大半は見つかります。見つかったら、優先順位をつけて個別化を進めます。判断基準は、そのエージェントがどれだけ広い範囲のデータやシステムにアクセスできるかです。経費精算のような限定的な業務よりも、複数の外部サービスに接続しているエージェントのほうを先に切り分けるべきだというのが私たちの考えです。

AI-Pathの見解——身元の設計は、事故が起きてから直すには遅すぎる

私たちがこれまで支援してきた現場では、鍵の管理は比較的早い段階で整備が進みます。ですがエージェントごとの身元の分離は、後回しにされがちでした。理由は単純で、動かすことだけを考えれば、鍵を1本使い回すほうが速いからです。ですが、この速さの代償は、何かが起きたときに一気に表面化します。

誤解のないように言えば、すべてのエージェントに最初から重厚な身元管理を課す必要はありません。私たちの立場は、エージェントの数が2つ、3つに増えた時点で、鍵の使い回しをやめるタイミングだというものです。小さく始めて、増えた分だけ設計を足していく。この順番を守ることが、後からの手戻りを一番小さくします。

私たちがVibeCoding内製化の現場で繰り返し目にするのは、非エンジニアの担当者が業務の合間に作った小さなエージェントほど、この身元の分離が後回しにされているという現実です。作った本人は「自分の裁量で動かしているだけ」のつもりでも、そのエージェントが使っているクレデンシャルが、実は他の業務システムにも及ぶ権限を持っていることがあります。私たちは、内製を否定するつもりはまったくありません。むしろ内製を安全に広げるためにこそ、エージェントごとに固有の身元を持たせるという最低限のルールを、最初のうちに現場へ渡しておくべきだと考えています。

自己診断: 自社のAIエージェントは「誰か」を持っているか

ここまでの内容を、自社に当てはめてチェックしてみてください。

1. 社内のAIエージェントは、それぞれ個別のAPIキー・認証情報を持っているか。
2. 操作ログに、鍵の情報だけでなくエージェント名やセッションIDが残っているか。
3. あるエージェントの異常な挙動が見つかったとき、他のエージェントへの影響範囲をすぐに特定できるか。
4. エージェントの権限は、機能単位で細かく分離されているか。
5. 誰が、いつ、どのエージェントに新しい権限を割り当てたかの記録が残っているか。

私たちの現場経験では、5つのうち3つ以上に「いいえ」がつく企業ほど、インシデント発生時の原因特定に時間がかかる傾向にあります。逆に言えば、これらの項目はどれも、大がかりなシステム刷新をしなくても、既存のクラウド基盤の設定変更と台帳への数列追加だけで着手できる項目ばかりです。棚卸しと台帳作りが入口であるように、この自己診断も、完璧を目指すための試験ではなく、次に何から手をつけるかを決めるための地図として使っていただければと思います。

よくある質問

Q1. すでに動いているエージェントの鍵を、今から個別化するのは大変ではありませんか。 一度にすべてを切り替える必要はありません。私たちは、新しく作るエージェントから個別発行のルールを適用し、既存のエージェントは影響範囲の大きいものから順に切り替えることを勧めています。

Q2. エージェントの数が少ない(2〜3個)場合でも、個別ID化は必要ですか。 必要です。私たちの経験では、鍵の使い回しは「後で困ったときに直す」のが最も難しい部類の技術的負債です。数が少ないうちに個別化しておくほうが、後から増えたときの手間はずっと小さくなります。

Q3. 個別IDを発行すると、管理コストが増えませんか。 初期の発行作業は増えますが、運用コストはむしろ下がるというのが私たちの実感です。異常が起きたときの原因特定にかかる時間が大きく短縮されるためです。私たちが関わった案件では、発行の手順をあらかじめテンプレート化しています。クラウド基盤に標準で備わっている機能を使えば、新しいエージェントを1つ追加するたびに個別のクレデンシャルを手作業で払い出す、という運用にはなりません。仕組みさえ最初に作っておけば、日々の追加作業はほとんど増えないというのが実際のところです。

Q4. 人間の従業員のIDと同じ仕組みで管理できますか。 部分的には可能ですが、完全に同じ仕組みでは足りません。AIエージェントは人間よりも高い頻度でアクセスを要求し、判断も動的に変わるため、短命なクレデンシャルの自動発行など、エージェント特有の仕組みを組み合わせる必要があります。

Q5. 退役したエージェントのIDはどう扱うべきですか。 前回の退役設計の記事でお伝えした手順がそのまま当てはまります。個別IDを発行していれば、退役時に「どのIDを失効させればよいか」が明確になるという副次的なメリットもあります。

Q6. 個別ID化を進める順番に、決まりはありますか。 決まった正解はありませんが、私たちが現場で勧めているのは「新規は個別発行を義務化し、既存は影響範囲の大きい順に切り替える」という2段構えです。すべてを一度に洗い替えようとすると、現場の反発を招きやすく、途中で頓挫しがちです。小さな単位で成功体験を積み重ねながら進めるほうが、結果として定着しやすいというのが私たちの実感です。

まず試すなら

• 社内のAIエージェントを一つずつ洗い出し、個別のAPIキーを持っているかを確認してみること。
• 操作ログにエージェント名・セッションIDが記録されているかをチェックしてみること。
• 鍵を共有しているエージェントが見つかったら、影響範囲の大きいものから個別化の計画を立ててみること。
• それぞれのエージェントに責任者を1人ずつ割り当て、組織図の上でも身元をひも付けておくこと。誰が見ても分かる一覧にしておくこと。

鍵を守ることと、身元を分けることは、似ているようで別の設計です。どちらか一方では、統制は完成しません。エージェントの数がまだ数個のうちなら、切り替えにかかる時間は数時間から数日で収まることがほとんどです。数十、数百に増えてから同じ作業をするのとでは、負担の桁が変わります。AI-Pathでは、無償の業務プロセス診断(BPR)を実施しています。自社のAIエージェントが「誰か」を持っているか、一緒に点検してみませんか。

参考リンク

• AI Agent Identity Management: A 2026 CISO Playbook

• AIエージェントという「意思を持つNHI」のリスク