Appleの公式資料を基準にすると、署名に関係する資産は少なくとも「証明書と秘密鍵、Provisioning Profile、macOS Keychain、App Store Connect API Key、CI実行アカウント」の5系統に分かれます。証明書の種類とKeychainのアクセス制御を別々に管理する必要があるため、iOS CI署名ノードは、通常のコンパイル、PR検証、信頼できないコードの実行から原則として分離するのが安全です。例外は、単一アプリ、低頻度リリース、固定メンバーの小規模チームが、論理分離と再起動後の検収まで実施できる場合に限られます。

この判断が必要なチーム

この記事は、次の判断を担当する企業IT責任者向けです。署名ノードの分離、遠隔復旧、監査証跡の基準を決める場面に適しています。

研发効能責任者は、通常ビルド、アーカイブ、署名、アップロードを適切に振り分ける設計を確認できます。技術責任者や購買担当者は、共有Mac、専用のリモートMac、混合ノード池のTCOと運用リスクを比較できます。

最初にタスクと資産の流れを分ける

コンパイルとテストは、原則としてソースコードと依存関係を扱う処理です。一方、アーカイブ後の署名とアップロードでは、証明書の秘密鍵、Provisioning Profile、Keychain項目、App Store Connect API Key、社内ネットワークへの接続権限が関係します。

したがって、同じMac上で処理する場合でも、信頼境界は同一ではありません。構成を次のように分けると、どの処理に本番資格情報を渡したかを追跡しやすくなります。

PR・通常ビルド
  └─ ソースコード、依存関係、テスト結果
       ↓
受控えアーカイブ
  └─ リリース対象の固定、成果物の検証
       ↓
本番署名ノード
  └─ 証明書秘密鍵、Keychain、Provisioning Profile
       ↓
アップロード
  └─ App Store Connect API Key、公開操作の監査記録

GitHub Actionsの自ホストRunnerについても、信頼できないワークフローを同じ環境で実行しないよう公式の安全ガイダンスが示されています。自ホストRunnerの安全な利用方法は、署名ノードを単なる高性能なビルド機として扱わない根拠になります。

環境変数を隠すだけでは十分ではありません。ジョブが同じワークスペース、プロセス、ファイルシステム、Keychainに触れられるなら、資格情報を利用できる経路が残るためです。

小規模チームは同じMacに論理分離を置けるか

単一アプリで、コードの投入者が限定され、リリース頻度も低く、公開操作を担当するメンバーが固定されている場合は、同じMacで論理分離を採用できます。ただし「codesignが一度成功した」ことを合格条件にしてはいけません。

通常CI用アカウントと公開用アカウントを分け、公開用のmacOS Keychainを別に作成します。署名ジョブの起動元は保護されたブランチや承認済みワークフローに限定し、PRや一時スクリプトが署名コンテキストへ入らないようタスクルーティングを制御します。

AppleのKeychain Servicesでは、アプリケーションがKeychain項目へアクセスする仕組みが定義されています。さらに、Keychain項目の可用性制御を確認し、ログインセッションの消失や再起動後に、想定外の自動アクセスが起きないことを検証します。

小規模構成の受け入れ条件

  • [ ] 通常CIアカウントに本番秘密鍵を読み取る権限がない
  • [ ] 署名用Keychainが通常のログインKeychainと分離されている
  • [ ] PR、外部コントリビューター、一時スクリプトが署名ジョブを起動できない
  • [ ] 署名用Provisioning Profileの配置先と削除記録を確認できる
  • [ ] 再起動後にKeychainが意図せず自動解除されない
  • [ ] 署名、アップロード、失敗時の回退をクリーン環境から再現できる
  • [ ] 担当者の離任後、旧アカウントと旧トークンを無効化できる

このどれかを確認できない場合は、同一Macの論理分離から専用ノードへ戻すべきです。特に、公開操作を複数チームが行う場合は、アカウント分離だけでは責任の境界が曖昧になります。

多プロジェクト環境では共有Macをどう隔離するか

複数リポジトリが同じ自ホストRunnerを使うと、ワークスペースの残留、誤ったジョブルーティング、キャッシュや一時ファイルの再利用が問題になります。あるプロジェクトのビルドが成功していても、別プロジェクトが同じ署名環境へ到達できるなら、署名ノードとしての分離は成立しません。

人群軸で見ると、少なくとも次の3層に分けると判断しやすくなります。

  • 製品チーム：自分のリポジトリで通常ビルドとテストを実行する
  • プラットフォームチーム：Runner、Xcode、macOSの更新とログを管理する
  • 外部協力者：署名資格情報へ到達できず、承認済み成果物だけを渡す

通常ビルド池、受け入れ済みアーカイブ池、本番署名池を分け、リポジトリのラベルやRunnerグループで実行先を制限します。Runnerの追加と管理に関する公式手順を確認し、誰がどのRunnerを選択できるかを記録してください。

注意：複数プロジェクトの共有Macでは、ジョブ終了後の作業ディレクトリ、DerivedData、ログ、キャッシュ、Keychain参照を消去した記録が必要です。消去処理そのものが失敗した場合に、次のジョブを止める設計でなければなりません。

受け入れテストでリモートMacの署名ノードを検証する

リモートMacを署名ノードにする場合、接続できることだけでは合格になりません。署名、アップロード、再起動、撤権を一つの運用手順として検証します。

実施手順

  1. 非本番資格情報で初期化する
    本番証明書ではなく、検証用の証明書、Provisioning Profile、API Keyを使い、作業用アカウントと管理用アカウントを分けます。

  2. Xcodeと署名環境を固定する
    Xcodeの選択、SDK、証明書、Profile、Keychainの場所を記録し、ジョブのログに秘密鍵やAPI Keyの値を出さないようにします。

  3. タスクルーティングを検証する
    PRジョブが署名ノードへ入らず、承認済みのアーカイブだけが公開用キューへ進むことを確認します。

  4. Keychainのロック状態を試す
    ユーザーセッションの終了、Keychainのロック、再ログインを順に実施し、許可されたジョブだけが再認証後に署名できることを確認します。

  5. 再起動後に一連の処理を再実行する
    Macを再起動し、接続、Runner、Xcode、Keychain、署名、アップロードの順に確認します。途中の手動操作が必要なら、運用手順に明記します。

  6. 証明書の撤回と更新を試す
    Appleの証明書撤回に関する説明を基準に、旧証明書を使うジョブが停止し、新しい資格情報へ切り替えられることを確認します。

  7. 担当者とホストの撤権を確認する
    CIアカウント、macOSローカルアカウント、Apple Developerの役割、App Store ConnectのAPI Keyを別々に無効化し、旧ノードから公開操作ができないことを検証します。

Apple Developerの役割とApp Store Connectの権限は同じものではありません。Apple Developer Programの役割とApp Store Connect APIの説明を責任分担表に結び付け、「申請する人」「インポートする人」「呼び出すジョブ」「撤回する人」「復旧する人」を個別に記録します。

チームの成熟度ごとの分岐を決める

次の条件分岐を、設計会議の結論として残してください。

  • 単一アプリ、低頻度リリース、固定メンバー、再起動後の復旧試験に合格
    → 同じMac上の論理分離を選択できます。ただし、本番署名アカウントと通常CIアカウントは分離します。

  • 複数アプリ、複数リポジトリ、チームごとに公開権限が異なる
    → 通常ビルド池と専用署名ノードを分けます。共有Macを使う場合でも、本番Keychainは共有領域に置きません。

  • 金融、医療、行政向けなど、変更承認と監査証跡が必要
    → 専用の署名ドメインを設け、管理者、ネットワーク出口、変更承認、資格情報のローテーション担当を分けます。

  • 外部協力者のコードを実行する、または信頼境界を確認できない
    → 共有Macへの署名資格情報の配置を避け、専用署名ノードへ回退します。

  • 安定した本番公開負荷があり、停止時の影響が大きい
    → 専用ノードを基本にします。通常ビルドと一時的な公開ピークだけを弾力的なリモートMacへ分散する混合構成が適します。

共有・専用・混合構成を比較する

構成 適するチーム 固定容量と空きコスト 障害時の影響 退出・変更の難しさ
共有Macの論理分離 単一アプリ、固定メンバー、低頻度公開 1台に集約しやすい一方、署名と通常CIが競合します 1台の障害が全処理へ波及します アカウント、Keychain、ジョブ履歴の整理が難しくなります
専用署名ノード 多プロジェクト、監査重視、安定した公開負荷 署名用途の待機時間が発生します 通常ビルド障害と署名障害を分離できます 資格情報と責任分担を明確にしやすい構成です
混合ノード池 通常ビルドと公開ピークの負荷が異なるチーム 基本容量を確保しつつ、ピークだけ増やせます 署名ノードを保護したままビルドを分散できます ルーティング、監査、復旧手順の管理が必要です

構成の選択では、CPUやメモリのスペックだけを先に決めないでください。公開待ちジョブの記録、同時実行数、再起動後の復旧時間、資格情報の更新頻度、失敗時の手動操作を先に集計します。金額や節約率は、実際の契約期間、同時利用数、保守担当者の工数が揃ってから算出すべきです。

判定項目 合格とみなす証拠 未達時の回退
タスク分離 PRが署名池へ入らない実行ログ 専用署名ノードへ移行
資格情報分離 アカウント、Keychain、API Keyの責任表 本番資格情報を一時撤去
ワークスペース清掃 ジョブ後の削除ログと再利用テスト 共有Runnerを署名用途から外す
再起動復旧 再起動後の署名・アップロード記録 手動復旧手順を整備して再検証
撤権 旧ユーザー、旧ノード、旧Keychainの拒否記録 新しい資格情報へローテーション
監査 承認者、実行者、成果物、公開結果の記録 本番公開を承認制へ変更

企業向けの構成を試す場合は、RUVCLOUDのMac利用案内で遠隔の実機環境を確認し、まず非本番資格情報を使ったPoCを行う方法があります。料金や契約期間は利用地域と構成で変わるため、日本語の料金案内を確認したうえで、専用ノードとして必要な復旧条件と運用責任を個別に整理してください。

通常の共有Macは初期費用を抑えやすい反面、PRや複数プロジェクトの処理が同じ作業領域に集まり、署名資格情報の到達範囲、障害の波及、監査記録の責任者が曖昧になりやすい構成です。自社でMacを購入する場合も、固定資産、保守、故障時の交換、設置場所、容量の先行確保を負担します。

そのため、安定した本番署名を常時運用する企業は専用の物理・論理境界を検討し、短期のリリース試験やピーク処理ではRUVCLOUDのリモートMacを隔離環境として試す方が、いきなり複数台を購入するより判断材料を集めやすくなります。まず非本番証明書でアカウント、Keychain、タスクルーティング、再起動復旧、撤権を検収し、結果が揃った時点で専用署名ノードまたは混合ノード池へ進むのが現実的です。