AI codingでCIがボトルネック化したら何を確認すべき？Linear事例に学ぶ2026年版チェックリスト
AIエージェントやコード生成ツールを導入すると、実装量は増えます。一方で、Pull Requestごとの検証、テスト、レビュー待ちが従来のままだと、開発者もエージェントもCIの完了を待つ時間が増えます。Linearはこの問題に対し、PRの待ち時間とrunner timeの両方を指標に置き、テスト数が年初から約4倍になってもPR待ち時間を6分超から5分強へ下げ、テストあたりのrunner timeをおよそ半減させたと公開しています。
この記事では、Linearの公開事例をもとに、AI coding導入企業が最初に確認すべきCI改善ポイントを「計測」「クリティカルパス」「セットアップ」「テスト分割」「運用ルール」の順に整理します。
概要：AI coding時代のCIは「速さ」だけでなく待ち時間で見る
CI改善でよくある失敗は、個別ジョブの秒数だけを見てしまうことです。AI codingではPR数、修正回数、テスト追加量が増えるため、重要なのは「PRがCI完了まで何分待つか」「どのジョブが後続を止めているか」「runner timeがどこで消えているか」です。Linearも、単純な高速化ではなく、PR待ち時間とrunner消費を同時に見ています。
最初のダッシュボードは、平均ではなくp50、p90、最遅ジョブ、月間runner-minutesで作るのが現実的です。AIエージェントが生成したPRは小さく見えても、テストの追加や依存更新が連続し、CIキューの山を作りやすいためです。
仕様表：Linear事例から見る改善レバー
改善領域 | 公開された効果 | 自社で確認する指標
runner基盤の変更 | 同条件比較でジョブ平均34%高速化、tscは52%短縮 | CPU、ストレージ、キャッシュ、GitHub接続の安定性
TypeScriptツール更新 | native TypeScript compilerへの移行でtsc中央値73%短縮 | 型チェック時間、lintとの重複、ボトルネック移動
lintの型依存削減 | API lint 68%短縮、全体lint 55%短縮 | 型情報が必要なlint rule、ASTだけで代替できるrule
change detection短縮 | 中央値26秒から8秒、p90は31秒から12秒 | checkout範囲、fetch depth、blobless/sparse checkout
短いチェックの統合 | 月間約87,000 runner-minutes削減 | 数秒の処理のためにrunnerを起動していないか
設定方法：まず90分でCIの待ち時間を棚卸しする
1. 直近30日のCI実行履歴を、workflow、job、duration、queued time、runner typeで出します。成功したPRだけでなく、失敗後に再実行されたジョブも含めます。
2. PRがmerge可能になるまでに必ず通るジョブを並べ、クリティカルパスを作ります。小さなchange-detectionやcache markerでも、後続のtest shardを止めているなら優先度は高くなります。
3. checkout、依存install、DB migration、container bootなど、各ジョブで繰り返している固定費を分解します。AI codingではテスト本体よりも固定費が増幅しやすいため、ここを見ないとshard数だけ増やしてコストが悪化します。
4. テストファイル単位の偏りを確認します。Linearは大きすぎるテストファイルを分割し、8 shard構成に移すことで、最遅shardを5.25分から4.33分へ下げたと説明しています。
CI改善の棚卸しやAI開発体制の見直しを社内で進めたい場合は、HelloCraftAIのAI研修・開発支援にご相談ください。
チェックリスト：AIエージェントが増える前に直す5項目
- checkout不要のjobでworking treeを取得していないか。必要なのが差分判定だけならfetch depth、sparse checkout、blobless checkoutを検討する。
- lintが型グラフ構築を毎回要求していないか。型情報なしのAST ruleに分けられるものは分離する。
- 短い検査を個別jobにしすぎていないか。runner起動、checkout、依存installの固定費が処理時間を上回るなら統合する。
- DB migrationやseedを毎回最初から流していないか。入力が変わらない場合はschema snapshotやbootstrap済みイメージを使う。
- AIエージェントが生成するテストに、shardしやすい粒度、共有state禁止、fake timerの扱いなどのルールを渡しているか。
料金シミュレーション：runner-minutes削減を稟議に変換する
CI改善は「速くなった」で終わらせず、runner-minutesと待ち時間の両方で稟議化します。たとえば月間740,000 runner-minutesを使う組織で、短いチェックの統合により11.8%削減できるなら、月間約87,000 runner-minutesの削減です。ここにrunner単価、人件費、PR待ち時間を掛け合わせると、AI codingの開発速度を支える基盤投資として説明できます。
ただし、shard数を増やす判断は慎重に行います。Linearの事例でも、setupが110〜140秒のままなら8 shardは固定費が大きすぎました。setupを約40秒まで下げた後だからこそ、8 shard化が現実的になっています。
FAQ
Q. GitHub Actionsから必ず移行すべきですか？
A. いいえ。Linearは第三者runnerへの移行で平均34%高速化したと公開していますが、自社のボトルネックがcheckout、依存install、test shardの偏りなら、runner移行より先にworkflow設計を直す方が効果的な場合があります。
Q. AIエージェント導入前でもCI改善は必要ですか？
A. 必要です。AI coding導入後はPR数とテスト追加が増えやすく、既存の小さな非効率が一気に待ち時間として表面化します。導入前にp90待ち時間と月間runner-minutesを基準値として保存しておくと、効果測定がしやすくなります。
Q. テストのisolateを外すのは安全ですか？
A. 無条件では危険です。Linearもopt-inコメント、共有stateのteardown、fake timerなどの除外を明示しています。速度改善より正しさを優先し、対象ファイルを明示的に管理するのが前提です。
まとめ：AI codingの成功条件はCIの運用設計まで含めること
AI codingは実装速度を上げますが、検証のパイプラインが追いつかなければ、開発全体の律速はCIに移ります。まずはPR待ち時間、クリティカルパス、固定setup、短いjobの統合、test shardの偏りを見える化してください。Linearの事例は、巨大な刷新ではなく、34%、73%、68%、87,000 runner-minutesといった複数の改善を積み上げることで、AI時代の開発速度を支えるCIへ近づけることを示しています。
