matchの同期ログは成功なのに、リモートMacでは署名に失敗する。
まずCIジョブの実行ユーザーが使うキーチェーンに秘密鍵があるかを確認し、次にProvisioning ProfileとXcodeの署名設定を照合してください。CIや公開用の定常ビルドではreadonly同期を優先し、証明書の再発行や失効を最初の対処にしないことが基本です。
この記事は、fastlaneのビルドをリモートMacへ移した個人開発者が、実行環境ごとの署名資産を確認するための手順です。
iOSの公開フローを保守する小規模チームや、Archiveで署名エラーが出て原因を絞り込みたい担当者にも役立ちます。
同期成功と署名成功を分けて考える
fastlane matchは証明書やProvisioning Profileを取得・配置するための仕組みですが、同期ログの成功だけで、現在のビルドユーザーが署名できるとは限りません。fastlaneのmatch公式ガイドでは、新しいマシンへの同期、証明書などの保管、CIでのreadonly利用が説明されています。同期と、Xcodeが実際に署名へ使う設定・鍵の利用可能性は別々に確認します。
失敗箇所をひとまとめにせず、次のように段階を分けてください。
- matchリポジトリへのアクセス：取得処理が認証され、必要なファイルを読めているか。
- 暗号化データの復号：ジョブに必要な復号用の情報が、安全な方法で渡されているか。
- 署名IDの利用：証明書だけでなく、対応する秘密鍵がビルド実行ユーザーから使えるか。
- プロファイルと設定の適合：対象のBundle IDやビルド構成に合うProvisioning Profileと署名設定をXcodeが選んでいるか。
- 成果物の工程：Build、Archive、IPAの書き出し、アップロードのどこで止まったか。
エラーの一行だけから根本原因を決めないでください。直前の処理と最初に失敗した工程をログで特定し、その条件に合う確認へ進みます。
リモートMacの初回同期で確認する実行環境
新しいMacで同期した直後は、手元のMacと同じアカウント・作業環境だと思い込まないことが重要です。ビルドを起動したユーザー、作業ディレクトリ、環境変数、対象のXcodeプロジェクトを、実際のジョブ定義と照合してください。ターミナルで手動実行したときの結果は、CIの実行ユーザーが同じ鍵や設定を使える証拠にはなりません。
fastlane matchの同期後に署名IDが見つからない場合は、何を確認しますか？
まず、同期処理と署名処理が同じユーザー環境を使っているかを確認します。fastlaneの説明では、証明書はキーチェーンに、プロファイルは指定された場所に配置されます。設定した保存先と、ビルドを実行するユーザーが参照する環境を別々に確認してください（matchの同期先・設定に関する説明）。
確認内容を記録するときは、秘密情報そのものではなく、次のように「どの環境で確認したか」を残します。
実行ユーザー: <ビルドジョブのユーザー>
対象プロジェクト: <リポジトリ内のプロジェクト>
Xcode署名設定: <対象Target・構成>
matchモード: <readonly または書き込み可能>
証明書: <署名IDが利用可能か>
Provisioning Profile: <対象Bundle IDとの適合>
結果判定: <失敗した工程と確認したログ>
この記録例はfastlaneの実際の出力ではありません。パスワード、秘密鍵、復号用の値、リポジトリ認証情報はログや共有メモに含めないでください。
証明書と秘密鍵を同じユーザーで照合する
証明書ファイルが取得できていても、その証明書に対応する秘密鍵が該当ユーザーのキーチェーンで使えなければ、署名IDとして利用できないことがあります。Appleは、署名証明書と秘密鍵の関係を説明しており、秘密鍵を含む署名資産を使える状態かどうかが署名の確認点になります（署名証明書の共有に関するAppleの説明、コード署名証明書の技術説明）。
macOSのキーチェーンアクセスで、ビルドを実行するアカウントのキーチェーンを開き、対象証明書に対応する秘密鍵があるかを確認します。証明書が一覧にあることだけで判断せず、秘密鍵を含めてそのユーザーが利用できる状態かを見ます。鍵が見つからない場合は、同期先や実行ユーザー、キーチェーンの選択を先に点検してください。原因を確かめずに証明書を失効・再作成すると、ほかのビルド環境にも影響するおそれがあります。
リモートMacで秘密鍵をログインキーチェーンから利用できない場合は、どう進めますか？
ビルドジョブが参照するユーザーと、キーチェーンアクセスで確認したユーザーが一致しているかを調べます。そのうえで、秘密鍵を含む証明書を正しいアカウントへ安全に用意する手順を確認し、ジョブ側のキーチェーン選択を見直します。秘密鍵そのものをログ出力したり、共有ストレージへ平文で置いたりする方法は避けてください。
Provisioning ProfileとTargetの組み合わせを確認する
プロファイルを同期・配置できても、Xcodeが現在のTargetに合うものを選んでいるとは限りません。アプリ本体と拡張機能など複数のTargetがある場合は、各TargetについてBundle ID、ビルド構成、署名ID、Provisioning Profileを照合します。Appleのコード署名に関する説明と署名関連ビルド設定のリファレンスを確認し、プロジェクトで指定された値と実際のArchive対象を比べてください。
App Store向けと登録済みデバイス向けでは、目的に応じて必要なプロファイルが異なります。AppleのApp Store用Provisioning Profileの説明を参照し、今回の配布方法に合うプロファイルを選択しているか確認します。同期済みかどうかと、配布先に適合しているかどうかは別の判定です。
| 状況 | 優先して確認する項目 | 次の判断 |
|---|---|---|
| matchの取得・復号で停止 | リポジトリ認証、復号情報、ジョブ環境 | 署名設定を変える前に、取得工程を復旧する |
| 証明書はあるが署名IDが利用できない | 実行ユーザー、キーチェーン、対応する秘密鍵 | 秘密鍵の所在と利用権限を確認する |
| 署名IDは使えるがArchiveで失敗 | Target、Bundle ID、構成、配布目的、プロファイル | 実際のArchive設定とプロファイルを照合する |
| Archiveは完了し、書き出しで停止 | エクスポート方法と配布設定 | Archiveの成否とIPA書き出しの成否を分ける |
CIのreadonly同期とローカルとの差を調べる
ローカルでは署名できるのにリモートMacのCIで失敗する場合、同じプロジェクトを使っていることだけで環境が同一とは判断できません。ジョブの実行ユーザー、秘密情報の受け渡し、matchリポジトリのアクセス、復号、キーチェーン、ビルド設定の順に比較します。readonlyは、同期処理で証明書やプロファイルを新たに生成・修復する指定ではありません。fastlaneはCIでの利用方法としてreadonlyを案内していますが、必要な署名資産が不足している状態を自動で直すものではありません（matchのreadonlyとCIに関する説明）。
fastlane matchのreadonlyは公開用ビルドでも使えますか？
必要な署名資産がすでに用意され、CIがそれを取得・復号し、対象ユーザーから使える構成なら、readonly同期を公開用ビルドに使う運用が可能です。資産の新規作成や更新が必要なときは、CIの通常実行に書き込み権限を足すのではなく、変更を行う手順と定常ビルドを分離してください。
ローカル成功・リモート失敗なら、同じ確認項目を両環境で記録し、最初に差が現れる箇所を探します。リポジトリから取得できない、復号できない、取得はできたが署名IDがない、という状態はそれぞれ別の対処です。readonlyの指定だけを変更して原因を隠さないようにします。
Archiveからアップロードまでを分けて検収する
Debugビルドが通ったことは、配布用ArchiveやIPA書き出しが成功する証明にはなりません。対象の配布方法と署名設定を指定したArchiveを実行し、どの工程で失敗するかを確認します。AppleのアプリのArchive・配布・書き出しに関する資料に沿って、Archive、配布用ファイルへの書き出し、App Store Connectへのアップロードを別工程として扱ってください。
ローカル署名が成功し、リモートMacのArchiveだけが失敗した場合は、どこから調べますか？
リモートジョブの実行ユーザーとキーチェーンを先に照合し、次にArchiveで使うTarget・構成・署名ID・Provisioning Profileを確認します。エラー文だけで原因を一つに決めず、最初に失敗した工程と前後のログを合わせて判断してください。Archiveが完了してからIPA書き出しやアップロードで止まる場合は、署名エラーと同じ問題として扱わず、該当する後続工程を調べます。
復旧判定は、対象プロジェクトと公開予定の構成でArchiveを実行し、署名情報と選択した配布方法が一致していることを確認して行います。確認記録には、実行ユーザー、ツールチェーン、資格情報の安全な供給元、Archiveと後続工程の結果を残してください。この検収で確認できるのは、そのプロジェクト・構成・実行経路です。別のアプリや配布方法まで検証済みとはみなせません。
遠隔ビルド環境を選ぶときの判断
毎回手元で署名作業を行う運用では、開発用Macの空き状況や担当者ごとの設定差が残ります。一方、専用のMacを購入すれば環境を継続して管理できますが、初期費用と保守、設置場所を自分たちで引き受ける必要があります。短期の移行検証や、定常CI用のMacを一時的に確保したい場合は、作業期間と必要な管理権限を基準に遠隔利用も比較対象になります。
NodeMiniの案内では、VNC、SSH、WebコンソールによるMacへの接続方法が示されています。XcodeのArchiveや署名検証を行う環境を検討する際は、NodeMiniのMac利用案内で利用方法を確認し、必要なツールや運用条件が合うかを事前に照合してください。継続的な重負荷運用や物理機器への接続が必要な場合は、自前のMacのほうが適することもあります。
今回のように環境移行後の署名不具合を切り分ける目的なら、原因が実行ユーザーやキーチェーンにあると確認してから、期間を区切って遠隔Macで検証する選択肢があります。購入前の動作確認や一時的なビルド環境が必要な場合は、NodeMiniのMac利用条件を確認し、Archiveから書き出しまで自分のプロジェクトで検収してください。署名資産の整合性は、利用環境だけで保証されるものではありません。