Amazon Bedrock AgentCore Harness：概要、仕組み、主要機能

デモで動くAIエージェントを構築するのは比較的簡単です。しかし、タスクを確実に実行し、ツールを使用し、コンテキストを管理し、本番環境で運用できるエージェントを構築することははるかに困難です。そこで登場するのがagent harnessです。

agent harnessは、モデルと、それが相互作用する必要のあるシステムとの間に位置します。LLMを機能するエージェントに変えるために必要なエージェントループ、ツール実行、コンテキスト、メモリ、サンドボックス化、その他のランタイムの関心事を管理します。

Amazon Bedrock AgentCore Harnessは、事前構築されたエージェントループを提供し、AgentCore Runtime内で動作するAWSの独自マネージドサービスです。

このガイドでは、AgentCore Harnessの仕組み、AgentCore Runtimeとの違い、およびモデルサポート、コンテキスト管理、サンドボックス化、拡張性、デプロイメント、エージェントループの制御においてTrueForgeとどのように比較されるかを詳しく解説します。

AgentCore Harnessとは？

AgentCore Harnessは、Amazon Bedrock AgentCore内のマネージドagent harnessです。2026年4月にパブリックプレビューが開始され、現在は一般提供（GA）されています。オーケストレーションループはStrands Agentsによって提供されるため、構築するのではなく設定として記述します。

実際の形式としては、モデル、システムプロンプト、一連のツール、メモリ設定、実行制限を構成として宣言します。AWSがループを実行します。通常であればコードの修正と再デプロイを伴うような変更の大部分が、単一の設定フィールドの更新で済みます。あるモデルプロバイダーから別のモデルプロバイダーへの切り替えもフィールド1つです。ツールの追加もフィールド1つです。

すべてのハーネスセッションはデフォルトでステートフルであり、分離されたmicroVM内で実行されます。エージェントは独自のファイルシステムとシェルを取得するため、毎回ゼロからスタートするのではなく、ファイルを書き込み、コードを実行し、セッション間でメモリやファイルを保持できます。

2つのAPI呼び出しだけで実行を開始できます。CreateHarnessでエージェントを定義し、InvokeHarnessで実行します。curlコマンドよりもクリック操作を好む場合は、AgentCore CLIパスやコンソールパスも利用できます。

AgentCore Harnessの仕組み

AgentCore Harnessは、エージェント実行への設定駆動型アプローチを中心に構築されています。

次のようなエージェントループを書く代わりに：

エージェントに必要なコンポーネントを定義し、ハーネスにループの管理を任せます。

ハイレベルで見ると、AgentCore Harnessは以下で構成されます：

• Model - 推論および生成のためにエージェントが使用するモデル
• Instructions - エージェントのシステムレベルの挙動および指示
• Tools - MCPサーバーやAgentCoreツールを含む、エージェントが呼び出せる機能
• Memory - 相互作用を跨いで保持できる状態
• Skills - エージェントに提供可能な追加の能力と指示
• Execution settings - エージェントの動作に関する制御設定

ハーネスは、実行中にこれらのコンポーネントを調整します。

例えば、エージェントがトピックを調査する必要がある場合、タスクについて推論し、ツールを呼び出して情報を取得し、その結果をコンテキストに組み込み、最終的な応答に達するまでループを継続できます。

この抽象化により、開発者はオーケストレーション層のあらゆる部分を自分たちで構築する必要がなくなります。

ただし、これは実行モデルが主にハーネスによって決定されることも意味します。基盤となるループを変更したり、カスタムのオーケストレーションロジックを導入したりする必要がある場合、ループ自体にアクセスできるオープンソースのハーネスを使用する場合よりも柔軟性が低下します。

ループを直接見ることはありません。それこそが製品の存在意義であり、同時に制限の主な原因でもあります。

何が同梱されているか？

マネージドハーネスは、コードを書くことなく広範な機能をカバーします：

モデル選択はBedrock、OpenAI、Gemini、LiteLLMに及び、セッションの途中でプロバイダーを切り替えることも可能です。組み込みシェルおよびfile_operationsツールは標準装備されており、Agent Skillsも同様です。メモリは短期および長期の両方の形式で提供され、後者にはセマンティック、要約、ユーザー嗜好、エピソードメモリが含まれ、アクターIDによるユーザーごとのスコープが設定されます。

その他のAgentCoreプリミティブは、SDKの呼び出しではなく設定としてプラグインできます：Gateway、Browser、Code Interpreter、リモートMCPサーバーツールなどです。ファイルシステムのオプションには、サービス管理されたセッションストレージ、EFSアクセスポイント、またはS3 Filesアクセスポイントが含まれます。

セキュリティ面では、インバウンド認証がIAM SigV4とOAuthをサポートし、アウトバウンド認証はIdentityトークンボルトを通じてOAuthトークンとAPIキーを処理します。また、VPCネットワーキングが利用可能な状態でセッションが分離されます。可観測性（Observability）、ストリーミング応答、バージョニング、エンドポイントのすべてがカスタムコードなしで機能します。

知っておくべき例外が1つあります：インラインツールおよびクライアントサイドツールについては、ハーネス上であっても依然として実装を記述して維持する必要があります。

AgentCore Harness vs AgentCore Runtime

これは多くの人がドキュメントを参照する比較ポイントであるため、正確に理解しておく価値があります。両者は同じ問題の異なる部分を解決するものであり、aws agentcore harnessはもう一方の上面に重ねられています。

AgentCore Harnessは、Runtime内部で動作するマネージド抽象化です。CloudTrailでも、ハーネスの操作はAWS::BedrockAgentCore::Runtimeの下に記録されます。これにより、実際の境界線がどこにあるかがわかります。

AgentCore Runtimeはサーバーレスホスティング環境です。任意のフレームワーク（またはフレームワークなし）で書かれたエージェントコードを持ち込み、AgentCore SDKのBedrockAgentCoreAppエントリーポイントでラップし、ARM64コンテナにパッケージ化してAmazon ECRにプッシュし、デプロイします。Runtimeは分離、スケーリング、セッション、認証制御、可観測性の配管を処理します。オーケストレーションループはあなたのものです。

ほぼすべての機能におけるパターンは同じです。ハーネス上ではコードなしの設定で行えます。Runtime上ではサポートされていますが、実装を維持するのはユーザーです。

AgentCore Harnessでできないこと

AWSは自社の機能グリッドでこれらの制限を公表しています。ハーネスでは以下の4つの機能が未サポートとしてマークされています：

エージェントフレームワークの選択不可。 ループはStrands Agentsを中心に構築されています。チームがすでにLangGraph、CrewAI、その他のフレームワーク上で構築している場合、そのコードを持ち込むことはできません。

エージェントループ以外のパターン不可。 グラフ型およびワークフロー型のアプリケーションは対象外です。パイプラインの1ステップのみがモデルを必要とし、残りが決定論的コードである場合、ハーネスにはそのワークフローを表現する手段がありません。

フック不可。 ループ内の特定のポイントに独自のロジックを注入することはできません。これにより、モデルがツール呼び出しを決定したときではなく、実行サイクルの正確な時点で実行する必要があるコンプライアンスチェックやビジネスルールなどのユースケースが除外されます。

双方向ストリーミング不可。 ハーネスは双方向ストリーミングをサポートしていないため、クライアントとエージェント間の継続的な双方向通信を必要とするアプリケーションが制限されます。

不足している機能というよりは設計上の決定である5つ目の項目があり、これは長時間の実行を伴うエージェントにとって特に重要です：コンテキスト処理で切り捨て（truncation）が使用される点です。

コンテキストウィンドウが満杯になると、古いコンテンツが削除されます。これによりエージェントはコンテキスト制限内に収まりますが、以前の情報が失われる可能性もあります。

代替アプローチは圧縮（compaction）です。古い履歴を構造化された記録に要約し、その要約を保持します。単に以前のターンを破棄するのではなく、エージェントは何が起こったかの凝縮されたバージョンを保持し、長時間の実行にわたって連続性を維持できるようにします。

短いサポートエージェントの場合、切り捨てで十分な場合があります。しかし、数時間に及ぶ調査や移行タスクでは、その違いがはるかに顕著になります。実行が長くなるにつれて、エージェントは過去のコンテキストが少ない状態で作業しなければならなくなります。

TrueForge：AgentCore Harnessへのオープンソース代替案

TrueForgeは、エージェントハーネスの問題に対して異なるアプローチをとります。固定されたマネージドオーケストレーションループを提供する代わりに、TrueForgeは独自のインフラストラクチャ上で実行できるMITライセンスのオープンソースエージェントハーネスです。

コアサーバーはオープンソースであるため、開発者はブラックボックスとして扱うのではなく、実行ループを検査および修正できます。TrueForgeはローカルで実行することも、Docker Composeで実行することも、Helmを使用してデプロイすることもできます。

これにより、トレードオフが大きく変わります。AgentCore Harnessでは、AWSがループと周囲のインフラストラクチャを管理してくれます。TrueForgeでは、エージェントが実際にどのように動作するかをより強力に制御できます。

独自のモデルとツールを持ち込む

TrueForgeはモデルニュートラルであり、OpenAI互換エンドポイントで動作します。基盤となるエージェント実装を変更することなく、目的のモデルプロバイダーやエンドポイントを指すようにハーネスを設定できます。

エージェントが使用するツールについても同様です。TrueForgeはMCPサーバーをサポートしており、エージェントを単一のマネージド実行環境に縛り付けることなく、独自のサンドボックスを持ち込むことができます。

これにより、ハーネス層がその下にあるモデルやインフラストラクチャから独立します：

モデル → TrueForge → MCP / ツール / サンドボックス

別のプロバイダーの周りにエージェントを再構築することなく、モデルエンドポイントを変更できます。

エージェントループを制御する

AgentCore Harnessとの最大の違いいの1つは、TrueForgeのループがオープンソースであることです。

これは、設定オプションとして利用できない挙動が必要な場合に、開発者がハーネスの実行処理方法を検査し、修正できることを意味します。

これは、エージェントが以下に関するカスタムロジックを必要とするときに役立ちます：

• ツールの実行
• 承認プロセス
• コンテキスト管理
• サブエージェント
• サンドボックス化
• 実行ポリシー
• カスタムオーケストレーション

マネージドハーネスが特定のフックや設定オプションを公開するのを待つ必要はなく、基盤となる実装を直接変更できます。

コンテキスト管理

TrueForgeはコンテキスト管理に関しても異なるアプローチを採用しています。

コンテキストが大きくなりすぎたときに切り捨てだけに頼るのではなく、TrueForgeは圧縮（compaction）とともに、遅延ツールロード、Code Mode、レスポンスオフロードなどの技術を使用します。

目的は、エージェントが作業を続けるために必要な情報を保持しながら、アクティブな会話に残す必要のあるコンテキストの量を減らすことです。

長時間の実行を行うエージェントにとって、この違いは極めて重要です。大規模なコードベースや複数ステップの調査タスクに取り組むエージェントは、膨大な量のツール出力や中間コンテキストを蓄積する可能性があります。単に古いメッセージを削除すると情報が利用できなくなりますが、圧縮を使用することで凝縮された表現を保持することができます。

ツールとしてのサンドボックス

TrueForgeはサンドボックスの扱いも異なります。

AgentCore Harnessでは、セッションは分離されたmicroVM内で実行されます。一方、TrueForgeはサンドボックスをエージェントが実際にコードを実行する必要があるときにプロビジョニングできるツールとして扱います。

つまり、サンドボックスがエージェントセッション全体の環境である必要はありません。必要なときにエージェントが呼び出せるもう1つの機能となります。

本番環境向けAIエージェントのためのランタイム層

モデル、MCPツール、サンドボックス化、承認、可観測性のためのオープンソースランタイムを使用して、本番エージェントを実行します。

TrueForgeを探索する

GitHubで見る

TrueForgeの適用シーン

この違いは、最終的には制御の度合いに集約されます。

AgentCore Harnessは、自らオーケストレーションループを構築することなく、エージェントを実行するための管理されたルートを開発者に提供するように設計されています。一方、TrueForgeは、ハーネス自体をカスタマイズ可能にし、特定のクラウドプロバイダーやエージェントフレームワークから独立させたい開発者向けに設計されています。

そのため、エージェントループを制御したり、コンテキストの管理方法を変更したり、独自のモデルエンドポイントを選択したり、自社のインフラ上でハーネスを実行したりする必要がある場合には、TrueForgeが特に適しています。

npx @truefoundry/trueforgeを実行すれば、約1分でエージェントを起動できます。または、TrueForgeが長時間の実行でどのようにコンテキストを処理するかをご覧ください。

よくある質問（FAQ）

Q: AgentCore Harnessとは何ですか？

A: AgentCore Harnessは、Amazon Bedrock AgentCore内のAWSマネージド型エージェントハーネスで、2026年時点で一般提供（GA）されています。オーケストレーションループはStrands Agentsによって提供・駆動されるため、自分でループを書くのではなく、モデル、システムプロンプト、ツール、メモリ、実行制限を含む設定としてエージェントを宣言します。セッションはデフォルトでステートフルであり、独自のファイルシステムとシェルを持つ分離されたmicroVM内で実行されます。

Q: AgentCore HarnessとAgentCore Runtimeの違いは何ですか？

A: Runtimeはサーバーレスホスティングであり、ハーネスはその内部で動作するマネージド型ループです。Runtimeを使用する場合、任意のフレームワークで独自のエージェントコードを作成し、ARM64コンテナとしてパッケージ化してECRにプッシュし、オーケストレーション自体を自分で記述します。ハーネスを使用する場合、コンテナも書くべきループも存在しません。AWSはハーネス操作をAWS::BedrockAgentCore::Runtimeの下にログ記録しますが、これが両者の関係性を示す最も明確なシグナルです。

Q: AgentCoreが提供するエージェントハーネスでLangGraphやその他のフレームワークを使用できますか？

A: ハーネス上では使用できません。ループがStrands Agentsであるため、AWSはエージェントフレームワークの選択を未サポートとしてマークしています。AgentCore Runtime上であれば、Runtimeが設計上フレームワークアグノスティックであるため、LangGraph、CrewAI、またはカスタムコードを実行できますが、ハーネスに移行する場合はそのコードを放棄することを意味します。これが、特定のフレームワークを採用しているチームがRuntimeにとどまる主な理由です。

Q: 自分のVPC内やオンプレミスでエージェントハーネスを実行できますか？

A: セルフホスト型のハーネスを使用すれば可能です。TrueForgeは、ローカル環境での単一のnpxコマンド、またはPostgres、Redis、レプリカ、OIDCログインを備えたチームデプロイメント用のDocker ComposeやHelmを介して実行できます。TrueFoundryのマネージドプラットフォームもセルフホスト、オンプレミス、エアギャップ環境、またはハイブリッドで動作するため、データが自社ドメイン外に出ることはありません。AgentCore HarnessはVPCネットワーキングをサポートしていますが、実行環境はAWS上となります。

Q: 多数のエージェントにわたるモデルやMCPサーバーをどのようにガバナンスすればよいですか？

A: チームごとのキー管理が限界に達した後は、ゲートウェイ層を通じて管理します。TrueFoundryのAI Gatewayは、1,000以上のLLMを1つのOpenAI互換APIの背後に配置し、単一のvCPU上で約3〜4 msの追加レイテンシと350+ RPSを実現します。RBAC、予算設定、ガードレール、認証情報の自動回転に加え、Grafana、Datadog、PrometheusへのOpenTelemetryトレースを備えています。AgentCore、TrueForge、あるいはその他の基盤上のエージェントも、すべて同じ方法でガバナンスできます。

関連ドキュメント

• Agent Harness vs Agent Framework：実際の違いとは？：本記事の前提となるカテゴリ上の違いについて
• 2026年ベストAgent Harness：主要5オプションの比較：この分野における比較情報
• ベストオープンソースAgent Harness：マネージドを選択肢から除外する場合のオープンソースの選択肢
• Claude Managed Agentsの代替案：Anthropicのマネージドハーネスにおける同様の選択肢
• Amazon Bedrock Agents vs The Control Plane：より広いAWSアーキテクチャの疑問について

まとめ

AgentCore HarnessとTrueForgeは、AIエージェントの構築に対して根本的に異なるアプローチを採用しています。

AgentCore Harnessはエージェントループを抽象化します。モデル、指示、ツール、メモリ、その他の構成を定義すれば、AWSが実行を管理します。これにより、特にすでにAWSエコシステム内で構築を行っており、マネージドハーネスの制約に問題がない場合、エージェントの本番導入を簡素化できます。

TrueForgeは開発者の手に多くの制御権を委ねます。オープンソースであり、独自のインフラストラクチャ上で実行でき、カスタマイズのために基盤となるエージェントループを公開しています。モデルエンドポイント、MCPサーバー、サンドボックスを選択し、固定されたオーケストレーション層ではなく基礎としてハーネスを使用できます。

したがって、選択はどちらのハーネスがより多くの機能を備えているかというよりも、エージェントランタイムをどの程度制御したいかによります。

AWSにオーケストレーションとインフラストラクチャの管理を委ねたい場合は、AgentCore Harnessがその抽象化を提供します。ハーネス自体を検査、カスタマイズ、運用したい場合は、TrueForgeがオープンソースの選択肢を提供します。

エージェントインフラストラクチャを評価しているチームにとって重要な質問は、単にどのエージェントハーネスを使用すべきか？ということではありません。エージェントスタックのどの部分をプラットフォームに管理させ、どの部分を自分たちで制御したいか？という点です。

npx @truefoundry/trueforgeを実行すれば約1分でエージェントを起動できます。または、TrueForgeが長時間の実行でどのようにコンテキストを処理するかをご覧ください。