はじめに
今さらながら、AgentCore Harnessというサービスの存在を知った。AgentCore Runtimeは知っていたものの、HarnessはRuntimeと何が違うのだろう。設定だけでどこまでエージェントを作れるのかも気になり、実際に試してみることにした。
AgentCore Runtimeは、エージェントを動かす実行環境を提供する。Runtimeでエージェントを作るときは、Strands Agentsなどのフレームワークを使って、モデル呼び出しやツール実行を含む処理を自分のコードに組み立てる。
一方のAgentCore Harnessは、エージェントの実行ループをマネージドで提供する。モデル、指示、ツールを設定すると、モデルがツールを選び、ツールの結果を受け取って回答する流れをHarnessが実行する。HarnessはAgentCore Runtime上で動く設定ベースのインターフェースだ。HarnessとRuntimeの比較
今回は、計算を依頼するとシェルを使うHarnessを作り、ツール呼び出しと実行結果を確認する。Runtimeでコードを書く場合との違いも、実際に触った範囲と公式ドキュメントをもとに見ていく。
検証環境
| 項目 | 値 |
|---|---|
| 検証日 | 2026-09-24 |
| OS | macOS |
| Node.js | v23.11.0 |
| AgentCore CLI | 0.30.0 |
| AWSリージョン | ap-northeast-1 |
| モデル | Claude Sonnet 4.6 |
| 推論プロファイル | jp.anthropic.claude-sonnet-4-6 |
| API形式 | Converse Stream（Harnessのデフォルト） |
| Harnessの上限 | 3 iterations、2,048 tokens、300秒 |
初回デプロイ時にはCDK環境のBootstrapが必要だった。CLIの確認に従って東京リージョンへBootstrapを行い、その後Harnessをデプロイした。アプリの実行ループはコードなしで用意できるが、AWS認証、権限、初回のデプロイ準備は必要になる。
作ったもの
モデルに「計算が必要なときはシェルを使う」と指示し、組み込みの shell ツールを使えるようにした。生成されたHarnessアプリは次の2ファイルだった。
app/CalculatorHarness/
├── harness.json
└── system-prompt.md
Harnessのエージェントコードである main.py はない。今回のHarness用アプリで自分が書いたPythonコードは0行で、モデルとシェルの間をつなぐループも実装していない。設定とプロンプトだけで動くのか、と実際に触ってみて驚いた。
このモデルとツールの往復を、自分で書いたエージェントループで制御しなくてよい。HarnessはStrands Agentsを基盤に、モデル、指示、ツール、実行制限などの設定からエージェントを動かす。AgentCore Harnessの概要
Harnessを作成する
AWS認証情報を利用環境に合わせて設定し、デプロイ先を東京リージョンにした。AgentCore CLIで空のプロジェクトを作り、Harnessを追加した。
npm install -g @aws/agentcore@0.30.0
agentcore create --project-name HarnessTrial --no-agent
cd HarnessTrial
agentcore add harness \
--name CalculatorHarness \
--model-provider bedrock \
--model-id jp.anthropic.claude-sonnet-4-6 \
--system-prompt "You are a calculator assistant. Use the shell tool to calculate arithmetic and show the result." \
--allowed-tools shell \
--max-iterations 3 \
--max-tokens 2048 \
--timeout 300
agentcore deploy
Harnessの構成は app/CalculatorHarness/harness.json に保存される。今回の設定では、モデル、システムプロンプト、許可するツール、実行上限を指定した。独自のPythonコードやツールループは追加していない。
生成された設定の主な項目は次のとおりだ。shell はHarnessの組み込みツールなので、ツール本体をPythonで定義する必要もなかった。
{
"name": "CalculatorHarness",
"model": {
"provider": "bedrock",
"modelId": "jp.anthropic.claude-sonnet-4-6"
},
"systemPrompt": "You are a calculator assistant. Use the shell tool to calculate arithmetic and show the result.",
"tools": [],
"allowedTools": ["shell"],
"maxIterations": 3,
"maxTokens": 2048,
"timeoutSeconds": 300
}
デプロイ後、次の依頼を送った。
agentcore invoke \
--harness CalculatorHarness \
--session-id "$(uuidgen)" \
--verbose --json \
"Use the shell tool to calculate (35000 * 3) * 0.9. Return the exact command and result."
--verbose --json を付けると、ストリーミング応答に含まれるツール呼び出しも確認できる。
実行結果
Harnessはシェルを2回呼び出した。
-
最初のツール呼び出しでは
bcを使おうとした。echo "$(( 35000 * 3 )) * 0.9" | bc -l実行環境に
bcがなく、終了コード127で失敗した。 -
モデルはその結果を受け取り、Pythonに切り替えた。
python3 -c "print((35000 * 3) * 0.9)"標準出力は
94500.0、終了コードは0だった。
最終回答には、35,000 × 3 = 105,000、105,000 × 0.9 = 94,500 と計算過程が示された。
最初の bc は実行環境になく失敗した。すると、その結果を受け取ったモデルがPythonを使う方法に切り替えた。再試行の処理は自分で書いていない。エラーを見てモデルが次の手を考え、ツールを呼び直すところまで任せられるので、エージェントの初期実装の手間を抑えられる点が非常に良いと感じた。
Runtimeでコードを書く場合との違い
AgentCore Runtimeは実行環境を提供し、エージェントのロジックは開発者がコードで持つ。Harnessではマネージドのエージェントループが用意され、モデルやツールを設定で指定する。公式の比較
| AgentCore Harness | AgentCore Runtime上のコードベースエージェント | |
|---|---|---|
| エージェントのループ | Harnessが実行 | アプリ側で実装 |
| 主な設定場所 |
harness.json と指示ファイル |
エージェントのソースコードと依存関係 |
| ツール連携 | 組み込みツール、MCP、Gatewayなどを設定 | フレームワークやAgentCore SDKから連携 |
| 処理の変更 | 設定を変更 | コードを変更 |
| 制御の自由度 | Harnessが提供するモデル駆動ループ | 独自フローやフレームワークを選べる |
Runtimeでも、フレームワークを使えばエントリポイント自体は短く書ける。たとえばAWSのStrands Agents向けサンプルでは、AgentCore RuntimeのエントリポイントからStrandsのエージェントを呼び出す。Runtimeのコードベースエージェント例
Harnessの利点は、どの構成でも必ずコード行数が少なくなることではない。標準的なモデル駆動ループを使うときに、エージェントの起動処理、ツール実行、ツール結果を戻す処理を自分で接続しなくてよいことだ。独自のワークフローや制御フローを細かく実装したい場合は、Runtime上でコードを書く方法が向いている。
設定から始めて、コードによる拡張が必要になった場合は、HarnessをStrands Agentsのコードへエクスポートできる。Harnessのエクスポート
まとめ
AgentCore Harnessでは、モデル、指示、ツールを設定して、コードベースのエージェントループを自分で実装せずにエージェントを動かせた。今回の計算依頼では、シェル実行が一度失敗した後、モデルがエラーを読み取ってPythonで再試行し、結果を返した。Pythonコード0行でここまで動いたのは、素直にすごいと思った。
独自の制御フローを細かく実装する必要がない、シンプルなエージェントアプリならAgentCore Harnessは非常に良さそうだと感じた。標準的なツール利用を早く試すときはHarnessから始め、独自の制御フローが必要になったらRuntime上でコードを書く、という使い分けができそうだ。