AIエージェント時代の非人間ID管理

AIエージェント時代に非人間ID管理が新しい管理対象になったのは、ソフトウェアや自動化処理が、人の代わりにAPIキー、トークン、証明書、サービスアカウントを使って業務システムへアクセスするようになったからです。OktaはNHIをサービスアカウント、APIキー、トークン、AIエージェントまで含む広い概念として扱う一方、マイクロソフト や グーグル は「ワークロードID」「サービスアカウント」をより技術寄りの狭い概念として整理しています。さらに、米国国立標準技術研究所 と 米国サイバーセキュリティ・インフラ安全保障庁 のゼロトラスト文書は、サービスアイデンティティや非人間エンティティを明示的に管理対象へ組み込んでいます。要するに、非人間ID管理は秘密情報の保管だけでなく、「何が、どの権限で、誰の責任で、どこへアクセスするか」をライフサイクルで管理するテーマです。 

導入：いま何が起きているのか

まず定義から整理します。Oktaの公式説明では、非人間IDにはサービスアカウント、APIキー、トークン、さらにAIエージェントまで含まれます。一方でGoogle Cloudの公式文書はサービスアカウントのライフサイクル管理を前面に出し、Microsoft Entraはアプリケーション、サービスプリンシパル、マネージドIDをワークロードIDとして扱っています。つまり現場では、「NHI」は市場や統制の広い概念、「ワークロードID」はその中の実行中ワークロードに近い技術概念、と理解すると混乱が減ります。 

いま注目度が上がっている理由は、AIエージェントが会話するだけのツールから実際に行動する主体へ変わってきたためです。OktaのAIエージェント関連文書では、利用者がOAuth 2.0のトークンや権限をAIエージェントへ与え、管理アプリや業務アプリの中で代理実行させる状況が前提になっています。Google Cloudは2026年4月更新の脅威検知文書で、AIエージェントのサービスアカウント資格情報が不正利用された可能性を検知するシナリオまで公開しました。AIエージェントは、もはやAI機能ではなく、権限を持つ実行主体として扱う必要があります。 

ここで読者が誤解しやすい点を先に解きます。APIキーやトークンは、厳密にはIDそのものではなく「IDを表現・証明する資格情報」と見る方が技術的には自然です。ただし市場では、Oktaのように資格情報まで含めてNHIの管理対象として扱うベンダーが増えています。AIエージェント時代には、実行主体と資格情報と権限が一体で増えるため、「どちらが本体か」よりも「その束をだれが管理し、いつ失効させるか」が実務上の本題になります。 

技術と産業の全体像

非人間ID管理を一言で言えば、「人以外のソフトウェア主体を、作成から廃止まで管理すること」です。OktaのNHIライフサイクル説明では、対象にサービスアカウント、APIキー、トークン、証明書、AIエージェントが含まれ、管理内容としてプロビジョニング、アクセスガバナンス、継続監視、廃止までが示されています。Google Cloudのサービスアカウント文書も、作成、利用、監視、無効化、削除までを明示しています。つまり本質は、単発の認証方式ではなく、ライフサイクル全体の統制です。 

この分野を理解するうえで便利な整理軸は4つあります。
第一に主体で、サービスアカウントやアプリ、AIエージェント、ワークロードそのものです。
第二に資格情報で、APIキー、トークン、秘密情報、証明書です。
第三に権限で、どのAPIやデータへ何ができるかというポリシーです。
第四に責任者で、Oktaや SailPoint が強調するように、そのNHIを説明できる人間のオーナーです。
これは、従来の「ID管理」「PKI管理」「シークレット管理」が別々だったものを、ひとつの管理線でつなぐ見方です。これは解釈ですが、現場でいちばん役に立つ視点です。 

技術面では、業界全体が「長寿命の固定キー」から「短寿命の動的資格情報」へ移っています。Microsoft EntraのマネージドIDは開発者が資格情報を自前で管理しなくてよい設計で、Google CloudのWorkload Identity Federationはサービスアカウントキーの代わりにフェデレーテッドIDを使うことを推奨しています。Amazon Web Services のIAM Roles AnywhereはX.509証明書を使って一時的な認証情報を発行し、HashiCorp のVaultはデータベース資格情報やX.509証明書を動的に払い出します。固定キーをばらまくより、必要な時だけ短く発行する方が安全で運用もしやすい、という方向です。 

証明書も、もはやWebサーバーだけの話ではありません。AWSはX.509証明書を使った一時認証を案内し、Vaultは短いTTLの動的証明書で各インスタンスに固有の証明書を与えられると説明しています。さらに、SPIFFE標準ではSVIDが「ワークロードが自分のIDを相手へ暗号学的に伝える仕組み」と定義されています。証明書管理とワークロードID管理は、AIエージェント時代には別分野ではなく、かなり近い場所まで寄ってきています。 

このトレンドを動かす成長ドライバー

最大の成長ドライバーは、クラウドネイティブ化と自動化です。NISTのゼロトラスト文書は、クライアントのIDにユーザーアカウントだけでなくサービスアイデンティティや自動タスクの認証要素が含まれると明記しています。2025年公開のAPI保護ガイドでも、APIゲートウェイは呼び出し元のサービスとエンドユーザーの双方を認証・認可するべきだと整理され、APIキー、証明書、JWT、SPIFFE IDなど複数資格情報の正規化が論点になっています。アプリ同士、サービス同士、エージェント同士が話す時代には、非人間IDが増えるのは自然な流れです。 

二つ目のドライバーは、漏えいと過剰権限の現実です。GitHub は2025年4月の公式ブログで、2024年だけで3900万件超のシークレットがGitHub上で漏えいしたと公表しました。OWASP のNHI Top 10でも、Improper Offboarding、Secret Leakage、Overprivileged NHI、Long-Lived Secrets、Human Use of NHIが主要リスクとして整理されています。要するに、問題は「IDが増えたこと」だけではなく、「棚卸しされず、長く残り、権限が強すぎること」です。 

三つ目のドライバーがAIエージェントです。Oktaは、ユーザーがAIエージェントへOAuth権限を付与し、管理下・非管理下アプリの双方で代理操作させることを前提に、シャドーAIエージェントの発見機能まで用意しています。Google Cloudの脅威検知も、AIエージェントによるサービスアカウントの調査、不正なトークン生成、データ引き出しなどを個別シナリオとして公開しています。AIエージェントは、NHIの追加例ではなく、NHI管理を一段難しくする加速装置です。

世界の競争地図

市場の見方は一つではありませんが、拡大方向はかなり明確です。MarketsandMarkets は2026年2月公表の市場見通しで、NHI access management市場が2024年の94.5億ドルから2030年に187.1億ドルへ伸びると予測しています。これは公的統計ではなく民間調査の推計なので絶対額は慎重に見るべきですが、少なくとも「NHIが独立した予算カテゴリとして立ち上がっている」ことは示しています。さらにOktaは2026年の年次報告書で、NHIとAIエージェントを統合コントロールプレーンの長期機会と明記しました。 

競争の主戦場は、領域単位で見るとわかりやすいです。
第一の領域はハイパースケーラーの実行基盤で、Microsoft Entra、Google Cloud IAM、AWS IAMが、鍵レス化や一時資格情報、サービスアカウント運用を押し進めています。
第二はIDガバナンス領域で、OktaやSailPointが人間IDと非人間ID、さらにAIエージェントを同じガバナンスに乗せようとしています。
第三はマシンアイデンティティ領域で、CyberArk と Venafi、HashiCorpのように証明書、シークレット、ワークロードIDを中心に強みを持つ陣営です。
第四はSPIFFEのようなオープン標準で、クラウドネイティブ基盤そのものに短命なワークロードIDを埋め込む流れです。 

地域で見ると、米国 はNIST、CISA、ハイパースケーラー、主要ベンダーが集中する「定義と実装」の中心です。
欧州連合 は、NIS2の実装を支える 欧州連合サイバーセキュリティ機関 の技術ガイダンスに見られるように、「規制と実務証跡」の側から市場を動かしています。
中東欧やアジアを含む各地域でも導入は進みますが、当面の争点は「どこの国が強いか」より、「誰が実行主体・資格情報・権限・所有者を一つの画面とポリシーで結べるか」です。

業界再編も進んでいます。CyberArkは2024年10月にVenafiの買収完了をSEC提出資料で公表し、機械ID管理を自社のアイデンティティセキュリティに統合する動きを明確にしました。
SailPointも日本語ページで、サービスアカウント、ボット、RPAの可視化、所有者設定、ライフサイクル制御、自動ガバナンスを前面に出しています。
つまり市場は、単機能製品の横並びから「人間・マシン・AIをまたぐ統合プラットフォーム」へ寄りつつあります。 

日本の現在地

日本 では、NHIという用語そのものより、隣接領域から実務が先に進んでいます。デジタル庁 のゼロトラスト方針概要は、識別対象としてアカウント、デバイス、サービス、データを挙げ、アクセス制御ポリシーで評価し、ログを観測することを基本方針にしています。これは、非人間ID管理の考え方とかなり近いです。つまり日本の公的文脈では、NHI専用政策というより、ゼロトラストの一部として土台が整えられている段階だと見た方が実態に近いです。 

AIとの関係では、情報処理推進機構 が2026年4月公開の「AI利用者のためのセキュリティ豆知識」で、クラウドAIへ営業秘密を入れない、AIブラウザを社内用と社外用で分ける、RAGの混在リスクに注意するといった初歩対策を示しています。これはNHI管理そのものではありませんが、AIエージェントやAI連携が企業システムへ入るとき、認証情報、接続先、利用境界を明確にする必要があることを示す実務資料です。AI活用とID管理を別物として扱えない、という点では重要です。 

市場面では、日本語で公開された製品ページを見ても、目立つ選手は海外ベンダーが中心です。SailPointはマシンアカウントの所有者設定とID棚卸しを、CyberArkはシークレット、証明書、ワークロードアイデンティティ統合を、Oktaは非人間IDとAIエージェントの一元化をそれぞれ打ち出しています。したがって日本企業の現実的な勝ち筋は、国内独自名称にこだわることより、ゼロトラスト、PKI、シークレット管理、AIガバナンスを一つの運用設計へ統合できるかどうかにあります。

産業・企業・社会へのインパクト

企業への影響は大きく三つあります。
第一に、セキュリティ運用が「人のアカウント管理」中心では足りなくなります。Microsoftも、ワークロードIDはMFAができず、正式なライフサイクルを持たないことが多く、秘密情報をどこかに保存する必要があるため、ユーザーアカウントより管理が難しいと説明しています。
第二に、監査と説明責任の対象が広がります。サービスアカウントやAIエージェントに、だれが所有者で、なぜ必要で、いつ見直したかを説明できないと、セキュリティだけでなく監査にも弱くなります。
第三に、停止リスクが増えます。証明書やキーの期限切れは、侵害だけでなくサービス停止の原因にもなります。 

人材面では、IAM担当だけで完結しません。CyberArkの2025年調査では、マシンアイデンティティを安全に保つ責任はセキュリティ、開発、プラットフォームの間に分散していました。
SailPointも、所有者設定、定期レビュー、自動ガバナンスを強調しています。
つまり今後必要なのは、ID管理、クラウド基盤、PKI、シークレット管理、DevSecOps、AI利用ルールを横断して会話できる人材です。非人間ID管理は、新しい製品カテゴリであると同時に、新しい分業設計の問題でもあります。 

ボトルネックとリスク

最大のボトルネックは、「シークレット管理を入れれば終わり」という誤解です。HashiCorp Vaultが示すように、動的資格情報や動的証明書は非常に有効ですが、それだけではなぜその資格情報が存在するか、誰の責任か、権限は適切かまでは解けません。Oktaのライフサイクル説明やSailPointの所有者設計が重視しているのは、保管庫より前後のガバナンスです。保管、発行、利用、棚卸し、失効をつなげないと、ツールを増やしても根本問題は残ります。 

リスクの中身は、すでにかなり整理されています。OWASP NHI Top 10では、不適切なオフボーディング、秘密情報漏えい、脆弱な第三者NHI、過剰権限、長寿命シークレット、人によるNHIの使い回しなどが主要論点です。GitHubの3900万件超の漏えい実績は、秘密情報漏えいが理論ではなく日常的な問題であることを示しています。さらにGoogle CloudがAIエージェント専用の脅威検知シナリオを公開したことは、AIエージェント由来の権限悪用が想定外ではなくなったことを意味します。 

運用面の難しさも大きいです。CyberArkの2025年調査では、機械IDセキュリティの主要課題として、迅速な無効化と置換、所有部門の特定、利用場所の把握、正確な棚卸しが挙がり、34%は依然として手作業や非自動化の方法でライフサイクルを管理していました。AIエージェントが増えるほど、この「どこにあるかわからない」「誰のものかわからない」が深刻になります。NHI管理は、脅威対策であると同時に資産管理の再設計でもあります。 

今後のシナリオと注目ポイント

以下は推測です。
楽観シナリオでは、短寿命資格情報、ワークロードフェデレーション、動的証明書、AIエージェントの登録制が標準化し、NHI管理は「新しい例外管理」ではなく「通常のID運用」に吸収されます。
中立シナリオでは、クラウド側は鍵レス化が進む一方、SaaS連携や古いシステムでは長寿命のAPIキーや共有サービスアカウントが残り、NHI管理はしばらくハイブリッド運用になります。
慎重シナリオでは、AIエージェントがOAuth許可や共有サービスアカウントを通じて無秩序に増え、漏えい、権限肥大化、証明書停止事故が同時多発します。

分岐を見極める指標は、短寿命資格情報への移行率、AIエージェントの台帳化率、証明書寿命短縮への対応、NHI専用予算の有無、ベンダー統合と規制ガイダンスの進展です。 

よくある疑問Q&A

Q:非人間IDとマシンIDは同じですか。
A:完全には同じではありません。市場ではほぼ同義で使われることもありますが、OktaはAPIキーやトークン、AIエージェントまで含める広い定義を採り、MicrosoftやGoogleはサービスアカウントやワークロードIDをより技術的に整理しています。用語の違いより、対象範囲を文脈ごとに確認することが大切です。

Q:APIキーはIDですか、それともただの鍵ですか。
A:技術的には「資格情報」と呼ぶ方が正確な場面が多いです。ただしNHI管理では、APIキーがどの主体にひもづき、どの権限を持ち、いつ失効するかまで一緒に管理するので、広義のNHI管理対象として扱われます。

Q:サービスアカウントが社内だけで使われるなら安全ですか。
A:そうとは限りません。NISTやCISAのゼロトラスト文書は、ネットワーク内外を問わず、サービスアイデンティティや非人間エンティティも継続検証の対象に含めています。内部だから信用する、という発想は通用しにくくなっています。

Q:なぜAIエージェントで急に問題が大きくなるのですか。
A:AIエージェントは、単に情報を読むだけでなく、OAuth権限やサービスアカウントを使って実際にシステムへ書き込みや実行ができるからです。OktaはシャドーAIエージェント発見を、Google CloudはAIエージェント関連の脅威検知を正式に公開しています。

Q:最初にやるべきことは何ですか。
A:まずは棚卸しです。OktaもSailPointも、発見、所有者設定、定期レビューを最初の柱に置いています。見えていないサービスアカウントやAPIキーを減らし、「だれの責任か」を付けるだけでも、管理の質は大きく変わります。

Q:すべてのAPIキーや証明書を今すぐなくすべきですか。
A:現実的には段階対応です。Google Cloud、Microsoft、AWS、Vaultの文書が示す通り、まずは高権限・長寿命・共有利用のものから、フェデレーション、一時資格情報、動的証明書へ置き換えるのが現実的です。全面廃止ではなく、優先順位を付けた短命化が重要です。

Q:中小企業にも関係ありますか。
A:関係あります。GitHub上での大量のシークレット漏えいが示す通り、クラウドやSaaS、CI/CDを使う限り、規模に関係なく非人間資格情報は増えます。大企業向けの大掛かりな製品から始めなくても、台帳化、所有者明記、期限設定、不要キー削除だけで改善できます。

結論：何をどう見るべきか

このトレンドの本質は、AIエージェントの登場によって「人が使うIDを守る」だけでは不十分になったことです。世界の争点は、APIキー管理単体でも、証明書管理単体でもなく、実行主体、資格情報、権限、所有者をひとつのライフサイクルへ統合できるかどうかにあります。OktaがNHIとAIエージェントをコントロールプレーンの機会と位置づけ、CyberArkがVenafiを取り込み、SailPointが所有者と棚卸しを前面に出しているのは、その方向を示す動きです。 

日本企業にとっての勝ち筋は、流行語としてのNHIを追いかけることではありません。ゼロトラスト、サービスアカウント管理、証明書運用、シークレット管理、AI利用ルールを分断せず、ひとつの説明可能な運用へ束ねることです。言い換えると、AIエージェント時代の非人間ID管理とは、「ソフトウェアに与えた力を、あとから説明できる状態に戻すこと」です。ここを押さえると、このテーマは急に理解しやすくなります。 

参考

  1. National Institute of Standards and Technology, 2020, Zero Trust Architecture, NIST SP 800-207, 閲覧日 2026-04-25. https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-207.pdf
  2. National Institute of Standards and Technology, 2025, Guidelines for API Protection for Cloud-Native Systems, NIST SP 800-228, 閲覧日 2026-04-25. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-228.pdf
  3. Cybersecurity and Infrastructure Security Agency, 2023, Zero Trust Maturity Model Version 2.0, PDF, 閲覧日 2026-04-25. https://www.cisa.gov/sites/default/files/2023-04/zero_trust_maturity_model_v2_508.pdf
  4. Okta, 2026, Annual Report 2026, SEC filing, 閲覧日 2026-04-25. https://www.sec.gov/Archives/edgar/data/1660134/000166013426000020/okta-20260131.htm
  5. Okta, 2026, What is the Non-Human Identity Lifecycle?, corporate article, 閲覧日 2026-04-25. https://www.okta.com/ja-jp/identity-101/what-is-the-non-human-identity-lifecycle/
  6. Okta, 2026, Non-human identities and AI agents / Discover and assess AI agents, documentation, 閲覧日 2026-04-25. https://help.okta.com/ispm/en-us/content/topics/ispm/nhi.htm
  7. Microsoft Learn, 2025-2026, Managed identities for Azure resources / Workload identities / Conditional Access for workload identities, documentation, 閲覧日 2026-04-25. https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview
  8. Google Cloud Documentation, 2026, Service accounts overview / Workload Identity Federation, documentation, 閲覧日 2026-04-25. https://docs.cloud.google.com/iam/docs/service-account-overview
  9. Google Cloud Documentation, 2026, Discovery: AI Agent Service Account Self-Investigation, Security Command Center documentation, 閲覧日 2026-04-25. https://docs.cloud.google.com/security-command-center/docs/findings/threats/ai-agent-iam-anomalous-behavior-service-account-gets-own-iam-policy
  10. AWS Documentation / AWS Prescriptive Guidance, 2025-2026, Getting started with IAM Roles Anywhere / Strengthening security in IAM Roles Anywhere by using certificate-based access controls, 閲覧日 2026-04-25. https://docs.aws.amazon.com/rolesanywhere/latest/userguide/getting-started.html
  11. SPIFFE, latest, SPIFFE Identity and Verifiable Identity Document, standard documentation, 閲覧日 2026-04-25. https://spiffe.io/docs/latest/spiffe-specs/spiffe-id/
  12. HashiCorp Developer, 2026, Vault Database secrets engine / Vault PKI secrets engine, documentation, 閲覧日 2026-04-25. https://developer.hashicorp.com/vault/docs/secrets/databases
  13. OWASP, 2025, OWASP Non-Human Identities Top 10, project documentation, 閲覧日 2026-04-25. https://owasp.org/www-project-non-human-identities-top-10/2025/introduction/
  14. GitHub, Havens, E., 2025, GitHub found 39M secret leaks in 2024. Here’s what we’re doing to help, GitHub Blog, 閲覧日 2026-04-25. https://github.blog/security/application-security/next-evolution-github-advanced-security/
  15. CyberArk, 2025, 2025 State of Machine Identity Security Report, report, 閲覧日 2026-04-25. https://www.cyberark.com/CyberArk-2025-state-of-machine-identity-security-report.pdf
  16. CyberArk Software Ltd., 2024, Form 6-K regarding completion of Venafi acquisition, SEC-related filing, 閲覧日 2026-04-25. https://d18rn0p25nwr6d.cloudfront.net/CIK-0001598110/f551de69-619f-4aaa-bb32-aa45b0b0419f.pdf
  17. SailPoint, 2024-2025, Machine Identity Security, product page and related materials, 閲覧日 2026-04-25. https://www.sailpoint.com/ja/products/identity-security-cloud/atlas/add-ons/machine-identity-security
  18. デジタル庁, 2023, デジタル社会推進標準ガイドライン「ゼロトラストアーキテクチャ適用方針」の概要, 閲覧日 2026-04-25. https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/ad619888-36bb-4f67-a61f-b44779bad1e9/bbd67408/20230921_meeting_network_guideline_01.pdf
  19. 情報処理推進機構, 2026, AI利用者のためのセキュリティ豆知識, 閲覧日 2026-04-25. https://www.ipa.go.jp/digital/ai/security/ai_security_tips.html
  20. ENISA, 2025, NIS2 Technical Implementation Guidance / Network and Information Systems Directive 2 overview, 閲覧日 2026-04-25. https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance
  21. MarketsandMarkets, 2026, Non-Human Identity Access Management Market worth USD 18.71 billion by 2030, press release, 閲覧日 2026-04-25. https://www.marketsandmarkets.com/PressReleases/non-human-identity-nhi-access-management.asp

コメント

タイトルとURLをコピーしました