トークンの浪費が見えにくい理由は、失敗ではなく重複だからです。同じファイルを2回読む、同じ引数で再試行する、同じツールを再呼び出しする。そこで、完了済みのトレースを読み、どのステップがすでにやったことを繰り返したのかを指摘するCLIを作りました！
[試す]
pip install "clew-custos[detect]"
python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.md
登録不要でローカルで動きます。torchを取得しないので、インストールは数秒で終わります。Python 3.12以上。Claude Codeのセッションファイルは ~/.claude/projects/ 配下にあります。
公開Claude Codeセッション（258ターン）で実行した実際の出力です:
Result: WASTE DETECTED
- category breakdown: 0 error_repeat, 0 side_effect, 1 idempotent, 0 unclassified
1. requery — Read on .../boot.ts
- turns: turn 50 → re-run at turn 58 (of 258 total)
- state: No modification of this file in between — re-read output is unchanged.
- re-consumed across 200 subsequent turns (≈439 tokens/turn → 87800 amplification tokens)
- estimated cost impact: $0.026340 ~ $0.263400 (cache-hit to cache-miss)
[どう判定するか]
LangfuseやPhoenixのようにトレースを保存して可視化するものではありません。すでに完了したトレースを読み、浪費だけを指摘します。
2段階です。まず同じツールを同じ引数で呼んだもの同士をまとめ、その次に出力のsha256が完全に同じかを見ます。出力が違えば状態が変わったということなので検出しません。
LLMによる判定はありません。同じトレースを入れれば、常に同じ結果が出ます。
見つけた浪費は4種類に分類します。エラーの繰り返し（同じエラーを原因を直さずに再試行）、副作用の再実行（状態を変えるツールを同じ引数でもう一度呼び出し）、グレーゾーン（読み取り専用の繰り返し — 副作用はないがトークンは使う）、判定不能です。BashやPowerShellのように、引数の内容によって効果が完全に変わるツールは、名前だけでは判定せず判定不能にしています。
[公開データで何を見つけたか]
Toolathlonベンチマーク（22個のフロンティアモデル × 3回実行、6,780トレース、tool span 176,270件）にそのままかけたところ、重複呼び出しが8,042件見つかりました。
この数字をそのまま使うと水増しになります。47%はグレーゾーン（作業完了宣言の繰り返し、すでに存在するディレクトリの再作成のようなもの）なので、除くと4,251件です。tool span比で2.41%。
目立ったのは、状態を変えるツールの重複実行1,343件で、そのうち同じ引数で繰り返されたメール送信が459件でした。ただしこれは「同じツールが同じ引数で2回呼ばれた」という検出であり、実際にメールが2回送られたかどうかはトレースだけでは確認できません。
[意外だったこと]
Claude Code自体は思ったより効率的でした。ファイルの再読み込み、無意味な再試行のような候補パターンを6回測定しましたが、5回はCCの実セッションには実質的に存在しませんでした。キャッシュとコンテキスト維持ですでに防げていたようです。
浪費が厚かったのは、MCPサーバーを複数つないだ環境でした。ツールが20個のCC（0.80%）と523個のToolathlon（2.41%）で3倍の差がありました。
[限界]
測定された削減事例はまだありません。検出して推定することはできますが、誰かがこれを見て何かを直し、請求額が実際に減ったというデータは0件です。
グレーゾーン47%は除外せず、分類して表示するだけです。読み取り専用の繰り返しが実際に浪費かどうかは実行コンテキストによって異なり、それは私には判断できない部分だからです。
CursorとCodexはまだサポートしていません。
検証に失敗した検出器は廃棄します。ファイル再読み込み検出器を作ったものの、30件の標本で適合率が70%のしきい値を大きく下回ったため（寛大に見ても3.3%、厳格なら0%）止め、事前登録文書に予測と結果をともに残しておきました。
[締めくくり...]
この分野については、引き続き研究と検証を続ける予定です！
READMEが英語な点はすみません.. 泣
もし使ってみて、こういう部分が改善されるとよい、追加されるとよい、といったフィードバックをいただけるとうれしいです！
今後ともclewにぜひご注目ください。ありがとうございます...!!
1件のコメント
[読みづらいかもしれないと思い、README の日本語訳を書いておきました！]
Clew
エージェントのトレースから無駄な作業を見つける決定論的検出器。
Clew は完了済みの AI エージェント実行トレースを読み取り、すでに実行した作業を繰り返したステップ――同じツールを同じ引数で再呼び出しする、失敗した呼び出しを同じ引数で再試行する、すでにコンテキスト内にある情報を再取得する――を見つけ出します。LLM による判定なしで動作するため、同じトレースを入力すれば常に同じ結果が出ます。
pip install "clew-custos[detect]"
python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.md
公開されている Claude Code セッションで実行した実際の出力例:
Result: WASTE DETECTED
1. requery —
.../boot.tsに対する Readなぜこれが重要なのか
AI コーディングエージェントのセッションでは、無駄は請求書でしか表面化しません。すべてのツール呼び出しが 200 を返し、何もエラーを出さないため、無駄は目に見えません。しかしトレースの中では、エージェントが同じファイルを二度読み、失敗した呼び出しを同じ引数で再試行し、同じツールを同じペイロードで再び呼んでいます。
コーディングエージェントのセッションでは読み取り（read）作業がトークンの 65〜90% を占めるため、こうした無駄は目立たないまま積み上がります。オブザーバビリティツールはトレースを表示してくれますが、どのステップが重複だったのかは教えてくれません。
何を検出するのか
Clew は 3 種類の重複パターンを探します:
repeat — 同じツール/ノードが繰り返し呼び出される
requery — 同じツールが同じ入力で再呼び出しされる（出力も同一）
pingpong — 2 つのエージェントが実質的に同じ内容をやり取りする（マルチエージェント）
各検出結果は 4 種類に分類されます:
error_repeat — 出力がエラーなのに同じ呼び出しを繰り返す
side_effect — 状態を変更するツール（送信/書き込み/生成など）を再実行する
idempotent — 読み取り専用/宣言的ツールを繰り返す（副作用はないが、トークンは消費する）
unclassified — マッピングにないツール。効果がペイロードに依存するため、ツール名だけでは推論しない（Bash/PowerShell など）
[どのように動作するか]
2 段階のカスケードです:
構造ゲート — 同じツールを同じ（正規化された）引数で呼び出したもの同士をグループ化
同一性ゲート — 出力の sha256 が完全に一致するかを確認。一致しなければ状態が変わったものとしてフラグしない
安価な構造チェックでまず候補を絞り込み、高価な意味チェック（埋め込み+コサイン）は必要な場合にだけ実行されます。LLM 判定がないため結果は決定論的です――CI に入れたいなら、この点は重要です。
[入力形式]
Claude Code — セッション JSONL を直接分析
LangGraph — トレースからチェーン重複を検出
LangChain・CrewAI・AutoGen・LlamaIndex など — OpenTelemetry/OpenInference 標準形式で計装されたトレースをパース（形式サポートであり、フレームワーク別の実測検証は進行中）
公開ベンチマークトレース（Toolathlon、RedundancyBench）
Cursor と Codex のセッションはまだサポートしていません — ローカル形式を検討中です。
[検証結果]
公開ベンチマーク（Toolathlon、6,780 トレース、tool span 176,270 件）:
重複呼び出し 8,042 件を検出。そのうち 47% はグレーゾーン（冪等操作、完了宣言）であり、これを除くと 4,251 件（tool span 比 2.41%）。Claude Code セッション（0.80%）と比べて約 3 倍。
状態変更ツールの重複実行 1,343 件。その中には、同じ引数で繰り返されたメール送信 459 件が含まれます。ただし、これは同じツールが同じ引数で重複呼び出しされたという検出であり、実際に副作用が発生したかは確認されていません。
ラベリングベンチマーク（RedundancyBench）:
precision 0.826（ファイル内重複に対する下限推定値）。RB ラベルのかなりの部分はファイル間（cross-file）重複であり、セッション単位分析という設計の範囲外です。recall は 0.157 と低いです。
[正直な境界線]
測定済みの節約事例はまだありません。検出して推定することはできますが、実ユーザーが何かを修正して請求額が実際に下がった before/after データは 0 件です。
ベンチマークでフラグされたものの 47% はグレーゾーン（冪等な再実行）です。除外せず分類だけします――読み取り専用の再実行が無駄だったかどうかは、見えない文脈に依存するためです。
sha256 の完全一致を要求するため、出力が少しでも異なればフラグしません。recall が低い理由であり、精度側に寄せた設計です。
Claude Code はひときわよく最適化されています。実際の CC セッションで候補となる無駄パターン 6 つを測定しましたが、5 つはそこには存在しませんでした。興味深い無駄は CC 自体ではなく、複数ツールの MCP 環境で現れました。
コスト推定（amplification）は測定ではなく推定であり、Claude Code 形式でのみ可能です。
検証されていないものは廃棄します
ファイル再読み取り検出器を作りましたが、30 件のサンプルに対する人手アノテーションで precision が事前登録したしきい値（70%）を大きく下回ったため（甘く見ても 3.3%、厳密には 0%）、廃棄しました。予測と結果は事前登録文書にあわせて残してあります。