Mac CIサービスのSLAはどう検収する？2026年企業調達チェックリスト
Runnerはオンラインなのに、ビルドが開始されずリリース判定が止まっている。
Mac CIサービスのSLA検収では、ホストの可用率だけで選ばず、合意したCIタスクの開始・完了、故障の計時、対応と復旧の責任、確認可能な証拠まで契約に記載してください。目標値は汎用の数字を流用せず、業務要件と契約条件から決めます。
企業IT・調達担当者：Mac CIの約束を比較できる検収条件に落とし込みたい方向けです。
プラットフォームエンジニア：サービス状態と実際のビルド成功を区別したい方向けです。
技術責任者：障害時の復旧責任とリリースへの影響を判断したい方向けです。
ホスト稼働率とCIタスクの成功率、どちらを検収するか
SSHやコンソールへ接続できても、Runnerがジョブを受け付けるとは限りません。さらに、Xcodeのビルドが完了し、成果物を取得できることまで保証されるわけではありません。したがって、可用性の基準は「Macがオンラインか」だけでなく、チームの実際の利用を代表するタスクで定めます。
GoogleのSRE資料では、利用者が経験するサービスの状態を測る指標（SLI）、目標（SLO）、契約上の取り決め（SLA）を区別しています。契約では、SLI・SLO・SLAの役割と関係を混同せず、測定対象と未達時の扱いを分けて確認してください。
タスクの検収条件には、次の要素を含めます。
- 起動：ジョブがRunnerに受け付けられ、実行が始まること。
- 実行：指定したビルドやテストが、合意した環境で完了すること。
- 受け渡し：成果物が保存され、利用側が確認できること。
- 失敗の帰属：サービス側の障害と、ソースコード・依存関係・利用者設定などによる失敗を区別すること。
Xcodeのビルド手順を検収対象に含める場合は、AppleのXcodeコマンドラインツール資料を参照し、実際のスキームや出力物に即した成功条件を定めます。製品名だけを記載して、どの処理を成功とするかを曖昧にしないことが重要です。
停止時間の定義と証拠を、同じ条項で確認する
「稼働率」の数字だけでは、何を分母にし、どの時間帯を集計し、いつからいつまでを停止と数えるのか判断できません。対象サービス、集計窓、障害の開始・終了判定、計画保守の扱いを一組の条件として契約に記載します。具体的な目標値は、リリース頻度や許容できる停止の影響に応じて決めます。
実行記録は、サービス側の状態記録だけに依存しないようにします。CI側のジョブログ、サービス状態、双方が合意した時刻の記録を照合できる形にしてください。ワークフローの記録に関しては、実行ログの確認方法や、セルフホストRunnerの監視・トラブルシューティング資料が、確認対象を整理する参考になります。これらは記録の考え方を示す資料であり、個別サービスのSLAを保証するものではありません。
契約前に実際のパイプラインで記録形式を確認します。以下は記録項目の形式例であり、実サービスの稼働実績ではありません。
set -o pipefail
xcodebuild -scheme "$SCHEME" -destination "$DESTINATION" test 2>&1 | tee build.log
記録形式例：
job_state=completed
runner_state=online
artifact_state=available
failure_owner=unassigned
event_timestamp=agreed_source
failure_ownerのように帰属が未確定のまま残る場合、ログを集めても責任の判断ができません。異常時に誰が判定を行うかも、検収前に決めておきます。
応答の開始と業務復旧は、別の責任として定める
受付通知が届いた時点で、ビルドが再開できるとは限りません。イベントの確認、調査着手、遠隔アクセスの復旧、CIタスクの再実行、成果物の検証は別々の状態です。対応責任をそれぞれ分ければ、「問い合わせを受け付けた」ことだけで復旧済みと扱う誤解を避けられます。
契約や運用手順には、障害区分、通知先、担当の引き継ぎ、エスカレーション経路、復旧確認の担当を記載します。インシデント対応では役割と引き継ぎが重要になるため、Googleのインシデント管理資料と対応準備・協働のワークブックを、責任分担の確認材料として利用できます。
成果物を公開・保管する運用なら、ビルド成功だけで検収を終えず、利用側が取得できるかも確認します。ワークフロー成果物の保存と共有に関する資料も、タスク完了条件を整理する際の参考になります。
よくある疑問：計時・保守・調達時の証拠
ホストがオンラインなら、CIサービスも利用可能と判定できますか？
できません。ホストの接続状態と、Runnerがタスクを受け付けて完了する状態は異なります。対象とするCIタスクを決め、起動・ビルド・成果物の受け渡しまでのどこを可用性として測るかを明記してください。失敗原因の切り分け方法も条件に含めます。
障害の計時は、検知と連絡のどちらから始めますか？
契約で起点を指定します。利用者の検知、通知、サービス側の確認のいずれを採用するかを決め、根拠に使う時刻記録も合わせます。終了側も、接続復旧だけで閉じず、必要ならビルドの再実行と成果物確認までを別の状態として残します。
保守やmacOS更新は、常に停止時間から外せますか？
常に除外できるわけではありません。対象作業、事前通知、記録、除外の適用範囲が契約に書かれているかを確認します。Xcodeや設定の変更後にビルド結果が変わった際の検収と切り戻しも、保守条項と一緒に確認してください。
調達時に求める障害・復旧の資料は何ですか？
SLA条項だけでなく、状態記録の見本、通知と引き継ぎの流れ、計画保守の規則、実際のCIタスクで確認したログをそろえます。未達の申告に必要な記録や、成果物を確認できる証拠も対象です。資料を契約条件と突き合わせ、測定不能な項目を残さないでください。
計画保守と環境変更は、除外条件とセットで検収する
計画保守や再起動、macOSの更新、Xcode環境の変更を停止時間に含めるかは、契約ごとに確認が必要です。「保守は対象外」とだけ書かれていると、対象範囲や通知、保守後のビルド不具合を誰が扱うかが不明です。除外条件には、適用対象、通知・記録の方法、変更後の検収、設定を戻す責任をひも付けます。
保守後は、ジョブが起動することだけではなく、基準として合意したビルドと成果物の受け渡しまで確認します。失敗時に環境変更の影響を調査する担当と、切り戻しの判断者も決めてください。
補償条項と、チーム側の復旧策は分けて考える
サービス未達時の控除などを定める場合は、発動条件、申請手順、期限や必要証拠が条文上明確かを確認します。補償の有無だけでサービスを比較すると、リリース遅延への備えが抜け落ちます。金銭的な補完は、代替のビルド経路や公開予定の保護、チーム自身の復旧演習の代わりにはなりません。
条件分岐で、署名・保留・追加確認を判断する
- [ ] CIタスクの成功条件を測定でき、失敗原因を区別できる場合は、実パイプラインで検収します。いずれかができない場合は、記録方法と失敗の帰属条件が契約に追記されるまで保留します。
- [ ] 停止の起点・終点、計画保守の扱い、復旧段階ごとの担当が明記されている場合は、運用責任者と内容を照合します。不明な項目がある場合は、可用性を比較する前に補足条件を求めます。
- [ ] ログ、状態記録、成果物を相互に照合できる場合は、署名前の証拠一式として保存します。確認可能な証拠がなく、未達時の扱いも曖昧な場合は、追加資料がそろうまで調達判断を保留します。
この確認で使う資料は、SLA本文、状態記録の見本、障害通知・引き継ぎの手順、保守条件、CIタスクの検収記録です。指標が測れない、例外範囲が広すぎる、復旧責任者が決まっていない場合は、署名前に解消すべき条件として記録します。
現状の構成とMacレンタルを、運用責任まで含めて比べる
既存の開発用Macを共有する方式は、専用容量の確保や担当者不在時の復旧が課題になり得ます。購入は初期調達や保守の責任が残り、一般的なクラウド実行環境はMac固有のCIタスクにそのまま置き換えられるとは限りません。どの方式でも、タスクの成功条件、故障計時、復旧責任を契約と運用の両方で確認する必要があります。
負荷が変動し、専用ハードウェアを自社で調達・保守する負担を避けたいチームには、リモートMacのレンタルも比較対象になります。条件や費用は契約内容で確認し、Mac miniレンタルの価格案内を調達案の比較材料にしてください。企業向けのMac mini調達案内も参照し、署名前には本記事の指標に沿ってサービス条件と実タスクの検収記録を照合します。安定した高負荷を長期運用する場合や、物理ポートへの接続が必須の場合は、自社保有を含めて比較するのが適切です。