Contents
- 1 1. Flutter のマルチプラットフォーム対応概要
- 2 2. プラットフォーム別デプロイフローと必須ツール
- 3 3. CI/CD ツール比較と設定サンプル
- 4 4. 最新ベンチマークとデプロイ最適化テクニック
- 5 5. 他フレームワーク比較と実務トラブル対策
- 6 6. まとめ
1. Flutter のマルチプラットフォーム対応概要
Flutter 3.29 系は、公式ドキュメントが 安定版 としてサポートしている 6 種類のターゲットに対し、各種 SDK / ツールチェーンの最低バージョンを明示しています。開発チームはこの表を基準にローカル環境と CI ランナーを統一すると、ビルド環境のばらつきを最小化できます。
出典：Flutter Official Platform Support Matrix（2025‑04‑01）https://docs.flutter.dev/reference/supported-platforms
| プラットフォーム | 必要 SDK / ツール | 主な制限・注意点 |
|---|---|---|
| iOS | Xcode 15.2 以上、CocoaPods 1.12 以上 | Apple Silicon 推奨／コードサイン必須 |
| Android | Android Studio 2023.3 (Flamingo) + SDK 34 | Gradle 8.5 推奨・Java 17 対応 |
| Web | Chrome 124+（ビルド時）、Node.js 20 LTS | CSP 設定が必要になるケースあり |
| Windows | Visual Studio 2022 (Desktop development with C++) | MSIX 作成に Windows 10 2004 以上必須 |
| macOS | Xcode 15.2、macOS 13 Ventura 以降 | DMG/PKG 作成は create-dmg 推奨 |
| Linux | Ubuntu 22.04 LTS (glibc 2.35)、CMake 3.27 | AppImage または Snap が主流 |
1‑1. 環境統一のベストプラクティス
- Docker コンテナ：
flutter:3.29‑sdkイメージをベースに、iOS（macOS ランナー）・Android 用の追加ツールをレイヤー化。 - CI 用ランナー設定：GitHub Actions の
ubuntu-latest／windows-latest／macos-latestに同一イメージを使用し、依存キャッシュ（~/.pub-cacheなど）を永続化することでビルド時間が約 30 %短縮。
2. プラットフォーム別デプロイフローと必須ツール
各プラットフォームのデプロイ手順は共通部分（flutter pub get、テスト実行）と固有ステップに分かれます。本節では iOS・Android・Web・Desktop の主要フローを H4 まで掘り下げ、サンプルスクリプトと注意点を掲載します。
2.1 iOS デプロイ（App Store Connect & Fastlane / Codemagic）
iOS アプリは Xcode でアーカイブし、App Store Connect にアップロードします。コードサインの自動化が鍵です。
2.1.1 ローカルビルド手順
以下のコマンドは コードサインを除外 した状態で
.xcarchiveを生成します。CI ではmatchに置き換えて自動署名してください。
|
1 2 3 4 5 6 7 |
flutter build ios --release --no-codesign cd ios && pod install xcodebuild -workspace Runner.xcworkspace \ -scheme Runner \ -configuration Release \ -archivePath $PWD/build/Runner.xcarchive archive |
2.1.2 Fastlane による自動化
Fastfile の代表的な lane は次の通りです（2025‑03‑28 時点、公式ドキュメント参照）。
|
1 2 3 4 5 6 7 |
lane :ios_release do match(type: "appstore") # 証明書・プロビジョニングを一元管理 build_app(scheme: "Runner") upload_to_app_store(skip_metadata: true, skip_screenshots: true) end |
2.1.3 Codemagic の UI 設定ポイント
| 項目 | 推奨設定 |
|---|---|
| Workflow 名 | ios_release |
| ビルドコマンド | flutter build ios --release --no-codesign |
| コードサイン | Codemagic UI → Code signing で証明書とプロビジョニングをアップロード |
重要：Apple の証明書は有効期限が 1 年なので、CI パイプライン開始前に自動リマインダー（例: GitHub Actions のスケジュール）を設定すると失敗回避につながります。
2.2 Android デプロイ（Google Play Console & Fastlane / GitHub Actions）
Android は Gradle が中心で、App Bundle (.aab) が推奨フォーマットです。CI では bundletool または Fastlane の supply を利用します。
2.2.1 ローカルビルドコマンド
|
1 2 |
flutter build appbundle --release # 出力: build/app/outputs/bundle/release/*.aab |
2.2.2 GitHub Actions ワークフロー（android.yml）
本ワークフローは GitHub の公式 Flutter アクション を使用し、2025‑04‑02 時点の無料プラン（月 2000 分）でも十分に実行可能です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
name: Android CI/CD on: push: tags: ['v*'] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Set up Flutter uses: subosito/flutter-action@v2 with: flutter-version: "3.29.0" - run: flutter pub get - run: flutter build appbundle --release - name: Upload to Play Store uses: r0adkll/upload-google-play@v1 with: serviceAccountJsonPlainText: ${{ secrets.PLAY_STORE_SERVICE_ACCOUNT }} packageName: com.example.myapp releaseFiles: build/app/outputs/bundle/release/*.aab |
2.2.3 Gradle キャッシュ活用
- キャッシュキー：
hashFiles('android/**/*.gradle', 'pubspec.yaml') - 効果：CI ランナーのビルド時間が約 30 %短縮（2025‑03‑15 の社内ベンチマーク参照）
2.3 Web デプロイ（Firebase Hosting / Vercel）
Web ビルドは静的ファイルとして出力され、CDN 配信が最適です。
2.3.1 ビルド手順
|
1 2 |
flutter build web --release # 出力先: build/web |
2.3.2 Firebase Hosting デプロイ例
|
1 2 3 4 |
firebase login firebase init hosting # public ディレクトリに build/web を指定 firebase deploy |
- CSP 対応：
firebase.jsonに次を追記すると、Flutter が要求するスクリプトのロードが許可されます（2025‑04‑03 更新）。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
{ "hosting": { "headers": [ { "source": "**/*.js", "headers": [ { "key": "Content-Security-Policy", "value": "script-src 'self' https://apis.google.com;" } ] } ] } } |
2.3.3 Vercel デプロイポイント
| 項目 | 設定例 |
|---|---|
| ビルドコマンド | flutter build web --release && cp -r build/web .vercel/output/public |
| 出力ディレクトリ | .vercel/output/public |
2.4 Desktop デプロイ（Windows・macOS・Linux）
デスクトップは各 OS のネイティブインストーラ形式で配布します。Flutter CLI がバイナリを生成し、外部ツールで包装する流れです。
2.4.1 ビルドコマンド一覧
| OS | コマンド |
|---|---|
| Windows | flutter build windows --release |
| macOS | flutter build macos --release |
| Linux | flutter build linux --release |
2.4.2 インストーラ生成ツールと配布例
| OS | ツール | 主な配布先 |
|---|---|---|
| Windows | MSIX Packaging Tool（Visual Studio 拡張） | Microsoft Store / 社内サーバ |
| macOS | create-dmg、pkgbuild |
Mac App Store（審査必須）/ 直接配布 |
| Linux | appimagetool、Snapcraft | Snap Store / GitHub Releases |
注意：Windows MSIX はコードサインが必須です。Azure Pipelines の
signtoolタスクと Azure Key Vault に格納した証明書を組み合わせると CI で自動化できます（2025‑02‑20 の Microsoft Docs を参照）。
3. CI/CD ツール比較と設定サンプル
本節では、GitHub Actions, GitLab CI, Codemagic, Bitrise の四大ツールを機能・料金・プラットフォーム対応で比較し、実際に使える YAML/JSON 例を示します。
3.1 比較表（2025‑04‑10 時点）
| ツール | 主な特徴 | 対応プラットフォーム | 無料枠 (月) | 有料プランの主な制限 |
|---|---|---|---|---|
| GitHub Actions | GitHub と完全統合、Marketplace に多数の Flutter アクション | iOS・Android・Web・Desktop（macOS/Ubuntu/Windows ランナー） | 2000 分* | 超過分は従量課金 |
| GitLab CI | セルフホストランナーで高いカスタマイズ性、強力なキャッシュ機能 | 同上 | 400 分** | エンタープライズ版は無制限 |
| Codemagic | Flutter 専用 UI、コードサイン UI が標準装備 | iOS・Android・Web（macOS ランナー必須） | 500 分*** | プロプランでビルド時間無制限 |
| Bitrise | ビジュアルステップエディタ、豊富なテンプレート | 同上 | 20 ビルド/月 | Pro で並列ビルド・無制限 |
*2025‑04‑01 の GitHub Docs（https://docs.github.com/en/billing）
*GitLab SaaS の公式プラン表（https://about.gitlab.com/pricing/）
**Codemagic Pricing ページ（https://codemagic.io/pricing/）
3.2 GitHub Actions 設定サンプル（共通 workflow）
導入：全プラットフォームで共通に実行したいビルド・テストステップをまとめた例です。OS ごとのビルドコマンドは
case文で分岐させます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
name: Flutter CI/CD on: push: branches: [ main ] jobs: build-test: runs-on: ${{ matrix.os }} strategy: matrix: os: [ macos-latest, ubuntu-latest, windows-latest ] steps: - name: Checkout repository uses: actions/checkout@v3 - name: Install Flutter SDK uses: subosito/flutter-action@v2 with: flutter-version: "3.29.0" - name: Get dependencies run: flutter pub get - name: Run unit tests run: flutter test --no-pub - name: Build release artifact env: OS_NAME: ${{ matrix.os }} run: | if [[ "$OS_NAME" == "macos-latest" ]]; then flutter build ios --release elif [[ "$OS_NAME" == "ubuntu-latest" ]]; then flutter build apk --release else flutter build windows --release fi |
3.3 GitLab CI 設定例（.gitlab-ci.yml）
導入：GitLab の共有ランナーを利用した Android ビルドパイプラインです。キャッシュディレクトリは
pub-cacheと Gradle を対象にしています。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
stages: - test - build variables: FLUTTER_VERSION: "3.29.0" test: stage: test image: cirrusci/flutter:${FLUTTER_VERSION} cache: key: "${CI_COMMIT_REF_SLUG}" paths: - .pub-cache/ - .dart_tool/ script: - flutter pub get - flutter test build_android: stage: build only: - tags image: cirrusci/flutter:${FLUTTER_VERSION} cache: key: "${CI_COMMIT_REF_SLUG}" paths: - .pub-cache/ - .dart_tool/ script: - flutter pub get - flutter build appbundle --release artifacts: paths: - build/app/outputs/bundle/release/*.aab |
3.4 Codemagic Workflow（codemagic.yaml）
導入：Codemagic の UI で設定可能な YAML。iOS 向けに
fastlaneを呼び出すステップを示します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
workflows: ios_release: name: iOS Release environment: xcode: latest flutter: "3.29.0" scripts: - name: Install dependencies script: | flutter pub get - name: Build iOS (no codesign) script: | flutter build ios --release --no-codesign - name: Run Fastlane lane script: fastlane ios_release publishing: app_store_connect: api_key_path: $HOME/fastlane/AppStoreConnectAPIKey.json |
3.5 Bitrise ステップ構成例（bitrise.yml）
導入：Bitrise の UI で作成した YAML。Android AAB ビルドと Fastlane
supplyによる Play Store アップロードを自動化しています。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
trigger_map: - push_branch: "*" workflow: primary workflows: primary: steps: - flutter-installer@2: inputs: version: "3.29.0" - script@1: title: Install dependencies inputs: content: | flutter pub get - script@1: title: Build Android AAB inputs: content: | flutter build appbundle --release - fastlane@2: inputs: lane: supply work_dir: . env_vars: | SUPPLY_JSON_KEY_DATA=${SUPPLY_JSON_KEY_DATA} - deploy-to-bitrise-io@2: {} |
3.6 ツール選定のまとめ
| 重視項目 | 推奨ツール |
|---|---|
| iOS のコードサイン自動化 | Codemagic（UI が最もシンプル） |
| マルチプラットフォーム統合 & キャッシュ活用 | GitHub Actions（Marketplace に豊富な Flutter アクション） |
| セルフホスト・高度カスタマイズ | GitLab CI（ランナー自由に構築可能） |
| 小規模チームでの高速導入 | Bitrise（テンプレートが充実し UI だけで完結） |
4. 最新ベンチマークとデプロイ最適化テクニック
4.1 ビルドサイズ・時間比較（2025‑04‑08 版）
出典：Flutter Performance Dashboard（公式、2025‑04‑07 取得）https://flutter.dev/perf-dashboard/
条件：GitHub Actions のubuntu-latest／macos-latestランナー上でインクリメンタルキャッシュ有効。
| プラットフォーム | ビルドタイプ | 平均ビルド時間* | リリースバイナリサイズ |
|---|---|---|---|
| iOS | .ipa (AOT) | 9 分 | 115 MB |
| Android | .aab (AOT) | 7.5 分 | 98 MB |
| Web | 静的ファイル | 2 分 | 3.4 MB（gzip） |
| Windows | MSIX | 6 分 | 120 MB |
| macOS | .app (AOT) | 8 分 | 118 MB |
| Linux | AppImage | 5.5 分 | 112 MB |
*ビルド時間は キャッシュ有り の場合。キャッシュなしだと約 30 % 増加。
4.2 ビルド時間短縮テクニック
-
Incremental Build（
--incremental）
効果: 変更が無いモジュールは再コンパイルしないため、CI 全体で平均 30 % の時間削減。 -
AOT コンパイルオプション
bash
flutter build web --release \
--dart-define=FLUTTER_WEB_AUTO_DETECT=false
効果: Web アセット解析をスキップし、ビルドが約 15 % 高速化。 -
リソース分割
- Android：
flutter build apk --split-per-abi→ ABI 別 APK が最大 30 % 小さくなる。 -
Web：
--tree-shake-icons+--obfuscate→ 未使用アイコン除去で 10 % サイズ減。 -
永続キャッシュの活用
- キャッシュ対象:
~/.pub-cache,$HOME/flutter/.dart_tool, Gradle の~/.gradle/caches。 - 効果: 依存取得時間が約 40 % 短縮（GitHub Actions のキャッシュ設定例は上記参照）。
4.3 CI に組み込むべきベストプラクティス
| 項目 | 実装例 |
|---|---|
| キャッシュキーの安定化 | key: ${{ runner.os }}-pub-${{ hashFiles('pubspec.yaml') }} |
| ビルド失敗時の自動通知 | GitHub Actions の workflow_run → Slack Webhook（2025‑02‑14 追加） |
| 証明書有効期限監視 | 月次スケジュールジョブで openssl x509 -noout -dates -in cert.p12 を実行し、期限が近い場合は PR を自動作成 |
5. 他フレームワーク比較と実務トラブル対策
5.1 React Native と Kotlin Multiplatform のデプロイフロー比較
| 項目 | Flutter 3.29 | React Native (2025) | Kotlin Multiplatform |
|---|---|---|---|
| UI 実装方式 | Skia ベースの単一コード | JavaScript → Bridge → ネイティブコンポーネント | 共通ロジックは Kotlin、UI は各プラットフォーム固有 |
| ビルドツール | Flutter CLI + 各 SDK | gradle（Android） / Xcode（iOS） |
Gradle マルチモジュール |
| CI/CD 成熟度 | Codemagic・GitHub Actions が公式サポート | Fastlane、CircleCI が主流 | GitLab CI、Bitrise が推奨 |
| エコシステム規模 | 3000+ パッケージ（2025‑04） | 8000+ npm パッケージ | 急成長中だが iOS 側は限定的 |
| 典型的リスク | プラグインの iOS/Android 両対応必須 | JS とネイティブ間の同期バグが頻発 | ロジック共有は得意でも UI の二重管理が必要 |
結論：UI が完全に独立している Flutter は、プラットフォーム横断的なデプロイリスクが最も低く抑えられます。React Native はブリッジ層の不具合、KMP は UI の二重実装コストが主な障壁です。
5.2 実務でよく遭遇するトラブルと対策チェックリスト
| トラブルシナリオ | 主な原因 | 推奨対策 |
|---|---|---|
| コードサイン失敗（iOS） | プロビジョニングプロファイルが古い、証明書期限切れ | fastlane match で一元管理、CI に有効期限監視スクリプトを追加 |
| Android プラグイン互換性エラー | Gradle バージョン不一致（例：8.5 未対応） | pub upgrade --major-versions → 最新版へ更新、compileSdkVersion を 34 に統一 |
| Web の CSP エラー | CDN がデフォルトでスクリプト制限 | firebase.json / Vercel の headers に適切な Content‑Security‑Policy を追記 |
| Desktop インストーラ署名エラー（Windows） | MSIX 用証明書が未設定または期限切れ | Azure Key Vault で証明書を管理し、signtool タスクで自動署名 |
| ビルドキャッシュが無視される | CI のキャッシュキーが頻繁に変わる | キーを hashFiles('pubspec.yaml') に固定し、依存更新時のみ再生成 |
デプロイ前チェックリスト（CI パイプラインに組み込み推奨）
- [ ] iOS/Android の証明書・プロビジョニングが有効期限内か
- [ ]
flutter pub outdated --mode=null-safetyで非互換パッケージを検出 - [ ] Web 用 CSP がホスティング設定に反映されているか
- [ ] Desktop インストーラ用コードサイン証明書が CI に正しく渡っているか
- [ ] ビルドキャッシュ設定が公式ドキュメントと一致しているか
6. まとめ
- マルチプラットフォーム環境は、公式の SDK バージョン表に沿って Docker／CI ランナーを統一すれば、開発者間での環境差異をほぼ排除できます。
- デプロイフローは iOS のコードサイン自動化が鍵となり、Fastlane と Codemagic が最も手軽です。Android は Gradle キャッシュと
bundletoolを活用すればビルド時間が大幅に短縮します。 - CI/CD ツールはプロジェクト規模と要件で選択し、GitHub Actions が汎用性・無料枠のバランスで最も推奨されます。
- ベンチマーク（公式 Dashboard）に基づく最適化テクニック（インクリメンタルビルド、AOT オプション、永続キャッシュ）は全プラットフォームで 20‑30 % の時間削減を実現します。
- 他フレームワークと比較すると、Flutter は UI が単一コードベースであることからデプロイリスクが最も低く、特に iOS の自動コードサイン環境が整っていれば、チーム全体の生産性向上につながります。
以上を踏まえて、「Flutter 3.29 を基盤にした統一 CI/CD パイプライン」 を構築すれば、2025 年以降も安定してマルチプラットフォームアプリをリリースできる体制が整います。ぜひ本稿の設定例とチェックリストをご活用ください。