Gitで公開しています
用途
イベントで取れるものはログに書き出してsessionが開始した時にログを空にしています。
なのでセッションごとのトークン数のみをカウントします、プランのトークン数の上限を見たいなどには使えません。
そういったニーズには下段の「Claude-Code-Usage-Monitor」とかの方がいいかと思います
簡単な使い方
使い方はGitのReadmeにありますが、ここにも簡単に記載します
- hooksの設定をする
- claudeCodeを立ち上げる
- しばらく作業する
- 下記のコマンドをうつ
/tokens-verbose
打つと下記のように表示されます
詳細トークン使用状況
合計: 53,282トークン (53.3%)
[################..............]
カテゴリ別内訳
- ユーザー入力: 266トークン
- ファイル読み込み: 21,189トークン
- token-calculator.js: 4,538トークン (19.1 KB)
- claude.md: 861トークン (3.9 KB)
- README.md: 1,306トークン (5.3 KB)
- README_jp.md: 1,924トークン (6.9 KB)
- token-calculator.json: 127トークン (507 B)
- ファイル書き込み: 30,966トークン
- 初期コンテキスト: 861トークン
最近のユーザー入力
1. /tokens-verbose コマンド (4トークン)
2. /tokens コマンド (2トークン)
3. "readmeを更新して" (10トークン)
4. /tokens コマンド (2トークン)
5. /tokens-verbose コマンド (4トークン)
言語判定
日本語コンテンツ: 60% (日本語として計算)
コンテキストウィンドウ
使用率 53.3% - 残り46.7%の余裕があります。
精度について
残念ながらHooksのイベントで取れないデータがあると判明しました。
トークン数が取れるもの
- 会話履歴
- 参照ファイル
- AIが書いた文書ファイル
トークン数が取れないもの
- Web参照、Web検索の結果
- Grepなどの検索結果
- 会話履歴が圧縮された後の要約のトークン数
WebFetch WebSearch
Web経由のデータは一旦APIの向こう側で要約されローカルPCに渡されるのですが、これが現状は取得できません。
会話の中で「ClaudeCodeに検索結果の内容を教えて」といえば出してくれます。
AIはWebに情報を探しにいったとき、掴んだ情報によってその後の作業の精度が左右されるのでこの情報は今後取れるようにして欲しいところです。
会話履歴の要約
これもHooks経由で取得できませんでした、圧縮されて全体のコンテキスト量が改善されるのはいいのですが何が情報として抜け落ちるのかわからないので非常に不便です。
ただ圧縮された情報と生のものを人類が見比べて、ここが情報として抜けてるので再度会話の中で注意するようにする、なんで使い方はしないと思うので要約自体が取れないのはいいと思います。
ただ要約した結果、現在のコンテキストがどこまで減っているのかは知りたいところですがそれも取れないので今後に期待したいところです。
重複読み込み
今回のカウントにおいて同一のファイルが2回読み込まれた場合にカウントしない設計としようかと考えたのですが、Claude Code自体の説明ではメモリ上に２重で持っているらしいのでそのままとしました。
もしかしたら読み込んだ時のデータを保持して差分も検知できるようにという配慮かもしれません。
とはいえ完全にClaude Codeの中の動作のことなので憶測の域を出ないです。
開発において
なんで作ったか
Claude Codeがバカになる瞬間として会話履歴の圧縮が起き、今まで長いこと会話の中で振る舞いを訂正していたのに圧縮が発生した後には大部分が忘却に送られるという問題があります。
これを回避するのに英語で書くとか、作業ディレクトリでピンポイントに必要な参照ファイルを読み込ませるなどの適切なコンテキスト管理の工夫が必要なんですが、そうした工夫が目に見える形で見えるといいなと思ったのがきっかけです。
回答精度の劣化に効果あるのか
下記の記事でも書きましたが、生成AIがバカになる問題は七色あるのでコンテキスト量の節約で全て解決するものでもないです。
ただし生成AIとの格闘の中では絶対にやらないことの一つではあるので、わざわざ自分で作らなくても今後、標準で実装されてくるんではないかと予想しています
カスタムコマンドで作る意味あるか？
今回Claude Code上で動作するカスタムコマンドとして作りましたが、AIが会話履歴を考慮して出力を変化させるので、別ターミナルで立ち上げて単にコマンドで打つ方がいいと感じています。
実際 カスタムコマンドの先はNPMに登録したJSです。
とはいえこの先このコードをメンテする気はないのでトークン数を知りたいといった方は下記を使う方がいいかと思います。
仕様駆動で生成AIが100%コードを書くことの苦労
AWSの生成AIエージェントIDE Kiroの概念である仕様駆動開発をClaue Codeでも試したかったのもあり、それ用の開発ガイドラインを作成して、今回試験的に全てのコードをClaude Codeに記述してもらいました。
結果は大きくハマるところとそうでないところで別れました。
よかったところ
/todo,/fixを使った開発プロセスガイドラインを作成し参照させると設計→設計書の設置→詳細設計→製造→テスト設計→テストまで段階を踏んで実行してくれます。
この時、各段階で文書ファイルが残るので途中でPCが落ちても、会話履歴の圧縮が発生しても再開が容易です。
開発においてはちょっとしたTipsというよりはこれからの標準になるんではないかと思います。
今回作った開発ガイドラインは別途記事にします。
ハマったところ
Claude Codeに自由にコードを書かせると、不得意なところも修正し続けるバグのループに陥ることがあります。
今回のケースだとhooksの設定をsetting.local.jsonに記述するところが非常に不安定でAIが「修正の不具合を直します」といって何度もHooksの設定を動かないものに変えてしまっていました。
イベントが発火されてログの出力も確認しているので機能的な修正はトークン計算のコードのみに行えばいいはずですが
なぜなのか繰り返しsetting.local.jsonを修正したがるので困りました。
最終的にclaude.mdに「setting.local.jsonは設定が動作することを確認済みなんで修正禁止」
と記載することで回避しました。
今後の開発利用でもこんなことしないかといけないと思うと恐ろしいです。
今回使った仕様駆動開発のガイドライン
下記の記事に記載しています
まとめ
Hooksを利用することでClaude Codeの内部で何が起きているかを推測できたのは非常に収穫でした。
現時点での生成AIの本質は事前に学習した内容と入力した内容のコンテキストの範囲でもっともらしいことを出力するだけの単一機能であることがよくわかります。
人類がわでは「超知性の誕生」とか「コーディングが不要になる」だとかの未来予想合戦が発生していてノイズが多いですが、末席ながらITに従事するものとしては冷静にこの革命的な技術革新に取り組んでいきたいと思います。
以上現場からでした。