AI駆動開発の成果、 計測していますか？ データが示す、AI駆動開発のハマりどころ
>100 Views
April 21, 26
スライド概要
CircleCI Webinar | 2026年4月
開発の質と速度を底上げしよう！ 世界中のエンジニアが愛用する CI/CD ツール「CircleCI」の公式アカウントから日本語で最新情報をお届けします。 最新イベント・ミートアップ情報はこちら: http://circleci.connpass.com
関連スライド
各ページのテキスト
CircleCI Webinar | 2026年4月 AI駆動開発の成果、 計測していますか？ データが示す、AI駆動開発のハマりどころ 岡本 秀高 ( @hidetaka_dev ) Senior Field Engineer #CircleCIJP 1
自己紹介 Hidetaka Okamoto (岡本秀高 ) ● CircleCI Senior Field Engineer ● 年間100本ペースで記事を書く人 ● CircleCIJapan ( Qiita )にて4月は平日毎日更新中 https://qiita.com/CircleCIJapan #CircleCIJP 2
今日のゴール #CircleCIJP 3
今日のゴール AIツールの効果を「経営に説明できる数字」に変換する #CircleCIJP 4
>Agenda 1 来年もそのAIツール、使えますか？ 2 AIによる、ソフトウェアの「工業化」 3 2,800万ワークフローからAIの導入効果を検証する 4 開発の数字を経営の言葉へ変換する 5 上位5%から学ぶ AI 駆動開発でスケールする方法 6 明日からできること #CircleCIJP 5
01 来年もそのAIツール、 使えますか？ AIツールの導入効果計測と 継続利用に向けた費用対効果の考え方 #CircleCIJP 6
計画された 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
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
AI導入の各指標は、「導入過程」の計測であることが多い ① ② ③ トークン消費量 どれだけツールが利用されているか？ LoC ( Lines of Code ) どれだけのコードが生成されたか？ 開発者インタビュー 開発者にとって使いやすいツールか？ 9
評価指標を過程から結果にシフトする必要がある ① ② ③ ④ トークン消費量 どれだけツールが利用されているか？ LoC ( Lines of Code ) どれだけのコードが生成されたか？ 開発者インタビュー 開発者にとって使いやすいツールか？ DORA Four Keys 他 DevOps系指標 ビジネスに価値を届けられているか？ Claude CodeとDevinをFour Keysで検証——NTTドコモビジネスが3カ月 のコーディングエージェント導入で得たデータと教訓: https://codezine.jp/article/detail/23665 10
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
CircleCI のデータで、 Four Keys を計測する デプロイ頻度 ① PR マージ数 / CI パイプライン実行数 / デプロイワークフローの実行数 変更失敗率 ② 生成・マージしたコードの品質は改善したか？ CI ワークフローの成功率（本番ブランチ vs 機能ブランチ） MTTR ③ マージされたコミットや、リリースの数は？ 問題発生時、どれだけ速く復旧・修正できているか？ CI やアプリで問題が起きた時の復旧・修正速度 ソフトウェア開発の現場にある数字を元に、 AI による成果物の影響を計測する 12
02 AIによる、 ソフトウェアの「工業化」 最新技術やパラダイムを 伝統的な視点や取り組みから捉え直す 13
“ 企業のなかのムダは無数にあるが、 つくり過ぎのムダほど恐ろしいものはない 14
“ 企業のなかのムダは無数にあるが、 つくり過ぎのムダほど恐ろしいものはない ── 大野耐一『トヨタ生産方式』 15
ソフトウェア開発は「手工業」から「工業」へ転換している これまで：クラフト（手工業） AI時代：インダストリアル（工業） 人間が考え、人間が書く AIが生成し、AIがテストを書く 人間がレビューする 人間は判断に集中する → コード生産速度は 人間の認知速度で制約 コード生産速度が 人間の制約から解放 プロセスは「手工業」の ペースに合わせて設計 しかしプロセスは 「手工業」時代の設計のまま 工業化した瞬間に、工業の問題が起きる。大量生産・品質管理・待ち行列・ボトルネック ── 16
トヨタ生産方式（TPS）から学ぶ「７つのムダ」 ① ② ⑤ つくり過ぎのムダ 最も危険。必要以上に、必要より早くつくる。他の六つのムダを連鎖的に誘発する 在庫 ③ 不良 ④ 手待ち 使われない滞留 欠陥と手直し 次工程を待つ 運搬 加工 動作 価値を生まない移動 ⑥ 不要な工程 ⑦ 価値を生まない動き 出典: 大野耐一『トヨタ生産方式』 17
AI 駆動開発の課題を TPS にあてはめると・・・ TPSのムダ AI駆動開発での現れ方 ①つくり過ぎ AIがコードを大量生成 ②在庫 マージされないPR（書かれたがデプロイされないコード） ③不良 AI Slop(生成時)・CIエラーによる手戻り(検証時) 本番での障害(リリース後) ④手待ち レビュー待ち・CI待ち・デプロイ待ち ⑤運搬 指示者→AI→レビュアー間でのコンテキストの引き渡し ⑥加工 AI による過剰実装 ⑦動作 プロンプトの書き直し・コンテキスト再投入などのAI操作作業 18
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
投入量の線形増加が、積み残しを非線形に爆発させる 「つくり過ぎ」が「在庫」を誘発する、の非線形版 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
デリバリー側を速くすると大幅に緩和される 観察 : デリバリーを 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
大事なのは生成量ではなく、流量 1. AI駆動開発の悩みは、トヨタがかつて歩んだ道のりで説明できる → 「つくり過ぎ」を起点とする因果鎖は、ソフトウェアでも同じように働く 2. 鍵は「作りすぎないこと」ではなく「作ったものを滞留させないこと」 → Just In Timeの発想：必要なものを生成し、即座に出荷する 3. デリバリーを速く・効率化すれば、スループットは上がる → 経営が投資すべきは「AIツール」と「パイプライン」の両輪 22
03 2,800万ワークフローから AI導入の効果を検証する CircleCI State of Software Delivery 2026レポート 23
[おさらい ] CI指標から、開発チームの現状が可視化される デプロイ頻度 ① PR マージ数 / CI パイプライン実行数 / デプロイワークフローの実行数 変更失敗率 ② 生成・マージしたコードの品質は改善したか？ CI ワークフローの成功率（本番ブランチ vs 機能ブランチ） MTTR ③ マージされたコミットや、リリースの数は？ 問題発生時、どれだけ速く復旧・修正できているか？ CI やアプリで問題が起きた時の復旧・修正速度 24
CircleCI上で実際に稼働したCI/CDワークフローを分析 28,738,317 分析対象のワークフロー実行数 https://circleci.com/resources/2026-state-of-software-delivery/ 25
生産性が向上したチームは一部、しかし格差はより大きく 上位5%チームのWF実行量 中央値チームの WF 実行量 97%+ +4% 下位25%チームの WF 実行量 前年比 大幅な生産性向上を実現 0% 生成したものをどれだけリリースできているかが、 AI導入効果の差を生み出す 26
CircleCI Insightでスループットや成功率・MTTRをモニタリング 目指すべきベンチマーク スループット 1.71 / 日 ワークフロー実行数の目安 成功率 90% 以上 本来目指すべきパイプライン成功 率 MTTR 1時間 以内 Mainブランチ復旧時間の目安 27
CIの成功率が低下していないかは要チェック 70.8% Mainブランチの成功率 過去5年で最も悪い結果に 90% 以上 本来目指すべき パイプライン成功率 28
90%の成功率が70%まで落ちると何が起きるか？ 1日の変更頻度 成功率 70% 成功率 90% 差分 5件/日 1.5回/日の失敗 0.5回/日の失敗 年間 約250時間 約 250 時間 / 年 中規模チーム (50件/日) で、エンジニア 約1.25人分 の工数に相当 ※ 失敗1件あたり復旧60分 / 年間250営業日 / 1人年2,000時間で換算 29
MTTR 悪化は feature branch 側で起きている main ブランチは改善。問題は「マージ前の PR 段階」にある Feature branch MTTR +25% 64分 → 約80分 (前年比) Main branch MTTR 59.2分 60分ベンチマーク以下まで改善 • main ブランチは改善している • • 失敗 → マージ前に検知 → 修正のサイクルは機能している 問題は feature branch 側 • • AI 生成コードの不具合は修正に時間がかかりやすい マージされない PR が長期滞留する要因に 30
デリバリーに着⽬すると、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
04 開発の数字を 経営の言葉へ変換する 投資判断・効果測定につながる数字と そのストーリーの作り方を知る 32
CIから見えた現状や変化を、どのように伝えるか？ リサーチによる現状 この状態を放置すると、 年間いくら失うのか ? スループット feature +15% / main -7% 成功率 CI/CD への投資は、 いくらが適正なのか ? 70.8%（過去5年で最低） MTTR 72分（前年比 +13%） 何から手をつければ、 投資対効果が最大か ? 33
品質コスト ( CoQ )フレームワークで整理する ① 予防コスト ② 評価コスト 欠陥混入を防ぐ 顧客に届く前に検出 例: 設計レビュー、コーディング標準 例: テスティング、CI/CD ③ 内部失敗コスト ④ 外部失敗コスト リリース前に発見 リリース後に発見 例: 手戻り、再テスト、デバッグ 例: 本番インシデント、顧客離反、罰金 ← CI/CD はここ https://beyondquality.org/ 34
CircleCI Insight の指標を、 CoQ 4分類へ翻訳する CircleCI Insight で見る指標 CoQ 4分類での位置づけ 経営的な意味 スループット （feature vs main） 在庫 → ④外部失敗コストの予備軍 PRに滞留する未出荷コード = 寝かされた投資 成功率 ③内部失敗コスト 手戻り・再テスト・デバッグの工数増 MTTR ③内部失敗コスト（長期化） 失敗1件あたりの時間損失の大きさ CI/CD の継続実行 ②評価コスト（投資している部分） 顧客に届く前に検出するための仕組み 失敗コスト（③④）を可視化することで、評価コスト（② CI/CD）への投資の正当性 が計算できるようになる 35
3つの問いに、 CoQ で答える ③内部失敗コスト + ④外部失敗コストの合計で試算する Q1. 放置すると、年間いくら失うか？ 例: 成功率 70% → 90% の改善で、 年間 約250時間のエンジニア時間を失敗対応から回収 基準は「②評価 + ①予防 < ③④失敗コスト」が成立する水準 Q2. CI/CD 投資は、いくらが適正か？ 失敗コストを可視化して初めて、 CI/CDへの投資の ROI が数式として語れるようになる 失敗コストが最も大きい項目から Q3. どこから着手すれば効果が最大か？ まずは成功率（③不良）と MTTR（失敗の長さ）を継続観測し、 ボトルネックを特定する 36
05 上位5%から学ぶ AI 駆動開発でスケールする方法 データと事例から 導入時に意識すべきポイントを整理する 37
上位5%企業は、CI 4指標すべてでベンチマークを達成している 指標 中央値 上位5% 推奨 スループット変化 +4% +97% — main 変化 -7% +26% — 成功率 70.8% 90% 以上 90% 以上 所要時間（P50） 2分13秒 6秒 10分以内 72分 1分36秒 60分以内 MTTR 速さと品質はトレードオフではない── パイプラインを「生産システム」として設計している 38
上位5%は Inner Loop と Outer Loop を揃えている 中央値チームと上位5%を feature / main で分解して比較する 中央値チーム Feature branch スループット +15% Main branch スループット -7% → feature が膨らんで main に届かない
上位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
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
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
ROI計算機で Autonomous Validation （自律的検証）効果を試算する テスト高速化や自動修正・最適化で、AIの導入効果を更に高める https://circleci.com/autonomous-validation-roi/ 43
06 明日からできること AI駆動開発の現状を見るために、 CIパイプラインの現状をチェックする 44
明⽇からできること ── 3つのステップ STEP 1 測る CIサービスダッシュボードで 直近30⽇の main ブランチの 成功率と MTTR を確認する。 まず現在地を知る 44
明⽇からできること ── 3つのステップ STEP 1 STEP 2 測る 診断する CIサービスダッシュボードで 直近30⽇の main ブランチの 成功率と MTTR を確認する。 ベンチマーク未達の指標を CoQ の内部失敗コストとして 年間⼯数‧⾦額に換算する。 失敗コストが最⼤の項⽬が、 最初の改善ターゲット。 まず現在地を知る 数字を経営の⾔葉に翻訳する 44
明⽇からできること ── 3つのステップ STEP 1 STEP 2 STEP 3 測る 診断する 回す CIサービスダッシュボードで 直近30⽇の main ブランチの 成功率と MTTR を確認する。 ベンチマーク未達の指標を CoQ の内部失敗コストとして 年間⼯数‧⾦額に換算する。 失敗コストが最⼤の項⽬が、 最初の改善ターゲット。 週次で4指標を追跡し、改善施 策の優先順位付けと投資判断 を継続的に回す。 まず現在地を知る 数字を経営の⾔葉に翻訳する ⼀度ではなく、仕組みにする ※ 指標が⾒えなくても、何が⾒えて何が⾒えないかの棚卸しから始められます 44
AIの導⼊効果を数字によって説明できるようにする 「速くなりました」 から 「本番到達率は ○%、成功率は ○%、 復旧時間は ○分です」 48
まとめ 1 AI はコード⽣成を加速した 2 しかし中央値チームでは出荷（リリース）が増えず、 成功率が低下し、復旧に時間がかかっている 3 リリースされないコードが増えると、TPSの「作りすぎのムダ」が⽣まれ、 CoQの内部失敗→外部失敗が発⽣しやすくなる 4 上位5%の特徴は、パイプラインを『⽣産システム』として運⽤していること 5 測って、診断して、仕組みにしよう 46
次回予告 CircleCI Webinar | 2026年5月 AI駆動開発の 「速く書けるのに出荷できない」 を解消する 上位5%が実践する 3つの改善パターンを掘り下げ https://circleci.connpass.com/event/391632/ フレーキーテスト排除・テスト並列化・ロールバック自動化 CoQ を使った投資判断の詳細 5月26日 (火) 14:00 - 15:00 ダッシュボードで「どこから着手すべきか」を判断する方法 オンライン開催 50
#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