Xcode Cloudのビルド成果物バックアップは、ビルド完了日に手動保存を始め、継続的にリリースするアプリではApp Store Connect APIへ移行してください。Appleの公式案内では、2026年8月30日時点でXcode Cloudのビルド情報と成果物にアクセスできる期間は最長30日です。 AppleのXcode Cloud設定資料
この手順は、Xcode Cloudで公開やテストを行っているものの、成果物を別途保存していない独立開発者向けです。過去のクラッシュを調べる保守担当者や、xcarchiveとxcresultを集中管理したい小規模チームにも適しています。
今週やることを決める：30日以内の時間線
今日：保存対象を公開価値で分類する
30日というアクセス期限は、すべてのファイルを永久保存すべきという意味ではありません。公開版のApp Archiveは再調査や再署名の基準になり、符号情報はクラッシュレポートのシンボル化に使います。一方、通常ブランチの成果物は、同じ価値で残す必要がない場合があります。
Appleの資料では、Xcode Cloudの成果物はビルドの種類や処理結果に応じて扱われます。管理対象を推測で増やさず、実際に対象ビルドから取得できるファイルを確認してください。クラッシュレポートとデバイスログの調査方法は、Appleのクラッシュレポート解説も参照できます。
| 成果物 | 主な用途 | 保存判断 |
|---|---|---|
| xcarchive | 公開版の構成確認、再調査 | App Store公開版は優先 |
| 符号情報 | クラッシュのシンボル化 | 対応するビルドと一緒に保存 |
| ビルドログ | 失敗原因や環境の確認 | 公開版と失敗ビルドを優先 |
| xcresult | テスト結果や診断情報の確認 | 不具合調査が必要な版を保存 |
| 通常ブランチの成果物 | 開発中の確認 | 保持条件をチームで決定 |
構築完了日：追跡できるフォルダーを作る
圧縮ファイルをダウンロードして終わりにすると、数か月後にどのアプリの成果物か分からなくなります。App名、マーケティングバージョン、Build Number、ワークフロー名、ビルドID、作成日を、フォルダー名または付属のメタデータへ記録してください。
例えば、AppName/version-build/workflow-build-id/ のように、検索条件を先に固定します。アカウント識別子、App ID、Build ID、APIキー、ログ内の個人情報は、共有用の記録では必ず伏せ字にします。
ビルド完了後に行う：手動保存から自動化へ
その日の基準ファイルを作る
XcodeまたはApp Store Connectで対象のビルドを開き、成功したArchive、テスト結果、符号情報など、画面上で取得できる公式成果物を確認します。Xcode Cloudのビルド実行と成果物の関係は、App Store Connect APIのビルド実行資料で照合できます。
最初の1回は、次の情報を同じ記録に残してください。
- ビルド番号とバージョン
- 対象ワークフローとビルドID
- ダウンロードしたファイル名
- 圧縮ファイルのハッシュ値
- 解凍後に確認できたフォルダー
- 保存処理の開始時刻と終了状態
この基準があると、後で自動処理が「ファイルを取得した」だけなのか、「必要な成果物をすべて取得した」のかを比較できます。
1週目：App Store Connect APIで繰り返し処理を置き換える
App Store Connect APIで自動化する場合、いきなり全ビルドを取得するのではなく、成功したArchiveまたは公開ワークフローに対象を絞ります。まずビルド実行を検索し、関連するビルドアクションからArtifactsの情報を取得し、ダウンロード先と実行状態を記録する流れです。
Artifactsの取得方法は、ビルドアクションに紐づくArtifactsのAPI資料と、Artifactsリソースの仕様を突き合わせて実装してください。API仕様の変更を前提に、レスポンス全体を固定的に決め打ちしないことが重要です。
認証情報は役割を分離します。App Store Connect APIのアクセスキー、コード署名用の証明書・秘密鍵、SSHなどによる遠隔Macログイン権限は別物です。
APPSTORE_ISSUER_ID=<your-issuer-id>
APPSTORE_KEY_ID=<your-key-id>
APPSTORE_PRIVATE_KEY_PATH=<path-to-private-key>
ARCHIVE_ROOT=<external-storage-path>
秘密鍵を成果物フォルダーへコピーしたり、APIキーをビルドログへ出力したりしないでください。AppleのAPI全体の認証とリソース構成は、App Store Connect API公式リファレンスを基準にします。
| 自動化方式 | 向いている状況 | 欠点と補完策 |
|---|---|---|
| 定時ポーリング | 発版頻度が低く、処理を単純にしたい場合 | 取得まで遅れやすい。補完スキャンを残す |
| webhook起点 | 頻繁に発版し、完了直後に保存したい場合 | 通知は保管機能ではない。再試行が必要 |
| 手動ダウンロード | たまに公開する個人開発 | 作業忘れが起きる。完了チェックを必須化 |
発版時：webhookと補完スキャンを組み合わせる
Xcode Cloudのwebhookは、構築完了などのイベントを外部処理へ知らせる仕組みです。ファイルそのものを保管する場所ではないため、通知を受けた処理がAPIで成果物を取得し、外部ストレージへ保存する必要があります。Xcode Cloud webhookの公式資料で対象イベントと設定を確認してください。
低頻度の発版なら定時処理で十分ですが、頻繁に公開するならwebhook起点が適しています。ただし、通知失敗や一時的なAPIエラーに備えて、後から未処理のビルドを探す補完スキャンを残します。
重複保存を防ぐキーは、ビルドIDだけに限定しない方が安全です。ビルドID、ワークフロー、成果物種別、処理状態を組み合わせ、同じ通知を受けても二重処理しない設計にします。失敗状態も記録し、成功扱いにして静かに取りこぼさないでください。
注意：webhookの受信記録だけ残っていても、xcarchiveの保存完了は証明できません。通知、API取得、解凍、内容確認を別々の状態として記録してください。
公開後に確かめる：ダウンロード成功と復元成功を分ける
公開版はファイル単体ではなく対応関係を検証する
圧縮ファイルを保存できても、復元できるとは限りません。解凍できるか、ArchiveのバージョンとBuild NumberがApp Store Connect上の対象ビルドと一致するか、符号情報を読み取れるかを確認します。
テスト結果を保存した場合は、xcresultを開いて試験結果や診断情報が読めるかも確認してください。テスト結果の読み方は、Appleのテスト結果解釈ガイドに沿って確認できます。
公開版の保存記録には、少なくとも次を含めます。
- 成果物のファイル一覧
- ハッシュ値または同等の改変確認情報
- App、バージョン、Build Numberとの対応
- ダウンロードと解凍の実行結果
- 符号情報とテスト結果の読み取り結果
- 復元確認を行った日付と担当者
証明書の秘密鍵やAPIキーは、通常の成果物ディレクトリへ入れないでください。復元に必要な署名環境は別の安全な管理手順で扱い、アーカイブと同じ場所に集約しない方が事故の範囲を限定できます。
復元演習で確認する
月単位の保管ルールを決める前に、保存先から別の作業環境へコピーし、圧縮ファイルを解凍して、xcarchiveとxcresultを読み取ります。公開版に対応するクラッシュ情報を用意できる場合は、符号化された情報が正しくシンボル化できるかまで確認してください。
復元時にBuild Numberが一致しない、xcresultが壊れている、符号情報だけ別ビルドのものだった場合、保管は成功していません。遠隔Macを使う場合も、接続できることではなく、Xcodeで対象成果物を開けることを合格条件にします。
長期運用：保存期間より復元条件を管理する
内部テスト、候補版、正式公開版を同じルールで保存すると、容量と検索性の両方が悪化します。社内の障害対応期間、公開後の監査要件、クラッシュ調査の必要性を基準に、種類ごとの保管条件を決めてください。根拠のない一律の保存年数を先に設定する必要はありません。
保存先の役割も分けます。ローカルディスクは一時作業、汎用オブジェクトストレージは長期保管、常駐の遠隔MacはXcodeで過去成果物を開く作業、シンボル化、復元スクリプトの実行に向いています。定期的にXcodeを使うなら、VMSPINの日本語サービス案内で利用形態を確認し、短期利用と常駐利用を分けて検討してください。
復元確認のチェックリスト
- [ ] 公開版のApp、バージョン、Build Numberを台帳へ記録した
- [ ] Xcode CloudのビルドIDとワークフロー名を保存した
- [ ] xcarchiveと対応する符号情報を同じ追跡単位で管理した
- [ ] 必要なxcresultとビルドログを選別して保存した
- [ ] APIキー、秘密鍵、ログ内の個人情報を成果物から除外した
- [ ] 圧縮ファイルを解凍し、内容を読み取れることを確認した
- [ ] 保存先から別環境へ戻す復元演習を実施した
- [ ] webhook通知だけでなく、補完スキャンの結果も確認した
- [ ] 発版後に対象成果物の保存状態を確認した
Xcode Cloudの成果物を失わないためのFAQ
Xcode Cloudの記録は30日を超えて残りますか？
Appleが確認しているアクセス可能期間は最長30日です。内部的に別の保持処理があるという未確認情報を前提にせず、必要なファイルは期限内にダウンロードしてください。長期保管の責任は、Xcode Cloudではなく外部の保存と復元手順に置きます。
APIは自動バックアップの代わりになりますか？
APIは取得処理を自動化できますが、保存先、再試行、重複排除、監視までは自動的に完成しません。Artifactsの取得後にハッシュ値や対応するビルドIDを記録し、失敗した実行を検知する仕組みまで用意して、初めてバックアップ運用になります。
削除後の成果物をAppleへ戻してもらえますか？
削除後の成果物を確実に戻せる運用として扱うべきではありません。Xcode Cloud上で確認できる期間に外部へ保存し、復元テストを行ってください。保存済みのArchiveやテスト結果がなければ、後日のクラッシュ調査に必要な材料を失う可能性があります。
現在の運用からMac環境へ移す判断
Xcode Cloudだけに依存する運用は、30日のアクセス期限、保存処理を自分で検証しにくいこと、過去の成果物をXcodeで調べる作業を毎回組み直すことが弱点です。ローカルMacだけで管理する方法もありますが、電源管理、空き容量、外部アクセス、故障時の復旧を自分で担う必要があります。
そのため、定期的に歴史的なArchiveをXcodeで開き、符号化や復元スクリプトを実行するなら、常時稼働するMac環境を保管作業の実行先に加える方が扱いやすい場合があります。VMSPINの日本語料金案内を確認し、短期の発版作業だけで足りるのか、継続的な制品管理用の環境が必要なのかを、復元頻度と保管責任で判断してください。