判定：ソースコードが永続保存されないという説明だけで、企業要件への適合を承認しないでください。権限、ログと成果物、スクリプトの外部通信、地域・保管・監査要件を証拠ごとに確認し、不明な統制が残れば対象のビルドを自管またはリモートのMac CIへ分けます。
対象：クラウド上のビルドで扱う情報を社内規程と照合するセキュリティ・コンプライアンス担当者。
CI基盤担当者：リポジトリ認可、スクリプト、ログや成果物の扱いを点検する方。
企業IT・技術責任者：Xcode Cloudの採用範囲と、Mac CIを残す条件を決める方。

セキュリティ担当：公開説明と社内要件を切り分ける

Xcode Cloudの企業データ安全性は、「暗号化されるか」だけでは判定できません。Appleの公開説明では、ビルドは一時的な隔離環境で実行され、ソースコードは永続保存されず、ビルド出力は転送時と保存時に暗号化されます。ただし、この説明だけで処理地域、具体的な保管・削除期限、監査能力まで確認できるわけではありません。AppleのXcode Cloudセキュリティ説明と、自社のデータ分類・契約・審査基準を別々に照合してください。

対象 公開資料で確認できること 社内で別途確認すること
ソースコード 一時的な隔離環境でビルドし、永続保存しないという説明 ビルド中のアクセスを許容するデータ分類か
ビルド出力 転送時と保存時の暗号化に関する説明 ログ、テスト結果、成果物ごとの閲覧・保管・削除要件
データの所在地 上記の説明だけでは所在地を立証できない 地域制限と、それを裏付ける現行資料
スクリプトの通信 実装により別のデータ経路が生じ得る 外部送信先、認証情報、承認者、通信制限

審査記録では「確認済み」と「資料では確認できない」を分けます。暗号化、一時的な隔離、データ所在地、保存期間、監査証跡は、互いの代わりになりません。

ソースコード管理担当：接続範囲と認可を棚卸しする

まず、どのリポジトリを接続するか、どの利用者やアカウントが接続を承認しているかを台帳にします。Appleのコード管理サービス接続設定とGitHub接続の説明を参照し、実際の組織設定と照らし合わせてください。

確認対象 受け入れ時の確認
接続対象 ビルドに必要なリポジトリだけが対象か
認可主体 接続を承認したアカウントと責任者を追跡できるか
人員変更 異動・退職時に不要な認可を失効できるか
自社管理のリポジトリ 接続経路とアクセス主体が社内承認の範囲内か

ケース： 共有アカウントで接続を承認し、担当者の交代後もその認可が残る運用では、コードの読取権限を誰が管理しているか曖昧になります。申請者、承認者、失効担当を決められない場合、その接続を本番ビルドに使う判断は保留します。App Store Connectのアカウントと役割の説明も参照し、役割とアクセス管理を混同しないようにします。

CI基盤担当：一時環境とスクリプトの送信先を調べる

「ソースコードを永続保存しない」は、ビルド中にコードが一時環境から利用されないという意味ではありません。また、カスタムスクリプトが外部サービスへ送る情報は、ビルド出力の保護説明とは別のデータ経路として扱います。

Appleのカスタムビルドスクリプトの説明と環境変数のリファレンスを使い、スクリプト、参照する環境変数、通信先、アップロード内容を確認します。認証情報をログへ出力しない設計か、外部送信が必要な理由と承認者を記録しているかも審査項目です。

実作業では、ワークフローごとにスクリプトの送信先を洗い出し、許可リストと照合します。送信内容や認証情報の扱いを説明できない処理は無効化するか、データを持たない検証用ワークフローに分けてから受け入れてください。基盤検証の目的は通常の製品ビルドと異なる場合があるため、インフラストラクチャ検証ビルドの説明も確認し、検証結果を本番運用の証拠として流用しないようにします。

アプリ担当：ログ、テスト結果、成果物を別々に分類する

ソースコードと、ビルドで生じる情報は一括管理しないでください。ログにはコマンド出力や環境情報、テスト結果には不具合の詳細、成果物には署名済みのアーカイブやアプリの情報が含まれる可能性があります。何が実際に出力されるかをワークフロー単位で調べ、データ分類に登録します。

Appleのセキュリティ説明は、ビルド出力の暗号化について示す根拠です。一方、社内の保管期間、閲覧者、削除手続きが自動的に満たされることの証明ではありません。各出力について、必要なアクセス権と保管・削除方針を社内規程に照らしてください。

  • [ ] ログに秘密情報や個人情報が出力されないことを確認する
  • [ ] テスト結果に含まれる情報と閲覧対象を定義する
  • [ ] アーカイブなど成果物の利用者と保管先を特定する
  • [ ] Appleの公開説明で確認できる保護と、社内規程で決める項目を分けて記録する
  • [ ] 要件を立証できない出力を含むワークフローは、承認まで公開・配布しない

購買・法務担当：証拠が示す範囲を記録する

Appleのセキュリティページ、サービスに関する契約資料、社内の審査記録は、別種類の証拠として保管します。文書ごとに確認日、支持する結論、対象外の論点、社内の確認者を残してください。

特に、暗号化や一時環境の説明から、データの所在地、特定の法域での処理、具体的な削除期限、監査機能を推定しないでください。それらが調達条件なら、適用される最新の公式資料や契約上の根拠で個別に確認します。裏付けを得られない項目は「適合」とせず、未確認のリスクとして責任者と対応期限を記録します。

FAQ：採用判断で残りやすい確認事項

ビルドが終わればソースコードは残りませんか？

Appleの説明ではソースコードは永続保存されませんが、ビルド中は一時的な隔離環境で利用されます。さらに、スクリプトやログに別の情報が含まれる可能性があります。ソースコードの扱いだけで全データ経路の審査を完了させず、ワークフロー単位で確認します。

ログと成果物も暗号化されますか？

Appleはビルド出力について、転送時と保存時の暗号化を説明しています。ただし、社内で必要な閲覧制御や保管・削除方針まで満たすかは別途確認が必要です。ログ、テスト結果、成果物を分類し、各担当者と利用目的を記録してください。

Xcode Cloudでデータ所在地の要件を満たせますか？

公開されている暗号化と一時環境の説明だけでは、データ所在地は判断できません。社内が許容する地域を定め、現行の公式資料や契約資料から根拠を確認します。必要な証拠がない場合は、該当ワークフローを保留して代替案を審査します。

リポジトリ権限とスクリプトは何から点検すべきですか？

接続対象、承認したアカウント、権限の失効手順を確認し、接続が必要な範囲に限られているかを調べます。次にスクリプトの外部サービス、送信データ、認証情報の参照先を一覧化します。人員変更時の失効担当と、外部通信の承認者も記録してください。

アーキテクチャ責任者：採用・制限・Mac CIへの切り替えを決める

審査の結論は「採用」だけにまとめず、ワークフローごとに分けます。コードの種類、出力、外部通信、地域・保管・監査要件のうち、未確認の項目があれば、対象作業を制限するか代替環境へ移す判断が必要です。

判断 適用する条件
採用 必要なデータ保護と社内要件を、確認可能な資料と設定で説明できる
制限付きで採用 対象リポジトリや出力を限定し、未確認の要件に触れる処理を分離できる
Mac CIを評価 地域、ネットワーク、保管、監査の必須条件を既存資料で確認できない

採用前に、責任者、確認した証拠、残るギャップ、リリースを許可する条件を記した責任マトリクスを完成させます。チーム内で管理するMac CIは、アクセス経路や運用責任を設計しやすい一方、パッチ適用、容量管理、障害対応などを自分たちで担います。どちらを選ぶ場合も、未確認の統制を「対応済み」と扱わないことが条件です。

もし地域、ネットワーク、保管、監査の条件が公開資料だけでは確認できないなら、クラウドCIへ一括投入せず、対象タスクを分離したMac CIも比較してください。自社でMacを調達する案は管理方法を決めやすい反面、機器の調達と維持を自社で担います。短期の評価や一時的なビルド環境が必要なら、Macレンタルも選択肢になります。MACCOMEのサービス概要を確認する場合も、データアクセス、分離方法、提供条件を個別に照合し、要件を満たす根拠が取れた範囲だけで採用を判断してください。購入案との比較には、Mac miniの案内も参照できます。