うちではこういうのにubuntu-slimのrunnerを使いました

CIの実行時間、増えていませんか？

私のプロダクトでは増えています。
Coding Agentに実装を任せることが増え、PRの作成数も爆発的に増えていますし、確認の手間を減らすためにチェックをどんどん自動化する動きがあります。
自動化が進むこと自体は喜ばしいことですが、CIの実行時間が増え、お金もかかるようになってきています。
私は ドケチ 倹約家なので少しでも安く済ませたい、という気持ちが高まっていました。

この記事はそんな中で GitHub Actionsのubuntu-slim runner を使うようにして、ちょっとした節約をした、という記事です。

GitHub Actionsのubuntu-slim runnerとは

2025年10月28日に発表された実行コストを抑えたrunner。
コストを通常のubuntu runnerの3分の1に抑えることができます。

runner	1分あたりの料金	vCPU数	RAM	最大実行時間
ubuntu-slim	0.002ドル	1	5GB	15分
ubuntu-latest	0.006ドル	2	7GB	6時間
ubuntu-latest-4core	0.012ドル	4	16GB	6時間

安い代わりにスペックは低くなっていて、最大実行時間にも制限があります。
また

• コンテナで実行されているためrunner内でDockerを使うのが難しい
• プリインストールされているツールが少ない
  • ubuntu-slimの場合
  • ubuntu-latestの場合

といった制約もあります。

うちではこういうのに使いました

変更検出ジョブ

私が開発しているプロダクトのプレマージのCIではたびたび以下のような実装を行っています。

  java-changes:
    runs-on: ubuntu-slim
    outputs:
      java: ${{ steps.filter.outputs.java }}
    steps:
      - name: Checkout repository
        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

      - name: Detect Java file changes
        uses: dorny/paths-filter@ceb8a2b8f2d89434be7ff52d3de7ec3738c5cc9d # v4.0.3
        id: filter
        with:
          filters: |
            java:
              - '【Java Directory】'

  java-build-and-test:
    needs: java-changes
    if: needs.java-changes.outputs.java == 'true'
    ・・・以下略

このような実装にしている理由は以下２つを両立するためです

• Javaファイルに修正が入っていない場合はjava-build-and-testのJobをスキップしたい
• java-build-and-testが通らないとマージできないように制御したい

単純にBranch Protection RuleのRequire status checks to passにjava-build-and-testを追加して、workflow全体の実行条件をJava Directoryに変更が入っている時だけ実行するように設定してしまうと、Java Directoryに変更が入っていない時にマージできなくなってしまいます。

java-changes Jobの実行時間はほんの数秒で、マシンパワーも必要ありません。
GitHub Actionsの課金は秒を切り上げた1分単位となるため、ubuntu-latestを利用すると1回あたり0.006ドルがかかります。
ここにubuntu-slimを利用することで、0.002ドルに抑えることができます。

テストレポート作成ジョブ

私が開発しているプロダクトでは自動テストにかなり力を入れています。
リリースの際にはJUnitで実装したテストの実行結果も証跡として残すようにしているため、CIで日々実行されたテストの結果をmarkdown形式のレポートにして出力するジョブがあります。
内容としては最新のCIジョブの実行結果を参照し、テストの実行件数や実行時のコミットハッシュ、カバレッジなどを記録してレポートにまとめるものです。

こちらの実行時間も20秒程度のもので、マシンパワーも必要ありません。
そのためこちらもubuntu-slimに移行しました。
移行後、実行時間が40秒〜50秒ほどになり速度劣化が発生しましたが、許容できる範囲であったため、そのまま運用しています。

OpenAPI Specのバリデーションジョブ

リポジトリ内にOpenAPI Specを配置しているため、@redocly/cli でもバリデーションを行っています。
こちらも20秒ほどの処理で、こちらはslimに移行しても速度劣化はほとんどありませんでした。

こういうのには使いませんでした

Mermaidのバリデーション

リポジトリ内にはArchitectureの説明用のmdファイルも配置されており、その中でMermaidのシーケンス図を書いています。
よくCoding Agentが正しくない記述のものをコミットしてきていたため、@mermaid-js/mermaid-cli によるバリデーションを行っています。

こちらに関しては検討した結果ubuntu-slimに移行せず、ubuntu-latestのrunnerで運用をしています。

以下は実行時間を比較したものです。

ポイントは冒頭に挙げた、プリインストールされているツールが少ないという点です。
バリデーションジョブに必要なChromium runtime librariesがubuntu-latestにはあるが、ubuntu-slimにはありません。
そのためインストールの時間がかかるようになっており、その時間が結構なボトルネックになっていました。

実行時間を切り上げて分単位で比較すると、2倍以内には収まっているので、移行した方が料金的にはお得ではあるのですが、今後バリデーションファイルが増えていくことも予測できており、ジョブが3分を超えると少しストレスにもなりそうだなと感じたため、こちらは移行せずに現状維持としました。

Build系

私が開発しているプロダクトでは固有の制約がありそもそも検討しませんでした。

ただそういった制約がない場合も、Build周りはCPUやRAMによる速度劣化が大きいため、あまり向いていないのではないでしょうか。実行時間的にも、大きなプロダクトだと収まらないパターンも多いのではないかと思います。

まとめ

とにかく実行時間が短いものを見ていき、簡単にできそうなものから移行していくのが良いと思います。GitHub Organizationのinsightsなどで各Actionのメトリクスを取っていると、あたりをつけやすいです。

実際に移行を考える際には、実測して比較をした上で、

• コスト
• 実行時間
• ストレス

といった観点をチームで検討するのが良いと思います。

おわり。