Claude CodeのPR attributionの仕組み — タグ付け基準と21日間の判定ウィンドウ
Claude Codeのanalyticsは、マージ済みPRのdiffとセッション記録を突き合わせてClaude Code支援コードを判定します。タグ付け基準・21日間の時間窓・除外ファイルをまとめました。
Claude CodeのPR attributionの仕組み — タグ付け基準と21日間の判定ウィンドウ
Contribution metricsが「このPRはClaude Codeの貢献」と判定するとき、裏では単純な比較が動いています。マージされたPRのdiffと、その前後の時間窓にあるClaude Codeセッションの出力を突き合わせ、一致する行があるかどうかを見る処理です。ダッシュボードの数字が思ったより低い、PRにラベルが付かない、といった場面では、この判定の条件を知っているかどうかで原因の切り分けが変わります。
PR attributionとは何か
Contribution metricsを有効化すると、Claude Codeはマージされたプルリクエストを解析し、どのコードがClaude Codeセッション由来かを判定します。この解析処理がPR attributionです。GitHub側のdiffとClaude Code側のセッション活動という、出どころの違う2つのデータを突き合わせて行を照合します。コミットの署名自体の話はコミットattributionの仕組みを参照してください。
判定は意図的に保守的です。Claude Codeの関与に高い確信度がある行とPRだけを数え、確信が持てないものは「Claude Code支援」に入りません。ダッシュボードの数字は、実際の貢献を過小評価した下限値として読むことになります。
判定は4ステップで動く
マージされたPRごとの判定の流れ
- 1
追加行を抽出する
PRのdiffから、追加された行を取り出します。
- 2
該当セッションを特定する
マージ日を基準にした時間窓の中で、一致しそうなファイルを編集したClaude Codeセッションを探します。
- 3
行を照合する
複数のマッチング戦略で、PRの行とClaude Codeが出力した行を突き合わせます。比較の前に、空白のトリム・連続空白の圧縮・引用符の統一・小文字化という正規化が入ります。
- 4
メトリクスを計算する
AI支援行数と総行数から、PR数・行数の指標を出します。
タグ付けの基準は、Claude Codeセッションで書かれた行がPRに1行でも含まれるかどうかです。PRの大部分が人間の変更でも、確信度の高い1行があれば「Claude Codeあり」の側に数えられます。該当PRにはGitHub上でclaude-code-assistedラベルが付く仕様です。GitHubの検索でこのラベルを絞り込めば、ダッシュボードを開かずにPRを一覧できます(ラベルが付かない報告は後述します)。
21日間の時間窓で何が漏れるか
照合の対象になるのは、マージ日の21日前から2日後までのセッションです。この窓の外にあるセッションは、同じファイルを編集していても判定材料になりません。
たとえば8月1日にマージしたPRなら、窓は7月11日から8月3日までです。6月に下書きして長く寝かせたPRを8月1日にマージすると、7月10日以前の作業は次のように窓の外に落ちます。
8月1日マージのPRで窓に入る作業・入らない作業
- 6月〜7月10日窓の外
この期間にClaude Codeで書いたコードは、attributionの照合材料になりません。
- 7月11日窓の開始
マージ日の21日前。ここからのセッションが照合対象です。
- 8月1日マージ
判定の基準日です。
- 8月3日窓の終了
マージ日の2日後までのセッションが対象です。
ドラフトのまま長く置くPRや、時間をかけて仕上げる大きなPRで「Claude Codeで書いたはずなのに数字に出ない」ときは、まず最初のセッションの日付とマージ日の差を確かめてください。
数字が低く出るもう2つの条件
自動生成っぽいファイルと行は最初から対象外
次のファイル・行は、自動生成されたとみなされて解析の対象から外れます。
- ロックファイル(
package-lock.json、yarn.lock、Cargo.lockなど) - 生成コード(Protobufの出力、ビルド成果物、minifyされたファイル)
- ビルドディレクトリ(
dist/、build/、node_modules/、target/) - テストフィクスチャ(スナップショット、cassette、モックデータ)
- 1,000文字を超える行(minifyまたは自動生成の可能性が高い行)
PR全体が外れるのではなく、該当する行だけが集計に含まれません。手書きのロジックが同じPRにあれば、そちらは通常どおり判定されます。ビルド成果物やロックファイルをまとめて更新するPRは、diffの行数が膨らんでも判定に使われる行はわずかです。
20%を超えて書き直したコードは外れる
Claude Codeが書いたコードでも、開発者が20%を超える差分で大幅に書き直すと、そのコードはClaude Codeの貢献として扱われません。時間窓と違い、こちらは人間が手を入れるほど数字が下がる条件です。
一方、PRの取り込み元・取り込み先のブランチは判定に使われません。feature branchからの通常のマージでも、他のブランチ経由でも、同じロジックが動きます。
PR数と行数は別の基準で数える
同じ判定結果から、2つの指標が別々の粒度で集計されます。
PRs with CC と Lines of code with CC
PRs with CC
attributionされた行が1行でもあれば、そのPR全体を1件として数えます。割合は「PRs with Claude Code (%)」として、マージされた全PRに対して出ます。
Lines of code with CC
正規化の後、3文字を超える行(4文字以上)だけを「有効行」として数えます。空行や、括弧・些末な句読点だけの行は除外されます。
「PRs with CCの割合は高いのにLines of code with CCは伸びない」ときは、attributionされたPRの多くが小さな修正だった可能性があります。
PR以外のメトリクスと集計の範囲
ダッシュボードの上部には、PR系の指標のほかに使用量の指標も並びます。
「Suggestion accept rate」は、Edit・Write・NotebookEditによるコード編集の提案を、利用者が受け入れた割合です。「Lines of code accepted」は、受け入れられたClaude Code由来の行数の合計です。
後者は却下された提案を含まず、後から行が削除されても減りません。PR attributionの「Lines of code with CC」はマージ済みPRの有効行を数えるので、集計の単位が違い、数字が揃うとは限りません。
PRsの推移を見るチャートには、1日あたりのマージ数を日次アクティブユーザー数で割った「PRs per user」もあります。導入が進むにつれて開発者1人あたりの生産性がどう動くかを追うための指標です。
contribution metricsはベータ版で、対象はclaude.aiの組織内のユーザーに限られます。Claude Console API経由の利用やサードパーティ連携の利用は含まれません。
数字もラベルも出ないときの切り分け
attribution自体が動かない条件は、組織の種類で決まります。
| 状況 | 結果 |
|---|---|
| Zero Data Retentionを有効にした組織 | 結果contribution metricsは提供されず、使用量メトリクスだけが表示される |
| Claude Console(API)のユーザー | 結果GitHub連携のcontribution metricsは提供されず、使用量と支出のメトリクスだけが表示される |
| Team / Enterpriseで、GitHub連携が未設定 | 結果使用量データは出るが、contribution metricsには追加設定が要る |
| GitHub Cloud / GitHub Enterprise Server | 結果どちらも対象 |
Team / Enterpriseの場合、設定にはOwnerロールが要り、GitHubの管理者がClaude GitHub appをインストールする必要があります。有効化後、データは通常24時間以内に日次更新で現れます。それでも出ないときは、ダッシュボードに2種類のメッセージのどちらかが出ます。「GitHub app required」はアプリ未導入、「Data processing in progress」は処理中の表示です。後者は数日待ち、アプリの導入も確認します。
ダッシュボード側の設定手順はContribution metricsを有効化してPR貢献を計測する設定手順にまとめています。
ダッシュボードには出るのにラベルが付かない
ドキュメントは、該当PRにclaude-code-assistedラベルが付くと説明しています。ところがGitHubのissue #84743には、ダッシュボードが8月だけで23件のPRを検出しているのに、ラベルが1件も付いていないという報告があります。ラベルが無いのは、報告者が関わる全リポジトリです。
報告者が詳しく調べた1リポジトリでは、マージ済み52件のPRのうち27件にCo-Authored-By: Claudeのコミットが含まれていました。ダッシュボードの検出と同じ規模感だ、というのが報告者の見立てです。
同じ症状は過去にも2件のissue(#69141と#35167)で報告され、どちらも解決前に自動クローズされています。#84743は起票者が、それらの続報として立てたものです。
報告者はGitHub appの導入状態とpull_requests: write権限を確認しています。ZDRでないことも確かめました。マージから数週間〜数か月たったPRが大半で、時間窓の判定はとうに終わっています。そのうえで、ラベルの書き込みだけが起きていないと書いています。issueはopenのままで、2026年9月26日にClaude Code 2.1.283でも再現するという追記が付きました。
報告者の組織では、claude-code-assistedラベルがどのリポジトリにも作られていません。詳しく調べた1リポジトリの52件のマージ済みPRでは、labeledのタイムラインイベントも一度も発火していません。切り分けの最初の一手は、対象リポジトリのラベル一覧にclaude-code-assistedがあるかを見ることです。ラベル一覧はGitHub APIのGET /repos/{owner}/{repo}/labelsで取れます。ここに無ければ、検索しても0件になります。
ラベルが空でもダッシュボードから突き合わせる
ダッシュボードで「Lines of code」表示に切り替えると、同じ内訳をPR数でなく行数で見られます。「Export all users」を押すと、全ユーザーの貢献データをCSVでダウンロードできます。
画面のLeaderboardに出るのは上位10人だけです。エクスポートには、表示された10人に限らず全ユーザーが入ります。ラベルの検索結果が空でも、ダッシュボードとCSVの数字は見比べられます。
プログラムから取りたいとき
Console側でユーザー単位の日次メトリクスを取るには、Admin APIキーでClaude Code Analytics APIを使います。返るのは使用量のメトリクスで、Consoleにはcontribution metricsが無いため、PR attributionの結果は含まれません。
Enterpriseプランでは、Claude Enterprise Analytics APIが、ユーザー単位の利用・コストのレポートをClaude Codeを含む各サービスについて返します。read:analyticsスコープのキーをPrimary Ownerが作成する仕組みで、Teamsプランでは使えません。contribution dataだけを取りたい場合は、GitHubでラベル付きPRを検索するのがドキュメントの示す方法です。上のissueのとおり、ラベルが書き込まれていない環境ではこの経路は空になります。
まとめ
PR attributionの数字は下限値なので、他の組織やツールとの絶対値比較には向きません。PRの規模やレビュー体制が似たチーム内で、自分たちの推移を見る指標として使うのが妥当です。
GitHub PRレビュー自体の運用はClaude CodeでGitHub PR自動レビューを設定・運用する、チーム導入の進め方はClaude Codeチーム導入ガイドで扱っています。