AI 時代の「詰まらない」開発戦略: 手元の検証・CI・実行基盤を、今日から速くする

CircleCI ウェビナー｜ 2026年7月21日 AI 時代の「詰まらない」開発戦略 手元の検証・CI・実行基盤を、今日から速くする Chunk Sidecar ／ Smarter Testing ／ Gen2 リソースクラス 岡本 秀高 ( @hidetaka_dev ) CircleCI Senior Field Engineer 1

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

• https://qiita.com/CircleCIJapan

CircleCI について AI 速度でコードを検証する、 世界トップクラスの CI/CD プラットフォーム 10K 200万 9,000万 300+ 顧客企業 ユーザー（開発者） 月間ビルド数 従業員数（全世界） ISV / DNB 小売・消費財 運輸・物流 ヘルスケア・製薬 メディア・広告 DevOps・セキュリティ

Problem 4

Problem コーディング AIを入れたのに 思ったよりも成果が出ない 5

Problem コーディング AIを入れたのに 思ったよりも成果が出ない コードを書く時間は減ったが レビューと修正指示で忙しい 6

２つの問題の裏にある共通項 7

２つの問題の裏にある共通項 フィードバックサイクルが コード生成の速度と一致していない 8

AI による変化 開発サイクルは Inner (手元の開発 )と Outer ( PR作成後 ) で等速だった

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

AI による変化 AI は開発サイクルの「一部分」だけを高速化した AIによるPRが ここで詰まる AI の速度を、Outer Loop が減速させている

世界中の CI 実ワークフロー実⾏を CircleCI が分析 平均スループット 2,800万 ワークフロー +59% 前年⽐ / 全プロジェクト平均 出典: CircleCI State of Software Delivery Report 2026 https://circleci.com/resources/2026-state-of-software-delivery/ 過去7年で⾒たことのない規模の変化が 開発の現場で発⽣している 12

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

State of Software Delivery report メインブランチへのマージ量は増えず、CICD成功率は5年間で最低 13

成功率の20ポイント低下 が生むコスト 成功率20%低下 = 失敗が3倍 1日5変更の場合 年間 250時間 の損失 MTTR = 60分／障害 1日500変更の場合 年間 25,000時間 の損失 1日500変更を回すチームは、フルタイムエンジニア 12名分に相当する時間を失っている 14

AI駆動開発によって増加する「見落とされがちなコスト」 CI ジョブの実行コスト エージェントが書いたコードの検証を 全てCIで実行させた時の副作用。 ローカルでやるべき検証についても、 CI上で複数回実行されている。

AI駆動開発によって増加する「見落とされがちなコスト」 CI ジョブの実行コスト エージェントが書いたコードの検証を 全てCIで実行させた時の副作用。 ローカルでやるべき検証についても、 CI上で複数回実行されている。 エージェントのトークン・クレジット CIやレビューエージェント任せの検証では、 早期フィードバックが困難。 小さなミスをAIが見落とし、大きなバグとして CIが検知する。 手戻りやエラーログ読み取り時のトークン・クレジット消費がそのまま追加コストへ

AIの開発速度にあったフィードバックループを開発サイクルへ Change Inner loop Outer loop Debug Plan Validate Code Release Build Deploy Validate Feedback 17

Solution AIの速度に合わせた開発サイクルを作る３ステップ 01 開発サイクルの 「詰まり」を可視化 Inner Loop / Outer Loopのどこで 生成されたコード / PR は滞留しているか？ 18

Solution AIの速度に合わせた開発サイクルを作る３ステップ 01 開発サイクルの 「詰まり」を可視化 Inner Loop / Outer Loopのどこで 生成されたコード / PR は滞留しているか？ 02 実装内容の検証を シフトレフト コードをpushする前にできる検証を CI フェーズまで後回しにさせていないか？ 19

Solution AIの速度に合わせた開発サイクルを作る３ステップ 01 開発サイクルの 「詰まり」を可視化 Inner Loop / Outer Loopのどこで 生成されたコード / PR は滞留しているか？ 02 実装内容の検証を シフトレフト コードをpushする前にできる検証を CI フェーズまで後回しにさせていないか？ 03 Outer Loopを AI の速度に追従する CI / CDやAIレビューの待ち時間は もっと短くできないのか？ 20

01 開発サイクルの 「詰まり」を可視化 21

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/ 22

• https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

開発サイクルでの「詰まり」は、数字化できていますか？ 01 CIワークフローの ブランチ別実⾏数 Featブランチのみ増加 PRODブランチも増加している コードがマージできていない → QA や レビューでの詰まり 23

開発サイクルでの「詰まり」は、数字化できていますか？ 01 02 CIワークフローの ブランチ別実⾏数 CIワークフローの ブランチ別成功率 Featブランチのみ増加 PRODブランチも増加している AI導入前より・・・ ・改善している ・現状維持 ・悪化している コードがマージできていない 低品質なコード⽣成が増加 → QA や レビューでの詰まり → コード⽣成フローの⾒直し 24

開発サイクルでの「詰まり」は、数字化できていますか？ 01 02 03 CIワークフローの ブランチ別実⾏数 CIワークフローの ブランチ別成功率 MTTR Featブランチのみ増加 PRODブランチも増加している AI導入前より・・・ ・改善している ・現状維持 ・悪化している CI Failや障害発⽣時に、 復旧まで何分かかりますか？ コードがマージできていない 低品質なコード⽣成が増加 問題の特定や検証コストの増減 → QA や レビューでの詰まり → コード⽣成フローの⾒直し → 認知負債が増えていないか？ 25

CircleCI Insights で「詰まりの兆候」を診断する プロジェクト View ワークフロー View ブランチ・ジョブごとの実行時間や成功率・クレジット消費などを可視化 いつ何が失敗したか？や、失敗したテストのリストなどを可視化 ソフトウェア開発の現場にある数字を元に、 AI による成果物の影響を計測する 26

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) 27

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

自チームの現在地 パイプラインの健康は、 3 つの指標で測れる 指標 中央値 Top 5% 推奨ベンチマーク スループット（日次） 1.71 13.36 1 以上 成功率（main・平均） 70.8% ─ 90% 復旧時間（MTTR） 72 分 1 分 36 秒 60 分 出典: CircleCI 2026 State of Software Delivery（2025年9月・2,800万ワークフロー） 29

02 実装内容の検証を シフトレフトする 30

CI でやるべきことと AI が CI に押し付けていることを 整理する Change ジョブキュー PR待機列 Release Build Deploy Test Feedback 31

CI でやるべきことと AI が CI に押し付けていることを 整理する Change ジョブキュー PR待機列 Release Build Deploy Test • 本来 CI はフルバリデーションの場所 ○ 手動レビューやテスト前の Gate • AI エージェントは「 CI通過」を 実装タスクのゴール要件として指定されがち ○ CIが通るまでリトライが最適解に Inner Loop( エージェントのセッション )で やるべき検証を CI でやっていないか？ Feedback 32

Inner Loopの検証（ Validate）は適切に実施されているか？ Change Inner loop Outer loop Debug Plan Validate Code Release Build Deploy Validate Feedback 33

AIエージェントに検証タスクを指示する方法 1: プロンプトで検証まで実施することを指示する ① エージェントがコードを編集 手軽に始めれるが、本当に検証を実施してくれるとは限らない ② 検証トリガー発火（ lint / test） ③ 結果判定 PASS → 次工程へ FAIL → 修正指示 34

AIエージェントに検証タスクを指示する方法 1: プロンプトで検証まで実施することを指示する ① エージェントがコードを編集 手軽に始めれるが、本当に検証を実施してくれるとは限らない ② 検証トリガー発火（ lint / test） 2: Git Hookでテスト実行を指示 コードをpushする前に検証を強制。序盤のミスによる歪みに弱い ③ 結果判定 PASS → 次工程へ FAIL → 修正指示 35

AIエージェントに検証タスクを指示する方法 1: プロンプトで検証まで実施することを指示する ① エージェントがコードを編集 手軽に始めれるが、本当に検証を実施してくれるとは限らない ② 検証トリガー発火（ lint / test） 2: Git Hookでテスト実行を指示 コードをpushする前に検証を強制。序盤のミスによる歪みに弱い 3: Claude Code等のHookでテスト実行を指示 ③ 結果判定 PASS → 次工程へ FAIL → 修正指示 ファイル編集や特定コマンド実行毎に検証。確実だがステップが増える 36

Hook の整備と保守は誰がやるのか？ 37

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

• https://chunk.ai/

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

• https://chunk.ai/

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

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

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

実測ベンチマーク｜結果 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% 減 43

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

Chunk Sidecar OR AND CI 観点 Chunk Sidecar（Inner Loop） CircleCI（Outer Loop） 目的 push 前に早く安く気づく 統合後に本番品質を担保する タイミング エージェントのコード編集中 PR 作成後・マージ前 検証の粒度 影響範囲の軽量チェック フル検証（E2E・統合を含む） 得意なこと Lint・型・単体の即時フィードバック 最終ゲート・回帰・デプロイ判定 位置づけ Inner Loop の品質ゲート デプロイ・リリース前の品質ゲート 45

03 Outer Loopを AI の速度に追従する 46

Inner Loop起因の詰まりは、 Outer Loopでも軽減できる 「開発サイクルの詰まり」を軽減・解消すれば、デリバリーの総量は大きく増える 60分 → 54分 のデリバリー短縮で -55% 14日間の積み残し（ 22.4件→10.0件） 数値の出典: Michael Webster（CircleCI）のシミュレーションを+20% シナリオで14日間に外挿 / Webinar "How AI is Breaking the SDLC" 「エンドツーエンドのパイプラインがきちんとチューニングされていないなら、AI は状況を救わない。状況を複雑にするだけだ」 — Brad Johnson, Worldwide Category Manager, AWS / Webinar "State of Software Delivery" 47

Outer Loopの詰まりを軽減させる方法 Before 全テストを 毎回実行 遅い 実行基盤 失敗は 手動でやり直し 遅い・ コスト増 48

Outer Loopの詰まりを軽減させる方法 Before 全テストを 毎回実行 遅い 実行基盤 失敗は 手動でやり直し 遅い・ コスト増 影響テスト だけ実行 速い 実行基盤 失敗だけ 自動再実行 速い・安い・ 止まらない After 49

Outer Loopを高速化する CircleCI 3つの機能 Release Build Gen. 2 スケーラブルな CI 実行インフラ（ Gen.2） ビルドの高速化とコスト最適化を実現 Smarter Testing チェックすべきテストだけを実行し、待ち時間を高速化 Deploy Test Smarter Testing Auto Rerun & SSH Debug 失敗したテストを、指定した回数まで自動的にリトライ ジョブにSSHで直接アクセスしてデバッグ 50

Outer Loop の詰まりを減らす CI の高速化は、バッチ処理の高速化として考える ジョブの特性に合わせて、2 つのスケール戦略を使い分ける スケールアップ スケールアウト CPU バウンドなジョブ（コンパイル等） メモリ要求の大きい E2E／統合テスト テスト数が多いジョブ（ユニット・回帰） コンテナ並列で実行時間を 1/N に 過剰スペック ＝ コスト増 ／ 過小スペック ＝ 実行時間増 → 総コスト増 51

CIサービスの移行だけで リードタイムを２５分短縮 「CI機能に特化したツールならではの使い勝手の良さをと ても気に入っています。エンジニアの間にも、『自分たちで 主体的にテストを実施していこう』『サイト信頼性エンジニア リング（SRE）のメンバーに負担をかけずに、自立してサー ビス品質の改善を進めよう』といった前向きな意識が広がっ ているように感じます」 https://circleci.com/ja/case-studies/andpad/ CI の高速化は 生産性に貢献する 52

• https://circleci.com/ja/case-studies/andpad/

CircleCI Gen2 resourceクラス 1行の変更で、早さとコスト削減を実現 .circleci/config.yml 最大180%の高速 CPU マルチコアを飽和させる並列テスト・ビルドなどに効果的 高速化によるコストダウンと効率化 多くのケースでテストやビルドが高速化、 実行時間短縮による生産性改善と、クレジットコスト削減へ jobs: build: machine: image: ubuntu-2404:current # before resource_class: large # after ← 1 行変えるだけ resource_class: large.gen2 1 行で切替、小さく試して移行が可能 resource_class に .gen2 を付与するだけで移行可能 最大180%は CPU 性能（Gen1比・公式）／68%は CircleCI 社内計測。対象は Cloud。単価はクラスにより増減し、Docker Gen2 は有料プラン。

gen2クラスの向き・不向き CPUを消費するジョブでは効果的 Networkアクセス系のジョブでは限定的 最大180%は CPU 性能（Gen1比・公式）／68%は CircleCI 社内計測。対象は Cloud。単価はクラスにより増減し、Docker Gen2 は有料プラン。

Smarter Testing Beta テスト結果を継続分析し、必要なテストのみを選別・実行する最適化機能 影響のないテストの自動スキップ コードの変更差分を瞬時に解析し、 関係のないテストを排除して CI 時間を大幅に削減 並列実行の動的最適化 選別されたテストを複数ジョブへ自動分割し、 コンテナの計算リソースを無駄なく活用 次回の高速化に向けた自動学習 実行後のカバレッジを継続分析し、 次回の選別精度を高める影響度データを自動更新 55

Smarter Testing Beta テスト結果を継続分析し、必要なテストのみを選別‧実⾏する最適化機能 56

Smarter Testing Beta 01 準備 最新 CLI ＋ testsuite プラグイン、JUnit XML 出力 02 ローカルで検証 test-suites.yml を作り circleci testsuite --doctor（アカウント不要） # .circleci/test-suites.yml name: ci tests discover: vitest list --filesOnly run: vitest run --reporter=junit --outputFile="<< outputs.junit >>" << test.atoms >> outputs: junit: test-reports/results.xml options: # 必要な機能だけ ON test-impact-analysis: true # .circleci/config.yml - run: circleci testsuite "ci tests" 03 CI で実行 → 機能 ON config を置換して push、必要な機能を個別に有効化 57

Auto return Flakyなテストなどの失敗を検知し、最⼤５回まで⾃動的にワークフローやジョブを再実⾏ version: 2.1 jobs: my-job: steps: - run: command: echo "Return 3 times" max_auto_reruns: 3 workflows: test-workflow: max_auto_reruns: 4 jobs: - my-job - test #CircleCIJP 58

SSHデバッグ: 実⾏環境内で直接調査 失敗したジョブに SSH 接続して、再現環境を作る⼯程を省略 「再現環境を作る」時間がゼロになる → 原因特定の初動を⼤幅に短縮 #CircleCIJP 59

Outer Loop を「遅い」から「速い」へ組み替える 観点 Before After（CircleCI） テスト実行 全テストを毎回実行 影響のあるテストだけ選別（ Smarter Testing） 実行基盤 遅い実行基盤で待たされる 1 行で Gen.2 に切替（最大 180% CPU） 失敗時 手動でやり直し 失敗だけ自動再実行＋ SSH で即調査 結果 遅い・コスト増 速い・安い・止まらない CI の高速化は、リードタイムを縮め、そのまま生産性への貢献になる。 60

まとめ AIコーディングの「詰まり」は、 時間とコストで跳ね返る。 成功率の低下も、AI 任せの検証も、見えないコストを生んでいる。 手戻りの時間コスト ＋ 投機的 CI 実行コスト ＋ トークン・クレジット 61

より速いフィードバック、 より少ないトークン ● ● エージェントや開発者が手元（ Inner Loop）で こまめに検証を実施する仕組みを構築 小さなミスに素早く気づいて修正、 Outer LoopのCIが動く前に歪みを正す 「検証済みのコードをレビューに出す」という、 開発サイクルのあるべき姿を Chunk の力で実現 27 秒 CIだと５分かかる検証タスクが、 microbuildで30秒以下に 78 % Checkout等のセットアップを省略 フル CI パイプラインより高速に 68 % 早期フィードバックの実現で AI のトークン効率を大幅改善 *社内検証結果に基づく数値 62

AI の速度に、 開発サイクル全体を合わせる。 詰まりの可視化から、Inner Loop、Outer Loop まで。3 つのステップで進める 01 可視化 → 02 シフトレフト → 03 Outer Loop 追従 63

自チームの現在地 01: CICDの指標から、開発チームの現状を可視化する 指標 中央値 Top 5% 推奨ベンチマーク スループット（日次） 1.71 13.36 1 以上 成功率（main・平均） 70.8% ─ 90% 復旧時間（MTTR） 72 分 1 分 36 秒 60 分 出典: CircleCI 2026 State of Software Delivery（2025年9月・2,800万ワークフロー） 64

02: コード変更の検証を、できるだけ早くこまめに実施する 観点 Chunk Sidecar（Inner Loop） CircleCI（Outer Loop） 目的 push 前に早く安く気づく 統合後に本番品質を担保する タイミング エージェントのコード編集中 PR 作成後・マージ前 検証の粒度 影響範囲の軽量チェック フル検証（E2E・統合を含む） 得意なこと Lint・型・単体の即時フィードバック 最終ゲート・回帰・デプロイ判定 位置づけ Inner Loop の品質ゲート デプロイ・リリース前の品質ゲート 65

03: CIそのものを高速化し、素早くミスを AIにフィードバック 観点 Before After（CircleCI） テスト実行 全テストを毎回実行 影響のあるテストだけ選別（ Smarter Testing） 実行基盤 遅い実行基盤で待たされる 1 行で Gen.2 に切替（最大 180% CPU） 失敗時 手動でやり直し 失敗だけ自動再実行＋ SSH で即調査 結果 遅い・コスト増 速い・安い・止まらない CI の高速化は、リードタイムを縮め、そのまま生産性への貢献になる。 66

まとめ フィードバックサイクルを、 AIの速度へ 試す Chunk Sidecar を手元で 計測する Insights で成功率と MTTR を見る 深める Gen.2・Smarter Testing を試す 詰まらない開発サイクルへ。まずは 1 つ、今日から。 67