AgentCore概要

この章では、AWSがマネージドで提供するエージェント実行基盤であるAmazon Bedrock AgentCoreについて学びます。これにより、Bedrock本体との違いやRuntime・Harness・主要コンポーネントの位置づけが理解できます。

1. 本章の概要

1.1 本章の目的

Lambda + Bedrock で自作したエージェント基盤は、Runtime・記憶・ツール管理・アクセス制御・可観測性などを自分で組み立てる必要があります。AgentCoreはこの周辺要素をマネージドサービスとして提供するため、エージェントロジックそのものに集中できるのが特徴です。以降のAgentCoreハンズオンに入る前に、全体像と各コンポーネントの位置づけを整理します。

1.2 本章で学ぶ内容

AgentCoreの位置づけとBedrock本体との違い、実行基盤としてのHarnessとRuntimeの使い分けを扱います。あわせて、主要コンポーネント（Memory・Gateway・Identity・Observability・Browser・Code Interpreter）の役割も整理します。

2. AgentCoreとは

Amazon Bedrock AgentCore は、AIエージェントを本番環境で運用するために必要な要素をマネージドサービスとして提供する基盤です。エージェント本体のロジックだけでなく、その周辺にある「状態を保持する」「外部からツールとして公開する」「アクセス権限を管理する」「動きを可視化する」といった役割を1つのサービス群でカバーします。

前の章では、以下のような内容を Lambda + Bedrock で自作しました。

• マルチターン会話（DynamoDB に session_id 単位で会話履歴を保存）
• 会話履歴の長さ管理（MAX_MESSAGES で古いメッセージを切り詰め）
• システムプロンプト（Converse API の system パラメータで役割・応答スタイルを宣言）
• ツール呼び出しループ（toolUse ブロックを for ループで回して結果を返す）
• ツール実行のエラーハンドリング（toolResult.status に "error" を明示してモデルに失敗を伝える）

ここまでで「1問1答」から一歩踏み込んだエージェントの基本挙動は動く状態になっています。またそれ以外にも、実運用に載せようとすると、以下のような要素が必要になります。

AgentCoreはこれらを個別に組み合わせるのではなく、エージェント運用向けに設計された機能セットとして提供する点が特徴です。前の章で自前実装したツール呼び出しループや DynamoDB での履歴保持は Harness や Memory コンポーネントで置き換えられ、まだ手を付けていない Gateway・Identity・Observability の領域も同じ AgentCore の枠内で扱えます。

3. AgentCoreの実行基盤

AgentCore でエージェントを組むときにまず決めるのは、AIエージェントの本体をどこで動かすか です。ユーザからの質問を受け取ってモデルにツール呼び出しを要求させ、結果をまた次のモデル呼び出しに渡して、最終回答が返ってくるまで繰り返す、この一連の流れを オーケストレーションループ と呼びます。AgentCore は、このループを動かすための実行方式として Harness と Runtime の2つを用意しています。

3.1 Harness

Harness は、エージェントのオーケストレーションループそのものをマネージドで提供する仕組みです。使いたいモデル・ツール・システムプロンプトを YAML などの設定ファイル（以降 config と呼びます）に書き並べるだけで、AWS 側がツール呼び出しループを実行してくれます。

モデルの応答を見てツールを実行し、その結果をまたモデルに渡す、というループを Lambda などで自前実装しようとすると、ループ制御・ツール名の分岐・実行結果の詰め直し・上限回数の管理などを全部自分でコードに書く必要があります。Harness はこれらを config 宣言だけで肩代わりしてくれるので、標準的なツール呼び出しループで足りるケースなら、最短ルートで立ち上げられます。

3.2 Runtime

Runtime は、エージェント本体のコードを動かすサーバレスな実行基盤です。セッション単位で分離された環境が提供され、Harness もこの Runtime の上で動きます。

Runtime を直接使う場合は、ループ処理を自分でコードに書き（Strands や LangChain などのフレームワークと組み合わせる）、それを Runtime へデプロイします。デプロイ方式は、Python コードと依存を zip に固める Direct Code Deployment と、Dockerfile でイメージを組み立てる コンテナデプロイ の2つから選べます。試作・素早い反復には Direct Code Deployment が向き、独自のシステム依存や既存のコンテナ CI/CD パイプラインと組み合わせたい場合はコンテナデプロイが向きます。独自のループ・多段構成のオーケストレーション・独自フレームワークを使いたい場合に、Runtime を選びます。

3.3 Harness と Runtime の使い分け

Harness と Runtime の機能ごとの違いは AgentCore harness vs. Runtime（AWS公式ドキュメント） に一覧があります。「まず Harness で立ち上げ、標準ループで足りない場面が出たときに Runtime へ寄せる」進め方が公式でも推奨されています。本講座のハンズオンも、先に Harness で最短ルートを体験し、そのあと Runtime で自分のループを書く順番で進めます。

4. AgentCoreの主要コンポーネント

実行基盤（Harness / Runtime）に加えて、AgentCore には目的別のコンポーネントがいくつも用意されています。すべてを一度に使う必要はなく、必要な部分だけ組み合わせる形で使います。

4.1 Memory

エージェントに短期／長期の記憶を持たせるマネージドなコンポーネントです。前の章で DynamoDB に自前で会話履歴を保存した処理を、AgentCore 側に丸ごと任せる位置づけになります。

• 短期メモリでは、同じセッション内でのユーザ発言・モデル応答・ツール実行結果を AgentCore 側で自動的に保存・取得する。前の章の session_id 単位の messages の put/get や MAX_MESSAGES による切り詰めロジックが不要になる
• 長期メモリでは、セッションを跨いで残したい情報（ユーザの嗜好・過去のプロファイル・重要な事実など）を抽出戦略に基づいて非同期に保存し、必要なときに意味検索で引き出せるようにする

本講座では AgentCore Memoryで会話履歴を保持しよう で、bedrock-agentcore SDK が Strands 向けに提供する AgentCoreMemorySessionManager を Runtime エージェントに組み込み、短期メモリでのマルチターン会話と長期メモリでのセッション跨ぎの情報保持を体験します。

4.2 Gateway

エージェントに使わせたい Lambda 関数や REST API など、様々な形式のツールを外部の MCPクライアントに公開するマネージドなコンポーネントです。将来的に複数プロトコルへの拡張が想定されていますが、現時点で対応するプロトコルは MCP（Model Context Protocol）のみです（Amazon Bedrock AgentCore Construct Library（AWS公式ドキュメント） に「Currently MCP is the only protocol available.」と記載）。エージェント同士の連携で使われる A2A（Agent to Agent Protocol）は Gateway ではなく AgentCore Runtime 側でサポートされている点も、頭の片隅に置いておくと後で混乱しにくくなります。

前提として、MCP の位置づけを整理しておきます。MCP は、AIエージェントや IDE などの「MCPクライアント」が、外部のツールやデータソースを提供する「MCPサーバ」に、統一されたプロトコルで接続するためのオープンな仕様です。プロトコルが決まっていることで、Claude デスクトップ・IDE・独自クライアントなど「MCP を理解する」あらゆるクライアントから、同じ MCPサーバのツールを再利用できます。

AgentCore Gateway を使うと、独自に HTTP サーバを立てたり認証を設計したりする手間が省け、前の章で run_tool の分岐として書いたツールを Gateway に登録すれば、社内他システムや他のエージェントからも同じツールを再利用できるようになります。

本講座では AgentCore Gatewayでツールを統合公開しよう で Gateway を使ったマネージドな公開方法を、AgentCoreで自作アプリケーションのAI操作基盤を作ろう で Python の mcp SDK を使って AgentCore Runtime に MCPサーバを載せる DIY アプローチを、それぞれ体験します。マネージドで手早く公開したい場合は Gateway、独自の実装や特殊な要件がある場合は Runtime に MCPサーバを載せる、と使い分けます。

AWS のサービスに API Gateway という名前のよく似たサービスがありますが、役割は別物です。API Gateway は Lambda などのバックエンドを HTTP/REST エンドポイントとして公開し、任意の HTTP クライアント（ブラウザ・アプリケーション・curl など）から叩けるようにする「入口」の役割を担います。一方 AgentCore Gateway は、エージェントに使わせたいツールを MCP プロトコルで公開し、MCPクライアント（AIエージェント・Claude Desktop・IDE など）から使えるようにする「ツールを束ねる棚」の役割です。「エージェント本体を HTTP で呼びたい」というユースケースは AgentCore Gateway ではなく、API Gateway や Lambda Function URL、あるいは Next.js の Route Handler などの側の話になります（本講座では AIチャットボットを作ろう で Route Handler 経由の呼び出しを扱います）。

4.3 Identity

エージェントの認証・認可を担うマネージドなコンポーネントです。「誰がこのエージェントを呼び出せるか」「エージェントは呼び出し元の代わりに何にアクセスできるか」を統一的に設計する土台になります。

• 受信認証（Inbound auth）: エージェントを呼び出すユーザやアプリケーションを認証する。Amazon Cognito や他の OAuth 2.0 / OIDC プロバイダと連携でき、社内 SSO のトークンをそのままエージェント呼び出しの認証に使う、といった構成が可能
• 送信認証（Outbound auth）: エージェントがツール実行時に外部 API（Slack・GitHub・社内システムなど）にアクセスする際の認証情報を管理する

自前実装では Cognito・IAM・シークレット管理などを個別に組み合わせる必要がありますが、Identity を使うとこれらを一貫して設計できます。本講座では AgentCore Identityでアクセス制御を設計しよう で、Cognito と連携した認証設定と外部 API 向け認証情報の管理を体験します。

4.4 Observability

エージェントの動きを追跡するためのトレース・メトリクス収集コンポーネントです。CloudWatch と統合されていて、以下のような情報が自動で取れます。

• トレース: 1回のエージェント呼び出しで、モデルがどのツールをいつ呼んだか、引数と結果は何だったか、最終回答に至るまでの流れ
• メトリクス: 応答レイテンシ、トークン使用量、エラー率、ツール別の呼び出し回数など

前の章では Lambda 上でツール呼び出しの中身（どのツールがどの引数で呼ばれたか、モデルの toolUse ブロックにどんな JSON が渡ってきたか）を追うために、コード側にログ出力を仕込む必要がありました。Observability を使えば、こうしたトレース情報が Runtime に載せた瞬間から標準機能で自動的に CloudWatch に流れるようになります。

本講座では AgentCore Observabilityでエージェントを可視化しよう で、CloudWatch Transaction Search を有効化し、Runtime に載せた小さなエージェントのトレース・メトリクス・ログを GenAI Observability ダッシュボードで確認する形を体験します。

4.5 Browser

エージェントがヘッドレスブラウザを操作するための隔離環境です。フォーム入力・ページ遷移・スクリーンショット取得・スクレイピングなど、ブラウザで実行するタスクをエージェントに任せられます。

典型的な用途としては以下のようなケースがあります。

• 社内Webアプリケーションからの情報取得（API が公開されていないシステムから、画面越しにデータを取ってくる）
• ログインが必要なサイトからのデータ取得
• 予約サイトやフォームなど「人間がブラウザで操作していた作業」の自動化

自前で構築する場合はコンテナ内で Chromium を管理し、セッション分離・タイムアウト・スケーリングを設計する必要がありますが、Browser を使えばマネージドな隔離環境がそのまま使えます。本講座では AgentCore Browserでブラウザ操作を任せよう で、実際にエージェントに Web ページからのデータ取得を任せる形を体験します。

4.6 Code Interpreter

エージェントが Python・JavaScript・TypeScript のコードを実行するためのサンドボックス環境です。データ処理・グラフ生成・動的な計算などを、eval の危険性を自前で対策することなく安全に実行できます。

典型的な用途としては以下のようなケースがあります。

• ユーザからもらった CSV データを解析してグラフを生成する
• 動的な計算（統計・回帰・シミュレーションなど）をモデルにやらせる
• モデルが生成したコードを試しに動かして結果を検証する

前の章で扱ったツール呼び出しは、create_signature や read_fortune のように「Lambda 側であらかじめ決めておいた固定ロジックを呼び出す」形でした。Code Interpreter を使うと、モデルがその場で生成したコードをサンドボックス内で実行する形が扱えるようになり、eval の危険性を自前で対策する必要もなくなります。本講座では AgentCore Code Interpreterで動的コード実行を任せよう で、実際にサンドボックス内での Python 実行をエージェントに任せる形を体験します。

AgentCore のコンポーネント一覧の最新情報は Amazon Bedrock AgentCore（AWS公式ドキュメント） に記載があります。

5. 主要ユースケース

AgentCoreが特に活きるのは、以下のようなケースです。

• 会話を継続させたい: セッション単位で環境が分かれるRuntimeと、会話履歴を保持するMemoryを組み合わせる
• ツールを社内で共有したい: Gatewayでチーム共通のMCPサーバを立てておき、複数のエージェントから使い回す
• エージェントの挙動をきちんと追跡したい: Observabilityでツール呼び出し・レイテンシ・エラーを一貫して見る
• ブラウザ操作やコード実行が必要: BrowserやCode Interpreterで隔離環境を活用する

一方で「1回の質問に対して短い応答を返すだけ」のような軽量なユースケースでは、AgentCoreをフルに使うと過剰になることもあります。自前実装との使い分けは、必要な機能軸で判断するのが妥当です。「まず前の章のように Lambda + Converse で自前で組んでみて、規模や責務が広がってから必要な軸だけ AgentCore に置き換える」進め方も現実的です。

6. まとめ

この章では、Amazon Bedrock AgentCoreの概要と自前実装との使い分けについて学びました。

• AgentCoreは、エージェント運用に必要な要素をコンポーネント単位で提供するマネージド基盤である
• 実行基盤は、configで宣言する Harness と、自前コードを動かす Runtime の2つで、Harness も内部では Runtime 上で動く
• Runtime のデプロイ方式は、Direct Code Deployment とコンテナデプロイの2つから選べる
• 主要コンポーネントは Memory／Gateway／Identity／Observability／Browser／Code Interpreter の6つで、必要な機能だけ組み合わせて使う
• Gatewayは、Lambda関数・REST API・別のエージェントなど、様々な形式のツールを外部のMCPクライアントに公開するときに使う。現時点で対応するプロトコルはMCPのみである
• 小規模ユースケースは自前実装で十分だが、規模と責務が広がるほどAgentCoreに寄せる価値が高まる
• 「まず Harness で最短ルートを組み、標準ループで足りない場面が出たら Runtime に寄せる」進め方が公式でも推奨されている

次の章では、AgentCoreハーネスを作る流れをハンズオン形式で体験します。