---
title: 開発サイクルを数える CI 成功率 / MER / MTTR:  AIコーディングの生産性を、CIから計測する方法
tags: 
author: [CircleCI Japan](https://image.docswell.com/user/circleci-japan)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/LE1RQ8W2EG.jpg?width=480
description: 詳解CircleCI #01｜2026年9月15日
published: September 15, 26
canonical: https://image.docswell.com/s/circleci-japan/K7N8G1-2026-10-28-140219
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/LE1RQ8W2EG.jpg)

詳解CircleCI #01｜2026年9月15日
開発サイクルを数える
- CI 成功率 / MER / MTTR
AIコーディングの生産性を、CIから計測する方法
岡本 秀高
CircleCI 合同会社 Senior Field Engineer
1


# Page. 2

![Page Image](https://bcdn.docswell.com/page/GEW1MZ6272.jpg)

自己紹介
Hidetaka Okamoto（岡本秀高）
•
CircleCI Senior Field Engineer
•
AWS Community Builder (Serverless) /
Stripe Developer Community Advocate
•
年間200本ペースで記事を書く人
https://qiita.com/CircleCIJapan
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/47ZPQ1Y4E3.jpg)

AI でコードは増えました。
でも、リリースは増えていますか。


# Page. 4

![Page Image](https://bcdn.docswell.com/page/YJ6M6LDG7V.jpg)

リリースが思うように増えない理由
AIによる「生産性増加」は開発サイクルの一部だけ
Code
Review
Test
Deploy
Release
10x
1x
1x
1x
1x


# Page. 5

![Page Image](https://bcdn.docswell.com/page/GJ5Z613XE4.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/9E2RM1ZQJR.jpg)

AI による変化
AI は開発サイクルの「一部分」だけを高速化した
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/D7YDXZRY7M.jpg)

AI による変化
AI は開発サイクルの「一部分」だけを高速化した
多くの企業では、作ったコードをユーザーに届けれていない
→ 中央値以下では、逆にリリース（価値提供）の量が減っている
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/VEN613DRE8.jpg)

調査結果｜mainブランチのCI成功率
mainブランチも
CI エラーが増加
80% 未満
持ち直し傾向ながら、 AI以前より悪い状態のまま
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/Y79L59GZJ3.jpg)

調査結果｜mainブランチのCI成功率
mainブランチも
CI エラーが増加
80% 未満
持ち直し傾向ながら、 AI以前より悪い状態のまま
① 意味的衝突：
長期間のFeatureなど、マージ後に矛盾が発生
② 検査範囲の差：
リリース前のE2Eテストなどでバグが発覚
③ flakyテスト：
マージ前チェックでは運よく成功していた
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/G78XY98YED.jpg)

マージできないコードや
エージェントセッションを
どうやって特定するか？


# Page. 11

![Page Image](https://bcdn.docswell.com/page/L7L84WR9JR.jpg)

Merge Efficiency Ratio (MER)
MER: 効率よくマージできたかどうかを見る指標
MER ＝ feature ブランチの実行回数 ÷ main の実行回数
1 つの変更が main に載るまで、
検証を何回走らせているか
そのうち、
一発で通っているのはどれくらいか
合計: Median 4.9 / p95 3.6 / Top 20 2.3


# Page. 12

![Page Image](https://bcdn.docswell.com/page/4EM6K9RV7W.jpg)

Merge Efficiency Ratio (MER)
MER: 効率よくマージできたかどうかを見る指標
MER ＝ feature ブランチの実行回数 ÷ main の実行回数
1 つの変更が main に載るまで、
検証を何回走らせているか
そのうち、
一発で通っているのはどれくらいか
TOP20のMERがここまで低い理由とは？
合計: Median 4.9 / p95 3.6 / Top 20 2.3


# Page. 13

![Page Image](https://bcdn.docswell.com/page/PERPXGRW79.jpg)

上位チームの習慣
上位チームは、 CI を push 以外のきっかけでも走らせている
pushイベント起因のCI実行比率（層が上がるほど下がる）
Top 20 の残り約1/3は、スケジュール実行・API起動・依存関係更新チェック・デプロイ後検証。
出典: Q2 Pulse Report p11


# Page. 14

![Page Image](https://bcdn.docswell.com/page/P7X36XRVEX.jpg)

pushはその変更をマージするために必要なチェックに限定
Before
push
CI（判定＋検証混在）
After
push
scheduled等
ブロッキング（マージ判定）
ブロッキング
（push駆動）
ノンブロッキング
（別トリガー）
lint / 単体テスト /
型チェック
依存関係更新チェック
マージ前の
最終ビルド
デプロイ後
スモークテスト
非ブロッキング（依存関係等）
スケジュール実行や API / CLIトリガーを組み合わせ、
検証のレイヤを薄く重ねた DevOps設計にする
無関係な失敗はブロッキングに混ざらない


# Page. 15

![Page Image](https://bcdn.docswell.com/page/37KY1WR5ED.jpg)

Merge Efficiency Ratio (MER)
CIコスト & MER で開発サイクルの現状を診断
中央値のチーム
上位20組織
+13%
−31%
変更1件あたり CI クレジット（前年比）
変更1件あたり CI クレジット（前年比）
上位チームは中央値より約 51% 少ない コストでリリースする
AI / チームは、手戻りの少ない開発サイクルを実現できていますか？
15


# Page. 16

![Page Image](https://bcdn.docswell.com/page/LJ39Q181J5.jpg)

自分の規模に置き換える
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 の単価モデルを元に、日次件数を差し替えて算出


# Page. 17

![Page Image](https://bcdn.docswell.com/page/8JDG9XMKJG.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/VEP3ZPR378.jpg)

自組織で測る
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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/27V4W2RNEQ.jpg)

AIの速度では、犠牲にした品質の代償がすぐにくる
Is High Quality Software Worth the Cost?:
https://martinfowler.com/articles/is-quality-worth-cost.html
*矢印は登壇者が追記
19


# Page. 20

![Page Image](https://bcdn.docswell.com/page/5JG1DRM57L.jpg)

まとめ
開発チームに、この 2つを聞いてください
01
検証は何回？
1つの変更が本番に出るまで、検証を何回
走らせていますか。（＝MER）
02
一発で通る？
そのうち、一発で通っているのはどれくらい
ですか。（＝CI成功率の裏側）
どちらも CI 製品を問わず答えられる、 2つの質問。


# Page. 21

![Page Image](https://bcdn.docswell.com/page/47QD1VRLEP.jpg)

10/6 13:00-: Postman x CircleCI 共催ウェビナー
https://www2.circleci.com/wbn_circleci_x_postman
21


# Page. 22

![Page Image](https://bcdn.docswell.com/page/KE4ZRM85J1.jpg)

Thank
you.
X: @hidetaka_dev
Qiita: https://qiita.com/CircleCIJapan
EN: https://loop.circleci.com/
詳解CircleCI #00｜2026年9月15日