---
title: AI時代の品質管理 - CIコストを抑える検証フローの作り方
tags: 
author: [Hidetaka Okamoto](https://www.docswell.com/user/hideokamoto)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/3EK989L5ED.jpg?width=480
description: CircleCI × Postman 共催ウェビナー｜2026年10月6日
published: October 06, 26
canonical: https://www.docswell.com/s/hideokamoto/KR8749-2026-10-06-140158
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/3EK989L5ED.jpg)

CircleCI × Postman 共催ウェビナー｜ 2026年10月6日
AI時代の品質管理
CIコストを抑える検証フローの作り方
岡本 秀高 ( @hidetaka_dev )
CircleCI 合同会社 Senior Field Engineer
1


# Page. 2

![Page Image](https://bcdn.docswell.com/page/L73W2W3175.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/87DKZK4KJG.jpg)

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%


# Page. 4

![Page Image](https://bcdn.docswell.com/page/VJPKDKM3E8.jpg)

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日、前年同期間比）


# Page. 5

![Page Image](https://bcdn.docswell.com/page/2EVV1V9NEQ.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/57GL2LZ5EL.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に追加公開
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/4EQYPYLLJP.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/KJ4WYWD571.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/LE1Y6YZ27G.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/GEWGWG92J2.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/47ZL5L94J3.jpg)

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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/YJ6W9WKGJV.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/GJ5MNMPXJ4.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/LE3W2W34E5.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/8EDKZK457G.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/V7PKDKMDJ8.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/2JVV1V9GJQ.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/5EGL2L4DJL.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/4JQYPYGX7P.jpg)

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


# Page. 20

![Page Image](https://bcdn.docswell.com/page/K74WYW52E1.jpg)

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


# Page. 21

![Page Image](https://bcdn.docswell.com/page/LJ1Y6YWKEG.jpg)

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


# Page. 22

![Page Image](https://bcdn.docswell.com/page/GJWGWG6P72.jpg)

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 の後


# Page. 23

![Page Image](https://bcdn.docswell.com/page/4EZL5LY673.jpg)

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


# Page. 24

![Page Image](https://bcdn.docswell.com/page/Y76W9WDL7V.jpg)

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


# Page. 25

![Page Image](https://bcdn.docswell.com/page/G75MNM3M74.jpg)

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


# Page. 26

![Page Image](https://bcdn.docswell.com/page/9J2959ZRER.jpg)

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


# Page. 27

![Page Image](https://bcdn.docswell.com/page/DEY4K4R5JM.jpg)

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


# Page. 28

![Page Image](https://bcdn.docswell.com/page/VJNYRYD478.jpg)

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


# Page. 29

![Page Image](https://bcdn.docswell.com/page/YE9PMPG4J3.jpg)

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


# Page. 30

![Page Image](https://bcdn.docswell.com/page/GE8DLDVVED.jpg)

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


# Page. 31

![Page Image](https://bcdn.docswell.com/page/LELMLM5R7R.jpg)

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