2026-04-28 App Store 段階公開、TestFlight の「ビルド列車」、レンタル Apple Silicon クラウド Mac（HK / JP / KR / SG / US）での出荷チェックリスト
レンタル Mac mini M4（シンガポールや東京）へ SSH して xcodebuild archive を回すモバイルリリース担当者は、すでに「遅い」系が二つを同時に抱えています：TestFlight（ベータ、テスター、ビルド処理）と、App Store の顧客更新パス（段階版／即時版）です。Apple のApp Store 更新の段階配信—自動更新ユーザーへの割合を約7 日で上げると語られることも多い—は TestFlight 機能ではありませんが、同一のオンコール手順書、Slack ステータス、Git タグは揃える必要があります。本 2026-04-28 手順書は、(1) TestFlight 内／外リングと App Store 製品版の責務を分ける、(2) ビルド列車アーティファクト（同一コミット → 同一 CFBundleVersion / ビルド番号群）を誤って分岐させない、(3) 既存の IPA エクスポート + App Store Connect API自動化の横に CI が記録できる数値チェックリストを置く、の三つです。ヘッドレス Archive + 署名や xcodebuild カバレッジゲートと併せ、段階配信したバイナリがテストしたバイナリである証拠に使えます。
TestFlight と App Store：二種の観客、ひとつのツールチェーン
TestFlight はプロダクトと QA が（まず内測、次に外測で）人間に挙動を証明する場であり、Apple の処理キュー、権利、輸出コンプライアンスも物語に含まれます。App Store の顧客更新—一括配信でも段階ロールアウトでも—はベータではなく、ストアから取得できるバージョンレコードに適用されます。古典的運用ミス：段階 App Storeをオンにしているのに、別チームがマーケをその列車では店頭に並ばない TestFlight ビルド番号へ向けること。是正は語彙：チケットで常に「TF ビルド」対「ストア版 3.2.1 (8)」と明示します。
- TestFlight — 代表的な規模では100〜10,000名の外テスター：クラッシュ／フィードバックで素早く回し、勝ったビルドをリリースへ。
- App Store — App Store Connect の製品バージョン + ビルドの組が顧客更新になる；段階配信は、その更新が自動更新ユーザーにどう拡がるかを一週間で変える。
7 日間の App Store 段階モデル（数字の要点）
Apple が示す段階スケジュールは自動更新ユーザーの割合を日々増やします。手動更新者・新規インストールはしばしば即最新のため、サポートマクロは両者を扱う必要があります。現場で多いパターン：0 日目に段階を有効化しクラッシュフリーセッションを監視；1〜2 日目は大きなコホートから最速の反応；3〜4 日目にはサポートが古い iOS層に支配されていないか、権利の回帰ではないかを見る。一時停止は第一級の状態—正式なインシデントとして扱い、承認者、長さ、App Store Connect UI／API の証跡を残します。
リースのビルドホストでまだ必須のこと
App Store の段階状態機は、信頼できるホストで IPA をアーカイブ・エクスポート・署名する責任を置き換えません。レンタル Mac mini M4（HK / JP / KR / SG / US）は依然コンパイルの真実です：ジョブ単位の Xcode 固定で検証した同一 codesign主体と、エクスポート手順書の ExportOptions.plist 選択が、段階トグルより前に App Store Connect に取り込まれている必要があります。
現場の「ビルド列車」：車掌は一人
ビルド列車とは、製品ライン向けリリース候補の一直線の列で、同時に App Store に「乗る」候補は多くて一つ、というイメージです。分散チームの失敗：リリース／ホットフィックスが別ポッドで緑 CI のため、同一日に別々の IPA を二人のマネージャが上げる。2026年、混雑した SSH で効く最小の規律：release/x.y へ Archive を引き起こすマージは CFBundleVersion を CI がゲートする単一コミットでも上げる—既にある セルフホステッド Runner衛生と同じ精神です。
git tag v3.2.1-build-4821
# ASC ビルド記録と CI ログ成果物パスにも同じタグを結ぶ
マトリクス：CI が緑から「顧客が更新できる」まで
| チャネル | 証明すること | 典型的ゲート |
|---|---|---|
| PR CI（シミュレータ + 単体） | 固定 SDK 上のコンパイルとテスト | 赤ならマージ不可；ヘッドレステスト と カバレッジゲート |
| TestFlight 内測 | スモーク、権利の健全性、人手フロー | 外に出す前に同一ビルドで二晩成功 |
| TestFlight 外測 | より広い端末行列 + App Review メタデータ | 段階的テスター；第一指標はクラッシュフリー > 99.0% |
| App Store（段階／全量） | ストア掲載 + 法務 + 地域価格 | オンコール + PM のロールバック／一時停止手順承認 |
9 ステップ手順：火曜アーカイブ → 金曜安定
- ブランチ凍結 — カット後に CocoaPods／SwiftPM を即席でいじらない；キャッシュ規律を再読。
- リリースラベルで Archive — レンタル Mac で
xcodebuild -versionを記録し、署名プレフライト。 - IPA エクスポート — レビュー済み
ExportOptions.plistで、エクスポートガイド通り API アップロード—CI で Ad hoc Transporter は避ける。 - 処理を追跡 — App Store Connect；
buildProcessingState等を Slack のログブリッジへ；ITMS-系は生 JSON で即失敗。 - TestFlightは先に内測；2営業日クラッシュログで sev-2 スパイクなし。
- 外測はテスター向け文書（特に14 日初回インストール人口）。
- App Store 版：リリースノート、必要ならスクショ差分、リスク許容で段階か即時。
- 段階オン：一時停止権限（別チームの二鍵）、許容する最長ウォール時計停止（Apple の30日上限を文脈として）、「全ユーザーへ公開」のタイミングを明文化。
- 公開後：2 日目のクラッシュフリーが基準から0.3% を超えて乖離したらretro—権利の差であり「SG の不運」ではないことが多い。
App Store Connect API・運用ダッシュボード・証跡
2026年、自動化に優しいチームは同じ UI を三度見ない；CI 文書済みの JWT でバージョンリソースを取得し、phased release stateをダッシュボードへマップします。長く効く作法は：API キーのロールを許容できる限り狭く、CI 署名証明書と同じ周期でローテし、共有 SSH ユーザの shell 履歴に鍵を残さない—ヘッドレス署名とアクセスパターンと同型です。API 読取がまだなら、少なくとも ASC UI を毎晩成果物バケットへスナップし、監査にタイムスタンプ付き PNG を；地味が英雄より勝る。
FAQ：五人に聞かず「段階中か」を知る
| 質問 | 2026-04-28 実務回答 |
|---|---|
| 段階配信中にホットフィックスを流したら？ | いったん停止し、Apple現在のガイダンスを読む（スレが政策変更前かも）；実際には新しい app バージョンと、進行中の列車を先に止めるかの判断が要る—判断を書き残し、二つ目のビルド番号を撫で回さない。 |
| 小さい地域では段階の届きが違う？ | ユーザー数はアプリ次第；ローカライズが重いなら地域別クラッシュ／ANR も。HK / JP / KR / SG / USは MacXCode でよく揃える拠点で、テスターと審査期待に合わせやすい。 |
この話に Apple Silicon Mac mini M4 が出続ける理由
リリース速度は最後の緑パイプラインをどれだけ信頼できるか：リージョン内のベアメタルMac mini M4は予測可能なxcodebuild時間、大型.xcarchive への実ディスク IO、署名前の安定したクロックを与えます—App Store Connect がバイトを見る前に。3:00 UTCの段階波とソウルでのクラッシュ監視が重なる金曜でも、コンパイルホストの可動部が少ないほど、慌てたVNCは減ります。MacXCode は香港・東京・ソウル・シンガポール・米国で1〜2 TBを用意し、リリースブランチと段階の顧客ストーリーが同一金曜夜にNVMeで争わないサイズです。
