cclensで自分のClaude Codeを計測したら、9,097トークンの無駄が見えた

この記事、最初は「開発者向けツールcclensを経営者向けに解説する」という体で書いていました。ところがひろくんから「実際に試してそれを記事にしてほしい」と一言。たしかに、人のブログを要約しただけの記事には説得力がありません。実際に計測したら何が見えるのか、ここから先は全部実測レポートです。

というわけで、その場でcclensをHomebrewで実際にインストールし、この記事を書いている私たち自身のClaude Code環境（ai-kidou.jpを含むmothership-labプロジェクト）に対して動かしてみました。これは「AIを入れたのに、なぜか成果が出ない」という話を、他人事の解説ではなく自分ごとの実測データで確かめる試みです。

理由はシンプルで、AIの「使い方」を感覚でやっているからです。料理で言うなら、レシピを見ずに「なんとなく美味しくなりそう」で調味料を足していく状態。1回はうまくいっても、2回目・3回目で同じ味を再現できません。私たち自身、本当にそうなっていないか、今日は自分の台所を計測してみます。

cclensは、AIコーディングツール「Claude Code」の設定・使い方のムダを可視化するツールです（開発者: lambdalisue氏「Claude Codeの『無駄』を可視化するツール cclens を作った」、実体はGitHub: lambdalisue/cclensで公開されています）。

記事の中でいちばん刺さったのは、この一節です。

インストールは brew install lambdalisue/cclens/cclens の一発だけ。30秒足らずで完了しました。続けて健康診断コマンド cclens doctor を実行すると、私たちのClaude Code利用履歴——150プロジェクト・3,527セッション分——を自動でスキャンして、こんな結果が返ってきました（実際の出力の抜粋です）。

正直、笑いました。「article.htmlを6分間で19回も編集し直して行き詰まっていた」というのは、まさに今この記事の元になった作業と同じ匂いがします。感覚では気づけなかった無駄が、実測だと一発で名指しされるんです。

新しく計測用のツールを追加で契約する必要はなく、すでにある使用履歴を見るだけというのがポイントです。ローカルで処理が完結するので、社外に情報が出る心配もありません。

以前、AIニュース解説（2026年6月17日号）でもClaude Codeの「動的ワークフロー機能」で作業を並列化できるようになったという話を紹介しましたが、あの時は機能の存在だけを取り上げて、「実際にその使い方が効率的かどうか」までは踏み込めていませんでした。cclensはまさにその「使い方の効率」を測るための道具です。

「無駄になってるかどうか、なんとなく分かるでしょ」と思うかもしれません。でも実際は、AIとのやり取りの無駄は、人間の目にはとても見えづらいんです。実際、私たち自身が計測するまで、この数字には気づいていませんでした。

cclens waste --scope global を実行すると、Claude Codeが毎回のセッション開始時に自動で読み込んでいる設定ファイル（CLAUDE.mdやルールファイル）ごとの消費トークン数が、こう出てきました。

合計すると1セッションを始めるたびに9,097トークンが、作業を始める前の「ルールを読む」だけで消えていることになります。しかもこれは、実際に何かAIに作業を頼む前の話。会話を1回もしていない時点で、すでにこれだけのコストが発生しているんです。

さらに視野を広げると、開発者のMario Zechner氏が2025年8月に行った別のベンチマークでは、同じ「ブラウザ操作」というタスクでも、AIへの情報の渡し方によってこれだけの差が出たと報告されています。

トークンというのは、AIが処理する「情報の量」のようなものです。同じ結果を得るのに、渡し方次第で43倍もコストが変わる。私たちの9,097トークンの実測結果と合わせて見ると、「便利そうだから追加する」の積み重ねが、いちばん見えにくい無駄の正体だとよく分かります。

さらにAnthropic自身も、2025年11月のブログで「従来150,000トークンかかっていたワークフローが、やり方を変えるだけで約2,000トークンに、98.7%削減できた」と公式に報告しています。開発者ですら気づかず無駄を垂れ流していたということです。

これは私たち自身にも心当たりがあります。ひろくん（田中）が社内MTGで自分のAI運用について「コンテキスト使用率が35%を超えたあたりから、精度低下と記憶漏れが実際に発生している」と正直に報告したことがありました。スキルやMCPを便利だからと追加していった結果、AIが本来集中すべき情報の中に、使っていない設定の情報が混ざり込んでいたのが原因でした。今回の実測（9,097トークン／セッション）は、まさにその実感を裏づける具体的な数字になりました。

無駄が生まれるもう一つの原因が、「情報が散らばっていること」です。

サイボウズのkintone Design Systemチームが公開した事例が分かりやすいので紹介します。彼らは、GitHub・Slack・Confluence・kintoneといった複数のツールに散らばっていたデザインの議論を、「LLM-Wiki」という仕組みで一元管理するようにしました（サイボウズ フロントエンドチーム「散らばった議論を LLM-Wiki でフル活用する AI 時代のデザインシステムのカタチ」）。

仕組みは3層構造です。

1. 一次資料（raw/）: 元の議論ログそのもの。書き換えない
2. AI生成ドキュメント（wiki/）: 一次資料をもとにAIが整理し直した、検索しやすい形の記録
3. Agent設定（AGENTS.md）: AIがどのルールで参照・生成するかの取り決め

これによって、「あの件、どういう経緯で決めたんだっけ？」という時に、担当者の記憶に頼らず、根拠付きで過去の判断を追跡できるようになったといいます。

GitHubやSlackという名前だけ見ると技術者向けの話に見えますが、本質は違います。「社長の頭の中にしかない判断基準」を、AIが参照できる形に整理する話です。

道具を増やすほど、運用と権限管理の対象も増えます。まず「今ある情報をAIが使える形に整えること」が先で、新しいツール導入はその後でいい、という順番は覚えておいて損はありません。Claude Code自体も日々アップデートが続いていて、8月6日のAIニュース解説ではセキュリティ強化の動きも紹介しました。ツールの進化を追いかけるだけでなく、今の使い方を整理する手も止めないことが大事です。

もう一つ、今回のブックマークで気になった論点があります。「AIエージェントが試行錯誤を高速に繰り返すようになると、逆に人間の役割が『事前の設計』にシフトし、ウォーターフォール型の開発スタイルが復活する」という指摘です（pdfractal氏「なぜ、ループエンジニアリングの普及がウォーターフォール開発を復活させるのか？」）。AIの内部ループがどれだけ速くなっても、それを評価する人間の判断速度は変わらないため、「先に何を成功とするか決めておく」ことの重要性が、AI時代になるほど増すという逆説的な話でした。

これ、実はai-kidou.jpで以前紹介した「Graphエンジニアリング」の記事とほぼ同じ結論です。あの記事では、AIエージェントに仕事を任せる時の設計を「走る地図」に例えていました。

「AIに丸投げすれば楽になる」のではなく、「AIに何を、どこまで、どんな合格ラインで任せるか」を先に決めておくほど、結果的にAIが使いやすくなる。これは、実際にひろくんが16時間AIにゲーム制作をループさせた実演でも同じでした。「信長の野望を超える」という具体的なゴールと、「達成するまで回す」というシンプルなルールの2つだけで、AIは長時間の試行錯誤に耐えられていました。

ここまでの話は、そのままだと開発者向けの用語が多くて分かりにくいと思います。表にまとめて翻訳しておきます。

開発者向けの言葉	経営者・中小企業向けの翻訳
トークン最適化	AIに無駄な説明を何度もさせない仕組みづくり
Claude Code設定	AIに渡す業務マニュアルの整理
ナレッジグラフ・ベクトルDB	会社の情報のつながりをAIが辿れる状態
LLM-Wiki	社内の判断・議事録・ノウハウをAI用に整えた知恵袋
ループエンジニアリング	AIに何度も試行錯誤させる業務改善サイクル
ウォーターフォール型の復活	AIに任せる前に、目的と合格条件を先に決める姿勢

そしてもう一つ、今回のcclensの話とai-kidou.jpの実践を比較した表もどうぞ。

	cclens（開発者向け）	AI氣道の実践（経営者向け翻訳）
Before	「なんとなく便利」で使い続け、無駄が見えない	「AI導入した」で満足し、効果測定なし
見るもの	Claude Codeのセッションログ	ChatGPT/Claudeとのやり取り履歴・使用時間
After	ランキング化された無駄をAIに渡して自動改善提案	「どの業務でAIが一番時間を食っているか」を定期的に振り返る
コスト	追加ツール費用ほぼゼロ（既存ログを解析）	追加ツール費用ほぼゼロ（既存の利用履歴を見るだけ）

正直に書きます。私たち自身、Claude CodeやMCPを日常的に使っていますが、cclensを実際に動かして数字を見るまで、9,097トークン/セッションという規模の無駄が起きていることに気づいていませんでした。

さらに cclens failures --scope project:mothership-lab というコマンドで自分たちのプロジェクトの失敗パターンを見せてもらうと、こんな結果が出ました。

3,830件という数字にまず驚きましたが、もっと痛かったのは「40%のBashコマンドがcdだけ」という指摘でした。作業ディレクトリを移動するだけのコマンドがそれだけの割合を占めているということは、その分だけ余計なやり取りが積み重なっていたということです。

ひろくんが「コンテキスト使用率35%で精度低下と記憶漏れが実際に発生している」と自分の運用について正直に報告した時も、最初は「便利な機能を足しているだけなのに、なぜ精度が落ちるのか」とピンときていませんでした。対策は/contextコマンドでの定期確認、不要な機能のオフ、指示の圧縮という、特別なことではない地味な積み重ねでした。今回の実測は、その感覚が正しかったことを裏づける具体的な証拠になりました。

「AIをたくさん使いこなしている」ことと、「AIの使い方が効率的である」ことは、まったく別の話です。私たちも、量をこなすことに気を取られて、質の計測を後回しにしていた時期がありました。GPTs研究会のライブで見た、高崎さんによるCursorとClaude Codeの並列作業実演も、「速く動かせる」ことばかりに目が行きがちですが、今振り返ると「その速さが本当に効率的だったか」までは検証していませんでした。

専用ツールがなくても、今日から始められることがあります。

1. 1週間分、AIとのやり取りを振り返る: 「これは何度も同じ説明をし直しているな」というやり取りがないか、ざっと見返すだけでも気づきがあります
2. 「あの件どう決めたっけ」を1つ思い出してみる: 過去の判断の根拠が、担当者の記憶だけに残っていないか確認する。残っていなければ、それが最初に整理すべき情報です
3. AIに仕事を任せる前に「何ができたら合格か」を1行で決める: 「とりあえずやって」ではなく、「この条件を満たしたらOK」と言えるようにする

どれも特別な予算やツールを必要としません。「感覚でAIを使う」から「振り返ってAIの使い方を直す」への切り替えが、今日からできる一番の改善です。

たとえば、見積書のたたき台をAIに作らせている会社なら、「毎回、同じ会社概要や取引条件を一から説明し直していないか」を1週間分見返すだけで、テンプレート化できる部分が見つかることがあります。逆に「AIに任せた結果を、毎回全部読み直して直している」なら、それは合格条件が曖昧なまま任せているサインです。振り返りの視点は、業種を問わず応用できます。

「開発者向けツールを紹介するだけの記事」で終わらせず、実際にcclensをインストールして自分たちのClaude Codeログ（150プロジェクト・3,527セッション）を計測してみました。結果、セッション開始だけで9,097トークンがルールを読むだけで消え、プロジェクト単体でも3,830件のツール失敗、40%がcdだけのBashコマンドという実態が見えてきました。

AIを「入れる」ところまでは、多くの会社がもうできています。差がつくのはその先、「入れたAIの使い方を、感覚ではなく実測で振り返っているかどうか」です。もう一度言います。AI導入で成果が出ない会社ほど、ログを見ていないのです。

料理と同じで、レシピ（=合格条件）を決めずに、味見（=振り返り）もせずに作り続けたら、いつまでも同じ味しか出せません。cclensという開発者向けツールが教えてくれたのは、特別な才能ではなく「推測するな、計測せよ」という、誰でも実践できる姿勢そのものでした。私たち自身、書いている本人が実測して初めて気づいたくらいです。

今週、AIとのやり取りを1つだけ振り返ってみてください。そこに、次の改善のヒントがきっとあります。