Claude Code GitHub ActionsでリモートMacをどう動かす？2026年デプロイガイド

📌 Claude Codeがコードを変更するJobと、リモートMacでApple向け検証を行うJobを分離する構成を解説します。外部Pull Request、Xcode、Simulator、署名資産、Mac Runnerの復旧まで、運用時の停止条件を場面別に確認できます。

2026年9月7日時点で、Claude Code Actionの公式利用資料とGitHubのRunner資料を確認すると、Claude Codeの処理とAppleツールチェーンの検証を同じJobに押し込む必要はありません。最短の安全策は、2つのJobに分けることです。Claude Code GitHub ActionsはIssueやPull Requestの理解、コード変更、コミット作成を担当し、リモートMacは固定されたCommit SHAに対するXcodeビルドとテストだけを担当させます。利用方法はClaude Code Actionの公式ドキュメントと、GitHubの自ホストRunner資料に照らして確認してください。

対象読者と先に決める境界

GitHub IssueやPull RequestをClaude Codeで処理し、iOSまたはmacOSプロジェクトを実際のmacOS環境で検証したい開発者向けです。
GitHub Actionsの自ホストMac Runner、ジョブ振り分け、再起動復旧を管理するDevOps担当者にも適しています。
さらに、Agentにソースコード、外部通信、キーチェーン、配布資格情報をどこまで見せるか決めるプラットフォーム・セキュリティ担当者にも必要な内容です。

2つのJobに分ける基本設計

Claude Code Action、Claude Code CLI、GitHub Actions Runner、Xcode実行環境は同じものではありません。Agent Jobは変更を作る処理、Mac検証Jobは変更を検査する処理です。一般的なコード解析や文章変更までMacで実行すると、Apple専用環境を不必要に占有します。

Job	主な役割	接触させないもの	成功条件
Agent Job	Issue・PRの読取り、変更、コミット、レビュー用出力	署名証明書、配布用キーチェーン	変更内容とCommit SHAが確定している
Mac検証Job	固定SHAの取得、Xcodeビルド、テスト、結果回収	未審査PRの任意スクリプト、公開用資格情報	`xcodebuild`の終了状態と結果ファイルを確認できる

Agent Jobの権限は、リポジトリの設定に合わせて最小化します。ワークフロー書き換え権限、Secrets参照、外部PRの扱いは、リポジトリ管理者が実際の権限設定を確認してください。Claude Code Actionのセキュリティ説明では、Actionに渡す権限や入力を安全に扱う考え方が説明されています。

Claude Code Actionと自ホストMac Runnerの接続

Claude Code ActionはGitHub ActionsのJob内で動きます。Apple SDKやSimulatorが必要な処理だけを、runs-onのラベルでMac Runnerへ振り分けます。ラベルとRunner Groupの割り当て方法は、GitHub公式のラベル設定手順と、Runner Groupのアクセス制御資料に合わせます。

jobs:
  agent:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
    steps:
      - uses: anthropics/claude-code-action@<固定バージョン>
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

  mac-verify:
    needs: agent
    runs-on: [self-hosted, macos, apple-project]
    steps:
      - uses: actions/checkout@<固定バージョン>
        with:
          ref: ${{ needs.agent.outputs.commit_sha }}
      - run: xcodebuild -scheme "<SCHEME>" -destination "platform=iOS Simulator,name=<SIMULATOR>"

上記は構造例です。Actionのバージョン、出力名、認証方法は、採用する公式ドキュメントと実環境で照合してください。存在しない出力値を前提にせず、Agent Jobから検証Jobへ渡すSHAは、明示的な成果物または信頼できるJob出力として固定します。

注意：Runnerがオンラインと表示されても、Xcodeの選択状態、Scheme、依存関係、Simulatorの起動状態まで保証されたわけではありません。オンライン表示は接続確認に限定し、ビルド結果は別の証拠で判定します。

コード変更後のXcode検証

Claude Codeが変更をコミットしたら、Mac検証Jobはブランチ名ではなく固定Commit SHAを取得します。これにより、Agentが変更した内容とMacでビルドした内容のずれを避けられます。

まず次を検査します。

xcode-select -pで選択中のXcode環境
対象プロジェクトまたはワークスペースの存在
<SCHEME>が共有設定されているか
Swift Package Managerなどの依存関係解決結果
実行したxcodebuildの終了ステータス
.xcresultなどのテスト結果パッケージ
作業ディレクトリと取得したCommit SHA

xcodebuildのオプションと終了結果の扱いは、AppleのXcodeコマンドラインツールリファレンスに合わせます。失敗時はキャッシュ削除やXcode変更をAgentに自由に許可せず、標準出力、エラー出力、結果パッケージをレビューへ返します。

検証段階	取得する証拠	停止条件
ソース	Commit SHA、リポジトリ、作業パス	SHAがAgentの成果物と一致しない
Xcode	選択パス、Scheme、依存関係ログ	Scheme不在、依存関係解決失敗
ビルド	`xcodebuild`の終了ステータス、ログ	非ゼロ終了、署名要求が想定外に発生
テスト	`.xcresult`、テスト概要、Simulator識別子	結果ファイルなし、テストが未実行
回収	Artifact名、Job ID、実行時刻	ログ欠落、別Jobの結果を参照

Simulatorと画面操作の切り分け

純粋なコマンドラインビルド、Simulatorテスト、画面ログインを必要とするUI操作は、同じ前提で扱えません。Simulatorの起動を確認できても、実機テストやすべてのUI自動化を無人運用できる証明にはなりません。

Simulatorを使う場合は、起動したデバイスの識別子、テスト対象、結果パッケージ、Job切断後の状態を記録します。テストの自動化と結果回収は、AppleのXcodeテスト自動化資料で対応範囲を確認してください。

長時間の画面操作をVNCに依存すると、ログインセッション、画面ロック、スリープ、接続断が停止要因になります。コマンドラインで完結する処理はSSHまたはRunnerプロセスで実行し、GUIが必要な処理だけを別の受入条件に分けます。

外部Pull Requestと署名資産

外部PR、ワークフローファイルを変更できるブランチ、未審査スクリプトを、配布証明書や秘密鍵が存在するRunnerで実行してはいけません。Claude Codeがコードを変更できても、iOS署名証明書、キーチェーン、プロビジョニングプロファイル、配布トークンへ自動的にアクセスさせる設計にはしません。

通常の検証は、署名なしビルドまたはテスト用の限定資格情報で行います。アーカイブが必要な場合は、保護ブランチ、専用Runner Group、環境承認、読み取り専用入力を組み合わせます。Appleの署名済みコード作成資料も確認し、署名工程をAgentの変更工程から分離します。

この条件分岐で運用を決めてください。

外部PRである場合：共有Mac Runnerではなく、署名資産を持たない検証用Runnerへ送ります。
ワークフロー変更を含む場合：自動実行を止め、内容をレビューしてから再実行します。
内部の保護ブランチである場合：専用Runner Groupと環境承認を経て、限定されたアーカイブJobだけを許可します。
証明書やトークンを使う必要がない場合：署名なしビルドへ戻します。
Runnerの隔離を証明できない場合：公開用アーカイブを実行せず、開発用Macでの検証に限定します。

GitHubも、自己管理Runnerでは実行コードの信頼境界を確認するよう説明しています。GitHub Actionsの安全な利用ガイドを、リポジトリの権限レビューと一緒に確認してください。

複数リポジトリと再起動復旧

複数リポジトリで1台のMacを共有する場合、Runner Group、ラベル、OSユーザー、作業ディレクトリを信頼レベルごとに分けます。前のJobのソース、キャッシュ、SSH鍵、環境変数が次のJobへ残らないよう、開始時と終了時の記録を保存します。

長期稼働Runnerは管理しやすい反面、残留ファイルと権限の蓄積が問題になります。単一Jobごとの隔離は安全性を高めやすい一方、MacではコンテナRunnerのように環境を即時廃棄できない部分があります。

運用方式	向いている用途	必須の確認
長期Runner	開発チームの反復ビルド	更新、作業領域の消去、Runnerユーザー権限
Job単位の隔離	外部PRや信頼度の低い検証	作業領域、資格情報、ログの分離
専用公開Runner	承認済みリリース	保護ブランチ、環境承認、監査ログ

再起動後は、Runnerプロセスの起動、対象ラベル、通信、作業ユーザー、Xcode選択、Simulator利用可否を順に確認します。失敗Jobを再キューする前に、元のCommit SHA、Job ID、作業ディレクトリ、清掃結果を保存してください。Runnerの更新と運用上の確認事項は、GitHubの自己管理Runner運用資料に沿って確認します。

最後に、IssueからAgent変更、Macビルド、結果回収、Mac再起動、再実行までを同じ検証プロジェクトで通します。開発試用なら署名なしで実行、チーム共有ならRunner Groupと清掃記録を必須化、製品公開なら独立Runnerと手動承認が揃うまで制限運用にします。

リモートMacを選ぶ判断

Linuxの汎用Runnerだけでは、Xcode、Apple SDK、Simulator、署名工程を同じ条件で再現できません。逆に、すべてのAgent処理をMacへ集約すると、外部入力とApple資産の境界が曖昧になります。

自前のMac miniは長期稼働や物理ポートが必要な場合に向きますが、初期調達、設置、故障時の交換、再起動試験を自分で負担します。短期の試行やチームの受入検証では、MACCOMEのMac環境のように、管理権限を持つリモートMacをまず分離環境として使い、実プロジェクトでログ回収と復旧を確認する方法が現実的です。長期運用で物理機を比較する場合は、Mac miniの運用案内も判断材料になります。

現在のLinux Runnerや共有Mac方式には、Appleツールチェーンを実行できない、GUIセッションの状態を管理しにくい、他プロジェクトの残留物が混ざるという欠点があります。そこで、Claude Codeの改修とXcode検証を分離でき、再起動確認と権限調整を自分で行える一台を先にレンタルして非生産環境で試すのが安全です。実ビルド、ログ返却、署名境界が通った後にだけ、利用期間や公開用の独立ノードを決めてください。