JevでAIエージェントは安くなるのか？モデルルーティングから結果検証まで、総コストを計算する

概要

Jevの1回の呼び出しは非常に安価です。しかし、AIエージェントに低コストの判断モデルを追加したからといって、タスク全体が自動的に安くなるわけではありません。

本当に計算すべきなのは、Jevが一部のリクエストを通常のコードや安価なモデルへ振り分けられるか、メインモデルへ送るコンテキストを減らせるか、結果検証によって無駄な再試行を防げるかです。その一方で、Jev自身の誤判定、レイテンシ、人手による確認、運用・保守にもコストが発生します。

本稿では、モデルルーティング、コンテキスト選別、結果検証という3つの典型的なアーキテクチャを分解し、Jevがどのような場合にエージェントの総コストを下げ、どのような場合には単にAPI呼び出しを1回増やすだけなのかを判断するための、完全な計算方法を示します。

---

AIエージェントのコスト問題は、表面上は「メインモデルが高すぎる」ことに見えます。実際には、ワークフローがタスクの種類を区別していないことが根本原因になっている場合が少なくありません。

「注文状況を確認して」という依頼なら、データベースを1回参照するだけで済むかもしれません。一方、「過去6か月の注文異常の原因を分析して」という依頼では、複数の情報源を統合できる高性能モデルが必要になる可能性があります。また、情報が不足している依頼では、モデルを呼び出すより先にユーザーへ確認する方が合理的です。

すべてのリクエストを同じ高性能モデルへ直接送れば、システムは単純になります。しかし、本来は通常のコードや小さなモデルで処理できる多数のタスクにも、同じ料金を支払うことになります。

Jevは別の考え方を提示します。

Jevは会話や長文生成を目的としたモデルではありません。開発者がstateを渡し、型付きの質問を複数提示すると、JevはChoice、Score、Noulなどの構造化された判断と確率を返します。業務ロジックはその結果に基づき、ツールを呼ぶか、安価なモデルを使うか、高性能モデルへエスカレーションするか、人に渡すかを決めます。TypeSafeはJevを、ソフトウェア内で高速かつ構造化された判断を行うために設計された、最初のSystem Oneモデルと位置付けています。(typesafe.ai)

価格だけを見ると、この判断コストは無視できるほど小さく見えます。

TypeSafeがJevの公開時に示した価格は、入力100万トークン当たり0.042米ドルで、出力トークンは無料でした。同社は通常のエンドツーエンド・レイテンシを70～500ミリ秒とも説明していますが、同時に、これは特定の地域とテスト条件で得られた数字であり、すべての導入環境を代表するものではないとしています。(typesafe.ai)

問題は次の点です。

判断が安いからといって、エージェントのワークフロー全体が安くなるとは限りません。

Jevでコストを下げられるかどうかは、Jev自身の呼び出し単価ではなく、その後の処理が変わるかどうかで決まります。

AIエージェントの実際の請求額は、モデル料金だけではない

エージェントが1つのタスクを完了する際には、少なくとも次の6種類のコストが発生します。

コスト項目	含まれるもの
判断コスト	意図分類、モデルルーティング、リスク判定、ツールが必要かどうかの判断
コンテキストコスト	会話履歴、検索結果、ツール出力、ログ、文書
生成コスト	メインモデルの入力、出力、推論トークン
再試行コスト	モデルのタイムアウト、ツール失敗、形式エラー、再生成
人的コスト	レビュー、修正、例外処理、高リスク操作の承認
誤判定コスト	誤ルーティング、重要情報の欠落、誤操作後の修復

したがって、1タスク当たりのより完全なコストは、次のように表せます。

総コスト
= 判断コスト
+ コンテキスト処理コスト
+ 後続のモデルとツールのコスト
+ 再試行とフォールバックのコスト
+ 人手確認のコスト
+ 誤判定による修復コスト

Jevの呼び出し料金は、通常この総額のごく一部にすぎません。

Jevが本当に削減できる可能性があるのは、その後に発生するコストです。高価なモデル呼び出しを1回省く、不要なコンテキストを送らない、失敗したタスクの再実行を防ぐ、あるいは本当に不確かな案件だけを人に確認させる、といった部分です。

代表的なコスト削減方法は、次の3つに分けられます。

1. 事前ルーティング：先に判断し、その後で何を呼ぶか決める。
2. コンテキスト選別：メインモデルを呼ぶ前に不要な情報を除く。
3. 事後検証：安価なモデルに先に処理させ、検証に失敗した場合だけエスカレーションする。

---

1つ目のコスト削減方法：Jevをメインモデルの前に置き、ルーターにする

最も直接的な構成は次の通りです。

ユーザーのリクエスト
   ↓
Jevが意図、複雑さ、リスクを判断
   ↓
通常のコード / 安価なモデル / 高性能モデル / 人

TypeSafeの公式ルーティングパターンも同じ考え方です。すべてのリクエストを同じLLMへ入れる必要はありません。一部は決定論的なコードへ、一部は専用モデルへ、複雑または高リスクなものは高価なモデルや人へ送れます。(docs.typesafe.ai)

たとえば、カスタマーサポートのエージェントは最初に次のような判断を行えます。

• 単なる注文状況の照会か。
• 返金やチャージバックに関係するか。
• 請求、技術サポート、営業のどこへ送るべきか。
• 人の介入が必要か。
• 本当にフロンティア級の推論モデルが必要か。

Jevが担当するのは、これらの判断だけです。

データベース検索、返金処理、回答生成、人によるチケット対応は、引き続き周辺システムが実行します。

1回のルーティング判断はいくらかかるのか

資料に記録された実際のAPIテストでは、10件のサポートチケットを1回のリクエストにまとめ、各チケットについてルーティング先と人手確認の要否を判定しました。質問数は合計20件です。

• 入力合計：2,571トークン
• 呼び出し時間：約405ミリ秒
• 公開価格での総コスト：約0.000108米ドル
• 1チケット当たりの平均：約0.0000108米ドル
• 同じトークン構成で換算：約100万チケット当たり10.8米ドル

同じ10件を10回の個別呼び出しに分けた場合、合計時間は約3,664ミリ秒でした。主要なルーティング結果は一致した一方、境界的な事例では一部の確率が明確に変動しました。この結果は、バッチ処理がリクエストのオーバーヘッドを大きく減らせることを示しますが、あらゆる業務領域でのルーティング精度を証明するものではなく、高リスクなゲートに同じ閾値を使えることも意味しません。

モデルルーティングの損益分岐点

次のように置きます。

• C_high：高性能モデルを1回呼ぶコスト
• C_low：安価なモデルを1回呼ぶコスト
• C_jev：Jevによる判断コスト
• P_code：通常のコードで完了できるリクエストの割合
• P_low：安価なモデルで完了できるリクエストの割合
• P_error：誤ルーティングによって修復が必要になる割合

すべてのリクエストを高性能モデルへ直接送る場合の期待コストは次の通りです。

C_direct = C_high

ルーティングを追加した後の期待コストは次のようになります。

C_route
= C_jev
+ P_low × C_low
+ P_high × C_high
+ P_error × C_repair

したがって、ルーティングが本当に節約になる条件は次の通りです。

回避できた高性能モデルのコスト
>
Jevのコスト + 誤ルーティングによる修復コスト

Jev自体は安いため、最終的な採算は通常、次の2点で決まります。

1. 実際に高性能モデルを回避できるリクエストはどれだけあるか。
2. 誤ルーティングの結果はどれほど高くつくか。

あくまで説明用の試算

以下は計算の考え方を示すための仮定であり、特定モデルの実価格ではありません。

• 高性能モデル：1回0.01米ドル
• 安価なモデル：1回0.002米ドル
• Jev：1回約0.0000108米ドル
• 総リクエスト数：100,000件

ルーティング後の内訳を次のように仮定します。

• 20%は通常のコードで完了
• 50%は安価なモデルへ
• 30%は高性能モデルへ
• さらに5%は誤判定や失敗により、高性能モデルで1回の修復呼び出しが必要

この場合は次の通りです。

項目	コスト
ルーティングなし：すべて高性能モデルを使用	1,000米ドル
Jevによる100,000回の判断	1.08米ドル
安価なモデル50,000回	100米ドル
高性能モデル30,000回	300米ドル
修復呼び出し5,000回	50米ドル
ルーティング後の総コスト	451.08米ドル

この仮定では、総コストは約55%下がります。

しかし、安価なモデルへ送れるのが10%だけで、90%が結局高性能モデルへ到達し、さらに5%に修復が必要なら、総コストは約971.08米ドルになります。

節約率は約2.9%です。

開発、監視、閾値調整、追加レイテンシまで含めれば、このルーティング層を作る価値がなくなる可能性もあります。

したがって最初に測るべきなのはJevの単価ではなく、次の割合です。

実際のトラフィックのうち、本当に高性能モデルを必要としないものは何%か。

---

2つ目のコスト削減方法：メインモデルへ送るコンテキストを減らす

コンテキストも、エージェントにとって大きなコスト源です。

長時間動作するエージェントには、次のような情報が蓄積します。

• 会話履歴
• 複数回のツール出力
• Bashやビルドのログ
• Webページ本文
• 検索で取得した文章断片
• すでに無効になった計画や中間結果

多くのシステムは、これらをそのままメインモデルへ再送します。現在のタスクで必要なのが一部だけでも、すべての入力トークンに料金がかかります。

Jevをメインモデルの前に置けば、次のような判断に使えます。

• どの検索結果が現在の質問に関係するか。
• どのツール出力が後で必要になる可能性があるか。
• どの過去メッセージに制約や未完了事項が含まれるか。
• どの文章断片にprompt injectionが含まれる可能性があるか。
• どの情報を削除でき、どの情報を要約だけにできるか。

TypeSafeの公式ユースケースマップにも、コンテキスト選択、セマンティック検索、RAG文章の選別、agent harness内のコンテキスト管理が含まれています。(docs.typesafe.ai)

金銭的な効果は、概算で次のように表せます。

コンテキストによる純利益
= 削除したトークン × メインモデルの入力単価
- Jevによる選別コスト
- 情報欠落によって発生した再取得と再試行のコスト

最初の2項は簡単に計算できます。見落とされやすいのは3項目です。

無関係なログを数十行削るのは、通常は明確な利益です。しかし、初期のメッセージに含まれていたユーザーの重要な制約を削除すると、メインモデルが完全に誤った結果を出し、再検索、再呼び出し、あるいは手作業の修正が必要になるかもしれません。

1回のやり直しだけで、それ以前の多くの成功したコンテキスト選別による節約が消える可能性があります。

したがってJevは、何が関連している可能性が高いかを判断する用途には向きますが、唯一の恒久的なメモリ管理者にするべきではありません。実運用システムには少なくとも次が必要です。

• システム指示、ユーザーの必須条件、安全ルールは常に保持する。
• 削除した内容のインデックスまたは原文を保存する。
• 情報不足時に、エージェントが省略した内容を再取得できるようにする。
• 圧縮率だけでなく、後続タスクの成功率で評価する。

コンテキスト圧縮で本当に見るべきなのは、次の合計です。

圧縮後の総トークン
+ 再取得に使ったトークン
+ 情報欠落による再試行トークン

「今回何トークン減らせたか」だけではありません。

---

3つ目のコスト削減方法：安価なモデルを先に使い、Jevで結果を検証する

別の代表的な構成では、Jevに「どのモデルを呼ぶか」を決めさせるのではなく、他のモデルの結果を検査させます。

流れは次の通りです。

安価なモデルが結果を生成
       ↓
Jevが根拠、抽出フィールド、ポリシーリスク、完了度を確認
       ↓
合格：結果を使用
不合格：再試行、高性能モデルへエスカレーション、または人へ渡す

TypeSafeはこの種のパターンをUniversal Verificationと呼んでいます。公式資料には、RAGの引用確認、ツール呼び出しの検査、結果品質の評価、構造化抽出のカスケードなどが含まれています。公式のSDE Cascade例では、「安価なモデルで抽出 → Jevがフィールド単位で検証 → 赤信号が出た場合だけ推論モデルへエスカレーション」という構成を採用しています。ただし、これはベンダーのcookbookに示された結果であり、すべての抽出タスクで同じ割合のコスト削減が得られる証明ではありません。(docs.typesafe.ai)

このカスケードの期待コストは概ね次の通りです。

C_cascade
= C_low
+ C_jev
+ P_escalate × C_high
+ C_failure

最も重要な変数はP_escalateです。つまり、安価なモデルの結果のうち、最終的に高性能モデルへ送る必要がある割合です。

失敗コストを無視すると、カスケードがすべてを高性能モデルへ直接送るより安くなる条件は次の通りです。

P_escalate
<
1 - (C_low + C_jev) / C_high

先ほどと同じ仮の価格を使います。

• 高性能モデル：0.01米ドル
• 安価なモデル：0.002米ドル
• Jev：約0.0000108米ドル

この場合、エスカレーション率の損益分岐点は約80%です。つまり、最終的にエスカレーションされるリクエストが約80%未満なら、モデル料金だけを見れば「すべて高性能モデル」の基準より安くなる可能性があります。

ただし、これは価格の損益分岐点であり、品質の損益分岐点ではありません。

「高性能モデルに近い」と「高性能モデルと同じ品質」は、別のコスト目標である

事前登録された独立評価では、CLINC150のサンプルでJevから高性能モデルへつなぐカスケードが検証されました。

• 最終精度が高性能モデルより1ポイント低くてもよい場合、Jevがエスカレーションする必要があったのは約22%でした。
• 高性能モデルと完全に同じ精度を求めた場合、すべてのリクエストをエスカレーションする必要があり、実質的に「常に高性能モデルを呼ぶ」構成になりました。

研究者はこの結果を、「安いコストで高性能モデルの品質に近づく」と読むべきであり、「少ない呼び出しで同じ精度を実現する」と読んではならないと強調しています。この実験は200サンプル、1つのデータセット、1つのサービス経路に限られており、他のエージェントへ直接一般化はできません。それでも、品質目標をわずかに上げただけで、エスカレーション率が大きく跳ね上がる可能性があるという重要なコスト構造を示しています。(github.com)

したがって、カスケードの評価で次の数値だけを報告してはいけません。

• 高性能モデルの呼び出しを何回削減したか。
• トラフィックの何%を自動処理したか。

同時に、次も報告する必要があります。

• 自動処理部分の精度。
• 最終的なエンドツーエンドのタスク成功率。
• すべてを高性能モデルへ送る場合と比べて、どれだけ品質が落ちたか。
• 後続処理によって、どのエラーが拡大されるか。

---

複数の質問を1回で聞くことは、リクエスト自体をまとめることより重要な場合が多い

Jevでは、同じstateに対して複数の質問を行い、その回答を並列に返せます。公式ドキュメントは、複雑な判断を原子的な質問へ分解し、複数の判断を曖昧な1問へ詰め込むのではなく、コード側で結果を組み合わせることを推奨しています。(docs.typesafe.ai)

たとえば、次のようにまとめて聞くのではなく、

このサポートチケットをどう処理すべきか。

次の質問へ分解します。

• どの業務キューへ送るべきか。
• 返金を明示的に求めているか。
• チャージバック、法的措置、規制当局に言及しているか。
• どの緊急度に当たるか。
• 人の対応が必要か。
• 高性能モデルを呼ぶ価値があるか。

資料に記録された測定では、1つのstateに対する質問数を1件から8件、さらに32件へ増やしても、ウォームアップ後のレイテンシはおおむね同じ350～400ミリ秒の範囲でした。質問数に応じて入力トークンは増えましたが、ネットワーク往復は線形には増えていません。

したがって、合理的なパターンは次の通りです。

現在のステップで本当に必要な原子的な質問を1回のリクエストでまとめて聞き、判断ごとに別々のAPI呼び出しをしない。

ただし、バッチ処理とは、すべてのユーザー、文書、タスクを巨大な1つのstateへ詰め込むことではありません。サポートチケットの実験でも、配列によるバッチ化で主要な分類結果は保たれましたが、一部の境界的な確率は変動しました。

バッチ戦略は、実際のアプリケーションのデータ分布で検証する必要があります。

---

見落としやすい4つの隠れコスト

1. confidenceは精度ではない

型付き出力は、結果がインターフェースに適合することを保証できます。しかし、業務上の判断が正しいことは保証しません。

独立評価の1つでは、200サンプル中102件でJevのconfidenceがちょうど1.0となり、そのうち6件は誤りでした。また、Jevのconfidenceが、小規模LLMの自己申告confidenceよりも、自身の誤りをうまく順位付けできるとは確認されませんでした。(github.com)

したがって、本番ロジックを次のように単純化してはいけません。

if (confidence === 1) {
  executeDestructiveAction();
}

より安全な方法は次の通りです。

• 特定の判定ルールが必要な場合は、選択肢ごとのprobabilitiesを優先する。
• 自社のラベル付きデータで閾値を選ぶ。
• リスクレベルごとに異なる閾値を使う。
• 支払い、削除、停止などでは人の確認を残す。
• モデルバージョン、確率、最終結果を記録し、ドリフトを監視する。

別の事前登録済み校正評価でも結果は分かれました。CLINC150ではECEが0.0204、Banking77では0.0936で、後者では体系的な過信が見られました。これは、校正がタスクやコーパスに依存し、あるデータセットで調整した閾値を別の業務へそのまま移せないことを示しています。(systemonemodels.org)

2. 誤ルーティングは無料ではない

ルーターが簡単な依頼を高性能モデルへ送った場合、主な損失は節約機会を1回逃すことかもしれません。しかし、複雑な依頼を通常のコードへ誤って送れば、誤回答、重複作業、ユーザー離脱につながる可能性があります。

高リスクなタスクでは、1回の誤判定コストが、関係するすべてのモデル呼び出し料金を上回ることもあります。

そのため、次の4種類のエラーを分けて記録すべきです。

• **誤エスカレーション：**安く処理できた依頼を高性能モデルへ送った。
• **誤ダウングレード：**高性能モデルが必要な依頼を安価な経路へ送った。
• **誤通過：**検証器が不良な結果を見逃した。
• **誤ブロック：**正しい結果を再試行や人手確認へ回した。

単一の総合精度では、この4種類のコストを表せません。

3. レイテンシと失敗もコストである

資料では、ウォーム状態の逐次呼び出しは主に340～450ミリ秒でした。一方、24件の同時リクエストを行ったテストでは、中央値が約1.2秒まで上がり、3件の通信失敗が発生しました。これは特定環境での小規模テストであり、公式サービス全体の可用性を示すものではありません。それでも、本番アーキテクチャで判断層を「決して失敗しないローカル関数」として扱えないことは分かります。

少なくとも、事前に次を決める必要があります。

• タイムアウト時にfail-open、fail-closed、人へのエスカレーションのどれを選ぶか。
• 再試行するか、何回まで行うか。
• Jevが利用できない場合、メインモデルを直接呼ぶか。
• ルーティングサービスの障害でエージェント全体を止めるか。
• p95とp99のレイテンシが製品の対話予算に収まるか。

第三者の事前登録済み評価では、Jevの1回当たり中央値は約0.42～0.44秒でした。ただし研究者は、これは特定のクライアント、ゲートウェイ、地域、負荷におけるサービス経路の値であり、純粋なモデル推論速度ではないと明記しています。(github.com)

4. ラベル付きデータがすでにあるなら、Jevが最安とは限らない

Jevの重要な利点の1つは、コールドスタートです。ラベル付きデータがなくても、自然言語の説明からzero-shotで判断できます。

しかし、安定した業務がすでに多くの人手ラベルを蓄積しているなら、従来型の小規模モデルの方が魅力的な場合があります。

事前登録されたBanking77評価では、10,003件の学習データを使った固定bge-small埋め込みモデルとロジスティック回帰が0.933の精度を達成し、Jevは0.832でした。エンコーダーはテスト環境で約9ミリ秒で動作し、リクエストごとのAPI料金もありません。研究者は、情報条件が異なることも強調しています。エンコーダーは同分布の大規模なラベル付きデータを見ており、Jevはzero-shotで評価されたためです。したがって、これは同条件でのモデル能力比較ではなく、現実的な導入候補の比較です。(github.com)

実務上の発展経路は次のようになります。

段階	評価すべき選択肢
ラベル付きデータがなく、ルールが頻繁に変わる	Jevのようなzero-shot判断モデル
少量のラベル付きデータが蓄積した	Jev + 閾値調整 + 人手確認
ラベルが安定し、大規模データがある	ローカルエンコーダー、分類器、または微調整モデル
ロングテールのタスクが変化し続ける	Jevをフォールバックとして残す

Jevは、コールドスタートを加速する層やロングテール向けの判断層として特に有効かもしれません。しかし、すべての安定した分類タスクの恒久的な最終地点になるとは限りません。

---

本番投入前に、自社の採算をどう計算するか

実際のアプリケーションから過去のタスクを用意し、オフラインで次の3経路を比較します。

A. すべてのタスクを高性能モデルへ送る
B. Jevルーティング → コード / 安価なモデル / 高性能モデル
C. 安価なモデル → Jev検証 → 必要時だけ高性能モデルへエスカレーション

最低限、次の指標を記録します。

指標	答えるべき問い
平均総コスト	成功した1タスクに実際はいくらかかったか。
高性能モデル呼び出し率	Jevは高価な呼び出しを何件、本当に防いだか。
自動処理カバレッジ	人も高性能モデルも不要だったタスクは何件か。
自動処理タスクの精度	自動処理したうち、本当に正しかったものは何件か。
エスカレーション率	カスケードのうち、結局高性能モデルへ行ったものは何%か。
再試行率	ルーティングや検証の誤りで追加呼び出しが何回発生したか。
人手確認率	人の作業は減ったのか、それとも場所が移っただけか。
p95レイテンシ	ユーザーが実際に体感した末尾レイテンシはどの程度か。
エンドツーエンド成功率	最終品質が基準より下がっていないか。

最も意味のある指標は「Jevの判断精度」ではなく、次です。

成功した1タスク当たりのコスト

判断APIが極めて安価でも、再試行、人手確認、誤実行を増やすなら、エージェント全体の経済性は悪化します。

---

Jevを優先的に試す価値がある条件

次の条件を多く満たすほど、Jevが実用的な価値を生む可能性は高くなります。

• リクエスト量が多く、判断が頻繁に必要。
• タスク境界が明確で、1ステップの意味判断へ分解できる。
• 多くのリクエストを通常のコードや安価なモデルで処理できる。
• 専用分類器を訓練するほどのラベル付きデータがまだない。
• メインモデル呼び出しが判断呼び出しより明確に高い。
• 誤りをエスカレーション、再試行、人手確認で封じ込められる。
• 確率、閾値、最終結果を記録できる。
• 判断基準を素早く追加・変更する必要がある。

反対に、次の状況ではJevを追加することを最初の選択肢にすべきではありません。

• ほぼすべてのリクエストが最終的に高性能モデルを必要とする。
• トラフィックが少なく、APIの節約が開発複雑性に見合わない。
• 多段階推論、算術、日付比較、長文生成が必要。
• 誤判定が不可逆な操作を直接引き起こす。
• 大規模で安定したラベル付きデータがすでにあり、ローカル小型モデルを作れる。
• 信頼できるフォールバックと人手確認の経路を構築できない。
• 公式デモの閾値をそのまま本番へコピーする予定である。

---

結論：Jevが節約するのは判断料金ではなく、その後の仕事である

Jevの1回の呼び出しは確かに安価です。しかし、それ自体がAIエージェントのコスト削減を決めるわけではありません。

Jevの本当の価値は、本来ならすべてを1つの高性能モデルへ送るワークフローを分割できることです。

• 単純なリクエストは通常のコードへ。
• 定型的なリクエストは安価なモデルへ。
• 複雑なリクエストは高性能モデルへ。
• 不確かなリクエストは人へ。
• 冗長なコンテキストは送らない。
• 不良な結果はユーザーへ届く前に止める。

Jevをメインモデルの前に置いても、すべてのリクエストが結局そのモデルへ進むなら、API呼び出しを1回増やしただけです。

高価な呼び出し、コンテキスト量、やり直しを確実に減らせるなら、初めて本当のコストレバーになります。

したがって、問うべきなのは次ではありません。

Jevを1回呼ぶと、どれだけ安いか。

問うべきなのは次です。

この判断の後、システムはどの高価な作業をしなくて済んだのか。

これが、AIエージェントが計算すべき完全なコストです。