詳解CircleCI: CIの無駄をSmarter Testingで解決 - 必要なテストだけを実行する方法

CIの無駄を Smarter Testingで解決 CircleCI 合同会社 岡本 秀高｜Senior Field Engineer 1

AI は コードを量産し テストを量産し コミットを量産した 2

AI は コードを量産し テストを量産し コミットを量産した 実装作業が高速化した一方で、 テストは遅く重たくなっている 3

テストの増加・複雑化は、 チームの貴重なリソースである「開発者の集中力」を奪う 最大 約50% CI/CD パイプライン時間のうち テストが占める割合

テストの増加・複雑化は、 チームの貴重なリソースである「開発者の集中力」を奪う 最大 約50% 平均 25分26秒 CI/CD パイプライン時間のうち テストが占める割合 次のステップに進むための 「開発者の待ち時間」 出典: CircleCI ブログ「Stop running tests that don't matter」（2026/8/26）／ Mark, Gonzalez, Harris「No Task Left Behind?」CHI 2005

テストの増加・複雑化は、 チームの貴重なリソースである「開発者の集中力」を奪う 最大 約50% 平均 25分26秒 CI/CD パイプライン時間のうち テストが占める割合 次のステップに進むための 「開発者の待ち時間」 AI でコミットが増えるほど、待ち時間と中断の総量も増える 出典: CircleCI ブログ「Stop running tests that don't matter」（2026/8/26）／ Mark, Gonzalez, Harris「No Task Left Behind?」CHI 2005

Smarter Testing コミット / push に関係のあるタスクだけを実行する 修正の範囲・粒度は コミットや PRによって異なる

Smarter Testing コミット / push に関係のあるタスクだけを実行する 修正の範囲・粒度は コミットや PRによって異なる 通常の CI ワークフローでは、 2行の変更でも 1000 行の変更でも 等しく全てのテストが実行される

Smarter Testing コミット / push に関係のあるタスクだけを実行する 修正の範囲・粒度は コミットや PRによって異なる 通常の CI ワークフローでは、 2行の変更でも 1000 行の変更でも 等しく全てのテストが実行される コミットのたびに、 必要なものだけを、できるだけ効率よく 実行する

Smarter Testing CircleCI Smarter Testing: 戦略的な検証による CI高速化 ✓ 関係のあるテストを選択 >_ フィードバックの高速化 開発者・ AI フレンドリー

Smarter Testing CircleCI Smarter Testing: 戦略的な検証による CI高速化 ✓ 関係のあるテストを選択 JUnit.xmlのデータなどを利用。 変更と関係のあるテストファイルだけ を特定して実行する。 変更と関係のないテストだけ スキップすることで高速化。 >_ フィードバックの高速化 開発者・ AI フレンドリー

Smarter Testing CircleCI Smarter Testing: 戦略的な検証による CI高速化 ✓ >_ 関係のあるテストを選択 フィードバックの高速化 JUnit.xmlのデータなどを利用。 変更と関係のあるテストファイルだけ を特定して実行する。 変更と関係のないテストだけ スキップすることで高速化。 選択的テストの実行や、 並列実行の最適化 / 自動リトライ フィードバックを得るまでの 待ち時間を減らして効率化 開発者・ AI フレンドリー

Smarter Testing CircleCI Smarter Testing: 戦略的な検証による CI高速化 ✓ >_ 関係のあるテストを選択 フィードバックの高速化 開発者・ AI フレンドリー JUnit.xmlのデータなどを利用。 変更と関係のあるテストファイルだけ を特定して実行する。 変更と関係のないテストだけ スキップすることで高速化。 選択的テストの実行や、 並列実行の最適化 / 自動リトライ CLIや Agent Skillによる セットアップ支援 フィードバックを得るまでの 待ち時間を減らして効率化 CLIでのローカル検証による 試しやすさを実現

Smarter Testing CircleCI Smarter Testing: 戦略的な検証による CI高速化 ✓ >_ 関係のあるテストを選択 フィードバックの高速化 開発者・ AI フレンドリー JUnit.xmlのデータなどを利用。 変更と関係のあるテストファイルだけ を特定して実行する。 変更と関係のないテストだけ スキップすることで高速化。 選択的テストの実行や、 並列実行の最適化 / 自動リトライ CLIや Agent Skillによる セットアップ支援 フィードバックを得るまでの 待ち時間を減らして効率化 CLIでのローカル検証による 試しやすさを実現 Smarter Testing とは、コミットのたびに、 必要なものだけを、できるだけ効率よく 実行すること

お客様の声 PR ジョブが 4 倍速くなった 4倍 “ Smarter Testing の導入をきっかけに、後回しにしていた テストスイートの見直しと最適化に取り組み ました。その 投資はすぐに回収できています 。導入以来、PR ジョブ は 4 倍高速になりました。 PR ジョブの速度向上 導入を機にテストスイートも最適化 — Willam Weckl Liti, Full Stack Software Engineer

Why Smarter Testing CI による検証には、 2 つの意味がある PR を作成 CI で マージ可能か 検証 レビュー CI Green Merge 開発ブランチへのマージ 2 つのマージで、検証のスコープが違う CI で デプロイ可能か 最終確認 本番ブランチへのマージ

Smarter Testing とは 変更に影響しないと分かったテストは、実行しない 有料機能（評価した test atom 数で課金） Intelligent Test Selection Dynamic Test Splitting Auto-Rerun Failed Tests Test Analytics Dashboard カバレッジをもとに 決定的に選ぶ 並列の配分を 実行中に決め、 待ちを減らす 失敗したテストだけを、 その場で再実行 スキップ率や Flaky の傾向を可視化 Coming Soon 無料 テスト実行 静的なテスト分割 失敗したテストだけの再実行

Smarter Testing とは 変更に影響しないと分かったテストは、実行しない 有料機能（評価した test atom 数で課金） Intelligent Test Selection Dynamic Test Splitting Auto-Rerun Failed Tests Test Analytics Dashboard カバレッジをもとに 決定的に選ぶ 並列の配分を 実行中に決め、 待ちを減らす 失敗したテストだけを、 その場で再実行 スキップ率や Flaky の傾向を可視化 Coming Soon 無料 テスト実行 静的なテスト分割 失敗したテストだけの再実行

01 判定ロジック｜例 変えたファイルに関係するテストだけが選ばれる $ circleci testsuite list-tests "rspec tests" --local spec/price_loop_spec.rb spec/price_spec.rb spec/price_shared_spec.rb lib/price.rb を変更 実行 price_spec.rb 実行 price_loop_spec.rb 実行 price_shared_spec.rb スキップ discount_data_spec.rb 4 件中 3 件だけを実行。 Price を使わないテストは回らない

01 判定ロジック｜動作の流れ（前半） Discovery で母集団を作り、 Selection で絞る 1. Discovery test-suites.yml の discover コマンド で、対象となる test atom をすべて列 挙する test atom：指定して実行できる最小単位 （ファイル、クラス、パッケージなど） 2. Selection 対応表（impact data）と差分を突き合わせる 新しく追加された atom 実行 前回失敗した atom 実行 カバーするファイルが変更・削除された 実行 どれにも当たらない スキップ 全件実行： full-test-run-paths に当たる変更、デフォルトブランチ（既定）

01 判定ロジック｜動作の流れ（後半） Run で実行し、 Analysis で対応表を更新する 3. Run 4. Analysis 5. Reporting 過去の実行結果から初期バッチを作 り、各並列ノードはキューの残りを消 化 変更のあった atom・新しい atom の カバレッジを取り直す（実質テストの 再実行） テスト結果と impact data を回収す る 1 回の circleci testsuite run で、Discovery から Reporting まですべて流れる 既定の Analysis はデフォルトブランチだけ → 作業ブランチだけで試すと全件選択のまま 初回は全 atom の分析が走るため、とても遅い

02 最小構成と移行｜.circleci/test-suites.yml

専用の YAML ファイルに、テストの動かし方を定義する
--name: rspec tests
discover: find spec -type f -name '*_spec.rb'
run: >bundle exec rspec --format RspecJunitFormatter
--out "<< outputs.junit >>" << test.atoms >>
analysis: >CIRCLECI_COVERAGE="<< outputs.circleci-coverage >>"
bundle exec rspec << test.atoms >>
outputs:
junit: test-reports/junit.xml
options:
test-impact-analysis: true

discover

run

analysis

options

テストを探す

指定したテストを実行

カバレッジを取る

機能を有効化

出典: CircleCI Japan の RSpec 検証記事（Qiita）、Testsuite configuration reference

02 最小構成と移行｜.circleci/test-suites.yml

discover：テスト対象のファイルを列挙するコマンド
--name: rspec tests
discover: find spec -type f -name '*_spec.rb'
run: >bundle exec rspec --format RspecJunitFormatter
--out "<< outputs.junit >>" << test.atoms >>
analysis: >CIRCLECI_COVERAGE="<< outputs.circleci-coverage >>"
bundle exec rspec << test.atoms >>
outputs:
junit: test-reports/junit.xml
options:
test-impact-analysis: true

出力の 1 行が 1 つの test atom
ファイル、クラス、パッケージなど、指
定して実行できる単位

テストは実行しない
列挙だけを行うコマンドにする

出典: CircleCI Japan の RSpec 検証記事（Qiita）、Testsuite configuration reference

02 最小構成と移行｜.circleci/test-suites.yml

run：ファイルを指定してテストを実行するコマンド
--name: rspec tests
discover: find spec -type f -name '*_spec.rb'
run: >bundle exec rspec --format RspecJunitFormatter
--out "<< outputs.junit >>" << test.atoms >>
analysis: >CIRCLECI_COVERAGE="<< outputs.circleci-coverage >>"
bundle exec rspec << test.atoms >>
outputs:
junit: test-reports/junit.xml
options:
test-impact-analysis: true

<< test.atoms >>
選ばれたテストがスペース区切りで入
る

<< outputs.junit >>
テスト結果（JUnit XML）の書き出し先

出典: CircleCI Japan の RSpec 検証記事（Qiita）、Testsuite configuration reference

02 最小構成と移行｜.circleci/test-suites.yml

analysis と options：カバレッジの取得と機能の有効化
--name: rspec tests
discover: find spec -type f -name '*_spec.rb'
run: >bundle exec rspec --format RspecJunitFormatter
--out "<< outputs.junit >>" << test.atoms >>
analysis: >CIRCLECI_COVERAGE="<< outputs.circleci-coverage >>"
bundle exec rspec << test.atoms >>
outputs:
junit: test-reports/junit.xml
options:
test-impact-analysis: true

出典: CircleCI Japan の RSpec 検証記事（Qiita）、Testsuite configuration reference

analysis
カバレッジ付きでテストを動かし、対応
表を作る

test-impact-analysis: true
変更に関係するテストの選択が有効
になる

お客様の声 フィードバックまでの時間を 70〜75% 短縮 “ フィーチャーブランチのテスト時間 導入前 12〜15分 導入後 3〜5分 薄色部分は範囲の上限まで フィーチャーブランチのテストは12〜15 分から 3〜5 分になり、 70〜75% 改善しました。以前は待ち時間にほかの作業へ切り 替えていた開発者が、いまは集中したまま、すぐに問題を直し ています。テストの信頼性はそのまま に、フィードバックループ を大きく短縮できました。CI/CD パイプラインに加えた改善のな かでも、効果が最も大きく、手間が最も少なかった ものの一つで す。 — Ankit Raj Clazar, Member of Technical Staff

Smarter Testing とは 変更に影響しないと分かったテストは、実行しない 有料機能（評価した test atom 数で課金） Intelligent Test Selection Dynamic Test Splitting Auto-Rerun Failed Tests Test Analytics Dashboard カバレッジをもとに 決定的に選ぶ 並列の配分を 実行中に決め、 待ちを減らす 失敗したテストだけを、 その場で再実行 スキップ率や Flaky の傾向を可視化 Coming Soon 無料 テスト実行 静的なテスト分割 出典: CircleCI ブログ「Stop running tests that don't matter」、Smarter Testing ドキュメント 失敗したテストだけの再実行

04 動的分割と自動再実行｜ Dynamic Test Splitting 配分を事前に決めず、共有キューから取り合う 事前に決める（静的） Node 1 Node 2 Node 3 Node 4 最も遅いノードで終了

04 動的分割と自動再実行｜ Dynamic Test Splitting 配分を事前に決めず、共有キューから取り合う 事前に決める（静的） 実行中に決める（動的） Node 1 Node 1 Node 2 Node 2 Node 3 Node 3 Node 4 Node 4 最も遅いノードで終了 初期バッチを消化したノードから、キューに残ったテストを取りにいく 図は概念図（バーの長さは例示）。出典: Use Dynamic Test Splitting（circleci.com/docs） 終了時刻がそろう

04 動的分割と自動再実行｜ Dynamic Test Splitting ノードごとに消化した件数は、そろわなくていい Node 1 Node 2 1 atom 13 atoms options: dynamic-test-splitting: true Node 3 17 atoms Node 4 17 atoms 件数をそろえるのではなく、空いたノードがキューの残りを消化する

Smarter Testing とは 変更に影響しないと分かったテストは、実行しない 有料機能（評価した test atom 数で課金） Intelligent Test Selection Dynamic Test Splitting Auto-Rerun Failed Tests Test Analytics Dashboard カバレッジをもとに 決定的に選ぶ 並列の配分を 実行中に決め、 待ちを減らす 失敗したテストだけを、 その場で再実行 スキップ率や Flaky の傾向を可視化 Coming Soon 無料 テスト実行 静的なテスト分割 出典: CircleCI ブログ「Stop running tests that don't matter」、Smarter Testing ドキュメント 失敗したテストだけの再実行

04 動的分割と自動再実行｜ Auto-Rerun Failed Tests 失敗したテストだけを、その場でやり直す 従来 テストジョブ全体をやり直す 成功したテストも、もう一度走る Smarter Testing ✕ 1 回目 ✕ 2 回目 ✕ 3 回目 ✓ 4 回目 SerialNumber User list（3 reruns） options: max-auto-rerun: 3 初回 + 最大 3 回まで再実行。Flaky による全体のやり直し を減らす

Smarter Testing とは 変更に影響しないと分かったテストは、実行しない 有料機能（評価した test atom 数で課金） Intelligent Test Selection Dynamic Test Splitting Auto-Rerun Failed Tests Test Analytics Dashboard カバレッジをもとに 決定的に選ぶ 並列の配分を 実行中に決め、 待ちを減らす 失敗したテストだけを、 その場で再実行 スキップ率や Flaky の傾向を可視化 Coming Soon 無料 テスト実行 静的なテスト分割 出典: CircleCI ブログ「Stop running tests that don't matter」、Smarter Testing ドキュメント 失敗したテストだけの再実行

Test Analytics Dashboard テスト実行結果のレポートダッシュボード テストの成功率などのトレンドレポート テストごとの成功率やパフォーマンス

お客様の声 1 プロジェクトでクレジットを 57% 削減 Test Impact Analysis 57% $2,803 変更の影響を受けるテストだけを実行 Dynamic Test Splitting クレジット削減 クレジット消費の削減額 実行コスト $131.76 “ 並列ランナー間でテストを均等に配分 Auto-Rerun Failed Tests 全体を再実行せずに不安定なテストを再試行 数字に表れない効果 不安定なテストを再実行するたびに、エンジニアは手を止めて待つことになりま す。定量化は難しくても、払う価値は十分にあります。 — Staff Software Engineer ※ 数値は 1 プロジェクトのクレジット削減分のみ（導入前後 30 日間の比較）。

03 導入前後の比較 選ばれるテストが減ると、待ち時間はここまで縮む 約10分 → 約10秒 12–15分 → 3–5分 CircleCI 社内のテストスイート Clazar 社のフィーチャーブランチのテスト

02 最小構成と移行｜既存の config.yml から 移行は、作業ブランチで 6 ステップ JUnit とカバレッジ（LCOV 等）を出せるか確認 1 出せなければ、まずここに取り組む push して、パイプラインの完全成功を待つ 4 test-suites.yml を作り、3機能をまとめて有効化 2 テスト選択・動的分割・自動再実行を全部入りにする 空コミットを push して、全件スキップを確認 5 テスト実行を circleci testsuite run に置き換え 3 お試し中は --run-tests と --analyze-tests を impacted で明示 途中で次を回すと、後続が全件を分析し直す 6 git commit --allow-empty で影響ゼロの変更を作る full-test-run-paths などを調整し、 フラグを外してマージ お試し用の 2 フラグは残さない

05 効果が出ないケース 導入前に潰しておく、 4 つの落とし穴 ! カバレッジが取れない・薄い 対応表はカバレッジから作る。取れないと正しく選べない ! フィーチャーブランチだけで試す 既定では分析が走らず、ずっと全件選択のまま ! テストが別プロセスを呼ぶ 別コンテナやサービスのコードはカバレッジを集めにくい ! 初回分析の途中で次を回す 初回は全件分析で遅い。完了前に回すと再分析になる

まとめ 影響しないと分かったテストは、走らせない 01 判定ロジック カバレッジから作った対応表と差分で、実行するatom を決める 02 最小構成と移行 test-suites.yml に discover / run / analysis を書き、testsuite run に置き換える 03 導入前後の比較 選ばれる atom が減るほど、待ち時間が縮む 04 動的分割と自動再実行 並列の偏りと、Flaky による全体のやり直しを減らす 05 効果が出ないケース カバレッジ・ブランチの既定・初回分析を先に確認する ドキュメント: circleci.com/docs/guides/test/smarter-testing

Thank you. 詳解CircleCI #02｜2026年10月16日