本文へスキップ
September 1, 2026

AIコーディングエージェントのスループット測定：マージ済みPR数・却下率・PRあたりコスト

AIコーディングエージェントのスループットを正しく評価するには、2つの指標をセットで確認する必要があります。それは「マージされたPull Request数（PRs merged）」と、マージされずに破棄されたPRの割合を示す「却下率（Denial rate）」です。これに計画作成からマージまでの「サイクルタイム」と「マージPRあたりのコスト」を加えれば、エージェントが費用対効果に見合う承認済みコードを生産できているかが一目で分かります。多くのチームが最初に報告しがちな「作成されたPR数（PRs opened）」だけでは不十分です。誰にもマージされないPRを1日に50件作成したとしても、その数値は見かけ上の進捗にすぎません。本記事では各指標の定義と数値悪化が示す意味を整理し、Ivy Tendrilと無料の計算ツールを用いてこれらを追跡する方法を解説します。

追跡すべき主要指標

指標 定義 数値が悪化している場合の意味
オープンPR数 期間内に作成されたPull Request数 単体では意味を持ちません。マージ数が横ばいなのに作成数が増加している場合、チームが求めていない不要なコードをエージェントが量産している状態を示します
マージ済みPR数 期間内にマージされたPull Request数 作成数が増えているのに横ばいまたは減少している場合：レビュー工程がボトルネックになっているか、コード品質が低下しています
却下率 マージされずにクローズされたPR数を、クローズ済み全PR数（マージ＋未マージクローズ）で割った割合 高い場合：計画の誤り、検証ゲートの機能不全、またはレビュー後半での却下を示します。PR数が少ないのにほぼ0%の場合、リスクのない極めて限定的な作業しか実行されていません
サイクルタイム 計画（Plan）の作成からマージ完了までの所要時間 長い場合：人間のチェックポイントで作業が滞留しています。どの段階で止まっているか特定する必要があります
マージPRあたりコスト 期間内の総トークン数または総費用を、マージ済みPR数で割った値 上昇している場合：検証失敗による再試行（Retry）、計画の肥大化、あるいは安価なモデルで十分なタスクに高価なモデルを浪費していることが原因です
検証通過率 初回の試行でテスト・リント・ビルドに合格した実行の割合 低い場合：計画の指定が不十分であるか、エージェントにコードベースの文脈が正しく与えられていません

特に2つの指標の算出定義には注意が必要です。却下率の分母には「作成されたPR数」ではなく「クローズされたPR数」を用います。これにより、現在レビュー中の未完了PRが承認または却下として誤ってカウントされるのを防ぎます。また、「マージPRあたりコスト」は、却下された計画や途中で破棄された作業にかかった費用も含めた総支出を、実際にマージされたPR数だけで割って算出します。これは意図的な設計です。却下された作業にかかったコストも、最終的にマージされた成果物の真のコストの一部だからです。

マージ済みPR数と却下率が「誠実なペア指標」である理由

あらゆる単一の指標は、別の指標を犠牲にすることで数字だけを良く見せかけることができます。

  • 実行基準を緩めれば「作成されたPR数」は急増しますが、それに伴い「却下率」も跳ね上がります。
  • レビュアーが詳細を見ずに承認を急げば「マージ済みPR数」は伸びますが、マージ後の本番障害が多発し、不健全な理由で却下率が下がります。
  • 極めて安全で自明な計画だけを実行させれば「却下率」は下がりますが、当然「マージ済みPR数」も激減します。

これはDORAメトリクスと同じ思想です。スループットと安定性が常にペアで報告されるのは、片方を犠牲にすればもう片方を容易に歪められてしまうからです。「マージ済みPR数」と「却下率」を同時に観察すれば、この歪みを排除できます。却下率を上げずにマージ数を増やすには、チームが実際に受け入れる質の高い成果物を増やすしかありません。また、マージ数を落とさずに却下率を下げるには、実行を減らすのではなく、計画と自動検証の精度を高める必要があります。どちらの数値も、相手方を無視して改善することは不可能です。

作成されたPR数が指標として好まれがちなのは、エージェントが真っ先に出力する成果であり、集計が最も容易だからです。しかし、オープンされたPull Requestとは、本質的に「他者の時間を奪うリクエスト」に過ぎません。リクエストの数自体をアウトプットとして評価すると、レビュアーの負担を増大させたエージェントが報われてしまいます。真に評価すべきなのは、仕事を最後まで完了させたマージの実績です。

Ivyでは自社の運用データをこの基準で公開しています。Ivyを選ぶ理由のページに掲載されている「1日あたりのPR数対却下率」のチャートは、2026年2月から4月にかけてIvyのリポジトリで処理された1,946件のPull Requestの実績に基づいています。Ivyの開発チームは、計画・実行・検証・レビューからなるソフトウェアファクトリーワークフローを導入したことで、1日あたり約10件だったマージ数を100件以上に拡大しました。このPR数は、却下率と併記されているからこそ意味を持つのです。

マージPRあたりコストと検証通過率

マージ数と却下率が安定したら、「マージPRあたりコスト」によって承認済みコードの実際の単価を把握できます。これはCTOやエンジニアリングマネージャーが最も必要とする指標であり、計画単位や単一実行単位ではなく、「マージされた変更1件あたりのドルまたはトークン」として算出されなければなりません。リトライや却下された試行の費用をすべて内包するためです。

また、マージPRあたりコストはキューの滞留を可視化する指標でもあります。リトルの法則によれば、一定のマージ速度に対して未処理のオープンPRが滞留していくと、明示的に計測していなくてもサイクルタイムは確実に長期化します。このコストを動かす要因は主に3点あります。

  1. 再試行（Retries）： 検証に失敗するたびに追加の実行が発生します。「検証通過率」はその先行指標であり、通過率が下がると数日後にマージPRあたりコストが跳ね上がります。検証ゲートでは、何を検証すべきか、なぜ計画ゲートが最重要であるかを解説しています。
  2. 計画のサイズ： 巨大な計画は実行ごとのコストが高く、レビュアーの指摘箇所も増えるため却下されやすくなります。計画を細かく分割すれば、レビュー対象のPR数は増えるものの、却下率とマージPRあたりコストの双方が低下するのが一般的です。
  3. モデルの選定： 同等の検証通過率を維持できるなら、安価なモデルへの切り替えは直接的なコスト削減につながります。これを確認する唯一の方法は、計画ごとのコストと通過率を記録し、同一のコードベース上で複数モデルを比較することです。

開発者の作業量から「承認された成果物」の測定へとシフトする背景については、イン・ザ・ループとアウト・オブ・ザ・ループ：エージェント時代に求められるKPIの転換を参照してください。

Ivy Tendrilによるメトリクス追跡の仕組み

Ivy Tendrilは、計画の立案からレビュー済みPRの作成までを一貫して管理するローカルファーストのデスクトップアプリケーション（macOS、Windows、Linux）です。ワークフローを実行する過程で、上記のすべての指標データが自動的に記録されます。外部ツールを個別につなぎ込む必要はありません。

  • Dashboard： Dashboardでは、ライフサイクル全体にわたる計画のステータス、コストKPI、時系列のトレンドチャート、接続リポジトリのGitアクティビティを表示します。計画ステータスからオープン、マージ、却下の各PR数が把握でき、Gitアクティビティから実際のマージ履歴が確認できます。
  • 計画・ジョブごとのコスト： トークン消費量と費用は、すべての計画および計画内の各ジョブ単位で記録されます。検証に合格するまで3回の実行ジョブを要した計画では3回分すべてのコストが集計され、マージPRあたりコストに再試行分が確実に反映されます。Jobs画面では、各ジョブのストリーミングログやツール呼び出しをコストとともに確認できます。
  • エージェントおよびモデルの比較： TendrilはClaude Code、OpenAI Codex CLI、GitHub Copilot CLI、Google Gemini CLI、OpenCodeなど任意のCLIエージェントに対応しており、計画ごとに使用するエージェントやモデルを選択できます。そのため、ワークフローを変えることなく同一コードベース上で各モデルの費用対効果を直接比較できます。
  • ローカルデータの保護： 計画、ログ、コストデータはすべて手元のマシン内に保持されます。外部への通信は、設定したAIモデルのAPIおよびGitHubとの通信のみです。

Tendrilをまだ導入していないチーム向けに、Ivyはオープンソースの無料ツールPR Cost Calculatorを提供しています。リポジトリの公開GitHubデータを読み取り、直近14日間の移動平均マージ数と却下率を算出します。現在の開発プロセスのベースラインを記録し、エージェント導入から1か月後に再測定して効果を比較してみてください。

導入のステップ

  1. ベースラインの把握：メインリポジトリでPR Cost Calculatorを実行し、直近14日間のマージ済みPR数と却下率を記録します。
  2. Tendrilのインストール：curl -sSf https://cdn.ivy.app/install-tendril.sh | sh（macOS、Linux）またはirm https://cdn.ivy.app/install-tendril.ps1 | iex（Windows）。詳細はインストール手順を参照。
  3. 2週間の運用とDashboardの確認：マージ数、却下数、計画あたりコスト、全体の推移傾向を分析します。
  4. マージPRあたりコストの試算：総支出をマージ数で割る計算を手動で行い、組織内の報告基準として定義の合意を形成します。

Tendrilは無料かつFunctional Source Licenseの下でソースコードが公開されています。チーム機能、オンプレミス運用、SSO、CI検証のインポートなどは、Pro（ユーザーあたり月額59ドル）およびEnterpriseプランでご利用いただけます。

よくある質問

理想的な却下率の目安はどれくらいですか？

全プロジェクト共通の絶対的な基準値はありません。却下率が0%である場合、リスクのある挑戦的なタスクが一切行われていない可能性が高いと言えます。時系列で自社チームの推移を監視し、数値が上昇した場合は計画の精度や検証ゲートを見直すシグナルとして活用してください。単に実行数を減らして数値を繕うべきではありません。

マージPRあたりコストに人間のレビュー時間を含めるべきですか？

一貫して計測できる体制が整っている場合は含めることを推奨します。多くのチームでは、自動的に計測できるトークンやモデル利用費から開始し、評価基準が定まった段階でエンジニアのレビュー工数を加算しています。基準が曖昧なまま両者を混ぜてしまうと、月ごとの比較が困難になります。

これらの指標はDORAメトリクスとどう異なりますか？

多くの領域で重なり合っています。計画からマージまでのサイクルタイムは、DORAの「変更のリードタイム（Lead Time for Changes）」に相当します。一方、却下率に該当するDORA指標はありません。DORAは人間がコードを書くことを前提とし「本番環境にデプロイされたか」を問いますが、却下率は「その変更がそもそも承認されたか」を問います。エージェントが大量のコード候補を作成する現代においては、後者こそが極めて重要な問いとなります。

Ivy Tendrilで開発を加速する

開発者レベルの並列エージェントオーケストレーションを体験しませんか？

Written by

Ivy Team