Jevとは？文章を書かないAIモデルの基本とデザイナーの使いどころ
今回は、2026年9月に発表されたJevというAIの概要と、デザイン業務での使いどころについて考察します。名前だけ聞いたことがあるけど結局これが何なのかよくわからん、という方を想定しています。
Jevは2026年9月15日にTypeSafe AIから公開された新しいAIモデルです。
we are officially out of stealth! join the frontier and get access to Jev on our website (link on profile) https://t.co/hGLSb4XsTv
— TypeSafe AI (@typesafeai) September 15, 2026
以下は2026年9月20日時点で公開されている公式ドキュメントなどを参考にしています。出回っている情報の多くは公式の発表によるもので、独立した検証は現時点ではあまり充実していないので、仕様も数値もこれから変わる前提で留意してください。
なお、記事を書いている時点で、別件の作業で少しだけ実際に動かしています。手元にある3万件ほどの短いテキストに対して、「この文はこの性質を持つか」というYes/Noの問いを当てて仕分けるという作業です。簡単にいうと図鑑アイテムのタグ付け分類です。公開情報だけでは分からなかった部分には、そのときの手元の数字も混ぜています。調整用のデータで測っている途中経過なので、確定値ではありません。
この記事のターゲット
Jevが何をするものか知りたい方
要望や問い合わせが、読まれないまま溜まっているチーム
分類やタグ付けをLLMに任せていて、コストと速度が気になっている方
Jevはテキストを書かないAI
ChatGPTやClaudeのようなLLM（大規模言語モデル）は、聞かれたことをテキストとして回答します。
JevはLLMとは明確に異なり、渡された テキストを読んでこちらが事前に決めておいた選択肢のどれかを選び、そう判断した確率を添えて返します。「この問い合わせは返金の希望か」「この文章の読みやすさは5段階のどこか」といった問いには答えますが、その理由も要約などのテキストは生成しません。
LLMが単語を1つずつ予測して文章を生成するのに対し、Jevは回答（判断）を1回で生成する仕組みなので、文章を組み立てるという構造が存在しません。
提供元のTypeSafe AIは、これをsystem oneモデルという新しい区分として名乗っています。ファスト&スローの著者で行動経済学者のカーネマン氏が提唱する、速い思考（システム1）に由来する呼び方です。
市役所で例えると。「その手続きでしたら3番窓口です」と1秒で振り分けるのが受付の仕事で、手続き内容を確認して受理するのは受付後の別の部門の仕事になります。いくら受付が優秀でも手続きは進みませんし、手続き内容に関する細かい問い合わせにも対応できません。JevとLLMの関係もこれと同じで、どちらかが上位互換ということではなく分業を想定して設計されているようです。
現在は、料金は入力100万トークンあたり0.042ドル・出力は無料のようです。速度は、数百ミリ秒で返るとTypeSafe AI公式では説明されています。
手元の実感としては、質問文を書いては測り直す往復を2400回ほど繰り返して、入力は合わせて0.87Mトークンでした。試し打ちの回数を気にしなくてよい、というのがこの料金のいちばん効くところだと思います。
用意した選択肢の中から回答する
Jevの紹介でよく見かける「ハルシネーションがゼロ」という言い方には、 注意点があります。
正確には、答えが必ずこちらの用意した枠の中から選ばれる、という意味です。想定していない値や壊れた形式が返ってくることはありません。問いに対して最初から選択肢が全て間違っていた場合、選択肢にない正解を答えることはないということです。
また、公式ドキュメント自身が、確率は校正されているものの、個々の答えが正しいことは保証しないと明記しています。ここで言われているのは型を外さないということであって、間違えないということではありません。
回答方式の型
Jevが用意している回答方式は3通りです。回答方式によって返ってくる確率の信頼性は変化します。
回答方式 | 返ってくるもの | こちらが決めておくもの |
Noul | はい/いいえと、「はい」である確率 | 問いの文面 |
Choice | 選択肢のうちの1つと、各選択肢の確率 | 選択肢の一覧（最大255） |
Score | 段階のどこに当たるかと、各段階の確率 | 段階の数（2から10）と、それぞれの意味 |
質問文の書き方で答えが変わる
手元で動かしてみて、一番意外だったのがここです。
同じことを聞いているつもりの2つの文で、返ってくる確率が大きく変わります。あるテキストに対して「〇〇によってこれができる」と書いたときは0.22、「〇〇を含む方法でこれができる」とすると0.97に改善しました。
原因は、対象のテキストに書かれていた方法が聞いた条件の一部だった点です。「〇〇によって」と書 くと、〇〇だけで成立する場合しか当てはまらないと読まれます。。
数の条件を混ぜると不安定になります。ある質問文に「単一の」という表記を含めただけで、正例が軒並み0.2から0.4になり、これを削除したら同じテキストが0.84から0.94まで上がりました。数を数えるのが苦手だという弱点は、数えさせなくても、問いの文面に数の条件を書いた時点で出てくるようです。
もうひとつ、「AまたはB」という書き方にも注意が要ります。この形で聞くと、Aしか当てはまらないテキストが0.14から0.28まで落ちました。問いを「Aを含む」の形に縮めると同じものが0.9前後まで上がりました。
必ずしも選択肢を並べること自体が悪いわけではなさそうです。手元の24種類の問いのうち11種類が「AまたはB」の形を含んでいますが、崩れたのは1種類だけでした。崩れるのは、性質の違うものを2つ並べて、片方しか持たないテキストを字義的に落としてしまう形のときです。
質問文を直せば直るので、致命的な欠点ではありません。ただ、最初に書いた質問文がそのまま通る前提でいると、返ってきた精度の数字だけを見て「使えない」と判断してしまいそうです。
回答の精度
TypeSafe AIによると、Jevの回答の精度は67.8%で、比較された中で最も高かったモデルは74.1%だったとされています。ただしこれは独立した正解ラベルとの照合ではなく、他のモデルが出した答えとの一致率です。
Jevの特徴としては、その回答がどれくらい確からしいかを確率として返す点です。第三者による事前登録テストでは、この確率が0.9以上だったときの正解率は92%、0.8を下回ると約50%だったとの報告があります。 ただしこれは検証者の手元にある2種類のデータを分類させた結果で、対象が変われば精度も変わるはずです。
0.8未満はコイン投げと変わりません。裏を返せば、どこから先を信じてよいかが数字で見えているということでもあります。確率が高いものだけ自動で流し、低いものは人の手元に戻せばよいわけです。公式ドキュメントにも、0.5を下回るものは人へ、0.5から0.9のあいだは確認を挟み、0.9を超えたら自動で進めてよい、という目安があります。
ただし独立した検証では、この目安をそのまま持ち込むのは避けて、どの値を見るかも含めて自分のデータで引き直すべきだと言われています。
判定装置としての使い道
私の手元では、実装を別のモデルへサブエージェント的に委譲して、そのレビューをさらに別系統へ回す、という分け方で作業を進めています。
このとき、エージェントやサブエージェントが完了と言っても、蓋を開けてみると完了条件を満たしていなかったり、テストを無視していたりすることがあります。
Jevの得意分野として挙げられているのは、こうしたLLMの完了したという主張と、実際の結果が食い違っていないかの判断に役立つのでは、と言われています。
取り返しのつかない行動ほど判定基準を引き上げておくのが無難だと思います。判断の理由を残す必要がある決定には、そもそも入れないほうが無難です。Jevは判断を返しますが、なぜそう判断したのかは回答に含まれないためです。
デザインの仕事に置いてみる
公式ドキュメントや検証記事に挙がっている得意分野を、デザイン業務で応用できないかを少し考えます。いずれも現段階での私個人の想像です。
まず使えそうなのが、リサーチの自由記述やインタビュー逐語の一次仕分けです。発話や回答の1単位ごとに、「特定の課題に言及しているか」「作業の中断について述べているか」といったYes/Noの問いをまとめて聞きます。
Jevは1回のリクエストに問いを足しても、上限まではほとんど遅くならないので、使うかどうか分からない問いも一緒に投げておいて、必要なものだけ後で拾う設計が成り立ちます。落とし穴は、「何人が言及したか」を数えさせてしまうことと、要約を期待してしまうことです。数えるのはプログラムの仕事ですし、返ってくるのはタグと確率だけです。
また、渡すテキストに回答者や発話者を特定できる情報を混ぜないほうがよさそうです。手元の作業でも、判定してほしい本文だけを送って、そのテキストの名前にあたる部分は最初から外しています。名前が入っていると、書かれている中身ではなく名前のほうで判定されてしまうノイズになりうるためです。
UIライティングの逸脱検出にも使えそうです。文体ガイドの表を、そのまま問いの一覧に置き換えるだけです。
ただし、表記ゆれや禁止語の検出なら正規表現のほうが確実で安い、という点です。Jevを足す意味があるのは、規則の形で書き切れない意味的な逸脱になると思います。なお、ここでも返ってくるのは指摘までで、書き換え案は出てきません。
もう少し身近なところだと、レビューコメントの仕分けです。100件返ってきたコメントを前に手が止まる、という経験は珍しくないのではないでしょうか。ここでやりたくなるのが「重大度を5段階で付け てもらう」なのですが、段階で答えさせる聞き方は、確率がブレやすいような気がします。
代わりに、「仕様への指摘か、好みの表明か」「リリースを止める種類の話か」といった事実情報を確認するYes/Noの問いへ分解して、重み付けは自分のコードで評価するのが関の山のような気がします。頼み方としては、優先順位を決めてもらうのではなく、判断材料を型に落としてもらう、という形になります。
なお、日本語で使う場合については、公式が「英語が最良で、日本語を含む他言語は精度が劣る」と書いているだけで、どれくらい劣るのかの数値は公開されていません。日本語のデータに当てるなら、自分で正解付きの評価セットを作るところからになります。
任せてはいけない判断
構造上できないことが、はっきりしています。
文章は作れません。要約も説明文もコードも生成しないため、「インタビューを要約して」「コピー案を5つ」などはユースケースとして不適切です。
数を数えるのも苦手です。件数が増えるほど精度が落ちるので、「何件が同じことを言っているか」は聞かずに、候補ごとに1問ずつ聞いてプログラム側で集計します。上述の通り、数を条件に含めることも推奨しません。
日付などの時間軸をもつ前後関係は比較できません。Jevにとっての「2026-03-01」と「2026-11-01」は、ただの文字の並びで、数直線の上の点として扱われないようです。判定させると、もっともらしい答えが返ってきたうえで外すことがあります。年月日を選択肢として抜き出させて、比較はプログラムでやることと公式ドキュメントにも書かれています。
そして、判定理由は返ってきません。監査の証跡が要る判断には使わないようにしましょう。
デザイン業務で言えば、「コントラストは足りているか」「余白は8の倍数になっているか」「このデザインは10点満点で何点か」あたりも一見ユースケースとして使えそうな気がしますが、これらも非推奨ということになります。判断ではない「測ること」と「数えること」はプログラムで判定すべきです。
Jevは渡されたテキストを疑いません。書かれている内容を悪意あるものとして扱わないことは公式が弱点として挙げており、外部からの入力を止める関門をJevだけに任せるのは避けたほうがよさそうです。
裏を返すと、「このUIは良いか」を機械に渡せるYes/Noの問いへ分解した時点で、何を良さと呼ぶかをこちらが確定させています。つまり、渡された問いの中にバイアスが含まれている場合、それを含んだ判断をさせてしまっている時点で、こちらにとって都合の良い回答に操作しやすい、ということになりそうです。
LLMとは異なり質問への回答に倫理的な善悪の判定が存在しないため、悪意を持った人間が悪意を含む質問に対して都合の良い返答をさせる操作がしやすいということだと私は捉えています。
品質の高い質問を設計できるかどうかで、Jevの価値を引き出せるかどうかが決まるんだろうなと思います。
