State of Software Delivery Q2 Pulseレポートから見る5つのポイント
シニア テクニカル コンテンツ マーケティング マネージャー
AIの普及により、ほぼすべての現場でコードの生成量が増加しています。しかし、それを実際に出荷することは依然として難しく、リーダー企業とそれ以外の企業との差はさらに広がっています。
本日、年次レポートの間を埋める短めのチェックインとして、2026 State of Software Delivery Q2 Pulseレポートを公開しました。2026年3月分の2,000万件を超えるCircleCIのワークフローを分析し、第1四半期に公開した包括的な2026年版State of Software Deliveryレポート以降、何が変化したのかを検証しています。変化のペースは四半期を追うごとに加速しているように見える中、エンジニアリングリーダーがチームの今後の方向性を左右する意思決定に活用できる、最新の情報を提供することを目指しています。
全体としての結論は変わっていません。チームは効率的に出荷できる以上の量のコードを生成しています。変わったのは、リーダー企業がどれだけ速く先行しているかという点と、彼らの運用習慣がエージェント型開発の時代におけるスピードとコストについて何を示しているか、という点です。
特に重要な5つの調査結果を紹介します。
1. 速度の格差は再び拡大
第1四半期では、上位5%のチームは中央値のチームと比較して、mainブランチでのワークフロー実行頻度が8倍でした。第2四半期には、この速度の格差は9倍に達しました。
- 中央値のスループットは、mainブランチで1日あたり約1.7ワークフローと横ばいでした。
- トップパフォーマーは、1日あたり15.6件のmainブランチワークフローまで増加しました。
誰もがより多くのコードを書くようになっています。エリートチームとそれ以外を分けるのは、そのコードのうちどれだけが実際に本番環境まで届くかという点です。
2. フィーチャーブランチは活発、mainブランチはそうではない
年次レポートの特徴づけとなったこの二極化は、第2四半期でも変わらぬ中心的なテーマです。
- フィーチャーブランチのスループットは前年比7.7%増加しました。
- mainブランチのスループットは完全に横ばいでした。
mainブランチの成功率は、第1四半期の70.8%から第2四半期には76.7%へとわずかに改善しました。これは正しい方向への一歩ではあるものの、2023〜2024年に記録していた80%台半ばの水準を依然として大きく下回っており、CircleCIが推奨する90%のベンチマークにはほど遠い数字です。
検証プロセスは依然として業界最大のボトルネックです。チームは、安全に統合・出荷できる量を超えてコードを生成し続けています。
3. 突出したコホートが群を抜いて先行
パーセンタイルは格差の大きさを示しますが、最も速いチームが実際に何をしているのかまでは示しません。
私たちは、データセットの中でmainブランチのスループットが最も高い実在の20組織を詳しく調査しました。一般的なチームが1日あたり2件未満のワークフローしか実行しない中、このエリートコホートは平均して1日あたり約2,165件のmainブランチワークフローを実行しており、この数字は過去1年間で72%も急増しました。
これらのチームは、地域、業界、規模（アクティブなコントリビューター数が約20人から約1,400人まで）を問わず存在しています。彼らは、業界の他の企業を足止めしている障害を回避し、増加したコード量を実際に出荷可能なソフトウェアへと変換する方法を確立した組織です。
4. 新たに注目すべき指標「Merge Efficiency Ratio」
本Pulseレポートでは、新たにMerge Efficiency Ratio（MER）という指標を紹介します。これは、ある変更をmainブランチに反映するまでに必要なフィーチャーブランチでの検証サイクル数を表す指標です。コードが本番環境で使える状態になるまでに、どれだけの手戻りが発生しているかを直接測る指標だと考えてください。
- 中央値のチーム: MERは3.9（mainでの最終実行を含めると、出荷1件あたり合計約5回のCIサイクルに相当）。
- 上位5%のチーム: MER 2.6で運用。
- トップ20コホート: 卓越した1.3を記録。
この格差も固定されたものではありません。過去1年間で、トップ20のMERは1.62から1.28へと21%改善した一方、中央値のチームのMERはほとんど変化していません。
作業をmainに反映するまでのサイクル数が少ないほど、開発者が待機、コンテキストスイッチ、そして完了したと思っていた変更の再検証に費やす時間は減ります。そして、その作業をコーディングエージェントが担っている場合、MERの低さは所要時間とコストに直接反映されます。検証ループが少なければ、マージが速くなり、無駄な実行やトークン消費も減ります。MERの低さは、単なるパイプライン効率の指標にとどまらず、開発者体験とコストの両面での勝利を意味します。
5. インナーループでの検証がボトルネックを解消し、コストを抑える鍵
スループットを制限しているのと同じ検証のボトルネックが、ソフトウェアデリバリーの経済性そのものを変えつつあります。AIによってコード量が増加するにつれ、フィードバックループが遅いほど、CI実行回数の増加、開発者の摩擦の増大、トークン消費の拡大といった隠れたコストが積み重なっていきます。
私たちは、中央値のMERで月間約3,000件の変更を出荷する、50人規模の開発チームをモデル化しました。最適化されていないエージェント型ワークフローと遅いCIフィードバックの場合、デリバリーコストは年間約90万ドルに達する可能性があります。この大部分は、自律型エージェントがコンテキストキャッシュの有効期限が切れるほど長く「グリーンライト」を待って待機し続けることで発生する「トークンリロードペナルティ」に起因します。
解決策はシンプルです。コードがCIに到達する前に、日常的な失敗を検出することです。lint、ユニットテスト、ビルドステップといった高速なチェックをインナー開発ループに組み込むことで、エージェントは数分ではなく数秒でフィードバックを得られるようになります。
同じ50人規模のチームの場合、検証をより早い段階に移すことで、デリバリーコストの総額を年間70万ドル以上削減できる可能性があります。Chunkサイドカーやエージェント型開発向けに新設計されたCLIといったCircleCIの機能は、コーディングエージェントにインナーループ内で高速かつコンテキストに沿ったフィードバックを提供し、日常的な失敗をCIに到達する前に数秒で検出できるように設計されています。これにより、検証はエージェント主導のコード量に歩調を合わせられるようになり、デリバリーを遅らせコストを押し上げるボトルネックにはならなくなります。
チームが次にできることは？
ソフトウェアデリバリーの課題は、コード生成の問題からコード検証の問題へとシフトしました。AIによってコードを書くスピードは上がりましたが、従来のプッシュ型CIワークフローは、機械が生み出すコード量を想定して作られていません。その結果として、パイプラインの停滞、無駄なリトライ、コストの上昇が生じています。
State of Software Delivery Q2 Pulseレポートでは、卓越したスループットを支える3つの運用習慣——高い個人単位のアウトプット、コミット駆動型CIにとどまらない継続的な検証、そして低いMER——を分解し、それぞれについて実践的な着手ポイントを紹介しています。
自分たちのチームがどの位置にいるか知りたいですか？ Software Delivery Data Explorerは、本レポートで使用したものと同じデータセットで更新されています。チームの規模、業界、地域別のベンチマークと自社の指標を比較できます。
