AI時代の品質管理 - CIコストを抑える検証フローの作り方

CircleCI × Postman 共催ウェビナー｜ 2026年10月6日 AI時代の品質管理 CIコストを抑える検証フローの作り方 岡本 秀高 ( @hidetaka_dev ) 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 2026 世界的に CI の実行回数は増加傾向 これまでにない増加量で、AI コーディング普及の影響が高い 1日あたりのワークフロー実行回数の前年比（チームの帯別） 100% +97% 75% +47% 50% +25% 25% 0% +4% 0% 下位25% 中央値 上位25% 出典: 2026 State of Software Delivery p2・p4–5（2025年9月1〜28日のデータ） 上位10% 上位5%

State of Software Delivery 2026 Q2 Pulse ただしCIクレジットの増加幅には差がある CircleCI上のスループット量が高い企業ほど、１変更あたりのクレジットは減少 変更1件あたりの CI クレジット（前年比） +20% +13% +10% 0% −10% −20% −30% −31% −40% 中央値のチーム 上位20組織 出典: 2026 State of Software Delivery Q2 Pulse p16・p17（2026年3月1〜28日、前年同期間比）

本日の進め方 アジェンダ 01 なぜ CI コストは増加するのか？ 02 AI に人間が従来やってきた開発スタイルを徹底させる方法 03 CI のガバナンス・セキュリティは CIで

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

• 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%増 7

調査結果｜mainブランチのCI成功率 mainブランチも CI エラーが増加 80% 未満 持ち直し傾向ながら、 AI以前より悪い状態のまま ① 意味的衝突： 長期間のFeatureなど、マージ後に矛盾が発生 ② 検査範囲の差： リリース前のE2Eテストなどでバグが発覚 ③ flakyテスト： マージ前チェックでは運よく成功していた 8

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

自チームの診断｜MER と1回あたりのクレジット CIコストは「回数」と「 1回の重さ」に分けて見る 回数（MER） × 1回の重さ 中央値 3.9 → 上位20組織 1.3 MER が横ばいでも この差で約 51%違う コストが上がるなら疑う ＝ 変更1件のクレジット まず自チームの値を測る AI / チームは、手戻りの少ない開発サイクルを実現できていますか？ 出典: 2026 State of Software Delivery Q2 Pulse p12・p16

なぜAIコーディングで CI コストが増えているのか？ 11

Merge Efficiency Ratio (MER) MERが増えている = マージまでの CI実行数が多い MER ＝ feature ブランチの実行回数 ÷ main の実行回数 1つの変更が main に 載るまで、検証を 何回走らせているか そのうち、 一発で通っているのは どれくらいか 12

手元でテストを回さずに PR を出してくる 新メンバーが入ったら、どうしますか？

作業手順のガバナンスが、 AI に届いていない 人間のチーム 変更 エージェント 変更 手元で検証 手元で検証 省略 push push CI 1回で通る CI 失敗 →修正 →再実行

手元で止める コミット前とターン終了時に止める git commit の直前 PreToolUse / pre-commit エージェントの作 業 検証 ターン終了時 Stop フック 失敗なら差し戻し $ git commit $ npm test × returns a personalized greeting expected 'Hello, name!' to be 'Hello, Chunk!' → コミットは成立しない

事例 既存テストの失敗を「無関係」として、エージェントが止まろうとした APIを追加するタスクで、エージェントは既存テストの失敗を今回の変更とは無関係と判断。 エージェント テスト Stop フック /reiwa のテストを実行 通過 既存の /business-days：1件失敗 無関係と判断し、ターンを終える 差し戻し

ローカル検証のハーネスにおける課題 01 誰がどうやって Hook を整備するのか？ 02 検証結果が環境依存じゃないとどう証明するか？ 03 テストが増えた時のチューニングなどはどうするか？

Chunk Sidecar ( Preview | Free) AIにもローカル検証を実⾏させるための、 エージェントハーネスツール群 ● 検証を強制する Agent Hook ● 検証⽅法などを伝える Agent Skill ● 検証環境としての Remote MicroVM ● それらを操作するための CLI 18

Chunk Sidecar ( Preview | Free) AIにもローカル検証を実⾏させるための、 エージェントハーネスツール群 ● 検証を強制する Agent Hook ● 検証⽅法などを伝える Agent Skill ● 検証環境としての Remote MicroVM ● それらを操作するための CLI 仕組み 19

Chunk Sidecar ( Preview | Free) AIにもローカル検証を実⾏させるための、 エージェントハーネスツール群 仕組み ツール ● 検証を強制する Agent Hook ● 検証⽅法などを伝える Agent Skill ● 検証環境としての Remote MicroVM ● それらを操作するための CLI 20

Chunk Sidecar ( Preview | Free) AIにもローカル検証を実⾏させるための、 エージェントハーネスツール群 仕組み ツール ● 検証を強制する Agent Hook ● 検証⽅法などを伝える Agent Skill ● 検証環境としての Remote MicroVM ● それらを操作するための CLI 検証環境 21

Chunk sidecar CI に近い Linux microVM で、push 前に検証する chunk init がフックを設置し、フックが chunk validate で sidecar 上の検証を実行する。コミット前の変更をそのまま検証 でき、CircleCI の全ユーザーが使える。 手元 CircleCI 検証結果 Chunk sidecar エージェント Linux microVM ワークスペース 同期して検証 コミット前の変更 出典: Q2 Pulse p22／Qiita「Chunk sidecar 入門」 push CI push の後

02｜AI に開発の作法を守らせる エージェントを待たせない 作業を終えるたびに、Stop フックは上から順に判断する コミット前のフックは、常に「その場で検証」 Stop フック 前回成功時と 同じ状態？ はい キャッシュ 検証を飛ばす chunk validate: skipped (no changes since last successful run) バックグラウンド 次のターンで結果 500行未満・文書のみ validating in the background: 0192cf6e (small change, 42 lines) chunk validate passed in the background (0192cf6e) その場で検証 複数 sidecar で並列 $ chunk validate --remote --parallel 3 いいえ はい 小さな変更？ いいえ それ以外 出典: chunk-cli docs/HOOKS.md・docs/CLI.md（v0.7.199）／internal/cmd/validate.go

なぜ CI と同じ環境で回すのか 環境を揃えることで、 push前に問題を発見できる 出典: qiita.com/CircleCIJapan/items/8ba4ef8f1e3ec6bcf387

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

CI のガバナンス セキュリティは CIで 26

Config Policies パイプライン開始前に、組織のルールで判定する Rego（Open Policy Agent のポリシー言語）でルールを書き、組織の全プロジェクトに効かせる 違反なし 開始する パイプラインの トリガー config を取得 ポリシー判定 Rego・組織共通 hard_fail のルールに違反 開始しない soft_fail のルールに違反 開始し、違反を記録する Scale プラン、または CircleCI Server v4.2 以降で利用できる 出典: CircleCI Docs「Config policies overview」

サプライチェーン攻撃のアンドン CVE が出たら、まず止める 該当するイメージ名を hard_fail のルールに追加すると、そのイメージを使うプロジェクトでパイプラインが開始されなくな る。止まったプロジェクトから調べる。 該当イメージを使用 開始されない 止まったプロジェクト から調べる CVE 公開 該当イメージ名を 該当イメージを使用 hard_fail のルールに追加 開始されない 使用していない 通常どおり開始 出典: CircleCI ドキュメント（ docker イメージを判定するポリシーの例）

まとめ 測る、手元で止める、組織で止める 01 測る 02 手元で止める 03 組織で止める CI コストは「回数（MER）× 1回 の重さ」。まず自チームの値を測 る フックで「いつ」検証するかを強 制し、Chunk sidecar が「どこで ・どう回すか」を担う パイプライン開始前に、組織の ルールで判定する。CVE が出 たら、まず止める MER・変更1件あたりのクレジット Agent Hook・Chunk sidecar Config Policies（hard_fail / soft_fail）

まずは手元のリポジトリで chunk init

Thank you. X: @hidetaka_dev Qiita: https://qiita.com/CircleCIJapan EN: https://loop.circleci.com/