Codex AppからSSH接続したMacでは、接続できてもiOSアプリをビルドできないことがあります。 まずSSH認証、プロジェクトの読み書き、Xcodeビルドを順に分け、最初に失敗した箇所を直してください。ビルド成功後も、シミュレーター、署名、アップロードは別々に確認します。
対象は、WindowsやLinuxで開発し、Codex AppからリモートMacへ作業を依頼したい独立開発者です。 SSH接続後にプロジェクトが見つからない小規模チームや、遠隔環境がテスト・公開まで担えるか判断したい方にも向いています。
最終更新：2026年10月7日。Codex AppのSSH機能の公開説明と、AppleのXcodeおよびコマンドラインツール資料を確認しています。機能の提供範囲や画面操作は更新されるため、利用中のバージョンの公式説明も照合してください。
まず失敗した段階を記録する
エラーの最終行だけで判断せず、どこまで処理が進んだかを記録します。次の順で確認すると、SSHの問題をXcodeや署名の問題と取り違えにくくなります。
| 確認段階 | 観察できる証拠 | 次の判断 |
|---|---|---|
| Codex Appが接続先を認識 | 接続先が選択可能か、SSH接続が開始されるか | 接続先が表示されないなら、機能の利用条件とアプリ側の接続設定を確認 |
| SSH認証 | 独立したSSHクライアントで同じ接続先へログインできるか | 失敗するなら、Mac側ではなくホスト名、ユーザー、鍵、ログイン許可を調査 |
| プロジェクトアクセス | 想定したリポジトリとブランチを読み書きできるか | 違うディレクトリやユーザーなら、作業場所と権限を修正 |
| Xcodeビルド | xcodebuildが対象プロジェクトを処理し、ビルド結果を返すか | 失敗するなら、開発者ディレクトリ、Xcode、依存関係、Schemeを確認 |
| テスト・公開 | シミュレーター実行、署名、Archive、アップロードが個別に完了するか | ビルド成功だけで公開可能と判断せず、目的の工程を別途検証 |
SSH認証と接続先を切り分ける
Codex AppからSSHでリモートMacへ接続する前に、何を確認しますか。
まず、ホスト名または接続先、SSHユーザー、ネットワーク経路、選択した秘密鍵が一致しているかを確認します。そのうえで、Codex Appとは別のSSHクライアントから同じ条件でログインし、認証エラーとアプリ側の接続エラーを切り分けてください。
別クライアントでも接続できない場合は、Mac側でSSHログインが許可されているか、該当ユーザーが正しいかを管理者に確認します。接続先の設定が正しくても、アカウントにログイン権限がなければ作業には進めません。
SSHクライアントでは接続できるのにCodex Appでは失敗するなら、Appが参照している接続先や鍵と、手動接続時の条件を一つずつ照合します。Appの画面や対応範囲はバージョンによって異なる可能性があるため、確認できない設定名を前提に操作を進めないでください。ログや画面共有を使って相談するときは、ユーザー名、ホスト名、IPアドレス、鍵の内容を伏せてください。認証を通すためにホスト検証を無効化したり、必要以上にログイン権限を広げたりするのは、標準の修正手段にしないでください。
接続後のプロジェクト位置と書き込み権限を確かめる
SSHでログインできても、Agentが期待したリポジトリを見つけて変更を保存できるとは限りません。リモートMacで実際のユーザーを確認し、リポジトリの場所、ブランチ、作業ツリーを照合します。
whoami
pwd
git rev-parse --show-toplevel
git status --short --branch各コマンドの結果が想定と異なる場合は、その状態を記録してから正しい作業ディレクトリへ移動してください。作業前後にgit statusを比較すれば、Codex Appの変更が意図したプロジェクトに反映されたかも確認できます。
SSH接続は成功したのに、iOSプロジェクトをCodex Appが見つけない場合はどうしますか。
リモートMac上にあるリポジトリの絶対パスと、Codex Appが処理対象としている場所を照合します。別ユーザーのホームディレクトリにチェックアウトされている、読み取り専用になっている、想定と違うブランチを開いている、といった不一致があれば、権限をむやみに変更せず、正しいユーザーとプロジェクトで再確認してください。
作業前に未コミットの変更がある場合は、その内容も記録します。これにより、Agentが変更を保存できない問題と、既存の変更やブランチ状態による混乱を分けて調査できます。
Xcodeの実体とコマンドライン設定を照合する
SSHでコマンドを実行できても、そのMacに対象プロジェクトに適したXcodeがあるとは限りません。AppleのXcodeシステム要件で、利用するXcodeリリースがリモートMacのmacOSに対応しているか確認してください。
リモートMacで、実際に呼び出される開発者ディレクトリとツールの状態を確認します。
xcode-select -p
xcodebuild -version
xcodebuild -showsdksxcode-select -pが想定外の場所を返す場合は、アクティブな開発者ディレクトリが別のXcodeまたはコマンドラインツールを指している可能性があります。xcodebuildが利用できない、または必要なSDKが表示されない場合は、設定とインストール状態を分けて調査してください。
Appleの資料では、コマンドラインツールのインストールと、使用するコマンドラインツールの設定が別に説明されています。コマンドラインツールがインストール済みというだけで、完全なXcode環境や対象プロジェクトのビルド要件まで満たしたとは判断できません。Appleのコマンドラインツールリファレンスも参照し、実際のビルドコマンドが使う設定を確かめてください。
ビルド、シミュレーター、署名、アップロードを分けて検証する
同じiOS開発でも、コマンドラインビルド、シミュレーターでの実行、実機テスト、Archive、アップロードは別の工程です。まず対象のSchemeとdestinationを明示してビルドを行い、その後に必要な試験だけを追加してください。
リモートMacでXcodeプロジェクトはビルドできるのに、シミュレーターを起動できないことはありますか。
あります。ビルドの成功から、必要なSimulator Runtimeの導入や起動、GUIを伴う操作までが可能だとは判断できません。対象デバイスでの実行が必要なら、Appleのシミュレーターまたは実機でアプリを実行する手順を基準に、必要なランタイムと実行経路を別に確かめてください。
署名条件も公開の成否を左右します。Archiveで使う署名ID、Provisioning Profile、Bundle ID、チーム設定に加え、秘密鍵や開発者アカウントへのアクセス権が実行ユーザーにあるかを確認します。チームで証明書を扱う場合は、Appleの署名証明書の共有に関する説明を参照し、資格情報をログやソース管理へ保存しない運用にしてください。
アップロードまで必要なら、Archiveの成功とApp Store Connectへの提出成功を分けて記録します。Appleの登録済みデバイスへのアプリ配布資料は実機配布の確認に、ビルドのアップロード手順はApp Store Connectへの提出確認に使えます。目的の工程が完了した証拠を残し、通常ビルドの成功をもって公開準備完了としないでください。
条件に合わせて次の確認先を選ぶ
- SSHクライアントでも接続できない場合：ホスト名、ネットワーク、ユーザー、鍵、サーバー側のログイン許可を確認します。ここが直るまでXcodeの調査に進みません。
- SSHは通るがプロジェクトを読めない、保存できない場合：実行ユーザー、リポジトリの場所、ブランチ、ディレクトリ権限を確認します。作業前後のGit状態で、変更先を検証してください。
- プロジェクトにはアクセスできるがビルドできない場合：macOSとXcodeの互換性、アクティブな開発者ディレクトリ、SDK、Scheme、依存関係を確認します。
- ビルドは通るがシミュレーターや実機で試せない場合：必要なランタイム、GUIセッション、実機へのアクセスを個別に検証します。要件が確認できない環境では、対応済みと判断しません。
- Archiveはできてもアップロードできない場合：署名、資格情報、App Store Connect側の処理を切り分けます。エラーと工程を記録し、必要な権限だけを見直してください。
現在の作業環境を続けるか、遠隔Macへ移るか判断する
ローカル環境にMacがない、空き容量や常時稼働が不足している、チームで同じビルド環境を使いたい場合は、遠隔Macが候補になります。一方、ローカル環境ではSSH越しの作業設定、作業コピーの不一致、ビルド用Macの維持が負担になりやすく、シミュレーターや実機接続まで必要なら遠隔環境での対応確認も欠かせません。
SSHとプロジェクト確認が済んでも、手元の機器ではXcodeを動かせない場合は、MACGPUの利用案内で遠隔Macの利用方法を確認し、必要ならMacのレンタル案内も比較してください。GUIや実機接続が必須なら、契約前にその作業経路を確認するのが安全です。短期のビルドや環境検証にはレンタルが選択肢になりますが、常時の物理接続が必要な作業や、長期にわたり安定した高負荷を専有する用途には、自前のMacのほうが適する場合があります。