OpenAIはJevの牙城を崩すかもしれない
OpenAI is about to eat Jev's lunch – Arcturus Labs (arcturus-labs.com)
要約
TypeSafeのJevは、LLMを活用した新しいアプローチでAI界を席巻していますが、OpenAIがその機能を模倣し、自社のモデルやエージェントに統合する可能性が指摘されています。Jevの成功の鍵は、その訓練データとプロセスにあると考えられており、OpenAIがそれを再現できるかどうかが今後の焦点となります。
全文翻訳
OpenAIはJevのランチを奪うのか？
TypeSafeのJevは、大規模言語モデル（LLM）に新しいアプローチをもたらし、AI界を席巻しました。Vercelによると、「JevはAI Gatewayの歴史上、どのモデルよりも速く採用されました」。しかし、地平線には暗雲が立ち込めています。OpenAIは間違いなく注目しており、次の一手を決めているでしょう。
［画像: 丸々としたOpenAIのロボットが唇を舐め、幸せそうに食べている痩せたTypeSafeのロボットが持つ巨大なサンドイッチに手を伸ばしている。］
TypeSafeの成功を心から願っていますが、もし彼らが約束を本当に果たすなら、OpenAIはJevの主力製品を模倣するだけでなく、その能力を今後のモデルやエージェントに組み込み、Jevが再現できない非常に有用な新しい振る舞いを提供できる位置にいると懸念しています。
私の見解を簡潔に述べると、OpenAIは何年も前からLLMを暗黙的な分類器として使用してきました。ただ、汎用的な分類タスクのために訓練しておらず、汎用分類をスタンドアロン製品としてパッケージ化していなかっただけです。もしOpenAIがその訓練を再現できれば、短期間でJevを再現できるでしょう。さらに、OpenAIは既存のモデルやエージェント内でこの新しい分類器を使用する位置にあり、これはモデル選択の迅速化、より効率的な思考、より優れたセキュリティガードレール、そして一般的にスマートで高速かつ安価なモデルに役立つ可能性があります。
これらすべてを決定する鍵は、TypeSafeに自社を守るための「堀（moat）」があるかどうかです。私が見る最大の堀は、TypeSafeの学習データと学習プロセスにあります。
古いものが新しくなる
私の主張をする前に、私の仮定を述べ、OpenAIからの関連する歴史と例で裏付けたいと思います。
私の主な仮定は、Jevが従来のLLMに非常に近いものを使用しているということです。その証拠として、Latent Spaceは、初期のクローン（模倣モデル）の多くが実際にLLMベースであると報告しています。
アイデアはこうです。state（状態）と一連のquestions（質問）が与えられた場合、JevのLLMは単一のトークン、より正確には、すべての可能な次のトークンに対する確率分布を生成します。その1ステップにおけるすべての可能なトークンのlogprobs（対数確率）は、Jevが必要とする形式にマッサージされます。（以降、便宜上「確率」と呼び、「対数確率」とは呼びません。目的においては交換可能です。）
noul（真偽）の質問に対して、Jevはtrueとfalseの2つのトークンのみを見て、それ以外のすべてを無視し、それらの確率を正規化して、答えがtrueである単一の確率を生成します。choice（選択）の質問に対して、Jevは、例えばA=happy, B=sad, C=angry, D=afraidのような可能性のリストを与えられ、それらの4つのトークンの相対的な確率を見て、完全な分布を構築し、最も高いものを勝者として選択します。この選択パターンは、私が2025年にSupercharging LLM Classifications with Logprobsでブログに書いたこととほぼ同じであり、ファインチューニングなしでもすでに有望でした。（ため息…アイデアと実行の重要性について、彼らは何を言っているのでしょう？）score（スコア）プリミティブについては深く考えていませんが、これも同じパターンのバリアントだと推測しています。
この投稿の前提の一部は、OpenAIがこのアイデアをすぐに活用できる可能性があるということです。そして、それがどのように可能になるかを理解すれば、これはより明確になります。OpenAIは、少なくともツール呼び出し（tool calling）が導入されて以来、LLMを暗黙的に特殊な分類器として使用してきました。
2024年初頭、私はTool Invocation – Demonstrating the Marvel of GPT's Flexibilityという記事を書きました。そこで私は、GPTモデルがツールを呼び出すかどうかをどのように決定するかを正確に明らかにすることに成功しました。以下は、内部でチャットセッションがどのように見えるかです。ここでは、ユーザーメッセージ、ツール呼び出しなしのアシスタント応答、そしてツール呼び出しありのユーザーメッセージがあります。
［画像: ChatMLのトランスクリプトで、各トークンが異なる色でハイライトされ、トークンの境界を示している。最後にベルリンのget_temperatureのためのツール呼び出しで終わる。］
テキストを色分けしてトークンの境界を示しました。ChatMLを初めて見る方のために説明すると、これはOpenAIがユーザーとエージェントの会話プロンプトを整理するために導入した内部マークアップ言語です。<|im_start|>と<|im_end|>はメッセージを区切る予約済みトークンであり、<|im_start|>の直後の最初のトークンが話者（userまたはassistant）を識別します。
<|im_start|>assistantの直後、モデルが最初に予測するトークンは またはto=function.のいずれかです。もし を予測した場合、通常の自然言語応答を続けます。もしto=function.を予測した場合、そのトークンシーケンスは、ツールを呼び出すべきかどうかを決定する分類器として機能します。次の数トークンがどのツールを呼び出すかを識別します – get_temperature – これは別の分類器で、利用可能なツールのリストから選択します。その後に、モデルは引数名を生成し、次に引数値（これも分類器または推定器と見なすことができます）を生成します。最後に、モデルが<|im_end|>トークンを生成した場合、それも「メッセージが完了した」と判断する分類器です。
一部のLLMは、いつ黙るべきかを知りません – これは面白い余談です。
私がGitHubでCopilotに取り組んでいた頃、GPT-4の非常に新しく、非常に未加工の内部APIを扱う機会がありました。最初から、何かが大きく間違っていることに気づきました。なぜなら、最初は非常に首尾一貫した応答の後、モデルは終了するのに苦労したからです。それは、応答の最後に「他に質問があればお知らせください。良い一日を。素晴らしい一週間を。楽しい時間を。素晴らしい人生を。特別な一日を。…」のようなものを付け加え、応答トークン制限に達するまで続けました。
APIは、モデルがこれらの特別なメッセージ区切り文字<|im_start|>と<|im_end|>を使用できるようにするヘッダー値を設定する必要があることが判明しました。実質的に、モデルに応答の終了を予測させないようにしていました – 文字通り、内部的に自分自身をシャットダウンする能力がなかったのです！
その古い投稿で私が述べた点は、OpenAIは何年も前から単一トークンを小さなマイクロ分類器として使用してきたということです。各トークンには確率が伴っていました – ツールを使用すべきか否か、どのツールを使用すべきか、アシスタントは終了したか。それがJevのトリックのすべてですが、重要な点が一つあります：これらのマイクロ分類器は専門家であり、これらの小さなタスクにのみ適していますが、Jevの分類器は汎用的です。しかし、一歩二歩戻って見ると、これが実は些細なことである可能性が見えてきます。なぜなら、LLMは本質的に、すべての後続トークンに対して確率分布を常に割り当てている、驚くほど汎用的な分類器だからです。
TypeSafeには堀があるのか？
私はJevを応援しています。彼らは私たちのすぐそばに隠されていた非常に興味深いものを見つけたと思います。
アーキテクチャ的には、上記の理由から、あまり堀はないと考えています。TypeSafeはJevに従来のLLM、またはそれに近いものを使用していると思います。たとえそうでなくても、従来のLLMは汎用分類作業に適しているようです。
おそらく本当の堀は、学習データそのものにあります。生のデータではなく、それをJevを「キャリブレーションされた（calibrated）」状態に訓練するための技術です。TypeSafeの共同創業者であるDiogo Almeidaは、データがアーキテクチャよりも重要だと示唆した人に対して、次のように述べています。
データについて話している人はあなたが初めてかもしれません！🥲 私たちは自分たちをデータ研究ラボと考えています！研究の大部分は、真に汎用的なデータ（認知コアのようなもの）を作成することに費やされており、私たちのデータは100%合成です（もちろん、LLMから吐き出されるようなゴミではありません）。
— Diogo Almeida (@CompleteSkeptic) 2026年9月17日
もし私がそのデータセットを構築するとしたら、結果がすでにわかっている例を大量に集めたいと思います – サポートチケットとその実際のルーティング方法、履歴書とその候補者が実際に採用されたかどうか、製品レビューとその実際の星評価、モデレーションキューとその実際の判定、予測市場とその実際の解決方法 – それぞれに、真実の答えがすでにわかっている質問をペアにします。ポイントは、Jevにサポートチケットや履歴書について具体的に教えることではありません。それは、非常に異なるドメインにわたる何千もの状況を示し、広範なドメインにわたる分類を一般化する能力を構築することです。
次に、強化学習があります。これが何を意味するのか疑問です。Wikipediaデモや彼らのサイトで構築しているDoomデモのような限られた選択肢を持つ決定をナビゲートする自律エージェントでしょうか？事前学習カットオフ後に発生したイベントの結果を予測するのでしょうか？わかりませんが、秘密のソースがあるなら、それはおそらくここにあるでしょう。
これらは、Jevが実際に正確でない限り、堀ではないことに注意してください。速度、コスト、使いやすさは明白ですが、正確さはチェックするのが難しい唯一のものです。すでにJevの確率が通用しないドメインを見つけました。Jevが人々が使用しようとしているユースケースに対して十分に汎用的で正確であるかどうかは、時が経てばわかるでしょう。
もうすぐOpenAIの番だ
では、OpenAIの次の一手は何でしょうか？明らかなのは、Jevをコピーして新しいモデルタイプとして出荷することです。Jevは明らかに人気があり、堀が浅いのであれば、OpenAIはその実行能力、ハードウェア、資金を持っています。
しかし、OpenAIはJevをコピーするよりもさらに興味深いことを行うことができます。分類能力を従来のLLMに組み込み、興味深い報酬を得ることができます。
自身の質問に答えるLLM
ツールの呼び出しを示唆するあの特別な構文、to=function.を覚えていますか？OpenAIはここで同様のことを行うことができます。新しい構文、例えば新しいタグ<prediction>を導入し、モデルが迅速な分類器の判断を必要とするたびに、それを自身のコンテキストに挿入できるようにします。以下はその例です。
<user>
ドニーが今日私に「素敵な髪型だね」と言いました。彼は私のことが好きなのでしょうか？
</user>
<assistant>
<thinking>
これを評価してみましょう。
<prediction>
claim: ドニーはジェスに恋愛感情を抱いている。
probability: 0.04
</prediction>
「素敵な髪型だね」は、愛の告白とは言えませんね。
</thinking>
残念ですが…おそらくそうではないでしょう。
</assistant>
通常のツール呼び出しとの興味深い違いが一つあります。通常のツール呼び出しでは、モデルは関数名と引数を生成し、その後生成が停止します – エージェントハーネスが引き継ぎ、実際にその関数を呼び出し、結果を新しいターンでフィードバックする必要があります。ここでは、ハンドオフがありません。分類器はモデルの外部にあるツールではなく、モデル自体に組み込まれた機能です。モデルは質問し、GPUから離れることなく、同じ息吹の中でそれに答えます。
通常のデコーディングは次のように機能します：各位置で、モデルは語彙トークンごとにセットのロジットを生成します。それらはソフトマックスを介して確率分布に変換され、次にデコーディング戦略（greedy、top-pなど）が単一のトークンを選択し、それがシーケンスに追加され、次のステップのためにフィードバックされます。しかし、モデルがprobability:と書いた時点では、通常のデコーディングは望ましくありません。主張はステートメントとして提示されているため、内部的にはモデルは依然として2つの暗黙的な結果、trueまたはfalseを比較しています。私たちはその位置のtrueとfalseトークンのロジットを読み取り、それらだけを互いに正規化し、結果の確率をテキスト、0.04としてシーケンスに書き戻したいのです。通常のトークンが勝つ場合とは異なり。これは奇妙なトリックですが、制約付き出力ライブラリが推論時に既に行っているものと同じ種類のガイド付きデコーディングです – ただ確率に対して適用されるだけです。
もう一つのトリックは、この1つの特別な位置が通常のトークン予測とは異なるように動作する必要があることです。通常、モデルは「このテキストで次に何が来るか」を推定しています。ここでは、「この質問の真の答えは何か」に近いものを推定させる必要があります。これは関連していますが、異なるスキルです。最近のフロンティアモデルはすべてエキスパートの混合（Mixture of Experts）であるため、ファインチューニングの数ラウンドで、この種のキャリブレーションされたスナップジャッジメントに特化したエキスパートを切り出すことができると想像するのは難くありません。モデルの残りの部分は、既に得意なことをやり続けます。（MoEルーティングを大幅に単純化していますが、これが実際のシステムにどのようにマッピングされるかは理解できると推測します。）
組み込み分類機能を持つLLMのメリット
あのドニーとジェスの例で、モデルがどのように自身を使用したかを見てください。TypeSafeが正しいとすれば、これらのJevのような小さな判断は非常に正確であり、モデルにテキストで信頼度を述べさせるよりも幻覚を起こしにくいでしょう。（注意点があります – TypeSafe自身のJevのギザギザしたエッジの概要を参照してください。Jevは高速なSystem One（直感的判断）の判断には最適ですが、数学やマルチホップ推論には向きません。）
最良の部分は、この新しい、電光石火の汎用分類システムを活用するために、GPUから離れる必要がまったくないという前述の事実です。LLMは文字通り、上記の例のように、思考ブロック内で自身に質問し、答えることができます。メリットは即時的です：モデル自身の推論は、訓練済みのキャリブレーションされた推定値と、可能性のある次のトークンの感覚ではなく、自身の仮定をチェックするため、より正確で、より確かなものになります。
そして、モデルが自身の思考に<prediction>を挿入するようにファインチューニングされたら、ロマンスのアドバイスで止める理由はありません。さらにいくつかのパターンが考えられます：
長い推論トレース中に、モデルは定期的に完了したかどうかを確認し、完了していない場合は次にどのタスクに取り組むべきかを確認できます：
<prediction>
query: 残りのタスクのうち、次にどれを実行すべきか？
options: A=テストスイートがパスすることを確認する, B=変更ログを更新する, C=何もしない、完了した
probabilities: A=0.71, B=0.24, C=0.05
answer: A
</prediction>
これは、モデルが停止するまで待つのではなく、迷走している推論トレースをショートカットするための安価な方法です。
または、ツール呼び出しの直後に、モデルは実際に実行する前に呼び出しが安全かどうかを確認できます：
<user>
アカウントの残高を確認してもらえますか？認証にはAPIキー`sk-live-83fj2ndk9`を使用してください。
</user>
<assistant>
to=function.check_balance
{"account_id": "12345", "api_key": "sk-live-83fj2ndk9"}
<prediction>
claim: このツール呼び出しは実行するには安全ではない。
probability: 0.97
</prediction>
プレーンテキストの引数にライブAPIキーが含まれています – そのまま送信するにはリスクが高すぎます。
</assistant>
同じパターンは、プロンプトインジェクションのためにツールの応答をスキャンする場合にも機能します。そして、常に同じ質問が同じ方法で尋ねられるため、スコアが低すぎると生成を停止するようにモデルに指示を組み込んだ<safety_score>0.94</safety_score>のようなものに砂糖漬けにされると想像するのは簡単です。
同じトリックは、モデル間で作業をルーティングすることもできます：定期的に「このタスクはより大きなモデル、より小さなモデル、またはこのモデルが必要か？」と尋ね、強化学習で精度を犠牲にすることなく最も安価な方に回答を押し出すようにします。
<prediction>
query: このタスクは、より大きなモデル、より小さなモデル、またはこのモデルが必要か？
options: A=より大きなモデル, B=より小さなモデル, C=このモデル
probabilities: A=0.05, B=0.77, C=0.18
answer: B
</prediction>
さらに、もし本当にこれらのスナップジャッジメントに特化した「エキスパート」がいるなら、モデルはほとんどの場合、特別な<prediction>構文を必要としないかもしれません。それは、GPUパスの途中で、通常のプロセスの一部として、スナップジャッジメントが正当化されるときにルーティングされるだけかもしれません – タグは不要です。LLMが行う他のすべてのことを処理するモデル内でそのエキスパートをファインチューニングすることは、相乗効果をもたらし、LLMをスナップジャッジメントにより賢く、分類においてより柔軟で汎用的にするかもしれません。
最後に、誰もが画像や音声の分類を、それが可能になり次第欲しがるでしょう。もしJevスタイルの分類が、私がここで概説したような従来のテキストLLMに組み込むことができれば、すぐにOpenAIは画像や音声に対しても汎用分類を提供できるようになるでしょう。逆に、音声モデルに組み込まれた分類は、ライブボイスエージェントのようなものに特に役立つでしょう – リアルタイムで、割り込むべきか、エスカレートすべきか、あるいはただ聞き続けるべきかを決定します。
TypeSafeは生き残るか？
Jevの精度と汎用性に関する主張が、人々がすでに投入しているすべてのタスク範囲で実際に通用するかどうかは、時が経てばわかるでしょう。もし通用するなら、TypeSafeの存続は堀にかかっています：彼らの学習データと強化学習プロセスを再現することがどれほど難しいかです。それが本当に難しいなら、彼らはたぶん大丈夫でしょう – そして、OpenAIに競争で負けるのではなく、むしろ買収されるという、非常に良い立場にさえなるかもしれません。私がここで概説したすべては、フロンティアラボにとって実際の能力アップグレードです：より速い思考、より安価な思考、そしてフラッグシップモデルに直接組み込まれた、よりシャープなSystem Oneの判断。
もし堀が薄ければ、OpenAIはそれを自社で構築するだけで、TypeSafeの窓はすぐに閉まるでしょう。
一方、TypeSafeの創業者兼CEOであるDiogo Almeidaは、「モデルの品質が重要なら、私たちは長い間非常に良い位置にいるでしょう」と自信を持っています。（Latent Spaceとのインタビューより）
TypeSafeよ、幸運を祈る。幸運を祈る。
追加情報：14日後
それは速かった。Jevのローンチから14日後のDevDay 2026で、OpenAIは限定プレビューでDecisions APIを発表しました：コンテキストと制限された質問を入力し、1つの許可された回答を出力します。Luna 6で実行されるJevと同じ形状で、報告によると約150ミリ秒です。さらに、画像コンテキストは初日からサポートされており、Jevはテキストのみです。
精度は、これら両方にとって依然として未解決の問題です。これらのモデルは推論を使用できません。そうでなければ、これほど速くはありません。代わりに、入力の迅速なスナップジャッジメントを行っています。どれほどうまく訓練されていても（そしてTypeSafeはここで真のキャリブレーションの特別なソースを持っているかもしれません）、どちらのモデルもあなた自身のカスタムな社内プロセスで訓練されていません。それらすべてはプロンプトに生きなければなりません。では、訓練したことのない基準に対する即時の直感的な反応が、どのようにして信頼性の高い良い答えを与えるのでしょうか？未定！