AWSが2026年9月9日、オープンソースの「Strands Agent Harness SDK」を改めて前面に出した。エージェントを作り、任意の環境へ配備できることが売りだという。だが、Strands Agentsそのものが初めて公開されたわけではない。最初の公開は2025年5月16日で、当時からAmazon Q DeveloperやAWS Glueなどで本番利用されていた。
今回の変化は、新しいコードベースの誕生というより、Strandsが担う範囲を「エージェント・ハーネス」という言葉で明確にした点にある。モデルを呼ぶ薄いライブラリではない。ツールを実行し、履歴を渡し、処理を続けるか止めるかを決める土台である。つまり、どこでも動かせる自由は、モデルと実世界をつなぐ境界を自分で管理する責任と一体になっている。
2026年の「Harness」は何が新しいのか
2025年の公式発表で、AWSはStrands Agentsをモデル駆動型のオープンソースSDKと説明していた。最小構成はモデル、ツール、プロンプトである。SDKがモデルを呼び、必要なツールの説明と会話履歴を渡す。モデルが次の操作を選ぶと、SDKはツールを実行し、その結果を次の呼び出しへ戻す。この反復がエージェントループになる。
現行の公開リポジトリにはPython版とTypeScript版が同居する。Python版はPython 3.10以上、TypeScript版はNode.js 20以上を要件とし、MCP、ストリーミング、複数エージェントの構成、構造化出力を備える。Apache License 2.0で公開され、配備先をAWSに限定していない。
したがって、2026年の呼称が示すのは断絶ではなく、役割の言語化だ。単発のAPI呼び出しでは、モデルの返答を受け取れば処理が終わる。ハーネスはその外側で、次に何をモデルへ見せるか、どの操作を許すか、失敗したときにどう戻すかを扱う。モデルの性能が上がっても、この部分は消えない。
SDKが担うエージェントループ
Strandsの公式学習文書は、ハーネスがモデルを繰り返し呼び、ツールを実行し、結果を文脈へ加え、処理を継続するか判断すると説明する。SDKにはフック機能（hooks）やメモリ機能がある。セッション管理に加え、評価や観測のための部品も用意されている。開発者はそれらを組み合わせ、自分の用途に合う実行環境を作る。
既定値にも注意が要る。Strandsはツールを自動では追加しない。ファイル操作、外部API、データベース更新といった能力は、利用者が選んで渡す。会話履歴も無制限には保持せず、既定の管理方式は新しい履歴を残して古い履歴を切り捨てる。先回りした文脈圧縮は自動設定を選んだときに有効になる。長時間動くエージェントを作るなら、何を記憶し、何を捨て、再開時にどの状態を信用するかまで設計しなければならない。
安全性も同じ構図にある。処理の前後へ検証を差し込み、人の承認まで一時停止する仕組みは作れる。しかし、SDKを導入しただけで、強い権限を持つツールが安全になるわけではない。読み取りと更新を分け、危険な操作には決定的な検証を置き、必要なら隔離環境で実行する。ハーネスを自ら運用するなら、利用者はこの境界をコードで管理することになる。
同じStrandsでも、管理する主体が違う
Strands Agent Harness SDKではエージェントループと配備先を利用者が選ぶ一方、AgentCore HarnessではAWSがStrandsベースのループと基盤運用を管理し、設定で足りない場合はStrandsコードへ書き出せる。
| 比較軸 | Strands Agent Harness SDK | SDKをAgentCore Runtimeで実行 | Amazon Bedrock AgentCore Harness |
|---|---|---|---|
| エージェントループ | 利用者がコードで構成 | 利用者のStrandsコード | AWS管理のStrandsベース |
| 配備と基盤 | 利用者が環境を選び運用 | AWSの実行基盤を利用 | AWSが管理 |
| 変更方法 | コードと設定を変更 | コードを更新して再配備 | 設定、版、名前付き接続先を管理 |
| 独自制御 | 最も広い | コード側で維持 | 設定で足りなければコードへ書き出す |
| 主な運用責任 | 権限、隔離、状態、監視を利用者が設計 | ループ設計は利用者、基盤はAgentCore | 基盤、版、接続先はAWS管理。ツール権限や業務ルールは利用者が定義 |
この表は2026年9月22日時点の公式資料を、性能や価格ではなく責任主体でそろえたものだ。AgentCore HarnessもStrands Agentsで動くため、二つは無関係な競合製品ではない。公開SDKをAgentCore Runtimeへ載せる中間の構成も選べる。
AgentCore Harnessは、作成後に変更できない版と名前付き接続先を持ち、接続先を過去の版へ戻せる。Step Functionsからも呼び出せる。AWSは基盤を管理せずに本番エージェントを運用できると説明しているが、利用料がなくなるわけではない。Harness単体の追加料金は設けず、使ったAgentCoreの機能へ課金する形だ。
「any model, any cloud」の現実
現行READMEはAmazon Bedrock、Anthropic、OpenAI、Geminiを主要な対応先として挙げ、ほかのモデル提供元や独自接続にも開いている。2025年の発表は、推論とツール利用に対応するモデルが前提だと説明していた。ここでの「任意のモデル」は、あらゆるモデルが設定なしで同じように動くという意味ではない。
既定経路も確認が必要だ。Python版とTypeScript版はいずれもAmazon Bedrockを既定のモデル提供元とし、そのまま始める場合はAWSの認証情報とClaude Sonnetへの利用権が要る。別の提供元へ切り替えればAWSへの依存は減らせるが、認証、課金、応答形式、ツール呼び出しの差は利用者が吸収する。
配備先の自由も、運用の肩代わりではない。2025年の公式発表は、エージェントループとツールを同じ環境に置く構成に加え、ループをFargate、ツールをLambdaへ分ける例を示していた。分離すれば権限の境界を引きやすくなる一方、通信、認証、障害時の再実行を設計する必要が生じる。自由度が増えるほど、決めることも増える。
導入判断は自由度より責任で決まる
独自の停止条件、検証、文脈管理を製品の競争力にしたいなら、公開SDKを選ぶ理由がある。モデルや配備先を替えながら、ループの細部を制御できるからだ。すでに自社の実行基盤と監視を持つチームにも合う。
一方、標準的なループで足り、版管理、接続先、評価、ロールバックを管理サービスへ寄せたいなら、AgentCore Harnessの方が運用項目を減らせる。設定の限界に達したときはStrandsコードへ移る道も用意されている。最初から将来のすべてを予測して二者択一にする必要はない。
判断軸は「どこでも動くか」より、「失敗した操作を誰が止め、状態を誰が復元し、変更を誰が戻すか」である。Strandsは、その答えをAWSへ固定しない。代わりに、答えを曖昧なままにもしてくれない。
