2026年 専有リモート Mac CI：並列 Job におけるキーチェーン争用と codesign のセッションロック——ユーザー／キーチェーン領域の分割と security／codesign の SSH 再現可能な意思決定マトリクス＋FAQ

1. TL;DR — 何が競合しているか

• キーチェーンは「ただのファイル」ではありません。 署名用 ID、中間証明書の信頼、公証／API シークレットは Security.framework 経由になり、対話ユーザーなら多くの場合 login キーチェーン、自動化なら明示的に作った カスタムキーチェーン が関与します。
• 同一 macOS ユーザー＋同一デフォルトキーチェーンを並列 Job が共有 すると、ロック待ち、ACL 由来のプロンプト、codesign 呼び出しの踏み合いが最大化されます。
• 単一ホストで最も強い分離 は多くの場合 CI 用ユーザーを分ける（ログインキーチェーンとホームが別）、アカウント追加が難しければ 別キーチェーンファイル ＋ security list-keychains の順序規律です。
• SSH は「どのセッションがログイン相当か」を変えます。 非対話 ssh、launchd、コンソールはキーチェーンのロック／アンロック意味論が揃いません——Runner が動く UID と文脈 を文書化してください。

2. キーチェーン争用を平易に言うと

二つの Job が同じ秘密鍵や同じ署名証明書に同時に触ると、macOS はアクセスを調停します。速い操作もあれば、ACL が UI セッションを前提にしている項目や、securityd 内部ロックで待つ操作もあります。典型的な症状は次のとおりです。

• CPU は低いのに codesign の壁時計だけが伸びる。
• 別 Job がキーチェーンを入れ替え・インポートしたタイミングで、「キーチェーンに項目が見つからない」 が間欠的に出る。
• 非対話 SSH では 「User interaction is not allowed」 —— 出せないプロンプトを要求している。

まず 並行設計の欠陥 として扱い、ユーザー／キーチェーンを分割してから Xcode の更新を疑うのが運用では速いです。Xcode の導入範囲（CLT のみか完全 Xcode か）と SSH ヘッドレスまわりの前提は 専有リモート Mac CI の意思決定マトリクス（CLT／完全 Xcode） も参照してください。

3. codesign の「セッションロック」——現場で見えること

Apple の署名ツールチェーンは、同一 ID や同一キーチェーンまわりで 直列化 されるように振る舞う場面があります。ロックか内部キューかは実装詳細ですが、運用上の結論は同じです：並列レーンごとに署名の表面積（ユーザー＋キーチェーン＋プロビジョニングキャッシュ）を分けると被害半径が縮みます。

単一のエクスポート済み .p12 を並列 Job で共有インポートすると、ファイルロック無しではインポートと ID 一覧の競合が起きやすいです。

4. 分離パターン（強い → 弱い）

5. SSH 意思決定マトリクス：security と codesign

ヘッドレスな 専有 Mac で「ローカル／VNC では通るが SSH だけ落ちる」を切り分けるときの表です。

6. 再現可能なコマンドチェックリスト（読み取り中心の切り分け）

CI が使う 同一ユーザー で実行してください。本番秘密を変えずにスナップショットを取る用途です——パスはポリシーに合わせて読み替えてください。

• security list-keychains -d user —— 複数キーチェーンがあるときの検索順を確認。
• security find-identity -v -p codesigning —— そのセッションから見える署名 ID。
• codesign -dvvv Your.app —— 失敗後、実際の署名状態を確認。
• Runner ログの Job 開始時刻と突き合わせ、codesign が重なる窓がないか見る。

7. FAQ

Q1: 並列 Job すべてが同じ login キーチェーンを使うべき？

避けた方がよいです。 UID を共有せざるを得ない場合は、別キーチェーンファイル に ID を分け、インポート順を文書化——よりよいのは ユーザーを分ける ことです。

Q2: VNC だと署名が「直る」のは GPU が付いているから？

多くの場合 いいえ——GUI セッション がありプロンプトを処理できるからです。ヘッドレス CI ではパイプライン途中に UI 承認を要求しない 設計にしてください。

Q3: export／archive 周りにミューテックスを張れば十分？

しばしば はい（緊急回避）ですが、待ち行列の深さを計測してください。署名がボトルネックなら、グローバルロックより ID の分割 に投資した方が伸びます。

Q4: SSH ControlMaster はどこに効く？

転送の再利用 を最適化するもので、キーチェーンの正しさそのものは保証しません。上記の ControlMaster と tmux の記事を参照してください。

Q5: ホスト型 macOS Runner では？

プロバイダ側のスケジューリングの裏で争用が隠れます。専有機 では あなた が被害半径を引き受ける——ユーザー／キーチェーンを明示的に設計してください。

この論点でも Mac mini クラスが残る理由

署名レーンを分けるのは対策の半分もう半分は、Xcode・セキュリティサービス・Derived Data I/O を、熱で挙動が崩れない 安定した macOS スタック で回すことです。Apple Silicon のユニファイドメモリは、並列コンパイルと署名をメモリ不足がちな PC ビルドファームのようにしません；macOS は Gatekeeper・SIP・FileVault で秘密と実行ファイルの信頼モデルを揃えやすく、使い捨て Linux イメージより運用が明確です。Mac mini はアイドル電力が非常に低く静音——24/7 無人ジョブ向けに向きます。

環境ドリフトと戦い続けずに並列 CI を回したいなら、これらのパターンを Mac mini M4 クラスに載せるのは、ネイティブ署名の挙動を確保しつつ拡張余地を残すコスト効率のよい選択のひとつです——SSHMac のトップページでプランを確認し、キーチェーン分割の微調整の前にハードを揃えてください。