Agent2Agent (A2A) プロトコルを使用すると、エージェントは他のエージェントを呼び出すことができます。 ほとんどの A2A エンドポイントでは、エンドポイントとその基になるサービスにアクセスするために認証が必要です。 認証を構成すると、承認されたユーザーのみが Foundry Agent Service で A2A ツールを呼び出すことができます。
この記事では、A2A 接続で使用できる認証方法について説明し、シナリオに適したアプローチを選択するのに役立ちます。
認証シナリオ
一般に、次の 2 つの認証シナリオがあります。
- 共有認証: エージェントのすべてのユーザーは、同じ ID を使用して A2A エンドポイントに対する認証を行います。 個々のユーザー コンテキストは保持されません。 このアプローチは、すべてのユーザーが同じレベルのアクセス権を持つ必要がある場合に最適です。 たとえば、組織のAzure Cosmos DBから情報を取得するチャット エージェントを構築する場合、すべてのユーザーが個別のサインインを必要とせずに同じ共有コンテナーにアクセスできます。
- 個々の認証: エージェントの各ユーザーは自分のアカウントで認証されるため、ユーザー コンテキストは対話間で保持されます。 この方法は、アクションのスコープをユーザーのアクセス許可に設定する必要がある場合に不可欠です。 たとえば、GitHubからコミットとプル要求を取得するコーディング エージェントを構築する場合、各開発者が自分のGitHub アカウントでサインインして、アクセス権を持つリポジトリのみが表示されるようにします。
前提 条件
認証方法を選択する前に、次のものが必要です。
- Foundry ポータルとプロジェクトへのアクセス。 ない場合は、「 Foundry でプロジェクトを作成する」を参照してください。
- プロジェクトの Azure AI ユーザー 以上のロール。 このロールは、プロジェクト接続を作成し、エージェントを構成するためのアクセス許可を付与します。 詳細については、 Foundry ポータルのロールベースのアクセス制御に関するページを参照してください。
- 接続先の A2A エンドポイント URL。 エンドポイントがサポートする認証方法を確認するには、エンドポイントの発行元に問い合わせてください。
- 選択した認証方法の資格情報:
- キーベース: API キー、個人用アクセス トークン (PAT)、またはエンドポイント発行元からのその他のシークレット トークン。
- Microsoft Entra認証: 基になるサービスでのエージェント ID またはプロジェクトマネージド ID のロールの割り当て。 特定のロールは、サービス (たとえば、Cosmos DB データ閲覧者 Azure Cosmos DB) に依存します。
認証方法を選択する
選択する認証方法は、共有ユーザー コンテキストと個々のユーザー コンテキストのどちらが必要か、および A2A エンドポイントがサポートする認証プロトコルによって異なります。
次の表を使用して、シナリオに適した方法を選択します。
| あなたの目標 | 推奨される方法 |
|---|---|
| すべてのユーザーに 1 つの共有 ID を使用する | キーベースの認証またはMicrosoft Entra認証 |
| 各ユーザーの ID とアクセス許可を保持する | OAuth ID パススルー |
| 基になるサービスでMicrosoft Entraがサポートされている場合は、シークレットの管理を避ける | Microsoft Entra認証 |
| 認証を必要としない A2A エンドポイントに接続する | 認証されていないアクセス |
サポートされている認証方法
次の表は、A2A 接続で使用できる認証方法をまとめたものです。
| メソッド | 説明 | ユーザー コンテキストが保持される |
|---|---|---|
| キーベース | A2A エンドポイントで認証するための API キーまたはアクセス トークンを指定します。 単純なトークン ベースの認証を使用するエンドポイントに最適です。 | いいえ |
| Microsoft Entra ID - エージェント識別子 | エージェントのマネージド ID を使用して認証します。 基になるサービスに対するロールの割り当てが必要です。 マネージド ID をサポートするAzure サービスに最適です。 | いいえ |
| Microsoft Entra ID - プロジェクトマネージド ID | プロジェクトのマネージド ID を使用して認証します。 基になるサービスに対するロールの割り当てが必要です。 プロジェクト内のすべてのエージェントが同じ ID を共有する場合は、このオプションを使用します。 | いいえ |
| OAuth ID パススルー | ユーザーにサインインを求め、A2A エンドポイントへのアクセスを承認します。 ユーザーごとのアクセス許可が必要な場合に必要です。 | はい |
| 認証されていないアクセス | 認証は必要ありません。 この方法は、パブリックにアクセスできる、または認証を必要としない A2A エンドポイントにのみ使用します。 | いいえ |
キーベースの認証
メモ
プロジェクトにアクセスできるユーザーは、プロジェクト接続に格納されているシークレットにアクセスできます。 共有シークレットのみをプロジェクト接続に格納します。 ユーザー固有のアクセスには、代わりに OAuth ID パススルーを使用します。
A2A エンドポイントが API キー、個人用アクセス トークン (PAT)、または別のシークレット資格情報を受け入れる場合は、キーベースの認証を使用します。 セキュリティを強化するために、共有資格情報を実行時に渡す代わりに、プロジェクト接続に格納します。
Foundry ポータルで A2A エンドポイントをエージェントに接続すると、Foundry によってプロジェクト接続が作成されます。 資格情報名 (HTTP ヘッダー名) と資格情報の値 (ヘッダー値) を指定します。 形式は、エンドポイントが想定する内容によって異なります。
一般的な資格情報の形式:
| エンドポイントの種類 | 資格名 | 資格情報の値 |
|---|---|---|
| ベアラー トークン | Authorization |
Bearer <your-token> |
| ヘッダーの API キー | x-api-key |
<your-api-key> |
| カスタム ヘッダー | <custom-header-name> |
<your-secret-value> |
エージェントが A2A エンドポイントを呼び出すと、エージェント サービスはプロジェクト接続から資格情報を取得し、要求ヘッダーに含めます。
キーベース認証のセキュリティのベスト プラクティス
- 最小特権の資格情報を使用する: エージェントのタスクに必要な最小限のアクセス許可のみを要求します。
- トークンを定期的にローテーションする: 有効期限が切れる前にトークンを再生成するようにアラームを設定します。
- プロジェクト アクセスを制限する: 共有シークレットを含むプロジェクトにアクセスできるユーザーを制限します。
- 監査（Audit）資格情報の使用状況: Azure 活動ログでプロジェクトの接続アクセスを監視します。
Microsoft Entra ID認証
A2A エンドポイントとその基になるサービスがMicrosoft Entra ID トークンを受け入れる場合は、Microsoft Entra ID認証を使用します。 この方法では、トークンの取得と更新が自動的に処理されるため、Azureシークレットを管理する必要がなくなります。
エージェント識別
エージェントのマネージド ID を使用して、Microsoft Entra ID認証をサポートする A2A エンドポイントで認証します。 エージェント サービスでエージェントを作成すると、エージェントは自動的にマネージド ID を受け取ります。
ID ライフサイクル:
- 発行前: 同じプロジェクト内のすべてのエージェントが共通の ID を共有します。 これにより、開発とテストが簡略化されます。
- 発行後: 発行された各エージェントは、一意の ID を受け取ります。 これにより、分離が実現され、きめ細かなアクセス制御が可能になります。
エージェント ID のライフサイクルの詳細については、「Microsoft Foundry の
エージェント ID 認証を構成するには:
- A2A エンドポイントを実行する基になるサービス (Azure Cosmos DBやAzure Storageなど) を特定します。
- そのサービスのエージェント ID に必要なロールを割り当てます。 特定のロールは、エージェントが実行する必要があるサービスと操作によって異なります。
- エージェント ID 認証を使用するように A2A 接続を構成します。
エージェントが A2A エンドポイントを呼び出すと、エージェント サービスはエージェント ID を使用して、Microsoft Entra IDから承認トークンを要求し、それを要求に含めます。
Foundry プロジェクトのマネージド ID
Foundry プロジェクトのマネージド ID を使用して、A2A エンドポイントで認証します。 このオプションは、プロジェクト内のすべてのエージェントがリソースにアクセスするために同じ ID を共有する場合に便利です。
プロジェクトマネージド ID 認証を構成するには:
- A2A エンドポイントに電力を供給する基になるサービスを特定します。
- 必要なロールを、そのサービスのプロジェクトのマネージド ID に割り当てます。
- プロジェクトマネージド ID 認証を使用するように A2A 接続を構成します。
エージェントが A2A エンドポイントを呼び出すと、Agent Service はプロジェクトのマネージド ID を使用して、Microsoft Entra IDから承認トークンを要求し、それを要求に含めます。
OAuth ID パススルー
メモ
OAuth ID パススルーを使用するには、エージェントと対話するユーザーには、少なくともプロジェクトの Azure AI User ロールが必要です。
OAuth ID パススルーを使用すると、エージェントは個々のユーザーに代わって動作できます。 個人用ファイル、リポジトリ、その他の保護されたリソースへのアクセスなど、各ユーザーのアクセス許可に対するアクションのスコープを設定する必要がある場合は、このメソッドを使用します。
OAuth ID パススルーは、OAuth 2.0 をサポートする Microsoft および Microsoft 以外の A2A エンドポイント (Microsoft Entra IDを使用するサービスを含む) で機能します。
OAuth ID パススルーのしくみ
- 最初の対話: ユーザーが最初にエージェントと対話すると、Agent Service によって同意リンクが生成されます。
- ユーザーの同意: ユーザーはリンクを開き、基になるサービスにサインインし、エージェントが自分のデータにアクセスすることを承認します。
- トークン ストレージ: エージェント サービスは、ユーザーの OAuth トークン (アクセス トークンと更新トークン) を安全に格納します。 これらのトークンのスコープは、その特定のユーザーとエージェントの組み合わせです。
- 後続の要求: エージェントが A2A エンドポイントを呼び出すと、エージェント サービスは要求にユーザーのアクセス トークンを含めます。 アクセス トークンの有効期限が切れると、エージェント サービスは更新トークンを使用して新しいトークンを取得します。
OAuth トークンの種類
OAuth では、次の 2 種類のトークンが使用されます。
| トークンの種類 | 目的 | 有効 期間 |
|---|---|---|
| アクセス トークン | 基になるサービスへの API 呼び出しを承認します | 侵害された場合に露出を制限する有効期間が短い (通常は 1 時間) |
| 更新トークン | ユーザーが再度サインインする必要なく、新しいアクセス トークンを取得します。 | 有効期間が長い (数時間から数週間、または取り消されるまで) |
OAuth スコープは、エージェントがユーザーに代わってアクセスして実行できる内容を定義します。 スコープは、接続を構成するときに指定され、同意フロー中にユーザーに表示されます。 OAuth の詳細については、Microsoft セキュリティに関するドキュメントを参照してください。
マネージド OAuth とカスタム OAuth
エージェント サービスでは、次の 2 つの OAuth 構成オプションがサポートされています。
| オプション | 説明 | 使用するタイミング |
|---|---|---|
| マネージド OAuth | Microsoftまたは A2A エンドポイントパブリッシャーが OAuth アプリの登録を管理します。 | 使用可能な場合に使用します。 セットアップを簡略化し、構成エラーを減らします。 |
| カスタム OAuth | Microsoft Entra IDまたは別の ID プロバイダーから独自の OAuth アプリ登録を提供します。 | マネージド OAuth を使用できない場合、またはカスタム スコープまたはブランド化が必要な場合に使用します。 |
カスタム OAuth を構成するには、次の情報を指定します。
- クライアント ID: OAuth アプリ登録のアプリケーション ID。
- クライアント シークレット (必要な場合): アプリの登録に関連付けられているシークレット。
- 承認 URL: ユーザーがアクセスを承認するエンドポイント。
- トークン URL: エージェント サービスがトークンの承認コードを交換するエンドポイント。
- 更新 URL: 有効期限が切れたアクセス トークンを更新するためのエンドポイント。
-
Scopes: エージェントに必要なアクセス許可 (たとえば、GitHubの場合は
repo、Microsoft Graph の場合はFiles.Read)。
重要
カスタム OAuth を使用する場合は、エージェント サービスからリダイレクト URL を受け取ります。 この URL を OAuth アプリ登録の許可されたリダイレクト URI に追加して、エージェント サービスが承認フローを完了できるようにします。
認証されていないアクセス
認証されていないアクセスは、A2A エンドポイントがパブリックにアクセスでき、認証を必要としない場合にのみ使用します。 このオプションは運用環境のシナリオではまれですが、次の場合に適している場合があります。
- 認証を必要としないパブリック API
- 内部開発またはテストエンドポイント
- 認証ではなく、ネットワーク レベルのセキュリティ (プライベート エンドポイントなど) によって保護されるエンドポイント
A2A 接続の認証を設定する
A2A 接続の認証を構成するには、次の手順に従います。
A2A エンドポイントとサポートされている認証方法を特定します。 エンドポイントの発行元に問い合わせるか、エンドポイントのドキュメントを確認して、サポートされている認証方法を確認してください。
選択した認証方法に基づいて、必要な資格情報を収集します。
- キーベース: エンドポイントパブリッシャーから API キーまたはトークンを取得します。
- Microsoft Entra ID: 基になるサービスに必要なロールの割り当てを特定します。
- OAuth: マネージド OAuth が使用可能かどうかを判断するか、カスタム OAuth アプリ登録の詳細を収集します。
Foundry ポータルでプロジェクト接続を作成します。 接続には、A2A エンドポイントの URL、認証方法、および資格情報が格納されます。
- 一般的な接続ガイダンスについては、「 新しい接続をプロジェクトに追加する」を参照してください。
- A2A 固有の構成については、「 Foundry Agent Service への A2A エージェント エンドポイントの追加」を参照してください。
ロールの割り当ての構成 (Microsoft Entra ID認証のみ)。 必要なロールを、基になるサービスのエージェント ID またはプロジェクトマネージド ID に割り当てます。
A2A ツールをエージェントに追加します。 作成したプロジェクト接続を参照し、エージェントが呼び出すことができる A2A エンドポイントからどのツールを構成するか。
認証を検証する
認証を構成したら、接続をテストして正常に動作することを確認します。
キーベースまたはMicrosoft Entra ID認証を検証する
- Foundry ポータルでエージェントを開きます。
- 会話を開始し、A2A ツールを呼び出すアクションをトリガーします。
- ツールの呼び出しが正常に完了したことを確認します。 呼び出しが失敗した場合は、エラー メッセージを確認し、「 トラブルシューティング」を参照してください。
OAuth ID パススルーを検証する
- 以前に同意していないテスト ユーザー アカウントを使用して、Foundry ポータルでエージェントを開きます。
- 会話を開始し、A2A ツールを呼び出すアクションをトリガーします。
- エージェントの応答に同意リンクが表示されることを確認します。
- 同意リンクを開き、テスト ユーザーの資格情報でサインインします。
- 要求されたアクセス許可を承認します。
- エージェントに戻り、A2A ツールをもう一度トリガーします。
- テスト ユーザーの資格情報を使用して、ツールの呼び出しが正常に完了したことを確認します。
- (省略可能)別のユーザー アカウントでテストし、複数のユーザーの同意フローが機能することを確認します。
トラブルシューティング
次の表を使用して、一般的な認証の問題を診断して解決します。
| 問題 | 考えられる原因 | 解決方法 |
|---|---|---|
| 401 Unauthorized でキーベースの認証が失敗する | 無効なトークンまたは期限切れのトークン | エンドポイントパブリッシャーからトークンを再生成し、プロジェクト接続を更新します。 |
| キーを使用した認証が400 Bad Requestで失敗する | ヘッダー名または値の形式が正しくありません | 予想されるヘッダー形式については、エンドポイントのドキュメントを確認してください。 一般的な形式には、 Authorization: Bearer <token> と x-api-key: <key>があります。 |
| Microsoft Entra ID認証が 403 Forbidden で失敗する | ID に必要な役割の割り当てがありません | 必要なロールを、基になるサービスのエージェント ID またはプロジェクトマネージド ID に割り当てます。 ロールの割り当ての変更が反映されるまでに最大 10 分かかることがあります。 |
| Microsoft Entra ID認証が 401 Unauthorized で失敗する | 基になるサービスが Microsoft Entra IDトークンを受け入れないか、対象が正しくない | 基になるサービスでMicrosoft Entra ID認証がサポートされたことを確認します。 A2A エンドポイントが正しい対象ユーザーのトークンを受け入れるように構成されていることを確認します。 |
| 同意は完了したが、ツールの呼び出しは失敗する | ユーザーが基になるサービスのアクセス許可を持っていない | 基になるサービスで必要なアクセス許可がユーザーに付与されていることを確認します。 また、ユーザーが Foundry プロジェクトに少なくとも Azure AI User ロールがあることを確認します。 |
| OAuth に同意リンクが表示されない | OAuth ID パススルーが構成されていないか、エージェントが A2A ツールを呼び出さなかった | プロジェクト接続が OAuth ID パススルー用に構成されていることを確認します。 A2A ツールを呼び出すアクションをトリガーします。 |
| 同意リンクが表示されるが、サインインに失敗する | カスタム OAuth 構成が正しくありません | カスタム OAuth の場合は、承認 URL、クライアント ID、およびリダイレクト URL が正しいことを確認します。 OAuth アプリの登録にリダイレクト URL が追加されていることを確認します。 |
| 更新トークンの有効期限が切れています | ユーザーが長期間エージェントと対話していない | ユーザーは、同意フローをもう一度実行する必要があります。 これは、セキュリティ上の予期される動作です。 |
関連コンテンツ
- A2A エージェント エンドポイントを Foundry Agent Service に追加する: エージェントの A2A ツールを構成するためのステップ バイ ステップ ガイド。
- Microsoft Foundry の
Agent ID の概念: エージェント ID のしくみとそのライフサイクルについて説明します。 - Microsoft Foundry におけるロールとアクセス許可を理解する。
- 新しい接続をプロジェクトに追加する: プロジェクト接続を作成するための一般的なガイダンス。