「Claude Codeを入れて効果はあったのか」と聞かれて、感覚では答えられても数字で答えられない、という相談を受けることがある。以前の記事では、Anthropicが管理コンソールに利用状況・コストの可視化機能を追加した背景から「何を価値とみなすかを導入前に決めておく」という考え方を紹介した。今回はその続きとして、実際に何がどこまで数字になるのか、公式ドキュメントの記述をもとに具体的に見ていく。

公式に用意されている測定手段の全体像

公式ドキュメントによると、Claude Codeの分析ダッシュボードはプランによって内容が異なる。

プランダッシュボード含まれる内容
Team / Enterpriseclaude.ai/analytics/claude-code利用状況指標（採用したコード行数・提案の採用率・日次アクティブユーザー数・セッション数）、GitHub連携によるコントリビューション指標（Claude Code支援で書かれたPR・コード行数）、リーダーボード、データエクスポート
Console（API）platform.claude.com/claude-code利用状況指標、支出トラッキング、チームインサイト

Team/Enterpriseのコントリビューション指標は、GitHub組織と連携すると「Claude Codeが関与したPR」「Claude Code支援で書かれたコード行数」を集計し、マージ済みPRにclaude-code-assistedラベルを付ける。日次アクティブユーザー数の推移や、ユーザーごとの「1日あたりPR数」の変化を追うチャートもあり、公式ドキュメントはこれを「導入が進むにつれて個人の生産性がどう変わるかを理解するため」の指標と説明している。個人単位・チーム単位の細かい支出把握には、別途OpenTelemetryのエクスポートや、EnterpriseプランならAnalytics APIを使う経路もある。どのプランでどこまで見えるかは、以前まとめたTeam/Enterpriseの選び方とも関わる話だ。

数字をそのまま信じてはいけない理由

ここで注意が要るのは、このダッシュボードの数字が「実態を過大にも過小にも見せない中立な計測」ではなく、公式ドキュメント自身が意図的に保守的な過小評価だと明記している点だ。

コントリビューション指標の集計条件を確認すると、次のような絞り込みが入っている。

公式ドキュメントはこの設計を「Claude Codeの関与に高い確度がある行・PRだけを対象にした保守的な計測で、実際の影響を過小評価している」と自ら説明している。つまりこのダッシュボードの数字は「Claude Codeが最低限どれだけ関わったか」の下限値であって、実態そのものではない。社内で「思ったより低い数字だった」という報告を受け取ったときは、まずこの前提を疑う必要がある。

もう一つの注意点は、「提案の採用率」や「コード行数」は生産性やROIの代理指標にならないということだ。公式ドキュメント自身、コントリビューション指標の使い方を説明する項で「DORAメトリクスやスプリントベロシティなど、既存のエンジニアリングKPIと合わせて使う」ことを勧めている。裏を返せば、Claude Code単独のダッシュボードだけでは判断材料として不十分だと、提供元自身が認めている格好だ。海外のソフトウェア開発組織の分析記事を複数確認すると、採用率は「AIの提案をどれだけ使ったか」という利用量を示すだけで、そのコードが本番で生き残ったか、レビューにどれだけ時間がかかったか、障害につながらなかったかとは連動しない、という指摘が繰り返されている。コードの生成・受け入れにかかる負担が減っても、レビューや検証の負担がそのぶん別の場所に移っているだけ、という見立てだ。数字が出せること自体が測定の妥当性を保証してくれるわけではない。

Team/Enterpriseのコントリビューション指標には、他にも適用条件がある。ベータ機能で、GitHub Cloud/GitHub Enterprise Serverとの連携が前提。Owner権限を持つ管理者がclaude.aiの管理画面で有効化し、GitHub側の管理者がアプリをインストールする必要がある。Zero Data Retentionを有効にしている組織では、この指標自体が使えない（利用状況指標のみ表示される）。導入前に「うちの契約形態・データ保持方針でこの機能が使えるか」を確認しておかないと、後になって指標が出ないことに気づくことになる。

自社で判断する基準

公式の仕組みだけに頼らず、自社で効果を語れるようにするには、次の順序で決めていくのが実務的だ。

まず、公式のコスト管理ドキュメントも勧めているとおり、小さなパイロットグループから始めてベースラインを作る。導入前の状態（PR数・レビュー待ち時間・特定作業の所要時間など、自社が既に追っている指標）を記録しておかないと、導入後の数字と比べる基準がそもそも存在しない。

次に、「Claude Codeが関与したPR/行数」と「関与していないPR/行数」を並べて見る。ダッシュボードのコントリビューション指標はこの比較のために設計されているので、素直に使える。ただし前述の通りこれは下限値なので、絶対値の大小より時系列の変化（導入が進むにつれてユーザーあたりのPR数がどう動いたか）を見る方が意味を持つ。

最後に、一度の計測結果で結論を固定しない。これは実際に手痛い経験をした。このブログを運用しているプロジェクト自身の記録(CLAUDE.md)には、記事26本の時点でGoogle Search Consoleのデータをもとに「クリックが付いた記事は4本だけで、直近6日間毎日書いたニュース記事6本はクリック0件だった」という分析から方針転換した経緯が残っている。その8日後、Google側のインデックス状況を示すステータスを確認すると、一度「Googleに認識されていない」段階まで後退していた記事のうち2本が「発見済み（未インデックス）」の段階まで持ち直していた一方、逆に新着記事の方は1週間経ってもその段階から進んでいなかった。検索結果に表示されるところまで回復したわけではなく、あくまでクロール状況の指標が動いただけだが、当時の記録には「薄いデータから強い構造論を立てない」という反省が明記されている。効果測定の指標は用意して終わりではなく、少ないサンプルから結論を急がず、継続して見て、必要なら見立てを撤回する運用まで含めて設計しておく必要がある。

自社にとって何を「効果」と呼ぶか、どの指標をどのタイミングで見直すかまで含めて整理したい場合は、パイロット・構築のフェーズで一緒に設計できる。まずは30分の無料診断から相談してほしい。