2026.08.27 開発

Firebase App Distributionとは｜配信物の分岐とテスター名簿・CI組み込みの設計【2026年8月時点】

Firebase App Distribution は、ストアの審査を挟まずに開発中のビルドをテスターの端末へ届ける仕組みです。導入だけなら、コンソールにファイルをドラッグするか、CI に配信コマンドを1本足せば終わります。運用で分かれ目になるのは、Android で APK と AAB のどちらを配るか、iOS の署名にテスターの端末を載せる経路があるか、そして名簿を誰がどこで持つかの3点です。この記事では配信物の分岐条件、上限値、CI からの自動配信、TestFlight や Play のテストトラックとの棲み分けを扱います。数値は2026年8月時点の実測です。

まとめ：配信物の形式とテスター名簿の持ち主を先に決める

最初に決めるのは配信物です。Android で AAB を配るなら、Firebase の Android アプリと Google Play 上のアプリを同一パッケージ名でリンクしておく前提が付きます。iOS は Ad Hoc 配布のプロファイルにテスターの端末が載るまでインストールできません。この2つが片付けば、残りはコマンドとグループの設定作業に落ちます。

次に名簿です。テスターは1プロジェクト500人・1グループ200人、招待は30日で失効、リリースは150日で消えて1アプリ1,000件が上限。数値そのものより、権限の単位がグループであること、そして配信履歴が半年で消える前提で検収の証跡を別に持つことが設計に効いてきます。

棲み分けは単純です。外部の一般ユーザーへ配るベータと、本番同等の課金・審査を通す検証は TestFlight や Play のテストトラックの領分。日々ビルドが更新される開発中の QA と、受注側・発注側をまたぐ UAT は App Distribution が速い。両方を併走させて構いません。

App Distributionが配信できる成果物とストア審査を挟まない制約

まず引き受ける範囲を確認します。ここを曖昧にしたまま名簿を作り始めると、後から配信物の形式を変えることになり、テスター側の入れ直しが発生します。

APK・AAB・IPAという3系統で入口も配られ方も変わってくる

受け付ける成果物は APK・AAB・IPA の3つで、iOS と Android の両方を1つのプロジェクトで扱えます。バイナリの上限は 2048 MiB。ゲームのように容量が張る案件でも、この枠に収まるかは先に測っておくところです。

APK はアップロードしたものがそのまま配られます。AAB は挙動が違い、Google Play の内部アプリ共有が受け取って、テスターの端末構成に合わせた APK を生成して配る形。おかげで Play Feature Delivery や Play Asset Delivery を使った構成でも、本番に近い形で確認できます。ダウンロードのサイズも小さくなる。

ただし AAB には条件が付きます。Firebase の Android アプリと Google Play 上のアプリを、同一パッケージ名でリンクしていないと AAB はアップロードできません。Play へまだ登録していない社内配布だけの案件なら、APK で回すほうが手数は少なくて済みます。

リリースは150日で消え1アプリ1,000件を超えると古い順に落ちる

配信したビルドは、アップロードから150日でダッシュボードから削除されます。期限の30日前に通知が出る作り。あわせて1アプリあたりのリリースは1,000件が上限で、超えたぶんは古い順に自動で消えていきます。

日次でビルドを配る案件だと1,000件はそれほど遠い数字ではありません。受託開発では「どのビルドを誰がいつ受け入れたか」が検収の材料になるため、配信履歴をそのまま証跡に使う設計は避けたほうが無難です。ビルド成果物とビルド番号は CI 側のアーティファクト保管に寄せ、App Distribution は流通の経路として割り切ってください。

テスターは1プロジェクト500人・1グループ200人という上限で動く

テスターの上限は、1つの Firebase プロジェクトで500人、1つのグループで200人です。どちらも無償で引き上げを申請できるため、上限そのものが壁になる場面は多くありません。効いてくるのは権限の単位のほうです。

項目	値（2026年8月時点）	設計への効き方
バイナリ上限	2048 MiB	超えると配信できない
リリース保持	150日	30日前に通知が出る
リリース件数	1アプリ1,000件	古い順に自動削除
テスター（全体）	500人	引き上げ申請は無償
テスター（グループ）	200人	権限の単位になる
招待の有効期限	30日	5日前に通知・再送可

グループからテスターを外すと、そのグループ経由で配ったすべてのリリースへのアクセスが同時に消えます。逆に言えば、個別のメールアドレス指定で配ってしまうと、後から一括で権限を落とせません。発注側 QA・現場担当・開発チームのようにグループを切っておくのが、引き渡しまで含めて楽な形です。

iOSは署名の壁でAndroidは配信物の選択が実装の分かれ目になる

ここからは実装側の話です。手順書どおりに進めても止まる箇所は、ほぼ OS ごとの前提条件に集中しています。プロジェクト作成からSDK導入までの導入手順を済ませた状態を前提に、詰まりやすい部分だけを扱います。

Ad Hocはプロファイルへ端末が載るまでインストールできない

iOS で最も多い停止要因がこれです。Ad Hoc 配布のビルドは、署名に使ったプロビジョニングプロファイルに端末が登録されていないとインストールできません。テスターが端末を登録するとその UDID が収集され、開発者へメールで通知が届きます。開発者はプロファイルへ UDID を足し、ビルドし直して配り直す。この往復が1周まわるまで、テスターの画面ではインストールが失敗し続けます。

もう1つ、通知にも癖があります。過去に同じビルド番号・バージョン番号のビルドを配っていない場合、新しく端末を登録したテスターには新リリースの通知が飛びません。iOS 16 以降ではテスター側でデベロッパモードの有効化も要ります。この辺りの前提はiOSアプリ開発の進め方と合わせて、発注側にも先に説明しておくと問い合わせが減ります。

UDIDの回収はfastlaneとCloud Functionsで往復を自動化できる

UDID の回収を手作業で回すと、テスターが増えるたびに開発者の手が止まります。書き出す経路は3つ。Firebase コンソールからの手動エクスポート、Firebase CLI、そして fastlane の firebase_app_distribution_get_udids アクションです。

さらに踏み込むなら、UDID をプロビジョニングプロファイルへ追加し、ビルドし直して再配信するところまでを関数側で連結できます。fastlaneによるビルドと配信の自動化を組んである案件なら、追加の作業量は小さい。なお、この連携を Cloud Functions で受ける構成は Blaze プランが前提です。

AABを選ぶとGoogle Play側のリンクが前提条件として付いてくる

Android 側の分岐は、APK と AAB のどちらを配信物にするかだけです。判断材料は Play へのリンクを張れるかどうか。張れるなら AAB を選び、端末構成ごとに生成された APK でテストしたほうが、機種依存の不具合を拾えます。

張れない、あるいは Play にまだアプリを作っていない段階なら APK です。社内向けの業務アプリで、そもそもストア配信を予定していない案件もここに入ります。途中で AAB へ切り替えることはできるので、初期は APK で回して、Play の登録が済んだ時点で artifactType を切り替える進め方でも問題ありません。

Gradle・CLI・fastlaneのどれでCIから配信を回すかの判断

配信を人手で回している限り、テスト版は「誰かが思い出したとき」にしか更新されません。CI に載せると更新の頻度が安定します。手段は Gradle プラグイン・CLI・fastlane の3つで、どれを選んでも認証の考え方は共通です。

Gradleプラグイン5.3系のappDistributionブロックで指定する項目

Android のビルドへ直接組み込むなら Gradle プラグインです。プラグイン ID は com.google.firebase.appdistribution で、2026年8月時点は 5.3.0系。ビルド種別ごとに配信先と成果物の種類を書き分けられます。

appDistribution {
    artifactType = "AAB"
    groupsFile = "app/groups.txt"
    releaseNotesFile = "app/release-notes.txt"
    serviceCredentialsFile = "app/sa.json"
}

実行タスクは appDistributionUpload にビルド種別名を付けたもので、リリースビルドなら appDistributionUploadRelease です。テスターやグループはインラインでも書けますが、ファイル参照にしておくとレビューの対象がテキスト1本に収まります。

CLIのdistributeコマンドは名簿をファイルで渡すと運用が崩れない

Gradle を使わない構成や iOS では CLI が主役になります。基本形は成果物のパスに続けてアプリ ID を渡すだけ。名簿とリリースノートはファイル指定にしておくと、変更が Git の差分として残ります。

firebase appdistribution:distribute app.aab \
  --app 1:1234567890:android:abcdef \
  --release-notes-file release-notes.txt \
  --groups-file groups.txt

テスターの削除は appdistribution:testers:remove で、追加と合わせてスクリプト化できます。CLI そのものの導入と版の考え方はFirebase CLIの認証とデプロイ運用にまとめてあります。

認証はサービスアカウントへ寄せて個人のトークン運用を残さない

認証の解決順は決まっています。Gradle なら serviceCredentialsFile の指定、次に環境変数 GOOGLE_APPLICATION_CREDENTIALS、どちらも無ければ Firebase CLI がローカルに持っている資格情報です。CI で最後の経路に落ちると、誰かの個人アカウントでビルドが流れる状態になります。

CI からの配信は、サービスアカウントを明示する形に寄せてください。鍵ファイル自体を置きたくない場合は、Workload Identity 連携の資格情報構成ファイルを渡す構成も取れます。GitHub Actions での組み方はFirebaseとGitHub Actionsの連携によるデプロイ自動化と同じ考え方で、シークレットの置き場所と権限の範囲を先に決めるところから始めます。

テスターの端末側で起きることをSDKの構成と通知の設計で決めておく

配る側が片付いたら受け取る側です。新しいビルドに気付く経路と、不具合を戻す経路を作れば、配信の回転がそのまま検証の回転になります。

App Distribution SDKはベータで本番ビルドに載せない分け方

アプリ内に「新しいビルドがあります」の案内を出すには App Distribution SDK を入れます。iOS・Android とも位置づけはベータで、後方互換のない変更が入る可能性があると明記されている点は踏まえておくところです。

Android では依存を2つに分けます。全ビルド種別に firebase-appdistribution-api を入れ、プレリリース種別にだけ firebase-appdistribution を足す形。本番ビルドには何もしない実装だけが残るため、テスト用の導線がストア版へ漏れません。呼び出しは checkForUpdate() に任せる基本構成と、signInTester() で独自の画面を作る構成の2択です。テスターは端末ごとに一度、Google アカウントでのサインインを求められます。

アプリ内フィードバックはAndroid限定で画面の写しが自動で付く

テスターからの報告を受け取る仕組みも SDK 側にあります。通知を常駐させる showFeedbackNotification() か、独自のきっかけから呼ぶ startFeedback()。送信時にはその画面のスクリーンショットが自動で添付され、コンソールのリリース単位のタブに集まります。

注意点は対応範囲です。この機能は Android のみで、iOS には同等の口がありません。両 OS を同じ運用で回すなら、フォームやチャットなど別の窓口を1本用意して、そちらへ揃えるほうが混乱しません。

配信ビルドではクラッシュ収集と不正クライアント対策の設定を揃える

テスト版で拾った不具合を追うには、クラッシュ収集が入っていることが前提になります。テスト版で意図的にクラッシュを起こして経路を確認する手順は、Crashlyticsの収集とシンボル運用の側で整理しました。配信の初回にここを通しておくと、以降のビルドで悩む時間が減ります。

もう1つが App Check です。バックエンドへの呼び出しを保護している構成では、テスト版のビルドにデバッグ用プロバイダの設定が入っていないと、テスターの端末からの通信が弾かれます。App Checkのプロバイダ選定と強制への移行で扱った監視から強制への切り替えは、テスト版の配信経路も含めて確認してから進めるのが安全です。

TestFlightとPlayのテストトラックに対する棲み分けの決め方

App Distribution だけで完結する案件と、ストア側のテスト機構が要る案件があります。境目は「外部の一般ユーザーが入るか」と「本番同等の経路を検証するか」の2つです。

TestFlightは90日と初回審査という条件から使いどころが決まる

TestFlight の内部テスターは App Store Connect のユーザー100人まで、外部テスターは10,000人まで。ビルドのテスト可能期間は90日で、グループへ最初のビルドを追加した時点で App Review に送られます。テスター1人あたり30台までという枠もあります。

この条件から、外部への公開ベータや、レビューを通った状態での動作確認は TestFlight の領分です。一方で、1日に何度も差し替わる開発中のビルドを配る用途には向きません。審査待ちと90日の期限が、そのまま検証サイクルの制約になるためです。

Play内部テストは100人でクローズドテストは条件が重くなる

Google Play 側は、内部テストが1アプリ100人まで。クローズドテストはリストが200個・1リスト2,000人まで、1トラックあたり50リストという枠で、規模の面では余裕があります。

気を付けたいのは公開までの条件です。2023年11月13日以降に作成した個人開発者アカウントは、12人のテスターが14日連続でオプトインしたクローズドテストを実施しないと本番公開を申請できません。受託案件で発注側が法人アカウントを持っていれば関係しませんが、個人名義のアカウントで進める案件では、この人数集めがスケジュールに乗ってきます。App Distribution 側の配信とは別建てで確保する必要がある点に注意してください。

観点	App Distribution	TestFlight	Play内部テスト
対象OS	iOSとAndroid	Appleの各OS	Androidのみ
人数の上限	500人	外部10,000人	100人
事前の審査	なし	初回ビルドで必要	原則なし
ビルドの寿命	150日	90日	期限なし

App Testing agentはAndroidのプレビューで月200テストまで無償

2026年8月時点の App Distribution には、Gemini in Firebase による App Testing agent が乗っています。自然言語で書いたテストケースを YAML かコンソールで管理し、Test Lab の実機・仮想端末で並列に実行して、画面の遷移と結果を返す仕組みです。CLI からは apptesting:execute、配信コマンド側からは --test-devices などのフラグで呼べます。実行基盤となる Test Lab 側の課金単位と端末の選び分けはFirebase Test Labを扱った記事で整理しています。

ただし現状は Android のみのプレビューで、SLA も廃止ポリシーの対象外。既定のクォータは1プロジェクトあたり月200テストで、プレビュー中は無償です。1テストあたり5分のタイムアウトがあり、FLAG_SECURE を立てた画面は操作できず、扱える操作もタップ・入力・スワイプ・長押し・ドラッグ・戻る・待機に限られます。回帰テストの置き換えではなく、配信のたびに主要導線が生きているかを確かめる煙テストとして置くのが、今の解像度に合った使い方です。

受託開発の検収とUATへ組み込む前に決めておきたい4つの取り決め

最後は判断です。受託案件でこの仕組みを配信の主線に据えてよいか、どこで別の手段に切り替えるかを、条件の形で置いておきます。

App Distributionを配信の主線に据えてよい受託案件の3条件

3つとも満たすなら、迷わず主線に据えて構いません。第一に、テスターが500人以内に収まり、名簿を発注側と共有できること。第二に、iOS の署名を受注側が握っていて、プロビジョニングプロファイルの更新を自分たちで回せること。第三に、検収の証跡をビルド成果物として CI 側に保管できること。

とくに2番目が効きます。署名を発注側の Apple Developer アカウントで管理していて、更新のたびに先方の稟議が要る体制だと、UDID を1件足すのに数日かかることがある。この場合は配信手段の問題ではないので、体制側を先に整えるほうが早い解決になります。

配信の主線をApp Distribution以外へ移すべき4つの場面

逆に、次の場面では別の手段を主線にします。1つ目は外部の一般ユーザーを含むベータ。人数の桁と招待の運用が合いません。2つ目は MDM で端末が管理された配布先で、ここは MDM の配信機構に乗せるのが筋です。

3つ目は課金・プッシュ通知・レシート検証など、ストア経由でないと本番同等にならない検証。4つ目は、署名や Play アカウントを発注側が握っていて更新の権限が渡らない案件です。この4つに当たる場合でも、開発チーム内の日次ビルド共有だけを App Distribution に残す併走は成り立ちます。

保守フェーズへ引き渡す前に名簿と権限の持ち主の線引きを決めておく

運用が始まってから揉めるのは、たいてい名簿の所有権です。プロジェクトの所有者は誰か、テスターの追加と削除を誰が実行するか、退職・異動でテスターを外す手順を誰が持つか。この3点を引き渡し前に文書化しておけば、保守フェーズで判断が止まりません。

グループ設計も同時に決めます。発注側 QA・現場の利用者・受注側開発の3系統に分けておくと、リリースごとに配る範囲を切り替えられ、外すときも一度で済みます。iOS と Android の両方を1つの名簿で扱う体制づくりを含めて相談したい場合は、スマホアプリ開発の窓口から具体的な案件の条件をお伝えください。

よくある質問

Firebase App Distributionは無料で使えますか？

Firebase の料金ページでは、App Distribution は Spark プラン・Blaze プランのいずれでも No-cost と示されています。ただし App Testing agent の実行基盤である Test Lab は、仮想端末が1日60分、実機が1日30分までが無償で、超過分は仮想端末が1台1時間あたり1ドル、実機が5ドルの課金です。Cloud Functions を絡めた自動化を組む場合も Blaze プランが前提になります。

配信したビルドはいつまでテスターがインストールできますか？

アップロードから150日です。期限の30日前になるとコンソール上に通知が出ます。あわせて1アプリあたりのリリース数は1,000件が上限で、これを超えると古いリリースから自動で削除されます。長期の保守案件では、配信履歴を検収の証跡として当てにせず、CI のアーティファクトとして別に保管する設計にしてください。

iOSでテスターがインストールできないときは何を疑いますか？

最初に疑うのは端末の登録状況です。Ad Hoc 配布では、プロビジョニングプロファイルにその端末の UDID が載っていないとインストールできません。次に iOS 16 以降のデベロッパモードが有効かどうか、企業内配布の証明書であれば設定画面で信頼の操作が済んでいるかを確認します。

AABとAPKはどちらを配ればよいですか？

Google Play 上のアプリと同一パッケージ名でリンクを張れるなら AAB です。内部アプリ共有がテスターの端末構成に合わせた APK を生成するため、機種依存の不具合や Play Feature Delivery の構成を実機に近い形で確認できます。Play へまだ登録していない案件や、ストア配信を予定しない社内アプリは APK で回すほうが手数が少なくて済みます。

TestFlightの代わりとして使えますか？

用途によります。開発中のビルドを社内 QA と発注側の担当者へ配る範囲であれば置き換えられますし、審査待ちが無いぶん回転も速いところです。一方、外部の一般ユーザーを含むベータ、App Review を通った状態での確認、ストア経由の課金やレシート検証は TestFlight でなければ再現できません。実務では両方を併走させ、日次の配信を App Distribution、リリース直前の確認を TestFlight という分担にする形が扱いやすい構成です。