TestFlightのビルドは、アップロードから最大90日間だけテストできます。90日を過ぎるとビルドは期限切れ（Expired）になり、テスターはインストールも起動もできなくなります。90日を超えて「延長」する方法はなく、新しいビルドをアップロードして置き換えるのが唯一の解決策です。新しいビルドには、それぞれ独立した90日間の期限が設定されます。
結論（先に答え）
TestFlightの90日制限は、ビルドをアップロードした時点から数え始めます。AppleのTestFlightページによると、テスターはビルドを最大90日間テストでき、その後は期限切れになります。この期限を直接延ばすことはできません。テストを続けるには、新しいビルドをアップロードします。新ビルドは処理と、外部テスターの場合はベータ App Review を経て、また90日間有効になります。内部テスターも外部テスターも、同じ90日の制限です。
TestFlightの90日制限とは？
90日制限とは、1つのビルドがテスト可能な最長期間のことです。アップロード日を1日目として数え、90日目を過ぎるとそのビルドは自動的に期限切れになります。App Store Connect のビルド一覧には残り日数が表示されるので、いつ切れるかを事前に確認できます。
この制限はビルドごとに独立しています。つまり、古いビルドが期限切れになっても、新しいビルドが有効であればテストは続けられます。プロジェクト全体やアプリが止まるわけではなく、あくまで個々のビルドに期限がある、という点が理解の鍵です。
なぜビルドは90日で期限切れになるのか
ベータ版はあくまでテスト用の一時的な配布であり、古いビルドが無期限に出回らないようにするためです。90日という上限があることで、テスターは常に比較的新しいビルドを使うことになり、すでに修正済みの不具合を古いビルドで報告し続ける、といった無駄を防げます。
言い換えると、これは不具合ではなく仕様です。「延長できない」ことに苛立つより、90日を1つのリリースサイクルの目安として使うほうが実務的です。多くのチームは、この期限が来る前に次のビルドを用意する運用にしています。
「延長」はできる？新しいビルドで置き換える
結論から言うと、既存ビルドの90日を延ばすことはできません。できるのは、新しいビルドをアップロードして置き換えることだけです。新ビルドは独立した90日間の期限を持つため、実質的にはこれが「延長」の役割を果たします。
ビルド番号を上げて同じバージョンで再アップロードするか、次のバージョンを配信します。外部テスター向けの最初のビルドはベータ App Review が必要ですが、同じバージョンの以降のビルドは不要な場合があります。いずれにしても、期限切れを待たずに早めに置き換えるのが安全です。
期限と状態の早見表
残り日数はApp Store Connect のビルド一覧で確認できます。表示が「Expired」に変わると、そのビルドはテスターの端末で起動できなくなります。
| 状態 | 意味 | 期間 | 次のアクション |
|---|---|---|---|
| 配信中（残り日数表示） | ビルドはテスト可能 | アップロードから最大90日 | 残り日数を監視 |
| まもなく期限切れ | 残り数日 | 90日目に近い | 新ビルドを準備 |
| 期限切れ（Expired） | インストール・起動が不可 | 90日経過後 | 新ビルドをアップロード |
| 処理中 | 新ビルドを検証中 | 数分〜1時間 | 完了を待つ |
期限切れを防ぐ手順
最も確実なのは、期限切れを待たずに新しいビルドを定期的にアップロードする運用です。手順はシンプルです。まず、App Store Connect で現在のビルドの残り日数を確認します。次に、残りが数日になったら新しいビルドを準備します。そして、CI（Xcode Cloud や Fastlane など）で自動アップロードを設定しておくと、手動での忘れを防げます。
自動化が難しい場合でも、カレンダーに期限のリマインダーを入れておくだけで大きく違います。期限当日ではなく、数日前に動けるよう余裕を持たせるのがコツです。こうしておけば、審査に時間がかかっても間に合います。
テスターへの影響と伝え方
ビルドが期限切れになると、テスターはアプリを開けなくなり、「このビルドは期限切れです」といった趣旨のメッセージが表示されます。新しいビルドが配信されれば、TestFlight アプリから更新して再びテストできます。
混乱を避けるには、期限が近いことと新ビルドの予定を、事前にテスターへ伝えておくとよいでしょう。特に外部テスターは事情を知らないことが多いため、短い連絡があるだけで問い合わせが減ります。
期限切れを防ぐチェックリスト
この4項目を習慣にすれば、期限切れでテストが突然止まる事態はほぼ防げます。特にセキュリティ点検は、却下による手戻りを避けるうえで見落とされがちな項目です。
| 確認項目 | なぜ重要か | いつ行うか |
|---|---|---|
| 残り日数の確認 | 期限切れを事前に察知できる | 週に1回 |
| CIでの新ビルド自動アップロード | 手動の忘れを防ぐ | リリースごと |
| テスターへの事前連絡 | 起動不可による混乱を防ぐ | 期限の数日前 |
| ビルドのセキュリティ点検 | 却下や手戻りを防ぐ | アップロード前 |
いつサポートに問い合わせるか
90日の期限そのものはAppleの仕様なので、延長を求めてサポートに問い合わせても解決しません。問い合わせが役立つのは、残り日数の表示がおかしい、新ビルドをアップロードしても処理が進まない、といった技術的な不具合が疑われる場合です。
その際は、ビルド番号、アップロード日時、状態のスクリーンショットを添えると、やり取りがスムーズになります。ベータ App Review での却下については、Resolution Center（問題解決センター）で理由を確認し、そこで返信します。
アップロード前にビルドを点検する
新しいビルドで「延長」する運用では、アップロードの回数が増えます。そのたびにベータ App Review で却下されると、そのぶん手戻りが発生します。埋め込まれた秘密鍵、正当な理由のない権限、安全でない通信設定などは、却下や指摘の典型的な原因です。
PTKD.com のようなセキュリティスキャナーは、アップロード前に .ipa を解析し、重大度順に並べて OWASP MASVS に対応づけたレポートを返します。これにより、却下につながる問題を事前に修正できます。ただし限界も正直に言えば、スキャナーはAppleの審査を速めるわけでも、高リスクなアプリでの手動監査を置き換えるわけでもありません。あくまで、避けられる却下を減らすための道具です。
まとめ
- TestFlightのビルドはアップロードから最大90日間で、それを直接延ばすことはできません。
- テストを続けるには、新しいビルドをアップロードして置き換えます。新ビルドは独立した90日間の期限を持ちます。
- 内部テスターも外部テスターも同じ90日制限で、期限切れのビルドは起動できなくなります。
- 期限切れを防ぐには、残り日数を監視し、CIで自動アップロードを設定し、テスターへ事前に連絡します。
- アップロード前にPTKD.comでビルドを点検し、却下による手戻りを防ぎましょう。
