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 分キューに並ぶ、というパターンがよく出ます。

すでに Cloud Mac で Claude Code を動かしていても、git push 後に Linux runner で xcodebuild: command not found になることは珍しくありません。問題は Agent ではなく、macOS 上の CI 実行層があるかどうかです。本稿は「GitHub Runner とは」の百科でも、actions/runner の登録手順（L1 連載の次回）でもありません。一点だけ：なぜ Cloud Mac の上に L1（GitHub Runner）を単独で立て、「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 五層構造図（責務階層）

図は組織内の承重関係を示します（ランタイムの呼び出し順ではありません）。L2–L5 の記事を読むときは、#stack-map に戻って対照してください。

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。L2 の Ollama はプライベート推論を載せられる層で、L3 と並行可能——必ず「先に Ollama、後から Claude Code」とは限りません。

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

五層モデルで 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

コーディングは L3。バイナリを外に出すのは L1。どこかが欠けると「Agent は完了、App Store Connect にパッケージなし」になります。

リポジトリの workflow では、通常 runs-on の Runner ラベル だけが見え、マシン側の登録手順は見えません。典型的な GitHub Actions iOS build を macOS ARM64 self-hosted runner へ載せる job 抜粋（token・launchd などは L1 連載の次回）：

# .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

エンジニアは GitHub Runner という汎用語だけを搜すことは少なく、具体的なシーンで来ることが多いです。例：

• 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 自動化

これらの表現の背後には、だいたい同じアーキテクチャ問題があります：GitHub Actions の job を自社の Apple Silicon ノードへ送りたい。Cloud Mac（またはオフィスの Mac mini）が機械で、Runner を登録して label を付けると「配車」が完成します。本稿は層を立てる理由；登録手順は L1 連載の次回。ハード比較は Mac mini vs Cloud Mac（iOS チーム）；Runner コストは同連載の後続で扱います。

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 連載の冒頭です。なぜ実行エンジンが先に要るかを述べ、続けて Runner を概念から運用へ：

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。L2 Ollama アーキテクチャも参照。§ 五層図。