OpenCodeのコマンドはプロジェクトの実行環境で動きます。SSHでリモートMacに接続できても、Agentの作業場所やコマンド実行先は自動でMacに切り替わりません。Xcodeを使うには、OpenCodeの作業環境をMac上に置くか、SSH経由の遠隔実行を明示し、ファイル変更・ビルド・テスト結果を個別に確かめてください。

今週は、まずpwdとgit rev-parse HEADで実行場所とコミットを特定し、その後にxcodebuildとテスト結果の保存先を確認してください。

WindowsまたはLinuxを主な開発機にしていて、iOSやmacOSアプリをビルドするエンジニア向けです。
リモートMacでmacOS CIを保守するDevOps担当者は、Agentの作業環境とビルドノードの責任範囲を切り分けられます。
OpenCodeをAppleのツールチェーンにつなぐ技術責任者は、権限と受け入れ証拠の設計に役立ててください。

最終更新：2026年10月24日。OpenCode公式の変更履歴とツール文書、Apple公式のXcode・テスト文書を確認しています。
OpenCodeのバージョンや公式仕様は更新されるため、導入時には公式変更履歴も確認してください。

01

OpenCode 2.0とリモートMacのXcodeで、最初に実行ホストを切り分ける

「SSHではMacに入れるのに、OpenCodeのAgentが呼ぶコマンドは手元のLinuxで失敗する」。この症状では、SSHの接続確認とAgentのコマンド実行先を別の問題として扱います。OpenCodeのツール文書では、bashツールがプロジェクトの実行環境で動くことが説明されています。SSH接続が確立したという事実だけから、AgentのコマンドもMacで動いているとは判断できません。

まず、OpenCodeのターミナルツールで次を実行します。

pwd
hostname
git rev-parse HEAD

表示されたホスト名とディレクトリが、意図したリモートMac上の作業領域か確認してください。hostnameが手元のPCを示すなら、OpenCodeのコマンド実行はまだローカルです。OpenCodeの権限設定でツール利用を許可していても、それだけで実行ホストが変わるわけではありません。設定の意味はOpenCodeの権限文書で確認できます。

02

症状から選ぶ実行方式

選択肢を比べるときは、「SSHが使えるか」ではなく、Agentが読むファイルとXcodeがビルドするファイルが同じかを基準にします。

選択肢 Agentが読む場所・コマンド実行先 主な利点 注意点と判断基準
ローカルでOpenCodeを実行 手元のWindowsまたはLinux 既存の編集環境を変えずに使えます 手元の実行環境にXcodeがなければ、Apple向けビルドをローカルで完結できません
SSHでログインできる状態にする OpenCodeは手元、SSHは別途接続 接続確認と手作業の遠隔操作を分けられます SSH接続だけではAgentのコマンド転送になりません
リモートMacの作業領域でOpenCodeを実行 ファイル操作とコマンドがMac上 同じMac上のXcodeと作業コピーを使いやすくなります Mac上のアカウント、作業ディレクトリ、権限をそろえる必要があります
SSH経由でコマンドを明示実行 Agentは手元、指定した処理はMac上 既存のAgent環境を保ちながら遠隔ビルドできます パス、引用符、終了状態、成果物の受け渡しを明示しないと検証が崩れます

ローカル編集と遠隔ビルドを分ける構成では、変更ファイルの転送漏れや、別々の作業コピーをビルドする事故に注意します。頻繁に差分がずれるなら、OpenCodeの作業領域をリモートMac側に置くほうが確認しやすくなります。

03

プロジェクトのコピー違いとツールチェーンを調べる

Agentが意図しないファイルを編集したように見える場合は、ローカルとMacのリポジトリを同一視しないでください。両方の環境でpwd、git rev-parse HEAD、git status --shortを実行し、作業ディレクトリ、コミット、未コミット変更を照合します。ディレクトリ名が同じでも、別のクローンなら変更内容は同期されません。

次に、OpenCode自身から実行される環境でXcodeのコマンドを確かめます。

command -v xcodebuild
xcode-select -p
xcodebuild -version

確認対象は、コマンドの場所、選択中の開発者ディレクトリ、実際に表示されるツール情報です。対話型SSHシェルで成功しても、OpenCodeが別ユーザーや別シェル環境から実行されていれば同じ結果になるとは限りません。Appleのコマンドラインツールのインストール文書とXcodeコマンドラインツールのリファレンスを参照し、Mac上で選択されている開発環境を確認してください。

04

権限とテスト対象を分けて確認する

プロジェクトを読めること、依存関係を取得できること、署名できること、OpenCodeがファイルを編集できることは別々の権限です。エラーが出たら、ログから不足している対象を特定してから、その作業に必要な範囲だけを許可します。リポジトリ全体の権限を広げたり、資格情報をプロジェクトに直接書き込んだりするのは避けてください。

署名エラーを見て、すぐにAgentのファイル編集権限を広げないでください。エラーが示すのがKeychain、秘密鍵、依存関係へのアクセスなら、変更すべき権限は別の場所です。

ビルドが通っても、Simulatorでテストできるとは限りません。scheme、destination、必要なSimulatorランタイムが、対象プロジェクトと一致するかを調べます。AppleのSimulatorまたは実機でアプリを実行する文書で実行先を確認し、一覧に対象がなければ、Agentの失敗と決めつけず、Mac側の利用可能な環境を調査します。

よくある質問

OpenCodeのbashコマンドは、手元とリモートMacのどちらで動きますか？

OpenCodeのプロジェクト実行環境で動きます。SSHでMacにログインできても、作業ディレクトリやコマンドの実行先は自動で切り替わりません。実行ホストでpwdを確認し、リモートMac上で実行する設計にするか、SSH経由の実行を明示してください。

リモートMac上のプロジェクトをOpenCodeから使うには何を合わせますか？

OpenCodeが読む作業ディレクトリと、Mac上でビルドするリポジトリをそろえます。両側でコミットIDと未コミット変更を確認し、Agentが編集したファイルがビルド対象に反映されたことまで確かめます。フォルダー名が同じというだけでは、同じコピーとは言えません。

SSH接続はできるのに、xcodebuildが見つからないときは？

まずコマンドが動いているホストとユーザーを確認します。次にMac上の同じアカウントでcommand -v xcodebuildとxcode-select -pを実行し、コマンドの場所と選択中の開発者ディレクトリを調べます。手動のSSHセッションで見つかっただけでは、OpenCodeの環境にも設定済みとは限りません。

テストの成功後、結果が保存されたことをどう確かめますか？

終了状態だけでなく、テスト実行時に指定した結果バンドルの保存先を確認します。CIではその保存先が成果物収集の対象かも調べてください。同じコミットで再実行し、結果バンドルを開けることまで確認します。Appleのテスト実行と結果の解釈に関する文書も参照してください。

05

5段階で修正と受け入れを確認する

  1. 実行ホストを特定します。 OpenCodeのターミナルからpwdとhostnameを実行し、作業場所が手元かMacかを記録します。
  2. リポジトリを照合します。 各環境でコミットIDと変更状態を取得します。OpenCodeが触ったファイルと、ビルド対象のファイルが一致しているか確認します。
  3. Macのツールチェーンを調べます。 OpenCodeから実行されるアカウントでcommand -v xcodebuildとxcode-select -pを実行します。必要ならAppleの案内に従ってコマンドラインツールと選択中のXcodeを確認します。
  4. 権限とテスト先を限定します。 ログから依存関係、署名、Keychain、ファイル編集のどこで失敗したかを切り分けます。schemeとdestination、Simulatorの利用可否も別に確認します。
  5. 結果を保存して再確認します。 テストを実行し、終了状態、結果バンドルの場所、CI成果物への収集を記録します。同じコミットで再実行し、保存された結果を開けることを受け入れ条件にします。

xcodebuildの終了状態が成功でも、テスト結果の保存や成果物収集まで完了したとは限りません。Appleはテスト結果を確認する手順を公式のテスト文書で説明しています。実行の成功と、結果を後から検証できる状態を分けて扱ってください。

06

問題が残るなら、実行場所を変えるか構成を見直す

原因がOpenCodeのローカル実行環境にAppleのツールチェーンがないことなら、WindowsやLinuxだけでXcodeビルドを完結させる構成は適しません。手元とMacでプロジェクトのコピーが分かれる、SSH先で利用する環境を毎回確認する、テスト結果の受け渡しを別途管理するといった運用上の負担も残ります。一方、すでにMacを保有し、常時アクセスできるなら、手元の構成を調整するほうが適切な場合もあります。自前のノードを用意する案を比べるなら、Mac miniの構成を検討するための案内も確認できます。

XcodeとmacOS CIを継続して使う必要があり、手元にAppleのツールチェーンを用意できないなら、リモートMacを実行ノードとして使う方法を検討できます。まずはVpsMeshのMac利用案内で利用形態を確認し、必要な期間だけリモート環境を使う選択肢と、自分でMacを用意する方法を比べてください。ビルド性能や費用はプロジェクトと利用条件によって変わるため、本文の切り分け結果をもとに判断するのが安全です。