AIで書いても納期が縮まらない — CIの待ち時間を3区間で測る

「AIを使っているのに、なぜ納期が変わらないのか」。開発を頼む側からも、受ける側の社内からも出てくる疑問です。実装が速くなったのは事実なので、答えにくい質問でもあります。

答えの候補の一つは、詰まる場所が移ったことです。コードを書く工程が速くなった分、書いたものを検証する工程に変更が集まり、そこで順番を待つ時間が伸びる。プロジェクト管理ツールのLinearも2026年9月21日に、PRが検証を通るまでの待ち時間と実行コストを、CIの実行基盤からジョブの割り振り、テストの並列化までを1つの仕組みとして見直して下げた、という開発ブログを公開しています。

詰まる場所は、書く工程から検証へ移る

AIで書く速度が上がると、同じ時間に出てくる変更の数が増えます。生成されたコードを確かめるためにテストも増やすので、1回の検証にかかる時間も伸びます。一方で、検証を走らせる仕組みが以前のままなら、変更は検証の入口で順番を待つことになります。

この構図の中では、実装をさらに速くしても納期は縮みません。縮めるべきなのは、待ち時間か検証の実行時間のほうです。どちらが効くかは現場ごとに違い、比率も一律ではありません。だから、先に自分たちの内訳を測ります。

自分たちの待ち時間を測る

他社の数字を借りてくる前に、自分たちの内訳を見る必要があります。測るのは3つです。

図の3段は、そのまま打ち手の分岐です。上が長ければ検証は原因ではなく、中段が長ければ同時実行数の話、下段が長ければ個々のテストを削る話になります。1週間分の記録を取って、どの段がいちばん長いかを先に決めてください。

記録は手で付けなくても集められます。例えばGitHub Actionsでは、ジョブごとの開始と完了の時刻をREST APIから取り出せます。待ち時間は、変更を検証に出した時刻と検証が始まった時刻の差として拾います。

分けずに「CIが遅い」とだけ言うと、並列度を上げて費用だけが増える、という結果になりがちです。実行時間の短縮そのものについてはビルド時間を縮めるで扱っています。

費用は待ち時間と引き換えになっている

同時に走らせる本数を増やせば待ち時間は減りますが、その分だけ実行環境の費用が増えます。従量課金のサービスを使っている場合、この増加は月末に請求として現れます。

ここは保守契約の中で曖昧になりやすい部分です。開発の速度を上げるために並列度を上げた結果、運用費が上がった。その増分を誰が持つのかが決まっていないと、後から揉めやすくなります。継続的な支払いとして扱う範囲はCI/CDの従量課金を保守契約でどう見せるかに整理しました。

発注する側の視点では、逆の読み方ができます。「AIで速くなるなら安くなるはず」という期待に対し、速くなった分がどこに吸われているのかを聞けば、その相手が自分たちの工程を測っているかどうかが分かります。測っていない相手には、速くなった理由も遅い理由も説明しにくいはずです。

テストを増やすと、待ち時間が伸びる

見落としやすいのは、テストを増やす判断が待ち時間に直結することです。

生成されたコードに対して検証を厚くするのは妥当な方向です。ただし、厚くした分は毎回の変更すべてにかかります。1本あたり数秒のテストでも、数千本になれば実行時間として現れ、それが順番待ちを伸ばします。

現実的な折り合いは、全部を毎回走らせるのをやめることです。変更した範囲に関係するものを先に走らせ、時間のかかる全体検証は頻度を落とす。この切り分けができていないチームでは、テストを増やすほど開発が遅くなる、という逆転が起きます。

見積りで先に確認すること

開発を依頼する側も受ける側も、着手前に確認しておく項目があります。1回の変更が検証を抜けるまでに何分かかるか。その値を実際に記録しているか。そして、その値が3か月前と比べて伸びているか。

この3つに答えがあれば、納期の議論は具体的になります。答えがない場合は、まず1週間分の実測を取るところからです。速さの話をするには、どこが遅いかを先に確定させる必要があります。

2026年9月24日に、Linearの公式サイトに掲載された記事の要旨と、GitHub Docsの該当ページを検索結果で確認しました。Linearの記事本文は開けなかったため、同社が公表した具体的な数値は扱っていません。自社環境での測定・再現は実施していません。本記事は測定項目と判断材料の整理です。

開発工程の所要時間の可視化や、検証の組み直しの相談は、グリームハブへご相談ください。