---
title: "fastlaneとは？iOS・Androidのビルドと配信を自動化する使い方【2.241・Ruby 3.2対応】"
url: "https://www.issoh.co.jp/tech/details/5686/"
published: 2025-03-06
updated: 2026-10-24
categories: ["モバイル（iOS・Android）"]
publisher: "株式会社一創"
---

# fastlaneとは？iOS・Androidのビルドと配信を自動化する使い方【2.241・Ruby 3.2対応】

fastlane（ファストレーン）は、iOS・Androidアプリのビルド、コード署名、テスト、TestFlight・App Store・Google Playへの配信を、Fastfileに書いた手順（lane）として1コマンドで実行するRuby製のオープンソースツールです。現行版は2026年10月15日公開の2.241.1で、2.241.0からRuby 3.2以上が必須になりました。9月までの解説にある「Ruby 3.1以上」はもう通りません。この記事では、インストールからFastfileの書き方、APIキー認証、matchによる証明書の共有、各ストアへの配信、Flutterでの置き場所、CIへの載せ方までを説明します。設定例は2.241.1（Ruby 4.0.6）の`fastlane lanes`で解析が通ることを確認したものです。実アプリのビルド・署名・ストア配信までは実行していません。

なお、同じ綴りの「Cisco Fastlane」（Wi-Fiで業務アプリの通信を優先するCiscoとAppleの機能）や「au 5G Fast Lane」（KDDIの5G優先通信サービス）、Fastlane Japan株式会社は別物です。この記事はアプリ開発ツールのfastlaneを扱います。

## まとめ：fastlaneで押さえる要点

- **役割：**ビルド（gym）、署名（match）、テスト（scan）、TestFlight配信（pilot）、App Store提出（deliver）、Google Play配信（supply）をlaneにまとめ、`bundle exec fastlane beta`のように実行する。
- **導入：**Ruby 3.2以上が必須（2.241.0から）。公式の推奨はGemfile＋Bundlerで版を固定する方法で、macOS標準のRuby 2.6は使えない。
- **認証：**App Store Connect APIの**チームキー**（key\_id・issuer\_id・.p8）を使えば2要素認証なしでCIから動く。個人キーではmatchのプロファイル作成ができない。
- **落とし穴：**supplyのtrackは既定がproduction、matchのreadonlyは既定がfalse。指定を忘れると本番公開や証明書の新規作成が起きる。
- **向かない場面：**リリースが年数回の個人開発や、iOSだけでXcode Cloudの月25時間に収まるチームは、Ruby環境を足さない既存の運用を続ける。

## fastlaneの役割とアクション名の対応

fastlaneは「アクション」と呼ばれる部品を並べてlaneを作ります。gymやdeliverは独立したツールだった時代の名前で、現在は機能名のアクション（build\_appなど）の別名です。`fastlane action gym`を実行すると「Alias for the build\_app action」と表示されます。どちらで書いても動きますが、Fastfileを初めて読む人には機能名の方が通じます。

| 別名（旧ツール名） | アクション名                       | 処理内容                      |
| --------- | ---------------------------- | ------------------------- |
| gym       | build\_app / build\_ios\_app | ビルドと署名、.ipaとdSYMの生成       |
| scan      | run\_tests                   | シミュレータ・実機でテスト実行           |
| match     | sync\_code\_signing          | 証明書とプロファイルをチームで共有         |
| pilot     | upload\_to\_testflight       | TestFlightへのアップロードとテスター管理 |
| deliver   | upload\_to\_app\_store       | メタデータ・スクショ・バイナリの提出        |
| snapshot  | capture\_ios\_screenshots    | 多言語・多端末のスクショ自動撮影          |
| supply    | upload\_to\_play\_store      | Google PlayへのAAB・メタデータ配信  |

ソースは[GitHubのfastlane/fastlane](https://github.com/fastlane/fastlane)で、MITライセンスです。Googleが運営していた時期がありますが、2023年10月にMobile Native Foundationへの移管が承認されています。

## fastlaneのインストール手順（Ruby 3.2以上・Bundler・Homebrew）

### Ruby 3.2が必須になった経緯とmacOS標準Rubyの扱い

RubyGemsに登録された2.241.1の`required_ruby_version`は`>= 3.2.0`です。要件は短い間隔で上がっており、2.238.0までは3.0以上、2.239.0（2026年9月4日）で3.1以上、[2.241.0のリリースノート](https://github.com/fastlane/fastlane/releases/tag/2.241.0)（2026年10月10日）に「Ruby 3.2 is now the minimum (dropping Ruby 3.1)」とあります。Ruby 3.1の環境で`bundle update fastlane`を実行すると、2.240.1より上には上がりません。

一方、macOS 26.6.2の`/usr/bin/ruby`は2.6.10のままです。この環境で`/usr/bin/gem install fastlane`を実行すると、fastlane本体より先に依存gemの段階で止まります（2.240.1で確認）。

```
ERROR:  Error installing fastlane:
	pp requires Ruby version >= 2.7.0. The current ruby version is 2.6.10.210.
```

システムRubyはgemの導入にsudoが要り、公式docsも推奨していません。Homebrew・rbenv・miseなどでRubyを用意します。[公式のセットアップ手順](https://docs.fastlane.tools/getting-started/ios/setup/)は「3.2以上に対応、3.3以上を推奨」と書いているので、新規導入なら3.3以上を選びます。rbenvでの版の切り替えは[rbenvとは？Rubyバージョン管理の仕組みとRVMとの違い・1.3系の導入手順](/tech/details/7474/)で説明しています。

### Gemfile＋Bundlerによるバージョン固定（推奨）

公式docsが推奨するのは、プロジェクト直下のGemfileでfastlaneの版を宣言し、Bundler経由で実行する方法です。開発者ごと・CIごとに版がずれず、起動も速くなります。

```
source "https://rubygems.org"

gem "fastlane", "~> 2.241"
```

`~> 2.241`は「2.241以上・3.0未満」を許す指定です。実際に使う版はGemfile.lockで固定され、`bundle install`では変わらず、`bundle update fastlane`や`bundle update --all`で依存関係を解決し直したときに上がります。

```
bundle install
bundle exec fastlane lanes   # 定義済みのlane一覧
bundle update fastlane       # fastlaneと必要な依存gemを更新
```

GemfileとGemfile.lockは両方ともGitに入れ、CIでは最初のステップで`bundle install`を実行します。2.241.0からは実行のたびに冒頭へ「fastlane 2.241.1 (Ruby 4.0.6, gem)」のように版・Ruby・導入元が表示されるので、CIのログでどの版が動いたかを後から確かめられます。Gemfileを使わずに起動すると「Get started using a Gemfile for fastlane」と案内が出ます。Bundler自体の使い方は[gemとBundlerの使い方｜Bundler 4系で変わったコマンドとGemfileの書き方](/tech/details/4221/)にまとめています。

### Homebrew経由の導入とチーム利用の制約

1人で試すだけなら`brew install fastlane`でも動きます。2026年10月24日時点で[Homebrewのformula](https://formulae.brew.sh/formula/fastlane)は2.241.1で、HomebrewのRubyに依存するためRubyを別に用意する必要がありません。ただしチームでは版がそろわず、プラグインもFastfileと別の場所に入るため、共有プロジェクトではGemfile方式に寄せます。

ロケールがUTF-8でないとビルドやアップロードで失敗するため、公式docsはシェル設定に`export LC_ALL=en_US.UTF-8`と`export LANG=en_US.UTF-8`を追加するよう求めています。

## fastlane initとFastfile・Appfileの書き方

### fastlane initの4つの選択肢

Gemfileを置いたXcodeプロジェクトのディレクトリで`bundle exec fastlane init`を実行すると、用途を4つから選びます。

1. Automate screenshots（スクリーンショット撮影）
2. Automate beta distribution to TestFlight（TestFlight配信）
3. Automate App Store distribution（App Store配信。既存のメタデータを取り込む）
4. Manual setup（Fastfileの雛形だけを作る）

どれを選んでも`fastlane/Fastfile`と`fastlane/Appfile`が作られ、後から自由に書き換えられます。1〜3はApple IDでのログインを求めるため、後述のAPIキーを使う予定なら4のManual setupで雛形だけ作る方が手戻りがありません。

### Fastfileでlaneを定義する例

次のFastfileは、テスト・TestFlight配信・App Store提出・Google Play内部テストの4つのlaneを持つ例です。MyAppなどの仮名を置き換え、環境変数に認証情報を入れ、matchの保存先とAndroidのリリース署名を設定してから実行します。

```
default_platform(:ios)

platform :ios do
  before_all do |lane|
    next if lane == :test
    app_store_connect_api_key(
      key_id: ENV["ASC_KEY_ID"],
      issuer_id: ENV["ASC_ISSUER_ID"],
      key_content: ENV["ASC_KEY_CONTENT"],
      is_key_content_base64: true
    )
  end

  desc "ユニットテストを実行"
  lane :test do
    run_tests(scheme: "MyApp")
  end

  desc "TestFlightへ配信"
  lane :beta do
    sync_code_signing(type: "appstore", readonly: is_ci)
    increment_build_number(build_number: latest_testflight_build_number + 1)
    build_app(scheme: "MyApp")
    upload_to_testflight(skip_waiting_for_build_processing: true)
  end

  desc "App Storeへ提出"
  lane :release do
    sync_code_signing(type: "appstore", readonly: is_ci)
    increment_build_number(build_number: latest_testflight_build_number + 1)
    build_app(scheme: "MyApp")
    upload_to_app_store(
      submit_for_review: true,
      automatic_release: false,
      force: true,
      precheck_include_in_app_purchases: false
    )
  end
end

platform :android do
  desc "Google Playの内部テストへ配信"
  lane :internal do
    gradle(task: "bundle", build_type: "Release")
    upload_to_play_store(
      track: "internal",
      package_name: "com.example.myapp",
      json_key: ENV["PLAY_JSON_KEY_PATH"]
    )
  end
end
```

実行は`bundle exec fastlane ios beta`です。`default_platform(:ios)`があるので`bundle exec fastlane beta`でも同じlaneが走ります。`before_all`はiOSのlaneの前にだけ呼ばれ、Androidのlaneには適用されません。`next if lane == :test`で、ストアに接続しないテストのlaneではAPIキーを読み込まないようにしています。`readonly: is_ci`は、CIでは既存の証明書を取り出すだけにし、CI以外では新規作成を許す書き方です。管理者かどうかは判定しないため、新規作成を管理者に限定するには認証情報へのアクセスを別途制限します。

ビルド番号の重複を避けるため、上の例ではTestFlight上の最新番号に1を足しています。ただし、複数ジョブが同時に同じ番号を取得すると重複するため、この方式では同じアプリの配信ジョブを直列に実行します。`increment_build_number`は内部でagvtoolを呼びますが、`build_number`を明示する場合、公式仕様ではApple Generic Versioningの有効化は必須ではありません。

### Appfileに書く共通設定

Appfileには、各アクションが共通で参照するアプリ識別子やチームIDを書きます。

```
app_identifier("com.example.myapp")
team_id("ABCDE12345")
```

Apple IDで認証する場合だけ`apple_id("dev@example.com")`を足します。APIキー認証ならApple IDは不要です。

### .gitignoreに入れる生成ファイル

Fastfile・Appfile・Gemfileはリポジトリに入れ、実行のたびに生成されるファイルは除外します。[公式のソース管理ガイド](https://docs.fastlane.tools/best-practices/source-control/)が挙げているのは次の4つです。

```
# fastlane specific
**/fastlane/report.xml
# deliver temporary files
**/fastlane/Preview.html
# snapshot generated screenshots
**/fastlane/screenshots
# scan temporary files
**/fastlane/test_output
```

APIキーの.p8やGoogle PlayのサービスアカウントJSONは、この4行に含まれていません。リポジトリの外に置くか、CIのシークレットから渡します。

## App Store Connect APIキーによる認証

[公式docsのAPIキーの説明](https://docs.fastlane.tools/app-store-connect-api/)が推奨する認証方式です。2要素認証を通さずに済むため、CIのように人が画面を見られない環境でも止まりません。App Store Connectの「ユーザーとアクセス」でキーを発行し、次の値を`app_store_connect_api_key`に渡します。

| パラメータ                    | 環境変数                                                    | 要否・既定値           |
| ------------------------ | ------------------------------------------------------- | ---------------- |
| key\_id                  | APP\_STORE\_CONNECT\_API\_KEY\_KEY\_ID                  | 必須               |
| issuer\_id               | APP\_STORE\_CONNECT\_API\_KEY\_ISSUER\_ID               | チームキーで必須         |
| key\_filepath            | APP\_STORE\_CONNECT\_API\_KEY\_KEY\_FILEPATH            | key\_contentと択一  |
| key\_content             | APP\_STORE\_CONNECT\_API\_KEY\_KEY                      | key\_filepathと択一 |
| is\_key\_content\_base64 | APP\_STORE\_CONNECT\_API\_KEY\_IS\_KEY\_CONTENT\_BASE64 | 既定false          |
| duration                 | APP\_STORE\_CONNECT\_API\_KEY\_DURATION                 | 既定500秒・上限1200秒   |

キーは**チームキー**で作ります。個人キーはプロビジョニング関連のAPIを使えないため、matchで証明書やプロファイルを作る処理が通りません。issuer\_idは個人キーのときだけ`nil`にします。

.p8は一度しかダウンロードできません。CIでは.p8の中身をBase64にしてシークレットへ入れ、`is_key_content_base64: true`で渡すと改行の崩れを避けられます。.p8として読めない文字列を`key_content`に渡すと、2.241.1では次のエラーで止まりました。

```
spaceship/lib/spaceship/connect_api/token.rb:76:in 'OpenSSL::PKey::EC#initialize': [!] invalid curve name (OpenSSL::PKey::PKeyError)
```

このエラーが出たら、まずシークレットの改行とBase64の指定を疑います。

APIキーに対応していないツールも残っています。公式の対応表では、アプリをApp Store Connectに新規作成するproduceと、プッシュ通知証明書を作るpemが「No」です。2.241.0でproduceの一部がAPIキーに対応しましたが、2.241.1で差し戻されました。これらだけはApple IDで実行し、CIでは`fastlane spaceauth -u user@example.com`で発行したセッションを`FASTLANE_SESSION`に入れて使います。

## match（sync\_code\_signing）による証明書の共有

### matchの保存先・暗号化・readonly設定

matchは、配布用の証明書とプロビジョニングプロファイルを1か所に暗号化して保存し、チーム全員とCIが同じものを取り出す仕組みです。個人のMacで作った証明書を手渡しする運用をやめられます。署名の仕組みそのものは[プロビジョニングプロファイルとは｜iOS署名の仕組み・4種類・作成・期限・エラー対処](/tech/details/11493/)で扱っています。

- **type：**appstore、adhoc、development（既定）、enterprise、developer\_idなど。TestFlight・App Store向けはappstore。
- **storage\_mode：**git（既定）、google\_cloud、s3、gitlab\_secure\_filesの4種類。
- **MATCH\_PASSWORD：**保存先がgitのときに証明書を暗号化・復号するパスフレーズ。紛失すると取り出せない。2.241.1のソースではs3も既定で同じ暗号化を使い、google\_cloudとgitlab\_secure\_filesでは使わない。
- **readonly：**既定はfalse。trueにすると既存の証明書を取り出すだけで新規作成しない。

CIでは必ずreadonlyをtrueにします。既定のfalseでは、保存先に無い証明書やプロファイルをmatchが新規作成します。[matchの公式docs](https://docs.fastlane.tools/actions/match/)も「CIでは常にreadonlyモードを使う」ことを推奨しています。新規作成は管理者が手元で`fastlane match appstore`を実行するときだけにします。

### matchへの既存証明書の取り込みと発行上限への対処

matchを後から入れるチームでは、Apple Developerアカウントにすでに配布用証明書があります。matchに新しく作らせると、アカウントで作れる配布用証明書の数の上限に当たることがあります。Appleが「You already have a current」で始まるエラーを返すと、fastlaneは次のメッセージで止まります（2.241.1のcertのソースより）。

```
Could not create another Distribution certificate, reached the maximum number of available Distribution certificates.
```

対処は2つです。

- **既存の証明書を取り込む：**`fastlane match import`を実行し、証明書（.cer）、秘密鍵（.p12）、プロファイルのパスを指定する。matchはDeveloper Portalで証明書を照合してから暗号化して保存する。秘密鍵が手元に無い証明書は取り込めない。
- **まとめて失効させて作り直す：**`fastlane match nuke distribution`で配布用の証明書とプロファイルを失効させ、matchで作り直す。公式docsによれば、App StoreやTestFlightにすでに出ているアプリは動き続けるが、Ad HocとEnterpriseで配ったビルドは使えなくなる。

Ad HocやEnterpriseで配布中のビルドがあるならimportを選びます。nukeは秘密鍵が誰の手元にも残っていない場合の最後の手段です。

## TestFlightとApp Storeへの配信（pilot・deliver）

### pilot（upload\_to\_testflight）によるTestFlight配信

pilotはビルド済みの.ipaをApp Store Connectへアップロードし、TestFlightのテスター管理も担います。アップロード後、Apple側でビルドの処理が終わるまで既定では待ち続けます。CIの実行時間を節約するなら`skip_waiting_for_build_processing: true`で待たずに終了させ、外部テスターへの配布は処理完了後に行います。

2.241.0からは、同じlaneでbuild\_appが作った.ipaを優先してアップロードします。それまでは現在のディレクトリにある最も新しい.ipaが選ばれることがあり、古い成果物が残っていると別のビルドが上がる恐れがありました。upload\_to\_app\_storeも同じ変更を受けています。

### deliver（upload\_to\_app\_store）による審査提出

deliverはメタデータ、スクリーンショット、App Preview、バイナリをApp Store Connectへ送ります。既定の挙動は次のとおりで、何も指定しないと審査には出しません。

| オプション                         | 既定値   | 用途                    |
| ----------------------------- | ----- | --------------------- |
| submit\_for\_review           | false | アップロード後に審査へ提出         |
| automatic\_release            | 未指定   | 承認後に自動公開するか           |
| skip\_metadata                | false | 説明文などの送信を省く           |
| skip\_screenshots             | false | スクショの送信を省く            |
| run\_precheck\_before\_submit | true  | 提出前にprecheckで規約違反語を検査 |
| force                         | false | HTMLプレビュー確認を省く        |

deliverは確認用のHTMLプレビューを開き、「Does the Preview … look okay for you?」とy/nを尋ねます。対話できないCIでは「Could not retrieve response as fastlane runs in non-interactive mode」で失敗するため、`force: true`を付けます。オプションは`fastlane/Deliverfile`に書いておくこともできます。

APIキーで認証している場合は、`precheck_include_in_app_purchases: false`も必要です。既定のtrueのままだと、提出前のprecheckが「Precheck cannot check In-app purchases with the App Store Connect API Key (yet)」で止まります。省かれるのはアプリ内課金の文言チェックだけなので、課金アイテムの説明文は提出前に人が確認します。

## supply（upload\_to\_play\_store）によるGoogle Play配信

AndroidではsupplyがAABやAPK、ストア掲載情報をGoogle Playへ送ります。認証にはGoogle CloudのサービスアカウントのJSONキーを`json_key`で渡します。2.241.1ではJSONの中身を`json_key_data`で直接渡す方法や、Application Default Credentialsも使えます。配信先のアプリは`package_name`（AndroidのapplicationId）で指定し、Appfileに`package_name("...")`と書いておくこともできます。

注意したいのはtrackの既定値です。[upload\_to\_play\_storeの公式docs](https://docs.fastlane.tools/actions/upload%5Fto%5Fplay%5Fstore/)では、指定しなければproductionになります。社内検証のつもりで素の`upload_to_play_store`を呼ぶと本番トラックに載るため、上のFastfile例のように`track: "internal"`を必ず明示します。段階的公開は`rollout`に0〜1の割合（例：0.1で10%）を渡します。

Firebase経由でテスターに配る場合は、`fastlane add_plugin firebase_app_distribution`でプラグインを追加します。追加したプラグインは`fastlane/Pluginfile`に記録され、Gemfileから読み込まれます。配布先の設計は[Firebase App Distributionとは｜配信物の分岐とテスター名簿・CI組み込みの設計【2026年8月時点】](/tech/details/17043/)で説明しています。

## FlutterやReact Nativeのプロジェクトでfastlaneを使う手順

クロスプラットフォームのプロジェクトでは、fastlaneをリポジトリの直下ではなく、`ios`と`android`のディレクトリにそれぞれ置きます。[Flutter公式の継続的デリバリーの手順](https://docs.flutter.dev/deployment/cd)（2026年7月31日更新・Flutter 3.47）は次の順序を示しています。

1. `flutter build appbundle`と`flutter build ipa`でリリースビルドが通ることを確かめる。
2. `[project]/android`と`[project]/ios`でそれぞれ`fastlane init`を実行する。Gemfileも両方のディレクトリに置く。
3. リリースのたびに`flutter build`を先に実行し、`cd ios`（または`cd android`）してから`bundle exec fastlane <lane名>`を実行する。

Android側はflutter buildが作ったAABを使うので、`upload_to_play_store`の`aab`に`../build/app/outputs/bundle/release/app-release.aab`を指定します。iOS側でfastlaneのbuild\_appに署名とビルドを任せる場合、CIでは`flutter build ios --release --no-codesign --config-only`で設定ファイルだけを生成してからlaneを呼びます。React Nativeも`ios`と`android`のディレクトリを持つ構成なので、同じ置き方になります。Expo（EAS）やCodemagicでビルドと提出を済ませているなら、fastlaneを重ねる必要はありません。

## CI/CD組み込み時のキーチェーン・認証・Xcode設定

fastlaneはCIのジョブから`bundle exec fastlane beta`を呼ぶだけで動きますが、手元と違ってキーチェーン、認証、Xcodeの版を決めておく必要があります。

- **setup\_ci：**一時キーチェーン（既定名fastlane\_tmp\_keychain）を作り、matchの証明書をそこへ入れる。CI以外では「Not running on CI」と表示して何もしない。
- **認証：**APIキーをシークレットに置き、Apple IDの2要素認証を経由しない。2.241.0からは、オプションに秘密と印の付いた値がfastlaneのログ上で伏せ字になる。
- **Xcodeの版：**[Appleの要件](https://developer.apple.com/news/upcoming-requirements/)により、2026年4月28日以降にApp Store Connectへ上げるアプリはXcode 26以降・iOS 26 SDKでのビルドが必須。2026年10月15日にXcode 27.1が出ており、ランナーの既定Xcodeはイメージ更新で変わるため、`xcode-select`で使う版を明示する。確認と切り替えは[Xcodeの最新バージョンは27｜確認・アップデート手順とIntel Macは26.6まで](/tech/details/9027/)を参照。

GitHub Actionsでのワークフロー定義、ランナーのイメージ選び、CIでだけ起きるエラー（キーチェーンのロックやmulti\_jsonの読み込み失敗など）は[GitHub Actionsでfastlaneを動かすiOSリリース自動化｜設定とCI固有エラー対処](/tech/details/2367/)で手順ごとに説明しています。Macを持たずにビルドと提出を回す構成は[WindowsでiOS・iPhoneアプリを開発する方法｜Macなしでビルドと提出を回す4経路と手順](/tech/details/16716/)で比べています。リリース工程の自動化をCI/CDの整備ごと進めたい場合は、[DevOps・CI/CD導入支援](/service/system/devops/)でも相談を受けています。

## fastlaneを導入しない方がよい場面

fastlaneはRubyの版、gemの依存、Appleの仕様変更への追随という保守コストを抱えます。2026年9月4日の2.239.0から10月10日の2.241.0までの約5週間でRubyの最低要件が3.0から3.2まで2段上がったように、Ruby側の変化に合わせた更新は今後も続きます。次の条件に当てはまるなら、導入を見送る方が合理的です。

- **リリースが年に数回で開発者が1人：**Xcodeの「Archive」から「Distribute App」で必要な配信を完結でき、繰り返す手作業も少ないなら、Ruby環境を足す前に手動運用を続ける。
- **Xcode Cloudで足りる：**[Apple Developer Programの会員には月25時間の計算時間](https://developer.apple.com/xcode-cloud/)が含まれ、署名とTestFlight配信をApple側が担う。iOSだけのアプリで、ビルドがこの枠に収まるなら追加の仕組みは要らない。
- **ExpoやFlutterのクラウドビルドを使っている：**EAS SubmitやCodemagicの配信機能と役割が重なる。二重に持つと、どちらの設定が効いているかの切り分けが難しくなる。

逆に、iOSとAndroidを同じ手順で出したい、ストアの説明文やスクリーンショットを多言語でGit管理したい、という条件があるならfastlaneが候補になります。複数アプリのビルドと配信だけならXcode Cloudでも扱えるため、判断の分かれ目はAndroid配信とストアメタデータの管理まで1つの仕組みにまとめたいかどうかです。

## よくある質問

### fastlaneの読み方と「fast lane」の意味は？

読み方は「ファストレーン」です。英語のfast laneには、高速道路の追い越し車線という意味があります。

### fastlaneは無料で使えますか？

MITライセンスのオープンソースで、fastlane自体は無料です。ただしApp Store Connectへの配信にはApple Developer Programの年会費（99ドル）が、Google Playへの配信にはGoogle Play Consoleの登録料が別途かかります。年会費の中身は[Apple Developer Programとは？年会費99ドル（アプリ経由12,800円）の中身・登録方法・ログイン先](/tech/details/7317/)で説明しています。

### fastlaneのアップデート方法は？

Gemfileで管理している場合は`bundle update fastlane`を実行し、更新されたGemfile.lockをコミットします。Homebrewで入れた場合は`brew upgrade fastlane`です。2.241.0以降はRuby 3.2以上が必要なので、Ruby 3.1以下の環境では先にRubyを上げます。

### pilotとdeliverの違いは？

pilotはTestFlight向けで、ビルドのアップロードとテスター管理を担います。deliverはApp Store向けで、メタデータ・スクリーンショットの更新と審査提出を担います。審査に出す前の社内配布はpilot、公開はdeliverと使い分けます。

### fastlaneはAndroidアプリでも使えますか？

使えます。`gradle`アクションでビルドし、supply（`upload_to_play_store`）でGoogle Playへ配信します。Android用のスクリーンショット撮影にはscreengrabがあります。iOSと同じFastfileに`platform :android`ブロックを並べて書けます。

## 関連記事

- [GitHub Actionsでfastlaneを動かすiOSリリース自動化｜設定とCI固有エラー対処](/tech/details/2367/)
- [プロビジョニングプロファイルとは｜iOS署名の仕組み・4種類・作成・期限・エラー対処](/tech/details/11493/)
- [Firebase App Distributionとは｜配信物の分岐とテスター名簿・CI組み込みの設計【2026年8月時点】](/tech/details/17043/)
- [XCTestとは？Swift Testingとの使い分けとユニット・UIテストの書き方【Xcode 27対応】](/tech/details/7318/)
- [rbenvとは？Rubyバージョン管理の仕組みとRVMとの違い・1.3系の導入手順](/tech/details/7474/)

---

出典: [fastlaneとは？iOS・Androidのビルドと配信を自動化する使い方【2.241・Ruby 3.2対応】](<https://www.issoh.co.jp/tech/details/5686/>)（株式会社一創）