Amazon Bedrock AgentCore

解決する課題

試作した AI エージェントを本番に載せようとすると、安全に実行する基盤、会話やタスクの記憶（メモリ）、外部ツールへの安全な接続、ユーザーに代わって API を呼ぶための認証、そして動作を追跡する監視など、多くの周辺機能が必要になります。これらを自前で用意すると、本来作りたいエージェントの中身よりも運用基盤づくりに時間を取られます。

• エージェントをセキュアにサーバーレスで実行する基盤を肩代わりする
• 短期・長期のメモリ、外部ツール連携、認証、監視といった部品を個別に提供する
• 特定のエージェントフレームワークやモデルに縛られずに使える

アイデアの段階から本番運用までを、基盤の作り込みなしに短期間で渡せる点が中心的な価値です。

主要概念と用語

• エージェント: 基盤モデルの判断にもとづいて、ツール呼び出しや複数ステップの処理を自律的に進めるアプリケーション。AgentCore はその実行・運用を支える
• Runtime（ランタイム）: エージェントやツールを動かすサーバーレスな実行環境。任意のフレームワークやプロトコルに対応し、セッションを分離して実行する
• Memory（メモリ）: 会話の文脈を保持する仕組み。1 セッション内で使う短期メモリと、セッションをまたいで共有する長期メモリがある
• Gateway（ゲートウェイ）: 既存の API や Lambda 関数、MCP サーバーなどを、エージェントが使えるツールとして安全に公開・検索・接続するための入口
• Identity（アイデンティティ）: エージェントがユーザーに代わって、あるいは自身として外部サービスにアクセスするための認証・認可。トークンを安全に保管する
• Browser / Code Interpreter（組み込みツール）: エージェントが Web を操作したりコードを実行したりするための、隔離された組み込みツール
• Observability（可観測性）: エージェントの動作・遅延・呼び出し回数などを追跡する監視機能
• MCP / A2A: ツール接続やエージェント間連携に使われるプロトコル。Runtime や Gateway が対応する

仕様・制限・クォータ

• Runtime は任意のオープンソースフレームワーク（エージェント構築ライブラリ）や任意のモデルで書いたエージェントを動かせる
• 各機能（Runtime・Memory・Gateway・Identity・組み込みツール・Observability など）は単独でも組み合わせても利用できる
• Gateway では既存の API・Lambda 関数・MCP サーバーをツールとして公開でき、多数のツールから関連するものを検索して使える
• Memory は**短期（セッション内）と長期（セッションをまたぐ共有）**の両方をサポートする
• 利用できるリージョンは限られており、対応リージョンは順次拡大している

対応リージョン・上限値・対応フレームワークやプロトコルの詳細は更新されるため、最新の公式ドキュメントで確認してください。

内部の仕組み

AgentCore は単一の機能ではなく、エージェント運用に必要な部品を集めたサービス群です。利用者は必要な部品だけを選んで組み合わせます。

• Runtime: エージェントのコードを受け取り、セッションごとに分離された環境で実行する。実行中だけ計算資源を使い、待機やアイドルの間はリソースを消費しない設計が特徴
• Memory: 会話やタスクの履歴を保存し、必要なときに文脈として取り出す。短期メモリはそのセッション限り、長期メモリは複数セッションで共有して、ユーザーの好みや過去のやり取りを引き継ぐ
• Gateway: 既存の API や関数を、エージェントが理解できるツール定義に変換して公開する。ツールが多くても、意味に基づく検索で関連するものを見つけて呼び出せる
• Identity: エージェントが外部サービスへアクセスする際の認証を仲介し、リフレッシュトークンなどを安全な保管領域に格納する。ユーザー本人として動く場合も、エージェント自身として動く場合も扱える
• Observability: 各部品の動作メトリクスを収集し、CloudWatch に集約してエージェントの挙動を追跡できるようにする

フレームワークやモデルに依存しないため、既存のエージェントコードを大きく書き換えずに本番基盤へ載せられます。

設計パターン / ベストプラクティス

• 必要な部品から段階的に: 最初から全機能を使う必要はなく、まず Runtime でデプロイし、後から Memory や Gateway を足していく
• ツールは Gateway に集約: 個々の API を直接呼ばせるのではなく、Gateway 経由で公開して認可と検索を一元化する
• 長期メモリで体験を継続: ユーザーの好みや過去の文脈を長期メモリに保持し、セッションをまたいだ一貫した応答にする
• 認証は Identity に委ねる: トークンを自前で持ち回さず、Identity に保管・更新を任せて漏えいリスクを下げる
• 本番前に可観測性を組み込む: リリース前から Observability を有効化し、遅延やエラーの傾向を把握できる状態にしておく

運用・監視

• エージェントや各部品の呼び出し回数・遅延・エラーなどのメトリクスは CloudWatch に集約され、Observability から確認できる
• API 操作の監査証跡は CloudTrail に記録される
• セッション分離により、あるユーザーの処理が別のユーザーへ影響しにくい構成になっている
• 障害時に備え、エージェントのリトライやタイムアウトの方針をアプリ側でも設計しておく

コスト

• 課金は従量制が基本で、前払いや最低利用料はなく、使った分だけ支払う
• Runtime は実際に使った計算資源（CPU・メモリ）に対する課金で、待機やアイドルの時間は課金対象外になる設計が特徴
• Gateway はツールへの呼び出しや検索など、操作の回数に応じて課金される傾向がある
• Memory・Identity・組み込みツールなど、利用した機能ごとに課金単位が異なる

具体的な単価はリージョンや機能で異なり変動するため、料金は公式の料金ページで確認してください。各機能を単独で使える分、まず小さく検証してから本番ボリュームを見積もるのが安全です。

セキュリティ

• アクセス制御は IAM で行い、エージェントや各部品に最小権限のみを付与する
• 外部サービスへのアクセス認証は Identity が仲介し、トークンを安全な保管領域に格納する
• セッションごとの分離実行により、ユーザー間でのデータ混在を防ぐ
• 通信は TLS で保護され、保存データの暗号化には KMS 管理鍵を利用できる
• エージェントがユーザーに代わって動く場合は、誰の権限で何ができるかを明確にし、過剰な代理権限を与えない

関連サービス・比較

基盤モデルを API で使う Amazon Bedrock とは役割が異なります。Bedrock が「モデルを呼ぶ」サービスなのに対し、AgentCore は「エージェントを本番で動かす」基盤です。両者は組み合わせて使えます。

ハンズオン / CLI例

# AgentCore Control 系の API 操作を確認（利用可能なコマンド一覧）
aws bedrock-agentcore-control help

# Runtime にデプロイ済みのエージェントランタイムを一覧表示
aws bedrock-agentcore-control list-agent-runtimes \
  --query "agentRuntimes[].{Name:agentRuntimeName,Status:status}"