Webの「ID連携」から、自律型AIの「権限管理」へ —— OIDF-J活動紹介とIdentity Management for Agentic AI

ID連携の基礎を固めておき、自律型AIの権限管理への道筋について解説します

Transcript

1. Webの「ID連携」から、自律型 AIの「権限管理」へ —— OIDF-J 活動紹介と Identity Management for Agentic AI
 2026.02.25
2. 2 寺原 歩 （てらら） 
 直近の活動
 • 2021年にフリー株式会社に入社
 主にSAML SP、パスキーなどの開発を担当
 • OIDF-J 人材育成推進WG 第2期に参加
 現在は技術SWGでSSFテーマを担当
 • Authlete人材（自称）
 
 趣味はホラー映画と猫と兎田ぺこら。
 IdF プロダクトリード
 ayumu terahara

3. CopyrightOpenIDFoundationJapan-AllRightsReserved. OpenIDファウンデーション・ジャパンとは？
 
 
 
 インターネットにおけるユーザー認証技術である
 「OpenID」技術の国際化を支援するため、
 日本国内において「OpenID」技術を普及、啓発 し、
 もって社員ならび会員に共有する利益を図ることを
 目的とするとともに、その目的に資するため、
 事業を行っています！
4. CopyrightOpenIDFoundationJapan-AllRightsReserved. OIDF-Jの主な活動
 ワーキンググループの活動をはじめ、デジタルアイデンティティに関わる
 内容の普及、啓発を行っています。
 ワーキンググループ による活動 ▪人材育成推進 WG 　技術調査や調査報告会の実施を通じて、プロフェッショナル人材の 　育成を目的としている。 ▪KYCWG 　本人確認・eKYC の現状の課題の分析を通じて、民間事業者による 　社会実装へつなげていくことを目的としている。 イベント開催による 情報発信 ▪OpenID Technight 　技術者・開発者向けのイベント ▪OpenID Bizday 　ビジネス企画者向けのイベント コンテンツによる 情報発信 ▪ホワイトペーパー＆最新情報翻訳 　米国OpenID Foundationが公開しているホワイトペーパーや最新情報の 　日本語訳を実施
5. CopyrightOpenIDFoundationJapan-AllRightsReserved. OpenIDファウンデーション・ジャパンの活動
 OpenID技術、KYC、デジタルアイデンティティ人材育成などWGやセミナーを通じて活動 しております。詳しくは公式HP・Connpass・Youtube へ！
 

6. 6 ID連携の基礎 

7. 7 「Identity is the new perimeter」
 
 クラウドネイティブ環境（コンテナ、マイクロサービス、SaaS）では、ネットワーク境界での防御だけで は不十分。
 「誰が」「どのリソースに」「何をできるか」を正確に制御するID基盤が不可欠。
 
 ID連携とは、複数のシステムやサービスに対し、ユーザーの属性情報を提供すること。
 これによってサービス立ち上げの際に、ID基盤の構築を容易とする。
 
 
 なぜ今、「 ID連携の基礎」が必要か 

8. 8 認証 (Authentication / AuthN): Who you are（あなたは誰か？）
 ・パスワードや生体認証による当人性の検証
 認可 (Authorization / AuthZ): What you can do（何をしてよいか？）
 ・ファイルの読み取り権限、APIの実行権限を制御するためのポリシー管理
 
 この2つを混同しないことがすべての出発点。
 おさらい：「認証」と「認可」 

9. 9 OpenID Connect 1.0は、ID連携を実現するための標準規格
 ※この資料ではOIDCと記載
 
 ID連携を支える OpenID Connect 1.0 概要
 標準仕様のスペックは、OpenID Foundationによって策定されている。
 
 スペック上の定義では、
 OpenID Connect 1.0 は, OAuth 2.0 プロトコルの上にシンプルなアイデンティティレイヤーを付与したもの である。
 このプロトコルはクライアントが認可サーバーの認証結果に基づいてエンドユーザーのアイデンティティを検 証可能にする. また同時にエンドユーザーの必要最低限のプロフィール情報を, 相互運用可能かつ RESTful な形で取得することも可能にする。
 
 OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
 
 
 出典元: デジタルアイデンティティ技術 認可・ID連携・認証 基礎 
 （https://speakerdeck.com/oidfj/ren-cai-yu-cheng-wg-zhong-jian-huo-dong-bao-gao-hui-ji-shu-sabuwg?slide=34）

10. 10 OpenID Connect 1.0 概要 - 実現できること 
 ユーザーが予約サービスに加入しようと、新たにアカウントを作成する場面である。
 ユーザーは新たに予約サービスのアカウントを作成するのではなく、既に作成済のGoogleアカウントを使用 することにした。
 
 ①oogle Photosにアクセ スする権限をください ②Googleアカウントにログインさせて 予約サービス ユーザー Google アカウント ①Googleアカウントを使用し、 アカウント作成を選択 ④Google 認証 ③ログインして（ログイン画面） ⑤ユーザーということが確 認できました 出典元: デジタルアイデンティティ技術 認可・ID連携・認証 基礎 
 （https://speakerdeck.com/oidfj/ren-cai-yu-cheng-wg-zhong-jian-huo-dong-bao-gao-hui-ji-shu-sabuwg?slide=35）

11. 11 OpenID Connect 1.0 概要　ー　実現できること 
 ⑦OK ⑥予約サービスにアカウントの情 報を渡していいですか？ ⑧ユーザーに同意もらったの で、情報あげます ⑨Googleアカウントで アカウント登録完了 ID Token ID Tokenによってユーザーの属性情報の提供を可能としている 予約サービス ユーザー Google アカウント 予約サービス ユーザー Google アカウント
12. 12 前段の実用例のポイント
 ◆OpenID Connectのメリットである「サービス毎にアカウントを作成する必要がない」ため、
 　ユーザーは複数のアカウント情報を保持する必要がない
 
 ◆例ではアカウント登録のシチュエーションを示したが、ID連携を使用した一例であり、
 　ID連携を使用するユースケースは他にも存在する
 　・サービス間での連携（名寄せ）だけに使用するケース
 
 ◆OpenID Connect 1.0はOAuth 2.0にID Tokenが追加されたもの
 　OpenID Connect 1.0 = OAuth 2.0 + ID Token
 OpenID Connect 1.0 概要　ー　実現できること 
 〜OAuth 2.0との違い〜
 OAuth 2.0は リソースへのアクセス権を取得するため に使用
 OpenID Connect 1.0は ユーザの属性情報取得（ID連携）のため に使用
 出典元: デジタルアイデンティティ技術 認可・ID連携・認証 基礎 
 （https://speakerdeck.com/oidfj/ren-cai-yu-cheng-wg-zhong-jian-huo-dong-bao-gao-hui-ji-shu-sabuwg?slide=39）

13. 13 広がるOIDCのエコシステム 
 OIDCは進化を続けている
 • FAPI: 金融グレードの高度なセキュリティプロファイル
 • OIDC4IDA: 身元確認（Identity Assurance）の拡張
 • Shared Signals (CAEP/RISC): セッション状態やセキュリティイベントのリアルタイム共有（ゼロトラ スト・継続的アクセス評価に必須）
 
 などなど

14. CopyrightOpenIDFoundationJapan-AllRightsReserved. 人材育成推進WG ph2 活動報告会を実施します！
 3/11(水)17:00よりイベントを開催します。OIDF-Jでの活動者内で整理した情報を
 アウトプットする機会になっておりますので、特に初学者の方はイベントへの参加
 ご検討ください！

15. 15 Identity Management for Agentic AI

16. 16 パラダイムシフト： WebからAgentic AIへ
 • これまでのWeb (人間主体)
 ◦ 人間がブラウザを操作し、システムは決まった命令を実行する（決定的）。
 • これからのAgentic AI (AI主体)
 ◦ AIが目標を与えられ、自律的に計画し、外部API等を用いて実行する（非決定的）。

17. 17 AIエージェントと「認可」の現在地 
 • 現状のツール連携: MCP (Model Context Protocol) 等による標準化が進行中。
 ◦ しかし、既存のOAuth/OIDCは「人間がリアルタイムで画面を見て同意する」ことが前提。
 • 課題: AIがバックグラウンドで非同期かつ自律的に動くとき、現在の同意モデルは機能不全に陥 る。
 ※ 参考: MCP docs/specification/2025-11-25/basic/authorization にて提示されているOAuthプ ロファイルの主要なコンポーネント
 • OAuth2.1: 認可サーバーにおけるセキュリティ対策のベースライン
 • CIMD: MCPクライアントをmetadataとして公開することでMCPの管理性と利便性を向上させる
 • OAuth 2.0 Authorization Server Metadata: 認可サーバを探索可能とするためのmetadata
 出典元: https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2025-11-25/basic/authorization.mdx
 

18. 18 AIの「なりすまし」から AIへの「委譲」へ 
 • ⚠ 現状のアンチパターン：Impersonation（なりすまし）
 ◦ AIが「ユーザーのクレデンシャル」をそのまま使ってAPIを叩く。監査ログ上、人間とAIの区別が つかない。
 • 💡 目指すべき姿：Delegation（委譲）
 ◦ AIエージェント自身に固有のアイデンティティを持たせる。
 
 「ユーザー〇〇の代理として動くAIエージェント△△」という明確な関係性の証明。

19. 19 • 再帰的委譲 (Recursive Delegation):
 ◦ エージェントが別の専門エージェントにタスクを依頼する際、権限（スコープ）をどう安全に連鎖・ 縮小させるか？
 • マルチユーザー・エージェント:
 ◦ SlackのBotなど、チーム全員で共有するAIエージェントは「誰の」権限で動くべきか？
 • 最小権限のジレンマ:
 ◦ AIに事前一括で強い権限を渡すのは危険だが、都度人間に「許可」を求めるとUXが崩壊する。
 
 => いくつかの提案が行われている現状
 • OpenID Connect for Agents
 （https://subramanya.ai/2025/04/28/oidc-a-proposal）
 • OAuth2.0 Extention: On-Behalf-Of User Authorization for AI Agents
 （https://www.ietf.org/archive/id/draft-oauth-ai-agents-on-behalf-of-user-00.html）
 次世代のアイデンティティ課題 

20. 20 OIDFが描く未来：標準化の重要性 
 • ⚠ エージェントのアイデンティティの「断片化」は避けるべき
 ◦ ベンダーが断片的な独自ソリューションを開発すると、開発者の速度が低下し、複数のセキュリ ティモデルが作られることで安全性が侵害される。
 • 💡 相互運用可能な基盤（トラスト・ファブリック）の構築へ
 ◦ 将来の自律システムが、独自のサイロではなく「相互運用可能な基盤」の上に構築されるよう、新 しい概念を形式化したプロトコルの標準化が急務。
 https://www.openid.or.jp/news/2025/11/identity-management-for-agentic-ai.html

21. 21 まとめ
 1. 「ID連携の基礎」は陳腐化しない
 OAuth/OIDCの「委譲」の概念は、AI時代にも不可欠なベースとなる。
 2. Agentic AIがもたらす新たな認可の課題
 「なりすまし」を検知、AIに適切なアイデンティティと動的な権限を与える仕組みが必要。
 3. アイデンティティは「人間」から「非人間」へ
 KubernetesのWorkload Identity等と同様、AIエージェントのID管理が今後の主戦場になる。

22. スモールビジネスを、世界の主役に。