【第1回】Amazon Bedrock AgentCore 入門 — AgentCore Runtimeの概要とPythonで始めるエージェント実行の基本

この記事でわかること

• Amazon Bedrock AgentCoreの全体像と各コンポーネントの役割
• AgentCore Runtimeがどんな課題を解決するか
• セッション分離・長時間実行・デプロイ方式の特徴
• Pythonコードでエージェントをデプロイする基本的な手順
• 課金モデルの特徴と注意点

Amazon Bedrock AgentCoreとは何か

まず全体像から。Amazon Bedrock AgentCoreは、AIエージェントを「安全に・大規模に」デプロイ・運用するための、包括的なサービス群（複数コンポーネント）です。Runtimeを中心に、メモリ、認証、観測、ツール接続などをまとめて扱えるようにしてくれる立ち位置。

「サービス群」というのがポイントで、AgentCoreは1つの機能じゃなくて複数のコンポーネントで構成されています。

• Runtime：エージェント/ツールをセッション分離された環境で動かすサーバーレス実行基盤
• Memory：会話・タスクのコンテキストや知識を保持する仕組み
• Gateway：既存ツール・APIをエージェント向けの「ツール」として接続する仕組み
• Identity：外部サービス向けのトークン取得など（Runtime/Gateway経由利用だと追加料金なしの扱い）
• Observability：実行状況の可視化（CloudWatch等との連携前提）
• Browser：セッション分離されたブラウザ実行（ワークフロー自動化向け）
• Code Interpreter：サンドボックス化したコード実行環境

これらは独立して使えるし、組み合わせることもできるという設計になっています。全部使わなくていいし、Runtimeだけ使うのも全然アリ。

重要なのが、フレームワーク非依存な設計になっている点。公式SDKの説明でも、Strands / LangGraph / CrewAI / Autogen など色々なエージェント実装をそのまま載せ替える用途が想定されています。モデルについても「Bedrockしかダメ」みたいな作りではなく、ネットワーク/認可設計は必要ですが、外部LLM APIを叩く形のエージェントも作れます。

AgentCore Runtimeが解決しようとしていること

ここからが今回のメイン、AgentCore Runtimeの話。

AgentCore Runtimeを一言で言うと、AIエージェント/ツールをホスティングするためのサーバーレス実行環境です。Lambdaに近いイメージですが、エージェントの特性（長時間実行、ストリーミング、セッション分離）を前提に設計されています。

従来の課題として、AIエージェントをインフラに乗せようとすると：

• 実行時間が長い（LLMの応答待ちが多い）からLambdaのタイムアウトが怖い
• セッション管理やコンテキスト保持を自前で実装する必要がある
• セキュリティのサンドボックス化が面倒
• スケーリングの設計が必要

というあたりがネックになりがちでした。AgentCore RuntimeはこのあたりをAWSがマネージドに寄せてくれるイメージです。

主な特徴をまとめると：

• セッション分離：各セッションは分離されたmicroVMで動作し、終了時に破棄・メモリ消去される設計
• 長時間実行対応：最大8時間までの長時間ワークロードをサポート
• 2つのデプロイ方式：direct code deploy（コードをそのままデプロイ）またはコンテナデプロイ

余談ですが、「最大8時間」って聞いたとき、LambdaやECSのタイムアウト設定と格闘してきた経験からすると、これだけでだいぶ気持ちが楽になる。

課金モデルが地味に面白い

AgentCore Runtimeの料金体系、ちょっと変わっていて面白いので先に触れておきます。

通常のコンピューティングサービスはインスタンスを確保した時間分を課金されますが、AgentCore Runtimeは「アクティブなリソース消費量ベース」の従量課金です（CPUとメモリ）。請求は秒単位で、CPUは実消費、メモリはその時点までのピーク使用量をベースに計算、という整理になっています。

何がポイントかというと、I/O待機やアイドルが基本的に無料という点（ただし「他のバックグラウンド処理でCPUを使っていなければ」という前提つき）。LLM待ちが長いワークロードだと、体感コストが下がりやすい設計っぽいです。

あと地味に注意なのが、direct code deployの場合はデプロイしたコード成果物がS3 Standardの保管料金対象になる点。コンテナデプロイの場合はECR保管料金が別途かかります。運用時には頭の片隅に置いておくと安心です。

デプロイの2つのモード

AgentCore Runtimeへのデプロイ方法は2種類あります。

① Direct Code Deploy（直接コードデプロイ）

Pythonコードをエントリーポイントにしてデプロイする方式。Starter ToolkitのCLIだと、デフォルトのデプロイタイプがdirect code deployになっています。Docker不要で「まず動かす」には向いてます。

「とりあえず動かしたい」「Dockerセットアップしたくない」というケースにはこちらが向いています。

② コンテナベースデプロイ

コンテナイメージでデプロイする方式。CLIのオプションとしてcontainerデプロイも用意されています。

コンテナの場合はイメージ内の脆弱性対応などは自分側の責任範囲が増えるので、最初はdirect code deployで始めて必要になってから切り替えるのは現実的な選択だと思います。

PythonでエージェントをRuntimeに乗せる基本

実際のコードを見てみます。AgentCore RuntimeはPython SDKのBedrockAgentCoreAppを使うのが一番シンプルな方法です。

まずインストール：

pip install bedrock-agentcore
pip install bedrock-agentcore-starter-toolkit  # CLI込みで使う場合

エージェントのエントリーポイントとなるファイル（例：agent.py）はこんな感じになります。

from bedrock_agentcore import BedrockAgentCoreApp
from strands import Agent

app = BedrockAgentCoreApp()

@app.entrypoint
async def handler(request):
    prompt = request.get("prompt")
    agent = Agent()
    async for event in agent.stream_async(prompt):
        yield event

app.run()

ポイントは@app.entrypointデコレーターを付けるだけでRuntimeのエンドポイントが定義されるところ。フレームワークはstrandsを使いましたが、LangGraph等に差し替えても同じ構造で動きます。要は「この関数がリクエストを受けて返す/ストリームする」形に寄せればOK、という感じです。

ここで使っているStrands Agentsは、AWSがオープンソースとして公開したエージェントSDKです。AgentCore上で動かす例もAWSブログ側で触れられていて、相性が良い組み合わせになっています。

Starter ToolkitのCLIでデプロイ

Starter Toolkitを使うと、デプロイの手順はかなりシンプルになります。まずconfigureで初期設定を行い、そのあとlaunch（またはdeploy）でデプロイする流れです。

# 初期設定（対話形式）
agentcore configure -e agent.py

設定はローカルの設定ファイル（.bedrock_agentcore.yaml）に保存されます。

# デプロイ
agentcore launch

デプロイ後は、CLIから呼び出せます。

# CLIで呼び出し
agentcore invoke '{"prompt": "面白いことを教えて"}'

セッションのタイムアウト設定

CLIでは--idle-timeoutや--max-lifetimeでセッションの挙動を明示指定できます。例えば--max-lifetime 7200で最大2時間、といった形。デフォルト値は環境差が出やすいので、運用時はagentcore configureで明示指定しておくのが無難かなと思います。

OAuthトークンを使った呼び出しについては、CLI側に--bearer-tokenオプションが用意されていて、そちらで対応できます。boto3での具体的なAPI名は公式のAPIリファレンスで確認するのが確実です。

まとめ

AgentCore Runtimeは「エージェント/ツールをサーバーレスで動かす基盤」として、インフラの手間をかなり省いてくれる印象です。セッション分離や長時間実行（最大8時間）に対応していて、エージェントっぽい処理を素直に載せやすいのが良い。

個人的には料金モデルの「I/O待機やアイドルが基本無料」が気に入っていて、LLMに投げてる間が長いワークロードほど割安になりそうな設計は面白いなと思っています。direct code deployのS3保管料金だけは、うっかり見落としそうなので頭に入れておきたいところ。

第2回はStarter Toolkitを使ったデプロイの実践を予定しています。CLIの細かい挙動や、実際にデプロイしてみてどうだったか、みたいな話を整理するつもりです。