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