TypeSafe AIのJevとは何か 文章は書かないが業務の判断を低コストで速く提示するAI
日本時間の9月16日未明、TypeSafe AIという会社が最初のモデル「Jev」を発表しました。創業者のDiogo Almeida氏は、ChatGPTにも使われたRLHFという学習手法を示したInstructGPT論文の著者の一人で、元Google Brainの研究者です。本人のXでは「ChatGPTを共同発明したあと、ずっと自問してきた。チャットで超人になったモデルが、なぜAGIにつながらないのか」と書いています。2年間ステルスで作って出した答えが、Jevです。
Jevが何なのかは、一言で言えます。文章を書かないAIです。質問を投げても、返事もコードも説明も書きません。Jevが返すのは「どれか」「何点か」「本当か」という答えと、その確率だけです。これまでのLLMが捨てなかったものを捨てて、その代わりに速さと安さと、答えの形が崩れない保証を手に入れた、というのが本人の主張です。この記事では、何ができて、何ができず、中小企業の業務のどこに置けるのかを、公式の文書と本人の発言で確かめます。まだ早期アクセス(順番待ち)の段階で、筆者は実機では試せていません。先に触った第三者の結果は後半で紹介します。
Jevが返すのは文章ではなく、答えと確率
Jevに渡すのは2つです。判断してほしい材料(問い合わせの文章、書類、アプリの状態など)と、型の決まった質問。質問の型は3つしかありません。
| 型 | 聞き方の例 | 返るもの |
|---|---|---|
| Choice | どの部署が担当すべきか | 選んだ選択肢と、各選択肢の確率、確信度 |
| Score | 顧客はどれくらい怒っているか | 段階の点数と確信度 |
| Noul | この文は急ぎか | 0〜1の確率 |
公式の入門ページにある例が分かりやすいです。「Stripeの接続が3日間失敗していて売上が落ちている、すぐ助けてほしい」という問い合わせ文を渡し、3つの質問を同時に投げると、次のような答えが返ります(小数は第2位あたりで丸めています)。
- 担当部署: technical(確率0.84。billingが0.16、salesが0.001)、確信度0.60
- 怒りの度合い: 1.04(0=冷静、1=不満だが丁寧、2=激怒、の3段階)、確信度0.84
- 急ぎか: 0.999
ここで大事なのは、3つの質問が1回の呼び出しで、並列に、互いに独立して評価されることです。公式は「質問を増やしても応答時間はほとんど変わらない」「質問同士が干渉しないので、文脈が長くなって答えが劣化する問題が起きない」と書いています。LLMに10個の判断を1つの出力にまとめて頼むと、前の答えが後の答えに影響し、聞く順番で結果が変わることがありますが、Jevは少なくともその生成順による干渉が起きない設計です。
「ハルシネーションしない」の正確な意味
発表文には「Jevはハルシネーションできない」とあります。ここは意味を正確に押さえる必要があります。Jevがしないのは、型の外の答えを出すことです。選択肢がbilling、technical、salesの3つなら、その3つ以外は返ってきません。JSONの形が崩れることも、存在しない項目名を作ることもない。公式はこれを「型のエラーは数学的に不可能」と書いていて、反例が1つあれば崩れる主張なので確かめやすい、とも言っています。
一方で、選んだ答えが正しいかどうかは別の話です。公式ドキュメントのSystem Oneの説明には「確率の当たり具合は予測の集まりに対して測るもので、個々の答えが正しいことを保証するものではない」と明記されています。「technical 0.84」は、確率がよく合っているモデルなら、0.84前後で答えたケースを集めるとおよそ84%が正しい、と期待できる値です。この1件が正しいという意味ではなく、自社の用途で本当にその割合になるかは、自分のデータで測るしかありません。
その代わりに手に入るのが、「分からない」を言える仕組みです。確率がどれか1つに集中していれば確信が高く、ばらけていれば低い。ChoiceとScoreにはこれを0〜1にまとめた確信度が付き、Noulは0〜1の確率そのものを見ます。コードの側で「確信が高ければ自動で進め、低ければ人に回す」と書けるのはそのためです。公式の確信度の解説にある言葉を借りると、「正直に不確かさを表現できないシステムは、人でも機械でも信用できない」。LLMに「自信はどれくらい?」と聞いても過信気味で一貫しない、というのが本人たちの見立てで、そこを学習の目標そのものに据えたのがJevです。
なぜ速くて安いのか、そのために何を捨てたか
数字は目を引きます。発表文によると、同社の測定で応答は70〜500ミリ秒。入力は百万トークンあたり0.042ドルで、出力は「安すぎて課金しない」。同じ比較表では、既存のLLMが入力0.20〜10ドル、応答3〜329秒とされています。トップページには「Claude Fable 5.1より入力価格が238分の1」とも書かれています。どれもTypeSafe自身が出した数字です。
速さの説明はこうです。LLMは1トークンずつ、前のトークンを見ながら順番に生成します。Jevは文章生成を捨て、全部の答えを1回で並列に出す。そのために、モデルの構造、並列に答えを出す仕組み、学習法(RLCD)を新しく作った、と発表文は説明しています。本人はXで「逐次計算を並列に置き換えるのは、TransformerがRNNを追い抜いたのと同じ手」と書いています。
その代わり、Jevは文章を生成できません。本人も同じ投稿で、この点を代償としてはっきり書いています。返事を書く、コードを書く、判断の理由を説明する、のどれもできません。長い推論を要する問いにも向かないと公式は書いていて、「知識のある人が数秒で判断できる種類の問い」に絞れ、と繰り返しています。会社のサイトには「Not Chat」と大きく書いてあります。
背景には、本人がRLHFを作った側だからこそ言える見立てがあります。RLHFは「人間の評価者が好む文章」を学習の目標にした。それはチャット製品には正しい目標だったが、自動化には間違った目標で、自信過剰やムラの一因になり、結果として人が常に見ていないと使えないモデルになった、というのがTypeSafeの主張です。同社はこれを「もっと苦い教訓」と呼び、データや計算量やアルゴリズムより、正しい課題を選ぶことが大事だった、と書いています。学習目標だけで過信やムラが決まるわけではないので、あくまで同社の仮説として読むのがよいと思います。
使い方の芯は「質問を分解し、判断はコードで」
ここが、この記事でいちばん持ち帰ってほしい部分です。Jevの使い方は、LLMに仕事を丸ごと頼むのとは発想が逆で、判断を小さな質問に分解し、その答えを組み合わせる論理はコードに書くやり方です。公式は「このピッチを評価して」と聞くのではなく、市場規模、技術的な実現性、差別化を別々に聞いて、自分の式で足し合わせろ、と書いています。重み付けを変えたければプロンプトを書き直すのではなく、コードの係数を1つ変えればよい。
公式の評価サイトにある経費精算の例が、その形をよく表しています(金額は日本向けに置き換えています)。社内の規定はこうです。
- すべての申請には領収書が要る。読めなければ再提出を求める
- 経費の種類を判定する(食事、交通、備品)
- 1万円を超える食事は、申請の説明と領収書が明らかに一致していなければ上長の承認が要る
- それ以外は承認
これをJev向けに書き直すと、モデルに聞くのは3つだけになります。領収書は読めるか(Noul)、種類は何か(Choice)、説明と領収書はどれくらい一致しているか(Score、4段階)。そして「1万円超」「明らかに一致していない」「上長へ回す」「承認する」の判断は、全部コードが持ちます。人が書いた規定の各文が、モデルへの質問か、コードの規則のどちらかに割り当てられる形です。
確信度の使い方も、判断を誤ったときの影響に応じて変えます。公式の振り分けの例は音声の銀行操作で、意図の確信度が0.6未満なら一律で人に回す。残高照会なら0.6で実行してよい(間違えても残高を読み上げるだけ)。送金の承認は0.85を超えないと自動では通さず、それ未満なら本人に確認を返す。閾値は1つの数字ではなく、間違えたときの損害の大きさに応じて行為ごとに置く、という設計です。この0.6や0.85は説明用の数字で、本番の閾値は自社のデータで誤判定の割合を測って決めるように、と公式も書いています。
中小企業の業務のどこに組み込めるか
公式の用途一覧は、採用、リード獲得、カスタマーサポート、保険金請求、金融犯罪検知、法務、ECマーケットプレイス、広告など幅広く挙げています。私たちがAI導入支援で見ている中小企業の現場に引き寄せると、置き場所は4つに絞れると思います。
1. 問い合わせの振り分け。 メールやフォームの内容から、担当部署、緊急度、返信の要否を判定する。上の公式例そのものです。LLMに返信文まで書かせる前段で、Jevが「誰に、どの優先度で」を決め、確信が低いものだけ人が見る。
2. 書類の突合。 請求書と発注書と納品記録を渡して、支払ってよいか、保留か、差し戻しか。公式の評価ワークフローの1つが、まさにこれです。金額の照合はコードがやり、「品目が実質的に同じか」のような曖昧な判断だけをモデルに聞く。
3. 採用書類の一次スクリーニング。 応募書類から「必須条件を満たすか」「経験年数の段階」「志望動機が具体的か」を別々に聞き、合成はコード。人事が見るのは確信の低い候補と、通過した候補だけ。人の判断に関わる用途なので、最終判断を機械に渡さない設計と、応募者への説明責任は別途要ります。
4. LLMの出力の検品。 公式が「すべてを検証する」と呼ぶ用途で、LLMが書いた返信や要約を渡して「規定に違反していないか」「引用は本文に根拠があるか」「顧客に送ってよいか」を確率で返させる。LLMの呼び出し1回あたりの費用のごく一部で、LLMの出力を見張る役を置けます。
共通するのは、JevはLLMの代わりではなく、LLMとコードの間に置く判断の部品だということです。文章を書く仕事はLLMに残り、判断して分岐する仕事だけをJevが引き受ける。しかも、その判断を「どう聞くか」は導入する側が設計します。
向き不向きを見分ける条件を、公式の説明から4つに絞ると、選択肢や段階を先に定義できること、知識のある人なら数秒で決められること、間違えたときに人に戻せる設計にできること、そして正解が分かる過去データを集められること(確率の当たり具合を自社で確かめるため)です。採用の一次スクリーニングはこの4つを満たしやすい一方、応募者への説明責任は別に要るので、モデルに理由文を書かせない代わりに、使った規定と入力と出力の記録は残す、という切り分けが要ります。
数字の中心は自社評価で、独立した検証は始まったばかり
冷静に見るべき点も書きます。トップページの「193.6倍速い、444.6倍安い」は、TypeSafe自身が作った4つの評価ワークフローから出た数字です。発表文はここに正直で、「実世界の改善幅は、これより低いところに落ち着くと予想する」「参照する正解をGPT-6 AstraとClaude Fable 5.1の平均にしたので、OpenAIとAnthropicのモデルに有利な偏りがある」「価格が補助されていないことは証明できない。長期で持続することで示すしかない」と自分から書いています。公開ベンチマークの成績は意図的に出しておらず、公開ベンチマークを重視せず自分の用途で評価を作れ、という姿勢です。
第三者が触った結果は、発表当日に1つ出ています。米メディアEveryの評価責任者Mike Taylor氏は、自分の記事27本とAI風に書いた10本の計37文書に21問を同時に投げ、0.7秒未満で777件の判断が返り、費用は推定0.25セントだったと書いています。同じ記事で、同社CEOのDan Shipper氏が12の文章にわざと入れた7つの欠陥を、JevとClaude Fable 5.1に探させた比較も載っています。Jevは1件あたり中央値0.35秒、Fableは8.83秒で、Jevが約25倍速く、費用は約580分の1。ただしJevは7件中6件、Fableは7件すべてを見つけた。Taylor氏自身も「本番に入れる前に、もっとちゃんとした精度の確認がほしい」と書いています。安く速い代わりに、1件の見逃しをどう扱うかが問われる、という結果です。
利用はまだ早期アクセスで、順番待ちです。対応言語の記載はなく、日本語の判断がどこまで効くかは分かりません。Xでは本人の発表投稿が9月16日朝の時点で1.7万いいねを集めた一方、日本語圏の反応は「面白そう」「第三勢力か」という紹介が数件という段階です。
そのうえで筆者の考えを書きます。「速い判断を安く大量に」という需要は、本人がモデルの名前をJevons(効率が上がると消費が増える、という経済学の法則で知られる人物)から取ったとおり、値段が桁で下がれば桁で増えると思います。10回の判断を1秒に回して時給およそ7ドル、という発表文のゲームのデモや、Everyの「全記事を0.7秒で検品」は、業務で言えば「全件を毎回見る」ができる値段です。ただし、それが使えるかどうかは、モデルの賢さより、自社の判断を「知識のある人が数秒で決められる問い」に分解して書けるかにかかっていると思います。経費精算の規定を4行で書けている会社は、Jev向けに書き直せます。規定が担当者の頭の中にしかない会社は、まず規定を書き出すところからで、それはAIの話ではなく業務の話です。
さいごに 文章が要らない判断を、まず3つ探す
「型を守った答え」だけなら、既存のLLMの構造化出力でも出せます。Jevを待つ理由があるとすれば、確率の当たり具合を学習の目標にしていること、質問を並列に評価すること、そして価格と速さの桁です。逆に、判断に理由の文章が要る、日本語で今すぐ使いたい、独立した精度の検証を見てから決めたい、という場合は、既存のLLMで構造化出力を使うほうが今日の時点では現実的だと思います。
すぐ試してみたいなら、順番待ちに登録するより先に、自社の業務フローから「文章が要らない判断」を3つ探すところからです。問い合わせの振り分け、書類の可否、出力の検品。どれも、知識のある人なら数秒で決められて、モデルに理由文を書かせる必要はない問いです。ただし、判断に使った規定と入力と出力の記録は残す前提で。見つかったら、その判断の規定を経費精算の例のように数行で書いてみる。書けたなら、Jevでも、既存のLLMの構造化出力でも、試す準備はできています。次に見るのは、早期アクセスの開放、対応言語、そして精度についての第三者の検証がどこまで積み上がるかです。