プラットフォームチームは、GitHub Actions 型の CI 用に帳簿上「専用」の Mac mini M4 を 1 台確保しつつ、夜間は同じマシンを OpenClaw やスクリプト自動化にも回したい、という要望をよく抱えます。ラベルと時間帯を契約として明文化しなければ、Simulator のポート枯渇、ビルドキューの飢餓状態、そして Slack での非難合戦に陥りがちです。本稿の 2026 年版プレイブックでは、Go／No-Go マトリクス、3 つのスケジュール型、7 ステップのラベル切り替え、そして数値で定義したロールバックの引き金をまとめます。形の異なる表を 2 つ置いたので、社内ランブックにそのまま貼り付けやすい構成にしています。
Mac をまだ「家畜」として捉え直していない場合は、まず ディスパッチャブルな Mac mini M4 ノード から読むとよいでしょう。キャパシティの貸し出しは ランナーのドレインとメンテナンス引き継ぎ と頻繁に交差するため、オンコール手順書の双方から相互リンクを張ってください。本番プールを共有せずにバースト用のベアメタルが欲しい場合は、NodeMac の料金とリージョン を参照してください。
なぜ「専用」ハードウェアでも衝突するのか
- オーナーシップが曖昧： 同じホスト名が CI ダッシュボードと自動化の台帳の両方に載っているのに、変更に責任を持つ人が一人もいない。貸し出しウィンドウが開くと、双方が「相手が譲るべき」と思い込みます。
- 単一ホストの飽和を「Mac が足りない」と誤読： エージェントとランナーが CPU とユニファイドメモリを奪い合うとキュー深度が跳ね上がります。負荷を落とさずラベルだけ足すと、ジョボリュームが横ばいでも p95 待ち時間が 12 分から 35 分を超えることがあります。
- 環境とクレデンシャルの汚染： 貸し出し中に macOS ユーザーやデフォルトのキーチェーンを共有すると、署名アイデンティティの衝突や、CI に「返却したあと」に謎の失敗を招くローテーション済み API キーが発生しやすくなります。
Go／No-Go の貸し出しマトリクス
変更レビューの場でこの表を使います。「貸してよい」列に該当する行が多いほど、一時的にデフォルトの CI ラベルを絞り込んでも安全です。大半がストップ側なら、唯一の本番プールを多重化するのではなく、別途バースト用ホストを借りるべきです。
| シグナル | 貸し出し可 | 一時停止／ブロック |
|---|---|---|
| スタンバイランナーのアイドル | 同一リージョン・同一イメージ世代にスタンバイが 1 台以上 | すぐにトラフィックを受けられるホストがゼロ |
| キュー深度と過去 7 日中央値 | 現在の深度 ≤ 中央値 × 1.2 | すでに ×1.5 を超えている |
| エージェント専有の時間予算 | チェックポイント可能なチャンクに分割し 90 分以内 | 終わりの見えない長時間処理や、数日単位の GPU／NPU 占有 |
| シークレットの分離 | ログイン項目の分割／キーチェーンのパーティション分離 | 開発者用証明書バンドルと API キーファイルを 1 つで共有している |
タイムウィンドウの型とラベル命名
| テンプレート | 典型ウィンドウ（UTC+8） | ラベルの動き | 連絡のリードタイム |
|---|---|---|---|
| 平日ピークのシールド | 10:00–19:00 は貸し出しなし | macos-ci をフル装着、agent-borrow は空 |
24 時間前通知 |
| 夜間バッチのスライス | 23:30–06:00 | macos-ci を外し、agent-borrow を付与 |
48 時間 |
| リリースフリーズ週 | RFC のフリーズカレンダーに従う | 読み取り専用エージェントのみ（リポジトリ書き込み・署名なし） | リリースマネージャーとの二重承認 |
数値ベースライン： 貸し出し前に、キュー深度・実行中ジョブ数・ホストの直近 24 時間平均 CPU をスナップショット化してください。ロールバックの議論では、この 3 指標だけを比較し、「なんとなく遅い」という逸話は持ち込まないこと。
7 ステップの貸し出し実行チェックリスト
- 変更チケットを起票： ホスト名、ウィンドウ、CI オーナー、自動化オーナーを列挙する。
- スタンバイ容量を検証： スタンバイランナーでスモークワークフローが 120 分以内に成功したことを確認する。
- インバウンドセレクタを絞る： ルーティング用の読み取り専用テレメトリラベルは残しつつ、対象から
macos-ciを外す。 - ドレインするか SLA 内でドレインに到達： ランナープレイブックに従い、無言の
kill -9ではなくエスカレーションする。 - エージェントワークロードを開始： CI のチェックアウトと重ならないよう、ワークスペースのルートとログのプレフィックスを分ける。
- 15 分ごとにサンプリング： p95 待ちがベースライン比 40% 以上悪化したら貸し出しを中止する。
- きれいにクローズ： 孤児の Simulator を終了し、空きディスクが 15% 超であることを確認し、
macos-ciを再装着してゴールデンパイプラインを流し、チケットをクローズする。
レイテンシ、データレジデンシ、マルチリージョンの貸し出し
オーケストレーションのコントロールプレーンがシンガポールにありつつ、エージェントのトラフィックは東京の顧客データに寄せたい、といった場合、貸し出しの議論には CPU グラフだけでなく往復遅延とコンプライアンスを含める必要があります。実務では、SSH のホップが安定して 35 ms 前後に収まるなら、コンパイル中心のジョブや軽量のツール呼び出しは、同一都市ベースラインの壁時計でおおよそ 12% 以内に収まることが多いです。80 ms を超えるなら、3 リージョン離れた「専用」マシンを借りるより、ワークロードの隣にバーストホストを置く方が合理的です。成熟したチームは地理ごとに最小限のウォームプール—同一イメージ系列の Mac が少なくとも 2 台—を維持し、香港のホストを主に北米開発者が所有するキューに引きずり込むような貸し出しで調整コストが爆発するのを防ぎます。
データレジデンシは RFC に明記しましょう。エージェントは PII を含むリポジトリを読めるのか、ウィンドウ中にログはどこへ書かれるのか、終了後にセキュアワイプが必要か。文書化を怠るチームは、貸し出し後にディスク上に 80 GB 級のキャッシュが残り、容量を浪費し監査を不安にさせることがよくあります。ステップ 7 のクリーンアップは「時間があれば」ではなく、必須ゲートにしてください。
ロールバックの引き金とコミュニケーションの閾値
貸し出しは可逆な操作として扱います。以下の閾値を Slack のワークフローや PagerDuty の説明欄に公開しておくと、夜間のエスカレーションがおおよそ半分に減ることが多いです。関係者全員がインシデント中に同じ数値を引用できるからです。
「貸し出し開始」「貸し出し終了」用のチャットテンプレートを 1 種類に統一し、どのラベルが権威あるのか推測させないようにします。キューダッシュボードへのディープリンクを含め、数分で陳腐化するスクリーンショットだけに頼らないこと。プロダクト幹部から「貸し出しでリリースが遅れたか」と聞かれたら、開始時に取得した 3 つのベースライン指標だけで答えましょう。それ以外は物語バイアスを招きます。
- キュー深度： 深度がベースライン ×2 を 20 分連続で超えたら、CI オンコールを自動ページする。
- 失敗率： デフォルトブランチの赤率が 30 分以内に 8 ポイント以上悪化したら、作者のせいにする前にリソース競合を疑う。
- エージェント側： OpenClaw ゲートウェイが OOM するか、1 時間に 3 回以上再起動したら貸し出しを止め、エージェントを別ホストへ—ベースラインの健全性は ヘッドレス OpenClaw の受け入れチェック で確認する。
Mac を家畜としてスケジュールする利点は、Apple Silicon M4 のユニファイドメモリと電力効率にあります。同じ熱設計の中で、コンパイルのバーストと控えめな推論を交互に回しても、熱制約の強いノート PC で見るような激しい振れが起きにくい構造です。NodeMac は香港・日本・韓国・シンガポール・米国に専用 Mac mini M4 を提供し、SSH と VNC でのアクセス により、貸し出し時のオーバーフロー容量やエージェント専用ノードとして最適です。従量課金のレンタルは CapEx を OpEx に振り替え、実験的なエージェントスタックが必ずしもハード購入委員会を経由しなくて済むようにします。