は、 が提供する、判断を返すAIです。自然言語の入力を読み、あらかじめ決めた選択肢・評価段階・真偽の確率を返します。自由な文章は生成せず、ソフトウェアの処理を分ける判断に使います。提供元は、この種類を と呼んでいます。公式の紹介
問い合わせを担当部署に振り分ける。届いた文書を分類する。返信案が条件を満たしているか確かめる。こうした仕事で必要な小さな判断を、プログラムが直接受け取れるのがJevの特徴です。この記事では、 との違い、APIの使い方、料金を確認し、業務へ組み込むための具体的な実装案を紹介します。
概要と選定の考え方は第1・2節、実装は第3〜7節、料金は第8節、日本語対応と限界は第9節で扱います。コードを試す前に、用途と利用条件を確認してください。
2026年9月22日時点の公式資料に基づく解説です。Jevは9月15日に早期アクセスとして発表されました。掲載コードは構文と応答後の分岐をローカルで確認していますが、Jevの実APIによる精度・速度の測定は行っていません。発表記事
1. Jev(TypeSafe AI)とは:3つの判断形式
Jevでは、評価する文章やデータを state、尋ねたいことを questions に入れます。現在の入力はテキストのみで、画像・音声・動画を直接渡すことはできません。入力の公式仕様。「営業・請求・技術のどこへ送るか」と聞くなら、選択肢も先に渡します。返ってくるのは選んだ項目や確率で、返信メールや判断理由の文章ではありません。TypeSafeはこの仕組みを、ソフトウェア内で使う判断のためのモデルとして位置付けています。System Oneの説明
| 形式 | 問い合わせ対応での問い | 返る値 |
|---|---|---|
| 担当する窓口はどこか | 選択項目、各候補の確率、confidence | |
| 業務への影響はどの段階か | 段階番号の確率加重平均、各段階の確率、confidenceなど | |
| 返金を明示的に求めているか | 「はい」の確率を表す0〜1の値 |
窓口のように順序のない分類には Choice、段階のある評価には Score、一つの条件の真偽には Noul を使います。Scoreに「影響なし・一部停止・全体停止」の3段階を渡すと、番号は0・1・2です。返り値の1.4は段階番号の確率加重平均であり、「業務が40%止まっている」という測定値ではありません。
2. JevとLLMの違い:通常のコードとの役割分担
この仕組みを使うなら、最初に仕事を分解すると見通しがよくなります。以下は製品の性能順位ではなく、本記事で提案する役割分担です。問い合わせの振り分けを例にすると、宛先の候補を決める判断と、実際の送信、返信文の作成は別々の処理として設計できます。
生成LLMでも、 を使って分類結果を返せます。たとえば生成LLMの公式ドキュメントにある分類例は、その使い方を示しています。JevはChoice・Score・Noulという判断形式と確率を返すAPIを備え、自由文を生成しない設計です。既存LLMで分類できている場合も、同じ入力で誤分類、未判定、応答時間、総費用を比べて選びます。本記事では優劣を実測していません。
| 必要な処理 | 組み込む役割 | 問い合わせ対応での例 |
|---|---|---|
| 文脈を読んで、候補から選ぶ | Jevなどの判断モデル | 用件を担当窓口に分類する |
| 自由な文章を作る、説明を組み立てる | 生成系LLM | 対応方針をもとに返信案を書く |
| 正確に計算する、決めた条件を適用する | 通常のコード | 金額を集計する、営業時間を確認する |
| 曖昧な案件や例外を確かめる | 担当者による確認 | 複数部署にまたがる相談を引き受ける |
まず分類だけに使えば、返信の書き方を変えずに効果を確かめられます。逆に、すでに固定の条件で正しく分類できているなら、その部分をモデルに置き換える理由は薄いでしょう。必要な箇所を見極める考え方は、道具箱 EP.24「道具を増やしすぎない」にもつながります。
3. Jevの使い方:PythonからAPIを呼ぶ
ここでは、架空の問い合わせに対して「担当窓口」と「返金要求の有無」を尋ねます。 のリクエストは で送り、結果をファイルに保存します。公式クイックスタートに従って利用可能なアカウントとAPIキーを用意し、キーを環境変数 TYPESAFE_API_KEY に設定してください。コードは の標準ライブラリだけで動く形です。
以下は日本語の例です。公式では英語が最も得意とされており、日本語の精度は自社の文章で確かめる必要があります。言語対応と第9節を確認したうえで、まずAPI呼び出し、次に応答を受けた分岐を作ります。

注目したいのは「その他・判断保留」に当たる review も候補に入れたことです。請求・技術・営業のどれにも収まらない文を、無理にその三つへ押し込めないためです。また、返金について尋ねるのは「要求があるか」だけで、返金の可否や実行を任せているわけではありません。利用者の意図の判定と、会社の対応方針を分けておきます。
# jev_request.py — Python 3.10以降、標準ライブラリのみ# TYPESAFE_API_KEY は環境変数から読み込む。ソースには書かない。import jsonimport osfrom pathlib import Pathfrom urllib.request import Request, urlopen
payload = { "model": "jev-1.13.0", # 記事確認時の版に固定 "state": { "message": "請求書の宛名を変更したいです。手順を教えてください。" }, "questions": { "department": { "type": "choice", "instructions": "問い合わせの主な用件を担当する窓口を選ぶ。", "criteria": { "billing": "請求書、支払い、返金の相談", "technical": "不具合、接続、操作上の技術的な相談", "sales": "新規導入や契約プランの相談", "review": "複数の用件が混在する、情報不足、または該当なし", }, }, "refund_requested": { "type": "noul", "instructions": "問い合わせの本文で、利用者は返金を明示的に求めているか。", }, },}
def evaluate_message(message): if not isinstance(message, str) or not message.strip(): raise ValueError("問い合わせ本文が空です。") key = os.environ.get("TYPESAFE_API_KEY") if not key or key == "YOUR_API_KEY": raise RuntimeError("有効なTYPESAFE_API_KEYを環境変数に設定してください。") body = {**payload, "state": {"message": message}} request = Request( "https://api.typesafe.ai/v1/systemone", data=json.dumps(body, ensure_ascii=False).encode("utf-8"), headers={ "Authorization": f"Bearer {key}", "Content-Type": "application/json", }, method="POST", ) with urlopen(request, timeout=30) as response: return json.load(response)
def main(): result = evaluate_message(payload["state"]["message"]) # 成功した応答を保存。2つ目の例で読み込める。 Path("jev-response.json").write_text( json.dumps(result, ensure_ascii=False, indent=2), encoding="utf-8" ) print("jev-response.json に保存しました。")
if __name__ == "__main__": main()python jev_request.py を実行すると、成功した応答が jev-response.json に保存されます。応答は answers.department と answers.refund_requested から読めます。仕様はAPIリファレンスを参照してください。この例では通信失敗時に例外で停止します。運用に組み込む際は、通信失敗も「未判定」として人の確認に戻し、過去の応答ファイルを今回の結果として使わない設計にします。
応答の形を読むため、説明用のJSONを示します。数値はすべて手で置いた仮値で、Jevによる判定・confidenceの計算・使用量の実測を示すものではありません。
{ "model": "jev-1.13.0", "answers": { "department": { "type": "choice", "choice": "billing", "probabilities": { "billing": 0.96, "technical": 0.02, "sales": 0.01, "review": 0.01 }, "confidence": 0.9 }, "refund_requested": { "type": "noul", "noul": 0.05 } }, "usage": { "input_tokens": 1000, "output_tokens": 40 }}choice は窓口候補、probabilities は候補ごとの確率、confidence は分布から得る指標、noul は返金要求についての「はい」の確率です。この仮の応答なら、次節の条件では billing が表示されます。同じ構造で confidence が0.85未満、または noul が0.20を超える場合は human_review になります。
一つの呼び出しに入れた質問は、同じ state を見て独立に評価されます。「質問Aの結果を読んで質問Bに答える」という順序にはなりません。たとえば、選ばれた窓口に応じて社内資料を取得し、その資料を評価したい場合は、最初の応答を受けた後で次の呼び出しを組みます。質問の独立性と組み合わせ
4. 「確率」「点数」「confidence」を混同しない
ChoiceとScoreに含まれる は、確率分布がどれだけ一つの候補や段階に集中しているかを要約した値です。したがって、confidence = 0.9 を「この判断は90%の確率で正しい」と読み替えることはできません。選択肢ごとの probabilities とも別の値です。confidenceの公式説明
Noulには独立した confidence がありません。たとえば返金要求を尋ねたときの noul = 0.5 は、「半額の返金を希望している」という意味ではなく、問いに対する「はい」と「いいえ」の確率が同程度という意味です。数値を使う前に、何についての確率なのかを文章で言える状態にしておくと、分岐条件を取り違えにくくなります。Noulの読み方
TypeSafeが重視する は、多数の予測で確率と実際の発生割合を対応させる考え方です。それも、目の前の一件を保証するものではありません。公式AI primerが示すように、個別の回答と集団での性質を分けて読みます。本記事では、未判定や曖昧な結果を、人が確認する窓口へ戻す設計を採ります。
# jev_route.py — 応答を検査し、候補窓口だけを表示するimport jsonimport mathimport sysfrom jev_request import payload
# 説明用の仮値。自社データで評価してから決める。MIN_CONFIDENCE = 0.85MAX_REFUND_PROBABILITY = 0.20ALLOWED_DEPARTMENTS = {"billing", "technical", "sales"}EXPECTED_OPTIONS = ALLOWED_DEPARTMENTS | {"review"}
def valid_probability(value): return (type(value) in (int, float) and 0 <= value <= 1 and math.isfinite(value))
def validate_response(result): # この問い合わせ例の応答契約を検査。判断内容の正しさは別に評価する。 try: if result["model"] != payload["model"]: raise ValueError("検証対象と異なるモデルです。") answers = result["answers"] department = answers["department"] refund = answers["refund_requested"] if department["type"] != "choice" or refund["type"] != "noul": raise ValueError("回答の型が一致しません。") queue = department["choice"] probabilities = department["probabilities"] if not isinstance(queue, str) or queue not in EXPECTED_OPTIONS: raise ValueError("未知の候補です。") if not isinstance(probabilities, dict) or set(probabilities) != EXPECTED_OPTIONS: raise ValueError("確率分布の候補が一致しません。") values = [department["confidence"], refund["noul"], *probabilities.values()] if not all(valid_probability(value) for value in values): raise ValueError("確率またはconfidenceが範囲外です。") if not math.isclose(sum(probabilities.values()), 1.0, abs_tol=1e-6): raise ValueError("確率の合計が1ではありません。") if probabilities[queue] != max(probabilities.values()): raise ValueError("選択結果と確率分布が一致しません。") usage = result["usage"] for key in ("input_tokens", "output_tokens"): if type(usage[key]) is not int or usage[key] < 0: raise ValueError("使用量が不正です。") return department, refund except (KeyError, TypeError) as error: raise ValueError("応答の必須項目が欠けているか型が違います。") from error
def choose_queue(result): try: department, refund = validate_response(result) except ValueError: return "human_review" # 返金の可能性がある相談は人へ。返金処理そのものは実行しない。 if refund["noul"] > MAX_REFUND_PROBABILITY: return "human_review" if department["confidence"] < MIN_CONFIDENCE: return "human_review" queue = department["choice"] return queue if queue in ALLOWED_DEPARTMENTS else "human_review"
if __name__ == "__main__": # python jev_route.py jev-response.json # 読み込み失敗時も窓口を決めず、人の確認に戻す。 try: with open(sys.argv[1], encoding="utf-8") as file: result = json.load(file) except (IndexError, OSError, ValueError): result = None print(choose_queue(result))二つのファイルを保存し、最初の呼び出しが成功した直後に python jev_route.py jev-response.json を実行します。表示されるのは担当窓口の候補か human_review です。ここで使った0.85と0.20は、推奨基準でも実測から得た値でもありません。実際の問い合わせで、誤って振り分ける件数と、人が確認する件数の両方を見ながら決めるための仮値です。
5. 具体的な実装提案:三つの業務に組み込む
ここからは、ふくふくが扱うデータ活用・業務自動化の領域を想定した設計提案です。導入済みの顧客事例や実測結果ではありません。公式の設計パターンを踏まえ、入力するもの、Jevへの問い、その後の処理、効果の測り方を具体化します。
提案A:問い合わせの担当窓口を提案する
最初に試すなら、前掲コードを使った問い合わせの仕分けを提案します。フォームの件名と本文をつなぎ、分類に必要な内容だけをJevへ渡します。「請求書の宛名を変更したい」は請求窓口の候補、「接続できないので返金してほしい」は人が確認する候補、といった扱いを業務担当者と先に決めます。これは期待する扱いの例で、Jevの実際の出力を示したものではありません。
| 項目 | 実装する内容 |
|---|---|
| 入力 | 件名・本文と、窓口ごとの業務範囲。分類に不要な氏名や電話番号は送信項目から除く |
| 質問 | Choiceで担当窓口、Noulで返金要求の有無を独立に判定する |
| 結果の使い方 | suggested_queue を保存。精度確認中は候補を隠し、人が確定した final_queue と後から照合する |
| 未判定の扱い | review、confidenceの下限未満、返金要求の確率の上限超過、通信失敗は人の確認待ちにする |
| 評価 | 候補窓口の誤分類率、返金要求の見逃し率、人へ戻す割合、仕分け作業時間を比較する |
提案B:社内検索で、回答に使う資料を選別する
の構成なら、検索で見つかった資料を生成LLMに渡す前にJevを挟みます。アクセス権限、有効期間、参照すべき文書の版は検索側のコードで先に絞ります。その後、質問と一つの資料断片を入力にして、「この断片は質問に答える材料としてどれだけ直接役立つか」を判定します。権限の絞り込みは、権限付きRAGの設計でも詳しく扱っています。
| 項目 | 実装する内容 |
|---|---|
| 質問 | Choiceの候補を direct(具体的な回答材料あり)、partial(一部の論点)、none(材料なし)、unclear(文脈不足)にする |
| 結果の使い方 | direct の資料を優先してLLMへ渡す。根拠が不足するときは追加検索や利用者への確認に進む |
| 最初の検証 | 既存の検索結果を保存したまま、Jevが選んだ資料と、人が必要と判断した資料を比較する |
| 評価 | 必要な根拠を落とした割合、不要な断片の混入、最終回答と根拠の対応、追加費用と応答時間を測る |
この設計で分かるのは、渡した断片が問いに役立つかどうかです。一つの断片で none が返っても、社内の資料全体に答えがないとはいえません。また、資料が質問に関連していても、生成した回答の全てが裏付けられるとは限りません。資料の選別と、最終回答の根拠確認を別々に評価します。
提案C:データ取り込み時に、文章と分類の食い違いを拾う
必須項目や日付の形式はコードで検査できても、説明文の意味まで条件式で拾うと複雑になります。たとえば登録カテゴリは「アカウント発行」なのに、説明文は「退職者のアクセスを止めたい」という依頼です。構造上の検査を通った後に、カテゴリ定義と説明文の整合をJevへ尋ねる工程を加えます。自由文から項目そのものを取り出す工程は、LLMによる項目抽出と検証と組み合わせて考えられます。
| 項目 | 実装する内容 |
|---|---|
| 入力と質問 | 登録カテゴリ・説明文・カテゴリ定義を入力し、「カテゴリと依頼内容が整合するか」をChoiceで判定する |
| 選択肢 | consistent(整合)、mismatch(別カテゴリの内容)、insufficient(説明不足) |
| 結果の使い方 | 不一致や説明不足を確認リストへ追加する。原データは残し、修正は担当者が行う |
| 評価 | 確認対象のうち本当に修正が必要だった割合、既知の不一致の検出率、確認作業の増減を測る |
6. 問い合わせ仕分けの構成と、観測用コード
提案Aの最小構成は、既存のフォーム、処理待ちの問い合わせを保存する表、バックグラウンドで判定するプログラム、候補を表示する管理画面です。受信と判定を分けておくと、Jevの応答が遅くても問い合わせ自体は受け付けられます。APIキーはサーバー側に置き、利用者のブラウザには渡しません。
| 処理の順番 | 役割と保存するもの |
|---|---|
| ① 受信・保存 | 問い合わせ参照番号と本文の版を保存し、判定待ちを登録する |
| ② 入力の準備 | 分類に必要な項目を選ぶ。長すぎる入力や必要情報の不足は保留にする |
| ③ Jevへ質問 | モデルの版と質問定義を固定し、分類と返金要求の有無を一度に尋ねる |
| ④ コードで分岐 | 応答の形式・候補・数値を検査し、閾値と業務ルールを適用する |
| ⑤ 候補の記録 | 確率・confidence・候補窓口・使用量・所要時間・エラー種別を保存する |
| ⑥ 人の結果と照合 | 候補を見ずに担当者が確定窓口・返金要求の有無・判定理由を記録し、後からモデル結果と照合する |
次のコードは、①の受付や管理画面までを作るものではなく、③〜⑤を一件ずつ試すためのものです。前掲の jev_request.py と jev_route.py を同じフォルダに置き、架空の本文を保存した ticket.txt で実行します。毎回その入力への新しい応答を使い、担当窓口の候補を記録します。実行するとTypeSafeへ本文を送信し、API料金が発生します。
# jev_shadow.py — 同じフォルダの前掲2ファイルと組み合わせるimport hashlibimport jsonimport sysimport uuidfrom datetime import datetime, timezonefrom http.client import HTTPExceptionfrom pathlib import Pathfrom time import perf_counterfrom urllib.error import HTTPError, URLErrorfrom jev_request import evaluate_message, payloadfrom jev_route import (choose_queue, validate_response, MIN_CONFIDENCE, MAX_REFUND_PROBABILITY)
def observe(ticket_ref, message): started = perf_counter() event = { "event_id": str(uuid.uuid4()), "ticket_ref": ticket_ref, # 個人名を含めない問い合わせ参照番号 "at": datetime.now(timezone.utc).isoformat(), "mode": "observe", # 担当先は変更しない "model_requested": payload["model"], "question_version": "support-v1", "policy_version": "routing-v1", "input_sha256": hashlib.sha256(message.encode()).hexdigest(), "thresholds": {"min_confidence": MIN_CONFIDENCE, "max_refund_p": MAX_REFUND_PROBABILITY}, "status": "pending_review", "suggested_queue": "human_review", "applied": False, } try: response = evaluate_message(message) validate_response(response) event.update( status="evaluated", model_used=response["model"], answers=response.get("answers"), usage=response.get("usage"), suggested_queue=choose_queue(response), ) except (HTTPError, URLError, HTTPException, TimeoutError, OSError, ValueError, RuntimeError) as error: # エラー本文や認証情報は記録しない。候補は人の確認に戻す。 event["error_type"] = type(error).__name__ if isinstance(error, HTTPError): event["http_status"] = error.code event["elapsed_ms"] = round((perf_counter() - started) * 1000, 1) return event
if __name__ == "__main__": # 架空の本文を ticket.txt に保存して実行する例: # python jev_shadow.py T001 < ticket.txt if len(sys.argv) != 2: raise SystemExit("使い方: python jev_shadow.py 問い合わせ参照番号 < 本文ファイル") event = observe(sys.argv[1], sys.stdin.read()) # 観測用の記録。問い合わせ本文は複製しない。 with Path("jev-decisions.jsonl").open("a", encoding="utf-8") as file: file.write(json.dumps(event, ensure_ascii=False) + "\n") print(event["suggested_queue"], "(記録のみ・担当変更なし)")jev-decisions.jsonl には、1行に1件のJSONが追記されます。mode = observe と applied = false は観測だけの結果であることを表します。status = evaluated は、この例で必要な応答項目の検査を通ったという意味で、判断の正しさを保証しません。不正な応答や通信失敗は pending_review とエラー種別を残します。有効な応答でも、確率や候補が分岐条件を満たさなければ human_review になります。
運用版では、この判断記録を として扱える保存先へ移し、入力の参照番号、本文の版、モデル・質問・分岐ルールの版をひも付けます。本文を判断記録へ何度も複製せず、権限を限定した元の保管先から確認できるようにします。コード中の入力の指紋は同じ本文かどうかを照合するためのもので、元の本文を復元する機能ではありません。 入力の指紋は匿名化の代わりにはならないため、判断記録にもアクセス権と保存期間を設定します。
本番へつなぐときに実装する項目
| 条件 | プログラムの動作 |
|---|---|
| 同じ問い合わせが再配送された | 問い合わせ番号・本文の版・判定設定の版を処理キーにし、重複した担当変更を防ぐ |
| 通信失敗・応答の形式不正 | 未判定を保存して確認待ちへ送る。以前の応答を代わりに採用しない |
| 呼び出し回数の制限 | 再試行回数と処理期限に上限を設ける。期限を超えたら確認待ちへ移す |
| 分類やconfidenceが条件を満たさない | 固定の確認窓口へ戻し、本文から自由な転送先を作らない |
| モデルや質問定義を変更した | 同じ評価用問い合わせ群で再検証し、適用する設定の版を更新する |
| 問題が見つかった | 自動反映の設定を切り、候補の記録だけに戻す |
同じ処理が再実行されても担当変更が重複しない性質を と呼びます。問い合わせ処理の状態を保存する表と、担当変更先の仕組みの両方で考える必要があります。Jevの判定が返ったことだけで「業務処理が完了した」とせず、判定済み・反映待ち・反映済みを分けて記録します。
7. 段階的に導入し、効果を確かめる
検証計画の例として、過去の日本語問い合わせを300件ほど用意し、100件を質問や閾値の調整、残り200件を最終確認に使います。件数は設計例で、精度を保証するための必要十分な数ではありません。同じ相談の続きが両方へ混ざらないように分け、窓口と返金要求の有無を人が確認します。曖昧な案件には保留という答えを認めます。 正解ラベルはJevの候補を見せずに付け、返金要求のような少数の分類も件数を確認します。最終確認用のデータで閾値を調整した場合は、別の未使用データで確かめ直します。
候補を表示した状態では、担当者の判断がAIの案に影響される可能性があります。候補を隠した精度比較と、候補を使った作業時間の評価を分けます。後者でも一部を候補なしで再確認し、人とAIの一致だけで正しかったと判断しないようにします。
| 段階 | 作るもの・確認すること | 次に進む条件 |
|---|---|---|
| 手元で比較 | 分類定義、独立に正解を付けた評価用データ、設定の版、集計表を用意。現在のルールや既存LLM分類とJevを同じ入力で比べる | 誤りの種類を把握し、業務側と分類ごとの許容範囲を決められる |
| 候補だけ記録 | 最初は候補を隠して人の確定結果と照合。その後、候補を表示した場合の作業時間・修正率を別に測る | 確認作業を含めた時間と費用に改善があり、許容範囲を満たす |
| 一部だけ自動反映 | 評価を通った窓口・条件だけ反映。返金や曖昧な案件は確認待ちへ送る | 誤分類や確認待ちの増加を検知でき、候補記録だけに戻せる |
集計する値は、少なくとも「自動反映の候補になった件のうち何件が誤分類か」「実際に返金要求がある件を何件見逃したか」「全件のうち何件が人へ戻るか」「仕分けに使う時間と総費用」です。割合には必ず分母の件数を付けます。少数の確認で誤りがゼロだったことから、将来も誤らないとは判断できません。窓口別・文章の種類別に結果を見て、対象を広げます。
8. Jevの料金と速度:費用の試算と評価条件
2026年9月22日確認時、公式のモデル一覧にある jev-1.13.0 の料金は入力100万当たり0.042米ドルで、出力は無料です。単純計算では、質問などを含む課金入力が一件1,000トークンで100万件なら42米ドルになります。これはその条件だけの試算で、再試行、周辺システム、人による確認などの費用を含めていません。公式モデル・料金一覧
速度については、発表資料の比較値を自社の処理時間として扱わないことが大切です。提供元自身が、評価場所や入力の短さ、比較するモデルの設定によって結果が変わることを説明しています。導入を比べるなら、同じ問い合わせ群で分類の正しさ、応答時間、未判定率、一件当たりの費用を測ります。発表資料の評価条件
9. 日本語対応と、導入前に確かめたい限界
返り値の型が決まっていても、分類の中身を誤ることはあります。たとえば許された候補である billing を返しても、実際には技術窓口の案件かもしれません。型が合うという性質だけで、判断の正しさを検証済みにはできません。公式の既知の限界にも、不得意な作業が具体的に示されています。
- 正確な計算、数え上げ、日付の前後比較はコードで行う。
- 無関係な情報を大量に渡さず、判断に必要な入力を選ぶ。
- 入力に混ざる誘導文やへの耐性を、実際の条件で確かめる。
- 長い説明文の生成や、何段階もの推論が必要な作業は、適した処理へ分ける。
日本語の問い合わせで使うなら、日本語で評価する必要があります。公式資料では英語が最も得意で、他の言語は同等の精度ではないとしています。また、jev-latest の指す版は更新されます。検証したモデルの版、質問文、選択肢、分岐条件を一緒に残せば、変更前後の結果を比べやすくなります。対応言語とモデルの版
実際の問い合わせや社内文書を送る前に、送信してよい範囲と利用プランのデータ保存条件を確認します。公式は顧客のリクエスト・応答を学習に使わないと説明していますが、保存しないこととは別の条件です。データを保持しない仕組みは企業向けとして案内されています。初期検証は架空・匿名化した文章で行い、実データに進む際は不要な個人情報を除きます。公式のデータ取扱説明・契約とデータ保持の案内
最初の検証では、通常の問い合わせだけでなく、情報不足、複数の用件、否定表現、分類先を誘導する文も含めます。本番の担当窓口は変えずに候補だけを記録し、候補を見ずに人が決めた結果と比較する方法なら、誤り方を確認できます。正解率だけを見ず、「どの分類を取り違えるか」「確認待ちがどれだけ増えるか」まで見て、使う範囲を決めましょう。
10. ここまでのまとめ
Jevを使うかどうかは、まず「答えの候補や評価基準を先に決められるか」から考えられます。決められるなら、文脈を読む小さな判断を取り出し、その後の処理をコードにつなげる余地があります。判断材料が足りないときの行き先まで設計すると、試した結果を業務の改善につなげやすくなります。
Jevは、選ぶ・段階で評価する・条件を確かめるための道具です。質問の定義、確率の読み方、未判定時の扱いをセットで設計し、手元のデータで効果を測ります。続編は読者リアクションに応じて随時追加していきます。
よくある質問
- Jevは文章を生成するLLMですか?
- TypeSafe AIはJevをSystem Oneモデルと位置付けています。自然言語の入力に対して、事前定義した選択肢や評価段階、真偽の確率を返し、自由な文章や判断理由の文章は生成しません。
- Jevの料金はいくらですか?
- 2026年9月22日確認時、jev-1.13.0は入力100万トークン当たり0.042米ドル、出力は無料です。質問の定義を含む課金入力や再試行で総額は変わります。最新の料金は本文でリンクした公式モデル一覧で確認してください。
- JevをPythonから使うには何が必要ですか?
- 利用可能なTypeSafe AIのアカウントとAPIキーを用意し、評価する入力と質問をAPIへ送ります。記事の例はPython 3.10以降の標準ライブラリを使い、キーは環境変数TYPESAFE_API_KEYから読み込みます。
- Jevのconfidenceが0.9なら、正解率は90%ですか?
- そのようには読めません。ChoiceとScoreのconfidenceは返された確率分布の集中度を要約した値で、個別の判断が正しい確率そのものではありません。
- Jevは日本語の業務で使えますか?
- 公式資料では日本語を含む言語を扱えるとしていますが、英語と同等の精度ではありません。実際の日本語データで誤分類や未判定の割合を測り、使う範囲を決める必要があります。
- Jevの実装は、どの業務から始めるとよいですか?
- 本記事では、問い合わせの担当窓口を候補として記録する構成を提案しています。現在の担当先を維持し、まず候補を見ずに付けた人の判断と比較します。その後に候補表示による時短効果を測り、条件を満たした分類から段階的に自動反映へ進めます。