Jevは何が進化した？ 1.14の画像入力・Box・長文対応と実装の勘所

Last updated at 2026-11-10Posted at 2026-11-10

個人開発しているもの

日々の開発で得た知識を発信しながら、「あったら便利」「作ってみたい」と思ったアイデアを形にしています。

これまでに、グループ旅行アプリ Trip Supporter、スコア管理サービス PointPia、リアルタイム共有サービス JustNow などを開発しました。

さらに、刺繍やオリジナルキャラクターを中心としたアパレルブランド MAD TOMMY WITH... も運営しています。

開発したサービスや技術記事は chicchi.work で紹介しています。

Jevの進化を2026年11月10日時点で整理する

2026年9月15日にTypeSafe AIが公開した Jev（ジェブ） は、文章を自由に生成するLLM（大規模言語モデル）とは違い、決められた問いに型の決まった答えを返す「System One」モデルだ。ここでいう「型」は、選択肢や数値など、プログラムからそのまま扱えるデータ形式を指す。

そのJevは10月14日の 1.14 リリースで、テキストの分類を中心とした用途から、画像を参照する判断・画像内の位置検出・長い文脈の扱いに広がった。11月3日には開発元が「Jevは判断材料を評価し、最終決定はコードが行う」という役割分担をあらためて明文化している。

2026年11月10日時点で公式モデル一覧に載る最新版は jev-1.14.0。この日付に新モデルが出たという意味ではない。更新の日時と、現在利用できる機能を分けて見ていく。

1. Jevが最初から得意だったこと

Jevには、あらかじめ結果の形を決める「質問のプリミティブ」（小さな基本操作）がある。

種類	入力する問い	受け取るもの	用途例
Choice	用意した候補のどれか	選ばれた候補、候補別確率、confidence	問い合わせの担当振り分け
Score	定義した段階のどこか	段階別確率、スコア、confidence	コメントの緊急度・トーン評価
Noul	「はい」か「いいえ」か	「はい」である確率（0〜1）	メッセージの要対応判定
Box	画像のどこに対象があるか	四辺の位置とconfidence	写真内の対象位置検出（1.14で追加）

confidence は候補への確率の集中具合を表す確信度で、正答率が保証される数値ではない。Noulは独立したconfidenceを返さず、noul の値そのものが「はい」の確率だ。複数の独立した質問を同一リクエストで評価できる点も特徴となる。

Jevは文章やソースコードを生成するサービスの置き換えではない。「問い合わせは請求か技術か」「チェックすべきか」といった狭い評価をソフトウェアに組み込むための部品と考えると理解しやすい。

2. 1.14で大きく広がった3つの機能

画像を読みながら分類・判定できる（実験的）

PNG / JPEG画像を state（判断対象の情報）、instructions（問いの指示）、criteria（選択肢の定義）の中に配置できる。例えば、商品の写真と説明文から「破損が見えるか」を問う、画像同士が同じ品物を示すか判断するといった使い方だ。

ただし 画像入力は1.14だけの機能ではない。公式説明では1.13にも対応があり、10月14日に利用方法が公開された。利用するリクエストには以下のHTTPヘッダーを付ける。

TypeSafe-Danger-Zone-Images: true

ヘッダーとはAPIリクエストに付ける追加情報のこと。ここでは、通常は無効の実験機能を有効化するフラグだ。画像の見落としは起こり得るため、本番の自動承認・拒否に直結させず、評価データで精度を測ってから採用する。

Boxで画像内の「場所」を返せる（1.14限定・実験的）

新しい Box 質問は、画像中の対象を囲む四角形の座標を返す。「この書類の署名欄はどこか」「写真のマグカップはどこか」といった問いが可能になった。

返り値は left、top、right、bottom の4辺を、それぞれ0〜1に正規化した数値で表す。例えば横幅1000pxの画像で left: 0.2 なら左端は約200pxに相当する。座標は画像全体に対する割合なので、プログラムから切り出しや枠の描画につなげられる。

Boxは jev-1.14.0が必要で、画像の実験フラグも必要だ。画像認識や位置推定が常に正しいわけではないため、低確信度の結果は目視確認に回す。

実際に画像を送る：SDKの動作例

画像を含むAPI呼び出しでは、画像ファイルそのものを image() で渡す。SDKは参照用の識別子を作り、ファイルをmultipart形式（HTTPリクエストを複数部分に分ける形式）で送信する。

import { openAsBlob } from "node:fs";
import { image, noul, box, TypeSafeClient } from "@typesafe-ai/sdk";

const client = new TypeSafeClient();
const photo = image(await openAsBlob("./sample.jpg"));

const result = await client.systemOne(
  {
    model: "jev-1.14.0",
    state: { photo },
    questions: {
      present: noul("Is there a signature in `photo`?"),
      position: box("The handwritten signature in `photo`"),
    },
  },
  { headers: { "TypeSafe-Danger-Zone-Images": "true" } },
);

// 対象の有無はNoulで独立に確認する。
// Boxの座標が返っただけで「署名がある」と断定しない。
const exists = result.answers.present.noul >= 0.8;
const coords = exists ? result.answers.position.box : null;
console.log({ exists, coords });

0.8は説明用の暫定値で、公式が定めた推奨閾値ではない。Boxは対象が見つからない画像にも四角形を返し得るため、Noulで存在を確認してから座標を採用するのが安全だ。なお、この例は公式SDKの使い方に合わせたサンプルで、実際の画像を使うAPI実行・精度検証は行っていない。

画像を使う前に知っておきたい入力制限

公式ドキュメントの現行上限は以下のとおり。

制限	値
対応形式	PNG / JPEGの静止画（HEIC / WebP / 動画は直接送れない）
画像1ファイル	最大16 MiB
縦・横	それぞれ280〜1568ピクセル
リクエスト本文	最大32 MiB
画像が参照先へ展開された後の合計	最大32 MiB

送信前にリサイズし、EXIFの回転情報を頼らず画像ピクセル自体を正しい向きにしておく必要がある。APIはサイズ超過の画像を自動縮小しない。画像を複数の質問で繰り返し参照すると、展開後のサイズや入力トークンも増える。画像も入力トークンとして課金されるので、安い単価でもサイズと呼び出し頻度の管理が必要になる。

長文を最大262kトークンまで扱える（実験的）

標準のコンテキスト制限（コンテキストとはモデルが一度に参照する入力範囲）は、リクエスト全体が 64kトークン、質問単位が 32kトークン。次のヘッダーで両方とも 262kトークン に引き上げられる。

TypeSafe-Danger-Zone-Long-Context: true

1.13と1.14の両方で利用可能だが、入力を長くするほど速く正確になるわけではない。公式も長文モードは遅くなり、精度が下がると注意している。先に検索やルールで関連箇所を絞り、必要なときだけ利用する設計がよい。

3. 1.14では多言語対応も改善

公式のモデル変更履歴で、1.14の改善点として明記されているのが 多言語対応の向上。日本語の問い合わせを分類するワークフローにも関係がある。ただし「日本語精度が何％改善」といった再現可能な公式数値は確認できない。業務固有の日本語サンプルで、1.13と1.14の判定結果を比較したい。

jev-latest と jev-preview は、確認時点ではどちらも jev-1.14.0 を指している。エイリアス（別名）は将来指す版が変わるため、検証済みの閾値を維持したい本番システムではバージョン固定を検討する。

4. TypeScriptでの実装例：問い合わせを安全に振り分ける

TypeSafe公式JavaScript SDKはNode.js 22以降に対応する。

npm install @typesafe-ai/sdk

npm はJavaScriptのパッケージ管理ツールで、install は依存ライブラリを導入する操作。APIキーは事前に環境変数 TYPESAFE_API_KEY で設定し、コードやGitに直接書かない。

次は「分類Choiceに加えて、そもそも分類対象かをNoulで確かめる」例。顧客への返信送信などの副作用（外部状態を変える操作）は発生させず、分類結果だけを返す。

import { choice, noul, TypeSafeClient } from "@typesafe-ai/sdk";

const client = new TypeSafeClient();

async function routeTicket(message: string) {
  const { answers, model } = await client.systemOne({
    model: "jev-1.14.0",
    state: { message },
    questions: {
      department: choice("Which team should handle `message`?", {
        billing: "Payment, charges, invoices, and subscriptions",
        technical: "API errors, bugs, and integration problems",
      }),
      inScope: noul(
        "Does `message` describe a billing or technical support request?",
      ),
      urgent: noul(
        "Does `message` describe an incident that needs immediate attention?",
      ),
    },
  });

  // 数値は説明用の仮の閾値。実データで検証して調整する。
  if (answers.inScope.noul < 0.7 || answers.department.confidence < 0.8) {
    return { route: "manual_review", model };
  }

  return {
    route: answers.department.choice,
    priority: answers.urgent.noul >= 0.8 ? "high" : "normal",
    model,
  };
}

console.log(await routeTicket("APIで500エラーが続いています"));

ここで重要なのは、Choiceは候補から必ずどれかを選ぶこと。関係のない入力でも選択肢の一つを選ぶことがある。そこで別のNoulで対象外かを確認する。この構成は公式の「Companion Noul」パターンに沿っている。例の0.7、0.8は公式推奨の閾値ではない。入力分布、誤判定時の影響、有人確認のコストに応じて評価する。コード例はAPIを実際に呼んだ検証結果ではなく、公式仕様に基づく実装例だ。

5. 進化してもJevに任せない処理

2026年11月3日のTypeSafe公式記事は、Jevの責務を明確に区別した。Jevは評価し、コードが決める。この線引きが、導入を考えるうえで特に重要だ。

例えば請求書処理なら、曖昧な文面が請求に関係するかはJevに聞ける。一方、金額の加算・日付の前後関係・件数の集計・実際の送金はコードで行う。Jevの公式な既知の弱点にも、計算、日付比較、複数段の推論、大量の無関係な文章、選択肢の順序依存などが挙げられている。

また、型どおりの値が返ることは、意味まで必ず正しいこととは違う。入力が不適切なら、構造として有効でも誤った分類や位置検出があり得る。実行権限・安全ルール・監査ログはアプリ側の責任として残す。

速さ・精度の数字はどう読むべきか

2026年9月15日の発表では、TypeSafeが開発元の評価条件で「従来の生成LLMより高速・安価」という測定結果を示した。ただし、これはすべてのシステムで同じ高速化率になるという保証ではない。開発元自身も、短い入力のデモに有利な条件や、評価対象のワークフローに偏りがあり得る点を明記している。

新しい1.14について確認できる主張は、主に多言語性能の改善と実験機能の拡張だ。日本語での精度向上率、Boxの汎用的な正解率、262kトークンでの品質を外部で再現した数字は本記事では提示しない。導入時は正解ラベル付きの自社データと実測レイテンシ（APIの応答時間）で評価する。

6. 料金・導入時の確認点

公式モデル一覧の2026年11月10日時点の価格は、1.13と1.14とも 入力100万トークンあたり0.042米ドル、出力トークンは無料。これは処理内容にかかわらず常に費用がゼロという意味ではなく、入力トークン数に応じて課金される。組織ごとのレート制限はコンソールで確認し、HTTP 429時は再試行間隔を尊重する。

導入前には、(1) 日本語や自社データでの誤分類率、(2) 確率・confidenceごとの精度、(3) モデルのバージョン、(4) 個人情報や機密情報の取り扱い、(5) 実験的な画像機能の可用性を確認したい。

まとめ：Jevは「賢いif文」から視覚的な判断にも広がった

9月の公開当初は選択・評価・真偽判定が中核だった。10月の1.14では多言語改善、画像入力の公開、Boxによる位置特定、長い入力へのオプトインが加わり、より多くの処理に組み込めるようになった。

それでも、文章を生成するLLMと競合する万能モデルになったわけではない。意味を評価する場所にだけJevを置き、数値計算や最終的な操作はテストできるコードが担う。この分担こそが実務での使いどころだ。

参照した一次情報（2026年11月10日確認）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up