Bedrock AgentCoreとは？構成要素・設計の要点と導入の判断基準

エージェント自体は動いているのに、それを支えるインフラの開発・運用が、もうひとつの製品を作るほどの仕事になっていませんか。そんな段階で試す価値があるのが、Amazon Bedrock AgentCoreです。AWSが現在公開している構成は、組み合わせて使える13のサービスと機能からなります。具体的な運用負荷を減らせるものを選び、エージェントの業務上の振る舞いには引き続き自分たちで責任を持つ、という使い方が基本です。

本記事の内容は、2026年10月30日にAWSの公開製品ページとドキュメントで確認しています。以下のコンポーネント一覧は、AgentCoreの製品ページから案内されている開発者向け概要に基づきます。各コンポーネントが自前の実装・運用のどこを代替できるかは、本記事によるエンジニアリング上の分析です。

Bedrock AgentCoreとは？本番運用のどこをAWSに任せられるのか

AgentCoreは、エージェントの本番運用に必要な仕事のうち、選んだ部分をAWSに任せるための基盤です。 エージェントとは、モデルを使って行動を選び、ツールを呼び出し、タスクの達成に向けて処理を進めるソフトウェアです。このループがローカル環境で応答するようになっても、アイデンティティ管理、実行基盤、状態管理、アクセス制御、デバッグには、まだ相当な作業が残ります。

コンサートホールに置き換えるとわかりやすいでしょう。エージェントの振る舞いは演奏にあたります。Runtimeは舞台とその設備を用意し、アクセス制御は出入りを管理し、メモリは役に立つ文脈を保持し、可観測性の仕組みは何が起きたかを記録します。それでも、演奏で何を実現し、成功したかをどう判断するかは、自分たちで決める必要があります。

AWSはAgentCoreの対応範囲を、“Any framework. Any model.” と明記しています。フレームワークやモデルを限定しないという説明で、製品ページにはLangChain、OpenAI Agents SDK、Claude Agent SDK、Strands SDK、独自のフレームワークが挙げられています。ただし、これはAWSが示すプラットフォーム全体の対応範囲です。すべての追加機能で同じ連携が使えることや、移行に作業が発生しないことまで保証するものではありません。AWSの製品概要を参照してください。

エージェントのループを誰が管理するかにも、異なる選択肢があります。Runtimeでは、自分たちのエージェントコードをデプロイします。Harnessでは、設定でエージェントを定義し、AWSが管理するループを利用します。その基盤となるのは、AWSのオープンソースのエージェントフレームワーク、Strands Agentsです。Harnessのドキュメントでも、この違いが明示されています。すでに動くオーケストレーションコードがあるなら、技術責任者が最初に検討すべきなのはRuntimeを使う構成です。

Bedrock AgentsとAgentCoreはどう選び分けるべきか

Amazon Bedrock Agentsで稼働中のシステムを、AgentCoreが登場したという理由だけで移行する必要はありません。 AWSは、既存のBedrock Agents利用者はそのまま利用を続けられるとしています。AgentCoreを検討する理由になるのは、その実行基盤、連携機能、運用機能に対する具体的な要件です。AWSのFAQで確認できます。

両者の違いは、今では「マネージドなループか、インフラか」だけでは整理できません。AgentCoreにもHarnessによるマネージドなループがあるからです。まず、オーケストレーションコードを自分たちで管理したいかを決め、その答えに合う構成を選びます。その際は、AIエージェントのアーキテクチャ全体像も合わせて確認してください。ホスティング先を選んだだけのつもりが、いつの間にかアプリケーション全体の再設計になってしまうのを防ぐためです。

Bedrock AgentCoreの構成要素と、代替できる開発・運用の仕事

コンポーネントは、それを使わなければ自分たちで開発・運用することになる仕事から選びます。 AWSは、各機能を組み合わせても単独でも利用できると説明しています。表の右端は、AWSが基盤サービスを提供していても、アプリケーション側に残る責任です。

たとえばサポートアシスタントなら、Runtime、Gateway、Identityが最初から必要で、継続利用するユーザーの文脈が役立つ段階になってMemoryを追加する、といった構成が考えられます。外部リソースへのアクセス権を購入しないなら、Paymentsの出番はありません。組織内の承認済みリソースを見つけにくくなって初めて、Registryが役立ちます。使うコンポーネントを増やすこと自体を目標にする必要はありません。

Code InterpreterとRuntimeは、解決する課題が異なります。 Runtimeはエージェントをホストし、Code Interpreterはエージェントが実行するコードのためのサンドボックスを提供します。不足しているのが分離されたコード実行環境だけなら、オーケストレーションを移す前に、AIエージェント向けコードサンドボックスのガイドで要件に合う選択肢を比較してください。

アプリケーション側に残るアーキテクチャの判断

線引きすべきなのは、運用を任せる仕組みと、アプリケーションが持つ業務上の権限です。 サポート業務を例にすると、エージェントは注文情報を読み取り、状況を説明し、対応案を提示できます。AWSは実行基盤やアクセスの仕組みを提供できますが、それが誰の注文で、その操作を許可してよいかは、アプリケーション側で判断しなければなりません。

Bedrock AgentCore Runtime：実行の分離とセッションの所有者管理

Runtimeは実行環境を分離できますが、どの顧客がセッションを所有しているかまでは把握しません。 AWSのドキュメントでは、セッションごとに専用のmicroVM環境を使い、コンピュート、メモリ、ファイルシステムのリソースを分離すると説明されています。同じドキュメントには、AgentCoreはセッションとユーザーの対応関係を強制せず、クライアント側のバックエンドで管理する必要があることも明記されています。Runtimeのセッションを参照してください。

サポートアシスタントでは、ブラウザーから送られたセッション識別子だけで、その顧客のセッションだと判断してはいけません。リクエストを認証し、利用を許可するセッションをバックエンドで特定したうえで、後続処理のアクセス範囲をその顧客に限定します。インフラの分離とアプリケーションの認可判断は、それぞれ別に担う必要があります。

Bedrock AgentCore Memory：何を記憶するかは自分たちで決める

Memoryはコンテキスト管理の基盤を代替しますが、そこに何を保存するかは自分たちで決めます。 AWSは、短期の会話コンテキストと、セッションをまたいで保持する長期の情報に対応しています。Memoryのドキュメントに詳しい説明があります。

顧客が簡潔な回答を好むことを覚えるのと、注文の残高を正式な業務データとして保存するのは、別の話です。業務レコードの正本はアプリケーションで管理してください。エージェントが最新のレコードを取得する方法、会話から保持してよい情報、記憶していた好みが変わった場合の扱いも決める必要があります。メモリサービスが、こうしたデータ設計まで代わりに判断してくれるわけではありません。

Bedrock AgentCoreとMCP：Gatewayがツールとの接続を担う

ツールを接続するたびに同じような実装を繰り返しているなら、Gatewayが役立ちます。 Model Context Protocol、略してMCPは、エージェントにツールを公開するための共通インターフェースです。GatewayはAPIやAWS Lambda関数をMCP互換のツールに変換でき、既存のMCPサーバーにも接続できます。現行のドキュメントでは、別のエージェントやモデルへのルーティングも説明されています。Gatewayのドキュメントを参照してください。

注文対応のアシスタントなら、汎用的なデータベース検索ツールを公開する前に、配送状況の確認のように用途を絞った操作を公開します。Gatewayは呼び出しを仲介できますが、その操作の意味、アクセス可能なレコード、再試行によって副作用が重複して発生しないかは、引き続きAPI側で定義する必要があります。

Bedrock AgentCore Identity：認証情報の管理に業務ルールを組み合わせる

Identityは誰がどの認証情報で動くかを管理し、PolicyはGatewayで許可する操作を制御します。 Identityは、ユーザーを代理して操作する場合も含め、AWSリソースや外部サービスへのアクセスに使うワークロードのアイデンティティと認証情報を管理します。Identityのドキュメントで確認できます。

Policyは、関連付けられたAgentCore Gatewayを通るトラフィックを評価し、ツールへのアクセスを許可するか判断します。この適用範囲は重要です。エージェントがGatewayを通さずに行う直接のネットワーク呼び出しまで、Gatewayのポリシーで制御できるとは考えないでください。機密性の高い操作は、意図した制御ポイントを通るようにし、そこを迂回する経路を制限します。Policyのドキュメントを参照してください。

カスタマーサポート用のアイデンティティには、注文の読み取りは許可しても、返金は許可しないことが考えられます。モデルへの指示にはそのワークフローを記述し、実際の権限はツール層と認可層で強制します。

Bedrock AgentCore Observability：トレースから何を評価するか

Observabilityは動作の経緯をたどるために、Evaluationsはその動作を評価するために役立ちます。 AgentCoreは実行状況の表示と、トレースやメトリクスの標準形式であるOpenTelemetryに対応したテレメトリを提供します。ダッシュボードにはAmazon CloudWatchが使われます。AWSは、組み込みのメトリクスと、アプリケーションに計装を加えて取得する追加のトレースや業務メタデータを区別しています。Observabilityのドキュメントに詳しい説明があります。

サポートアシスタントなら、要求された注文情報の取得が完了したか、操作が承認されたかを記録します。ツール呼び出しが技術的に成功していても、業務上は的外れな回答をしている可能性があります。

Evaluationsは、モデルによる判定を含め、組み込み評価とカスタム評価を提供します。実際の利用を代表するケースを自分たちで定義し、影響の大きい失敗を確認してください。評価のドキュメントには、対応するフレームワークと計装方法が記載されています。プラットフォーム全体についての幅広い互換性の説明をすべての機能に当てはめず、自分たちが使う構成で確認する必要があります。

設計前に押さえておきたい制約

コンピュートの存続期間と、必要な状態を保持する期間は分けて考えます。 AWSの現行のライフサイクルに関するドキュメントでは、デフォルトのアイドルタイムアウトは15分、microVMのコンピュートの最大存続期間は8時間です。一方、自分たちのアカウント内でマネージドなAmazon Elastic Compute Cloudのキャパシティを利用するInstancesでは、キャパシティプロバイダーの設定に応じて、最大14日の存続期間を設定できます。ライフサイクルの設定とInstancesを参照してください。

論理的なセッションは、新たに用意されたコンピュート上で再開できます。デフォルトでは、メモリ内の状態とローカルファイルシステムの状態は、コンピュートのライフサイクルに従います。セッションストレージを設定すれば、停止・再開をまたいでファイルシステムのデータを保持できます。処理が中断しても残すべきものを明確にして、設計してください。セッションのライフサイクルとストレージで確認できます。

採用する機能を固める前に、AWSの機能別・リージョン別の対応表を確認します。特定のリージョンで稼働させる必要があるアプリケーションでは、「AWSで利用できる」という確認だけでは足りません。

AgentCoreを導入する価値があるのはどんなときか

具体的に不足している運用機能がリリースを妨げていて、それに対応するマネージドなコンポーネントが要件に合うなら、試すタイミングです。 実行の分離、認可されたツールアクセス、状態の保持、原因調査のしやすさ、そしてそれらを自前で運用する負荷から判断します。

開発者なら、エージェントのロジックは動いているのに、ホスティングやツール連携が整わず先に進めないときに試験導入を始めます。既存のループをRuntimeに載せれば、フレームワークとデプロイ先を同時に変更するよりも、検証対象を絞れます。

運用担当者にとっては、どのエージェントにも共通の認証情報管理、アクセス制御、インシデント調査が必要になったときに、導入の意義が強まります。それらの責任をどう果たせるか確認できるワークフローを選び、原因を調べる必要のある障害も検証に含めます。

技術選定・調達の担当者は、繰り返し発生するどの作業がなくなり、どの連携作業が新たに残るのかを確認してください。AWSの設定、権限設計、アプリケーションの振る舞い、オンコール対応には、引き続き明確な担当者が必要です。

必要な制御が今の構成ですでにできていて、解消すべき具体的な問題がないなら、導入を待ちます。移行するには、現在の構成では提供できない機能が必要になるなど、別の理由が要ります。また、既知の操作を決まった順序で実行するワークフローで、次の行動をエージェントに選ばせる必要がないなら、この選択を気にする必要はありません。

費用が判断を左右する場合は、AWSのAgentCore料金と、当サイトのAmazon Bedrock料金ガイドを合わせて確認してください。

Bedrock AgentCoreの使い方：AWSのCLIで試験導入する

AWSのコードベースのテンプレートから始め、実際の利用を代表する業務操作をひとつ追加します。 以下は、現行のRuntimeクイックスタートとCLIの完全ガイドに沿った手順です。ドキュメントを基にした説明であり、本記事のためにデプロイを実施して検証したものではありません。

完全ガイドでは、Node.js 20.12以降、npm、Python 3.10以降、Pythonの依存関係管理ツールuv、設定済みのAWS認証情報、デプロイ権限、モデルへのアクセスが必要とされています。このテンプレートはCodeZipを使うため、Dockerは不要です。

1. 1

   インストールしてプロジェクトを作成する

   開発用のAWSアカウントまたは環境を使ってください。

   npm install -g @aws/agentcore
   agentcore --version
   agentcore create --name MyProject --template agent-python-strands

   テンプレートには、agentという名前のRuntimeと、AgentCore Memoryのリソースが含まれます。生成された設定で、両方を確認してください。

2. 2

   ローカルで動作を確認する

   cd MyProject
   agentcore dev --mode browser

   ローカルのインスペクターでエージェントを動かして確認します。同じターミナルで次の作業に進む前に、サーバーを停止してください。

3. 3

   ビルド、デプロイ、呼び出しを行う

   agentcore build
   agentcore deploy
   agentcore status
   agentcore invoke --runtime agent --payload '{"prompt":"Hello, what can you do?"}'

   デプロイ時には、AWS Cloud Development Kit、略してCDKを通じてAWSリソースが作成されます。

4. 4

   実行状況を確認し、リソースを削除する

   agentcore logs runtime
   agentcore traces runtime list

   この試験導入プロジェクトのディレクトリで次のコマンドを実行すると、プロジェクトのリソースと、デプロイ済みのスタックが削除されます。

   agentcore remove all --yes
   agentcore deploy --yes

本番のリクエストを流す前に、あいさつのプロンプトを、テスト用の注文情報を取得するような範囲の限られたタスクに置き換えます。受け入れ確認では、正しいデータが返ること、不正なアクセスが拒否されること、ツール呼び出しの失敗をトレースで確認できること、中断後の復旧動作を把握できることを推奨します。これらはアプリケーションに即した試験導入の判断基準であり、AWSの性能を示す主張ではありません。

AgentCoreに期待しすぎてはいけないこと

実行環境がマネージドになっても、エージェントの業務判断が正しいことの証明にはなりません。 ホスティング、トレース、評価、ポリシーの適用は、それぞれ異なる課題を扱います。役に立つタスクを選び、許容する操作を定め、失敗を検証する責任は残ります。

“Any framework”という説明を、「連携作業が不要」という意味に受け取るべきでもありません。柔軟なプラットフォームであっても、依存関係、認証、計装、採用する各サービスのインターフェース仕様は、自分たちで検証する必要があります。

また、すべてのコンポーネントを採用しても、本番運用の準備が整った証拠にはなりません。読み取り専用のサポートアシスタントに、決済権限や不要なブラウザーを与えても、役に立つようになるわけではありません。具体的なタスクに必要になったときに機能を追加し、広がる権限もレビューの対象にしてください。

次に取り組むこと

既存のエージェントのタスクを選び、何の運用作業が進行を妨げているのかを書き出します。その遅れを解消するために必要なAgentCoreの機能だけを試験導入してください。デプロイ、障害対応、管理責任に伴う負荷がどう変わるかを現在の構成と比較し、その結果を根拠に導入範囲を広げます。

AIシステムの構築と運用に役立つ実践ガイドを、ニュースレターでお届けします。