開発サイクルを数える CI 成功率 / MER / MTTR: AIコーディングの生産性を、CIから計測する方法
>100 Views
September 15, 26
スライド概要
詳解CircleCI #01｜2026年9月15日
開発の質と速度を底上げしよう！ 世界中のエンジニアが愛用する CI/CD ツール「CircleCI」の公式アカウントから日本語で最新情報をお届けします。 最新イベント・ミートアップ情報はこちら: http://circleci.connpass.com
関連スライド
各ページのテキスト
詳解CircleCI #01｜2026年9月15日 開発サイクルを数える - CI 成功率 / MER / MTTR AIコーディングの生産性を、CIから計測する方法 岡本 秀高 CircleCI 合同会社 Senior Field Engineer 1
自己紹介 Hidetaka Okamoto（岡本秀高） • CircleCI Senior Field Engineer • AWS Community Builder (Serverless) / Stripe Developer Community Advocate • 年間200本ペースで記事を書く人 https://qiita.com/CircleCIJapan 2
AI でコードは増えました。 でも、リリースは増えていますか。
リリースが思うように増えない理由 AIによる「生産性増加」は開発サイクルの一部だけ Code Review Test Deploy Release 10x 1x 1x 1x 1x
State of Software Delivery 2800万以上の CI ワークフローデータを分析 Q2 Pulse Report 表紙（差し替え） https://circleci.com/resources/2026-state-of-software-delivery/ https://circleci.com/resources/2026-state-of-software-delivery-q2-pulse/ AIによる変化速度の加速から、 2026年は初の四半期( puls )レポートを2026/07に追加公開 5
AI による変化 AI は開発サイクルの「一部分」だけを高速化した 6
AI による変化 AI は開発サイクルの「一部分」だけを高速化した 多くの企業では、作ったコードをユーザーに届けれていない → 中央値以下では、逆にリリース（価値提供）の量が減っている 7
調査結果｜mainブランチのCI成功率 mainブランチも CI エラーが増加 80% 未満 持ち直し傾向ながら、 AI以前より悪い状態のまま 8
調査結果｜mainブランチのCI成功率 mainブランチも CI エラーが増加 80% 未満 持ち直し傾向ながら、 AI以前より悪い状態のまま ① 意味的衝突： 長期間のFeatureなど、マージ後に矛盾が発生 ② 検査範囲の差： リリース前のE2Eテストなどでバグが発覚 ③ flakyテスト： マージ前チェックでは運よく成功していた 9
マージできないコードや エージェントセッションを どうやって特定するか？
Merge Efficiency Ratio (MER) MER: 効率よくマージできたかどうかを見る指標 MER ＝ feature ブランチの実行回数 ÷ main の実行回数 1 つの変更が main に載るまで、 検証を何回走らせているか そのうち、 一発で通っているのはどれくらいか 合計: Median 4.9 / p95 3.6 / Top 20 2.3
Merge Efficiency Ratio (MER) MER: 効率よくマージできたかどうかを見る指標 MER ＝ feature ブランチの実行回数 ÷ main の実行回数 1 つの変更が main に載るまで、 検証を何回走らせているか そのうち、 一発で通っているのはどれくらいか TOP20のMERがここまで低い理由とは？ 合計: Median 4.9 / p95 3.6 / Top 20 2.3
上位チームの習慣 上位チームは、 CI を push 以外のきっかけでも走らせている pushイベント起因のCI実行比率（層が上がるほど下がる） Top 20 の残り約1/3は、スケジュール実行・API起動・依存関係更新チェック・デプロイ後検証。 出典: Q2 Pulse Report p11
pushはその変更をマージするために必要なチェックに限定 Before push CI（判定＋検証混在） After push scheduled等 ブロッキング（マージ判定） ブロッキング （push駆動） ノンブロッキング （別トリガー） lint / 単体テスト / 型チェック 依存関係更新チェック マージ前の 最終ビルド デプロイ後 スモークテスト 非ブロッキング（依存関係等） スケジュール実行や API / CLIトリガーを組み合わせ、 検証のレイヤを薄く重ねた DevOps設計にする 無関係な失敗はブロッキングに混ざらない
Merge Efficiency Ratio (MER) CIコスト & MER で開発サイクルの現状を診断 中央値のチーム 上位20組織 +13% −31% 変更1件あたり CI クレジット（前年比） 変更1件あたり CI クレジット（前年比） 上位チームは中央値より約 51% 少ない コストでリリースする AI / チームは、手戻りの少ない開発サイクルを実現できていますか？ 15
自分の規模に置き換える CI の成功率が 10pt変わると、コストはどれだけ変わるか？ 日次 push 件数 追加デバッグ時間 /年 コスト/年（未最適化） 5件/日 250時間 約684万円 20件/日 1,000時間 約2,738万円 50件/日 2,500時間 約6,844万円 100件/日 5,000時間 約1億3,688万円 1USD=150円換算。未最適化（ MER高止まり）の CI コスト単価をそのまま日次件数に当てはめたモデル計算。 出典: Q2 Pulse Report p18-19 の単価モデルを元に、日次件数を差し替えて算出
MER悪化問題は、企業規模にかかわらず発生している チーム規模 p50 p95 比率 2-5名 2.7 12.7 4.3x 6-10名 6.2 26.1 4.2x 11-25名 12.7 58.5 4.6x 26-50名 31.9 147.7 4.6x 51-100名 58.1 226 3.9x 101-250名 140 600 4.1x 出典: Q2 Pulse Report p8
自組織で測る
MER は Insights API + CircleCI CLIで概算できる
feature ＝ デフォルトブランチ以外のすべてとして数える
branch=mainでmainブランチの実行数を取得
$ circleci api "api/v2/insights/${PROJECT}/workflows" \
-X GET -f reporting-window=last-30-days -f branch=main \
--jq '[.items[].metrics.total_runs] | add'
308
all-branches=trueで全ブランチの実行数を取得
$ circleci api "api/v2/insights/${PROJECT}/workflows" \
-X GET -f reporting-window=last-30-days \
-f all-branches=true \
--jq '[.items[].metrics.total_runs] | add'
960
MER = (all - main) ÷ main
= (960 - 308) ÷ 308 = 652 ÷ 308 -> 2.12
AIの速度では、犠牲にした品質の代償がすぐにくる Is High Quality Software Worth the Cost?: https://martinfowler.com/articles/is-quality-worth-cost.html *矢印は登壇者が追記 19
まとめ 開発チームに、この 2つを聞いてください 01 検証は何回？ 1つの変更が本番に出るまで、検証を何回 走らせていますか。（＝MER） 02 一発で通る？ そのうち、一発で通っているのはどれくらい ですか。（＝CI成功率の裏側） どちらも CI 製品を問わず答えられる、 2つの質問。
10/6 13:00-: Postman x CircleCI 共催ウェビナー https://www2.circleci.com/wbn_circleci_x_postman 21
Thank you. X: @hidetaka_dev Qiita: https://qiita.com/CircleCIJapan EN: https://loop.circleci.com/ 詳解CircleCI #00｜2026年9月15日