LLMの代わりになる？ 文章を生成しないAI「Jev」を日本語で試してみた

「この投稿はスパムか」「問い合わせをどの担当に回すか」。

AIを使いたくても、回答文まではいらない処理があります。

そういう場面で気になったのが、文章を生成しないAI「Jev」です。状況と質問を渡すと、選択肢やスコア、確率が返ってきます。¹

実際に日本語で12項目をまとめて判定させてみたところ、Playgroundの時間表示は 96ms + 212ms でした。

2026年9月17日の実行画面。2つの時間の内訳は未確認で、通信を含めて手元で測った値ではありません。

速さも気になりますが、それ以上に知りたかったのは、普通のLLMにJSONを返させるのと何が違うのかという点です。

Jevとは？ 文章ではなく、判断を返すAI

Jevは、TypeSafe AIが2026年9月15日に発表したAIモデルです。同社はこの種類のモデルを「System One Model」と呼んでいます。²

自然言語の入力を読んで判断しますが、返信文やコードは生成しません。「どの分類に当てはまるか」「どの程度重要か」といった質問に、あらかじめ決めた型で答えます。¹

返り値は、次の3種類です。

型	何を聞くか	返ってくるもの
Choice	決めた候補のうち、どれか	選択結果、候補ごとの確率、Confidence
Score	定義した段階で、どの程度か	スコア、段階ごとの確率、Confidence
Noul	条件に当てはまるか	Yesの確率を表す0〜1の値

型の仕様は公式ドキュメントに基づきます。Noulには別のConfidenceフィールドはありません。³⁴⁵

たとえば、問い合わせを「料金」「不具合」「使い方」から分類するならChoice、対応の優先度を段階別に評価するならScoreです。返信文まで作ってほしい場合は、文章を生成できるモデルを別に使います。

LLMを丸ごと置き換えるというより、分類や評価だけを任せている処理で、使い分けを検討したくなるモデルです。

日本語で12項目をまとめて聞いてみた

最初に試したのは、この記事の企画です。

Jevについて、仕組みと実際の使用結果を載せた記事を書きたい。では、QiitaとZennのどちらが合うのか。せっかくなので、その判断をJev自身に頼んでみました。

使ったのは公式Playgroundです。2026年9月17日に、モデルを jev-latest にして実行しました。

入力欄は State と Questions に分かれています。⁶

入力	役割	今回入れた内容
State	判断の材料	記事のテーマ、書く予定の内容、目的、想定読者、媒体の説明
Questions	何を判断してほしいか	公開先、技術的な深さ、実用性、想定読者などの12問

渡したのは完成した本文ではなく、「こういう記事を書きたい」という企画です。Scoreを8問、Choiceを4問、1つのリクエストにまとめました。Noulは今回は使っていません。

公開先はQiitaが92%、Zennが8%

結果はこちらです。

Qiitaが92%、Zennが8%。今回は、この結果も参考にQiitaへ投稿することにしました。

技術的な深さのスコアは 1.97 / 2。一方で、「初めてJevを知る人への分かりやすさ」は 1.00 / 2 でした。

ここは少し気になりました。自分ではJevの紹介記事のつもりでも、企画には仕組みや性能の話が多く、初見の人向けというより、ある程度技術を知っている人向けに見えるようです。

もちろん、この入力で評価できるのは企画の傾向までです。公開先の92%も、記事が読まれる確率ではありません。QiitaとZennの説明はこちらで簡略化して与えており、その説明と企画に対する回答です。

Score 8項目の結果をすべて見る

質問	スコア	Confidence
技術的な深さ	1.97 / 2	96%
実用性・検証の重視	1.93 / 2	90%
技術的な分析	1.98 / 2	98%
実装・使い方の重視	1.84 / 2	76%
新しい技術を扱う度合い	1.94 / 2	91%
検索から後で参照される価値	1.86 / 2	79%
初めてJevを知る人への分かりやすさ	1.00 / 2	81%
エンジニアへの関連性	1.98 / 2	97%

筆者のPlayground実行結果。各スコアの範囲は、Questionsで定義した0〜2です。「検索から後で参照される価値」も、実際の検索流入を測ったものではありません。

「1.97点」は、何を計算した値なのか

Scoreでは、評価の段階を日本語で定義します。今回の「技術的な深さ」は、この3段階にしました。

{
  "technical_depth": {
    "type": "score",
    "instructions": "この記事はどの程度、技術的な深さを重視した内容ですか？",
    "criteria": [
      "概要やニュース紹介が中心",
      "実装や仕組みをある程度掘り下げる",
      "仕組み、実装、検証まで深く掘り下げる"
    ]
  }
}

配列の先頭から順に、段階0、1、2です。実行画面で内訳を見ると、次のようになっていました。

段階0が0%、段階1が3%、段階2が97%。Scoreは段階の番号を確率で重み付けした平均なので、表示値で計算すると、こうなります。⁴

0 × 0.00 + 1 × 0.03 + 2 × 0.97 = 1.97

単に「段階2です」で終わらず、どの程度そこに寄っているかが分かります。画面の確率は丸められているため、ほかの項目では手計算と表示値が少しずれる場合があります。

Confidenceは「正解率」ではない

Choiceの結果も、すべてが1つの候補に集中したわけではありません。

記事の種類を聞いた質問では、technical_analysis が52%、hands_on が35%、technical_explanation が13%。この質問のConfidenceは36%でした。

今回の企画には、仕組みの分析と実際の使用例の両方を含めています。用意した分類自体に重なる部分があるので、1つに決まりにくい質問だったとも考えられます。

Confidenceは、モデルが文章で「自信があります」と申告した値ではなく、返された確率分布から計算する統計量です。1つの候補に集まっているか、複数に分かれているかを要約しています。⁷

公開先のChoiceでは、Qiitaの確率が92%、Confidenceが84%でした。選択肢の確率、Confidence、実際の正解率は、それぞれ別のものです。

なぜ、12項目がまとめて返ってくるのか

結果を眺めていると、「技術的な深さを採点し、その点数を見て投稿先を選んだ」と思うかもしれません。

ただし、Jevの仕様はそうではありません。同じStateに対して、各質問を独立・並列に評価します。投稿先のChoiceも、ほかのScoreを経由せず、企画から直接判断しています。⁸

今回の12問のうち4問を抜き出した図。

「先に出た判定を使って、次の判定を変えたい」場合は、最初の結果を次のStateに入れてもう一度呼ぶなど、依存関係をアプリケーション側で作ります。

質問をまとめることと、推論を何段も積み重ねることは別です。また、質問を追加すれば入力トークンも増えます。並列に聞けるからといって、質問の追加が無料になるわけではありません。⁸⁹

普通のLLMにJSONを返させるのとは違う？

ここで気になるのが、「同じようなJSONなら普通のLLMでも返せるのでは？」という点です。

まず、型に沿った出力を返す機能は、Jevだけのものではありません。LLMにもStructured Outputsがあり、スキーマに合うように生成候補を制限できます。OpenAIの説明では、この制御をconstrained decodingと呼んでいます。¹⁰

そのうえで、出力の作り方には違いがあります。

出力処理の概略。OpenAIとTypeSafeの説明に基づきます。¹⁰²

一般的な自己回帰LLMでは、短いJSONでもトークン列として出力を作ります。Jevは自由な文字列の生成を行わず、型付きの判断を出す方式です。TypeSafeは独自のモデルアーキテクチャとparallel samplerを採用したと説明しています。²

観点	LLMのStructured Outputs	Jev
出力の作り方	スキーマに沿うトークン列を生成	型付きの判断と確率を出力
文章やコード	文字列フィールドなどで扱える	生成しない
判断の確率	数値を書かせるだけでは、校正されるとは限らない	判断と確率の校正を目的とした学習を行う
複数の質問	1つの出力にまとめられる	同じStateに対して独立・並列に評価する

LLM側はOpenAIのStructured Outputs、Jev側はTypeSafeの公開仕様に基づく比較です。¹⁰⁸¹¹

なお、JevのAPIも通信上はJSONを返します。「JSONを返すかどうか」ではなく、モデルが自由な出力文字列を生成するかどうかの違いです。¹²

型付きの答えだけが必要な処理なら、この出力方式は魅力的です。一方、モデル内部の層構成などは発表資料からは分からず、「どの処理が何ms短くなったか」まで説明できるわけではありません。

今回の 96ms + 212ms は、表示値を足すと308msです。ただ、内訳は未確認で、繰り返し測った平均でもありません。手元のLLMと同じ条件で速度比較をした結果ではなく、日本語12項目を実行した際の画面記録として見ています。

判断だけでなく、確率も学習する

TypeSafeは、学習手法をRLCD（Reinforcement Learning for Calibrated Decisions）と呼んでいます。判断に加え、その確率が実際の正しさと対応するように学習するものです。¹¹

たとえば、80%と予測した事例を多数集めたとき、おおむね80%が正解になる。これが、確率が校正されているという考え方です。

これが自分の用途でも成り立つなら、判断が割れたものを確認待ちにし、別のモデルや人に回す設計がしやすくなります。ただ、今回の投稿先選びには唯一の客観的な正解がないため、この実験だけでは校正の良し悪しは評価できません。

公式の「193.6倍高速」は、何を比べた結果か

公式の速度・価格の数字も、気になるところです。

TypeSafeは、4つの業務ワークフローでの評価を公開しています。対象は、セキュリティインシデント対応、エージェントの実行ログの確認、請求書処理、顧客対応です。¹³

出典：TypeSafe AI公式発表。Jevの位置に赤枠が付いた図を掲載しています。

縦軸が精度、横軸が1ワークフロー当たりのコストです。横軸は対数目盛で、菱形はワークフロー、丸はプロンプトで処理した結果を表しています。

この図では、Jev、Terra、Sonnet 5の菱形が近い精度の位置にあり、Jevは低コスト側に離れています。ただし、これは上の4つのワークフローでの比較です。

参照回答も、人間が付けた唯一の正解ではありません。GPT-6 AstraとClaude Fable 5.1をhigh thinkingで動かした回答の平均を使っています。比較対象のモデルは、各社のデフォルトの推論設定です。¹³

「193.6倍高速」「444.6倍安価」という公表値も、このワークフロー評価に由来します。TypeSafeは、実運用で得られる改善の上限寄りだろうと説明し、評価用ワークフローの作成に自社のモデル開発チームが関わったことにも触れています。²

単純なラベル分類と比較するときに確認したい条件

公式の比較では、LLM側にも判断の確率分布を返させるラッパーを使っています。そのため、LLMにラベルだけを短く返させる実装よりも、出力の負担が大きくなる可能性があります。TypeSafeも、この点を比較条件として説明しています。²

自分の用途で比べるなら、入力、欲しい出力、許容できる誤判定率をそろえて、待ち時間とコストを測りたいところです。

料金は入力100万トークン当たり0.042ドル

2026年9月18日に確認した公表料金では、入力100万トークン当たり0.042ドルで、出力は無料です。⁹

仮に、1回の課金対象入力が1,000トークンなら、計算は次のようになります。

1回    : 1,000 / 1,000,000 × $0.042 = $0.000042
10万回 : $0.000042 × 100,000       = $4.20

今回の日本語12問が1,000トークンだった、という意味ではありません。実際の課金対象トークン数は、APIの usage で確認できます。¹²

「型エラー0%」でも、判断は間違える

公式発表には、ツール呼び出しエラーを比較したグラフもあります。

公式のツール呼び出しエラー率の図を見る

出典：TypeSafe AI公式発表。

Jevの0%は、出力スキーマに適合する設計に基づく値で、TypeSafeは実測値ではないと明記しています。「判断を一度も間違えない」という意味ではありません。比較対象側も同じ質問条件でそろえた実験ではありません。²

今回なら、qiita と zenn 以外の未定義の答えが出ないことと、選んだ投稿先が本当に目的に合うことは別です。通信エラーや認証エラーがなくなるわけでもありません。¹²

LLMの代わりに使うなら、まずどこか

私が試したいのは、開発しているDiscord Botの判定処理です。

投稿回数や投稿間隔は、コードで集計できます。一方で、「このリンクは質問への回答なのか、宣伝禁止の場所での宣伝なのか」は、投稿だけでなく前後の会話やサーバールールも見たいところです。

そのような部分なら、対象の投稿、必要な範囲の会話、チャンネルの用途、ルールをStateに入れ、何を判定したいかをQuestionsで指定する使い方が考えられます。

ここでJevに期待するのは、自然言語を読まないと決めにくい部分の判定です。回数や時間の計算、処理を実行してよい条件、失敗時の扱いまでAIに任せる必要はありません。

最初から投稿の削除まで自動化するより、まずは判定ログを残し、人の判断と比べるところから試したいと思っています。今回実行したのは記事企画の12問で、Discordでの性能を検証したわけではありません。

また、「Jevか、AIエージェントか」の二択でもありません。LangChainの公式ブログには、Jevをエージェント内の分類処理に組み込む例が掲載されています。文章生成をLLM、特定の判定をJevに分担させる構成も考えられます。¹⁴

日本語と苦手な処理は、用途ごとに確かめたい

今回の日本語入力には、企画の内容を踏まえた結果が返ってきました。ただし、公式のModelsページでは、英語を主な学習言語とし、現状では英語で最もよく動作すると説明しています。日本語の1例が動いたことと、日本語で十分な精度があることは別です。⁹

さらに、Jev 1.13の制約をまとめた公式ページでは、細かな数値比較や計算、日付の扱い、悪意ある入力などに弱さがあるとされています。型が守られていても、入力の意味を誤って判断する可能性は残ります。¹⁵

自分のBotで使うなら、普通の会話だけでなく、引用された宣伝文、冗談、ルールの境界にある投稿なども試したいところです。

同じ入力を繰り返した際の再現性も気になります。公式の反復実験では一部のNoulの確率に小さな変動が報告されており、「同じ入力ならすべての数値が常に完全一致する」とは見ていません。¹⁶

同じ入力を手元で試す

今回使ったStateとQuestionsの全文を載せておきます。Playgroundに貼り付けるか、JSONファイルに保存してPython SDKから呼び出せます。⁶¹⁷

まずは投稿先のChoiceだけに絞って、媒体の説明や記事の目的を変えてみるのも面白そうです。

{
  "publishing_platform": {
    "type": "choice",
    "instructions": "この記事の内容、目的、技術的な深さ、実装や検証の量、想定読者を総合的に考えて、公開先として最も適している媒体を選んでください。",
    "criteria": {
      "qiita": "Qiita。具体的な技術解説、実装例、検証、トラブルシューティングなど、実務や開発に直接役立つ技術記事との相性が良い。",
      "zenn": "Zenn。技術的な深掘り、設計思想、考察、個人の開発経験を含む記事や、体系的な技術解説との相性が良い。"
    }
  }
}

criteria のキーが選択肢で、値がその説明です。候補は開発者が定義します。³

Choiceの criteria はオブジェクト、Scoreの criteria は配列です。同じ形ではない点に注意してください。以下の全文には、実行時と同じ12問を入れています。

state.json：今回使った記事企画の全文

state.json

{
  "article": {
    "topic": "新しいAIモデルJevについて、実際に使用しながら仕組み、性能、LLMとの違い、向いている用途を解説する技術記事",
    "content": [
      "Jevとは何か",
      "Noul、Choice、Scoreの仕組み",
      "一般的なLLMとの違い",
      "高速な理由",
      "公式ベンチマークの確認",
      "実際にJevを使った検証",
      "Discordのスパム判定への利用例",
      "得意な用途と苦手な用途"
    ],
    "purpose": [
      "日本のエンジニアにJevを知ってもらう",
      "ニュースの紹介だけでなく実際の検証結果を載せる",
      "技術的な仕組みまで掘り下げる",
      "検索から継続的に読まれる記事にする",
      "できるだけ多くの技術者に読んでもらう"
    ],
    "target_readers": [
      "AIやLLMに興味のあるエンジニア",
      "バックエンド開発者",
      "AIをソフトウェアに組み込みたい開発者"
    ]
  },
  "platforms": {
    "qiita": "日本の技術者向け情報共有サービス。実装例、検証、技術解説、トラブルシューティングなどの記事が多い。",
    "zenn": "日本のエンジニア向け技術情報共有サービス。技術解説、開発経験、考察、体系的な記事などが投稿されている。"
  }
}

questions.json：Score 8問・Choice 4問の全文

questions.json

{
  "technical_depth": {
    "type": "score",
    "instructions": "この記事はどの程度、技術的な深さを重視した内容ですか？",
    "criteria": [
      "概要やニュース紹介が中心",
      "実装や仕組みをある程度掘り下げる",
      "仕組み、実装、検証まで深く掘り下げる"
    ]
  },
  "practicality": {
    "type": "score",
    "instructions": "この記事はどの程度、実用的な実装や検証を重視していますか？",
    "criteria": [
      "概念やニュース紹介が中心で、実用的な検証は少ない",
      "概念説明と実用的な検証をどちらも含む",
      "実際の利用例や検証を強く重視する"
    ]
  },
  "analysis_depth": {
    "type": "score",
    "instructions": "この記事はどの程度、技術的な考察や分析を重視していますか？",
    "criteria": [
      "事実や機能の紹介が中心",
      "事実紹介に加えて一定の考察を含む",
      "仕組みや性能の理由まで深く分析する"
    ]
  },
  "implementation_focus": {
    "type": "score",
    "instructions": "この記事はどの程度、実装や具体的な使い方を重視していますか？",
    "criteria": [
      "実装要素はほとんどない",
      "一部に実装例や利用例を含む",
      "実装や利用例が記事の重要な要素になっている"
    ]
  },
  "novelty": {
    "type": "score",
    "instructions": "この記事はどの程度、新しい技術や新しい情報を扱っていますか？",
    "criteria": [
      "広く知られた既存技術が中心",
      "比較的新しい技術や情報を含む",
      "登場したばかりの新しい技術や情報が中心"
    ]
  },
  "search_value": {
    "type": "score",
    "instructions": "この記事はどの程度、検索から継続的に読まれる価値がありますか？",
    "criteria": [
      "一時的なニュース性が中心",
      "一定期間は参考になる",
      "後から検索しても技術資料として参考になりやすい"
    ]
  },
  "beginner_accessibility": {
    "type": "score",
    "instructions": "この記事はどの程度、Jevを知らない読者にも理解しやすい内容ですか？",
    "criteria": [
      "前提知識が多く、詳しい読者向け",
      "ある程度の技術知識があれば理解できる",
      "Jevを知らない読者でも理解しやすい"
    ]
  },
  "engineer_relevance": {
    "type": "score",
    "instructions": "この記事はどの程度、ソフトウェアエンジニアにとって直接役立つ内容ですか？",
    "criteria": [
      "一般的な読み物としての要素が強い",
      "エンジニアにも参考になる",
      "開発や技術選定に直接参考になる"
    ]
  },
  "article_style": {
    "type": "choice",
    "instructions": "この記事の性質として最も近いものを選んでください。",
    "criteria": {
      "technical_news": "新しい技術やサービスを紹介するニュース・速報寄りの記事",
      "technical_explanation": "技術の仕組みや特徴を整理して解説する記事",
      "hands_on": "実際に使った結果や手順を中心にした検証・ハンズオン記事",
      "technical_analysis": "仕組み、性能、設計思想などを深く考察する技術分析記事"
    }
  },
  "primary_value": {
    "type": "choice",
    "instructions": "この記事が読者に提供する主な価値として最も近いものを選んでください。",
    "criteria": {
      "awareness": "新しい技術の存在や概要を知ること",
      "understanding": "技術の仕組みや特徴を理解すること",
      "practical_use": "実際の開発や導入で使える知識を得ること",
      "evaluation": "その技術がどこまで使えるか、長所や制約を判断する材料を得ること"
    }
  },
  "target_reader": {
    "type": "choice",
    "instructions": "この記事の主な想定読者として最も近いものを選んでください。",
    "criteria": {
      "general_engineers": "幅広いソフトウェアエンジニア",
      "ai_engineers": "AIやLLMを扱うエンジニア",
      "backend_engineers": "バックエンドやシステム設計を担当するエンジニア",
      "technology_enthusiasts": "新しい技術やAIに興味がある技術者"
    }
  },
  "publishing_platform": {
    "type": "choice",
    "instructions": "この記事の内容、目的、技術的な深さ、実装や検証の量、想定読者を総合的に考えて、公開先として最も適している媒体を選んでください。",
    "criteria": {
      "qiita": "Qiita。具体的な技術解説、実装例、検証、トラブルシューティングなど、実務や開発に直接役立つ技術記事との相性が良い。",
      "zenn": "Zenn。技術的な深掘り、設計思想、考察、個人の開発経験を含む記事や、体系的な技術解説との相性が良い。"
    }
  }
}

Pythonから呼び、使用モデルと経過時間を記録する

Python 3.10以降で公式SDKをインストールし、APIキーを環境変数 TYPESAFE_API_KEY に設定します。上のJSONを state.json、questions.json として、コードと同じフォルダーに保存してください。⁶

python -m pip install typesafe-sdk

run_example.py

"""旧記事と同じState / QuestionsをTypeSafe APIへ送るサンプル。"""

import json
import os
from pathlib import Path
from time import perf_counter

from typesafe_sdk import RetryPolicy, TypeSafeClient, TypeSafeError


def main() -> None:
    if not os.environ.get("TYPESAFE_API_KEY", "").strip():
        raise SystemExit("環境変数 TYPESAFE_API_KEY を設定してください。")

    base = Path(__file__).resolve().parent
    try:
        state = json.loads((base / "state.json").read_text(encoding="utf-8"))
        questions = json.loads((base / "questions.json").read_text(encoding="utf-8"))
    except (OSError, UnicodeError, json.JSONDecodeError) as exc:
        raise SystemExit(f"入力JSONを読み込めませんでした: {exc}") from exc

    if not isinstance(questions, dict) or not questions:
        raise SystemExit("questions.jsonには空でないオブジェクトを指定してください。")

    # 別のバージョンを試す場合は環境変数で指定できます。
    model = os.environ.get("TYPESAFE_MODEL", "").strip() or "jev-latest"
    try:
        with TypeSafeClient(timeout=30.0, retry=RetryPolicy(max_retries=0)) as client:
            start = perf_counter()
            response = client.system_one(
                state=state,
                questions=questions,
                model=model,
            )
            elapsed_ms = (perf_counter() - start) * 1000
    except TypeSafeError as exc:
        raise SystemExit(f"TypeSafe APIの呼び出しに失敗しました: {exc}") from exc

    # 通信やSDK処理を含む時間です。モデルだけの推論時間ではありません。
    print(f"経過時間: {elapsed_ms:.1f} ms")
    print("実際に使われたモデル:", response.model)
    print("入力トークン数:", response.usage.input_tokens)
    platform = response.choices.get("publishing_platform")
    if platform is None:
        raise SystemExit("publishing_platformのChoiceが回答にありませんでした。")
    print("公開先:", platform.choice)
    print("確率:", platform.probabilities)
    print("Confidence:", platform.confidence)
    print("回答全体:")
    print(response.model_dump_json(indent=2))


if __name__ == "__main__":
    main()

実行コマンドは次のとおりです。

python run_example.py

スクリーンショットはPlaygroundの実行結果です。このAPIコードによる新たな計測結果は掲載していません。コードは公式SDKの同期クライアントと返り値の仕様に合わせた例です。¹⁷¹⁸

このコードでは再試行を無効にし、通信・SDK処理を含む呼び出し時間を測ります。Playgroundの表示値と同じ範囲を測っているとは限りません。

jev-latest は固定のバージョン名ではなく、更新される別名です。2026年9月18日時点の公式ページでは jev-1.13.0 を指していますが、9月17日の実行で使われた具体的なバージョンまでは記録していません。比較を続けるなら、回答に含まれる model と入力・回答を保存しておくと確認しやすくなります。⁹¹⁸

おわりに

Jevを使ってみて面白かったのは、日本語で書いた企画に対して、12項目の評価が選択肢と数値でまとめて返ってきたことです。

もちろん、LLMでも分類や構造化出力はできます。そのうえで、文章を生成せず、判断と確率を返すように作られたモデルには、繰り返し呼ぶ処理で試す価値がありそうだと感じました。

返信文やコードを書いてほしいのか。それとも、次の処理に使う判定が欲しいのか。まずはその違いから、自分のアプリケーションで使えそうな場所を探してみたいです。

2026年9月18日更新：9月17日の実行結果をもとに構成を見直し、構造化出力との違いや利用時に確認したい点を加筆しました。

引用元

1. TypeSafe AI, System One。対象となる処理、入力と出力、生成しないもの。 ↩ ↩²

2. TypeSafe AI, Introducing System One Models & Jev（2026年9月15日）。発表内容、出力方式、公式評価と比較条件。本文の2枚の公式グラフの出典。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

3. TypeSafe AI, Choice。候補の定義と返り値。 ↩ ↩²

4. TypeSafe AI, Score。評価段階と期待スコアの計算。 ↩ ↩²

5. TypeSafe AI, Noul。Yesの確率とConfidenceの扱い。 ↩

6. TypeSafe AI, Quick start。PlaygroundとPython SDKの使い方。 ↩ ↩² ↩³

7. TypeSafe AI, Confidence。確率分布からの計算と解釈。 ↩

8. TypeSafe AI, Introduction。同じStateに対する各質問の独立・並列評価。 ↩ ↩² ↩³

9. TypeSafe AI, Models（2026年9月18日確認）。モデルの別名、公表料金、対応言語。 ↩ ↩² ↩³ ↩⁴

10. OpenAI, Introducing Structured Outputs in the API。スキーマ制約とconstrained decoding。 ↩ ↩² ↩³

11. TypeSafe AI, AI primer。RLCDと確率の校正。 ↩ ↩²

12. TypeSafe AI, API reference。通信上のJSON、usage、HTTPエラー。 ↩ ↩² ↩³

13. TypeSafe AI, Workflow evals。4つのワークフロー、参照回答、評価条件。 ↩ ↩²

14. LangChain, What Is Jev? A Guide to TypeSafe AI’s System One Model。エージェント内の分類処理への組み込み例。 ↩

15. TypeSafe AI, Jev 1.13 jaggedness（2026年9月18日確認）。数値・日付・悪意ある入力などに関する制約。 ↩

16. TypeSafe AI, Parallel questions。質問の一括実行と反復時の変動に関する公式実験。 ↩

17. TypeSafe AI, Python SDK／Sync client／Questions。辞書での質問定義、同期呼び出し、再試行の設定。 ↩ ↩²

18. TypeSafe AI, Answers and responses。回答、使用モデル、トークン数の取得。 ↩ ↩²