ID-JAG The Hard Way：失敗から学ぶAIエージェントのセキュリティハンズオン
こんにちは。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 アクセスを実現します。
- OAuth 2.0 Token Exchange (RFC 8693)
- JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523)
アーキテクチャ図は全体像を把握するのに役立ちますが、実際に実装する際に直面する実践的なエンジニアリングの疑問には答えてくれません。
- ユーザーが 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 つのコアコンポーネントで構成されています。
| コンポーネント | テクノロジー | 役割 |
|---|
AgentOpen WebUI、Ollama、Gemma 4、AI Client Gateway
ユーザーの代わりにツールを実行する AI エージェントとゲートウェイ。
IdP Keycloak (Docker 上)
ユーザー認証とサブジェクト・アサーションを管理する IdP（ID プロバイダー）。
IdP Authorization Server Athenz KeycloakTokenExchangePlugin
ID アサーションを検証し、ID-JAG を発行するプラグイン。
Authorization Server Athenz (ローカル K8s 上)
アクセストークンを発行する 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 の ID 認証サーバー（IdP Authorization Server）に対して ID-JAG トークンの発行を要求します。
- Athenz は企業のポリシーを評価・検証し、その委譲が許可されているかを確認します。
- 次に、AI エージェントは Athenz の認可サーバーにアクセストークンを要求します。
- AI エージェントは取得したトークンを付与して MCP サーバーへリクエストを送信します。
- MCP サーバー側では、認可サーバーとの間でトークン交換（Token Exchange）が実行されます。
- 最後に、MCP サーバーは交換されたトークンを用いて、最終的なリソースサーバーにアクセスを要求します。
ここで最も重要なのは、AI エージェントが長期間有効な特権キーを保持するのではなく、エンタープライズレベルのポリシーエンジンによって評価された「特定の範囲（スコープ）」内でのみ動作することです。
5. 失敗を前提とした設計：ブロッカーから学ぶ
AI エージェントの認可アーキテクチャを理解するには、成功するケース（ハッピーパス）よりも、失敗するケースを通じて学ぶ方が効果的です。システムが未承認の状態をどう処理するかを観察することで、セキュリティ設計の意図がより明確になります。そのため、今回のハンズオンではあえて以下の失敗ポイントを体験できるように設計されています。
- トークンなしで保護された API を呼び出し、401 Unauthorized エラーが発生する様子を確認します。
- エンタープライズロールは設定しているもののメンバーシップを省略し、意図的にトークン交換の失敗を引き起こします。
- エージェントに必要な権限を明示的に付与せずに委譲呼び出しを試み、委譲チェーンがどこで途切れるかを確認します。
それぞれのエラーメッセージは、そのチェーン内に特定のポリシーコンポーネントや信頼関係が「なぜ不可欠なのか」を正確に示してくれます。
アーキテクチャの深掘り：なぜ ID トークンを直接交換してはいけないのか？
今回のような小規模なローカル環境であれば、技術的には Keycloak の ID トークンを Athenz のアクセストークンと直接交換することも可能です。Athenz が Keycloak トークンの発行者、署名、オーディエンス、サブジェクトを検証し、自社のポリシーを評価した上でアクセストークンを発行することはできます。
しかし、本番環境や大規模システムでは、このアプローチには重大なリスクが伴います。
しかし、このモデルはログイン用のトークンを、暗黙的にリソースアクセスのための「認可グラント（Authorization Grant）」として扱ってしまいます。この違いは、障害発生時や監査の経路において非常に重要です。
ID トークンは、ユーザーがクライアントに対して認証されたことを証明するものです。一方、認可グラントとは、特定のリソースとスコープに対するアクセストークンを要求するために、認可サーバーに提出されるアーティファクトです。
このように認可グラントの境界を明確に導入することで、認証の失敗、グラントの検証失敗、エージェントへの委譲拒否、企業ポリシーによる拒否、リソーストークンの拒否などを、それぞれ明確に切り分けることができます。簡単に言えば、アイデンティティデータと明示的なアクセス権限が混同されるのを防ぎ、認証イベントがクロスドメインの認可権限を自動的に保証しないようにするのです。
このデモを実行するために 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 ドラフトと、これらの戦略を比較・分析しました。
ご参加いただいた皆様、ありがとうございました。
原文を表示
こんにちは。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アクセスを実現します。
- OAuth 2.0 Token Exchange (RFC 8693)
- JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523)
アーキテクチャ図は全体像を把握するのに役立ちますが、実際に実装する際に直面する実践的なエンジニアリングの疑問には答えてくれません。
- ユーザーが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 AgentOpen WebUI, Ollama, Gemma 4, AI Client Gatewayユーザーの代理としてツールを実行するAIエージェントとゲートウェイ。
IdPKeycloak (on Docker)ユーザー認証とサブジェクト・アサーションを管理するIdP。
IdP Authorization ServerAthenz KeycloakTokenExchangePluginIDアサーションを検証し、ID-JAGを発行するプラグイン。
Authorization ServerAthenz (on Local K8s)Access Tokenを発行するPDPとして機能する認可サーバー。
Resource ServerSample 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ドラフトとこれらの戦略を比較・分析しました。ご参加いただいた皆様、ありがとうございました。
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み