Xcode Cloudのビルド成果物を長期保存するには？2026年アーカイブガイド

📋 目次

AppleのXcode Cloudでは、ビルド成果物を完了後の限られた期間だけ利用でき、案内されている最長期間は30日です。AppleのXcode Cloudワークフロー文書を踏まえ、Xcode Cloudを永久保管庫として扱わず、必要なファイルを期間内に取得して、ビルドとソースの情報を添えて保存し、実際に開けるか確かめてください。

対象となるのは、次のような開発者やチームです。
正式版のArchiveやシンボル情報、リリース時のログを後から調べたい個人開発者。
過去のテスト結果やスクリーンショットを見直したい開発者、リリース資料を引き継ぎたい小規模チーム。

リリース調査では、ビルド記録とArchiveを分けて残す

正式リリース後にクラッシュや署名の問題を調べるなら、ビルド記録だけでなく、原因調査に使う実ファイルを特定します。ビルド記録は、どのワークフロー・ソース変更から作られたかを探す手掛かりであり、Archiveやシンボル情報の代わりにはなりません。AppleのBuild Runsリソースを参照し、対象のビルドを特定してから取得する成果物を選びます。

Xcode Cloudのビルド成果物は、どのくらい利用できますか？
Appleの案内では、ビルド成果物の利用期間は有限で、最長30日です。期間内にプラットフォーム上でアクセスできることと、チームが自分たちの保管先へダウンロードして復元可能な状態にしたことは別です。保存が必要なリリースは、期限を待たずに取得してください。Xcode Cloudの利用期限とワークフロー

Archive、dSYMなどのシンボル情報、ビルドログは用途が異なります。Archiveは配布や後日の検証に使うビルド成果物、シンボル情報はクラッシュのスタック情報を読み解くための材料、ログはビルド時の処理やエラーを追う材料です。Appleのデバッグ情報に関する説明を確認し、対象リリースのArchiveと対応するシンボル情報をセットで管理してください。Archiveだけを残してシンボル情報を取りこぼすと、後からクラッシュを調べる際に必要な情報が不足することがあります。

どの情報を組にして保存しますか？
アプリ、ワークフロー、ビルド識別情報、ソースのコミットを記録し、ファイル名だけでリリースを推測しないようにします。対象のビルド記録と成果物を照合し、保管後も対応関係をたどれるか確認してください。

テストの再現では、結果ファイルと取得元を一緒に保管する

テスト結果を後日見返す場合は、結果パッケージだけでなく、自動テストのスクリーンショットやビルドログのうち、再現や原因調査に必要なものを選びます。すべての実行ファイルを一律に永久保存するのではなく、テストの目的とチームの保管ルールに照らして対象を決めてください。

テスト結果が復元できるか、どう確認しますか？
ダウンロードした結果ファイルを保管先から開き、対象のワークフローとビルド記録に結び付くことを確認します。スクリーンショットがある場合は内容を表示できるか、ログがある場合は該当するテスト実行を特定できるかも見ます。AppleのXcode Cloud結果パッケージに関する説明は、結果パッケージを扱う際の確認先になります。

ファイル単体で保存すると、どの実行から取得したか分からなくなることがあります。フォルダー名や付随する記録に、アプリ名、ワークフロー、ビルド識別情報、コミットを残し、スクリーンショットやログにも同じ記録を対応させてください。

引き継ぎでは、見つけやすさと復元の検収を優先する

チームで過去のリリースを引き継ぐ場合は、担当者の記憶や個人のダウンロードフォルダーに頼らず、アプリとワークフローを起点に資料を整理します。ビルド記録からソースのコミット、Archive、シンボル情報、関連ログへ進める構成にすると、調査する人が変わっても出所を追いやすくなります。

引き継ぎ前に、何を復元すべきですか？
重要なArchiveを開き、必要なシンボル情報とログが揃っているかを確認します。テスト結果やスクリーンショットを保存対象に含めた場合は、それらも開いて内容を検査します。見つからないファイルは「保存済み」と扱わず、欠落した対象と確認担当を記録してください。

社内の保管ルールは、リリース診断、テスト再現、日常のビルド調査に分けて定めると整理しやすくなります。各ファイルの種類、実際の用途、サイズを確認して選定し、すべてのビルドを同じ範囲で永久保存する前提にはしないでください。プロジェクトの実データを確認せずに必要容量や費用を決めるのは避けます。

APIでの取得は、一覧確認とダウンロードを別工程にする

App Store Connect APIを使う場合は、ビルド実行を特定し、その実行に関連する成果物を調べてから、対象ファイルをダウンロードする流れにします。AppleのXcode Cloud API概要と成果物のAPI資料で、現在のリソース構成と利用可能な成果物を確認してください。

成果物の属性には、ファイル名、ファイルサイズ、ダウンロードURLなど、取得対象を確認するための情報があります。実際の属性名や値の扱いは、成果物属性の公式定義を基準に実装します。単一の成果物を読む場合は個別成果物のAPI仕様も参照し、取得したURLを恒久保管先として扱わず、必要なファイルをダウンロードした後に検証してください。

App Store Connect APIから取得するとき、どこで失敗しやすいですか？
一覧取得、対象の選択、ダウンロード、ファイル検証、状態記録を別々に扱います。認証情報は必要な範囲に絞って管理し、失敗時は再試行の対象と回数を運用ルールで決め、取得済みかどうかを記録してください。トークンの発行手順はAppleのAPIトークン文書で確認し、APIのフィールドや認証要件は実装時点の公式仕様に合わせます。

ダウンロードURLを取得できたことは、アーカイブ完了の証明ではありません。ファイルが保管先に存在すること、開けること、元のビルド記録へ戻れることを別々に確かめてください。

取得後の運用は、手作業の保管と継続環境を比べて選ぶ

保存方法は、担当者が必要時に手動で取得する方法、APIで取得処理を自動化する方法、取得後の整理・検証を継続的なMac環境で行う方法に分けて考えます。手動運用は対象を選びやすい一方、期限の見落としや担当者不在に弱くなります。API運用は記録を揃えやすい一方、認証管理、ダウンロード失敗時の処理、ファイル検証を設計する必要があります。Mac環境を追加しても、保存先やバックアップの設計が自動で解決するわけではありません。

環境選びでは、物理機と仮想化環境の違いを整理したMac環境の比較ガイドも参考になります。購入とレンタルの費用条件を比べたい場合は、Mac miniの料金と選び方を確認し、利用期間や既存の保管先に合わせて判断してください。

運用に入れる前の確認項目

[ ] 保存対象を、リリース診断・テスト再現・日常調査の用途別に選びました。
[ ] ビルド記録からアプリ、ワークフロー、ビルド識別情報、コミットを確認しました。
[ ] Archiveと対応するシンボル情報を区別し、必要なログやテスト結果も選びました。
[ ] APIを使う場合、認証情報の管理とダウンロード失敗時の再試行方法を決めました。
[ ] ダウンロードしたファイルを開き、記録との対応関係を確認しました。
[ ] 欠落したファイルと確認担当を記録し、別の担当者でも同じ資料を探せる状態にしました。

手元のXcode Cloudだけに頼る運用は、利用期間の見落とし、資料の出所が分からなくなること、復元確認が後回しになることが弱点です。継続してアクセスできるMac環境を使えば、ダウンロードした成果物の整理や確認場所をまとめる選択肢になりますが、保管・バックアップ手順は別途必要です。専用のMacを購入するほどではないものの、こうした作業場所を一時的または一定期間確保したい場合は、MacDateのMacレンタルも比較対象にできます。まず必要な保管方法と復元手順を決め、その運用に合う環境かを確認してください。