企業 Mac CI ビルド成果物の保存期間は？2026年戦略ガイド

公開後のクラッシュを調べようとしたら、対応するarchiveやdSYMがCIノードに見つからない。
今週は、公開済みビルドのarchiveと対応するdSYMを保管対象として特定し、ログ、テストレポート、キャッシュ、作業領域には別々の期限と復元条件を設定してください。

このガイドは、iOSの公開とクラッシュ診断を担うエンジニア責任者、Mac Runnerの保存領域を管理するプラットフォームエンジニア、監査やデータライフサイクルを担当するIT・セキュリティ部門向けです。
保管期限に一律の正解はありません。診断、監査、契約、社内のデータ管理要件をもとに決め、長期保管する資料を再作成可能なCI作業領域から分離するのが基本です。

企業 Mac CI ビルド成果物の保存期間は、種類ごとに設計します

「CIビルド成果物」をひとまとめにして同じ期限で消すと、再作成できるキャッシュと、公開済みアプリの調査に必要な資料を同じ扱いにしてしまいます。まず、それぞれが何のために必要か、削除後に再取得または再生成できるかを確認してください。

Appleは、配布したアプリに関連するXcode archiveを保持し、デバッグ情報を含めることの重要性を説明しています。公開後の診断にarchiveが必要になる可能性があるため、ソースコードが同じという理由だけで、別のビルドのarchiveを代用品とみなさないでください。配布用アプリのarchive作成に関するAppleの説明とデバッグ情報を含むビルドおよびarchive保持の案内を確認できます。

公開済みiOSアプリのarchiveとdSYMは、どのように残せばよいですか。
社内の診断・監査要件に基づいて保管期限を定め、少なくとも対象の公開版、ビルド識別子、archive、対応するdSYMをひとまとまりとして追跡できるようにします。全企業に共通する日数を設けるのではなく、調査可能性や契約上の要件を基準にしてください。

注意：dSYMが手元にあっても、対象アプリのビルドと対応していると確認できなければ、必要なクラッシュ情報を正しくシンボル化できるとは限りません。ファイル名だけで判断せず、ビルドの識別情報と対応関係を記録してください。

archiveとdSYMの対応が切れると、公開後の調査が止まります

archiveとdSYMは、どちらか一方があれば同じ目的を果たせるファイルではありません。Appleは、対応するデバッグシンボルを使ってクラッシュレポートの情報を読み解く方法を案内しています。クラッシュレポートに識別可能なシンボル名を追加する手順を踏まえ、対象バージョンやビルド識別子とシンボルファイルを照合できる形で管理します。

実務では、公開時に参照する記録へ、リリース版、ビルド識別子、archiveの保管先、dSYMの保管先、配布ファイル、公開または承認の記録を関連付けます。保管先が単独のMac上の一時ディレクトリや、定期清掃の対象となる作業領域だけでは、ホスト障害や誤削除により追跡が途切れるおそれがあります。

archiveを削除した後でも、dSYMだけでクラッシュをシンボル化できますか。
dSYMは対応するビルドのシンボル化に使われますが、それだけでarchiveと同じ役割を担うわけではありません。後日の再確認や配布物の追跡に必要なarchiveも含め、公開済みビルドに紐付けて保管してください。

ログ、レポート、キャッシュは期限の根拠が異なります

ビルドログやテストレポートを早く消しすぎると、失敗の再現や公開判断の確認に必要な手掛かりまで失われることがあります。一方、依存関係キャッシュは通常、再構築の可否や復旧コストを確認してから整理する対象です。用途の異なるファイルを一括清掃しないためにも、「何を調べるために残すのか」「誰が読むのか」「消えた場合に何を再実行するのか」を先に定義してください。

CIサービスの設定も共通仕様ではありません。公式資料には、組織単位のログ・成果物保持設定や、個別成果物に対する保持設定が示されています。組織レベルの保持設定に関する公式資料とワークフロー単位の成果物保持設定を確認し、実際に使うプラットフォームで設定の適用範囲を照合してください。ある環境の初期設定を、すべてのCI基盤に共通する企業標準として扱うのは避けます。

キャッシュは、公開証拠とは異なり、再取得・再生成できる場合があります。ただし、再構築に必要な依存関係やアクセス権が失われていないかを確かめずに削除すると、復旧手順が想定どおり動かないことがあります。キャッシュと成果物の用途の違いを説明する公式資料やキャッシュの制限と整理に関する説明を参照し、キャッシュ専用のルールを設けてください。

補足：保持期限を設定できるか、またどの単位で適用されるかは、利用するCIサービスや設定階層で異なります。別の基盤へ移行するときは、ログ、成果物、テスト情報の期限が引き継がれると決めつけず、公式の保持仕様を再確認してください。

保管場所と責任者を決め、誤削除に備えます

長期保管するファイルは、CIワークスペースの定期清掃と同じルールに含めず、保存場所、アクセス権、削除権限、担当者、復元方法を記録します。使用中のCIサービスに成果物の期限や最新実行分の扱いがある場合も、対象条件を把握したうえで、社内の保存要件と合うか確認してください。成果物の期限や最新実行分の保持条件を扱う公式資料やパイプライン実行およびテストデータの保持に関する資料は、サービスごとの設定範囲を確認する際の参考になります。

Mac CIのログ、テストレポート、キャッシュに、同じ保持期限を適用すべきですか。
それぞれの用途と消失時の影響が異なるため、共通期限をそのまま当てはめるのではなく、個別に決めます。ログとレポートは調査や監査の必要性、キャッシュは再構築の可否と復旧手順を根拠にし、作業領域は成果物を退避した後に清掃する設計にします。

清掃時に公開記録や診断用ファイルを巻き込まないために、何を分離しますか。
公開済みビルドの記録とarchive、dSYM、配布ファイルの保存先を、再生成可能なキャッシュや一時領域から分けます。削除担当者だけに依存せず、保存場所と削除権限を別々に記録し、定期清掃の対象に含まれないことを確認してください。

受入チェックで保持ルールを検証します

方針書を作るだけでは、誤削除後に実際に復元できるかは分かりません。次の項目を運用の受入条件にして、担当者と証拠の保管先を記録してください。

• [ ] 公開済みバージョンを選び、記録から対応するarchiveとdSYMを特定できる。
• [ ] ビルド識別情報を照合し、archiveとdSYMの対応関係を確認できる。
• [ ] 配布ファイルと公開・承認記録が、対象バージョンから追跡できる。
• [ ] ログとテストレポートの期限、閲覧対象者、削除責任者が定義されている。
• [ ] キャッシュを再生成する手順と、削除後に復旧できることの確認方法がある。
• [ ] 保管先、閲覧・削除権限、保存責任者が記録されている。
• [ ] CIノードの外部に保管した必要ファイルを実際に取り出し、復元を確認している。
• [ ] 定期清掃の対象から、公開証拠と長期保管資料が除外されている。

評価は、archiveとdSYMの対応確認、保存場所と権限の記録、ログ・レポートの期限設定、独立した保管先からの復元確認の各項目で判定できます。どれか一つでも確認できない場合は、保存期限だけを短縮せず、責任者や復元手順を補ってから運用を変更してください。

CIノードの見直しとMac環境の選択

単一のMacの作業領域だけに成果物を置く運用は、ホスト故障、不要ファイルの一括削除、担当者不在による引き継ぎ漏れに弱くなります。レンタルMacをCIノードとして追加しても、それだけで長期保管や監査証跡が保証されるわけではありません。公開済みのarchiveやdSYMは別途保管場所と復元手順を定め、CIノードの交換・停止時にも追跡できる設計が必要です。

まず、現在のノードで「誰が保存先を管理するか」「公開物をどこから復元するか」「清掃対象をどう区別するか」を確認してください。構築リソースの増減に合わせてMac環境を検討する場合は、VPSMACのMac環境で利用形態を確認し、Macノードの構成情報とチームの運用条件を照らし合わせられます。ローカル機を長期利用するほうが適するケースもありますが、増減のあるCI環境を補う目的なら、VPSMACのMacレンタルを候補にしつつ、成果物の保管・交接・復元を別の運用要件として設計してください。