--- title: 詳解CircleCI: CIの無駄をSmarter Testingで解決 - 必要なテストだけを実行する方法 tags: #circleci #cicd author: [CircleCI Japan](https://image.docswell.com/user/circleci-japan) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/DJYDXGVNJM.jpg?width=480 description: テストの待ち時間は「テストが終わるまでの時間」では終わりません。作業を中断された開発者が元の集中に戻るまでには平均で20分以上かかるという研究があり、30分のテスト実行は作業セッションひとつ分のコストになります。AI によるコード生成でコミット数が増えた分、検証側にかかる圧力も増えています。 CircleCI の Smarter Testing は、この圧力に対して「変更に影響しないと証明できたテストを実行しない」という方向から手を入れる機能群です。影響範囲はカバレッジデータをもとに判定します。 published: October 16, 26 canonical: https://image.docswell.com/s/circleci-japan/KE1D47-2026-10-16-173013 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/DJYDXGVNJM.jpg) CIの無駄を Smarter Testingで解決 CircleCI 合同会社 岡本 秀高｜Senior Field Engineer 1 # Page. 2 ![Page Image](https://bcdn.docswell.com/page/V7N61GMV78.jpg) AI は コードを量産し テストを量産し コミットを量産した 2 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/YJ9L5WNVE3.jpg) AI は コードを量産し テストを量産し コミットを量産した 実装作業が高速化した一方で、 テストは遅く重たくなっている 3 # Page. 4 ![Page Image](https://bcdn.docswell.com/page/GJ8XYNK47D.jpg) テストの増加・複雑化は、 チームの貴重なリソースである「開発者の集中力」を奪う 最大 約50% CI/CD パイプライン時間のうち テストが占める割合 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/LJL84PZVER.jpg) テストの増加・複雑化は、 チームの貴重なリソースである「開発者の集中力」を奪う 最大 約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 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/47M6K4VNJW.jpg) テストの増加・複雑化は、 チームの貴重なリソースである「開発者の集中力」を奪う 最大 約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 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/P7RPXW24J9.jpg) Smarter Testing コミット / push に関係のあるタスクだけを実行する 修正の範囲・粒度は コミットや PRによって異なる # Page. 8 ![Page Image](https://bcdn.docswell.com/page/PJX36PDZ7X.jpg) Smarter Testing コミット / push に関係のあるタスクだけを実行する 修正の範囲・粒度は コミットや PRによって異なる 通常の CI ワークフローでは、 2行の変更でも 1000 行の変更でも 等しく全てのテストが実行される # Page. 9 ![Page Image](https://bcdn.docswell.com/page/3JKY1DXV7D.jpg) Smarter Testing コミット / push に関係のあるタスクだけを実行する 修正の範囲・粒度は コミットや PRによって異なる 通常の CI ワークフローでは、 2行の変更でも 1000 行の変更でも 等しく全てのテストが実行される コミットのたびに、 必要なものだけを、できるだけ効率よく 実行する # Page. 10 ![Page Image](https://bcdn.docswell.com/page/LE39QRRQE5.jpg) Smarter Testing CircleCI Smarter Testing: 戦略的な検証による CI高速化 ✓ 関係のあるテストを選択 >_ フィードバックの高速化 開発者・ AI フレンドリー # Page. 11 ![Page Image](https://bcdn.docswell.com/page/8EDG9YYWEG.jpg) Smarter Testing CircleCI Smarter Testing: 戦略的な検証による CI高速化 ✓ 関係のあるテストを選択 JUnit.xmlのデータなどを利用。 変更と関係のあるテストファイルだけ を特定して実行する。 変更と関係のないテストだけ スキップすることで高速化。 >_ フィードバックの高速化 開発者・ AI フレンドリー # Page. 12 ![Page Image](https://bcdn.docswell.com/page/V7P3Z66XJ8.jpg) Smarter Testing CircleCI Smarter Testing: 戦略的な検証による CI高速化 ✓ >_ 関係のあるテストを選択 フィードバックの高速化 JUnit.xmlのデータなどを利用。 変更と関係のあるテストファイルだけ を特定して実行する。 変更と関係のないテストだけ スキップすることで高速化。 選択的テストの実行や、 並列実行の最適化 / 自動リトライ フィードバックを得るまでの 待ち時間を減らして効率化 開発者・ AI フレンドリー # Page. 13 ![Page Image](https://bcdn.docswell.com/page/2JV4W3337Q.jpg) Smarter Testing CircleCI Smarter Testing: 戦略的な検証による CI高速化 ✓ >_ 関係のあるテストを選択 フィードバックの高速化 開発者・ AI フレンドリー JUnit.xmlのデータなどを利用。 変更と関係のあるテストファイルだけ を特定して実行する。 変更と関係のないテストだけ スキップすることで高速化。 選択的テストの実行や、 並列実行の最適化 / 自動リトライ CLIや Agent Skillによる セットアップ支援 フィードバックを得るまでの 待ち時間を減らして効率化 CLIでのローカル検証による 試しやすさを実現 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/5EG1D33YJL.jpg) Smarter Testing CircleCI Smarter Testing: 戦略的な検証による CI高速化 ✓ >_ 関係のあるテストを選択 フィードバックの高速化 開発者・ AI フレンドリー JUnit.xmlのデータなどを利用。 変更と関係のあるテストファイルだけ を特定して実行する。 変更と関係のないテストだけ スキップすることで高速化。 選択的テストの実行や、 並列実行の最適化 / 自動リトライ CLIや Agent Skillによる セットアップ支援 フィードバックを得るまでの 待ち時間を減らして効率化 CLIでのローカル検証による 試しやすさを実現 Smarter Testing とは、コミットのたびに、 必要なものだけを、できるだけ効率よく 実行すること # Page. 15 ![Page Image](https://bcdn.docswell.com/page/4JQD15567P.jpg) お客様の声 PR ジョブが 4 倍速くなった 4倍 “ Smarter Testing の導入をきっかけに、後回しにしていた テストスイートの見直しと最適化に取り組み ました。その 投資はすぐに回収できています 。導入以来、PR ジョブ は 4 倍高速になりました。 PR ジョブの速度向上 導入を機にテストスイートも最適化 — Willam Weckl Liti, Full Stack Software Engineer # Page. 16 ![Page Image](https://bcdn.docswell.com/page/K74ZR99ME1.jpg) Why Smarter Testing CI による検証には、 2 つの意味がある PR を作成 CI で マージ可能か 検証 レビュー CI Green Merge 開発ブランチへのマージ 2 つのマージで、検証のスコープが違う CI で デプロイ可能か 最終確認 本番ブランチへのマージ # Page. 17 ![Page Image](https://bcdn.docswell.com/page/LJ1RQKKYJG.jpg) # Page. 18 ![Page Image](https://bcdn.docswell.com/page/GJW1MDD1E2.jpg) # Page. 19 ![Page Image](https://bcdn.docswell.com/page/4EZPQGGXJ3.jpg) Smarter Testing とは 変更に影響しないと分かったテストは、実行しない 有料機能（評価した test atom 数で課金） Intelligent Test Selection Dynamic Test Splitting Auto-Rerun Failed Tests Test Analytics Dashboard カバレッジをもとに 決定的に選ぶ 並列の配分を 実行中に決め、 待ちを減らす 失敗したテストだけを、 その場で再実行 スキップ率や Flaky の傾向を可視化 Coming Soon 無料 テスト実行 静的なテスト分割 失敗したテストだけの再実行 # Page. 20 ![Page Image](https://bcdn.docswell.com/page/Y76M6YYPEV.jpg) Smarter Testing とは 変更に影響しないと分かったテストは、実行しない 有料機能（評価した test atom 数で課金） Intelligent Test Selection Dynamic Test Splitting Auto-Rerun Failed Tests Test Analytics Dashboard カバレッジをもとに 決定的に選ぶ 並列の配分を 実行中に決め、 待ちを減らす 失敗したテストだけを、 その場で再実行 スキップ率や Flaky の傾向を可視化 Coming Soon 無料 テスト実行 静的なテスト分割 失敗したテストだけの再実行 # Page. 21 ![Page Image](https://bcdn.docswell.com/page/G75Z6GGPJ4.jpg) 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 を使わないテストは回らない # Page. 22 ![Page Image](https://bcdn.docswell.com/page/9J2RMYYZ7R.jpg) 01 判定ロジック｜動作の流れ（前半） Discovery で母集団を作り、 Selection で絞る 1. Discovery test-suites.yml の discover コマンド で、対象となる test atom をすべて列 挙する test atom：指定して実行できる最小単位 （ファイル、クラス、パッケージなど） 2. Selection 対応表（impact data）と差分を突き合わせる 新しく追加された atom 実行 前回失敗した atom 実行 カバーするファイルが変更・削除された 実行 どれにも当たらない スキップ 全件実行： full-test-run-paths に当たる変更、デフォルトブランチ（既定） # Page. 23 ![Page Image](https://bcdn.docswell.com/page/DEYDXGGNEM.jpg) 01 判定ロジック｜動作の流れ（後半） Run で実行し、 Analysis で対応表を更新する 3. Run 4. Analysis 5. Reporting 過去の実行結果から初期バッチを作 り、各並列ノードはキューの残りを消 化 変更のあった atom・新しい atom の カバレッジを取り直す（実質テストの 再実行） テスト結果と impact data を回収す る 1 回の circleci testsuite run で、Discovery から Reporting まですべて流れる 既定の Analysis はデフォルトブランチだけ → 作業ブランチだけで試すと全件選択のまま 初回は全 atom の分析が走るため、とても遅い # Page. 24 ![Page Image](https://bcdn.docswell.com/page/VJN61GGVJ8.jpg) 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 # Page. 25 ![Page Image](https://bcdn.docswell.com/page/YE9L5WWV73.jpg) 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 # Page. 26 ![Page Image](https://bcdn.docswell.com/page/GE8XYNN4JD.jpg) 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 # Page. 27 ![Page Image](https://bcdn.docswell.com/page/LEL84PPV7R.jpg) 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 変更に関係するテストの選択が有効 になる # Page. 28 ![Page Image](https://bcdn.docswell.com/page/4JM6K44NEW.jpg) # Page. 29 ![Page Image](https://bcdn.docswell.com/page/PJRPXWW4E9.jpg) お客様の声 フィードバックまでの時間を 70〜75% 短縮 “ フィーチャーブランチのテスト時間 導入前 12〜15分 導入後 3〜5分 薄色部分は範囲の上限まで フィーチャーブランチのテストは12〜15 分から 3〜5 分になり、 70〜75% 改善しました。以前は待ち時間にほかの作業へ切り 替えていた開発者が、いまは集中したまま、すぐに問題を直し ています。テストの信頼性はそのまま に、フィードバックループ を大きく短縮できました。CI/CD パイプラインに加えた改善のな かでも、効果が最も大きく、手間が最も少なかった ものの一つで す。 — Ankit Raj Clazar, Member of Technical Staff # Page. 30 ![Page Image](https://bcdn.docswell.com/page/PEX36PPZJX.jpg) 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 ドキュメント 失敗したテストだけの再実行 # Page. 31 ![Page Image](https://bcdn.docswell.com/page/3EKY1DDVJD.jpg) 04 動的分割と自動再実行｜ Dynamic Test Splitting 配分を事前に決めず、共有キューから取り合う 事前に決める（静的） Node 1 Node 2 Node 3 Node 4 最も遅いノードで終了 # Page. 32 ![Page Image](https://bcdn.docswell.com/page/L739QRPQ75.jpg) 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） 終了時刻がそろう # Page. 33 ![Page Image](https://bcdn.docswell.com/page/87DG9YLW7G.jpg) 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 件数をそろえるのではなく、空いたノードがキューの残りを消化する # Page. 34 ![Page Image](https://bcdn.docswell.com/page/VJP3Z62XE8.jpg) 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 ドキュメント 失敗したテストだけの再実行 # Page. 35 ![Page Image](https://bcdn.docswell.com/page/2EV4W3D3JQ.jpg) 04 動的分割と自動再実行｜ Auto-Rerun Failed Tests 失敗したテストだけを、その場でやり直す 従来 テストジョブ全体をやり直す 成功したテストも、もう一度走る Smarter Testing ✕ 1 回目 ✕ 2 回目 ✕ 3 回目 ✓ 4 回目 SerialNumber User list（3 reruns） options: max-auto-rerun: 3 初回 + 最大 3 回まで再実行。Flaky による全体のやり直し を減らす # Page. 36 ![Page Image](https://bcdn.docswell.com/page/57G1D3YYEL.jpg) 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 ドキュメント 失敗したテストだけの再実行 # Page. 37 ![Page Image](https://bcdn.docswell.com/page/4EQD15M6JP.jpg) Test Analytics Dashboard テスト実行結果のレポートダッシュボード テストの成功率などのトレンドレポート テストごとの成功率やパフォーマンス # Page. 38 ![Page Image](https://bcdn.docswell.com/page/KJ4ZR9VM71.jpg) お客様の声 1 プロジェクトでクレジットを 57% 削減 Test Impact Analysis 57% $2,803 変更の影響を受けるテストだけを実行 Dynamic Test Splitting クレジット削減 クレジット消費の削減額 実行コスト $131.76 “ 並列ランナー間でテストを均等に配分 Auto-Rerun Failed Tests 全体を再実行せずに不安定なテストを再試行 数字に表れない効果 不安定なテストを再実行するたびに、エンジニアは手を止めて待つことになりま す。定量化は難しくても、払う価値は十分にあります。 — Staff Software Engineer ※ 数値は 1 プロジェクトのクレジット削減分のみ（導入前後 30 日間の比較）。 # Page. 39 ![Page Image](https://bcdn.docswell.com/page/LE1RQK3YEG.jpg) 03 導入前後の比較 選ばれるテストが減ると、待ち時間はここまで縮む 約10分 → 約10秒 12–15分 → 3–5分 CircleCI 社内のテストスイート Clazar 社のフィーチャーブランチのテスト # Page. 40 ![Page Image](https://bcdn.docswell.com/page/GEW1MDP172.jpg) 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 フラグは残さない # Page. 41 ![Page Image](https://bcdn.docswell.com/page/47ZPQGKXE3.jpg) 05 効果が出ないケース 導入前に潰しておく、 4 つの落とし穴 ! カバレッジが取れない・薄い 対応表はカバレッジから作る。取れないと正しく選べない ! フィーチャーブランチだけで試す 既定では分析が走らず、ずっと全件選択のまま ! テストが別プロセスを呼ぶ 別コンテナやサービスのコードはカバレッジを集めにくい ! 初回分析の途中で次を回す 初回は全件分析で遅い。完了前に回すと再分析になる # Page. 42 ![Page Image](https://bcdn.docswell.com/page/YJ6M6YQP7V.jpg) まとめ 影響しないと分かったテストは、走らせない 01 判定ロジック カバレッジから作った対応表と差分で、実行するatom を決める 02 最小構成と移行 test-suites.yml に discover / run / analysis を書き、testsuite run に置き換える 03 導入前後の比較 選ばれる atom が減るほど、待ち時間が縮む 04 動的分割と自動再実行 並列の偏りと、Flaky による全体のやり直しを減らす 05 効果が出ないケース カバレッジ・ブランチの既定・初回分析を先に確認する ドキュメント: circleci.com/docs/guides/test/smarter-testing # Page. 43 ![Page Image](https://bcdn.docswell.com/page/GJ5Z6GRPE4.jpg) Thank you. 詳解CircleCI #02｜2026年10月16日