Xcode Cloudのビルド成果物はどう自動アーカイブする？2026年ガイド

結論：構築完了後に取得し、検証してから保管します

Appleの説明では、Xcode Cloudのビルド情報と成果物は最大30日間アクセスできます。この期限を越えても必要なログ、アーカイブ、テスト結果は、構築完了後にダウンロードして別の保存先へ移してください。手動保存でもAPIによる自動化でも、取得した一時ダウンロードURLを長期保管先として扱わないことが要点です。AppleのXcode Cloudに関する説明

過去の失敗を再現したいチーム、テストの証跡を残したい小規模チーム向けです。
保存対象の選定からAPI取得、ファイル検証、アクセス管理まで、運用に組み込める形で確認します。

最初に、後から必要になる成果物を選びます

「全部保存する」方針は、保存容量だけでなくアクセス管理や削除作業も増やします。リリースの追跡、クラッシュ調査、テストの再確認など、後日どの判断に使うのかを先に決めて対象を絞ります。

リリースの追跡には、配布したビルドのアーカイブやバイナリと、関連するビルド情報を残します。
クラッシュ調査には、対象アプリに対応するシンボル情報を保管対象として検討します。
テストの再確認には、テスト結果と失敗内容を調べるためのログを残します。
ビルド失敗の調査には、失敗したアクションのログと、再現に必要なビルド識別情報を関連づけます。

Xcode Cloudから取得できる成果物は、ビルドやワークフローの内容によって異なります。Appleの成果物とアーカイブの説明で対象を確認し、実際のビルドで必要なファイルが提供されるかを確かめます。成果物が存在しない場合に備え、代わりに保存するログやテスト記録も決めておきます。

Xcode Cloudのテスト結果とビルドログは、どう保存すればよいですか。

まず対象ビルドのレポートを開き、アクションとダウンロード可能な成果物を確認します。必要なテスト結果やログを保存先へコピーし、ビルド識別情報と結びつけます。画面からの手動保存は、低頻度の利用や人による内容確認に向いています。担当者、保存先、ファイル名の付け方を決めないままでは、後から検索できない記録が残りやすくなります。

手動保存とAPI自動化を、作業頻度で使い分けます

手動保存は構築レポートを見ながら要否を判断でき、導入作業も小さくできます。一方、担当者が操作を忘れたり、保存方法が人によって変わったりすると、必要なビルドだけ欠落するおそれがあります。

App Store Connect APIを使う方法は、既存の自動処理に取得、記録、検証を組み込めるのが利点です。ただし、認証情報の管理や失敗時の再処理が必要です。APIを利用できること自体は、ビルド完了時の自動実行が保証されることを意味しません。チーム側で検知方法と実行タイミングを設計します。

Xcode Cloudのビルド成果物は、いつまで残りますか。

Appleが案内するアクセス可能期間は最大30日です。公式の設定・アーカイブ手順で示される期間を、チーム独自の保存期間と混同しないでください。長期の監査や障害調査に必要な期間は、チームの運用要件に基づいて別途決めます。

APIで対象を特定し、認証情報を安全に扱います

App Store Connect APIでは、ワークフロー、ビルド、ビルドアクションなどのリソースをたどって対象を特定します。Xcode Cloudのワークフローとビルドに関するAPI資料を参照し、取得対象となるビルドとアクションを絞り込みます。

ビルドアクションに関連する成果物を列挙するには、アクションの成果物一覧を取得するAPIを確認します。成果物の個別情報を調べる場合は、成果物リソースの取得方法と、成果物属性の定義を参照してください。ファイル名、種類、ダウンロード先など、利用する属性やレスポンス形式は実装時に現行資料で照合します。

APIへのリクエストには、App Store Connect API用のキーと認証トークンが必要です。AppleのAPIキー作成手順に沿って権限を絞り、トークン生成の公式資料を基に認証処理を実装します。秘密鍵やJWTをソースコード、成果物、通常の実行ログに出さないようにします。

APIが返す成果物のダウンロードURLは、長期間使えますか。

長期間利用できるリンクとして扱ってはいけません。AppleのAPI資料にあるダウンロードURLは有効期間が限られるため、取得後すぐにファイルをダウンロードし、保存先の管理下に置きます。URL自体をアーカイブの代わりに記録しても、後日ファイルを取り出せる保証にはなりません。

構築後の取得から保管までをチェックします

以下のチェックリストを、手動運用または既存の自動処理へ当てはめます。APIのエンドポイント、属性、認証要件は変更される可能性があるため、実装時はAppleの現行資料を確認します。

[ ] 保存する成果物を決め、リリース追跡、障害調査、テスト確認のどれに使うか記録します。
[ ] 対象ビルドとアクションを特定できるよう、ワークフローやビルドの情報を取得する方法を決めます。
[ ] 手動保存かAPI取得かを選びます。自動化する場合は、構築完了を検知して処理を開始する仕組みをチーム側で用意します。
[ ] APIを使う場合は、必要な権限のAPIキーを準備し、秘密鍵とJWTを実行ログやリポジトリに含めない設定にします。
[ ] 成果物情報を取得したら、URLの有効期間内にファイルをダウンロードします。処理失敗時に再取得できる手順も用意します。
[ ] ダウンロードしたファイルを開けるか、期待した種類かを確認します。取得できなかった場合は、成功扱いにせず担当者へ知らせます。
[ ] ビルド識別情報、コミットやワークフローの情報と成果物を結びつけ、保存先のアクセス権を必要な範囲に限定します。
[ ] 保存期間と削除責任者を決め、実際のワークフローで取得、閲覧、復旧まで確認します。

保存先の階層や命名規則は、後から別の担当者が探せるかを基準に決めます。ビルド番号だけでなく、コミットやワークフローなどの情報も一緒に記録すれば、似た成果物の取り違えを防ぎやすくなります。社内情報やコードを含むファイルは、保管することだけでなく、誰が閲覧できるかも確認します。

長期運用では、保存期間と復旧手順を分けて決めます

Apple側でアクセスできる期間と、チームが保管する期間は別の管理事項です。リリース後の調査や社内の証跡要件に必要な期間を決め、その期間を過ぎた成果物を誰が削除するかまで定めます。すべてのログを恒久保存するのではなく、調査目的に照らして対象と削除条件を見直します。

実案件のワークフローで、ダウンロードしたファイルが開けること、記録したビルド情報から対象を追えること、権限のない利用者が保存先へアクセスできないことを確認します。Xcode Cloudだけで完結する構成と比べ、手動保存には担当者依存があり、API取得には認証情報の保護と失敗処理が必要です。さらにAPIのダウンロード先は長期保存向けではないため、別の保管先を運用する作業も発生します。

アーカイブ後の確認や追加処理にmacOSのツールチェーンが必要なら、手元のMacで実行する方法、継続利用するMacを用意する方法、必要な期間だけMac環境を使う方法を比べます。長期の安定稼働や物理接続が必要なら、レンタルより自前のMacが適する場合もあります。一方、短期の検証や追加処理用に実機が必要な場合は、metalvncのMac環境を候補として確認し、料金プランが利用期間と合うか見比べられます。接続や利用方法を先に確認したい場合は、ヘルプ情報も参照してください。