Cursor Background Agent は Xcode を実行できる？2026年リモートMacの構成

📋 目次

症状： Background AgentがiOSコードを変更してコミットしたのに、XcodeビルドとSimulator検証だけが完了しません。
最短解： AgentはUbuntu上の改碼・一般検査に限定し、Xcode、Simulator、署名はリモートMacの実行層へ渡してください。

Cursor公式ドキュメントでは、Background Agentの既定環境は隔離されたUbuntu環境として説明されています。公式の環境説明から判断すると、Cursor Background Agent Xcodeを同じ実行環境で完結させる構成は前提にできません。

このページは、WindowsまたはLinuxを主力にしてiOS開発を行うエンジニア、Agent導入後もXcode検証で止まっているモバイルチーム、そしてAgentとMacの権限境界を設計するDevOps・開発基盤担当者向けです。

最終更新：2026年9月11日。Cursor Background Agent、Cursor CLI、Xcodeのコマンドラインツールに関する公式資料を再確認しています。

Background AgentとXcodeを同じ箱で扱わない

Background Agentは、リポジトリの取得、コード変更、一般的なコマンド実行に向いています。たとえば依存関係の確認、フォーマッター、静的解析、設定ファイルの編集、クロスプラットフォームのテストはUbuntu側に置けます。

しかし、コードが変更できたことは、Appleプラットフォームで検証できたことを意味しません。XcodeのSDK、Simulator、XCTest、Swift Testing、Appleの署名ツールが存在しなければ、iOSアプリのビルド結果を確定できないためです。

ここでLinux環境にXcodeらしいコマンド名だけを追加しても解決しません。AppleのXcodeコマンドラインツールのリファレンスが示すように、xcodebuildなどは有効なXcode環境の選択とインストール状態に依存します。

Agentだけで完了させる作業

次の範囲なら、Background Agentに残しても運用上の説明がつきます。

ソースコード、テストコード、設定ファイルの変更
フォーマット、静的解析、依存関係の整合性確認
APIクライアントや共通ライブラリのクロスプラットフォーム検査
ビルドを伴わないドキュメント更新
変更差分、コミットメッセージ、レビュー用要約の作成

反対に、iOS SDKを使うコンパイル、Simulator起動、XCTestの結果判定、アーカイブ、署名、アップロードはMac側へ移します。

第一段階：改碼層と実行層を分ける

最も復旧しやすいのは、AgentとMacを別ノードにする二層構成です。Agentは独立ブランチまたはコミットを作成し、Macはその識別子を受け取って検証します。

交接時に残すべき情報は、次の4点です。

リポジトリの識別子と対象ブランチ
検証対象のコミットハッシュ
Scheme、構成、実行したコマンド
ビルドログ、テスト結果、生成物の保存先

Mac側では、固定したスクリプトからxcodebuildを実行します。Agentに「ビルドは成功した」と報告させるだけでは不十分です。Mac側の終了コード、ログ、生成物の存在、対象コミットが一致して初めて、検証済みとして扱います。

この分離は、物理Macと仮想macOSの違いを検討するときにも重要です。Xcodeの実行可否だけでなく、再現可能な環境、権限分離、失敗後の復旧方法まで比較してください。

第二段階：通用検査とSimulator検証を分ける

iOS自動化では、すべてをMacへ送る必要はありません。Ubuntu側で早く失敗させられる検査と、Apple環境でしか成立しない検査を分けると、Macノードの占有を抑えられます。

Ubuntu側に置く検査

フォーマットと静的解析
シェルスクリプトや生成コードの検査
サーバー側ロジックの単体テスト
API仕様やJSON変換の検査
変更差分と依存関係の確認

リモートMac側に置く検査

xcodebuildによるコンパイル
Simulator上の起動と画面遷移
XCTestおよびSwift Testing
Apple SDKに依存する単体テスト
アーカイブと署名の前段階

Appleのテスト結果の解釈に関する資料に沿って、Mac側では結果バンドルを保存してください。失敗したテスト名だけでなく、xcresult、標準出力、クラッシュ情報、失敗時の添付ファイルをAgentへ戻すと、次の修正が推測に頼りにくくなります。

Simulatorで成功しても、実機での動作を全面的に代替できるわけではありません。AppleのSimulatorと実機でアプリを実行する説明を基準に、カメラ、通知、Bluetooth、性能、実機固有の権限を含む項目は別の実機確認として扱います。

Cursor CLIをMacへ置く場合の境界

Cursor CLIは、リモートMac上でAgentの変更後に直ちにxcodebuildを呼び出したい場合に候補になります。CursorのCLI導入資料と非対話的な利用方法を確認し、まずは専用の検証ノードで小さなリポジトリから試してください。

同一Mac上で変更とビルドを続ける構成には、文脈が切れにくい利点があります。一方で、変更権限とビルド権限が同じホストに集まり、無限ループ、不要なファイル変更、ディスク消費、秘密情報への接触範囲が広がります。

本番の共有ビルドノードへ、CLIをそのまま置くのは避けてください。リポジトリの作業ディレクトリ、許可するコマンド、ネットワーク接続先、同時実行数、停止条件を先に固定します。CursorのCloud Agentセキュリティ資料が扱う隔離や権限の考え方も、Mac側の設計を確認する材料になります。

第三段階：署名と配布はさらに別の権限へ分離する

ビルドと配布を同じ自動化権限で扱うと、失敗時の被害範囲が大きくなります。次のように権限を段階化してください。

低権限： コード変更、静的解析、通常のビルド
中権限： Simulatorテスト、アーカイブ生成、検証用署名
高権限：配布用署名、ストアへのアップロード、リリース操作

Agentには低権限の変更と検証ジョブの起動だけを許可し、高権限の証明書、キーチェーン、配布トークンは直接見せない構成が安全です。Appleの配布用署名コードに関する資料でも、配布署名は通常の実行確認とは異なる工程として扱われています。

固定スクリプトまたは保護されたパイプラインが、検証済みコミットだけを受け取って署名します。人の承認、監査ログ、失敗時の停止条件を設け、Agentの文章出力を承認根拠にしないでください。

失敗しても戻せる実行手順

本番リポジトリへ接続する前に、破棄可能なブランチで次の順に確認します。

[ ] Agent用の作業ブランチとMac側の検証ブランチを分ける
[ ] Agentが作成したコミットハッシュを自動記録する
[ ] Mac側で対象ハッシュを取得し、別の変更がないことを確認する
[ ] 固定スクリプトからSchemeと構成を指定してxcodebuildを実行する
[ ] xcresult、ログ、生成物、終了コードを保存する
[ ] 失敗時の添付ファイルをAgentが読める場所へ戻す
[ ] 署名なしの検証を先に通し、署名権限は後から追加する
[ ] タイムアウト、ディスク上限、ネットワーク先、停止担当者を決める
[ ] ノードを初期化または復元し、次のジョブを受けられる状態に戻す

この手順で重要なのは、Agentの修正能力を評価する前に、証拠の受け渡しを検証することです。ログが欠ける構成では、成功しても再現できず、失敗しても修正箇所を特定できません。

どの構成を選ぶか：分離運用と同機運用

構成	Agentの担当	Macの担当	強み	主なリスク	適した用途
Background Agentのみ	改碼、一般検査	なし	隔離しやすく、Apple環境の秘密情報を持たせない	Xcode検証が完了しない	共通コード、設定変更、レビュー準備
二ノード構成	改碼、静的解析、結果に基づく修正	ビルド、Simulator、テスト	権限と責任範囲を分けやすい	証跡の受け渡しを設計する必要がある	通常のiOS開発とCI
受 नियंत्रされたMac上のCursor CLI	改碼と検証の連続実行	同一ノードでXcode実行	文脈を保ちやすく、試行が速い	書き込み権限と秘密情報が集中する	破棄可能な実験ノード
二軌道構成	改碼と検証ジョブの起動	検証と保護済み配布	高リスク操作を隔離できる	パイプライン設計が複雑になる	チームの継続的リリース

Macを常時使うか、短期間だけ借りるかは、作業時間と復旧要件で決めます。Mac miniレンタルの選び方を確認するときも、単純な月額比較ではなく、稼働時間、SSH接続、再起動、初期化、ログ回収の条件を確認してください。

判断の目安は明確です。Appleツールチェーンが不要ならBackground Agent単体、XcodeやSimulatorが必要なら二ノード、同じMac上で即時反復したいなら制限付きCursor CLI、配布まで自動化するなら二軌道構成を選びます。

FAQ

Cursor Background AgentでiOSプロジェクトをビルドできますか？

コード変更や一般的な静的検査はBackground Agentで進められますが、標準の隔離環境はUbuntuです。そのため、Xcode、Simulator、Apple SDKを使うiOSビルドは完了できません。Agentが作成したコミットをリモートMacへ渡し、xcodebuildで実際の検証を行う構成にしてください。

CursorからリモートMacのXcodeを呼び出すにはどうしますか？

CursorからXcodeを直接呼び出す専用機能として扱うのではなく、Agentがブランチまたはコミットを作成し、Mac側の固定スクリプトやCIジョブが取得してxcodebuildを実行します。ビルドログ、コミットハッシュ、xcresultを返せば、Agentは結果を読んで修正を続けられます。

Cursor CLIはmacOSのビルドノードで動かせますか？

Cursor公式資料では、Cursor CLIはmacOSへの導入と非対話的な利用に対応しています。ただし、Mac上でCLIを動かせることと、無制限に証明書やリリース鍵へアクセスさせることは別問題です。まずは破棄可能な検証ノードで、対象リポジトリと許可コマンドを限定してください。

AI Agentが変更したiOSコードを自動テストするには？

Ubuntu側ではフォーマット、静的解析、クロスプラットフォームの単体テストを実行し、XCTest、Swift Testing、Simulatorを使う検査はMac側へ分離します。Macではxcresult、テストログ、失敗時の添付ファイルを保存し、Agentには文章だけでなく検証ファイルそのものを渡してください。

Cursor Background AgentとリモートMacはどう分担すべきですか？

Background Agentはコード変更と一般的な検査、リモートMacはXcodeビルド、Simulator検証、必要な実機確認を担当させます。署名と配布はさらに保護されたジョブへ分離し、Agentには起動権限だけを与えるのが安全です。同機構成は、十分に制限した試験ノードでのみ採用してください。

結論：未検証のコードに署名権限を渡さない

LinuxやWindowsを中心にした現在の構成では、Cursor Background Agentは改碼層として有効ですが、Xcodeを含むAppleツールチェーンの代替にはなりません。Agentの変更をリモートMacへ渡し、コミット、xcodebuildの終了結果、xcresult、生成物を照合する二ノード構成が、最初に試すべき境界です。

既存の作業が「コードは変更できたがXcodeで検証できない」で止まっているなら、まず破棄可能なブランチをMacで動かしてください。Linuxの実行環境だけではApple SDK、Simulator、署名を扱えず、ローカルMacの購入では初期費用、保守、常時稼働の管理が増えます。短期の検証や一時的なビルドノードには、MacDateのリモートMacを使い、署名権限を開放する前に実際のリポジトリで復旧手順まで確認するのが現実的です。