Claude Code telemetryのユーザー属性を監査へつなぐ

結論：Apps Gatewayのtelemetryに属性が加わったが、収集と監視の承認は別に設計する

一次情報はClaude Code公式changelogの2.1.265、および公式Monitoring usageです。前者は属性が追加されたsurfaceとApps Gateway経路を明記し、後者はmetrics、events、traces、managed settingsなどの観測設計を説明します。契約やプライバシー条件は別のAnthropic公式契約・管理文書で確認し、changelogにない保持期間を推測しません。

属性・surface・利用目的を比較する

確認軸	今回のreadbackで言えること	企業側で決めること
属性	user.emailとuser.groupsがtelemetryへ追加	識別の必要性、マスキング、閲覧者
surface	Claude DesktopとCowork	Terminal、Web、別gatewayへ一般化しない
経路	Claude apps gatewayへ送信	設定、契約、送信先、委託関係を確認
目的	terminal sessionsと属性軸をそろえる方向	費用、品質、障害のどの判断に使うか

最初に決めるべきなのは、属性を「誰が使ったか」の監視に使うのか、「どのgroupで導入が止まっているか」の改善に使うのかです。目的が後者なら、メールアドレスをそのままBIへ流さず、group単位や不可逆な内部IDへ変換できる場合があります。目的と最小データが一致しない設計は、後で削除や説明が難しくなります。

また、DesktopとCoworkをterminalと同じに扱うことにも注意が必要です。今回の更新は属性の整合方向を示しますが、surfaceごとの設定、利用者、契約、送信内容まで同一とは限りません。公式に書かれた対象を超えて「全Claudeに同じ属性がある」と断定せず、環境ごとにreadbackします。

導入手順：telemetryを本番監査へ入れる前の8ステップ

1. Claude CodeとDesktop、Cowork、Apps Gatewayのversion・契約経路・管理者を台帳へ書きます。
2. 目的を一文で固定し、費用、障害、利用率、品質など、属性を使う判断を一つ以上定義します。
3. user.emailとuser.groupsを誰が閲覧し、何日保存し、いつ削除するかを決めます。
4. 対象surfaceをDesktopとCoworkに限定し、Terminalや別の送信経路へ推測で適用しません。
5. テストgroupのダミー利用者でtelemetryを送り、属性の有無、値の形式、欠損時の挙動をreadbackします。
6. メールアドレスの直接表示が本当に必要か確認し、group集計、内部ID、マスキングなどの代替を比較します。
7. 閲覧権限、監査ログ、通知文、データ主体からの問い合わせと削除手順を確認します。
8. 承認後に限定groupへ段階導入し、送信量、欠損、誤紐付け、目的外利用がないかレビューします。

テストでは、正常なメールアドレスだけでなく、groupが空、変更された、アカウントが無効になったケースを用意します。属性が欠けた時に個人へ誤った責任を帰さないよう、欠損を「未観測」として扱い、ゼロ利用と区別します。データの値をチャットやログへそのまま貼らないことも重要です。

Apps Gatewayの設定を変えたら、期待した属性だけでなく、送信先、アクセス権、保存先、下流のBIやアラートも確認します。監査のために収集した情報が、別の部署の評価表へ無制限にコピーされると目的が変わります。用途ごとに必要な列だけを渡す境界を置きます。

企業運用の判断：テレメトリを評価制度と混ぜない

導入初期は、user属性を個人の評価や処分へ直結させず、導入障害を見つける補助線として使います。例えば「特定groupだけlogin失敗が多い」「Desktopだけ属性欠損がある」「Coworkの利用はあるが成果物レビューがない」といった状態を発見し、支援や設定修正へつなげます。単一の利用量を生産性と呼ばないでください。

既存の監査ログの設計は判断記録、コスト管理は利用量と費用、Enterpriseの安全設計は契約・権限・データ境界を扱います。今回の記事は、telemetryに属性を加える更新を、目的外利用のない観測設計へつなぐ検索意図に限定します。

公式の属性名が分かっただけで、保存期間や法的根拠を決めることはできません。実際の契約、社内規程、従業員への通知、委託先管理を確認し、分からない項目は送らない・見せない・保存しないという保守的な判断を取ります。実装担当、セキュリティ、法務、現場管理者の責任を分けて承認します。

チェックリスト：user属性を有効化する前に

2.1.265以降か／対象がDesktop・CoworkのApps Gateway経路か／目的が一文で書けるか／emailとgroupsの必要性を比較したか／欠損と変更を試験したか／保存期間と削除を決めたか／閲覧者を最小化したか／Terminal等へ一般化していないか／個人評価へ直結させないか／送信内容と下流destinationを記録したか、を確認します。

readbackで属性が見えない場合は、直ちに「送られていない」と決めず、version、surface、gateway設定、テストユーザー、収集側のフィルタを順に確認します。逆に値が見えた場合も、本番の全利用者へ拡大する前に、目的外の下流利用がないかを確認します。観測できることと、保存・共有してよいことを分けるのが安全運用の基準です。

よくある質問

user.emailとuser.groupsは利用者の評価用ですか？

公式changelogはtelemetry属性の追加を説明していますが、評価への利用を承認しているわけではありません。導入支援、費用、障害など目的を限定し、目的外利用を防ぎます。

DesktopとCowork以外にも属性がありますか？

今回確認した更新の対象はClaude DesktopとCoworkがClaude apps gatewayへ送るtelemetryです。TerminalやWebを同一とせず、各surfaceと契約経路を個別に確認します。

メールアドレスをそのまま保存すべきですか？

必要性を先に判断します。group集計や内部IDで目的を達成できるなら、直接識別子を下流へ渡さない設計を比較します。保存期間と削除も同時に決めます。

公式情報と無料診断

属性の追加範囲はClaude Code公式changelog、観測項目と設定はMonitoring usageで公開直前に確認します。Miraigentの無料診断では、Claudeのsurface、telemetry、権限、保存、監査、説明責任を業務に合わせて整理できます。