1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@softbase(FullStack ITエンジニア)

AI Jev とは？「文章を書くAI」ではなく「すばやく答えを選ぶAI」を小学生にもわかるように説明する

1
Posted at

「AI Jev（ジェヴ）」という名前を見て、ChatGPTのように会話する新しいAIだと思いました。ところがJevは、長い文章を書く役よりも、ソフトウェアの中で決まった形の判断を返す役に向いたモデルです。

たとえば、学校の先生が届いた連絡を見て「急ぎ？」「どの係が担当？」「困り具合は1〜3のどれ？」と仕分ける場面を考えてみてください。Jevは、作文を書く児童ではなく、たくさんの連絡を素早く分類する係に近い存在です。

この記事は、AIに初めて触れる人にも伝わる説明から始め、最後はAPIを組み込むエンジニア向けに、質問の作り方・安全な使い方・失敗しやすい点まで扱います。2026年9月18日時点で公開されている公式情報をもとにしています。

まず結論：Jevは何者？

Jevは、TypeSafe AIが2026年9月15日に早期アクセスとして公開した、同社がSystem One Modelと呼ぶAIモデルです。入力された文章やプログラムの状態（state）に対し、あらかじめ決めた選択肢・点数・はい／いいえを、確率付きの構造化データとして返します。

ここでの大事な違いは、出力が「自由な文章」ではないことです。

したいこと 会話型LLMが得意な形 Jevが得意な形
問い合わせへの返信 相手に説明する文章を書く 担当チームを選ぶ
宿題の質問に答える 理由も含めて解説する 質問が緊急か判定する
アプリの処理を進める 次に何をするか文章で提案する low / medium / high を返す
データを整理する 要約文を作る 指定した項目で点数を付ける

したがって、JevはChatGPTの代わりではありません。説明文、メール、コード、アイデアを作る役には会話型LLMが必要です。一方で、アプリが毎秒のように「どちらへ送るか」「人に見せるべきか」を決める場所では、Jevのような判断専用モデルが合う可能性があります。

なお「Jev」という名前は、効率が上がると利用量が増えるという考え方で知られる経済学者 William Stanley Jevons に由来すると、TypeSafe AIは説明しています。モデル名そのものに一般的な略語の意味があるわけではありません。

小学生向けに言い換えると、「作文係」ではなく「仕分け係」

AIを学校にたとえると、会話型LLMは「質問に文章で答えられる作文係」です。便利ですが、毎回まず一文字ずつ文章を考えます。ときどき、頼んでいない形式で答えたり、もっともらしい説明を混ぜたりします。

Jevは、次のような丸付きの用紙を返す仕分け係です。

おたより：3日間ログインできず、売上が下がっています。すぐ助けてください。

急ぎ？                 はい（0.999）
担当は？               技術サポート（0.84）
困り具合は？           1.0 / 0〜2

「0.999」は「絶対に正しい」という意味ではありません。この文が急ぎだと考える確率がとても高い、という意味です。人が決めたルールと一緒に使うと、AIの答えをそのまま命令にせずに済みます。

この図でJevがしているのは、D・E・Fのどこへ進めるかを助けることです。勝手にお客様へメールを送ることではありません。

Jevに渡すもの、返ってくるもの

JevのAPIでは、大きく2つを渡します。

  • state：判断材料。問い合わせ本文、エラーログ、JSON形式の注文情報など
  • questions：stateについて何を決めたいか。返答の型と基準もここで指定する

公式ドキュメントには、次の3種類の質問が示されています。

質問の型 返るもの 使いどころ
choice 選んだ項目、各項目の確率、confidence 問い合わせの担当部署、タスクの種類
score 連続した点数、段階ごとの意味、confidence 怒りの強さ、難しさ、リスクの度合い
noul 文が真である確率 「急ぎか」「規約違反の疑いがあるか」

noul は聞き慣れない名前ですが、ここでは「はい／いいえを確率で返す質問」と覚えれば十分です。is_urgent のような名前にして、「急ぎなら真」と質問文で定義します。

複数の質問を同じstateに対してまとめて送れる点も特徴です。公式発表では、質問群を並列に評価する設計だと説明されています。個別にLLMを何度も呼ぶより待ち時間や費用を下げられる可能性はありますが、実際の速度・料金・精度は、地域、stateの長さ、質問の数、比較対象で変わります。自分のデータで測らずに「必ず200倍速い」と判断するのは危険です。

文章を1トークンずつ作るLLMと、判断を返すJevの違い

通常のLLMは、次の単語を予測しながら文章を前から順に作ります。文章、コード、会話ではこの自由さが強みになります。

Jevは、出力の候補と形を先に決めます。たとえば担当部署なら billing、technical、sales 以外を返さないように質問を定義します。アプリ側が受け取る値を予測しやすく、if department == "technical" のような通常のプログラムへつなげやすくなります。

ただし、型が合うことと、仕事上の判断が正しいことは別です。billing・technical・sales のどれかは必ず返っても、質問の基準が悪ければ誤った部署を選びます。TypeSafe AIが「型エラーを起こさない」と説明する点は、返却形式に関する利点です。問い合わせ内容の理解や業務ルールまで自動で正しくなる保証ではありません。

この区別は地味に大事です。最初は「決まった候補だけ返るなら安全」と考えがちですが、候補の中の誤答は普通に起こりえます。

まずは問い合わせを仕分けるAPIを呼んでみる

以下は公式のREST API形式に合わせた、外部ライブラリなしのPython例です。APIキーはソースコードへ書かず、環境変数から読みます。

.env はGitに入れず、共有用には値を空にした .env.example だけを置きます。

# .env.example（実際の .env へコピーして値を設定する）
TYPESAFE_API_KEY=

# macOS / Linux: .env を環境変数として読み込んで実行する
set -a; source .env; set +a
python jev_ticket_router.py

# jev_ticket_router.py
import json
import os
from urllib.error import HTTPError, URLError
from urllib.request import Request, urlopen

API_URL = "https://api.typesafe.ai/v1/systemone"


def classify_ticket(ticket: str) -> dict[str, object]:
    api_key = os.environ.get("TYPESAFE_API_KEY")
    if not api_key:
        raise RuntimeError("TYPESAFE_API_KEY を環境変数に設定してください")

    payload = {
        "model": "jev-latest",
        "state": ticket,
        "questions": {
            "department": {
                "type": "choice",
                "instructions": "どのチームが担当すべきか",
                "criteria": {
                    "billing": "支払い・請求・契約の問題",
                    "technical": "不具合・接続・連携の問題",
                    "sales": "料金・導入・アカウントの相談",
                },
            },
            "is_urgent": {
                "type": "noul",
                "instructions": "緊急の対応を求めているか",
            },
        },
    }
    request = Request(
        API_URL,
        data=json.dumps(payload).encode("utf-8"),
        headers={"Authorization": f"Bearer {api_key}", "Content-Type": "application/json"},
        method="POST",
    )
    try:
        with urlopen(request, timeout=10) as response:
            result: dict[str, object] = json.load(response)
            return result
    except HTTPError as error:
        raise RuntimeError(f"Jev API が HTTP {error.code} を返しました") from error
    except URLError as error:
        raise RuntimeError("Jev API に接続できませんでした") from error


if __name__ == "__main__":
    print(json.dumps(classify_ticket("決済連携が失敗します。今日中に確認してください。"), ensure_ascii=False, indent=2))

この例では、APIキー、問い合わせ本文、APIレスポンス全体をエラーメッセージに出していません。障害調査のために生の応答をログへ出したくなることがありますが、問い合わせには氏名・メールアドレス・契約内容が混ざります。本番では、アクセス制御、マスキング、保存期間、監査ログを先に決めます。

Python SDKを使う場合、公式ドキュメントでは typesafe-sdk と TypeSafeClient も案内されています。依存パッケージをプロジェクトへ追加する際は、公開時点の互換バージョンをロックファイルで固定し、更新は検証用環境で試します。

返答を見て、すぐ実行しない

Jevの返答を使う本当の処理は、API呼び出しの後にあります。たとえばdepartmentがtechnicalで、confidenceが十分高いときだけ技術キューへ自動投入する、と決めます。低い確信度は「失敗」ではなく、人が見た方がよい合図です。

from typing import Any


def next_action(response: dict[str, Any]) -> str:
    answers = response.get("answers", {})
    department = answers.get("department", {})
    urgent = answers.get("is_urgent", {})

    choice = department.get("choice")
    confidence = department.get("confidence", 0.0)
    urgency_probability = urgent.get("noul", 0.0)

    if not isinstance(confidence, (int, float)) or not isinstance(urgency_probability, (int, float)):
        return "manual_review"  # 壊れた応答は自動処理しない
    if urgency_probability >= 0.90:
        return "page_on_call_human"  # 通知先は固定し、AIに宛先を作らせない
    if choice == "technical" and confidence >= 0.80:
        return "enqueue_technical_ticket"
    if choice in {"billing", "sales"} and confidence >= 0.80:
        return f"enqueue_{choice}_ticket"
    return "manual_review"

一見わかりにくいのですが、ここでは「AIが送信先を自由に書く」ことを許していません。アプリ側に用意した文字列だけを返し、実行できる処理を絞っています。実際のキュー投入や電話通知の前には、認可、重複防止、利用者への表示、失敗時の再試行も別途必要です。

個人的には、最初の導入では自動実行よりも、manual_review を増やして人が採点できる状態から始める方が好みです。十分な正解データと失敗例が集まってから、対象を限定して自動化します。

Jevが合う場面、合わない場面

合いやすい場面

  • 大量の問い合わせ・レビュー・ログを、事前に決めた項目で仕分ける
  • エージェントがツールを呼ぶ前に、危険度や人の承認が必要かを判定する
  • 軽い問い合わせは安価なモデルへ、難しい作業は高性能モデルへ振り分ける
  • 画面操作やゲームのように、短い待ち時間で繰り返し判断したい

LangChainは、モデルの振り分けや、ツール呼び出し前のリスク判定にJevを使う例を公開しています。これは「AIエージェントの司令塔をすべてJevに替える」のではなく、文章を考えるLLMの前後に判断係を置く設計です。

合いにくい場面

  • 相手に事情を説明するメールや、自由な会話を作る
  • まだ選択肢や採点基準が決まっていない探索
  • 法的判断、採用可否、診断、送金など、誤った自動判断の被害が大きい処理
  • 結果の理由を文章で丁寧に説明する必要がある処理

Jevの確率は便利でも、責任を肩代わりするものではありません。特に人の権利やお金に関わる決定は、説明可能な業務ルールと人の承認を残します。

失敗しやすい4つの使い方と避け方

1. 質問をぼんやり書く

「これは大事ですか？」では、人によって「大事」の意味が違います。SLA違反までの時間、顧客への影響、セキュリティ事故かどうかなど、判断基準を分解します。

悪い例：重要か
改善例：4時間以内に人が対応しないと顧客影響が広がるか

2. 確率を正解率だと思い込む

0.9は「この入力を真だと判断する確率」であり、自社の運用で90%当たるという保証ではありません。過去の問い合わせを正解ラベル付きで集め、確率帯ごとの実際の正解率、誤振り分け数、人手確認率を測ります。

3. 判定結果から、いきなり危険な操作をする

「削除してよい」「本番へ反映してよい」という質問をAIに投げ、そのまま実行すると、誤判定の影響が大きすぎます。読み取り専用、下書き作成、通知候補の提示から始めます。書き込み操作には、固定した許可リスト、人の承認、実行上限を置きます。

4. ベンダーの性能値だけで設計を決める

TypeSafe AIは公式発表で、System One型のタスクにおける速度・費用の優位性を報告しています。一方で、その評価の前提や比較対象は自社発表です。自社の日本語データ、ネットワーク遅延、質問設計、エラー処理を含めた時間と費用で、小さなA/Bテストをします。

導入するなら、この順番が安全

  1. まず業務を一つだけ選ぶ。例は「問い合わせを3部署へ仕分ける」。
  2. 人が付けた正解ラベルを用意し、質問の基準と候補を何度も直す。
  3. 最初は結果を人に見せるだけにする。自動実行はしない。
  4. 確信度のしきい値ごとに、正解率・人手確認率・処理時間・費用を記録する。
  5. 誤りの影響が小さい処理だけ、固定された操作へ段階的につなぐ。

「AIを入れる」より、「今までif文だけでは書けなかった、あいまいな仕分けを一つ安全に置き換える」と考えると、Jevの役割が見えやすくなります。

まとめ

Jevは、文章を生成するLLMではなく、ソフトウェアが利用しやすい型付きの判断と確率を返すAIです。小学生向けに言えば、作文係ではなく仕分け係です。

その速さや形式の扱いやすさは魅力ですが、正しい業務判断を保証する魔法のボタンではありません。選択肢と基準を人が設計し、低確信度を人へ戻し、危険な操作を別の仕組みで止める。この3つを守ると、JevをAIエージェントや業務フローの堅実な部品として試せます。

参考資料

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?