re:Invent 2025: Amazon Bedrock AgentCore IdentityによるAIエージェントアクセス保護
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Securing agent access with Amazon Bedrock AgentCore Identity (SEC313)
この動画では、AWSのPrincipal Product ManagerであるRahulとBenが、Amazon Bedrock AgentCore Identityを使用したエージェントアクセスの保護について解説しています。agentic AIの業界動向として、Gartnerによると2028年までにエンタープライズアプリケーションの33%がagentic AI要素を持つようになると予測されています。エージェント構築における主要な課題として、呼び出し元の検証、同意管理、スコープを限定したシステムアクセス、カスタムコードの必要性が挙げられます。AgentCore Identityは、ワークロードIDの作成、OAuthフローのオーケストレーション、トークンボルトによる認証情報管理を通じてこれらの課題を解決します。three-legged OAuthとtwo-legged OAuthの両方のアクセスパターンをサポートし、AWS CloudTrailとの統合により監査可能性を提供します。re:Inventでは、カスタムクレームとスコープのサポート、Gateway用のthree-legged OAuthサポート、AgentCore Policyなどの新機能が発表されました。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
セッション開始：Bedrock AgentCore Identityによるエージェントアクセス保護の全体像
はい、皆さんこんにちは。私はRahulです。AWSのPrincipal Product Managerで、生成AI、機械学習、そしてユーザー認証に注力しています。本日は、Bedrock AgentCore Identityを使用したエージェントアクセスの保護についてお話しできることを、大変嬉しく、そしてワクワクしています。それでは、前置きはこのくらいにして、早速始めましょう。その前に、もう一度確認させてください。私の声は聞こえていますか？皆さん聞こえていますでしょうか？完璧ですね。素晴らしい。では始めましょう。
本日は、これから1時間かけて幅広いトピックをカバーしていきます。まず、agentic AIの業界コンテキストを広く設定することから始め、その後、各トピックごとにどんどん深掘りしていきます。エージェントのアクセスを保護することに関連する認証の課題についてお話しします。そして、Bedrock AgentCore Identityを皆さんにご紹介し、これが私たちが指摘するすべての課題にどのように対処するかについてお話しします。さらに深く掘り下げて、Bedrock AgentCore Identityが可能にするagenticアクセスパターンについてお話しし、最後にAgentCore Identityの新機能についてお話しします。re:Inventでたくさんの発表を行いましたので、皆さんが製品を使い始められるよう、それらについて最新情報をお伝えしたいと思います。
Agentic AIへの全力投資：生産性向上と市場投入スピードを加速する業界トレンド
それでは、agentic業界のコンテキストを設定するために、Benにバトンタッチします。ちょっと手を挙げていただけますか、今日、agentic AIの領域で何か構築している方はいらっしゃいますか？驚きませんね。 さて、明らかなことですが、企業はエージェントに全力投資しています。これは驚くことではないと思います。皆さんは4日目にここにいて、かなり満席の聴衆です。これは重要なトピックです。展示ホールに行けば、agentic AIを中心にどれだけの投資が行われているかが分かります。個人的には、毎日それを目にしています。 今週私が行ったすべての顧客との会話は、エージェントをより早く本番環境に導入するのをどう支援してくれるか、というものでした。
そして、これを見ているのは私たちだけではありません。Gartnerによると、2028年までに、わずか数年後には、すべてのエンタープライズアプリケーションの33%、つまり3分の1がagentic AIの要素を持つようになるとのことです。これは昨年のわずか1%から増加しています。おそらく昨年は1%が、このAI要素を投入しなければならないニッチな小さなユースケースを持っていたかもしれませんが、今ではそれはかなり主流になっています。アプリケーションの構築方法において一般的になっています。 さらに、彼らは私たちの意思決定の15%が自律的に行われるようになると言っています。皆さんはどうか分かりませんが、私は今後、自分の意思決定の15%が自律的に行われることに不満はありません。これは招待への返信やチケットへの対応などです。ユースケースは無限ですが、私の意思決定の15%がどこか別の場所に行って、時間を解放してくれることに不満はありません。
それでは、何がそれを推進しているのか自問しなければなりません。これのいくつかはかなり明白だと思います。まず第一に、生産性です。繰り返しになりますが、個人的に、私はProduct Managerとして毎日agentic AIツールを使用しています。顧客フィードバックの統合、皆さんが日々提供してくださる機能リクエストなどに使用しています。ドキュメントの作成を加速するためにも使用しています。ご存知のように、Amazonは大きなドキュメント文化を持っています。PMとして、私たちはこれらを使用してドキュメントをAmazonのライティングスタイルに合わせることができます。
最近、私たちはUXモックを構築するのに役立つ素晴らしいツールを手に入れました。プロダクトマネージャーとして、自分のアイデアを実現したいと思っていたのですが、それを実現する最良の方法はモックを作ることです。以前は、UXデザイナーの順番待ちに入って、そのデザインが実現するまで2週間ほど待つ必要があり、ただただ不安な気持ちで待っていました。そして今では、わずか15分で、いくつかの簡単なプロンプトと反復作業で、これらの素晴らしいUXモックが実現できるツールを手に入れたのです。つまり、明らかなメリットは、スケールでの生産性向上です。皆さんもこれを実感されていると思います。
次に、これらのコンテキストアウェアな体験と意思決定が見られるようになります。例えば、開発者として何万行、何十万行ものコードやビジネスロジックを書いて、これらの体験を実現しようとしていたような状況です。 今では、それらはコンテキストアウェアになり、LLMへのシンプルな呼び出しで実現できます。さまざまな機会が開かれているのです。ですから、私たちが実現できる体験の種類、そしてこのコンテキストアウェアネスは、本当に素晴らしいものです。
最後に、市場投入までの時間の短縮です。先ほど申し上げたように、プロダクト側から得られる生産性の向上だけでなく、コーディングエージェント、ドキュメントの自動開発などによるエンジニアリング側から得られる生産性の向上により、お客様へのサービス提供能力が加速しているのです。明確な、明確なメリットがあります。
本番化への壁：セキュアアクセス、制御された自律性、進化したガバナンスという3つの課題
メリットは明確です。では次の質問は、これが実際に組織にとって何を意味するのかということです。素晴らしいプロトタイプがあります。そのプロトタイプは本当に、本当に価値があることが証明されています。しかし、そこで、ちょっと待てよとなるわけです。 実際にこれを本物にしなければならない。そして、最初に聞かれる質問の一つが、セキュアアクセスです。エージェントは、タスクを実行するために、必要な分だけのアクセス権を、必要なタイミングで持つべきです。では、どうやってそれを実現するのでしょうか？エージェントに独自のアイデンティティを与えるのでしょうか？独自のアクセス権を与えるのでしょうか？おそらく最善の決定ではありません。エージェントは非決定論的ですから。これは、エージェントを構築し始める際に考え抜かなければならないことです。
次は、この面白い制御された自律性です。私たちはこれを健全な綱引きと呼んでいます。クラウドが最初に登場したときのことを思い出します。開発者にはクラウドリソースへのオンデマンドアクセスを与えて、アジャイルに、素早く動けるようにしたいという綱引きがありました。そして運用チームは、ちょっと待って、セキュリティとコンプライアンスの要件があるんだと言っていました。今、同じ綱引きが再び起こり始めているのを目にしています。
組織はエージェントのメリットを確認したいと考えており、これらのクールなことができることは理解していますが、どのようにコントロールとコンプライアンスを整備すればよいのかと問いかけています。そのため、同じ綱引きが発生します。つまり、迅速に進める必要がありますが、コントロールされた方法で迅速に進める必要があるのです。
最後に、進化したガバナンスです。エージェントは人間ではありません。人間のガバナンスについては、ある程度解決されていますよね。長い間存在してきました。アイデンティティプロバイダーや人間のライフサイクル管理があります。そして、マシンが登場しました。マシンは管理が非常に簡単です。決定論的なので、アクセス権を与えても安全です。毎回何をするかがわかっています。そして今、突然、エージェントという新しいエンティティタイプが登場しました。エージェントとは何でしょうか。人間でもなく、マシンでもありません。組織が今やガバナンスについて考えなければならない、本当に第三のエンティティなのです。どのようにライフサイクル管理を行うのか。どのように適切な所有権を持つのか。エージェントが持つ権限の監査をどのように確保するのか。このような新しいことが組織にとって考えなければならないこととして出てきており、それらは困難です。
営業担当役員Sarahの事例：クライアントブリーフ作成で見えるアクセスパターンと認証課題
このような背景を説明したところで、Rahulに引き継ぎます。彼が、これらを扱う際の認証の課題について、実際にどういう意味を持つのか、もう少し深く掘り下げていきます。ありがとうございます、Ben。agentic AIシステムを組織が採用する原動力となっている業界の背景について説明していただきました。 組織がなぜagentic AIを採用しているのかを理解したところで、もう一度挙手をお願いします。実際に組織で本番環境でエージェントを構築している方はどのくらいいらっしゃいますか。かなり多くの方がいらっしゃいますね。ですので、認証の課題についてはすでにご存知の方もいらっしゃると思いますが、多くのお客様から聞いている課題について、本当に深く掘り下げていきます。
認証の課題について説明する前に、一般的なアクセスパターンにはどのようなものがあるかを理解することが重要です。お客様、皆様とお話しする中で、2つの主要なカテゴリーが聞かれます。 まず第一に、エージェントが人間のユーザーに代わってタスクを実行する場合です。これは典型的な例で、ユーザーが本来自分で実行できたであろうタスクを実行するようにエージェントに委任します。このカテゴリーでは、3つの例または3つのシナリオが見られます。
最初のシナリオは、人間のユーザーが非常に特定のタスクを実行するためにヘルパーエージェントに委任する場合です。例えば、組織内でサポートチケットのキューが多くなっている場合があります。サポートチケットを要約し、根本原因分析を行うためにエージェントを使用するというお客様のユースケースを聞いています。これがタスク固有のエージェントです。2つ目の例は、人間のユーザーが汎用オーケストレーターエージェントにタスクを使用または委任し、そのエージェントがユーザーが実行したいアクションの性質を判断し、次にタスク固有のアクションを実行するためにセカンドエージェントまたはサブエージェントに委任するというものです。典型的な例は、汎用の生産性AIエージェントアシスタントがあるとします。そのエージェントに、Google Calendarにカレンダーイベントを設定してもらえますか、メールの概要を書いてもらえますか、組織内のすべてのサポートチケットの根本原因分析を行ってもらえますか、あるいはCRMシステムから販売記録を取得してもらえますか、といったことを依頼できます。この汎用エージェントにタスクを与えると、そのエージェントが他のタスク固有のエージェントと対話してそれらのアクションを実行します。
3つ目のカテゴリーは、人間のユーザーがエージェントを呼び出し、そのエージェントがMCPサーバーを呼び出して、MCPサーバーが公開している様々なツールを呼び出すことで、ターゲット固有のリソースにアクセスするというものです。これがパターン1ですね。2つ目のパターンとしてよく耳にするのは、エージェントがイベントや事前に承認されたユーザーの同意に応じてタスクを実行するというものです。典型的な例としては、バックグラウンドジョブ、スケジュールされたタスク、またはイベント駆動型の自動化などがあります。例えば、毎週水曜日の午後8時に特定のデータベースにクエリを実行して週次のビジネスレポートを生成するようにスケジュールされたエージェントがあるとします。これが1つの例です。イベント駆動型の自動化の例としてよく耳にするのは、キューに重大度の高いチケットがある場合に、エージェントにログを分析させて根本原因分析を提供させるというものです。これらは、お客様から広く聞いている例の一部です。
では、これらのアクセスパターンの1つについて、もう少し詳しく掘り下げて、例をより具体的にしていきましょう。組織におけるエージェントAIのユースケースのサンプルについてお話しします。on-behalf-ofフローについてお話しします。これは人間がエージェントにアクションを委任するというものです。この例では、営業担当役員がいます。彼女をSarahと名付けましょう。彼女は今度のクライアントミーティング、つまり顧客ミーティングの準備をしたいと考えており、基本的にエージェントを使ってこれらのクライアントミーティングの準備を手伝ってもらいたいと思っています。
以前、エージェント以前の時代には、彼女がやっていたことは、CRMシステムにアクセスして、すべての顧客ノートを手動で確認し、顧客ミーティングに行く前にクライアントブリーフを準備するというものでした。あるいは、このタスクをチームに委任して同じことをやってもらっていました。ご想像の通り、これは多くの手作業です。Benが先ほどお話ししたように、エージェントを活用することで得られる大規模な生産性向上、それがSarahが今このユースケースで実現しようとしていることです。
そこでSarahは、これらのクライアントブリーフを自分で準備する代わりに、組織内のAIエージェントに自然言語を使ってプロンプトを出し、今度の顧客ミーティングの準備を手伝ってもらいます。エージェントは、受け取ったこの自然言語クエリを使って、2つのシステムにアクセスする必要があると判断します。CRMシステムにアクセスして、この顧客との過去のディスカッションからすべてのミーティング記録とコールノートを取得する必要があり、さらに組織内の財務システムにアクセスして過去の顧客の支出データを取得する必要があります。そこでエージェントは、必要だと判断すると、Sarahに戻って、エージェントがこれらのシステムにアクセスすることを許可する同意を求めます。
Sarahがこの同意を与えると、エージェントはSarahがCRMシステムや財務システムに対してアクセス権を持っている権限を使用して、ノートや財務支出データを取得することができます。エージェントがこの情報を取得した後、それを要約して、営業担当役員向けにパーソナライズされたクライアントブリーフを作成することができます。別のツールを使ってブリーフを要約し、それに対する書き込みアクセス権を持ち、それをSarahに出力して、彼女が営業ミーティングの準備ができるようにします。
それでは、これがサンプルのユースケースです。このプレゼンテーションの複数の箇所でこのユースケースを参照しながら、いくつかの課題についてご説明していきます。それでは早速見ていきましょう。このような比較的シンプルなクライアントブリーフを準備するagenticワークフローでさえ、明確なアイデンティティとアクセス管理の課題が伴います。それでは、まずこれらの課題が何であるかを理解していきましょう。
4つの認証課題：呼び出し元検証、同意管理、スコープ限定アクセス、カスタムコードの負担
まず第一に、呼び出し元が誰であるかを検証するという課題があります。このエージェントは、誰が呼び出しているのか、つまりこのジョブを実行するために自分を呼び出している人間のアイデンティティが誰なのかを知る必要があります。また、このユーザーがこのエージェントを呼び出すことを許可されているか、承認されているかどうかを識別する必要もあります。これが第一です。ステップ1は呼び出し元の検証です。
第二のステップは同意の管理です。先ほどの例で話したことを思い出してください。Sarahはこのエージェントがブリーフを準備するために、CRMシステム、財務システム、さらにはこのメール作成システムにアクセスするための同意を委任する必要があります。エージェントは、これらのシステムにアクセスして作業を行うために、特定の読み取り・書き込み権限を持つ必要があり、それもSarahによって同意が付与された後にのみ行う必要があります。
第三は、スコープを限定したシステムアクセスを可能にすることです。先ほど説明したように、このケースではエージェントはCRMシステム、財務システム、そしてドキュメント要約ツールとも通信します。これらのツールはそれぞれ、独自のトークンを発行するサイロ化された認可サーバーを持っています。このケースでは、エージェントは正確な読み取りアクセスまたは書き込みアクセスを持つ必要があり、想定されている以上のアクションを取らないようにしなければなりません。なぜなら、それを超えたアクションを取ってしまうと問題になる可能性があるからです。エージェントに付与したくない機密システムへの書き込みアクセスを持ってしまう可能性があるためです。ですから、スコープを厳密に限定したシステムアクセスを解決できることが重要なのです。これにより、エージェントはユーザーに代わってアクションを実行するために必要十分なアクセス権のみを持つことができます。
そして最後になりますが、これらすべてをつなぎ合わせるためのカスタムコードを作成するという課題があります。エージェントビルダーや開発者は、アイデンティティプロバイダーの統合について考える必要があることが多いです。認証情報の処理、API呼び出し、認証情報の交換、承認、そしてこれらすべてにおけるエラー処理について考える必要があります。これは簡単な作業ではありません。これを実現するために、エージェントビルダーや開発者がつなぎ合わせなければならない大量のカスタムグルーコードなのです。ですから、シンプルで軽量なagenticユースケースでさえ、複数のアイデンティティオーケストレーション関連の課題に広がっていくことがお分かりいただけると思います。
では、この例を取り上げて、より広く一般化すると、私たちは何を観察しているのでしょうか?お客様とお話しする中で、これらすべての問題を3つのカテゴリーに集約することができました。1つ目は、エージェントに対して安全かつセキュアに権限を委譲することです。
エージェントは複数のシステム、つまりファイルシステム、API、そしてMCPサーバーを呼び出せる必要があります。ここでの問題は、既存のアイデンティティおよびアクセス管理ソリューションが、複数の動的な委譲フローで動作するように設計されていなかったということです。この結果、エージェント構築者は、エージェントに過剰な権限を与えてしまったり、脆弱な回避策を構築したりすることが多くなり、これは大きな問題となっています。
2つ目の課題は、ユーザー同意疲労への対処です。ご想像いただけると思いますが、先ほどの例では、営業担当役員が1つの顧客ミーティングの準備をしていました。re:Inventでは、皆さんも複数の顧客との会話、数十回、あるいは50回もの会話をされたことがあると思います。それら3つのシステムそれぞれに対して50回同意を与えることを想像してみてください。つまり、ユーザーに対して150回も同意を求めるプロンプトが表示されることになります。これはノイズです。エンドユーザーエクスペリエンスの観点から良くありません。今日のアイデンティティおよびアクセス管理システムには、これらのエージェントに対する永続的な同意やタスク固有の同意を保存するメカニズムがありません。
そして3つ目の課題は、カスタム統合とグルーコードです。構築者は、アイデンティティの配管をつなぎ合わせるために多くのカスタムロジックを書かなければなりません。初期のアイデンティティプロバイダーとの認証管理、同意の取得、認証情報の処理、エラー処理、そして認証情報の交換などです。つまり、このカスタム統合コードをつなぎ合わせるために多くの作業が必要になります。これらの課題は理論的なものではありません。これらは、実施する必要があるほぼすべてのエージェント展開に存在し、これらの課題がエージェントの本番化を遅らせることがよくあります。これは、お客様から一貫してお聞きしていることです。
では、今お話しした課題がなぜ重要なのでしょうか?何よりもまず、Benが先ほどのプレゼンテーションでお話ししたように、エージェントは生産性の向上と市場投入までの時間短縮を実現する鍵となります。エージェントに信頼が組み込まれていなければ、エージェントに安全に権限を委譲するメカニズムがなければ、組織はエージェントを採用したり、エージェントを受け入れたりすることに自信が持てず、したがってそのメリットを引き出すことができません。ですから、エージェントへの信頼は、より広範な採用にとって不可欠なのです。
第二に、組織は開発者にさらなる負担を課せる状況にはありません。エージェントアクセスを保護するために必要な認証の配管作業を容易にし、解決するための追加の開発者負担は望んでいません。それがない場合、開発者はより多くの時間と労力を費やさなければならず、実験サイクルやリリースサイクルが遅くなり、その結果、本番環境でエージェントを展開する速度が低下してしまいます。
そして最後に、エンドユーザーエクスペリエンスはシームレスでなければなりません。エージェントを呼び出すユーザーが、繰り返される同意プロンプトに常にさらされ、体験が著しく低下するような状況は望ましくありません。エンドユーザーにとってノイズの多い体験は望ましくありません。シームレスでありながら安全な体験が必要です。これらの問題は、エージェントシステムをどのように構築し、本番化できるかに直接影響を与えます。そして私たちは、皆さんが本番環境でエージェントを構築する際、または本番環境でエージェントを構築することを検討し始める際に、皆さんを支援したいと考えています。どうすればより早く市場に投入できるのか？どうすればより早くエンドユーザーに届けられるのか？
Amazon Bedrock AgentCore Identityの誕生：安全な委任アクセスと差別化につながらない重労働の排除
では、今後の機会は何だったのでしょうか？私たちが課題として話したすべてのことが、AWSにとって、この基盤となるIAM、つまりアイデンティティとアクセス管理の課題を解決する機会を生み出しました。私たちは、アイデンティティがエージェントを迅速に本番化できるようにする重要な接着剤であることに気づきました。それが、私たちがこの問題を大規模に解決することにつながりました。私たちは、エージェントへの安全な委任を可能にし、組織内または外部でのより広範なエージェント採用を解放するソリューションを求めていました。そして、それによってエージェントをより早く市場に投入できるようにしたいと考えました。これがAmazon Bedrock AgentCore Identityの誕生につながったのです。それでは、Bedrock AgentCore Identityが、私たちが今話した課題のいくつかをどのように解決するかについて、Benに詳しく話してもらいます。Benお願いします。
ありがとうございます。さて、もう一度手を挙げていただきましょう。AgentCore Identityについて聞いたことがある方はどのくらいいらっしゃいますか？わかりました。AgentCore Identityを使って何らかのプロトタイプを構築している方は、手を挙げたままにしてください。それほど多くはないですね。AgentCore IdentityやAgentCore全般を使って本番エージェントを構築している方はそれほど多くないと思います。どなたかいらっしゃいますか？わかりました、私たちにはやるべきことがありますね。これは良いことです。
さて、Rahulが述べたように、私たちは顧客から聞いた課題を理解しています。
明らかに、私たちはこれらの課題を直接解決するためにAmazon Bedrock AgentCore Identityを構築しました。まず第一に、AIエージェントのための安全な委任アクセスの課題を解決します。これは、AgentCore上のすべてのデプロイメントに対して、ユニークで安定したワークロードIDを作成することで実現しています。つまり、エージェントをデプロイしたり、ゲートウェイをデプロイしたりすると、それに対してユニークな識別子を作成するわけです。
第二に、合理化されたAIエクスペリエンスの実現を支援します。Raulが言及したように、同意疲れは現実に存在するものです。せっかくこれらのものを構築しても、ユーザーが疲れてしまって使いたくなくなるような事態は避けたいですよね。生産性向上のために使ってもらいたいわけです。ですから、AgentCore Identityは、Raulが言及したように、これらのトークンを安全かつセキュアな方法で永続化することで、同意疲れのすべてを解決する手助けをします。
最後に、私たちは皆さんがより速くエージェントを構築できるよう支援するためにAgentCore Identityを構築したいと考えました。AWSでは、おそらく「差別化につながらない重労働」という言葉をよく耳にすると思います。開発者が何度も繰り返し同じことをしなければならない状況を目にした場合、それは皆さんにとってビジネス価値を付加するものではないので、私たちはそれを取り除きたいのです。ですから、私たちはOAuthフローのオーケストレーションに関するマネージドサービスを提供するといったことを行うように、これを構築しました。皆さんの中で、エージェントを構築する際に、認可コードを取得してアクセストークンと交換し、そしてアクセストークンが期限切れになったらリフレッシュトークンを取得して新しいものを取得する、といった処理を扱いたい人はどれくらいいますか？それは楽しいことではありません。エージェントを構築する際に皆さんが価値を付加することになるとは思えないものです。ですから、AgentCore Identityはその差別化につながらない重労働を皆さんから取り除くのです。
AgentCoreの中核を担うIdentity：インバウンド・アウトバウンド認証とIDP非依存の柔軟性
では、AgentCore全体の中でどこに位置するかを考えてみましょう。AgentCoreに馴染みのない方のために説明すると、これは様々なプリミティブのセットで、それらがすべて一緒になって一つの大きなサービスのように機能します。AgentCore Runtimeがあります。これはエージェントをホストするためのコアランタイムです。AgentCore Gatewayがあります。これはMCPプロトコルベースで、外部ツールと通信できるようにします。AgentCore Memoryがあります、これはかなり自明ですね。AgentCore Observabilityがあり、これはエージェントが行っているすべてのことに対する可視性とトレーサビリティを提供します。いくつかの便利なツール、AgentCore BrowserとAgentCore Code Interpreterがあります。これらすべてを詳細に説明する時間はありませんが、ぜひ見ていただくことをお勧めします。そして、その中心にAgentCore Identityがあります。もちろん、偏った意見かもしれませんが、これがこれらすべてを結びつける接着剤のようなものだと私たちは考えています。これについては少し触れていきます。
エージェントを構築する際、本当に考えなければならない非常に基本的なことがいくつかあります。まず、ユーザーがエージェントにアクセスできる必要があります。AWSの世界では、一般的にこれはIAMを通じて行われますが、皆さん全員がアプリケーションでIAMを使用してユーザーにエージェントの呼び出しを許可したいわけではありません。では、ユーザーは実際にどのようにアプリケーションを通じてエージェントにアクセスするのでしょうか？そして、もう一方では、そのエージェントがタスクを実行したり、外部ツールを呼び出したりする必要があるので、それをどのように実現するかということです。
私たちの世界では、左側をインバウンド認証、右側をアウトバウンド認証と呼んでいます。そして、AgentCore Identityが答えを出す重要な質問は、まず、ユーザーは誰なのか、ということです。Raulが言及したように、ユーザーが誰かの代理として行動する場合、その「誰か」が誰なのか、そのユーザーが誰なのかを知る必要があります。このエージェントを呼び出しているユーザーが誰なのかを、どのように検証可能な形で判断するのか。そして、そのユーザーはそもそもエージェントへのアクセスを許可されているのか。例えば、HRエージェントはHR部門のみが呼び出せるようにしたい場合、その基本的な認証設定をどのように確保するのか。アウトバウンド側では、このエージェントが本当に本物なのかを知る必要があります。その特定のエージェントに対して検証可能な識別子を持っているのか。そして、そのエージェントは実際にそのユーザーの代理としてこれらのツールにアクセスできるのか。これらがインバウンドとアウトバウンド側の中核的な要件であり、Raulが言及したように、スケールに達すると実際にはそれほど簡単に解決できるものではありません。
では、AgentCoreの中核コンポーネントを少しお見せして、Raulがより深く掘り下げていく中で、それらがどう繋がっているかをご理解いただきたいと思います。先ほど申し上げたように、どんどん深く、深く、深く掘り下げていきます。これは300レベルのトークですので、徐々にそこに到達していきます。AgentCore Identity内には、いくつかの異なるコンポーネントがあります。まず第一に、アイデンティティディレクトリです。これは実際には、AgentCore Identityを使用したことがある方でも、あまり目に見えるものではありません。これが起こっていることすら知らないかもしれません。AgentCoreでランタイムをデプロイするたびに、そのアカウントにアイデンティティディレクトリを作成し、そのランタイムはワークロードID、つまりエージェント識別子に相当します。ゲートウェイも同様です。AgentCore Gatewayでゲートウェイをデプロイするたびに、その特定のゲートウェイに対してユニークなワークロードIDを作成します。つまり、Identity内にこのエージェントディレクトリがあるわけです。
次はオーソライザーです。私たちはあるアプローチを取りました。皆さんの多くが、非常に確立されたアイデンティティアクセス管理ソリューションをお持ちであることを理解しています。IDPをお持ちで、AgentCoreを使いたいなら、それを全部取り除いて、新しいIDPを導入するか、IAMだけを使ってください、と言っても、それは私たちにとってうまくいきませんでした。そこで、オーソライザーでIDP非依存のアプローチを取りました。これが意味するのは、Okta、Azure Entra ID、Pingなどを使用している場合、エージェントを呼び出すリクエストを私たちのオーソライザーに送信すると、私たちが皆さんのIDPと通信し、検証を行い、その呼び出しを許可するかしないかを判断するように設定できるということです。このオーソライザーが重要な要素なのです。
次に、リソースクレデンシャルプロバイダーという概念があります。これは基本的に、エージェントがツールにアクセスできる場合、 そのツールにアクセスするために使用する認証情報は何か、ということを示しています。基本的なAPIキーで保護されたAPIにアクセスしようとする場合は、APIキーと考えてください。そのエージェントが特定のOAuthで保護されたリソースにアクセスできる場合は、OAuthクレデンシャル、つまりクライアントID、クライアントシークレットのようなものと考えてください。この特定のエージェントがこれらのツールにアクセスするための認証情報を可能にする、セキュアなクレデンシャルプロバイダーがあります。
そして最後に、トークンボルトという概念があります。トークンボルトも、 おそらくかなり自明だと思います。その名の通り、トークンを保存しますが、それ以上のことをします。先ほど、差別化されていない重労働について言及しました。これが実際に提供するのは、管理されたOAuthグラントワークフローのセットです。つまり、トークンボルトに対して、Gmailにアクセスする必要があると言うと、自動的に確認して、アクセストークンが利用可能かどうかを見ます。ない場合は、ユーザー認証リクエストを起動し、アクセスコードまたはコードを取得し、それをトークンと交換する、といった具合です。つまり、これらの異なるOAuthグラントタイプのあらゆる重労働を管理してくれるのです。
それでは、これらがAgentCoreを構成する4つの主要コンポーネントです。繰り返しになりますが、プレゼンテーションを深く掘り下げていく中で、これらを参照していきます。では簡単に、これがどのように見えるかをお見せしたいと思います。インバウンドのユーザーがアプリケーションとやり取りし、エージェントが動作して検証を行い、アウトバウンドで外部ツールへの呼び出しを行います。ダブルクリックすると、ユーザーはアクセストークンを取得します。そのアプリケーションはAgentCoreに対して、ねえ、これが私のアクセストークンです、エージェントを呼び出したいです、と言いに行きます。
そして、私たちのオーソライザーが呼び出しを行い、キーを取得し、その特定のユーザーを認証・認可するための楽しい作業をすべて行います。しかし、AgentCoreで私たちが行っている独自のことの一つは、その特定のリクエストのサブジェクト、つまりユーザーが誰であるかを検証可能な形で識別すると、ワークロードアクセストークンと呼ばれるものを通じて、そのユーザーをエージェントにバインドするということです。これは、ねえ、私がエージェントを呼び出したら、今、私とそのエージェントがこの一つのキーを通じて結び付けられた、そしてそのキーが私の特定のセッションの認証情報を取得するためのロックを解除することを可能にするものだ、と考えてください。そして、そのキーだけが認証情報を取得することを可能にします。
これが、もしRaoulがエージェントを通じてGmailにアクセスしたい場合と、私がエージェントを通じてGmailにアクセスしたい場合に、そのエージェントが私の代理としてのみ動作する、またはRaoulの代理としてのみ動作することを保証する方法です。つまり、ユーザーがそのエージェントを呼び出すと、私たちはそのワークロードアクセストークンを開始し、それが2つのエンティティを一緒にバインドしているのです。そして、そのアクセストークンが実際にトークンボルトを呼び出すために使用され、トークンボルトは本質的にそれらの外部ツールへのリクエストを行うものです。
さて、私たちが強調しておきたいことが一つあります。これは同じスライドではありませんが、真ん中に小さな違いが一つあります。Bring your own agent runtimeと書かれています。つまり、Bedrock AgentCore内のプリミティブはスタンドアロンなのです。ですから、Bedrockランタイムやゲートウェイ内でエージェントコードを実行していなくても、AgentCore identityを使用することができます。これはスタンドアロンのプリミティブです。例えば、EKSや他のコンピュートでエージェントコードを実行することに決めたとしても、AgentCore identityを使用して、その一意のエージェントIDを作成し、クレデンシャルプロバイダーを作成したり、トークンボルトを使用したりすることができます。
ですので、このプレゼンテーションを進める中で、AgentCoreだけではないということを理解していただきたかったのです。もしあなたのビジネスが、ねえ、これを独自のEKS環境で実行することに決めた、となっても、問題ありません。AgentCore identityをスタンドアロンのプリミティブとして使用できます。これが非常に高いレベルでのAgentCoreです。さて、私たちが考えたのは、どのようにして、それがアンロックできる特定のアクセスパターンとは何か、そして実際の詳細にもっと深く入り込んでいくかをお見せするかということです。
それでは、一時的な中断について申し訳ございませんが、先ほど申し上げたように、これから多くのエキサイティングなことが控えています。Benには、Bedrock AgentCore identityと、それが私たちが言及した認証の課題をどのように解決するかについてお話しいただき、ありがとうございました。次のレベルの詳細に入る前に、非常に重要なことだと思いますので、このスライドにまだ留まっているのですが、Bedrock AgentCore identityを持つに至った背景にあるデザイン原則やテネット、さらにはBedrock AgentCore自体が非常に柔軟で、皆さんがいる場所、つまり私たちの顧客が実際にいる場所に本当に寄り添うものであることを強調することが非常に重要です。
Bedrock AgentCoreは、Benが指摘したように、フレームワークに依存しません。Bedrock AgentCore identityは、左側にご覧いただけるように、お好みのアイデンティティプロバイダーに依存せず、また、エージェントをホストする場所にも依存しません。これは私たちが持っている重要なデザインテネットであり原則だと思います。これを強調することも私たちにとって重要です。それでは、お話ししましょう。Bedrock AgentCore identityが今日サポートしているアクセスパターンとは何か、そして舞台裏でアイデンティティのオーケストレーションとオーケストレーションが実際にどのように行われているかを深く理解していきましょう。
3つのアクセスパターン：AWSリソース、Three-legged OAuth、Two-legged OAuthの仕組み
それでは、今日サポートしているアクセスパターンのいくつかを改めて強調しますと、AgentCore identityは、ユーザーがエージェントを呼び出してAWSリソースにアクセスできるようにします。
同時に、OAuthまたはAPIキーで保護されたAWS外部のリソースにアクセスすることもできます。先ほどのスライドの1つで述べたように、2つの主要なカテゴリーについてお話ししました。1つは、ユーザーの代わりに動作するエージェント、もう1つは、事前に承認されたユーザーの同意を使用して自身の代わりに動作するエージェントです。これらの両方のカテゴリーは、AWSリソースにアクセスする場合でも、AWS外部のリソースにアクセスする場合でも、両方のアクセスパターンで解決されます。
それでは、アクセスパターンをより深く見ていきましょう。まず、AWSリソースアクセスについてお話しします。ここでの典型的な例は、ユーザーがAIエージェントを呼び出し、そのエージェントがLambda関数を呼び出したり、S3バケットからファイルを読み取ったりする必要がある場合などです。AWS内では、エージェントがAWSリソースにアクセスする必要がある場合、舞台裏で行われることは、AWSがSignature Version 4、つまりSigV4を署名プロトコルとして使用し、APIリクエストを行う際に認証情報を追加します。つまり、舞台裏で実際に起こることは、エージェントのユースケースやシナリオに話を戻すと、エージェントがAWSリソースにアクセスしようとするとき、SigV4を使用してAPI呼び出しに署名します。その後、IAMロールを引き受け、AWSがこの署名されたリクエストを検証し、STSクレデンシャルを発行することで、そのエージェントがユーザーの代わりにリソースにアクセスできるようにします。これが簡単に言うと、AWSリソースアクセスがどのように機能するかです。
それでは、非AWSリソースへのアクセスについてお話しします。まず、three-leggedシナリオについてお話しします。なぜthree-leggedと呼ばれるのか疑問に思われるかもしれません。three-leggedと呼ばれるのは、3つの当事者が関与しているからです。ユーザー、エージェント、そしてリソースがあります。それはGmailかもしれませんし、GitHub、Slack、Salesforceなどかもしれません。これは、プレゼンテーションの前半で説明した例です。営業担当者がエージェントを呼び出してCRMシステム、財務ツール、さらにはドキュメント概要ジェネレーターにアクセスする例でした。これがthree-legged認証フローの例です。
実際に裏側で何が起こっているかというと、先ほどの例に戻りますが、営業担当者のSarahが、企業環境やコーポレート環境で自分のアプリケーションにログインします。組織が使用しているアイデンティティプロバイダー、それがMicrosoft Entra IDであれ、Oktaであれ、Amazon Cognitoであれ、その他であれ、着信した呼び出し元のSarahを検証し、認証コンテキストと実際にログインしたユーザーに関する情報を含むアクセストークンまたはJWTトークンを発行します。このトークンはその後、AgentCore Identityに渡されます。次のスライドでさらに詳しく説明します。しかし、Sarahが同意を与えると、エージェントは一意のトークンを取得し、それをSarahのアクセストークンと交換して、CRMノート、財務システムのレコードを取得し、ドキュメントを生成します。これが基本的にthree-legged OAuthの仕組みです。
そして最後のアクセスパターンは、two-legged OAuthです。Two-leggedというのは、2つの当事者が関与しているからです。エージェントと、アクセスしようとしているリソースがあります。ここでの例は、スケジュールされたジョブ、イベント駆動型の自動化などで、エージェントが事前に承認された同意やいくつかのイベントに基づいて、リソースにアクセスしたり、APIを呼び出したり、MCPサーバーを呼び出したりします。以前お話しした例では、重大度の高いチケットが入ってきた場合、アクセスログやアプリケーションログを調べて根本原因分析を行うようにプログラムされたエージェントがあったり、スケジュールされた分析ジョブを実行したりします。たとえば、毎週水曜日の午後8時にデータベースにクエリを実行して、組織の売上レポートを生成するエージェントがあります。これがtwo-legged OAuthの例です。
舞台裏の詳細フロー：ユーザー検証からクレデンシャル交換までの5ステップ
それではもう一段階深く掘り下げてみましょう。AgentCore Identityがどのように機能するかを理解しましょう。3つのフローの中で最も複雑な例を取り上げます。エージェントがAWS外部のリソースにアクセスするシナリオについてお話しします。営業担当者の例がありました。裏側で何が起こっているかを理解していただけるよう、その例を引き続き参照していきます。まず第一に、営業担当者のSarahがエージェントを呼び出す前に、彼女はアプリケーションにログインする必要があります。そのアプリケーションには特定のアイデンティティプロバイダーがあるかもしれません。先ほど述べたように、Bedrock AgentCore IdentityはIDPに依存しません。アプリケーションは、現在サポートしている任意のIDPを使用できます。それがユーザーのSarahに、彼女のユーザーコンテキストを含む一意のJWTトークンを発行します。そして、このJWTトークンがAgentCore Identityに渡されます。
Amazon Bedrock AgentCore Identityの一部として、呼び出し元が誰であるかを検証し、ユーザーのアクセストークンを確認します。発行元のIdentity Providerからのトークン署名を検証します。このトークンの発行者、オーディエンスが誰であるか、そしてエージェントビルダーが検証を希望するカスタムクレームを検証します。たとえば、Sarahが組織内の特定の部門や特定のグループに属しているかどうかなどです。このすべての豊富な認証コンテキストがこのJWTトークンに取り込まれており、AgentCore IdentityのAuthorizerコンポーネント、これはBenが先ほど言及していたものですが、これが検証します。この検証ステップの決定は、Sarahがこのエージェントを呼び出すことを許可されているかどうかです。シンプルなyes or noの決定です。
もし答えがイエスであれば、次のステップに進みます。それはユーザーの同意とスコープの適用です。エージェントがこのセールスエグゼクティブの代理として行動することが許可されたと判断したら、エージェントコード、つまりエージェントロジックが、どのツールを呼び出す必要があるのか、どのMCPサーバーを呼び出したりアクセスしたりする必要があるのかを判断します。この例では、CRMシステム、ファイナンスシステム、そしてドキュメントジェネレーターでした。そしてSarahに対してプロンプトを返して、彼女の同意を取得します。Sarahは、このエージェントが必要なレコードを取得したりフェッチしたりすることに対して明示的に同意する必要があります。これは本来であれば彼女自身が権限を持っていたものです。このエージェントも適切なスコープを持つ必要があります。先ほど述べたように、私たちにとっての重要な原則は、デフォルトでセキュア、必要最小限のアクセスです。もしSarahがこれらのシステムに対して読み取りアクセス権限のみを持ち、ドキュメントジェネレーターに対して書き込み権限を持っている場合、エージェントもSarahが同意を与える際に彼女から付与されたのと同じアクセスレベルを持つべきです。これがステップ2です。その同意を取得し、タスクを実行するために必要なスコープを取得します。
このステップが完了すると、AgentCore Identityはエージェントに対してタスクを実行することを承認します。ここで私たちが行うのは、Sarahのユーザーアイデンティティコンテキストとユーザーアイデンティティを取得することです。ユーザートークンがあり、エージェントの一意のアイデンティティがあり、それらを使って不透明なワークロードアクセストークンを発行します。私たちはこれをワークロードアクセストークンと呼んでいますが、このトークの目的のために、これをエージェントトークンと呼びましょう。これは基本的に、呼び出し元プリンシパルの代理としてタスクを実行するためにエージェントに付与する権限です。これはここで注目すべき重要な概念です。私たちは、エンドユーザーまたは呼び出し元が誰であるかとエージェントアイデンティティの一意の組み合わせによって、このエージェント固有のトークンを発行しています。これは2つのことを保証します。なりすましが発生しないこと。ユーザーの代理として行動することが許可された正しいエージェントであること。そして2つ目は、Sarahがエージェントを呼び出したときに彼女が持っているコンテキスト、つまりユーザーコンテキストに特定して紐付けられた状態でのみ動作することです。
次のステップは、クレデンシャル交換の促進です。ご存知のように、このエージェントトークンだけでは十分ではありません。このエージェントは、私たちが話しているこれら3つのシステムすべてとやり取りする必要があります。これら3つのシステムには、それぞれ独自のトークンエンドポイントがあります。独自の認可サーバーがあります。これらのエージェントトークンを受け付けないので、エージェントがアクションを実行するために、ユーザーSarahが持っている適切な、必要最小限にスコープされたアクセストークンを取得できることが重要です。では実際に何が起こるのでしょうか?前のステップで発行したエージェントトークンが、トークンボルトのロックを解除するための鍵として機能します。トークンボルトには、右側と下部に見えるすべての認可サーバーによって発行された、ユーザーSarahのアクセストークンが保存されています。トークンボルトは、Benが話していたように、AgentCore Identityの重要なコンポーネントです。
発行したエージェントトークンによってこのトークンボルトのロックが解除されると、エージェントはSarahのアクセストークンのベアラーとして機能し、これら3つのツールすべてへのアクセスのロックを解除します。Sarahの読み取りアクセス権限とアクセストークンを持つCRMシステムからフェッチします。ファイナンスについても同様です。そしてブリーフを生成するための書き込みアクセスです。最後になりますが、それが完了すると、基本的にリソースへのアクセスをブローカーします。これがこの例全体においてAgentCore Identityが行う最後の締めくくりのステップです。エージェント自体が、セールスエグゼクティブがクライアントミーティングの準備をするためのドキュメントブリーフを作成します。
AgentCore Identityは、舞台裏ですべての差別化されない重労働を処理します。BenがAWSでは差別化されない重労働という言葉を使うのが大好きだという話をしていたのを覚えていますが、考えてみてください。最初のユーザーの認証全体、同意の取得、このユーザーの代理として行動するためのエージェントの承認、このクレデンシャル交換の促進。
これらすべては、AgentCore Identityによってバックグラウンドで行われます。つまり、皆さんや組織内の開発者が、これを実現するためにカスタムの接続コードを組み合わせる必要はありません。これがAgentCore Identityがバックグラウンドで行っていることです。
Resource Credential Providerの活用：Google Driveアクセスの実装とCloudTrail統合
次に、別のシナリオについてお話しします。Benが、AgentCore IdentityがエージェントをホストするAgentCore Runtimeと緊密に統合されている点についてお話ししました。これから、AgentCore RuntimeとAgentCore Identityを使用して、エージェントがAWS外部のリソース、例えばGoogle Drive、Slack、GitHubなどにアクセスできるようにするシナリオについてお話しします。ご存知のように、これらのツールの多くは、クライアントIDやクライアントシークレットのようなOAuthクライアント認証情報、またはAPIキーを、システムへのアクセス方法として受け入れています。これを実現するために、ここで理解していただく必要がある重要な部分は、AgentCore IdentityにはResource Credential Providerと呼ばれるコンポーネントがあるということです。このメリットについてはすぐにお話しします。しかし、開発者として、エージェントがこれらのサードパーティツールにアクセスできるようにアクセスを仲介し促進するために、最初に行う必要があるのは、クライアント認証情報を設定することです。この具体的な例についてお話しします。この場合、Google Driveにアクセスしようとしているとしましょう。開発者はGoogle Consoleに行き、アプリケーションがこれらのツールにアクセスできるようにするために必要な関連するクライアントIDとクライアントシークレットを取得する必要があります。
これはエージェントアプリケーションなので、次に行うことは、Bedrock AgentCore Identityの主要コンポーネントの1つであるcredential providerを設定することです。取得したばかりのこれらのクライアントIDとクライアントシークレットを使用して、エージェントを登録できます。この登録は、管理コンソールで行うことも、CLIを通じて行うことも、さらにはSDKを通じて行うこともできます。ここでAgentCore Identityのメリットとして強調したい重要な違いは、これらのシークレット、クライアントIDとクライアント認証情報、またはAPIキーを、エージェントコードの一部として埋め込む必要がないということです。CI/CDパイプラインやリポジトリに埋め込む必要もありません。AgentCore Identity独自のシークレット管理コンポーネントを使用して、安全に保存できます。このようにして、関連するエージェントのみが、エージェントの代わりに保存した適切な認証情報を取得することで、このGoogle Driveツールを呼び出すことができるようにします。
3番目のステップはアノテーションの追加です。ここでコードスニペットを共有しましたが、これは基本的に、エージェントがユーザーの代わりにGoogle DriveにアクセスするためのOAuthアクセストークンを取得できるようにするものです。ご覧いただいているこのコードアノテーションは、ユーザーの代わりにこのアクセストークンを取得しようとするときに、どのスコープをリクエストしているかを指定します。Google Driveの場合、実際にアクセストークンを取得しようとしている対象のプロバイダー名を指定します。そして、ここでの次のステップは、実際にエージェントにコードを追加して、このOAuthアクセストークンを使用し、ユーザーの代わりにこのリソースにアクセスできるようにすることです。この具体的な例では、画面を少し拡大すると、この特定の例では読み取りスコープをリクエストしています。これにより、ユーザーがGoogle Driveでアクセスできる最初の10個のファイルのすべてのIDをリストできるようになります。つまり、これが本質的にAgentCore Identityでバックグラウンドで起こっていることです。
これらの認証情報を保存し、AgentCore Identityにエージェントを登録したら、アクセストークンを取得するようにコードにアノテーションを指定し、このコードが実際にエージェントコード内でどのように使用されるかを指定します。最終的には、ユーザーがエージェントを使用して、この場合はGoogle Driveという特定のツールにアクセスできるようになります。コントロールプレーンの設定、エージェントの登録について多くお話ししましたし、このリソースへのアクセスがどのように仲介されるかというデータプレーンフローについてもお話ししました。しかし、ここで重要なコンポーネントは、これがエージェントライフサイクル全体の終わりではないということです。ガバナンスと可観測性の観点から、エージェントがユーザーの代わりに、または事前に承認されたユーザーの同意を得て自身の代わりに、どのようなアクションを実行しているかを理解するための可視性を顧客が持つことも重要です。
これを可能にするために、AgentCore IdentityはAWS CloudTrailとネイティブに統合されています。
Bedrock AgentCore IdentityへのすべてのAPIコールは、CloudTrailに不変のログとして保存されます。また、エージェントがAWSリソースにアクセスするたびに、誰がアクセスしたのか、誰がこの特定のAPIをAWSサービスリソースに対して呼び出したのか、そのエージェントのアイデンティティは何だったのかを追跡することができます。実際に、CloudTrailを通じてこれらすべてのトレースをご自身で行うことができます。2つ目の項目は、AgentCore observabilityとの事前構築された統合です。これにより、エージェントへのインバウンドおよびアウトバウンドの認証リクエスト、成功率、トークンとAPIキーの取得回数などをトレースおよび監視できるようになります。CloudTrailとAgentCore observability統合の両方により、エージェントがどのようなアクションを取っているかを理解するために必要な適切なレベルの監査可能性と可視性が提供されます。また、必要に応じて問題を診断およびトラブルシューティングするためのツールも提供され、特にAWSリソースにアクセスしている場合に、そのエージェントが何をしてきたかのトレースを確認したいときに、組織内のコンプライアンス要件を満たすことができます。
今週の新機能リリースと今後のロードマップ：カスタムクレーム、AgentCore Policy、そして始め方
それでは、Benに引き継いで、Bedrock AgentCore Identityに追加された新しいアップデートについてお話しいただきたいと思います。それではBen、お願いします。ありがとうございます。さて、皆さんはAgentCore Identityが何であるかについて、非常に良い理解を得られたことと思います。AgentCore Identityについて何か学んでいただけたでしょう。願わくば、何か持ち帰っていただいて、実装できるかどうか試していただければと思います。先ほど申し上げたように、今週は私たちにとって忙しい週でした。ここで非常に多くのお客様とお話しするだけでなく、火曜日には多数のローンチがあり、もちろんこのセッションの準備もしなければなりませんでした。
それでは、今週に特化したローンチについてお話ししたいと思います。私たちは数ヶ月前にAgentCoreをプレビューでローンチし、ほんの数ヶ月前にGAになりました。そしてそれ以来、多くの追加改善に取り組んできました。さて、ここでお見せしているのは、アイデンティティアクセス管理認証に関連するものだけです。AgentCore Identityは今週、さらに多くのローンチがありました。評価に関する全く新しいプリミティブや、メモリに関する多くの機能強化などをローンチしましたが、今週のアイデンティティに関する特定のローンチについて詳しく見ていきたいと思います。
まず、AgentCore Identity内で、カスタムクレームとスコープのサポートをローンチしました。これが意味するのは、そのインバウンドオーソライザーにおいて、以前はオーディエンスやクライアントIDの検証などができましたが、今ではオーソライザー内に任意のカスタムクレームを追加できるようになったということです。例えば、この人がエージェントを呼び出せるのは、そのグループがHRに等しい場合のみ、または他のクレームの場合のみ、といったことが言えるようになります。これにより、そのインバウンド認証において、粗粒度のアクセス制御を提供することが容易になります。細粒度のアクセス制御とは呼んでいませんが、粗粒度のアクセス制御です。
次に私たちが行ったのは、three-legged OAuthサポートの立ち上げです。これは本当はGatewayのユーザー同意と呼ぶべきものですね。繰り返しになりますが、GatewayはMCPベースのコンポーネントで、外部ツールにアクセスできるようにするものです。私たちは常にRuntime自体から直接three-legged OAuthをサポートしてきました。Runtimeは単なるコードです。認証URLなどすべてを自分のコード内で処理できます。MCPについて話すとき、それは少し難しくなりました。つまり、認証をリクエストする必要があるときに、このURLを返送するわけですが、それを処理する簡単な方法がなかったんです。ありがたいことに、MCPとコラボレーションがURL elicitationを立ち上げました。そして今やMCPはプロトコルとして、そのURLをアプリケーションに返す標準化された方法を提供しています。そこで私たちはGateway内でそれを活用し、プロトコルが提供するものに追いつくようにしました。そして今、私たちもthree-leggedサポートを提供しています。つまり、これはGatewayを使ってユーザー同意ベースの認証を使用できるようになったということです。
さて、Gatewayはいくつかの本当にエキサイティングなものも立ち上げました。実際、カスタムLambdaインターセプターは先週後半に立ち上げられました。これは皆さんが期待する通りのものです。Gatewayでツールを呼び出したいとき、それに対してカスタムLambda認証を実行する機能が使えるようになりました。つまり、この特定のターゲットを呼び出すと言って、そのリクエストをLambda関数に送信します。Lambda関数はそれを使って好きなことを何でもできます。パスまたはフェイルを返送すると、ツールが呼び出されます。これは究極の柔軟性ですね。
もう一つ私たちが立ち上げたのは、AgentCoreのPolicyです。これは超エキサイティングです。これは、お客様から最も多く聞いた要望の一つだと思います。エージェントを本番環境に導入する必要があるが、これを安全にするための認可レベルが必要だと言われていました。そしてAgentCoreのPolicyはGatewayに対して機能します。Cedarを活用しています。もしご存じなければ、Cedarはオープンソースのポリシーランゲージです。Gateway内のさまざまな呼び出しに対して、きめ細かいアクセス制御を記述できます。Gatewayの呼び出しに対しては粗粒度、実際に呼び出そうとしているツールに対しては細粒度です。ユースケースを考えてみましょう。金額が100ドル未満の場合にのみ、このエージェントがこれを実行できるように認可すべきだとします。このポリシーこそが、その本当にきめ細かいアクセス制御を可能にするものです。これについては超エキサイティングです。今週これまでのところ、お客様から素晴らしいフィードバックをいただいています。
今後を見据えて、私たちは開発者エクスペリエンスの改善を続けていきます。SDKについてお話ししました。
まだ始める際のエクスペリエンスに少し摩擦があると考えています。そのため、SDK周りのエクスペリエンスを進化させ続ける必要があり、オートメーション周りのことも進化させ続ける必要があり、より良いサンプルを提供し続ける必要があります。これは、エンドユーザーエクスペリエンスではなく、エージェントを構築しAgentCoreを使用する開発者としての皆さんのエクスペリエンスを改善することに対する、私たちの大きな焦点です。
2つ目の領域は、新しく登場するアクセスパターンやプロトコルに対応し続けなければならないということです。皆さんもご想像の通り、これは非常に動きの速い分野です。1年前にはMCPなんて存在していませんでしたが、今では実際に存在し、進化し続けています。私たちはそれに対応し続けなければなりません。先ほど触れたように、URL elicitationがちょうどリリースされたばかりで、私たちはそれを活用してGatewayに追加していく予定です。さまざまなタイプのプロトコルがあります。現在、私たちはOAuth、APIキー、IAMをサポートしていますが、世の中には本当にたくさんのプロトコルがあり、私たちはそれらを継続的に強化し、進化させていきます。
最後に、私たちにとって大きな焦点となっているのは、このOn-Behalf-Of機能をどのように進化させていくかということです。今日、現在のOn-Behalf-Ofのサポート方法について詳しく説明しましたが、結局のところ、保護されたリソースが見ているのは依然としてユーザーのアクセストークンであり、私たちにはもっとできることがあります。そこで、OAuth token exchange RFC 8693を検討しており、実際にエージェントがアクターとしてそのクレームに追加されるようにしたいと考えています。複数のエージェントチェーンやその他のシナリオを通じて、それを進化させていきます。もう1つの大きな焦点は、Human in the Loopです。これは常に耳にすることです。エージェントができることを制限するポリシーがあるのは素晴らしいことですが、時には人間がこれを確認できるようにする必要があるのです。これらは私たちが継続的に改善していく領域です。
素晴らしい。では、AgentCore Identityを始めるにあたって。私たちはたくさんのリソースを用意しています。製品詳細ページと開発者ガイドがあります。ぜひGitHubのサンプルを見ていただきたいと思います。私たちは本当にたくさんの例を提供するよう努めてきました。これらは私が言及したすべての異なるアクセスパターンの例です。ランタイムでこの3-Legged OAuthを試してみたい、そういったサンプルがあります。IDPを使って認証したい、そういった例もあります。ですから、GitHubのサンプルをぜひご覧ください。AgentCore全体だけでなく、特にIdentityについても始めるのに最適な場所です。10分程度で始められるタイプのガイドもあります。
それでは、本当にありがとうございました。皆さんにとって長い、長い1週間だったことは承知しています。ランチタイムにここに来ていただき、感謝しています。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion