# CPU負荷診断レポート — 2026-05-11 12:07

## 計測環境
- 調査時刻: 2026-05-11 12:07 JST
- uptime: 19時間稼働 / load avg: 2.06, 1.54, 1.63
- top実測時の全体CPU: user 5.3% / sys 10.6% / idle 84.9%
- ディスプレイ: 内蔵Retina 2880×1864 × 1枚（外部モニタなし）
- Safariタブ: 7 / Chrome Helper: 13プロセス（≒タブ数）
- アクティブウィンドウ数: 18

---

## 真因ランキング

### 1位: anchor_monitor.py（PID 1118）— 疑惑の常駐Python

**top2回サンプル実測値: 7.7% → 6.0%（持続的）**

- 正体: `/Users/rk/jarvis-dashboard/anchor_monitor.py`
- 挙動: REFRESH_INTERVAL_SEC = 30秒ごとに ccusage + JSONLスキャン実行
- 問題: 30秒ポーリング × ~/.claude/projects/*.jsonl 全スキャンは高コスト
- 推測: ファイルI/Oが多量でsys CPUを圧迫 → サイト描画の応答遅延に波及
- 対処: REFRESH_INTERVAL_SEC を 30→120秒に変更 / ccusageコール最適化

### 2位: WindowServer（PID 397）— 実際は Activity Monitor バイアス込みで膨張

**top実測: 6.7%（Activity Monitor計測34.8%は誤り）**

- Activity MonitorはWindowServerに自身の描画負荷をアトリビュートする既知バイアス
- top -l（サンプリング型）の6.7%が実際の値
- 真因: Chrome+Safariの両立（二重レンダリングスタック）+ VSCode + 18ウィンドウ
- ディスプレイは1枚Retinaのみ → 複数モニタ問題は非該当
- 対処: Chrome/Safariどちらかに統一（バックグラウンドタブを閉じる）

### 3位: bluetoothd（PID 389）— 通常時の倍のCPU

**top実測: 2.1%（bluetoothd として異常値）**

- 通常 bluetoothd は 0.1〜0.3% 程度
- AppleCentauriAlpha（Wi-Fi/BT複合ドライバ）も 1.1% で連動
- 推測: AirPodsかHOLLYLAND等のBTデバイスが断続再接続 / 干渉している
- 対処: 不要なBTデバイスをペアリング解除 or 一時OFF

---

## WindowServer 34.8% は本当に高かったのか

**結論: Activity Monitorの表示は誤り。実際は 6.7%。**

> Activity Monitor自体がWindowServerの描画コスト（グラフ描画・更新）を
> WindowServerプロセスに算入するバイアスがある。
> top -l コマンドではこのバイアスが除外される。
> top実測 6.7% は Retina 2880×1864 + 18ウィンドウ + Chrome並列描画 として
> やや高め（許容上限の目安は10%）だが「異常値」ではない。

---

## kernel_task Threads 641 の妥当性

**結論: 温度throttlingの証拠なし。Threads 641 はやや高いが正常範囲内。**

- pmset thermlog: 出力なし（throttling記録なし）
- thermal sysctl: 利用不可パス（Apple Silicon / Darwin 25の差異）
- top実測での kernel_task CPU: 3.9%（高い方だが危険水準ではない）
- 641スレッドはドライバ・XPC・I/Oポートの合算。19時間稼働なら自然な累積
- 対処: 不要であれば再起動でリセット（根本解決）

---

## 「サイト動かない」再発防止 3策

### 策1: anchor_monitor.py のポーリング間隔を 30→120秒へ
```python
# /Users/rk/jarvis-dashboard/anchor_monitor.py
REFRESH_INTERVAL_SEC = 120  # 変更（元30）
```
推定削減: 現状7.7% → 2%以下。これ単体でload avgを0.5〜0.8下げられる可能性。

### 策2: Chrome/Safariどちらかをメインに絞り、バックグラウンドタブを閉じる
- 現状: Chrome 13プロセス + Safari 7タブ = 二重レンダリングスタック
- calendar.google.comはChromeで開いたままにするか、Safariに統一するか決める
- 不要タブを閉じるだけで WindowServer+ブラウザ合計を 5〜8% 削減推定

### 策3: bluetoothd 対処（BTデバイス整理）
- ペアリング済みBTデバイスのうち現在使っていないものをOFF/解除
- AirPodsの自動切替を無効化（システム設定 → Bluetooth → AirPods → 接続先）

---

## その他プロセスの状況

| プロセス | 実測CPU | 評価 |
|---|---|---|
| resource_guard.py (PID 1114) | 1.1% | 許容（60秒ポーリング） |
| agent_fleet_monitor.py (PID 1121) | 1.9% | 許容 |
| timeline_monitor.py (PID 4051) | 上昇中 7.7%→現在安定 | 要監視（INTERVAL=60秒） |
| claude (PID 25802) | 3.3% | 正常（本セッション） |
| Activity Monitor (PID 675) | 2.3% | 計測ツール自身のコスト |
| searchpartyd (PID 574) | 2.8% | 異常値。AirDropやFindMy等の探索系常駐 |

**searchpartyd 2.8%** は見落としていた追加の犯人候補。
Find My / AirDrop 不使用なら `Disable Standby` or `launchctl unload` で削除可能。

---

## サマリ（30秒で読む版）

```
真因:
1. anchor_monitor.py (30秒ポーリング×ccusage) → 7.7% 常駐。即修正可
2. WindowServer 34.8%はActivityMonitorの誇張。実態6.7%で正常〜やや高め
3. bluetoothd 2.1% + searchpartyd 2.8% の系統デーモン群が意外に重い

「サイト動かない」の直接トリガー:
→ anchor_monitorのccusage実行タイミング(30秒毎)にI/Oスパイクが起きて
  ブラウザのレンダリングスレッドが待たされる可能性が高い

対処優先度:
1. anchor_monitor.py REFRESH_INTERVAL_SEC = 120 に変更（即効・リスクゼロ）
2. Chromeタブ整理（calendar.google.comは1タブのみ残す）
3. 不要BTデバイス整理
```

---

*計測ツール: top -l2, ps auxww, osascript, system_profiler*
*調査実施: Claude Code Sonnet 4.6 (Jarvisセッション外・通常モード)*