Claude CodeのPR attributionの仕組み — タグ付け基準と21日間の判定ウィンドウ

Contribution metricsが「このPRはClaude Codeの貢献」と判定するとき、裏では単純な比較が動いています。マージされたPRのdiffと、その前後の時間窓にあるClaude Codeセッションの出力を突き合わせ、一致する行があるかどうかを見ています。判定の対象になる行、対象から外れる行、そして21日間という時間窓の意味を追っていきます。

PR attributionとは何か

Contribution metricsを有効化すると、Claude Codeはマージされたプルリクエストを解析し、どのコードがClaude Codeセッション由来かを判定します。この解析処理そのものがPR attributionです。GitHub側のdiffとClaude Code側のセッション記録という、出どころの違う2つのデータを突き合わせる仕組みなので、コミットメッセージや作者名のような表面的な情報だけでは判定できません(コミットの署名自体の話はコミットattributionの仕組みを参照してください)。

判定は保守的です。Claude Codeの関与に高い確信度がある行だけをカウントし、確信が持てない行は「Claude Code支援」に数えません。ダッシュボードの数字が実際の貢献より少なめに出やすいのは、この保守的なマッチングが理由です。

この解析が動くのは、そもそもcontribution metricsが有効な組織だけです。Zero Data Retentionを有効にしている組織ではcontribution metrics自体が提供されないため、attributionの結果も表示されません。

タグ付けの基準

PRが「Claude Codeあり」としてタグ付けされる条件は明快です。Claude Codeセッション中に書かれたコード行が、そのPRの中に1行でも含まれていればタグ付けの対象になります。逆に言えば、PRの大部分が人間の手による変更でも、確信度の高い1行があれば「Claude Codeあり」の側にカウントされます。

タグ付けされたPRは、GitHub上でclaude-code-assistedというラベルが付いた状態でマージされます。ダッシュボードを開かなくても、GitHubの検索でclaude-code-assistedラベルを絞り込めば、対象PRを直接一覧できます。

判定は4ステップで動く

内部の処理は4段階に分かれています。

1. PRのdiffから追加された行を抽出する
2. マージ日を基準にした時間窓の中で、一致しそうなファイルを編集したClaude Codeセッションを特定する
3. 複数のマッチング戦略で、PRの行とClaude Codeが出力した行を照合する
4. AI支援行数と総行数からメトリクスを計算する

比較の前には正規化も入ります。空白をトリムし、連続する空白を1つにまとめ、引用符の表記を統一し、大文字小文字を揃えてから比較します。改行位置やクォートの種類が違うだけで「別のコード」と判定されるのを防ぐための前処理です。

21日間の時間窓が意味すること

マッチング対象になるのは、マージ日の21日前から2日後までのセッションです。ドラフトのまま数週間置かれるPRや、レビュー対応で何度か手直しが入るPRを想定すると、マージ直前の数日だけを見る設計では取りこぼしが出ます。21日という幅は、そうした現実のPRライフサイクルに合わせて確保された猶予です。マージ後2日という短い余白は、マージ直後の軽微な追随コミットまでは拾うが、それ以降の別作業までは含めないという線引きです。

この時間窓の外にあるセッションは、たとえ同じファイルを編集していても判定材料になりません。長期間放置してから一気にマージしたPRでは、21日より前の作業がattributionから漏れます。

具体的な例で考えると分かりやすくなります。あるPRを8月1日にマージした場合、判定材料になるのは7月11日から8月3日までの間に対象ファイルを編集したClaude Codeセッションです。6月中に下書きしたきり長期間放置し、7月10日以前の作業だけでほぼ完成していたPRを8月1日にマージすると、その部分の作業は時間窓の外になり、attributionの対象から漏れます。

集計から除外されるファイル・行

自動生成されたとみなされるファイルは、最初から解析対象の外に置かれています。

• ロックファイル(package-lock.json、yarn.lock、Cargo.lockなど)
• 生成コード(Protobufの出力、ビルド成果物、minifyされたファイル)
• ビルドディレクトリ(dist/、build/、node_modules/、target/)
• テストフィクスチャ(スナップショット、cassette、モックデータ)
• 1,000文字を超える行(minifyまたは自動生成の可能性が高いと判断される)

これらはPR全体を対象から外すわけではなく、該当する行だけが集計に含まれません。手で書いたロジックが同じPRの中にあれば、そちらは通常どおり判定対象になります。フロントエンドのビルド成果物や依存関係ロックファイルをまとめて更新するようなPRでは、diffの行数自体は膨らんでもattributionの計算に使われる行はごくわずかしか残りません。こうしたPRで数字を読むときは、この差を踏まえておくと読み違いを防げます。

20%を超える書き直しはカウントされない

もう1つ見落としやすい条件があります。Claude Codeが最初に書いたコードでも、開発者が20%を超える差分で大幅に書き直した場合、そのコードはClaude Codeの貢献として扱われません。軽微な調整とみなされる範囲を超えると、attributionの対象から外れる仕組みです。

この20%という基準を比率のイメージで捉えると、Claude Codeが最初に書いたコードに対して開発者が加えた書き直しの分量が小さいうちはattributionが維持され、一定を超えると対象から外れる、という境界線になります。レビュー指摘を受けて命名や細部を整える程度の修正なら残りやすく、ロジックそのものを別のアプローチで書き直すような大きな手直しは対象から外れやすくなります。

同様に、PRの取り込み元・取り込み先のブランチが何であるかは判定に一切関係しません。feature branchからの通常のマージでも、他のブランチ経由でも、判定ロジックは同じように動きます。

PR数と行数では集計の粒度が違う

判定結果がダッシュボードにどう積み上がるかを見ると、2種類の指標が別々の粒度でカウントされていることが分かります。「PRs with CC」はPR単位の指標で、attributionされた行が1行でもあればそのPR全体を1件として数えます。一方「Lines of code with CC」は行単位の指標ですが、ここでも生の行数がそのまま使われるわけではありません。正規化を終えた後、3文字を超える行(4文字以上の行)だけを「有効行」として数え、空行や括弧・些末な句読点だけの行は除外します。

つまり同じ判定結果から、PR数ベースの指標と行数ベースの指標がそれぞれ別の基準で集計し直されています。「PRs with CCの割合は高いのに、Lines of code with CCは伸びていない」といった見え方をするときは、attributionされたPRの多くが小さな修正だった可能性を考える材料になります。

よくある質問

1行だけの修正でもタグ付けされますか

されます。基準は「確信度の高いClaude Code由来の行が1行でも含まれるか」で、行数の多さは条件ではありません。

自分で大幅に書き直したコードもカウントされますか

されません。開発者が20%を超える差分で書き直した行は、attributionの対象から外れます。

21日間の時間窓の外にあるセッションはどうなりますか

考慮されません。マージ日の21日前から2日後までに絞ってマッチングするため、それより前のセッションは判定材料になりません。

PRの取り込み元・取り込み先ブランチは判定に影響しますか

影響しません。アルゴリズムはPRのソースブランチ・デスティネーションブランチを区別せずに判定します。

GitHub上でタグ付け済みのPRだけを探せますか

探せます。マージ済みでClaude Code支援コードを含むPRにはclaude-code-assistedラベルが付くので、GitHubの検索でこのラベルを条件に絞り込めば直接一覧できます。

まとめ

PR attributionは、PRのdiffとClaude Codeセッションの出力を正規化したうえで突き合わせ、確信度の高い一致だけをカウントする保守的な仕組みです。判定に使われるのはマージ日の21日前から2日後までのセッションに限られ、ロックファイルや生成コードは最初から対象外、開発者が20%を超えて書き直した行も対象から外れます。有効化の手順はContribution metricsを有効化してPR貢献を計測する設定手順、GitHub連携によるPRレビュー自体を設定したい場合はClaude CodeでGitHub PR自動レビューを設定・運用する、チーム全体への導入の進め方はClaude Codeチーム導入ガイドを参照してください。