Amazon Bedrock AgentCoreとは｜構成・料金と本番運用の勘所
最終更新日：2026/11/05
Amazon Bedrock AgentCoreとは、AIエージェントの実行・認証・記憶・監視をまとめて引き受けるAWSのマネージド基盤です。モデルの選定や推論料金はBedrock本体の話で、AgentCoreが担うのは「動かし続ける側」。PoCから先に進めないエンジニア向けに、構成要素と料金、設計の勘所を整理します。
先に結論
AgentCoreはエージェントを本番で動かすための土台。どのモデルを使うかではなく、どう動かし続けるかを引き受けるサービス群です
まずはRuntime・Gateway・Identity・Memory・Observabilityの5つを押さえれば全体像はつかめます。残りは用途別の追加機能です
フレームワークとモデルのロックインが小さいのが設計思想。公式ドキュメント上は、LangGraph・CrewAI・Strands AgentsなどのOSSフレームワークと、Bedrock外のOpenAI・Geminiのモデルにも対応するとされています
料金は完全従量制。Runtimeは1vCPU時間あたり0.0895ドルから、Gatewayはツール呼び出し1,000回あたり0.005ドルという単位で積み上がります（2026年11月時点の公式料金ページ掲載値）
案件を探すときは「AgentCore」という語だけで検索しても絞り切れません。AWSの環境タグとAIエンジニア職種を併用して見るほうが実務的です
この記事でわかること
AgentCoreがBedrock本体と何を分担しているのか
主要サービスそれぞれの役割と、いつ必要になるのか
従量課金の単位と、コストが膨らみやすい箇所
本番投入で詰まりやすい設計ポイントと、案件で求められるスキル
対象読者は、Pythonなどでエージェントの試作までは作れていて、次に「本番で運用してほしい」と言われた立場のエンジニアです。生成AIの基礎やプロンプト設計の入門は扱いません。
なお本記事の仕様・料金は、2026年11月時点でAWSの公式ドキュメントおよび公式料金ページから確認できる内容をもとにしています。AgentCoreは機能追加と価格改定が続いている領域のため、見積もりや設計の判断に使う際は必ず公式ページで最新の内容を確認してください。
目次
Amazon Bedrock AgentCoreとは何か
AgentCoreを構成する主要サービス
Bedrock Agents（設定型）との違いと使い分け
料金の考え方
本番運用で詰まりやすいポイント
導入パターン別の進め方
フリーランスエンジニアから見たAgentCore案件
検証を始めるときのチェックリスト
まとめ
よくある質問
Amazon Bedrock AgentCoreとは何か
結論から言えば、AgentCoreはエージェント専用のアプリケーション実行基盤です。モデルを呼ぶところではなく、モデルを呼ぶコードを安全にホスティングし、権限を与え、記憶させ、動きを追跡する層を担当します。
AWSの開発者ガイドでは、AgentCoreを「任意のフレームワークと基盤モデルを使って、エージェントを安全に大規模構築・デプロイ・運用するためのエージェンティックプラットフォーム」と定義しています（AgentCore開発者ガイド）。プレビューを経て一般提供に移行済みのサービスで、その後も機能追加が続いています。提供状況は機能単位で異なるため、採用を検討する機能がプレビューか一般提供かは公式ページで確認してください。
Bedrock本体との役割分担
Bedrockは、複数ベンダーの基盤モデルを統一APIで呼べるサービスです。どのモデルを選ぶか、トークン単価がいくらか、Knowledge Basesで何を検索させるか。こうした論点はBedrock本体側に属します。モデル選定と料金体系は『Amazon Bedrockとは｜主要モデル・料金とAWS LLM開発案件』で整理しているため、本記事では扱いません。
AgentCoreが引き受けるのは、その先です。
論点 | 担当 |
|---|---|
どのモデルを使うか・推論料金 | Bedrock本体 |
エージェントのコードをどこで動かすか | AgentCore Runtime |
外部システムにどうつなぐか | AgentCore Gateway |
誰の権限で動くのか | AgentCore Identity |
会話や学習をどう保持するか | AgentCore Memory |
何が起きたかをどう追うか | AgentCore Observability |
エージェント版のサーバレス実行環境と捉える
AgentCore Runtimeは、エージェントをサーバレスでホスティングするサービスです。コンテナを用意してデプロイすれば、スケーリングとセッション分離はAWS側が面倒を見ます。Lambdaのエージェント版、という比喩が実態に近いでしょう。
ただしLambdaと違い、セッションという概念が最初から組み込まれています。マルチターンの会話、長時間の非同期処理、セッションごとの完全分離。これらはエージェント特有の要件で、汎用のサーバレスでは自前で組む必要がありました。AWS Lambdaで同じことをやろうとして詰まった経験があれば、差分は理解しやすいはずです。
ミニFAQ：AgentCoreを使わないとエージェントは本番に出せないのですか。
いいえ。ECSやLambda、EKS上に自前で組むことも可能です。AgentCoreの価値は、セッション管理・認証・メモリ・トレースといった定型の配管を自作しなくて済む点にあります。AWSの発表でも、本番対応のために「数か月を基盤インフラの構築に費やす」ケースが課題として挙げられていました。
AgentCoreを構成する主要サービス
AgentCoreはモノリシックな1つのサービスではありません。独立して使えるモジュールの集合です。Runtimeだけ使ってMemoryは自前のRedis、という組み合わせも成立します。
以下は公式ドキュメントに記載されている機能を、「いつ必要になるか」の観点で並べ直したものです。事実上の必須はRuntimeだけで、それ以外は要件が出てから足す任意の部品と考えてください。先に挙げた5つは「多くの本番構成で結局必要になる順」であり、Code Interpreter以降はさらに用途が限定されます。
機能 | 役割 | いつ必要になるか |
|---|---|---|
Runtime | エージェントのサーバレス実行環境 | 最初に必要。PoCのコードを本番に載せる段階 |
Harness | モデル・プロンプト・ツールを指定するだけで動くマネージドなエージェントループ | 自前のループを書きたくないとき |
Memory | 短期（会話単位）・長期（セッション横断）の記憶 | 2回目以降の対話で文脈を引き継がせたいとき |
Gateway | 既存API・LambdaをMCP互換ツールに変換 | 社内システムをエージェントから叩かせたいとき |
Identity | エージェントの認証・認可。外部IdPと接続 | エージェントが人の権限を借りて動くとき |
Code Interpreter | 隔離サンドボックスでのコード実行 | 計算・集計・ファイル処理をさせたいとき |
Browser | クラウド上のブラウザ実行環境 | Web画面の操作・情報抽出をさせたいとき |
Observability | 実行経路のトレース・監視。OpenTelemetry準拠 | 本番で「なぜこの答えになったか」を追う段階 |
Evaluations | タスク遂行品質の自動評価 | リリース判定の基準がほしいとき |
Policy | ツール呼び出し前に決定論的な制御をかける | 「やらせてはいけないこと」を機械的に止めたいとき |
Registry | エージェント・MCPサーバ・ツールの社内カタログ | 複数チームで資産を共有する段階 |
実行基盤：RuntimeとHarness
Runtimeは、任意のフレームワークで書いたエージェントをそのまま載せられます。CrewAI、LangGraph、LlamaIndex、Google ADK、OpenAI Agents SDK、Strands Agents。公式ドキュメントが明示的に挙げているのはこの範囲です。フレームワークの比較は『AIエージェント開発フレームワーク比較｜LangGraph・CrewAI・AutoGen』が詳しいので、選定段階ならそちらを先に読んでください。
Harnessは、そのエージェントループ自体をAWSに任せる選択肢です。モデル・システムプロンプト・ツールをインラインで指定すると、オーケストレーションとツール実行を引き受けてくれます。各セッションは独立したmicroVMで動き、ファイルシステムとシェルにアクセスできます。
つなぐ：GatewayとIdentity
Gatewayの役目は単純です。既存のAPIやLambda関数を、MCP互換のツールに変換して公開する。OpenAPI仕様やLambdaを指定すれば、バックエンドを書き直さずにエージェントから呼べるようになります。SalesforceやJIRA、Slackといった既存のMCPサーバへの接続も同じ口から扱えます。
MCPそのものの仕組みは『Model Context Protocolとは｜MCPの仕組み・活用事例をエンジニア視点で解説』で解説しています。エージェント間連携まで視野に入れるなら『A2A（Agent2Agent）とは｜MCPとの違いとエージェント連携の標準化』も合わせてどうぞ。
Identityは認証・認可の層です。Amazon Cognito、Okta、Microsoft Entra ID、Auth0といった既存IdPと接続でき、ユーザー移行や認証フローの作り直しを避けられます。ここは設計を間違えると事故に直結する部分で、最小権限の考え方は『AIエージェントの権限設計｜最小権限とHuman-in-the-loopの実装』にまとめています。
覚える：Memory
短期メモリはマルチターン会話のため、長期メモリはセッションをまたいだ永続化のためのものです。メモリストアを複数エージェントで共有することもできます。
どこまでを記憶させるかは設計判断です。全部覚えさせれば賢くなるわけではなく、むしろコストと誤参照の両方が増えます。設計パターンは『AIエージェントのメモリ設計｜短期記憶と長期記憶の実装パターン』を参照してください。
見る・測る：ObservabilityとEvaluations
Observabilityは、エージェントのワークフローを1ステップずつ可視化します。実行経路の確認、中間出力の監査、ボトルネックの特定。テレメトリはOpenTelemetry互換の形式で出るため、既存の監視基盤にも流し込めます。
Evaluationsは、タスク遂行の品質を自動評価する機能です。StrandsやLangGraphで生成されたセッション・トレース・スパンを対象にできます。
Bedrock Agents（設定型）との違いと使い分け
従来からBedrockには、コンソール上の設定でエージェントを組み立てる方式がありました。AgentCoreはその代替というより、別のアプローチと捉えるのが実態に近いでしょう。
観点 | 設定中心のアプローチ | AgentCore |
|---|---|---|
作り方 | コンソールでの設定が中心 | コードで実装してデプロイ |
推論モデル | Bedrock上のモデル | Bedrock外のモデルも対象 |
フレームワーク | 固有の仕組みに沿う | OSSフレームワークをそのまま載せる |
向いている場面 | 要件が定型的で早く出したい | ロジックが複雑・既存資産を活かしたい |
運用の自由度 | 限定的 | 実行環境・監視・認証を個別に制御できる |
判断軸はシンプルです。エージェントのロジックをコードで管理したいか。Gitでレビューし、テストを書き、CIを回したいなら、AgentCoreの方向に寄せる理由があります。逆に、業務部門が自分で設定を変えたいような用途では、設定中心の方が運用が回ります。
料金の考え方
AgentCoreは前払いも最低利用料もない従量課金です。注意したいのは、料金メーターが機能ごとに分かれている点。単一の単価で見積もると外します。
以下は、2026年11月時点で公式のAgentCore料金ページに掲載されている主な単価です。米ドル建ての掲載値であり、リージョンや利用形態によって異なる場合があります。価格改定も入るため、見積もり時は必ず最新の公式ページで対象リージョンの単価を確認してください。
Runtimeの課金単位
Runtime v1：1vCPU時間あたり0.0895ドル、1GB時間あたり0.00945ドル
Runtime v2（microVM）：1vCPU時間あたり0.1276ドル、1GB時間あたり0.0169ドル。確約ベースラインを選ぶと単価が下がる設定も用意されています
BrowserツールとCode Interpreterも、v1と同じ単価体系です
つまり消費したCPU時間とメモリ時間にしか課金されません。エージェントが待機しているだけの時間が長いワークロードでは、常時起動のコンテナより有利になるケースがあります。
Gateway・Memory・その他の課金単位
Gateway：ツールAPI呼び出し1,000回あたり0.005ドル、検索API1,000回あたり0.025ドル、ツールインデックス100ツールあたり月0.02ドル
短期メモリ：取り込みが1GBあたり1.00ドル、取得が1GBあたり0.20ドル、保存が1GB月あたり0.10ドル
長期メモリ：ビルトイン保存が1,000レコード月あたり0.75ドル、取得が1,000検索あたり0.50ドル
Identity：AWS外リソースへのトークン・APIキーリクエスト1,000件あたり0.010ドル。RuntimeやGateway経由の利用では追加料金なし
Observability：CloudWatchの料金に準じます
短期メモリの取り込みは、2026年10月にイベント課金からデータ量課金へ切り替わっています。古い記事や社内の試算シートが残っている場合は、単位そのものが変わっている点に注意してください。
コストが膨らみやすい箇所
実務で効いてくるのは、Runtimeの単価そのものより呼び出し回数と保持量です。ツールを細かく分割するとGatewayの呼び出し回数が増え、会話ログを丸ごと長期メモリに入れるとレコード数が積み上がります。
Observabilityも同様です。全スパンを無条件に出すとCloudWatch側のコストが伸びます。サンプリング方針は、本番投入の前に決めておくほうが安全です。
ミニFAQ：モデルの推論料金はAgentCoreの料金に含まれますか。
含まれません。基盤モデルの利用料は別建てで、Bedrock経由ならBedrockの、外部プロバイダなら各社の料金が加算されます。見積もりでは「基盤料金＋モデル料金」の二階建てで計算してください。
本番運用で詰まりやすいポイント
セッション分離と状態の持ち方
Runtimeはセッション単位で分離されます。裏を返すと、セッションをまたいで保持したい状態は明示的にMemoryへ出す必要があります。PoCでグローバル変数に状態を置いていたコードは、ここで必ず書き直しになります。
ポートとプロトコルの作法
Runtimeは、エージェント側が実装すべき通信契約を定めています。HTTPならデフォルトのポートは8080でマウントパスは/invocations、MCPなら8000で/mcp、A2Aなら9000でルートパス、という具合です（Runtimeサービスコントラクト）。
加えて、プラットフォーム予約ポートが存在します。1144、1514、1571、2049、4317から4318、8443、48620、48640、53530から53532。自前のサーバをこれらで立てるとデプロイ時に弾かれます。手元のdocker-composeから持ち込んだポート番号が衝突するパターンは、最初の数時間で踏みやすい地雷です。
認証の設計を後回しにしない
Identityは後付けしにくい部分です。エージェントがユーザーの権限で外部システムを叩くのか、サービスアカウントで叩くのか。ここが曖昧なまま作り込むと、監査要件が出た段階で設計ごとやり直しになります。Runtimeのサービスコントラクト上はSigV4とOAuth 2.0が認証方式として挙げられているため、社内IdPの方式に合わせて早めに決めておくのが無難です。
本番導入にあたっては、IAM権限の範囲、OAuthの委譲設計、監査ログの保持、個人情報や機密情報の取り扱いについて、社内のセキュリティ担当者やAWSに詳しい専門家と確認したうえで進めてください。
観測の設計
「なぜこの答えを返したか」を後から説明できる状態にしておくこと。エージェントは非決定的に動くため、ログがないと再現も原因特定もできません。OpenTelemetry準拠で出る以上、既存のAPMに寄せるか、CloudWatchで完結させるかは先に決めておきましょう。
導入パターン別の進め方
ケース1：PoCのコードを本番に乗せ替える
最短ルートです。既存のエージェントコードをコンテナ化し、Runtimeに載せるところから始めます。MemoryもGatewayも最初は使わず、動くことを確認してから足していきます。
この段階で手戻りが出やすいのは、前述の状態管理とポート設定の2点です。
ケース2：既存のAPI群をツール化する
社内にAPIやLambdaが既にある場合、Gatewayから着手する選択肢もあります。エージェント本体は後回しにして、まずツール側をMCP互換で公開してしまう。こうすると、どのフレームワークを採用するかを決める前に資産側の整備を進められます。
ケース3：社内のエージェント基盤を整える
複数チームがエージェントを作り始めている組織向けです。Registryでツールとエージェントを棚卸しし、Policyで越えてはいけない線を引き、Observabilityを共通化する。この規模になるとマルチエージェントの設計パターンが必要になります。
フリーランスエンジニアから見たAgentCore案件
募集要項での現れ方
公開案件を探すとき、「AgentCore」という単語だけで検索しても候補はあまり出てきません。実務的には、AWS環境のタグとAIエンジニア職種を組み合わせて絞るほうが見つかります。募集要項では「Bedrockを用いた生成AI基盤構築」「AIエージェントの本番運用」といった表現で書かれ、面談で詳細を聞くと内訳にAgentCoreが入っている、という順序になりがちです。
フリコンでも、AWS案件の一覧とAIエンジニア案件の一覧の両方から探せます。どちらか一方だけ見ていると、同じ案件を取りこぼします。
求められるスキルの組み合わせ
AgentCore案件で問われるのは、LLMの知識だけではありません。コンテナ、IAM、VPC、CloudWatch。AWSの基礎運用スキルが土台にあり、その上にエージェント設計が乗る構造です。
コンテナのビルドとECRへのデプロイが自力でできる
IAMポリシーを読んで、権限が広すぎないか判断できる
OpenTelemetryやCloudWatchでトレースを追える
MCPの仕様を理解し、ツールのインターフェースを設計できる
LangGraphなどのフレームワークでエージェントのループを書いた経験がある
AWS側の基礎が弱いと感じる場合は、AWS認定資格一覧で学習順序を確認しておくと、面談でも話が通りやすくなります。
単価の考え方
AgentCore名指しの公開案件が潤沢にあるわけではないため、この記事で独自の相場レンジを出すことはしません。近い領域の目安は『AIエージェント開発案件の単価相場｜必要スキル・獲得ルートを解説』と『AWSエンジニア フリーランスの単価相場｜経験・案件レイヤー別に解説』にまとめています。
自分の経歴でどのあたりを狙えるか知りたい場合は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。複数の候補案件を比べる段階なら、『案件の選び方｜フリーランスエンジニアが単価・稼働・スキルで決める優先順位』の比較軸が使えます。
検証を始めるときのチェックリスト
手を動かす前に確認しておくと、手戻りが減る項目です。
既存のエージェントコードがコンテナ化できる状態か
セッションをまたいで保持したい状態を洗い出したか
使いたいポートが予約ポートと衝突していないか
エージェントが使う外部システムの認証方式を把握しているか
ツールとして公開したいAPIがOpenAPI仕様で記述されているか
どのスパンをトレースに残すか方針を決めたか
料金メーターのうち、どれが主要コストになるか試算したか
最初の3つを満たしていれば、小さなサンプル構成でのRuntimeへのデプロイは比較的短時間で検証できます。実際にかかる時間は、AWSアカウントの権限、ネットワーク構成、組織のポリシーによって変わります。詰まりやすいのは4以降です。
まとめ
AgentCoreは、エージェントのビジネスロジック以外をAWSに預けるための基盤です。モデル選定はBedrock本体、動かし続ける仕組みはAgentCore。この分担を掴むと、ドキュメントの読み方が一気に楽になります。
主要なのはRuntime・Gateway・Identity・Memory・Observabilityの5つ。残りは用途別に足す
モジュールは独立して使えるため、Runtimeだけの採用から始められる
フレームワークもモデルも外部のものが使える。OSS資産を捨てずに本番へ寄せられる
料金は機能ごとに別メーター。Runtimeの単価より、呼び出し回数と保持量が効いてくる
設計で先に決めるべきは、セッションをまたぐ状態の持ち方と認証方式の2つ
案件を探すときは、AWS環境タグとAIエンジニア職種の両方から当たる
次の一歩としては、手元のPoCをコンテナ化してRuntimeに載せるところまでを1本通してみるのが確実です。そこで見つかる手戻り（状態管理とポート設定）が、そのまま本番設計の論点になります。
参照した一次情報は以下のとおりです。
よくある質問
AgentCoreはBedrockのモデルしか使えませんか。
Bedrock上のモデルに限定されません。公式ドキュメントのRuntimeの説明では、Bedrock内外の基盤モデル（OpenAI、Google Gemini、Anthropic Claude、Amazon Nova、Meta Llama、Mistral）に対応すると記載されています。ただし実際に使えるかは接続構成や機能ごとの対応範囲に依存するため、採用前に該当機能のドキュメントで確認してください。Bedrockを経由しないモデルの推論料金は、各プロバイダ側の請求になります。
LangChainで書いたエージェントをそのまま載せられますか。
Runtimeは任意のフレームワークに対応する設計のため、原則として載せられます。ただしコンテナ化とサービス契約（ポート・エンドポイント）への適合は必要です。LangChain系の構成なら『LangChainとは？できること・活用事例から年収・将来性まで解説』と『LangGraphとは｜LangChainとの違い・エージェント構築の基本』で前提を押さえておくと移行しやすくなります。
Memoryを使わずに自前のDBで代用できますか。
できます。AgentCoreのサービスは独立して使える設計のため、Runtimeだけ採用してメモリはDynamoDBやElastiCacheで持つ構成も成立します。判断材料は、長期記憶の要約・抽出処理を自作したいかどうかです。自作しないならMemoryのほうが早く、細かく制御したいなら自前が向きます。
Gatewayを使わずにエージェントから直接APIを叩くのは問題ですか。
問題にはなりません。Gatewayの利点は、ツール定義の集約とMCP互換化、そして呼び出しの観測が一箇所に集まることです。ツールが数個なら直接呼び出しで十分ですが、十数個を超えて複数エージェントから使われ始めると、定義の重複管理が負担になります。
AgentCoreとMCPサーバの自作は、どちらを先に学ぶべきですか。
扱う案件によります。ツール提供側に回るならMCPサーバの実装を先に、エージェント本体を作るならAgentCoreのRuntimeを先に触るほうが近道です。MCPサーバ側の具体的な作り方は『MCPサーバーの作り方｜自作の実装手順とMCP開発案件の単価』にあります。
小規模な社内ツール程度でも、AgentCoreを使う価値はありますか。
使わない判断もあり得ます。単発のバッチ処理やSlack通知程度なら、Lambdaに素のコードを置くほうが構成要素が少なく済みます。AgentCoreが効くのは、マルチターンの対話・複数ツールの呼び分け・権限の委譲といった要素が2つ以上絡むときです。
Azure側に同等のサービスはありますか。
用途の重なる選択肢としてAzure OpenAI ServiceやCopilot Studioがあります。ただし設計思想が異なるため、機能を1対1で対応づけるより、要件側から選ぶほうが現実的です。クラウドの選択順序そのものに迷う場合は『クラウド案件の参入順序｜AWS・Azure・GCPどれから取るかの判断軸』が参考になります。
料金の試算が難しいのですが、どこから概算すればよいですか。
Runtimeの消費時間から始めるのが扱いやすい手順です。1セッションあたりの平均処理時間と割り当てvCPU・メモリを仮置きし、月間セッション数を掛けます。そのうえでGatewayの呼び出し回数、Memoryの保存量を足します。モデルの推論料金は別立てで加算してください。
未経験からAgentCore案件に入るのは現実的ですか。
AWS実務が未経験の状態では厳しい場面が多くなります。逆に、AWSでの設計・運用経験があり生成AIが未経験という順序なら、入り口は見つかりやすいほうです。エージェントの基礎概念は『AIエージェントとは？仕組み・種類・活用事例をわかりやすく解説』から入ると全体像をつかめます。
検証用のアカウントで試すとき、コストを抑えるコツはありますか。
割り当てメモリを絞ること、長期メモリを有効にしないこと、Observabilityのスパン出力を限定することの3点が効きます。Runtimeは消費リソースへの従量課金のため、検証中に放置しているだけで大きく請求が伸びる構造ではありません。ただしBrowserやCode Interpreterを並行で走らせると消費は増えます。
