軽いCIを常時稼働のクラウドランナーへ移す判断軸
今回やったこと
CIをどのマシンで動かすかは、処理の重さだけでは決められない。手元のMacでしか動かない処理、常時稼働が必要な処理、OSに依存しない軽い検査を分ける必要がある。ここでは、ワークフローのコメントと移設計画に残された実例をもとに、軽いCIを常時稼働のクラウド機へ移す判断軸を整理する。
実装ステータス
対象となる移設はワークフロー上で移設済みとして記録されている（個々のジョブの稼働確認は本稿の範囲外）。文章の表記検査は2026年9月3日、自動起稿レーンは2026年10月6日に移され、どちらもワークフローの runs-on 付近に移設日がコメントされている。この記事ではインフラ全体を新たに構築した手順ではなく、既存資料に記録された配置判断を説明する。
移設先を決める前に依存条件を分ける
移設計画では、常時稼働の一次機として Ubuntu 24.04 arm64 のクラウド機を置き、CIランナーもその役割に含めている。一方、M1はフェイルオーバー先と、macOSが必要なCIランナー1本を担う計画になっている。すべてをクラウドへ移すのではなく、OS固有の処理を残す設計だ。
資料に記載されたM1上のGitHub Actionsランナーは3本で、runs-on: [self-hosted, m1] を使うワークフローは19本とされていた。調査では、ワークフローの記述はmacOS前提に見えても、実際の処理本体はPython、Node.js、GitHub CLIだけで動くものが多かった。したがって、ラベルを一括置換するのではなく、ジョブが依存するOS機能とツールを調べてから移す方針が採られている。
判断材料は三つに分けられる。
| 判断軸 | クラウドへ移しやすい条件 | 手元に残す条件 |
|---|---|---|
| OS依存 | Python・Node.jsなど共通ツールで実行できる | macOS専用機能やコマンドが必要 |
| 稼働時間 | 定時実行や常時稼働のホストが必要 | ローカル機器など場所に依存 |
| 復旧要件 | サーバー再起動後にサービス管理で戻せる | 手元のログインやデスクトップ操作が必要 |
表は計画書の役割分担を整理したもので、個々のジョブを自動判定するルールではない。各ワークフローの依存コマンドや接続先は、移設前に個別に確認する。
ランナーを移すときの段取り
第一に、ワークフローごとに runs-on と実際の処理を確認する。ラベルが m1 だからmacOS必須だと決めつけず、スクリプトが使うコマンドとファイル形式を追う。移設計画では、launchctl、sips、caffeinate、pmset、osascript など、macOSに固有の経路が調査対象として挙げられている。これらが無条件に呼ばれるか、代替経路があるかを見てから配置を決める。
第二に、移行を段階化する。既存のワークフローでは、移設日がコメントとして残されている。小さな単位で移し、実際にどのホストのランナーが処理したかを確認すれば、失敗時に原因を狭めやすい。移設計画では、Linuxランナー用のラベルを加えてワークフローを段階的に付け替える方針が記載されている。
第三に、元のランナーをすぐに消さず、必要なジョブが新しい環境で動くことを確認する。移設先で失敗した場合に、OS依存の見落としか、認証・PATH・依存パッケージの問題かを切り分けるためだ。記事の参照資料は段階的な付け替えを示しているが、個別ジョブの移行完了率までは示していないため、一括移設が完了したとは扱わない。
クラウド化で得るものと残る制約
常時稼働ホストへ軽いCIを置けば、個人のMacが起動しているかどうかにビルドや検査の実行が左右されにくくなる。定時実行の自動化レーンも、固定したホスト上で動かしやすい。一方、クラウド機に移せば運用が不要になるわけではない。認証情報、ランナーのラベル、更新、監視、再起動後の復旧を管理する必要がある。
また、クラウドのネットワークからアクセスできないサービスや、macOS固有の処理は移設候補にできない。資料では、クラウドのネットワークからは接続できない処理は手元の機械に残すとされている。クラウド移設はホストを変える判断であり、外部サービス側のアクセス制限を解決するものではない。
環境と確認範囲
参照した設計資料は、Ubuntu 24.04 arm64 のクラウド機とM1の役割分担を記録している。ワークフローの runs-on コメントは移設日を示す。個々のランナーの現在の稼働状態やジョブ成功率を本稿で計測したわけではないため、実環境へ適用するときは直近の実行ログとランナー登録状態を確認する。
更新履歴
- 2026-10-18: 初稿作成。