FAPIの立ち位置はどう変わる？ ~多様化するユースケースを支えるセキュアAPIエコノミー~

下記イベントの登壇資料です。

OpenID Summit Tokyo 2026 Special Edition
https://www.openid.or.jp/summit/2026/

Transcript

1. FAPIの立ち位置はどう変わる？ 多様化するユースケースを支える セキュアAPIエコノミー 伊東 諒 (いとう りょう@ritou) OpenIDファウンデーション・ジャパン エバンジェリスト 2026/8/26 OpenID Summit Tokyo 2026 Special Edition 1
2. 今回お話する内容 • FAPIについて • AI エージェント時代におけるAPIの提供スタイルの変化 • FAPIの立ち位置はどう変わるのか 2
3. FAPIについて 3
4. FAPI (Financial-grade API) • OAuth: アクセストークンを用いて同期的/非同期なリソースアクセスを実現 するためのフレームワーク • OIDC: 同期的/非同期にエンドユーザーの属性情報を提供するための仕組み • FAPI: OAuth 2.0 / OpenID Connectを高いセキュリティが求められるAPI 向けにプロファイルした仕様群 • 自由度を制約することで特定の攻撃への耐性と相互運用性を高める • “金融”以外にも適用可能 4
5. FAPIでは何がどのように強化されるのか • OAuthで実装者に委ねられていた部分を、FAPIではセキュリティ要件として 明確化 • 認可リクエスト/レスポンスの保護 • Sender-Constrained Token: 盗難対策 • Message Signing: 署名による否認防止 5
6. FAPI 2.0の仕様群 • FAPI 2.0 Security Pro le: FAPI 2.0の中核となる高セキュリティOAuthプ ロファイル • FAPI 2.0 Attacker Model: FAPI 2.0が想定する攻撃者モデル • FAPI 2.0 Message Signing: OAuth/OIDCの各種リクエスト・レスポンス への署名による非否認性の強化 fi 6
7. FAPI 2.0のポイント • Simpler: FAPI 1.0から整理・簡素化 • Stronger: OAuth Security BCP等を取り込み、より強固に • Broader: 金融以外の高価値APIにも適用可能 • Interoperable: Certi cationによって実装間の相互運用性を確認 fi 7
9. API提供スタイルの変化 「自サービスの機能を他のサービスに提供しよう」となった時 9
10. これまでのAPI提供スタイル • 固定的な連携シナリオ、ワークフロー • リソース単位よりも「一連の手続き」のパッケージ化: 「専用API」も • 境界防御によるアクセス管理の簡略化: アクセス元の環境、端末による制限 10
11. AIエージェント時代のインパクト • 自律的アクセス: 例) スケジュール確認 -> 経路検索 -> 決済の場合にどのよう にアクセス許可を行う？ • トークン漏洩、不正利用リスクの増大: Confused Deputy攻撃など • 境界防御の無効化: アクセス元の制限が困難に？ 11
12. これから求められるAPI提供スタイル • より柔軟、動的なワークフロー • リソース単位の機能提供 • 連続的、複合的な利用を想定: セキュリティレベルの底上げ、APIのレートリ ミットや課金の扱い • ゼロトラストの本格導入と最小権限の原則: 対象は人間(端末)からAIエージェ ントへ。厳格なアクセスポリシーの定義と運用が求められる 12
13. FAPIの立ち位置はどう変わるのか 13
14. これまでのFAPIの立ち位置 • 手続きをまとめた個別のAPI あるいは 高セキュリティが求められるAPI群 に ピンポイントで適用 • 決済系のAPIや個人情報を扱うAPIなど提供するサービスの内容、想定する 脅威によって選択される • 高コストな特殊要件としての認識 • 境界防御による代替も 14
15. これからのFAPIの立ち位置 • Future-grade API: AIエージェント時代のあらゆるAPIアクセスを支えるベ ースライン • 同時に必要となる他の仕様群と合わせて導入が進む • エンドユーザーからAI Agent、AI Agentからツールへの権限委譲 • アクセスポリシーの定義、運用 15
16. FAPI-friendlyになるためにできること • 自サービスの高セキュリティAPIの見直し: 一連の手続きからリソース単位へ の機能分解、再設計は必要か？ • FAPI 2.0のプロファイルを評価 • 対象となる攻撃、保護の対象を確認 • 認可サーバー、リソースサーバーそれぞれの対応コストを見積もり 16