Xcode 27のリモートSSH署名失敗はどうする？2026年の切り分け

errSecInternalComponentは、それだけで原因を特定できるエラーではありません。Apple Developer Technical Supportは、SSHやCIなどの署名環境で起こり得る問題として説明し、ロックされたキーチェーンを原因候補の一つに挙げています。したがって、SSH特有の実行環境と署名資産の問題を分けて調べます（Apple DTSのコード署名に関する説明）。

まず、ビルドログで最初に現れたCodeSignの失敗を確認します。コンパイルエラー、署名エラー、署名後のアップロードエラーでは調査対象が異なります。アップロードで失敗した場合は、SSHセッションのキーチェーンを先に変更するのではなく、該当工程のログを手掛かりにしてください。

Xcodeのバージョンも記録し、対象バージョンのApple Xcode 27 Release Notesに、署名動作に関係する変更がないか確認します。バージョン表記だけで既知の問題や修正済みと決めつけず、実際のエラーと照らし合わせて判断してください。

同じプロジェクトと同じ署名設定を使い、GUIのターミナルとSSHから実行した場合の結果を比べます。GUIでは成功しSSHだけが失敗するなら、コード自体の問題より、プロセスのユーザーや利用できるキーチェーンが異なる可能性を先に調べます。

SSHセッションと、CIエージェントや常駐プロセスが起動するタスクは、同じユーザーで動作するとは限りません。Appleはデーモンやエージェントの実行コンテキストを、ユーザーがログインして使うプロセスと区別して説明しています（Appleのデーモンとエージェントに関する技術資料）。

ビルドを起動するタスクの中で、次の情報を一時的に記録してください。共有ログには個人情報やホスト情報をそのまま残さず、必要な範囲に絞ります。

• whoamiとidで、実際の実行ユーザーを確認します。
• printf '%s\n' "$HOME"で、そのユーザーのホームディレクトリを確認します。
• GUIで署名できるユーザーと、SSHまたはCIタスクのユーザーを照合します。
• rootや別のサービスアカウントでビルドが起動していないか調べます。

表示されたユーザー名がSSHログイン時のアカウントと違う場合は、まずタスクの起動方法を見直します。キーチェーンの解除や証明書の再作成をしても、ビルドが別ユーザーで動いていれば、意図した署名IDにアクセスできないままです。

署名IDは、署名に使う証明書だけでなく、対応する秘密鍵を含むアイデンティティとして確認します。Appleのキーチェーンにアイデンティティを保存する資料も参照し、GUIで見える証明書名だけを根拠に、SSH側でも署名できると判断しないでください。

SSHセッションでは、GUIに表示される解除ダイアログを前提にした操作は完了できません。ビルド中に入力待ちが発生していないか、また、タスクの実行ユーザーが署名対象のキーチェーンを参照できているかを調べます。ログイン時に解除したという事実だけでは、別ユーザーのタスクでもその状態が有効とは限りません。

Apple DTSの説明に照らして、ログインキーチェーンのロック状態と実際の署名プロセスの実行条件を一緒に確認します。秘密情報はリポジトリ、公開スクリプト、平文ログに書き込まないでください。パスワードをコマンドへ直接埋め込む方法も、漏えい範囲を広げるため避けます。

ログインキーチェーンを解除しても失敗が続く場合、同じユーザーの同じSSH条件で再現するかを保ったまま、秘密鍵の有無とアクセス許可へ調査を進めます。一律のアクセス許可変更を、どの環境にも有効な修正として扱わないでください。

キーチェーンの状態に問題が見つからない場合は、署名IDに証明書と対応する秘密鍵の両方が含まれているか確認します。さらに、codesignがその秘密鍵を利用できる状態か、同じユーザーのコンテキストで調べます。署名IDの重複や不完全なアイデンティティ、証明書チェーンの問題は、ログや確認結果に根拠があるときに追加で調査します。

Appleの証明書の概要と保護に関する案内に沿って、証明書の種類や有効性を確認してください。証明書の情報だけで秘密鍵へのアクセスまで確定できるわけではないため、問題の層を混同しないことが重要です。

証拠がアプリ設定やプロファイルを指す場合に限り、次の項目を照合します。

• 署名対象のBundle IDと、プロビジョニングプロファイルのアプリ識別子が一致しているか。
• Teamの指定が、対象の署名IDとプロファイルで整合しているか。
• 使用しているプロファイルが有効で、意図した用途に合っているか。

プロファイルの内容を確認する場合は、Appleのプロファイルの編集・ダウンロード・削除の説明を参照します。成果物のEntitlementsが問題を示している場合は、Entitlementsの診断手順も確認してください。これらの設定不一致は、非対話のSSHセッションでキーチェーンを使えない問題とは別の層です。

• GUIでは成功し、SSHでは失敗する場合： 実行ユーザー、ホームディレクトリ、利用中のキーチェーンを先に照合します。署名資産の再作成は保留します。
• SSHのタスクが想定と別のユーザーで動いている場合： タスクの起動ユーザーを修正し、正しいアカウントのキーチェーンを確認します。
• 実行ユーザーが一致し、ログインキーチェーンも利用可能な場合： 署名IDに対応する秘密鍵と、codesignの利用許可を確認します。
• 署名IDが利用でき、ログが識別子やプロファイルの不一致を示す場合： Bundle ID、Team、プロファイルの適合性を調べます。
• 失敗がコンパイルまたはアップロード工程にある場合： CodeSign障害として扱わず、最初に失敗した工程のログに戻ります。

Appleのコード署名に関する技術資料も参照し、エラーの段階に応じた調査を進めてください。ログの一行だけを根拠に証明書を無効化したり、作り直したりすることは避けます。

SSHでxcodebuildを実行したとき、なぜerrSecInternalComponentが出るのですか？

エラー名だけでは根本原因は決まりません。Apple DTSは、SSHやCIのような通常のGUI操作とは異なる環境で発生し得るものとして説明し、ロックされたキーチェーンを可能性の一つに挙げています。実行ユーザー、キーチェーン、秘密鍵へのアクセスを分けて調べてください。

SSHのビルドタスクが正しいmacOSユーザーで動いているか、どう確かめますか？

SSH接続直後だけでなく、実際にビルドを起動するタスク内でユーザー名、ユーザーID、ホームディレクトリを確認します。CIや常駐エージェントが別ユーザーなら、そのユーザーが参照するキーチェーンを調査します。コマンドが実行できても、GUIセッションと同じ署名コンテキストとは限りません。

キーチェーンを解除したのにcodesignが失敗する場合はどうしますか？

対象タスクが同じユーザーのキーチェーンを参照しているか、署名IDに対応する秘密鍵があるか、codesignがその鍵を利用できるかを確認します。確認中はユーザーとSSH条件を変えず、代表的なArchiveを再実行してください。パスワードをスクリプトやログへ書き込む方法は避けます。

キーチェーン障害とプロファイルの不一致は、どのように見分けますか？

GUIで成功してSSHでのみ失敗するなら、まず実行ユーザーとキーチェーン、秘密鍵へのアクセスを調べます。ログに証明書の期限、署名ID、Bundle ID、Team、プロファイルの不一致が示される場合は署名資産を確認します。根拠がない段階で証明書を失効・再作成しないでください。

環境だけを直して終わりにせず、正式なビルドと同じユーザー、SSH経路、Xcode選択、署名設定で代表的なxcodebuild archiveを実行します。Archiveが完了したかに加え、成果物の署名情報とビルドログを確認し、失敗した工程が解消されたかを判断します。署名後にアップロードを行う場合は、その結果をArchiveの成否と分けて記録してください。

Appleの証明書・秘密鍵・プロファイルに関する署名エラーの案内を参照しつつ、確認したXcodeとmacOSのバージョン、実行ユーザー、キーチェーンの場所、再現条件を記録します。秘密情報は記録から除外し、必要な担当者だけが参照できるようにします。

ローカルの署名資産とプロジェクト設定が正しく、問題がSSH実行環境に限られるなら、次はリモートMacの構築条件を整理してください。SSHで常時稼働するMacを自前で維持すると、ハードウェア費用に加え、ユーザー・キーチェーン管理、更新、障害時の確認も必要です。NUKCLOUDのMacレンタルなら、実機を購入せずにリモートのmacOS環境を使い、SSHビルドの実行条件を整える選択肢になります。物理接続が必要な作業や、長期の常時高負荷で専用機を運用する場合は、自前のMacが適することもあります。まずはNUKCLOUDのサービス概要と日本向けMac利用案内を確認し、手元のビルド方式に合うか判断してください。