AI活用でスループットとレビュー負荷が2倍に ── 活用の効果と課題

supateam プロダクト責任者の若月です。

「AIにいくら使って、スループットがどれくらい上がっているのか?」

AIコーディングツールの全社導入が進む中、多くの組織で同じ問いが出てきているのではないでしょうか。

今回は、社内の約15名を対象にClaude CodeのOpenTelemetryログとGitHubのPRデータ、各AIプロバイダのコスト情報を突合し、AIコストとスループットの相関、そしてPRの品質への影響を分析しました。

※ 今回扱うデータにはユーザープロンプトの内容は一切含まれていません。プライバシーを保ったまま活用度だけを計測できる仕組みになっています。


1. AIの利用メトリクス(OpenTelemetry・Cursor)とGitHubデータからわかったこと

AIの積極的活用によってスループットが向上

6ヶ月間のAIのヘビーユーザー(コスト上位)のアウトプットを追うと、 AIコストとコード上のスループットに相関があり、特にPR数に大きな差がありました。

上位メンバーにおいては、プロダクトの成熟期にも関わらずエージェントモードの活用・習熟によってPRサイズは変わらずPR作成数が2倍に増加しており、AIの使い方や習熟度がスループットに影響を与えることも分かりました。

1-2. スループットが増えた結果、組織のレビュー負荷が上がっている

スループット(PR数・変更行数)の増加に伴って、PRあたりの平均レビュー回数が1.0回(2025年4月)→3.2回(2026年2月)に増加していました。

内訳を見ると、人間のレビュー回数は0.96→1.92で約2倍。残りの増分はAIレビュー(botによるコメント)で、2026年2月にはAIのレビュー回数が人間に匹敵する水準に達しています。

スループットが上がった分、レビュー側の負荷が増えており、AIが作成したPRの品質向上や、認知負荷の低減がチームのスループットを阻む要因となっている可能性があります。


2. Claude Codeの分析手法(2026年4月現在)

2-1. Claude Teamプランのコスト・トークン数を分析する

2026年4月現在、Claude Teamプランにはダッシュボードや利用分析APIが提供されていません。「誰がどれだけ使っているか」を把握するには、Claude CodeのOpenTelemetry(OTel)エクスポート機能を利用する必要があります。

主に取得できるデータは以下の通りです。

メトリクス(時系列データ)

  • claude_code.cost.usage ── APIコスト(モデル別)
  • claude_code.tokens.usage ── トークン数(input/output/cache_read/cache_creation)
  • claude_code.lines_of_code.count ── AI生成行数(added/removed)
  • claude_code.active_time.total ── アクティブ時間(cli/user)
  • claude_code.code_edit_tool.decision ── コード編集の採用/却下

ログ(イベントデータ) - セッションID、ユーザーメール、ツール呼び出し(Read/Edit/Agent/WebSearch等)、プロンプトイベント

これらを組み合わせることで、メンバー別のコスト、トークン消費量、AI生成行数、ツール利用パターンが可視化できます。

2-2. supateam MCPでの分析環境セットアップ

supateamでは、OTelデータをDuckDBに蓄積し、MCP経由で自然言語クエリを実行できます。 またCursorの利用データ分析もAdmin APIキーを設定するだけで可能となります。

claude mcp add supateam-mcp-server -s local -- \
    npx mcp-remote https://api.supateam.com/public/v1/mcp \
    --header "Authorization: Bearer sk-..."

呼び方の例

# ユーザー別の月間AIコストを出す
> supateam MCPで、3月のユーザー別AIコストを集計して

# マージ済みPRを検索する
> 3月にマージされたPRを、botを除外して一覧で出して

# AIコストとスループットを突合する
> 3月のAIコストとPR数・変更行数を突合して、ユーザーごとに比較して

MCPを通じて自然言語で依頼するだけで、OTelへのDuckDBクエリとGitHub PR検索が実行され、突合分析が返ってきます。


まとめ

OpenTelemetryとGitHubのPRデータを突合することで、「AIにいくら使って何が起きているか」を定量的に把握できるようになりました。

また今回はあくまでスループットを計測したものであり、コード負債や変更のビジネスインパクトを考慮したものではないため、定性的なヒアリングや各チームの文脈の重要性も改めて感じました。


supateamについて

supateam.com

supateamは、AI時代の開発組織を支援する開発生産性プラットフォームです。

本記事で紹介した分析は、supateam MCPのOpenTelemetry/GitHub分析機能を使って実施しました。MCPを活用することによって、Claude Code OpenTelemetryデータの蓄積・可視化、GitHub PRデータとの突合分析を、コードを書くことなく自然言語で実行することができます。

変更のリードタイム・PRの平均レビュー数・変更障害率といったFour Keys指標に加え、AIコーディングツールの活用状況やPRあたりのAIコストを定点観測するためのダッシュボードとしてご活用いただけます。

Uberにおける、人間のレビューよりも"有用"なAIレビューエージェントの構築事例

,

supateam プロダクト責任者の若月です。

直近、AIレビューを導入する企業が増え、その有用性についても様々な議論が盛り上がっています。

今回はUberにおいて、人間のレビューよりも対応される独自のレビューエージェントを構築し、

週65,000件のAIレビュー及びエンジニアからの75%という高い有用性評価を得ているという事例についてまとめました。

元記事:uReview: Scalable, Trustworthy GenAI for Code Review at Uber

AIレビュー導入のアンチパターン - 対応されない大量のAIレビュー

よくあるチームへのAIレビュー導入のアンチパターンとして、

不十分な設定でAIレビューエージェントを導入し、的外れなAIレビューが増加し、 オオカミ少年効果を引き起こしさらにAIレビューが見られなくなり、メンテナンスされ無くなるといった負のループの発生が挙げられます。

一方でUberではレビュー精度にフォーカスし、

人間のレビューよりも有用なAIレビューを独自に構築した「uReview」という内製システムを構築しており、

AIレビューの対応率(インラインコメントの対象コード行がその後outdatedになった率としてsupateamでも計測可能)や エンジニアからの有用性評価について観測し、その精度を評価しています。

AIのコードレビューコメントは、人間より「対応される」── UberのuReview事例から学ぶ精度優先設計

AIコーディングツールの普及によって開発速度は大きく上がりました。一方で、レビュー側の課題についてはあまり語られていません。

AIが生成したコードは、人間が書いたコードと比べて「論理エラーが1.75倍・XSS脆弱性が2.74倍」含まれるというデータがあります。コーディングを加速するほど、レビューの質がより重要になります。しかしレビュアーのリソースは有限であり、PRの量だけが増え続けるという状況が多くの組織で起きています。

Uberは2025年8月の、この問題への取り組みとして内製AIコードレビューシステム「uReview」の詳細を公開しました。

発表時点で週65,000件以上のコードdiffをAIがレビューし、エンジニアの有用性評価75%以上を維持していると記載されています。

この事例でとくに注目すべきは、AIのコメント対応率が人間レビュアーを上回ったという点です。


uReviewとは

  • Uberが内製したAIコードレビューシステム(2025年8月に詳細公開)
  • 週65,000件以上のコードdiffをカバー(カバレッジ90%以上)
  • Go・Java・Android・iOS・TypeScript・Pythonの6つのモノレポにまたがる
  • エンジニアの有用性評価75%以上、コメント対応率65%以上を維持

Uberのエンジニア規模を考えると、週65,000件というのはほぼ全てのコード変更をAIがレビューしている状態に近いといえます。


なぜサードパーティを使わず内製したか

uReviewを構築する前に、Uberは市場のAIコードレビューツールを一通り評価しましたが、結果として全て見送ることになりました。

その理由として以下の3つが挙げられています。

① GitHubが前提のツールが多い UberはPhabricatorをコードレビュー基盤に使用していたが、 GitHub連携が前提のサードパーティツールはそもそも導入できなかった。

② 品質が基準に達しなかった 実際に評価すると偽陽性が多く、低品質な真陽性が目立ちました。 加えてUber固有のコーディング規約や内部ドキュメントとの連携ができず、実用に耐えるものではありませんでした。

③ コストが合わない 週65,000件の規模でサードパーティを動かすと、自前運用より1桁高いコストになることがわかりました。

これらの理由から、内製という選択に至っています。


4段階パイプラインの設計

uReviewは「コードレビュー」という複雑なタスクを4つのサブタスクに分解しています。

uReviewのパイプライン図 パイプラインのDAG構造(出典:Uber Engineering Blog)

① 前処理 設定ファイル・自動生成コード・実験ディレクトリを除外します。

LLMに渡す前にノイズを最初に取り除くことで、レビュー精度を高めています。

② コメント生成 3つの専門アシスタントが並列で起動し、コメントを生成します。

アシスタント 担当
Standard バグ・例外処理の誤り・ロジックの欠陥
Best Practices Uber固有のコーディング規約(社内共有レジストリ参照)
AppSec アプリケーションレベルのセキュリティ脆弱性

3つを独立したアシスタントとして分けた理由としては「それぞれを個別に評価・改善できるから」とUberは説明しています。

1つの巨大プロンプトに全てを詰め込むより、役割ごとに切り分けたほうが品質管理がしやすくなります。

③ 品質のフィルタリング 生成したコメントをそのまま出力するのではなく、

信頼スコアリング・セマンティック重複排除・カテゴリ分類という多層フィルタを通します。

このステップが品質と開発者の信頼を維持するための核になっています。

④ 配信とフィードバック収集 エンジニアの評価データを継続的な改善に反映するループを持ちます。運用を続けるほどシステムの精度が向上していく設計です。


偽陽性との戦い

uReviewの構築において最も難しかったのが、偽陽性の管理だとしています。

Uberはその種類を2つに整理しています。

タイプ1:LLMのハルシネーション 事実として間違っているコメントです。存在しないメソッドを参照したり、コードの動作を誤解釈して生成されます。

タイプ2:コンテキスト不適切 技術的には正しいものの、今のコードには関係ない指摘です。過去のPR・DBスキーマ・フィーチャーフラグ・技術ドキュメントにアクセスできないため、ローカルなコードしか見えないことで生じます。

Uberはこの問題に対して、一貫した原則を持って設計を進めました。

開発者の信頼は稼ぐのは難しく、失うのは簡単。

私も冒頭で記載しましたが、ノイズを出し続けるとツールは使われなくなります。 そのため、uReviewは精度を最優先とする設計になっています。

削ったカテゴリ、残したカテゴリ

開発者フィードバックを分析すると、評価の分かれ目は明確でした。

❌ 低評価のため出さないようにしたもの - 可読性の細かい指摘(nits) - ちょっとしたログの修正提案 - スタイルの好みの問題

✅ 高評価のため残したもの - 正確性のバグ - エラーハンドリングの欠落 - 内部ドキュメントへのリンクつきのベストプラクティス指摘

AIが検出したバグの例 高評価カテゴリの例:メトリクス計算のロジックエラー指摘(出典:Uber Engineering Blog)

コメントの絶対数は減りましたが、開発者に実際に使われるシステムになりました。


結果:AIのコメント対応率が人間を上回った

精度優先設計の結果として、注目すべき数字が出ています。

コメント対応率
🤖 uReview(AI) 65%
👤 人間レビュアー 51%

51%という数字は、内部監査でUberが初めて計測した「人間レビュアーが自分のコメントを実際に対応する率」です。

AIシステムを設計するために人間のベースラインを数値化したことで、副産物として明らかになりました。

AIのコメント対応率が人間を上回った背景には、モデルの性能よりも「対応される確率が高いコメントだけを出す」という設計の徹底があります。

あわせて、システム全体での節約効果は週1,500開発者時間(年換算で39年相当)に達しています。

モデル構成

最終的に採用したモデルの組み合わせは以下のとおりです。

役割 モデル
コメント生成 Anthropic Claude 4-Sonnet
品質評価(グレーダー) OpenAI o4-mini-high

全テスト済みの組み合わせの中でこのペアがF1スコア最高となったとのことです。

※ 2025年8月の事例のため、現在利用されているモデルは変更されている可能性が高いです。

生成と評価では求められる能力が異なるため、タスクの性質に応じてモデルを使い分けるアーキテクチャが選ばれています。


段階的な導入

uReviewは全社に一気に展開したわけではありません。1チーム・1アシスタントずつ展開し、各フェーズで精度・リコール・コメント対応率・偽陽性数を計測しながら進めました。

問題があれば次のフェーズに進む前に修正する、という方針を徹底しています。一気に全社展開してノイズが多い状態になれば「こういうもの」という印象が定着しかねません。開発者の信頼を最優先にした展開順序といえます。


AIコーディング時代のレビュー品質という課題

uReviewの事例は、AIコーディングが活発な組織ほど参考になる内容を含んでいます。

AIが書いたコードには前述のとおり品質リスクが伴います。コーディングの速度が上がるほど、そのリスクが積み重なっていきます。レビューがそれに追いつかなければ、手戻りの頻度が上がり、本番障害が増えることになります。

Uberが示したのは「AIがコードを書く時代のレビューをどう設計するか」という問いへの一つの実践例です。その答えは「AIをもっと使う」ではなく「AIの出力をどう絞り込み、開発者の信頼を維持するか」という方向でした。

こうした施策の効果を継続的に把握するためには、手戻りPR率・レビューサイクル数・AI起点の障害率といった指標を定点観測する仕組みが重要になります。supateamでは、これらの指標をチーム別に可視化し、AIコーディングが活発なチームにおける品質面のリスクを早期に検出できます。


まとめ

  • uReviewはサードパーティ製品の課題(GitHub前提・品質・コスト)を背景に内製されたシステムです
  • 「量より精度」を徹底した設計の結果、AIのコメント対応率(65%)が人間レビュアー(51%)を上回りました
  • AIコーディングが加速する今、レビュー品質の設計とその効果計測は、多くの技術組織にとって重要な課題になっています

supateamについて

supateamは、AI時代の開発組織を支援する開発生産性ツールです。

チーム・メンバー・AI活用(現在注力中)の3軸でデータを可視化し、「今、何が起きているか」を定量的に把握できるようにします。

本記事のテーマに関連する指標として、変更のリードタイム・PRの平均レビュー数・変更障害率といったFour Keys指標や、

AIコーディングツールの活用状況・AI起点の手戻りPR率を計測できます。uReviewのような施策を導入した際の効果を定点観測するためのダッシュボードとしてご活用いただけます。

supateam 公式サイト


参考リンク - uReview: Scalable, Trustworthy GenAI for Code Review at Uber