僕等はただ失っていくので初投稿です。
先日public previewとして発表されたubuntu-slim runnerとcoding agentを用いた置き換え作業の補助について紹介します。
ubuntu-slimについて
ubuntu-slimは2025年10月末にpublic previewとして公開された、GitHub Actions用の新しいrunnerです:
軽量で格安なのが特長で、ubuntu-latest（もしくはfixed versionのUbuntu runner。この記事では便宜上これらrunnerをubuntu-latestと呼ぶことにします）の廉価版として登場しました。
ubuntu-slimのメリット
何と言ってもコストが格安なのが嬉しみポイントで、ubuntu-latest(standard runner)が$0.008/min.なのに対し、ubuntu-slimは$0.002/min.と1/4の料金で利用できます。
PR submit時に毎回走るworkflow/jobなど、小さい利用をきちんと置き換えていけばちりつもでそれなりのコスト削減になるはずです。
制約事項
- ubuntu-slimには15分の実行時間制限が設けられています。
- 1vCPUと5GBのRAMが割り当てられます（ubuntu-latestはprivate repositoryだと2vCPU/7GB RAMです）。
- ストレージ容量も少し小さめになります。
- pre-installed toolsもubuntu-latestと差分があり、Javaなどの一部ツールがインストールされておらず追加stepが必要でした（これは記事執筆時点の状況であり、GA時には変わっているかもしれません）。
- 執筆時点ではubuntu-slimにインストールされているツール群は公開されていないため、手探りで動作確認をする必要があります。
- ubuntu-latestはVMインスタンスとして動作しますが、ubuntu-slimはcontainerとして実行されます。
- GitHubにはplanごとに"Included Minutes"と呼ばれる無料枠がありますが、これはubuntu-latest/ubuntu-slimどちらも同じ量を消費します。
- そのため、無料枠からほとんどはみ出さないくらいの使用量だとコストメリットはそこまで大きくないかもしれません。
置き換え作業を楽にしたい
コストが安くなるなら積極的にubuntu-slimを使っていきたいものです。アナウンス記事ではlabelingなどが置き換え対象例として挙げられています。
その他、PRにauthorをassignするだけのjobであれば置換すべきことは自明ですが、Actionsを深く利用していればいるほど管理しているworkflow/jobの数・内容は複雑になり、置換すべき対象を見つけるのに苦労するかもしれません。
ここで「そうだ、coding agentに依頼すればいいじゃない」という話が出てきます。雑に「ubuntu-slimはこういうrunnerで、置き換えできるやつ探して～」と依頼してもいいのですが、もう少し判断材料があればより正確に提案してくれるでしょう。
人間が置き換えるときに何を見るかといえばworkflow/jobの平均実行時間がその一つとして挙げられるかと思います（単発でもいいのですが、cacheのinvalidationなどrunごとに実行時間に大きくブレが出るケースもあり、それらを均して取得する方が望ましいケースもあるでしょう）。そういった情報やubuntu-slim特有の制約などを加えて依頼するとより精度が上がりそうな気がしますね。
jobのメトリクスを取る
平均実行時間などのメトリクスを取得する手段として、WebだとActions Usage MetricsまたはActions Performance Metricsを利用できます。
ただしcoding agentにこのまま読ませるのは少し難しく、private repositoryでは尚の事です。一応CSVをexportできるのですが、organization配下のrepositoryについてそれぞれCSVをexportしてagentに渡して……といった作業は骨が折れます。
自分はCLIでサクッと取得したかったのでGitHub CLI extensionを作って解決することにしました:
平均実行時間を取得するにはAPIのresponseを束ねる必要があり、単純に gh api commandを使うのではなく、extensionで集計などを行っています。また、GitHub CLI extensionの嬉しみポイントとして gh auth login 時に作成されたtokenを使ってAPI callできるというものがあり、利便性が高いです。
JSON/CSV optionsを備えているので結果をJSONやCSVで吐き出してagentに渡すこともできます。
gh-actricsの実際の使い方
extension自体は gh extension install JohnTitor/gh-actrics するだけで導入でき、以降は gh actrics サブコマンドとして利用できます。以下はorganization配下の特定workflowについて、過去30日分の平均実行時間をJSONで取得する例です:
gh extension install JohnTitor/gh-actrics
gh actrics workflow-runs my-org/my-repo \
--workflow assign.yml \
--days 30 \
--format json > assign.json
CLI内部でページングやworkflow runのステータスフィルタリングを済ませてくれるので、素の gh api を叩いてCSVをマージするより手軽に平均値を得られます。workflowの実行回数が多い場合はratelimitに引っかかるので --days オプションを適宜調整してください。
その他手段
その他手段としてはghaperfを使ってメトリクスを取得したり、gh-slimifyを使ってルールベースで置換したりと他にもありそうです。ここら辺は好みやworkflow/jobの特徴に合う手段を選択すればいいと思います。
結局精度は上がったのか
検証として、同じrepositoryを対象にGPT-5 Codex(via Cursor chat)に2つのプロンプトで依頼してみました。プロンプトは部分的に同じでubuntu-slim runnerの特性と制約を伝え、一方にのみ上記で得られたメトリクス（過去N日間の平均実行時間）がまとめられたJSONファイルを参考情報として渡しました。コンテキストはそれぞれクリアした状態から走らせています。
結果、平均実行時間なしに依頼したプロンプトでは、assignするだけだったりsubmoduleを更新するだけだったり、明らかに実行時間の短いjobのみubuntu-slimに置き換えられたのに対し、追加情報を与えたプロンプトでは実行時間が短くCPU-boundでなさそうなjobも置き換えの対象になっていました。
下記はagentの返答を抜粋したものですが、平均実行時間をもとに選定されているのが分かるかと思います:
...fooワークフローは平均約N秒かかっていますが、その大半はテスト系ジョブであり、今回切り替えた assign ジョブは数秒で完了するためランナー変更の影響はほぼありません。
...barワークフローは平均約N秒かかっていますが、AWS操作など軽量ステップのみを ubuntu-slim に移行し、ビルド処理が走るジョブは引き続き ubuntu-latest を使用します。
サンプルを十分に採れていないので精度が上がったと断言するのは難しいですが、少なくともagentの考慮事項として活用されているのが出力から分かります。
実際弊社環境でこの方式を用いて置き換えを行い、一定の正確性を持つ出力を得られました。もちろん完璧ではありませんでしたが、すべてを人力で確認する労力と比較して楽に置換作業を行えました。
まとめ
この記事ではGitHub Actionsのubuntu-slim runnerとその置き換え作業の簡便化について紹介しました。
ubuntu-slimはまだまだpreviewということもあり、pre-installed tools listが公開されていないなど、利用しづらい部分もありますが、一方でコストメリットは大きく特に大規模にActionsを活用しているorganizationでは大活躍しそうです。
Discussion