---
title: AI駆動開発の成果、 計測していますか？ データが示す、AI駆動開発のハマりどころ
tags: 
author: [CircleCI Japan](https://www.docswell.com/user/circleci-japan)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/4EQD1V9RJP.jpg?width=480
description: CircleCI Webinar | 2026年4月
published: April 21, 26
canonical: https://www.docswell.com/s/circleci-japan/ZN7PLP-2026-10-28-141124
---
# Page. 1

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

CircleCI Webinar | 2026年4月
AI駆動開発の成果、
計測していますか？
データが示す、AI駆動開発のハマりどころ
岡本 秀高 ( @hidetaka_dev )
Senior Field Engineer
#CircleCIJP
1


# Page. 2

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

自己紹介
Hidetaka Okamoto
(岡本秀高 )
● CircleCI Senior Field Engineer
● 年間100本ペースで記事を書く人
● CircleCIJapan ( Qiita )にて4月は平日毎日更新中
https://qiita.com/CircleCIJapan
#CircleCIJP
2


# Page. 3

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

今日のゴール
#CircleCIJP
3


# Page. 4

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

今日のゴール
AIツールの効果を「経営に説明できる数字」に変換する
#CircleCIJP
4


# Page. 5

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

>Agenda
1
来年もそのAIツール、使えますか？
2
AIによる、ソフトウェアの「工業化」
3
2,800万ワークフローからAIの導入効果を検証する
4
開発の数字を経営の言葉へ変換する
5
上位5%から学ぶ AI 駆動開発でスケールする方法
6
明日からできること
#CircleCIJP
5


# Page. 6

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

01
来年もそのAIツール、
使えますか？
AIツールの導入効果計測と
継続利用に向けた費用対効果の考え方
#CircleCIJP
6


# Page. 7

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

計画された AI 予算の 25% が先送りされつつある
25%
2026 年の AI 予算のうち
2027 年に先送りされる割合
AI の価値を企業の業績貢献に関連付けて
説明できる意思決定者は 3 分の 1 未満
AI の価値を測定可能なビジネス成果に
変換できる組織とできない組織の
差が広がっている。
Forrester’s 2026 Technology & Security Predictions: As AI’s Hype Fades, Enterprises Will Defer 25% Of Planned AI Spend To 2027:
https://www.forrester.com/press-newsroom/forrester-tech-security-2026-predictions/
The 2026 State of Software Delivery - CircleCI
https://circleci.com/resources/2026-state-of-software-delivery/
7


# Page. 8

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

AIの導入効果は、体感と実測に差が発生する
20%
開発者が体感した高速化率
19%
実測された減速率
※ 経験豊富な OSS 開発者 16 名による RCT（2025 年前半、Cursor Pro + Claude
3.5/3.7 Sonnet）
Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity:
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
8


# Page. 9

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

AI導入の各指標は、「導入過程」の計測であることが多い
①
②
③
トークン消費量
どれだけツールが利用されているか？
LoC ( Lines of Code )
どれだけのコードが生成されたか？
開発者インタビュー
開発者にとって使いやすいツールか？
9


# Page. 10

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

評価指標を過程から結果にシフトする必要がある
①
②
③
④
トークン消費量
どれだけツールが利用されているか？
LoC ( Lines of Code )
どれだけのコードが生成されたか？
開発者インタビュー
開発者にとって使いやすいツールか？
DORA Four Keys 他 DevOps系指標
ビジネスに価値を届けられているか？
Claude CodeとDevinをFour Keysで検証——NTTドコモビジネスが3カ月
のコーディングエージェント導入で得たデータと教訓:
https://codezine.jp/article/detail/23665
10


# Page. 11

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

DORA Four Keys — ソフトウェアデリバリーを測る 4 指標
スピード と 安定性 の両軸で計測する
スピード (Throughput)
安定性 (Stability)
デプロイ頻度
変更失敗率
Deployment Frequency
Change Failure Rate
どれだけ頻繁に本番環境に
リリースできているか
デプロイのうち障害を
引き起こした割合
変更のリードタイム
平均復旧時間 (MTTR)
Lead Time for Changes
Mean Time to Recovery
コミットから本番稼働までの
時間
障害発生から復旧までの
時間
DORA (DevOps Research and Assessment) - Google Cloud: https://cloud.google.com/devops
Accelerate: The Science of Lean Software and DevOps (Forsgren, Humble, Kim, 2018)
11


# Page. 12

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

CircleCI のデータで、 Four Keys を計測する
デプロイ頻度
①
PR マージ数 / CI パイプライン実行数 / デプロイワークフローの実行数
変更失敗率
②
生成・マージしたコードの品質は改善したか？
CI ワークフローの成功率（本番ブランチ vs 機能ブランチ）
MTTR
③
マージされたコミットや、リリースの数は？
問題発生時、どれだけ速く復旧・修正できているか？
CI やアプリで問題が起きた時の復旧・修正速度
ソフトウェア開発の現場にある数字を元に、 AI による成果物の影響を計測する
12


# Page. 13

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

02
AIによる、
ソフトウェアの「工業化」
最新技術やパラダイムを
伝統的な視点や取り組みから捉え直す
13


# Page. 14

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

“
企業のなかのムダは無数にあるが、
つくり過ぎのムダほど恐ろしいものはない
14


# Page. 15

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

“
企業のなかのムダは無数にあるが、
つくり過ぎのムダほど恐ろしいものはない
── 大野耐一『トヨタ生産方式』
15


# Page. 16

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

ソフトウェア開発は「手工業」から「工業」へ転換している
これまで：クラフト（手工業）
AI時代：インダストリアル（工業）
人間が考え、人間が書く
AIが生成し、AIがテストを書く
人間がレビューする
人間は判断に集中する
→
コード生産速度は
人間の認知速度で制約
コード生産速度が
人間の制約から解放
プロセスは「手工業」の
ペースに合わせて設計
しかしプロセスは
「手工業」時代の設計のまま
工業化した瞬間に、工業の問題が起きる。大量生産・品質管理・待ち行列・ボトルネック
──
16


# Page. 17

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

トヨタ生産方式（TPS）から学ぶ「７つのムダ」
①
②
⑤
つくり過ぎのムダ
最も危険。必要以上に、必要より早くつくる。他の六つのムダを連鎖的に誘発する
在庫
③
不良
④
手待ち
使われない滞留
欠陥と手直し
次工程を待つ
運搬
加工
動作
価値を生まない移動
⑥
不要な工程
⑦
価値を生まない動き
出典: 大野耐一『トヨタ生産方式』
17


# Page. 18

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

AI 駆動開発の課題を TPS にあてはめると・・・
TPSのムダ
AI駆動開発での現れ方
①つくり過ぎ
AIがコードを大量生成
②在庫
マージされないPR（書かれたがデプロイされないコード）
③不良
AI Slop(生成時)・CIエラーによる手戻り(検証時)
本番での障害(リリース後)
④手待ち
レビュー待ち・CI待ち・デプロイ待ち
⑤運搬
指示者→AI→レビュアー間でのコンテキストの引き渡し
⑥加工
AI による過剰実装
⑦動作
プロンプトの書き直し・コンテキスト再投入などのAI操作作業
18


# Page. 19

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

AIが加速するのは、開発サイクルの一部分だけ
Inner Loop
IDE → コード生成 → ローカルテスト
秒〜分単位
AI が加速 ✓
Outer Loop
Push → CI → レビュー → デプロイ
分〜時間単位
変わっていない ✕
「LLMと20分作業して、CIの実行に2時間かかるなら、それは機能しない。
フィードバックループの各段階は、同じオーダーの時間で揃っていなければならない」
— Liz Fong-Jones（Honeycomb Technical Fellow）
https://www.youtube.com/watch?v=nXx52z2OukY
19


# Page. 20

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

投入量の線形増加が、積み残しを非線形に爆発させる
「つくり過ぎ」が「在庫」を誘発する、の非線形版
AI で +20% 到着
1.6件 / 日
毎時0.2件が蓄積
AI で 5x 到着
32件 / 日
数日で収拾不能
キューイング理論 : 到着率がサービス率を超えると、待ち行列
は無限に伸びる。
前提 : デリバリー処理能力 = 60分 /件（ 1時間に 1件を本番に届ける）
出典: Michael Webster（Principal Engineer, CircleCI）のキューイング理論シミュレーション / Webinar "How AI is Breaking the SDLC"
https://www.youtube.com/watch?v=dDu-sT11AvU
20


# Page. 21

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

デリバリー側を速くすると大幅に緩和される
観察 : デリバリーを 10% 改善すると、同じ到着率でも積み残しが大幅に減る
60分 → 54分 のデリバリー短縮で
-55%
14日間の積み残し（ 22.4件→10.0件）
示唆
問題は AI ツールの側ではなく、
パイプラインの側 にある。
10% のデリバリー改善が、コード生成加速より高い ROI を生
む可能性がある。
数値の出典: Michael Webster（CircleCI）のシミュレーションを+20% シナリオで14日間に外挿 / Webinar "How AI is Breaking the SDLC"
「エンドツーエンドのパイプラインがきちんとチューニングされていないなら、AI は状況を救わない。状況を複雑にするだけだ」
— Brad Johnson, Worldwide Category Manager, AWS / Webinar "State of Software Delivery"
21


# Page. 22

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

大事なのは生成量ではなく、流量
1. AI駆動開発の悩みは、トヨタがかつて歩んだ道のりで説明できる
→ 「つくり過ぎ」を起点とする因果鎖は、ソフトウェアでも同じように働く
2. 鍵は「作りすぎないこと」ではなく「作ったものを滞留させないこと」
→ Just In Timeの発想：必要なものを生成し、即座に出荷する
3. デリバリーを速く・効率化すれば、スループットは上がる
→ 経営が投資すべきは「AIツール」と「パイプライン」の両輪
22


# Page. 23

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

03
2,800万ワークフローから
AI導入の効果を検証する
CircleCI State of Software Delivery 2026レポート
23


# Page. 24

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

[おさらい ] CI指標から、開発チームの現状が可視化される
デプロイ頻度
①
PR マージ数 / CI パイプライン実行数 / デプロイワークフローの実行数
変更失敗率
②
生成・マージしたコードの品質は改善したか？
CI ワークフローの成功率（本番ブランチ vs 機能ブランチ）
MTTR
③
マージされたコミットや、リリースの数は？
問題発生時、どれだけ速く復旧・修正できているか？
CI やアプリで問題が起きた時の復旧・修正速度
24


# Page. 25

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

CircleCI上で実際に稼働したCI/CDワークフローを分析
28,738,317
分析対象のワークフロー実行数
https://circleci.com/resources/2026-state-of-software-delivery/
25


# Page. 26

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

生産性が向上したチームは一部、しかし格差はより大きく
上位5%チームのWF実行量
中央値チームの WF 実行量
97%+
+4%
下位25%チームの WF 実行量
前年比
大幅な生産性向上を実現
0%
生成したものをどれだけリリースできているかが、
AI導入効果の差を生み出す
26


# Page. 27

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

CircleCI Insightでスループットや成功率・MTTRをモニタリング
目指すべきベンチマーク
スループット
1.71 / 日
ワークフロー実行数の目安
成功率
90% 以上
本来目指すべきパイプライン成功
率
MTTR
1時間 以内
Mainブランチ復旧時間の目安
27


# Page. 28

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

CIの成功率が低下していないかは要チェック
70.8%
Mainブランチの成功率
過去5年で最も悪い結果に
90% 以上
本来目指すべき
パイプライン成功率
28


# Page. 29

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

90%の成功率が70%まで落ちると何が起きるか？
1日の変更頻度
成功率 70%
成功率 90%
差分
5件/日
1.5回/日の失敗
0.5回/日の失敗
年間 約250時間
約 250 時間 / 年
中規模チーム (50件/日) で、エンジニア 約1.25人分 の工数に相当
※ 失敗1件あたり復旧60分 / 年間250営業日 / 1人年2,000時間で換算
29


# Page. 30

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

MTTR 悪化は feature branch 側で起きている
main ブランチは改善。問題は「マージ前の PR 段階」にある
Feature branch MTTR
+25%
64分 → 約80分 (前年比)
Main branch MTTR
59.2分
60分ベンチマーク以下まで改善
•
main ブランチは改善している
•
•
失敗 → マージ前に検知 → 修正のサイクルは機能している
問題は feature branch 側
•
•
AI 生成コードの不具合は修正に時間がかかりやすい
マージされない PR が長期滞留する要因に
30


# Page. 31

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

デリバリーに着⽬すると、AI の真の影響が⾒えてくる
What
Why
How
何が起きているか
なぜ起きているか
どう計測するか
スループット
feature +15% / main −7%
⽣成量は増えたが出荷できていない
成功率
70.8%（過去5年で最悪）
マージ前で不良が多発
MTTR
feature +25% / main は改善
問題は「マージ前のPR段階」に集中
AIは Inner Loop を加速した
スループット‧成功率‧MTTR
コード⽣成は秒〜分単位に短縮
3指標を継続的にモニタリング
しかし Outer Loop は変わっていない
feature vs main を⽐較
レビュー‧CI‧デプロイは分〜時間単位のまま
どのサイクルで詰まっているかを特定
上流の⽣成量増 → 下流で詰まる
CircleCI Insight で⼀元追跡
「在庫」「不良」「⼿待ち」が連鎖的に発⽣
経営報告に使えるダッシュボードを整備
格差
上位5%と下位の差が拡⼤
中央値チームは横ばい
「作りすぎ → 在庫 → 不良 → ⼿待ち」の連鎖が、
2,800万ワークフローの実データで観察されている
31


# Page. 32

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

04
開発の数字を
経営の言葉へ変換する
投資判断・効果測定につながる数字と
そのストーリーの作り方を知る
32


# Page. 33

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

CIから見えた現状や変化を、どのように伝えるか？
リサーチによる現状
この状態を放置すると、
年間いくら失うのか ?
スループット
feature +15% / main -7%
成功率
CI/CD への投資は、
いくらが適正なのか ?
70.8%（過去5年で最低）
MTTR
72分（前年比 +13%）
何から手をつければ、
投資対効果が最大か ?
33


# Page. 34

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

品質コスト ( CoQ )フレームワークで整理する
① 予防コスト
② 評価コスト
欠陥混入を防ぐ
顧客に届く前に検出
例: 設計レビュー、コーディング標準
例: テスティング、CI/CD
③ 内部失敗コスト
④ 外部失敗コスト
リリース前に発見
リリース後に発見
例: 手戻り、再テスト、デバッグ
例: 本番インシデント、顧客離反、罰金
← CI/CD はここ
https://beyondquality.org/
34


# Page. 35

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

CircleCI Insight の指標を、 CoQ 4分類へ翻訳する
CircleCI Insight で見る指標
CoQ 4分類での位置づけ
経営的な意味
スループット
（feature vs main）
在庫 → ④外部失敗コストの予備軍
PRに滞留する未出荷コード = 寝かされた投資
成功率
③内部失敗コスト
手戻り・再テスト・デバッグの工数増
MTTR
③内部失敗コスト（長期化）
失敗1件あたりの時間損失の大きさ
CI/CD の継続実行
②評価コスト（投資している部分）
顧客に届く前に検出するための仕組み
失敗コスト（③④）を可視化することで、評価コスト（② CI/CD）への投資の正当性 が計算できるようになる
35


# Page. 36

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

3つの問いに、 CoQ で答える
③内部失敗コスト + ④外部失敗コストの合計で試算する
Q1. 放置すると、年間いくら失うか？
例: 成功率 70% → 90% の改善で、
年間 約250時間のエンジニア時間を失敗対応から回収
基準は「②評価 + ①予防 < ③④失敗コスト」が成立する水準
Q2. CI/CD 投資は、いくらが適正か？
失敗コストを可視化して初めて、
CI/CDへの投資の ROI が数式として語れるようになる
失敗コストが最も大きい項目から
Q3. どこから着手すれば効果が最大か？
まずは成功率（③不良）と MTTR（失敗の長さ）を継続観測し、
ボトルネックを特定する
36


# Page. 37

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

05
上位5%から学ぶ
AI 駆動開発でスケールする方法
データと事例から
導入時に意識すべきポイントを整理する
37


# Page. 38

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

上位5%企業は、CI 4指標すべてでベンチマークを達成している
指標
中央値
上位5%
推奨
スループット変化
+4%
+97%
—
main 変化
-7%
+26%
—
成功率
70.8%
90% 以上
90% 以上
所要時間（P50）
2分13秒
6秒
10分以内
72分
1分36秒
60分以内
MTTR
速さと品質はトレードオフではない── パイプラインを「生産システム」として設計している
38


# Page. 39

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

上位5%は Inner Loop と Outer Loop を揃えている
中央値チームと上位5%を feature / main で分解して比較する
中央値チーム
Feature branch スループット
+15%
Main branch スループット
-7%
→ feature が膨らんで main に届かない


# Page. 40

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

上位5%は Inner Loop と Outer Loop を揃えている
中央値チームと上位5%を feature / main で分解して比較する
中央値チーム
上位5%チーム
Feature branch スループット
Feature branch スループット
+15%
+85%
Main branch スループット
Main branch スループット
-7%
+26%
→ feature が膨らんで main に届かない
→ feature の膨張に main も追従
上位5%は、Outer Loop まで含めて「生産システム」として CI/CD を運用している
4
1


# Page. 41

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

Case: Stripe Minions
●
コーディングエージェントを自作
●
サンドボックス内で実装を行い、
リントや CI による検証も AIが確認
●
問題が起きた時は、 AIが自律的に
エラーを調査して修正を実施
●
毎週1,300 以上のPRがMinions経由で
生成・マージされている
Minions: Stripe’s one-shot, end-to-end coding agents
https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents
https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agentspart-2
41


# Page. 42

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

CircleCIは Autonomous Validation （自律的検証）で課題解決を提案
feature +15% / main -7%
フィードバックサイクルの高速化
生成したコードをどれだけリリースできているか？
Smarter Testing [ Beta ] で関連するテストのみを並列実行
AIの生成速度にCIも追従できる環境を提供
MTTR +13%
問題の調査と修正を AIで支援
AIが混入させたバグを、誰がどう修正するのか？
→
Chunk [ Beta ] によるエラーログの分析と修正PR作成
成功率 70.8%
レビューやテストカバレッジの継続的改善
AIがミスを自分で気付けるようにできないか？
OSS の chunk-cli でレビュー指針の分析と明文化
ミューテーションテストによるカバレッジ改善
42


# Page. 43

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

ROI計算機で Autonomous Validation （自律的検証）効果を試算する
テスト高速化や自動修正・最適化で、AIの導入効果を更に高める
https://circleci.com/autonomous-validation-roi/
43


# Page. 44

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

06
明日からできること
AI駆動開発の現状を見るために、
CIパイプラインの現状をチェックする
44


# Page. 45

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

明⽇からできること ── 3つのステップ
STEP 1
測る
CIサービスダッシュボードで
直近30⽇の main ブランチの
成功率と MTTR を確認する。
まず現在地を知る
44


# Page. 46

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

明⽇からできること ── 3つのステップ
STEP 1
STEP 2
測る
診断する
CIサービスダッシュボードで
直近30⽇の main ブランチの
成功率と MTTR を確認する。
ベンチマーク未達の指標を
CoQ の内部失敗コストとして
年間⼯数‧⾦額に換算する。
失敗コストが最⼤の項⽬が、
最初の改善ターゲット。
まず現在地を知る
数字を経営の⾔葉に翻訳する
44


# Page. 47

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

明⽇からできること ── 3つのステップ
STEP 1
STEP 2
STEP 3
測る
診断する
回す
CIサービスダッシュボードで
直近30⽇の main ブランチの
成功率と MTTR を確認する。
ベンチマーク未達の指標を
CoQ の内部失敗コストとして
年間⼯数‧⾦額に換算する。
失敗コストが最⼤の項⽬が、
最初の改善ターゲット。
週次で4指標を追跡し、改善施
策の優先順位付けと投資判断
を継続的に回す。
まず現在地を知る
数字を経営の⾔葉に翻訳する
⼀度ではなく、仕組みにする
※ 指標が⾒えなくても、何が⾒えて何が⾒えないかの棚卸しから始められます
44


# Page. 48

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

AIの導⼊効果を数字によって説明できるようにする
「速くなりました」
から
「本番到達率は ○%、成功率は ○%、
復旧時間は ○分です」
48


# Page. 49

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

まとめ
1
AI はコード⽣成を加速した
2
しかし中央値チームでは出荷（リリース）が増えず、
成功率が低下し、復旧に時間がかかっている
3
リリースされないコードが増えると、TPSの「作りすぎのムダ」が⽣まれ、
CoQの内部失敗→外部失敗が発⽣しやすくなる
4
上位5%の特徴は、パイプラインを『⽣産システム』として運⽤していること
5
測って、診断して、仕組みにしよう
46


# Page. 50

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

次回予告
CircleCI Webinar | 2026年5月
AI駆動開発の
「速く書けるのに出荷できない」
を解消する
上位5%が実践する 3つの改善パターンを掘り下げ
https://circleci.connpass.com/event/391632/
フレーキーテスト排除・テスト並列化・ロールバック自動化
CoQ を使った投資判断の詳細
5月26日 (火)
14:00 - 15:00
ダッシュボードで「どこから着手すべきか」を判断する方法
オンライン開催
50


# Page. 51

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

#CircleCIJP
Q&A
ご質問をチャット・Q&A機能でお寄せください
明日やること
① アンケート回答のお願い
今後のウェビナー改善のため、
ご回答にご協力ください。
https://form.typeform.com/to/SfZCylOK
01
測る
02
診断する
main ブランチの成功率と MTTR を確認
CoQ で失敗コストを金額・工数に翻訳
② 次回 Webinar 登録
5月26日(火) 14:00–15:00
「出荷できない」を解消する 3 つの型
03
回す
circleci.connpass.com/event/391632/
週次で 4 指標を追跡し、仕組み化する
ありがとうございました
51