モバイルCI/CDとベータ配信

なぜモバイルのCI/CDは特殊なのか

Webのデプロイが「成果物をサーバーに配置して終わり」なのに対し、モバイルはビルド後に必ず外部ゲートウェイ（App Store Connect／Google Play）を経由し、その先に審査というアプリ側では制御できない工程が挟まる点が決定的に違います。加えてビルドには署名資産が必須で、CI上の一時的な環境にそれを安全に持ち込む必要があります。つまりモバイルのパイプラインは「ビルド」「署名」「配信API呼び出し」「ストア申請」という性質の異なる工程を、再現可能かつ冪等につなぐことが設計の主題になります。署名・プロビジョニングの内部原理そのものは /mobile-development/mobile-app-signing-provisioning/ に譲り、ここではパイプライン設計に焦点を当てます。

Fastlaneの基本モデル：laneとアクション

Fastlaneは、ビルドや配信といった個々の操作を「アクション」として提供し、それを順に並べた手続きを「lane」という単位で定義するツールです。laneは冪等な再実行を意図した手順書であり、CIから呼ばれるエントリポイントになります。

# Fastfile（iOSの例・概念を示す簡略版）
lane :beta do
  increment_build_number(build_number: latest_testflight_build_number + 1)
  build_app(scheme: "MyApp", export_method: "app-store")
  upload_to_testflight(skip_waiting_for_build_processing: true)
end

重要なのは、laneが単なるシェルスクリプトの寄せ集めではなく、状態を持たない再現可能な手続きとして設計される点です。同じコミット・同じ署名資産を与えれば、何度実行しても同じ成果物と同じ配信結果に収束するべきで、ここが崩れると「CIでは通るのにローカルで失敗する」類の不安定さを生みます。

署名資産をCIへ安全に注入する

CIは使い捨ての環境なので、証明書の秘密鍵とプロビジョニングプロファイルを毎回持ち込む必要があります。これを手作業でコピーするのは漏洩リスクも再現性も最悪です。iOS向けにはFastlaneのmatchが定番で、署名資産を暗号化して専用リポジトリ（またはクラウドストレージ）に保管し、CI上で復号して一時キーチェーンへ展開する方式を取ります。

いずれの方式でも原則は共通です。第一に、秘密鍵や復号パスフレーズはコードやログに残さずCIのシークレット機構（環境変数・秘密ストア）経由でのみ渡します。第二に、CI上で作る一時キーチェーンはジョブ終了時に破棄し、ランナーに署名資産を残さないようにします。第三に、対話的なパスワード入力を要求する認証（Apple IDの2要素認証など）はCIで詰まるため、App Store Connect API Keyのような非対話認証へ置き換えます。

ベータ配信：TestFlightと内部テストトラック

ビルドができたら、審査前のテスターへ届ける段階です。ここはコード署名とは別レイヤーの「誰にどの段階で配るか」というガバナンスの問題で、iOSとAndroidで反映速度と審査の有無が異なります。

横にスクロール

パイプライン設計としては、配信先ごとにlaneを分けるのが基本です。日々の開発ビルドは反映の速い内部チャネル（TestFlight内部／Android内部テスト）へ自動配信し、ここは審査を挟まないので短いフィードバックループが回せます。外部テスターやより広いトラックへの昇格は、マージやタグ付けなど明示的なトリガーに紐づけ、対象範囲を段階的に広げます。テスト対象アプリがオフライン同期を持つ場合は、配信したベータ版で /mobile-development/mobile-offline-first-sync/ が扱う競合解決の挙動を実機検証する、といった具合にベータ配信は本番前の最後の実機確認レイヤーとして機能します。

ストア申請の自動化と段階的ロールアウト

本番リリースも、メタデータ登録・スクリーンショット差し替え・審査提出までをAPIで自動化できます。Fastlaneではdeliver（iOS）／upload_to_play_store（Android）が、多言語のメタデータやスクリーンショットをローカルの決められたディレクトリ構造から読み取り、一括で反映します。テキストや画像をGit管理下に置けるため、ストア掲載情報もコードレビューの対象にできるのが利点です。

ただし自動化できるのは提出までです。審査自体は人手のプロセスを含み、所要時間も結果もパイプラインの外側にあります。したがって成熟したパイプラインは「審査提出」と「一般公開」を明確に分けます。Androidの段階的ロールアウト（staged rollout）は公開直後の配信比率を数%に絞り、クラッシュ率などの指標を見ながら比率を上げていく仕組みで、iOSにも段階的リリースの相当機能があります。パイプラインは審査通過後に低い比率で公開を開始し、指標が健全なら比率引き上げ、異常があればロールアウト停止、という制御を担います。

パイプライン全体の設計原則

工程をつなぐと、ビルド → 署名 → テスト → ベータ配信 → 審査提出 → 段階公開という一本の流れになりますが、これを1つの巨大なlaneに詰め込むのは避けます。各工程を独立したlaneに分け、CI側のジョブ依存関係で連結すると、失敗した工程だけを再実行でき、責務も明確になります。

• 早い工程で速く失敗させる：ビルド番号の採番・署名資産の展開・単体テストのような軽い検証を前段に置き、コストの高いアーカイブビルドや配信を後段に回す。
• 配信APIは冪等に扱う：同一ビルド番号の再アップロードは失敗する前提で、リトライ時は採番からやり直すか、既存ビルドの存在を確認してスキップする。
• 回帰の自動検知を挟む：ベータ配信の前段に、起動時間やバイナリサイズの計測を組み込み、/mobile-development/mobile-app-startup-optimization/ で扱うようなパフォーマンス回帰を数値で検知する。
• 人手の判断点を明示する：外部テスター昇格や一般公開の比率引き上げは、自動化しつつも承認ゲート（手動トリガー）を残し、いつでも止められるようにする。

まとめ

モバイルCI/CDは、Webと違ってビルドの先に外部ゲートウェイと審査が必ず控えるという構造上、「ビルド・署名・配信・申請」という性質の異なる工程を再現可能につなぐことが本質です。Fastlaneはこれらをlaneという冪等な手続きに束ね、ビルド番号の単調増加・署名資産の安全な注入・配信APIの一貫した呼び出しを自動化の土台にします。ベータ配信はTestFlightと内部テストトラックを配信先ごとにlaneで分け、審査の有無と反映速度の違いを踏まえて対象を段階的に広げます。ストア申請は提出まで自動化しつつ、審査という外部工程を尊重して一般公開は段階的ロールアウトで制御する——この「自動化できる境界」を正しく見極めた設計が、手作業のリリースにつきまとう属人性と事故リスクを構造的に減らします。