Amazon SageMaker AIにおける多ターン強化学習のベストプラクティス

Amazon SageMaker AI でマルチターンエージェントをトレーニングしてサポートチケットの解決やコンテンツのモデレーションを行う場合、単一の応答ではなく、依存関係のある一連のステップを処理する必要があります。これらのエージェントは指示を読み取り、ツールの呼び出しを行い、結果を確認し、次のアクションを決定し、回答を確定する前にミスを回復します。この柔軟性が、アジェンティックな強化学習（RL）を困難にする要因でもあります。行動の選択肢が増えるほど、タスクを実行せずに報酬を満たす方法も増え、エージェントがトレーニングを行う環境が訓練信号を静かに汚染してしまう可能性があります。 本稿では、信頼できるマルチターン RL トレーニングのためのベストプラクティスをご紹介します。信頼できるトレーニング環境の構築方法、外部評価の設定、エンドタスクと整合した報酬設計、複数ターン実行時の変更点の管理、そして反復を行うべきタイミングを示す指標の監視について解説します。例は、12 のビジネスドメインにわたる複雑な標準作業手順（SOP）に基づいてタスク解決能力を評価する Amazon Science ベンチマークである [SOP-Bench](https://github.com/amazon-science/SOP-Bench) データセットから引用しています。 ## SageMaker AI マルチターン強化学習 [Amazon SageMaker AI マルチターン RL](https://aws.amazon.com/about-aws/whats-new/2026/06/multi-turn-reinforcement-learning-on-sagemaker-ai/)（SageMaker AI MTRL）は、エージェントタスク向けのトレーニングループを提供します。あなたのエージェントは、[Amazon Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)、Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Compute Cloud (Amazon EC2)、AWS Fargate、または選択したインフラ上で実行できます。ツールサーフェスをロールアウトサーバーに公開する小型アダプターを介して接続し、SageMaker AI MTRL が残りの処理を担当します。 - 統合をローコードに保ちつつ、完全なアルゴリズム制御を提供するモジュラー型エージェント・環境インターフェース。カスタム報酬、カスタムツールループ、多ターン会話の形状はすべてユーザーが定義できます。 - インフラストラクチャの懸念を簡素化するサーバーレス実行により、GPU クラスターのプロビジョニングや管理を行わずに、トークン単位の価格で本番環境規模のエージェント強化学習（Reinforcement Learning）を実現します。 - 非同期ロールアウトと軌跡収集により、オフポリシーの古さ（staleness）を制限。生成と勾配更新が並列実行され、現在のポリシーから過度に乖離することなくトレーニング速度を向上させます。 - 近接政策最適化（Proximal Policy Optimization: PPO）、クリップド重要性サンプリング政策最適化（Clipped Importance Sampling Policy Optimization: CISPO）、および重要性サンプリング（IS）損失を含むネイティブアルゴリズムライブラリと、複数のグループベースのアドバンテージ推定器（GRPO, GRPO pass@k, RLOO など）を組み合わせます。これらは多ターン型エージェント強化学習において最も関連性の高い選択肢を網羅しています。 - 長時間にわたる多ターンの軌跡においても、実時間（wall-clock time）の短縮を実現するためのシーケンス拡張トレーニング。 - Amazon SageMaker AI が管理する MLflow を通じた軌跡と報酬の観測性により、エージェントがターンごとに何を行ったか、またトレーニングステップ全体を通じて何を成し遂げたかを把握できます。 - 本番環境への SageMaker AI エンドポイントや Amazon Bedrock へのデプロイ前に、報酬、pass@k、軌跡メトリクスなどを報告する評価ジョブ機能。 このサービスはトレーニングループ、ハードウェア、オーケストレーションを提供します。信頼性の高いエージェントを構築できるかどうかを決める選択肢はすべてユーザーにあります。エージェントが学習する環境を構築し、報酬以外の成功基準を測定し、報酬そのものを設計し、曲線が停滞した際の反復方法を決定するのはあなた次第です。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/06/29/ML-21260-1.jpg) *図 1: SageMaker AI の多ターン RL サービスの概要* ## 安価で再現性があり、かつ実態を反映したトレーニング環境を構築する シングルターンの RL（強化学習）にはプロンプトと報酬関数が必要です。一方、マルチターンの RL では、エージェントがターンを超えて行動するための環境、つまり呼び出されるツールやその背後にあるシステムが追加されます。この環境はトレーニングセットアップの一部であり、どのように構築するかによって、モデルが学習できる内容や、指標を信頼できるかが決定されます。 エージェントのトレーニングにおいては、本番環境と類似しているがライブトラフィックから隔離されたサンドボックス化された環境またはシミュレーション環境を構築してください。ツールの呼び出しと応答は、同じスキーマとビジネスロジックを維持します。これらは生きた呼び出しではなく、記録された応答や隔離された状態によって駆動されます。 シミュレーション環境は推奨される出発点です。なぜなら、通常のランでは数千回のロールアウトが発生し、それぞれが複数のツール呼び出しを行うからです。例えば、バッチサイズを 128、グループサイズを 8 とすると、ステップあたり 1,024 回のロールアウトになります。このトラフィックを生きたシステムに直接流すと、顧客への影響が生じる可能性があります。シミュレーション環境がない場合、探索によって実際の副作用を引き起こす恐れがあります。例えば、試行錯誤を通じて学習するエージェントは、意図しないリファンドの発行、レコードの削除、またはワークフローのトリガーを実行してしまうかもしれません。さらに、生データは常に変化しており、同じ軌道でもランごとにスコアが異なります。報酬を計算するには正しい結果を知る必要があり、ツール呼び出し先がどこであれ、固定されたラベル付きタセット（または信頼できる判定モデル）が必要です。 シミュレーション環境の構築方法は、ツールの機能に依存します。遭遇するユースケースのほとんどをカバーする 3 つのパターンがあります： - リーダーツール：入力に応じて記録された応答を再生する。これらのツールは、エージェントがタスクに関連する情報を取得するのを支援します。例えば、SOP-Bench のカスタマーサービスタスクでは、10 個のモックツール（validateAccount, getAuthenticationDetails, createSessionAndOpenTicket など）が提供されており、それぞれがツール呼び出し引数に基づいて CSV ファイルの特定の行などの固定データから決定論的な応答を返します。 - ステートフルツール：エピソードの期間中、状態を保持するシードされたサンドボックス。エージェントが何かを書き込み、それを再度読み取る場合、環境にはメモリが必要です。パターンは以下の通りです：ロールアウト開始時にエピソードごとのリソースを割り当て、エージェントが作成したすべてのものを登録します。エピソード終了時（ターミナルアクションに達した場合、最大ターン数に到達した場合、またはクラッシュした場合）は、try/finally ブロック内ですべてを破棄します。状態が次のロールアウトに漏れ出すことはありません。 - 検証可能な結果：隔離されたシミュレーション環境における実際の実行。エージェントの出力がコード、SQL、または数学式である場合、それを隔離された環境で実行できます。コードには Docker exec を、SQL にはロールアウトごとのインメモリ SQLite を、数学には純粋な Python eval を使用します。実際の実行であり、インスタンスごとに決定論的です。同じ入力と同一のサンドボックス状態であれば、必ず同じ結果が得られます。例えば、AgentCore Code Interpreter はコード実行用の管理された隔離環境を提供しています。 いずれのパターンを採用する場合でも、以下の 2 つのプロパティを固定値として維持してください： - 再現性：同じツールを同じ引数で呼び出すと常に同じ結果が返されるため、同一の軌跡に対する報酬が安定し、実行間での評価が可能になります。 - 代表性：モデルが学習する振る舞いが本番環境へ転移できるよう、実際のスキーマとデータ分布に基づいて環境を構築します。 **トレーニングを開始する前に、環境が正しく設定されていることを確認してください：** - 同じ引数で呼び出されたツール呼び出しは同じ結果を返すこと。これは同一インスタンスを 2 回実行し、ロールアウトメッセージを比較（diff）することで検証します。 - ロールアウトごとの状態は隔離されていること（別々の一時ディレクトリ、別々の ID、別々のデータベース接続を使用）。 - 利用可能なツールと、そのツール呼び出し・レスポンスのスキーマが本番環境と一致していること。 ## トレーニング前に外部評価を設定する 環境が整い検証されたら、報酬関数を作成する前に成功を測定する方法を構築してください。この測定はあなたの最終目標を直接的に捉えるべきです。強化学習（RL）は報酬信号を文字通り最適化するため、報酬が唯一の指標となる場合、タスク上の進捗と報酬基準への適合に関する進捗を分離して評価することはできません。報酬、環境のシード値、ハイパーパラメータの反復処理中に意思決定を導くために信頼できる外部評価が必要です。 ## パターン デプロイ時に重視する成果を評価する、報酬とは独立して計算される保留評価（held-out evaluation）を用意してください。実際には、モデルを受け取り、固定されたテスト分割に対してロールアウトサーバーで実行し、単一のタスク成功率を返す小さなコード片です。誠実であれば、最小限の構成でも構いません。 SOP-Bench における評価は、最終的な JSON オブジェクト内の完全一致（exact-match）です。エージェントの出力にあるすべてのフィールドが、正解（ground-truth）のフィールドと完全に一致している必要があります。そうでなければロールアウトスコアはゼロとなります。報酬関数は部分的な加点や加重成分を計算できますが、評価機能はそうではありません。 トレーニングを開始する前にベースラインを設定してください。基本モデルと参照モデル（Amazon Bedrock でホストされた最先端モデルが適しています）を同じ評価プロセスに通します。これにより、2 つのことがわかります：基本モデルが到達すべき距離、およびこのタスクにおいて「良い状態」とはどのようなものかです。 ## アンチパターン トレーニング報酬、またはそこから導き出される指標を成功の尺度として扱うことです。これは直感的に思えるかもしれませんが、報酬ハッキング（reward hacking）を検出するには外部評価が必要です。多ターンエージェントには特別な配慮が求められます：ツール呼び出しに対して報酬を支払う設計は、エージェントにできるだけ多くのツールを呼び出すよう学習させてしまいます。一方、ターン数に対するペナルティを与える設計は、必要な情報を得る前に回答を確定させるよう学習させてしまいます。いずれの場合も、トレーニング中の報酬は上昇しますが、タスクにおけるエージェントの実際の成功度は低下します。 **トレーニングを開始する前に、評価が信頼できることを確認してください：** - 評価は単一の関数、score(rollout) -> float であり、あなたが実際に提供するものを正確にスコアリングするものです。 - ベースライン評価は、ファインチューニングを計画しているベースモデルに対してゼロではありません（もしゼロである場合は、次のセクションの「まずベースモデルが足場を持つことを確認する」を参照してください）。 - 比較対象となる高度なベースラインを得るために、フロンティアモデルに対して評価を実行してください。 ## 多ターン強化学習のための適切な報酬関数の設計 報酬の設計は、強化学習における最も困難な未解決問題の一つです。エージェントが実際のタスクを解決できるという同じ柔軟性が、タスクを実行せずに報酬を満たす方法を見つけさせる原因にもなります。追加する各コンポーネント、調整する各報酬重み、付加する各フォーマットボーナスはすべて、エージェントがタスクを解決せずに登れる別の表面となります。モデルはあなたが意図したものを最適化するのではなく、あなたが記述したものを最適化します。デフォルトでは、トレーニングと評価で同じスコアリングルールを使用し、具体的な理由がある場合のみ例外として扱うようにしてください。 翻訳全文 翻訳全文 ベンチマークスコアは、すべての項目が一致すれば 1、そうでなければ 0 を返します。トレーニングと評価では通常このスコアリングルールを共有し、観察対象となる情報のみが異なります。トレーナーは各ロールアウトに対して 1 つの報酬（スカラー値またはスカラー値のリスト）を受け取ります。評価は固定された分割データセットでより低い頻度で実行されるため、より多くの指標を監視できます：項目ごとの精度、完了率（エージェントが出力を発行したか）、ツール呼び出しの分布、ターン予算の枯渇、フォーマット準拠状況。 デフォルトのベンチマークスコアリングルールから逸脱する理由は主に 2 つあり、どちらもより密な報酬（denser reward）を必要とします。 1 つ目はアルゴリズム的な理由です。強化学習（RL）は、各プロンプトに対して group_size 個のロールアウト群全体にわたる分散から学習信号を計算し、グループベースのアバンテージ法（advantage_method）を使用します。サービスのデフォルト設定では group_based は GRPO です。rloo や grpo_passk など他の多くの手法も利用可能です。完全なリストについては [ドキュメント](https://docs.aws.amazon.com/sagemaker/latest/dg/model-customize-mtrl-hyperparams.html) を参照してください。二値スコアはこの分散を圧縮してしまいます：グループ内のすべてのロールアウトが同じスコアを得た場合、相対的な信号は 0 となり、そのグループは勾配に寄与しません。rollout/reward/valid_mean（非ゼロ・アバンテージを持つグループの平均）が rollout/reward/mean を下回って推移し、モデルが停滞した場合、このギャップが症状となります。 2 つ目は収束速度です。グループの分散が健全であっても、密な報酬は、完全な成功を収めたロールアウトだけでなく、すべてのロールアウトにおいてモデルに部分的な進歩への勾配を与えます。6 つのフィールドのうち 5 つを正しく回答したロールアウトは、モデルに対して「より近い状態」がどのようなものかを教示します。一方、二値スコアではそのような情報は得られません。 SOP-Bench タスクにおける密な報酬は、各フィールドを独立して採点し、**スカラーまたはスカラーのリスト**（ターンごとの報酬）と**メトリクス辞書**を返します。 ```python class SOPBenchReward: """SOP-Bench 航空機検査タスク向けのフィールドごとの密な報酬。 [0, 1] の範囲のスカラーと、MLflow で公開されるメトリクス辞書を返します。""" ground_truth: dict[str, str] format_coef: float = 0.1 # フォーマットは小さな形状化項であり、目的関数ではない ``` async def __call__(self, history: list[Message]) -> tuple[float, dict[str, float]]: fields = parse_final_output(last_assistant(history)) # JSON inside emitted = float(fields is not None) if fields is None: # no parseable answer return self.format_coef * (emitted - 1), {"completion": 0.0, "field_acc": 0.0} matched = sum(1 for k, v in self.ground_truth.items() if str(fields.get(k)).strip().lower() == str(v).strip().lower()) field_acc = matched / len(self.ground_truth) # partial credit: 5/6 > 0 reward = field_acc + self.format_coef * (emitted - 1) # correctness dominates return reward, {"completion": emitted, "field_acc": field_acc} Your agent reports the reward through update_reward, and the metrics dictionary (completion, field_acc) appears in MLflow. To credit individual turns instead of the whole trajectory, update_reward also accepts a per-turn list, paired with the group_based_per_turn advantage method, so your reward function can also return one reward value per turn. - トレーニングを開始する前に、実際の出力に対する報酬を確認してください。評価よりも寛容な報酬パーサーは、それ自体が一種の報酬ハックとなります。SOP-Bench の実行例の一つでは、報酬側がベンチマークが採点した形式よりも緩い出力フォーマットを受け入れました：ベンチマークが ` ` タグを必要とする一方で、単なるラッパータグのみでもクレジットが付与されたのです。トレーニングはまさに私たちが求めた通りに機能しました：モデルはベンチマークが必要とするタグを削除することを学習し、報酬は上昇しましたが、外部評価は低下しました。 - まずベースモデルが何らかの基礎能力を持っていることを確認してください。強化学習（RL）は、ベースモデルがすでに一定の確率で実行できている機能を改善するものであり、ゼロから新たな能力を創出するものではありません。もしベースモデルがあなたのタスクにおいて成功した軌道（trajectories）を一度も生成できない場合、報酬信号が増幅する対象が存在せず、トレーニングは停止してしまいます。 SageMaker AI MTRL は、このようなベースラインを管理された評価ジョブとして実行できます。MultiTurnRLEvaluator は、**ホールドアウトされたプロンプトセット**に対してエージェントを再実行し、評価結果・報酬値および pass@k を報告します。すでにモデルをトレーニング済みの場合、`evaluate_base_model=True` を指定して単一の呼び出しを行うだけで、ベースモデルとファインチューニング済みモデルの両方を並列にスコアリングできます。pass@k は成功閾値（success_threshold）で報酬を制限するため、`success_threshold=1` を設定すると厳格な成功率が得られます：これは、完全な報酬を獲得したロールアウトの割合と平均値を示すものです。 ```python from sagemaker.train.evaluate import MultiTurnRLEvaluator ``` # Bedrock AgentCore を使用して evaluator_base = MultiTurnRLEvaluator( model="openai-reasoning-gpt-oss-20b", dataset="s3://my-bucket/eval-prompts.parquet", agent_config="arn:aws:bedrock-agentcore:us-west-2:123456789012:runtime/my-agent", s3_output_path="s3://my-bucket/eval-output/base/", mlflow_resource_arn="arn:aws:sagemaker:us-west-2:123456789012:mlflow-tracking-server/my-mlflow", role="arn:aws:iam::123456789012:role/SageMakerRole", accept_eula=True, ) execution = evaluator_base.evaluate() execution.wait() 指定された s3_output_path には、評価の報告メトリクス（MLflow でも確認可能）と評価トラジェクトリが含まれています。ファインチューニング済みモデルおよびベースモデルに対する報酬ベースの評価については、[Model evaluation](https://docs.aws.amazon.com/sagemaker/latest/dg/model-customize-mtrl-evaluation.html) のドキュメントをご覧ください。 一つの区別を心に留めてください：評価ジョブは、エージェント自身の報酬関数を用いてロールアウトにスコアを付けます。つまり、これは保持された一般化能力を測定するものであり、*報酬からの独立性*を測定するものではありません。ここでは緩やかな報酬パーサーが健全に見えるでしょう。なぜなら指標自体が報酬だからです。報酬パーサーのバグを検出する独立したチェックは別に行います：同じロールアウトを、より厳格で独立したパーサー（SOP-Bench の場合、ベンチマークの完全一致スコアラー）を用いてスコアリングし、比較します。さらに、MultiTurnRLEvaluator を報酬が独立指標であるエージェントに指向させることで、その厳格なスコアラーを独自の評価ジョブとして実行することも可能です。 報酬設計の詳細、スパース報酬と密報酬の違い、ジャッジモデル、多目的形状付け、およびそれらの間のトレードオフについては、[SageMaker AI 報酬設計のベストプラクティス](https://docs.aws.amazon.com/sagemaker/latest/dg/model-customize-mtrl-assets.html#model-customize-mtrl-assets-best-practices)をご覧ください。 **報酬を信頼する前に確認してください：** - トレーニング用報酬と評価用報酬は、異なる理由が測定され文書化されていない限り、同じ基礎となるスコアリングルールを共有する必要があります。 - 報酬は [0, 1] の浮動小数点数を返す必要があります（負の回帰項を許可する場合は [-1, 1]）。 報酬は 100 ベースラインロールアウトに対して分散を持ちます（

Amazon SageMaker AIにおける多ターン強化学習のベストプラクティス

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト