GitHub公式の課金説明では、Actionsの利用料金を確認する際、リポジトリの公開範囲やRunnerの種類、保存容量などを区別します。公式の課金項目を踏まえると、研究CIの予算は月間の合計時間だけで決めず、実際のワークフローごとの実行回数と所要時間、再実行、保存容量を記録してから、当日の公式条件に照合するのが先です。
短時間で完結する自動テストは托管Runnerで見積もり、継続的な調査や手動検収があるなら、利用環境の費用を別枠で計算してください。最終確認日は2026年9月27日です。GitHub ActionsのRunner情報、larger runnerの利用条件、公式の単価と課金ルールを照合しています。ルールやラベルは変わるため、実際の予算決定時にも再確認してください。
対象となる方
- macOSのビルド、テスト、署名確認のCI予算を組む大学・研究機関のソフトウェア開発者。
- 非公開リポジトリの月間利用量を把握したい課題グループの責任者。
- 短時間の自動処理と、継続利用できるmacOS環境の境界を整理したい研究室のCI管理者。
見積もり前に、月間合計ではなく実行記録をそろえる
月間の見積もりは、ワークフローの種類ごとに「実行回数 × 実測した処理時間」を集計し、失敗後の再実行や並行して動くジョブを加えて作ります。キューで待った時間とRunner上で処理した時間は分けて記録し、課金対象の扱いは公式の請求情報で確認してください。
公開リポジトリと非公開リポジトリ、標準Runnerとlarger runnerでは、適用条件や課金の考え方が同じとは限りません。無料枠や単価も一律とは限らないため、他のアカウントや過去の請求額を流用せず、予算を作成する日に対象リポジトリとRunnerの条件を確認します。
見積もり表には、少なくとも次の項目を設けます。
- リポジトリの公開範囲とRunnerの種類
- ワークフローの用途、月間実行回数、実測した処理時間
- マトリックスで増えるジョブと失敗後の再実行
- 成果物、ログ、キャッシュの容量と保存期間
- 公式条件の確認日と、確認した単価・無料枠
PR後のビルドとスモークテストを分けて数える
プルリクエストの更新ごとに動く軽量ジョブは、回数が増えやすいため、代表的な運用期間の実行履歴から頻度を拾います。GitHub Actionsの利用状況メトリクスを確認し、処理時間、失敗、再実行が分かるログと突き合わせます。
その際、macOSでなければ実行できない作業と、言語解析やフォーマット確認のように別の実行環境へ分けられる作業を仕分けます。macOS依存がない検査まで毎回macOS Runnerに載せているなら、処理を分離した後の実行記録も取り、削減できたジョブ数と残すべき検査を確認してください。
並行実行では、同じ変更に対する古い実行が残るかどうかも点検します。ワークフローの並行制御を使う場合は、処理を取り消しても安全かを先に判断します。長時間の解析や成果物生成を安易に中断すると、再実行が増えて見積もりが崩れるためです。
Xcode 27を含む回帰ジョブは、ラベルと実行範囲を確認する
Xcode 27が必要な場合は、まず使うRunnerラベル、macOSの版、CPUアーキテクチャ、公開プレビューの状態を確認します。Runnerイメージの一覧とXcode 27のプレビュー告知は更新されるため、以前動いた設定だけを根拠に継続利用を決めないでください。
費用の集計では、単一環境でのビルド、複数のmacOS環境を対象にした回帰テスト、署名確認を別々の作業として記録します。マトリックスにより一度の起動から複数のジョブが作られる場合、ワークフローの実行回数だけを数えると実際のRunner利用を小さく見積もります。ジョブ単位の回数と所要時間を残してください。
プレビュー中の構成は、ラベルの提供状況や条件が変わる可能性を含めて扱います。Xcode 27のテストが継続的な研究開発に不可欠なら、対象イメージでの実行が可能かを公式情報で確認し、プレビューが終了した後の代替環境も検討項目に入れます。
定期解析と長時間処理は、再実行要件まで分ける
定期解析や周期的な回帰は、スケジュールによる実行頻度と、実行ログから得た処理時間をもとに集計します。途中で中断した場合に最初から再実行するのか、状態を引き継げるのかも確認し、通常実行と復旧用の実行を同じ成功ケースとして扱わないようにします。
ビルドを開始して完了後に終了するCIと、画面操作を伴う調査や、プロセスと状態を保ちながら繰り返し確認する作業は別の運用です。後者を短時間のRunner利用量だけで見積もると、作業のたびに環境を再構築する負担や、手動確認の時間が見落とされます。
成果物、キャッシュ、失敗の再実行を予算へ加える
ログ、成果物、依存関係キャッシュは、Runnerの処理時間だけを集計しても把握できない確認項目です。キャッシュの制約と動作を確認し、保存する必要があるデータと、古くなったデータを整理できるかを分けます。成果物とログは、組織で設定された保存期間も調べてください。公式の保存期間設定で適用条件を確認できます。
予算には、実際に発生した失敗後の再実行と、同時に動くジョブを反映します。単発の成功記録だけでは、依存関係の取得失敗やテスト不安定時の追加利用を捉えられません。直近の運用ログを振り返り、再実行の理由、成果物の保存要否、容量を記録してから公式の課金条件に照合します。
課題グループの判断を、利用場面ごとに採点する
次の対比表は料金の優劣ではなく、作業の性質から予算の分け方を決めるためのものです。評価は「◎＝適合しやすい」「○＝条件を確認」「△＝別枠で要検討」を示します。実際の請求額は、リポジトリやRunnerに適用される公式条件を確認して算出してください。
| 選択肢 | PRごとの短い自動ビルド | 定期的な回帰・バッチ | 手動デバッグ・継続利用 | 判断 |
|---|---|---|---|---|
| 標準の托管Runner | ◎ 実行回数と時間を記録して見積もる | ○ 実行頻度と再実行も加算 | △ 毎回の再構築や操作性を確認 | 実行が開始・終了の明確なジョブ向き |
| larger runner | ○ 必要なRunner条件を確認 | ○ 実際のラベルと課金ルールを確認 | △ 継続利用できる環境とは別に評価 | 標準Runnerでは要件を満たせないか検証 |
| 継続利用できる遠隔Mac環境 | △ 短いジョブだけなら利用形態を要確認 | ○ 状態維持や人手の介入がある場合に比較 | ◎ 調査・手動検収・反復デバッグを別枠評価 | 常時利用の必要性と契約条件を確認 |
よくある質問
非公開リポジトリの利用量を見積もるには
ワークフロー別に実行回数と処理時間を記録し、マトリックスで増えるジョブ、失敗後の再実行、保存容量を加えます。次に、リポジトリの公開範囲とRunnerの種類に応じた条件を公式請求ページで確認します。無料枠や単価は確認日と一緒に記録し、別アカウントの条件を自分の課題グループへ当てはめないでください。
Xcode 27の実行環境を選ぶ手順
Runnerイメージ一覧とXcode 27の公開プレビュー告知で、ラベル、macOS、アーキテクチャ、プレビュー状況を確認します。実行時間は予想で埋めず、代表的なテストを動かして測定します。公開プレビューの状態や提供ラベルに変更があれば、利用継続の可否と予算を再確認します。
再実行や成果物を集計する方法
再実行は初回とは別の処理としてログから拾い、成功した実行だけを月間利用量の根拠にしないようにします。成果物、ログ、キャッシュは容量と保存期間を確認し、Runnerの時間とは別に適用される条件を公式情報で照合します。失敗理由も記録しておくと、一時的な再実行と継続的な不安定さを分けられます。
托管Runnerと継続利用できる遠隔Macの境界
テストの開始と終了が明確な自動ジョブなら、実測した利用量をもとに托管Runnerを見積もります。反対に、画面を見ながらの調査、手動検収、状態を保った反復作業が多い場合は、CIの分数に含めず継続環境として費用と運用条件を評価します。両者を併用する場合も、用途別の記録を分けると判断しやすくなります。
まず代表的なプロジェクトの実行ログを集め、処理時間、再実行、保存容量を計算してから、核算当日の公式条件に照らしてください。短時間で完結するCIだけなら托管Runnerでの見積もりを優先し、手動検収や継続デバッグも必要だと分かった段階で、遠隔Macの利用条件を確認します。導入前にはMac環境の利用案内を確認し、研究用途のMac環境についてはレンタル構成の案内も参照してください。需要が短期の検証ではなく、常時稼働する重い処理や物理接続にある場合は、レンタルを前提にせず、研究室での実機運用も含めて比較するのが適切です。