Claude Code利用分析の選び方｜公式とローカルの使い分け

Claude Code の利用を「もっとうまく回したい」とき、見るべき数字は1種類ではありません。組織向けの公式 Analytics は受け入れ行や提案受け入れ率、GitHub 連携の貢献指標を見ます。一方、個人の Pro/Max や現場の摩擦（失敗の繰り返し、肥大した設定、スタックした作業）は、ローカルの transcript と設定を読む分析ツールが補完します。

📑目次

1. 公式Analyticsとローカル分析の役割分担
2. cclensで分かること（doctor・waste・failures・optimize）
3. 隣接ツール比較（ccusage・cc-lens・session-analyzer・自作）
4. 導入手順と1週間の観察チェックリスト
5. 筆者の観点
6. よくある質問（FAQ）
7. まとめ

本記事では、Anthropic の公式ドキュメントとヘルプ、lambdalisue/cclens の一次 README、ccusage や隣接ツール、Shipyard と READYFOR の運用報告を突き合わせ、目的別に何を先に入れるかを判断できる材料にします。人気ランキングやブックマーク数は発見のきっかけに留め、採用判断の根拠には使いません。

記事の使い方

目的（組織KPI / コスト / 摩擦）を先に決め、公式とローカルの役割分担表 → 主ツール1本 → 1週間1改善の順で読んでください。

---

公式Analyticsとローカル分析の役割分担

結論から言うと、チームの採用KPIと自分のセッション摩擦を同じ画面で完結させようとしない方が安全です。公式は組織の利用状況と貢献の説明に強く、ローカルは履歴・設定・失敗パターンの深掘りに強い、という分担が実務的です。

公式ダッシュボードが答えること

Anthropic の英語ドキュメント（Claude Code analytics）では、Team/Enterprise 向けダッシュボード（claude.ai/analytics/claude-code）に次が並びます。

• usage metrics（accepted lines、suggestion accept rate、DAU/sessions）
• contribution metrics（public beta）
• leaderboard
• CSV

Contribution は Owner が analytics を有効化し、GitHub 管理者が Claude GitHub app を入れる前提です。ZDR 組織では contribution が使えず usage のみ、という境界も明記されています。

attribution の保守的な定義

attribution は保守的です。主な定義は次のとおりです。

• 高信頼一致のみ
• 正規化後3文字超の effective lines
• マージ21日前〜2日後のセッション窓
• lock/generated 系の除外
• マージ PR への claude-code-assisted ラベル

日本語ヘルプが示す対象範囲

日本語ヘルプ（Claude Code使用分析、最終更新 2026-07-01 時点）でも、Team/Enterprise の所有者と API Console ロール向けであることがはっきりしています。

• 使用タブ: 受け入れ行、提案受け入れ率、アクティビティ、トップコマンド、CSV
• 価値タブ: 推定生産性・コミット単価・年間価値の式
• 貢献メトリクス: パブリックベータ

個別の Pro/Max には組織ダッシュボードが提供されないこと、機能対応の最初の Claude Code が v2.0.28 であることも FAQ で示されています。

セッション内コマンドとPro/Maxのギャップ

セッション内の /usage（別名 /cost /stats）と /context は、いまの枠とコンテキスト圧の確認に向きます。

一方 Shipyard の比較記事（How to track Claude Code usage + analytics）が整理するように、履歴横断や設定 inventory は slash だけでは弱いです。Pro/Max では Console に per-token が見えにくいギャップがあり、そこを ccusage のようなローカル履歴 CLI が埋める、という見方も同記事で示されています。

出典

公式レイヤの役割分担

レイヤ	主な面	向く問い	典型ユーザー	限界
公式 Team/Enterprise	claude.ai/analytics/claude-code	受け入れ行・提案受け入れ率・DAU/sessions・leaderboard	Owner/Admin	個人 Pro/Max 向け組織ダッシュボードなし
公式 contribution（β）	GitHub app + claude-code-assisted	PR/行の保守的 attribution、ROI 説明	Team/Enterprise + GitHub admin	ZDR では contribution 非対応。API Console は GitHub 連携なし
公式 Console	platform.claude.com/claude-code	accepted lines、accept rate、spend、per-user	API 顧客	contribution 未提供。請求の正本ではない推定あり

ローカル／セッションレイヤの役割分担

レイヤ	主な面	向く問い	典型ユーザー	限界
セッション内 slash	/usage /context	今のセッション枠・コンテキスト圧	全員	履歴横断・設定 inventory は弱い
コスト履歴 CLI	ccusage	日次/セッション/プロジェクト横断の token・USD 推定	Pro/Max 個人〜複数CLI	リアルタイム弱い。課金台帳ではない
リアルタイム	cmonitor 等	ライブ token/上限到達予測	枠を食い切る人	摩擦・設定最適化は別
摩擦/設定レンズ	cclens	waste/inventory/failures/stuck、doctor、optimize	ローカル transcript を持つ人	請求金額の正本ではない。read-only ローカル前提
品質指標	claude-session-analyzer	Read:Edit 比などの行動指標	定量品質を見たい人	cclens とは別系統
自作パイプライン	SessionEnd hook 等	セッション総括・繰り返し指摘	チーム内製	運用コストが乗る

出典

• Claude Code analytics（EN docs）
• Claude Code使用分析（JA Help）
• Shipyard（2026年8月時点）

再結論

組織KPIが必要なら公式を主、個人のコストと摩擦ならローカルを主にします。両方必要なら併用し、画面を混ぜないのが失敗しにくいです。

---

cclensで分かること（doctor・waste・failures・optimize）

何を見るレンズか

cclens は「いくら請求されたか」ではなく、時間・トークン・労力の無駄と、どこを直すかを transcript と live configuration から示すレンズです。

lambdalisue/cclens の README では、読み取った内容をローカル SQLite（cclens.db）へ抽出し、read-only・外部送信なしと説明されています。

• counts は usage signal であり billing ledger ではない
• store は regenerable cache

インストールと主要コマンド

インストールの代表経路は次のとおりです。

1. 試す: nix run github:lambdalisue/cclens -- doctor
2. 定着: nix profile install、または flake + just build / cargo build --release
3. Claude Code plugin: /plugin marketplace add lambdalisue/cclens → /plugin install cclens@cclens
4. スキル例: /cclens:doctor、/cclens:optimize、/cclens:query

主要コマンドの役割は次の通りです。

• doctor — 優先度付きヘルス（WHAT TO FIX FIRST / COST / CONFIG WORTH PRUNING / LOOKS HEALTHY）
• analyze — 増分抽出
• sql — read-only SQL（stdin 可）
• optimize — finding を private temp 経由で claude に渡す（CLI 引数に載せない）
• curated views: waste / inventory / failures / stuck / usage / prompts など（全コマンド --format json 可）

読み取り対象と breaking change

読み取り対象は次です。

• ~/.claude/projects の transcript
• ~/.claude/*
• プロジェクト側の .claude/ と CLAUDE.md

2026-07-10 前後の breaking change で、次のようにリネームされ、エイリアスはありません。

• summary→doctor
• wedges→waste
• surfaces→inventory
• baseline→overhead
• friction→failures
• thrash→stuck

古いチートシートのコマンド名は無効になるため、導入時にコマンド表を更新してください。schema 変更後は古い db を消して再構築する運用も README の注意点です。

実務での回し方

実務では、まず doctor で「最初に直す1件」を決め、failures と waste で根拠を確認し、必要なら optimize で修正案を対話的に作る流れが分かりやすいです。

• optimize は Claude Code を起動するため、追加トークンを消費し得ます
• 全面最適化を毎回走らせるより、1週間に1系統の変更に留める方が再現性を取りやすいです

---

隣接ツール比較（ccusage・cc-lens・session-analyzer・自作）

cclens だけが正解ではありません。目的が「いくら使ったか」「画面で眺めたいか」「品質ベンチか」「チームの繰り返し指摘か」で主ツールが変わります。

目的別の選び方

主ツールは「答えたい問い」で決めます。比較表の前に、コスト・摩擦・品質・内製のどれが先かを固定してください。

ツール比較表

ツール	主目的	起動の目安	データ	強み	向かないこと
cclens	摩擦・設定・waste のレンズ	nix/cargo/plugin	~/.claude + プロジェクト設定	doctor/optimize、SQL、JSON	複数 agent CLI 横断コストの一次集計
ccusage	token/USD 履歴	npx ccusage@latest report daily	各 CLI のローカル usage log	多CLI、cache 分離、offline pricing、JSON	設定 inventory / 失敗パターン
Arindam200/cc-lens	ローカル dashboard	npx cc-lens	~/.claude/ 系	UI、5秒リフレッシュ、telemetry なし	cclens 相当の optimize フローは別
lucemia/claude-session-analyzer	品質ベンチ指標	Python / plugin	session JSONL	Read:Edit 等の表基準	設定コストの inventory
READYFOR 自作	セッション総括・繰り返し指摘	SessionEnd hook	transcript_path	118セッションの実運用知見	汎用製品としての配布
cmonitor	リアルタイム枠	pip/uv cmonitor	ローカル	上限到達予測	履歴横断の深い摩擦分析

比較表の出典

• ccusage.com
• Arindam200/cc-lens
• lucemia/claude-session-analyzer
• READYFOR Tech Blog（Zenn）
• Shipyard（2026年8月時点）

ccusage・cc-lens・session-analyzer

ccusage は Claude Code に限らず、Codex や Gemini CLI など複数の agent CLI のローカル usage log から token と推定 USD を集計します。

• アップロードしない
• cache create/read の分離
• JSON 出力
• オフライン pricing

コスト履歴を先に見たい人の入口として導入負荷が低いです。

Arindam200/cc-lens は npx cc-lens でローカル dashboard を立ち上げ、telemetry なしで ~/.claude/ を可視化します。UI 中心で、cclens の doctor/optimize とは別実装です。名前が似るため、リポジトリを確認してから選ぶ必要があります。

lucemia/claude-session-analyzer は session JSONL から Read:Edit 比などの品質指標を出します。README のベンチ表では、Read:Edit >6 が good、<2 が degraded と示されています。行動品質を数値で見たい場合の隣接選択肢です。

READYFOR の運用示唆

READYFOR の公開記事は、公式 /insights が横断俯瞰には有用でも、直前セッションの振り返りには不足しがちだと位置付け、SessionEnd hook で総括を溜めるパイプラインを報告しています。

主な定量メモは次のとおりです。

• 12日で118レポート
• 繰り返し指摘の上位: PR テンプレ非準拠18・コミット粒度15
• 改善提案177件の約40%が CLAUDE.md 追加に偏り
• hook/スキル自動化の方が効くという考察
• /analyze-sessions は約15万トークン規模になり得る

再帰防止（CLAUDE_SESSION_ANALYSIS=1）や timeout/background 設計は、内製するときの参考になります。

出典

選定ヒューリスティック

選定ヒューリスティックは次の4段で足ります。

1. 組織KPI・GitHub ROI → 公式 Analytics（必要なら spend report 等を併用）
2. いくら使ったか（個人/複数CLI）→ ccusage（必要なら cmonitor）
3. 何が無駄で何を直すか → cclens（必要なら session-analyzer）
4. チーム内の繰り返し指摘を潰す → hook 自作、または cclens optimize の運用化

---

導入手順と1週間の観察チェックリスト

次の手順は、読後にそのまま試せる最小運用です。目的を混ぜないことが成功条件です。

8ステップの最小運用

1. 目的を1つに切る: A コスト可視化 / B 摩擦削減 / C 組織採用KPI。同時に3つ追わない。
2. 公式の可否を確認する: Team/Enterprise/Console か Pro/Max か。ZDR なら contribution 非対応を前提に入れる。
3. ローカル前提を満たす: ~/.claude/projects に transcript があること。共有PCや秘密情報ポリシーを決め、ログに秘匿が残る前提で扱う。
4. コスト目的なら ccusage を先に: npx ccusage@latest report daily でプロジェクト別の偏りを1枚メモする。
5. 摩擦目的なら cclens: nix run github:lambdalisue/cclens -- doctor または plugin インストール → analyze → failures / waste / inventory。
6. 1週間ルール: 変更は最大1系統（未使用 skill 削除、重い always-on の trim、失敗カテゴリ top1 のパス修正など）。毎回の全面最適化は避ける。
7. 効果判定: 同種タスクの再実行で failures 件数・stuck・/usage 枠消費・主観リードタイムを比較する。改善がなければツールを増やさず観測項目を変える。
8. 組織展開: READYFOR 型なら再帰防止と timeout/background を先に設計する。個人で再現してから共通ルール化する。

採用チェックリスト

• ✓ 目的が A/B/C のどれか一つに決まっている
• ✓ 公式ダッシュボードの対象プランを確認した
• ✓ ローカルログの取り扱い（秘密・保管）を決めた
• ✓ ccusage または cclens のどちらかを「主」にした
• ✓ doctor/failures の top 項目を1件だけ直す合意がある
• ✓ 課金の正本を Anthropic 請求/プラン画面に置き、CLI 数値は信号扱いと明記した
• ✓ plugin/CLI の breaking rename（doctor 等）をチートシート化した

制約・注意点

• cclens/ccusage の数値は usage signal / 推定であり、最終請求ではない
• optimize は追加トークンを消費し得る
• 古いチュートリアルの summary / friction 等は無効（リネーム済み）
• 発見元の紹介記事の人気度は採用理由にしない

---

筆者の観点

比較の軸は次の3点に絞ると判断がぶれにくいです。

判断の3軸

次の3点を先に固定します。

1. 組織向けダッシュボードで答えたい問いか、現場の摩擦・コスト信号で答えたい問いか
2. ツールを増やす前に、観測項目を1つに固定できるか
3. ローカル transcript を扱うとき、個人端末と共有端末で秘密情報ポリシーを分けられるか

よくある取り違え

「1つの画面でコスト・摩擦・組織KPIを同時に解決する」期待は外しやすいです。

公開ドキュメントと第三者の現場レポートが示すのは、説明責任・活動状況の可視化と、改善の手がかり抽出が別レイヤである、という点です。

READYFOR の偏り（CLAUDE.md 追加への集中）は、ルール文章の増殖が短期では気持ちよくても、hook や skill の自動化の方が効く場面がある、という注意にもなります。

---

よくある質問（FAQ）

Q1. Pro/Max だけでも公式 Analytics で十分ですか？

• 組織ダッシュボードは Team/Enterprise/Console 向けです
• 個人は /usage・/context とローカル CLI が主戦場になります（JA Help / Shipyard）

Q2. cclens と ccusage はどちらを先に入れるべきですか？

• コスト履歴が先なら ccusage（npx 一発）
• 設定ムダ・失敗パターンなら cclens
• 多くの場合は併用が合理的です

Q3. cclens はデータを外部送信しますか？

• README は read-only・送信なしと説明しています
• store はローカル SQLite です
• ただし transcript 自体に秘密が含まれる前提で扱ってください

Q4. 公式 contribution の数字は過大評価ですか？

• EN docs は保守的 underestimate と明記しています
• 高信頼一致のみ、実質的な大幅書き換えは非計上、生成物除外などのルールがあります

Q5. /insights だけでチーム改善できますか？

• READYFOR は横断俯瞰には有用だが session-level 振り返りには不足と位置付け、hook 総括を併用しています
• CLAUDE.md 追加偏重を避け、hook/スキル自動化も検討してください

Q6. cc-lens（Arindam）と cclens は同じですか？

• 別実装です
• 前者は dashboard UI、後者は doctor/optimize/SQL の CLI レンズです
• 名前が似るのでリポジトリを確認してください

---

関連記事:

• Claude CodeとCodexの設定同期｜CLAUDE.mdとAGENTS.mdのズレを防ぐ
• CLAUDE.md設計パターン｜個人・チーム・モノレポで使い分ける構成と肥大化対策

まとめ

• 公式は組織KPI、ローカルは個人/現場の摩擦とコスト信号、と役割を分ける
• cclens は「何を直すか」、ccusage は「いくら使ったか」、公式は「誰がどう採用しているか」
• 次アクション: 目的1つ → 主ツール1つ → 1週間1改善 → 金額は請求画面で確認
• 判断材料は公式 docs と独立実装・運用報告。発見元の紹介記事は入口に留める

関連して設定面を整えるなら、Claude CodeとCodexの設定同期｜CLAUDE.mdとAGENTS.mdのズレを防ぐ や CLAUDE.md設計パターン｜個人・チーム・モノレポで使い分ける構成と肥大化対策、マルチエージェント連携の OpenAI Codex plugin for Claude Code もあわせて参照してください。