3行まとめ
このテーマをもう少し広げて見るなら、AWS Step FunctionsのAgentCore推論ステップとは：AIエージェントをワークフローに組み込む前に確認すべきこと と AWS ConfigがBedrock AgentCore/SageMaker系9リソースに対応：AI基盤の設定監査で確認すべきこと も合わせて確認してください。マルチターンRLで改善したエージェントを、業務ワークフローへ組み込む段階の確認点につながります。
単発の回答だけでなく、エージェントがツールや環境とやり取りした過程を学習対象にします。
発表時点では、対応モデルと利用できるリージョンの組み合わせが限られています。
最終回答だけでなく、trajectory、tool選択、失敗回復、安全制約、コストを分けて見ます。
PoCに入る前に、対応モデル、リージョン、エージェント環境、reward、評価指標を一続きで確認します。
Amazon SageMaker AIで、AIエージェントの複数手順タスクを対象にしたmulti-turn reinforcement learningが発表されました。単発の回答精度だけでなく、ツール呼び出し、再試行、途中判断を含む行動の軌跡を学習・評価するための機能です。
2026年6月4日時点の公式発表では、Amazon Bedrock AgentCore Runtime、Amazon EKS、Amazon EC2、AWS Fargate、任意の基盤上で動くエージェント環境と接続でき、SageMaker AIがrollout orchestration、trajectory collection、training、checkpoint管理を担うとされています。
導入判断では、対応モデルとリージョン、reward設計、評価セット、MLflow tracking、デプロイ先、料金確認を分けて見る必要があります。特に料金は公式発表とPricingページで表現が異なるため、見積もり前に最新のPricingとAWSコンソールで再確認してください。
AWSは2026年6月3日、Amazon SageMaker AIのmodel customizationでmulti-turn reinforcement learningを利用できるようになったと発表しました。日本語で短く言えば、AIエージェントが複数の手順を踏んで仕事を進める場面に合わせ、モデルを強化学習で調整するための機能です。
これまでのモデルカスタマイズは、正解例を与えるSFT、好ましい回答を選ばせるDPO、検証可能な報酬を使うRLVR、AIフィードバックを使うRLAIFといった選択肢で語られることが多くありました。今回のポイントは、エージェントが環境とやり取りしながら進めた一連の行動、つまりtrajectoryを評価対象にできることです。検索、API呼び出し、途中の判断、エラーからの回復、最終回答までをまとめて見る必要があるチームには、試す価値があります。
一方で、これは「エージェントを作れば自動的に賢くなる」機能ではありません。rewardをどう定義するか、どの失敗を減点するか、ツール呼び出しの無駄をどう測るか、評価セットをどう固定するかが結果を左右します。すでに<a href="https://amzn-watch.blog.mo-gmo.com/amzn-21-agentcore-identity-secrets-manager/" rel="noopener">Amazon Bedrock AgentCore Identityの認証情報管理</a>や<a href="https://amzn-watch.blog.mo-gmo.com/amzn-19-bedrock-mantle-cloudwatch-metrics/" rel="noopener">Bedrock MantleのCloudWatchメトリクス</a>を追っている読者なら、今回の発表は「モデルをどう動かすか」から一歩進んで、「エージェントの行動品質をどう学習させるか」を見る材料になります。
本稿はAmazonおよびAWSとは非提携のAmazon Watch Japanによる整理です。投資助言ではなく、開発者、導入企業、調査担当者が一次情報を読むための確認メモとして扱ってください。
Amazon SageMaker AIのマルチターンRLで何が変わるのか
- 1従来の単発評価
prompt、answer、scoreを中心に、最終出力の良し悪しを見ます。
- 2エージェント実行
promptからagentが動き、tool、API、社内データ、検証用実行環境と複数回やり取りします。
- 3trajectoryを記録
どの手順で何を参照し、どの操作に進んだかを学習と評価の材料にします。
- 4rewardを反映
成功条件、禁止条件、無駄な呼び出し、途中回復をrewardに落とし込みます。
- 5model customization
複数手順タスクに近い行動を、SageMaker AIのカスタマイズ工程で改善します。
Bedrock AgentCoreそのものの紹介ではなく、SageMaker AIのmodel customizationとして捉えると位置づけが整理しやすくなります。
今回の発表でまず押さえたいのは、SageMaker AIのmodel customizationの話であり、Bedrock AgentCoreそのものの新機能紹介ではないという点です。AgentCore Runtimeは接続先のひとつとして出てきますが、主役はSageMaker AI側でモデルをカスタマイズする仕組みです。
AWSの発表では、multi-turn RLはmulti-step、agentic tasks向けのserverless model customization techniqueと説明されています。SageMaker AI model customizationでは、SFT、RLVR、RLAIFなどの手法で基盤モデルを調整でき、今回のmulti-turn RLはエージェント環境に対してモデルを動かし、複数手順の意思決定全体に報酬を与える流れです。
単発回答ではなく、タスクの軌跡を学習対象にする
根拠
通常のチャット評価では、最終的な回答が正しいか、文体が適切か、指示に従ったかを見ます。multi-turn RLで見たいのは、それだけではありません。
注意点
たとえば社内の運用エージェントが障害調査を行う場合、正しい最終報告だけでなく、最初にどのログを見るか、不要なAPIを呼ばないか、権限外の操作を試みないか、途中で失敗したときに安全に戻れるかが問題になります。ECサイトの商品調査エージェントなら、検索語をどう変えるか、在庫や価格の古い情報をどう扱うか、条件に合わない商品を候補から外せるかが品質になります。
AWS発表では、SageMaker AIがrollout orchestration、trajectory collection、training、checkpoint managementを管理するとされています。ここでいうtrajectoryは、エージェントが環境とやり取りした一連の履歴です。最終回答だけを採点するより、途中の行動を含めて評価できるため、業務に近いタスクをモデル調整へ戻しやすくなります。
SFT、DPO、RLVR、RLAIFとはどこが違うのか
使い分け
SFTは、望ましい入力と出力の例を学習させる方法です。回答の形式、専門用語、社内ルールの反映には向いていますが、複数のツールを使いながら試行錯誤する行動そのものを評価するには限界があります。
DPOは、どちらの回答が好ましいかという比較を使う方法です。文体や方針の調整では有効でも、エージェントが途中でどの手順を選んだかまでは見えにくいままです。
RLVRやRLAIFはrewardを使う点でmulti-turn RLに近い考え方を持ちます。ただし、今回の発表で重要なのは、単一の出力だけでなく、エージェント環境上での複数手順を対象にすることです。モデルがツールを呼ぶ、環境が結果を返す、モデルが次の行動を選ぶ、その流れに対して報酬を設計します。
見送る条件
そのため、すべてのチームがいきなりmulti-turn RLへ進む必要はありません。単発の分類、要約、フォーマット変換が中心なら、SFTやプロンプト改善で足りる可能性があります。multi-turn RLを検討しやすいのは、タスクの成功が「途中の行動品質」に左右され、かつその行動を再現可能なテスト環境で評価できる場合です。
まず確認するのは対応モデルとリージョン
モデル名、バージョン、リージョン、カスタマイズ手法の対応状況は変わり得るため、PoC開始直前に公式情報と実画面を照合します。
PoCに入る前に、対応モデルとリージョンを確認してください。ここを飛ばすと、評価設計やデータ準備まで進んだあとに、希望のモデルが対象リージョンにない、既存のデータ所在地要件と合わない、デプロイ先の前提が違う、といった手戻りが起きます。
2026年6月4日時点で確認したAWS発表では、multi-turn RLはSageMaker StudioとSageMaker Python SDKから利用でき、Amazon SageMaker AI model customizationの一部として提供されています。
発表時点の対応モデル
確認項目
AWS発表では、us-west-2でQwen 3.6 27B、Nova Lite 2.0、GPT-OSS-20B、Gemma 31Bが挙げられています。us-east-1では、Nova Lite 2.0とGPT-OSS-20Bが挙げられています。
注意点
この一覧は、モデル選定の入口としては使えます。ただし、モデル名、バージョン、リージョン、カスタマイズ手法の対応状況は短期間で変わることがあります。記事や社内メモに固定して終わりにせず、PoCを始める直前にAWSのWhat’s New、SageMaker AIドキュメント、SageMaker Studioの画面、SDKの対応状況を照合してください。
モデルの選び方は、単純な性能比較だけでは決まりません。エージェントが扱う言語、ツール呼び出しの安定性、社内の監査要件、Bedrockとの使い分け、推論先のコスト、リージョンの制約を合わせて見る必要があります。Bedrock上の既存モデル利用との違いを整理したい場合は、<a href="https://amzn-watch.blog.mo-gmo.com/amzn-15-claude-opus-48-aws-bedrock-platform/" rel="noopener">Claude Opus 4.8のAWS提供開始記事</a>や<a href="https://amzn-watch.blog.mo-gmo.com/amzn-14-openai-codex-bedrock-ga/" rel="noopener">OpenAI/Codex on Bedrockの記事</a>も比較材料になります。
us-west-2とus-east-1で選択肢が変わる
条件
AWSの発表文を見る限り、発表時点ではus-west-2とus-east-1で対応モデルの選択肢が異なります。これは、日本企業が検証する場合にも無視できません。
既存のS3データ、評価ログ、エージェント環境、Bedrockの利用リージョン、社内のデータ所在地ルールがどこにあるかで、最初に選べる構成が変わります。米国リージョンでPoCを行えるチームなら候補が広がる一方、日本リージョンや特定リージョンでの処理を前提にするチームは、一般提供や対応リージョンの拡大を待つ判断もあり得ます。
分岐
希望モデルが対象リージョンにない場合は、モデルを変える、リージョンを変える、通常のSFTやDPOへ戻す、Bedrockで既存モデルを使う、SageMaker endpointsで別の運用を検討する、といった分岐になります。この分岐をPoC計画書の最初に置いておくと、後工程の期待値を合わせやすくなります。
エージェント環境とreward設計をどう用意するか
- 1エージェント環境を選ぶ
AgentCore Runtime、EKS、EC2、Fargate、任意の基盤から、検証に使う実行環境を決めます。
- 2ツール境界を切る
Secrets Manager、OAuth、社内API、S3、DynamoDB、Lambdaなどへのアクセスを検証用に分けます。
- 3rolloutを実行する
代表タスクを流し、エージェントがどの手順で環境とやり取りしたかを記録します。
- 4rewardを計算する
成功条件、禁止条件、再試行、API制限、無駄な呼び出しを採点に反映します。
- 5MLflowで追跡する
trajectory、reward、trace、評価結果を実験ごとに比較できる状態にします。
rewardがずれると、採点上は良くても現場では使いにくい行動を学ぶため、成功条件と禁止条件を同じ粒度で決めます。
multi-turn RLで難しいのは、モデルを選ぶことよりも、エージェント環境とrewardを用意することです。AWS発表では、AgentCore Runtimeでホストされたエージェント、Amazon EKS、Amazon EC2、AWS Fargate、または任意の基盤上で動くエージェントを接続できると説明されています。つまり、SageMaker AIだけで閉じる話ではありません。
AgentCore Runtimeを使う場合
確認項目
Amazon Bedrock AgentCore Runtimeは、AIエージェントやツールをデプロイ、スケール、分離するためのサーバーレス実行環境です。AWSドキュメントでは、Runtimeがスケーリング、セッション管理、セキュリティ分離、インフラ管理を扱うと説明されています。今回のSageMaker AI multi-turn RLでは、こうした実行環境で動くエージェントを学習ループに接続する選択肢があります。
注意点
この構成を選ぶ場合、確認すべきことは大きく三つあります。
一つ目は、エージェントが実際にどのツールや外部APIへアクセスするかです。Secrets Manager、OAuth、社内API、S3、DynamoDB、Lambdaなどに触れる場合、学習時のrolloutが本番データや本番操作へ誤って向かわないように境界を切る必要があります。
二つ目は、認証と監査です。AgentCore IdentityやSecrets Managerをどう使うか、学習用の実行ロールを本番ロールと分けるか、CloudTrailやCloudWatchでどこまで追跡するかを先に決めます。認証情報の扱いは本稿の主題ではないため、詳しくは<a href="https://amzn-watch.blog.mo-gmo.com/amzn-21-agentcore-identity-secrets-manager/" rel="noopener">AgentCore Identityが既存Secrets Manager参照に対応した記事</a>を参照してください。
三つ目は、失敗時の扱いです。エージェントが途中でAPI制限に当たった、外部サービスが失敗した、想定外のツールを呼んだ、同じ処理を繰り返した、といったケースをrewardにどう反映するかを決めます。最終回答だけを見て高得点にすると、余計な呼び出しや危うい途中行動を見落とします。
Bring your own agent環境を使う場合
条件
AWS発表では、AgentCore Runtime以外にも、EKS、EC2、Fargate、任意のインフラで動くエージェント環境を接続できるとされています。既存のLangGraph、CrewAI、独自フレームワーク、社内の検証ハーネスを使っているチームには、この選択肢が重要です。
ただし、bring your own agent環境では、環境側の責務が増えます。状態管理、失敗処理、再試行、ログ保存、reward計算、テストデータのリセット、外部APIのモック、実行時間の制御を自分たちで整える必要があります。公式ドキュメントでは、RFT evaluationの文脈でcustom reward functionsやLambdaによる採点が説明されており、multi-turn trainingでは環境と報酬設計の切り分けを慎重に見る必要があります。
評価基準
reward設計では、成功条件と禁止条件を同じくらい具体化してください。たとえば、問い合わせ対応エージェントなら「正しい回答を出す」だけでなく、「個人情報を余計に参照しない」「根拠のない返答をしない」「確認が必要な場合は人間に渡す」「同じAPIを無駄に連打しない」といった条件を入れます。運用エージェントなら、「復旧手順を提案する」だけでなく、「変更操作は承認なしに実行しない」「読み取り専用の調査で止める」「アラートの原因を複数候補で残す」などが評価に入ります。
rewardがずれていると、モデルは「採点上は良いが現場では使いにくい行動」を学びます。multi-turn RLの価値はここで決まります。
評価は最終回答ではなく軌跡で見る
RFT evaluationのsingle-turn制約と、multi-turn RLで扱うtrajectory評価は同じものとして読まない方が安全です。
エージェントの品質評価では、最終回答だけを見ても足りません。途中でどの情報を参照したか、どのツールを選んだか、失敗をどう扱ったか、無駄な呼び出しをどれだけ減らせたか、禁止操作に近づかなかったかを見ます。
AWS発表では、MLflow trackingでagent trajectories、rewards、tracesを確認できるとされています。また、evaluation jobsではreward、pass@k、trajectory metricsを報告し、SageMaker AI endpointまたはAmazon Bedrockへデプロイする前にbenchmarkできるとされています。
MLflow trackingとevaluation jobsで確認する
確認項目
導入前のPoCでは、評価セットを固定してください。毎回違うタスクを流して「なんとなく良くなった」と判断すると、学習効果と偶然を分けられません。最低限、同じタスクセットでベースモデル、プロンプト改善後、SFT後、multi-turn RL後を比較できる状態を作ります。
見るべき指標は、タスク成功率だけではありません。正しいツールを選んだ割合、不要なツール呼び出し、途中失敗からの回復、禁止操作の未遂、最終回答の根拠、実行時間、推論・外部API・学習にかかるコストを分けて記録します。
判断基準
MLflow trackingは、モデルカスタマイズの実験を追ううえで重要です。SageMaker AIの製品ページでも、training metricsやevaluation resultsをMLflow on SageMaker AIで追跡できることが説明されています。これを使うなら、単に画面で眺めるのではなく、社内の判断基準に合わせて「合格」「再学習」「reward修正」「プロンプトに戻す」を切り分ける運用表に落としてください。
single-turn評価の限界とmulti-turn評価の分担
注意点
SageMaker AIのRFT evaluationドキュメントには、custom reward functionsでモデルの出力を評価する考え方が説明されています。一方で、同ドキュメントの現在の制限として、single-turn conversationsのみをサポートするという記載もあります。
この点は、multi-turn RLの記事で混同しやすい部分です。RFT evaluationのsingle-turn制約と、今回のmulti-turn RLで扱うエージェント環境上のtrajectory評価は、同じものとして読まない方が安全です。自社のPoCでは、公式発表で述べられているevaluation jobs、trajectory metrics、MLflow trackingが、どの範囲でmulti-turnの実行履歴を見せるのかを実機で確認してください。
評価基準
合格基準は、最終回答の正しさだけにしないでください。たとえば次のように分けると、rewardの調整先が見えやすくなります。
| 評価項目 | 見ること | 失敗時に戻す場所 |
|---|---|---|
| タスク成功率 | 最終目標を満たしたか | training data、reward、モデル選定 |
| ツール選択 | 必要なAPIや検索だけを使ったか | プロンプト、tool schema、reward |
| 途中回復 | API失敗や欠損情報から戻れたか | agent environment、retry設計 |
| 安全制約 | 権限外操作や禁止情報参照を避けたか | IAM、環境分離、reward |
| コスト | 無駄な呼び出しや長い軌跡が増えていないか | reward、stop条件、モデル選定 |
| 説明可能性 | 何を根拠に判断したか追えるか | logging、MLflow、trace設計 |
この表を最初から用意しておくと、multi-turn RLを「精度が上がったか」だけでなく、「現場で運用できる行動に近づいたか」で評価できます。
料金・デプロイ・運用で最後に詰める
料金表現や課金軸は確認時点で変わる可能性があるため、PoCや予算申請の直前にPricing、Studio、請求表示、AWS窓口で最新条件を確認します。
multi-turn RLはサーバーレスで提供されると説明されていますが、料金と運用負荷が消えるわけではありません。学習、評価、推論、ログ、外部API、ストレージ、ネットワーク、監視は別々に見積もる必要があります。
ここで注意したいのは、2026年6月4日時点で確認した公式ページの料金表現です。AWSの発表文では、multi-turn RLはfully serverless capabilityであり、tokens processedに対して支払うという趣旨の説明があります。一方、SageMaker AI PricingのModel Customization欄では、SFTとDPOはtraining中に処理されたtokensに基づく課金、RL customizationはtraining job durationに基づく課金と説明されています。
この二つは、読み方によっては異なる課金軸に見えます。そのため、本稿では具体的な料金表や単価を断定しません。PoCや予算申請に入る前に、SageMaker AI PricingのModel Customizationタブ、SageMaker Studioの見積もり、AWSアカウント側の請求表示、必要であればAWS窓口で最新条件を確認してください。
customizationと推論を分けて見積もる
見積もり項目
費用は、少なくとも次の項目に分けてください。
| 項目 | 確認すること |
|---|---|
| モデルカスタマイズ | training job、処理量、duration、対象モデルごとの単価 |
| 評価 | evaluation job、custom scorer、LLM-based evaluator、Lambda利用 |
| 推論 | SageMaker endpointに置くか、Amazon Bedrockへデプロイするか |
| エージェント環境 | AgentCore Runtime、EKS、EC2、Fargate、外部API |
| 観測 | MLflow tracking、CloudWatch Logs、メトリクス、trace保存 |
| データ | S3、KMS、VPC、データ転送、ログ保持期間 |
注意点
この分解をせずに「サーバーレスだから安い」と見ると危険です。とくにエージェントは、失敗時に何度もツールを呼び、長いtrajectoryを作りがちです。rewardで無駄な呼び出しを減らす設計は、品質だけでなく費用にも効きます。
Bedrockへ置くか、SageMaker endpointsへ置くか
条件
AWS発表では、評価後のデプロイ先としてSageMaker AI endpointまたはAmazon Bedrockが挙げられています。どちらを選ぶかは、既存の運用基盤で変わります。
Bedrockへ置く場合は、既存のBedrockアプリ、IAM、監査、モデル利用方針、ほかのBedrockモデルとの使い分けを見ます。SageMaker endpointsへ置く場合は、既存のSageMaker運用、VPC、Auto Scaling、Model Monitor、MLOpsパイプライン、推論レイテンシを見ます。
戻し方
判断を急がない方がよいのは、デプロイ先を決める前にrewardや評価セットが固まっていないケースです。モデルをどこへ置くかより、何を合格にするかが曖昧なままでは、運用後に戻す場所が見えません。
どのチームがPoCに進むべきか
社内ヘルプデスク、SRE支援、購買調査、契約レビュー、データ抽出、コード修正支援など、環境とやり取りする業務がある状態です。
代表タスクをJSONLや評価ハーネスで固定し、ベースモデル、プロンプト改善後、SFT後、multi-turn RL後を比べられます。
成功条件と失敗条件を、最終回答だけでなく途中行動にも結びつけられます。
外部APIやツールを本番データ、本番権限、本番操作から切り離して呼べます。
単発の要約や分類に近い、評価基準が曖昧、ログを残せない、料金やリージョンの制約が大きい場合は、プロンプト改善、tool schema、SFT、DPO、通常の評価ジョブ、Bedrockの既存モデル利用を先に検討します。
multi-turn RLは、評価できないタスクを自動で評価可能にする機能ではなく、評価できる形にした行動を学習へ戻すための選択肢です。
multi-turn RLは、AIエージェントを本番に近づけたいチームにとって魅力的です。ただし、PoCに進みやすい条件と、先に別の改善を試すべき条件があります。
PoCに進みやすい条件
進める条件
PoCに進みやすいのは、複数手順タスクがすでに明確なチームです。たとえば、社内ヘルプデスク、SRE支援、購買調査、契約レビュー、データ抽出、コード修正支援など、エージェントが環境とやり取りしながら進める業務がある場合です。
そのうえで、次の条件がそろうほど試しやすくなります。
- 代表的なタスクセットをJSONLや評価ハーネスで固定できる。
- 成功条件と失敗条件をrewardに落とせる。
- 外部APIやツールを安全な検証用実行環境で呼べる。
- 対象モデルとリージョンが要件に合う。
- 失敗時にプロンプト、reward、training data、環境のどこへ戻すかを決めている。
- MLflowやCloudWatchで、trajectoryとコストを追える。
この条件がそろっているなら、multi-turn RLは単なる新機能チェックではなく、エージェントの運用品質を上げる実験になります。
先に別手段を試す条件
見送る条件
見送った方がよいケースもあります。タスクが単発の要約や分類に近い、評価基準がまだ曖昧、外部ツールの安定性が低い、ログを残せない、料金見積もりができない、対象リージョンに制約がある、といった場合です。
この場合は、まずプロンプト改善、tool schemaの整理、SFT、DPO、通常の評価ジョブ、Bedrockの既存モデル利用を試した方が早いことがあります。multi-turn RLは、評価できないタスクを魔法のように評価可能にする機能ではありません。評価できる形にしたうえで、その評価を学習へ戻すための選択肢です。
Amazon Watch Japanとしては、今回の発表は「AIエージェント本番化の次の確認点」と見ています。モデルが賢いかどうかだけではなく、環境とやり取りする行動をどう測り、どう改善するかが焦点になるためです。2026年6月のAmazon/AWS重要トピックは<a href="https://amzn-watch.blog.mo-gmo.com/monthly-topics-2026-06/" rel="noopener">月次まとめ</a>にも追記していきます。
次に読むなら
参照した主な情報源
- Amazon SageMaker AI launches multi-turn reinforcement learning for AI agent model customization – AWS What’s New（確認日: 2026年6月4日）
https://aws.amazon.com/about-aws/whats-new/2026/06/multi-turn-reinforcement-learning-on-sagemaker-ai/
- Customizing models with Amazon SageMaker AI – Amazon SageMaker AI Developer Guide（確認日: 2026年6月4日）
https://docs.aws.amazon.com/sagemaker/latest/dg/customize-model.html
- Model Customization with Amazon SageMaker AI – AWS製品ページ（確認日: 2026年6月4日）
https://aws.amazon.com/sagemaker/ai/model-customization/
- Amazon SageMaker AI pricing – Model Customization（確認日: 2026年6月4日）
https://aws.amazon.com/sagemaker/ai/pricing/
- RFT evaluation – Amazon SageMaker AI Developer Guide（確認日: 2026年6月4日）
https://docs.aws.amazon.com/sagemaker/latest/dg/nova-hp-evaluate-rft.html
- Overview – Amazon Bedrock AgentCore Developer Guide（確認日: 2026年6月4日）
https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/index.html
更新履歴: 2026年6月4日、AWS What’s New、SageMaker AI Developer Guide、SageMaker AI Pricing、Bedrock AgentCore Developer Guideを確認して初稿を作成しました。料金は公式ページ間で表現差が見えるため、単価や最終請求条件は本文で断定していません。