AIエージェントの「非人間ID」急増でOAuth 2.1移行が加速、AWS・Oracle・Databricksが認証基盤を競って整備

AIエージェント急増が生む「非人間ID」問題とOAuth 2.1への移行

2025年から2026年にかけて、AIエージェントやAPIなど人間ではないアカウント「非人間ID（NHI）」が爆発的に増加している。AIエージェントが自律的に複数のSaaSシステムへアクセスしてデータを処理する構成が一般化したことで、OAuthによるきめ細やかなスコープ管理の重要性がこれまで以上に高まっている。Admina by Money Forwardによれば、OAuth 2.0の脆弱性を排除するため「OAuth 2.1」への移行が推奨されており、インプリシットグラントフローが非推奨となる一方、PKCE（Proof Key for Code Exchange）を伴う認可コードフローが必須化される流れが進んでいる。

あわせて、SAMLライブラリの脆弱性も看過できない問題として指摘されている。2024年から2025年にかけて、Ruby SAML（CVE-2024-45409）やsamlifyといった実装で、XML署名検証を回避してなりすましを可能にする致命的な脆弱性が相次いで報告された。AIエージェントが認証済みユーザーコンテキストで動作する設計が広まる中、こうした認可基盤側の脆弱性放置はエージェント経由での不正アクセスに直結するリスクとなる。

AWS AgentCoreによる実装事例、Oktaと組み合わせた権限維持設計

NTTデータが公開したAWSブログでは、複数SaaSを横断するAIエージェント構築においてAmazon Bedrock AgentCore Identity・Gatewayを活用した認証・認可設計が紹介されている。ユーザー認証にはAgentCore IdentityでOAuth 2.0プロバイダとして設定したOktaが発行するJWTアクセストークンを利用し、AgentCore Runtime側でトークンを検証することで、エージェントは常に認証済みユーザーコンテキストで実行される。

Salesforce連携ではAgentCore GatewayのMCPターゲット機能を用い、OpenAPI定義を介したOAuth 2.0 Authorization Code Flowを実装した。一方、Tableauは OAuth 2.0ではなくPersonal Access Token（PAT）方式のため、Gateway Interceptorsによるカスタム認証方式を採用し、ユーザー単位の認可を維持したままOAuth非対応SaaSとの連携も実現している。AgentCore Observabilityと組み合わせることで、誰がいつどのエージェントを通じて何にアクセスしたかを追跡できる監査体制も構築された。

Oracle AI Database AgentとGemini Enterpriseの権限昇格なしOAuthフロー

Oracleのブログによると、Gemini Enterprise上で稼働するOracle AI Database Agentは、A2Aサーバー稼働後にOAuthクライアント認証情報（client_id・client_secret）を生成し、OAuth 2.0認可フローを通じて個々のデータベースユーザーとして認証される仕組みを取る。この方式ではエージェントがアクセスできるのは、そのデータベースアカウントに参照権限が付与されたスキーマと表のみで、SQL Developer等で自身がクエリを実行する場合と同じ範囲に限定され、権限昇格は発生しない。導入時は初期ユーザーグループに必要なスキーマだけを含む狭い範囲のAIプロファイルから始め、段階的にアクセス範囲を広げる運用が推奨されている。

MCP標準化とAuthleteのCIMD実装、認可サーバー構築の効率化

2024年にAnthropicが提唱したModel Context Protocol（MCP）は、Amazon Web Services、Cloudflare、Google、Microsoft、OpenAIなど大手ITベンダーに相次いで採用され、2025年11月には最新版が公開された。株式会社Authleteは2026年1月、プレスリリースで、MCP最新仕様が採用したOAuth拡張仕様「OAuth Client ID Metadata Document（CIMD）」を「Authlete 3.0」に実装したと発表した。CIMDにより、クライアントと認可サーバーの動的な連携が前提となるMCPにおいて、従来必要だった認可サーバーへのクライアント情報の事前登録が不要になる。Authleteは2026年2月18日にハンズオン勉強会も開催し、CIMDを含むOAuth仕様の実装体験を提供する予定だ。

Databricksが指摘する認証ボトルネックとUnity AI Gatewayの解決策

Databricksのブログは、外部MCPサーバーごとに独自のOAuthアプリ登録、独自のクライアントシークレット、独自のトークン更新ロジックが存在し、シークレットのローテーションや権限監査、どのエージェントが何にアクセスしているかの追跡が困難になっている実態を指摘する。本来数分で終わるはずの接続作業が数週間かかるケースもあるという。これに対しUnity AI Gatewayは、GitHubやGlean、Atlassianなど外部MCPサーバーへの接続を単一の管理された方法で提供し、Agent Bricksでのデプロイ後はMLflow Tracingによるエンドツーエンドの可観測性とUnity Catalogの監査ログを組み合わせ、誰がいつどのエージェントを通じて何にアクセスしたかを可視化する。認証インフラの構築ではなくエージェント自体の開発に集中できる体制を目指した設計だ。