RLCD解説：なぜTypeSafeはJevを、好かれることではなく自信について正直であるように訓練するのか

Jev 1.13 (typesafe/jev-1.13は、その開発元が「較正された意思決定のための強化学習」— RLCD —と呼ぶ手法で訓練されており、この頭字語は、すでに知っていることを前提とされる業界用語ではなく、TypeSafe自身の造語です。ローンチ記事はそれを言葉そのままに述べています。同社は「新しいモデルアーキテクチャ、最大効率のための並列サンプラー、そして私たちがReinforcement Learning for Calibrated Decisions（RLCD）と呼ぶ訓練手法」を構築した、と。それは、かつて答えが二つしかなかった問いへの第三の答えであり、それが存在する理由は、言語モデルを意思決定の中に組み込もうと初めて試みる多くのチームがぶつかるミスマッチにあります。それに触れる前に、二つの日付が重要です。このページはローンチ記事ではないからです。TypeSafeがモデルそのものを出荷したのは2026-09-15で、これはこのブログが対象とする7日間の窓の外にあり、ここにある内容はJevを新しいものとして位置づけるものとして読まれるべきではありません。日付のある出来事は2026-09-24、OrcaRouterが typesafe/jev-1.13 を自社のカタログに追加し、そのモデルカードを公開したときです。JevがTypeSafe自身のエンドポイント経由だけでなく、サードパーティのゲートウェイを通じて呼び出せるようになったのは初めてです。これがこのページの前提となる変化であり、実務上の帰結は、以下のテクニックが、読んだだけの研究アイデアではなく、すでに持っているかもしれないキーでコード上で試せるものになったということです。

これから述べるのはモデルではなく概念です。このページの最初の3分の1は、RLCDが対抗するものとして設計された2つの訓練手法についてです。なぜならRLCDは、タスクが会話であることをやめて判断になる局面で、それら2つが行うことへの修復策としてのみ意味が通るからです。RLHFとRLVRが何を最適化しているかをもう知っているなら、あなたが読むべきセクションは3番目です。そこでTypeSafe自身の三者比較表が役割を果たします。

RLHFは人が好む回答に最適化する

人間のフィードバックからの強化学習（RLHF）は、事前学習済み言語モデルをアシスタントに変えた手法だ。TypeSafe自身の入門資料は、RLHFと見出しの付いたカードの中で、その目的を淡々とこう述べている。それは「事前学習済みモデルをチャットボットに変えた。人々が好む応答を生成するようにモデルを訓練する」ものだ。InstructGPTとChatGPTはこれで訓練されており、同資料は、ここでは別の理由で関連するある詳細を付け加えている——このアプローチはDiogo Almeidaによって共同発明された。同氏はTypeSafeの共同創業者であり、Jevのローンチ投稿の著者である。同社はその手法を否定しているわけではない。その構築を助けた人物が同社を創業したのだから。同社が主張しているのは、その目的が特定の用途には間違っているということだ。

この不一致をはっきりと見るには、報酬シグナルが実際には何を測定しているのかを問えばよい。RLHFでは、それは2つの候補応答の間で評価者がどちらを好むかを測定している。製品が会話である場合、これは優れた代理指標になる。なぜなら、会話の成功基準は、人がその返答をよいと感じるかどうかそのものだからだ。製品が意思決定である場合、これは壊れた代理指標になる。なぜなら、そこでの成功基準は、示された信頼度が現実と一致しているかどうかであり、もっともらしい2つの段落を比較する評価者には、よく較正された0.6と、自信がありそうに響く0.95との違いを見るすべがないからだ。2つの答えは同じくらい好まれても、ソフトウェアがそれらをどれだけ信頼すべきかという点では、大きく異なりうる。

TypeSafe が入門書で挙げている故障モードは、まさにそこから直接導き出される：

• 迎合性 — モデルは評価者が聞きたがっているものを生成することを学習するが、それは真実とは異なる目標である。

• 自信ありげなハルシネーション — 何の裏付けがなくても、流暢さと確信は選好によって報われる。

• モードドロッピング — 選好最適化は出力分布を狭め、「指示追従のような特定のスタイルを好む一方で、他の起こり得る出力の確率を低下させる」。モードドロッピングは、敵対的生成ネットワークを悩ませる古典的なモード崩壊という失敗の軽度な版であり、そこでは生成器が識別器を騙し続ける単一の出力に収束してしまう。

その入門書自身の警告の段落こそ、残す価値のある一文だ。「ある出力は、人にとって説得力があっても、無人自動化に十分信頼できるとは限らない。人間の選好と機械の信頼性は、異なる最適化目標である」。これは手法としてのRLHFへの批判ではない。選好で訓練されたモデルは、自動化が答えを必要としている問い——これが自信があると言うとき、正確にはどれくらいの頻度で正しいのか——を一度も尋ねられたことがない、という指摘である。

RLVRは、プログラムがチェックできる出力へと最適化する——そして意思決定に、そうした出力が備わっていることはめったにない

検証可能な報酬を用いた強化学習は第二の適応であり、推論モデルの背後にあるものだ。TypeSafeの入門書はそれが生み出したものについて説明している。「数学などのタスクは得意だが、より遅く高コスト」なモデルである。その仕組みはチェッカーだ。タスクにプログラムでテストできる答え——単体テスト、証明チェッカー、数値回答——があるなら、人間に何も尋ねずに報酬を計算でき、モデルはそのシグナルに対して大規模に訓練できる。それは機能しており、安価な自動検証が存在する領域で推論モデルがまさに得意になったのはそのためだ。

限界は、その「検証可能」という言葉の形にある。検証可能な報酬には検証者が必要であり、検証者には、誰かが計算できる正解がそのタスクにあることが必要だ。実際に本番システムが尋ねる問いを考えてみよう。このサポートチケットは請求部門に回すべきか、技術部門に回すべきか？この返金依頼はポリシー内か？この取引は不正に見えるか？それぞれにはほとんどの場合、擁護可能な答えがあるが、プログラムが検証できる答えは一つもなく、最も重要なケースはまさに、経験豊富な人間の間で意見が分かれるケースだ。実行すべき関数はない。RLVRには報酬を与えるものが何もないため、何も貢献しない。

魅力的な回避策は、データセットにラベルを付け、そのラベルに対して学習させることで検証器をでっち上げることだ。それによって手法は検討すべき材料を得るが、無視できない形で目的関数を変えてしまう。ラベルが符号化するのは決定であり、その周辺の不確実性ではない。難しいケースにおけるあるチームの判断を再現するよう訓練されたモデルは、それらのラベルが持っていたのと同じ自信を持つようになる——つまり、ラベルを書いた人間とまったく同じだけ過信するようになる。本物の検証器が存在する場合でさえ、第二のギャップがある。検証器は答えを採点する。表明された自信は採点しない。95%のケースで正しく、しかもそのすべてで確信を示すモデルは完璧な報酬を得てしまい、自動化パイプラインの構成要素としては役に立たない——なぜなら、パイプラインが知らされる必要があったのは5%の部分だけだったからだ。TypeXのローンチ資料は、逆の方向から同じ点を指摘している。「モデルがタスクを95%の時間で実行できても、自分が5%に入っているときを言わなければ、そのタスクを自動化することはできない。」

TypeSafe自身のフレーミングによる、RLCDが果たすこと

RLCDは、回答の品質ではなく、出力の契約を変える。プライマーのカードにはこうある。「較正された意思決定のための強化学習は、TypeSafeを訓練して、生成されたテキストではなく、意思決定と較正された確率を返させる。」ローンチ投稿の簡潔な版は、「較正された意思決定：System Oneタスクにおける認識論的に正直な確率を伴う回答」だ。どちらも一つの手を説明している。すなわち、モデルを、人やチェッカーがその回答を気に入ったかどうかではなく、自ら示した確率がその回答が実際に正しかった頻度と一致したかどうかに照らして訓練する、ということだ。

ローンチ投稿は3つの手法を並べており、その対比こそ、存在する中でこの考えを最も明確に述べたものだ。表としてではなく、一連の対比として読んでほしい：

• 何を最適化するか — RLHFは人間の選好を最適化する。「人間の評価者が好む文章やチャット応答」；RLVRは「プログラムで検証可能な出力」を最適化する；RLCDはキャリブレーションを最適化する。「システム1のタスクにおける、認識論的に誠実な確率を伴う回答」

• 入力となるもの — 上の2つは「逐次的なメッセージに重点を置いた」非構造化データを扱い、キャリブレーション済みの決定モデルは「構造化されたプログラム状態に重点を置いた」非構造化データを扱う。

• 出力されるもの — 「解析と検証が必要」な生成文字列であり、「AI が脱線してしまうリスクが常につきまとう」のに対し、型安全な構造化値では「取り得る出力と構造があらかじめ定義され」、モデルは「型エラーを決して起こさず」、「すべての回答には較正された確率と信頼スコアが付随する」。

• どのようにサンプリングされるか — 一度に1トークンずつ、それぞれが直前のトークンに条件付けられ、単一のクエリで生成されるすべての出力をまとめて扱うのとは対照的である。これが、3番目の方法が安価である機械的な理由である。支払うべきデコーディングループが存在しない。

• コスト — 比較対象モデルでは、入力トークンが100万あたり0.20ドルから10ドルで、出力はおおよそ入力価格の5倍。これに対してJevでは、入力トークン100万あたり0.042ドルで、出力は課金ゼロ。

• 応答の速さ — フロンティアモデルではエンドツーエンドで3～329秒、それに対して70ms～500msで、ベンダーはこれをSystem One的なクエリにおいて40～200倍高速だと特徴づけている。

• 自身の自信について述べていること — 旧来の2つは、信頼度の推定を促された場合でも「自信過剰で一貫性がない傾向がある」；RLCDは「あらゆる出力で自信と不確実性を常に伝え」、そこでは「自信が高いほど精度が高い」。

最後の行こそが実際の製品主張であり、他のものとは異なり反証可能だ。「信頼度が高いほど精度も高い」は曲線に関する主張である。モデルの回答を、それが付与した確率によってバケット分けすると、各バケットはその確率が主張するおおよその割合で正しくなるはずだ。TypeSafe の confidence ドキュメントは、その契約を異例なほど具体的な数字で明記している：

• 確率0.2が割り当てられた結果は、約20%の頻度で発生するはずです。

確率0.8が割り当てられた結果は、約80%の頻度で発生するはずです。

• 確率1.0が割り当てられた結果は、常に100%の確率で発生するはずです。

そして、その主張を誠実に保つ一文が、ベンダー自身の言葉で続く。「これらの率は予測の集まりを表すものであり、個々の回答についての保証ではありません」。それは法的な理由で後付けされた逃げではない。それがキャリブレーションの意味のすべてだ。0.8と言う、よくキャリブレーションされたモデルは、今回は正しいと約束しているのではない。0.8とラベル付けしたすべての回答を通じて、およそ5件に4件が正しかった、と約束しているのだ。1つの回答では何もわからない。1週間を通した1000件の回答が、その曲線が本物かどうかを教えてくれる。

同じ3枚のカードによる対比は、TypeSafe自身のドキュメントに載っています。それは上記の比較の出典であり、要約を鵜呑みにするのではなく、文言そのものを確認するのに最も明確な場所です。下のキャプチャは、今日時点でのそのページのままです。3つのポストトレーニング手法に対応する3枚のカードがあり、3枚目にはRLCDが略さずに記されています。

ベンダーのドキュメントにあるさらに二つの詳細は、この手法が製品にどこまで深く入り込んでいるかを示している。第一に、信頼度は生成されるのではなく導出される。モデルは、あなたが提供した選択肢やレベル全体にわたる完全な確率分布を返し、信頼度の値はその分布の形状から計算される統計量である。だからこそドキュメントは、その定義が決定的な意味を持つわけではないと説明できる — どちらにしても生の分布が得られ、自分の統計量のほうがよく適合するなら自分で計算できるのだ。第二に、重みを形作る唯一のものはRLCDだ。TypeSafeのモデルページには次のように記されている。「Jevは顧客データでファインチューニングやLoRA適応はされていない。RLCDで訓練され、較正された意思決定を返し、同じ重みがあらゆるアカウントに使われる。」ドメイン適応はリクエスト内で起こる — あなたの状態、あなたの基準 — 顧客ごとのチェックポイントではない。この手法が生み出した較正は、どの顧客も得る較正である。

なぜキャリブレーションが、安価な意思決定モデルを使い物にするのか

キャリブレーションされた確率は、それ自体では興味深いものではありません。コードがそれに基づいて分岐する瞬間に、それはアーキテクチャになります。そしてTypeSafeの信頼度ドキュメントは、まさにそのパターンを3つの範囲として説明しており、それぞれが異なるシステム動作を生み出します。

• 確信度が高い — 自動的に実行します。モデルが明確に判断しているため、人による関与なしに進めることができます。

• 中程度の信頼度 — 注意して進めてください。モデルには妥当な回答がありますが、確実ではないため、行動する前にユーザーに確認する、レビューのためにフラグを立てる、または追加情報を収集してください。

• 信頼度が低い — 行動しないでください。人間に回す、明確化を求める、または別のシステムにフォールバックしてください。モデルが判断するのに十分な材料がないと伝えているからです。

ドキュメントは、境界線はあなたが引くものであり、結果によって異なるべきだとはっきり述べている。「信頼度しきい値は単一の数値ではない。同じシステム内でも、操作が異なれば、間違えたときの結果に応じて異なるレベルでゲートされるべきだ。」彼らの具体例では、0.5 に絶対的な下限を設けている——モデルがそれ未満を報告したものは、それ以上の検査なしに人間に回される——そして、破壊的な操作には読み取り専用の操作よりも高い基準を適用している。あなたのコードがリスク許容度をエンコードし、モデルはそれに対する正直な入力を提供する。

そのパターンは、2モデルワークフローを正当化する論拠そのものであり、機能一覧としてではなく、一つの論拠として述べる価値がある。自信をもって判断できる大多数のケースを処理し、残りをより大きなモデルや人間にエスカレーションする自動パイプラインを望んでいるとしよう。エスカレーションの判断は、どこかから出てこなければならない。安価なモデルが、推測しているケースも含めてすべてに0.98を報告するなら、その分岐にはテストするものが何もなく、エスカレーションすべき判断まで含めてすべてを自動化するか、何も自動化しないかのどちらかになる。自信の度合いが有益な情報となるモデルだけが、部分集合を安全に自動化できるようにする。なぜなら、どの部分集合で安全でないかを教えてくれるのは、そうしたモデルだけだからだ。ドキュメントは同じ点を、その率直さゆえに引用する価値のある一文で述べている。「知的システムが、人間であれ機械であれ、正直な不確実性を表現できないなら、そのシステムは信頼できない。」

これが高価なモデルよりも安価なモデルにとってより重要になる2つ目の理由であり、ルーティングの話とRLCDの話が同じ話である理由でもあります。入力トークン100万あたり$0.042で、出力課金がないモデルは、常に参照するのに十分安価です——エージェントループの毎ターン、バッチ内の各レコード、チケットが届くたびに。常に参照される状況は、まさにモデルの誤りが複合していく状況です。なぜなら、その出力が実行に移される前に誰も読んでいないからです。それを安全にするのは確信度です。安価さはエスカレーション分岐を手頃なものにします。高価な経路は、安価なモデルが辞退したごく一部のケースでしか実行されないからです。どちらの半分も片方なしでは機能せず、両者を結びつけるルーティング判断は、RLCDが信じるに足る根拠となる数値に対するしきい値です。

正直な限界：較正済みであることは正確であることではない

RLCDについて最も重要なのは、それが主張していないことだ。較正は信頼度の性質であり、答えに関する保証ではない。そしてベンダーは、それを批評家に任せるのではなく、自社のドキュメントでそう述べている。System Oneのページにはこうある。「System Oneのモデルは較正された意思決定のために訓練されている。その確率は、不確実性を反映するように結果に対して最適化される。較正は予測のグループ単位で測定されるものであり、個々の答えが正しいことを保証するものではない。」モデルは完全に較正されていても、あなたのチケットで誤った判断を下すことがある。0.9は10回中9回を意味し、今回はその10回目かもしれないからだ。

ここで有用な対抗軸となるのは、私たち自身の配信実測値です。それはまさに、この手法が何を達成するかという主張ではなく、本番環境におけるモデルの測定値だからです。2026-09-30 で終わる 7 日間について、モデルがカタログに追加されて以降の OrcaRouter のプレイグラウンド経由のトラフィックでは、Jev 1.13 のカードは 7,620 万トークンにわたる 0.49% のエラー率を報告しており、あわせて最初のトークンまでの時間の p50 が 151 ms、p95 が 247 ms、出力は毎秒約 349 トークンです。その数値について、はっきりと言っておくべきことが 2 点あります。これはベンダーのものではなく私たちの数値であり、固定のテストセットではなくローリングウィンドウです。同じフィールドはウィンドウの前半には 0.57% を示していました。直近 7 日間の実トラフィックに対して再計算され、昨日の呼び出しが対象から外れていくからです。また、これはキャリブレーションの測定値でもありません。エラー率は、私たちのトラフィックでどれだけ頻繁に問題が起きたかを示すものであり、信頼度の値が誠実だったかどうかは示しません。それは別の問いであり、答えるにはラベル付きデータが必要です。

これは、ベンダーが自社のしきい値ガイダンスに添えた注記でも示している実践的な指示でもある：「正しいしきい値は、あなたのドメインとユースケースに対するモデルの性能に依存します。保守的なしきい値から始め、自分のデータでテストし、結果を観察しながら調整してください。」RLCDは、モデルがどのように訓練されたかに関する主張である。その主張があなたの入力で成り立つかどうかは実証的な問いであり、機械学習のインフラを一切使わずにテストできる数少ないモデル特性の一つだ——すでにラベルがある数百件のケースを取り、モデルが報告した信頼度で回答をバケット分けし、各バケットが主張どおりの割合で正しいかを確認する。0.9のバケットがあなたのトラフィックで約90%正しければ、そのしきい値は本物であり、それより上を自動化できる。すべてが0.9より上に固まっているのに精度がそれに追随しないなら、どんな見出しの数字よりも役立つことを学んだことになる。

さらに二つの限界も、併せて述べておくべきだろう。第一に、このモデルについて、そのいずれかを照合するための公開ベンチマークカードが存在しない。ベンダーは公開しておらず、サードパーティのリーダーボードにもこのモデルは載っていない。Artificial Analysis のこのモデルのモデルページは、2026-09-30 時点で 404 を返す。したがって、キャリブレーションの議論は、公開された曲線ではなく、トレーニングの説明、文書化された契約、そして自分で測定したあらゆるものに依拠することになる。第二に、ベンダー自身の性能主張はあくまでベンダー自身のものである。ローンチ記事は、速度とコストという見出しの背後にあるワークフロー評価が同社のモデルケイパビリティチームによって構築されたこと、それらを測定する際の参照回答が2つの外部モデルの平均であること、そして数値が「実世界での改善幅としては高めの側」にあることを率直に記している。また、価格設定が補助金なしであることは証明できないとも述べている。そのどれもトレーニング手法を損なうものではない。それは速度の主張とは別の主張である。しかし、それは RLCD の論拠が、確定した実証結果ではなく、目的設計に関する議論であることを意味する。それを安価に検証できる仮説として扱おう。これは、ほとんどのトレーニング手法の主張があなたを置く立場よりも良い立場だ。

今日これでできること

議論の2つの項は1か所で交わる。RLCDは、意思決定モデルの信頼度を分岐の判断に使う価値がある理由であり、コード内のしきい値はその分岐が存在する場所であり、エスカレーションが経済的に成り立つのは、共通パスがどこでも実行できるほど安価な場合だけだ。Jev 1.13はOrcaRouter上でtypesafe/jev-1.13として呼び出し可能だ — 200以上のモデルに対応する1つのAPI、マークアップ0%、プロバイダーの定価をそのまま適用、そのためベンダーの値下げはここでも当日から有効になる — つまり、確信度の高い多数派のパスと生成エスカレーションのパスは、2つのベンダー契約ではなく同じキーで課金される。それでも、これは独自の形式で、POST /v1/systemone、非ストリーミング、65,536トークンのコンテキストに対して呼び出す必要がある。なぜなら、それはOpenAIのchat-completionsルートではなく、チャットエンドポイントに統合されているわけでもないからだ。接続するのであれば、ベンダーのSDKリリースによる日付付きの2つの注記を知っておく価値がある：バージョン0.7.1は2026-09-21にリリースされ、AIゲートウェイでの使用例を追加し、バージョン0.7.2は2026-09-26にリリースされ、Pythonパッケージにhttp2エクストラを追加した。2つ目はリリースノートにしか現れない種類の詳細だ — 価値提案のすべてが200ミリ秒未満のラウンドトリップにあるモデルにとって、HTTP/2クライアントを持つ価値がある。

このページから一つだけ持ち帰るなら、RLCDが答える問いの形を持ち帰ってください。それは「モデルはより賢くなれるか」ではありません。「モデルは、自分が十分に賢くないと、残りを自動化できる程度に頻繁に、かつ正確に教えてくれるか」です。それは、この分野がここ数年取り組んできた二つの研究目標とは異なるものであり、あなたのコードが行動に移せる数値を生み出す唯一のものです。信頼度の値がその数値です。信頼する前に、自分のラベルでそれをテストし、正しくなっていてほしいと思う閾値ではなく、間違っていたら恥ずかしいと思う閾値から始めてください。

全体像の最後のピースは、これまでのすべてと並べて心に留めておく価値があります。なぜなら、それはこの議論全体が狙っている数値であり、主張ではなく実測されたものだからです。下のカードは、typesafe/jev-1.13 についての私たち自身の7日間のサービング記録です。訓練手法ではなく、ベンチマークでもなく、実際に本番で動いているモデルです。これをキャリブレーションの問いの後半として読んでください。信頼度は、どの呼び出しに対処すべきかを教えてくれます。そしてこれは、残りのルーティング判断が、放置して任せておけるシステムにどれだけ近いかを教えてくれます。