--- title: 「検証」が静かに 膨らませる開発コスト: 見えない CI/CD 支出をどう捉えるか tags: author: [CircleCI Japan](https://www.docswell.com/user/circleci-japan) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/L71RQ8227G.jpg?width=480 description: CircleCI × PagerDuty 共催ウェビナー｜2026年8月21日 https://circleci.connpass.com/event/403399/ published: August 21, 26 canonical: https://www.docswell.com/s/circleci-japan/ZJWP9N-2026-10-28-140335 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/L71RQ8227G.jpg) CircleCI × PagerDuty 共催ウェビナー｜ 2026年8月21日 「検証」が静かに 膨らませる開発コスト 見えない CI/CD 支出をどう捉えるか 岡本 秀高 CircleCI 合同会社 Senior Field Engineer 1 # Page. 2 ![Page Image](https://bcdn.docswell.com/page/G7W1MZR2J2.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/4JZPQ1R473.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に追加公開 3 # Page. 4 ![Page Image](https://bcdn.docswell.com/page/YE6M6LRGJV.jpg) 調査結果｜ブランチ別スループット 生成されたコードの「リリース」が増えていない 中央値チームのワークフロー実行回数、前年比 AI 導入で増えるはずだったリリースは、実際には増えていない [年次] 中央値チーム・ワークフロー実行回数の前年比・2025年9月時点。 直近四半期では feature +7.7%・main は横ばい [Q2] p6。1プロジェクトあたりの平均スループットは前年比59%増 4 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/GE5Z618X74.jpg) AI による変化 AI は開発サイクルの「一部分」だけを高速化した Code Review Test Deploy Release 10x 1x 1x 1x 1x 5 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/972RM1KQER.jpg) 調査結果｜mainブランチのCI成功率 80% 未満 一方で Top 10以上のチームは生産性改善に成功 持ち直し傾向ながら、 AI以前より悪い状態のまま 6 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/DJYDXZNYJM.jpg) Merge Efficiency Ratio (MER) マージ効率（ MER）を見ると違いが可視化できる MER ＝ feature ブランチの実行回数 ÷ main の実行回数 1つの変更が main に 載るまで、検証を 何回走らせているか そのうち、 一発で通っているのは どれくらいか 7 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/V7N613XR78.jpg) Merge Efficiency Ratio (MER) CIコスト & MER で開発サイクルの現状を診断 中央値のチーム 上位20組織 +13% −31% 変更1件あたり CI クレジット（前年比） 変更1件あたり CI クレジット（前年比） 上位チームは中央値より約 51% 少ない コストでリリースする AI / チームは、手戻りの少ない開発サイクルを実現できていますか？ 8 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/YJ9L598ZE3.jpg) 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 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/GJ8XY9ZY7D.jpg) CI / CDが持つデータも Observability ( o11y )ツールで監視する CI / CD のデータを Open Telemetry ( OTEL )連携で監視ツールに送信 会社・チームで管理したい指標をダッシュボード化 DORA Four keys / CICDパフォーマンス / etc GitHub / Claude Codeなどと組み合わせた 開発サイクル全体のモニタリング 実装からデリバリーまでを１つのサービスで集約監視 10 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/LJL84WD9ER.jpg) マージ効率を高めるには、 push前の検証が必要 MER ＝ feature ブランチの実行回数 ÷ main の実行回数 「pushする前に、 動作チェックした？」 「そのエラー、 手元で再現させた？」 11 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/47M6K9PVJW.jpg) 「CI 前の検証精度」が、 MERやリリース量を左右する ● ● ● AI が引き起こすミスのパターンを特定 ○ テスト不⾜ ○ チェック漏れ ○ Headブランチへの追従もれ commit / push 前の検証を仕組み化 チェック内容の⾒直しと最適化 12 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/P7RPXG1WJ9.jpg) 「CI 前の検証精度」が、 MERやリリース量を左右する ● ● ● AI が引き起こすミスのパターンを特定 ○ テスト不⾜ ○ チェック漏れ ○ Headブランチへの追従もれ commit / push 前の検証を仕組み化 チェック内容の⾒直しと最適化 ① エージェントがコードを編集 ② 検証トリガー発火（ lint / test） ③ 結果判定 PASS → 次工程へ FAIL → 修正指示 AI がミスしたその場所で フィードバックできる仕組みを作る 13 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/PJX36XYV7X.jpg) 「Pushする前にやるべき検証」に目をむける Change Inner loop 手元の開発 Outer loop チームでの検証 Debug Plan Validate Code Release Build Deploy Validate Feedback 14 # Page. 15 ![Page Image](https://bcdn.docswell.com/page/3JKY1W357D.jpg) Chunk Sidecar Inner Loop https://chunk.ai/ Debug インナーループ で早期の検証、 AI slop をより効率的に捕捉する while the agent codes Validate Chunk sidecar Microbuild 15 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/LE39Q1G1E5.jpg) Chunk Sidecar Inner Loop https://chunk.ai/ Debug インナーループ で早期の検証、 AI slop をより効率的に捕捉する while the agent codes Hookやスキル の簡単セットアップ Validate CI 相当の環境で、高速に検証 Chunk sidecar 主要コーディング AI に対応 Microbuild 16 # Page. 17 ![Page Image](https://bcdn.docswell.com/page/8EDG9X1KEG.jpg) Chunk Sidecarが解決するローカル検証問題 1: エージェントに検証を強制させる仕組みがない 確実に検証させる仕組みを、Claude Codeでどう設定するか？ 2: 検証環境の構築と共有に手間がかかる CI 環境にちかい、「クリーンな検証環境」を数秒で用意できるか？ 3: エージェントの並列実行を妨げずに検証したい CPUリソースやアプリの port の奪い合いは発生しないか？ 17 # Page. 18 ![Page Image](https://bcdn.docswell.com/page/V7P3ZPQ3J8.jpg) Chunk Sidecarが解決するローカル検証問題 1: エージェントに検証を強制させる仕組みがない 確実に検証させる仕組みを、Claude Codeでどう設定するか？ 2: 検証環境の構築と共有に手間がかかる CI 環境にちかい、「クリーンな検証環境」を数秒で用意できるか？ 3: エージェントの並列実行を妨げずに検証したい CPUリソースやアプリの port の奪い合いは発生しないか？ セットアップコマンドで PJに最適な Hookをセットアップ microVM上に環境を構築し、 スナップショットで高速に再利用 microVMベースの検証環境で 迅速に並列で環境を起動 18 # Page. 19 ![Page Image](https://bcdn.docswell.com/page/2JV4W25N7Q.jpg) INNER LOOP VALIDATION Chunk Sidecarのはじめ方 Claude Code 等向けの Hook や設定ファイルの⽣成をまとめて実施 $ chunk init エージェントが検証をよりスムーズに実施するためのスキルを追加 $ chunk skill install エージェントセッション⽤の検証環境（ microVM ）を使ってテストを実施 $ chunk validate --remote 実際の開発サイクルでは、エージェントがスキルを使って⾃律的に作業 > /chunk-sidecar 19 # Page. 20 ![Page Image](https://bcdn.docswell.com/page/5EG1DR65JL.jpg) 実測ベンチマーク｜結果 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 # Page. 21 ![Page Image](https://bcdn.docswell.com/page/4JQD1V4L7P.jpg) より速いフィードバック、 より少ないトークン CI 相当の検証を AIの速度で高頻度に実行。 エージェントが手元で検証を実施した状態で Outer Loopの Pull Request としてコードを提出。 ● エージェントは素早く間違いに気付け、 27 秒 CIだと５分かかる検証タスクが、 microbuildで30秒以下に 78 % Checkout等のセットアップを省略 フル CI パイプラインより高速に 68 % 早期フィードバックの実現で AI のトークン効率を大幅改善 より精度の高いコードを少ないトークンで提出 ● 開発者は壊れた PR に注意を奪われず、 復旧作業による時間ロスも削減 「検証済みのコードをレビューに出す」という、 開発サイクルのあるべき姿を Chunk の力で実現 *社内検証結果に基づく数値 21 # Page. 22 ![Page Image](https://bcdn.docswell.com/page/K74ZRMQ5E1.jpg) 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 # Page. 23 ![Page Image](https://bcdn.docswell.com/page/LJ1RQ8P2JG.jpg) AIの速度では、犠牲にした品質の代償がすぐにくる Is High Quality Software Worth the Cost?: https://martinfowler.com/articles/is-quality-worth-cost.html *矢印は登壇者が追記 23 # Page. 24 ![Page Image](https://bcdn.docswell.com/page/GJW1MZ22E2.jpg) まとめ 検証を武器にする組織だけが差を広げる リリースは多くの会社でまだ増えていない。差を生むのは、pushする前の検証精度である。 01 AI活用の格差 02 判断基準は MER 03 本質は変わらない リリース量は増えず 検証を何回走らせているか 内部品質と高速フィードバック リリース頻度は伸びていない。 AIの使 いこなし度で、チーム間の差が広がっ ている。 見ているものが違っても、この数字は 共通言語になる。中央値 +13%、上位 組織−31%。 やるべきことは昔と同じ。内部品質を 保つ開発と、速く気づいて直せるサイ クルの構築。 出典: 2026 State of Software Delivery 定義: feature実行 ÷ main実行 支える機能 : Chunk Sidecar 検証の仕組み化が、次のリリースを増やす # Page. 25 ![Page Image](https://bcdn.docswell.com/page/4EZPQ1D4J3.jpg) Thank you. CircleCI × PagerDuty 共催ウェビナー｜2026年8月21日 X: @hidetaka_dev Qiita: https://qiita.com/CircleCIJapan EN: https://loop.circleci.com/