Claude Code telemetryにrepository属性を付ける方法

結論：repositoryの識別に使えるが、先に命名と保持を設計する

更新内容はClaude Code公式changelogの2.1.269に記載されています。収集できるmetrics、events、traces、exporter、managed settingsの考え方は公式Monitoring、設定の適用範囲は公式 settingsで確認します。公式資料にない保持期間や匿名化の効果は、社内仕様として別に定義してください。

repository属性を付ける前の比較

集計対象	分かること	注意点
repository属性付きmetrics	session数などをrepository別に集計	命名規則とcardinalityの増大
events	user promptやcommitなどの出来事	本文・識別子・保持範囲を確認
traces	必要な処理経路の相関	収集量、費用、機微情報の範囲
Gitの監査記録	commit・review・変更の正本	Claude Code telemetryの代替ではない

repository別の利用量が分かると、運用チームは教育対象や負荷の偏りを見つけやすくなります。一方で、repository名をそのままユーザー名、顧客名、案件番号として使うと、telemetryの閲覧範囲が業務上の機密範囲へ広がります。属性を付ける前に、識別子を無害な内部IDへ置き換えるか、対象repositoryを除外するか判断します。

既存のuser.email・user.groupsの記事は利用者属性の目的と閲覧範囲を扱います。Apps GatewayのOTLP転送記事はcollectorやrelayの経路を扱い、監査ログの記事はsession証跡を扱います。今回の記事はVCS repositoryで集計単位を作る時のデータ境界に限定します。

設定・検証手順：8ステップで小さく始める

1. claude --versionで2.1.269以降かを確認し、対象surface、repository、利用者、設定sourceを台帳へ記録します。
2. 目的を一文にします。例えば「repository別のsession数を月次で見て教育施策を決める」のように、不要な収集を正当化しない形にします。
3. repositoryの命名を棚卸しし、顧客名、個人名、メールアドレス、秘密の案件名が含まれないかを確認します。
4. metricsだけで足りるか、eventsやtracesも必要かを決めます。必要性が説明できないsignalsは有効化しません。
5. 検証用repository一つでOTEL_METRICS_INCLUDE_REPOSITORYを有効にし、公式Monitoringの手順でOTLPまたはconsole exporterの到着を確認します。
6. metricsとeventsを同じ期間で読み、vcs.*属性の値、欠落、想定外の高いcardinality、本文への混入を確認します。
7. collector側で属性のマスク、ルーティング、保持、削除、閲覧roleを設定し、開発者が別collectorへ勝手に送れる経路がないかを確認します。
8. 段階展開後も月次で属性一覧、利用目的、アクセスログ、保持期限、repository改名時の対応をレビューします。

公式MonitoringではClaude Codeがmetricsを標準metrics protocol、eventsをlogs/events protocol、必要に応じてtracesをtraces protocolでexportすると説明されています。これらを一つの巨大なログにまとめるのではなく、利用目的と保持期限を分けます。managed settingsで全員へ配る場合も、developerが設定を上書きできるか、送信先とcredentialが固定されるかを確認します。

制限・料金・プライバシーを混同しない

OTEL_METRICS_INCLUDE_REPOSITORYは観測データへ属性を追加する設定であり、Claude Codeのモデル料金や利用上限を変更する設定ではありません。collectorの保存量や外部観測基盤の契約費用が変わる可能性はありますが、具体的な削減額や無料を公式資料から断定しません。増えたデータ量と保持を実測し、費用は自社のproviderと契約で確認します。

また、repository属性が付いても、Gitのcommit正本、PRレビュー、session transcriptの代わりにはなりません。commit eventsにはvcs.ref.head.*が付く場合がありますが、どの状態を証跡と認めるかは業務で決めます。telemetryの欠落や遅延を「作業がなかった」と解釈せず、export失敗、collector停止、設定scopeの違いを別に記録します。

不明なrepositoryを検出した時は、即座に全体を停止するか、該当属性だけを落とすかを事前に決めます。外部collector、proxy、gatewayを経由するなら送信先と認証を台帳化し、秘密情報を環境変数やログへ不用意に複製しません。問題が送信経路ならHTTP hookの許可先とは別のOTLP境界として扱います。

チェックリスト：有効化前に確認する項目

□2.1.269以降か　□収集目的を一文で説明できるか　□repository命名を棚卸ししたか　□顧客名・個人情報の混入を確認したか　□metrics・events・tracesの必要性を分けたか　□検証repositoryで到着を確認したか　□vcs.*属性の欠落とcardinalityを見たか　□collectorの送信先と認証を固定したか　□保持・削除・閲覧roleを決めたか　□Gitやsession証跡との役割を分けたか　□費用を実測する期間を決めたか　□改名・誤送信・停止時の手順を残したか。

よくある質問

repository属性を有効にするとコード内容も送られますか？

設定の説明はVCS repository属性をmetricsとeventsへ付けるものです。コード内容を送る設定とは別ですが、exporter、collector、ログ本文、タグ、保持を自社で確認します。

全repositoryへ一律に付けてよいですか？

先に命名、対象、閲覧、保持、除外を決めます。顧客名や個人情報が含まれるrepositoryは内部IDへの変換や対象外を検討します。

metricsだけで監査できますか？

できません。metrics、events、traces、Git記録は目的が異なります。必要なsignalだけを収集し、欠落や遅延を別の状態として扱います。

公式情報と無料診断

追加設定は公式changelog、収集方式は公式Monitoring、設定scopeは公式 settingsを公開直前にreadbackしました。Miraigentの無料診断では、repository命名、collector、保持、閲覧権限を業務表へ落とし込みます。