イラストで理解するAmazon Bedrock AgentCore
はじめに
こんにちは、大阪オフィスのよなみねです。
みなさんはAWSでAI Agentを作りたいと言われると、どのサービスが思い浮かびますか？私は最初にAmazon Bedrock AgentCoreが思い浮かびます。
AgentCore、みなさんは触ったことありますか？
興味あるけど、まだ触れてないという方も多いんじゃないでしょうか？
その理由の1つとして、AgentCoreが具体的にどんなサービスなのか、何ができるのか、その実態がよく分からない。という方も多いんじゃないでしょうか。
かくいう私もAgentCoreを触り始めた当初、AgentCore = AWSのAI Agentサービスくらいのイメージで、具体的に何ができるのかが全く分かっていなかったので、この記事では私が何が分からなかったのか、そして何を理解することで使えるようになったのかをイラストを交えながら紹介できればと思います。
前提としてEC2やLambdaの基礎的な知識があるとより理解しやすいと思います。
それではいってみましょう！
私は何が分かっていなかったのか？
私は最初AgentCoreというのはAI Agentで、Claude CodeやOpenAI CodexといったAI Agentのようなチャットができるアプリケーション的なものを簡単に作れる「何か」だと思っていました。
しかし、AgentCoreのコンソール画面を開いてもそんなチャット欄はどこにもありません。なぜでしょう、困りました。(今はAgentCore Harnessというコンソール上でチャットができる機能がありますが、ここでは触れません)
ちゃんと調べてみると、AgentCoreはチャットアプリではなく、AI Agentな動きをするアプリを動かすためのインフラ基盤だったのです。
今考えると、アプリとインフラを混同していたのがAgentCoreが理解できない原因の1つだったと思います。
今の時点で、「え？AI Agentのインフラ基盤の仕組み？どういうこと？」と、なっているかもしれませんが、大丈夫です。ここから一緒に理解していきましょう。
AI Agentとは？
まずAgentCoreに入る前に、AI Agentをふわっと理解しましょう。
AI Agentって何でしょうか？
私の思うAI Agentは、自分で計画して、判断して、行動できるプログラムのことです。
そんなこと知ってるわ！という声が聞こえてきそうですが、AgentCoreを理解する上ではこれが重要です。
自分で判断して行動するというのは具体的にどういうことでしょうか？
例えばあなたが家電量販店の販売員だったとしましょう（頑張って自分に販売員を憑依させてください）
お客様から「そろそろ夏なので、私の部屋に合う省エネなエアコンを教えてほしい」と相談されたらどうしますか？
まずはお客様の部屋の広さや予算などの要件を確認して
店頭に並んでいるメーカーごとの商品を比較して
性能や価格を比較して
在庫を確認して
おすすめできそうな商品を選んで
みたいな流れでお客様に案内しますよね？
これは販売員(私)が計画を立てて、判断して、お客様に商品を買ってもらうというゴールに向かって行動していますね。
これを私の代わりにAIが自分で判断して計画して行動してくれるのがAI Agentです。
AI Agentと聞くと、一般的なAIチャットと何が違うの？と気になる方もいるかもしれません。
AIチャットに「おすすめのエアコンを教えて」と聞けば、条件に合いそうな商品や選び方は教えてくれるかもしれません。
でも、販売員のように「部屋の広さを確認する」「候補を比較する」「在庫を確認する」「結果を踏まえておすすめを出す」といった一連の作業を、目的に向かって進めていくには普通のAIチャットだけでは難しいですね。
このように、ユーザーの依頼を達成するために、必要な手順を考え、自分が使えるツールを使いながら行動していくプログラムがAI Agentです。
AI Agentをもう少し詳しく
ふわっとAI Agentがイメージできたと思うので、先ほどの店員の例をAI Agentに置き換えながら、もう少しAI Agentの動きを深掘りしてみましょう。
お客様(ユーザー)は、販売員である私に
「6畳の部屋に合う省エネなエアコンを教えてほしい」と相談してきました。
このとき、私はいきなり商品を1つ選ぶわけではありません。
まず頭の中で、
「6畳の部屋なら対応畳数はこのくらいでよさそう」
「省エネ重視なら年間の電気代や性能を見た方がよさそう」
「でも、予算や設置条件も確認しないと決められない」
などと考えます。
つまり、お客様の依頼を理解した上で、
必要な条件を整理し、次に何を確認すべきかを考えています。
ある程度方針が決まったら、次は実際に商品を探します。
店頭の商品を見るだけでなく、カタログで性能を確認したり、在庫システムで在庫を調べます。
候補を見つけても、すぐに決まりとは限りません。
性能は良いけど予算を超えている、価格はちょうどいいけど在庫がない、商品はあるけど工事日が合わない、ということもあります。
その場合は、別の商品を探したり、条件を少し変えたりしながら、お客様に合う商品を探していきます。
最後におすすめ商品をいくつかお客様に提案します。
お客様は提案されたものを吟味して、私の提案理由を聞きながら、比較して、最終的に商品を決めます。
AI Agentでも同じです。
ユーザーの依頼を受け取ったら、まず目的を解釈し、
目的を達成するために必要な情報や手順を考えます。
このように、
「何を確認すればよいか」
「どの情報を使えばよいか」
「どの順番で進めればよいか」
を考えることが、AI Agentにおける計画です。
使えるツールの中から、目的を達成するために使えそうなツールを選んで、実行し、その結果を見て、次の行動を決めます。
必要であれば、条件を変えてもう一度実行したり、別のツールを使ったりしながら、目的達成に近づいていきます。
ポイントは、ツールを一度使って終わりではなく、実行結果から次の行動を決める点です。
AI Agentも人間と同じように調べた結果を自分で確認しながら、最終的にユーザーが必要としているであろう結果を考えます。
このようにAI Agentは、人間が仕事を進めるときと同じように、考えて、実行して、結果を確認して、最終的な答えを出します。
AI Agentは誰が実装するのか
さて、ここまでの説明でAI Agentがどういう動きをするのか？については理解できたかと思います。
ここまでAI Agentの話をしましたが、これはあくまでもAI Agentの動きの話です。
以前の私はAgentCoreを使えば、こうしたAI Agentな動きが魔法のように勝手に実装されるものだと思っていました。
これは大きな間違いで、AgentCoreが勝手にAI Agentな動きを実装してくれるわけではありません。
少し考えれば分かることですが、どのようなツールを使えるのか？どのモデルを使えるのか？何回考え直すのか？どのくらい深く考えるのか？などAI Agentの動きを制御する必要があります。
では、誰がこのAI Agentな動きを実装するのでしょうか？それは開発者です。
開発者がプログラムを書いて、AI Agentの動きを実装します。
開発者はAIに使って欲しいツールや、再思考の処理など、AIに「こう動いてほしい」という処理をプログラムで実装します。
これはインフラではなく、アプリケーションによる実装です。
これはあくまでも私のイメージの話ですが、開発者が書いたコードが体（制御ロジック）に道具（ツール）と脳（LLM）を持たせることでAI Agentとして動くようになります。
上の図はそれぞれこんなイメージです。
制御ロジック → LLMとツールを接続し、Agent全体の実行を管理するプログラム
ツール → 商品の在庫一覧を検索するツール（MCPや自分で定義した在庫照会プログラムなど）
LLM → モデル（有名なところだとClaudeやGPTなど）
余談ですが、世の中にはAI Agentの制御ロジックの部分をなるべく簡単に実装できる便利なフレームワークもあったりします。
例えば、Strands Agents、LangGraph、CrewAI、LlamaIndexなどのフレームワークがあります。
ここまで来て、あれ？じゃあAgentCoreってなんだ？となりますよね。
さっきからアプリケーションの話ばかりしています。
AgentCore
かなり前置きが長かったですが、ここからがAgentCoreの話です。
AgentCoreは、ここまでに見たAI Agentな動きをするアプリケーションに必要なインフラを用意します。
今までAI Agentの話をしてきましたが、そのAI Agent(アプリケーション)はどこで動くのでしょうか？
一般的なアプリケーションと同じようにサーバー上で動かす必要があります。
パッとイメージしやすいのは、オンプレミスのサーバーだったり、クラウド上の仮想サーバーなどが思いつくでしょう。
AgentCoreは、そのサーバー側の話です。
じゃあ、どうやってAgentCore上でアプリケーション（AI Agent）を動かすの？と思いますが、AgentCoreの主要なリソースとしてAgentCore Runtimeがあります。
このAgentCore Runtimeがまさにアプリケーションが動くインフラ部分になります。
Runtimeを作成する際に、自分が作成したソースコードを選択する箇所があります。
ここで、自分のソースコード（を置いた場所）を選択すると、あとはそのコードが動くインフラ部分はRuntimeが勝手に用意してくれます。
このインフラ部分はmicroVMがセッションごとに起動する仕組みになっています。
ユーザーがチャットを開く(セッションを開始する)とRuntimeとしてmicroVMが立ち上がるイメージです。
AWSを触っている人ならLambdaをイメージしてもらうと分かりやすいですね。
必要な時だけ、コードを動かすインフラだけが起動するイメージです。
そのため、開発者はあまりインフラを意識しなくてもすみます。
AI Agentにあると嬉しいインフラってなんだろう？
では、AI Agentな動きをするアプリケーションに必要なインフラ、AI Agentを動かす際にあると嬉しいインフラとは何かを考えるとAgentCoreのありがたみがわかってきます。
ここからはAgentCoreの代表的な機能をいくつか紹介します。
まず、前提として、AgentCoreは単体のサービスというより、「AgentCore ほにゃらら」という名前のサービス群の総称です。
まずはAgentCoreのメイン機能となるAgentCore Runtimeの特徴をいくつか紹介します。
AgentCore Runtime
スケーリング
例えばどこかの家電量販店のAI Agent チャットアプリがあったとしましょう。
イメージとして、EC2などの仮想サーバー上でチャットアプリが動いていることをイメージしてみてください。
チャットアプリが出始めた序盤は利用者も少なく問題なく動くでしょう。
しかし、家電量販店が有名になって、チャットアプリの利用者も増えてきました。
どうなるでしょうか。
大量のリクエストに耐えられず処理が止まってしまうことが考えられます。
例えばEC2 Auto Scalingを使えば、ある程度は対応できるかもしれませんが、スパイク的なリクエスト増への対応は難しいでしょう。
また、サーバーが増えるとセッション管理や会話履歴管理も工夫が必要になります。
AgentCoreはこういったスケーリングを気にする必要はありません。
AgentCore RuntimeがセッションごとにmicroVMを起動するため、開発者はインフラを気にする必要がありません。
もちろん増えた分お金はかかるので、その点は気にしましょう。
環境分離
仮に1つのサーバー上でチャットアプリを運用する場合、複数ユーザーのリクエストを1つのサーバーで処理する形になります。
この場合、会話履歴や一時ファイル、リソース使用量をユーザー単位で分離する仕組みを、アプリケーションやファイルシステム、DBなどで管理する必要があります。
万が一にも実装ミスにより別ユーザーの情報が混ざると大問題です。
先ほども出てきましたが、AgentCore RuntimeはセッションごとにmicroVMが起動します。
このmicroVMはCPU、メモリ、ファイルシステムが完全に分離された専用の仮想環境です。
そのため、開発者が境界面を分離する負担が少なくなります。
起動時間
AI Agentは自分で考えて動くという話を前半でしました。
これはAI Agentのメリットではありますが、違う角度から見ると処理がいつ終わるか分からないという見方もできます。
つまり、一時的にサーバーが起動するような仕組みがあっても、AI Agentの処理時間がいつまで続くか分からないので、ある程度余裕を持った起動時間が必要です。
この問題は通常のサーバーでは常時起動しているため問題になりません。
しかし、Lambdaのように必要な時だけ起動するタイプの実行環境では、その実行時間制限が問題になります。
Lambdaは最大でも15分間という実行時間の制限があります。
AI Agentが15分以上処理をする可能性があるようなケースではインフラにLambdaを選択するのは難しいです。
しかし、必要な時だけ起動してほしい...ということはあります。
AgentCore Runtimeはそうした実行時間のバラつきにも対応できます。
AgentCore Runtimeの場合は最大8時間まで実行できるため、AI Agentの処理時間を気にする必要がありません。
また、ありがたいことに、LLMからの返答を待っている間にCPUを使用していなければ、CPUに対する課金が発生しません。お財布にも優しいですね。
この他にもAI Agentを実装する様々なフレームワークやモデルに対応している点や、ストリーミングに対応している点など、AI Agentの実行基盤に特化した機能があります。
AgentCore Memory
次にAgentCore Memoryです。
Memoryというくらいなので記憶に関する機能です。
Memoryには短期メモリと長期メモリという二つの機能があります。
この機能はみなさんが普段使っているであろうAI Agentを思い浮かべると分かりやすいと思います。
短期メモリ
まずは短期メモリです。
例えば、チャットアプリとエアコン比較の話をしている際、「さっき説明してくれたエアコンの中で一番安いのってどれ？」という質問をすることがあると思います。
これに対してチャットアプリは「先ほど説明した商品の中で最も安いのはA社です。続いてC社が...」というような回答をすると思います。
よくありますね。
あたかもついさっき話した内容を覚えているかのような回答をします。これが短期メモリです。
もう少し詳しく説明しましょう。
「先ほど」というのは、いつのことでしょうか？
人間であれば何となく分かりますね。あーついさっき話したやつね。という感じです。
しかしプログラムの場合は記憶するためには、何かしらの「記憶しておく場所」が必要です。
この記憶しておく場所というのがAgentCore Memoryの短期メモリです。
短期メモリは今進行している会話を記憶します。
あくまでも、今進行している会話（セッション）なので、新しくセッションを開くと短期メモリに記録されたことはきれいさっぱり忘れています。
長期メモリ
次に長期メモリです。
皆さんが使っているAI Agentは、自分がよくする話をだんだん覚えてきませんか？
私は普段からAWS関連の調べ物をすることが多いのですが、全然関係のない質問をした時に、「あなたが好きなAWSに例えると...」みたいな回答をしてくることがあります。
これは、私の好みをAI Agentが覚えているということです。
これが長期メモリです。
長期メモリはセッションを跨いで記憶されます。
仕組みとしては短期メモリに保存されたデータから会話の要約や、ユーザーの好みなどを非同期に抽出して長期メモリに保存しています。
これらのMemoryの機能は、AgentCore以外でも同じようなことは実装できます。
例えば、Lambdaであれば会話情報をDynamoDBに書き出しておく。みたいな方法です。
しかし、セッションやユーザーごとにデータを管理したり、インフラや読み書きの実装をしたりと、自分で実装しなければならない部分が多いです。
これをAgentCore Memoryを使うことで、開発者が自分で実装する負担を軽減できるので、特別な要件がなければ積極的に使いたい機能です。
特に短期メモリはチャット系のAI Agentを実装する上でほぼ必須の機能だと思うので、こういった機能をAgentCoreの機能群として用意してくれているのは嬉しいですね。
AgentCore Identity
次はAgentCore Identityです。
Identityは認証・認可に関するAgentCoreの機能です。
Identityも2種類あって、Inbound AuthとOutbound Authがあります。
Inbound Authは外部からAgentCore Runtimeを呼び出す際に検証する機能です（外→中）
Outbound AuthはAgentCore Runtimeが外部サービスにアクセスする際に検証する機能です（中→外）
Inbound Auth
Inbound Authはユーザー（呼び出し元）がRuntime上で動いているAgentを呼び出しても良いか検証します。
ユーザーが正しい認証情報を持っていればIdentityはRuntimeの呼び出しを許可します。
Inbound AuthはIAM認証やCognito、外部IdPのJWT認証にも対応しています。
Outbound Auth
Outbound Authは、Runtime上で実行されるAI Agentが外部サービスを利用する際に、必要な認証情報を安全に取得・利用するための仕組みです。
例えばエアコンの一覧を照会するAPIがあるとします。このAPIを実行するにはAPIキーが必要です。
この時、Runtimeに直接APIキーを埋め込むのはリスクが高いので、安全なところに置いておきたいです。
AgentCore IdentityはToken Vaultというトークンの保管場所があり、そこにAPIキーやOAuth 2.0トークンを保存できます。
Outbound Authはその保管場所からAPIキーを取得して、外部サービスへアクセスできるようにします。
ここではAPIキーの例を書きましたが、OAuth 2.0トークンを保管してGoogle関連のサービスやGitHubにアクセスすることもできます。
Identityも自前で実装できそうですが、APIキーの安全な保管、ユーザーごとの権限分離などの対応まで考えると、実装だけでなく継続的な運用コストも無視できないですよね。
AgentCore Identityは、「誰がAgentを利用できるか」を確認し、AgentがGoogleやGitHub、社内APIなどの外部サービスを安全に利用するための認証情報を管理します。
AgentCore Gateway
次にAgentCore Gatewayです。
Gatewayという名前の通り、いろいろなツールの入り口になる機能です。
何と何を繋ぐ入り口かというと、「AI Agent」と「ツール」を繋ぐものです。
ひとことにツールと言ってもいろいろあります。
MCPサーバーや、自分で作成したプログラム、他のAgentやGitHubのような外部サービス、LLMプロバイダーなど様々です。
また、Gatewayにはレート制限機能もあり、ユーザー単位のリクエスト制限や、LLMの呼び出しなどを制限できます。
ここに書いた以外にもGatewayとPolicyを統合して、Gatewayでユーザーがどのツールをなんの権限で呼び出せるかの制御や、GatewayからMemoryを呼び出すこともできます。
正直、なんのために使うんだろうと思ったりしますが、入り口をGatewayに絞ることで、アクセス権限や経路を一括管理しやすくするといった目的があるのかなと思います。
まとめ
今回はAgentCoreの概要をイラストを交えながら紹介しました。
Memory, Identity, Gatewayなどを紹介しましたが、他にもPolicy, Observability, Evaluations, Browser, Code Interpreter, Optimization などなど...AgentCoreほにゃららはたくさんあります。
この記事ではAI AgentとAgentCoreの関係性について、AgentCoreはあくまでもAI Agentを動かす基盤であることを理解して欲しいです。
AgentCoreは基盤でしかないので、例えば基盤部分をEC2やLambdaに置き換えることも可能です。その上で動くプログラムがAI Agentな動きをすれば、それはAI Agentです。
しかし、AI Agentを本番環境で動かす上で必要となる機能がAgentCoreにはたくさん用意されています。
今回紹介したMemoryやIdentity, Gatewayもその中のイチ機能です。
この記事を読んで、まずはAgentCoreを触る機会に繋がれば嬉しいです。
最後に
ここまで読んだ皆様は、もうAgentCoreを触ってみたくなっているはずです。
概要すぎる！！もっと詳しく！！という方は毎日私にAgentCoreの最新情報を教えてくれる同僚が昨年末に頑張って作ったこちらの資料がおすすめです。
AgentCoreについて実装方法も交えながら、網羅的に書かれた素晴らしい資料です。
