Bedrock AgentCore の「Harness」は便利だが自由が失われる — 実体を検証した

Amazon Bedrock AgentCoreを使ったエージェント基盤の構築では、「Harness」という機能を使うと、エージェントループの実装をほとんど書かずにRuntimeへ組み込むことができます。便利な反面、内部で何が起きているのかが見えづらく、カスタマイズの自由度に影響が出ないか気になっていたため、実際に構築しながら実体を確認しました。

今回はHarnessの正体と、コンソールとCLIでの作成方法による違い、そして私たちが実案件でどう役割分担を設計したかをまとめます。

Harnessとは何か

Harnessは、設定を行うだけでエージェントループをAgentCore Runtimeに埋め込んでくれる機能です。本来であればエージェントが「考えて、ツールを呼んで、結果を受け取って、また考える」というループを自前で実装する必要がありますが、Harnessを使うとこの部分をあらかじめ用意された仕組みに任せられます。

実体はstrands agents

検証の結果、Harnessの実体はstrands agents（stream_async）であることを確認しました。つまりHarnessは、strands agentsのエージェントループをAgentCore向けにラップして提供しているものだと理解できます。

コンソール作成とCLI作成の違い

ここで注意が必要なのは、コンソール（GUI）で作成したHarnessは、後からコードに変換することができないという点です。この点はAWS Summitの場で、AWS側の担当者に直接確認しています。一方、CLIで作成したHarnessであればコードへの変換が可能です。試作段階ではコンソールで手早く動かし、本番に近づけていく段階ではCLIで作成する、という使い分けが必要になります。

役割分担の考え方

Harnessは便利である一方、内部の挙動が隠蔽されるため、ブラックボックス化しやすい面があります。特にツールの呼び出し周りを細かく調整したい場合、Harnessに任せるよりも、Runtime内に直接関数を書いた方が試行錯誤しやすいというのが私たちの実感です。

関連する取り組みとして、社内では以前、Flask＋Claude CLIでエージェントループを全て自前で担う構成を採用していましたが、その後Runtime上でagent.pyが独自のループ（for step in range(30)）を持つ構成に移行しました。この移行にあわせて、モデルはClaude、ループとツール実行はHarness、実行環境はRuntime、会話履歴と長期記憶はMemory、という形で役割を分担する設計にしています。

まとめ

AgentCoreのHarnessは、エージェントループの実装コストを大きく下げてくれる一方、実体はstrands agentsであり、コンソール作成では後からコード化できないという制約があります。ツール周りを細かく作り込みたい案件では、Harnessに任せきりにするのではなく、Runtime・Memoryとの役割分担を意識した設計が有効だと考えています。

※ 本記事の検証は2026年7月時点のものです。