CI/CDexpoグロースOTA アップデートパフォーマンス

2026年にモバイルアプリのCI/CDをどう選ぶか：実用比較

ビルド速度、料金、そしてモバイルチームが実際に気にするポイントで、EAS Workflows、Bitrise、Codemagic、GitHub Actions などの選択肢を比較する。

Expo BlogJon Samp約 16 分

日本語
中文日本語
コピー
Best CI/CD for mobile apps in 2026: a practical comparison

モバイルアプリの構築とリリースにおいて、CI/CD はしばしば問題になる。iOS アプリをビルドして App Store に提出するだけで、500 行を超える YAML を書いているチームも見てきた。

モバイルアプリを継続的にデリバリーするには深いドメイン知識が要る。チームの設定を書き、保守し、改善していく作業は、しばしば専任の仕事になる。

CI/CD サービスはそもそもモバイルアプリ向けに作られたわけではない。何でも動く汎用ツールとして設計されているため、使えはするものの、開発者が慣れ親しんだ作り込まれたツールにはならない。

似たようなことを実現するために、山のような複雑な YAML を何度も組み直している開発者や企業を、私たちは繰り返し見てきた。そこで汎用の CI/CD を作り、その上にモバイル専用の機能を重ねた。CI/CD Workflows なら、10 行に満たない YAML でビルドや提出などができる。時間とともに良くなっていく job もあり、たとえば iOS/Android のビルドキャッシュはビルドを速くする（開発者側の変更は不要）。提供できるものはこれだけではない。詳しく知りたいならドキュメントやブログを見てほしい。

本記事では 2026 年時点で最も有力なモバイル CI/CD の選択肢を比較する。各ツールが何を得意とし、どこが物足りないか、そしてチームと技術スタックに応じてどれを選ぶべきかを明らかにする。Expo はこの競争において利害関係がある。だから偏りはあるが、他のツールが優れている点は正直に書く。

モバイル CI/CD ツールで評価すべきこと

個々のサービスを比較する前に、モバイルチームが実際に気にする機能を挙げておく。

Apple Silicon でのビルド速度。 iOS ビルドはほとんどのチームにとってボトルネックだ。M1 で 20 分かかるビルドと M4 Pro で 6 分のビルドでは、タイトなフィードバックループが得られるか、開発者が別の作業に移ってしまうかの差になる。

コード署名と認証情報。 Android と iOS のコード署名は厄介になりがちだ。service JSON の認証情報や provisioning profile を保管・更新する手間は、チーム全体の足を引っ張る。

ビルド成果物の保存。 ビルドや OTA 更新を終えたら、レビュー担当者に共有するか、アプリストアに提出する必要がある。こうした成果物をどう保存し、どう公開し、どう整理するかは、継続的デリバリーに取り組むチームなら必ず向き合う機能だ。

設定の複雑さと保守コスト。 モバイル専用の job は設定を急速に膨らませる。設定が大きくなるほど、保守し最適化すべき範囲が広がり、バグの入り込む余地も増える。

コスト構造。 課金モデルは分単位、ビルド回数単位、credit 単位とさまざまだ。表示価格だけでは全体像は見えない。1 か月使い込んでみて初めて、実際にいくら払うことになるか分かるサービスもある。

モバイル CI/CD の比較

EAS Workflows（Expo）

EAS Workflows は私たち（Expo チーム）が作ったモバイル CI/CD サービスで、ビルド、提出、OTA 更新、E2E テストなどのプリセット job を備えている。

Workflows の強み：

理想的な CI/CD を組むのは、質が高く手入れの行き届いたレゴブロックを組み合わせ、必要なものだけをぴったり揃えるようなものだ。

たとえば 6 行の YAML で、M4 Pro Apple Silicon 上の iOS ビルドを作れる。さらに job を追加して、完全なビルドが本当に必要かを判定させることもできる。ネイティブ層に変更がなければ、典型的な iOS ビルド時間は約 10 分から 2 分（場合によっては数秒）に縮む。

EAS Workflows は基本的なブロックも、高度に最適化された手順もそのまま使える形で提供する。

設定は簡潔だ。完全な CI パイプラインはこうなる：

name: deploy-to-production

on:
  push:
    branches: [main]

jobs:
  build_ios:
    type: build
    params:
      platform: ios
      profile: production

  upload_to_app_store:
    needs: [build_ios]
    type: testflight
    params:
      build_id: ${{ needs.build_ios.outputs.build_id }}

プリセットの job タイプはどれもモバイル専用だ：build、submit、update、repack、fingerprint、maestro（E2E テスト）、testflight、deploy（Web ホスティング）、そして slack。それぞれがプラットフォーム固有の複雑さを包み込んでいる。

物足りない点：

EAS Workflows は React Native と Expo のプロジェクト向けに設計されている。Swift、Kotlin、Web アプリを作っているなら、他のサービスと大差はない。GitHub Actions や CircleCI の orb のようなコミュニティプラグインもない。

EAS Workflows は無料で試せる。有料プランは月額 $19 から（Starter プラン）で、$45 分のビルドクレジットが付く。本格的に取り組むチームは、$225 分のビルドクレジットと同時ビルド 2 本を含む月額 $199 の Production プランが必要になることが多い。価格の詳細。

向いているチーム： モバイル専用の CI/CD でビルド、提出、OTA 更新の配信まで行いたい React Native / Expo プロジェクト。

Bitrise

Bitrise もモバイルに特化した CI/CD プラットフォームで、iOS、Android、React Native、Flutter などをサポートする。

強み：

Bitrise はモバイル分野で最大のプリセット step ライブラリを持つ。コード署名ウィザード、自動 provisioning、ビジュアル workflow エディタのおかげで、DevOps の経験が深くないチームでも扱える。matrix builds や再利用可能な workflow 設定も用意されている。最近追加された機能には、AI によるビルド失敗の要約や、失敗したビルドを自動修復しようとする auto-fixer がある。

iOS のジョブを実行するとき、Bitrise は M2 Pro マシン（Enterprise プランなら M4 Pro）も提供しているので、ビルドと E2E テストは高速に回る。

対応フレームワークは多く、React Native に限らない。ネイティブ iOS アプリと React Native アプリを並行して開発しているチームなら、Bitrise はその両方を 1 か所で管理できる。

不足している点：

Bitrise には、fingerprinting、repacking、不安定なテストを検出する Maestro のテストインサイトパネルなど、よくある組み込み機能が一部欠けている。しかも最速の Mac ハードウェアを使えるのは Enterprise プランだけだ。

向いているチーム： 複数フレームワーク（ネイティブ + クロスプラットフォーム）にまたがるモバイルプロジェクトを抱え、成熟したエコシステム、ビジュアル workflow エディタ、競争力のある価格を求めるチーム。

Codemagic

Codemagic はもともと Flutter 向けに作られ、その後 React Native、iOS、Android プロジェクトへと対応を広げた。

強み：

Codemagic は M2 と M4 のマシンを提供し、M4 Pro と Max のマシンは上位プラン向けになっている。iOS の自動コード署名はよくできている。

従量課金モデルは小規模チームにとって割安になり得る。固定価格プランも用意していて、使用量が十分あればチームのビルドコストを大きく下げられる。

さらに現在は CodePush にも対応しており、Microsoft が終了した AppCenter の代替サービスを探しているチームには実用的だ。

物足りない点：

fingerprint と repack によるビルドのスキップには対応していないので、新しいビルドが必要かどうかは自分で判断することになる。

向いているチーム： Flutter アプリを使うチーム、またはシンプルでわかりやすい料金体系を求める React Native チーム。

GitHub Actions

GitHub Actions は GitHub を使うチームにとっての既定の CI/CD だ。汎用ツールであり、モバイル専用に設計されたものではない。

優れている点：

コードが GitHub 上にあるなら統合は非常にスムーズだ。Marketplace にはコミュニティが保守する action が数千ある。パイプラインのうちモバイル以外の部分（lint、型チェック、ユニットテスト）では、GitHub Actions に勝るものはなかなかない。

物足りない点：

iOS のジョブは遅い M1/M2 Pro マシンで動くため、ビルドも Maestro テストも余計に時間がかかる。

また GitHub Actions は汎用 CI/CD なので、ビルドや更新、テスト結果などが使いやすいダッシュボードにまとまらない。

それに、私たちの Workflows なら 6 行の YAML で済むことをやるために、GitHub Actions では 80〜150 行の YAML を書いたユーザーもいる。

向いているチーム： すべてを GitHub 内に置いておきたい、パイプラインの保守に手間をかけることを厭わないチーム。モバイルのビルドに別のツールを使っていても、CI のビルド以外の部分には向いている。

CircleCI

CircleCI は汎用 CI/CD プラットフォームで、macOS executor を通じてモバイルにも対応する。

優れている点：

並列化とキャッシュの性能が高い。汎用 CI/CD サービスである以上、モバイルのタスクだけでなくあらゆるタスクを動かすために設計されている。そのために高い同時実行枠を用意しており、大規模チームが複数のパイプラインを同時に走らせやすい。

物足りない点：

GitHub Actions と同様、汎用プラットフォームの上にモバイル対応を載せている形になる。課金も credits 単位なので、1 回の実行にいくらかかったのかを正確に把握するのは簡単ではない。

コード署名、アプリストアへの提出、OTA 更新のためのモバイル専用の抽象化も用意していない。

向いているチーム： すでに CircleCI に投資していて、同じプラットフォームにモバイルビルドも載せたいチーム。

モバイル CI/CD 比較表

機能EAS WorkflowsBitriseCodemagicGitHub ActionsCircleCI
モバイル専用の job/step を内蔵はいはいはいいいえいいえ
iOS job のハードウェアM4 ProM2 Pro（Enterprise は M4 Pro）M2 と M4（最上位プランは M4 Pro と Max）M1 と M2 ProM4 Pro
アプリストアへの提出内蔵 job と提出専用 UISteps ライブラリ内蔵 job自前でスクリプトを書く自前でスクリプトを書く
E2E テスト内蔵 job と insights パネル（Maestro）Steps ライブラリ自前でスクリプトを書く（Detox はドキュメントあり）自前でスクリプトを書くOrbs
設定の複雑さ低い。典型的な job は 10 行未満の YAML。低い。ビジュアルエディタ付き。低い。ビジュアルエディタ付き。高い高い
ビルドのスマートなスキップフィンガープリント + repackいいえいいえいいえいいえ
OTA 更新を内蔵はい。EAS Update に対応。はい。CodePush に対応。はい。CodePush に対応。いいえいいえ
最低価格無料から。以降 $19+/月無料から。以降 $89+/月従量課金、または固定価格 $3990+/年無料。以降 $4〜$21/ユーザー/月 + 分単位の課金無料から。以降 $15+/月

モバイル CI/CD と Web CI/CD の違い

Web 開発から移ってきた人なら、モバイル CI/CD にはレイヤーがいくつか増えることを覚悟しておいたほうがいい。

コード署名は必須。 iOS には provisioning profile と配布証明書が要る。Android には keystore が要る。これらをチームで管理し、常に最新に保つには工数がかかる。

iOS のジョブには macOS ハードウェアが要る。 ここは回避できない。iOS ビルドごとに macOS ワーカーが1台必要になる。Linux ベースの Web ビルドと比べて、CI が高くつき、遅くなる。

アプリストアへの申請自体が1つのデプロイ工程。 Web のデプロイは通常 CDN へのプッシュで済む。モバイルのデプロイはメタデータ、スクリーンショット、審査ガイドライン、審査キューが絡んでくる。この流れを自動化し、さらに OTA 更新で JavaScript レイヤーの変更を素早く反映できれば、かなりの時間を節約できる。

チームに変更をプレビューしてもらうには、まずビルドが必要。 Web アプリならプレビューリンクを生成してレビューしてもらうのは比較的簡単だ。モバイルは違う。ビルドを作るか、OTA 更新を配信するか、あるいはその両方が要る。さらにチームメンバーを Play Console/TestFlight に追加したり、ad-hoc プロビジョニングプロファイルでデバイスを事前登録したりする必要もある。こうした余分なステップが積み重なり、チームのコミュニケーションコストを押し上げる。

fingerprint と repack で不要なビルドをスキップする

試す価値のある手法が fingerprint ベースのビルドスキップで、EAS Workflows がネイティブにサポートしている。ほとんどのコミットはプロジェクトの JavaScript レイヤーだけを変更し、ネイティブ依存は変わらない。ネイティブレイヤーが変わっていなければ、フルビルドをスキップして、以前のネイティブバイナリに新しい JavaScript バンドルを再パックすればいい。

このワークフローこそ、多くの GitHub Actions ユーザーが EAS Workflows に乗り換えた理由だ。既存の CI パイプラインを置き換えるつもりのなかったクライアントが Workflows を使い始めたケースもある。fingerprint と repack による効率の改善がそれだけ大きいということだ。

repack はおよそ2分、フルビルドは10〜15分かかる。1日に20回ビルドするチームなら、ビルド時間を毎日およそ3〜4時間節約できる計算になる。

Infinite Red は多くのクライアントでこの仕組みを導入し、CI 時間を半分に削減した。

jobs:
  fingerprint:
    type: fingerprint

  get_build:
    needs: [fingerprint]
    type: get-build
    params:
      fingerprint_hash: ${{ needs.fingerprint.outputs.ios_fingerprint_hash }}
      platform: ios

  repack:
    needs: [get_build]
    if: ${{ needs.get_build.outputs.build_id }}
    type: repack
    params:
      build_id: ${{ needs.get_build.outputs.build_id }}

  build:
    needs: [get_build]
    if: ${{ !needs.get_build.outputs.build_id }}
    type: build
    params:
      platform: ios
      profile: production

上のワークフローはネイティブレイヤーが一致する既存ビルドを探し、見つかれば新しいビルドを自動で作成する。ただしビルドするのは JavaScript レイヤーだけだ。コードの変更がネイティブレイヤーに及ぶ場合はフルビルドにフォールバックする。他のモバイル CI/CD ツールにはこの機能が組み込まれていない。

モバイル CI/CD サービスの選び方

判断材料はいくつかある。プロジェクトのフレームワーク、すでに使っている CI プラットフォームがあるか、CI/CD パイプラインにどれだけ開発時間を割けるか。

React Native/Expo で開発していて、ビルド、OTA 更新、E2E テスト、fingerprint と repack による高速化、アプリストアへの提出までを 1 つのサービスでまかないたいなら、EAS Workflows を選ぶ。

ネイティブアプリとクロスプラットフォームアプリを同時にリリースしていて、最も充実した step ライブラリと、深い DevOps の知識がなくてもチームが使いこなせるビジュアルエディタが欲しいなら、Bitrise を選ぶ。ただし最速のハードウェア（M4 Pro）は Enterprise 版限定だ。

Flutter で開発していて、CLI 駆動の CodePush による OTA で構わないなら、Codemagic を選ぶ。

コードとその他の CI がすでに GitHub 上にあり、ベンダーを増やすよりもモバイルのパイプラインを自分たちで保守したいなら、GitHub Actions を選ぶ。macOS が分単位の課金であることと、80〜150 行の YAML を書くことを受け入れられる場合に限る。

注意：EAS Workflows は GitHub Actions と併用できる。これは顧客の間でよく見られる構成で、たいていは fingerprint + repack というユースケースの価値に気づいたチームが導入する。

すでに CircleCI でバックエンドや Web を動かしていて、モバイルも同じプラットフォームに載せて credit プールを共有したい、大規模チーム向けの強い並列実行能力も必要だというなら、CircleCI を選ぶ。

EAS Workflows から始める

npx eas-cli@latest workflow:create を実行して最初の workflow を作成する。

次に eas workflow:run workflow-file-name.yml を実行する。

サンプル workflow では、よくあるパターンを押さえている。PR プレビュービルド、本番デプロイ、スケジュールビルド、Maestro による E2E テストだ。

迷ったらドキュメントを読むか、Expo Discord の #eas チャンネルで他の開発者と話してみるといい。チームもコミュニティも力になってくれる。Expo プロジェクト向けの YAML を書いたり修正したりするのに使える CI/CD Workflows Skill も用意している。

CI/CD よくある質問

モバイルアプリ開発における CI/CD パイプラインとは？

CI/CD パイプラインは、モバイルアプリのビルド、テスト、デプロイを自動化する。コードをプッシュすると、パイプラインが iOS と Android 向けにアプリをコンパイルし、テストを実行し、App Store や Google Play への提出までこなす。CI/CD がなければ、これらの作業はすべて手作業になり、遅くてミスも多い。

モバイルの CI/CD は Web の CI/CD と何が違う？

モバイルのほうが難しい点は 3 つある。1 つ目は、iOS のビルドには macOS ハードウェアが必要で、CI インフラのコストが跳ね上がる。2 つ目は、どちらのプラットフォームもコード署名を必須とすること（iOS は provisioning profile、Android は keystore）。3 つ目は、デプロイが CDN への公開ではなく、アプリストアの審査を経由することだ。

モバイル CI/CD パイプライン構築で最大の課題は？

コード署名と証明書の管理が最も厄介だ。次に、共有 macOS runner 上での遅いビルド、プラットフォーム固有のビルド設定の管理、アプリストア提出の自動化の複雑さが続く。EAS Workflows、Bitrise、Codemagic を使うチームは、こうした問題をほぼ回避できる。プラットフォーム側が処理してくれるからだ。

モバイルアプリ向けの無料 CI/CD ツールはある？

GitHub Actions は公開リポジトリなら無料（基本的な M1/Intel macOS マシン）、プライベートリポジトリにも無料枠がある。EAS Workflows、Bitrise、Codemagic も無料プランを用意しているが、ビルド時間に上限がある。本格的なプロジェクトなら、プラットフォームとビルド量に応じて月 19〜299 ドルを見込んでおくといい。

React Native や Expo アプリに最適な CI/CD は？

EAS Workflows は React Native と Expo のために作られている。1 つの YAML 設定でビルド、OTA アップデート、アプリストアへの提出、repack と fingerprinting、E2E テストを処理し、コード署名もマネージドで提供する。Bitrise と Codemagic も React Native をサポートするが、同じパイプラインを組むには設定量がはるかに多くなる。

Android と iOS の CI/CD はどう違う？

iOS のビルドには Xcode を入れた macOS と、Apple 特有のコード署名（provisioning profile、distribution certificate）が必要だ。Android のビルドは Linux 上で Gradle を使って動き、署名には keystore を使う。ほとんどのモバイル CI/CD ツールは両プラットフォームを並行して実行し、パイプライン全体の時間を短縮する。

出典: Expo Blog← ホームへ戻る