6月21日、Janakiram MSVが「Why AWS AgentCore Harness Is A Big Deal For Enterprise Agents」と題した記事を公開した。AWSがエンタープライズ向けAIエージェントの「運用インフラ」をマネージドサービス化するAmazon Bedrock AgentCore Harnessを正式リリースしたことについて、その意義と競合との比較、ロックインの構造まで詳しく論じている。
2つのAPIコールでエージェントが立つ
6月18日のAWS New York Summitで、Amazon Bedrock AgentCore Harnessが正式にGAとなった。売り文句はシンプルで、エージェント開発を2つのAPIコールに集約するというものだ。
CreateHarness：エージェントを定義するInvokeHarness：エージェントを実行する
これだけで、プロダクショングレードのエージェントが数分で立ち上がる。
ラップトップ上でエージェントを動かすだけなら、開発者1人が午後の数時間で実現できる。問題はその先だ。複数ユーザーへのサービング、セッション間の分離、アイデンティティ管理、状態保持、スケーリング——これらが一度に押し寄せる。AgentCore Harnessは、こうした「配管工事」をすべてAWSのマネージドサービスとして引き受ける。
Harnessが束ねるもの
Harnessは既存のAgentCoreの構成要素を1つのマネージドユニットとして統合する。
| コンポーネント | 役割 |
|---|---|
| Runtime | セッションごとに分離された実行環境 |
| Memory | ターン（会話の往復）をまたいでコンテキストを保持 |
| Gateway | ツール（外部API等）を公開 |
| Identity Vault | 認証情報を安全に管理 |
| Observability | 各ステップをAmazon CloudWatchにトレース |
GA時点でいくつかの新機能が追加された。Memoryはハーネス作成時に自動プロビジョニングされるようになり、再訪ユーザーの認識に追加セットアップが不要になった。AWSがキュレーションしたスキルカタログを1つのトグルで読み込める機能、各呼び出しのリアルタイムストリーミングも利用可能になった。
最も要望の多かった機能：セッション中のモデル切り替え
顧客からの要望が最も多かったのが、1セッション内でのモデル切り替えだ。例えば、計画フェーズはClaude、コード生成は別モデル、要約はGemini、といった使い分けを、会話のコンテキストを保ったまま実現できる。モデルは1回のAPIコールごとにフィールドとして指定する形になる。
エージェントの継続性を担うMemory、Gateway、Identity VaultはすべてAWS上に置かれたまま、推論部分だけを差し替えられる設計だ。
大手クラウド3社が同じ形に収束している
この動きはAWSだけにとどまらない。
- Google：4月のCloud NextでVertex AI Agent EngineをGemini Enterprise Agent Platformの中核として刷新。マネージドなAgent Engine、Sessions/Memory Bank、Observabilityを提供
- Microsoft：3月にAzure AI Foundry Agent Serviceの次世代版をGA。サンドボックスセッションとファイルシステムアクセスを備えたホスト型エージェントは7月初旬にGA予定
3社ともRuntime、Memory、Tools、Identity、Observability、Governanceという同じ構成要素に収束している。Janakiram MSVはこの点について「エンタープライズ顧客への持続的なロックインは、エージェントが呼び出すファンデーションモデルではなく、その下にあるオペレーショナルレイヤーにある」と指摘する。
AWSはAgentCore上でエージェントが実行したタスク数が6ヶ月で15倍に増加したと報告しており、本番環境でスケーリングしている顧客としてNasdaq、Visa、Experianを挙げている。
ロックインはモデル層ではなく運用層で起きる
Harnessはモデル層の柔軟性を提供する一方で、運用層では明確なリテンション機構として機能する。モデルは入れ替えられても、Memory・Gateway・スキルカタログ・Identity VaultはすべてAWSサービスのままだ。
ポータビリティへの対応として、AWSはCLI1コマンドでStrands Agentsベースのコードとしてエクスポートする手段を提供している。ただしエクスポートされたエージェントは引き続き同じAWSのコンピュートとプリミティブ上で動作する。現時点でエクスポート対象はStrandsのみで、Claude Agent SDKへの対応は元記事執筆時点でComing Soonとされている（※対応時期や詳細はAWS公式のAgentCoreドキュメントで最新情報を確認されたい）。
価格設計の複雑さ
Harness自体に課金はないが、裏側のサービスには個別に費用が発生する。
- Runtime：秒単位の課金
- Gateway：呼び出しごと
- Memory：イベントおよびリトリーバルごと
- Observability：CloudWatchの標準料金
メーターが独立しているため、ツール呼び出しやリトリーバルが倍増した場合のコスト予測が難しい。元記事でJanakiram MSVは、Googleの類似したコンポーネント別課金モデルがすでに価格予測の困難さを示している事例として言及しており、エージェント価格設計はパイロット時点では安く見えても、本番スケールで想定外の挙動をする可能性があると警告している。
エンタープライズのデシジョンメーカーが確認すべき問いは2つだ。どこまでが自社の資産で、どこからがAWSのラッパーか。そして、本番ロード下でのコスト予測は成立するか。特にMemoryは、エージェントが蓄積したコンテキストそのものがスイッチングコストになるため、注意が必要だ。
詳細はWhy AWS AgentCore Harness Is A Big Deal For Enterprise Agentsを参照していただきたい。
