CI設定、作って終わり？OSS調査で判明した「CI負債」のリスク
公開日
多くの開発現場でCI/CDは当たり前のプラクティスとなりました。その一方で、プロジェクトの成長や技術トレンドの変化に伴い、利用するCIサービスの選定や移行は多くの開発チームにとって大きな課題となっています。どのサービスが現在の主流で、プロジェクトはどのようにサービスを乗り換えているのでしょうか。
本記事では、Trent大学の研究者らが発表した論文「From First Use to Final Commit: Studying the Evolution of Multi-CI Service Adoption」（2025年）に基づき、18,924ものJavaプロジェクトの歴史から明らかになった、CIサービス採用の変遷と実態を、データと共に詳しく解説していきます。
調査の概要：17年間にわたる18,924プロジェクトのCI利用動向を分析
この研究は、2008年から2024年にかけてGitHubでホストされているJavaプロジェクトのうち、8つの主要なCIサービス（Travis CI, AppVeyor, CircleCI, Azure Pipelines, GitHub Actions, Bitbucket, GitLab CI, Cirrus CI）のいずれかを利用した18,924件を対象とした、大規模な実証的調査です。プロジェクトがどのCIサービスを、いつ、どのように利用し、そして乗り換えていったのかを分析しています。
明らかになったCIサービス採用の4つの実態
1. CIサービスの主流はTravis CIからGitHub Actionsへ
調査によると、CIサービスの採用は2013年頃から急激に増加し、その初期の波を牽引したのはTravis CIでした。しかし、2016年頃からGitLab CIやGitHub Actionsといった新しいサービスが登場すると、Travis CIの採用は減少し始めます。特に、Travis CIが2020年に有料化へ移行したことをきっかけに、その流れは決定的となり、GitHub ActionsとGitLab CIが最も広く採用されるサービスへとシフトしていったことが、データから明確に読み取れます。
図表1: 新規Javaプロジェクトにおける各CIサービスの年間採用数（2008-2024年）
2. 約2割のプロジェクトが複数のCIサービスを併用・移行
驚くべきことに、調査対象となったプロジェクトの約18%が、そのライフサイクルの中で2つ以上のCIサービスを採用していました。中には、最大で6つものサービスを同時に利用していたプロジェクトも存在したといいます。これは、特定の機能要件を満たすため、あるいはクロスプラットフォーム対応のために複数のサービスを意図的に併用するケースや、新しいサービスへの移行期間中に一時的に併用するケースなど、CIサービスの利用が単一のサービスに留まらない実態を浮き彫りにしています。
3. 見過ごされる「CI負債」：CI設定のメンテナンスは驚くほど少ない
CI/CDパイプラインは一度設定すれば終わりではありません。しかし調査結果は、多くのプロジェクトでCI設定が放置されているという厳しい現実を示しました。CI設定ファイルに対するコミットは、プロジェクト全体の総コミット数に対して非常に低い割合しか占めていませんでした。 例えば、最もメンテナンス割合が高かったGitHub Actionsでさえ、その中央値はわずか3.9%に留まります。
図表2: CIサービスごとの総コミット数に占めるCI設定関連コミットの割合
このメンテナンス不足は、見過ごされがちな「CI負債」として静かに蓄積していきます。論文では、CI設定の約3分の1が時代遅れになっており、特にTravis CIでは非アクティブな設定が50%を超えていると指摘されています。 放置された設定は、具体的に以下のような深刻な問題を引き起こす時限爆弾となり得ます。
- 壊れたビルドの発生: プロジェクトの依存関係やワークフローは日々進化するため、古い設定はビルドの失敗に直結します。
- リソースの無駄遣い: 不要になった、あるいは冗長なビルドが走り続けることで、貴重なCIリソースと時間を浪費します。
- 開発者の混乱: 古い設定ファイルがリポジトリに残っていると、新規参画者がどれが有効な設定なのか分からず混乱を招きます。
- 非効率なインフラ: これら全ての結果として、開発インフラ全体の効率性が低下します。
CI設定は、アプリケーションコードと同様に、継続的な注意と改善が必要な「生きた資産」なのです。
4. CI移行の7割以上がTravis CIから。移行先はGitHub Actionsが最多
CIサービスを乗り換えたプロジェクトを分析したところ、その移行元の実に71.5%がTravis CIでした。そして、Travis CIから移行したプロジェクトの26%が、移行先としてGitHub Actionsを選択していました。これは、GitHubエコシステムとの緊密な統合、豊富な機能、そして活発なコミュニティを持つGitHub Actionsが、現在のCIサービス市場において非常に強力なポジションを築いていることを明確に示しています。論文では、Travis CIのフリーミアムプランの変更が、この大規模な移行を後押しした一因である可能性も指摘されています。
まとめ：CIサービス選定と運用における実践的な視点
今回の論文から、CI/CDの世界におけるいくつかの重要な動向が見えてきました。
第一に、CIサービスの選定は一度きりの静的なものではなく、プロジェクトの成長や技術トレンドの変化に応じて見直していく動的な活動であるということです。第二に、市場のトレンドとして、Travis CIからGitHub Actionsへの大きな潮流が存在することは間違いありません。これは、単なる人気だけでなく、GitHubエコシステムとの親和性や機能性が開発者に高く評価されている結果と言えるでしょう。
最後に、そして最も重要なこととして、CI設定のメンテナンス不足は、見過ごされがちな「CI負債」となり、将来的には冗長なビルドやリソースの浪費、開発者の混乱を招き、プロジェクトの健全性を損なうリスクをはらんでいます。 CIパイプラインは、アプリケーションコードと同様に、継続的な注意と改善が必要な資産なのです。
開発生産性やチームビルディングにお困りですか？ 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください！
参考資料: