本記事は元々 blog.logto.io に掲載されたものです。
最近、この記事をレビューし、エージェント認証について言及しました：
これがどのように見えるかのヒントが見られます。たとえば、最新の MCP スペックには、OAuth 2.1 に基づく認可フレームワークが含まれており、AIエージェントにスコープされた、取り消し可能なトークンを与える可能性があることを示しています。AIエージェントが実際の AWS キーを取得するのではなく、短命のクレデンシャルや特定のアクションを実行するための能力トークンを取得するシナリオを想像できます。
https://a16z.com/nine-emerging-developer-patterns-for-the-ai-era/
多くの友人や、セキュリティ分野や CIAM 分野にいない人々は、これが新しいものだという印象を受けますが、決してそうではありません。OAuth は、スコープされた許可（アクセストークン）を持つトークンを含む標準的なトークンベースの認可プロトコルです。これらは時間に敏感でスコープが制限されており、リソースやサービスへの適切なアクセス制御とセキュリティを保証します。グローバル SaaS 市場（AI 前）では、ほとんどのプロフェッショナルなアイデンティティソリューションは既にこれに基づいて構築されています。
Google アカウントを Notion や Zoom などのサードパーティアプリに接続する際、OAuth を使用してカレンダーや連絡先へのアクセスなど必要な許可のみを要求し、Google パスワードを公開することはありません。この委任されたアクセスパターンはまさに OAuth が設計されたものであり、今日、エージェントアプリケーションに拡張されている同じ基盤です。
エージェント世界で変わらないこと
認証は新しいものではなく、依然として OAuth 2.1 に基づいている
2つの主要なプロトコルが出現しています：MCP と A2A。
- MCP は、LLM とアプリのツールやコンテキストとの相互作用に焦点を当てています。
- A2A は、エージェント間のタスク交換を可能にすることに焦点を当てています。
しかし、認証と認可に関しては、どちらも引き続き OAuth のような確立された業界標準に依拠しています。
MCP 認可サーバーは、OAuth 2.1 を適切なセキュリティ措置とともに両方のクライアントに対して実装する必要があります（MUST）。
A2A クライアントは、必要なクレデンシャル材料（例：OAuth 2.0 トークン、API キー、JWT）を A2A プロトコル自体の外部のプロセスを通じて取得する責任があります。これには、OAuth フロー（認可コード、クライアントクレデンシャル）、セキュアキー配布などが含まれる可能性があります。
Google が言うように：
セキュリティと運用のために新しい、独自の標準を発明するのではなく、A2A は既存の企業インフラや広く採用されているベストプラクティスとシームレスに統合することを目指しています。
エージェントにはユニークなアイデンティティが必要ですか？
多くのハイプや FOMO コンテンツが、エージェントがより一般的になるにつれて、エージェントのアイデンティティを管理するシステムが必要だという考えを押し出しています。
答えは：はいといいえ。
はい、人間と機械の間に新たな層を導入するからです。以下の実際のニーズがあります：
- エージェントを管理し特定する
- ユニークなIDを割り当てる
- ログを追跡する
- 行動を監査する（タスクが人間またはエージェントによって行われたかどうか）
しかし、多くの技術的な場合、正式な「エージェントアイデンティティ」の概念を作成する必要はありません。
エージェント ≠ ユーザー ≠ サービスアカウント。
すべてのエージェントの背後には依然としてユーザーが存在し、通常はユーザーのアイデンティティが十分です。
今日、ほとんどのエージェントは：
- ユーザーの権限（例：OAuth トークン）に基づいて行動する
- ロジックを実行するか API コールを行う
- 追跡を必要としない、一度限りの短命タスクを遂行する
その意味では、エージェントは ツールとしての機能 に過ぎず、グローバルに唯一の ID を必要としません。
例：
- カレンダー API を呼び出す GPT エージェントは、あなたが提供したアクセス権しか必要としません。
- ラングチェーン エージェントは、正しいツールを呼び出せる限りアイデンティティを必要とせずに動作します。
AI 以前でも、機械間（M2M）認証の概念がありました。
M2M とは、サービス間の自動データ交換であり、人間の介入はありません。
この文脈では、認証はクライアントアプリまたはサービスアカウントを使用することがよくあります。
監査などのために本当にエージェントにアイデンティティを持たせたい場合は、アプリ ID を使用し、それで十分です。
製品のアーキテクチャを定義する必要がある
これは変わっていません。製品がエージェントを含むかどうかにかかわらず、アイデンティティシステムのアーキテクチャは、ユーザーが誰か、システムがどのようにそれらと対話するかに依存します。
消費者向けエージェント製品を構築している場合：
軽量なサインイン方法（メール、電話、ソーシャルログイン）と、アプリやそのエージェントと対話する個人を管理する統一されたユーザープールを必要とします。エージェントは、委任されたトークン（例：OAuth 経由）を使用してこれらのユーザーの代理で行動します。
例：
AI スケジューリングアシスタントや AI 主導のカレンダーボットを構築していると想像してください。
各ユーザーは個人的な Google アカウントでログインします。あなたのシステムは、彼らのカレンダーにアクセスする許可を得るために OAuth を使用します。エージェントが自身のアイデンティティを持つわけではなく、ユーザーのトークンを使用して会議をスケジュールしたり、利用可能かどうかを確認したり、リマインダーを送信します。アイデンティティアーキテクチャはシンプルです：グローバルなユーザープール、トークンストレージ、ユーザーごとの同意追跡。
B2B エージェント プラットフォームを構築している場合：
個々のユーザーだけでなく、組織レベルでのアイデンティティのサポートが必要です。これには以下が含まれます：
- 企業クライアント向けの SSO
- ワークスペースまたはテナントレベルの分離
- 組織レベルでのエージェントの委任ポリシー（例：チーム全体でエージェントができることを制御）
- 従業員の代理でのすべてのエージェント活動に対する管理レベルの可視性とログ
例：
内部ワークフローを自動化するための AIエージェントを提供するプラットフォームを構築していると想像してください。セキュリティアナリストボットがログを監視しアラートを送信したり、CRM データからメールを作成する営業アシスタントのように。
あなたのプラットフォームを使用する各企業は次を行いたいと望んでいます：
- 既存の SSO を使用してログインする
- エージェントがアクセスできるものを制御する（例：内部ツール、ドキュメントシステム）
- どのエージェントがどのタスクを、どの従業員の権限下で行ったかを確認する
この場合、アイデンティティアーキテクチャはマルチテナント設計、スコープされたエージェントの許可、および企業テナントごとに適用されるポリシーをサポートする必要があります。エージェントは依然としてユーザーの代理で行動しますが、許可とアイデンティティの境界はビジネステナントごとに強制されます。
どちらの場合でも、アイデンティティモデルはエージェントがどのように操作するか、何にアクセスできるか、システムがどのように責任を確保するかを定義します。
このガイドを使って、あなたのアイデンティティと製品アーキテクチャを計画するのに役立ててください。
エージェント駆動のアプリを安全に保つためのセキュリティレイヤーが必要
エージェントアプリであれそうでない場合であれ、これらの基本的なセキュリティレイヤーはユーザーやシステムを保護するのに必要です：
-
資格情報が危殆化された場合でも、不正なアクセスを防ぎます。
例：エージェントが取引を行うなどの高リスクな行動を手助けする場合、人間を介在させ、行動を進める前に MFA を使用して行動を確認するべきです。
-
資格情報詰め込みやボットを使ったサインアップのような自動化された悪用を防ぎます。
例：3 回のログイン試行失敗後にキャプチャを表示してブルートフォース攻撃を防ぎます。
-
ユーザーとエージェントが許可されたもののみをアクセスできるようにします。
例：企業ワークスペースの AI アシスタントはカレンダーイベントを読むことができますが、明示的により高い役割を割り当てられない限り課金データにはアクセスできません。
-
UX を改善し、弱いパスワードのリスクを減少させます。
例：ユーザーがメールに送信されたマジックリンクや Face ID のようなバイオメトリックプロンプトを使ってサインインできるようにする。
これらの機能は伝統的なアプリとエージェントベースのアプリの両方に適用され、特にエージェントが機密データやシステムを横断するように操作を始めた際に重要です。
エージェント世界で変わったこと
認証はこれまで以上に重要
エージェントと多エージェントのワークフローが出現する中で、ユーザー、エージェント、API、MCP サーバーがすべて相互作用する新しいユースケースが見られます。これらのシナリオの数と種類は、過去よりもはるかに速く増えてきています。
これらの接続が発生するたびに、認可がこれまでになく顕著に なります。ユーザーは明確な同意を与え、システム間での許可は慎重に管理される必要があります。だからこそ、今皆が「人間を介在させる」ことについて話しているのです。エージェントができること、そしてどのスコープで認可を受けているかに関してユーザーが十分なコントロールと可視性を持つようにする必要があるのです。
あなたの AI アプリは多くの外部サービスと統合する必要があります
MCP エコシステムが拡大しているため、アプリはもはや単なるスタンドアローンのサービスではなく、より大きな接続されたネットワークの一部となります。
LLM に豊富で有用なコンテキストを提供するために、エージェントは以下を行う必要があるかもしれません：
-
複数の MCP サーバーにアクセスする
例：Jira からのタスク更新、Google カレンダーからのチームの可用性、Salesforce からの販売データを引き出す AI プロジェクトマネージャーを想像してください。そしてこれらのそれぞれが異なる MCP サーバーによって稼働しているかもしれません。週次サマリーを一つ生成するためにエージェントは複数のデータソースと安全に対話しなければなりません。認証と認可はすべての接続を保護し、データがどのように共有されるかを管理します。
-
外部 API やツールと接続する
例：カスタマーサポートエージェントが Shopify からの注文履歴を取得したり、Zendesk でチケットを更新したり、Slack でワークフローをトリガーする必要があるかもしれません。統合がなければエージェントは孤立し非効率的になります。
エージェントがより多くの責任を担うにつれて、統合が有用性の鍵となります。 あなたの AI 製品は単独で何ができるかだけではなく、アクセスできるもの、調整できるもの、および接続されたエコシステム内で推論できるものです。それが、今まさに、インターオペラビリティを考慮して構築することがかつてないほど重要になっている理由です。
オープンスタンダードを受け入れる必要があります：OAuth/OIDC はこれまで以上に重要
AI の時代において、セキュアで柔軟な統合の必要性が増しています。それが OAuth 2.0 と OIDC がこれまで以上に重要であることを意味します。
主なユースケースには次のようなものがあります：
- リモート MCP サーバー：サードパーティのエージェントが委任されたトークンを使って製品に安全にアクセスできるようにする。
- サードパーティ統合：他のツールやエージェントがアプリ（例：プロジェクト管理プラットフォーム）と接続できるようにする。必要に応じて生の資格情報を必要とせずに。
- エージェント開発：サービス間でユーザーの代理として安全に行動できる AI エージェントを構築する。
- スマートデバイス：OAuth/OIDC を使用して、AI 駆動のメモテイカーがユーザーを認証しクラウドに接続するようにする──特に UI が最小限である場面で。
これらのプロトコルはセキュアで、トークンベースの、ユーザーの同意を得たアクセスを提供します。
それは、エージェント的な、接続されたシステムの世界で必要不可欠です。このOAuth および OIDC が重要な理由に関する記事をチェックしてください。
エージェント ソフトウェアの時代における信頼とスケールのための設計
エージェント製品が進化する中で、アイデンティティと認可の核となる原則は変わりませんが、文脈が変化しています。エージェントは委任、同意、アクセスのための新しい表面を導入します。だからこそ、OAuth のようなオープンスタンダードに拘ること、明確なアーキテクチャを構築すること、そして堅固なセキュリティプラクティスを強化することが、単なるベストプラクティスではなく、基本であるということです。今慎重に設計することで、あなたのシステムは信頼性と柔軟性を持って AI パワードな未来に向けてスケールすることができます。