TypeSafe AIの「Jev」は本番で使えるか。本番環境のログで名寄せを再生して見えた、AI運用の設計課題

こんにちは！株式会社YTAL（ワイタル）です。

TypeSafe AIが、「System One Models」という新しいモデルの系統と、その最初のモデル「Jev」を発表しました。非構造な状態を渡すと、型の決まった判断を確率つきで返す。発表記事の言葉を借りれば「frontier-intelligence function call」です。料金は入力100万トークンあたり$0.042で、出力は無料とされています。

AIを業務に組み込む仕事をしていると、こうした発表を見て最初に考えるのは「で、本番で動いているあの処理に使えるのか」です。そこで発表から間もない2026年9月17日に、実際に試してみました。

先に結論を書きます。

• 今回組んだ設計では、Jevを本番の名寄せにそのまま採用するのは見送りました。
• ただし、これは「Jevは名寄せに向いていない」という意味ではありません。少なくとも、当初「保留が多すぎる」と見えた数字の大きさには、私たちの側の設計、つまり質問の単位や判定をまとめるルールが強く効いていました。コストが下がらなかったのも、Jev側ではなく、保留を戻す処理の区切り方の問題です。
• 実は検証の途中で一度、「Jevの性能では名寄せはまだ厳しい」と読める結論をまとめています。それを公式Cookbookと突き合わせて、自分たちで修正しました。その経緯も含めて書きます。

最初に：「本番環境で」が何を指すか

タイトルに「本番環境」と入れていますが、Jevを本番に導入したわけでも、本番のトラフィックを流したわけでもありません。

「本番の実データと実際の処理結果を相手に、ローカルで再生した」検証です。「本番でJevを使っていたらどうなったか」に近い問いには答えられますが、本番で運用して初めて分かること（障害時の挙動、下流の検索や生成の品質への影響など）は分かっていません。

題材：業務資料から作ったGraphの「名寄せ」

検証の舞台は、弊社で開発している、大手AIエージェントからの利用に特化したナレッジ基盤（一般公開前）の本番環境です。この基盤は業務資料を読み込み、組織・人物・プロジェクト・トピックといったノードからなるGraphを組み立てています。

資料を追加するたびに新しいノードが抽出されるので、必ず名寄せが必要になります。新しく出てきたノードが、既存のどれかと同じものかを判定する処理です。

• 「A社」と「株式会社A」（架空の例）は、おそらく同じ組織
• 「納品」と「納品書」は、名前は似ていても別の概念（業務プロセスと書類）

名前が似ているだけで統合すればGraphの意味が崩れます。逆に慎重すぎれば、同じものが重複したまま残ります。

今回の対象は次のとおりです。

• 資料67件（xlsx 35件、pptx 16件、pdf 9件、docx 7件）
• 名寄せ3バッチで新しく作られたノード525件
• そのうち、本番の名寄せで既存ノードに統合されたもの44件

無作為に抽出した標本ではありません。また人が付けた正解ラベルはなく、比較の基準は「本番の名寄せ処理が実際にどう判断したか」です。本番の判断そのものが正しいとは限らない、という点は最後まで効いてきます。

本番の名寄せは、LLMがツールを使いながら判断するターン形式で動いており、今回の3バッチは3ターンでした。使用量を、そのLLMの公表単価（Standard・短文脈）で換算すると約$0.787320。これは推計で、請求額ではありません。ターン時間の合計は198.695秒で、ツールの実行時間を含みます。

Jevの道具立て

Jevでは、判断の形を「プリミティブ」として指定します。今回使ったのは次の3つです。

• Choice：選択肢の中から1つを選ぶ。選択肢ごとの確率も返る。「該当なし」の選択肢を入れておくことが推奨されている
• Score：順序のある2〜10段階のどこに当たるかを評価する。スコアは各段階の確率で重み付けした平均
• Noul：yes/noの問いに、yesである確率を1つの数値で返す

ChoiceとScoreは、確率の分布がどれだけ一つに集中しているかをconfidence（0〜1）として返します。Noulは別にconfidenceを返さず、yesの確率そのものが確信度の役割を果たします。

confidenceの公式ドキュメントには0.5や0.9といった数値も出てきますが、いずれも処理のリスクに応じた設定例で、たとえば0.9は送金の承認のようなリスクの高い処理に付けられた例です。ドキュメントの主張はむしろ「しきい値は1つの数字ではない」「間違えたときの影響に応じて処理ごとに変える」「保守的に始め、自分のデータで試して調整する」という点にあります。この考え方は、あとの検証で効いてきます。

初版の設計と結果

最初に組んだ設計はシンプルです。

• 新しいノードごとに、既存の候補（最大24件）の名前・別名・種類をstateに入れる
• Choiceで「どの候補と同じか」を、候補＋none（どれとも違う）＋uncertain（判断できない） から1つ選ばせる
• confidenceが0.85以上で候補を選んだら統合、0.85以上でnoneなら別物、それ以外は保留
• 保留になったものは既存の名寄せ処理に回す、というハイブリッド構成を想定

結果は次のとおりです。

本番で統合された44件のうち、Jevも同じ統合をしたのは20件。一方で、本番では別のクラスタとして扱われていたノード同士をJevが統合したものが19件ありました。

ここは読み方に注意が必要です。

• 「44件中20件を再現」は、正解率やrecallではありません。基準にしている本番の判断が正しいとは限らないからです。
• 「本番とは別クラスタの統合19件」は、誤統合とは限りません。Jevの誤りかもしれないし、本番が見逃した重複かもしれない。正解ラベルがない以上、どちらかは判定できません。

保留228件の内訳は、モデルが明示的にuncertainを選んだものが22件、候補を選んだもののconfidenceが足りなかったものが87件、noneを選んだもののconfidenceが足りなかったものが119件でした。

コストと時間は次のとおりです。

• 候補があった423ノードに対して423回のHTTPリクエスト
• 入力765,035トークン、料金は発表記事の単価で換算して約$0.03213147（推計）
• HTTP時間の合計は101.398秒、1リクエストの中央値は約220ms

名寄せの1回分だけを比べれば、Jevの推計料金は本番の既存処理の約4%で、約96%安い計算になります。一方、速度の倍率は出しません。本番側は「ツール実行を含むターン時間の合計」、Jev側は「HTTP時間の合計」で、並列実行したときの実際の待ち時間（wall time）とも違ううえ、処理の区切り方もそろっていないからです。

「単体で96%安い」が、システムでは4.1%高くなる

ここで最初の落とし穴に気づきました。

保留を既存の名寄せ処理に回す構成では、既存処理はバッチ単位で動きます。3バッチのすべてに保留が含まれていたので、保留を含むバッチをまるごと既存処理に戻すと、既存処理は結局3バッチとも全部実行されます。

これは実際にフォールバックを動かした実測ではなく、試算です。それでも言えることがあります。モデル単体の料金が安くても、保留を戻す先の処理の区切り方が変わらなければ、システム全体のコストは下がらない。今回の構成では、試算上、安いモデルを前段に足した分だけコストが増えます。

「単体で約96%安い」は事実ですが、これをそのまま「名寄せのコストを96%削減できる」と言い換えることはできません。

しきい値を動かしても、うまい落としどころはなかった

保留が多すぎるなら、しきい値を下げればいい。初版のconfidenceのしきい値を動かしてみました。

※ 統合件数には、上の2区分のどちらにも数えていないもの（本番でも同じクラスタに属していたもの）を含みます。

しきい値を0.5まで下げると保留は74件まで減りますが、本番とは別クラスタの統合が57件に増えます。0.95まで上げると別クラスタの統合は7件になる代わりに、保留が309件に増えます。単純なトレードオフで、正解ラベルがない以上、どこが「ちょうどいい」のかも決められません。

設計を7通り変えてみた

次に、初版以外に7通りの設計を試しました。各方式とも「0.85」を基準にしていますが、多候補Choiceではconfidence、ペアのChoice・Scoreでは判定ラベルの確率、Noulではyesの確率（0.85以上で「同じ」、0.15以下で「別物」）と、見ている値がそれぞれ違います。数字が同じだからといって判定の厳しさがそろっているわけではない点に注意してください。

※ ペア方式は、各ペアを上記の基準で「同じ／別物／保留」に分け、ノード単位では「1つの候補だけが同じで、他の候補はすべて別物と確定」の場合にのみ統合としています。料金はいずれも発表記事の単価で換算した推計です。

どの方式も、初版を明確に上回りませんでした。 別クラスタの統合を初版と同じ19件以下に抑えるしきい値を方式ごとに探しても、本番の統合の再現が20件を超える方式はありませんでした。

ひとつ興味深かったのは、原文を追加した方式です。

原文を与えると、モデルが「判断できない」と答える回数は22件から5件に減りました。一方で、候補を選んでもconfidenceが0.85に届かないものが増え、保留の合計は228件から262件に増えています。「モデルが情報不足だと答えた」ことと「コード側の保留条件に引っかかった」ことは別の現象で、分けて見なければ改善の方向を見誤ります。

なお、ペア方式は「候補ごとに独立した質問を並べる」形にしていますが、stateには全候補を共有して入れています。後で触れる公式Cookbookの「1回のリクエストに2つの実体だけを入れる」形を忠実に再現したものではありません。

そして、これは私たちが組んだ8通りの設計の範囲での結果です。Jevの性能の限界や、日本語に弱いといったことを示したわけではありません。

一度書いた「Jevは厳しい」を、Cookbookで見直す

ペア方式の結果、たとえばScoreで525件中322件（約61%）が保留、という数字を見て、私たちは一度「Jevの判定では保留が多すぎて、名寄せに使うのはまだ厳しい」と受け取れる結論をまとめました。

その後、TypeSafeが公開している名寄せのCookbook（Knowledge Graph Entity Alignment）を読み込み、自分たちの数字と並べました。

Cookbookの設定は次のようなものです（2026年9月17日時点のページで確認）。

• ビールのカタログ同士から事前に絞り込まれた450ペア
• 各実体は名称・醸造所・種類・アルコール度数という構造化された属性を持つ
• モデルはjev-1.12
• 1回のリクエストのstateには、比べる2つの実体だけを入れる
• 「別の商品」「同じ商品かもしれない関連商品」「同じ商品」の3段階のScoreを使い、0.5と1.5を区切りにして統合・保留・別物に分ける
• 名称・醸造所・種類が一致するかを問う3つのNoulは、保留になったときに確認する人のための補助情報で、振り分けの判定には使わない

結果は統合40件、保留50件、別物360件。**保留率は11.1%**です。ただしこれは「精度88.9%」という意味ではありません。ページには、ベンチマークの正解と照らした全体のprecisionやrecallの集計は載っていません。

そこで、保存してあった自分たちのScoreの応答（jev-1.13.0）を、Cookbookと同じ0.5/1.5の区切りで、ペア単位に集計し直しました。

ペア単位で見ると、保留率は大きく変わりません。もちろんモデルのバージョンも、入力の形も、データもまったく違うので、これで性能が同等だと言えるわけではありません。ただ、「Jevが極端に保留しがち」という見立てとも合いません。

では、約61%という保留はどこから来たのか。原因は2つありました。

1つ目は、しきい値の条件が違ったこと。 保留322件という数字は、Cookbookの0.5/1.5の区切りではなく「判定ラベルの確率が0.85以上か」という、別の条件で出したものでした。同じ保存済み応答でも、この条件ではペア単位の保留が1,897件になります。

2つ目は、ペアをノードにまとめるルール。 候補があるノードは423件で、1ノードあたり平均約12.5件の候補とペアになっています。私たちは「1つの候補だけが同じで、他の候補はすべて別物と確定」の場合にのみ統合とするルールを自作していました。12件のうち1件でも曖昧なペアがあれば、ノード全体が保留になります。

Cookbookと同じ区切りでも、このルールでノード単位にまとめると保留は208件（39.6%）。ペア単位では13.0%だった保留率が、集約ルールを通すだけでノード単位では39.6%まで膨らんでいたことになります。

「Jevの判定は保留が多い」と見えていた数字は、評価の単位と私たちの集約ルールによって大きく膨らんでいた。これが、結論を修正した理由です。ただし、ここで確かめられたのは保留の数え方への影響であり、統合の質がどこで決まっているかまで切り分けたわけではありません。

集約ルールを緩めると

では「他の候補の曖昧さは許し、既知のクラスタのうち1つだけが『同じ』と判定されたら統合する」に緩めるとどうなるか。

保留は6.5〜8.4%減りました。新たに統合されたもののうち約28〜33%は、本番では別クラスタとして扱われていたものです。繰り返しになりますが、これは誤統合率ではありません。そして、この変化がGraphを使った検索や生成の品質にどう効くかは測っていません。

保留を「先送り」する運用も考えた

もう一つ、運用側の工夫も試算しました。noneを選んだがconfidenceが足りないノードは、今回は統合も既存処理への回付もせず、別物として置いておき、次の機会に回す。

この運用だと、初版で既存処理に回す必要があるノードは228件から109件に減ります。

ただし、これは119件を解決したのではなく、重複を解消するタイミングを先送りしただけです。その間Graphには重複が残る可能性があり、あとで再処理するコストも発生し得ます。既存処理を必要なノードだけ部分的に回した場合の総コストも、まだ測っていません。

本番でAIを運用する視点で、持ち帰ったこと

今回の検証から持ち帰ったのは、Jevの評価そのものよりも、本番でAIを運用するときの設計の話でした。

1. モデルの料金と、システムのコストは別物

1回あたり約96%安いモデルでも、保留を戻す先がバッチ単位の既存処理のままなら、全体のコストは約4.1%増える試算になりました。コストを決めていたのは、モデルの単価よりも処理の区切り方です。安いモデルを試すときは、単価の比較と同時に「判断できなかったものを、どの単位で、どこに戻すか」を設計する必要があります。

2. 「保留率」はモデルの性質である前に、設計が出した数字

同じScoreの保存済み応答から、ペア単位では13.0%、ノード単位では39.6%、別のしきい値条件では約61%という保留率が出ました。質問の単位 × 集約ルール × しきい値の掛け算で、数字は大きく変わります。公式ドキュメントが「しきい値は自分のデータで調整する」と書いているのは、まさにこのことだと思います。

3. 本番と比べるだけでは、良し悪しは決まらない

正解ラベルがないため、測れたのは「本番の判断との一致」だけでした。本番とは別クラスタの統合19件が改善なのか劣化なのかも言えません。本番のAI処理を置き換える検証には、小さくても人の手で付けた正解ラベルが要ります。

4. 結論は、検証した範囲でしか書けない

私たちは一度、自分たちの設計の都合で出た数字を、モデルの性能として読みかけました。外部の一次情報（今回はCookbook）と並べ、評価の単位をそろえて見直したことで、それに気づけました。

結論と、次に確かめたいこと

今回の設計のままでは、Jevを本番の名寄せに採用しない。これが現時点の判断です。保留を戻す先の処理の区切り方を変えない限りコストは下がらず、正解ラベルがない状態では統合の質も保証できないからです。

一方で、TypeSafeやJevが名寄せに向いていない、あるいは未成熟だと結論づける根拠は、今回の検証にはありません。 少なくとも保留率の大きさについては、検証する側の評価の単位と集約ルールが強く影響していたことを確認しました。統合の質についてはラベルがないため、モデルと設計のどちらにどれだけ原因があるのかは、まだ分かっていません。

次に確かめたいのは、次のようなことです（いずれも未実施です）。

• Cookbookに近い「1回のリクエストに1ペアだけ」の形での再実行
• 保留になったノードだけを既存処理に部分的に戻せる処理の区切り方と、そのコストの実測
• 小規模でも、人の手で付けた正解ラベルでの評価
• Graphを使った検索・生成の品質への影響の確認

数字を読むときの注意

最後に、この記事の数字の前提をまとめておきます。

• Jevを本番に導入したのではなく、本番の保存済みログ・出力・使用量をもとに、同じ入力をローカルで再生した検証です。
• 対象は資料67件・新設ノード525件で、無作為標本ではありません。人が付けた正解ラベルはありません。
• 「本番の統合を再現」は正解率やrecallではなく、「本番とは別クラスタの統合」は誤統合とは限りません。
• 料金はすべて推計です。既存処理はそのLLMの公表単価（Standard・短文脈）、Jevは発表記事に記載の単価（入力100万トークンあたり$0.042、出力無料）で使用量から換算しており、請求額ではありません。
• 保留を既存処理に戻した場合のコストは試算で、実測ではありません。
• 時間は計測の範囲が異なるため（ツール実行を含むターン時間と、HTTP時間の合計）、速度の倍率は出していません。
• Cookbookとの比較は、モデルのバージョン・入力・データがすべて異なるため、性能の比較ではありません。

新しいモデルが出るたびに「本番で使えるか」を確かめるのは、AIを業務で運用する以上、避けて通れない仕事です。そして今回、その答えはモデルの単価や応答だけでは決まらず、「どう評価し、どこで区切り、判断できなかったものをどこへ戻すか」という設計に大きく左右されました。

「AIの処理を本番に入れたいが、どう評価すればいいか分からない」「新しいモデルに乗り換えるべきか判断したい」といったご相談があれば、ぜひご連絡ください。検証の設計から一緒に考えます。