非人間ID（NHI）とは？AI時代に必須の認証・ID管理の考え方を解説

人間にはパスワードや多要素認証（MFA）、生体認証などの本人確認手段があります。では、AIエージェントやサービスアカウント、アプリケーションは、どのように「正規の主体である」と証明しているのでしょうか。

現在の企業システムでは、人間だけでなく、アプリケーション、サービス、スクリプト、コンテナ、RPA BOT、AIエージェントなどが、APIや業務システムへ自動的にアクセスしています。こうした人間ではない主体に割り当てるデジタルIDが、非人間ID（NHI：Non-Human Identity）です。

NHIは新しく生まれた仕組みではありません。サービスアカウント、アプリケーションID、証明書、APIキーなどは以前から使われてきました。ただし、クラウド化やAPI連携に加え、AIエージェントが情報の参照だけでなく判断や操作まで担うようになることで、NHIの認証・権限・監査を従来以上に厳密に管理する必要が生じています。

この記事では、NHIの基本概念、人間IDとの違い、現在使われている認証方式、方式ごとの注意点、RPA時代との違い、AIエージェント時代の管理ポイント、今後の方向性までを解説します。

NHI（Non-Human Identity）の定義

非人間ID（NHI）とは、人間以外の主体がシステムやデータへアクセスするために使用するデジタルIDの総称です。Microsoftは、NHIをアプリケーション、サービス、スクリプトなどのソフトウェアがシステムやデータへ自動的にアクセスするためのIDとして説明しています。NISTでは、これに近い概念として、サイバー空間で活動する人間ではないデジタルIDを持つ主体をNon-Person Entity（NPE）と定義しています。

NHIには、サービスアカウント、アプリケーションID、サービスプリンシパル、マネージドID、APIクライアント、RPA BOT、CI/CDパイプライン、コンテナ、IoT機器、AIエージェントなどが含まれます。製品や標準によって呼び方と対象範囲は異なりますが、「人の対話操作を前提とせず、ソフトウェアや機器がアクセスするためのID」という点が共通しています。

ワークロードID（Workload Identity）との違い

NHIは人間以外のID全般を指す広い概念です。一方、ワークロードIDは、アプリケーション、サービス、スクリプト、コンテナなど、ソフトウェアのワークロードへ割り当てるIDを指します。Microsoft Entraでは、アプリケーション、サービスプリンシパル、マネージドIDがワークロードIDとして整理されています。

そのため、ワークロードIDはNHIの一部と捉えると理解しやすいでしょう。なお、業界全体で用語が完全に統一されているわけではないため、製品を設計・比較するときは対象範囲を確認する必要があります。

AIエージェントが業務の実行主体になる

生成AIが回答や文章作成にとどまる場合、主なリスクは入力情報や出力品質でした。しかしAIエージェントは、メール、CRM、ERP、ストレージ、データベース、外部APIなどへ接続し、情報を取得・更新・送信できます。

このとき重要になるのが、「どのエージェントが」「どの目的で」「どの権限を使い」「何へアクセスしたか」を識別できることです。共有アカウントや汎用的なAPIキーだけで複数のエージェントを動かすと、操作主体を区別しにくくなります。

クラウド・API・マイクロサービスで機械間通信が増える

クラウドやマイクロサービスでは、ソフトウェア同士がAPIを介して連携します。人間が画面へログインしなくても、サービスからサービスへ処理が連鎖します。

Microsoftは、ワークロードIDを、アプリケーション、サービス、スクリプト、コンテナなどのソフトウェアが他のサービスへ認証・アクセスするために割り当てるIDとして説明しています。動的なクラウド環境では、個々のワークロードを識別し、必要なリソースだけへアクセスさせることが重要です。

NHIは気づかないうちに残りやすい

人間アカウントには入社、異動、退職という明確なイベントがあります。一方、NHIはプロジェクト、検証、システム連携のために作成された後、所有者や利用目的が曖昧なまま残ることがあります。

不要なNHIが有効なまま残る、権限が見直されない、認証情報が長期間変更されないといった状態は、攻撃や誤用の入口になります。Microsoftも、NHIは必要以上のアクセスを蓄積したり、追跡されないまま残ったりするリスクを指摘しています。

人間の認証では、本人が知っている情報、持っている端末やセキュリティキー、生体情報など、複数の要素を組み合わせられます。NHIには顔や指紋がなく、スマートフォンへ承認通知を送ることも原則としてできません。

NHIでは、秘密情報、秘密鍵、証明書、トークン、実行環境の属性などを使って、正規のワークロードであることを証明します。重要なのは、単に認証情報を渡すことではなく、その認証情報が特定のワークロード、環境、用途と結び付いていることです。

認証と認可は別の問題

• 認証：アクセスしている主体が誰か、正規の主体かを確認する
• 認可：認証された主体に、どのデータ・操作を許可するかを決める

→ NHIを正しく認証できても、過剰な権限を与えていれば安全とはいえない

APIキー・固定トークン

APIキーは実装しやすく、多くのAPI連携で使われています。利用側がキーを送信し、提供側が一致を確認するシンプルな方式です。

一方、キーを取得した主体が正規のワークロードかを追加で見分けにくく、漏えいすればなりすましに利用される可能性があります。長期間同じキーを使う、コードや設定ファイルへ直接記述する、複数処理で共有すると、影響範囲が広がります。

サービスアカウントとクライアントシークレット

サービスアカウントは、アプリやバッチ処理専用に作成するアカウントです。既存システムとの互換性が高い一方、パスワードの長期固定、複数システムでの使い回し、所有者不明、過剰権限が生じやすい点に注意が必要です。

クライアントシークレットを使うアプリケーション認証でも、シークレットを安全に保管し、期限を管理し、定期的に更新する必要があります。

OAuth 2.0と短命アクセストークン

OAuth 2.0では、認可サーバーからアクセストークンを取得し、APIへ提示します。トークンへ対象リソースや権限範囲を持たせ、有効期限を短くできる点が特徴です。

ただし、トークンが漏えいすれば有効期限内は悪用される可能性があります。また、トークンを取得するためのクライアント資格情報や署名鍵の管理も必要です。

クライアント証明書

クライアント証明書では、秘密鍵と証明書を用いてクライアントを認証します。相互TLS（mTLS）では、サーバーとクライアントが互いの証明書を検証できます。

暗号学的に強い認証を実現できますが、証明書の発行、秘密鍵保護、有効期限、更新、失効を適切に運用する必要があります。

マネージドID （Managed Identity）

マネージドIDは、クラウド事業者が資格情報の管理を支援する仕組みです。Microsoft EntraのマネージドIDはサービスプリンシパルの一種で、開発者が認証情報を直接管理する必要を減らします。

ただし、資格情報管理が自動化されても、付与するロールやアクセス範囲が適切でなければ過剰権限になります。また、利用できる環境やサービスの条件も確認が必要です。

ワークロードIDフェデレーション（Workload Identity Federation）

ワークロードIDフェデレーションは、外部の信頼できるIDプロバイダーが発行したトークンを使い、クラウド側の短命なトークンへ交換する考え方です。長期利用するクライアントシークレットを外部環境へ保存せずに済むため、シークレット漏えいのリスクを減らせます。

一方、発行元、対象主体、宛先などの信頼設定を誤ると、意図しないワークロードへアクセスを許す可能性があります。フェデレーションは「秘密をなくす」だけでなく、「誰を信頼するか」を厳密に設定する仕組みです。

SPIFFE/SPIRE

SPIFFEは、動的で異種混在する環境においてソフトウェアシステムを安全に識別するためのオープン標準群です。SPIFFE ID、暗号学的に検証可能なSVID、IDを取得するWorkload APIなどで構成されます。SPIREは参照実装です。

ワークロードの実行環境などを検証してIDを発行し、パスワードやAPIキーへの依存を減らせる点が特徴です。ただし、信頼ドメイン、証明書発行、ワークロードの登録・証明といった基盤設計が必要です。

RPAでもNHIは使われていた

RPAでも、BOT専用アカウントやサービスアカウントは使われてきました。つまり、NHI自体はAIエージェントの登場以前から存在していました。

現場では、BOTごとに専用アカウントを作る場合もあれば、担当者のアカウントを代理利用する場合、複数BOTで共通アカウントを使う場合もありました。後者ほど、操作主体の特定や権限の分離が難しくなります。

固定手順を前提に管理しやすかった

RPAは基本的に、事前に設計された画面操作やデータ処理を順番に実行します。そのため、ワークフローの変更管理、テスト、本番リリース、実行ログを中心に管理しやすい仕組みでした。

もちろん、RPAでも認証情報漏えいや過剰権限は問題です。ただし、AIエージェントのように文脈を解釈し、利用するツールや手順をその場で選ぶ範囲は限定的でした。

AIエージェントではIDの強さと行動の不確実性が重なる

AIエージェントは、入力や外部情報をもとに、次に使うツールや操作を選択できます。同じIDと権限を持っていても、毎回まったく同じ順序で動くとは限りません。

そのため、NHIを正しく認証するだけでは足りません。最小権限、実行上限、Human in the Loop、ログ、異常検知などを組み合わせ、「正規のエージェントであること」と「許可された範囲で健全に動いていること」を分けて確認する必要があります。

なりすまし

APIキー、シークレット、秘密鍵、トークンが盗まれると、第三者が正規のアプリやエージェントを装ってアクセスする可能性があります。

過剰権限による被害拡大

本来は読み取りだけでよいNHIが更新・削除・管理権限まで持っていれば、認証情報の侵害や誤動作時の影響が大きくなります。

所有者不明と休眠ID

プロジェクト終了後もNHIが残る、管理担当者が異動する、用途が分からなくなると、アクセスレビューや廃止判断ができません。

シークレットの拡散

認証情報がコード、設定ファイル、CI/CDログ、チャット、ドキュメントへコピーされると、漏えい箇所を特定しにくくなります。

監査不能

複数のアプリやエージェントが一つの共有IDを使うと、どの主体が操作したか区別できず、インシデント調査や説明責任を果たしにくくなります。

NHIを棚卸しし、所有者と目的を明確にする

最初に、どのNHIが存在し、何のために使われ、誰が責任を持ち、どのシステムへアクセスしているかを可視化します。人間IDの棚卸しだけではNHIを見落とす可能性があります。

できる限り固有のIDを割り当てる

複数のアプリやエージェントで共有IDを使い回すと、追跡性と停止単位が粗くなります。可能な範囲で、用途やエージェント単位の固有IDを用います。

静的・長期シークレットを減らす

マネージドID、ワークロードIDフェデレーション、短命トークン、証明書の自動更新など、長期固定のシークレットを持たせない方式を優先します。移行できない場合はシークレット保管、期限、ローテーション、利用監視を強化します。

最小権限と条件を設定する

認証できたNHIへ無制限の権限を与えないことが重要です。対象リソース、操作、環境、時間、ネットワーク、件数などを絞り、必要に応じて一時的な権限を使います。

ライフサイクルとアクセスレビューを運用する

作成、公開、変更、休止、廃止のイベントを管理します。所有者、目的、接続先、権限、利用実績を定期的に見直し、不要なNHIと資格情報を無効化します。

ログと異常な振る舞いを監視する

どのNHIが、いつ、どのリソースへ、どの権限でアクセスしたかを記録します。通常と異なるアクセス先、時間帯、操作量、権限利用などを検知できる状態を整えます。

高リスク操作にはHuman in the Loopを組み合わせる

NHIは「アクセス主体が誰か」を扱い、Human in the Loopは「誰が監督・承認するか」を扱います。対外送信、支払い、削除、権限変更などでは、人の承認や停止手段を組み合わせます。

NHI管理のチェックリスト

• NHIの一覧、所有者、用途を把握しているか
• 共有IDや汎用APIキーを減らしているか
• 読み取りだけでよい処理へ更新権限を与えていないか
• シークレットをコードや文書へ直接記載していないか
• 有効期限とローテーション方針があるか
• 不要なNHIを停止・削除できるか
• 操作ログから主体を追跡できるか
• AIエージェントの高リスク操作へ承認・停止を組み込んでいるか

シークレットレスと短命資格情報が中心になる

今後は、固定パスワードや長期APIキーを配布する方式から、実行時に短命なトークンや証明書を取得する方式への移行が進むと考えられます。

ただし「シークレットレス」は、信頼が不要になるという意味ではありません。どのIDプロバイダー、実行環境、ワークロード属性を信頼するかという設計がより重要になります。

実行環境の証明と継続的なアクセス判断

ワークロードのIDだけでなく、どの環境で動いているか、正規の構成か、リスクが検知されていないかといったコンテキストをアクセス判断へ使う方向性があります。

Microsoft Entra Workload IDも、ワークロードIDへの条件付きアクセス、リスク検知、アクセスレビューなどを打ち出しています。今後は、一度認証して終わりではなく、アクセスのたびに条件を評価する考え方が重要になります。

AIエージェント専用IDの管理

AIエージェントが増えると、従来のアプリケーションIDだけでは、エージェントの目的、所有者、行動、権限、ライフサイクルを十分に表現しにくい場合があります。

Microsoftは、AIエージェントのID、アクセス、ライフサイクル、保護を管理するMicrosoft Entra Agent IDを展開しています。製品仕様は変化するため公開時点で公式情報を確認する必要がありますが、AIエージェントを独立した管理対象として扱う方向性は明確です。

NHI認証だけではAIの信頼性を保証できない

NHIが正しく認証されても、そのAIエージェントのモデル、プロンプト、RAG、メモリ、接続ツール、外部データが安全とは限りません。正規のIDを持つエージェントが、汚染された情報や不正な指示に基づいて誤った操作をする可能性があります。

そのため、NHIはAIを信頼するための重要な基盤ですが、権限設計、Human in the Loop、構成管理、評価、監視、インシデント対応と組み合わせる必要があります。

NHIとサービスアカウントの違いは何ですか？

NHIは人間以外のデジタルID全般を指す広い概念です。サービスアカウントはNHIの一種で、アプリケーションや常駐サービス、バッチ処理などを動かすために使われます。

NHIとワークロードID（Workload Identity）の違いは何ですか？

NHIはアプリ、サービス、BOT、機器など人間以外のIDを広く含みます。ワークロードIDは、そのうちアプリケーション、サービス、スクリプト、コンテナなどのソフトウェアワークロードへ割り当てるIDを指します。

NHIとRPAのBOTアカウントは同じですか？

RPAのBOTアカウントはNHIの一種です。ただしAIエージェントは状況に応じてツールや操作を選ぶ場合があり、固定手順のRPAよりも権限・監督・監視を厳密に設計する必要があります。

AIエージェントにはMFAのような仕組みがありますか？

人間向けMFAをそのまま使うのではなく、秘密鍵、証明書、短命トークン、ワークロードID、実行環境の証明などを組み合わせて正規のワークロードであることを確認します。

APIキーだけで運用しても問題ありませんか？

APIキーが直ちに不適切とは限りませんが、漏えい時に利用者をなりすまされる可能性があります。用途と権限を限定し、安全な保管、期限、ローテーション、監視を行い、可能なら短命トークンやワークロードIDへの移行を検討します。

マネージドID（Managed Identity）とは何ですか？

クラウド側が資格情報の管理を支援するワークロードIDです。Microsoft EntraではマネージドIDはサービスプリンシパルの一種で、開発者がシークレットを直接管理する必要を減らします。

ワークロードIDフェデレーション（Workload Identity Federation）とは何ですか？

外部の信頼できるIDプロバイダーが発行したトークンを使い、クラウド側の短命なアクセス資格情報を取得する仕組みです。長期シークレットを外部環境へ保存する必要を減らせます。

NHIを適切に管理しないとどのようなリスクがありますか？

認証情報の漏えいによるなりすまし、過剰権限、休眠ID、所有者不明、監査不能、インシデント時の影響拡大などが考えられます。

NHIがあればAIエージェントは安全ですか？

いいえ。NHIは正規の主体を認証するための基盤です。権限が適切か、Human in the Loopがあるか、モデルやRAGが汚染されていないか、異常な振る舞いがないかは別途確認する必要があります。

NHIとHuman in the Loopはどのような関係がありますか？

NHIは「そのアクセス主体は何者か」を確認し、Human in the Loopは「誰がAIを監督し、重要操作を承認するか」を定めます。両者は異なる統制であり、組み合わせて使います。

中小企業でもNHI管理は必要ですか？

組織規模よりも、利用しているクラウド、API連携、自動処理、AIエージェントの数と権限が判断基準です。まずNHIの棚卸し、所有者、用途、権限、認証情報の保管状況を確認します。

NHI管理は何から始めればよいですか？

サービスアカウント、アプリケーションID、APIキー、証明書、BOT、AIエージェントを一覧化し、所有者、用途、接続先、権限、有効期限、利用実績を確認します。その後、共有・長期シークレットと不要な権限から優先的に見直します。

非人間ID（NHI）とは、アプリケーション、サービス、スクリプト、BOT、AIエージェントなど、人間以外の主体がシステムやデータへアクセスするためのデジタルIDです。

NHIはAI時代に突然現れた概念ではありません。サービスアカウントやRPA BOTとして以前から存在していました。しかし、クラウド、API、マイクロサービス、AIエージェントによって数と権限範囲が拡大し、従来の固定資格情報や共有アカウント中心の運用では管理しにくくなっています。

重要なのは、NHIを発行することだけではありません。所有者と目的を明確にし、固有ID、短命な資格情報、最小権限、アクセスレビュー、ログ、停止・廃止までを継続的に管理する必要があります。

また、NHIは「その主体が本物か」を確認する基盤ですが、AIエージェントが健全に動いていることまで保証するものではありません。権限設計、Human in the Loop、評価、監視と組み合わせることで、AIエージェントを信頼して運用するための基盤になります。

参考情報
https://www.microsoft.com/en-us/security/business/security-101/what-are-non-human-identities
https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview
https://www.microsoft.com/en-us/security/business/identity-access/microsoft-entra-workload-id
https://learn.microsoft.com/en-us/defender-xdr/investigate-non-human-identities
https://csrc.nist.gov/glossary/term/non_person_entity
https://www.nist.gov/identity-and-access-management
https://spiffe.io/docs/latest/spiffe-specs/