AIエージェント認証、OAuthだけでは足りない——TableauのPAT対応やX APIのxurlブリッジが示す「標準の隙間」

AIエージェントが外部サービスを自律的に操作する際の認証基盤として、OAuth 2.0および2.1が事実上の標準になりつつある。しかし実装現場では、OAuthをそのまま適用できないサービスやAPI仕様の制約に直面し、ブリッジやカスタム認証層で穴を埋める動きが相次いでいる。標準化が進む裏側で広がる「回避策」の実態を追う。

NTTデータの事例が示す三者三様の認証方式

NTTデータがAmazon Bedrock AgentCoreを用いて構築したSaaS横断AIエージェントでは、ユーザー認証にOktaが発行するJWTアクセストークンをAgentCore Identityで検証し、常に「認証済みユーザーコンテキスト」でエージェントを実行する設計を採用した。Salesforce連携ではAgentCore GatewayのMCPターゲット機能を使い、OpenAPI定義を介したOAuth 2.0 Authorization Code Flowを実装している。

一方でTableauはOAuth 2.0ではなくPersonal Access Token（PAT）による認証方式を採用しているため、AgentCore Identityの標準機能ではユーザー単位のPAT管理ができなかった。そこでNTTデータはGateway Interceptorsを活用したカスタム認証方式を構築し、OAuth非対応SaaSでもユーザー単位の認可を維持する連携を実現した。同一システム内で3種類の認証方式が併存する構成は、標準化の限界を端的に示している。

X公式MCPサーバーが必要とした「xurl」ブリッジ

2026年6月30日、XはX MCPサーバーとDocs MCPサーバーの提供を開始した。対応クライアントはGrok Build、Cursor、Claude Desktop、VS Code（GitHub Copilot Agent mode）など。ここで問題となったのがX APIのOAuth 2.0が動的クライアント登録（Dynamic Client Registration）に対応していない点だ。AIクライアントを直接X MCPサーバーのURLへ向けることができないため、X開発者プラットフォームチームが提供するOSSのCLIツール「xurl」がローカルブリッジとして介在する2段構成になった。

具体的には、AIクライアントがstdio経由でJSON-RPCを送信し、xurlがHTTPS＋BearerトークンでX側MCPサーバーへ中継する。初回起動時はブラウザでOAuth 2.0ログインを一度完了させればトークンが`~/.xurl`にキャッシュされ、以降は自動更新される。ヘッドレス環境では`xurl auth oauth2 --headless`による事前認証も用意された。プロトコルバージョンはStreamable HTTP MCP（2025-06-18）で、料金は月額制ではなく従量課金となっている。

Amazon Connect×Salesforce連携ではGatewayが認証を一元化

Amazon Connect CustomerとSalesforceをMCPで連携させたAWSの実装例では、Salesforceがホスト型MCPサーバーを通じて機能を公開し、AIエージェントはOAuth 2.0による認証とアクセスポリシー適用を担うAmazon Bedrock AgentCore Gatewayを経由して接続する。実行時にはAgentCoreがOAuth認証を行いリクエストを転送、Salesforce MCPサーバーが適切なSalesforce API操作へ変換する。この構成により、Salesforceが新しいツールをMCPサーバーに追加してもオーケストレーション層のコードを変更せずにエージェントが利用できる「ランタイム発見」が可能になった。

国産CMSやスタートアップも追随、OAuthは前提条件に

国産CMSのbaserCMSは5.4.0でMCPによるAIエージェント連携機能を搭載し、認証にOAuth 2.1を採用した。AIエージェントは連携を許可したユーザーの権限で動作し、管理画面でできない操作はエージェントからもできない設計とすることで、既存の権限設計をそのまま適用できるようにしている。

2026年2月中旬リリース予定のマルチモーダルAIエージェントプラットフォーム「emma」（Duzzle）も、Slack・Google Drive・Jiraなど53種類の外部サービス連携にOAuth認証を採用し、APIキーを直接管理するリスクを排除した。加えてEA2（Extended Agent Authentication）と呼ぶ独自の権限制御機構で、70エージェント・800個超のツールに対するユーザー単位の細かい権限管理を実現している。

Oktaの拡張策とA2Aが示すその先

OktaはOAuthの認可分断が課題だとして、Cross App Access（XAA）という拡張プロトコルを提供し、複数アプリと自律連携するAIエージェントのリスクに対応する。2026年8月25日にはAIエージェント向けSSO「Agent SSO」を一般提供開始し、OAuthの拡張機能を用いてSlackなど外部サービスへの認可を統合管理できるようにした。

エージェント間通信の標準化を目指すA2A（Agent2Agent）プロトコルでも、認証はAPIキー、OAuth 2.0、OpenID Connect DiscoveryなどOpenAPI仕様に準拠したセキュリティースキームをサポートする設計だ。IBMはA2Aの解説で、エージェント・カードへの認証スキームの正式な組み込みなど、プロトコル自体がまだ発展途上であると位置づけている。OAuthを核としながらも各社・各サービスが個別のブリッジや拡張で穴を埋める状況は、当面続くとみられる。