こんにちは。LINEヤフー株式会社で認証・認可基盤「Athenz」の開発・運用を担当している金 廷祐（Kim, Jeongwoo）です。
前回の記事「AI時代の認証課題を解決する次世代標準候補「ID-JAG」とは？」では、Identity Assertion JWT Authorization Grant（以下、ID-JAG）がAIエージェントにとってなぜ重要性を増しているのか、従来からあるシングルサインオン（SSO）の信頼モデルをどのようにAPI領域へ拡張するのか、そしてAI開発者や企業にとっての主な利点と考慮事項について解説しました。
今回は、理論から実践へと一歩踏み出します。抽象的な仕様と実際の動作のギャップを埋めるため、「athenz-community/id-jag-the-hard-way」というハンズオンを作成しました。
このローカルハンズオン環境では、AIエージェントがユーザーの代わりに保護されたAPIへアクセスする際に必要となる、実際のトークンやポリシー、システム間の信頼関係を直接観察することができます。
デモ動画：
リポジトリ：athenz-community/id-jag-the-hard-way
本記事で学べること
- AIエージェントがログイン済みのユーザーに代わって保護されたAPIに安全にアクセスする、ID-JAGのエンドツーエンドのフローをローカルで再現する方法。
- AIエージェントと保護されたModel Context Protocol（MCP）サーバーとのやり取り、Authorization Serverによる企業ポリシーの評価方法、そしてResource Serverが最小権限のAccess Tokenをどのように強制するかの仕組み。
- トークンが正確にどこで発行されるのか、そして特定のポリシーが欠落している場合にパイプラインのどこで処理がブロックされるのか。
1. 構成図のその先へ
ID-JAGは、IETFのOAuthワーキンググループで策定が進められているアクティブなInternet-Draft（2026年6月26日時点ではdraft-ietf-oauth-identity-assertion-authz-grant-04）であり、以下の既存のRFC仕様を組み合わせて、安全で委譲されたクロスドメインのAPIアクセスを実現します。
アーキテク チャ図は全体像を把握するのに役立ちますが、実際に実装する際に直面する実践的なエンジニアリングの疑問には答えてくれません。
- ユーザーがAIエージェントにログインした際、具体的にどのようなトークンペイロードが生成されるのか？
- すでにID Tokenを持っているのに、なぜID-JAGを介さずに直接Access Tokenと交換してはいけないのか？
- 認証はIdPに任せつつ、企業の認可ポリシーの管理と評価を独立したポリシー決定ポイント（PDP）に分離することは可能なのか？
- AIエージェントがMCPサーバーを呼び出す際、具体的にどのような権限を持ち、自分がログイン済みのユーザーの代理であることをどのように証明するのか？
- Enterprise IdPとAuthorization Serverの間で、システムレベルの信頼関係はどのように設定されるのか？
ID-JAGをデファクトスタンダードと呼ぶにはまだ早いかもしれませんが、標準的なOAuthの仕組みの上に委譲アクセスをモデル化する、今後の有望なOAuthベースのプロファイルといえます。本ハンズオンでは、これらのコアな概念をAIエージェントの認可という課題に直接適用します。
2. AIエージェントの認可における課題
従来のアプリケーションセキュリティモデルでは、人間のユーザーまたはサービスアカウントが認証情報（パスワードや証明書）を提示して、静的なアクセス権を取得していました。しかし、AIエージェントはそのどちらの枠にもきれいに収まりません。固定化された予測可能なルーチンを実行するサービスアカウントでもなければ、自分の行動に即座に責任を負える人間のユーザーでもあり ません。まったく新しい、進化し続けるアクターなのです。
AIエージェントは、バックグラウンドで内部APIやSaaSツール、データベースを継続的に呼び出します。この自動化されたチェーンのすべてのステップで人間のユーザーに同意（Consent）を求めていては、ユーザー体験が著しく損なわれます。
一方で、エージェントに包括的かつ永続的な同意を与えてしまうと、影響範囲（ブラストラジアス）の拡大と説明責任の問題が生じます。エージェントが誤動作したり悪用されたりした場合、ユーザーの意図と委譲されたエージェントの自律的な動作を区別することが困難になります。これは個人のユーザーにエージェントの監視という絶え間ない負担を強いることになり、人間の注意力や運用リソースを継続的に消費します。また、企業内での「シャドーAI」の広がりを招き、プロンプトインジェクションなどの新たな攻撃ベクターに対して組織を脆弱にし、企業のアタックサーフェスを大幅に拡大させる要因にもなります。
この環境を安全に保つためには、「このユーザーは誰か？」という問いから、次のような問いへと視点を移す必要があります。
「このAIエージェントは、現在、この特定のユーザーの代理として、この正確な権限の範囲内で、この特定のリソースにアクセスすることを認可されているか？」
ID-JAGは、断片化されたアドホックな接続から脱却し、きめ細かい企業ポリシーによって管理されるEnterprise IdPとAuthorization Serverの間に集中管理された信頼のファブリック（織り目）を確立することで、この課題の解決を支援します。
3. デモアーキテクチャのコンポーネント
本ハンズオン環境は、以下の5つのコアコンポーネントで構成されています。
| コンポーネント | テクノロジー | 役割 |
|---|---|---|
| Requesting Agent | Open WebUI, Ollama, Gemma 4, AI Client Gateway | ユーザーの代理としてツールを実行するAIエージェントとゲートウェイ。 |
| IdP | Keycloak (on Docker) | ユーザー認証とサブジェクト・アサーションを管理するIdP。 |
| IdP Authorization Server | Athenz KeycloakTokenExchangePlugin | IDアサーションを検証し、ID-JAGを発行するプラグイン。 |
| Authorization Server | Athenz (on Local K8s) | Access Tokenを発行するPDPとして機能する認可サーバー。 |
| Resource Server | Sample Document API | ターゲットとなる保護されたリソースサーバー。 |
アーキテクチャ設計に関する注記
標準的なID-JAGモデルでは、通常、IdP Authorization Serverがユーザーを認証し、クライアントがそのユーザーの代理として行動できるかを評価し、ID-JAGを発行する役割を担います。
しかし、このハンズオンでは意図的にそれらの責任を分離しています。Keycloakは、ユーザー認証と元のIDアサーションを担当するアップストリームのIdPとして機能します。一方、Athenzは（KeycloakTokenExchangePluginを通じて）フェデレートされたIdP Authorization Serverとして機能し、Keycloakが発行したアサーションを検証し、企業ポリシーを適用した上で、ID-JAGアサーションを発行します。
これはドラフトに記載されている最もシンプルなデプロイモデルとは少し異なりますが、同一のセキュリティ境界を維持しています。Resource Authorization Serverは、アップストリームのKeycloakトークンをリソース認可グラントとして盲目的に受け入れるわけではありません。その代わり、発行者（Issuer）、署名、オーディエンス、サブジェクト、クライアントバインディング、および企業ポリシーのチェックがすべて適用された後にのみ発行される、Athenz発行のID-JAGを信頼します。
この分離は、認証IdPがベンダー管理のシステムである一方で、認可ポリシーや委譲の制御を複数のIdPやSaaSベンダー、リソースアプリケーション全体に分散させたくないエンタープライズ環境において非常に有用です。認可の決定をAthenzに集約することで、企業はアプリケーション横断的な委譲ポリシーを1か所で管理でき、認可ロジックに関するベンダーロックインを軽減し、多数のシステム間で重複または矛盾したポリシーを維持することから生じるリスクを回避できます。
したがって、このハンズオン環境では、AthenzがID-JAGの発行者（Issuer）として、また集中管理されたResource Authorization ServerおよびPDPとして機能し、委譲されたAPIアクセスの企業における「信頼できる唯一の情報源（Source of Truth）」の役割を果たします。
4. 実行フローのトレース
ハンズオンを実行すると、内部では以下のシーケンスが発生します。
- ユーザーはKeycloak IdPを介してシステムにログインします。
- ユー ザーがプロンプトを入力し、AIエージェントにタスクを指示します。
- AIエージェントは、AthenzのIdP Authorization ServerにID-JAGトークンを要求します。
- Athenzは企業ポリシーを評価および検証し、要求された委譲が許可されているかを確認します。
- AIエージェントは、AthenzのAuthorization ServerにAccess Tokenを要求します。
- AIエージェントは、トークンを付与してMCPサーバーにリクエストを送信します。
- MCPサーバーは、Authorization ServerとToken Exchangeを実行します。
- MCPサーバーは、交換されたトークンを使用して、最終的なResource Serverにリクエストを送信します。
重要なのは、AIエージェントが長期的な特権キーを保持するのではなく、エンタープライズポリシーエンジンによって評価された特定の境界（スコープ）内でのみ動作するという点です。
5. 失敗を前提とした設計：ブロッカーから学ぶ
AIエージェントの認可アーキテクチャは、成功の経路（ハッピーパス）よりも、失敗の経路を通じて理解するのが効果的です。未認可の状態をシステムがどう処理するかを観察することで、セキュリティ設計の意図がより明確になるため、このハンズオンでは意図的に以下の失敗ポイントを体験するように設計しています。
- トークンなしで保護されたAPIを呼び出し、
401 Unauthorizedを観察します。 - エンタープライズロールを設定するもののメンバーシップを省略し、Token Exchangeの失敗を意図的に引き起こします。
- エージェントに必要な権限を明示的に付与せずに委譲呼び出しを試み、委譲チェーンが途切れる様子を確認します。
それぞれのエラーは、チェーン内に特定のポリシーコンポーネントや信頼関係が「なぜ存在しなければならないのか」を正確に示してくれます。
アーキテクチャの深掘り：なぜID Tokenを直接交換してはいけないのか？
このハンズオンのような小規模なローカルセットアップであれば、KeycloakのID TokenをAthenzのAccess Tokenと直接交換することも技術的には可能です。AthenzがKeycloakトークンの発行者、署名、オーディエンス、サブジェクトを検証し、Athenzのポリシーを評価してAccess Tokenを発行することはできます。
しかし、そのモデルは、ログイン用のトークンを暗黙的にリソースアクセスのための Authorization Grant（認可グラント） として扱ってしまいます。この違いは、障害発生時や監査の経路で非常に重要になります。ID Tokenは、ユーザーがクライアントに対して認証されたことを証明するものです。一方、Authorization Grantは、特定のリソースとスコープに対するAccess Tokenを要求するために、Authorization Serverに提出されるアーティファクトです。
認可グラントの境界を導入することで、認証の失敗、グラントの検証の失敗、エージェントへの委譲の拒否、企業ポリシーによる拒否、リソーストークンの拒否などを明確に切り分けることができます。簡単に言えば、アイデンティティデータと明示的なアクセス権限が混同されるのを防ぎ、認証イベントがクロスドメインの認可権限を自動的に保証しないようにするのです。
このデモを動かすためにID-JAGが必須というわけではありません。しかし、ID-JAGの価値は、特にシステムが失敗したときに、この認可の境界を明確にしてくれる点にあります。
6. クイックスタート：ローカルでのフロー実行
実践的な演習を始めるには、以下のリポジトリリンクにアクセスしてください。
リポジトリ：athenz-community/id-jag-the-hard-way
メインページの START THE TUTORIAL NOW ボタンをクリックすると、ローカル環境のセットアップとID-JAGフローの検証手順が表示されます。
ガイド自体は意図的な「失敗と修正」のループを中心に構築されており、最終的に正しく動作する状態に行き着くように設計されています。ハンズオン完了後も、設定をあえて手動で壊すことで境界テストを行うことができます。例えば、AthenzのUIに入ってエージェントの委譲権限を削除し、実行のブロックがどこで発生するかを正確にトレースしてみてください。このような能動的な実験こそが、集中管理されたポリシーコントロールについて深く学べる方法です。
おわりに
AIエージェントが企業ワークフロー全体にスケールしていく中、入口での認証検証だけではもはや不十分です。現代のアーキテクチャには、委譲されたアクセスに対するシステム的で集中管理された制御 と、明示的な監査機能が求められています。
ID-JAGはこのような複雑性を管理するための構造化されたアプローチを提供します。そして、それを理解する方法の一つは、直接手を動かして実験することです。id-jag-the-hard-way へのコントリビューション、Issue、フィードバックはいつでも歓迎します。
Tech-Verse 2026にて登壇しました
LINEヤフーの年次テックカンファレンス「Tech-Verse 2026」にて、このテーマに関するセッションを行いました。
『AI時代の次世代認可標準「ID-JAG」：MCPとA2A連携における認可設計と実践』
プロトコルの基本的な仕組みを超えて、中央ポリシー制御モデルについて議論し、GoogleのAgent2Agent（A2A）の取り組みや、AIエージェントのセキュリティに対するより広範なクラウドプラットフォームのアプローチなど、エージェントエコシステムにおける周辺の動向を探りました。さらに、OktaやPing Identityの貢献者も参加しているID-JAGドラフトとこれらの戦略を比較・分析しました。ご参加いただいた皆様、ありがとうございました。
