AIコーディングエージェントを複数使い分けていると、「今月どのエージェントにどれだけトークンを使ったか」を把握するのが難しくなりがちです。Claude Code、Cursor、Gemini CLI、Codex CLIとそれぞれログの置き場所が異なり、料金感覚もつかみにくい。そこに目をつけたのが、junhoyeo氏が開発した tokscale です。ターミナルから一発で全エージェントのトークン消費を集計できるCLIツールで、リポジトリの紹介と設計上の工夫を一緒に見ていきます。
どんなツールか
tokscale は、ローカルに散らばったAIコーディングエージェントのログファイルを読み取り、トークン使用量とコストをまとめて表示するCLIツールです。対応エージェントは記事執筆時点で40を超えており、Claude Code、OpenCode、Cursor IDE、Gemini CLI、Codex CLI、GitHub Copilot CLI、Roo Code、Cline、Zed Agent など主要どころはほぼ網羅されています。
TUI（ターミナルUI）画面では、エージェント別の集計、モデル別の内訳、日次サマリー、統計グラフがタブ切り替えで確認できます。さらに bunx tokscale@latest submit コマンドを実行すると、使用データをグローバルリーダーボードに送信して公開プロフィールを作成することもできます。ウェブ版（tokscale.ai）では3Dコントリビューショングラフやラップアップレポートも提供されており、CLI単体で完結させるか、ウェブと組み合わせて使うかを選べます。MITライセンスで公開されており、商用利用も含めて制限は少ない構成です。
設計でここが上手い
エージェントごとにデータ取得方法を分けている
tokscale が扱うエージェントのログ形式は、SQLiteデータベース、JSONLファイル、CSVエクスポートなど実にばらばらです。それぞれに対して個別のパーサーを用意し、ユーザーが意識しなくて済む形に抽象化しています。たとえばCursor IDEはAPIエクスポートをキャッシュする方式で、Claude Codeは ~/.claude/projects/ 以下のJSONLを直接読み取ります。データの取得ロジックとUIの表示ロジックを分離しているため、新しいエージェントの対応を追加するときも既存のコードを壊しにくい構造になっています。
オンデマンド設計で不要な処理を増やさない
ログファイルを読む対象は、ローカルマシン上にすでに存在するファイルです。エージェント側に特別なプラグインを入れたり、設定を変更したりする必要はありません。使いたいときにコマンドを叩くだけで完結する設計は、導入コストをゼロに近づけながら、バックグラウンドで常駐するプロセスも持たないため、トークン経済の観点でも無駄が少ないと言えます。一部のエージェント（Cursor IDE、Trae IDE、Warp）はAPIからのキャッシュ取得が必要ですが、それも tokscale cursor sync のようなサブコマンドで明示的に行う形であり、自動で外部通信が走るわけではありません。
単一機能への絞り込み
tokscale がやることは「トークン消費を集計して見せる」だけです。エージェントを起動したり、プロンプトを管理したりする機能は持ちません。機能を絞ったことで、コアのパーサー精度を上げることに開発リソースを集中できており、各エージェントの環境変数による上書き（CODEBUFF_DATA_DIR、SENPI_CODING_AGENT_DIRなど）もきちんと拾える程度の細かさがあります。自分が使うエージェントのログパスが標準と違う場合でも、環境変数で対応できるのは実運用で助かる点です。
リーダーボードというソーシャルフック
機能だけを見ると地味なツールですが、グローバルリーダーボードとWrapped 2025（年間まとめ）という仕掛けを入れることで、使い続けるモチベーションを作っています。自分のトークン消費量を他のエンジニアと比較できる場を用意することで、データを提出するユーザーが増え、リーダーボードの質も上がる。この構造は、ユーティリティツールとしてのtokscaleを「続けて使うもの」に育てる上でうまく機能していると感じます。
こういう人に向くかも
複数のAIコーディングエージェントを同時期に試しているエンジニアに特に向きます。「先月はClaude Codeに集中したけど、今月はOpenCodeも使い始めた。実際どちらが多い？」という素朴な疑問を可視化するのにちょうどいいサイズです。
またフリーランスや個人開発者で、月ごとのAIツール費用をざっくり把握したい人にも使いやすいと思います。Cursor IDE のように API 経由でコスト情報を取得するものはそのままでは数字が見えにくいですが、tokscale のキャッシュ取得コマンドを経由すれば一箇所にまとめられます。逆に言うと、エージェントをひとつしか使っていない場合や、クラウド側の請求ダッシュボードで十分管理できている場合は、このツールを入れるメリットはそこまで大きくないかもしれません。
設計の良し悪しをどこで見るか
tokscale を評価するうえで気になる軸をいくつか挙げます。
ドキュメントの深度 という観点では、READMEに全エージェントのデータパスが丁寧に記載されており、環境変数による上書きの情報も揃っています。これは実際に使ってみてエラーが出たときのデバッグコストを下げる設計です。ただし、各エージェントのパーサーがどのフィールドをどう集計しているかという詳細なドキュメントは薄めなので、「集計結果が想定と違う」という場面ではコードを読む必要が出てくるかもしれません。
想定外の使われ方への備え は、環境変数による上書きをほぼ全エージェントに用意している点で一定の配慮があります。ただし、CI環境でチーム全員の使用量を集計したいとか、カスタムのログパスに書いているエージェントがある、といったケースでどこまで対応できるかは、実際に試してみないと分からない部分もあります。
メンテナンスの継続性 については、スター数5,000超えというのはある程度のコミュニティ規模があることを示しており、READMEには英語・韓国語・日本語・中国語の多言語対応も確認できます。junhoyeo氏は毎週新しいオープンソース成果物を出すと宣言しており、Discord コミュニティも存在します。一方で、対応エージェントが40を超えてくると、それぞれのログ形式変更への追従が継続的な負担になる点は意識しておく価値があります。たとえば OpenCode が v1.2 でストレージ形式を変えたときにも対応が入っているのは、現状では機能しているサインです。しかし、エージェント側の仕様変更がどのくらいの頻度で起きるかを考えると、このリポジトリのメンテナンス頻度は今後も注目してよいと思います。
機能の単一性 という軸で見ると、「トークンを計測して見せる」以外のことをしない設計は潔いです。リーダーボードへの送信もオプトインで、強制はありません。コア機能とオプション機能の境界がはっきりしているツールは、将来的に使わなくなっても副作用が少ないという安心感があります。
自分が書くなら、どこを変えるか
個人的に気になるのは、トークン消費の集計方法がエージェントによって「実測値」と「推計値」で混在している点です。たとえば Command Code は「~4 chars/token」という概算で推計していると明記されており、Freebuff も同様です。集計画面でこの区別が視覚的にどこまで伝わるかが不明で、実測値と推計値が同じグラフに乗ると、精度の差が分かりにくくなります。
もし自分が設計するなら、各エージェントの集計方法（直接読み取り／API取得／推計）を凡例として表示するUIを入れるかなと思います。ユーザーが「この数字はどこまで信頼していいか」を判断できるようにするためです。推計値が混ざること自体は仕方がないとして、それが「推計である」と分かる状態にするだけで、数字の読み方が変わります。コスト管理ツールとしての信頼性は、精度そのものより「精度の説明」に依存するケースが多いからです。
導入を検討するときのチェック観点
- 自分が使っているエージェントが対応リストに含まれているか（40超えあるが全部ではない）
- ログファイルのデフォルトパスが標準構成に合っているか、あるいは環境変数で上書きできるか
- Cursor IDEやWarpなどAPIキャッシュが必要なエージェントを使っている場合、認証フローに問題がないか
- チームで使う場合、個々のマシンにインストールするのか、共有環境で集計するのかを整理しておく
- 集計数字の「実測」と「推計」の混在が許容できるか、精度要件を確認する
- リーダーボードに参加する場合、どのデータを外部送信するかREADMEで確認する
- Node.js（またはBun）の実行環境がローカルに用意できているか
測定値の置き方
AIコーディングエージェントは増え続けており、トークン消費の全体像を把握するのは個人でも会社でもじわじわ切実になっています。tokscale はその問題に対して、ログを読むだけという最小限の介入で答えを出しています。精度の課題や対応エージェントの追従コストなど気になる点はありますが、「ゼロコストで今すぐ概算を知る」という用途には十分な実力を持つツールです。導入する前に、自分が何を知りたくてこのツールを使うのかを一度整理しておくと、数字の読み方が変わってくるかもしれません。
