GitLab CIで複数のiOS署名タスクが競合したら？2026年トラブルシューティングガイド

GitLab公式資料では、同じresource_groupを指定したJobの同時実行を制御でき、実行順はprocess modeによって変わります。resource_groupの仕様が示すのは対象Job間の調停であり、Mac全体や署名資格情報を隔離する機能ではありません。まず署名対象Jobを直列化し、そのうえでRunner並行数、作業ディレクトリ、Keychainの境界を切り分けてください。プロジェクトをまたぐ競合や信頼範囲の違いがあるなら、別途調停と隔離を設計します。

対象読者
企業のiOSリリース担当者：同時署名やアーカイブによる上書き、順序の乱れを防ぎたい方。
プラットフォームエンジニア：同じMac Runner上のJobと作業領域を調べたい方。
IT・セキュリティ担当者：共有Macで署名資格情報のアクセス範囲を確認したい方。

今週は、本番設定を先に変えるのではなく、非本番Jobで症状を再現し、ログと実行設定を照合してから直列化やノード分離を選んでください。着手時に失敗Jobのログを保全し、原因候補をRunner、ディレクトリ、認証情報へ振り分け、変更後は再試験の記録を残します。

競合症状を分類する

同じMacで署名、アーカイブ、公開処理が重なると、Jobが待ち続ける、古い成果物が公開対象になる、署名の成否が実行ごとに変わる、といった症状が現れます。ただし、これだけで並行実行が原因とは断定できません。証明書の期限や権限、ビルド設定、外部サービスの失敗でも似たログになります。

まず、Pipeline、Job、Runner、署名コマンドの各ログを同じ時系列で確認します。署名開始・終了、チェックアウト先、アーカイブの出力先、使用した実行アカウントを、秘密値を含めずに記録してください。個別のチーム記録がない状態で、発生率や復旧時間を一般値として置くのは避けます。

問題の切り分けでは、次の順序が有効です。

• 同じプロジェクトの署名Jobだけで発生するかを確認します。
• 署名以外の並行ビルドでもディレクトリや成果物が混ざるかを確認します。
• 失敗時のKeychainアクセスや証明書の選択に差があるかを調べます。
• Jobのリトライ前後で、対象コミットと成果物の対応が維持されているかを照合します。

resource_groupの制御範囲

GitLab CIのresource_groupは、同じリソースグループを使うJobの並行実行を制御します。署名や公開のように同時実行を避けたい処理へ設定しますが、ビルド全体を無条件に直列化する必要はありません。並列化できるテストやコンパイルまで待たせると、競合を防ぐ代わりにRunnerの待ち行列が伸びます。

設定範囲は、実際に共有状態を変更するJobに合わせます。たとえば、署名Jobだけが同じKeychainやアーカイブ出力先に触れるなら、その処理を対象にします。署名と公開が一連の排他区間である場合は、両Jobをどう連携させるかも設計に含めてください。

process modeは待機Jobの処理順を左右します。GitLabの資料には複数のmodeが記載されているため、古いリリースを先に処理すべきか、新しいリリースを優先すべきかを決め、実際の待ち行列で期待どおりに動くかを試します。設定名だけで順序を保証したと判断せず、遅れて完了した古いPipelineが新しい公開結果を上書きしないことまで確認します。

注意：resource_groupはホスト全体のロックではありません。同じMacを使う未設定Jobや、別プロジェクトから来るJobまで止める設定だと見なさないでください。

Runner並行数と作業ディレクトリ

GitLab Runnerには、複数Jobを実行するための並行設定があり、実際に同時実行できる数はRunner側の設定にも左右されます。Runnerの高度な設定を確認し、管理対象のRunner全体に対する上限と、個々のRunnerに設定された上限を区別してください。並行数を絞るだけでは、異なるJobが同じパスを使う問題や資格情報の共有までは解消しません。

次に、builds_dir、Gitのチェックアウト先、キャッシュ、アーカイブ出力先を追います。Runnerの作業ディレクトリ設定に沿って、並行Jobを識別できるパス構成になっているか確認してください。設定上は別Jobでも、スクリプト内で固定の一時ディレクトリやファイル名に書き出していると衝突します。

切り分けでは、並行して動かすテスト用Jobに識別可能なファイルを作り、相手側のJobから見えないことを確認します。チェックアウト先だけでなく、キャッシュのキーや成果物の保存パスも対象です。共有パスが必要な場合は、排他制御の対象と削除・上書きの責任者を明記します。

Keychainと署名資格情報の境界

iOSコード署名の失敗が資格情報に由来する場合、署名Jobが開始できても安全な分離ができたとは限りません。証明書、秘密鍵、Keychainのロック解除状態、CIサービスアカウントの権限を別々に記録し、どのJobがどの資格情報へアクセスできる設計かを確認します。

AppleのKeychainアクセス制御の説明では、項目へのアクセスを制御する仕組みが扱われています。実際の許可対象や動作はMac上の構成に依存するため、CIのテスト用資格情報を使って、許可したJobでは署名でき、許可していないJobではアクセスできないことを確かめてください。署名と検証の公式資料も参照し、署名の成功とアクセス境界の検証を混同しないようにします。

CI/CD変数に秘密値を置く場合も、マスクや保護設定だけをもってJob間の隔離と判断してはいけません。CI/CD変数の保護に関する説明とPipelineのセキュリティガイドを確認し、変数の適用範囲、実行者、対象ブランチを点検します。監査ログにはアクセス主体や結果を残し、秘密値そのものは出力しない運用にします。

プロジェクト間の共有と公開順序

resource_groupを設定しても、別プロジェクトのJobが同じMacやKeychainを使う場合に、プロジェクト横断のロックになるとは限りません。GitLabのRunner管理範囲を確認し、どのプロジェクトがそのRunnerを利用できるかを整理してください。共有するプロジェクトが増えるほど、Runnerの割り当て範囲と署名資格情報の信頼範囲を別々に評価する必要があります。

公開順序に要件があるなら、待機Jobの順番だけでなく、古いPipelineの再実行や遅延完了も試験対象にします。アーカイブと公開成果物の対応は、Job artifactsの仕様を参考に、コミットやJobの識別情報と結び付けて追跡します。複数プロジェクトが同じ署名ホストへ書き込むなら、各プロジェクトの設定と実行記録で調停策が実際に働くことを確認してください。

非本番で行う受け入れ試験

本番へ適用する前に、次の手順で競合の境界を確認します。

• 失敗したPipelineとJobのログを保全し、署名開始から成果物生成までの実行順を記録します。
• 対象Jobにresource_groupを設定し、同じグループのJobだけが待機することを検証します。
• resource_groupを使う処理と通常の並行ビルドを同時に実行し、作業ディレクトリ、キャッシュ、アーカイブが混ざらないか確認します。
• 失敗後の再試行を行い、対象コミット、署名結果、成果物の対応が保たれるか照合します。
• テスト用資格情報で、許可したJobと許可していないJobのアクセス記録を比較します。
• 必要に応じて別プロジェクトからも実行し、単一プロジェクト内の設定を横断ロックと誤認していないか確かめます。

試験結果は、症状、設定変更、Jobの順序、成果物の識別情報、資格情報へのアクセス結果で残します。秘密値をログに記録せず、原因を特定できるだけの監査情報を確保してください。

構成選択の比較

次の評価は、導入前の判断材料です。スコアは実測性能ではなく、並行署名のリスクと運用上の確認範囲を基準にした定性的な評価です。

試験で確認した境界を、受け入れ条件に落とし込んでください。未確認の項目が残るなら、共有構成のまま本番署名へ進めず、並行数を制限するか専用ノードを検討します。

よくある判断の確認

resource_groupを追加しても、Mac Runner全体の並行数やKeychainアクセスが自動的に変わるわけではありません。署名Jobだけを保護するのか、公開まで含めて順序を制御するのかを先に決め、非本番の同時実行で設定範囲を確かめます。

共有Macを続ける判断は、作業領域と資格情報の境界を試験記録で説明できることが条件です。プロジェクトをまたぐ競合があり、共通の調停を検証できない場合は、Runnerの利用範囲を狭めるか、専用署名ノードを設ける方が境界を明確にしやすくなります。

共有構成を続けるか、Macを分けるか

同じMacを共有する方式は、ノード管理をまとめやすい一方、並行処理の衝突、プロジェクト間の調停不足、Keychainのアクセス範囲を継続して検証する負担があります。現在の構成でこれらをログと受け入れ試験によって説明できないなら、署名処理を専用Macへ分けることで、実行対象と資格情報の範囲を運用上切り分けやすくなります。

まず非本番の署名Jobで境界を再現し、共用Runnerの制限で足りるかを判断してください。独立した署名環境が必要で、社内にMacを購入・保守するより一時的な構成を選びたい場合は、VPSMACのMac利用案内とMacノードの選択肢を確認できます。長期にわたり安定した高負荷運用や物理インターフェースが必要な場合は、自社保有も比較対象に残し、専用ノードの分離要件が固まってからレンタルを検討してください。