LLM を Jev に置き換えたらコストが 39% 下がった
Polylane はオンコール agent の 1 日数千件の小さな判断を LLM から Jev に移した。テキストを生成せず判断だけを返すモデルで、コストは 39% 下がった。
日本語
コピー

私たちの on-call agent は毎日何千もの小さな判断を下している。その判断を LLM から Jev——テキストを生成しないモデル——に移したところ、コストが 39% 下がった。
公開日:2026年9月25日 著者:Vi Tran と Boris Tane 原文リンク:https://polylane.com/blog/we-swapped-our-llms-for-jev/
私たちは 24 時間稼働の on-call agent を作っている。こいつは絶えず判断を下す必要がある。たとえば:
- この問題はどれくらい深刻か?
- この Slack スレッドに自分から介入すべきか?
- この障害は以前にも見たことがあるか?
先週までは、こうしたタスクは LLM が担っていた。今週月曜に Jev へのアクセス権を取得したので、さっそく試し始めた。
Jev とは?
Jev は TypeSafe AI が提供する意思決定モデルだ。テキストを生成する代わりに、型付きの値と較正済みの確率でデータに関する問いに答える。TypeSafe はこれを「賢い if 文」と位置づけ、分類・ルーティング・スコアリングなど、手書きのロジックでは脆すぎる場面で使うものとしている。公式の応答時間は 70〜500 ms、出力トークンは無料。私たちの agent は一日中こうした判断をしているので、そのまま本番環境に投入した。
仕組み
1 つのリクエストは 2 つの部分からなる。state、つまり判断の対象となるテキストまたは JSON と、答えを知りたい questions だ。各問いは 3 つの型のいずれかに属する:
graph TB
S["State: a message, thread, or evaluation case"] --> J["Jev"]
Q["Questions"] --> J
J --> N["Noul<br/>yes/no"]
J --> C["Choice<br/>pick an option"]
J --> R["Score<br/>rate against a rubric"]
style J fill:#d1fae5,stroke:#6ee7b7,color:#065f46
style N stroke:#3b7dd8,color:#2b5fa8
style C stroke:#3b7dd8,color:#2b5fa8
style R stroke:#3b7dd8,color:#2b5fa8
- Noul は
yesの確率を返す。 - Choice は与えられた選択肢から 1 つを選ぶ。
- Score は順序付きの評価基準上で、確率で重み付けした値を返す。
ユースケース 1:ルーティング、つまり agent はいつ応答すべきか?
私たちの agent は Slack と Github に自分から参加する。ユーザーにとって価値のある洞察があれば、Slack メッセージや Github コメントに返信する。ユーザーが要求すれば agent は動かねばならないが、あらゆるイベントに過剰反応するわけにもいかない。これはまさに Jev の Noul の問いが向いている。
flowchart LR
E["New event"] --> M["PR comment<br/>Slack message"]
M --> J["Jev Noul<br/>Triage?"]
J -->|Yes| W["Wake agent<br/>to follow up"]
J -->|No| N["No action"]
style J fill:#77a52d,stroke:#5c8023,color:#ffffff
style W stroke:#77a52d,color:#5c8023
style N fill:#e5e5e8,stroke:#d1d2d6,color:#47484d
- 私たちの agent が提出した PR へのコメント: レビュアーが修正を求めたら agent を起こす。CI のステータス更新や「ありがとう」の一言では起こさない。
- Slack チャンネル: 本当に役に立つとき、たとえば誰かがインフラ関連の質問を直接してきたときにだけ、agent は自分から口を挟む。人間同士が調整しているときは参加しない。
- agent が参加している Slack スレッド: 自分宛てのメッセージには返信し、人間同士の会話は無視し、退出を求められたら退出する。
以下は、agent がとある Slack メッセージにフォローすべきかを判断する Jev リクエストの例だ。
{
"model": "jev-1.13.0",
"state": {
"slack_channel": "#Deployment",
"user_message": "Watch this PR until fully deployed"
},
"questions": {
"respond": {
"type": "noul",
"instructions": {
"question": "Should the agent follow up on this user message?"
}
}
}
}
私たちは Jev を 1 週間ほど動かし、このタスクで以前使っていた LLM と比較した。
図 1. 応答ルーティング:レイテンシと 1,000 回あたりのコスト
| 指標 | DeepSeek V4.1 Flash | Jev |
|---|---|---|
| P90 レイテンシ(ms) | 1,466 ms | 472 ms |
| 1,000 回あたりのコスト(USD) | $0.238 | $0.123 |
ルーティングの P90 レイテンシは 3 倍速くなり、1.5 秒から 500 ms 以内に収まった。コストもほぼ半減している。
ユースケース 2:分類、つまりこの証拠は何を意味するのか?
私たちは、agent が内容を異なるカテゴリに振り分ける必要があるタスクも動かしている。たとえば、与えられた証拠に基づいて、agent はこの問題の調査を始めるべきか、既存の何らかの問題に関連するものとして片付けるべきか、それともすでに解決済みの問題の重複なのか。
Jev の Choice の問いは、私たちが定義した基準に従って、その証拠を 1 つのラベルに変える。次の手はそのラベルが決める。おおよそこうだ:
flowchart LR
I["New incident"] --> E["Evidence from tool calls"]
E --> J["Jev Choice"]
J -->|Same root cause| D["Defer to the original"]
J -->|Related| L["Link both incidents"]
J -->|Independent| N["Investigate on its own"]
style J fill:#77a52d,stroke:#5c8023,color:#ffffff
style D stroke:#77a52d,color:#5c8023
style L stroke:#77a52d,color:#5c8023
style N fill:#e5e5e8,stroke:#d1d2d6,color:#47484d
この方法で 3 つの分類タスクを動かした。いずれも明確な基準を持つ Choice の問いを使い、それぞれ別の LLM を置き換えたので、個別に測定している。
これらのイベントは関連しているか?
新しいインシデントが始まると、agent はそれを既存のインシデントと比較する。同じ根本原因なのか、関連しているのか、それとも無関係なのか? 以下の例は候補を 1 つだけ示しているが、本番の呼び出しでは複数の候補を同じ新しいインシデントと比較する。
{
"model": "jev-1.13.0",
"state": {
"incident": "Checkout cannot authenticate to the database.",
"candidate_0": "Billing cannot authenticate to the same database.",
"evidence": "Both services use a credential revoked at 14:00."
},
"questions": {
"candidate_0": {
"type": "choice",
"instructions": "How is candidate_0 connected to the new incident?",
"criteria": {
"duplicate_same_root_cause": "One underlying problem explains both",
"related": "Distinct problems share a trigger or blast radius",
"independent": "No evidenced connection"
}
}
}
}
このユースケースで Jev に切り替えたところ、P90 レイテンシは 8 倍近く速くなり、2.9 秒から 400 ms 以内に収まった。コストは 27% 減っている。
図 2. インシデントの関連付け:レイテンシと 1,000 回あたりのコスト
| 指標 | GPT-OSS 120B | Jev |
|---|---|---|
| P90 レイテンシ(ms) | 2,859 ms | 373 ms |
| 1,000 回あたりのコスト(USD) | $0.388 | $0.285 |
私たちが提出したこの PR はなぜクローズされたのか?
私たちの agent は開発者に pull request を提出する。マージ率は重要な成功指標の 1 つだ。pull request がなぜクローズされるのかを突き止めなければ、プロダクトを改善できない。
私たちの PR がマージされずにクローズされると、agent はレビューコメント、議論の内容、他の作業への参照を読み、理由を判断する。修正そのものが間違っていた、別の方法で誰かが直した、問題が誤検知だった、PR が長く放置されていた、あるいはその挙動がそもそも想定どおりだった、のいずれかだ。
このシナリオで Jev に切り替えると、P90 レイテンシは約 6 倍速くなり、コストは 17% しか下がらなかった。
図 3. 修正系 PR のクローズ理由:レイテンシと 1,000 回あたりコスト
| 指標 | GPT-OSS 120B | Jev |
|---|---|---|
| P90 レイテンシ(ms) | 2,379 ms | 416 ms |
| 1,000 回あたりコスト(USD) | $0.123 | $0.102 |
この pull request はどれくらい緊急か?
pull request を開発者に渡す前に、agent はそれを並べ替え、深刻度の高い問題を先に持ってくる必要がある。この分類では、agent が根本的な問題を critical から info までの段階で格付けする。評価するのは現在の影響であり、仮定上のリスクではない。
図 4. Autofix の深刻度:レイテンシと 1,000 回あたりコスト
| 指標 | DeepSeek V4.1 Flash | Jev |
|---|---|---|
| P90 レイテンシ(ms) | 1,456 ms | 313 ms |
| 1,000 回あたりコスト(USD) | $0.197 | $0.081 |
ここで Jev に切り替えたことでコストは大きく下がった。DeepSeek V4.1 Flash より 59% 安く、P90 レイテンシは 5 倍近く速い。
分類タスクはすべて Jev のほうが速い。GPT-OSS 120B を置き換えた箇所では、効果は主にレイテンシに出た。DeepSeek V4.1 Flash を置き換えた箇所では、請求額も半分以下になった。
ユースケース 3:並べ替え、つまりこのクラウドリソースはどれくらい重要か?
Polylane を最大限に活かすため、チームは自社のクラウドアカウントを接続する。すべてのクラウドリソースについてコンテキストグラフを構築し、agent がコンピュートノード、データベース、キューなどの関係を素早く把握できるようにする。
プラットフォーム上には、数万ノードを抱える極めて忙しいクラウドアカウントを持つチームがある。サーバー、サンドボックス、データベース、キューはそれぞれがコンテキストグラフのノードだ。どのノードがアプリにとって決定的に重要で、どれが落ちてもほぼ「問題ない」のかを agent が判断できるよう、これらのノードを並べ替える必要がある。
各リソースには Critical、Standard、Low、Minimal のいずれかの優先度を割り当てる。
flowchart LR
C["Cloud account"] --> G["Context graph"]
G -->|Each node + metrics| J["Jev Choice"]
J --> T1["Critical"]
J --> T2["Standard"]
J --> T3["Low"]
J --> T4["Minimal: fine to fail"]
style J fill:#77a52d,stroke:#5c8023,color:#ffffff
style T1 stroke:#77a52d,color:#5c8023
style T2 stroke:#77a52d,color:#5c8023
style T3 stroke:#77a52d,color:#5c8023
style T4 fill:#e5e5e8,stroke:#d1d2d6,color:#47484d
Jev はリソースごとに Choice の問いを評価し、設定、環境、直近のメトリクス、依存関係から判断する。
{
"model": "jev-1.13.0",
"state": {
"instructions": "Assign importance relative to the other resources in this cohort.",
"cohort": [
{
"id": "database-a",
"environment": "production",
"daily_queries": 80000,
"dependents": 6
},
{
"id": "database-b",
"environment": "preview",
"daily_queries": 0,
"dependents": 0
}
]
},
"questions": {
"resource_0": {
"type": "choice",
"instructions": "Assign the importance tier for database-a.",
"criteria": {
"1": "Critical: substantial production traffic or blast radius",
"2": "Standard: active and operationally relevant",
"3": "Low: limited activity or importance",
"4": "Minimal: idle or disposable, without meaningful dependents"
}
}
}
}
並べ替えはまさに Jev の得意分野だ。P90 レイテンシは 10 倍以上速く、5.4 秒から約 0.5 秒に短縮され、コストも 34% 低い。これが最も呼び出し回数の多い判断でもあるため、全体の削減効果は主にここから来ている。
図 5. リソースの並べ替え:レイテンシと 1,000 回あたりコスト
| 指標 | GPT-OSS 20B | Jev |
|---|---|---|
| P90 レイテンシ(ms) | 5,445 ms | 511 ms |
| 1,000 回あたりコスト(USD) | $0.817 | $0.542 |
まとめ
全体として、Jev はレイテンシと 1,000 回あたりの推定コストの両方を大きく下げた。
- P90 レイテンシの低下:4,752 ms --> 508 ms。
- 1,000 回あたりコストの低下:$0.76199 --> $0.46369。
図 6. 完了した呼び出しにおける Jev と LLM の比較 2026 年 9 月 20 日 20:00 から 9 月 24 日 20:00 UTC · LLM 呼び出し 36,664 回と Jev 呼び出し 23,951 回
| 指標 | LLM | Jev |
|---|---|---|
| P90 レイテンシ(ms) | 4,752 ms | 508 ms |
| 1,000 回あたりコスト(USD) | $0.76199 | $0.46369 |
P90 レイテンシは約 89.3% 高速。 4,752 ms から 508 ms へ。
1,000 回あたりコストは 39.1% 低い。 1,000 回あたり $0.76199 から $0.46369 へ。
LLM 呼び出し 36,664 回と Jev 呼び出し 23,951 回で、リソース階層の分類を含む。P90 は概算値、1,000 回あたりコストは完了した呼び出しの平均。
モデル別に見ると、Jev は最速かつ最安だ。DeepSeek V4.1 Flash よりわずかに安く、2 つの GPT-OSS モデルよりはるかに安い。
図 7. モデル別のレイテンシと 1,000 回あたりコスト
| P90 レイテンシ | 1,000 回あたりコスト | |
|---|---|---|
| OpenAI GPT-OSS 20B | 5,445 ms | $0.82 |
| DeepSeek V4.1 Flash | 1,372 ms | $0.51 |
| OpenAI GPT-OSS 120B | 2,255 ms | $0.74 |
| TypeSafe AI Jev | 508 ms | $0.46 |
我々のエージェントが固定の選択肢から選ぶ限り、Jev が今やデフォルトである。移行済みの意思決定はすべて、Jev のほうが速く、安い。