エージェント実行基盤は自作かマネージドか — AgentCore harness を"逃げ道付き"で採用する判断軸
自前の orchestration を書き続けるか、AgentCore harness に載せるか。独自性・自由度・工数運用・ロックイン耐性の判断軸4つと、後から自前へ寄せる逃げ道（export）の実体を、ロックインの誇張なしで整理します。マネージドを常に正解とはしない中立の立場で、自作が向く場面とその送り先まで示します。
- #AgentCore
- #AgentCore harness
- #エージェント
- #orchestration
- #build vs managed
- #マネージド
- #意思決定
- #ロックイン
- #Strands
「If the model is the brain, the harness is the body（モデルが頭脳なら、harness は身体）」。AWS公式はAgentCore harnessをこう説明します。エージェントをPoCから小規模本番まで触ると、いずれ「自前の orchestration loop（生成・ツール呼び出し・状態管理を回す制御ループ）を書き続けるのか、マネージドな実行基盤に載せ替えるのか」という分岐に行き当たります。2026年6月17日にAmazon Bedrock AgentCore harnessが一般提供（GA）となり、「載せ替える」が現実的な選択肢に昇格しました。本記事は機能紹介ではなく、自前で握るか・harnessに委ねるかをどう決めるかの判断軸に重心を置きます。これは知識層（RAG）の build vs managed を扱ったRAGはマネージドか自前かの双子にあたり、そちらが「ツールとして呼ばれる側」の判断なら、本記事は「ツールを呼ぶ側＝実行基盤層」の判断です。マネージドを常に正解とはしない、中立の立場で整理します。
AgentCore harnessとは — configで本番グレードを自動構築（GA 2026-06-17）
AgentCore harnessは、モデル・ツール・スキル・指示（instructions）をconfigとして定義すると、本番グレードのエージェント実行基盤を自動で組み立てるマネージドサービスです。2026年6月17日にGAとなりました。AWS公式は、ごく少数のAPI呼び出しでアイデアから本番相当のエージェントへ到達できると説明します。
実行の特性も公式に明記されています。各harnessセッションは既定でステートフル（状態を保持する）で、セッションごとに隔離されたmicroVM（軽量な仮想マシン）の中で動きます。各セッションは独自のファイルシステムとシェルを持ち、短期・長期のメモリやファイルをセッションをまたいで保持できます。モデルはAmazon Bedrock、OpenAI、Google Gemini、またはLiteLLM互換プロバイダーのいずれでも選べ、文脈を失わずにセッションの途中でプロバイダーを切り替えられます（計画用と実行用でモデルを分ける、価格性能を比較する、といった差し替えが再構築なしでできます）。
ここで本記事の核を先に置きます。このharness自体が、AWS発のオープンソースのエージェントフレームワークである Strands Agents で動いています（“powered by Strands Agents”）。この事実が、後述する「逃げ道」の技術的な裏付けになります。
自作かマネージドかを分ける4つの判断軸
自前で書くかharnessに載せるかは、次の4つの軸で整理できます。
① orchestrationの独自性。制御フローが定型的（ユーザー入力を受けてツールを呼び、結果をまとめて返す、といった標準形）なら、harnessが引き受けやすい範囲です。独自の分岐ロジックや特殊な状態遷移を細部まで握りたいなら、自作が向きます。
② 自由度制約の許容度。harnessが管理するのは、環境（environment）・コンピュート（compute）・メモリ（memory）・アイデンティティ（identity）・ネットワーキング（networking）・可観測性（observability）の各レイヤーです。公式は「別のモデルを試す・新しいツールを足すのはconfigの変更であり、コードの書き換えではない」と表現します。一方で、独自のインフラ構成や特殊な制御フローまで自分の仕様で握りたい場合は、委ねる範囲が制約として効いてきます。委ねて速く進めるか、握って自由を取るかの許容度を測る軸です。
③ 工数・運用負荷。実行基盤を自前で持つと、ランタイム・サンドボックス・メモリ・可観測性の実装と運用が継続的に乗ります。harnessはこれらを委ねる代わりに、configの変更で対応できる範囲が広がります。
④ ロックイン耐性。マネージドに寄せたあと、後から自前へ戻せるか。ここがharness採用の最大の懸念ですが、後述のとおりexport経路が用意されており、しかもその先がオープンソースです。
なお、harnessは中間的な握り方も用意します。独自コンテナの持ち込み（bring your own container）や、Amazon S3 FilesやEFSのマウントにより、委ねつつ一部だけ自分の仕様にすることもできます。全部おまかせか・全部自前かの二択ではありません。
harnessが向くケース／自作が向くケース
4軸を踏まえると、向き不向きは次のように整理できます。orchestrationが定型的で、速く本番化したく、ランタイムやサンドボックスの運用を委ねたい場合は、harnessが向きます。逆に、固有の制御フローや特殊な状態管理が要件の中心で、独自インフラまで握る必要があるなら、自作が向きます。
ここで線引きを一つ。「載せ替えたあとの本番運用をどう回すか」という運用総論は、本記事の範囲を超えます。可観測性・障害対応・コスト管理を含む運用設計は、本番運用のための生成AIエージェント運用に整理しているので、自作・harnessのどちらを選ぶにせよ、運用フェーズに進む段階でそちらを参照してください。
逃げ道の設計 — 後から自前へ寄せる2経路
harness採用の判断で最後まで残るのが「後から自前へ戻せるか」です。公式は、configでは足りなくなったとき（when configuration isn’t enough）の逃げ道として、現時点で次の2経路を用意しています。
ひとつは、AWS Step Functions の AgentCore InvokeHarness ステートにharnessをドロップし、より大きなパイプラインの一部として組み込む経路です。もうひとつは、Strands code へexportし、AgentCore runtime 上で実行する経路です。なお、Claude Agent SDK へのexportは「coming soon」、つまり現時点では未提供です。逃げ道を「Claude Agent SDKへ出せる」と先回りして書くことはできません。現状の逃げ道はStep Functionsへの組み込みとStrands code exportの2つ、と正確に押さえてください。export後の詳細な制約は専用ドキュメント「Export Harness to Code」で時点確認する前提です。
この逃げ道が意味を持つのは、抜け出し先がオープンソースだからです。harness自体がOSSのStrands Agents製で、export先もStrands codeです。つまり、要件がconfigを超えたとき、独自のプロプライエタリな閉じた領域ではなく、OSSのコードへ抜けられます。これが「逃げ道付き採用」という設計の技術的な裏付けです。
採用前に知る落とし穴
逃げ道は強みですが、過大評価は禁物です。採用前に押さえるべき点を3つ挙げます。
第一に、exportはロックインゼロではありません。export経路があっても、AgentCore runtimeという基盤の上で動く構造は残ります。「いつでも何の痕跡もなく自前へ戻せる」わけではなく、「configを超えたらコードへ抜ける経路がある」という意味だと理解してください。
第二に、自由度制約の過小評価です。委ねる範囲（環境・コンピュート・メモリ・アイデンティティ・ネットワーキング・可観測性）は、裏返せば「harnessの流儀に合わせる前提」です。独自の制御フローや特殊なインフラ要件があるなら、採用前にその要件が委ねる範囲に収まるかを確認すべきです。
第三に、料金です。harness自体には別料金はかからず、使った下層のAgentCore機能ぶんの従量課金のみ、と公式は明記しています。ただし「下層の従量は発生する」点は変わりません。具体的な料金額やクォータ・上限は改定されるため本記事には載せません。AgentCore pricingで時点確認してください。
加えてリージョン差も正直に書きます。harnessは東京リージョン（ap-northeast-1）を含む15リージョンで利用できます。現時点で唯一の非対応はAWS GovCloud（US-West）です（AgentCore runtimeなど他の機能はGovCloudにも対応していますが、harnessはこのリージョンのみ非対応）。利用予定のリージョンが対応範囲かは、公式のリージョン一覧で確認してください。
自分の案件にどう当てるか（チェックリスト）
ここまでの軸を、案件への当てはめとして整理します。
| 確認ポイント | 自作に寄せる | harnessに寄せる |
|---|---|---|
| 独自の制御フロー（orchestration） | 特殊な分岐・状態遷移を細部まで握りたい | 標準的なループで足りる |
| 運用体制 | ランタイム・可観測性を自前で運用できる | 運用を委ねて開発に集中したい |
| 立ち上げ速度 | 時間をかけて作り込む前提 | 少数のAPI呼び出しで速く本番化したい |
| 撤退可能性（ロックイン耐性） | 最初から自前で完全に握る | configで始め、超えたらexportで抜ける |
| 自由度の要件 | 独自インフラまで自分の仕様で握る | 委ねる範囲に要件が収まる |
判断に迷うときは、撤退可能性を軸に置くと整理しやすくなります。configで始めて要件が超えたらexportで抜ける、という段階戦略を取れるのがharnessの性格だからです。
まとめ — 次に読む
エージェント実行基盤の build vs managed は、独自性・自由度・工数運用・ロックイン耐性の4軸で決まります。harnessはconfigで本番グレードを自動構築し、configを超えたらStep Functions組み込みかStrands code exportで抜けられます。逃げ道の先はOSSのStrandsで、これが「逃げ道付き採用」を支えます。ただしexportはロックインゼロではなく、料金は下層従量で発生し、GovCloud（US-West）のみ非対応である点は誠実に押さえてください。
知識層（RAG）側の同じ判断はRAGはマネージドか自前かに、載せ替えたあとの本番運用は本番運用のための生成AIエージェント運用に、マネージドでも出荷判定に必要な評価は生成AIの評価とリリースゲートに、それぞれ整理しています。実行基盤層と知識層の2つが、エージェントの build vs managed の大きな論点です。
明日の一歩としては、immutable versions（変更不可のバージョン）とnamed endpoints（名前付きエンドポイント）を用意し、エンドポイントを過去バージョンに向けるだけで即座にロールバックできる構成から、安全に始めることをおすすめできる形で公式が示しています。まずは小さく載せ、export経路の存在を採用前提として確認しておくのが、後悔の少ない入り方です。