壊れたコードはCI に送らない - CI と同じ環境の検証を push 前に回す方法
>100 Views
October 26, 26
スライド概要
【オンライン】CodeRabbit × CircleCIではじめる、AIコードのpush前検証
https://circleci.connpass.com/event/408597/
AI エージェントに書かせたコードを CI に投げて、落ちてから直す往復が、マージまでに何度も起きています。まず CircleCI が公開しているレポートのデータで、この往復がどこにどれだけ効いているかをご紹介します。そのうえで、CI と同じ環境での検証を push 前の手元で回すところをデモします。手元で潰せる範囲と、潰せない範囲の両方を明示します。
開発の質と速度を底上げしよう！ 世界中のエンジニアが愛用する CI/CD ツール「CircleCI」の公式アカウントから日本語で最新情報をお届けします。 最新イベント・ミートアップ情報はこちら: http://circleci.connpass.com
関連スライド
Meta XR SDK(V66-74)でQuestアプリを開発
あうぜん
1.2M
各ページのテキスト
壊れたコードは CI に送らない CI と同じ環境の検証を push 前に回す方法 CircleCI 合同会社 岡本 秀高｜Senior Field Engineer 1
自己紹介 Hidetaka Okamoto (岡本秀高 ) ● CircleCI Senior Field Engineer ● AWS Community Builder ( Serverless ) AWS Samurai 2017 ● 年間150本ペースで記事を書く人 ● 猫好きのヒカセン（10月末に幕張再訪予定） 2
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
State of Software Delivery Q3 レポートを 2026/10に追加公開 ● CIは改善傾向、 しかし以前としてボトルネック ● 開発者それぞれの持つ「仕掛品」が増加 着手したものの多くがリリースされていない ● 上位5% と中央値のスループット差は 10.4倍 リリースまで持っていけるかが分水嶺 ● 上位チームはサイクル内の CI実行回数を最適化 例: 手戻りの削減やトリガーの最適化 Q2 Pulse Report 表紙（差し替え） https://circleci.com/blog/five-takeaways-2026-q3-pulse/ 4
Q3 Pulse Report より コーディングエージェントが CI を回している 14x claude/ や codex/ など、 エージェント名が付いた ブランチの増加（ Q1→Q3） 出典: CircleCI「2026 State of Software Delivery: Q3 Pulse Report」 p.22 週末に CI を回す feature ブランチの 約 5 本に 1 本が、エージェントと bot。 平日の 2 倍の割合
Q3 Pulse Report より CI 自体は良くなった main ブランチの成功率 main ワークフロー 1 回あたりのジョブ数 100% 目標 90% 70.8% 76.7% 8 78.3% 0 7.14 6.16 6.32 Q1 Q2 0 Q1 Q2 Q3 出典: CircleCI「2026 State of Software Delivery: Q3 Pulse Report」 p.11, p.13 Q3
Q3 Pulse Report より それでも、出荷までの CI の往復は減っていない 変更 1 件あたりの CI 実行回数 中央値のチーム 3.8 上位 5% のチーム 上位 20 組織 2.6 1.6 1 1 1 計 4.8 回 計 3.6 回 MER ＝ feature の実行回数 ÷ main の実行回数 中央値の MER 3.9 → 3.8 計 2.6 回 CI が良くなっても、 ほぼ横ばい feature ブランチでの実行 main での最後の実行 出典: CircleCI「2026 State of Software Delivery: Q3 Pulse Report」 p.27。MER＝main での実行 1 回あたりの feature ブランチでの実行回数
なぜAIコーディングで CI コストが増えているのか？ 8
自チームの診断｜MER と1回あたりのクレジット CIコストは「回数」と「 1回の重さ」に分けて見る 回数（MER） × 1回の重さ 中央値 3.9 → 上位20組織 1.3 MER が横ばいでも この差で約 51%違う コストが上がるなら疑う ＝ 変更1件のクレジット まず自チームの値を測る AI / チームは、手戻りの少ない開発サイクルを実現できていますか？ 出典: 2026 State of Software Delivery Q2 Pulse p12・p16
Merge Efficiency Ratio (MER) MERが増えている = マージまでの CI実行数が多い MER ＝ feature ブランチの実行回数 ÷ main の実行回数 1つの変更が main に 載るまで、検証を 何回走らせているか そのうち、 一発で通っているのは どれくらいか 10
手元でテストを回さずに 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!' → コミットは成立しない
ローカル検証のハーネスにおける課題 01 誰がどうやって Hook を整備するのか？ 02 検証結果が環境依存じゃないとどう証明するか？ 03 テストが増えた時のチューニングなどはどうするか？
Chunk Sidecar ( Preview | Free) AIにもローカル検証を実⾏させるための、 エージェントハーネスツール群 ● 検証を強制する Agent Hook ● 検証⽅法などを伝える Agent Skill ● 検証環境としての Remote MicroVM ● それらを操作するための CLI 15
Chunk Sidecar ( Preview | Free) AIにもローカル検証を実⾏させるための、 エージェントハーネスツール群 仕組み ツール ● 検証を強制する Agent Hook ● 検証⽅法などを伝える Agent Skill ● 検証環境としての Remote MicroVM ● それらを操作するための CLI 検証環境 16
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 の力で実現 *社内検証結果に基づく数値 20
ソフトウェア開発のあるべき姿を、 AIと共に創り直す Change Inner loop 手元の開発 Outer loop チームでの検証 Debug Plan Validate Code Release Build Deploy Validate Feedback 21
まずは手元のリポジトリで chunk init