YES!かNO!で答えてくれるAI「Jev」を使ってみた

最近、話題になっている判定に特化した AI「Jev」を使ってみました。これは、まるで「アトゥム」です。

Jev とは

Jev は TypeSafe AI の判定に特化した AI です。通常の AI (LLM) は文章など、ユーザーが指定したとおりの出力形式で内容を生成しますが、Jev は JSON 形式で数値を返します。

できることと返す内容を限定することで、出力トークンは小さく、とても速く、圧倒的に安いという特徴があります。

Jev の料金は出力トークンがほぼ固定されているため、入力トークンのみで決まります。

2026年9月30日現在、GPT-6 Astra (OpenAI) と Claude Fable 5.1 (Anthropic) の100万トークンあたりの価格は、入力トークンが 10USD、出力トークンが 50USD、計 60USD なのに対し、Jev は 0.042USD だと公式でアナウンスされています。

判定方法は Noul, Score, Choice の3種類が使用できます。

Noul

質問に対して YES! か NO! を確率で判定します。公式によると、API 経由で次のような JSON リクエストを行った場合、

{
  "state": "I have asked three times now. Can I please just talk to a real person?",
  "questions": {
    "is_human_escalation": {
      "type": "noul",
      "instructions": "Is the customer asking for a human agent?"
    },
    "is_repeat_contact": {
      "type": "noul",
      "instructions": "Has the customer contacted support about this before?",
      "criteria": {
        "true": "Mentions a prior attempt, ticket, or that they have asked before",
        "false": "No sign of any previous contact"
      }
    }
  }
}

次のような JSON レスポンスが返ってきます。

{
  "model": "jev-1.13.0",
  "answers": {
    "is_human_escalation": {
      "type": "noul",
      "noul": 0.99
    },
    "is_repeat_contact": {
      "type": "noul",
      "noul": 0.93
    }
  },
  "usage": {
    "input_tokens": 360,
    "output_tokens": 39
  }
}

この場合、is_human_escalation が YES! である確率は 99%、NO! である確率は 1%、is_repeat_contact が YES! である確率は 93%、NO! である確率は 7% ということになります。

Score

質問に対して、アンケートを集計したかのような判定をします。公式によると、API 経由で次のような JSON リクエストを行った場合、

{
  "state": "The export button crashes the settings page in Safari. It works in Chrome, but a few of our customers only use Safari.",
  "questions": {
    "bug_severity": {
      "type": "score",
      "instructions": "How severe is the reported issue?",
      "criteria": [
        "Cosmetic; no impact to functionality",
        "Broken or degraded feature, but workaround exists",
        "Blocking issue; no workaround exists"
      ]
    }
  }
}

次のような JSON レスポンスが返ってきます。

{
  "model": "jev-1.13.0",
  "answers": {
    "bug_severity": {
      "type": "score",
      "score": 1.43,
      "confidence": 0.35,
      "legend": {
        "0": "Cosmetic; no impact to functionality",
        "1": "Broken or degraded feature, but workaround exists",
        "2": "Blocking issue; no workaround exists"
      },
      "probabilities": {
        "0": 0.0,
        "1": 0.57,
        "2": 0.43
      }
    }
  },
  "usage": {
    "input_tokens": 332,
    "output_tokens": 18
  }
}

この場合、「Cosmetic; no impact to functionality」は 0%、「Broken or degraded feature, but workaround exists」は 57%、「Blocking issue; no workaround exists」は 43%、そして、それらの信頼度 (confidence) は 35% ということになります。

Choice

複数の選択肢の中から1つを選択します。公式によると、API 経由で次のような JSON リクエストを行った場合、

{
  "state": "My running shoes arrived in the wrong size. Can I swap them for a size 10?",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this?",
      "criteria": {
        "returns": "Exchanges, wrong or damaged items",
        "shipping": "Delivery status, delays, lost packages",
        "billing": "Charges, invoices, payment problems"
      }
    }
  }
}

次のような JSON レスポンスが返ってきます。

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "returns",
      "confidence": 1.0,
      "probabilities": {
        "shipping": 0.0,
        "returns": 1.0,
        "billing": 0.0
      }
    }
  },
  "usage": {
    "input_tokens": 328,
    "output_tokens": 34
  }
}

この場合、「shipping」は 0%、「returns」は 100%、「billing」は 0% で、「returns」が選択され、その信頼度 (confidence) は 100% ということになります。

Jev のユースケース

Jev は人向けではなく、マシン (コンピュータ, ソフトウェア, AI) 向けの AI で、プログラムなどに組み込んで使用します。

プログラミングにおいて、変数の値が不定のものを判定させることは困難でした。しかし、Jev を使用することで判定が可能になり、適切な分岐を行うことができるようになります。

例えば、お客様からの問い合わせメールの、緊急度、問い合わせ理由、求めている対応などを判定して、適切な担当者に適切な優先度で振り分ける、といったことができるようになります。

私が Jev を使ってみた理由

私は現在、OpenAI の Codex を使用しています。処理させる内容にもよりますが、トークンをがっつり消費されることが多々あります。指示の出し方や処理のさせ方に問題がある可能性もありますが、Codex が複雑な判定をする際に、多くのトークンを消費している可能性もあると思い、使用してみました。

Jev を Codex に使用させるための大まかな流れ

1. TypeSafe AI にサインインします。初回にはアカウントを作成します。
2. API キーを作成します。初回には支払方法 (Payment method)、請求先アドレス (Billing address) を設定し、利用可能クレジット (Available credits) のチャージが必要です。
3. PC (Windows) のユーザー環境変数 TYPESAFE_API_KEY に作成した API キーを設定します。
4. Codex が環境変数 TYPESAFE_API_KEY を認識できているか尋ねて確認します。認識できていない場合は Codex を再起動 (Ctrl+Q) します。
5. 疎通テストを行うよう指示し、Codex が Jev を使用できるか確認します。
6. Jev を使用すべきケースと使用すべきではないケースをディスカッションして決定します。

これで、Codex が必要に応じて Jev を使用できるようになります。

Jev を Codex に使用させる前の注意点

Jev を使用して適切に判定させるには、Noul, Score, Choice のうちの正しい判定方法を使用して適切なリクエストをコーディングエージェントに作成させる必要があります。

それを実現するには、一定以上の性能を持ったモデルを使用する必要があると思い、Codex に各モデル毎の Jev の活用力を尋ねてみました。その結果、次のような返答がありました。

Codex の場合、Astra, Sol であれば、事前に特別な指示を出すことなく、Jev を使ってくれそうです。他のコーディングエージェントの場合、Astra, Sol と同等の性能を持つモデルであれば問題ないかと思います。

実際、GPT-5.6 Sol でテストした結果、

• 日本語の運用意図を英語の構造化状態へ変換
• Choice, Score, Noul を正しく選択
• 複数の判断を1リクエストにまとめる
• プロジェクト固有の制約を選択肢と評価基準へ反映
• 不確実な結果を無理に採用せず識別する

これらができていると報告されました。

ちなみに、「日本語の運用意図を英語の構造化状態へ変換」は、Jev は英語が主な訓練言語で、CJK (中国語, 日本語, 韓国語) は現時点で精度が低いと公式資料にあるため、このような処理を行っています。現時点において、独自のプログラムに Jev を組み込む際には、リクエストを英語で記述した方が良さそうです。

A/B テストの結果

同一の簡単な判断課題を Codex のみと Codex + Jev の2パターンで A/B テストを行わせたところ、Codex + Jev は約18倍高速、およそ 1/8.3 のトークン量という結果になりました。

これは、各1回ずつの限定判断なので、実運用判断には複数回・難易度別の追加測定が必要ですが、現時点では、一応は狙い通りにトークン消費の軽減と速度向上が実現できています。

ちなみに、今回の疎通テストと A/B テストにかかった Jev の料金は 0.0001USD (0.016円) でした。正しく活用できれば、上位モデルの使用量を増やしたり、ChatGPT (Codex) のプランをワンランク下げたりできると思います。

今後の AI はどうなるか？

間違いなく Jev は有用で、独自のプログラムに組み込むだけでなく、AI の判断補助に活用できます。しかし、AI の開発元はトークン消費量と応答速度の改善を行っているはずなので、将来的には、AI のネイティブな機能として組み込まれるのではと予想します。

それが、いつ実現するかは分かりませんが、それまでは Jev を使い続けてみようと思っています。

〆

冒頭に挙げた「アトゥム」は「ジョジョの奇妙な冒険」第三部「ダービー・ザ・プレイヤー」に登場する YES! か NO! で読心術を行うスタンドの名称です。Jev が登場したとき同じように思った人もいるはず。オレオレですか？