02 5層ハーネス理論 — 判断を逃がす場所の全体像

エージェントの作業中に生まれる「小さな判断」を、どこからJevに逃がすことができるかを 5つの層で整理します。各層には公開実装と報告された数値がありますが、すべて独立検証前のものです。

全体像

エージェント（Claude Code・Codex等）は、1つの依頼を終えるまでに大量の小さな判断を回しています:

依頼を受ける → どうするか判断する → ツールを使う → 結果を見て判断する → またツールを使う → … → 完成かどうか判断する

この判断のたびに高価なモデル呼び出しが発生し、ツールの結果はすべてコンテキストに積み上がります。Jevハーネスは、この判断を「作る仕事」と「選ぶ仕事」に分けて、後者だけをJevへ逃がします。

ユーザーの新しい依頼をJevが見て難易度を判定し、モデルを割り当てます。公開されているルーター実装では、判定は4段階（軽い/普通/強い/長時間）で、それぞれHaiku・Sonnet・Opus・Fable（Claude Codeの場合）に割り当たります。

賢い設計が2つあります:

ループ中は選んだモデルを維持 — ツールを1回使うたびに判定するのではなく、依頼の最初に1回だけ判定します
キャッシュ考慮で切替を拒否する — 会話が巨大な場合、モデルを変えるとプロンプトキャッシュが無効化され、節約額より再読込コストが大きくなることがあります。そこで「安いモデルへの切替が得にならない」と判断したら切替えない

公開報告では、Codex向けルーターの実装者が、7日間237ターンの実履歴を再生するバックテストで約60%のコスト削減（推定）を報告しています。Jevの判定コスト自体は1ターンあたり約$0.00003・0.6秒とのことです。

通常の圧縮は、古い履歴を高いモデルに要約させて短くします。しかし要約は情報を落とします。ファイルのパス・エラーの詳細・3時間前に失敗した理由・途中で追加された細かい条件です。落ちた情報で同じ失敗を繰り返す事故が起きます。

Jev方式は発想が逆です。各ツールの呼び出しと結果を「まだ必要か」を問うて分類します:

残ったものは原文なので、要約による情報の欠落が起きません。公開実装（fast-jev-compaction）の報告では、187,635トークン→33,447トークン（約82%削減・1.4秒）の実例があります（実装者報告・独立検証なし）。

⚠ 注意: これは「その時点で持ち越すコンテキスト」の削減率です 「Claude Codeの総利用トークンが82%減る」ではありません。総トークンへの影響は、過去履歴が全体の何%かで変わります（詳しくは効果測定の章）。

MCP 10個・Skill 30個・社内ドキュメント500件を全部接続すると、何もしていないのにツール定義だけでコンテキストを食います。選択肢が多すぎると選択精度も落ちます。

Jevに「今の状況」と「使える候補の一覧」を渡して、今この瞬間に使う価値があるものを数個に絞らせ、高いモデルはその数個だけを見ます。

コードを書いた本人（モデル）が「完成しました」と自己申告するのは信頼できません。従来は別の高価なモデルを呼んで採点していましたが、それも採点のたびに高価な呼び出しです。

Jevを採点役に置き換えると、1判定あたり約0.44秒・$0.00035で採点できます（公開実験の報告）。興味深い設計は、却下されたときの扱いです:

「言い方を変えて通す」を構造で封じる点は、LLM運用における検証設計と共通する思想です。公開実験では、サーバー障害対応タスクで50問中20問→24問成功（ただし問題によっては悪化も報告）という結果があります。

Jevに最終決定権を渡しません:

公式デモでも、確信度と選択確率の両方に0.85以上を要求し、基準未満・存在しない候補・エラー・曖昧な判断は自動実行せず確認に戻します。

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

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