Fable5.1・GPT-6 Astraのトークン消費を7割減らせる「Jevハーネス理論」とは

Jevという新しいAIが出ました。

Jevは文章を書きません。コードも書きません。

できるのは3つだけです。

用意された候補から1つ選ぶ。0から1で採点する。そうか、そうでないかを返す。

それだけ。

「それの何が嬉しいの」となりますよね。僕も最初そう思いました。

速さと値段が桁違いなんです。

返ってくるまで0.5秒以下。入力の料金は100万トークンあたり4セント台。しかも出力のトークンは課金されません。

比較すると分かります。上位のモデルは入力が100万トークンあたり10ドル前後です。桁が2つ違う。

CodexやClaude Codeと組み合わせると何が起きるか

ここからが本題の入口です。

Claude CodeやCodexを使っていると、1つの依頼を終わらせるまでに、内部では大量の判断が発生しています。

どのファイルを見るか。原因はどこか。次に何を読むか。このテストは足りているか。もう完成と言っていいか。

これ、全部を高いモデルにやらせています。

Jevハーネスというのは、この判断の部分だけをJevに逃がす設計のことです。

作る仕事と、選ぶ仕事を分ける。

そうすると何が減るか。

高いモデルを呼ぶ回数が減る。次のターンに持ち越すトークンが減る。無駄な再調査が減る。

この3方向から効きます。

今日はここを、数字の出どころまで含めて分解します。

先に、タイトルの「7割」について

盛るつもりはないので、最初に断っておきます。

Jevを入れれば総トークンが一律7割減る、という実測はありません。

公開されている数字は3つあって、全部が別の指標です。

Claude Codeで1回のコンテキスト圧縮で82%削減した実例。Codexのモデル振り分けで約60%のコスト削減を推定したバックテスト。Claude向けのモデル振り分けで26.3%の推定コスト削減。

82%はコンテキストの圧縮率。60%と26.3%はコストです。

足せません。

この記事の「7割級」は、公開されている圧縮率と、モデル選択、ツール選択、検証の置き換えを全部重ねた場合に理論上どこまで届くか、という話です。

計算過程も後で全部見せます。

なぜトークンが膨らむのか

削り方の前に、どこで膨らんでいるかを押さえます。

Claude CodeやCodexは、こういうループで動いています。

依頼を受ける ↓ どうするか判断する ↓ ツールを使う（ファイルを読む、検索する、コマンドを走らせる） ↓ 結果を見て判断する ↓ またツールを使う ↓ … ↓ 完成かどうか判断する

判断のたびに、高いモデルへの呼び出しが発生します。

そして、使ったツールの結果は全部コンテキストに積み上がります。

読んだファイル。検索の結果。コマンドの出力。失敗したテスト。成功したテスト。古いエラー。修正前のコード。修正後のコード。

これを抱えたまま、次のターンに進みます。

つまり、作業が長くなるほど、毎ターンで再送されるトークンが増えていく。

ここが本丸です。

第1層：どのモデルを使うかをJevが決める

一番わかりやすいところから。

電卓で済む仕事にスパコンを使わない

公開されているルーターの実装では、ユーザーの新しい依頼をJevが見て、難易度を判定します。

判定は4段階です。軽い、普通、強い、長時間。

そしてそれぞれに、Claude CodeならHaiku、Sonnet、Opus、Fable。CodexならLuna、Terra、Sol、Astra、という具合にモデルが割り当たります。

具体的にはこうです。

変数名を変えるだけ。ここに最上位モデルは要りません。

普通の機能実装。中間のモデルで足ります。

複雑なデバッグ。ここで上位モデルの出番。

巨大なコードベースを長時間かけて調べる。ここではじめて最上位です。

この判定を、人間ではなくJevが毎ターンやります。

設計が賢いところが2つ

ひとつ目。ツールを1回使うたびにJevに聞くわけではありません。

新しい依頼を受けた最初の1回だけ判定して、そのあとのファイル読み込みやコマンド実行のループ中は、選んだモデルを維持します。

毎回切り替えると、Jev自身のオーバーヘッドが増えますし、動作も不安定になるので。

ふたつ目が、これを知ったとき「そこまで考えるのか」と思ったやつです。

会話がすでに巨大になっている場合、安いモデルに切り替えることを拒否する仕組みが入っています。

理由が面白いんですよ。

モデルを変えると、それまで効いていたキャッシュが無効になります。つまり、巨大な資料をもう一度読み直させることになる。

安いモデルに変えて節約できる額より、キャッシュを捨てるコストのほうが大きくなる場面がある。

だから変えない。

これ、日本ではまだほとんど語られていないと思います。

安いモデルに変えれば必ず得、ではない。

数字はこう出ている

Codex向けのルーターを作った人が、7日間237ターンの実際の履歴を再生したバックテストを公開しています。

全部を最上位モデルに送った場合と比べて、約60%のコスト削減。

Jevの判定自体は1ターンあたり約0.00003ドル、0.6秒でした。

Claude向けのルーターでは、100件のラベル付きケースで評価して、97件が許容できる範囲のモデルに割り当たり、能力不足のモデルを選んだケースは0件。全部を最上位で処理した場合と比べて、推定コストが26.3%減という報告です。

[ここに引用ポスト：Claude向けJevモデルルーターの作者による削減報告]

ここで一番大事な注意

この2つの数字、どちらもコストです。

トークンではありません。

同じ1万トークンを安いモデルに送っても、トークン数は1万のままです。減るのは金額だけ。

なので、トークン削減というテーマで見ると、実はこの層は主役じゃないんです。

主役は次です。

第2層：次のターンに何を持ち越すかをJevが決める

ここが本命です。

要約するのではなく、捨てる

普通のコンテキスト圧縮は、古い履歴を高いモデルに要約させて短くします。

これ、問題があるんですよ。

要約すると落ちるんです。ファイルのパス。エラーの詳細。3時間前に試して失敗した理由。ユーザーが途中で追加した細かい条件。

で、落ちた情報をAIが忘れて、同じ失敗をもう一度やる。

Jevを使った圧縮の実装は、発想が逆です。

各ツールの呼び出しと結果について、Jevに聞きます。

これ、まだ必要ですか。

必要なら原文のまま残す。微妙なら短縮する。不要なら捨てる。

文章を書き直して縮めるんじゃなくて、要らない荷物を捨てる。

だから、残ったものは原文です。要約による情報の欠落が起きません。

実測が強烈です

実際のセッションでの報告がこれです。

187,635トークンが、33,447トークンになりました。

約82%削減。処理時間は1.4秒。

[ここに引用ポスト：fast-jev-compactionの削減実測]

ここも表現に気をつけてください。

Claude Codeの総利用トークンが82%減った、ではありません。

その時点で次に持ち越すコンテキストが82%小さくなった、です。

海外での反応

この実装、Xでけっこう話題になっています。

要約なしで圧縮できるようになった、という紹介。ファイルのパスやエラーや制約を要約で失わずに済む、という点が評価されています。

別の人は、AIのコーディング支援ツールがファイルの読み込み、検索、エラー、テスト結果をノートのように溜め込んでいく問題、という切り口で紹介しています。

さらに別の投稿では、50回ほどツールを使ったあとの圧縮で重要な情報が失われる問題を指摘しています。

[ここに引用ポスト：海外エンジニアによるfast-jev-compactionの紹介]

日本語圏だとまだJev自体の紹介で止まっていますが、海外ではもう組み込む側に回っています。

なぜ82%が、総トークンの82%にならないのか

ここ、記事で一番説明したかったところです。計算を見せます。

Claude Codeの1セッションの総入力トークンを100とします。

その内訳が、新しく必要な情報が40、過去の履歴の再送が60だったとします。

過去の履歴の82%を削れると、

60 × 0.82 = 49.2

なので、100が約51になります。

総入力で約49%削減です。

ここで大事なのが、過去履歴が全体の何%を占めるかで結果が変わることです。

短いセッションで過去履歴が40%しかないなら、40 × 0.82で約33%削減。

長時間のエージェント作業で過去履歴が70%を占めるなら、70 × 0.82で約57%削減。

まとめるとこうなります。

短い作業 0〜20%前後 普通の開発セッション 20〜40% 長時間のAgent作業 30〜50% ツール結果が大量に溜まる特殊ケース 50〜60%近く 1回の圧縮対象だけで見れば 実測82%の例あり

つまり、作業が長いほど効きます。

そして、ここにモデル選択、ツール選択、検証の置き換えを重ねたときに、特定の条件で7割級まで届く可能性がある、というのがこの記事の立場です。

実証されている、ではありません。そこは正直に書きます。

第3層：どの道具を使うかをJevが決める

トークンが膨らむ原因は、履歴だけではありません。

使える道具そのものも膨らみます。

MCPを10個、Skillを30個、社内のドキュメントを500件。全部を接続すると、何もしていなくてもツールの定義がコンテキストを食います。

しかも、選択肢が多すぎると選択の精度が落ちます。

そこでJevです。

今の状況と、使える候補の一覧を渡して、今この瞬間に使う価値があるのはどれかを評価させる。

Jevが数個に絞って、高いモデルはその数個だけを見る。

ここで押さえておきたいのが、100個持てることと、100個読ませることは別だ、という点です。

コンテキストが広いモデルほど、この勘違いが起きます。入るから入れていい、ではありません。

第4層：完成したかどうかをJevが判定する

これが4つ目で、個人的には一番面白い層です。

作った本人に合格を出させない

普通はこうなっています。

高いモデルがコードを書く。テストする。そして自分で「完成しました」と言う。

あるいは、もう1つ別の高いモデルを呼んで採点させる。

後者、けっこうやってる人いると思います。僕もやってました。

でもこれ、採点のためにもう一度高いモデルを呼んでいます。

採点役をJevに置き換えた実験

エージェントの出力を採点する役として、Jevを試した比較実験が公開されています。

結果が衝撃的でした。

限定された条件という前提つきですが、採点の点数のブレが、比較した他モデルより桁違いに小さかった。軽量モデルと比べて数百倍のオーダーで安定していた、という報告です。

平均0.44秒。1回あたり0.00035ドル。

そして費用の比較がこれです。

同じ実験で、Jevの合計が0.34ドル。比較対象の高いモデルは28ドル台。

固定した5件のケースを100回ずつ評価した合否判定では、500回とも人間の評価と一致したとされています。

ただし5ケースです。万能性の証明ではありません。

でも、方向性としてはこうなります。

100回仕事をさせるとして、その100回を高いモデルに採点させる必要はもうないかもしれない。

判定が厳しいだけでは意味がない

もうひとつ、この層で大事な設計があります。

サーバー障害の対応をAIにやらせる研究で、Jevを提出前の判定に使った例があります。

原因を本当に証明できたか。修復できた証拠があるか。

ここで賢いのが、却下されたときの扱いです。

文章を書き直して再提出するのは認められていません。

もう一度調査に戻って、新しい証拠を取ってこないといけない。

言い方を変えて通すのを、構造で封じています。

結果は50問中20問成功から24問成功になりました。ただし問題によっては悪化もしています。

つまり、Jevを付ければ賢くなる、ではありません。

第5層：実行していいかを、コードと人間が決める

最後の層です。ここはJevの話ではありません。

Jevに最終決定権を渡さない、という話です。

公式のデモでも、Jevが次の処理先を選んでも、そのまま実行はしません。候補をあらかじめコード側で制限して、Jevが選んだあとにもう一度チェックします。機密に関わる候補は、そもそもJevに選択肢として渡しません。

層にするとこうです。

高いモデル 実行する Jev 判断する コード 絶対に越えられないルール 人間 不可逆な操作の最終承認

下の2層があるから、上を速く動かせます。

確信が足りないときは動かない

具体的な線引きも公開されています。

Jevの選択について、確信度と、選んだ候補の確率の両方に0.85以上を要求する。基準を満たさない、存在しない候補を返した、エラーが出た、判断が曖昧。こういうときは自動で実行せず、確認に戻します。

Claude CodeやCodexに当てはめるなら、こうなります。

確信度が0.9以上なら自動で安いモデルへ。0.6から0.9なら今のモデルを維持。それ以下なら人間に確認。

Jevが選んだから実行、ではありません。十分に確信があるときだけ自動化する。

逆効果になる条件

ここを書かないと、ただの宣伝になります。3つあります。

1. キャッシュを壊すと高くなる

Codex向けに圧縮の実装を移植した人が、かなり厳しい注意書きを出しています。

実運用には推奨しない。実証実験として扱ってほしい、と。

理由のひとつがキャッシュです。

履歴を頻繁に書き換えると、削ったトークン以上にキャッシュの再計算が発生する可能性があります。

つまり、20万トークンが3万トークンになったからといって、コストも85%減ったとは言えません。

しかも、Jevが不要と判断した情報が、後になって必要になる可能性もあります。

2. Jevを外しても結果が同じだった実験がある

これが一番大事な但し書きかもしれません。

ルーティングの精度を測るベンチマークを使った実験で、Jevとretrievalを組み合わせたルーターが、単一モデルより安く高精度になりました。

ところが、Jevを外してretrievalだけにした構成でも、ほぼ同じ結果が出たそうです。

作者自身が、この実験ではJevによる難易度の判定に測定可能な追加効果は確認できなかった、と書いています。

つまり、既存のルールやretrievalで足りているなら、Jevを挟む意味がない場合もある。

足せば良くなる、ではありません。

3. Jev自身もトークンを使う

当たり前ですが、書いておきます。

判断させるには、状況をJevに送る必要があります。

圧縮の実装では、Jevに渡す状態を最大2万5000トークン程度、1リクエストを最大3万トークン程度に制限しています。

そしてJev自体にも上限があります。1リクエストで最大6万4000トークン、状態は3万2000トークン程度まで。

ということは、Claude Codeの20万トークンの履歴を毎回まるごとJevに投げる設計はできません。ログを分割したり、ツールの結果単位で評価したりする必要があります。

Jevは巨大なコンテキストを丸ごと処理する代役ではなく、巨大なコンテキストの中から何を残すか判断するフィルターです。

ここを間違えると設計が破綻します。

導入するなら、まずこれをやってください

いきなり本番でモデル選択を任せないでください。

影で動かす

公開されているルーターの実装に、影で動かすモードがあります。

Jevは判定します。でも実際には切り替えません。判断の結果だけをログに残します。

作者も、まず数日間これで動かして、Jevがどういう判断をするかをログから確認してから調整することを勧めています。

これ、かなり安全な始め方です。

もしJevに任せていたら何を選んでいたか、だけを記録する。

違和感のある判定が出ていたら、本番に入れる前に気づけます。

自分の環境で測る

もうひとつ、実装によってはルーティングをオンとオフで切り替えて、それぞれのトークン消費を計測できるものがあります。

同じタスクを、Jevなしで1回、Jevありで1回。

これが一番強い検証です。

この記事に書いた数字は、全部よその環境のものです。あなたの仕事で同じ比率になる保証はありません。

だから自分で測ってください。

数字を混同しないための表

最後にこれだけは持ち帰ってください。

約82%減 → Claude Codeの実利用例。1回の圧縮後に持ち越すコンテキスト

約60%減 → Codexの237ターンを再計算した推定コスト

26.3%減 → Claudeのモデルルーターによる推定コスト

$0.042 / 100万トークン → Jev自体の入力単価

約20〜50% → 総トークンについての推定レンジ。未実証

この5つを混ぜなければ大丈夫です。

特に、82%と60%を足して142%削減、みたいな計算はできません。指標が違うので。

結局、Jevハーネスとは何なのか

一文にするとこうです。

CodexやClaude Codeを弱いAIに置き換える技術ではありません。

最強のモデルにやらせる必要のない選択、整理、確認をJevへ逃がして、本当に生成と推論が必要な瞬間だけ計算資源を渡す設計です。

モデルの選択でコストが減る。コンテキストの整理でトークンが減る。ツールの選択で無駄な処理が減る。完成の判定で再推論とやり直しが減る。

1個の技術で7割削るのではありません。小さな無駄を別々に削って、積み上げた結果です。

僕がやらかした話

この記事を書く前に、自分の環境でコンテキストを削る仕組みを試しました。

長いセッションで、確かに履歴は小さくなりました。数字を見て満足しました。

で、月末に請求を見たら、あまり変わってませんでした。

原因はキャッシュでした。

履歴を頻繁に書き換えていたので、そのたびにキャッシュが無効になって、読み直しが発生していたんです。

削ったトークンより、読み直したトークンのほうが多かった。

（コンテキストの長さだけ見て、キャッシュの当たり具合を見ていませんでした）

削減を測るなら、トークンの数だけじゃなくて請求を見てください。そこがズレるなら、キャッシュを壊しています。

今日やること

ひとつだけ。

次にClaude CodeかCodexで長いセッションを回すとき、終わったあとにコンテキストの内訳を確認してください。

何が占めているか。ファイルの読み込みか、コマンドの出力か、テストのログか。

そこで一番大きいものが、あなたにとって一番削る価値があるものです。

全員の答えが同じではありません。フロントを触る人とデータを触る人では、溜まるものが違います。

削り方を決める前に、何が溜まっているかを見る。そこからです。

僕のアカウントではAIの使い方や最新情報を毎日発信しながら、初心者でも日常業務で簡単に扱えるレベルになる方法を無料で教えています。知りたい人はフォローしてもらえると嬉しいです

※料金、上限、仕様は変わりやすいので、実際に使う前に各提供元の公式情報を確認してください。記事内の数値は実装者や提供元の測定によるもので、独立した検証結果ではないもの、バックテストによる推定、限定された条件での実験を含みます。自分の環境で同じ比率になるとは限らないため、導入する場合は必ず前後で計測してください。紹介した実装には、作者自身が実運用を推奨していないものも含まれます。