AIエージェントの認可疲れを解消するOBOトークン交換の実装戦略

日々の開発業務において、我々エンジニアが直面する「認可疲れ」は、もはや無視できない生産性のボトルネックとなっている。GitHub、Slack、Notion、そして社内のレガシーな業務システム。AIエージェントにこれらのツールを操作させようと試みた瞬間、我々は「認可の迷宮」に迷い込むことになる。エージェントがツールを実行するたびに発生する認可リクエストは、非同期的なワークフローを断絶させ、「仕事を任せたはずが、認可待ちでプロセスが停止している」という、深夜の障害対応にも似た徒労感をもたらす。この課題の本質は、AIエージェントという「ブラウザを持たない主体」が、従来のSSO（Single Sign-On）の恩恵を享受できない点にある。

SSOは、ブラウザのCookieとIdP（Identity Provider）のセッション管理によって、一度のログインで複数のサービスを横断的に利用可能にする。しかし、AIエージェントにはCookieという概念が存在しない。エージェントが手にできるのは、認証フローの末端で発行されるid_tokenのみである。OpenID Connect Core 1.0の仕様上、id_tokenは特定のクライアント（aud: Audience）に紐付いており、他のサービスへそのまま使い回すことはできない。この「audの壁」こそが、エージェント連携における最大の障壁だ。我々エンジニアは、この壁を突破するために、単なる認証の再利用ではなく、トークンの「交換」という概念を導入しなければならない。ブラウザというリッチなクライアントに依存せず、サーバーサイドで完結する認可の委譲こそが、AIエージェント時代の標準的なアーキテクチャとなるべきである。

この「認可疲れ」に対する最も現実的かつ強力な処方箋が、RFC 8693で定義された「トークン交換（Token Exchange）」、特に「OBO（On-Behalf-Of）」パターンである。OBOは、ユーザーが一度取得したid_tokenを、外部サービスの認可サーバーへ提示することで、そのサービス専用のaccess_tokenを新規発行させる仕組みだ。このプロセスは、ブラウザのリダイレクトを一切必要とせず、認可サーバーへの直接的なPOSTリクエストで完結する。これにより、AIエージェントはユーザーの代理人として、シームレスに複数のAPIやMCP（Model Context Protocol）を叩くことが可能となる。

OBOのプロセスを理解する上で重要なのは、トークン交換前後でのクレームの変化である。元のid_tokenが持つ「誰が認証したか」という情報は、交換後のaccess_tokenにおいても「sub」クレームとして引き継がれるが、発行者（iss）や宛先（aud）はサービス側の認可サーバーへと書き換わる。さらに、特筆すべきは「act.sub」という新しいクレームの存在だ。これは「誰が代行したか（AIエージェントの識別子）」を明示するものであり、監査ログやセキュリティポリシーの適用において極めて重要な役割を果たす。また、将来的な標準化として期待されるID-JAG（Identity Assertion JWT Authorization Grant）も存在するが、現時点ではIdP側の対応状況や仕様の流動性を考慮すると、OBOこそが今すぐ実装可能な最適解であると私は断言する。

OBOを実装する際、我々が注力すべきは「既存のSSOインフラの流用」である。認可サーバーがRFC 8693に対応している場合、実装のハードルは驚くほど低い。具体的には、既存のJWT検証ロジックを再利用し、新たに「grant_type=urn:ietf:params:oauth:grant-type:token-exchange」を受け付けるエンドポイントを構築するだけでよい。TypeScriptのjoseライブラリ等を用いれば、JWKSの取得から署名検証までを堅牢に実装できる。ただし、ここで注意すべきは「sub」クレームの扱いだ。GoogleとMicrosoft Entra IDでは、subのスコープや一意性の保証範囲が異なる。メールアドレスをユーザー識別子として使うという安易な設計は、退職者によるアカウント再利用のリスクを孕んでおり、絶対に行うべきではない。常に「tid」や「oid」といった、IdP固有の不変的な識別子を突合のキーとすべきである。

さて、ここで我々エンジニアに突きつけられた問いがある。AIエージェントに「ユーザーの代理権限」を無制限に与えることは、セキュリティ上のパンドラの箱を開けることにならないか？OBOは確かに便利だが、エージェントが暴走した際、その被害はユーザーの権限範囲に直結する。認可の自動化を進める一方で、我々は「最小権限の原則」をどう担保し、エージェントの行動をどう監視すべきか。単に「認可疲れ」を解消して終わりではなく、認可の委譲に伴うリスクを可視化し、ガバナンスをコードとして組み込むことこそが、シニアエンジニアに求められる責務である。明日から、貴方のチームの認可サーバーは、エージェントの「代行」を正しく識別し、制御できているだろうか？この問いに対する答えを設計に落とし込むことこそが、真のエンジニアリングである。