Amazon Web Services（AWS）は10月1日、文章を生成するのではなく、与えられた候補を評価して答えを選ぶ小型AIモデル「Strands Decider 2B」を公開した。

約20億パラメータのモデルを手元のCPUやGPUで動かせるほか、コードや学習済みの重み、再学習するための手順も公開している。

TypeSafeのJevやOpenAIのDecisions APIが、こうした判定機能をクラウド上のサービスとして提供するのに対し、Strands Decider 2Bでは判定処理そのものを自社環境で実行し、必要ならモデルを再学習できる。

ただし、自由度が高い分、モデルが自社の質問を正しく理解できるか、自動実行を任せられるほど判定が安定しているかも、自分たちで検証する必要がある。

AD

文章を生成せず、候補だけを評価する約20億パラメータのモデル

Strands Decider 2Bの基盤となっているのは、Alibabaの「Qwen3.5-2B-Base」だ。

設計文書によると、約19億パラメータの基盤モデルから、次の単語を予測するための言語生成用出力層を取り外し、代わりに約100万パラメータの「ポインターヘッド」を追加している。

入力された文章と、それぞれの選択肢をモデル内部で表現し、その類似性を比較して候補ごとのスコアを算出する。

通常の生成AIは、トークンを一つずつ生成しながら文章を作る。一方、Strands Decider 2Bは文章を生成せず、1回の推論で候補ごとの確率を求める。

基盤モデル側にはLoRAを使った追加学習を施しており、自由な文章やコードを生成する能力を持たせる代わりに、問い合わせの振り分けやエージェントの次の行動選択など、限られた候補から答えを選ぶ用途に特化している。

利用できる判定形式は3種類ある。

  • Choice: 複数の候補から1つを選ぶ
  • Score: 順序のある尺度から評価値を求める
  • Noul: Yes／No型の問いに対して、真である確率を返す

Noulは誤記ではなく、Strands Deciderで使われている正式な名称である。

候補の名前や意味はリクエストごとに指定できるため、例えば問い合わせ先の部署を追加しただけでモデルを再学習する必要はない。

TypeSafeのJevも似た形式のAPIを提供している。TypeSafeの文書では、一つの入力に対して複数の質問をまとめて評価できる仕組みを説明している。

ただし、入出力形式が似ているからといって、内部で使われているモデルや学習方法まで同じというわけではない。

確信度の数字にも注意が必要だ。

AWSが示した例では、支払いに関する問い合わせを3部署へ振り分ける際、最有力候補の確率が0.845、確信度が約0.768となっている。

Choiceの確信度は、候補数をN、最も高い確率をpとして、

（N × p − 1）÷（N − 1）

で計算する。

この例なら、

（3 × 0.845 − 1）÷ 2 = 0.7675

となる。

つまり、確信度0.768は「76.8%の確率で正解する」という意味ではない。候補への確率分布がどれだけ一つの答えへ集中しているかを、均等なら0、一つの候補に完全に集中すれば1となるよう正規化した値だ。

実際の正答率との対応は、別途検証する必要がある。

Scoreでは分布の広がりを使った別の確信度を計算し、Noulでは真である確率そのものを返す。

JevやDecisions APIとの違いは、自社環境で動かして再学習できること

2026年10月2日時点の公開情報では、Strands Decider 2B、TypeSafeのJev、OpenAIのDecisions APIには、提供方法に大きな違いがある。

比較する点 Strands Decider 2B Jev OpenAI Decisions API
提供方法 重みとコードを取得して自社環境で実行 TypeSafeのホスト型API OpenAIのホスト型API
入力 テキストと質問・候補 テキストやJSONなど テキストまたは画像
業務への適応 質問・候補を変更でき、公開レシピを使った再学習も可能 入力、質問、候補をリクエストごとに指定 質問と有限の回答候補を指定
提供状況 実験・ローカル開発向け ホスト型サービスとして提供 9月29日時点で限定プレビュー

Strands Decider 2Bについては、推論手順と学習手順が公開されている。

Jevでは、利用者が入力や質問、候補を指定してAPIを利用する。一方、AWSのモデルでは、それに加えて学習データやモデルの調整方法まで利用者側で変更できる。

社内文書を外部APIへ送れない場合や、自社特有の判定をモデルに覚えさせたい場合には、この違いが導入理由になり得る。

一方、画像を直接判断材料に含めたい場合は、テキストと画像の双方に対応すると発表しているOpenAI Decisions APIとの違いも重要になる。OpenAIによると、Decisions APIは9月29日時点では限定プレビューで、一般提供はその後に予定されている。

公開された学習手順は、個人向けGPUでも実行できる規模に収められている。

開発チームの記録では、v19の学習をRTX 3090 1枚で最初から実行すると約11時間、H100を8枚使い高速化設定を有効にした環境では約1時間10分だった。

ただし、現在のQwen3.5系モデルを学習する環境として想定されているのはLinuxまたはWSL2とNVIDIA GPUだ。

Apple Silicon搭載Macでは推論できるが、同じ学習手順をそのまま実行できるわけではない。「Macで動く」と「Macで再学習できる」は分けて考える必要がある。

公開データについても同様だ。

データに関する説明では、合成データやモデルによって生成したラベルの一部をリポジトリに収録し、外部の公開データセットについては利用時に取得・変換する方式を採っている。

既存の学習手順を再実行するために、有料のモデルAPIを呼び出す必要はない。一方で、基盤モデルや教師モデル、外部データセットの取得は必要になる。

コードと配布されているモデル関連ファイルはApache 2.0で公開されているが、ContractNLIやMuSiQueなど外部データセットにはそれぞれ別の利用条件がある。

そのため、「コードも学習データもすべてApache 2.0」とまとめて扱うのは適切ではない。

AD

「115ミリ秒」は短い入力での代表値

開発チームの測定結果では、v19はRTX 3090上で、JevBenchの1問を処理する時間が中央値115ミリ秒、95パーセンタイル299ミリ秒だった。

95パーセンタイル299ミリ秒とは、測定した処理の95%が299ミリ秒以内に完了したことを意味する。

ただし、入力が長くなれば待ち時間も大きくなる。

Apple M3 Pro、メモリ36GBのMacでv19を測定した結果を見ると、短い入力と長い入力では大きな差がある。

M3 Proでの入力 問いの数 初回の中央値 同じ入力を直後に繰り返した中央値
300トークン未満 136問 310ミリ秒 153ミリ秒
2,500〜5,000トークン 29問 3,836ミリ秒 2,514ミリ秒
全231問 231問 622ミリ秒 234ミリ秒

全231問における95パーセンタイルは、初回が3,862ミリ秒、同じ入力を直後に繰り返した場合でも2,628ミリ秒だった。

測定環境はmacOS 26.6、MPS、bf16である。

初回が遅くなる理由の一つは、入力サイズごとにApple GPU向けの実行準備が発生するためだ。

しかし、長い文書では2回目以降も2秒以上かかっている。初回特有の準備時間を除けば、どんな入力でも短文と同じ速度になるわけではない。

短い問い合わせの分類と、数千トークンの社内文書を読ませる判定は、同じ「1回の意思決定」でも計算量が大きく異なる。

また、こうしたローカル環境での測定値と、ネットワーク通信を伴うJevやDecisions APIの応答時間をそのまま比較することもできない。

入力長、質問数、ハードウェア、ネットワーク条件をそろえなければ、モデルそのものの速度と実行環境の違いを切り分けられないためだ。

正答率72.3%だけでは実力を判断できない

開発時のv19は、3,072トークンの入力上限でJevBench公開231問のうち167問に正答し、正答率72.3%を記録した。

難易度別の結果では、開発チームが分類した48問の「easy」で100%、72問の「standard」で87.5%、111問の「hard」で50.5%だった。

簡単な分類では高い精度を示す一方、長い文章を読み、複数段階の判断を必要とする問題では性能が大きく下がる。

JevBench自体は外部の公開ベンチマークだが、この72.3%という測定を実施したのはStrands Deciderの開発チームである。独立した第三者による追試とは区別する必要がある。

また、この結果からJevやOpenAI Decisions APIより高性能だと判断することもできない。各サービスを同じ条件で直接比較した結果ではないためだ。

配布されている重みについても、評価条件を確認する必要がある。

Hugging Faceで公開されたv19モデルは4,096トークンを標準の入力上限としている。一方、事前登録された主要な評価は3,072トークンで実施された。

開発時のv19は3,072トークンで167問に正答し、Brierスコアは0.342、ECEは0.052だった。公開されたモデルを4,096トークンで評価すると168問に正答する。

同じv19でも、入力条件をそろえずに数値を比較すべきではない。

さらに重要なのが、質問文そのものへの反応だ。

評価資料では、同じ文章と候補を与えたまま質問文だけを変更するテストで、モデルが質問の違いを十分に反映しないケースが確認されている。

例えば、「どれに該当するか」という問いを「どれに該当しないか」と反転させても、元の質問と同じように答えてしまうことがある。

これは「全質問の94%を間違える」という意味ではない。

問題なのは、質問文の条件が変われば本来は答えも変わるはずの場面で、その変化を十分に捉えられないことだ。

業務ルールを質問文として書き加える場合には、文章を変えただけでモデルがその条件を理解したと考えず、否定形や反対条件を与えるテストも行う必要がある。

モデルカードでは、学習時とは異なる種類の二択問題や評価尺度へ適用した場合にも性能が落ちる可能性を示している。

確信度の校正についても同様だ。

例えば、ある業務で「確信度0.9以上なら自動実行」と決めても、そのしきい値が別の業務でも同じ誤判定率になるとは限らない。

実際、開発チームも、しきい値は実際の利用データを使って検証するよう求めている。

AD

モデルの判断と、実際に処理を実行する条件は分ける

公式のStrands連携例では、天気を尋ねられたAIエージェントが、ユーザーに都市を確認せず天気ツールを呼ぼうとする例を使っている。

デモでは、生成AIが場所を推測してツールを実行しようとする設定になっている。

その実行前にStrands Deciderが、

  • ツールへ渡そうとしている値にユーザーの発言という根拠があるか
  • 現時点でツールを実行するのは早すぎないか

という二つのYes／No型の判定を行う。

その結果を受け取ったPythonコードが、次の処理を決める。

問題があれば生成AIへ処理を戻して都市を確認させ、問題がなければツールを実行する。必要であれば、人間による確認へ回す仕組みを組み込むこともできる。

重要なのは、Strands Decider自身が最終的な業務処理を決定しているわけではないことだ。

モデルが返すのは、入力された質問に対する判定結果である。

その結果を受けて、

  • 自動実行する
  • ユーザーに聞き直す
  • 人間の確認へ回す
  • 処理を拒否する

のどれを選ぶかは、アプリケーション側のルールとして実装する。

モデルによる判定と実際の処理を分離しておけば、業務方針を変更しやすくなり、誤判定が起きた際の原因も追跡しやすい。

ただし、公式の天気デモで使われている質問やしきい値はあくまで一例であり、そのまま本番環境へ適用するための推奨設定ではない。

「ローカルで動く」という表現にも注意が必要だ。

Strands Decider自体は手元のPCで実行できるが、公式デモで会話を担当する生成AIにはAmazon Bedrockを使っている。

そのため、公式例のエージェント全体がオフラインで動作するわけではない。

さらに、同梱されているHTTPサーバーはローカル実験向けで、認証機能を備えていない。公開されたのは意思決定を担当するモデルとその実装であって、認証や監視を含む完成済みの運用サービスではない。

「無料のモデル」でも運用コストがゼロになるわけではない

費用を比較する場合も、モデルを無料で取得できるかどうかだけでは判断できない。

Jevの公開料金は入力100万トークン当たり0.042ドルで、出力への課金はない。

例えば、1回の入力を1,000トークンとして100万回呼び出した場合、合計は10億入力トークンとなり、単純計算で入力料金は42ドルとなる。

これはJevの公開単価だけを使った計算で、周辺システムなどの費用は含まない。

一方、Strands Deciderを自社で動かす場合には、GPUやCPU、電力、サーバー運用などの費用がかかる。モデルを再学習するのであれば、学習用GPUやデータ整備、評価にもコストが発生する。

したがって、モデル自体を無料で取得できることだけを根拠に、ホスト型APIより総コストが低いとは判断できない。

Strands Decider 2Bを試すなら、まずは短い問い合わせを数種類の処理先へ振り分けるような、正解と誤りを確認しやすい用途から始めるのが現実的だ。

日本語、否定形、正解となる候補が存在しない入力なども含め、自動実行を誤って許可する割合や、人間の確認へ回る割合を測る。

そのうえで長文を扱った場合の待ち時間も確認し、誤判定の影響を許容できる処理から自動化していく必要がある。

Strands Decider 2Bの特徴は、単に小さく高速なAIモデルを公開したことではない。判定モデルの重み、コード、学習手順まで公開し、自社の用途に合わせて評価と再学習を繰り返せる環境を提供した点にある。