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

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

「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が公開プレビューとなり、オーケストレーションコードを書かずにエージェントを動かす選択肢が増えました。

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

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

Managed HarnessとCode-based Runtimeの違い

判断基準はシンプルです。「今すぐ試す」なら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が向くケースと向かないケース

よくある失敗と対策

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

他のエージェント実行基盤との使い分け

AgentCoreを選ぶかどうかは、単体の機能比較だけでは決められません。実際の選定では「自前でエージェント実行基盤を構築する」「他クラウドのマネージドなエージェント／ワークフロー基盤を使う」「AgentCoreに寄せる」という3つの選択肢を、自社の技術スタックと運用体制に照らして比べることになります。ここでは断定的な価格・性能の数値ではなく、判断軸ごとの一般的な傾向を整理します。具体的な料金・制限値は変動するため、必ずAWS公式ドキュメントで最新情報を確認してください。

選び方の考え方

大まかな目安として、すでにAWSを主軸に使っていて、運用の手離れを優先したいならAgentCoreが有力候補になります。マルチクラウドや特殊な実行要件があり、挙動を完全に自分で握りたい場合は自前構築が選択肢に入りますが、その分の運用コストを継続的に負担できるかを見極める必要があります。すでに別クラウドにデータと開発体制が集中しているなら、その環境のマネージド基盤を使うほうが移行摩擦は小さくなります。重要なのは「機能の多さ」ではなく、既存の技術資産・チームのスキル・運用に割けるリソースの3点で自社にフィットするかを判断することです。

本番導入前に確認すべき実務チェックリスト

PoCで動いたエージェントをそのまま本番に載せると、権限・コスト・ガバナンスの面で後から問題が表面化しがちです。ここでは、本番運用を前提にしたときに事前に設計・合意しておくべき実務項目を、観点ごとに分けて整理します。各項目の具体的な設定値や上限は環境やプランによって異なるため、数値はAWS公式ドキュメントで都度確認する前提で読んでください。

IAM・権限設計

• 最小権限の原則を徹底し、エージェントが触れるリソースを必要なものだけに絞る
• エージェントの実行ロールと、エージェントが呼び出す各ツール・外部連携の権限を分離して管理する
• 本番・検証・開発で環境ごとに権限境界を分け、検証用の広い権限が本番に紛れ込まないようにする

コスト管理

• モデル呼び出し・実行回数が増えるとコストが膨らむため、想定リクエスト量と上限を事前に見積もる
• 予算アラートや使用量モニタリングを設定し、暴走時に早期検知できる状態にする
• 不要なリトライやループでコールが膨張しないよう、失敗時の挙動を設計に織り込む

監視・ログ

• エージェントの入出力・ツール呼び出し・エラーを追跡できるログ設計にしておく
• 障害時に原因をたどれるよう、リクエスト単位で相関できる識別子を残す
• 異常な挙動（想定外のツール呼び出し・連続失敗）を検知するアラート条件を決める

データガバナンス

• エージェントが扱うデータの機密区分を整理し、扱ってよい範囲を明文化する
• 個人情報・社外秘がログやモデル入力に不用意に流れ込まないようマスキング方針を決める
• 保持期間・保存場所・アクセス権を、自社のコンプライアンス要件と突き合わせる

段階導入

• いきなり全社展開せず、限定ユースケース・限定ユーザーから始める
• 本番反映前にロールバック手順を用意し、問題時にすぐ戻せるようにする
• 初期は人によるレビューを挟み、安定を確認してから自動化の範囲を段階的に広げる

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公式ページで確認してください。

Managed Harnessの実行モデル詳細——microVMとstateful sessionの仕組み

GSCで「managed harness」「agentcore harness」と検索されているにもかかわらず、既存ドキュメントではHarnessが「コンフィグ中心で試作を早くする手段」としか説明されていないことが多いです。ここでは、Harnessが実際に何をしてくれるかを公式ドキュメント（2026年6月時点）に基づいて整理します。

Harnessが内部で引き受けていること

AgentCoreの公式ドキュメント「AgentCore harness」（docs.aws.amazon.com）によれば、Managed Harnessは以下を自動で管理します。

• エージェントループ: モデル呼び出し・ツール選択・結果フィードバック・コンテキスト管理・失敗処理をAgentCore側が担う。オーケストレーションコードを書く必要がない
• セキュアなmicroVM: セッションごとに独立したmicroVMが起動し、ファイルシステムとシェルが使える。各セッションは分離された実行環境で動く
• ステートフルなセッション管理: デフォルトでstateful。短期・長期メモリとファイルをセッション間で引き継ぐことができる
• インフラ一式: コンピュートのプロビジョニング、VPCネットワーキング、Identity、ObservabilityをAgentCoreが処理する

公式ドキュメントの表現をそのまま引くと「Every harness session is stateful by default and runs in a secure, isolated microVM per session」とあります。これがCode-based Runtimeとの最大の違いです。Runtimeは自分で書いたエージェントループを持ち込む場所ですが、Harnessはそのループを書かなくていい場所です。

対応モデルとプロバイダー

HarnessではAmazon Bedrock、OpenAI、Google Geminiのモデルをいずれも使えます。公式ドキュメントには「switch providers mid-session without losing context」と記載されており、セッション中のモデル切り替えが可能です。

Harnessに接続できるツール

Harnessは以下のツール接続経路を公式でサポートしています（2026年6月時点の公式ドキュメントより）。

また、シェルコマンドをモデルを通さずに直接セッション上で実行することもできます。公式ドキュメントは「no model reasoning, no token cost」と説明しており、環境セットアップや決定論的スクリプトをトークンコストなしで回せる点が特徴です。

Harnessのプレビュー状況と対応リージョン（2026年6月時点）

公式ドキュメントによれば、Managed HarnessはGA（一般提供）ではなくパブリックプレビューの状態です（2026年6月時点）。対応リージョンは以下の4つです。

• US West (Oregon)
• US East (N. Virginia)
• Asia Pacific (Sydney)
• Europe (Frankfurt)

HarnessへのアクセスにはpreviewチャンネルのCLIが必要です（npm install -g @aws/agentcore@preview）。また、Harness自体の追加料金はなく、実際に利用する個別のAgentCore機能分のみ課金される構造です（最新料金はAWSのAgentCore料金ページで確認してください）。Harnessが動くOSS基盤はStrands Agents（AWSが公開しているOSSフレームワーク）です。

本番運用を前提にした場合、Harnessのプレビュー依存部分が増えすぎないよう、PoC後の段階でCode-based Runtimeへ移行するタイミングを最初に設計しておくことが重要です。

AgentCore Observabilityの実装ガイド——CloudWatch連携と見えるメトリクス

「agentcore runtime observability」というクエリへの答えとして、ここではObservabilityの実際の設定手順と本番で見えるデータを整理します。公式ドキュメント（docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html）に基づく内容です。

AgentCore ObservabilityがCloudWatchで提供するデータ

AgentCore Observabilityは、テレメトリデータをOpenTelemetry（OTEL）互換フォーマットで出力します。これにより、既存の監視スタックとの統合が容易です。全データはAmazon CloudWatchに保存され、CloudWatchコンソール・AWS CLI・各言語SDKから参照できます。

デフォルトで収集されるメトリクスは以下のとおりです。

AgentCore Runtimeでデプロイされたエージェントには、CloudWatchコンソール上に専用のオブザーバビリティダッシュボードが提供されます。ダッシュボードには、トレースのビジュアライゼーション・カスタムスパンメトリクスのグラフ・エラー内訳が含まれます。

Observabilityの有効化手順（初回設定）

公式ドキュメント「Get started with AgentCore Observability」（docs.aws.amazon.com）によれば、初回だけAWSアカウント単位でCloudWatch Transaction Searchを有効化する必要があります。

# Transaction Searchを有効化（AWS CLIで実施・アカウント単位・初回のみ）
aws logs put-resource-policy 
  --policy-name MyResourcePolicy 
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Sid": "TransactionSearchXRayAccess",
      "Effect": "Allow",
      "Principal": {"Service": "xray.amazonaws.com"},
      "Action": "logs:PutLogEvents",
      "Resource": [
        "arn:aws:logs:REGION:ACCOUNT_ID:log-group:aws/spans:*"
      ]
    }]
  }'

# スパン送信先をCloudWatch Logsに変更
aws xray update-trace-segment-destination --destination CloudWatchLogs

CloudWatchコンソールから有効化する場合は、「CloudWatchコンソール → 設定 → X-Ray traces → Transaction Search → 有効化」の順で操作します。有効化後、スパンが検索可能になるまで最大10分かかります。

AgentCore CLIでデプロイしたエージェントの場合

AgentCore CLI（agentcore deploy）でデプロイしたエージェントは、Runtimeが自動でOpenTelemetry計装を適用するため、追加のOTELライブラリ設定は不要です。ログとトレースの確認はCLIから直接できます。

# 直近ログをストリーミング（直近30分のエラーに絞る場合）
agentcore logs --since 30m --level error

# トレース一覧の取得
agentcore traces list

# 特定トレースの詳細確認
agentcore traces get <trace-id>

非Runtimeデプロイのエージェントにトレースを付ける場合

AgentCore Runtimeを使わずに独自環境で動かしているエージェントは、OTELライブラリを手動で追加する必要があります。公式ではaws-opentelemetry-distro（ADOT）をrequirements.txtに追加し、利用フレームワークのインストルメンターを有効化する手順が案内されています（例: LangChainならopentelemetry-instrumentation-langchain）。

Observability活用のポイント

• 1%のトレースは無料でインデックス可能: Transaction Searchの初期サンプリングは1%から設定でき、本番の負荷を把握してから比率を上げる運用が安全です
• カスタムスパンの追加: デフォルトメトリクスに加えて、アプリケーションコードに独自のスパン・メトリクス・ログを追加することも可能です
• クロスアカウント監視: 公式ドキュメントによれば「Monitor AgentCore resources across accounts」機能が用意されており、複数アカウントにまたがるエージェント監視にも対応しています

まとめ

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

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

あわせて読みたい:

• OpenAI Agents SDKマルチエージェント実装ガイド
• OpenAI Apps SDK入門
• AWS Strands / OpenAI Agents SDK / Bedrock AgentCore比較

参考・一次情報

• AWS Docs: Get started with Amazon Bedrock AgentCore
• AWS Docs: Amazon Bedrock AgentCore Release Notes
• AWS What’s New: AgentCore adds new features to help developers build agents faster（2026年4月22日）
• AWS What’s New: Bedrock supports server-side tool execution with AgentCore Gateway（2026年2月24日）
• AWS News Blog: Introducing Amazon Bedrock AgentCore
• AWS News Blog: AgentCore adds quality evaluations and policy controls