最近よく聞く「Typesafe AI って何？」「Jev って何？」——ざっくり言うと、AI の出力に型を付けて、プログラムが毎回同じ形で読めるようにする話です。チャットで人と話す分には「なんか返ってくる」で済みますが、アプリやワークフローに AI を組み込むときは、その「なんか」では困ります。ここでは Function Calling との違いや、Jev を試したときの体感（速度・コスト）を、自分の使い所の整理として書きます。
01｜AI の出力に型定義が要る理由
AI は基本、会話型です。何か言ったら何か返ってくる。アプリやワークフローに組み込むとき、この「何か返ってくる」だと使いにくい。
たとえば、ユーザーからの質問を AI に投げて「どの機能の質問か」を分類し、次の処理につなげる——こういうパターンで、JSON で返ってきたり、自然言語で返ってきたりすると、コード側は毎回分岐地獄になります。コードは「よしなに」ができないので、毎回同じ形式で返してくれないとうまく組み込めない。
少しの違いで出力がブレる例（同じ分類依頼・架空の応答）
次の2つは、同じユーザー入力「請求書の再発行をお願いします」に対する、イメージ用の応答例です（実測ログではありません）。
パターン A — JSON だけ返す
{
"intent": "billing",
"confidence": "high"
}パターン B — 前置き付きの自然言語
承知しました。JSON でお返しします。
{"intent": "billing"}
こちらが請求に関するお問い合わせの分類結果です。人間にはどちらも読めますが、パースするコードにとっては別物です。プロンプトで「JSON で返して」と縛っても、B のように余計な一文が付くことがあり、これが「型が要る」理由の入口です。
02｜これまでの定番：Function Calling
そこでこれまでよく使われてきたのが、各社 API の Function Calling（構造化出力に近い機能）です。AI API を呼ぶときに、返してほしい形（スキーマ）も一緒に渡せます。定義した型どおりに返却させやすくなり、変わるのは値だけになるので、コードから毎回安定して answer などを参照できます。
入力
こんにちはスキーマ（例）
{
"type": "object",
"properties": {
"answer": { "type": "string" }
},
"required": ["answer"]
}応答（例）
{
"answer": "こんにちは！"
}プロンプトだけで「JSON で返して」だとダメなのか
ダメ、というよりブレやすい。勝手に「はい、JSON で返します！」のような前置きを付けたり、キー名や余計なフィールドが混ざったりします。AI の気分任せでブレが生じるので、本番のワークフローだけでは不安が残ります。
03｜なぜ型定義が要るのか — カテゴライズとトークン
質問に答える AI ワークフローを作るとき、だいたい次の流れになります。
- ユーザーの質問
- AI でカテゴライズ（どの機能・どのナレッジか）
- その分類に応じた情報だけ AI が参照
- AI が自然言語でユーザーに返信
なぜ一度カテゴライズを挟むか。トークン量の削減のためです。「質問 → 全部の情報を AI が参照して返信」にすると、すごい量のトークンを消費してコストが上がります。
カテゴライズのような軽いタスクは安いモデルで回せるので、
- 先に Claude Haiku でカテゴライズ
- その情報だけを読んで返信を Claude Opus で行う
と、コストが浮きます。基本的に、安いモデルでできることは安いモデルでやる——これは今も有効な設計です。
ここでも出力ブレは効く
カテゴライズ結果が JSON だったり、billing という単語だけだったり、表形式だったりすると、次のステップのコードが壊れます。Function Calling でも型は揃えやすい一方、待ち時間が課題になりやすい、というのが自分の体感です。
これまで辛かったこと — 遅さ
Function Calling でも、質問から「どの機能の話か」をカテゴライズするだけなのに、一度推論してからそれを型に合わせて返すので、待ち時間はチャットしているときと同じくらいに感じることがありました。AI ワークフローとして組んだとき、ステップを細分化すればするほどコストは下がる。でも、その分待ち時間が増える——これが致命的な弱点に感じる場面がありました。
04｜Jev なら — 型定義前提の System One
Jev は、TypeSafe（Typesafe AI）が提供する System One モデルです。Function Calling のように「会話前提だけど後付けで型定義もできるようにしました」という位置づけではなく、もともと決められた型で返すことだけを前提に設計されている、という理解です（詳細は公式ドキュメントを参照）。
自分が試した範囲では、「質問に対する確率を返す」ような Noul（「この文は正しいか」を 0〜1 の確率で返す質問タイプ）だけの用途でも、とにかく速い印象でした。たとえば「大谷翔平は野球選手か」という問いに対し、試したところおおよそ 500ms 前後で確率が返ってきます（環境・問いの内容で変わります）。
AI ワークフローとして組み込んだとき、ステップを細分化しても、Jev なら速くて安い、という体感です。
05｜これから嬉しいこと・難しいこと
嬉しいこと
速い。安い。ワークフローのステップを増やしても、カテゴライズや分岐判定を Jev に寄せやすい。
難しいこと — 閾値をどうする？
「大谷翔平は野球選手か」と聞いても、返ってくるのは確率です。80% 以上なら野球選手として扱う？ 79.9% なら野球選手ではない、とする？ → 閾値をどこに置くかの検証は、地味に難しそうです。ビジネスルールとセットで、ログを取りながら調整する必要がありそうです。