CodexやClaude Codeを毎日使っていると、同じ作業なのに消費が読めない日が出てくる。「Jev」という名前がトークン削減や高速化の切り札として話題に上がることがあるが、2026年9月26日時点で、その名前に対応する公式ドキュメント・公開リポジトリ・提供元を特定できる一次情報は確認できない。
だから結論は先に置く。名前を探すより、消費の発生源を押さえるほうが確実に効く。トークンは「モデルが賢いかどうか」ではなく、毎ターンどれだけの文脈を作り直して送っているかで決まる。ここを直すと、ツールを1つも増やさなくても消費カーブは変わる。
以下では、確認できる公式仕様と公開ツールだけを使って、削減に効く場面・速度に効く場面・ほとんど変わらない場面を分けて整理する。
この記事で分かること
- 「Jev」という呼称を、実務でどう扱えば安全か
- トークンが膨らむ構造的な原因と、キャッシュが効く条件
- 削減に効く場面／速度に効く場面／変わらない場面の切り分け
- 今日から組める具体的な構成と、その公開元URL
「Jev」という名前をどう扱うか
結論: 出典が特定できない呼称は、手法として評価し、製品として信用しない。
AIコーディング周辺は、特定の設定やラッパー、MCPサーバー、プロンプト運用が口伝で広がりやすい領域だ。名前が先に流通して実体が後追いになるケースもあるし、個人の作業環境の愛称がそのまま外に出ることもある。どちらにしても、検証の入口は同じ。
- 提供元と一次情報（公式サイト、GitHubリポジトリ、ドキュメント）があるか
- 何を減らすと主張しているのか（入力トークン／出力トークン／往復回数のどれか）
- 測定方法が再現できるか（同一タスク・同一モデル・同一リポジトリでの前後比較か）
この3点が揃わない話は、効果があってもなくても再現できない。逆に、次章以降で扱う仕組みは提供元と挙動が公開されているので、自分の環境で測れる。
ここがポイント: 削減できるのは「送り直している文脈」と「無駄な往復」であって、名前のついた魔法ではない。
トークンが膨らむ本当の原因は、文脈の作り直し
結論: 1回のやり取りが重いのではなく、同じ前提を何度も再送しているから重くなる。
エージェント型のコーディング支援は、1つの依頼を数十ターンに分けて進める。ファイルを探し、読み、差分を当て、テストを走らせ、失敗を読み直す。このとき会話履歴とツール出力は積み上がり、次のターンの入力には、それまでの履歴がもう一度乗る。ターン数が伸びるほど、入力側が二次関数的に増えていく感覚になるのはこのためだ。
キャッシュが効く条件と、壊れる条件
Anthropic APIのプロンプトキャッシュは、キャッシュ読み出しを通常入力の約0.1倍、書き込みを1.25倍（5分TTL）／2倍（1時間TTL）で課金する。つまり前置きが安定しているほど安くなる設計だ。
ただし効くのは接頭辞（prefix）が一致している間だけ。次をやると崩れる。
- セッション途中でシステム指示や設定ファイルを書き換える
- ツール定義を足し引きする（MCPサーバーの出し入れを頻繁にやる）
- 履歴の古い側を編集・削除する
再利用したい情報は前に、揺れる情報は後ろに。順番の設計だけで請求は変わる。詳細な単価と対象モデルは公式のプロンプトキャッシュ解説で必ず確認してほしい。
畳むのか、捨てるのか
Claude Codeにも Codex CLI にも会話を要約圧縮する /compact がある。Claude Code には履歴を破棄する /clear もある。使い分けははっきり分かれる。
- タスクが続いているなら
/compact（経緯を残したまま縮める） - タスクが終わったなら
/clear（前のタスクの文脈は次の作業にとって純粋な負債）
「なんとなく続けて使う」が一番高い。1タスク1セッションに寄せるだけで効く場面は多い。
効く場面・効かない場面
結論: 削減が効くのは「探索」と「前提の再送」。生成そのものは減らない。
| 場面 | 効き方 |
|---|---|
| 大きなリポジトリで該当箇所を探す | 効果が大きい。全文読みを構造検索に置き換えると入力が大幅に減る |
| プロジェクト固有の前提を毎回説明している | 効果が大きい。常設ファイルに移すとキャッシュ側に乗る |
| 長時間の1セッションで多目的に作業 | 効果が大きい。分割と `/clear` が直接効く |
| 設計を詰める・仕様の抜けを議論する | ほぼ変わらない。思考の出力量が本体なので削りにくい |
| 大量のコードを新規生成する | ほぼ変わらない。出力トークンは仕様の量で決まる |
| 失敗するテストを何度も踏む | 逆効果になりうる。往復が増えるほど履歴が太る |
最後の行が実務では一番厄介だ。テストやビルドが落ち続ける状態で放置すると、エラーログがそのまま文脈に蓄積する。先に環境を直すほうがトークン対策として早い、という順序は覚えておきたい。
実際の組み方：3つの構成と公開元
結論: 増やすツールは多くていい話ではない。「常設化」「取得を絞る」「作業を分ける」の3方向だけで足りる。
1. 指示を常設化する（AGENTS.md / CLAUDE.md）
毎回チャットで説明している前提を、リポジトリ側のファイルに移す。Codex系は AGENTS.md、Claude Code は CLAUDE.md（およびユーザー階層のメモリ）を自動で読む。仕様はagents.mdとClaude Code のメモリ機能にある。
書くべきは「知らないと踏む地雷」に絞る。
- ビルド・テストの正しいコマンド（探索の往復を消す）
- 触ってはいけないディレクトリ、壊せないデータ契約
- 命名・構成の既存ルール（差し戻しのやり直しを減らす）
逆に、長い一般論や網羅的なコーディング規約を詰め込むと、毎セッションの固定費になる。短く、具体的に、例外を書くのが効率側の正解だ。
2. 取得を絞る（構造検索とパッキング）
ファイル全文を読ませるのをやめ、必要な範囲だけ渡す。公開されている選択肢は主に3系統ある。
- Serena — Language Server を使ってシンボル単位で参照・定義を取得するMCPサーバー。「この関数の呼び出し元だけ」を渡せる
- ast-grep — 構文木ベースの検索。grepの取りこぼしとノイズを同時に削る
- Repomix — リポジトリを1ファイルにまとめ、トークン数を数えてから渡せる。小さめのリポジトリや初回把握に向く
方向は逆だ。SerenaとRepomixは「絞る」と「まとめて渡す」で思想が違うので、両方入れる必要はない。既存コードの改修が主なら前者、全体像の把握が主なら後者から試すのが素直だ。
3. 作業を分ける（サブエージェントと段階実行）
Claude Code のサブエージェントは独立したコンテキストウィンドウを持つ。調査・レビュー・テスト実行を切り出すと、探索中に読んだ大量のコードが親の履歴に残らない。仕様はサブエージェントのドキュメントにある。
もう一つは推論量の制御。Codex CLI は設定で推論の深さ（model_reasoning_effort）を変えられるので、定型の修正に最上位の設定を使い続ける必要はない。設定項目とモデルの対応はCodex CLI の公式ドキュメントとリポジトリを確認してほしい。
速度は何で決まるか
結論: 体感の待ち時間を作っているのは、多くの場合モデルの生成速度ではなく往復回数だ。
- 入力が長い → 初回の処理（プリフィル）が伸びる。キャッシュヒットで短縮できる
- 推論が深い → 出力前の思考トークンが増える。タスクに応じて設定を下げる余地がある
- 往復が多い → ここが最大。探索10往復を1往復で済ませる設計が一番効く
だから「速くしたい」と「安くしたい」は、この領域ではだいたい同じ方向を向く。渡す情報を正確に絞る施策は両方に効き、モデルを軽くする施策はやり直しが増えれば逆効果になりうる。軽いモデルへの切り替えは、失敗率まで見て判断する必要がある。
実務者が最初にやる順番
効果と手間の比で並べると、こうなる。上3つは今日できる。
- タスクが終わったら
/clear、続くなら/compactに切り替える AGENTS.md/CLAUDE.mdに正しいテスト・ビルドコマンドと禁止事項を書く- 落ちているテストや壊れた環境を先に直す（履歴の膨張源を止める）
- 探索が重い実感があるなら、構造検索系かパッキング系を1つだけ試す
- 調査とレビューをサブエージェント側に出す
- 定型作業の推論設定を見直す
導入前後は必ず同じタスクで比べること。Claude Code なら /cost、API利用なら使用量ダッシュボードで測る。料金体系やコマンドは更新が入るため、Claude Code のコスト管理ドキュメントなど公式情報での確認を前提にしてほしい。
継続ウォッチ
- 「Jev」の一次情報: 提供元やリポジトリが公開されたら、主張している削減対象（入力／出力／往復）と測定条件を確認する
- コンテキスト管理機能の標準化: 履歴の自動圧縮・自動編集がCLI側の標準機能に寄っていくほど、外部ツールで補う必要は減る
- キャッシュ条件の変更: TTLや単価、対象モデルが変わると、前置きを固定する設計の損得も変わる
今日のまとめ
- 「Jev」は現時点で一次情報を確認できない呼称。手法として中身を見て、製品として信用しない
- トークンの主犯は履歴と文脈の再送。前置きを固定し、終わったタスクは捨てる
- 削減が効くのは探索と前提の再説明。設計議論と新規生成はあまり減らない
- 速度も往復回数で決まる。安くする施策と速くする施策はほぼ同じ方向
- 効果は環境とリポジトリ規模で差が出る。導入前後を同一タスクで測ってから定着させる
次に手を付けるなら、まず自分の直近1週間のセッションを見返して、「同じ説明を何回書いたか」を数えるところからでいい。その回数がそのまま、削れる固定費だ。