LASSIC Media らしくメディア

2026.06.24 らしくコラム

fastlaneでアプリのビルド・ストア配信を自動化する外注の進め方

LASSIC IT事業部|元請(プライムベンダー)としてシステム保守・運用を受託

mobile app deployment

この記事のポイント

  • fastlaneはiOS/AndroidのリリースエンジニアリングをOSSで自動化するツールで、match(証明書管理)・gym(ビルド)・deliver(App Store申請)・supply(Google Play申請)・pilot(TestFlight)を組み合わせてlaneとして一括実行できます
  • 外注で自動化を進める場合は「現行リリース作業の棚卸し→match設計→lane作成→CI/CD連携→運用引継ぎ」の5フェーズが基本構成で、証明書管理とセキュリティ設計が成否を左右します
  • Apple/Googleの仕様変更が定期的に発生するため、lane設計・CI/CD構築だけをスポット委託するか、継続運用まで含めて委託するかを、チームの内製能力と照らして判断することが大切です

fastlaneとは — iOSとAndroidのリリース工程を自動化するOSS

app store automation

fastlaneとは、iOS/Androidアプリのリリースエンジニアリング(証明書・プロビジョニングプロファイル管理、ビルド/アーカイブ、ベータ配信、ストア申請、ビルド番号管理)を自動化するオープンソースのツールです*1。開発チームが毎リリースごとに手動で行っていたXcodeでのアーカイブ操作・証明書の再発行・ストアへのバイナリ提出を、コマンド1つで再現可能な形に置き換えられます。

手動リリース(Before) Xcodeで証明書更新 手動アーカイブ/アップロード メタデータを個別入力 属人化・ミスリスク・時間コスト大 自動化 fastlane(After) match で証明書を一元管理 gym でビルド/アーカイブ deliver/supply でストア申請 CI/CDから再現可能・属人化解消
図:手動リリース作業とfastlane導入後の比較

fastlane公式によると、fastlaneは各リリース作業を「action」という単位で提供しており、複数のactionを「lane」としてまとめてCI/CD(GitHub Actionsなどの継続的インテグレーション/継続的デリバリー)から呼び出す構成をとります*1。開発者はFastfileと呼ばれる設定ファイルにlaneを定義し、チームで共有します。

リリース作業の属人化は、担当者不在時にリリースが止まるリスクを生みます。fastlaneによる自動化は属人化の解消だけでなく、ビルド設定のミスや証明書期限切れによるリリース失敗の防止にも寄与します。

fastlaneが自動化する主なリリース工程

fastlaneが対象とするリリースエンジニアリングの工程は幅広く、iOSでは証明書・プロビジョニングプロファイルの管理と更新、アプリのビルドとアーカイブ、TestFlightへのベータ配信、App Storeへの審査申請・メタデータ更新が含まれます。Androidでは対応するGoogle Playへの申請・APK/AABのアップロード・メタデータ管理が対象です*1

加えて、ビルド番号の自動インクリメントや、スクリーンショットの自動撮影と多言語対応なども対象actionとして用意されています。これらをlaneに組み合わせることで、リリース前後の反復作業をほぼすべて自動化できます。

主要action — match/gym/deliver/supply/pilotとlaneの考え方

fastlane公式によると、リリース自動化で中心となるactionはmatch・gym・deliver・supply・pilotの5つです*1。それぞれの役割を理解したうえでlaneに組み合わせることが、fastlane導入の出発点になります。

match — 証明書とプロビジョニングプロファイルのチーム共有管理

matchは、iOSの開発・配信用証明書(Distribution Certificate)とプロビジョニングプロファイルを、GitリポジトリやGoogle Cloud StorageなどのストレージにOpenSSL暗号化して保存し、チーム間で共有管理するactionです*1。新しいメンバーが参加したとき、またはCIサーバー上でビルドを行うときに、matchコマンド1つで正しい証明書セットを取得・インストールできます。

なお、fastlane公式によると、2025年5月にAppleが対応を終了したため、matchの「managed capabilities」機能(App IDのケーパビリティ自動同期機能)は廃止されました*1。現在のバージョンでは、Push NotificationsなどのケーパビリティはXcodeまたはApple Developer Portalから手動設定する運用が必要です。バージョン依存の細かな挙動については、最新のfastlane公式ドキュメント(docs.fastlane.tools)でご確認ください。

gym — ビルドとアーカイブの自動化

gymはiOSアプリのビルド(xcodebuildラッパー)とアーカイブを自動化するactionです*1。ビルド設定(スキーム・エクスポート方式・コード署名設定)をFastfile内で一元管理できるため、開発者ごとにXcodeの設定が異なることで起きるビルドエラーを防げます。AndroidのビルドはGradleタスクをfastlaneから呼び出す形で対応できます。

deliver — App Storeへの申請とメタデータ管理

deliverはバイナリのApp Storeへのアップロード、スクリーンショット・説明文などのメタデータ更新、審査申請を自動化するactionです*1。メタデータをローカルのテキストファイルとして管理できるため、バージョン管理システムで変更履歴を追跡しながら多言語対応を進められます。

supply — Google Playへの申請

supplyはGoogle PlayへのAPK/AABアップロード・メタデータ更新・リリーストラック管理(internal/alpha/beta/production)を自動化するactionです*1。deliverのAndroid版に相当する役割を担い、iOS/Androidの申請作業を1つのFastfileで統一して管理できます。

pilot — TestFlightによるベータ配信

pilotはTestFlightへのビルドアップロードと、テスターへの配信管理を行うactionです*1。社内QAや外部ベータテスターへの配信トリガーをCI/CDのブランチプッシュと連動させることで、ベータ版の配信サイクルを自動化できます。

laneの考え方 — actionを組み合わせて工程を定義する

fastlaneではFastfileにlaneを定義することで、複数のactionを順番に呼び出すワークフローを作成します。たとえば「betaリリースlane」としてmatch→gym→pilotを順に実行するlaneを定義しておけば、`fastlane beta` の1コマンドでベータ配信が完了します。

「本番リリースlane」ではmatch→gym→deliverを並べ、ビルド番号のインクリメントやリリースノート更新もlane内に組み込めます。iOS用laneとAndroid用laneを同一Fastfileに共存させ、CI/CDのトリガーから選択実行する構成が標準的です。

配信自動化を外注で進める5フェーズ

fastlaneを用いたリリース自動化を外注で進める場合、「現状棚卸し→match設計→lane作成→CI/CD連携→運用引継ぎ」の5フェーズが基本構成になります。各フェーズで確認すべきポイントを整理します。

フェーズ 主な作業内容 委託判断のポイント
1. 現状棚卸し 手動リリース手順の文書化・証明書の整理・既存CI/CDの確認 社内知識が分散している場合はインタビュー込みで委託が有効
2. match設計 証明書ストレージ選定・暗号化パスフレーズ設計・アクセス権設計 セキュリティ要件の高い工程。match経験のある委託先を選ぶ
3. lane作成 Fastfile作成・iOS/Android各laneの定義・ローカル動作確認 gym/deliver/supplyの組み合わせが固まるまで密な確認が必要
4. CI/CD連携 GitHub Actions等へのfastlane呼び出し設定・シークレット管理 CI/CD基盤の知識も必要。内製CI担当との協働体制を整える
5. 運用引継ぎ 運用ドキュメント作成・証明書更新手順の引継ぎ・トラブル対応訓練 継続運用委託か内製引継ぎかを発注前に方針確定させる

フェーズ1:現行リリース作業の棚卸し

外注で自動化を進める前に、現在チームが手動で行っているリリース作業を文書化します。証明書の保管場所と更新担当者、Xcodeでのアーカイブ手順、App Store ConnectやGoogle Play Consoleへのログイン情報の管理方法などを洗い出します。棚卸しが不十分なまま発注すると、委託先が現状把握に時間を取られて工期が延びる原因になります。

この段階で「どの作業が最も時間・工数を取っているか」「どの作業でミスが発生しやすいか」も整理しておくと、自動化の優先順位が明確になります。証明書の期限管理に追われているケースでは、matchのセットアップを最初のスコープとして発注することが有効です。

フェーズ2:証明書管理(match)の設計

matchの設計では、証明書を保管するストレージの選定が最初の判断点になります。fastlane公式が推奨するプライベートGitリポジトリのほか、Google Cloud StorageやAmazon S3を使うオプションもあります*1。どのストレージを選ぶかはセキュリティポリシーとCI/CD環境の組み合わせで判断します。

暗号化パスフレーズはCI/CDの環境変数(シークレット)として管理し、Fastfileに平文で書かない設計にします。複数チーム・複数アプリが1つのApple Developer Accountを共有する場合は、matchのapp_identifierとtypeの設計が複雑になるため、経験のある委託先に設計段階から関与してもらうことを検討してください。

フェーズ3:ビルドと配信laneの作成

lane設計では、iOS/Androidそれぞれのリリーストラック(TestFlight/internal beta/App Store本番など)に対応したlaneを定義します。gymbuildの設定(Xcodeスキーム・export_method・コード署名設定)はアプリ固有の情報が多く、既存のXcodeプロジェクト構成を正確に理解したうえで書く必要があります。

lane作成後は実際のアプリのリポジトリでローカル動作確認を行います。初回は証明書取得エラー・ビルド設定ミス・fastlaneのバージョン不一致など複数の問題が同時に発生することがあります。委託先がiOS/Android両方の実機ビルド経験を持っているかを事前に確認してください。

フェーズ4:CI/CD(GitHub Actions等)との連携

laneをローカルで動かせた後は、CI/CDパイプラインからfastlaneを呼び出す設定を行います。GitHub Actionsではワークフローファイル(YAML)にmacOS環境を指定し、Rubyとfastlaneのセットアップステップとfastlane laneコマンドを記述します。シークレット(matchパスフレーズ・App Store Connect APIキーなど)をGitHub Secretsで管理する設計が標準的です。

CI/CD連携ではApple Developer ProgramのApp Store Connect APIキー(JWT形式)の発行と設定も必要です。このキーの発行には組織のApple Developer Programの管理者権限が必要なため、外注開始前に権限確認と委託範囲の合意を行っておきます。

フェーズ5:運用引継ぎと継続保守の判断

fastlaneのセットアップが完成したら、運用ドキュメントの整備と引継ぎを行います。証明書の年次更新手順・fastlaneのバージョンアップ手順・Apple/Googleストアの仕様変更があった場合の対応フローを文書化します。内製エンジニアが引き継げるかどうかを発注前に判断しておくことが、運用フェーズのコストを左右します。

fastlaneはApple/Googleの審査API・証明書API・ストア申請APIと密接に連携しているため、プラットフォーム側の仕様変更(2025年5月のmanaged capabilities廃止のような変更)が定期的に発生します。継続的に追従対応を行えるエンジニアをアサインするか、外注に継続保守を委託するかを方針として決めておくことが大切です。

導入時の注意点 — 証明書管理・セキュリティ・Apple/Google仕様変更への追従

fastlaneの導入では、リリース自動化の恩恵を得る反面、適切に設計しないと新たなリスクを生む領域があります。特に証明書管理とセキュリティ設計は、外注で進める場合にも発注者側が理解しておくべき重要事項です。

証明書と署名の管理:誤設定が招くリリース停止リスク

iOSのコード署名は、Distribution Certificate・Provisioning Profile・App IDの3つが正しく紐付いていないとビルドが通りません。matchを使って証明書を一元管理する設計にすれば個人の証明書への依存を解消できますが、matchの初期設定が誤っているとCI/CD上でのビルドがすべて失敗する状態になります。

証明書の期限管理も見落としが起きやすい領域です。iOSのDistribution Certificateは1年で失効します。期限切れに気づかずリリース直前にビルドが止まると、審査期間も考慮してリリース日程に支障をきたします。matchのrenew_certificateオプションで自動更新の設定を行い、期限切れの検知をCI/CDのアラートに組み込む設計が推奨されます。

シークレット管理の設計ミスが引き起こすセキュリティリスク

matchのパスフレーズ・App Store Connect APIキー・Google Play JSONキーをFastfileやワークフローYAMLにハードコードすることは厳禁です。これらをGitHub SecretsやCI/CDプラットフォームのシークレット機能に格納し、コードには環境変数名だけを記述する設計にします。外注で設定する場合も、発注者がシークレットの格納操作を行い、委託先には変数名だけを共有する運用がリスクを低減できます。

また、matchが証明書を保管するリポジトリのアクセス権限は最小化します。CI/CDサービスアカウントに対してはリードオンリーのアクセスのみを付与し、証明書の追加・更新は権限を持つ担当者が手動で行う運用が標準的です。

Apple/Google仕様変更への追従:2025年5月の廃止例から学ぶ

fastlaneはAppleとGoogleの公開APIに依存しているため、プラットフォーム側の変更がfastlaneの動作に影響します。2025年5月にはApple側の対応終了によりmatchの「managed capabilities」機能が廃止されました*1。これは、matchがApp IDのケーパビリティ(Push NotificationsやApp Groupsなどの機能権限)をApple Developer Portalと自動同期する機能でしたが、現在はXcodeまたはApple Developer Portalから手動で設定する運用が必要です。

このような仕様変更はAppleのWWDC発表・fastlaneのCHANGELOGおよびGitHub Issuesで確認できます。fastlaneをCI/CDに組み込んでいる場合、定期的なバージョンアップと変更内容の確認を継続的に行う体制が必要です。内製での追従が難しい場合は、継続保守を外注する選択肢を検討する必要があります。

内製で導入する場合に必要な知識・工数の目安

fastlaneのセットアップを内製で完結させるには、iOS/Androidの両プラットフォームのコード署名の仕組み、Rubyの基礎知識(fastlaneはRubyで記述)、CI/CDツール(GitHub Actions等)の設定、Apple Developer ProgramとGoogle Play Consoleの管理者操作の4領域の知識が必要です。これらをすべてカバーできるエンジニアが社内にいない場合、初期セットアップだけで予想以上の工数がかかることがあります。

fastlaneを初めて導入するチームでは、環境依存の問題解消・ドキュメント読み解き・試行錯誤を含め、初回セットアップに数日から数週間かかるケースも珍しくありません。この工数を外注に委ねることで、本業の開発に集中できる時間を確保できます。

外注の使いどころ — lane設計・CI/CD構築・運用の委託判断軸

fastlaneを外注で進める場合、「どの工程をどの契約形態で委託するか」を事前に判断することが費用対効果に直結します。委託範囲と内製能力を照らして判断するための3つの軸を整理します。

スポット委託が向いているケース

fastlaneの初期セットアップ(match設計・Fastfile作成・CI/CD連携)は作業スコープが明確であり、請負契約でスポット委託しやすい工程です。社内にiOSエンジニアが在籍しているが証明書管理やCI/CD設定の経験がない、またはfastlane導入の初期調査に工数を割けない場合はスポット委託が向いています。

成果物として「動作するFastfile」「CI/CDのワークフローYAML」「運用ドキュメント」を納品物として指定し、内製エンジニアへの引継ぎセッションを含むスコープにすることで、委託後の内製運用に移行しやすくなります。

継続運用まで委託するべきケース

iOS/Android両プラットフォームのリリースエンジニアリングを専任できるエンジニアが社内にいない場合、またはApple/Googleの仕様変更に自社で追従することが難しい場合は、継続運用まで含めた委託が現実的です。証明書の年次更新・fastlaneのバージョンアップ・ストア申請APIの仕様変更対応を月次または年次の保守委託として契約する形をとれます。

継続委託では、SES(準委任)形態でエンジニアをアサインするか、保守請負として月額固定費用で契約するかを委託先と相談します。どちらの形態が適切かは、対応頻度や改修の規模によって異なります。

委託先選定で確認すべきポイント

fastlaneの外注先を選ぶ際には、iOS/Android両プラットフォームのリリースエンジニアリング経験(特にmatch/gym/deliver/supplyの実務経験)、CI/CDツール(GitHub Actions・Bitrise等)の導入実績、Apple Developer ProgramおよびGoogle Play Consoleの管理者操作の経験を確認します。

fastlaneは設定ファイルがRubyで記述されるため、Rubyの基礎知識も必要です。委託先がRails等のRuby経験のみでiOS/Androidのリリースエンジニアリング経験が浅い場合、証明書管理の設計ミスが起きるリスクがあります。実績として具体的なアプリ名・プラットフォーム・対応したリリース工程を確認することが大切です。

元請(プライムベンダー)として受託するパートナーを選ぶ場合は、iOS/Androidの両方に対応でき、CI/CD設計からセキュリティ要件の確認まで一貫して対応できる体制があるかどうかが判断基準になります。LASSIC IT事業部では、モバイルアプリの開発・保守運用を元請(プライムベンダー)として受託しており、fastlaneを含むリリースエンジニアリングの設計・構築・運用支援にも対応しています。モバイルアプリ受託開発・CI/CD構築の知見

まとめ:fastlane外注で押さえる3つの判断軸

本稿では、fastlaneによるiOS/Androidのビルド・ストア配信自動化と、外注で進める際の進め方を整理しました。要点を3つに集約します。

第一に、fastlaneはmatch(証明書管理)・gym(ビルド)・deliver/supply(ストア申請)・pilot(TestFlight)を組み合わせたlaneを定義し、CI/CDから呼び出す構成が基本です。各actionの役割を理解した設計が自動化の精度を左右します。

第二に、外注で進める場合は「現状棚卸し→match設計→lane作成→CI/CD連携→運用引継ぎ」の5フェーズが基本構成です。特に証明書管理の設計ミスはCI/CD上のビルド停止につながるため、match経験のある委託先に設計段階から関与してもらうことが大切です。

第三に、Apple/Googleの仕様変更(2025年5月のmanaged capabilities廃止のような変更)が定期的に発生するため、初期セットアップのスポット委託で終わらせるか、継続保守まで委託するかをチームの内製能力と照らして判断する必要があります。自動化の恩恵は、運用体制が整って初めて継続的に享受できます。

よくある質問

fastlaneの導入だけ外注することはできますか?

はい、fastlaneのセットアップとlane設計だけを外注することは可能です。match設定・Fastfile作成・CI/CD連携までをスポット委託し、運用は内製に引き継ぐ形が多く採用されています。スコープを明確にした請負契約で発注すると工数・費用が見積もりやすくなります。

fastlaneはAndroidにも対応していますか?

はい、対応しています。fastlane公式によると、supply actionがGoogle Playへのアプリ申請・メタデータ更新・APK/AAB配信を担い、iOSのdeliverと同等の機能をAndroidで提供します。iOS/Androidを同一のFastfileで管理し、laneを分けて運用するのが標準的です。

matchで証明書をGitリポジトリで管理するのはセキュリティ上問題ありませんか?

fastlane公式によると、matchはOpenSSLを用いたパスフレーズ暗号化を行ったうえで証明書をリポジトリに保存します。パスフレーズをCI/CDの環境変数として適切に保護すれば、平文での漏洩リスクを抑えられます。プライベートリポジトリを使用し、アクセス権限を開発チームに限定することが推奨されています。最新のセキュリティ要件はfastlane公式ドキュメント(docs.fastlane.tools/actions/match/)でご確認ください。

2025年5月に廃止されたmatchの「managed capabilities」とはどのような機能でしたか?

managed capabilitiesはmatchがApple Developer Portalと連携してApp ID・プロビジョニングプロファイルのケーパビリティ(Push Notificationsなどの機能権限)を自動的に同期・管理する機能でした。fastlane公式によると、2025年5月にApple側の対応終了に伴いこの機能は廃止されました。現在はケーパビリティを手動またはXcodeから設定する運用が必要です。詳細はfastlane公式ドキュメントでご確認ください。

fastlane導入後の運用を外注に任せ続けることはできますか?

はい、lane追加・バージョンアップ対応・証明書更新などの継続運用も外注できます。SES(準委任)形態でエンジニアをアサインする方法と、月次の保守委託を請負で契約する方法があります。Apple/Google両ストアの仕様変更が定期的に発生するため、追従対応を含めた運用スコープを事前に合意しておくことが大切です。

著者:テレリモ総研編集部 鈴木 亮佑

LASSICに相談するメリット

LASSIC IT事業部は、iOS/Androidアプリの開発・保守運用を元請(プライムベンダー)として受託しており、fastlaneを含むリリースエンジニアリングの設計・構築から継続運用支援まで対応できる体制を整えています。CI/CD連携や証明書管理の設計など、外注スコープが曖昧な段階からご相談いただくことも可能です。モバイルアプリ受託開発・運用支援の知見


ITアウトソーシング・システム開発のご相談はLASSICへ

元請(プライムベンダー)として、貴社の課題に合わせた体制構築・開発支援をご提案します。まずはお気軽にご相談ください。

無料相談はこちら

ご不明な点はお問い合わせフォームからもご連絡いただけます。

  1. *1 出典:fastlane「fastlane docs — fastlane Documentation」(2025年)

View