05 効果的な使い方と限界 — 数字の正しい読み方と導入チェックリスト
「数字を混同しない」「キャッシュを壊さない」「まず影で動かす」— Jevハーネスを 安全に試すための原則とユースケース集です。
逆効果になる条件（3つ）
1. キャッシュを壊すと高くなる
履歴を頻繁に書き換えると、そのたびにプロンプトキャッシュが無効化され、削ったトークンより再読込のコストが大きくなることがあります。「20万トークンが3万になったからコストも85%減」ではありません。実際に、履歴の頻繁な書き換えでキャッシュを壊し、月末の請求がほぼ減らなかった実装者の失敗談が公開されています。
2. Jevを外しても結果が同じだった実験がある
ルーティング精度のベンチマーク実験で、Jev+retrieval構成が単一モデルより安く高精度になった一方、Jevを外してretrievalだけの構成でもほぼ同じ結果が出たという報告があります。作者自身が「Jevによる難易度判定に測定可能な追加効果は確認できなかった」と書いています。既存のルールやretrievalで足りているなら、Jevを挟む意味はありません。
3. Jev自身もトークンを使う
判断させるには状態をJevに送る必要があります。fast-jev-compactionでは状態上限25,000・1リクエスト上限30,000トークン程度に制限されています（04章）。Jevは巨大なコンテキストを丸ごと処理する代役ではなく、何を残すか判断するフィルターです。20万トークンの履歴を毎回まるごと投げる設計はできません。
数字の正しい読み方（混同禁止表）
| 数字 | 指すもの |
|---|---|
| 約82%減 | 1回の圧縮後に持ち越すコンテキストの削減率（実装者報告・1実例） |
| 約60%減 | Codexの237ターンを再計算した推定コスト（バックテスト） |
| 26.3%減 | Claude向けモデルルーターの推定コスト（100ケース評価） |
| $0.042/Mtok | Jev自体の入力単価（公式） |
| 約20〜50% | 総トークンへの影響の推定レンジ（未実証） |
⚠ 「82% + 60% = 142%削減」はできません 指標が違うため足せません。圧縮率とコスト削減率は別物です。
総トークンへの影響の見積り方
過去履歴が全体に占める割合で、総トークン削減率は大きく変わります。履歴の82%削減を仮定した場合:
| セッションの種類 | 過去履歴の割合 | 総トークン削減の目安 |
|---|---|---|
| 短い作業 | 約40% | 0〜20%前後 |
| 普通の開発セッション | 約50% | 20〜40% |
| 長時間のAgent作業 | 約60〜70% | 30〜50% |
| ツール結果が大量に溜まる特殊ケース | 70%超 | 50〜60%近く |
長時間・ツール結果が大量に溜まるほど効きます。
効果的なユースケース集
採点役（judge）として
100件のケースを高価なモデルに採点させる代わりにJevへ。公開実験では判定のブレが他モデルより桁違いに小さく（限定条件・5ケース×100回）、1判定約0.44秒・$0.00035という報告があります。
ルーティング・完了判定・guardrail
- 依頼の難易度判定→モデル割当（5層理論第1層）
- 提出前の完成判定（第4層・却下時は再調査を強制）
- 悪用検知・jailbreak判定（公式の位置づけ）
向いている条件 / 向いていない条件
| 向いている | 向いていない |
|---|---|
| 判断回数が多い長時間エージェント作業 | 短く1回きりの作業 |
| ツール結果が大量に溜まる | 履歴が軽い |
| 判断が「選ぶ・採る・分ける」に分解できる | 生成・推論そのもの |
| コストが$課金でキャッシュ効率が効く | 料金でなくレート制限枠の運用 |
導入チェックリスト（shadow運用から）
いきなり本番でモデル選択・圧縮を任せないでください。推奨の導入順序:
- 影で動かす（shadow mode） — Jevは判定するが実際には切替えない・判断のログだけ残す。ルーターの公開実装にはshadowモードがあり、作者も数日間のshadow運用を推奨しています
- ログの違和感確認 — 「もしJevに任せていたら何を選んでいたか」を見て、違和感のある判定がないか確認
- 自分の環境で前後計測 — 同じタスクをJevなし/ありで1回ずつ回し、トークン数だけでなく請求額を比較（キャッシュ破壊の検出は請求側でしか見えない）
- 削減率0.25未満でフォールバック — fast-jev-compactionのコード例では、削減率が不十分なら元の履歴保持や要約へフォールバックする設計が示されています
- 失敗条件を先に書く — 「同じ失敗を2回繰り返したらJev方式を疑う」「請求が減らなければキャッシュ破壊を疑う」など、失敗の観測条件を導入前に決める
💡 Tip: 削る前に何が溜まっているかを見る 次に長いセッションを回したら、終わった後にコンテキストの内訳を確認してください。ファイルの読み込みか・コマンド出力か・テストログか。一番大きいものが、一番削る価値のあるものです。削り方を決める前に、何が溜まっているかを見るのが最初の一手です。
更新と限界の明示
- 本ガイドの数値は2026-09-22時点の公開情報（ベンダー主張・実装者報告・バックテスト推定）です
- 独立検証済みの実測値はまだありません。今後の検証結果で更新します
- 仕様・価格・上限は変わりやすいため、実使用前に公式ドキュメントを確認してください