2026年4月22日、AWSはAmazon Bedrock AgentCoreに「managed agent harness」（プレビュー）を追加しました。モデル / システムプロンプト / ツールを設定として宣言するだけでエージェントが動く仕組みで、オーケストレーションコードはAWS側がマネージドで持ちます。
このリリースが目を引くのは機能そのものよりも、AWSが "agent harness" という用語を採用した点でしょう。Martin Fowler氏が2026年2月にハーネスエンジニアリングの整理を書いて以降、AnthropicやOpenAIも公式に "harness" を使うようになった流れの先に、クラウドベンダーが自社サービスに同じ語を当てたことになります。
自分でハーネスを組んできた立場から見ると、managed harnessは何を引き受けてくれて、何が手元に残るのか。本記事ではこの分業線を整理します。Claude Desktopと複数のMCPサーバー、Markdownのナレッジで業務自動化エージェントを運用してきた経験を起点に、AgentCore managed harnessとの対応関係を並べていきます。
「触ってみた」記事は既にいくつか公開されているので、本記事はその前段の「乗せる / 乗せない / 乗せる順序」の判断材料を提供する位置付けです。公式ブログとドキュメント、既存の解説記事を出典として参照しながら、自前運用の経験から見える対応と判断軸を整理します。
AWSが "managed harness" を出した
上述の公式ブログでは、エージェントには必ずオーケストレーション層があり、その層を動かすには計算資源・コード実行のサンドボックス・ツール接続・永続ストレージ・エラー回復といった基盤が必要で、これらをまとめてagent harnessと呼ぶ、と整理しています。managed harnessはこのharnessをAWS側がマネージドで提供するもので、利用者はモデル・システムプロンプト・ツールを設定として宣言するだけで動くエージェントが手に入ります。
ここで「ハーネス」という言葉が指す範囲を一度揃えておきます。ハーネスはベンダー側が組み込んでいる内部の話としても、利用者側が外側に組み立てる環境の話としても使われていて、文脈で意味がぶれる用語です。Fowler氏の整理に加え、watany氏がZennで内部 / 外部の混乱を整理しています。
本記事は「自前で外側の環境を組んできた立場」、つまり利用者側のハーネスを実際に運用してきた視点で書きます。AgentCore managed harnessはベンダー側の内部ハーネスをマネージド化したように見えますが、利用者側から見るとそれまで自分で作っていた外部ハーネスの一部を委譲できるようになった、と読むこともできます。この二重性が、自前運用との分業線を考える出発点になります。
自前ハーネスの構成、空白だった四つの層
自前で組んできたハーネスの構成を、AgentCoreのコンポーネントと対応させてみます。これまで自分で運用してきた環境はおおまかに次の三要素で、それぞれがAgentCoreのどれと対応するかを並べます。
| 自前ハーネス | AgentCore側 | 対応の度合い |
|---|---|---|
Markdownのナレッジファイル群（agents/、knowledge/ 配下） |
AgentCore Memory | 似た役割、永続化と検索の機構が違う |
| MCPサーバー群（タスク管理 / カレンダー / チャット / 文書管理など） | AgentCore Gateway | MCPに統一されつつあるので近い |
| Claude Desktop | AgentCore Runtime | エージェントループの実行基盤、規模が違う |
| 該当なし | AgentCore Identity | 自前では実装していない |
| 該当なし | AgentCore Policy | 自前では実装していない |
| 該当なし | AgentCore Observability | 自前では実装していない |
| 該当なし | AgentCore Evaluations | 自前では実装していない |
上の三つは「自分が手で組んだ部分」と「AgentCoreが同じ役割でマネージドに提供している部分」の対応関係です。下の四つは自前ハーネスでは空白になっている層、つまりAgentCoreが提供しているのに自分の運用ではカバーしていない部分です。
ここで気になるのは、空白の四層が「なくても困らなかったから書かなかったもの」なのか、「あったらよかったが諦めていたもの」なのかでしょう。両者は意味が違います。前者はmanaged harnessを導入しても価値が小さく、後者は価値が出ます。
四層を順に確認します。
Identityは、複数のユーザーがエージェントを使うときの認証と権限の管理です。自前ハーネスは個人の端末で動いているので、認証は端末ログインに任せられて、エージェント単位の認証は不要でした。これは「一人で使う限り」不要です。組織でエージェントを共有しようとした瞬間に、誰がどのMCPに対して何を呼べるかの制御が問題になり、空白だったことが諦めの形で表面化します。
Policyは、エージェントがツールを呼ぶときの境界線を宣言的に定義する仕組みで、AWSのオープンソースのポリシー言語Cedarをベースに、自然言語からポリシーを生成できます。自前ハーネスではMCPサーバー側のスコープと、ナレッジで「やってはいけないこと」を文書化する形でゆるく境界を引いていますが、これは規律であって強制力ではありません。実装可能な強い境界として書いておきたかったが、自前でCedar相当の仕組みを書く動機がなく、諦めていた領域です。
Observabilityは、エージェントの実行ログ・トレース・メトリクスをCloudWatchに出して可視化する仕組みです。自前ハーネスではClaude Desktopの会話履歴と、各MCPサーバーが個別に出すログがあるだけで、横串で「どのエージェントがいつ何を呼んでどう失敗したか」を追跡する仕組みは持っていません。一人で使っている分にはチャット画面を見れば足りますが、組織展開では必要になるもので、諦めの領域に入ります。
Evaluationsは、エージェントの応答品質を継続的に評価する仕組みで、有用性・ツール選択精度・正確性などの観点で組み込みの評価器を持ちます。自前ハーネスではナレッジファイルの改善履歴と日次の作業ログで主観的にチェックしていますが、定量的な品質モニタリングはありません。これは個人運用なら主観で十分とも言えますが、組織運用や有償サービスとして提供する場合には欠かせなくなります。
四層を眺め直すと、Identityだけは「一人で使う限り不要」、残りの三層は「あったらよかったが自前では諦めていた」に分類されます。空白の意味が層によって違うことが、managed harnessを乗せるかどうかの判断に影響します。
managed harnessが引き受ける層、残す層
managed harnessを使うと、利用者は何を書かなくてよくなり、何は書き続けるのか。これは公式ブログとドキュメントから事実として取れるので、まず整理します。
managed harnessが引き受けるのは以下の範囲です。
- モデルを呼び、ツールを選び、結果を戻し、コンテキストを管理し、エラーから回復するエージェントループ
- セッションごとに分離されたmicroVM、ファイルシステム、シェル
- AgentCore Gatewayを介したツール接続のオーケストレーション
- Strands Agentsをベースにしたフレームワーク部分
逆に、managed harnessを使っても利用者が依然として書く必要があるのは以下の範囲です。
- どのモデルを使うか
- システムプロンプトに何を書くか
- どのツールを呼べるようにするか
- AgentCore Memoryに何を入れて何を入れないか
- AgentCore Policyにどんな境界線を宣言するか
宣言ベースの設定で済むので、コードとしては大幅に減ります。ただし、上の五つは「設定として書く対象が変わっただけ」で、判断そのものは消えません。harness.json という構成ファイルに表れる形に変わるだけです。実際にmanaged harnessを試したプレビュー検証記事を読むと、harness.json にはモデルとツールリストが、別ファイルの system-prompt.md にシステムプロンプトが、それぞれ宣言として並びます。
これは自前ハーネスでMarkdownのシステムプロンプトファイルやMCPの接続定義として書いていたものを、AWSの構成ファイル形式に置き換えた形に見えます。
つまりmanaged harnessが引き受けるのは「オーケストレーションコードを書く労力」であって、「エージェントを設計する判断」ではありません。設計判断は依然として利用者の側に残ります。AWSはインフラ整備の障壁を取り除くと表現していますが、インフラではない部分、つまり「このエージェントは何のために存在し、どこまでをやらせるか」の設計は、managedであろうと自前であろうと変わらず人間の側に残ります。
この区別は、managed harnessを採用するかどうかを判断する上で大事な視点です。「コードを書かなくていい」という訴求は当たっていますが、「考えなくていい」と読み替えると不正確になります。
自前運用が言語化できる「設計判断の場所」
自前ハーネスを運用していくと、エージェントを動かす上で「どこを動かしてよくて、どこを動かしてはいけないか」の判断が手元に蓄積されます。これらはmanaged harnessを採用しても消えません。表れる場所が harness.json の中身に変わるだけで、判断そのものは依然として人間の側にあります。代表的なものを挙げてみます。
ナレッジファイルの粒度設計。Markdownのナレッジを「ロールごと」に分けるか、「業務ごと」に分けるかは、最初に決めると後の運用が楽になる判断です。ロールごとに分けると、エージェントの呼び分けが文脈で自然に決まります。業務ごとに分けると、業務横断的な知識が散らばります。両者は単純な優劣ではなく、運用するエージェントの数と業務の重なり方で最適解が変わります。managed harnessを使っても、Memoryに何をまとめて何を分けるかという同じ問いが残ります。
MCPサーバーの組み合わせ設計。どこまでをツールとしてMCPで繋ぎ、どこまでをローカルファイル操作で済ませるかの線引きです。たとえばタスク管理はAPI経由でMCP化したほうが自動化との相性がよく、機微な業務はローカルでファイル操作のほうが安全、という判断は使いながら見えてきます。managed harnessのGatewayも同じ問いに答える必要があり、ツールリストとして宣言する形に置き換わります。
エージェント間の責務分割。司令塔となるエージェントが文脈を判別して専門エージェントに渡す構造を取るか、最初から専門エージェントを直接呼ぶか、という設計です。司令塔型は文脈判別の精度に左右され、直接呼ぶ方式はユーザー側に判別の負荷が乗ります。これもmanaged harnessでは、複数のharnessを並べて連携させる設計判断として残ります。
この三つは自前で一度運用してみないと言語化しにくい判断です。最初からmanaged harnessで組むと、これらの判断が「最初から最適配置されているように見える」状態が生まれます。実際は前提を固定しているだけなのですが、固定された前提の中で動く分には設計判断の存在自体が見えにくくなります。
最初からmanaged harnessでよくないか
ここで想定される反論があります。「最初からmanaged harnessで組めば、自前で組む必要がないのでは」というものでしょう。
この反論には部分的に同意できます。組織で本番運用するエージェントを新規にゼロから組むなら、managed harnessから入るほうが早いと思います。ただし、その設計が「最初から見えている」ことはほとんどありません。エージェントを実際に使ってみてはじめて、ナレッジの粒度、ツールの過不足、責務の境界線が見えてきます。この発見の流れを、枠の決まったmanaged harnessの上で回すのと、自由度の高い自前ハーネスで回すのとでは、得られる学習の量が変わります。
もう一つの観点として、自前運用で得た判断はmanaged harnessに乗せ替えるときの設計図として再利用できます。設計図を持たずにmanaged harnessから入ると、一見動くものはできますが、なぜそう構成したのかを説明しづらいシステムが残ります。「とりあえず乗せて改良していく」が成立するかは、一人で改良するか複数人で改良するかという状況にもよります。一人なら自前ハーネスとmanaged harnessの反復速度の差は小さいかもしれませんが、複数人で改良する段階では harness.json の宣言的な変更とデプロイ単位の反復が運用負債として効いてきます。
乗せる順序: 個人運用と組織運用の分岐点
managed harnessを採用するかどうかは、運用規模で分岐するのが自然と言えます。三つの段階に分けて確認します。
一人で使っている個人運用の段階では、自前ハーネスで十分な場合が多いと思います。ナレッジファイルの編集と利用が密結合していて、使ってみて気付いた瞬間にMarkdownを書き換えるという反復が早く回るからです。IdentityもObservabilityも、一人で動かしている限りは欠落として認識されにくく、あったほうがよいかもしれない、程度の位置付けに留まります。実験的な段階ではこの自由度が学習速度に直結します。
組織で複数人がエージェントを使う運用に展開する段階で、空白だった四層が一気に問題化します。誰がどのエージェントをどう使ったかの監査ログが必要になり（Observability）、共有環境で勝手にツールを叩かれたら困る局面が出てくるので境界線が必要になり（Policy）、メンバーごとの認証情報の管理が必要になり（Identity）、エージェントの応答品質を継続して測りたくなります（Evaluations）。この段階でmanaged harnessの価値が前面に出ます。自前で四層を書く労力とAgentCoreに乗せる労力を比べると、後者が現実的になります。
過渡期ではハイブリッドな戦略が取れるでしょう。個人の探索段階は自前ハーネスのまま続け、組織で運用する確定パスだけをmanaged harnessに乗せていく形です。設計が固まったエージェントから順にAgentCoreへ移し、まだ動かしながら学習しているエージェントは手元に残します。
乗せる順序にも目安があります。組織展開で最初に必要になるのはIdentityとObservability、次にPolicy、最後にEvaluationsです。Identityがないと共有自体が成立しません。Observabilityがないと組織として運用判断ができません。Policyは事故が起きてからでは遅いことが多いので、組織展開の初期に置くのが安心です。Evaluationsは運用が回り始めてから品質測定を入れる順序で構いません。
ハーネスはもともと、エージェントを作る側と使う側の境目にあった概念でした。AWSがmanaged harnessを出したことで、それまで自分で組み上げていた一部が、設定として宣言すれば動く仕組みに変わりました。Identity・Observability・Policyのように、自前ではどうしても諦めていた層が手の届くところに来た意味は小さくありません。
それでも、何のためにエージェントを動かすのか、ナレッジに何を残すのか、ツールにどこまで権限を渡すのかという設計判断は、設定として宣言できる形にはなっていません。判断の根拠は依然として、自身のリポジトリのコミット履歴と作業ログに残っていきます。自前ハーネスを組んできた経験は、managedに乗せ替えても価値が消えない種類の知見として、手元に残ります。managed harnessの整備によって、自前で組む層と人間が判断する層の境目が、これまでよりはっきり見えるようになった、とも言えます。
Discussion