LASSIC Media らしくメディア

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

アプリのベータ配信・内部テストとは — リリース前に品質を固める工程

アプリのベータ配信・内部テストとは、正式リリースの前に限定されたテスターへビルドを配布し、実機での動作・不具合・使い勝手を確認する運用工程を指します。iOSではTestFlight、AndroidではGoogle Play Consoleのテストトラック（内部テスト・クローズドテスト・オープンテスト）が、それぞれの公式な仕組みとして用意されています^*1*3。

この工程は、ストア公開の審査対応（ASO・リリースノート作成）やクラッシュ解析基盤の構築、A/Bテスト基盤の整備とは別の論点になります。ストア審査は「公開してよいアプリかどうか」の合否判定であり、クラッシュ解析やA/Bテストは公開後の品質・仮説検証を扱う領域と言えるでしょう。本稿はその手前にある「限定した相手にビルドを配って試してもらう」運用設計に絞って解説します。

ベータ配信・内部テストの目的は、社内外の少人数で先に不具合を見つけ、正式リリース後の大規模な障害を避けることにあります。テスターの招集方法、ビルドの配布経路、フィードバックの集め方、そして本番公開までの展開方法——この4点を事前に設計しておかないと、テストが形骸化しやすくなるでしょう。

iOSとAndroidでは、テスト機能の名称も上限も審査有無も異なります。次章以降でそれぞれの仕様を具体的に確認していきましょう。

TestFlightの内部テストと外部テストの違い

TestFlightはAppleが提供するベータ配信の公式ツールで、内部テスターと外部テスターの2種類を使い分ける設計になっています^*1。

内部テスターは100人・App Store Connectのアカウント保有者

内部テスターは、App Store Connectへのアクセス権を持つメンバーに限定され、上限は100人です^*1。追加のApp Review（アプリ審査）を経ずにビルドを配布できるため、開発チーム内での初期検証にすぐ使える点が特徴です。社内の開発者・QA担当・プロダクトオーナーなど、権限管理が可能なメンバーに向いています。

外部テスターは10,000人・ベータ版App Reviewが必須

外部テスターは10,000人まで招待でき、社外の顧客やパートナーを含む幅広いテスト運用に対応します^*1。ただし外部テスターへ配布する場合、最初のビルドはベータ版App Reviewの承認を経る必要があり、グループに追加されたビルドは自動的に審査へ送られる仕組みです^*1。内部テストのように「すぐ配布」とはいかない前提を踏まえてスケジュールを組む必要があります。

ビルドの有効期限は90日

TestFlightで配布したビルドは、90日を過ぎるとテスターの端末で利用できなくなります^*1。長期間のベータ運用を行う場合は、期限が切れる前に新しいビルドをアップロードし続ける体制が欠かせません。90日を超えて特定のビルドを動かし続けたい事情がある場合、TestFlight自体には延長機能がなく、Ad Hoc配布など別の配布手段を検討する必要が出てきます^*1。

内部・外部いずれのテスターも、1つのビルドを30台のデバイスにインストールでき、同時にテストできるビルド数は100件という上限があります^*1。複数バージョンを並行検証する場合はこの上限を意識しておくとよいでしょう。

Google Playのテストトラック（内部・クローズド・オープン）

Google Play Consoleでは、内部テスト・クローズドテスト・オープンテストという3段階のテストトラックが用意されています^*3。それぞれ対象規模と審査の有無が異なります。

内部テストはポリシー審査対象外・数分で利用可能

内部テストは100人のテスターに配布でき、通常のPlayポリシー審査やセキュリティレビューの対象外です^*3。テスターは登録から数分程度で利用を開始できるとされており^*3、開発初期の未完成な状態のアプリでも社内検証に使いやすいトラックです。

クローズドテストは200リスト・リストごとに2,000人

クローズドテストは、メールアドレスのリストやGoogleグループを使ってテスターを管理する仕組みで、1リストあたり2,000人、200リストまで作成できます^*3。内部テストより広い範囲でのテストが可能ですが、通常のポリシー審査が適用され、テスターが利用できるまで数時間かかる場合があります^*3。既存顧客やパートナー企業を絞り込んで招待する用途に向いています。

オープンテストはストア上に公開され誰でも参加可能

オープンテストは、Google Play上でベータ版として一般に公開されるトラックです^*3。参加人数の上限はデフォルトで無制限か、最小1,000人以上の範囲で任意の上限を設定できます^*3。通常のポリシー審査が適用され、公開までに数時間を要する点はクローズドテストと同様といえます^*3。不特定多数からのフィードバックを集めたい場合や、大規模な負荷を想定した検証に適したトラックです。

段階的な公開（Staged Rollout）でリスクを抑える

ベータ配信・内部テストを終えた後、正式リリースをいきなり全ユーザーに配信するのではなく、段階的に展開してリスクを抑える運用がStaged Rollout（段階的な公開）です^*4。

ロールアウト対象は無作為に選ばれる

Google Playの段階的な公開では、リリース時に配信対象とするユーザーの割合を指定でき、新規ユーザー・既存ユーザーの双方から無作為に対象が選ばれます^*4。特定の属性を狙って先行配信する機能ではなく、あくまで母集団からのランダムサンプリングという位置づけです。

割合の引き上げは自動ではなく手動判断

段階的な公開のパーセンテージは自動的に増加しません^*4。対象を広げるには、Play Consoleのリリース管理画面から手動でロールアウト率を更新する操作が必要です^*4。この仕様により、初期の反応やクラッシュ率を確認してから次の段階に進むという、人の判断を挟んだ展開が可能になります。

問題発生時はHalt（停止）で被害を止められる

配信中に不具合が判明した場合、ロールアウトを停止する操作により、それ以降の新規ユーザーへの配信を止められます^*4。ただし、すでにその版を受け取ったユーザーは引き続き当該バージョンを使い続けるため、完全に配信前の状態へ巻き戻せるわけではない点は理解しておく必要があります^*4。

iOS側では、TestFlightの外部テストで段階的に対象グループを広げる運用や、App Storeの「フェーズ配信」機能を組み合わせる方法が一般的です。いずれの環境でも、ベータ段階のテスト結果と本番の段階的公開のモニタリング指標を接続して見る体制こそ、リスクを抑えた展開の土台になるでしょう。

テスターからのフィードバック収集と運用フロー

ベータ配信の価値は、テスターがどれだけ具体的なフィードバックを返してくれるかで決まってきます。収集経路を設計段階で決めておくことが重要です。

TestFlightはアプリ内・スクリーンショット・メールの3経路

TestFlightでは、TestFlightアプリ内から直接フィードバックを送信する方法と、ベータアプリ内でスクリーンショットを撮影すると同時に送信する方法が用意されています^*1。tvOSや旧バージョンのiOSを使うテスターについては、事前に指定したメールアドレスへのフィードバック送信という経路が使われます^*1。集まったフィードバックはApp Store ConnectのTestFlight Feedbackセクションで確認できます^*1。

Google Playはテスターとのコミュニケーション手段を事前設計

Google Play側は、クローズドテストで使うメールリストやGoogleグループが、そのままフィードバック収集の連絡経路になり得ます^*3。オープンテストのように不特定多数が参加するトラックでは、専用のフォームやチャットツールなど、Play Console外の受け皿を別途用意しておかないと、意見が散逸しやすくなるでしょう。

フィードバックは受け取って終わりにしない

集めたフィードバックは、重複や優先度を整理したうえで開発チームの課題管理ツールに転記し、対応状況を追跡できる状態にしておく必要があります。テスターへの返信や修正状況の共有を怠ると、次回以降のテスト協力が得られにくくなるため、フィードバックを起点にした一次対応の窓口を決めておくことが運用継続のポイントと言えるでしょう。

招集したテスターの継続率も見落とせない観点です。毎回同じテスターに偏ると特定の利用パターンしか検証できず、逆に毎回入れ替えるとテスト自体のノウハウが蓄積されません。継続テスターと新規テスターを一定の比率で組み合わせる運用が、長期的なテスト品質の安定につながるはずです。

外注時に確認すべきテスト運用と引き継ぎの論点

ベータ配信・内部テストの運用を開発会社に委託する場合、ビルド配布だけを依頼して満足してしまうと、テスター管理やフィードバック対応が抜け落ちる事態が起こり得ます。発注前に整理しておきたい論点を見ていきましょう。

内製に必要なもの

内製でベータ配信・内部テストを運用するには、App Store ConnectとGoogle Play Consoleの両方を扱える担当者、テスター名簿の管理者、そしてフィードバックを技術要件へ翻訳できる橋渡し役の3つの役割が必要になります。ビルドのアップロードだけであれば開発者単独でも対応できますが、テスターとのコミュニケーションや優先順位付けまで含めると、単純な技術作業を超えた運用体制が求められるでしょう。

発注先への確認

提案書に「ベータテストを実施します」とだけ書かれている場合、テスターの募集方法・上限人数に対する運用計画・審査待ち時間を踏まえたスケジュール調整・フィードバックの集約先を具体的に質問しておきたいところです。TestFlightの外部テスト審査やGoogle Playのクローズド・オープンテスト審査には一定の時間がかかるため、リリース日から逆算したスケジュール感覚を持っているかどうかが、実務経験を見極める手がかりになるでしょう。

契約明記

契約終了後に運用を引き継ぐ可能性がある場合、テスター名簿・フィードバック記録・ビルド配布の設定情報を納品物に含めるよう契約段階で明記しておく必要があります。これらの情報がないまま引き継ぐと、後任の担当者がテスターへの再アナウンスから始めることになり、テスト再開までの空白期間が発生しかねません。App Store ConnectやGoogle Play Consoleのアカウント権限の移管範囲も、契約書上で明確にしておくべき事項と言えるでしょう。

ベータ配信・内部テストは一度型を作れば終わりではなく、リリースのたびに繰り返す運用です。発注時にはこの繰り返し運用まで見据えた体制を確認しておくことが、長期的な品質担保につながります。

まとめ：ベータ配信・内部テスト運用を機能させる3つの判断軸

本稿では、TestFlightとGoogle Playにおけるベータ配信・内部テストの仕組みと、段階的な公開・フィードバック収集・外注時の論点を整理しました。要点は3つに集約されるでしょう。第一に、iOSとAndroidではテスター上限・審査有無・ビルドの有効期限が異なるため、両者を混同せずスケジュールを組む必要があります。第二に、段階的な公開は自動で進むものではなく、初期指標を確認しながら手動で対象を広げる判断が前提になるでしょう。第三に、外注する場合はビルド配布だけでなくテスター管理とフィードバック集約・引き継ぎ資料の範囲まで発注前に確認する姿勢こそ、繰り返し運用の品質を左右する分かれ目と言えるでしょう。

よくある質問

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

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

1. *1　出典：Apple「TestFlight overview」（App Store Connect Help）https://developer.apple.com/help/app-store-connect/test-a-beta-version/testflight-overview/
2. *2　出典：Apple「TestFlight」公式紹介ページhttps://developer.apple.com/testflight/
3. *3　出典：Google「Set up your testing track」（Play Console Help）https://support.google.com/googleplay/android-developer/answer/9845334
4. *4　出典：Google「Release app updates with staged rollouts」（Play Console Help）https://support.google.com/googleplay/android-developer/answer/6346149
5. *5　出典：Google「Prepare and roll out a release」（Play Console Help）https://support.google.com/googleplay/android-developer/answer/9859348

Tweet