Amazon Bedrock AgentCore完全ガイド 2026｜Managed HarnessとRuntimeの違い・始め方5ステップ

2026.05.20 公開 11分で読める

この記事の結論

Amazon Bedrock AgentCoreのRuntime・Managed Harness・Gateway・Evaluationsを一次情報で整理。始め方5ステップと実運用の勘所を解説します。

最終確認日: 2026年5月20日（日本時間）

結論

Amazon Bedrock AgentCoreは、AIエージェントをAWS上で実運用するための実行基盤です。最短で試すならManaged Harness、本番向けに細かく制御したいならCode-based Runtimeを選ぶのが基本です。

すぐに試作したいチームは、2026年4月22日に発表されたManaged Harnessから始めると早いです。
既存のStrands、LangGraph、Google ADK、OpenAI Agents SDKを活かしたいなら、Code-based Runtimeの方が移行しやすいです。
本番運用では、Gateway、Observability、Evaluationsまで最初から設計しないと、後で品質監視と権限制御が詰まりやすくなります。

向いている読者: AWS上でエージェントをPoCから本番に載せたい開発者、PM、AI基盤担当者

今日やること: まずはAgentCore CLIで雛形を作り、RuntimeとHarnessのどちらで始めるかを決めましょう。

「AWSでAIエージェントを動かしたいが、LangGraphやOpenAI Agents SDKのまま本番化してよいのか分からない」「権限、監視、評価を後付けすると破綻しそう」と感じる場面は多いはずです。

そこで注目されているのがAmazon Bedrock AgentCoreです。この記事では、Amazon Bedrock AgentCoreとは何かを公式ドキュメントとAWSの一次情報をもとに整理し、Managed HarnessとRuntimeの違い、始め方5ステップ、運用で外しやすいポイントまでまとめます。

Amazon Bedrock AgentCoreとは

Amazon Bedrock AgentCoreとは、AWS上でAIエージェントを安全にデプロイし、実行し、監視し、評価するための基盤群です。単なるSDKではなく、Runtime、Gateway、Memory、Observability、Evaluationsなどをまとめて扱える点が特徴です。

AWSのQuickstartでは、AgentCore CLIを使って「作成 → ローカル検証 → デプロイ → invoke」まで進める流れが示されています。さらに2026年4月のアップデートで、Managed Harnessが公開プレビューとなり、オーケストレーションコードを書かずにエージェントを動かす選択肢が増えました。

まず押さえるべき構成要素

機能	何をするか	向いている使い方
Runtime	エージェントをAWS上で実行する本番エンドポイント	既存フレームワークを維持して本番化したい
Managed Harness	モデル、ツール、メモリを設定してオーケストレーション込みで実行	PoCを最短で立ち上げたい
Gateway	外部APIやMCPサーバーへの接続を統制する	ツール実行権限を中央管理したい
Memory	短期・長期の会話記憶を保持する	継続会話や業務文脈を持たせたい
Observability	CloudWatchベースでログ、トレース、メトリクスを見る	本番障害やツール失敗を追いたい
Evaluations	品質、安全性、ツール選択などを継続評価する	本番運用品質を数値で監視したい

2026年2月24日には、Amazon Bedrock Responses APIがAgentCore Gatewayと連携し、サーバーサイドでのツール実行に対応しました。これにより、クライアント側でツール呼び出しループを組む負担を減らしやすくなっています。

Managed HarnessとCode-based Runtimeの違い

観点	Managed Harness	Code-based Runtime
立ち上げ速度	速い。設定中心で開始できる	やや遅い。エージェントコードが必要
制御の細かさ	中程度。抽象化が強い	高い。既存コードをそのまま持ち込みやすい
向くフェーズ	PoC、初期検証、社内デモ	本番運用、既存資産移行、複雑な業務フロー
フレームワーク依存	薄い	Strands、LangGraph、Google ADK、OpenAI Agents SDKを使いやすい
典型的な失敗	プレビュー機能前提で本番要件を早く積みすぎる	ローカルコードのまま監視・評価設計を後回しにする

判断基準はシンプルです。「今すぐ試す」ならHarness、「既存実装を持ち込んで本番に載せる」ならRuntimeです。なお、AWSのQuickstartはCode-based Runtime寄りに書かれている一方、2026年4月22日の発表ではHarnessが「最速で試作する道」として位置付けられています。

5ステップで始める手順

1. AgentCore CLIを入れる

Code-basedでもHarnessでも、入口はCLIです。Node.js 20以上とPython 3.10以上を先に確認してください。

npm install -g @aws/agentcore
agentcore --version

# Harnessなどプレビュー機能を試す場合
npm install -g @aws/agentcore@preview

2. プロジェクトを作る

公式Quickstartでは、作成時にフレームワーク、モデル提供元、メモリ、ビルド方式を選びます。OpenAI Agents SDKやGoogle ADKを前提にしていても、AgentCore上へ載せる土台をここで作れます。

agentcore create 
  --name MyAgent 
  --framework Strands 
  --model-provider Bedrock 
  --memory none 
  --build CodeZip

フレームワーク選定で迷うなら、比較記事のAWS Strands / OpenAI Agents SDK / Bedrock AgentCore比較も併読すると整理しやすいです。

3. ローカルで挙動を見る

agentcore dev でローカルサーバーとインスペクタを起動し、トレースやツール呼び出しを観察します。ここでツール説明が曖昧だと、後の本番でも誤ったツール選択が出やすいです。

cd MyAgent
agentcore dev --no-browser

4. 運用機能を先に足す

本番直前ではなく、PoC段階でMemory、Gateway、Evaluatorの設計だけは入れておく方が安全です。

agentcore add memory
agentcore add gateway
agentcore add evaluator
agentcore deploy --plan

AgentCore Evaluationsは2026年3月にGAとなり、AWSのリリースノートでは13種類の組み込みEvaluatorとGround Truth、カスタムEvaluatorが案内されています。

5. デプロイしてCloudWatchで見る

デプロイ後は、レスポンスの正しさだけでなく、ツール選択の妥当性、危険な応答、レイテンシ、失敗率まで追ってください。CloudWatchベースの可観測性に寄せられるため、既存のAWS運用と接続しやすいのがAgentCoreの強みです。

agentcore deploy
agentcore status
agentcore invoke --prompt "Hello, what can you do?"

運用で外しやすい3つの論点

1. ツール接続をコードに直書きする

2026年2月24日のAWS発表では、AgentCore GatewayをBedrock Responses APIに接続し、サーバー側でツール実行まで回せるようになりました。API鍵や接続先ルールをアプリ側に散らすより、Gateway経由で統制した方が後から監査しやすいです。

2. 評価を本番後まで先送りする

AgentCore Evaluationsは、正確性、Helpfulness、安全性、ツール選択精度などを継続評価できます。ここを入れないと、「回答は動くが、役に立つか」「ツール引数は正しいか」が追えません。評価系の考え方はLangfuseの観測・評価ガイドやInspect AIの評価ガイドとも相性が良いです。

3. セキュリティ境界を曖昧にする

Harnessはセッションごとに隔離環境を使える一方、実際の権限、ネットワーク、ツール到達性は個別設計が必要です。特にMCPや外部APIをつなぐ場合は、MCPサーバーの脆弱性対策も合わせて確認してください。

AgentCoreが向くケースと向かないケース

ケース	向き/不向き	理由
AWS中心で本番運用したい	向く	CloudWatch、IAM、VPC、Gatewayと接続しやすい
まず数日でPoCを見せたい	向く	Managed Harnessで立ち上げを短縮できる
OpenAI Agents SDK資産を残したい	向く	Quickstart上でOpenAI Agents SDKも選択肢に入っている
AWS依存を極力減らしたい	やや不向き	運用価値は大きいが、観測や権限設計がAWS寄りになる
単発スクリプトの社内自動化だけで十分	やや不向き	AgentCoreの運用機能を使い切れずオーバースペックになりやすい

よくある失敗と対策

失敗: Harnessを便利だからと本番前提で使い始め、プレビュー依存部分が増える
対策: PoC成功後にRuntimeへ移す境界を最初に決める
失敗: AgentCoreに載せた時点で品質保証まで終わったと思う
対策: EvaluationsとCloudWatchアラートを必ずセットで入れる
失敗: MCPや外部APIの権限をアプリ設定に散らす
対策: GatewayとIAM前提で接続点を絞る
失敗: 既存LangGraph/OpenAI Agents実装を全部作り直そうとする
対策: まずRuntimeへ持ち込める最小単位から載せ替える

FAQ

Q1. Amazon Bedrock AgentCoreとは結局何ですか？

AWS上でAIエージェントを実行、接続、観測、評価するための基盤群です。単なるSDKではなく、Runtime、Gateway、Memory、Observability、Evaluationsまで含みます。

Q2. Managed HarnessとRuntimeはどちらから始めるべきですか？

PoCを急ぐならManaged Harness、本番に近い構成で始めたいならRuntimeです。既存コード資産があるならRuntimeの方が移行しやすいです。

Q3. OpenAI Agents SDKやGoogle ADKを使っていてもAgentCoreに載せられますか？

はい。AWSのQuickstartでは、フレームワーク選択肢としてStrands、LangGraph、Google ADK、OpenAI Agents SDKが案内されています。

Q4. AgentCore Evaluationsでは何を見られますか？

正確性、Helpfulness、安全性、タスク成功、ツール選択などです。2026年3月のリリースノートでは13種類の組み込みEvaluatorが案内されています。

Q5. Gatewayは必須ですか？

必須ではありませんが、本番ではほぼ必須に近いです。外部APIやMCPサーバーを安全に管理し、サーバーサイド実行に寄せやすくなります。

Q6. 料金面で最初に見るべき点は何ですか？

CLIやHarness自体の追加料金説明だけで安心せず、実際にはモデル推論、周辺AWSリソース、ログ保管、評価実行のコストを分けて見積もるのが安全です。料金の最終判断は必ず最新のAWS公式ページで確認してください。

まとめ

Amazon Bedrock AgentCoreは、AIエージェントをAWS上で本番運用したいチームにとって、かなり実務寄りの選択肢です。特に2026年2月〜5月の更新で、Harness、Gateway、Evaluations、ファイルシステム連携が強化され、PoCから運用までの線が太くなりました。

最初の1週間はHarnessかRuntimeのどちらで始めるかを決める
その次にGatewayとEvaluationsを先回りで組み込む
本番前にCloudWatch上の監視項目を固定する

あわせて読みたい:

参考・一次情報

Need help moving from reading to rollout?

この記事を読んで導入イメージが固まってきた方へ

Uravationでは、AIエージェントの要件整理、PoC設計、社内導入、研修まで一気通貫で支援しています。

30分無料相談を予約支援実績を見る

※ 本記事の情報は2026年5月時点のものです。サービスの料金・仕様は変更される可能性があります。最新情報は各サービスの公式サイトをご確認ください。