ノンヒューマンアイデンティティ（NHI）とは？機械IDの管理・リスクと実装者向けの守り方を解説【2026年時点】

ノンヒューマンアイデンティティ（NHI／非人間アイデンティティ）は、人が操作しないソフトウェアや機械に割り当てられるデジタルIDの総称です。サービスアカウント、APIキー、アクセストークン、シークレット、TLS証明書、OAuthアプリケーションなどが該当し、システム同士が自動でやり取りするときの「誰が」を担います。クラウドとマイクロサービス、そして自動化やAIエージェントの広がりとともにその数は人のアカウントを数十倍に上回る規模へ膨らみ、放置された資格情報が侵害の入口になる事例も後を絶ちません。この記事では、NHIの定義と種類、増殖が生むリスク、シークレット管理や短命な資格情報といった守り方、そして受託開発で自社システムにNHI管理を組み込むときの判断を、実装する側の視点で整理します。

まとめ：NHIは人が操作しない機械のIDで、増殖と放置が攻撃面を広げる

NHIは、人のログインではなくプログラムやワークロードが認証・認可を通すために使うIDだと捉えると全体像を掴めます。APIキーやサービスアカウントは開発の現場で当たり前に発行されますが、誰が何のために作ったかの記録が残らないまま増え続け、退職者の人IDのように棚卸しの網に掛からない点が盲点になります。攻撃者にとっては、広い権限を持ったまま放置されたトークンほど狙いやすい標的はありません。

守り方の起点は、まず全数を可視化して台帳に載せ、権限を業務に必要な範囲へ絞り、資格情報を短命化して定期的に入れ替える三点に集約されます。専用のNHIセキュリティ製品を買うかどうかは検索順位やベンダーの宣伝ではなく、自組織で動く機械IDの数と散らばり具合が判断の軸です。IDが一つの基盤に収まり手作業の棚卸しで足りる段階なら、まずシークレット管理と最小権限設計を固めるほうが投資が生きます。逆にクラウドとSaaS、CI/CDやAIエージェントにIDが分散し、誰も全体像を把握できていない組織ほど、可視化そのものが最初の成果になります。

NHIの定義と代表的な種類＝人が操作しない機械の資格情報の全体像

NHIという言葉は Non-Human Identity の頭文字で、日本語では非人間アイデンティティや機械IDとも呼ばれます。人が画面からログインするのではなく、コードやサービスが別のサービスへアクセスするために使うIDを幅広く含む傘概念だと理解すると、個々の技術要素が一枚に整理できます。

NHIという言葉の意味と人のアイデンティティとの本質的な違い

人のアイデンティティは、従業員や顧客といった生身の利用者に結び付き、パスワードや多要素認証で本人確認をします。対してNHIは、アプリケーションやスクリプト、コンテナ、IoT機器などに割り当てられ、キーやトークンといった資格情報そのものが本人確認の代わりになる点が特徴です。人のIDが入退社に合わせて発行と削除の運用に乗るのに対し、NHIは開発の途中で必要に応じて量産され、ライフサイクルの管理者が曖昧なまま残りやすい性質を持ちます。この「持ち主が人ではない」という一点が、後述するリスクの根っこになります。

サービスアカウント・APIキー・トークン・証明書などNHIの類型

実装の目線でNHIを分解すると、いくつかの代表的な類型に落ちます。サーバーやバッチ処理に紐づくサービスアカウント、外部APIを呼ぶためのAPIキー、認可を担うアクセストークンやリフレッシュトークン、通信を保護するTLS証明書、システム間連携を許可するOAuthアプリケーション、そしてデータベースの接続情報やパスワードといったシークレットです。下表に主な類型と使われ方をまとめます。いずれも人の顔が見えないまま権限を持つ点が共通しており、台帳へ載せる対象として一括りに扱う発想が守りの出発点になります。

人のIDを数十倍に上回る増殖の背景＝クラウドと自動化とAIエージェント

NHIが問題として立ち上がってきた背景には、環境そのものの変化があります。オンプレミス中心の時代は機械IDの数も限られていましたが、クラウドへ移りマイクロサービスへ分割し、CI/CDで自動デプロイを回す構成が広がると、サービスごと・パイプラインごとに資格情報が増える一方です。2020年代半ばの各社調査では、NHIの数が人のアカウントをおおむね数十対1、環境によっては45〜50対1系の比率で上回るとされます。さらに自ら判断して他システムへアクセスするAIエージェントが加わると、機械が機械の資格情報を発行する連鎖も生まれ、増殖の勢いを一段と押し上げる要因です。数が増えるほど手作業の棚卸しは破綻し、可視化を自動化する必要へつながります。

NHIが生むセキュリティリスクとOWASP Top10が示す類型

NHIの危うさは、単に数が多いことではなく、権限を持ったまま管理の網から外れやすい構造にあります。ここでは実務で繰り返し表面化するリスクを、外部の整理も引きながら三つの角度で押さえます。

シークレットの漏洩・ソースコードへのハードコード・使い回しの危険

最初に挙がるのが資格情報そのものの漏洩です。APIキーやパスワードをソースコードに直接書き込み、そのままリポジトリへ push してしまう事故は後を絶ちません。公開リポジトリや誤設定のストレージから鍵が流出すれば、攻撃者はそのまま正規の呼び出しとしてシステムへ入り込めます。加えて、同じキーを複数のサービスで使い回すと、一つの漏洩が横展開の起点になる点も見逃せません。人のパスワードなら多要素認証が二段目の壁になりますが、機械の資格情報は鍵を握った側がそのまま通ってしまうため、漏洩の一撃が重くのしかかります。

過剰な権限と休眠した資格情報が残るオフボーディング漏れの構造

次に、権限とライフサイクルの問題があります。開発を急ぐ現場では、動かすことを優先して広めの権限をサービスアカウントへ与えがちで、後から絞り直されないまま過剰な権限が固定化しがちです。加えて、役目を終えたトークンや連携用アカウントが削除されず休眠状態で残り、誰も監視しない鍵が環境に溜まっていきます。人の退職時に相当するオフボーディングの仕組みが機械IDには整っていないことが多く、この抜けこそ攻撃者に狙われやすい弱点です。最小権限の原則を機械IDへも適用し、使われない資格情報を定期的に失効させる運用が防御の軸になります。

OWASP Top 10 NHIリスクと侵害統計が示す優先順位

こうしたリスクは、外部のフレームワークでも体系化が進んでいます。2025年に公開されたOWASPのNon-Human Identities向けTop10は、シークレットの漏洩や過剰な権限、長寿命のシークレット、脆弱な認証といった項目を並べ、機械IDに固有の弱点を整理しました。国内の調査報道でも、NHIに関わる侵害を経験した組織が半数近くにのぼるという結果が伝えられています。攻撃経路の統計を見ても、資格情報の悪用は侵害の主要な入口であり続けており、NHIの棚卸しと権限の適正化は後回しにできない領域として位置づけられます。優先順位に迷うときは、まず広い権限を持つ長寿命の資格情報から手を付けると効果が出やすい構造です。

NHIを守る技術的アプローチ＝可視化・権限の縮小・資格情報の短命化

NHIの守り方は、可視化・権限の縮小・資格情報の短命化という三本柱を、既存のID防御層と組み合わせて形にします。ここでは実装の具体像を、代表的な仕組みに沿って見ていきます。

シークレット管理とローテーション＝Vault・Secrets Managerの利用

入口になるのがシークレット管理です。APIキーやパスワードをコードや設定ファイルに直書きするのをやめ、HashiCorp Vaultやクラウド各社のシークレットマネージャーへ集約し、アプリは実行時に取得する形へ切り替えます。これにより資格情報が一元管理され、定期的なローテーション（入れ替え）も自動化できる仕組みです。鍵の保管場所を一箇所に絞れば、漏洩時の失効や再発行も素早く回せます。まずリポジトリからシークレットを排除し、集中管理へ寄せるところが取り組みの起点になります。

短命な資格情報とワークロードアイデンティティ連携でキーを持たせない

より進んだ守りは、長寿命の鍵そのものを持たせない設計です。静的なAPIキーの代わりに、実行のたびに数分〜数時間で失効する短命なトークンを発行し、用が済めば自動で切れるようにします。クラウドでは、ワークロードが自身の実行環境を証明して権限を受け取る仕組みが用意されており、鍵をファイルに置かずに認証を通せる点が肝です。この考え方は、実行環境に紐づくIDで認証するWorkload Identity（その仕組みと基本概念）の解説と合わせて読むと、機械IDから静的な鍵を減らす道筋が具体的に描けます。短命化は、漏洩しても使える時間を縮める点で被害の上限を下げる打ち手になります。

棚卸しと可視化＝ISPM・ITDRとの連携でNHIを監視下に置く

個別の鍵を守るだけでなく、全数を台帳に載せて監視下へ置く層も土台になります。IDの姿勢を静的に点検するISPM（ITDRとの違いとID姿勢管理の仕組み）は、人のアカウントと並べて非人間アイデンティティも棚卸しし、過剰権限や休眠状態を弱点として拾い上げる役です。一方、資格情報が実際に悪用された兆候をリアルタイムに捉えるのが動的検知の役割で、認証の異常を追うITDR（EDRとの違いと検知の仕組み・導入判断）がその守りを担います。攻撃される前の弱点を静的に減らすISPMと、突破後の兆候を動的に捕まえるITDRを対で置くと、NHIを予防と検知の両面から囲い込めます。こうした最小権限と継続検証の発想は、誰も無条件に信頼しないゼロトラスト（境界型防御との違いとNIST7原則）の思想とも地続きです。

受託開発でNHI管理を組み込む判断＝採用条件と見送りの線引き

NHIは新しい領域のため、専用のセキュリティ製品を導入すべきか、自社システムに管理の仕組みを作り込むべきかで迷いやすい対象です。判断は流行ではなく、自組織で動く機械IDの数と散らばり、そして是正を回す運用体制で決めます。

専用のNHIセキュリティ製品を採用すべき条件＝散らばったIDの母数

専用製品の費用対効果が出るのは、機械IDが複数の基盤に散り、手作業の棚卸しが追いつかなくなった段階です。クラウドとSaaS、CI/CDやコンテナ基盤に資格情報が分散し、サービスアカウントとトークンが数百から数千の規模で動いている、発行元や用途をたどれない鍵が積み上がっている、といった条件が揃えば、自動で全数を発見して権限とリスクを採点する製品の価値が高まります。とりわけAIエージェントが機械IDを自ら発行し始める環境では、人手の追跡が原理的に破綻するため、可視化の自動化が土台になります。

自前のシークレット管理と最小権限設計だけで足りる見送りの場面

一方、専用製品を見送ってよい場面もあります。IDプロバイダーとクラウドが一つに集約され、サービスアカウントが数十規模で、既存のシークレット管理と権限レビューが機能しているなら、まずは自前の仕組みを固めるほうが投資に見合う判断です。Vaultなどでシークレットを集中管理し、短命なトークンへ寄せ、最小権限を徹底する運用が回っていれば、専用製品に踏み込む前段としては十分に守れます。母数が小さいうちに設計の型を作っておくと、後で数が増えたときの移行もなめらかに進みます。

受託開発でNHIの棚卸しと最小権限を設計へ組み込むための指針

受託開発の現場では、機能を作り込む段階からNHIの扱いを設計に織り込むと、後追いの是正コストを抑えられます。新しいサービスアカウントやAPIキーを起こすときに用途と権限範囲、失効の条件を台帳へ記録し、シークレットは集中管理へ寄せ、可能な限り短命な資格情報で認証を通す。こうした型を初期設計へ埋め込む作業は、AIエージェントや自動化基盤が抱える機械IDの棚卸しと最小権限設計を含めて、AIセキュリティ対策の受託として組み込みから支援できます。運用が始まってからではなく、作る段階でNHIを可視化下に置くことが、増殖に飲まれない設計につながります。

よくある質問

NHIの位置づけや守り方について、選定や実装の現場で挙がりやすい質問に答えます。

ノンヒューマンアイデンティティと人のアイデンティティは何が違うのですか？

持ち主が人かどうかが違います。人のIDは従業員や顧客に結び付き、パスワードや多要素認証で本人確認をする点が前提です。NHIはアプリケーションやサービス、機器に割り当てられ、APIキーやトークンといった資格情報そのものが本人確認の代わりになります。人のIDが入退社に合わせて発行と削除の運用に乗るのに対し、NHIは開発の途中で量産され、ライフサイクルの管理者が曖昧なまま残りやすい点が守りの難しさになります。

NHIはなぜ人のアカウントより数が多いのですか？

クラウドと自動化が進んだためです。マイクロサービスへ分割し、CI/CDで自動デプロイを回し、外部SaaSと連携する構成では、サービスやパイプラインごとに資格情報が増えます。各社の調査では、NHIが人のアカウントを数十対1の比率で上回る環境も珍しくありません。自ら他システムへアクセスするAIエージェントが加わると、機械が機械の鍵を発行する連鎖も生まれ、増殖の勢いはさらに強まります。

NHIの管理で最初に手を付けるべきことは何ですか？

可視化と権限の縮小です。まず環境に散らばるサービスアカウントやAPIキー、トークンを洗い出して台帳へ載せ、全数を把握します。次に、広い権限を持つ長寿命の資格情報から順に権限を業務範囲へ絞り、使われていない鍵を失効させる順序が扱いやすいはずです。シークレットをコードから排除して集中管理へ寄せるところまでを最初の区切りにすると、以降の是正が進めやすくなります。

シークレット管理ツールを入れればNHI対策は十分ですか？

入口としては有効ですが、それだけでは足りません。Vaultやシークレットマネージャーは鍵の集中管理とローテーションを担いますが、過剰な権限の是正や休眠アカウントの棚卸し、悪用された兆候の検知までは守備範囲が別です。シークレット管理を土台に、ISPMで姿勢を点検し、ITDRで異常を検知する層を重ねると、予防と検知の両面で機械IDを囲い込めます。

AIエージェントの普及はNHI管理にどう影響しますか？

管理の難度を押し上げます。AIエージェントは自ら判断して他システムやAPIへアクセスするため、動作のために機械IDを必要とし、場面によっては新たな資格情報を自動で発行する存在です。人手の追跡が原理的に追いつかなくなるため、発行と権限付与を記録に残し、短命な資格情報で認証を通し、全数を自動で可視化する仕組みが前提になります。エージェントを組み込む設計の初期からNHIの扱いを織り込むと、後追いの是正を避けられます。

関連記事

• ISPMとは？ITDRとの違いとID姿勢管理の仕組み・導入判断を実装者向けに解説：NHIを人のアカウントと同じ台帳に載せ、過剰権限や休眠状態を静的に点検する姿勢管理の記事です。
• ITDRとは？EDRとの違い・検知の仕組みと導入判断を実装者向けに解説：NHIの資格情報が悪用された兆候を、認証の異常からリアルタイムに検知して対応する対の仕組みです。
• ゼロトラストとは？境界型防御との違い・NIST7原則と導入判断を解説：機械IDへも最小権限と継続検証を求める、NHI管理の土台になる防御思想を整理した記事です。