Clew は完了済みの AI エージェント実行トレースを読み取り、すでに実行した作業を繰り返したステップ――同じツールを同じ引数で再呼び出しする、失敗した呼び出しを同じ引数で再試行する、すでにコンテキスト内にある情報を再取得する――を見つけ出します。LLM による判定なしで動作するため、同じトレースを入力すれば常に同じ結果が出ます。
AI コーディングエージェントのセッションでは、無駄は請求書でしか表面化しません。すべてのツール呼び出しが 200 を返し、何もエラーを出さないため、無駄は目に見えません。しかしトレースの中では、エージェントが同じファイルを二度読み、失敗した呼び出しを同じ引数で再試行し、同じツールを同じペイロードで再び呼んでいます。
こういう時だけは気が合うんですね。
社名に Open を掲げておきながら厚かましく振る舞う OpenAI も、
OpenAI が変わったと言って飛び出していった Anthropic も、
金のためにやっているのか、AIを覇権争いと見て政府が介入し、経営陣を意のままに操っているのか
うわ…
教育を売り物にするのが最もコスパがよい。責任はなく、費用を請求するだけ。AIはこうした商売の大きなパイを占めることになるだろう。
数年前に見た気がします
元サイトを見ると、画像で説明されているので直感的に理解しやすいですね。
散歩や読書のようなオフライン活動を増やすといいですね。笑
3番（エージェント間の責任分離）が一番難しい部分だと思います。公開ベンチマークのトレースを少し見たことがあるのですが、そこで見たパターンを1つ共有します。
最も多かったのは「誤った判断」よりも、同じ作業が2回実行されることでした。同じ引数でメール送信が繰り返されたり、同じファイルが再度書き込まれたり。特にタイムアウト後のリトライ区間でよく発生していました。最初の呼び出しが遅かっただけなのに、失敗と判断して再度呼び出す、といった形です。
これが追跡しにくい理由は、エラーが出ないことです。どちらも200でログもきれいなので、後からログだけ見ても見えません。
私たちが使っている方法は、（ツール、正規化された引数、出力ハッシュ）でまとめて、同じ組み合わせが繰り返されているかを機械的に数えることです。LLMの判断なしに計算だけでできるので、再現可能です。ただし限界は明確で、「2回呼び出された」ことまでは分かっても、「実際に2回実行されたか」はトレースだけでは確認できません。レスポンスでエンティティIDを返すツール（ドキュメント生成APIのようなもの）ならIDを比較して確認できますが、メールのように「送信成功」だけを返すツールでは方法がありませんでした。
2番でおっしゃっていた「速さのためにそのまま通す」部分にも共感します。私たちもリアルタイムで止めることを検討しましたが、実行前には結果が見られないため引数だけで判断する必要があり、その精度が低かったです。正常なリトライまで止めてしまうケースが出たので、取りやめました。
バグ修正も非常に安くなり、ソフトウェア更新のコストもゼロに近づいているうえ、金融業界レベルでもなければバグは直せば済む場合が多いので……
でも、こうした認識が積み重なると、結局は大事故が起きるのでしょうね。
お試しいただいて、Jumpbackが空回りする会話や「これはちょっと不便だな」と感じる部分があれば、気軽にコメントを残してください。サイトごとに会話構造が異なるので、実際の利用事例がいちばん助けになります。次はPerplexity対応とNotion/Obsidianへのエクスポートを考えていますが、もっと急ぎのものがあればそちらからやろうと思っています（笑）
ありがとうございます。お試しいただいて、Jumpbackが拾えない会話があれば気軽にお知らせください〜
私も使ってみてはいるのですが、実際にほかのユーザーの方々の不便な点もあわせて聞けるといいなと思っています（笑）
エージェントが修正するたびに diff ログを観察して、ショットガン手術や大量の変更を引き起こしているなら、ソフトウェア工学的な悪臭と見なして強化学習できそうな気もしますね…
[読みづらいかもしれないと思い、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%）、廃棄しました。予測と結果は事前登録文書にあわせて残してあります。
作者からの更新です。本文で1行だけ触れたMCPサーバー部分について、別途整理した記事を公開しました — エージェントがマイグレーションを書くときにカラム名を勝手に付けてしまう問題を、物理名を"入力"ではなく単語辞書ベースの"計算"に変えることで解決する構成です:
https://sqemo.com/blog/erd-mcp-server
(まだ
stdioのローカル専用のため、リモートMCPは未対応。アプリ本体は非公開で、MCPサーバーのみ公開しています)。登録不要ですぐ試せるので(app.sqemo.com)、気になる点があればコメントしてください — 初期段階なので、フィードバックはすぐ反映されます.
更新履歴 (2026-07-25)
最初の投稿以降、Repolis を単なる 3D repo ブラウザよりも、再訪する理由のある小さな町として継続的に拡張してきました。
新しい投稿を作る代わりに、今後の変更点もこの元投稿のコメントに続けて記録していきます。
Live: https://hyeonsangjeon.github.io/Repolis/
Source: https://github.com/hyeonsangjeon/Repolis
Macの韓国語キーボードでは入力できないのが残念。Claudeは回答するときにこの記号をかなりよく使っているようですが、韓国語ユーザーにはなじみが薄いですね…
自分のところにも配信されたので使ってみたけど……うーん、日本語はまだですね。
作者です。本文に入れられなかった点をいくつか補足すると —
・デモ動画（スマホ承認フロー、デスクトップ3分割コマンドセンター）はランディングページに実機キャプチャで載せています: adhf.dev
・セルフホストは
npm i -g adhdevの1行だけで、localhost:3847にダッシュボードが立ち上がります（アカウント不要）・ff-onlyマージ設計や、MAGIの交差検証が実際に何を検出するのかといった設計面の質問も歓迎です
フィードバックをいただければ、すぐ反映します。
自分はgpt6を期待していたのですが……opus5が出たのですから、新モデルも出るべきではないでしょうか。
最近は技術的負債ではなく、認知的負債が語られますよね。
たまに同僚たちと話していると、自分で作ったものなのに動作をきちんと理解できていない様子をしばしば目にして、少しぞっとすることがあります。
このまま時間がたてば、誰も動作を理解できない状態になるはずですが、AIに分析させて聞けばいいのだから問題ではないのかも、と思ったりもしますね.
こういう文章、大好きです