CircleCI Machine Runner 3移行：2026年macOS受入チェックリスト

先に作る移行台帳

全量置換を避けるには、最初に「何を移すか」ではなく「何が止まると困るか」を記録します。対象ノード、利用するリポジトリ、リソースクラス、署名の有無、私設ネットワークへの接続、保守時間帯、切り戻し担当者を一つの台帳にまとめます。

本番唯一のビルド機を試験機に兼用すると、失敗時に調査と復旧が同じホストで競合します。既存ノードを止める前に、隔離Macまたは別の待機ノードで同じ基準ジョブを通せる状態を作ることが重要です。

旧サービスの残留

旧launch agentのplist、インストール先、実行プロセスが残ると、新旧サービスが異なる設定を読み込んだり、同じノードで接続状態を争ったりする可能性があります。公式のmacOS移行手順に沿って停止と削除を行い、手作業で別方式の起動設定を追加しないでください。

確認には、対象ユーザーのサービス一覧とプロセス一覧を使います。

launchctl list | grep -i circleci
ps aux | grep -i '[c]ircleci'

出力が空であることだけを合格条件にせず、旧plistの保存場所、削除日時、停止ログを証跡として残します。新Runnerの導入は、macOSインストールガイドに掲載された現在の方法と配布物を使い、バイナリの入手元、署名、notarizationの状態、インストールログを記録します。

互換性ではなく実行意味を確認する

既存のconfig.yamlが読み込めることは、移行完了の証拠ではありません。working_directory、cleanup_working_directory、runner mode、command_prefix、タスクの最長実行時間、task-agentのキャッシュ動作を、Machine Runner 3設定リファレンスと照合します。

特に確認すべきなのは、パスの置換、環境変数の継承、実行ユーザー、ディレクトリ所有者です。旧環境で暗黙に成立していた相対パスやログインシェルの設定が、新サービスの起動コンテキストでは成立しないことがあります。

既存のconfig.yamlはそのまま使えますか。
構文や一部設定が互換でも、パス、権限、環境変数、キャッシュの扱いまで同一とは限りません。コピーして本番投入するのではなく、認証情報を含まない基準タスクでcheckout、ビルド、ログ出力、終了コード、成果物回収を個別に確認します。

タスクのルーティング

Runnerがオンラインでも、意図しないプロジェクトがMacへタスクを送れるなら受入失敗です。namespace、resource class、認証トークン、プロジェクト設定を照合し、試験プロジェクトからは試験ノードへ、許可されていないプロジェクトからは拒否されることを確認します。

組織の設定ポリシーは、自前Runner向けの公式設定ポリシーを基準に設計します。信頼できるリリース用パイプラインと、一般的なテストや外部コントリビューションを同じmacOSリソースクラスへ流さないことが基本です。

トークンはリポジトリ、共有スクリプト、ビルドログに現れてはいけません。許可プロジェクト、拒否プロジェクト、リソースクラスの対応表、トークンの保管者とローテーション担当者を受入証跡に含めます。

残留物の検査

cleanup_working_directoryが設定されていても、作業ディレクトリだけを見て完了とはしません。キャッシュ、checkout用SSHキー、一時Keychain、Provisioning Profile、署名証明書、ビルド成果物、環境変数に展開された秘密情報を、企業の保持方針に沿って確認します。

自前Mac Runnerにコードや署名認証情報を残さない方法はありますか。
分離した試験プロジェクトを用意し、プロジェクトAのジョブ終了後にプロジェクトBを実行します。BからAのソース、環境変数、Keychain、Provisioning Profile、キャッシュが読めないことを確認し、失敗した場合は共有Runnerへの署名ジョブ投入を止めます。

署名を扱うノードでは、専用実行アカウントと専用resource classを優先します。一般テストを同じ信頼境界へ混在させると、清掃処理の一時的な失敗やログの誤出力が、横方向のアクセス経路になり得ます。

再起動と異常終了

macOS再起動後にMachine Runner 3が自動でタスクを受けない場合、何を確認しますか。
サービスの登録先、起動ユーザー、設定ファイルの所有権、ネットワーク到達性、認証情報の読み込み、旧launch agentの残留を順に確認します。再起動後に画面へログインしないと起動しない構成なら、無人のCIノードとしては不合格です。

以下の試験を、公開や本番署名を伴わない基準ジョブで実施します。

1. 試験ノードを遠隔から再起動し、ログイン操作なしでRunnerが接続するか確認します。
2. Runnerプロセスを停止し、再起動またはサービス復旧後に再び接続するか確認します。
3. 短時間のネットワーク中断を発生させ、同一タスクが重複実行されないか記録します。
4. タスクを意図的にタイムアウトさせ、後続タスクへ壊れた作業領域が渡らないか確認します。
5. 接続不能、署名失敗、成果物未回収の各ケースで、担当者が定めた切り戻しを実行します。

注意: 再接続できたことと、重複公開が起きないことは別の確認項目です。リリース処理には冪等性、公開前の承認、成果物識別子の照合を組み込み、Runnerの復旧だけを安全性の根拠にしないでください。

証跡カード

各試験は「実施した」ではなく、入力、期待結果、実際の結果、ログの保存先、担当者、判定を一行で記録します。性能値や処理時間を推測で埋めず、実際の基準パイプラインから取得できた値だけを採用します。

容量については、固定ノードの台数を先に決めるのではなく、実際のキュー、同時実行、リリース締切、復旧時間を継続的に記録します。Apple Siliconを使うiOS CI/CDでは、署名やXcodeの実行環境だけでなく、同時実行時のメモリ、ディスク、キャッシュ競合も基準ジョブで確認します。

条件分岐による決定

• 旧サービスが停止し、新Runnerが無人再起動後に接続し、許可外プロジェクトを拒否できる場合は、試験ノードで署名なしの段階的なジョブを開始します。
• 設定は読み込めるが、実行ユーザー、パス、キャッシュの挙動が説明できない場合は、config.yamlを修正し、基準タスクを再実行します。
• コード、Keychain、Provisioning Profileの清掃を証明できない場合は、共有ノードへの署名ジョブ投入を止め、専用アカウントと専用resource classへ戻します。
• 再起動後の自動復旧または重複実行の抑止を確認できない場合は、固定本番ノードの切替を延期し、予備ノードへルーティングします。
• キューが継続的に長く、公開締切に対する余裕を説明できない場合は、固定Macの増設、隔離ノード、弾力的なリモートMac容量を比較します。
• 失敗時に旧launch agentを安全に復元できない場合は、旧サービスを本番ホスト上で即興復元せず、事前検証済みの待機ノードへ切り替えます。

遠隔Macを試験ノードにする判断

既存のMacを試験に回すと、本番ジョブの停止、物理機の占有、社内ネットワーク変更、返却時のデータ消去が同時に発生します。短期間だけ隔離した実機を用意し、同じ基準パイプラインで移行証跡を作る方法なら、唯一の本番ビルド機を変更せずに検証できます。

企業のMac基盤をレンタルで試す価値はどこにありますか。
移行前の試験では、固定資産として購入する前に、実際のジョブ、再起動、清掃、署名隔離を確認できる点にあります。NUKCLOUDでは、Macのリモート利用方法を確認したうえで、試験ノードを本番と分離し、必要な期間だけ運用する構成を検討できます。長期の高負荷運用や物理USB機器が必須の場合は、購入した専用Macのほうが適しています。

受入後の運用

判定は「合格」「制限付きで放量」「差し戻し」の三つに分けます。制限付きの場合は、許可プロジェクト、実行種別、署名利用の可否、監視担当者、再評価条件を明記し、オンライン表示だけで本番利用へ広げないことが必要です。

本番容量を追加する場合は、日本向けMacレンタルの案内を比較対象に含め、固定ノードの増設費だけでなく、故障時の代替、保守担当者の工数、移行試験期間、キュー滞留によるリリース遅延もTCOに入れます。価格や性能を一般論で埋めず、実際の契約条件と基準パイプラインの記録で判断してください。

旧launch agentからMachine Runner 3への移行は、設定ファイルを置き換えてRunnerがオンラインになれば終わる作業ではありません。サービス残留、実行意味の差、誤ったタスク経路、署名資産の残留、再起動後の復旧失敗を別々に検査し、すべての証跡と切り戻し手順が揃って初めて本番切替を承認できます。

唯一の本番Macを直接改造する方法は、停止リスク、復旧時の設定混在、物理機の調達待ちという弱点を抱えます。まずNUKCLOUDの隔離したリモートMacを試験環境として使い、実際のiOS CI/CDで経路、清掃、再起動、署名保護を検証し、合格後にキューとSLAを根拠として長期ノード数を決める流れが、企業の移行リスクを抑えやすい選択です。