Amazon、Jev類似モデルの増加のなかAWS Strands Decider 2Bを公開

Amazon Web Servicesは、自由形式のテキスト生成ではなく限定的な選択のために構築されたオープンモデル、AWS Strands Decider 2Bを公開した。TypeSafe AIがJevを発表してからわずか数週間後のこの公開により、AWSは意思決定モデルをめぐる急成長中の競争に直接参入することになる。

これらのモデルは、AIエージェントに異なる基盤をもたらす。大規模言語モデルに次の行動を説明させる代わりに、ソフトウェアが固定された選択肢を提示し、信頼度スコアを伴う選択を受け取る。

このより限定的な契約は速度と制御をもたらす一方で、厳しい試験も生む。AWSは、自社モデルが整備されたベンチマークの外でも正確性、キャリブレーション、有用性を維持できることを示さなければならない。一方のTypeSafeは、より大きなプラットフォームが同じ基本的な考え方を採用するなかで、先行者としての立場を守る必要がある。

このタイミングは重要性を高めている。OpenAIも同じ週に限定プレビューのDecisions APIを発表しており、特化型の意思決定レイヤーがエージェント基盤の重要な一部になりつつあることを示している。

AWS Strands Decider 2B、実験をオープンモデルへ転換

AWSは、エンジニアによるJev着想の実験を、エージェントワークフロー向けの完全にオープンな意思決定モデルへと転換した。

Strands Labsは2026年10月1日にこのモデルを公開した。同組織は、Strands Agentsエコシステムを中心とする実験的なツールとプロトコルを開発している。

公式の公開詳細では、Strands Decider 2Bをローカル開発、実験、エージェント自動化向けに最適化した小型モデルと説明している。重み、トレーニングスクリプト、トレーニングデータはいずれも公開されている。

製品名とは異なり、初期モデルは19億パラメータで構成される。AWSによると、ローカルCPU、Appleシリコン搭載Mac、または互換GPUで実行できる。

このモデルは段落の作成、コードの記述、文書の要約を行わない。状態を受け取り、1つ以上の構造化された質問を受け、開発者が定義した選択肢を評価する。

カスタマーサポートシステムは分かりやすい例になる。状態には、支払い失敗に関する苦情が含まれる場合がある。モデルはその後、請求、営業、または別のチームのどこがその案件を受け取るべきかを選択できる。

また、はい・いいえの文を評価したり、順序付けられた尺度上の位置を割り当てたりすることもできる。各応答には、行動、エスカレーション、人によるレビューの要請を判断する際にソフトウェアが利用できるスコアが含まれる。

この出力契約が、意思決定モデルを通常のチャットボットと区別する。生成モデルは説明、留保、あるいは不正な構造を返す可能性がある。Strands Deciderは、提示された選択肢から選ばなければならない。

AWSは、公開されたモデルリポジトリを通じて実装を公開した。開発者はコマンドラインインターフェースから実行することも、HTTPエンドポイントの背後で提供することもできる。

リポジトリでは、Nvidia RTX 3090での応答時間の中央値を115ミリ秒と記載している。この結果は公開されたテスト環境に固有のものであり、普遍的なレイテンシー保証ではない。

このシステムは、状態全体を繰り返し処理することなく、1つのテキストについて複数の質問を評価できる。この設計は、エージェントが行動を起こす前に複数の確認を必要とする場合に重要となる。

例えば、エージェントは受信した依頼を分類し、緊急度を推定し、担当者を選択できる。より大きなモデルに3つの別々の説明を生成させずに、これらの判断を実行できる。

AWSは、信頼度が設計の中心だとしている。短く、これまで見たことのない分類タスクでは、指定された信頼度しきい値を上回る回答の正答率は約95%だったとプロジェクトは報告している。

これは依然としてプロジェクトによる評価であり、本番ワークロード全体での独立した証明ではない。それでも、確信度の高いケースを自動化し、不確実なケースを転送するという意図された運用モデルを示している。

この公開は、記事の中心的な緊張関係を生み出す。オープンで高速な意思決定モデルの構築は、今や比較的手が届きやすい。しかし、未知の環境でも信頼できる信頼度スコアを生み出すことははるかに難しい。

エージェントワークフローに小さな意思決定が必要な理由

ほとんどのエージェントのステップには、エッセイを書けるモデルは必要ないが、固定ルールが提供できる以上の判断は依然として必要だ。

現代のエージェントは、多くの場合、複数の種類の作業を組み合わせる。依頼の解釈、情報の取得、ツールの選択、ポリシーの確認、別のモデルを関与させるべきかの判断などだ。

大規模言語モデルは、これらすべてのステップを処理できる。その柔軟性は、ワークフローが限定された答えだけを必要とする場合にはオーバーヘッドももたらす。

例えばツールルーターは、検索、メール、カレンダー、文書取得から選択する必要があるかもしれない。ソフトウェアは利用可能な行動をすでに把握しているため、生成的な応答は不要になる。

構造化出力機能は、大規模モデルの応答を制約できる。しかし、基盤となるシステムは依然として自己回帰的な生成を行い、応答が完了するまでトークンを順番に生成する。

意思決定モデルは、この生成ループを取り除く。提示された選択肢を並列に評価し、その相対的なスコアを返す。

この設計は、繰り返されるワークフローのゲートに特に適している。企業向けエージェントは、ユーザーに表示される最終回答だけでなく、実行前に提案されたすべての行動を検査する必要があるかもしれない。

アカウントレポートを作成するエージェントを考えてみよう。どの文書が関連するか、情報が矛盾しているか、機密コンテンツを社内システムの外に出してよいかを判断する必要があるかもしれない。

こうした判断は、1つのタスクの中で何度も発生する可能性がある。すべてのゲートをフロンティアモデルに送ると、レイテンシーと運用上の複雑さが増すことがある。

AWSのDistinguished EngineerであるMarc Brookerは、自身の関心をまさにこのワークフローの問題に結び付けている。公開されたエンジニアリングノートでは、明示的なステップを持つエージェントにとって、意思決定モデルは有用な構成要素だと説明している。

Brookerは、TypeSafeが9月15日にJevを公開した後、Hobsonという個人プロジェクトから始めた。実験を約20億パラメータに限定し、複数のアーキテクチャを試した。

その作業は、AWSがStrands Decider 2Bとして公開準備を進めるまでに複数のバージョンを経た。公開モデルはバージョン19であり、単純なインターフェースの下で相当な反復が行われたことを示している。

Brookerは、このモデルが一時的に公開JevBenchリーダーボード上で同規模のエントリーの最上位を共有したと報告した。同時に、そのベンチマークから結論を導くことの限界も認めている。

この率直さは重要だ。なぜなら、エージェントのルーティングは通常のテキスト分類ではないからだ。誤ったラベルは不適切なツールの選択、データの露出、望ましくない外部アクションの開始につながり得る。

信頼度スコアは、このリスクへの1つの対応となる。ワークフローは高信頼度の選択を受け入れる一方、不確実なケースをより強力なモデルまたは人に回すことができる。

このアプローチは、階層化されたエージェントアーキテクチャを生み出す。小型の意思決定モデルが日常的なゲートを扱い、生成モデルや推論モデルが曖昧なタスクに対応する。

このパターンは、単一の全知的なアシスタントよりも、通常のソフトウェアエンジニアリングに近い。異なるコンポーネントに、明確な責任、インターフェース、障害対応ポリシーが与えられる。

開発者はすでに、ルール、分類器、埋め込みモデルを使ってそのようなシステムを構築している。意思決定モデルは、構造化出力を手放すことなく、より広い言語理解を約束する。

この約束が、AWS、OpenAI、研究者、独立系開発者からの急速な関心を説明する。また、現時点であらゆるステップを1つの大規模モデルにルーティングしているチームにも圧力を生む。

異種混在のワークフローには、より多くの設計作業が必要になる。開発者は許容される選択肢を定義し、信頼度しきい値を設定し、結果を記録し、エスカレーション経路を確立しなければならない。

それでも、単一の制約されないエージェントより優れた制御を提供できる可能性がある。検索可能な技術知識に取り組むチームは、エンジニアリングナレッジベースを構築する際にも同様の分離を適用できる。

重要な問いは、小型モデルが意思決定をできるかどうかではない。実際のソフトウェアに見られる雑多な条件下で、正しい意思決定を下せるかどうかだ。

AWS Strands Decider 2B、オープン性でJevに挑む

主な競争はAWS Strands Decider 2BとJevの間にあり、オープン性と再現性が、独自データと特化した開発に対峙している。

TypeSafeはJevを、速く直感的な判断を表す言葉を借りて、System Oneモデルと説明している。自由形式のテキストではなく、型付けされた意思決定を返す。

Jevは、現在の意思決定モデルというカテゴリーの確立に寄与した。開発者は状態と質問を提供し、散文ではなく選択、尺度上の位置、または確率を受け取る。

AWSは、自社プロジェクトがJevから着想を得たことを明示的に認めている。そのためStrands Deciderは、似た市場ニーズを軸に構築された偶然の競合相手以上の存在となる。

現在、両者は異なる提案をしている。AWSは、重み、スクリプト、データ、コード、そして開発者が自らのハードウェアで実行できるモデルを提供する。

TypeSafeは商用モデルを提供し、有用な知能はアーキテクチャをコピーするだけでは実現しないと主張している。同社幹部は、データ品質、トレーニングの規律、継続的なモデル改善を強調している。

TypeSafe CEOのDiogo AlmeidaはTechCrunchに対し、実装の急増はモデル知能が依然としてどれほど難しいかを過小評価する危険があると述べた。多くの新規参入者を、継続的な知能プロジェクトではなくアーキテクチャ実験と位置付けた。

この批判は、競争上の重要な問いを示している。オープンな実装は検査、変更、ローカルデプロイが可能だが、オープン性はより良い判断を保証しない。

独自サービスは、すべてのコンポーネントを公開せずにデータとモデルを改善できる。その場合、顧客はベンダーの測定値を信頼し、APIを通じて性能を観察しなければならない。

AWSの公開は、アーキテクチャを研究しやすくする。Strands DeciderはQwen3.5-2B-Baseのトルソーから始まる。つまり、テキスト生成ヘッドを除いた、事前学習済みトランスフォーマーの内部ネットワークだ。

開発者は元の言語モデリングヘッドを取り除き、約100万パラメータを持つポインターヘッドに置き換える。このコンポーネントは、提案された各選択肢を、モデルが保持する回答の表現と比較する。

チームはrank-16のLoRAアダプターでモデルのトルソーを適応させる。LoRAは、すべての重みを再トレーニングする代わりに、追加されたより小さなパラメータ群を更新するファインチューニング手法だ。

このアーキテクチャは、デコードループなしで1回のフォワードパスを実行する。モデルは説明を生成する能力を失うが、事前定義された選択肢のための直接的なスコアリング機構を得る。

AWSは115,000行のデータでこのプロジェクトをトレーニングした。Brookerによると、約113,000行は公開データセットに由来し、約2,000行には合成された難問が含まれていた。

トレーニングプロセスでは、モデルが固定されたバージョンまたは以前のバージョンから学習する自己蒸留も用いられた。AWSは、モデルがすでに処理できていたタスクでの性能低下を抑えるためにこの手法を用いた。

これらの詳細は、開発者に再現可能な出発点を提供する。同時に、TypeSafeが、アーキテクチャだけでは持続的な優位性をもたらさないと主張できる領域も明らかにする。

トレーニングデータは、モデルがどのような区別を学ぶかを決定する。キャリブレーション手順は、0.9というスコアが関連するケース全体で90%の信頼性として機能するかどうかを決定する。

信頼度の値が有用になるのは、観測された結果と一致する場合だけだ。未知の言語、敵対的な入力、または微妙なポリシーに対して自信を持って失敗するモデルは、率直に不確実性を示すモデルより危険になり得る。

独立したJev評価では、バージョン1.13を37のデータセットと346,009件のリクエストで検証した。対象タスクは、分類、ルーティング、推論、モデレーション、法的分析、ルーブリック採点に及んだ。

研究者らは、いくつかの従来型データセットで強力な結果を報告した。一方で、低リソース言語、細分化されたラベル、ノイズの多いカテゴリ、ルーブリックに基づく品質判断では、性能が弱いことも確認された。

こうした制約はカテゴリ全体に当てはまるものであり、すべての実装に自動的に当てはまるわけではない。これは、単一の総合リーダーボードではAWSとTypeSafeの競争に決着を付けられない理由を示している。

AWSは、開発経路を完全に公開することで信頼性を高めている。TypeSafeには、より優れたデータ、汎化性能、マネージドな改善を通じて差別化する機会が残されている。

OpenAIはさらに競争の層を加えている。限定プレビュー中のDecisions APIでは、開発者が画像カテゴリや想定されるエージェントの振る舞いを含む、事前定義済みの選択肢をモデルに与えられると報じられている。

OpenAIは、詳細な比較を行うに足る十分な公開証拠をまだ示していない。それでも同社の参入は、自動化システム内で制約された意思決定に対する根本的な需要を裏付けている。

したがってAWS、TypeSafe、OpenAIは、同じ実務的な試練に直面している。顧客が評価するのはカテゴリ名ではなく、意思決定の質、エスカレーション時の挙動、レイテンシ、運用上の適合性だ。

この仕組みは柔軟性を制御と引き換えにする

Strands Deciderが有用になるのは、フロンティアモデルの幅広い能力を置き換えるからではなく、自由形式の生成を手放すからだ。

このトレードオフの中核にあるのがpointer-head設計である。これは次のトークンを無制限の語彙から探すのではなく、アプリケーションが提示した選択肢を採点する。

この違いにより、回答がインターフェースに違反する経路は減少する。ワークフローが請求、営業、小売を提示する場合、モデルはそれらの選択肢を採点しなければならない。

4番目の部署を勝手に作り出したり、説明文の中に選択結果を埋め込んだりすることはできない。利用側のアプリケーションは、直接処理できる値を受け取る。

閉じたドメインは明示的なしきい値も支える。チームは、検証済みの信頼度境界を上回る選択を実行し、それ以外はすべてエスカレーションすることができる。

この方針は、実際のワークロードから得たラベル付きの例を用いて調整すべきである。公開ベンチマークからコピーしたしきい値は、別の企業の文書や顧客の表現を反映しない可能性がある。

意思決定モデルは、複数の質問に対してエンコード済みの状態を再利用することもできる。この性質により、単一のメール、文書、または提案されたエージェント行動に対する複合チェックに適している。

承認ワークフローでは、ある行動がユーザーの依頼に合致するか、機密データに触れるか、外部とのコミュニケーションを要するかを問える。それぞれの回答は、別個のポリシーに入力できる。

モデルは依然として、開発者が与える選択肢とコンテキストに依存する。有効な選択肢が欠けていれば、どれほど完全に校正されたモデルでもそれを選ぶことはできない。

選択肢の表現が不適切であれば、別の失敗モードが生じる。重複する2つのラベルによって確率が分割され、信頼度の解釈が難しくなる可能性がある。

コンテキストの質も重要だ。受け取っていない文書の中に隠されたポリシー例外を、モデルが推測することはできない。

このため、意思決定モデルによってワークフロー設計が不要になるわけではない。作業の焦点が、生成されたテキストの解析から、状態、選択肢、しきい値、エスカレーション規則の定義へと移るだけだ。

AWSは、Strands Deciderが複雑な問題では推論モデルより性能が低いことを認めている。これはコーディング、文書要約、長い会話、生成された説明を必要とするタスクを対象としていない。

ワークロードが適合する場合、この境界は機能となる。チームが安価な意思決定を推論の代替として扱う場合、それは負債となる。

モデルは、推論を説明せずともサポートチケットを分類できる。しかし、規制対象の判断や重大なセキュリティ行動では、別のプロセスによる監査可能な根拠が必要になる可能性がある。

一見単純な行動にも、多段階の論理が隠れていることがある。証拠がある主張を裏付けるかを選ぶには、計算、外部検証、または矛盾の解消が必要になる場合がある。

意思決定のみを対象とする評価の研究は、この限界を示している。ある研究では、Jevは通常の選好判断および根拠のある事実性タスクにおいて、より強力な判定モデルに近い性能を維持した。

一方、導出を必要とする数学、コード、論理、専門的な質問では差が大きく広がった。精巧に書かれた誤答も、より小規模な意思決定モデルを誤導し得た。

有用なパターンはカスケードだった。自信のある定型的な判断は意思決定モデルに任せ、不確実なケースはより強力なシステムへ移した。

この証拠は、AWSが目指すアーキテクチャを支持している。ただし、あらゆるエージェントモデルをStrands Deciderに置き換えることを支持するものではない。

この区別はセキュリティ監視において重要である。高速なモデルは、提案された各行動を検査し、実行前に明白な不一致を検出できるかもしれない。

より曖昧な行動については、なお深い評価または人間による承認を発動すべきだ。信頼度はルーティングのシグナルであり、安全性の保証ではない。

広く報じられたJevのゲームプレイテストは、その両面を示している。Jevは提示された行動から選択してPokémon Redをクリアしたが、システムが行き詰まった際にはClaude Opus 5が選択肢の調整を支援した。

この実演は、制約された選択肢が長い行動連鎖を支えられることを示した。同時に、どれほどの能力が周辺のハーネスに存在し得るかも示している。

この教訓はStrands Deciderに直接当てはまる。モデル精度は重要だが、導入されたエージェントが機能するかを決めるのは、選択肢の設計、監視、復旧ロジックである。

初期の数値が示していないこと

AWSは実験を正当化するのに十分な証拠を公開しているが、組織全体にわたる本番信頼性を確立するにはまだ不十分である。

報告されたレイテンシ数値は、特定のハードウェアとテスト入力に基づく。より長い状態、異なるプロセッサ、同時トラフィック、デプロイメントのオーバーヘッドは、応答時間を変化させる。

信頼度の結果についても、ワークロード固有の再現検証が必要である。短い分類タスクで校正されたスコアは、社内ポリシーや専門用語では異なる挙動を示す可能性がある。

Brookerは、開発中に汎化性能よりもドメイン内の精度のほうが容易に改善したと述べている。これはモデルを評価するチームにとって重要な警告である。

モデルは、学習コーパスに似たタスクでは良好に機能する一方、新しい問題構造には苦戦する場合がある。公開ベンチマークでの成功は、この分布ギャップを解消しない。

多言語での挙動も未解決の問題である。基盤となるQwen torsoは幅広い言語知識を持つが、ファインチューニングはそうした能力を維持することも低下させることもある。

AWSは、忘却を抑える目的の一部として蒸留を訓練プロセスに用いたとしている。その取り組みが言語やドメインをまたいでどれほど機能したかは、独立したテストで判断しなければならない。

ベンチマーク汚染も、このカテゴリのすべてのモデルにとって懸念事項である。開発者は、直接それらで学習していなくても、アーキテクチャやデータを改善する過程で公開テスト例を確認する可能性がある。

Brookerは、JevBenchの例を見たことがあり、合成プロセスを設計したと認めている。この開示は結果を無効にはしないが、強い比較主張には制約を与える。

したがって本番評価には、モデル選定前に作成された非公開の例を含めるべきである。また、まれな失敗、曖昧なラベル、敵対的な表現も含める必要がある。

校正はデプロイ後も継続的に監視する必要がある。ユーザーの行動や文書形式は変化し、その結果、昨日のしきい値が信頼できなくなることがある。

チームは、状態、提示された選択肢、モデルバージョン、スコア、選択された行動、最終的な結果を記録すべきだ。この記録がなければ、信頼度が意味を持ち続けているかを測定できない。

開発者は、すべての選択肢が不適切な場合に何が起こるかも決めなければならない。強制的な選択は、正しい応答が欠けている場合でも決定的に見えることがある。

明示的な棄権またはエスカレーション経路は、この問題への対処に役立つ。ワークフローは、不確実性を不便なものではなく、行動可能な情報として扱うべきだ。

オープンウェイトにより、これらのテストは非公開で実施しやすくなる。組織は、機密データを外部のモデルプロバイダーへ送ることなく評価できる。

ローカルデプロイメントには責任も伴う。各組織が、提供、更新、セキュリティ、性能、モデルガバナンスを管理しなければならない。

マネージドサービスは、運用作業の一部をプロバイダーへ移す。同時に、モデルの訓練プロセスや更新スケジュールが見えにくくなる可能性もある。

このトレードオフで自動的に勝つモデルはない。購入者は、自らのワークロードにとって、制御性、再現性、マネージドな改善、測定された精度のどれが最も重要かを決めなければならない。

用語についても懐疑的であるべきだ。「System One」は、熟慮を要する推論モデルとの記憶に残る対比を提供するが、このラベルが新たな科学的保証を生み出すわけではない。

ブランディングの下にあるのは、事前学習済みTransformerから構築された特化型ニューラル分類器だ。その実用的価値は、心理学的な類推ではなく、測定可能な成果に依存する。

したがって最大の不確実性は、AWSが機能する意思決定モデルを構築したかどうかではない。オープンなコードと公開テストは、その結論を明確に裏付けている。

不確実なのは、持続的な優位性である。多くのチームが類似モデルを作れるなら、差別化の焦点はデータ、校正、統合、信頼できる評価へ移る。

この変化は、流通網と開発者アクセスの面でAWSに有利に働く。特化した訓練が一貫してより良い意思決定を生むなら、TypeSafeに有利に働く。

OpenAIは既存のモデルプラットフォームとマルチモーダル能力を通じて競争できる。しかし、その限定プレビューでは、主要な性能およびデプロイメントの詳細が未解決のままだ。

市場はローンチ週のリーダーボードでこの問題に決着を付けない。本番環境でのエラー率、エスカレーション件数、開発者維持率を通じて決着する。

意思決定モデルが定着するかを示す3つのシグナル

次の段階では、意思決定モデルが永続的なエージェント基盤となるのか、それとも激しい実験の一時的な盛り上がりにとどまるのかが試される。

第1のシグナルは、AWS Strands Decider 2Bの独立評価である。研究者は、未知のワークロード、多言語入力、敵対的な表現、変化する選択肢セットをテストすべきだ。

安定した信頼度を伴う強い汎化性能は、AWSのオープンなアプローチを支持する。馴染みのあるデータセットの外で性能が急激に悪化すれば、アーキテクチャは容易な部分にすぎないというTypeSafeの主張を強める。

第2のシグナルは、実際のStrandsワークフロー内での導入である。有用な証拠には、ルーティング、モデレーション、ポリシーチェック、モデル選択における再現可能なデプロイメントが含まれる。

リポジトリ活動や実験的なデモは、開発者の関心を示し得る。本番の事例研究では、許容できないエラーやエスカレーション件数を生まずに、モデルがレイテンシを削減するかを示さなければならない。

第3のシグナルは、TypeSafeとOpenAIの対応である。TypeSafeは先行者であることを超えた測定可能な優位性を示す必要があり、OpenAIはDecisions APIを明確化しなければならない。

直接比較では、同じ状態、選択肢、しきい値、結果ラベルを使うべきだ。無関係なベンチマークに基づくマーケティング上の主張では、中核的な問いは解決しない。

開発者は、勝者が決まるのを待たずに実験を始められる。誤った選択でも元に戻せる、低リスクのワークフローから始めることができる。

有用なパイロットには、代表性のある非公開テストセット、明示的な棄権経路、より強力なフォールバックモデルを含めるべきだ。すべての意思決定は、その後の結果と照合して記録する必要がある。

チームは、金融送金、アクセス制御の変更、取り消し不能な外部コミュニケーションから始めるべきではない。こうした行動には、より深い安全策と明確な人間の権限が必要となる。

最も有望な初期ユースケースは、選択肢が既知の反復的な分類に関わるものです。チケットの振り分け、文書のトリアージ、関連性フィルタリング、安全なモデル選択は、このプロファイルに適しています。

AWS Strands Decider 2Bは、実装を検証し、ローカル環境にデプロイできるため、このような実験を容易にします。また、慎重な評価を省略する言い訳もなくします。

本当の機会は、あらゆる場面で大規模言語モデルを置き換えることではありません。生成、拡張的な推論、あるいは説明が有益な作業のために、それらを確保しておくことです。

信頼できる意思決定レイヤーは、そうした作業の周辺にある、より限定的なゲートを担えます。信頼できないレイヤーは、低速なモデルでは到底及ばない速度で誤りを拡大しかねません。

現在のAIワークフローで繰り返されているどの選択に、慎重に評価された意思決定モデルを導入する価値があるでしょうか。また、その確信度を信頼する前に、どのような証拠を求めますか？