Mac M4 で Xcode CI は OpenClaw Gateway を遅くする？swap 根本原因 + 同居デプロイ launchd チューニング完全ガイド（2026）

1. Mac M4 で Xcode CI と OpenClaw Gateway は同居できるか？

macOS 上では、Xcode ビルドエージェント（xcsbuildd）と OpenClaw Gateway（ポート 18789 で待ち受ける常駐 Node.js サービス）は本質的に独立したプロセスです。ポート競合なし、ソケット共有なし、launchd で同時管理可能です。

問題は「動くかどうか」ではなく、CPU ピーク + メモリ swap + スケジューラ優先度の衝突という 3 つの隠れたリスクにあります：

• Xcode コンパイルが全 CPU コアを瞬時に占有（M4 の 10 コアがフル稼働）
• Swift のクリーンビルドが 1 回あたり 4–6 GB RAM を消費
• macOS の swap 機構により Gateway の応答レイテンシがミリ秒から秒単位に跳ね上がる

2. Mac M4 のメモリモデルと CI ボトルネック：16 GB / 24 GB / 32 GB はそれぞれ足りるか？

現実的なメモリ配分ベースラインを確認しましょう。macOS 自体が約 3 GB 消費し、OpenClaw Gateway（Node.js ランタイム、Channels、Dashboard を含む）に安全マージンとして 800 MB を確保、残りすべてが Xcode ビルドプロセスに使われます。

Xcode ビルドのメモリ消費はプロジェクト規模によって大きく異なります：

これをもとに、各メモリ帯域の同居能力をまとめます：

32 GB マシンでは 3 本並列ビルドを安全に実行でき、Gateway は完全に影響を受けません。チームスケールの CI ノードに最適です。

3. Xcode CI と OpenClaw Gateway のポートは競合するか？プロセストポロジー全量対照表

同居デプロイの最初のステップは、両サービスのポート・プロセス名・launchd ラベルを確認し、優先度設定とインシデント診断のベースラインを確立することです。

sudo lsof -iTCP:20300 -sTCP:LISTEN   # Xcode Server
sudo lsof -iTCP:18789 -sTCP:LISTEN   # OpenClaw Gateway

# 両サービスのプロセスを一度に確認
ps aux | grep -E 'xcsd|xcsbuildd|openclaw' | grep -v grep

4. launchd + CPU スケジューラチューニング：Xcode が Gateway を圧迫しないようにする方法

macOS の launchd は plist の Nice キーでプロセス優先度を制御します（値が低いほど優先度が高い、範囲 −20〜20、デフォルト 0）。同居シナリオの中核戦略：Gateway に高い優先度を与えつつ Xcode の並列コンパイルスレッド数を制限し、コンテナも仮想化も使わず、launchd のネイティブ機構だけで対処します。

ステップ 1：Gateway スケジューラ優先度を上げる

<!-- <dict> 内に挿入して Gateway を Xcode より優先的にスケジュールさせる -->
<key>Nice</key>
<integer>-5</integer>

ステップ 2：Xcode 並列コンパイルスレッド数を制限（メモリ帯域別）

# 16 GB マシン推奨値：3–4（M4 の 10 コアの 30–40%）
defaults write com.apple.dt.Xcode \
    IDEBuildOperationMaxNumberOfConcurrentCompileTasks 4

# 24 GB マシン推奨値：4–6
# defaults write com.apple.dt.Xcode \
#     IDEBuildOperationMaxNumberOfConcurrentCompileTasks 5

# 32 GB マシン推奨値：6–8
# defaults write com.apple.dt.Xcode \
#     IDEBuildOperationMaxNumberOfConcurrentCompileTasks 7

# 現在の値を確認
defaults read com.apple.dt.Xcode \
    IDEBuildOperationMaxNumberOfConcurrentCompileTasks

ステップ 3：Gateway plist をリロードして Nice を反映

sudo launchctl unload /Library/LaunchDaemons/com.openclaw.gateway.plist
sudo launchctl load   /Library/LaunchDaemons/com.openclaw.gateway.plist

# nice 値が -5 であることを確認
ps -o pid,nice,comm -p $(pgrep -f openclaw-gateway)

5. swap が Gateway レイテンシを 50ms から 500ms に急騰させる真因と監視方法

macOS は Linux のように OOM Kill でプロセスを終了させません。代わりに非アクティブなメモリページを圧縮（Compressed Memory）して SSD の swap に書き込みます。この動作により Gateway のヒープがサイレントに退避され、次回アクセス時の解凍 CPU 負荷と I/O 待ちがレイテンシ急騰の直接原因になります。

Xcode ビルドのピーク中に別の SSH セッションを開き、以下の 3 層監視を実行します：

# 第 1 層：システム全体のメモリプレッシャーレベル（主要指標）
memory_pressure
# Normal   → 安全
# Warn     → Gateway レイテンシが揺れ始めている。並列数の削減を検討
# Critical → Xcode の並列数を直ちに半減させる

# 第 2 層：vm_stat スナップショット。compressed 列に注目
vm_stat | grep -E 'Pages (wired|active|inactive|compressed|free)'

# 第 3 層：Gateway 応答レイテンシをリアルタイムでプローブ
while true; do
  ms=$(curl -o /dev/null -s -w "%{time_total}" http://localhost:18789/health)
  echo "$(date +%H:%M:%S)  gateway=${ms}s"
  sleep 5
done

判断基準：memory_pressure が Warn を示し Gateway レイテンシが 200ms を超えたら、次の 3 択から選択してください：Xcode 並列数を下げる → より高い RAM 帯域にアップグレードする → Gateway を専用マシンに移行する。sudo purge で非アクティブページを一時的に解放してレイテンシが回復するか確認することはできますが、恒久的な解決策にはなりません。

6. 本番マシン分離の判断モデル：Mac M4 CI をいつ 2 台に分けるべきか

同居の上限は定量化できます。以下のいずれかに該当したら Gateway を専用ノードに移行してください：

• 1 日のビルド数 ≥ 50 回——累積したメモリプレッシャーにより、業務ピーク時に Gateway が周期的に揺れます。
• 3 本以上の並列ビルドが必要——24 GB マシンで 3 本同時フルビルドを実行すると空きメモリが限界に達します。
• Gateway がエンドユーザー向け（内部 CI 専用でない）——モバイルクライアントが直接 Gateway に接続する場合、わずかなレイテンシジッターもユーザーに伝わります。
• ビルド成果物 > 50 GB/月——ディスク I/O の競合により Gateway のログ書き込みとビルドスループットが両方低下します。

最小コスト分離プラン：Gateway 専用に M4 16 GB を 1 台追加（常駐メモリは ~500 MB なので 16 GB で十分）、元のマシンは Xcode ビルド専用に残します。Tailscale で内部ネットワークを構築（<5 ms レイテンシ）し、既存のネットワークトポロジーは変更不要です。分離後の詳細な運用については、OpenClaw 2026｜カナダのリモート Mac M4 における制御アップグレードと安定運用ハンドブック を参照してください。

7. FAQ：Mac M4 上の Xcode CI + Gateway 同居デプロイ よくある質問

Q1：Mac M4 で Xcode と Node.js サービス（OpenClaw Gateway）は互いに影響するか？

はい、主にメモリ swap とスケジューラ優先度を通じて影響します。CPU 直接競合ではありません。Xcode のフルビルドが 4–6 GB RAM を瞬時に消費すると、macOS は優先度の低い（Nice 未設定の）Gateway のメモリページを swap に圧縮します。解凍時の I/O 待ちが Gateway レイテンシを 50ms から 500ms に押し上げる直接原因です。Gateway に Nice=-5 を設定することで大幅に緩和できます。

Q2：Gateway レイテンシがなぜ突然 50ms から 500ms に跳ね上がるのか？

根本原因は macOS の Compressed Memory 機構です。Xcode ビルドが利用可能な RAM を使い切ると、Gateway の匿名メモリページが圧縮されて SSD swap に書き込まれます。次に Gateway がそのメモリにアクセスしようとすると、CPU による解凍と SSD 読み取りを待たなければならず、この往復が数百ミリ秒の遅延を生みます。memory_pressure コマンドでリアルタイムにプレッシャーレベル（Normal / Warn / Critical）を監視できます。

Q3：Xcode の並列コンパイル数は何に設定すると最も安定するか？

メモリ帯域別：16 GB → 3–4 スレッド（M4 の 10 コアの 30–40%）、24 GB → 4–6 スレッド、32 GB → 6–8 スレッド。コマンド：defaults write com.apple.dt.Xcode IDEBuildOperationMaxNumberOfConcurrentCompileTasks 5（24 GB の例）。設定後にビルドを 1 回トリガーして Gateway レイテンシが 100ms 以内に収まることを確認してから微調整してください。

Q4：launchd の Nice=-5 は具体的に何をするのか？

Nice 値が低いほど macOS スケジューラがそのプロセスに多くの CPU タイムスライスを割り当て、Compressed Memory による圧縮対象になるタイミングも遅くなります。Gateway を Nice=-5（Xcode のデフォルトは 0）に設定することで、CPU 競合時に Gateway が優先的にスケジュールされ、メモリプレッシャー下でも Xcode コンパイルプロセスより後に swap へ追い出されるようになり、Gateway の応答速度が維持されます。

Q5：いつマシンを分離しなければならないか？どの条件で同居を続けられなくなるか？

次のいずれかに該当したら Gateway を専用ノードに移行してください：① 並列ビルド ≥3 本；② 1 日のビルド数 ≥50 回；③ Gateway がエンドユーザー向け（モバイルが直接接続し内部 CI 専用ではない）；④ 業務時間中に memory_pressure が Warn または Critical を継続し Pages compressed が回復しない。最小分離プラン：M4 16 GB を 1 台追加して Gateway 専用に、Tailscale 接続（<5 ms）。

Q6：16 GB Mac M4 で Xcode CI と OpenClaw Gateway を本番環境で同時に動かせるか？

できますが、厳しい条件があります：① 並列ビルドを 1 本に制限；② Gateway は内部 CI 専用（外部に公開しない）；③ 1 日のビルド数を 20 回以下に抑える。この設定では memory_pressure はほとんどの時間 Normal を維持し、Gateway レイテンシが時折揺れても通常 <300ms で回復します。条件を超えたらすぐに 24 GB にアップグレードするか分離してください。