Kotlin Multiplatform iOS CI：2026年はレンタルか自前構築か？

PRは通るのにiOSアーカイブだけ失敗し、TestFlight公開時には署名資格情報とMacの空き容量が問題になります。
最短解は、共有Kotlinの検証と標準的なiOSビルドをホスト型macOS Agentへ、製品署名・私網依存・固定Xcodeが必要な処理を専用の遠隔Macへ分けることです。負荷が変動するなら、固定した本番基盤に弾力的な実行環境を加える混合構成を選んでください。

この解説は、Kotlin MultiplatformのiOSリリースパイプラインを整備するプラットフォームチーム、署名資格情報やソースコードの境界を管理するIT・セキュリティ担当者向けです。
Macの保有費用だけでなく、ビルド待ち時間、復旧作業、Xcode更新時の停止リスクまで比較したい技術責任者にも適しています。

最初の判定：PRのコード検証だけならMacを占有させないでください。Appleターゲットの生成物を確認するジョブから、macOS実行環境の要否を判定します。

SECTION 01まず負荷を4つのシナリオに分ける

Kotlin Multiplatformでは、共有コードのテストとiOSアプリの完成品検証を同じジョブに詰め込むと、Macの使用時間と障害範囲が不必要に広がります。Kotlin公式のiOS CI/CD手順でも、iOS向けビルド、署名、公開はmacOSを前提にした流れとして説明されています。公式のiOS CI/CD手順を基準に、次のように分解します。

• 共有Kotlinの検証：静的解析、共通テスト、依存関係の確認。Apple固有の成果物を保証する処理ではありません。
• iOS frameworkのコンパイル：iosArm64など実機向けのターゲットを生成します。Kotlin公式のNativeバイナリ生成に関する説明に沿って、対象と成果物を分けて管理します。
• シミュレーター検証：iosSimulatorArm64など、シミュレーター用の成果物と実機向け成果物を混同しません。
• アーカイブと署名：Xcode、Keychain、証明書、App Store Connectの権限を扱います。
• 私網依存を含むビルド：社内リポジトリ、制御された出口、社内制品庫へ接続します。

したがって、「Kotlin MultiplatformのビルドはすべてMacが必要」という判断も、「共有Kotlinが通ればiOSリリースも安全」という判断も不正確です。どの段階でAppleのツールチェーンと署名境界に入るかを先に記録してください。

SECTION 02PR検証ではMacの占有範囲を狭くする

プルリクエストごとにXcodeビルド、シミュレーター起動、署名処理まで実行すると、変更量の少ない検証でもmacOS Agentのキューを消費します。共有モジュールのテスト、コードフォーマット、依存関係のロック確認を先に実行し、Appleターゲットを生成するジョブだけを後段へ送る構成が扱いやすいです。

ホスト型Agentは、標準イメージと一時的な並列実行を使いやすい一方、Xcodeの細かな版、キャッシュ、シミュレーター状態を長期間固定できるとは限りません。対して専用の遠隔Macは、Xcodeとキャッシュを管理しやすいものの、アイドル時間も含めたノード維持、更新、再起動、監視を担当する必要があります。

検証結果を過大評価しない

共有Kotlinのテストが成功した結果は、共通ロジックの回帰が見つからなかったことを示します。しかし、それだけではiOS frameworkのリンク、Xcodeプロジェクトの設定、実機向けアーカイブ、TestFlightへ送る署名済み成果物の成立までは証明できません。

iosArm64とiosSimulatorArm64は目的が異なるため、片方だけを通して本番投入可能と判断しないでください。ターゲットごとの成功条件をCIのアーティファクト名とログに残すと、レビュー時に「何が確認済みか」を説明できます。

SECTION 03シミュレーターとXcode固定環境は別の判断にする

シミュレーター検証は、画面遷移やOS APIの組み合わせを確認するための処理です。実機配布用アーカイブの代替ではないため、シミュレーター用バイナリが成功しても、署名、Provisioning、アーカイブの検証は別ジョブで必要です。

Xcode 27については、Appleのシステム要件ページでbetaとして扱われている状態です。AppleのXcodeシステム要件にある現行の状態をリリース前に確認し、beta版を本番の唯一のビルド環境にしないでください。正式版への移行時期や、ホスト型Agentのイメージ更新日を未確認の情報から推測するのも避けます。

専用の遠隔Macを使う場合は、次の項目を受け入れ試験に含めます。

1. 対象XcodeとKotlinのバージョンを固定し、起動後に実際のバージョンを出力します。
2. iosArm64とiosSimulatorArm64を個別に生成し、成果物を取り違えないことを確認します。
3. シミュレーターの起動、テスト、終了を無人実行できるようにします。
4. Derived Dataや依存キャッシュを削除した状態でも再現できるか確認します。
5. ノード再起動後にSSH、CI接続、ディスク容量監視が自動復旧するか確認します。
6. 失敗時にログ、アーティファクト、終了コードを収集し、資格情報を記録しないことを確認します。

運用上の注意：キャッシュがある状態でだけ通るビルドは、環境固定の証拠ではありません。定期的にクリーンビルドを実行し、キャッシュ依存を検出してください。

SECTION 04TestFlight公開では「成功」より資格情報の流れを見る

TestFlightへの公開は、ビルドが完了したかだけでなく、誰がどの資格情報をどのノードへ渡したかで安全性が決まります。Appleが案内するApp Store Connectへのビルドアップロード手順を基準に、公開ジョブをPR検証から分離してください。

推奨する流れは次のとおりです。

1. PRジョブでは署名なしのビルド、または署名不要の検証だけを行います。
2. 承認済みのリリース操作でのみ、App Store Connect API keyを取得します。
3. Distribution certificateと秘密鍵は、本番公開ノードの専用Keychainに限定します。
4. ビルド中だけ資格情報を読み込み、環境変数、標準出力、アーティファクトへ出さないようにします。
5. アップロード後に一時ファイル、Derived Data、エクスポート設定を消去します。
6. 失敗時は公開権限を広げず、ログとジョブ単位の監査記録を確認します。

GitHub Actionsを使う場合も、安全な利用に関する公式ガイドの権限分離を適用してください。デプロイ承認や環境保護を設定できる場合は、デプロイメント制御の公式仕様も確認します。

本番署名をホスト型Agentで行うこと自体が直ちに不可能という意味ではありません。ただし、多数のアプリで証明書を共有する、長期鍵を保持する、データの保管場所を限定する、操作証跡を細かく残す、といった要件がある場合は専用の遠隔Macを優先候補にしてください。

SECTION 05私網依存があるなら、接続できることを安全と誤認しない

内部Gitリポジトリ、制品庫、企業プロキシ、固定IPの許可リストがあると、実行ノードの選択はCI料金だけでは決まりません。ホスト型Agentが社内ネットワークやデータ保管要件を満たさない場合、資格情報の権限を拡大して無理に接続する設計は避けます。

専用の遠隔Macへ接続する場合は、次の境界を別々に確認してください。

• CIサービスからMacへ入る経路と、Macから社内資源へ出る経路。
• 開発者の対話アクセスと、CIサービスの無人実行アカウント。
• リポジトリのワークスペース、ビルドキャッシュ、署名用Keychain。
• ジョブ終了後の作業領域削除、ログ保管、緊急時のアカウント停止。

自前Runnerの登録や更新には、セルフホストRunnerの公式仕様にある運用条件を確認します。ホスト型Runnerとの違いは、単にCPUやメモリの差ではなく、パッチ適用、常駐資格情報、ネットワーク境界、障害復旧を自分で引き受ける点にあります。

SECTION 06第1段階：固定基盤と弾力容量を分けて見積もる

容量は、平均的な一日のジョブ数だけで決めないでください。通常のPR検証、リリース直前の集中実行、ノード障害、Xcode更新の試験というシナリオごとに、同時実行数、許容待ち時間、復旧目標、必要なキャッシュを記録します。

料金を比較するときは、次の変数だけを使って計算します。

• ホスト型Agent：ジョブ実行時間 × 単価 × 実行回数
• 専用Mac：レンタルまたは購入費 + 保守工数 + 監視費 + 障害時の停止影響
• 混合構成：固定署名ノード費用 + 弾力Agent費用 + 接続・監査費用

公開価格や構成は契約地域と時期で変わるため、ここでは金額や節約率を断定しません。MACNOXの日本語料金ページで候補を確認したうえで、あなたの実際のキュー時間、再実行回数、復旧作業を式へ入れてください。

SECTION 07シナリオ別の最終判定表

ホスト型macOS Agentは、標準化されたPR処理と一時的なピーク吸収に向きます。専用の遠隔Macは、固定Xcode、私網依存、署名資格情報、復旧手順を一つの管理対象へまとめたい場合に向きます。

SECTION 08導入時に残すべき交付記録

試験運用では、単に「ビルドできた」と記録しないでください。次の順で証拠を残すと、容量追加や構成変更の判断がしやすくなります。

1. シナリオごとにMac必須ジョブと非必須ジョブを分類します。
2. 対象Xcode、Kotlin、SDK、依存関係の解決結果を保存します。
3. 実機向け、シミュレーター向け、署名済み成果物を別々に検証します。
4. API key、証明書、Keychainの保管場所と取得者を台帳化します。
5. 私網接続、出口制御、ログの保管期間をセキュリティ担当者と確認します。
6. ノード停止、再起動、資格情報撤回、ジョブ再実行を実施します。
7. 通常時とピーク時の待ち時間、失敗原因、復旧に要した作業を容量表へ反映します。

よくある判断への回答

FAQでは、Kotlin Multiplatform iOS CIの選択を「Macがあるかどうか」だけで決めないことが重要です。共有コードの検証、Appleターゲット、公開権限、社内接続を別の信頼境界として扱えば、ホスト型と専用ノードの役割が明確になります。

SECTION 09現在の構成からMACNOXを試すべき場面

すでに自社Macを保有している場合でも、ピーク時にキューが伸びる、Xcode更新の試験用環境を確保できない、障害復旧を担当する人が限られる、といった問題が残ることがあります。購入したMacを常時稼働させる構成は、低稼働時間の費用、故障時の交換、固定ネットワークや遠隔復旧の運用を引き受ける点が弱みです。

一方、ホスト型Agentだけに寄せると、固定したXcodeや私網境界、長期的な署名隔離を満たしにくい場合があります。そこで、まずMACNOXの日本語の申込み案内から専用の遠隔Macを試験用に確保し、あなたのKotlin Multiplatform iOS CIで実際のキュー、署名、再起動、復旧記録を取得してください。金額の比較はその記録を基準に行うのが、購入かレンタルかを誤らない進め方です。