TestFlightへ頻繁に開発ビルドを送る独立開発者、内部確認と正式リリースを同じCIで処理する小規模チームが対象です。遠隔Macや自前Runnerを使っている場合は、アップロード方式だけでなく、署名鍵とApp Store Connect権限も分ける必要があります。

初めて外部テスターを招待する場合も注意が必要です。チームメンバー、外部テスター、最終ユーザーは同じ配布対象ではありません。

最終更新：2026年9月11日。Xcode 27 RCの対応状況、Internal Onlyの制限、テスター資格をAppleの公式資料で確認しています。Xcode 27正式版の公開時期や、ビルド処理・アップロード待ち時間は本稿の判断材料にしていません。

配布資格で先に決める

判断は次の順番で十分です。

• App Store Connectのチームメンバーだけが使う。
• 外部テストグループへ追加しない。
• App Store提出の候補にしない。
• 実験機能、デバッグ用スイッチ、開発中の確認に限定する。

すべて当てはまるなら、TestFlight Internal Onlyを選びます。AppleのXcodeアプリ配布ドキュメントでも、配布目的に応じてアップロード方法を選ぶ考え方が示されています。

次のどれかに当てはまるなら、通常のTestFlightおよびApp Store配布を選びます。

• チーム外のテスターへ招待する。
• 外部テストグループや公開リンクを使う。
• 外部テスト審査を経て評価してもらう。
• 同じArchiveを正式候補として管理する可能性がある。
• 将来、App Store提出へ進める予定がある。

AppleのTestFlight概要では、内部テストと外部テストが別の配布経路として整理されています。便利そうだからInternal Onlyにするのではなく、ビルドの最終的な資格で選ぶのが安全です。

テスト対象ごとの境界

App Store Connectのチームメンバーは、必要なアカウントと役割を持つ内部テスターです。内部テストでは、チーム内での動作確認、開発中の機能確認、CIからの短いフィードバック取得に向いています。内部テスターの条件は、Appleの内部テスター追加ガイドで確認できます。

一方、チーム外の顧客、協力者、公開ベータ参加者は外部テスターです。メール招待や公開リンクを使う場合は、外部テストグループと、そのビルドを関連付ける必要があります。外部テスターの招待条件は公式の外部テスター案内に従ってください。

つまり、同じ「TestFlightで試す」という目的でも、対象者が違えば選ぶ配布方式も変わります。内部メンバーだけならInternal Only、外部の意見を集めるなら通常のTestFlightです。

Internal Onlyの利点と限界

Internal Onlyの主な利点は、開発用Archiveを正式配布の候補から意図的に切り離せる点です。実験機能や未完成の画面を含むビルドを、誤って外部テスターや顧客へ渡すリスクを抑えられます。

ただし、次の制約があります。

• 外部テストグループに追加できない。
• 外部テスト向けの配布経路に使えない。
• App Store提出用の候補として扱えない。
• 後から分類だけを変更して再利用する前提にできない。

Appleのテスト担当者とビルドの関連付けに関する説明でも、テスターの種類と利用できるビルドの関係が区別されています。App Store Connectで外部グループが表示されないときは、最初にビルド分類を確認してください。

通常配布を選ぶ場合のコスト

通常のTestFlightおよびApp Store配布を選べば、外部テストと正式候補の両方へ進める余地を残せます。しかし、開発中の全ビルドを通常配布にすると、未完成のArchiveが候補版一覧に混ざり、運用上の判断を誤りやすくなります。

Internal Onlyを選んだ後に「やはり外部テストへ回したい」となった場合、単純な設定変更で済むとは限りません。用途に合わせた再Archive、署名、バージョン管理、アップロード確認が必要になるため、リリース直前の変更は遅延要因になります。Appleのビルドアップロード手順を確認し、Archive、アップロード方式、App Store Connect上のビルド状態を別々に確認してください。

注意：Internal Onlyは「安全な一時置き場」ではありません。正式候補になる可能性が少しでもあるなら、最初から通常配布用のJobとして扱い、内部確認と候補管理を分けてください。

Xcode 27で確認すべき事実

Appleは2026年9月9日の発表で、Xcode 27 RCで作成したアプリをApp Store Connectへアップロードできることを案内しています。詳細はXcode 27 RCの公式発表で確認できます。

したがって、Xcode 27を使う場合も「新しいバージョンだからInternal Only」という選び方はできません。重要なのは、誰に配布するか、外部テストへ進むか、App Store提出候補として残すかです。

AppleのXcode 27リリースノートとApp Store Connectのビルド状態一覧を、CIの更新時に確認してください。正式版の公開時期や処理時間を推測して、Job設計を決める必要はありません。

遠隔MacをiOS打ち上げ用の環境として使う場合、内部検証と候補リリースを同じJobに詰め込まない構成が適しています。特に、どのArchiveも同じAPIキーで提出できる状態は避けてください。

内部検証Job

内部検証用のJobには、次の要素を固定します。

1. 開発ブランチまたは内部検証専用ブランチだけを対象にする。
2. 内部確認用のSchemeを指定する。
3. 実験機能を含む設定でArchiveを作成する。
4. アップロード時にTestFlight Internal Onlyを選ぶ。
5. 内部テストグループへの追加後、ビルド分類を確認する。
6. 外部テストやApp Store提出の資格情報をJobから参照できないようにする。

候補リリースJob

候補リリース用Jobでは、次の条件を別に設けます。

1. リリースブランチまたは承認済みタグだけを対象にする。
2. リリース用Schemeと署名設定を明示する。
3. Archive生成後に人手の承認を要求する。
4. 通常のTestFlightおよびApp Store配布としてアップロードする。
5. 外部テストグループへ関連付ける前に、バージョンとビルド番号を確認する。
6. App Store提出権限を持つ資格情報は、このJobだけに限定する。

GitHub Actionsなどの自前Runnerを使う場合も、Runnerのラベルだけで安全性を判断しないでください。署名用秘密鍵、App Store ConnectのAPIキー、証明書、ログ出力のマスキング、管理者権限を別々に確認します。実際のTeam ID、Bundle ID、ホスト名、鍵、トークンを設定ファイルやログへ出力してはいけません。

現在のMacが常時稼働に向かない場合は、遠隔Macの利用環境を、常駐CIの候補として比較できます。長期運用では、Macの購入費だけでなく、電源、保守、空き容量、OS更新時の停止も判断に含めてください。

設定を終えたら、実際のテストアカウントで分類を確認します。ここでは、実在のリポジトリ情報、Team ID、Bundle ID、APIキー、ホストアドレスを記載しません。

• [ ] 脱敏した内部確認用Archiveを作成する。
• [ ] App Store Connect上でInternal Onlyの表示を確認する。
• [ ] 内部テストグループに追加できることを確認する。
• [ ] 外部テストグループへ追加できないことを確認する。
• [ ] 候補リリース用Archiveを別のJobから作成する。
• [ ] 通常のTestFlightおよびApp Store配布として処理されることを確認する。
• [ ] 候補ビルドが外部テストの対象として選択できることを確認する。
• [ ] 候補リリースJobだけが提出用資格情報を参照できることを確認する。
• [ ] 失敗時に署名のリセット、証明書の取り消し、Archiveの削除を自動実行しないことを確認する。

外部グループに追加できない場合は、まずアップロード方式、ビルド分類、App Store Connect上の処理状態を調べます。いきなり証明書を撤回すると、原因を増やしてしまいます。

個人開発で内部確認だけの場合

チームメンバーだけが確認し、公開ベータやApp Store提出の予定がないなら、Internal Onlyが適しています。開発用と候補用のArchiveを混同しないため、Scheme名にも用途を明記してください。

公開ベータを予定している場合

外部テスター、顧客、協力者から評価を集めるなら、通常のTestFlightおよびApp Store配布を選びます。外部テストグループ、招待方法、審査の有無を確認し、内部用ビルドをそのまま流用しない運用にします。

継続的にリリースする場合

内部検証Jobと候補リリースJobを分けてください。前者はInternal Only、後者は通常配布です。短期的なアップロードの手軽さより、誤提出の防止、候補版の再利用、資格情報の分離、復旧手順の明確さを優先します。

Internal Onlyのビルドを外部テストへ変更できますか？

できません。Internal Onlyとしてアップロードされたビルドは内部用として扱われ、外部テストグループへ追加できません。外部配布の可能性がある場合は、最初から通常のTestFlightおよびApp Store配布用にArchiveを作成してください。

内部テスト用ビルドをApp Storeへ提出できますか？

Internal Onlyのビルドを、そのままApp Store提出候補にはできません。正式版へ進む可能性があるなら、候補リリース用のJobを使い、通常配布として別のArchiveを管理します。

Xcode 27では何を選びますか？

内部メンバーだけの検証ならInternal Onlyです。外部テスターを招待する、またはApp Store提出候補として扱うなら、通常のTestFlightおよびApp Store配布を選びます。Xcode 27 RCのApp Store Connect対応は、Appleの公式発表とリリースノートで確認してください。

遠隔Macの自動アップロードを分ける方法は？

ブランチ、Scheme、エクスポート方式、承認条件、署名資格情報を分けます。内部検証Jobには提出権限を与えず、候補リリースJobだけに必要なApp Store Connect権限を付与してください。

外部テストグループへ追加できない原因は？

Internal Onlyとして分類されている可能性があります。App Store Connectのビルド状態と分類を確認し、証明書の取り消しや署名の初期化を先に実行しないでください。

内部確認と正式候補を一つのアップロード経路で扱うと、外部テストへ進めない、提出候補を作り直す、資格情報を広く配布してしまう、といった問題が起こります。特に、手元のMacが常時オンラインでなく、CIを止めたくない場合は、KVMNODEのMac環境を遠隔の打ち上げ基盤として検討できます。

ただし、物理デバイスを直接接続する作業や、長期間にわたり自分で管理する安定した高負荷環境が必要なら、Macの購入や自前設備のほうが適する場合もあります。短期の開発、継続的な内部検証、候補版の自動アップロードを分けたいなら、遠隔Macをレンタルして、二つのJobを常時動かせる状態にするほうが運用上の選択肢を増やせます。