firebirdテックトーク

パソコ

こんにちは！パソコです。気になったら関連記事もチェックしてみてね🔥

「このモデルは、文章を一切生成しない」

TypeSafe AIというスタートアップが2026年9月15日に公開した発表を読んで、最初に引っかかったのがこの一文だった。文章を生成しないAIモデルというのは、ここ数年の常識からすると形容矛盾に近い。

だが、自分がこれまで書いてきた処理を思い返すと、納得できる部分もあった。問い合わせメールを「請求関連」か「技術的な質問」かに振り分ける。レビューコメントが緊急かどうかを判定する。ログの一行が異常を示しているかを判断する。こういった処理をAIに任せるとき、こちらが本当に欲しいのは判定結果だけだ。それなのに毎回、長い文章を生成できる重いモデルを呼び出し、返ってきた文字列を正規表現やJSONパーサで削り取って値に戻している。

この「文章を経由する無駄」を最初から取り除いたのがJevだ、というのが今回の発表の主張である。

Jevとは何か

Jev（ジェヴ） は、TypeSafe AIが開発したAIモデルの名前だ。同社は約4,000万ドルの資金調達を受けたスタートアップで、共同創業者兼CEOのDiogo Almeida氏はOpenAIの元研究者だと報じられている。

Jevの特徴を一言でまとめると「文章の代わりに、型の決まった判定結果と、その判定がどれくらい確かなのかを表す確率を返すモデル」である。

公式ブログでは、このモデルが属するカテゴリを次のように定義している。

a new class of frontier models built to make fast, structured decisions

「速く、構造化された判定を下すために作られた新しいモデル群」という位置づけだ。人間と会話するためではなく、ソフトウェアがそのまま使える値を返すために設計されている。

System Oneという名前が意味するもの

TypeSafe AIはこのカテゴリを System Oneモデル と呼んでいる。心理学でいう「速い思考（システム1）」と「遅い思考（システム2）」の対比を借りた命名だろう。じっくり推論して文章を組み立てる従来型のモデルが後者だとすれば、Jevは前者、つまり反射的な判断に特化した層を担う、という主張になる。

訓練の方法論も従来と違う名前が付けられている。公式ブログによれば RLCD（Reinforcement Learning for Calibrated Decisions／較正された判定のための強化学習） という手法で、従来のRLHF（人間のフィードバックによる強化学習）やRLVR（検証可能な報酬による強化学習）とは狙いが異なるとされる。

ここでいう較正（キャリブレーション） とは、モデルが出した確率が現実の的中率と一致している状態を指す。「確率0.9」と答えたケースを100回集めたら、実際に約90回当たっている——これが較正されている状態だ。公式ブログはこれを “epistemically honest probabilities”（認識として正直な確率）と表現している。

従来の大規模言語モデル（大量のテキストで学習し、文章を生成するAIモデル。以下、単に言語モデルと書く）が「自信満々に間違える」と言われてきたのは、まさにこの較正がずれているからだ。そこを訓練目標そのものに据えた、というのがJevの主張である。

従来の言語モデルとの違い

公式ブログの説明を整理すると、違いは4点に集約できる。

「トークン」とは、モデルが文章を扱うときの最小単位のことで、日本語ならおおよそ1〜2文字程度に相当する。従来の言語モデルはこれを1個ずつ順に吐き出すため、答えが長くなるほど時間がかかる。Jevは文章を作らないので、この逐次生成そのものが発生しない。

出力が文字列ではなく「型のついた値」になる

実務上いちばん効くのはここだと思う。

言語モデルに分類をさせる場合、たいていは「JSONで答えて」と指示し、返ってきた文字列をパースする。うまくいく日が続いても、あるとき前置きの一文が混ざる、キー名が変わる、末尾のカンマが余る——といった形で壊れる。だからリトライ処理とバリデーションとフォールバックを書くことになる。

Jevは出力の選択肢と構造をあらかじめ定義する方式で、公式ドキュメントは “The model never makes type errors”（モデルが型エラーを起こすことはない）と明言している。パースに失敗する経路が仕様として存在しない、という設計だ。

確率が必ず付いてくる

もうひとつの違いは、答えに必ず確率と確信度が付随することである。

たとえば問い合わせの振り分けなら、報道されている例では {"billing": 0.08, "technical": 0.85, "sales": 0.07} のような値が返る。これはそのまま閾値による分岐に使える。「0.9以上なら自動処理、0.6〜0.9なら人間に確認、それ未満は保留」といった設計が、後付けの工夫ではなく最初から書ける。

言い換えると、判断の責任をAIではなくプログラム側に置くということだ。ここがAIエージェント（状況を解釈し、次に使う道具を自分で選んで動くAIの仕組み）との根本的な分かれ目になる。エージェントは柔軟だが、どう動くかはそのときのモデル次第になる。Jevは値を返すだけで、どう動かすかは人が書いたコードが決める。

3つの質問の型——Choice・Score・Noul

Jevに投げられる質問は3種類に整理されている。公式ドキュメントの定義は次のとおりだ。

そして “All three question types can be mixed in a single API call”——3つは1回の呼び出しに混ぜられる、と記載されている。1通のメールに対して「請求関連か（Noul）」「顧客の口調は（Choice）」「緊急度は（Score）」を同時に聞ける、ということだ。

実際に書くとこうなる

公式のPython SDKのドキュメントに載っている例がわかりやすい。インストールは次のとおり。

1

pip install typesafe-sdk

環境変数 TYPESAFE_API_KEY を設定したうえで、非同期クライアントならこう書く。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

from typesafe_sdk import AsyncTypeSafeClient, Choice, Noul, Score

async def main() -> None:
    async with AsyncTypeSafeClient() as client:
        response = await client.system_one(
            state={"document": "I was charged twice. Please fix this ASAP."},
            questions={
                "billing": Noul(instructions="Is this ticket about billing?"),
                "tone": Choice(
                    instructions="What is the customer's tone?",
                    criteria={"calm": None, "frustrated": None, "angry": None},
                ),
                "urgency": Score(
                    instructions="How urgent is this ticket?",
                    criteria=["can wait", "this week", "today"],
                ),
            },
        )

結果は response.nouls["billing"].noul ／ response.choices["tone"].choice ／ response.scores["urgency"].score のように、質問につけた名前で取り出す。JavaScript向けのSDKも用意されている。

注目したいのは、プロンプトを組み立てる工程が消えている点だ。「必ずJSONで答えてください」「余計な説明を加えないでください」といった、モデルを型に押し込めるための呪文がいらない。選択肢の定義そのものがインターフェースになっている。

公称値をどう読むか

ここからは数字の話になるが、先に断っておく。以下はすべてベンダーの公称値であり、第三者による独立した検証結果ではない。

速度

公式ブログが挙げている応答時間は、Jevが70〜500ミリ秒、比較対象の従来型モデルが3〜329秒。倍率にして40〜200倍速いという主張だ。報道されたデモでは、Jevの0.114秒に対してGPT-5.6 Terraが8.566秒という数字が示されている。

価格

入力トークンが100万トークンあたり0.042ドル、出力トークンは無料（公式表現は “too cheap to meter”＝計測するのも馬鹿らしいほど安い）とされている。公式サイトは10億トークンあたり42ドルという表記も併記しており、Claude Fable 5.1と比べて入力価格が238分の1だと主張している。

ワークフロー全体での評価としては “193.6x faster, 444.6x cheaper”（193.6倍速く、444.6倍安い）という数値が公表されている。

桁が大きすぎて実感しにくいが、出力が無料という部分は構造として理解できる。従来のモデルでは出力トークンが入力の数倍の単価に設定されているのが普通で、これは生成が逐次処理で重いからだ。文章を作らないモデルなら、そのコストがそもそも発生しない。

何に効いて、何に効かないのか

公式ブログが想定用途として挙げているのは、分類・振り分け・スコア計算・特徴抽出といったワークフロー内の判断、数百テラバイト規模のデータ処理、100ミリ秒台の速度を活かしたリアルタイム処理、そして言語モデルの出力や実行トレースの検査である。

逆に言えば、次のような処理には向かない。

• 文章を書く（要約・翻訳・下書き生成）
• 対話する（チャットボット、ユーザーとのやり取り）
• 手順を自分で組み立てる（何をすべきか自体が未定の探索的なタスク）

つまりJevは言語モデルを置き換えるものではない。繰り返し発生する定型の判断を切り出して前段に置く層、という理解が正しいだろう。判断はJevに、文章の生成は従来のモデルに、という分業だ。

鵜呑みにすべきでない点

ここは新しい技術ほど丁寧に見ておきたい。

「幻覚しない」の意味は限定的だ

The Registerの記事は、この主張に対して「自然言語の出力がない以上、同じ土俵の比較ではない」という趣旨の批判を載せている。これはもっともだと思う。

構造上保証されているのは型エラーが起きないこと、つまり定義していない値が返らないことであって、判定内容が正しいことではない。選択肢のどれかは必ず返るが、それが間違った選択肢である可能性は残る。そこを埋めるのが較正された確率という設計であり、だからこそ確率を無視して結果だけ使う運用をすると、保証の大半を捨てることになる。

ジェヴォンズのパラドックス

同記事はもうひとつ、皮肉な指摘をしている。ジェヴォンズのパラドックス——効率が上がると消費量はかえって増える、という19世紀の経済学者ウィリアム・スタンレー・ジェヴォンズが石炭について論じた現象だ。1回あたりのコストが444分の1になっても、呼び出し回数が1,000倍になれば総額は増える。

モデル名の「Jev」がここから来ているのかは公式には確認できていないが、安くなったぶんだけ気軽に呼ぶようになる、というのはAPIを使う側の実感としてよくわかる話ではある。

仕様上の制約（2026年9月時点）

公式ドキュメントに記載されている制約も押さえておきたい。

画像を扱えない点と、先行アクセス段階である点は、本番システムに組み込む前に確認しておくべきところだ。レート制限についても「予告なく変わりうる」と明記されている。

まとめ

Jevを一言でまとめるなら、AIに文章を書かせてから値に戻すという回り道を、仕様ごと削除したモデルだ。

整理するとこうなる。

• 返ってくるのは文章ではなく、型の決まった値と較正された確率
• 質問はChoice（選択）・Score（採点）・Noul（はい／いいえ）の3種類で、1回の呼び出しに混ぜられる
• 公称値は70〜500ミリ秒、入力100万トークンあたり0.042ドルで出力は無料。ただしすべてベンダー公称値
• 「幻覚しない」が保証するのは型の正しさであって、判定内容の正しさではない
• 言語モデルの置き換えではなく、定型判断を切り出す前段の層として使うもの

個人的にいちばん価値があると感じたのは、速度や価格よりも判断の責任をコード側に戻せることだった。AIエージェントに任せると柔軟に動いてくれる反面、なぜそう動いたのかを後から説明しづらい。確率という数値で返ってくるなら、閾値も分岐もログもこちらの管理下に置ける。

もっとも、まだ先行アクセス段階で、第三者による検証もこれからだ。既存の処理をいきなり置き換えるのではなく、分類や振り分けのように結果を検証しやすい処理を1つ選んで、いまの実装と並走させて精度と応答時間を自分の目で測ってみる。試すならそこからだろう。

関連書籍

PR: 本セクションにはアフィリエイトリンクが含まれています。

AIをワークフローに組み込む設計思想を学びたい方に。判断をどこまでAIに委ね、どこから人間とコードが持つべきかという線引きの考え方が、実践的な事例とともにまとまった一冊です。