TestFlightとは?初めての招待からインストールまで、初心者のための完全ガイド

目次

確認日:2026年9月17日。この記事では主にiPhoneとiPadを取り上げます。Appleの画面やルールは更新されるため、本文でリンクしている公式の説明と、実際に表示される画面を優先してください。

アプリができたので、まずは友人に試してもらいたい。でも、App Storeで正式に公開する準備はまだできていない。ソースコードをそのまま送るわけにはいかず、インストール用のファイルを送っても、相手がインストールできるとは限りません。

そんな問題を解決するのが TestFlight です。

「TF」と呼ばれているものは、通常、TestFlightの略です。Appleが提供するテスト用の配布サービスで、開発者がベータ版をアップロードし、ほかの人を招待してインストールしてもらい、フィードバックを集め、改善したバージョンを配布できます。テスターがインストールするのは、スクリーンショットやウェブ上のデモではなく、デバイス上で実際に動くアプリです。[1][2]

まずは次の3点を覚えておきましょう。

  • 内部テストは、適切なApp Store Connectの権限を持つメンバー向けです。
  • 外部テストは、友人、顧客、コミュニティのユーザー向けです。開発者用の管理画面にアクセスする権限を渡す必要はありません。
  • 各ビルドをテストできるのは、アップロードした日から最長90日間です。テスト審査に通っても、正式に公開されたことにはなりません。[1][3]

誰かからリンクを受け取っただけなら、第9節「テスターがインストール、更新、フィードバック、テストの終了を行うには」から読んでください。自分のアプリをほかの人に配布したい場合は、最初から読み進めましょう。

1. TestFlight、App Store Connect、App Storeは、それぞれ何?

新しいアプリを、まだプレオープン中のお店に例えてみましょう。TestFlightは体験してくれる人を招くための仕組みで、App Storeは正式に営業を始めるための場所です。プレオープンにも期限やルールがあり、審査を回避するための抜け道ではありません。

名前は似ていますが、この3つは役割が異なります。

幅の広い表は左右にスクロールできます。キーボードでは表にフォーカスを合わせてから矢印キーを使ってください。

名称 主に使う人 用途
App Store Connect アプリの配布担当者と権限を持つチームメンバー アプリ情報、アップロード済みビルド、テスター、グループ、審査の管理
TestFlight 配布担当者が配布を設定し、テスターがクライアントアプリをインストール 招待の承諾、ベータ版のインストール、更新、問題のフィードバック
App Store 正式リリースされたアプリとそのユーザー 正式版の検索、ダウンロード、購入

App Storeからダウンロードするのは TestFlightというツール です。そのツールを使い、テストに招待されたアプリをインストールします。TestFlightにアプリが表示されても、App Storeで検索できるようになったわけではありません。[1][3]

AppleはTestFlightによって、「バージョンを配布する→テストに招待する→問題を集める→バージョンを更新する」という流れをつないでいます。現在のTestFlightでは、開発者がテスターのデバイス識別子を1人ずつ集めたり、テスターごとにインストール用のプロビジョニングプロファイルを作成したりする必要はありません。[2]

ただし、アプリを代わりに作ってくれるわけでも、すべての機能が正しいと証明してくれるわけでも、ベータ版を自動で正式版にしてくれるわけでもありません。テスト審査を通過していても、脆弱性がないことやデータが失われないことは保証されません。よく知らないアプリを試すときは、ほかにコピーのない大切なデータを危険にさらさないでください。

ビルドを作成してアップロードした後、Appleによる処理と必要なコンプライアンス対応を経て、内部グループでの招待、または外部グループでの審査と招待に進みます。最後にテスターがTestFlightで承諾してインストールします。正式公開は別の手順です。ビルドを作成してアップロードした後、Appleによる処理と必要なコンプライアンス対応を経て、内部グループでの招待、または外部グループでの審査と招待に進みます。最後にテスターがTestFlightで承諾してインストールします。正式公開は別の手順です。
管理画面のスクリーンショットではなく、流れを示した図です。外部テストに最初に提出するビルドには完全な審査が必要で、同じバージョンの後続ビルドも審査が免除されるとは限りません。必要に応じてテスト開始や通知を行った後も、相手が招待を承諾してインストールする必要があります。Appleは現在、外部グループを作る前に内部グループを作成するよう求めていますが、内部メンバー全員のインストールを先に済ませる必要があるという意味ではありません。また、処理や審査の所要時間を保証するものでもありません。

2. TestFlightの歴史:Appleがゼロから作ったものではない

歴史を知ると、古い解説記事で名称、人数、操作方法が違う理由がわかります。

  • 2011年1月:サードパーティーのサービスとして一般公開。当時、未公開のiPhoneアプリをテストするには、デバイス識別子、インストール用ファイル、プロビジョニングプロファイルなどを扱い、パソコンのiTunesで同期することがよくありました。TestFlightによってワイヤレスでのインストールが大幅に簡単になりました。これは非公開テストから一般向けサービスに移行した時点の話であり、会社の設立登記日ではありません。[H1]
  • 2012年3月:Burstlyによる買収が報じられる。この時点では、TestFlightはまだサードパーティーの製品でした。[H2]
  • 2014年2月:AppleがBurstlyを買収。TestFlightも親会社とともにAppleの傘下に入りました。[H3]
  • 2014年10月:AppleがiTunes Connectを通じたメール招待によるテストの提供を発表。iTunes Connectは現在のApp Store Connectの前身です。当時は最大1,000人を招待できました。これは過去の数字である点に注意してください。[H4]
  • 2017年7月:招待できる外部テスターが10,000人に拡大。[H5]
  • 2018年9月:Appleが公開招待リンクを導入。開発者はメールアドレスを1人ずつ事前に集めなくても、リンクの共有でテスターを募集できるようになりました。[H6]

現在は、iPhone、iPad、Mac、Apple Watch、Apple TV、Apple Vision Proなど、Appleの複数のプラットフォームに対応しています。この記事ではiPhoneを例にしていますが、iPhoneアプリしかテストできないという意味ではなく、Androidアプリを配布できるという意味でもありません。[2][3]

3. まずは5つの用語:ベータ版、バージョン、ビルド、グループ、審査

ベータ版(Beta):まだ検証や改善を進めているアプリの版で、不具合があるかもしれません。

バージョン(Version):1.0、1.1など、対外的なリリースのまとまりを示すものです。

ビルド(Build):ある1回の作成処理で生成された具体的なアプリです。例えば1.0(12)は、バージョン1.0、ビルド番号12を意味します。問題を修正したら1.0(13)をアップロードできます。対外的なバージョンは同じでも、インストールされる内容は変わっています。[7]

グループ(Group):どの人にどのビルドを届けるかを決める単位です。「チーム」と「先行体験」の2つのグループを作り、同じビルドや異なるビルドを割り当てられます。1つのグループに複数のビルドを追加でき、同じ通常ビルドを複数のグループに割り当てることもできます。[2][5][6]

テスト審査(TestFlight App Review):外部テストのためにAppleが行う審査です。App Storeで正式にリリースするための審査とは別のものです。[1][6]

次の関係を覚えておくと、迷いにくくなります。アプリはプロジェクト全体、ビルドはそのうちの特定のインストール内容、グループは誰が試せるかを決めるものです。公開招待リンクは外部グループに属し、特定のビルドにずっと固定されているわけではありません。

4. 始める前に、配布する側とテスターは何を準備すればいい?

配布する側が準備するもの

  1. 有効なApple Developer Programのメンバーシップ。Appleの現在の標準料金は年間99米ドルです。地域によって価格が異なる場合があり、条件を満たす一部の組織は料金免除を申請できます。TestFlightは関連するメンバーシップのサービスに含まれており、テスター用のサブスクリプションを別途購入するものではありません。[4]
  2. 正しいApp Store Connectのアプリレコード。アプリの識別子、署名、アップロード内容が対応している必要があります。別のアプリのインストール用ファイルを勝手に追加することはできません。[7]
  3. 必要十分で、過剰ではないアカウント権限。ビルドをアップロードできるのは、アカウント所有者、管理者、Appマネージャ、デベロッパの役割です。外部テストの管理には、アカウント所有者、管理者、Appマネージャのいずれかの役割が必要です。アップロードできても、外部テストのすべての設定を操作できるとは限りません。[6][7]
  4. テストに必要な情報。アプリの説明、フィードバック用メールアドレス、試してほしい内容などです。外部審査には連絡先情報に加え、審査担当者が実際にログインしたり機能を利用したりできる手段も必要です。[6][8]
  5. テストに使えるデバイスと時間。アップロードに成功しても、インストールや主要機能の検証が済んだことにはなりません。

自分のAppleのパスワードを友人に送らないでください。アプリを試してもらうには、管理用アカウントを共有するのではなく、招待を送りましょう。

一般のテスターが準備するもの

必要なのは、Appleアカウント、対応するデバイス、TestFlight、有効な招待だけです。有料の開発者プログラムに加入したり、開発者用の管理画面に入ったりする必要はありません。[1][3]

この記事の確認日時点で、Appleのテスター向けヘルプに記載されているiPhone、iPadの要件は、iOS 16、iPadOS 16以降です。ただし、個々のアプリがさらに新しいOSを要求する場合があります。公開招待でも、デバイスやOSのバージョンで対象を絞り込めます。TestFlightをインストールできても、その中のすべてのアプリをインストールできるとは限りません。[3][6]

職場や学校から提供された管理対象Appleアカウントを使う場合は、利用資格を特に確認してください。Appleの外部テストのヘルプには、この種のアカウントではビルドをテストできないと明記されています。一方、内部テストのヘルプでは、予約済みドメインで作成された管理対象アカウントはテストに使えないと別途明記されています。該当する場合は、対応するヘルプページと組織のポリシーを確認し、招待リンクの不具合だと決めつけないでください。[5][6]

5. 内部テストと外部テストは、何が違う?

最も重要な違いは、管理画面での立場と権限です。親しい相手かどうかでも、メールで招待したかどうかでもありません。

幅の広い表は左右にスクロールできます。キーボードでは表にフォーカスを合わせてから矢印キーを使ってください。

項目 内部テスト 外部テスト
対象者 そのアプリにアクセスでき、役割の条件を満たすApp Store Connectユーザー 管理画面の権限を必要としない、招待された試用者
人数の上限 内部テスター最大100人 アプリごとに外部テスター最大10,000人
管理画面のアカウント権限は必要か 必要 不要
メールで招待できるか できる できる
公開招待リンクを共有できるか できない できる
外部テスト審査は必要か この審査は不要。ただしアップロード後の処理とコンプライアンス要件は満たす必要がある 初回の提出には完全な審査が必要。同じバージョンの後続ビルドは完全な審査が不要な場合がある
よくある用途 自分自身と信頼できる共同作業メンバー 友人、顧客、少人数の試用、公開テスト

内部テスターになれる役割は、アカウント所有者(Account Holder)、管理者(Admin)、Appマネージャ(App Manager)、デベロッパ(Developer)、マーケティング(Marketing)です。加えて、そのアプリへのアクセス権が必要です。[2][5]

友人1人を個別にメールで招待する場合も、通常は外部テストを選ぶべきです。外部だからといって公開とは限りません。公開リンクを有効にせず、数人だけを招待することもできます。

審査を1つ省くために、一般のテスターに管理者権限を与えないでください。それは単なるインストール許可のスイッチではなく、実際の管理権限です。

もう1つ見落としやすい制限があります。個人の開発者アカウントで追加できるApp Store Connectユーザーは最大50人です。そのため、TestFlightの「内部テスター100人」という上限は、すべての個人アカウントで管理画面のメンバーを100人追加できるという意味ではありません。[9]

内部テストは条件を満たす管理画面ユーザー最大100人。外部テストはアプリごとに最大10,000人で、管理画面の利用資格は不要です。どちらもメール招待に対応し、公開リンクは外部グループでのみ使えます。内部テストは条件を満たす管理画面ユーザー最大100人。外部テストはアプリごとに最大10,000人で、管理画面の利用資格は不要です。どちらもメール招待に対応し、公開リンクは外部グループでのみ使えます。
利用資格の違いを示した図です。内部メンバーには対象となる役割と、そのアプリへの権限が必要です。個人の開発者アカウントには管理画面ユーザー数の制限もあります。外部テストでは管理画面の権限を与える必要はなく、初回の提出には完全なテスト審査が必要です。「メールで送るか、リンクで送るか」で内部と外部を分けるものではありません。

6. ビルドを追加するには?まず「アップロード」と「テストグループへの追加」を区別しよう

この2つは、実際には別の作業です。

  • ビルドのアップロード:作成済みのアプリを、開発ツールやビルドツールからAppleに渡すことです。
  • グループへのビルドの追加:アップロード済みの利用可能なビルドから、そのグループに配布するものを選ぶことです。

App Store Connectのテストグループにある「ビルドを追加(Add Builds)」は、ソースコードをドラッグすれば自動でアプリが生成される機能ではなく、ローカルファイルをアップロードするボタンでもありません。[5][6][7]

同じアプリのバージョン1.0にビルド5と6があります。内部グループにはビルド5、外部グループにはビルド5と6が割り当てられています。公開招待リンクは特定のビルドではなく、外部グループを指します。同じアプリのバージョン1.0にビルド5と6があります。内部グループにはビルド5、外部グループにはビルド5と6が割り当てられています。公開招待リンクは特定のビルドではなく、外部グループを指します。
架空のデータを使って関係を示した図です。1つのビルドを複数のグループに割り当てることができ、1つのグループに複数のビルドを追加することもできます。ビルド番号は、そのプロジェクトを実際にコンパイルした回数ではありません。公開リンクは外部グループに属し、グループ内のビルドも審査、有効期限、デバイスの条件を満たす必要があります。この図は通常の配布可能なビルドを示しており、Internal Onlyの特別な制限は含んでいません。

初めて配布するため、管理画面にまだアプリがない場合は?

アカウント所有者、管理者、Appマネージャのいずれかの役割で、マイApp(Apps)→「+」→ 新規App(New App)に進みます。プラットフォームを選び、アプリ名、プライマリ言語、アプリの識別子(Bundle ID)、管理用のSKUなど、必要な情報を入力します。その後、メンバーのアクセス範囲を設定して作成します。アプリの識別子はプロジェクトと一致している必要があります。どの識別子を使うかわからない場合は、まずビルド作成の担当者に確認し、別のアプリの識別子を適当に選ばないでください。

作成できない場合は、アカウント所有者が最新の契約に同意しているか確認してください。アプリレコードの作成は、管理画面に管理用の入口を作っただけであり、アップロードや公開が済んだことにはなりません。[15]

Xcodeでアップロードする基本的な手順

iOSプロジェクトがすでにある場合は、次の順序で操作できます。

  1. アプリの識別子と署名チームが、App Store Connectのアプリレコードに対応しているか確認します。
  2. 今回のアップロード用に、重複しないビルド番号を設定します。例えば1.0(12)から1.0(13)に増やします。
  3. 実機への配布に使うターゲットを選び、Product → Archiveをクリックしてアーカイブを作成します。シミュレータ向けのものをアップロードするのではありません。
  4. Window → Organizer → Archivesでアーカイブを選び、Distribute Appをクリックします。通常のTestFlightと、その後の正式リリースに使う場合は、TestFlight & App Storeを選びます。カスタムの手順ではApp Store Connectへの配布に相当します。画面に従って署名とアップロードを完了します。[16]
  5. アップロード後、App Store Connect → マイApp(Apps)→ 対象のアプリ → TestFlightで確認します。
  6. Appleによる処理を待ちます。輸出コンプライアンスについて質問された場合は、アプリで実際に使っている暗号化に基づいて正しく回答してください。先に進むために一律で「暗号化を使用していない」を選んではいけません。
  7. 処理が完了してビルドが利用可能になったら、内部または外部のテストグループに追加します。

Xcode CloudやTransporterなどのツールをアップロードに使うこともできます。ツールが違っても、Appleの処理、コンプライアンス対応、グループへの割り当て、外部審査を省略できるわけではありません。[7] アップロード用ツールやSDKの最低要件は変更されるため、作業時にはAppleの現在のアップロード要件を確認してください。ビルドに使用するSDKのバージョンと、アプリをインストールできるOSの最低バージョンは別のものです。[18]

「内部テスト専用」の選択肢に注意

TestFlight Internal Onlyは、アップロード方法によって付く制限です。このビルドは内部グループにしか追加できず、外部テストにも、正式版ユーザーへのリリースにも使えません。後で外部テストや正式リリースが必要になったら、適切な方法で新しいビルドをアップロードする必要があります。元のビルドを別のグループに移すだけでは対応できません。[5][6]

一方、通常のビルドを最初に内部グループへ追加しても、それだけで「内部テスト専用」のビルドになるわけではありません。「今は内部メンバーに試してもらっている」ことと、「このアップロードは内部でしか使えない制限がある」ことを混同しないでください。

AirBuildでアプリを開発している場合

AirBuildに、配布可能なビルドの準備、署名、アップロード、テストグループや招待の設定を手伝ってもらえます。まず「TestFlightに配布したい」と伝え、対象がチームメンバーなのか、外部の友人なのかを明確にします。そのうえで、権限のあるApple開発者チームを接続または確認し、テストの説明、フィードバック用メールアドレス、審査用の連絡先、公開リンクを有効にするかどうかを確認します。

Appleの処理、外部審査、人数、有効期限のルールは引き続き適用されます。引き渡しの際は、具体的なバージョンとビルド番号、利用可能になっているグループ、外部審査がまだ待機中かどうかを区別して確認する必要があります。AirBuildが手順を支援しても、Appleの審査を回避できるわけではなく、シミュレータでの検証ですべての実機の動作を確認できたことにもなりません。

以上はAirBuildでの進め方の説明であり、Appleが特定のツールの使用を義務付けているという意味ではありません。Mac上にローカルのXcodeがなくても、ほかの人と協力して配布するために、ビルド作成の細部をすべて学ぶ必要があるわけではありません。

7. 内部テスターを追加するには?招待は2回あるので注意

対象は、自分自身と、アプリの管理画面にアクセスする必要が実際にある共同作業メンバーです。

1回目:相手を権限のある管理画面ユーザーにする

アカウント所有者(Account Holder)、管理者(Admin)、Appマネージャ(App Manager)のいずれかの役割でユーザーを追加します。

  1. ユーザとアクセス(Users and Access)→ ユーザ(People)に進みます。
  2. 「+」をクリックし、氏名とメールアドレスを入力します。
  3. 適切な役割を割り当てます。アプリの範囲を制限できる役割なら、必要なアプリへの権限だけを与えます。最初から管理者にしないでください。管理者、財務、またはレポートや証明書などの追加リソースへのアクセス権を付与されたユーザーは、アプリ単位でアクセスを制限できません。権限を選ぶ前に、その範囲をよく確認してください。[9]
  4. 招待を送り、相手に承諾してもらい、管理画面へのアクセスを有効にします。

Appleの現在の説明では、この管理画面ユーザーへの招待は3日後に期限切れになります。期限切れになった場合は再送できます。これは後で送るTestFlightの招待とは別のもので、ビルドの90日間の有効期限とも異なります。[9]

相手がすでに条件を満たす役割と、そのアプリへの権限を持っている場合は、この手順を省略できます。

2回目:テスターとビルドを内部テストグループに追加する

  1. マイApp → 対象のアプリ → TestFlightに進みます。
  2. 内部テスト(Internal Testing)の横にある「+」をクリックし、「チーム」などのグループを新規作成します。
  3. グループを開き、テスターを招待(Invite Testers)、またはテスター一覧の横にある「+」を選びます。
  4. 条件を満たす管理画面のメンバーにチェックを入れ、グループに追加します。
  5. ビルドを追加(Add Builds)をクリックし、処理が完了してテスト可能なビルドを選びます。
  6. テスト内容(What to Test)を入力し、追加します。
  7. 相手にデバイスへTestFlightをインストールしてもらい、テストへの招待を承諾してからアプリをインストールしてもらいます。[5]

「一覧に人が載った」だけでは完了ではありません。利用可能なビルドがあり、相手が実際に招待を承諾してインストールしている必要があります。

招待したい人が見つからない場合は?まず、管理画面への招待を承諾したか、役割が条件を満たしているか、そのアプリへのアクセス権があるかを確認しましょう。すぐにアプリを再アップロードする必要はありません。

一部の内部グループでは自動配布を有効にできますが、どの作成元のビルドでも、すべてのグループに自動追加されると思わないでください。Appleの現在のヘルプでは、Xcode Cloudで作成したビルドはApp Store Connectで手動でグループに追加する必要があると特に明記されています。[5]

8. 外部テスターを追加するには?

対象は、友人、顧客、初期ユーザー、コミュニティのテスターです。初めてアプリをほかの人に共有するときは、通常こちらの方法が適しています。

まず、ビルドを受け取る外部グループを準備する

アカウント所有者、管理者、Appマネージャのいずれかの役割で操作します。

  1. 内部グループがなければ、先に作成します。Appleの現在の外部テストの手順では、「内部グループを先に作成する」ことが前提条件です。先に正式公開しなければならないという意味でも、外部テスターが先に内部メンバーになる必要があるという意味でもありません。[6]
  2. マイApp → 対象のアプリ → TestFlightに進みます。
  3. テスト情報(Test Information)にベータ版の説明とフィードバック用メールアドレスを入力し、審査に必要な連絡先情報もそろえます。ログインが必要な場合は、審査で使える有効なアクセス手段と操作方法を提供し、関連するサーバーが利用可能であることを確認します。実際のユーザーの個人データをデモ用の資料に使わないでください。[6][8][14]
  4. 外部テスト(External Testing)の横にある「+」をクリックし、「先行体験」などのグループを新規作成します。
  5. グループを開き、ビルドを追加をクリックして、プラットフォーム、バージョン、具体的なビルドを選びます。
  6. テスト内容を入力します。「自由に試してください」だけでなく、例えば「記録を1件作成し、アプリを終了して開き直し、記録が残っているか確認してください」と書きます。
  7. 必要に応じてテスターに自動通知(Automatically notify testers)にチェックを入れます。
  8. 画面の状態に応じて審査への提出またはテスト開始を選び、必要な審査がすべて完了するのを待ちます。
  9. メール、公開リンク、またはその両方でテスターを招待します。[6]

最初に審査に通れば、その後はずっと審査不要?

そうではありません。

外部テストに最初に提出するビルドには、完全な審査が必要です。同じバージョンの後続ビルドは、完全な審査が不要な場合もありますが、その後ずっと審査が免除されるとは約束できません。またAppleは、ベータ版の大きな更新については、配布前にテスト審査へ提出するよう求めています。[6][14]

審査にかかる時間は一定ではありません。「アップロード後、数分で必ずインストールできる」「24時間以内に必ず承認される」と約束しないでください。

ビルドを追加するときに自動通知を選ばなかった場合は、承認後にテスターに通知(Notify Testers)を行う必要があります。TestFlightの左側にあるビルド(Builds)でプラットフォームとバージョンを選び、そのビルドのステータス欄にある通知の操作をクリックします。承認済み、配布済み、相手がインストール済みは、それぞれ別の状態です。[6]

方法1:メールで招待する

外部グループを開き、テスター(Testers)の横にある「+」をクリックします。新しいテスターのメールアドレスを入力する、既存のテスターを選ぶ、または一覧を読み込むことができます。[6]

相手に届くのはテストへの招待です。App Store Connectの管理権限が与えられるわけではありません。

方法2:公開リンクを作成して共有する

外部グループのテスターページを開き、公開リンクを作成(Create Public Link)を選びます。

  1. すべての人に公開(Open to Anyone)、または条件で絞り込む(Filter by Criteria)を選びます。
  2. 必要に応じて、リンクで募集する人数の上限を設定します。1~10,000人に設定できますが、そのアプリの外部テスター総数の上限も適用されます。
  3. 絞り込む場合は、対象デバイスとOSのバージョンの条件を設定します。
  4. 確認後、実際に生成されたリンクをコピーし、友人に送ったり、コミュニティ、メール、ウェブサイトに掲載したりします。[6]

リンクは通常、https://testflight.apple.com/join/…で始まります。Appleが生成した実際のリンクをコピーしてください。後ろのコードを自分で作ったり、App Store Connectの管理ページのアドレスをインストール用リンクとして使ったりしてはいけません。

同じリンクをQRコードにすることもできますが、それは別の配布方法ではなく、審査を回避できるものでもありません。

リンクを共有する前に確認する4つのこと

  • 対象の外部グループに、共有したいビルドが入っている。
  • 必要な審査に通り、配布が始まっている。
  • ビルドが期限切れではなく、対象デバイスに対応している。
  • リンクが有効で、空き枠があり、絞り込み条件によって対象ユーザーが除外されていない。[3][6]

リンクを開けても、新しいバージョンを必ずインストールできるとは限りません。古いビルドが利用可能でも、最新のビルドがそのグループに配布済みとは限りません。

公開リンクはさらに転送できるため、非公開の招待者リストにはなりません。特定の数人だけを招待したい場合はメール招待を優先し、アプリ自体のアカウント権限でも適切にアクセスを制御してください。

公開リンクから参加した人の氏名とメールアドレスは、標準ではTestFlightのテスター一覧に表示されません。ただし、インストール日、利用セッション、クラッシュなどの情報は確認できます。本人がフィードバックを送る際にメールアドレスを提供する場合もあります。Appleやアプリ自体のログインシステムに対して完全に匿名になるという意味ではありません。[3][6]

後でビルドを更新するときは、通常、同じ外部グループのリンクを引き続き使えるため、毎回全員を募集し直す必要はありません。管理(Manage)で絞り込み条件や人数制限を変更したり、リンクを無効にしたりすることもできます。リンクの無効化は新規参加の入口を閉じる操作であり、インストール済みのアプリの削除、アプリのアカウントの削除、サーバーデータの消去ではありません。[6]

9. テスターがインストール、更新、フィードバック、テストの終了を行うには

招待を受け取ったら、テストに使うiPhoneまたはiPadで操作します。

  1. App StoreからApple公式の TestFlight をインストールします。
  2. 招待メールまたは公開リンクを開きます。
  3. 画面の案内に従ってTestFlightに進み、承諾(Accept)を選んでから、インストール(Install)をタップします。
  4. テスト内容を読み、使い始めます。
  5. 新しいビルドが届いたらTestFlightで更新します。自動更新を有効にすることもできます。すでに参加しているテスターには、アップデート(Update)や開く(Open)が直接表示される場合もあります。[3]

通常の外部テストでは、開発者のパスワードも、管理画面の役割も必要ありません。専用のサンドボックスアカウントを事前に作成する必要もありません。

スマートフォンに正式版が入っている場合、2つのアプリになる?

通常はなりません。同じアプリのTestFlightベータ版は、デバイス上のApp Store版を置き換えます。[3]

そのため、大切なデータは事前にバックアップまたは書き出しをしてください。ベータ版でデータ形式が変わる可能性があり、新しいバージョンが書き込んだデータを古いバージョンで読み戻せるとは限りません。バージョンの切り替えは、データを失わずに行えることが保証された操作ではありません。

開発者がほかの有効なビルドを引き続き提供している場合は、以前のビルド(Previous Builds)から選べます。ただし、過去のすべてのバージョンを永久に保存したダウンロード用の保管庫ではありません。[3]

開発者に伝わりやすいフィードバックの送り方は?

TestFlightで対象のアプリを開き、ベータ版フィードバックを送信(Send Beta Feedback)をタップします。対応するOSでは、テスト中のアプリでスクリーンショットを撮ってからフィードバックを送ることもできます。クラッシュ後に、補足情報の共有を求める案内が表示される場合もあります。[3]

「使えません」よりも、例えば次のように書くと役に立ちます。

使用しているのは[デバイスのモデル]、[OSのバージョン]で、アプリは[バージョンとビルド番号]です。設定を開いて言語を切り替え、ホーム画面に戻りました。ホーム画面の文字も一緒に切り替わると思っていましたが、実際には元の言語のままでした。2回試して、どちらも再現しました。スクリーンショットを添付します。

パスワード、支払い情報、ほかの人のプライバシーに関わる情報を、そのままスクリーンショットに含めないでください。TestFlight経由で送信したフィードバックはAppleにも提供されます。アプリ独自のフィードバック機能は、これとは別の経路です。[3]

テストをやめたいときは?

TestFlightでそのアプリの情報ページを開き、テストを停止(Stop Testing)を選びます。正式版がすでにある場合は、App Storeで改めてダウンロードまたは購入できます。ベータ版だけがあり、まだ正式リリースされていないアプリでは、戻れる正式版があるとは限りません。[3]

テストを停止しても、アプリで登録したアカウントが削除されるわけではありません。アカウントやクラウド上のデータは、アプリ独自のルールに従って処理する必要があります。

10. TestFlightで支払いをすると、実際に請求される?

TestFlightからインストールしたアプリで、Appleのアプリ内課金を通じて行うテスト取引はサンドボックスで処理され、実際の請求は発生しません。StoreKitを使ったサブスクリプションのテストも含まれます。[3][10]

「サンドボックス」は、購入手続きをリハーサルするための環境と考えるとわかりやすいでしょう。アプリは商品情報の取得、テスト購入の開始、購入の復元、取引通知の処理などを行えますが、それによって実際の売上が発生することはありません。[10]

特に誤解しやすいのは、このサンドボックスが適用される範囲です。

請求されないからといって、正式版が永久無料になるわけではない

Appleは、テスト中のアプリ内購入は、App Storeの正式版に購入履歴として引き継がれないと明記しています。「今1回購入ボタンを押せば、正式公開後もずっと会員になれる」とテスターに約束してはいけません。[3]

開発者が別途、アプリのアカウントに特典を付与することを決めた場合は、その開発者自身の事業上の対応です。TestFlightが自動で提供する仕組みではありません。

テスト用サブスクリプションの時間は、実際の課金期間とは違う

自動更新サブスクリプションについて、Appleの現在のTestFlightテスター向け説明では、本来の契約期間に関係なく、テスト中は毎日更新され、1週間に最大6回更新されます。サンドボックスアカウントの高度な制御では、更新速度を調整することもできます。別のサンドボックス環境にある「5分」「12回」などの設定値を、通常のTestFlightテストにそのまま当てはめないでください。[3][10]

こうした時間短縮のルールは、更新や有効期限切れをテストするためのもので、正式版ユーザーの請求期間として扱うことはできません。

自動でサンドボックスに入るのはAppleの購入経路だけで、アプリ全体ではない

TestFlightのアプリでも、次のようなことは起こり得ます。

  • 本番サーバーに接続して実際の記録を変更する。
  • 実際にメールやメッセージを送信する。
  • 実際のアカウントやデータを削除する。
  • 本当に代金を受け取るウェブページを開く。
  • Appleのアプリ内課金ではない支払い方法を使う。

ウェブ決済、Apple Pay、StoreKitのアプリ内課金は、それぞれ別のものです。TestFlightから入れたアプリだからといって、ウェブ上の決済や実際の業務でお金がかからないとは限りません。開発者は、テスト用データ、サーバー、その他の決済環境を別途設定する必要があります。[10];アプリシステムの適用範囲についての説明

破線の内側はAppleのアプリ内課金のサンドボックステストです。実際の請求はなく、正式版の購入特典にも自動では引き継がれません。アプリのサーバー、ウェブやその他の決済、メール、データ操作は自動でサンドボックスに入るわけではありません。破線の内側はAppleのアプリ内課金のサンドボックステストです。実際の請求はなく、正式版の購入特典にも自動では引き継がれません。アプリのサーバー、ウェブやその他の決済、メール、データ操作は自動でサンドボックスに入るわけではありません。
適用範囲を示した図です。サンドボックスが対象とするのはAppleのアプリ内課金のテスト取引であり、サーバー、ウェブやその他の決済経路、実際の業務が自動で対象になるわけではありません。画面に価格が表示されても、実際の請求を意味するとは限りません。サンドボックス取引に成功しても、本番の購入や権利付与の処理が必ず正しいことの証明にはなりません。

テスター全員がサンドボックスアカウントを作る必要はある?

ありません。通常のTestFlightでのインストールや購入テストには、普段使っているAppleアカウントを使えます。[10]

購入履歴の消去や高度なテスト設定の調整などが必要な場合に限り、開発者はAppleの文書に従ってSandbox Apple Accountを設定する必要があります。高度な手順には「メディアと購入」からのサインアウトが含まれる場合があり、デバイス上の購入済みコンテンツへのアクセスに影響する可能性があります。これは一般のテスターがインストール前に行う必須作業ではなく、デバイス全体のiCloudから安易にサインアウトさせるべきでもありません。Appleは、専用のテストデバイスの使用を検討するよう勧めています。[10]

購入成功と表示されたのに機能が使えるようにならない場合も、開発者に報告してください。商品設定、取引の検証、利用権の付与、購入の復元、更新処理は、いずれも正しく実装する必要があります。サンドボックスで購入に成功しても、本番の支払い、売上の入金、すべてのサブスクリプション処理が正しいことの証明にはなりません。

11. TestFlightにはどんな制限がある?

幅の広い表は左右にスクロールできます。キーボードでは表にフォーカスを合わせてから矢印キーを使ってください。

ルール 実際に注意すること 出典
内部テスターは最大100人 条件を満たす管理画面の役割とアプリへの権限が必要。アカウントのユーザー数のルールも適用される [2][5][9]
外部テスターはアプリごとに最大10,000人 グループを増やしても、アプリ全体の枠は増えない [6]
公開リンクの人数は1~10,000人に設定可能 小規模な募集にもできるが、アプリ全体の上限は超えられない [6]
各ビルドは最長90日間 アップロード時から数える。審査の承認、招待の送信、インストールからではない [3]
テスター1人につき最大30台のデバイス デバイス、アプリ、招待の条件も満たしている必要がある [2][3]
最大100個のビルドを共有可能 複数のビルドを並行してテストできるという意味であり、100個を同時に審査へ提出できるわけではない [2]
TestFlight App Reviewへの提出は24時間に最大6ビルド テスト審査への提出数の制限であり、1日に6回しかアップロードできないという意味ではない [6]
各バージョンで同時にテスト審査中にできるのは1ビルドのみ そのビルドが承認されてから、同じバージョンの別のビルドを提出できる [6]
内部テスト専用のアップロード 制限のある同じビルドを、外部テストや正式リリースに使うことはできない [5][6]

90日が過ぎたら、招待を送り直せば使える?

使えません。期限はテスターごとではなく、ビルドに設定されています。後から参加した人に、改めて90日間が与えられるわけではありません。期限が切れるとベータ版を開けなくなるため、開発者が新しい有効なビルドを提供する必要があります。[3]

テストを途切れさせたくない場合は、古いビルドが期限切れになる前に新しいビルドをアップロードして配布し、更新を案内しましょう。新しいビルドには独自の期限があり、古いビルドの有効期間が延びるわけではありません。

TestFlightで長期的にアプリや参加枠を販売してもいい?

正式リリースを回避するための販売経路として使わないでください。

Appleの審査ガイドライン2.2は、テスト用アプリにも審査ルールの遵守と一般公開を目的とすることを求めています。また、クラウドファンディングの特典を含め、いかなる対価と引き換えにするTestFlightのテスト配布も禁止しています。簡単に言えば、「お金を払ってグループに入ればベータ版をもらえる」という形を、通常のTestFlightの配布方法にすることはできません。[14]

12. よくある問題:相手がインストールできないのはなぜ?

幅の広い表は左右にスクロールできます。キーボードでは表にフォーカスを合わせてから矢印キーを使ってください。

症状 最初に確認すること
アップロードは成功したが、管理画面にビルドがない Appleによる処理がまだ続いていないか、処理失敗のメールが届いていないか、正しいアプリとバージョンを見ているか
無効なバイナリ(Invalid Binary)と表示される Appleの具体的なアップロードエラーを確認し、修正して新しいビルドを提出する
コンプライアンス情報が不足(Missing Compliance)と表示される アプリの実態に合わせて輸出コンプライアンス情報を補う。単に審査を待ち続ける状態ではない
内部テストの招待一覧に相手が見つからない 管理画面への招待を承諾済みか、役割が条件を満たすか、そのアプリの権限があるか
ビルドを外部グループに追加できない 処理とコンプライアンス対応が完了しているか、誤って内部テスト専用でアップロードしていないか
審査待ち、またはテスト審査中になっている 外部テストに必要な承認をまだ得ていない。内部で利用可能でも、この手順の代わりにはならない
審査には通ったが、誰にも更新が届かない 対象グループに追加したか、テスターへの手動通知がまだ必要ではないか
リンクがテスターを受け付けなくなった 無効になっていないか、リンクの枠やアプリ全体の枠が埋まっていないか、利用可能なビルドがあるか
リンクは開けるが、インストールできるバージョンがない OS、デバイス、絞り込み条件、有効期限、グループに実際に入っているビルドを確認する
招待を送ったが、利用データがない 招待済み、承諾済み、インストール済みを区別する。インストール後のテスト指標の表示は最大24時間遅れる場合があるため、すぐにインストール失敗と判断しない [17]
相手に新機能が表示されない アプリ名だけでなく、インストールされているバージョンと括弧内のビルド番号を確認する
招待を承諾したのに、アプリでログインを求められる インストールする資格とアプリのアカウントは別。開発者が登録やログインの方法を別途案内する必要がある
しばらく使っていたアプリが突然開かなくなった まずTestFlightの残り日数と有効期限の状態を確認し、その後開発者に連絡する
サンドボックスで購入できたのに、正式版では会員になっていない テスト購入は正式版の購入特典に自動で変わらない。これだけで実際の支払いが反映されていないとは判断できない

これらは原因を調べるための確認項目であり、エラーメッセージ1つだけで根本原因を断定できるわけではありません。[3][5][6][11]

特に注意:管理画面の緑色の「テスト中(Testing)」も、内部グループだけが利用している状態かもしれません。外部ユーザーがインストールできるか判断するには、対象の外部グループ、具体的なビルド、そのグループでの利用可能状態を確認する必要があります。[11]

「提出準備完了(Ready to Submit)」「審査待ち(Waiting for Review)」「ベータ版審査中(In Beta Review)」「テスト準備完了(Ready to Test)」も、それぞれ異なる段階です。特にテスト準備完了でも、テスターの追加や手動通知がまだ必要な場合があります。[11]

13. 開発者はどこでフィードバックを確認し、次のバージョンを配布する?

マイApp → 対象のアプリ → TestFlight → フィードバック(Feedback)に進むと、スクリーンショット(Screenshots)とクラッシュ(Crashes)を確認でき、バージョンやデバイスなどの条件で絞り込めます。アプリ内からフィードバックを送れるかどうかは、グループの設定にも左右されます。[12]

まず再現できる問題に対応し、次のテストに進みます。

  1. 問題を修正し、新しいビルド番号でビルドを作成してアップロードします。
  2. 処理を待ち、必要なコンプライアンス対応を完了します。
  3. 新しいビルドを対象グループに追加し、必要な外部審査を完了します。
  4. テスト内容を更新し、設定に応じてテスターに通知します。
  5. 対象グループの人に、実際にインストールしたバージョンとビルドを確認してもらい、元の問題をもう一度試してもらいます。

アップロード履歴、グループの名簿、審査の承認はどれも重要です。ただし、最後には対象の人たちが、対象のビルドを確かにインストールしたことまで確認する必要があります。

内部テストのスクリーンショットを1枚送るだけでは、すべての外部ユーザーもインストールできるという証明にはなりません。シミュレータで動いても、デバイス上でのインストール結果の代わりにはなりません。

14. テストを終了する、または正式に公開するには?

まず、何を止めたいのかを確認しましょう。

  • 新しいユーザーの募集をやめる:外部グループの公開招待リンクを無効にします。
  • 誰にどのビルドを届けるかを変える:テスター、グループ、ビルドの割り当てを管理します。
  • 特定のビルドの新規インストールを止める:ビルドの詳細を開き、ビルドを期限切れにする(Expire Build)を選びます。すべてのスマートフォンから遠隔でアプリを削除したり、クラウド上のアカウントを消去したりする操作だと考えないでください。[6][13]
  • 正式にリリースする:App Storeの正式版に必要な情報を準備し、条件を満たすビルドを選んで、正式版の審査に別途提出します。[1][2]

通常のTestFlight用としてアップロード済みで、条件を満たすビルドは、正式版の審査に選択できます。公開するという理由だけで、必ずビルドを作り直す必要があるわけではありません。ただし、実際のコードが変わった場合は新しいビルドのアップロードが必要です。また、「内部テスト専用」でアップロードしたビルドは正式リリースに使えません。[2][5]

TestFlightの審査に通っても、App Storeに自動公開されることはありません。逆に、正式版を公開しても、まだ有効なベータ版が自動で終了するわけではありません。テストの終了とユーザーの移行は、それぞれ計画する必要があります。[1]

15. 最初のテスターへの案内は、この文面を使えます

[アプリ名]の初期バージョンを試してもらえませんか。

まずApp StoreからApple公式のTestFlightをインストールし、iPhoneで[実際の招待リンク]を開いて、招待を承諾してからインストールしてください。

今回は特に[具体的な作業を1~2つ]を試してほしいです。対応デバイスとOS:[実際の要件]。

これはベータ版なので、不具合があるかもしれません。大切なデータは先にバックアップしてください。問題が起きたら、TestFlightの「ベータ版フィードバックを送信」から、何をしたか、どうなるはずだったか、実際に何が起きたかを教えてください。できればスクリーンショットとバージョン番号も添えてもらえると助かります。

角括弧の部分は実際の情報に置き換えてください。対象の外部グループのビルドを本当にインストールできると確認してから送信しましょう。まだ審査待ちのリンクを先に一斉送信して、「もう使えます」と案内してはいけません。

配布前に、最後の10項目をチェック

  • アカウントの権限に合わせて内部テストか外部テストを選び、手間を省くために過剰な権限を与えていない。
  • 対象ビルドの処理が完了し、配布を妨げる未解決の問題がない。
  • 対象グループに、そのビルドが確実に含まれている。
  • 必要な外部審査に通過し、必要な通知も送信済みである。
  • 使用する招待方法を確認した。メール招待は正しい相手に送り、公開リンクを使う場合は有効で空き枠がある。対象のデバイスとOSが要件を満たしている。
  • テストの説明、フィードバック用メールアドレス、テスト内容が、実態に合っていて役に立つ。
  • テスターがベータ版であることと、正式版を置き換える可能性があることを理解している。
  • サンドボックスでの購入と、実際のサーバー、ウェブ決済、現実の操作を区別できている。
  • ビルドの有効期限を確認し、今後の更新を計画している。
  • 対象者の中に、招待ページを開いただけでなく、対象ビルドを実際にインストールしたと確認できた人がいる。

初めてアプリを配布するとき、本当のゴールは「アップロード完了」ではありません。適切な人が適切なバージョンをインストールし、何を試すかを理解し、問題をあなたに伝える方法もわかっていることです。

出典と参考資料

以下の資料は2026年9月17日に確認しました。歴史上の出来事には当時の報道やAppleの発表を使い、現行ルールは主にAppleの公式ヘルプに基づいています。操作画面は言語やバージョンによって変わる場合があります。

[1] Apple:TestFlightの概要。 https://developer.apple.com/help/app-store-connect/test-a-beta-version/testflight-overview/ ↑

[2] Apple:TestFlightの製品紹介。 https://developer.apple.com/testflight/ ↑

[3] Apple:TestFlightのテスター向けヘルプ。インストール、90日間の期限、サブスクリプション、プライバシー、テストの終了について。 https://testflight.apple.com/ ↑

[4] Apple:Developer Programへの登録と料金。 https://developer.apple.com/programs/enroll/ ↑

[5] Apple:内部テスターの追加。 https://developer.apple.com/help/app-store-connect/test-a-beta-version/add-internal-testers/ ↑

[6] Apple:外部テスターの招待。 https://developer.apple.com/help/app-store-connect/test-a-beta-version/invite-external-testers/ ↑

[7] Apple:ビルドのアップロード。 https://developer.apple.com/help/app-store-connect/manage-builds/upload-builds/ ↑

[8] Apple:テスト情報の提供。 https://developer.apple.com/help/app-store-connect/test-a-beta-version/provide-test-information/ ↑

[9] Apple:ユーザーの追加と編集。 https://developer.apple.com/help/app-store-connect/manage-your-team/add-and-edit-users/ ↑

[10] Apple:サンドボックスでのアプリ内課金のテスト。 https://developer.apple.com/documentation/storekit/testing-in-app-purchases-with-sandbox ↑

[11] Apple:アプリのビルドステータス。 https://developer.apple.com/help/app-store-connect/reference/app-uploads/app-build-statuses/ ↑

[12] Apple:テスターのフィードバックの確認。 https://developer.apple.com/help/app-store-connect/test-a-beta-version/view-tester-feedback/ ↑

[13] Apple:ビルドのテストの停止。 https://developer.apple.com/help/app-store-connect/test-a-beta-version/stop-testing-a-build/ ↑

[14] Apple:App Reviewガイドライン。特に2.2「ベータ版のテスト」。 https://developer.apple.com/app-store/review/guidelines/#beta-testing ↑

[15] Apple:新しいアプリの追加。 https://developer.apple.com/help/app-store-connect/create-an-app-record/add-a-new-app/ ↑

[16] Apple:ベータテストとリリースのためのアプリの配布。 https://developer.apple.com/documentation/xcode/distributing-your-app-for-beta-testing-and-releases ↑

[17] Apple:テスター情報の確認と管理。 https://developer.apple.com/help/app-store-connect/test-a-beta-version/view-and-manage-tester-information/ ↑

[18] Apple:今後の要件。現在のSDKとアップロードの要件。 https://developer.apple.com/news/upcoming-requirements/ ↑

歴史に関する資料:

[H1] Macworld、2011-01-21、TestFlightでiOSアプリのテストが大幅に簡単に。 https://www.macworld.com/article/210218/testflight.html ↑

[H2] MacStories、2012-03-05、BurstlyがTestFlightを買収。 https://www.macstories.net/news/testflight-acquired-by-burstly-launches-testflight-live/ ↑

[H3] The Verge、2014-02-21、AppleがiOSテストプラットフォームTestFlightの開発元を買収。 https://www.theverge.com/apps/2014/2/21/5434060/apple-buys-maker-of-the-ios-testing-platform-testflight ↑

[H4] Apple、2014-10-23、すべての人にTestFlightのベータテストを。 https://developer.apple.com/news/?id=10232014a ↑

[H5] Apple、2017-07-31、TestFlightのテスター数の上限を拡大。 https://developer.apple.com/news/?id=07312017a ↑

[H6] Apple、2018-09-26、公開リンクでテスターを招待。 https://developer.apple.com/news/?id=09262018a ↑