GitHub Runner が Cloud Mac AI Stack の実行エンジンである理由

昨日までの話題でも触れましたが、Claude Code・CodeGraph インデックス・Ollama をリモート macOS ノードへ移すチームが増えています（Cloud Mac vs ローカル Mac）。「クラウドに乗せれば push で全部緑」——そう思っても、ターミナルの Agent は快調なのに git push 後の GitHub Actions は ubuntu-latest のまま、xcodebuild が落ちるか、macOS job が 30 分キューに並ぶ、というパターンがよく出ます。

本稿は「GitHub Runner とは」の百科でも、actions/runner の登録手順（次回のチュートリアル向け）でもありません。目指すのは単なる Mac レンタル訴求ではなく、拡張可能な方法論 Cloud Mac AI Stack です。L1 が答えるのは：なぜ「Claude Code が動くリモート PC」で終わらず、先に実行エンジンが要るのか。

Stack 言語：Context → Diff → Fact → Workflow

Claude Code、Cursor、MCP、OpenHands の話は溢れていますが、Agent がコードを直したあと、誰が組織が認める結果になるかはあまり語られません。業界語は Agent、Tool、CI、Automation——Cloud Mac AI Stack では四つの産出物でつなぎます（L2 推論は表で別枠）：

記憶用チェーン（呼び出し順ではない · 五層図参照）

  Context  →  Diff  →  Fact  →  Workflow
  (MCP)      (Claude Code)  (Runner)  (OpenHands)

論点は「AI が賢いか」ではなくL1 が独立しているか。Fact 層がなければ Context と Diff がどれだけ綺麗でも、merge ボタンの緑にはなりません。

コーディング層と実行層：Cloud Mac でも CI が切れる理由

実行レイヤーの分割では、モデル推論と Agent 実行を分けました。さらに一歩、多くのチームが見落とす第二の実行チェーンがあります——ターミナルで一度走る pnpm test ではなく、push 後に CI が定義する再現可能・監査可能なビルドです。

断絶はここで起きます。Claude Code を Cloud Mac の SSH に置き、そこでテストは緑。しかし workflow は Linux runner のまま——リポジトリの公式な真実は赤のまま。iOS チームでは TestFlight パイプラインが Linux では始まりません。実行層は独立し、しばしば同種の macOS 環境と揃える必要があります。

典型誤認：Claude Code「テスト全部通過」、PR は赤

顧客リポジトリで繰り返し見る同型事故——図より覚えやすいです：

1. Cloud Mac の SSH で Claude Code。Agent：「すべてのテストが通りました。」
2. 開発者が git push して会議へ。
3. GitHub Actions 起動。workflow は runs-on: ubuntu-latest のまま。
4. 約 10 分後 PR checks が赤。ログの定番：xcodebuild: command not found（または iOS job がなく Node テストだけ Linux で緑）。

Claude Code のせいではなく、Claude Code の実行環境 ≠ CI の実行環境です。macOS セッションの「通過」は、組織が認める Runner が同じ GitHub Actions パイプラインで再現していません。Runner はセッション内の結論を push ごと監査可能な Fact にします——必要なら GitHub Actions self-hosted runner macOS と同ノードに。

Runner は「もう一台 Mac を借りる」ことではない

よくある三つの誤解をはっきり切ります：

• 違う：Cloud Mac の製品紹介——レンタルは L0。Runner はその上でGitHub ジョブを常時待ち受けるソフトとポリシー（label、並列、ワークスペース掃除）。
• 違う：GitHub 公式 macos-latest の説明書——ホスト runner は別の課金・キュー・隔離。self-hosted は自ノードへディスパッチ。
• 違う：OpenClaw / OpenHands——OpenClaw クラウド自動化はオーケストレーションと ACK。Runner は xcodebuild、fastlane を実際に踏む足です。

一言で：Cloud Mac は macOS 算力と出口。Runner はそれを GitHub のイベントモデルに接続する。

Runner がなければ Cloud Mac はリモート PC。Runner があって初めて研発インフラ。 一句だけなら：Diff → Fact（上の青枠）。

Cloud Mac AI Stack 五層構造図（シリーズ共通 · 戻りリンクは #stack-map）

今後の L2–L5 は「Cloud Mac AI Stack 五層構造図を参照」（本稿 #stack-map）で統一。単発 SEO ではなく方法論と命名を積み上げます。

Cloud Mac AI Stack 五層（責務 · 下から上）

                 ┌──────────────┐
                 │  OpenHands   │  L5 · Workflow
                 └──────┬───────┘
                        │
                 ┌──────▼───────┐
                 │     MCP      │  L4 · Context
                 └──────┬───────┘
                        │
                 ┌──────▼───────┐
                 │ Claude Code  │  L3 · Diff
                 └──────┬───────┘
                        │
                 ┌──────▼───────┐
                 │    Ollama    │  L2 · Inference（任意）
                 └──────┬───────┘
                        │
                 ┌──────▼───────┐
                 │ GitHub Runner│  L1 · Fact  ← 本稿
                 └──────┬───────┘
                        │
                 ┌──────▼───────┐
                 │  Cloud Mac   │  L0 · インフラ
                 └──────────────┘

読み方：L0 が算力を支え、L1 が組織が信じる Fact を支え、その上に Diff・Context・Workflow。Ollama は L2 の「プライベート推論を載せられる」示し。L3 の前に Ollama 必須ではありません。

「実行エンジン」と呼ぶ理由

五層モデルで Runner は L1 固定。Claude Code と「どちらが賢いか」を争うのではなく、再現実行の三つ：

1. リポジトリイベント——on: push、pull_request、workflow_dispatch が label 付き self-hosted runner へ job を送る。
2. macOS ネイティブツール——xcodebuild、swift test、notarytool、署名・アーカイブ。Linux では代替不可。
3. AI 層との分離——Agent が直す ≠ CI 自動合格。Runner は「直した」を artifact・テストレポート・配布可能物にする。

iOS / Flutter（iOS ターゲット）向けの実デリバリー経路：

Cloud Mac AI Stack · L1 実行鎖（概念）

  Claude Code（L3 · SSH / ターミナル）
           │
           │  git commit & push
           ▼
  GitHub（webhook / Actions スケジュール）
           │
           ▼
  GitHub Actions workflow
           │
           ▼
  GitHub Runner（L1 · self-hosted · macOS · ARM64）
           │
           ├── xcodebuild（Debug / Release）
           ├── 単体 / UI テスト
           ├── archive → .ipa
           └── fastlane → TestFlight

価値：「Runner とは」の定義はコピーされやすいが、Stack 全体の階層関係はコピーしにくい。コーディングは L3。バイナリを外に出すのは L1。どこかが欠けると「Agent は完了、App Store Connect にパッケージなし」になります。

# .github/workflows/ios-ci.yml（抜粋）
jobs:
  build-ios:
    runs-on: [self-hosted, macOS, ARM64, cloud-mac]
    steps:
      - uses: actions/checkout@v4
      - name: Build & Test
        run: xcodebuild -scheme MyApp -destination 'platform=iOS Simulator,name=iPhone 16' test

検索は「GitHub Runner」より iOS CI / Mac mini Runner

SEO・サポートでは、エンジニアは汎用語より次の意図で来ることが多いです：

• GitHub Actions self-hosted runner macOS / macOS ARM64 runner / Apple Silicon runner
• GitHub Runner Mac mini / GitHub Actions Mac mini
• iOS CI/CD self-hosted runner / GitHub Actions iOS build
• Cloud Mac CI、Xcode on CI、TestFlight 自動化

背後は同じアーキテクチャ問題：job を自社の Apple Silicon へ送りたい。Cloud Mac（またはオフィスの Mac mini）が機械。Runner 登録 + label で「配車」が完成。本稿は層を立てる理由。L1-Q02 で手順。

「Mac mini を買う vs Cloud Mac を借りる」は L0 の話——Mac mini vs Cloud Mac（iOS チーム）。Runner ロジックは同じ。L1-Q05 でコスト比較予定。

Linux では足りないとき · macOS Runner が不要なとき

ubuntu-latest は Web バックエンドに強いが、Apple デリバリーには硬い境界があります。

「向かない」も同じくらい重要——万事 Cloud Mac と誤解されないため。次はLinux runner のままでよい典型：

• Next.js / 静的フロント——Node ビルドのみ、Xcode なし。
• Node / Python / Go API——Docker job は Linux が一般的。
• コンテナ化バックエンド——K8s デプロイは macOS 不要。
• 個人小規模リポ——月数回 CI ならホスト runner のキューコストの方が安いことも。

macOS Runner のシグナルは集中：workflow に Xcode、署名、notarize、Simulator、TestFlight。または Mac mini vs Cloud Mac を検討中。本稿は L1 の位置だけ強調します。

ホスト macos-latest vs Cloud Mac 自前

経験則（契約ではない）：週 10 回超の macOS job の半分が iOS 署名・アーカイブなら、L1 を「一時キュー」から「固定 Cloud Mac + self-hosted」へ。それ未満ならまずホスト macOS でパイプラインを通す方が楽なことが多いです。

導入順：先に Fact、後から Diff——図とは別

五層図は責務階層。導入はデプロイ順も別記：多くの記事は Claude Code → MCP → 最後に CI。私たちは：

1. L0——Cloud Mac（常駐 macOS、出口、SSH）。
2. L1——GitHub Runner。先に push → 緑/赤 を再現（本稿）。
3. L2–L3——Ollama、Claude Code。「客観的ビルド結果」の上に AI。
4. L4–L5——MCP、OpenHands。安定 CI の後。

CodeGraph + Agent は 18 ファイル直せても、macOS CI が不安定ならarchive で爆発する漏れが分からない。Runner が先に「機械検収」を固定し、AI がサンドボックス遊びにならない。

Mac mini + Claude Code 一週間は L3 体験。本稿は L1——同一マシンで夜 Runner・昼 Agent も可。ただし記事では層を混ぜない。

判断：Runner を実行エンジンとみなすか

左列に二つ以上当てはまるなら、次は MCP を増やす前に L1 を通してください。L1 連載へ。

L1 連載：実行エンジンから運用可能な macOS CI へ

本稿は Cloud Mac AI Stack · L1 基盤（L1-Q01）。続きは Runner を概念から運用へ：

Google は L1 の記事群を「GitHub Runner + macOS CI」トピックとして理解しやすいです。L2 以降は Ollama（Inference）、Claude Code（Diff）、MCP（Context）、OpenHands（Workflow）——いずれも「push に Fact がある」前提。戻り 五層構造図。

よくある質問

Cloud Mac と self-hosted Runner の関係は？
Cloud Mac は L0。Runner は L1 のプロセスとポリシー。レンタル ≠ Runner 自動付与。

MacBook だけで Runner？
可能だが安定性に難。日次 macOS CI は 24/7 Cloud Mac が一般的。

Runner と Claude Code は同機必須？
必須ではない。同機は「SSH 緑・Actions 赤」の摩擦低減。

OpenClaw との違い？
Runner は step 実行。OpenClaw はトリガーと ACK。OpenClaw クラウド自動化参照。

self-hosted runner macOS と Cloud Mac の併用？
L0 に Runner を登録し、runs-on: [self-hosted, macOS, ARM64] で iOS CI/CD・xcodebuild・TestFlight をそのノードへ。

Claude Code → Diff、Runner → Fact の意味は？
Diff はセッション内の変更と主観的結論。Fact は GitHub Checks の緑、ログ、artifact。組織が merge するのは後者。MCP は Context、OpenHands は Workflow。§ Stack 言語。

図で Ollama が Claude Code の下＝先に Ollama？
いいえ。責務階層であり呼び出し順ではない。Claude Code は API 利用が多く、Ollama は L2 任意 Inference。§ 五層図。