Agentの作業は完了するのに、後続のXcodeビルドをmacOS Runnerで実行できない。
最短の解決策は、Agent処理を対応するLinux Runnerで行い、Xcodeのビルドとテストは独立した通常のGitHub Actions macOSジョブへ渡すことです。
gh-awを使ったリポジトリー自動化を、Xcode作業まで任せられるか判断したいエンジニア向けです。AppleプラットフォームのCIを運用する開発者や、Linux AgentとMac Runnerの権限境界を設計する担当者にも役立ちます。
最終更新日：2026年10月25日。GitHub Agentic WorkflowsとGitHub Actionsの公式資料で、Runnerの対応状況、イベント、成果物、セキュリティ上の注意点を確認しました。
SECTION 01最初に押さえる実行環境の境界
GitHub Agentic WorkflowsのAgentジョブは、macOS Runnerでは実行できません。公式FAQが説明する理由は、Agent Workflow Firewallが必要とするコンテナジョブをmacOS Runnerで実行できないためです。macOS専用ツールを使う処理は、別の通常のGitHub Actionsジョブに分けるよう案内されています。公式FAQのmacOS Runnerに関する説明とワークフローの仕組みを先に確認してください。
ここで混同しやすいのが、CLIをインストールする端末、Agentワークフローの実行環境、Xcodeを実行する環境です。CLIの導入先を見て、AgentジョブもmacOS上で動くと判断してはいけません。Runnerの設定とAgentジョブの実行制約は、frontmatterの公式リファレンスで分けて確認します。
なぜGitHub Agentic WorkflowsはmacOS Runnerに対応していないのですか。
Agent Workflow Firewallが前提とするコンテナジョブをmacOS Runner上で利用できないためです。Xcodeが必要な作業をAgentジョブへ追加して回避するのではなく、Agent処理とmacOS専用処理の境界を設計します。
| 選択肢 | 担当する作業 | 選ぶ条件・注意点 |
|---|---|---|
| Linux上のAgentワークフロー | リポジトリーの調査、変更案の作成、メタデータやパッチの出力 | Xcodeを直接実行しない。生成物と対象コミットを明示する |
| 通常のGitHub Actions macOSジョブ | Xcodeによるビルド、テスト、Appleプラットフォーム固有の検証 | Agentジョブとは別に定義し、上流の実行結果と入力を検証する |
| Agentを使わない通常のMac CI | 既存のビルド・テスト経路 | Agentによる変更処理が不要、または安全に分離できない場合 |
SECTION 02準備段階：受け渡す情報を決める
Agentに任せるのは、リポジトリーの解析や自動変更など、Xcodeなしで完結する作業です。Xcodeでのビルド、テスト、署名などはmacOS側に残します。変更とビルドをひとつの曖昧な処理にまとめると、何をどのコードで検証したか追えなくなります。
先に、Agentが出力しMacジョブが受け取る情報を決めます。最低限、対象のコミットSHA、作業ブランチ、上流ワークフローの実行ID、成果物名、上流の結論を記録します。ブランチ名だけで受け渡すと、そのブランチが更新された後に別のコミットをビルドするおそれがあります。
GitHub Agentic WorkflowsからXcodeビルドへ、どのように作業を渡しますか。
同一ワークフロー内ならジョブの依存関係を定義し、必要に応じてActionsの成果物を使います。別ワークフローなら、上流の実行完了を契機に後続処理を動かし、実行IDとコミットSHAを照合してからビルドします。
SECTION 03初回試行：LinuxでAgent側を確かめる
まず、公式手順に沿ってワークフロー定義を確認し、コンパイル後のロックファイル、選んだAgentエンジン、認証情報を検証します。必要な権限は用途に絞り、秘密情報をどの処理が使うかも記録します。実行方法や設定項目は、GitHub Agentic Workflowsの仕組みと設定資料を基準にしてください。
初回は、Xcodeを呼ばない小さなリポジトリー作業で試します。トリガー、Agentの出力、権限、ログが想定どおりかを見て、結果とコミットSHAを後続Macジョブの入力基準として保存します。ここで失敗する場合、Xcode側に進む前にAgentの設定を直します。
SECTION 04接続段階：通常のMac CIへ引き継ぐ
通常のGitHub Actions macOS Runnerで動くビルド・テスト用ワークフローを、Agentワークフローとは別に用意します。たとえば、同一ワークフロー内でAgent相当の準備後にXcodeジョブを依存させる構成と、完了イベントを使って後続ワークフローを起動する構成があります。後者では、トリガー条件の設定だけでなく、どの上流実行の入力を取得するかが重要です。
gh-awとGitHub ActionsのmacOSワークフロー間で、成果物をどう渡しますか。
同一ワークフローならActionsの成果物を保存して後続ジョブで取得できます。公式の保存・共有ガイドを参照してください。ワークフローをまたぐ場合は、download-artifactの仕様を確認し、対象の実行IDや認証方法を明示して成果物を取得します。
SECTION 05引き継ぎ段階：上流の実行と権限を検証する
workflow_runは、指定した上流ワークフローの完了後に別ワークフローを起動するイベントです。イベントの対象やブランチ条件には制約があるため、GitHub Actionsのイベント資料で起動条件を確認します。後続ワークフローが既定ブランチ側の定義で実行される場合があるため、「同じブランチ名だから同じコード」とはみなさず、SHAを照合してください。
workflow_runでMacビルドを起動するとき、上流コミットはどう確認しますか。
上流の実行IDから対象ワークフローと成果物を特定し、成果物に記録したSHA、ブランチ、実行結果を取得します。そのSHAがビルド対象と一致し、上流が許可した結論で終わっていることを確かめてからXcodeジョブへ進めます。
注意：
workflow_runで起動する後続ワークフローは、上流より強い権限や秘密情報を利用できる場合があります。信頼できないコードが作った成果物を無検証で実行したり、資格情報を渡したりしないでください。GitHub Actionsのセキュリティガイドに沿って、権限を最小化し、入力の検証と信頼境界を明示します。
SECTION 06受け入れ段階：実プロジェクトで採用可否を決める
本番相当のリポジトリーで、Agentの変更からXcodeビルド・テスト、結果の記録までを一続きに試します。失敗時に後続処理が止まること、ビルド結果が正しいコミットと結び付くこと、不要な権限が付与されないことを確認してください。
試行結果に応じて、構成を選びます。
- Agentの出力とMac CIの入力を検証できるなら、Linux AgentとMac CIを分けて採用します。
- Agentによる自動変更が不要なら、通常のMac CIだけを維持します。
- SHAや権限の検証が不十分なら、対象範囲を絞った試行を続け、本番の資格情報を接続しません。
Linuxだけの構成ではXcodeを実行できず、AgentジョブをmacOS Runnerに置く方法も使えません。さらに、ワークフローをまたぐ成果物はコミットの取り違えや権限の拡大を招かない設計が必要です。Xcodeを実行する環境が不足している場合は、実際に必要なツールチェーン、接続方式、受け渡し方法を先に確定し、MACNOXの案内で利用条件を確認してください。料金や実行環境の適合性はプロジェクト要件と照らし、料金情報を見たうえで判断します。短期の検証環境が必要なら、確認できた条件に基づいてリモートMacの利用を検討し、恒常的な高負荷運用や物理接続が必須の場合は、自前のMacを含めて比較してください。