はじめに
Amazon Bedrock AgentCore に「アイデアから動くエージェントまで最短で到達する」ための新機能群がまとめて発表されました。
中でも目を引くのは、オーケストレーションコードを一切書かずに config だけでエージェントを起動できる Managed Harness です。
これまで AgentCore Runtime に乗せるには、Strands なり LangGraph なりで自分で「モデル呼び出し → ツール選択 → 結果の戻し → コンテキスト管理」のループを書く必要がありました。
新しい Managed Harness はこのループを丸ごとマネージドにしてくれるので、harness.json の中身を書き換えるだけでモデルやツールを差し替えられるようになるとのことです。
そのため、インフラエンジニアでちょっと、Strands や LangGraph といった学習コストが高いなーと感じていた方には向いていそうな機能に感じます。
忙しい人のために要約
- Managed Harness（プレビュー） が追加。モデル / システムプロンプト / ツールを config で宣言するだけで、エージェントループ・microVM・ファイルシステム・シェルまで AWS 側がマネージドで用意してくれる
-
AgentCore CLI（
npm install -g @aws/agentcore）が GA。agentcore create→agentcore dev→agentcore deploy→agentcore invokeの4コマンドでデプロイから呼び出しまで完結する - Coding Assistants 向け Skills も提供開始。Kiro はすでに対応済み、Claude Code / Codex / Cursor も近日対応予定。
- ハーネスや CLI、Skills の追加料金はかからず、内部で動く AgentCore 機能の従量課金のみ
AgentCore Managed Harness とは
エージェントは結局のところ「モデルを呼ぶ → ツールを選ぶ → 結果を戻す → コンテキストを管理する → エラー回復する」というループなどで動きます。
これを動かすには、コンピュート、サンドボックス、ツール接続、ストレージ、メモリ、ID、可観測性といったインフラが必要で、これらをひっくるめて agent harness と呼ぶようです。
Managed Harness は、このハーネスを AWS 側でマネージドに用意してくれる仕組みで、開発者は「どのモデルを使うか」「どんなシステムプロンプトを与えるか」「どのツールを呼ばせるか」を宣言するだけで済みます。
ベースは AWS のオープンソースエージェントフレームワーク Strands Agents になっているとのことです。
何がうれしいのか
-
config 変更だけでモデル / ツールを差し替えられる: 「やってみる」で詳しく説明しますが、json ファイルを編集するだけで差し替えれるのが大きなポイント
-
ループを書かずに済む: オーケストレーション層（モデル呼び出し / ツール選択 / 結果戻し / コンテキスト管理 / エラー回復）が完全にマネージドなので、Strands や LangGraph を直接触らずにエージェントを立ち上げられる
-
セッション永続化で「中断と再開」が成立する: ファイルシステムが永続化されるので、エージェントが作業の途中で停止しても、同じ
runtimeSessionIdで再呼び出しすればその続きから再開可能 -
CLI が「ローカル → 本番」を1本のワークフローで貫通する: AgentCore CLI は内部で AWS CDK を使って CloudFormation リソースをプロビジョニングします。
agentcore devでローカル開発サーバを立てて Web UI で会話を確認し、納得したらagentcore deployで本番に上げる、という流れをそのまま回すことが可能。(Terraform 対応も近日提供予定との)
やってみた
ここでは Managed Harness を CLI で立ち上げて、AWSのサービス、イベントについて回答するエージェントを作成してみました。
CLI のインストール
Node.js 20 以上が必要です。プレビュー機能（Managed Harness）を使うので、@preview チャネルを指定します。
# プレビューチャネルでインストール
npm install -g @aws/agentcore@preview
# バージョン確認
agentcore --version
後は、AWS 側の準備として、プレビュー対応リージョン（バージニア北部 / オレゴン / フランクフルト / シドニー）のいずれかに対する認証情報を、AWS CLI などで設定しておきましょうね。
プロジェクトを作成する
agentcore create
対話ウィザードで以下を聞かれるので、Project type で harness を選び次のように入力および選択します。
| 項目 | 入力もしくは選択 |
|---|---|
| Project name | 例: MyResearchAgent と入力 |
| Project type |
Harness (recommended) を選択 |
| Harness name | 例: MyHarness と入力 |
| Model provider |
Amazon Bedrock を選択 |
| Environment |
Default Environment を選択 |
| Memory |
Enable を選択 |
| Advanced settings | ここでは一旦何も選択しない |
ウィザードが終わると、こんなディレクトリ構成のプロジェクトができあがりました。
ポイントは app/MyHarness/ の配下が Python コードではなく config ファイルだけという点です。コードを書かずにエージェントが定義されています。
harness.json
system-prompt.md
ツールを追加する
ブラウザツールを追加してみます。
cd MyResearchAgent
agentcore add tool \
--harness MyHarness \
--type agentcore_browser \
--name browser
次の通り、harness.json の tools セクションにブラウザツールが追加されました。
リモート MCP サーバを足したいときも、同様に CLI から追加できます。
# リモート MCP サーバを追加
agentcore add tool --harness MyHarness --type remote_mcp \
--name exa --url https://knowledge-mcp.global.api.aws
次の通り、harness.json の tools セクションにリモート MCP サーバが追加されました。
システムプロントを書き換え
system-prompt.md を次の通り適当に書き換えます。
あなたは、AWS のサービスやイベントについての質問に答える、AWS エキスパートのアシスタントです。あなたは、AWS のサービスやイベントについての豊富な知識を持っており、ユーザーからの質問に対して正確で詳細な回答を提供することが求められます。あなたは、AWS のサービスやイベントについての最新の情報を常に把握しており、ユーザーからの質問に対して迅速かつ正確な回答を提供することが求められます。
デプロイする
agentcore deploy
CLI が裏で CDK を呼び、CloudFormation で AgentCore Runtime のエンドポイントや Memory などを一気に作ってくれます。
一応 AWSマネージメントコンソールからも以下の通り作成されていることも確認しておきます。
Harness の画面をもう少し詳しくみていくと、次のような項目が設定できるんですね。
- Model and system prompt
- Memory
- Tools
- Skills
- Advanced configurations
- Inbound Auth
- オブザーバビリティ
- ログの配信とトレース
- タグ
Skills の項目も気になりますが、挙動がつかみきれなかったので今後別記事で改めて検証してみたいと思います。
呼び出してみる
セッション ID を渡して呼び出します。（同じセッション ID を使い回すと、同じ microVM で会話を計測することが可能です）
agentcore invoke --harness MyHarness \
--session-id "$(uuidgen)" \
"AWS Summit Japan 2026 の詳細を教えて"
レスポンスはストリームで返ってきます。先ほど設定したブラウザツールと AWS の knowledge-mcp(exa_aws___search_documentation) が動いて調査してくれている様子が伺えますね。
(一部回答省略)
同じ --session-id で次のメッセージを送ると、同じファイルシステム上で会話の続きを動かせます。
agentcore invoke --harness MyHarness \
--session-id "FF783DE8-4465-4FD1-B669-901DE5D1501C" \
"募集はいつからですか？"
以前のセッションの内容が引き継がれているようですね。
モデルを差し替えてみる
ここでは Anthropic Sonnet 4.6 から Amazon Nova 2 Lite へ切り替えてみます。記事の冒頭で触れた通り config 変更だけでモデルを差し替えられます。
harness.json の modelId の行をこう書き換えるだけです。
"model": {
"provider": "bedrock",
- "modelId": "global.anthropic.claude-sonnet-4-6"
+ "modelId": "us.amazon.nova-2-lite-v1:0"
},
再デプロイする
agentcore deploy で再度反映します。
agentcore deploy
なお、agentcore deploy --diff / --dry-run は CDK / CloudFormation の差分しかみなさそうなので、harness.json の中身（modelId や tools 等）を書き換えても "There were no differences" となるため、harness 本体の設定確認は git diff app/MyHarness/harness.json や agentcore validate で済ませた方が確実そうです。
同じ質問を投げ直す
先ほどと同じ AWS Summit 2026 の質問を投げて、Nova 2 Lite 側で処理されていることを確認します。
agentcore invoke --harness MyHarness \
--session-id "$(uuidgen)" \
"AWS Summit Japan 2026 の詳細を教えて"
(一部回答省略)
モデル差し替え前後で、回答の長さ・トーン・使うツールの選び方が変わるのが面白いポイントですね。(Nova 2 Lite ではブラウザは使ってくれなかったようです)
おまけ: 呼び出しごとの一発オーバーライド
harness.json を書き換えて deploy し直さなくても、agentcore invoke --model-id を渡せばその呼び出しだけ別モデルで試せます。harness は Nova 2 Lite のまま据え置いたうえで、その回だけ Sonnet 4.6 で同じ質問を投げる、みたいな A/B が再デプロイなしで回せます。
agentcore invoke --harness MyHarness \
--session-id "$(uuidgen)" \
--model-id global.anthropic.claude-sonnet-4-6 \
"AWS Summit Japan 2026 の詳細を教えて"
Skills について
Harness 設定画面で気になっていた「Skills」ですが、プレビュー段階ということもあり、harness.json に skills を足して --exec でスキル本体を microVM に書き込んでも、トレース上はスキルの description がシステムプロンプトに注入されないままで、期待通りの挙動をつかみきれませんでした。カスタムコンテナイメージにスキルを焼き込めればいいのか、別記事で改めて掘り下げたいと思います。
シーケンスでみる呼び出しの流れ
まとめ
- Managed Harness の登場で、AgentCore は「ループを書かずに config でエージェントを定義する」という選択肢を持つようになりました
- AgentCore CLI が
create→dev→deploy→invokeをひとつなぎで回せるので、プロトタイプから本番デプロイまでの摩擦がだいぶ減りそうです - ただし、Managed Harness は AWS がマネージドでやってくれる分カスタマイズ性が低いのでどこまで利用するのかがポイントにもなりそうです