拡大し続ける”もう一つのID”―非人間アイデンティティ(NHI)管理に企業は今から備えられるか

「NHI」とは何か

NHIとは、人間ではなくソフトウェアやシステムがリソースへアクセスするために用いられるデジタルアイデンティティの総称です。具体的には次のようなものが含まれます。

• クラウドAPIを呼び出すためのAPIキー

• アプリケーションやバッチ処理が使うサービスアカウント

• クラウド基盤のリソース間権限を表すIAMロール

• 外部連携時に発行されるOAuthトークン、アクセストークン

• サーバー間通信を暗号化・認証するTLS/SSL証明書

• そして近年急増している、業務を自律的に遂行するAIエージェント用の資格情報

人間のIDと決定的に異なるのは、NHIには多要素認証のような追加の本人確認手段がほとんど存在しないという点です。パスワードやAPIキーといった「知識・所持要素」一つが漏えいするだけで、そのままなりすましが成立してしまいます。攻撃者にとって、サービスアカウントやAPIキーは人間のアカウント以上に魅力的な標的となります。

NHIが急増する背景にある3つの構造変化

NHIの数が急増している背景には、次の3つの構造変化があります。

第一に、クラウド化とDXの進展です。 オンプレミス中心の時代と異なり、クラウドサービス・SaaS・マイクロサービスが縦横に連携し合う現代のシステムは、その連携の数だけAPIキーやサービスアカウントを必要とします。

第二に、CI/CDやマイクロサービスアーキテクチャの普及があります。 開発・運用の自動化が進むほど、パイプラインやコンテナ、Kubernetesクラスタの間で自動的に発行・利用される認証情報が増加します。

第三に、最も急激な変化として、生成AI・AIエージェントの台頭が挙げられます。 AIエージェントが人に代わって複数のシステムへアクセスし、タスクを自律的に実行する時代には、エージェントの数だけNHIが新たに生まれます。しかもエージェントは高速かつ広範囲に権限を行使するため、一つの資格情報の悪用が及ぼす影響範囲は人間のアカウントの比ではありません。

データでみるNHIの実態

その規模感は、業界データからも裏付けられています。

• パロアルトネットワークスの「2026 Identity Security Landscape Report」によれば、企業は平均して人間のID1つに対しNHIを109個管理しているといいます。

• 同社のUnit42の調査では2025年に発生した750件超のインシデントを分析し、そのうち87%で原因究明に複数のログ・証跡の突き合わせが必要だったと報告しています。

• 同じくパロアルトネットワークスの調査では、企業は今後12カ月でAIエージェントが85%増加し、それに伴いマシンアイデンティティも77%増加すると見込まれています（人間のIDの増加見込みは56%）。

• 業界団体であるIdentity Defined Security Alliance（IDSA）の調査でも、クラウド環境ではマシンアイデンティティが人間を50対1の比率で上回っているとされ、NHI関連の侵害を防止できると自信を持って回答した組織はわずか15%にとどまっています。同調査では、実際に発生した52件のNHI関連侵害事例も確認されています。

つまり、多くの企業にとってNHIはすでに「管理対象IDの大半」を占めているにもかかわらず、その実態を正確に把握できている組織はごくわずかというのが実情です。

すでに顕在化しているリスク ー 実際に起きたインシデントに学ぶ

NHIの管理不備は、机上の懸念にとどまらず、すでにいくつもの重大インシデントとして表面化しています。これから先、NHIの数が増え続ける以上、同様の事象はより高い頻度・より大きな規模で発生する可能性があります。

• 管理されていないOAuthアプリの悪用：レガシー化し放置されていたOAuthアプリケーションが足がかりとなり、本番環境への侵入を許した事例。

• サービスアカウント認証情報の個人アカウントへの保存：本来厳格に管理されるべきサービスアカウントの認証情報が従業員の個人アカウントに保管されており、その個人アカウントの侵害を通じて認証情報自体が窃取された事例。

• 長期間ローテーションされていないアクセストークン：有効期限や定期的な失効・更新の運用が徹底されておらず、古いトークンがそのまま悪用された事例。

これらに共通するのは、「人間のIDであれば当然行われている基本的な統制（オーナーの明確化、定期的な棚卸し、権限の見直し、認証情報のローテーション）が、NHIに対してはほとんど機能していなかった」という点です。

NHI特有の3つの構造的課題

なぜNHIはこれほど管理が難しいのでしょうか。背景には次の3つの構造的な課題があります。

1. 可視性の欠如：そもそも組織内にどれだけのNHIが存在し、どこで何にアクセスしているのかを網羅的に把握できていない企業が多いです。開発チームが必要に応じて発行したAPIキーやトークンが、台帳化されずに"野良"の状態で残っているケースは少なくありません。

2. ライフサイクル管理の不在：プロジェクト終了後や担当者の異動後、不要になったNHIの棚卸が行われず、削除されないまま「休眠NHI」として残り続けます。人間のIDであれば退職時のアカウント無効化フローが存在しますが、NHIにはそれに相当する仕組みが整備されていないことが多いです。

3. 過剰な権限付与：開発を迅速に進めるため、必要以上に高く広い権限をNHIに付与してしまう傾向があります。多要素認証などの追加防御が使えない以上、この過剰権限がひとたび悪用されれば被害は一気に拡大します。

例えば、営業支援AIエージェントに「Salesforce参照」「SharePoint参照」「Teams参照」といった権限を付与するケースを考えてみましょう。本来であれば営業部門の情報だけを参照できれば十分であるにもかかわらず、過剰な権限を付与してしまっていたために全社の情報にアクセスできる状態になっていたとすると、本来は参照できてはいけないはずの情報まで取得できてしまいます。しかもこれは人間による不正アクセスとは異なり、「正規に付与されたNHIの権限の範囲内で実行された」正常な動作として記録されるため、異常として検知することが極めて難しいという問題があります。

さらに日本企業においては、多重下請け構造による委託先・協力会社を跨いだ認証情報の受け渡しや、長年運用されてきたレガシーシステムに紐づくブラックボックス化した連携アカウントなど、独自の要因がリスクを増幅させている点にも注意が必要です。

同様に、長期間運用される基幹システムやバッチ処理向けのサービスアカウントが、オーナー不明のまま残存しているケースも少なくありません。発行当時の担当者が異動・退職しているものの、停止時の影響範囲が分からないため削除できず、長期間放置される「休眠NHI」となっている例も見られます。こうしたアカウントは、定期的な棚卸しや権限見直しの対象から漏れやすく、潜在的なセキュリティリスクとなっています。

経営レベルで向き合うべき理由

NHIをめぐる問題は、現場の技術対応だけでは片づかない範囲に広がっています。

まず、規制・コンプライアンス対応の観点があります。EUのNIS2指令をはじめ、サプライチェーン全体のセキュリティ統制を求める規制が国内外で強化される中、委託先・連携先まで含めたアクセス管理の実効性が問われるようになっています。国内でも、経済産業省の「サイバーセキュリティ経営ガイドラインVer3.0」がサプライチェーン全体を含めたリスクマネジメントを経営者が取り組むべき重要事項の一つに位置付けているほか、個人情報保護法が求める安全管理措置やインシデント発生時の報告義務は、サービスアカウントやAPIキーの管理不備を起点とした不正アクセスにも及びます。「規制対応はまだ先の話」と考えている組織こそ、早めに現状把握に着手する価値があるでしょう。

また、インシデント発生時の影響範囲とコストも見過ごせません。NHIは人間より広範な権限を持ち、かつ24時間365日稼働し続けることが多いため、侵害された場合の被害拡大速度は人間のアカウントの比ではありません。原因究明にも複数の証跡突合を要し、対応コストと復旧までの時間も増大する傾向にあります。

さらに、AIエージェント導入の前提条件としての側面も重要です。業務効率化のためにAIエージェントの活用を検討する企業は多いですが、エージェントに与える権限とアクセス範囲を適切に統制する基盤がなければ、効率化への投資がそのままセキュリティリスクの拡大に直結してしまいます。NHI管理は、AI活用を安全に進めるための土台でもあります。

対応の進め方――4段階のステップ

NHI対策は、次の4段階で段階的に進めることが現実的です。

1. 可視化：まず自社環境に存在するNHI（APIキー、サービスアカウント、証明書、トークン等）を検出し、棚卸しします。

2. リスク分析：検出したNHIについて、権限範囲・利用状況・最終利用日時などから課題の優先順位や対処方法を定義します。

3. ライフサイクル管理：発行から失効・更新・削除までのプロセスをできる限り自動化し、「誰が・いつ・何のために発行したか」を追跡可能な状態にします。

4. 継続的な保護：アクセスコンテキストの評価や異常検知の仕組みを組み込み、平時からの監視体制を構築します。

NHI可視化の始め方

「まず可視化から」と言われても、何から着手すべきか迷う企業は少なくありません。現実的な最初の一歩として、次のような進め方が考えられます。

• 対象範囲を絞り込む：全社一斉の棚卸しはハードルが高いため、まずは本番環境のクラウドリソースや外部SaaS連携、決済系システムなど、影響度の大きい領域から着手します。

• 既存の情報源を洗い出す：クラウドプロバイダのIAMコンソールやSecrets Manager、APIゲートウェイのログ、CI/CDパイプラインの認証情報ストアなど、すでに社内に存在する情報を集約するところから始めます。ゼロから台帳を作るのではなく、散在する情報をつなぎ合わせる方が現実的です。

• 台帳化しオーナーを明確にする：発見したNHIについて「誰が・いつ・何の目的で発行したか」を記録します。オーナーが特定できないNHIは、それ自体を要注意対象としてフラグを立てておくことが重要です。

• 専用ツールの活用を検討する：手動での棚卸しには限界があるため、クラウド環境やSaaS連携先を自動的にスキャンし、NHIを検出・分類するNHI専用の可視化・管理ツールの導入も選択肢に入れます。

• 棚卸しを一度きりで終わらせない：可視化は単発のプロジェクトではなく、新規発行や失効のたびに更新される「生きた台帳」として運用し続けることで初めて実効性を持ちます。

自社にとって最もリスクの高い領域から小さく始め、そこで得られた知見をもとに対象範囲を広げていくアプローチがお薦めです。

重要なのは、完璧な一元管理を最初から目指す必要はないという点です。まずは可視化――「自社にどれだけのNHIが存在するか」を把握することから着手するだけでも、リスクの所在は明確になります。

まとめ：”もう一つのID”に、今から向き合うために

本記事では、規模感・構造的な課題・実際のインシデント事例を通じて、NHI管理が既に経営レベルで向き合うテーマとなっていることを見てきました。

NHIは、クラウド化・DXや生成AI活用が進むほど増え続け、自然に減っていくことはない領域です。人のIDを守る仕組みが一定の成熟を見せた今こそ”もう一つのID”であるNHI管理に着手すべき時期にきているのではないでしょうか。

対応を先送りにすればするほど、可視化すべきNHIの数も、放置された休眠アカウントの数も増えていきます。まずは自社にどれだけのNHIが存在するのかを把握するところからはじめることが、将来の大きなリスクを防ぐための最も確実な近道です。

出典・参考情報

• 2026　Identity Security Landscape

• Outnumbered and Underprotected: The Hidden Risk of Non-Human Identities – Identity Defined Security Alliance (IDSA)