Amazon Bedrock AgentCore APIの使い方｜SDK・CLIでAIエージェントを本番デプロイ【2026年最新】

Amazon Bedrock AgentCoreは、任意のフレームワークとモデルで作ったAIエージェントを、サーバー管理なしで本番運用するためのAWSのマネージド基盤です。2025年7月のプレビュー公開を経て、2025年10月13日に一般提供（GA）となり、VPC・AWS PrivateLink・CloudFormation・リソースタグに対応しました。この記事は主力キーワードである「AgentCore API」に沿って、エージェントを操作する3つの入口（SDK・CLI・InvokeAgentRuntime API）の実コードを中心にまとめます。Runtime・Gateway・Memoryなど主要コンポーネントの使いどころ、従量課金の料金、Bedrock Agentsとの違いまで、公式ドキュメントの一次情報で確認できます。

まとめ：AgentCore APIを触る前に押さえる要点

• AgentCoreは「コードは自分で書く、インフラはAWSが持つ」基盤。フルマネージドで設定中心のBedrock Agentsとは役割が違う（後述の比較表を参照）。
• エージェントの入口は3つ。①ランタイム化するbedrock-agentcore SDK（Python）、②雛形生成〜デプロイを担う@aws/agentcore CLI（npm）、③外部から呼び出すInvokeAgentRuntime API（boto3等のAWS SDK）。
• フレームワークは非依存。Strands Agents・LangChain/LangGraph・CrewAI・LlamaIndex・Google ADK・OpenAI Agents・独自コードを載せられる。
• 料金は12コンポーネントの従量課金。AgentCoreの仕組み自体は無料で、消費したリソースにだけ課金される。Runtimeは1 vCPU時0.0895ドル・1 GB時0.00945ドル。
• 旧来のbedrock-agentcore-starter-toolkit（agentcore configure／agentcore launch）は現在レガシー扱い。新規は@aws/agentcore CLIを使う。

Amazon Bedrock AgentCoreとは｜GAした本番エージェント基盤

AgentCoreは、エージェントの実行環境・セッション隔離・メモリ・ツール接続・認証・可観測性といった「本番で必要になる周辺機能」を個別のマネージドサービスとして提供します。特定のエージェントフレームワークやモデルに縛られず、開発者はエージェント本体のコードだけを書けばよいのが設計思想です。GAに伴い、すべてのサービスがVPC・PrivateLink・CloudFormation・タグに対応し、本番のガバナンス要件に載せやすくなりました。

AgentCoreを構成する7つのマネージドサービス

GA後は上記に加え、品質評価のEvaluations、x402マイクロ決済のPayments、認可制御のPolicyといったコンポーネントも料金体系に組み込まれています。各コンポーネントは単体でも組み合わせても使え、Runtimeを使わず既存のエージェントからMemoryやGatewayだけを呼ぶ構成も可能です。

Bedrock AgentsとAgentCoreの違い｜どちらを選ぶか

「bedrock agents agentcore 違い」で検索する人が最初に迷うのがこの2つの棲み分けです。結論から言うと、コードを書かずに設定で完結させたいならBedrock Agents、任意のフレームワークで書いたエージェントを本番に載せたいならAgentCoreです。両者は競合というより、抽象度の違う選択肢です。

すでにLangGraphやStrandsでエージェントを組んでいるなら、作り直さずAgentCore Runtimeに載せられるため移行コストは小さくなります。逆に、要件が「社内ドキュメントに答えるQ&Aボット」程度で内製工数を割きたくないなら、Bedrock Agentsのほうが早い。フレームワークにこだわりがない小規模PoCでAgentCoreをフル装備すると、後述の12コンポーネント課金が過剰になりがちなので注意してください。

AgentCore APIとSDKの全体像｜3つの触り方

「AgentCore API」と一口に言っても、開発フェーズごとに触る対象が変わります。役割を混同するとドキュメントを探しても目的の手順にたどり着けないため、まず3つの入口を分けて理解します。

ざっくり言えば、SDKで「エージェントを載せる形」を作り、CLIで「AWSに配る」、APIで「アプリから叩く」という流れです。以下で順に実コードを示します。

AgentCore SDKでエージェントを本番化する（bedrock-agentcore）

PythonのランタイムSDKbedrock-agentcoreは、自作のエージェント関数を、ヘルスチェックとストリーミングに対応した本番用HTTPサーバーに変換します。2026年7月時点の最新は1.18.0（2026年7月10日リリース）で、Python 3.10以上が必要です。中核はBedrockAgentCoreAppクラスと@app.entrypointデコレータの2つだけです。

pip install bedrock-agentcore

from bedrock_agentcore import BedrockAgentCoreApp
from strands import Agent

app = BedrockAgentCoreApp()
agent = Agent()

@app.entrypoint
def invoke(payload):
    result = agent(payload.get("prompt"))
    return {"result": str(result)}

if __name__ == "__main__":
    app.run()

@app.entrypointを付けた関数が、リクエストを受け取る呼び出し口になります。app.run()はローカルでは既定でポート8080のサーバーを起動し、AgentCore Runtimeと同じHTTPプロトコルで動作を確認できます。ストリーミング応答が必要なら、関数内でreturnではなくyieldでイベントを逐次返します。Runtimeの実行環境はARM64（AWS Graviton）のため、コンテナビルドする場合はARM64向けにビルドする必要があります。

AgentCore CLIでデプロイする（@aws/agentcore）

デプロイと開発を担うのが@aws/agentcore CLIです。npmで配布され、Node.js 20以上とAWS CDKを前提に、内部でCloudFormationスタックを組み立ててRuntimeやIAMロールを作成します。旧bedrock-agentcore-starter-toolkit（agentcore configure／agentcore launch）はレガシーになったため、新規プロジェクトはこちらを使います。

npm install -g @aws/agentcore
agentcore create --name MyAgent --framework Strands --model-provider Bedrock --memory none
cd MyAgent
agentcore dev            # ローカルで動作確認（http://localhost:8080）
agentcore deploy         # CDKでAWSにデプロイ
agentcore invoke "Tell me a joke"   # デプロイ済みエージェントを呼ぶ

agentcore createは対話ウィザードでも、フラグ指定でも雛形を生成できます。--frameworkはStrands／LangChain_LangGraph／GoogleADK／OpenAIAgents、--protocolはHTTP／MCP／A2A、--memoryはnone／shortTerm／longAndShortTermから選びます。デプロイ前にagentcore deploy --dry-runで差分を確認でき、片付けはagentcore remove allのあと再度agentcore deployでリソースを削除します。使うフレームワークの詳細はStrands Agentsとは？AWS製OSSエージェントSDKの使い方・特徴を解説【読み方も】やLangChainとLangGraphの違い｜v1.0で逆転した関係と使い分けが参考になります。

InvokeAgentRuntime APIでエージェントを呼び出す（boto3）

デプロイ後、アプリケーションからエージェントを呼ぶのがInvokeAgentRuntime APIです。boto3ではbedrock-agentcoreクライアントのinvoke_agent_runtimeを使い、エージェントのARN・セッションID・ペイロードを渡します。応答はストリーミングで返り、ペイロードは最大100MBまで扱えます。

import json, uuid, boto3

agent_arn = "<あなたのエージェントのARN>"   # agentcore status で取得
client = boto3.client("bedrock-agentcore")
payload = json.dumps({"prompt": "こんにちは"}).encode()

response = client.invoke_agent_runtime(
    agentRuntimeArn=agent_arn,
    runtimeSessionId=str(uuid.uuid4()),
    payload=payload,
    qualifier="DEFAULT",
)

content = []
for chunk in response.get("response", []):
    content.append(chunk.decode("utf-8"))
print(json.loads("".join(content)))

runtimeSessionIdに同じ値を渡し続けると会話コンテキストが維持されます。衝突を避けるためUUIDなど一意な値を推奨します。呼び出しにはbedrock-agentcore:InvokeAgentRuntime権限が必要で、権限不足はAccessDeniedException、ARN誤りはResourceNotFoundException、レート超過はThrottlingExceptionで返ります。OAuthでユーザー認証を統合する場合はAWS SDK経由では呼べず、HTTPSで直接InvokeAgentRuntimeを叩く必要がある点に注意してください。エージェント本体の作成・更新など管理系の操作は、別クライアントのbedrock-agentcore-control（CreateAgentRuntime等）で行います。

主要コンポーネントの使いどころ｜Gateway・Memory・Identity・Observability

Gateway：既存APIをMCPツール化する

AgentCore Gatewayは、OpenAPI仕様やLambda関数をMCP（Model Context Protocol）のツールとしてエージェントに公開します。エージェントごとにツール連携コードを書かず、Gateway側でツールを一元管理できるのが利点です。MCPサーバー自体の作り込みはFastMCPとは｜PythonでMCPサーバーを最速構築するフレームワークの使い方【2026年版】が理解の助けになります。

Memory：短期STMと長期LTM

短期メモリ（STM）は1つの会話セッション内の文脈を保持し、長期メモリ（LTM）はセッションをまたいで事実・嗜好・要約を自動抽出して蓄積します。CLIの--memory longAndShortTermやコンソールでLTMを有効化すると、抽出戦略（SEMANTIC等）に沿って記憶が構築されます。

Identity：認証の仲介と課金の勘所

Identityはエージェントへの受信認証と、外部サービスへの送信認証の両方を仲介します。実務上重要なのは、RuntimeまたはGateway経由でIdentityを使う場合、Identity分の追加課金は発生しない点です。

Observability：CloudWatchで追跡する

ObservabilityはOpenTelemetry準拠でトレース・ログ・メトリクスをCloudWatchに送ります。CLIならagentcore logsでログを、agentcore traces listでトレースを確認できます。ただしCloudWatch側の課金には上限がないため、監視コストは別枠で見積もる必要があります。

AgentCoreの料金体系｜従量課金の勘所

AgentCoreは、前述の7つの主要コンポーネントにGA後追加のEvaluations・Payments・Policyなどを加えた計12の課金項目を、個別に従量課金します。基盤（ハーネス）そのものは無料で、各コンポーネントが実際にリソースを消費したときだけ課金される設計です。代表的な単価は以下のとおりで、変動しうるため契約前に公式の料金ページで確認してください。

見落としやすいコストが2つあります。1つはアイドル状態のセッションメモリで、既定15分のタイムアウトまでメモリが確保され続けるため、放置セッションが積み上がると課金対象になります。もう1つはObservability（CloudWatch）に上限がない点で、テレメトリ量が多いエージェントでは監視費が本体費用を上回ることもあります。小規模から始め、実測してからコンポーネントを増やすのが安全です。

よくある質問

AgentCoreは無料で使えますか？

基盤の仕組み自体は無料ですが、Runtimeの実行時間やGateway・Memoryなどの利用量に応じて従量課金されます。呼び出さなければ料金は発生しません。ただしアイドルセッションのメモリ確保やCloudWatchの監視費は発生しうるため、実質的に「完全無料」ではありません。

Bedrock AgentsとAgentCoreの違いは何ですか？

Bedrock Agentsは設定中心のフルマネージドで、AWSがエージェントループを実行します。AgentCoreは自分でフレームワークを選んでコードを書き、その実行基盤・メモリ・認証・監視をAWSが受け持ちます。既存のLangGraphやStrandsのエージェントを本番化したいならAgentCoreが適しています。

どのエージェントフレームワークが使えますか？

フレームワーク非依存で、Strands Agents・LangChain/LangGraph・CrewAI・LlamaIndex・Google ADK・OpenAI Agents・独自コードを載せられます。CLIの雛形生成ではStrands・LangChain_LangGraph・GoogleADK・OpenAIAgentsを選択できます。

agentcore configure や agentcore launch が動きません。

それらは旧bedrock-agentcore-starter-toolkitのコマンドで、現在はレガシー扱いです。新しい@aws/agentcore CLIではagentcore create／agentcore dev／agentcore deploy／agentcore invokeに置き換わっています。

AgentCore Runtimeはどんな環境で動きますか？

RuntimeはARM64（AWS Graviton）のサーバーレス環境で動作し、セッション隔離と最長8時間の長時間実行に対応します。既定のデプロイリージョンはus-west-2で、コンテナをビルドする場合はARM64向けにビルドする必要があります。より詳しくは、Amazon Quickの記事で整理しています。

関連記事

• Strands Agentsとは？AWS製OSSエージェントSDKの使い方・特徴を解説【読み方も】
• LangChainとLangGraphの違い｜v1.0で逆転した関係と使い分け
• FastMCPとは｜PythonでMCPサーバーを最速構築するフレームワークの使い方【2026年版】