「検証」が静かに 膨らませる開発コスト: 見えない CI/CD 支出をどう捉えるか

CircleCI × PagerDuty 共催ウェビナー｜ 2026年8月21日 「検証」が静かに 膨らませる開発コスト 見えない CI/CD 支出をどう捉えるか 岡本 秀高 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

• https://qiita.com/CircleCIJapan

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に追加公開 3

• https://circleci.com/resources/2026-state-of-software-delivery-q2-pulse/
• https://circleci.com/resources/2026-state-of-software-delivery/

調査結果｜ブランチ別スループット 生成されたコードの「リリース」が増えていない 中央値チームのワークフロー実行回数、前年比 AI 導入で増えるはずだったリリースは、実際には増えていない [年次] 中央値チーム・ワークフロー実行回数の前年比・2025年9月時点。 直近四半期では feature +7.7%・main は横ばい [Q2] p6。1プロジェクトあたりの平均スループットは前年比59%増 4

AI による変化 AI は開発サイクルの「一部分」だけを高速化した Code Review Test Deploy Release 10x 1x 1x 1x 1x 5

調査結果｜mainブランチのCI成功率 80% 未満 一方で Top 10以上のチームは生産性改善に成功 持ち直し傾向ながら、 AI以前より悪い状態のまま 6

Merge Efficiency Ratio (MER) マージ効率（ MER）を見ると違いが可視化できる MER ＝ feature ブランチの実行回数 ÷ main の実行回数 1つの変更が main に 載るまで、検証を 何回走らせているか そのうち、 一発で通っているのは どれくらいか 7

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

Merge Efficiency Ratio (MER) 自組織の CI成功率が低いときに見る順番 失敗の内訳を分解する 01 cancelled の割合と auto-cancel 設定 定義由来の見かけ上の悪化を先に除去する 02 再実行で緑になった割合（ flaky 率） 半分を超えるなら、テストを増やすのは逆効果 03 merge した後の main で落ちているか 落ちているなら検証の「量」ではなく「種類」が足りていない 04 MER feature ブランチの実行回数 ÷ main の実行回数 05 main の MTTR 60分の目安に対してどこか（ [年次] では 59.2分・2025年9月時点） 9

CI / CDが持つデータも Observability ( o11y )ツールで監視する CI / CD のデータを Open Telemetry ( OTEL )連携で監視ツールに送信 会社・チームで管理したい指標をダッシュボード化 DORA Four keys / CICDパフォーマンス / etc GitHub / Claude Codeなどと組み合わせた 開発サイクル全体のモニタリング 実装からデリバリーまでを１つのサービスで集約監視 10

マージ効率を高めるには、 push前の検証が必要 MER ＝ feature ブランチの実行回数 ÷ main の実行回数 「pushする前に、 動作チェックした？」 「そのエラー、 手元で再現させた？」 11

「CI 前の検証精度」が、 MERやリリース量を左右する ● ● ● AI が引き起こすミスのパターンを特定 ○ テスト不⾜ ○ チェック漏れ ○ Headブランチへの追従もれ commit / push 前の検証を仕組み化 チェック内容の⾒直しと最適化 12

「CI 前の検証精度」が、 MERやリリース量を左右する ● ● ● AI が引き起こすミスのパターンを特定 ○ テスト不⾜ ○ チェック漏れ ○ Headブランチへの追従もれ commit / push 前の検証を仕組み化 チェック内容の⾒直しと最適化 ① エージェントがコードを編集 ② 検証トリガー発火（ lint / test） ③ 結果判定 PASS → 次工程へ FAIL → 修正指示 AI がミスしたその場所で フィードバックできる仕組みを作る 13

「Pushする前にやるべき検証」に目をむける Change Inner loop 手元の開発 Outer loop チームでの検証 Debug Plan Validate Code Release Build Deploy Validate Feedback 14

Chunk Sidecar Inner Loop https://chunk.ai/ Debug インナーループ で早期の検証、 AI slop をより効率的に捕捉する while the agent codes Validate Chunk sidecar Microbuild 15

• https://chunk.ai/

Chunk Sidecar Inner Loop https://chunk.ai/ Debug インナーループ で早期の検証、 AI slop をより効率的に捕捉する while the agent codes Hookやスキル の簡単セットアップ Validate CI 相当の環境で、高速に検証 Chunk sidecar 主要コーディング AI に対応 Microbuild 16

• https://chunk.ai/

Chunk Sidecarが解決するローカル検証問題 1: エージェントに検証を強制させる仕組みがない 確実に検証させる仕組みを、Claude Codeでどう設定するか？ 2: 検証環境の構築と共有に手間がかかる CI 環境にちかい、「クリーンな検証環境」を数秒で用意できるか？ 3: エージェントの並列実行を妨げずに検証したい CPUリソースやアプリの port の奪い合いは発生しないか？ 17

Chunk Sidecarが解決するローカル検証問題 1: エージェントに検証を強制させる仕組みがない 確実に検証させる仕組みを、Claude Codeでどう設定するか？ 2: 検証環境の構築と共有に手間がかかる CI 環境にちかい、「クリーンな検証環境」を数秒で用意できるか？ 3: エージェントの並列実行を妨げずに検証したい CPUリソースやアプリの port の奪い合いは発生しないか？ セットアップコマンドで PJに最適な Hookをセットアップ microVM上に環境を構築し、 スナップショットで高速に再利用 microVMベースの検証環境で 迅速に並列で環境を起動 18

INNER LOOP VALIDATION Chunk Sidecarのはじめ方 Claude Code 等向けの Hook や設定ファイルの⽣成をまとめて実施 $ chunk init エージェントが検証をよりスムーズに実施するためのスキルを追加 $ chunk skill install エージェントセッション⽤の検証環境（ microVM ）を使ってテストを実施 $ chunk validate --remote 実際の開発サイクルでは、エージェントがスキルを使って⾃律的に作業 > /chunk-sidecar 19

実測ベンチマーク｜結果 CIではなく手元で検証させることにより、トークン量を削減 RAW ＝ CI 生ログをそのまま渡す ／ SIDECAR ＝ Chunk sidecar の出力 中央値 RAW SIDECAR (a) ESLint 20,537 2,079 (b) env var 22,121 3,382 RAW ÷ SIDECAR ＝ 6.5〜9.9× フィードバック 1 回分で 85〜90% 減 20

より速いフィードバック、 より少ないトークン CI 相当の検証を AIの速度で高頻度に実行。 エージェントが手元で検証を実施した状態で Outer Loopの Pull Request としてコードを提出。 ● エージェントは素早く間違いに気付け、 27 秒 CIだと５分かかる検証タスクが、 microbuildで30秒以下に 78 % Checkout等のセットアップを省略 フル CI パイプラインより高速に 68 % 早期フィードバックの実現で AI のトークン効率を大幅改善 より精度の高いコードを少ないトークンで提出 ● 開発者は壊れた PR に注意を奪われず、 復旧作業による時間ロスも削減 「検証済みのコードをレビューに出す」という、 開発サイクルのあるべき姿を Chunk の力で実現 *社内検証結果に基づく数値 21

CICD成功率の悪化は、開発工数に跳ね返る 成功率 90% 停止級の破損は 2日に1回 +125時間 / 年 成功率 80% 停止級の破損は 1日1回 main への変更 5件/日・復旧1時間の場合の増分 頻度は 2倍 [年次] p13 の計算式（1日の変更数 × 失敗率・復旧60分/回・年250営業日）に 80% を代入した自算。レポート記載値は 70% 前提の「3倍 / 250時間 / 12人分」。検算: 5件 ×20%=1.0回/日 と 5件×10%=0.5回/日 の差 0.5回/日 → 約125時間/年 22

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

• https://martinfowler.com/articles/is-quality-worth-cost.html

まとめ 検証を武器にする組織だけが差を広げる リリースは多くの会社でまだ増えていない。差を生むのは、pushする前の検証精度である。 01 AI活用の格差 02 判断基準は MER 03 本質は変わらない リリース量は増えず 検証を何回走らせているか 内部品質と高速フィードバック リリース頻度は伸びていない。 AIの使 いこなし度で、チーム間の差が広がっ ている。 見ているものが違っても、この数字は 共通言語になる。中央値 +13%、上位 組織−31%。 やるべきことは昔と同じ。内部品質を 保つ開発と、速く気づいて直せるサイ クルの構築。 出典: 2026 State of Software Delivery 定義: feature実行 ÷ main実行 支える機能 : Chunk Sidecar 検証の仕組み化が、次のリリースを増やす

Thank you. CircleCI × PagerDuty 共催ウェビナー｜2026年8月21日 X: @hidetaka_dev Qiita: https://qiita.com/CircleCIJapan EN: https://loop.circleci.com/