TITLE

テストが増えるほどCIが遅くなる問題を、Datadog Test Impact Analysisはどう解くか

投稿日：2026.08.08

テストが増えるほどCIが遅くなる構造

タイミーの場合、この問題が厄介だったのは、並列実行やキャッシュ最適化といった高速化手法をひととおり適用した後でも、テストの増加ペースには追いつけなかった点にあります。

タイミーのケースは、この限界がどこにあるかを示す実例です。35並列・自動分割・キャッシュ最適化を導入済みの状態でも、CI時間は約10分で頭打ちになっていました。並列化の延長線上に、月2,000件ペースの増加を吸収し続けられる余地は残っていませんでした。

Datadog TIAは「テストを減らす」のではなく「実行するテストを選ぶ」

TIAの発想は、テストの本数そのものを減らすことではありません。PRごとに「どのテストを実行するか」を、コードの変更範囲から機械的に判定することです。

判定の根拠

Datadogの公式ドキュメントによると、TIAは有効化するとテストごとのコードカバレッジを収集してDatadogのバックエンドに送信します。バックエンドは、過去のコミットで「カバー対象・追跡対象のファイルが現在のコミットと同一の状態でテストがパスした記録」があるかどうかを見て、記録があればそのテストはコード変更の影響を受けていないとみなしてスキップします。言い換えると、過去に発行された「合格証」をそのまま使い回してよいかどうかを、対象ファイルの変更有無だけで判定しているということです。「スキップ不可(unskippable)」に指定したテストは、この判定から除外して常に実行することもできます。

二段階のテスト実行モデル

TIAだけで品質を担保しているわけではありません。タイミーは次の二段階でPRのフィードバック速度と品質保証を両立させています。「二段階ゲート」と呼べる構造です。

PRステージ: TIAで差分に関連するテストのみを実行し、高速なフィードバックを返す
マージキューステージ: 全テストを実行し、カバレッジも収集して品質を保証する

PRステージとマージキューステージの二段階ゲート図。PRステージはTIAが差分関連テストのみ実行(約1〜2分)、マージキューステージは全テスト実行とカバレッジ収集で品質を担保する。

Datadogの仕様上も、デフォルトブランチ(mainブランチ等)は自動的にTIAの対象外となり、本番反映前には常に全テストが実行される仕組みになっています。省略していい場所とはっきり分けて、ここだけは省略しない安全弁が最初から組み込まれているわけです。PRで絞ったテストも、マージ前のどこかで必ず全量チェックを受ける導線が用意されています。

実装上の工夫

タイミーの実装には、判定の仕組みをそのまま使うだけでは出てこない工夫がいくつか含まれています。具体的には、ddtest plan で実行前にテストを選定し、選定されたファイルだけを split-test で35ノードに均等分割する構成を取っています。分割の単位はファイル単位の「suiteモード」を採用しており、テスト単位で分割する「testモード」では約2分の分割コストが余計にかかるため、この選択をしています。またカバレッジ収集時は DD_TIA_FORCE_RUN_ALL=true を指定して全テストの実行を強制し、マージキューステージでの品質保証を成立させています。差分の評価はmerge-base(マージ元との共通の祖先コミット)を基準に行っており、複数コミットにまたがるPRでも変更を正しく認識できるようにしています。

導入判断のポイント

TIAのような差分ベースのテスト選別は、どのチームにも即座に有効というわけではありません。検討にあたって確認しておきたい点は次のとおりです。

テストスイートの規模と増加ペースを言語化できているか: タイミーのように、月あたり何件テストが増えているかを把握できていなければ、既存の高速化手法がいつ限界に達するかも見積もれません。
並列化・分割・キャッシュを一通り試した上での限界か: タイミーの事例は、これらの手法をすでに導入した後の話です。まだ手を付けていない最適化が残っているなら、そちらを先に検討する余地があります。
マージ前に全テストを流す場所(マージキュー等)を用意できる体制か: TIAによる高速化は、PRだけでなくマージ前の全量実行とセットで機能する設計です。この受け皿がなければ、スキップした分のリスクを引き受けたままになります。
依存関係の追跡設定を運用できるか: 追跡対象のファイル・ディレクトリの設定によって、どこまで正確に「変更の影響範囲」を捕捉できるかが変わります。設定漏れがあれば、本来実行すべきテストがスキップされる可能性が残ります。

まとめ

TIAを検討する前に確認しておきたいのは、直近1か月のCIログから、PRあたりの平均実行時間と、その期間に追加されたテスト数を並べてみることです。タイミーのように実行時間の伸びがテスト数の伸びとほぼ比例しているなら、並列化やキャッシュのチューニングだけでは同じ壁にぶつかる可能性があります。差分ベースでテストを選別するという発想は、テストを減らす話ではなく、どのテストを・いつ・どの精度で実行するかという設計の話です。PRを絞り、マージ前で全量を担保する二段階ゲートを用意できるかどうかが、導入の可否を分けます。

出典

タイミー Product Team Blog「テストが増えすぎてもう限界だったので、PRで全テストを回すのをやめた話」https://tech.timee.co.jp/entry/2026/08/07/164910
Datadog 公式ドキュメント "How Test Impact Analysis Works" https://docs.datadoghq.com/tests/test_impact_analysis/how_it_works/

※ この記事は AI を使用しています。Leadeas が自社開発した AI エージェント基盤で下書きを作成し、人間のレビューを経て公開しています。AI ネイティブ開発会社として自社の技術をそのまま実演する目的で、この手法を用いています。(詳しくは AI 利用ポリシー)