🔗TypeSafe / Jev

「文章を読んで、はい/いいえ・選択肢・点数のどれかを確率つきで返す」専用のAPI。TypeSafeという会社のサービスで、Jevというモデルが実際に判定する。文章を生成するAIではない(直したいカードの文面そのものを作ってくれる仕組みではなく、「直す必要があるか」のような判定だけを返す)。

本ページの入出力例は、断りが無い限り2026-09-18に実際にAPIを呼び出して得たものをそのまま載せている。「ドキュメント記載」と注記した数値は、公式ドキュメントに書かれているだけで実際に上限まで試したものではない。両者を区別して読むこと。

state(判定対象の文章)には、文字列(§2の例)とJSONオブジェクト(§4の例)のどちらも渡せる。リクエストは"model": "jev-latest"を指定しているが、応答の"model"は毎回"jev-1.13.0"になっている。これはjev-latestが現時点で最新の正式版jev-1.13.0を指す別名だからで、ドキュメントにそう記載がある。

• 公式ドキュメント: https://docs.typesafe.ai
• コンソール(アカウント管理・APIキー発行・課金): https://console.typesafe.ai

🔗1. 何をするものか

普通のチャットAI(ChatGPT・Claudeなど)は文章で答える。TypeSafeのJevは、noul/choice/scoreという3種類の質問(§2)に対して確率つきの判定だけを返す。判定できる質問の形はこの3種類しかない。同じ文章に対して複数の質問を1回でまとめて聞ける(§3)。

🔗2. 3種類の質問と、実際の生の入出力

質問にはtypeという項目があり、3種類のどれかを選ぶ。

🔗2-1. noul(はい/いいえ)

「〜かどうか」を聞く。返ってくるのは「はい」である確率(0〜1)の数字1つだけ。

// リクエスト
{
  "state": "Front: 처음으로\nFrontPron: 처으므로\nBack: 初めて\nExample: 처음으로 만났어요.\nExampleJapanese: 初めて会いました。",
  "model": "jev-latest",
  "questions": {
    "needs_fix": {
      "type": "noul",
      "instructions": "この韓国語Ankiカードには修正が必要な誤りがあるか。FrontPronは見出しFrontの標準発音であるべき欄。",
      "criteria": {
        "true": "発音・訳・例文のいずれかに明確な誤りがある",
        "false": "誤りが無い、または迷う程度"
      }
    }
  }
}

// 応答
{
  "model": "jev-1.13.0",
  "answers": {
    "needs_fix": {
      "type": "noul",
      "noul": 0.72
    }
  },
  "usage": {
    "input_tokens": 419,
    "output_tokens": 21
  }
}

この結果は実際には誤りだった。 처으므로は韓国語の連音規則(終声が次の母音に移る現象)による正しい標準発音で、修正は不要。0.72(72%の確率で修正が要る)という判定は間違っている。原因は、質問文(instructions)に連音規則という判断材料を渡さなかったこと。判断材料を十分に渡すと結果は変わる(下の2-3の例を参照)。

🔗2-2. choice(選択肢から1つ選ぶ)

決まった選択肢の中から1つ選ばせる。返ってくるのは、選ばれた選択肢名と、全選択肢それぞれの確率(合計すると1になる)。

// リクエスト
{
  "state": "お客様メッセージ: 先週注文したスニーカーがサイズ違いで届きました。すぐに交換してほしいです。今日の午後までに返事がないと解約します。",
  "model": "jev-latest",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "どの担当チームが対応すべきか",
      "criteria": {
        "returns": "返品・交換",
        "billing": "支払い・請求",
        "technical": "不具合・技術的な問題"
      }
    }
  }
}

// 応答
{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "returns",
      "confidence": 1.0,
      "probabilities": {
        "returns": 1.0,
        "billing": 0.0,
        "technical": 0.0
      }
    }
  }
}

選択肢に説明文が要らないときは、criteriaの値をnullにしてよい(例: "calm": null)。選択肢は1つの質問につき最大255個まで指定できる(ドキュメント記載)。

🔗2-3. score(順序のある段階を評価する。1〜5段階のような評価はこれ)

「悪い→良い」のような順序のある段階に位置づける。これが「1〜5の評価を確率で量子化する」仕組みそのもの。 段階の数は2〜10個まで指定できる(ドキュメント記載)。

低い順に段階の説明文を並べて送ると、各段階の確率(合計1になる)と、それを加重平均した1つの点数が返る。

// リクエスト
{
  "state": "Front: 열리다\nFrontPron: 열리다\nBack: 開く\nExample: 문이 열렸어요.\nExampleJapanese: ドアが開きました。",
  "model": "jev-latest",
  "questions": {
    "quality_1to5": {
      "type": "score",
      "instructions": "このAnkiカードの品質を5段階で評価する",
      "criteria": [
        "重大な誤り（訳が反対の意味など）がある",
        "明確な誤りがある",
        "軽微な問題がある",
        "問題はないが改善余地あり",
        "完全に正しく自然"
      ]
    }
  }
}

// 応答（実際にAPIが返したまま）
{
  "model": "jev-1.13.0",
  "answers": {
    "quality_1to5": {
      "type": "score",
      "score": 3.59,
      "confidence": 0.66,
      "legend": {
        "0": "重大な誤り（訳が反対の意味など）がある",
        "1": "明確な誤りがある",
        "2": "軽微な問題がある",
        "3": "問題はないが改善余地あり",
        "4": "完全に正しく自然"
      },
      "probabilities": {
        "0": 0.01,
        "1": 0.02,
        "2": 0.05,
        "3": 0.2,
        "4": 0.72
      }
    }
  }
}

確認: 0.01+0.02+0.05+0.2+0.72 = 1.0(合計は確かに1)。scoreは各段階の番号×確率を足したもので、このprobabilitiesをそのまま計算すると 0×0.01 + 1×0.02 + 2×0.05 + 3×0.2 + 4×0.72 = 3.60になる。APIが返したscoreは3.59で、手計算の3.60とわずかにずれている。 表示されたprobabilitiesは小数第2位までの丸めなので、内部的にはもう少し細かい値(例: 0.715など)を使って3.59を計算している可能性が高いが、この差の原因そのものは確認していない。段階は0始まりなので、5段階なら0〜4の範囲になる。「1〜5」として見せたいなら、コード側で+1すればよい。

🔗confidenceの読み方

choiceとscoreにはconfidence(0〜1)という値も付く。「選ばれた選択肢・段階の確率」とは別物で、一致しないことがある。 実際の例:

上の2例はどちらも「選ばれた側の確率よりconfidenceが低い」という点は共通しているが、score例は1位(72%)と2位(20%)の差が大きく、tone例は1位(82%)と2位(18%)の差も大きい(僅差の分布ではない)。「僅差の分布だとconfidenceが下がる」という説明はこの2例には当てはまらず、confidenceが何を根拠に計算されているかはドキュメントからは確認できていない。「confidence単体の意味」は未確認として扱う。

🔗3種類のまとめ

🔗3. 複数の質問を1回でまとめて送る

同じ文章(state)に対して、noul・choice・scoreを混ぜて何個でも質問できる。質問どうしは互いを見ずに、それぞれ独立して判定される(前の質問の答えが次の質問の材料になったりはしない)。

1noul + 2choice + 1scoreの実例:

// リクエスト
{
  "state": "お客様メッセージ: 先週注文したスニーカーがサイズ違いで届きました。すぐに交換してほしいです。今日の午後までに返事がないと解約します。",
  "model": "jev-latest",
  "questions": {
    "is_urgent": {
      "type": "noul",
      "instructions": "このメッセージは緊急性を伝えているか"
    },
    "department": {
      "type": "choice",
      "instructions": "どの担当チームが対応すべきか",
      "criteria": {
        "returns": "返品・交換",
        "billing": "支払い・請求",
        "technical": "不具合・技術的な問題"
      }
    },
    "tone": {
      "type": "choice",
      "instructions": "顧客の口調",
      "criteria": {
        "calm": null,
        "frustrated": null,
        "angry": null
      }
    },
    "urgency_level": {
      "type": "score",
      "instructions": "対応の緊急度",
      "criteria": [
        "急ぎではない",
        "通常対応",
        "本日中の対応が必要"
      ]
    }
  }
}

// 応答
{
  "model": "jev-1.13.0",
  "answers": {
    "is_urgent": {
      "type": "noul",
      "noul": 0.97
    },
    "department": {
      "type": "choice",
      "choice": "returns",
      "confidence": 1.0,
      "probabilities": {
        "technical": 0.0,
        "billing": 0.0,
        "returns": 1.0
      }
    },
    "tone": {
      "type": "choice",
      "choice": "frustrated",
      "confidence": 0.73,
      "probabilities": {
        "calm": 0.0,
        "angry": 0.18,
        "frustrated": 0.82
      }
    },
    "urgency_level": {
      "type": "score",
      "score": 2.0,
      "confidence": 1.0,
      "legend": {
        "0": "急ぎではない",
        "1": "通常対応",
        "2": "本日中の対応が必要"
      },
      "probabilities": {
        "0": 0.0,
        "1": 0.0,
        "2": 1.0
      }
    }
  },
  "usage": {
    "input_tokens": 529,
    "output_tokens": 114
  }
}

構造の対応関係:

🔗4. 複数の対象(カード)を1リクエストにまとめる

「同じ評価をカード5枚に対してかけたいが、そのたびに指示文を送ると入力トークンが増える」という疑問に対して、実際に比較した。

5枚を1つのstate(配列)にまとめ、カードごとに短い質問を1個ずつ(計5問)作って1回で送った場合と、1枚ずつ5回に分けて送った場合の入力トークン合計:

約55%減った((1,812−821)÷1,812)。 ただし理由に注意が要る。

• 減った分の正体は、カードの中身の重複ではない。 1枚ずつ送る側も、1回のリクエストには元から1枚分の中身しか入れていないので、まとめても「カードの中身の重複」は最初から発生していない
• 実際に減っているのは、リクエストの外枠({"state":...,"model":...,"questions":{...}}という構造そのもの)を5回分書く代わりに1回分で済むこと。 外枠を5回分書くと、そのたびにmodelの値やquestionsという入れ物の分だけ余計にトークンを使う
• questionsの中の指示文(instructions)自体は、まとめても1回では済まない。 5枚を判定するには質問を5個作る必要があり、それぞれに指示文を書くので、指示文そのものは5回分そのまま残る
• 今回は指示文を「cards[0]のカードは誤りがあるか」のように短くしたので、外枠を1回で済ませた効果が相対的に大きく出た。指示文が長い(数百行のルールのような)場合は、指示文の重複が支配的になるため、削減幅はこれよりずっと小さくなる(実測していない推測)

実際に送ったリクエスト(わざと2枚に誤り— 訳が反対の意味 — を仕込んだ):

// リクエスト
{
  "state": {
    "cards": [
      {"note_id": 1, "Front": "가다", "Back": "行く", "Example": "학교에 가요.", "ExampleJapanese": "学校に行きます。"},
      {"note_id": 2, "Front": "먹다", "Back": "食べる", "Example": "밥을 먹어요.", "ExampleJapanese": "ご飯を食べます。"},
      {"note_id": 3, "Front": "열리다", "Back": "閉まる", "Example": "문이 열렸어요.", "ExampleJapanese": "ドアが閉まりました。"},
      {"note_id": 4, "Front": "춥다", "Back": "寒い", "Example": "오늘 추워요.", "ExampleJapanese": "今日は寒いです。"},
      {"note_id": 5, "Front": "가르치다", "Back": "習う", "Example": "한국어를 가르쳐요.", "ExampleJapanese": "韓国語を教えます。"}
    ]
  },
  "model": "jev-latest",
  "questions": {
    "card1": {"type": "noul", "instructions": "`cards[0]`のカード: Back・ExampleJapaneseに明確な誤りがあるか"},
    "card2": {"type": "noul", "instructions": "`cards[1]`のカード: Back・ExampleJapaneseに明確な誤りがあるか"},
    "card3": {"type": "noul", "instructions": "`cards[2]`のカード: Back・ExampleJapaneseに明確な誤りがあるか"},
    "card4": {"type": "noul", "instructions": "`cards[3]`のカード: Back・ExampleJapaneseに明確な誤りがあるか"},
    "card5": {"type": "noul", "instructions": "`cards[4]`のカード: Back・ExampleJapaneseに明確な誤りがあるか"}
  }
}

// 応答
{
  "model": "jev-1.13.0",
  "answers": {
    "card1": {"type": "noul", "noul": 0.05},
    "card2": {"type": "noul", "noul": 0.06},
    "card3": {"type": "noul", "noul": 0.94},
    "card4": {"type": "noul", "noul": 0.07},
    "card5": {"type": "noul", "noul": 0.89}
  },
  "usage": {
    "input_tokens": 821,
    "output_tokens": 89
  }
}

わざと誤りを仕込んだ3枚目(열리다=開くなのにBackが閉まる)と5枚目(가르치다=教えるなのにBackが習う)を、それぞれ0.94・0.89という高い確率で正しく検出した。

質問を増やしても速度はほとんど変わらず、増えた質問ぶんのトークン代しかかからない、とドキュメントに書かれている。

🔗5. 料金

2026-09-18時点、コンソールの課金画面で確認した内容:

料金表(ドキュメント記載): 入力100万トークンあたり0.042ドル。出力トークンは無料。

$5でどれだけ呼べるか計算すると、入力トークン換算で約1億1,900万トークンぶん。質問1個だけの単発呼び出し(§2-1の実例、419トークン)で割ると、約28.4万回呼べる計算になる(119,047,619÷419≒284,123回)。この419という数字は「1回のリクエストに質問1個だけを入れた場合」の値で、§3・§4のように複数の質問やカードをまとめて1回のリクエストに詰め込むと、リクエスト1回あたりのトークン数は質問の個数ぶん増える一方、判定1件あたりのコストは下がる(§4で実測)。つまり28.4万回という数字は「質問を1個ずつ、まとめずに呼んだ場合」の目安であり、まとめて呼べばこの回数はもっと増える。カードが未登録なので、5ドルを使い切っても勝手に追加で課金される状態ではない。この5ドルが毎月付与され続けるのか、今回だけのものかは未確認(§10)。

🔗6. 1回のリクエストに入る質問の数・上限

質問の「個数」に上限があるのではなく、文章(state)と全ての質問を合わせたトークン数(文字量に近いもの)に上限がある。 ドキュメントの2箇所に少し違う書き方の数値があり、どちらが実際の上限か記事だけでは確定できないため、両方をそのまま載せる(いずれも実測して上限まで送ってはいない)。

具体的な目安(2つの数値のうち小さい方、32,000トークンを使って計算。64,000トークン側が実際の上限なら、以下の目安はおよそ2倍になる。いずれもドキュメント記載からの計算で、実測はしていない): choiceの255選択肢をフルに使った質問は1問で1,000トークン以上を使うので(§2-2のcriteria欄のような選択肢の説明文が長くなるほど増える)、32,000トークンの枠には数十問しか入らない。scoreの10段階のような小さい質問なら、数百問は同じリクエストに入る計算になる。

🔗7. 学習に使われるか

トグルのようなオン/オフ設定は無い。公式ドキュメントに「Jevは顧客のリクエスト・応答では学習しない」という会社としての方針が明記されている。

原文: "Jev is not trained on customer requests or responses." — Models

原文: "our commitment not to train models on user data" — Legal

訓練の方法そのもの(どんなデータでどう学習させたか)は、公式ドキュメントに記載が無い。 上の2つの引用は「顧客のデータを学習に使わない」という方針の宣言であり、訓練方法の説明ではない。大企業向けには、記録を一切残さない「Zero Data Retention」という別のオプションもある(問い合わせ制、詳細は未確認)。これらは全てTypeSafe社の公表内容であり、こちらで独自に検証した事実ではない。

🔗8. 使い方の型(一般論)

具体的な用途に依らず、ドキュメントが挙げている使い方のパターン:

対応言語は英語が中心で、日本語・韓国語を含む他言語は同等の精度ではないとドキュメントに明記されている。本ページで実際に韓国語のカードを判定した結果は次のとおりで、件数がごく少なく(計7件)、体系的な精度比較はしていない。

🔗9. 現時点での結論

Jevは判定しか返さず、文章そのもの(誤りを直した新しい内容など)は生成しない。 そのため、「文章の誤りを見つけて直す」という作業のうち、「直す」部分は担えない。 使えるとすれば、大量の対象の中から「これは怪しい」というものだけを先に絞り込み、実際に直す作業は別の(文章を生成する)モデルに回す、という前段の判定に限られる。

本ページはAPIの仕組み・料金について実際に呼び出して確認した記録であり(質問1個1回あたりのトークン上限は未確定、§6)、何かに実際に組み込むかどうかはこの記事の時点では決めていない。 ここまでで分かったことは、§5の料金は現状カード未登録で課金が発生しないこと、§4のようにまとめて送れば1件あたりのトークン数は減ること、§8のとおり少ない件数の範囲では韓国語の判定は妥当だったこと。判断材料としてはこれで足りるが、組み込むかどうかの決定と、その先の設計は別途行う。

🔗10. 未確認のこと

• §6の上限(64,000/32,000トークン)を実際に超えて送った場合にどう返ってくるか(エラーの形)
• §2-3でscoreの手計算(3.60)とAPIの返り値(3.59)がずれた原因
• confidenceが具体的にどう計算されているか(選ばれた側の確率と一致しない理由)
• 日本語・韓国語での精度が英語とどの程度違うか(§2-1の1件以外は未検証)
• Zero Data Retentionの申込方法・条件
• この5ドルの無料クレジットが来月以降も繰り返し付与されるか、今回1回限りか
• 他のアカウント(このアカウント以外)でも同じ5ドルの無料枠が付くかどうか

出典: 公式ドキュメント(https://docs.typesafe.ai)、コンソール画面(https://console.typesafe.ai。2026-09-18に本人のGoogleアカウントでログインして確認)。生の入出力例は、断りが無い限り2026-09-18に実際に呼び出して得たものをそのまま掲載している。