「No signing certificate」や「Provisioning Profile not found」がArchive中に突然表示されました。
最短の復旧策は、match nukeや証明書の一括失効を先送りし、署名リポジトリの接続と復号、Keychain内の完全な署名ID、Profileの対応関係、entitlements、CIのreadonly設定を順番に確認することです。
今週は、失敗したジョブのログを脱敏して保存し、同じコミットを使った最小Archiveを常駐Macで再実行してください。原因が「取得」「インストール」「選択」「検証」のどの層にあるか確定してから、修正、輪換、再構築のいずれかを選びます。
このチェックリストを使う対象
リモートMac上でfastlane matchを実行しているのに、Archiveが突然署名ID不足になる独立開発者向けです。
CIによる自動リリースでは成功していたローカルビルドとの差分を調べ、小規模チームで証明書管理を集中化したい場合にも使えます。fastlaneの導入方法やlaneの書き方ではなく、すでに署名運用があり、無人実行だけが失敗したケースに絞ります。
まず失敗地点を4層に分ける
ログに同じ「署名エラー」と出ても、修正箇所は異なります。次の順番で、取得、導入、選択、検証を分離してください。
| 失敗層 | 典型的な症状 | 最初に確認する対象 | 先にやらないこと |
|---|---|---|---|
| 取得 | リポジトリへ接続できない、復号に失敗する | Gitまたはストレージ認証、ブランチ、Team、MATCH_PASSWORD |
証明書の失効 |
| 導入 | 証明書はあるが署名IDとして使えない | 証明書と秘密鍵、対象Keychain、CIユーザー | Keychain全体の権限緩和 |
| 選択 | Profileが存在するのに対象Targetが選ばない | Bundle ID、Team、Profile種別、ビルド設定 | Profileの一括削除 |
| 検証 | Archiveやexport後にentitlements、署名、配布条件で失敗する | 実際の署名結果、export options、対象環境 | 原因不明の再生成 |
Appleは署名に使う証明書、秘密鍵、Provisioning Profileを別の要素として扱っています。Profileの構造と署名条件は、AppleのProvisioning Profile技術ノートと、Appleのアプリ配布に関する公式説明を基準に確認してください。
保存する証拠は、脱敏済みの該当ログ、終了ステータス、実行したコミット、Xcodeのパス、Scheme、Configuration、export optionsです。トークン、デプロイキー、ストレージ資格情報、復号パスワード、秘密鍵の内容はログに残してはいけません。
取得失敗と導入失敗を先に切り分ける
署名リポジトリはソースリポジトリと別に検証する
アプリのソースコードを取得できても、署名資産の保管先へ接続できるとは限りません。ソース用Gitと署名用Gitでデプロイキー、アクセストークン、権限、ブランチが分かれていることがあるためです。オブジェクトストレージを使う構成でも、バケット、リージョン、読み取り権限、暗号化設定を別々に確認します。
matchの保存先や読み取り専用運用は、fastlane match公式ドキュメントに記載された現在の設定を基準にします。コマンドには実値を入れず、次のような明確な置換値を使ってください。
bundle exec fastlane match appstore \
--git_url "https://git.example.invalid/SIGNING_REPO.git" \
--git_branch "SIGNING_BRANCH" \
--team_id "TEAM_ID_PLACEHOLDER" \
--readonly
この例のURL、ブランチ、Team IDはすべて置換用です。実行前に、CI環境から署名資産の保存先へ接続できるか、復号用のMATCH_PASSWORDが注入されているかを個別に確認します。認証エラーと復号エラーを一つの再実行で済ませないことが重要です。
証明書ファイルだけでは署名IDにならない
証明書をKeychainへインポートしても、対応する秘密鍵がなければ完全なcode-signing identityにはなりません。security find-identityで署名IDとして認識されるかを調べ、証明書名だけが表示される状態を成功と判断しないでください。
security find-identity -v -p codesigning \
"KEYCHAIN_PATH_PLACEHOLDER"
確認する項目は、次のとおりです。
- 想定した
Apple Distributionまたは用途に合う署名IDが表示されるか - 証明書と秘密鍵が同じKeychainに存在するか
- fastlaneを実行するユーザーが、そのKeychainを参照しているか
- 再起動後も対象Keychainを解除できるか
- 一時的なログインセッションだけに秘密鍵が残っていないか
Appleのアカウント設定でProfileを再ダウンロードできても、秘密鍵が自動的に復元されるわけではありません。証明書、秘密鍵、Profileを別々の資産として台帳化してください。
注意：Keychainのアクセス許可をすべてのアプリへ無制限に開放する修正は、短期的にエラーを隠しても、秘密鍵の保護範囲を広げます。専用のビルドユーザーとKeychainを使い、必要なプロセスだけが扱える状態を優先してください。
ProfileとTargetの対応を表で固定する
Provisioning Profileを確認するときは、ファイルが存在するかだけでなく、現在のTargetがそのProfileを使えるかを調べます。AppleのProfile管理手順でも、対象アプリ、証明書、状態を分けて扱います。
| 確認軸 | 一致させる内容 | ずれた場合の症状 |
|---|---|---|
| Bundle ID | アプリ本体、Widget、通知拡張などの実際の識別子 | Profileが見つからない、別アプリのProfileを選ぶ |
| Team | Apple Developer上のTeamとビルド設定 | 署名IDやProfileが候補から外れる |
| Profile種別 | 開発、登録端末向け、配布などの用途 | Archiveまたはexportで拒否される |
| 証明書 | Profileに関連付けられた署名証明書 | 証明書はあるがProfileと組み合わせられない |
| entitlements | Push通知、App GroupsなどTarget固有の権限 | 署名後の検証や実行時に失敗する |
Profileの問題は、存在しない、期限や状態が無効、Xcodeが別のProfileを選択している、という3つに分けます。多くのBundle IDを一つの署名リポジトリで管理する場合、アプリ本体と拡張コンポーネントを同じ名前の変数で扱わず、Target単位の対応表を作ると誤選択を発見しやすくなります。
Xcodeやfastlaneのバージョンによって、Profileの保存場所や選択動作が変わる可能性があります。したがって、パスを固定値として断定せず、使用中のXcodeとfastlaneのバージョンをログへ記録し、fastlaneの署名トラブルシューティングにある確認方法と照合してください。
ローカル成功と無人Archiveの差分を潰す
ローカルのXcodeが自動署名で成功しても、CIのコマンドラインArchiveが同じ環境とは限りません。ローカルではログインユーザーのKeychainや自動更新されたProfileを使い、CIでは別ユーザー、別Keychain、別のXcode選択、明示的なexport optionsを使うためです。
次の順に固定すると、変数を減らせます。
- 同じコミットを保存する
ローカル成功版とCI失敗版のコミット、サブモジュール、依存関係を記録します。 - 利用中のXcodeを確認する
xcode-selectの参照先と、CIジョブで選択されるXcodeを一致させます。 - SchemeとConfigurationを固定する
Archive対象のScheme、Release相当のConfiguration、ワークスペースまたはプロジェクトを明示します。 - matchをビルドより先に実行する
署名資産を導入する処理とArchiveを別ステップにし、取得・復号・インポートのログを分離します。 - readonlyの意味を確認する
fastlaneのCI運用ガイドが示すように、CIの読み取り専用運用は、管理者に代わって不足資産を作成する仕組みではありません。 - 署名設定を明示する
CODE_SIGN_STYLE、各Targetの署名設定、Profile指定、export optionsを同じジョブ成果物として保存します。 - 最小Archiveを実行する
実際の公開ではなく、同じ署名経路でArchiveとexportだけを行い、アップロード前に署名状態を確認します。
Archiveだけでなく、export後の成果物に含まれるBundle IDとentitlementsも確認します。署名が通ったように見えても、拡張機能だけ異なるProfileを使っていると、公開直前の検証で止まることがあります。
修正、輪換、再構築を分ける判断基準
故障層が確定したら、対応を3段階に分けます。
その場で修正するケース
保存先の権限、ブランチ、Team設定、MATCH_PASSWORD、Keychainの参照先、TargetとProfileの対応が原因なら、資産を削除せずに修正します。修正前後で同じコミットとArchiveコマンドを使い、差分が署名環境だけになるようにしてください。
管理された輪換に進むケース
証明書やProfileの期限切れ、Team権限の変更、秘密鍵の紛失など、既存資産を継続利用できないことが確認できた場合は、影響を限定して輪換します。アプリ本体、拡張機能、開発用、配布用、CIジョブを一覧化し、どの資産を更新するかを先に決めます。
再構築を検討するケース
資産が復号できず、秘密鍵も復元できず、関連するアプリと配布経路への影響を確認できた場合に限り、再構築を検討します。match nukeは広範囲の証明書とProfileを削除する可能性があるため、match nukeの公式仕様を確認し、バックアップと影響範囲の記録なしに実行しないでください。
再構築後の完了条件は、単にmatchが終了することではありません。非緊急のブランチで、資産取得、Archive、export、アップロード前検証を一連で通し、再起動後にも同じ経路を再現できることを確認します。
FAQ：長引く署名障害を止める確認点
FAQの回答は、上の作業を飛ばして一括再生成するためのものではありません。各回答に対応する証拠をログと設定台帳に残してください。
今週の復旧マイルストーン
| 時点 | 実施すること | 完了条件 |
|---|---|---|
| 今日 | 失敗ログを脱敏し、取得・導入・選択・検証へ分類 | 原因候補が一つの層に絞られている |
| 次の作業日 | 署名保存先、復号、Keychain、Profileを個別確認 | CIユーザーが完全な署名IDを認識する |
| 修正後 | 同じコミットで最小Archiveとexport | アプリ本体と全拡張の署名が一致する |
| 公開前 | 非緊急ブランチでアップロード前検証 | 本番公開を止めずに再現性を確認できる |
| 次回再起動後 | 同じCIジョブを再実行 | Keychainと署名資産が再起動後も利用できる |
この手順で復旧できない場合は、追加の証明書を作る前に、失敗したコマンド、実行ユーザー、Xcodeの参照先、TargetごとのBundle ID、Profile名を並べてください。署名障害は、資産そのものより環境の取り違えで長期化することがあります。
現在の手元のMacや一時的なCIマシンだけで運用すると、再起動後にKeychainが解除できない、ログイン状態に依存する、マシン交換のたびに署名環境を再構築する、といった欠点が残りやすくなります。物理Macを新たに購入する方法は長期の安定運用には向きますが、初期費用と保守、常時稼働場所の確保が必要です。短期の復旧検証や、署名チェーンを再現できる常駐環境が必要なら、VMSPINのレンタルMacで非緊急の公開ブランチを動かし、再起動後もArchiveできるかを受け入れ条件にする方法が現実的です。
購入前に、VMSPINの日本語プランで利用期間を確認し、手動操作が必要な証明書登録や物理インターフェース依存の作業がある場合は、レンタルが適するかを先に切り分けてください。常時稼働の署名環境を一時的に確保したい場合は、日本向けMacレンタル案内から条件を確認できます。