GitHub Actions EnvironmentをiOS署名リリースにどう接続する？2026

本番のiOS署名リリースは、署名権限が必要なジョブだけを保護されたGitHub Actions Environmentに接続してください。Environmentの承認とSecretsの利用条件を整えたうえで、Mac Runner自体は別の信頼境界として隔離する必要があります。

企業IT担当者：既存のGitHub Actionsにリリース承認を組み込み、監査できる形にしたい場合に適しています。
プラットフォーム担当者：Mac CI Runnerと署名資格情報の責任範囲を整理し、本番投入の可否を判断したい場合に役立ちます。

承認ゲートをすべてのCIジョブに付けると、通常のプルリクエスト検査まで人手待ちになり、公開リリースの判断も埋もれます。逆に、ビルドから署名までを単一ジョブにまとめると、どの処理が本番の秘密情報を必要とするのかを検証しにくくなります。

まず、次の役割を分けてください。

• 検査：プルリクエストのテストや静的解析。通常は本番署名資格情報を使いません。
• ビルド：再現可能な成果物の作成。署名を伴わない範囲と、署名が必要な範囲を明示します。
• 署名・公開：本番用の署名身份と配布権限が必要な処理。保護されたEnvironmentと信頼できるMac Runnerに限定します。

この区分を決める際は、起動元、対象ブランチやタグ、署名資産の保管場所、公開の責任者を記録します。特に、未信頼のコードが秘密情報に触れ得るイベントやワークフローを署名経路に含めていないかを点検してください。pull_request_targetに関するGitHubの安全利用上の注意も、実際のトリガーと権限設計に照らして確認します。

Environmentは、保護ルールを通過するまで、そのEnvironmentを参照するジョブをRunnerに送らないためのデプロイ制御として利用できます。また、Environment Secretsは保護ルールの通過前には該当ジョブから利用できません。これらはEnvironmentの機能であり、Macホストの初期化やジョブ間の隔離を保証するものではありません。GitHubのEnvironment保護ルールとSecretsの仕様を設定時に参照してください。

設定では、リポジトリのEnvironment管理画面で本番用Environmentを作成し、許可するブランチまたはタグ、必須レビュアーなどを指定します。自己承認や管理者による保護ルールの回避が許容されるかは、画面上の設定と組織ポリシーの両方で確認してください。利用可能な保護機能はリポジトリの公開範囲や契約プランによって異なる場合があるため、別のリポジトリで有効だった設定をそのまま適用せず、対象環境で検証します。

ワークフローでは、検査ジョブの後に署名ジョブを置き、後者だけがEnvironmentを参照する形にします。needsはジョブ間の依存関係、environmentは保護ルールを適用する対象、runs-onは実行先の指定です。それぞれの役割が混同されていないか、GitHub Actionsのワークフロー構文で照合してください。

jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - run: echo "本番署名資格情報を使わない検査"

  sign-and-release:
    needs: checks
    runs-on: [self-hosted, production-signing]
    environment: production
    steps:
      - name: 署名と公開
        run: ./ci/sign-and-release.sh

この例は構成の骨格です。production-signingはRunnerに設定したラベルと一致させ、Environment名も実際に作成した名前に合わせます。署名処理が必要とする秘密情報だけを公開ジョブから参照し、検査ジョブへ渡さないようにします。

Environment Secrets、リポジトリSecrets、組織Secretsは、利用できる範囲が異なります。本番署名に使う値をEnvironmentに置けば、保護ルールを通過する前の利用を制限できますが、同じ資格情報を別のスコープにも登録していたら、意図した境界は弱まります。登録場所と参照するジョブを一覧にし、公開ジョブ以外から参照されないことを確認してください。

コード署名では証明書だけでなく、それに対応する秘密鍵も署名身份を構成する要素です。Appleのコード署名証明書に関する技術資料に沿って、証明書と秘密鍵の組み合わせ、Keychainへの取り込み方法、利用を許可する実行主体を記録します。作成、保管、アクセス承認、失効の責任者を定め、担当者が変わったときにどの手順でアクセス権を取り消すかも運用文書に残します。

Environmentの審査はジョブの実行許可を制御しますが、自ホストRunnerの状態まではきれいにしません。永続稼働するMacでは、前のジョブの作業領域や一時ファイルが残る可能性があり、同じホストを別のワークフローで共有する構成では、ジョブ間の影響も評価が必要です。GitHubも、自ホストRunnerが一時的でクリーンな仮想マシン上で動くことを保証していません。自ホストRunnerの追加とセキュリティ上の注意を、ホスト運用の設計に含めてください。

Runner groupのアクセス制御は、どのリポジトリやワークフローにRunnerを利用させるかを管理する要素です。ラベルだけで信頼性を判断せず、組織ポリシー、グループのアクセス範囲、ワークフローのruns-on指定を組み合わせて確認します。Runner groupのアクセス制御を参照し、本番署名ノードに通常の検査ジョブや未信頼のプルリクエストが到達できないことを検証してください。

公開前には、設定画面を見るだけでなく、承認待ち、承認拒否、許可されていないブランチ、発信者自身による承認、管理者による回避、ワークフロー失敗をそれぞれ試験します。どの条件でジョブが停止し、どの条件でRunnerに送られるかを実行記録とともに保存してください。機能の利用条件や画面の表示は変更され得るため、公開時点の公式文書と対象リポジトリの設定を再確認します。

運用前のチェックリスト

• [ ] 検査、ビルド、署名・公開のジョブを分け、本番Environmentは必要なジョブだけに設定しました。
• [ ] 許可ブランチ・タグ、レビュアー、自己承認、管理者の回避条件を社内ポリシーと照合しました。
• [ ] Environment Secretsが承認前に使えず、ほかのスコープに重複登録されていないことを試しました。
• [ ] Runner group、ラベル、runs-onの組み合わせから、未信頼コードが本番ノードへ到達しないことを確認しました。
• [ ] Keychainと署名資格情報の作成、保管、承認、失効、ホスト清掃の担当者を記録しました。
• [ ] 承認拒否、許可外ブランチ、失敗、取消の実行記録を保存しました。

現在の共有CI環境で署名まで行う構成は、署名資格情報を扱うホストと一般ジョブの境界があいまいになりやすく、作業領域の残留やノード障害時の切り分けも負担になります。一方、自社でMacを購入すればホスト管理を直接統制できますが、継続的な保守や利用量の変動への対応は自社負担です。短期の試験導入や独立した署名ノードが必要なら、JEXCLOUDのリモートMacも選択肢になりますが、実際のノード、アクセス方式、受け渡し条件を確認し、物理接続が必要な用途や長期の常時高負荷では購入・自社運用とも比較してください。構成を検討する際はJEXCLOUDの案内と日本向けの利用案内で確認できる条件を照合し、まず本番署名とは独立した試験ジョブで受け入れ可否を判断します。