AWSは2026-08-14、Amazon SageMaker AI上のOpenAI互換エンドポイントとAmazon Bedrock AgentCore runtimeを組み合わせ、開発者がエージェンティックAI（自律型AI）ワークフローを構築する方法を示す技術ガイドを公開した。ワークフローは1つのAgentCoreコンテナでマネージド基盤モデルと、低コスト化または特定領域向けに最適化したモデルを接続し、エージェントフレームワークを書き直さずに専門エージェント同士を連携させる。例ではQwen 3.5 9BをSageMaker AIにデプロイし、Amazon Bedrockモデルを使うStrands Agentsのマルチエージェントシステムへ統合したうえで、AgentCore runtimeに配置する。

サンプル構成には3つのモデルホスティング経路がある。オーケストレーターエージェントはBedrock上のClaude Haiku 4.5を使い、ユーザー意図を分類してGlobal cross-Region inference経由でタスクを振り分ける。予算エージェントはBedrock上のClaude Sonnet 4.6を使い、50/30/20の予算配分を構造化されたPydantic出力で処理する。金融分析エージェントはSageMaker AIのリアルタイムエンドポイント上のQwen 3.5 9Bを使い、ツール呼び出しを伴う株式分析とポートフォリオ構築を担う。

ユーザーリクエストはAmazon Bedrock AgentCore runtime内のオーケストレーターに入り、Strands Agentsの「agents as tools」パターンによって、予算エージェントまたは金融分析エージェントへ処理が回される。予算エージェントはAmazon Bedrock経由でClaude Sonnet 4.6を呼び出す。金融分析エージェントはSageMaker AIのOpenAI互換API経由でQwen 3.5 9Bを呼び出し、結果はオーケストレーターを通じてユーザーに返る。

ガイドは前提条件として、Amazon SageMaker AI、Amazon Bedrock、AgentCoreの権限を持つAWSアカウント、Python 3.12+、Claude Haiku 4.5とClaude Sonnet 4.6のBedrockモデルアクセス、sagemaker:InvokeEndpointとsagemaker:CallWithBearerTokenを持つIAMロールを挙げた。セットアップではsagemaker-core、openai、httpx、strands-agents[otel]、yfinance、pydantic、bedrock-agentcoreをインストールする。Qwen 3.5 9Bは、vLLM Deep Learning Containerイメージvllm:0.22.1-gpu-py312-cu130を使い、ml.g6e.2xlarge上にデプロイされる。

主要な実装課題は可観測性だ。Amazon Bedrock AgentCore runtimeはOpenTelemetryでエージェントを自動計装し、Bedrockモデル呼び出しにはトークン数を含む完全な生成AIスパンが付く。一方、Strands OpenAIModel経由で使うSageMakerのOpenAI互換エンドポイントにはトークンの自動テレメトリーが付かないため、金融分析エージェントのトークン使用量がトレース上で見えなくなり、コスト監視、回帰検知、レイテンシーデバッグが制限される可能性がある。

原因は、StrandsのOTEL統合がツール呼び出しとエージェントのライフサイクルイベントについてスパンを出す一方、OpenAIModelプロバイダー向けにはトークン属性を持つgen_ai.chatスパンを出さない点にある。ガイドの修正策は、SageMakerエージェント呼び出しの周囲でgen_ai.chatスパンを手動発行し、AgentResult.metrics.accumulated_usageからトークン使用量を読む方法だ。Strandsは、プロバイダーが使用量データを返す場合、inputTokens、outputTokens、totalTokensにトークン使用量を保存する。

ガイドは、vLLMストリーミングではstream_options: {"include_usage": true}が必須だとしている。vLLMはデフォルトで使用量チャンクを含めないため、この設定がないとStrandsはテキストチャンクだけを受け取り、最終的な使用量オブジェクトを得られない。accumulated_usageはゼロのままで、カスタムスパンは0トークンを報告する。手順ではAmazon CloudWatch Transaction Searchを有効化し、AGENT_OBSERVABILITY_ENABLED=trueを設定し、コンテナCMDとしてopentelemetry-instrumentを使い、SageMakerエージェント呼び出しの周囲にカスタムスパンを作成する。

ガイドは複数の運用上の知見を報告した。ClaudeまたはAmazon NovaのBedrock呼び出しには追加作業が不要で、SageMaker OpenAIエンドポイントには手動スパンが必要となる。vLLMではトークン使用量のためにstream_optionsが必要で、AWS X-Rayのデフォルト1 percentサンプリングは大半のトレースを落とすため、開発中は100 percentサンプリングが有用だ。リクエストごとに新しいエージェントインスタンスを使うと、同時呼び出しエラーを避けられる。同じパターンは、Amazon S3からファインチューニング済みモデルへ差し替える、同じSageMakerエンドポイントでベースモデルとファインチューニング版をA/Bテストする、単純な検索をHaikuへ回し、複数ステップの推論タスクにはSageMaker GPUエンドポイントを確保する、といった形に拡張できる。

AWSは2026-08-14、Amazon SageMaker AI上のOpenAI互換エンドポイントとAmazon Bedrock AgentCore runtimeを組み合わせ、開発者がエージェンティックAI（自律型AI）ワークフローを構築する方法を示す技術ガイドを公開した。ワークフローは1つのAgentCoreコンテナでマネージド基盤モデルと、低コスト化または特定領域向けに最適化したモデルを接続し、エージェントフレームワークを書き直さずに専門エージェント同士を連携させる。例ではQwen 3.5 9BをSageMaker AIにデプロイし、Amazon Bedrockモデルを使うStrands Agentsのマルチエージェントシステムへ統合したうえで、AgentCore runtimeに配置する。

サンプル構成には3つのモデルホスティング経路がある。オーケストレーターエージェントはBedrock上のClaude Haiku 4.5を使い、ユーザー意図を分類してGlobal cross-Region inference経由でタスクを振り分ける。予算エージェントはBedrock上のClaude Sonnet 4.6を使い、50/30/20の予算配分を構造化されたPydantic出力で処理する。金融分析エージェントはSageMaker AIのリアルタイムエンドポイント上のQwen 3.5 9Bを使い、ツール呼び出しを伴う株式分析とポートフォリオ構築を担う。

ユーザーリクエストはAmazon Bedrock AgentCore runtime内のオーケストレーターに入り、Strands Agentsの「agents as tools」パターンによって、予算エージェントまたは金融分析エージェントへ処理が回される。予算エージェントはAmazon Bedrock経由でClaude Sonnet 4.6を呼び出す。金融分析エージェントはSageMaker AIのOpenAI互換API経由でQwen 3.5 9Bを呼び出し、結果はオーケストレーターを通じてユーザーに返る。

ガイドは前提条件として、Amazon SageMaker AI、Amazon Bedrock、AgentCoreの権限を持つAWSアカウント、Python 3.12+、Claude Haiku 4.5とClaude Sonnet 4.6のBedrockモデルアクセス、sagemaker:InvokeEndpointとsagemaker:CallWithBearerTokenを持つIAMロールを挙げた。セットアップではsagemaker-core、openai、httpx、strands-agents[otel]、yfinance、pydantic、bedrock-agentcoreをインストールする。Qwen 3.5 9Bは、vLLM Deep Learning Containerイメージvllm:0.22.1-gpu-py312-cu130を使い、ml.g6e.2xlarge上にデプロイされる。

主要な実装課題は可観測性だ。Amazon Bedrock AgentCore runtimeはOpenTelemetryでエージェントを自動計装し、Bedrockモデル呼び出しにはトークン数を含む完全な生成AIスパンが付く。一方、Strands OpenAIModel経由で使うSageMakerのOpenAI互換エンドポイントにはトークンの自動テレメトリーが付かないため、金融分析エージェントのトークン使用量がトレース上で見えなくなり、コスト監視、回帰検知、レイテンシーデバッグが制限される可能性がある。

原因は、StrandsのOTEL統合がツール呼び出しとエージェントのライフサイクルイベントについてスパンを出す一方、OpenAIModelプロバイダー向けにはトークン属性を持つgen_ai.chatスパンを出さない点にある。ガイドの修正策は、SageMakerエージェント呼び出しの周囲でgen_ai.chatスパンを手動発行し、AgentResult.metrics.accumulated_usageからトークン使用量を読む方法だ。Strandsは、プロバイダーが使用量データを返す場合、inputTokens、outputTokens、totalTokensにトークン使用量を保存する。

ガイドは、vLLMストリーミングではstream_options: {"include_usage": true}が必須だとしている。vLLMはデフォルトで使用量チャンクを含めないため、この設定がないとStrandsはテキストチャンクだけを受け取り、最終的な使用量オブジェクトを得られない。accumulated_usageはゼロのままで、カスタムスパンは0トークンを報告する。手順ではAmazon CloudWatch Transaction Searchを有効化し、AGENT_OBSERVABILITY_ENABLED=trueを設定し、コンテナCMDとしてopentelemetry-instrumentを使い、SageMakerエージェント呼び出しの周囲にカスタムスパンを作成する。

ガイドは複数の運用上の知見を報告した。ClaudeまたはAmazon NovaのBedrock呼び出しには追加作業が不要で、SageMaker OpenAIエンドポイントには手動スパンが必要となる。vLLMではトークン使用量のためにstream_optionsが必要で、AWS X-Rayのデフォルト1 percentサンプリングは大半のトレースを落とすため、開発中は100 percentサンプリングが有用だ。リクエストごとに新しいエージェントインスタンスを使うと、同時呼び出しエラーを避けられる。同じパターンは、Amazon S3からファインチューニング済みモデルへ差し替える、同じSageMakerエンドポイントでベースモデルとファインチューニング版をA/Bテストする、単純な検索をHaikuへ回し、複数ステップの推論タスクにはSageMaker GPUエンドポイントを確保する、といった形に拡張できる。