Claude Codeのreceiptsプラグインで/receiptsから利用実績レポートを出す
receiptsプラグインは手元のセッション記録とgit履歴から、成果物とプロジェクト別の利用割合をMarkdownとHTMLにまとめます。期間指定、出力先、数えない項目、プライバシーまで。
receiptsは、自分のClaude Codeのセッション記録から「この利用で何が出来上がったのか」を1本のレポートにする公式プラグインです。上司やチームから「Claude Codeにこれだけ使って、何が得られたのか」と聞かれた場面を想定して作られています。
/receiptsを実行すると、期間内に触ったファイル数、関わったコミット、開いたPRの数、プロジェクト別の利用割合が出ます。Markdownの報告文と、印刷やCSV出力に使えるHTMLの「レシート」の2ファイルが、ホームディレクトリに保存されます。
この記事では導入から期間・プロジェクトの指定、数字の意味、レポートが意図的に出さない項目、外部へ出るデータの範囲までを順に扱います。
receiptsは何を答えるプラグインか
receiptsが答えるのは「その利用に価値があったか」です。使用量が多いか少ないかではなく、何が出荷され、どのプロジェクトに使われたかを示します。
同じ公式マーケットプレイスには、同じセッション記録を読むもう1つのプラグインがあります。2つの違いはREADMEが次のように整理しています。
| プラグイン | 答える問い | 向く場面 |
|---|---|---|
| receipts | 答える問い使った分に見合う成果は何か | 向く場面利用の価値を説明する |
| session-report | 答える問いどこでトークンを無駄にしているか | 向く場面利用を安くする |
session-reportはキャッシュヒット率や高くついたプロンプトを調べ、最適化の候補を返します。詳しい使い方はsession-reportプラグインの解説にあります。コスト削減が目的ならそちら、利用の説明が目的ならreceiptsです。
導入して最初の1枚を出す
公式マーケットプレイスのプラグインなので、導入は1行です。claude-plugins-officialを指定する形になります。@形式と--marketplaceの使い分けはclaude plugin installの導入経路の記事にまとめています。
/plugin install receipts@claude-plugins-official入れたら、引数なしで実行します。既定の対象は直近30日です。
/receiptsREADMEによれば、処理にかかる時間は1週間分で約1秒、1年分で約5秒です。数秒待つだけで、ホームディレクトリに2つのファイルが並びます。どちらも外部には公開されません。
期間とプロジェクトを指定する
引数で期間を変えるか、プロジェクトに絞り込みます。READMEに載っている形は次の5つです。
/receipts # 直近30日(既定)
/receipts week # 直近7日
/receipts quarter # 直近90日
/receipts 14 # 直近14日
/receipts for myrepo # 1つのプロジェクトに絞るスキル本体(SKILL.md)の引数の解釈には、READMEに出てこない書き方もあります。monthは30日で、省略時と同じです。yearは365日です。数字だけを渡すと、その日数として扱われます。
forの後ろの文字列は、プロジェクト名の部分一致として使われ、大文字小文字は区別されません。この絞り込みは合計値も含めてレポート全体に効くため、特定のリポジトリだけの実績を出したいときに向いています。
期間指定の選び方
1週間の振り返り
/receipts week。週次の1on1や日報の下書きに使えます。四半期の評価面談
/receipts quarter。90日分をまとめ、成果物の規模と主なプロジェクトを示せます。案件ごとの報告
/receipts for <プロジェクト名>。ほかの仕事を混ぜず、1つの案件に限った数字を出せます。
出力される2つのファイル
実行が終わると、ホームディレクトリに同じ期間名の2ファイルができます。ファイル名の日付はスクリプトが算出した開始日と終了日で、実行日ではありません。
| ファイル | 用途 |
|---|---|
~/claude-code-receipts-<開始日>-to-<終了日>.md | 用途ドキュメントやレビュー文書に貼る報告文 |
~/claude-code-receipts-<開始日>-to-<終了日>.html | 用途開く、または添付する自己完結のレシート |
HTMLは外部リソースを読み込まない単独のファイルです。ディスクから直接開けるうえ、Export CSVボタンでプロジェクト別の表をCSVにできます。CSVはページに埋め込まれているため、オフラインでも動きます。印刷すると、きれいなPDFにもなります。
生成の途中には一時ファイルとして/tmp/cc-receipt.htmlが使われ、最後に上記の名前でホームへコピーされます。
レポートに載る項目と数字の意味
レポートは3つの部分でできています。
何を出荷したか
触ったファイルの数、触った行数(概数)、その作業を含むコミット、開いたPRの数が出ます。数え方には注意点があります。
- 行数は「触った行数(概数)」と表示されます。編集した範囲の大きさで、差分の純増ではありません。同じ範囲を何度も直すと、そのたびに加算されます。「書いたコード行数」と読み替えないでください。
- コミット数は、本人が作者で、かつ変更ファイルにClaude Codeが触ったものを含むコミットだけです。SHAで重複を除きます。Claude Codeが作ったコミットという意味ではなく、本人が後から手で確定したコミットも含まれます。
- PR数は
gh pr createの実行回数です。作成に成功したPRの数を確認した値ではありません。
スナップショット用のcronやリリースボットのコミットは、Claude Codeが触ったファイルを含まないため、数に入りません。
プロジェクト別の内訳
セッション数、アクティブな日数、各プロジェクトの利用割合が表になります。どのプロジェクトに属するかは、セッションがファイル操作で触った場所から決まります。読み取りだけでも「そのリポジトリでの作業」として数えます。サブエージェントの作業は親セッションに含まれます。
リポジトリの外の作業は、ディレクトリ名で表示されます。ファイルに一度も触れなかったセッション(Web検索、チャットツール、ダッシュボード参照)は「Research & investigation (no project)」という行にまとまります。READMEは、これが多くの人で最大の行になると書いています。
表の下には、合計しない列の注記が付きます。
- セッション数とアクティブ日数: 複数のプロジェクトにまたがるセッションは両方の行に入る
- コミット数: 同じリポジトリのworktreeは別の行になるが履歴を共有するため、1つのコミットが2行に出ることがある(総計ではSHAで重複除去)
- 利用割合: 丸めると、1%未満の行が消えるため100%にならないことがある
上司への見せ方
最後に、2〜3文の「見せ方」の提案が付きます。活動量ではなく出荷した成果から始めること、ローカルの1台から作った自己申告の数字だと明記すること、手で具体的な成果を1〜2件足すことが骨子です。
組織が検証済みのエンジニアリング指標を公開しているなら、見出しの数字はそちらを引き、receiptsは手元ですぐ作れる補足として使う、という位置づけも示されます。
出さない項目が信頼性の中身になる
receiptsは、金額・時間・作業別の内訳を意図的に出しません。READMEは理由を「推測を計測のように見せると、1つの悪い数字でページ全体の信用が落ちるから」と説明しています。
- 金額: ローカルのトークン数から計算した金額は推定でしかなく、実際の請求額と合わない
- 削減時間: ローカルデータには比較の基準がなく、倍率を作ると根拠がなくなる
- 作業別の支出内訳: 1ターンの費用の大半は文脈の処理で、その半分は以前のターンが積んだ内容の読み直し。どのツールに費用を割り当てるかは設計上の選択で、その選び方で答えが変わる
スキルの説明には、定義の置き方で結果が変わる例が出てきます。実際の1か月のデータで、Web検索の割合が3通りの妥当な定義で11%、28%、51%になるという例です。支出は「プロジェクト単位」にだけ割り当てられます。セッション全体の費用を、どのプロジェクトに役立ったかで割る方法なら、定義に左右されません。
なお、金額を知りたいときは別の手段になります。コスト集計はccusageの使い方で扱っています。履歴からトークンの行き先を診断する公式プラグインもあります(ai-adoptionプラグインのtoken-doctor)。
外部に出るデータと、渡す前の確認
処理はすべてローカルで完結します。ファイルの読み取りと読み取り専用のgitだけで、ネットワーク通信は行いません。
読み込む対象は~/.claude/projects/**/*.jsonl、つまりディスクに残っている自分のセッション履歴です。どのディレクトリがgitリポジトリかを判定するために、各ディレクトリでgit rev-parseを実行します。リポジトリならuser.emailを読み、git logを実行します。メールアドレスはコミットの作者照合にだけ使い、送信しません。
モデルに渡るのは小さな要約だけです。
| モデルに渡る | 渡らない |
|---|---|
git configの名前 | 渡らないコード |
| 集計した件数 | 渡らない会話の内容 |
| プロジェクト名 | 渡らないツール名・MCPサーバー名 |
接続しているサービスの一覧は、端末の外に出ません。
プロジェクト名はレポートにそのまま載ります。社内のコードネームや顧客名、未発表のプロジェクト名がディレクトリ名になっていることもあります。そのためスキルは、保存後に「このレシートに載っているプロジェクト名」を一行で読み上げます。誰かに送る前にそこで確認してください。載せたくない名前があれば、/receipts for <プロジェクト名>で範囲を絞って作り直せます。HTMLを手で編集することもできます。
レシートを共有用のページとして公開する場合も、既定では何も公開しません。ユーザーが明示的に頼み、プロジェクト名の確認を済ませた後でだけ行う、という手順がスキルに書かれています。
つまずきやすい点
数字が想定と違うときは、次の順に確認します。
数字が合わないときの確認順
- Qコミット数が「–」か「?」になっていませんか?答えがいいえのとき答えがはい
「–」は、リポジトリでない、またはClaude Codeの作業を含むコミットがないという意味です。「?」はgitが読めなかったプロジェクトで、ゼロではなく不明を表します。
- Q研究・調査が中心の期間でしたか?答えがいいえのとき答えがはい
ファイルに触れない作業が多い期間は、コミットが0になるのが正常です。「Research & investigation」の行が大きくなります。
- Q想定のプロジェクトが「everything else」に入っていませんか?答えがいいえのとき答えがはい
表に出るのは利用割合の上位12件で、残りは1行にまとまります。見たいプロジェクトは
forで絞ると単独で出せます。
期間とプロジェクトを絞って再実行
合計値は絞った対象だけで計算されます。複数の実行結果を足し合わせないでください。
まとめ
receiptsは、利用料の説明ではなく「成果の説明」に特化した設計です。金額や削減時間を出さない代わりに、後から質問されても崩れにくい数字だけを並べます。評価面談や上長への報告の材料として、weekやquarterで期間を決め、載ったプロジェクト名を確認してから渡す、という使い方が想定されています。トークン消費を減らす目的なら、session-reportのほうが答えを持っています。