この記事の目次 ＋
THE STARTING QUESTION
「それ、普通の条件分岐でよくない？」
たとえば、チャットに暴言が投稿されていないか確認したいとする。禁止ワードを探せば済みそうだが、次の2つはどうだろう。
どちらにも「使えない」という言葉が含まれる。それでも、相手への攻撃と、被害を伝えるための引用は同じではない。単語だけで分岐すると、この違いを扱いにくい。
もちろん、ルールを増やすことはできる。引用、否定、対象、前後の会話……。ただ、表現のたびに例外を追加していくと、保守すべき条件が複雑になる。一方、必要な答えが「確認対象にするか」だけなら、毎回長い説明文を生成してもらう必要はない。
「言葉の意味を読んで、
決めた形式で答えてほしい。」
この用途に向けて作られたのが、TypeSafe AIのJevだ。2026年9月15日に発表された、同社が「System One」と呼ぶ判断特化モデルの最初の製品である。[2]
ここでの「小さな判断」は、重要性が低いという意味ではない。暴言判定の出力が一つでも、誤って相談を消せば影響は大きい。小さくするのは問いの範囲であって、責任ではない。
WHAT IT IS
文章ではなく、判断を返す。
Jevに渡すのは、判断材料となる文章・状態と、あらかじめ定義した質問・選択肢・評価基準。受け取るのは、コードが処理に使える値と確率である。会話文やコードを書くためのモデルではない。[1][24]
「同じ注文で2回引き落とされました。
確認をお願いします。」
説明用の表示例。実際のAPI応答・実測結果ではありません。
返せる判断は、大きく3種類。複数の質問を同じリクエストに入れ、それぞれ同じ入力をもとに評価できる。[1]
CHOICE
選ぶ
「請求」「不具合」「その他」など、用意した選択肢から選ぶ。
choice + probabilitiesSCORE
評価する
「冷静」「不満」「強い不満」など、順序のある尺度で評価する。
score + probabilitiesNOUL
真の確率を返す
「返金を求めているか」などに、0〜1の確率で答える。
noul: 0–1ChoiceとScoreにはconfidenceも付く。Noul自体にはconfidenceは付かない。[4]
入力の表現は多様でもいい。
判定基準まで曖昧にしない。
「いい感じに判定して」ではなく、何を該当とし、何を除外するかを定義する。判断が複数の要因にまたがるなら、問いを分けて結果をコードで組み合わせる。[1][5]
なお、Jevが返すのは判断であり、返金やメール送信を勝手に実行するわけではない。判断結果を受け取ったアプリが、業務ルールに沿って次の処理を決める。[24]
CODE × JEV × LLM
置き換えるより、分担する。
LLMは「大規模言語モデル」の略。本稿では、文章やコードを作る役割のモデルを「生成型LLM」と呼ぶ。[24]
「普通のコードか、Jevか、LLMか」の三択で、システム全体を決める必要はない。処理を分け、得意な方法を組み合わせると考える方がわかりやすい。
| 必要な処理 | まず任せる先 | 理由 |
|---|---|---|
| 支払い金額を合計する | コード | 正確な計算が必要 |
| 問い合わせの意図を読む | Jevの検証候補 | 表現は違っても、分類は決められる |
| 顧客への返信案を書く | 生成型LLM | 新しい文章を作る仕事 |
| 実際の返金を承認する | 業務ルール＋必要な人の確認 | 権限と事実の確認が必要 |
上表は設計例。Jevの現行版では、計算・件数集計・日時比較はコードに残すことが公式にも勧められている。[5]
「選択肢から答えるAI」が、初めて登場したわけではない
文章をカテゴリに分ける分類モデルは以前からあり、専用の学習なしに候補ラベルを指定するゼロショット分類もある。生成型LLMにも、出力をJSONの構造や選択肢に制約する機能がある。[7][6]
したがって、新しさを「これまで不可能だった分類」と説明するのは違う。注目点は、判断に特化したAPIとして、速度・料金・確率付きの結果をどう実用化しているかだ。既存の分類器や小型LLMが十分に機能しているなら、それらとの比較から始めたい。[20]
WHY IT MATTERS
小さな判断を、細かく挟める。
Jevのおもしろさは「大きなAIより何でも賢い」ことではない。これまではコストや待ち時間が気になった場所にも、意味を読む判断を置ける可能性にある。
2026年9月19日確認の公式情報。トークンはAIが文章を処理する単位で、文字数や単語数と同じではない。速度の主な測定地点は米国西海岸。料金や性能を将来にわたって保証する値ではない。[2][3]
同じ入力を、一度に複数の観点で見る
問い合わせを「何の相談か」「不満は強いか」「人とのやり取りを求めているか」に分けて聞く。Jevは宣言された質問を並列に評価するため、公式は質問の追加による応答時間への影響が小さいと説明している。ただし、入力長などの上限はある。[1][3]
不確かなときは、人や別の処理へ渡せる
確率分布とconfidenceを使い、明確なケースと確認が必要なケースを分けられる。ただし、confidenceが0.9だから正答率90％、という保証ではない。confidenceは確率分布の形から計算される指標で、しきい値は実データで検証する。[4]
入力料金だけ、ざっくり計算。
100,000 × 1,000 ÷ 1,000,000 × $0.042 = $4.20
質問・評価基準も含めた課金対象の入力トークン数を使う。税、再試行、他のモデル、サーバー、人による確認などの費用は含まない。提供経路の条件も別途確認する。[3]
Jevを追加しただけで、必ず速く安くなるわけではない。
後段のLLMを同じように毎回呼ぶなら、判定の費用と待ち時間が追加される。省けた処理、再試行、人の確認まで含めて、システム全体で比較することが大切だ。
THE USE-CASE ATLAS
どこで使う？ 12の活用例。
「分類」の一言では、使い道が見えにくい。実際には、選ぶ・評価する・照合する・確認対象を絞るという形で、さまざまな業務に組み込める。
以下の日本語入力例・業務への当てはめは、本稿の説明用に作成したもの。公式実装例や公式評価があることは、そのまま本番環境での効果実証を意味しない。
12件の活用例を表示
暴言と、被害の相談を分ける
コミュニティ運営・チャット機能の開発チーム
「『使えない』と何度も言われて困っています」
Jevに任せること
禁止語の有無だけでなく、攻撃の対象、引用かどうか、運営の確認が必要かを、それぞれ別の質問にする。
公式には、境界的な投稿を複数の観点で評価し、不確かな結果を人へ回す例がある。導入初期は自動削除より、確認すべき投稿の候補を絞る使い方が考えられる。[8]
任せきらない部分被害相談まで消してしまう誤検知に注意。投稿者への制裁や最終判断は、単一のスコアに委ねない。
問い合わせの担当と優先度を整理する
カスタマーサポート・CRM開発チーム
「同じ支払いが2回発生しています。先週も連絡しました」
Jevに任せること
請求の相談か、過去の対応への催促か、人への引き継ぎを求めているかを判定し、担当の一覧へ送る。
公式の業務フロー評価でも、意図・不満・緊急性などを分解している。分類結果に応じて取引履歴を取得し、必要ならLLMに返信案を書かせる構成にできる。[9]
任せきらない部分「二重請求を訴えている」と「実際に二重請求された」は別。事実は取引データで確認する。
検索結果から、回答に使う資料を選ぶ
社内検索・ナレッジボットの開発チーム
検索で見つかった20件の資料。どれを回答の材料にする？
Jevに任せること
資料が質問に関係するか、根拠になるか、質問の前提と矛盾するかを判断する。
検索した資料をLLMの回答に使う仕組みをRAGという。公式例では、その検索と生成の間に選別を入れる。反対の内容を示す資料も、前提を訂正するために残している。[10]
任せきらない部分検索で見つからなかった資料は選べない。専用の再ランキングモデルとも、検索品質と費用を比較する。
引用が、主張の根拠になっているか確かめる
調査・文書検索・レポート生成の開発者
資料は「一部のプランで無料」。回答は「すべて無料」。
Jevに任せること
引用先が、その主張を支持するのか、反対の内容なのか、根拠になっていないのかを判定する。
公式例は、まずコードで引用文が原文に存在するかを調べ、その後にJevで意味の整合性を確認する。文字列の照合と意味の判断を分担する好例だ。[11]
任せきらない部分引用の内容自体が真実か、最新版かまでは保証しない。重要な主張には追加の出典確認が必要。
書類の中から「欲しい値」を選ぶ
経理・受発注・メール処理の自動化チーム
税抜額、税額、今回の合計、前回請求額が同じ文書にある。
Jevに任せること
コードで抽出した金額候補から、「今回の請求合計」に当たる値を選ぶ。
公式には、金額やメールアドレス、電話番号の候補から該当するものを選ぶ例がある。Jevに数値を書かせるのではなく、元の値をコードがコピーする設計だ。[12]
任せきらない部分正しい候補を抽出し損ねれば選べない。選び間違いもあり得る。計算・税・合計の整合性はコードで検証する。
エージェントに、必要なスキルを選ばせる
コーディングエージェント・社内AIの開発者
「画面の崩れを直して」。コード調査？ ブラウザ確認？
Jevに任せること
用意されたスキルの説明から候補を絞り、今回、本当に必要かを確認する。
公式例は、多数のスキルから候補を絞った後、上位候補を詳しく評価する二段階構成。「どれも使わない」という判断も用意している。上の依頼文は本稿の応用例だ。[13]
任せきらない部分選ばれたスキルが正しいことと、修正が成功したことは別。実行権限・差分レビュー・テストは別途必要。
難しいケースだけ、大きなモデルへ回す
AI処理の品質と費用を改善したい開発チーム
小型LLMが書類から抽出した値に、取り違えはない？
Jevに任せること
フィールドごとに原文との対応を検査し、問題が疑われるケースを上位モデルへ渡す。
公式例は「小型モデルで抽出 → Jevで確認 → 必要時だけ大型モデル」の流れ。すべてを最初から高価な処理に送らない設計である。[14]
任せきらない部分検査が見逃せば、後段へ回らない。Jev自身の誤判定と追加の待ち時間を含め、全体で測る。
自然な言葉から、既存機能を呼び分ける
業務アプリ・管理画面の開発者
「今月のデータを、表じゃなくグラフで見たい」
Jevに任せること
用意済みの関数と、決まった候補を持つ引数を選ぶ。例なら表示形式などを選択する。
公式の関数呼び出し例は、関数名と選択式の引数を判定する仕組みだ。自由なプログラムを作るのではない。期間の解釈や上の画面操作は本稿の応用案である。[15]
任せきらない部分日付の計算、アクセス権限、破壊的操作の承認はコード側。自然文の指示だけで権限を与えない。
商品・文書を、細かいカテゴリに分類する
EC運営・商品管理・文書管理チーム
大量の商品説明を、大分類から小分類まで整理したい。
Jevに任せること
一度に全カテゴリから選ぶ代わりに、階層ごとに候補を絞る。
公式例は、商品分類などの階層をたどる方法を示している。複数の有力候補を並行して残すことで、早い段階の曖昧さに対応する設計も紹介されている。[16]
任せきらない部分分類体系そのものが不適切なら精度は出ない。未分類・複数カテゴリ・体系の更新も設計に含める。
エージェントの実行ログを点検する
AIサービスの品質管理・運用チーム
「完了」と返したAIは、依頼を本当に満たした？
Jevに任せること
実行履歴を読み、依頼とのずれや確認すべき結果を見つける。
公式評価では、完了後のエージェントの履歴を見て、対応が必要なケースを振り分ける用途を扱う。人が読むログの優先順位づけに応用できる。[17]
任せきらない部分ログに残っていない実際の状態は確定できない。テスト結果、監査記録、サービスの状態確認と併用する。
文章を、分析に使える特徴へ変える
データ分析・機械学習チーム
自由記述を、そのままでは集計・予測に使いにくい。
Jevに任せること
定義した性質が文章にあるか、その程度はどれくらいかを値にする。
公式例は、LLMが評価の観点を提案し、Jevが文章を評価し、その値を別の予測モデルに使う流れ。Jevは最終的な予測器ではなく、入力となる特徴を作る役割だ。[18]
任せきらない部分結果を知ってから観点を作ると、評価が甘くなる。学習用と評価用のデータを分け、偏りも確認する。
顧客の声を、改善の材料に整理する
プロダクトマネージャー・営業企画・調査担当
「使いやすいけれど、毎月の料金が少し高い」。
Jevに任せること
「操作性への好意」「価格への不満」など、定義した観点を複数付ける。
公式の用途マップをもとにした応用案。Jevでタグ付けし、コードで集計し、LLMが傾向を文章にする。要約の前に集計しやすい情報へ変える考え方だ。[19]
任せきらない部分最初から用意した観点しか拾えないことがある。未知の不満を探すため、原文を人が読み返す枠も残す。
検索結果の並べ替えでは、専用の再ランキングモデルも比較対象になる。[23]
BETTER TOGETHER
AIエージェントの、どこに入れる？
AIエージェントは、目的に応じてツールを使い、複数の処理を進める仕組みだ。Jevはそれを丸ごと置き換えるというより、途中にある限定的な判断を受け持つ部品として使える。Vercelも、次のツールの選択、続行・再試行・停止などを用途として挙げている。[20]
たとえば、コード修正を行うエージェントなら
依頼を読む
Jevで「画面の見た目」「データ取得」「環境設定」などの候補を評価する。分類体系は開発側が決める。
LLMが修正する
コードの生成や複雑な計画は生成型LLMが担当。ツールを実行できる範囲は、コード側で制限する。
結果を確認する
テスト・差分・実画面を確認する。意味の確認をJevで補助しても、それだけで成功を確定しない。
上記はスキル選択の公式例をもとにした設計案であり、この構成での性能を実測したものではない。
何でも細かく分ければよいわけでもない。判断を増やすと、設計・評価・ログ管理も増える。まずは繰り返し発生し、入力と期待する出力を具体的に説明できる一つの判断を取り出すのがよい。
A SMALL DESIGN DEMO
曖昧なら、自動で決めない。
確率付きの出力をどう使うか。次のデモは、入力の例としきい値を切り替えて、振り分けの考え方を試すためのものだ。
同じ注文で2回引き落とされました。重複した分を確認してください。
このデモはJevの推論を実行しません。確率は説明用の仮値で、実際の精度・confidenceを示すものではありません。自動化するのもラベル付けだけで、返金などの操作ではありません。
ここでは最上位の選択肢の確率を使った設計例を示した。APIのconfidenceとは別の値だ。どちらを使う場合も、高い値で間違えるケースはあり得る。人へ回す割合だけでなく、自動処理に残った誤りを測ってしきい値を決めたい。[4]
KNOW THE BOUNDARIES
万能ではない。だから、設計する。
「ハルシネーションゼロ」は、誤判定ゼロではない。
用意した選択肢の外にある部署名を作らなくても、部署を選び間違えることはある。出力の型が正しいことと、判断内容が正しいことは別だ。構造の保証を、事実や精度の保証と読み替えない。[24][5]
日本語の精度は、日本語で確かめる。
公式では英語が主要な学習言語で、精度も英語が最もよいとされる。日本語でも、敬語、遠回しな依頼、否定、引用を含む実データで確認したい。現行モデルの入力はテキストのみ。画像・音声・動画には別の前処理が必要になる。[3]
計算・日時・権限は、コードに残す。
正確な計算や日付の前後比較、件数集計は不得意として公開されている。また、質問同士を独立に判定すると、結果の組み合わせが業務ルールに反することもある。整合性はコードで検証する。[5]
安全確認の「唯一の壁」にしない。
入力中の誘導的な文章で判断が動く可能性がある。送金、削除、重要な承認を、Jevの判断だけで実行しない。権限チェック、許可された操作の制限、必要な確認は別途設ける。[5]
「学習に使わない」と「保存しない」は別。
TypeSafeは顧客データを学習に使わないと説明し、企業向けのゼロデータ保持も案内している。保持期間や適用条件は提供経路・契約ごとに確認したい。まずは匿名化したデータで試す方法もある。[22]
派手な倍率より、自分の業務での差を見る。
TypeSafeの速度・費用の比較は、同社の特定のワークフロー評価に基づく。参考回答にも他のモデルを使っている。あらゆる業務で同じ改善が出る証明ではない。本稿の数値も独自実測ではなく、公開情報の紹介である。[2]
WHO SHOULD TRY IT
同じ種類の判断を、繰り返す人へ。
業種よりも、「いま、どこで同じ判断を繰り返しているか」で探すとよい。最初から全面導入するより、取り返しのつく一機能で比較するのがおすすめだ。
開発者
LLMに「この中から選んで」と毎回頼んでいる部分、肥大化したキーワード分岐、エージェントのスキル選択が検証候補になる。
業務・運営担当
担当の振り分け、要確認の選別、自由記述の整理など。現場は、正解の例と、誤判定すると困る境界を提供する役割を担う。
企画・分析担当
顧客の声にタグを付け、改善テーマを集計する。何を分類し、何を見逃したくないのかを、開発者と一緒に定義する。
Jevは基本的に、APIやSDKからアプリへ組み込むモデルだ。APIは、ソフトウェアから機能を呼び出す窓口のこと。非エンジニアが何でもチャットするサービスとは異なるが、判定基準を作る仕事には、現場の知識が欠かせない。[21][24]
一方、まだ導入しなくてよいケースもある
コードで明確に決められる。処理件数が少なく、手作業で困っていない。既存の分類器が十分に動いている。こうした場合は、新しい部品を増やす価値があるかを先に考えたい。「新しいから置き換える」必要はない。
まずは「裏側で判定だけ」する。
一つの判断を定義する
対象、選択肢、除外条件、情報不足の扱いを決める。現場で判断が割れる例も集める。
同じデータで比較する
現行ルール、既存分類器、小型LLM、Jevを比較。通常例だけでなく、引用・否定・複数意図も含める。
実行せず、誤りを記録する
利用者への動作は変えず、裏側で判定する。見逃しと過剰検知を分け、特に困る誤りを把握する。
自動化の範囲を広げる
安全なラベル付けなどから始める。人へ回す割合、残る誤り、全体の費用と速度を継続して測る。
しきい値は自分の業務データで評価する。モデルの更新で結果が変わり得るため、バージョンと質問文を記録し、変更時に同じ評価データで再確認する。[4][3]
FOR DEVELOPERS HTTP APIで、一つの判断を試す＋
TypeSafeのクイックスタートは、POST /v1/systemoneで状態と質問を送る形だ。以下は、その形式に沿って作成した日本語のリクエスト例。APIキーが必要で、本稿では実行していない。[21]
# 利用可能なAPIキーを環境変数 TYPESAFE_API_KEY に設定して実行。
# 実行するとAPI利用料金が発生します。ブラウザ側にはキーを置かないでください。
curl --fail-with-body --silent --show-error \
--connect-timeout 10 --max-time 30 \
https://api.typesafe.ai/v1/systemone \
-H "Authorization: Bearer ${TYPESAFE_API_KEY:?APIキーを設定してください}" \
-H 'Content-Type: application/json' \
--data-binary @- <<'JSON'
{
"model": "jev-1.13.0",
"state": "同じ注文で2回引き落とされました。確認をお願いします。",
"questions": {
"intent": {
"type": "choice",
"instructions": "この問い合わせの主な目的を選んでください。",
"criteria": {
"billing": "請求・支払い・返金に関する相談",
"technical": "動作不良・接続・機能に関する相談",
"other": "上記以外の相談",
"unclear": "主な目的を判断する情報が足りない"
}
}
}
}
JSONレスポンスのanswers.intentなどを読み、低確信度やunclearは要確認にする。タイムアウト・APIエラー時も、自動処理を続けず安全な経路へ戻す。APIキーはサーバー側の環境変数などで管理する。
現行の公式モデルIDはjev-1.13.0。jev-latestは将来の更新で指すモデルが変わるので、検証結果を再現したい場合は固定IDを使う。[3]
また、2026年9月16日にはVercel AI Gatewayでの対応も発表された。AI SDKの評価APIは実験的な機能として案内されているため、導入時点のドキュメントで利用方法と条件を確認したい。[20]
THE TAKEAWAY
全部をAIに、ではなく。
意味の判断だけ、
小さくAIに。
コードで決められることは、コードに。
文章を作る仕事は、生成型LLMに。
そして、候補が決まった意味の判断には、Jevという選択肢がある。
新しいモデルの名前を覚えること以上に大切なのは、自分のシステムのどの判断を取り出せるかを考えることだ。
SOURCES & EDITORIAL NOTES
出典・参考資料
確認日：2026年9月19日。製品仕様、料金、公開評価は変更される可能性がある。本文の図解、入力例、料金計算、振り分けデモは説明用に作成したもので、精度や効果を実証するものではない。画像はコンセプト表現であり、製品画面・実装アーキテクチャの公式図ではない。