← ブログ

M6 Mac miniとGitHubのホスト型macOS runnerを比較:Xcodeビルドのベンチマーク

2026年9月24日 · 7分で読めます

ある疑問に、実際の数字で答えたいと考えました。実際のiOSアプリで、専用のM6 Mac miniはGitHubの標準ホスト型macOS runnerよりどれだけ速いのか。そこでオープンソースのWikipedia iOSアプリを両方でビルドしました。Xcodeもスクリプトも同じで、それぞれ3回ずつです。

この記事は、以前のM4ベンチマークの記事に代わるものです。ここにある数字はすべて、2026年9月24日の実行結果です。

結果

Median of 3 runs, in seconds. Lower is better.

                      GitHub-hosted   MacRun M6   change
                      macos-26
package download            43            39       -8%
clean build                183            86      -53%
incremental build           21            10      -51%
no-op build                 20            10      -50%
220 unit tests              44            17      -61%

コンパイルはM6のほうが約2倍速くなりました。パッケージのダウンロードは僅差でした。どちらのマシンも、同じパッケージを高速な回線でGitHubから取得するからです。すべての手順が、両方のマシンのすべての実行で成功しました。

普段のCIジョブにかかる時間

上の表は、マシンを手順ごとに比べたものです。実際のCIジョブの中身は、それぞれで違います。ホスト型runnerは毎回空の状態からジョブを始めます。パッケージをダウンロードし、クリーンビルドし、それからテストします。専用のMacはビルドフォルダを残しているので、小さな変更のあとは変わった部分だけを再ビルドします。

これがチームが体感する差です。4分半かかっていたジョブが、30秒未満で終わります。プッシュの多い日なら、節約できる時間は数時間になります。

ホスト型runnerでは、同じジョブにお金もかかります。GitHubはジョブごとに分単位で切り上げるので、269秒は5分として請求されます。1分$0.062なら、ジョブ1回あたり約31セントです。専用のMacなら追加料金はかかりません。当社のコスト計算ツールで、ご自身のジョブ数を月額に換算できます。

2台のマシン

ハードウェアの詳細は、マシン自身が出力したものです。各実行で、ビルド前にチップ、コア数、メモリを表示させました。GitHubは、より大きなmacOS runnerも高い分単価で販売しています。ここでは、ほとんどのチームが使う標準runnerをテストしました。

手法

  • プロジェクト:wikimedia/wikipedia-iosのコミット8691a89。WikipediaスキームとSwiftパッケージを使い、iOSシミュレータ向けにビルド。
  • シミュレータ:iOS 26.5の新しいiPhone 17。両方のマシンで同じ方法で作成。
  • 各実行の開始時に、パッケージキャッシュとDerivedDataを削除。CIのシミュレータビルドでは普通そうであるように、署名はオフ。
  • パッケージのダウンロード:空のフォルダに対してxcodebuild -resolvePackageDependencies。
  • クリーンビルド:DerivedDataが空で、パッケージはダウンロード済みの状態でxcodebuild build-for-testing。
  • インクリメンタルビルド:アプリ内のSwiftファイル1つにコメント行を1行追加し、同じコマンドを実行。
  • 何も変更なしのビルド:何も変えずに、同じコマンドをもう一度実行。
  • テスト:アプリのWMFDataパッケージにある220個のユニットテスト。起動済みのシミュレータでtest-without-buildingを使って実行。
  • 各マシンで全体を3回実行。中央値を報告。

注意点

実行したのはアプリのパッケージのテストで、メインのテストターゲットではありません。メインのターゲットには署名済みのApp Groupのエンタイトルメントが必要で、署名なしのCIビルドにはそれがありません。そのテストホストは両方のマシンで再起動を繰り返したので、公平な測定になりませんでした。

インクリメンタルビルドで変更したのは小さなファイル1つです。10秒のほとんどはXcodeがビルドを計画する時間です。そのため、何も変更なしのビルドと同じ時間になっています。広く使われているファイルを変更すれば、どちらのマシンでも時間は長くなります。

2台のマシンでmacOSのバージョンは違います。それぞれの運営者が現在提供しているものを使ったためです。ホスト型のジョブでも、actions/cacheでSwiftパッケージをキャッシュできます。そうすればダウンロードの手順は短くなります。ただし、時間の大部分を占めるクリーンビルドはなくなりません。

当社はM6 runnerを販売しています。その点を考慮して数字を見てください。上の手法は、ご自身のプロジェクトで再実行できるだけの情報をそろえています。あなたにとって本当に意味のあるベンチマークは、それだけです。

よくある質問

GitHubの標準macOS 26 runnerのハードウェアは何ですか?
当社の実行では、macos-26 runnerはApple M2 Pro (Virtual)、CPU 5コア、メモリ14 GBと表示しました。仮想マシンで、ジョブごとに新しく起動します。
XcodeのビルドでM6 Mac miniはどのくらい速いですか?
当社のベンチマークでは、WikipediaのiOSアプリのクリーンビルドの中央値が、専用のM6 miniで86秒、GitHubの標準macOS 26 runnerで183秒でした。53%速いことになります。インクリメンタルビルドとユニットテストは50〜61%速くなりました。
日常のCIジョブで専用runnerがこれほど速いのはなぜですか?
主な理由は、ジョブ間でビルド成果物を残しておけることです。ホスト型runnerは毎回空の状態からジョブを始めるので、毎回パッケージをダウンロードしてクリーンビルドします。専用のMacは変更された部分だけを再ビルドします。
このベンチマークは再現できますか?
はい。手法のセクションに、プロジェクト、固定したコミット、Xcodeのビルド番号、正確なxcodebuildの手順を載せています。MacとGitHub Actionsがあれば、誰でも同じ手順を実行できます。

自分の数字で試すなら 計算ツール へ。または ランナーを契約する。