LASSIC Media らしくメディア
モバイルアプリのCI/CD構築の進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- モバイルアプリのCI/CDは、ビルド・自動テスト・署名・ストア配信までを一連の仕組みとして自動化する取り組みです。
- Xcode Cloud・Bitrise・Codemagic・GitHub Actionsはそれぞれ立ち位置が異なり、Apple純正か、モバイル特化か、Flutterに強いか、汎用CIかで選定基準が変わります。
- 署名・証明書管理とストア配信の自動化範囲は外注先によって差が出やすく、発注前に構築範囲と引き継ぎ資料を確認しておく必要があります。
目次
モバイルアプリのCI/CDとは — ビルド・テスト・配信を自動化する
モバイルアプリのCI/CD（継続的インテグレーション・継続的デリバリー）とは、開発者がコードをリポジトリにプッシュしてから、ビルド・自動テスト・アプリへの署名・TestFlightやGoogle Playへの配信までの一連の作業を、人手を介さずに実行する仕組みを指します。Webアプリケーション向けのCI/CDと基本思想は共通していますが、モバイル特有の制約が加わる点が異なります。iOSアプリのビルドにはmacOS環境が必須であり、配信にはApple・Googleそれぞれの署名・証明書の仕組みへの対応が求められます。
この記事で扱うCI/CDは、fastlaneのようなビルド・署名コマンドを自動化するツール自体の使い方や、GitHub Actionsの実行コスト削減テクニックとは別の論点です。ここでは「どのマネージドCI/CDサービスを選び、どこまでを構築範囲とするか」という、サービス選定と外注時の判断に焦点を当てます。Xcode Cloud・Bitrise・Codemagic・GitHub Actionsは、いずれもクラウド上でビルド環境を提供する点は共通していますが、対応プラットフォームや統合先、料金体系の考え方が異なります。
モバイルアプリの開発チームがCI/CDを導入する動機は、リリース頻度を上げることだけではありません。手作業でのビルド・署名・アップロードは属人化しやすく、特定の担当者のPC環境に依存した状態のまま運用が続くと、その担当者が異動・退職した際にリリース作業自体が止まるリスクを抱えます。CI/CDを構築する目的の一つは、こうした属人化を解消し、誰が実行しても同じ手順で同じ結果が得られる状態を作ることにあります。
一方で、CI/CDは導入して終わりではなく、OSやIDEのバージョンアップに追随し続ける運用が前提になります。iOS・Androidともに年次でメジャーアップデートがあり、ビルド環境や証明書の仕様が変わることも珍しくありません。次章以降では、代表的な4つの選択肢について、それぞれの立ち位置を整理します。
Xcode Cloud — Apple純正のCI/CDとApp Store Connect統合
Xcode CloudはAppleが提供する、XcodeとApp Store Connectに組み込まれたCI/CDサービスです*1。コミットされたコード変更ごとに自動でビルドを実行し、問題が見つかった場合はチームに通知する仕組みが標準機能として用意されています*1。複数のデバイス構成に対して自動テストを並列実行できる点も特徴で、クラウド上のリソースを使って実行時間の短縮を図る設計です*1。
Xcode・App Store Connectとの統合の深さが特徴
Xcode CloudはApple純正であるため、開発者が普段使うXcode上にビルド・テスト結果がライブステータスとして表示され、ビルドタスクをXcode内でフィルタリングして確認できます*1。さらにApp Store ConnectのWebダッシュボードからワークフローの編集やビルドの起動が可能で、Xcodeを開いていない状態でも進捗を追える点は、他の外部サービスにはない統合の深さです*1。TestFlightとの連携も標準機能に含まれており、新しいビルドをテスターへ自動的にインストールし、開発中の機能を含む特定ブランチのビルドを選定したテスターだけに配信するといった運用が可能です*1。
セキュリティ設計とコンピュート時間という考え方
Xcode Cloudでは、すべてのデータが暗号化され、二要素認証によるアクセス保護が行われます*1。ソースコードへのアクセスはビルド実行時に限定され、ビルドが完了すると一時的なビルド環境自体が削除される設計です*1。利用量は「compute hour」という単位で計算され、Apple Developer Programの会員には毎月一定のcompute hourが無償で付与されるほか、追加のcompute hourを購入できる有償プランが用意されています*1。具体的な無償枠の時間数や有償プランの価格は変更される可能性があるため、契約前にApple公式の料金ページで確認するのが確実です。
Xcode Cloudの立ち位置は明確で、iOSアプリ（およびmacOS・watchOS・tvOSアプリ）をApp Store経由で配信する体制において、Appleの純正エコシステムに最も深く統合されたCI/CDという位置付けになります。裏を返せば、Androidアプリの配信には対応しておらず、iOS・Androidを同一のCI/CD基盤で管理したい場合は、後述するBitriseやCodemagicのようなクロスプラットフォーム対応のサービスが選択肢に入ります。
Bitrise・Codemagic — モバイル特化のマネージドCI/CD
Bitriseは「モバイルDevOpsプラットフォーム」を掲げ、iOS・Androidアプリのビルド・テスト・デプロイに特化したサービスです。Jenkins・CircleCIのような汎用CIツールと異なり、macOS環境でのビルド、コード署名の自動化、実機・エミュレータでのテスト、iOS/Androidの技術スタックの頻繁な更新への対応など、モバイル開発固有の課題に向き合う設計になっている点が特徴です*2。中核機能として400以上の事前構築済みStep（CocoaPods、Gradle Runner、fastlane連携など個別タスクの部品）が用意されており、これらを組み合わせてWorkflow（ビルドからテスト、配信までの一連の処理）を構成します*2。対応プラットフォームはiOS・Android本体に加え、React Native・Flutter・Ionic・Cordova・Unityなど幅広いフレームワークをカバーしています*2。
Codemagicはビルド設定の柔軟さとFlutterへの強さが特徴
CodemagicはFlutter・React Native・ネイティブiOS・ネイティブAndroid・Ionic・Unity・MAUIなど、複数のフレームワークとプラットフォームに対応するCI/CDです*3。UIベースの自動プロジェクト設定と、codemagic.yamlというコード形式の設定ファイルによる詳細なワークフロー制御のどちらかを選べる構成になっており、Flutterプロジェクトについては特に自動設定が手厚い点が公式で紹介されています*3。コード署名、新しいアプリバージョンのビルド・アップロード、変更履歴の設定といったリリース工程の自動化が主要な訴求ポイントで、クラウドベースの保守されたインフラを通じて、異なるハードウェア・ソフトウェア構成に即座にアクセスできる点も特徴です*3。GitHub・GitLab・Bitbucket・Azure DevOpsとの連携に対応し、SOC 2 Type 2・ISO 27001・GDPR/CCPAといったセキュリティ認証への対応も明記されています*3。
両者の使い分けの軸
BitriseとCodemagicはどちらもモバイル特化型のマネージドCI/CDという点で共通していますが、強みの重心が異なります。Bitriseは400以上のStepという部品の豊富さと、iOS・Android両方でのモバイルDevOps全般（配信だけでなくテスト自動化やアプリストア運用の最適化まで）を広くカバーする志向が強く、Codemagicはcodemagic.yamlによる設定の柔軟さと、特にFlutterプロジェクトでの自動設定の手厚さを前面に出しています。自社のアプリがFlutterで書かれているか、ネイティブ（Swift/Kotlin）中心かによって、どちらの強みがより活きるかが変わってくるため、選定時にはこの技術スタックとの相性を確認する必要があります。
両サービスともに公式サイトでは無料枠の存在が示唆されているものの、具体的な料金プランの詳細はプライシングページで確認する必要があり、記事執筆時点でトップページに料金表は掲載されていません。契約前には最新のプライシングページを直接確認することが前提になります。
GitHub Actions等の汎用CIをモバイルに使う場合の論点
GitHub Actionsは特定のモバイル用途に限定されない汎用CI/CDサービスですが、GitHubがホストするmacOSランナーを利用することで、iOSアプリのビルド・テストにも対応できます*4。GitHubはAzureのデータセンターでmacOSランナーをホストしており、Ubuntu・Windows・macOSのいずれかを選んでジョブを実行する構成です*4。macOSランナーにはIntel版とarm64版が用意され、公開リポジトリの場合でIntel版が4 CPU・14 GBメモリ、arm64版（M1相当）が3 CPU・7 GBメモリという構成が公式リファレンスに記載されています*5。
汎用CIをモバイルに使う際の論点は署名とコスト構造
GitHub Actionsでモバイル特化型サービスとの違いが最も表れるのが署名まわりです。Bitrise・Codemagicが署名関連のStep・機能をあらかじめ用意しているのに対し、GitHub Actionsでは証明書とプロビジョニングプロファイルをBase64エンコードしてSecretsに保存し、ワークフロー内でキーチェーンの作成・証明書のインポート・プロビジョニングプロファイルの配置までを自前のスクリプトで組む必要があります*6。公式ドキュメントでは、security create-keychainでテンポラリキーチェーンを作成し、security importで証明書を取り込む手順が示されており*6、これらの処理をワークフローファイルに明記する構築作業が発生します。
もう一つの論点はコスト構造です。GitHub Actionsの課金は消費した分数(minute)に基づく仕組みで、macOSランナーで実行したジョブはLinuxランナーよりも高い倍率で分数が消費される仕組みになっています。実際の倍率や単価は変更される可能性があるため、公式の料金ページ・Actions runner pricingのドキュメントで確認する必要があります*7。macOSビルドを頻繁に走らせるプロジェクトでは、この消費レートの違いが運用コストに直結するため、ビルド頻度の設計（プルリクエストごとに実行するか、マージ後のみにするか等）と合わせて検討する価値があります。
汎用CIを選ぶ場合の位置づけ
GitHub Actionsをモバイル用途で選ぶ主な動機は、すでにコードのホスティングとPull Requestベースの開発フローをGitHub上で運用しており、CI/CDだけを別サービスに分離せず同一プラットフォーム内で完結させたい場合です。Web用のバックエンドやその他のCIワークフローと合わせて一元管理できる利点がある一方、モバイル特化型サービスが提供する署名自動化・ストア配信のStepをすべて自前で構築する工数がかかる点は、選定時に織り込んでおく必要があります。この構築工数と、fastlaneなどのコマンド自動化ツールをどこまで組み合わせるかという実装方針は、本稿の主題であるサービス選定とは別に、実装フェーズで詰める論点になります。
| 観点 | Xcode Cloud | Bitrise | Codemagic | GitHub Actions |
|---|---|---|---|---|
| 立ち位置 | Apple純正のCI/CD*1 | モバイル特化DevOps*2 | Flutter等に強いモバイル特化*3 | 汎用CI/CD*4 |
| 対応プラットフォーム | iOS/macOS/watchOS/tvOS*1 | iOS/Android/React Native/Flutter等*2 | iOS/Android/Flutter/React Native等*3 | Linux/Windows/macOS全般*4 |
| 署名・配信の自動化 | TestFlight連携が標準機能*1 | 署名自動化のStepが用意*2 | 署名・ストア公開の自動化を訴求*3 | 証明書の取扱いを自前で構築*6 |
| 設定方法 | Xcode/App Store Connect上のワークフロー*1 | Workflow×Stepの組み合わせ*2 | UIまたはcodemagic.yaml*3 | YAMLワークフロー*4 |
| 料金の考え方 | compute hour単位。公式料金ページで確認*1 | プランはプライシングページで確認*2 | プランはプライシングページで確認*3 | 分数課金。macOSは高い消費レート*7 |
署名・証明書管理とストア配信の自動化
モバイルアプリのCI/CD構築において、ビルドやテストの自動化以上に検討に時間がかかりやすいのが署名・証明書管理の設計です。iOSアプリはApple Developer Programで発行される証明書とプロビジョニングプロファイルによる署名が必須で、これらの有効期限管理や失効対応を誰がどう行うかがCI/CDの安定運用を左右します。
証明書の保管場所と自動更新の仕組み
Xcode Cloudの場合、App Store Connectと統合された環境の中で署名関連の情報が管理される一方、Bitrise・Codemagicでは各サービスが提供する証明書管理機能（暗号化した状態でのアップロード、自動更新のオプションなど）を利用する構成が一般的です。GitHub Actionsのように汎用CIを使う場合は、証明書自体をBase64エンコードしてリポジトリのSecretsに保管し、ジョブの実行のたびにテンポラリなキーチェーンへインポートする手順を自前のワークフローに組み込む必要があります*6。どのサービスを選ぶ場合でも、証明書の有効期限が切れた際にビルドが失敗する事態を防ぐため、期限が近づいたタイミングで通知される仕組みを用意しておくことが望ましいでしょう。
ストア配信の自動化範囲を事前に線引きする
TestFlightやGoogle Playへの配信自動化は、CI/CDサービス側の機能だけで完結する部分と、App Store Connect・Google Play Consoleの管理画面側での手動承認が残る部分に分かれます。Xcode CloudはTestFlightへの自動配信が標準機能として組み込まれていますが*1、審査提出やリリースの最終承認といった工程は別途Apple側の審査プロセスに委ねられます。CI/CDを構築する際は「どこまでを自動化し、どこから先は人が判断するか」という線引きを最初に決めておくと、後から想定外の手動作業が発覚する事態を避けやすくなります。
Androidの配信についても同様で、Google Playへのアップロードを自動化する場合はサービスアカウントの発行・権限設定が必要になり、この設定作業自体はどのCI/CDサービスを選んでも発生します。署名鍵とサービスアカウントの管理主体（開発会社が持つのか、発注企業が持つのか）を契約段階で明確にしておくことが、後述する外注時の論点にもつながります。
外注時に確認すべき構築範囲と引き継ぎの論点
モバイルアプリのCI/CD構築をアプリ開発会社に外注する場合、サービスの選定だけを丸投げにすると、自社の証明書管理体制やリリース頻度と合わないワークフローが構築されてしまう可能性があります。発注前に確認しておきたい論点を3つに整理します。
内製に必要なもの
CI/CD構築を内製で行うには、選定したサービスのWorkflow・Step（またはYAML設定）を書ける人材に加えて、iOS・Androidそれぞれの署名の仕組みを理解している人材が必要です。証明書の発行・更新の運用はApple Developer Program・Google Play Consoleの管理権限とも絡むため、単にCI/CD設定ファイルを書けるだけでなく、モバイルOSベンダー側の管理画面運用まで含めて対応できる体制が求められます。社内にモバイルアプリの署名・配信フローを専門に扱う担当者がいない場合、証明書の期限切れによるビルド失敗のような運用トラブルが後を絶たない状態に陥りやすくなります。
発注先への確認
提案書に「CI/CDを導入します」とだけ書かれている場合、どのサービス（Xcode Cloud・Bitrise・Codemagic・GitHub Actions等）を採用するのか、その選定理由、証明書の保管場所と更新手順、ストア配信のどこまでを自動化しどこから手動承認にするのかを具体的に質問する必要があります。特に証明書やAPIキーといった機密情報の管理方法（誰のアカウントに紐づくか、契約終了後に発注企業側へ移管可能か）は、後々のトラブルを避けるために打ち合わせの段階で解像度を確認しておきたい項目です。
契約明記
開発会社との契約が終了した後、別の会社や自社の内製チームに運用を引き継ぐ可能性がある場合は、CI/CDのワークフロー定義ファイル一式、証明書・プロビジョニングプロファイルの管理主体、各サービスのアカウント権限を納品物・引き継ぎ資料に含めるよう契約段階で明記しておく必要があります。これらが整理されないまま契約が終了すると、後任の担当者が既存のワークフロー設定を1つずつ解析するところから作業を始めることになり、リリース作業が一時的に止まるおそれがあります。
CI/CDは構築して終わりではなく、OSアップデートやツールの仕様変更に応じてワークフローを継続的に見直す運用が前提です。発注時にはこの運用フェーズの体制まで含めて確認しておくことが、長期的な安定運用につながります。
まとめ：モバイルCI/CD構築を機能させる3つの判断軸
本稿では、モバイルアプリのCI/CD構築について、Xcode Cloud・Bitrise・Codemagic・GitHub Actionsそれぞれの立ち位置と、署名・証明書管理、外注時の論点までを整理しました。要点を3つに集約すると次の通りです。第一に、各サービスは代替可能な横並びの選択肢ではなく、Apple純正で統合の深さを取るか、モバイル特化のマネージドサービスで幅広いプラットフォームに対応するか、既存のGitHubワークフローに寄せて汎用CIで構築するかという方向性の違いがあります。第二に、署名・証明書管理の設計はビルド自動化そのものより運用の安定性を左右する要素であり、有効期限管理と機密情報の保管主体を最初に決めておく必要があります。第三に、外注する場合は選定理由の説明を求めるだけでなく、ワークフロー定義・証明書管理・アカウント権限の引き継ぎ範囲を契約に明記する姿勢が、長期的な運用品質を左右します。
よくある質問
Xcode CloudとBitrise・Codemagicはどちらを選べばよいですか。
iOSアプリのみを開発しApp Store Connect中心の運用を想定している場合はXcode Cloudの統合の深さが活きます*1。一方、Android版も同時に開発している、またはFlutter・React Nativeなどクロスプラットフォームで開発している場合は、iOS/Android双方に対応するBitriseやCodemagicが選択肢になります*2*3。自社アプリの技術スタックと配信先プラットフォームの組み合わせで判断する必要があります。
GitHub Actionsだけでモバイルアプリの署名・配信は完結できますか。
技術的には可能ですが、証明書のBase64エンコードとSecrets登録、キーチェーンの作成・削除といった署名関連の処理をワークフローファイル内に自前で組み込む必要があります*6。BitriseやCodemagicのような署名専用のStep・機能が用意されているわけではないため、構築工数はモバイル特化型サービスより多くかかる傾向があります。
fastlaneを使えばCI/CDサービスの選定は不要になりますか。
fastlaneはビルド・署名・アップロードの手順をコマンド化する自動化ツールであり、そのコマンドをどの環境でいつ実行するかを制御するのがCI/CDサービスの役割です。両者は併用されることが多く、fastlaneのコマンド定義とは別に、実行基盤としてXcode Cloud・Bitrise・Codemagic・GitHub Actionsのいずれかを選定する検討は引き続き必要です。
CI/CDサービスの料金はどう比較すればよいですか。
各サービスとも無料枠を用意している一方、具体的な料金額やビルド時間の上限は変更される可能性があるため、契約前に各社の公式料金ページを直接確認する必要があります*1。ビルド頻度・実行時間・並列実行数によって実際のコストが変わるため、自社のリリース頻度を踏まえた見積もりを取ることが望ましいでしょう。
証明書の管理は開発会社に任せてよいですか。
任せること自体は可能ですが、証明書やサービスアカウントの管理主体を契約終了後にどう扱うかを事前に明記しておく必要があります。管理主体が開発会社のアカウントに紐づいたままだと、契約終了時にリリース作業ができなくなるおそれがあるため、発注企業側への移管手順を契約段階で確認しておくことが重要です。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Apple Developer「Xcode Cloud」https://developer.apple.com/xcode-cloud/
- *2 出典：Bitrise公式サイトhttps://bitrise.io/
- *3 出典：Codemagic公式サイトhttps://codemagic.io/
- *4 出典：GitHub Docs「About GitHub-hosted runners」https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners
- *5 出典：GitHub Docs「GitHub-hosted runners reference」https://docs.github.com/en/actions/reference/runners/github-hosted-runners
- *6 出典：GitHub Docs「Installing an Apple certificate on macOS runners for Xcode development」https://docs.github.com/en/actions/how-tos/deploy/deploy-to-third-party-platforms/sign-xcode-applications
- *7 出典：GitHub Docs「Actions runner pricing」https://docs.github.com/en/billing/reference/actions-runner-pricing
