「モデルのデモ」から「運用するエージェント」までの隙間を埋める

AWSのオープンソースプロジェクト Strands Harness は、ローカル環境で動いたAIエージェントの試作を、配備可能なアプリケーションへ持ち込む際に必要となる周辺機能をまとめた基盤です。

LLMを選び、タスクを与えるだけでエージェントらしい対話は作れます。しかし実用化には、コンテキストの扱い、ツール呼び出し、状態の保持、権限、実行制限、監視といった仕組みが必要です。Strands HarnessはStrandsエコシステム上にこれらの共通部品を用意し、ローカル実行にも任意のクラウドプロバイダーへの配備にも使えるものとして提供されています。AWS専用のランタイムをうたうものではありません。7

モデルの周囲に何を用意するのか

Strands Harnessには、あらかじめ次の機能が組み込まれています。

• ファイル操作
• シェルコマンド実行
• Webツール
• コンテキスト管理
• 永続セッションとメモリ
• プロンプトキャッシュ
• 複数エージェント間の委任

5

重要なのは、これらが「モデルそのもの」ではなく、モデルをエージェントとして動かすための実行層である点です。ローカルでの実験からアプリケーション化へ進むとき、開発者は通常、ツール連携、会話・作業状態、長い入力の整理、役割分担などを個別に組み立てる必要があります。共通のハーネスを使えば、モデル提供元や実行環境を変えても、ツールと状態の設計をなるべく保ちやすくなります。

Strandsは、外部ツールに接続するためのオープン標準 Model Context Protocol（MCP） もサポートします。MCPを利用すれば、エージェント本体に連携コードを個別実装し続けなくても、承認済みの社内システムや外部サービスをツールとして接続できます。基盤となるStrands SDKはプロバイダーを差し替えられる設計で、Amazon Bedrock、Anthropic API、OpenAI、Ollamaなどのローカル／オープンソースモデルを含む選択肢に対応します。15

ローカル試作からクラウド配備まで

基本的な流れは、ローカルでエージェントを試作し、PythonまたはTypeScriptのプロジェクトとして構成・テストしたうえで、配備先に応じた設定を加えるというものです。リリースの報道では、AWS、Google Cloud、Microsoft Azure、Cloudflare、Modal、ローカル環境向けの配備設定を生成するためのガイダンスが案内されています。6

ただし、これは「ワンクリックで本番運用可能」という意味ではありません。実運用に移すなら、ハーネスとは別に、組織ごとのセキュリティと運用設計が不可欠です。

• エージェントには、業務に必要な最小限のファイル、シェル、ネットワーク、データ権限だけを与える。
• シークレットやプロバイダー認証情報を、プロンプトやソースコードの管理対象に置かない。
• MCPサーバーと外部ツールも、信頼境界の一部として評価する。
• インフラ変更、メッセージ送信、本番データの更新といった影響の大きい操作には、承認フローまたはサンドボックスを設ける。
• 本番で使う前に、ログ、監視、テスト、対象業務に即した評価を追加する。

Strands Harnessは統合作業を減らせますが、アクセス制御、許容リスク、信頼性の基準を決めてくれるわけではありません。

Strands CLIで始める

公式クイックスタートでは、CLIにNode.js 20以降が必要です。対話型セットアップでPythonかTypeScriptを選び、使用するモデルプロバイダーを設定できます。PythonプロジェクトにはPython 3.10以降が必要です。2

# 対話型CLIをインストール
npm install -g @strands-agents/cli

# セットアップアシスタントを起動
strands

Pythonで始める場合、ドキュメントに示されている導入手順は次のとおりです。

python -m venv .venv
source .venv/bin/activate  # Windows: .venv\Scripts\activate
pip install strands-harness

TypeScriptでは、Node.jsプロジェクトを初期化し、現行のクイックスタートに従って@strands-agents/harnessを導入します。2

実務では、対話型セットアップでエージェントの役割、許可するツール、モデルプロバイダー、メモリの要否を定め、まずローカルで実行します。その後、生成または設定したプロジェクトを配備用成果物としてバージョン管理し、テストする進め方が妥当です。CLIの操作や生成フローはリリースごとに変わり得るため、特定のexport／生成コマンドを手順書に固定する前に、strands --helpと最新のクイックスタートを確認してください。2

モデルを選べても、プロバイダー設定は必要

Strandsは複数プロバイダーでの利用を想定していますが、可搬性がプロバイダー固有の設定を不要にするわけではありません。Harness SDKはAmazon Bedrockをデフォルトにしており、選んだモデルを利用するにはAWS認証情報の設定とモデルアクセスの有効化が必要です。12

他のプロバイダーでも、それぞれ認証情報、エンドポイント、料金体系、ポリシー管理を整える必要があります。ローカルモデルやオープンウェイトモデルを用いるチームについては、関連するStrandsのベンチマーク用ハーネス資料でLiteLLMやvLLMといったランタイム経由の利用が説明されています。18

つまり、エージェントの運用設計を単一のモデルベンダーから切り離せる可能性はあります。一方で、モデルまたはランタイムを替えた際には、回答品質、レイテンシー、ツール利用の信頼性を改めてテストすべきです。

AWSの「28％低コスト」はどう読むべきか

AWSは、同じClaudeまたはGPTモデルを使う6つのベンチマークで、Strands Harnessが他のハーネスより28％低コストで、精度はほぼ同等だったと説明しています。7

別の報道では、Claude CodeとCodexに対しては約45％低コスト、DeepSeek Harnessを比較対象に含めた場合は28％という数値が紹介されています。比較対象のグループが異なるため、これらを一つの普遍的な削減率として扱うべきではありません。5

コンテキストの組み立て、ツール出力の処理、オーケストレーション、検証方法は、トークン消費とタスク結果の双方を大きく左右し得ます。研究のポジションペーパーでも、同程度に能力の高いモデルを使う長期タスクでは、コンテキスト構築、ツール連携、オーケストレーション、検証を担うハーネスのほうが、モデルの違い以上に性能差の要因になり得ると論じられています。17

とはいえ、これらはAWSが報告したベンチマークです。The Registerは、汎用ハーネスをコーディングエージェントと比較した点に触れ、評価についてAWSが「自分で宿題を採点している」と表現しました。3 これは結果が誤りだと示すものではありませんが、どのエージェント業務でもStrandsが安価または高性能になるという独立した証拠でもありません。

社内評価では、少なくとも以下を揃えて比較する必要があります。

• 使用モデルとプロンプト
• タスクセットとツール
• 権限範囲とリトライ方針
• レイテンシー目標
• コストの集計方法

また、見るべき費用は入出力トークンだけではありません。ツール呼び出し、ストレージ、インフラ、人によるレビュー、失敗処理、誤操作が生むコストも含めて判断する必要があります。

どんなチームに向くか

Strands Harnessは、実際のツール利用と状態保持を備えた汎用エージェントを早く立ち上げつつ、モデルと配備先の選択肢を残したい開発者に向きます。特に、ローカルの概念実証を、メモリ、ツール統合、コンテキスト制御、クラウド配備経路を持つサービスへ進める際、作り直しが大きくなりそうなケースで価値を発揮しやすいでしょう。57

AWSのベンチマーク数値は購入判断の予測値ではなく、検証すべき仮説として扱うのが適切です。まずは限定した用途のエージェントをサンドボックス内で動かし、本当に必要なツールだけを与える。そのうえで、代表的な業務に対する成功率、レイテンシー、総コストを測定し、本番向けの統制が整ってから段階的に昇格させるべきです。

「モデルのデモ」から「運用するエージェント」までの隙間を埋める

AWSのオープンソースプロジェクト Strands Harness は、ローカル環境で動いたAIエージェントの試作を、配備可能なアプリケーションへ持ち込む際に必要となる周辺機能をまとめた基盤です。

LLMを選び、タスクを与えるだけでエージェントらしい対話は作れます。しかし実用化には、コンテキストの扱い、ツール呼び出し、状態の保持、権限、実行制限、監視といった仕組みが必要です。Strands HarnessはStrandsエコシステム上にこれらの共通部品を用意し、ローカル実行にも任意のクラウドプロバイダーへの配備にも使えるものとして提供されています。AWS専用のランタイムをうたうものではありません。7

モデルの周囲に何を用意するのか

Strands Harnessには、あらかじめ次の機能が組み込まれています。

• ファイル操作
• シェルコマンド実行
• Webツール
• コンテキスト管理
• 永続セッションとメモリ
• プロンプトキャッシュ
• 複数エージェント間の委任

5

重要なのは、これらが「モデルそのもの」ではなく、モデルをエージェントとして動かすための実行層である点です。ローカルでの実験からアプリケーション化へ進むとき、開発者は通常、ツール連携、会話・作業状態、長い入力の整理、役割分担などを個別に組み立てる必要があります。共通のハーネスを使えば、モデル提供元や実行環境を変えても、ツールと状態の設計をなるべく保ちやすくなります。

Strandsは、外部ツールに接続するためのオープン標準 Model Context Protocol（MCP） もサポートします。MCPを利用すれば、エージェント本体に連携コードを個別実装し続けなくても、承認済みの社内システムや外部サービスをツールとして接続できます。基盤となるStrands SDKはプロバイダーを差し替えられる設計で、Amazon Bedrock、Anthropic API、OpenAI、Ollamaなどのローカル／オープンソースモデルを含む選択肢に対応します。15

ローカル試作からクラウド配備まで

基本的な流れは、ローカルでエージェントを試作し、PythonまたはTypeScriptのプロジェクトとして構成・テストしたうえで、配備先に応じた設定を加えるというものです。リリースの報道では、AWS、Google Cloud、Microsoft Azure、Cloudflare、Modal、ローカル環境向けの配備設定を生成するためのガイダンスが案内されています。6

ただし、これは「ワンクリックで本番運用可能」という意味ではありません。実運用に移すなら、ハーネスとは別に、組織ごとのセキュリティと運用設計が不可欠です。

• エージェントには、業務に必要な最小限のファイル、シェル、ネットワーク、データ権限だけを与える。
• シークレットやプロバイダー認証情報を、プロンプトやソースコードの管理対象に置かない。
• MCPサーバーと外部ツールも、信頼境界の一部として評価する。
• インフラ変更、メッセージ送信、本番データの更新といった影響の大きい操作には、承認フローまたはサンドボックスを設ける。
• 本番で使う前に、ログ、監視、テスト、対象業務に即した評価を追加する。

Strands Harnessは統合作業を減らせますが、アクセス制御、許容リスク、信頼性の基準を決めてくれるわけではありません。

Strands CLIで始める

公式クイックスタートでは、CLIにNode.js 20以降が必要です。対話型セットアップでPythonかTypeScriptを選び、使用するモデルプロバイダーを設定できます。PythonプロジェクトにはPython 3.10以降が必要です。2

# 対話型CLIをインストール
npm install -g @strands-agents/cli

# セットアップアシスタントを起動
strands

Pythonで始める場合、ドキュメントに示されている導入手順は次のとおりです。

python -m venv .venv
source .venv/bin/activate  # Windows: .venv\Scripts\activate
pip install strands-harness

TypeScriptでは、Node.jsプロジェクトを初期化し、現行のクイックスタートに従って@strands-agents/harnessを導入します。2

実務では、対話型セットアップでエージェントの役割、許可するツール、モデルプロバイダー、メモリの要否を定め、まずローカルで実行します。その後、生成または設定したプロジェクトを配備用成果物としてバージョン管理し、テストする進め方が妥当です。CLIの操作や生成フローはリリースごとに変わり得るため、特定のexport／生成コマンドを手順書に固定する前に、strands --helpと最新のクイックスタートを確認してください。2

モデルを選べても、プロバイダー設定は必要

Strandsは複数プロバイダーでの利用を想定していますが、可搬性がプロバイダー固有の設定を不要にするわけではありません。Harness SDKはAmazon Bedrockをデフォルトにしており、選んだモデルを利用するにはAWS認証情報の設定とモデルアクセスの有効化が必要です。12

他のプロバイダーでも、それぞれ認証情報、エンドポイント、料金体系、ポリシー管理を整える必要があります。ローカルモデルやオープンウェイトモデルを用いるチームについては、関連するStrandsのベンチマーク用ハーネス資料でLiteLLMやvLLMといったランタイム経由の利用が説明されています。18

つまり、エージェントの運用設計を単一のモデルベンダーから切り離せる可能性はあります。一方で、モデルまたはランタイムを替えた際には、回答品質、レイテンシー、ツール利用の信頼性を改めてテストすべきです。

AWSの「28％低コスト」はどう読むべきか

AWSは、同じClaudeまたはGPTモデルを使う6つのベンチマークで、Strands Harnessが他のハーネスより28％低コストで、精度はほぼ同等だったと説明しています。7

別の報道では、Claude CodeとCodexに対しては約45％低コスト、DeepSeek Harnessを比較対象に含めた場合は28％という数値が紹介されています。比較対象のグループが異なるため、これらを一つの普遍的な削減率として扱うべきではありません。5

コンテキストの組み立て、ツール出力の処理、オーケストレーション、検証方法は、トークン消費とタスク結果の双方を大きく左右し得ます。研究のポジションペーパーでも、同程度に能力の高いモデルを使う長期タスクでは、コンテキスト構築、ツール連携、オーケストレーション、検証を担うハーネスのほうが、モデルの違い以上に性能差の要因になり得ると論じられています。17

とはいえ、これらはAWSが報告したベンチマークです。The Registerは、汎用ハーネスをコーディングエージェントと比較した点に触れ、評価についてAWSが「自分で宿題を採点している」と表現しました。3 これは結果が誤りだと示すものではありませんが、どのエージェント業務でもStrandsが安価または高性能になるという独立した証拠でもありません。

社内評価では、少なくとも以下を揃えて比較する必要があります。

• 使用モデルとプロンプト
• タスクセットとツール
• 権限範囲とリトライ方針
• レイテンシー目標
• コストの集計方法

また、見るべき費用は入出力トークンだけではありません。ツール呼び出し、ストレージ、インフラ、人によるレビュー、失敗処理、誤操作が生むコストも含めて判断する必要があります。

どんなチームに向くか

Strands Harnessは、実際のツール利用と状態保持を備えた汎用エージェントを早く立ち上げつつ、モデルと配備先の選択肢を残したい開発者に向きます。特に、ローカルの概念実証を、メモリ、ツール統合、コンテキスト制御、クラウド配備経路を持つサービスへ進める際、作り直しが大きくなりそうなケースで価値を発揮しやすいでしょう。57

AWSのベンチマーク数値は購入判断の予測値ではなく、検証すべき仮説として扱うのが適切です。まずは限定した用途のエージェントをサンドボックス内で動かし、本当に必要なツールだけを与える。そのうえで、代表的な業務に対する成功率、レイテンシー、総コストを測定し、本番向けの統制が整ってから段階的に昇格させるべきです。