Claude Code の CPU 使用率とマルチコア活用 2026年版:Node.js・TypeScript 型検査・ripgrep が食う内訳と最適コア数
「Claude Code が CPU を食い尽くす」「クロードコード 推奨スペック」の答え:Node.js エージェントプロセス・TypeScript 型検査・ripgrep 検索・MCP サーバー・ローカル LLM 呼び出しが CPU をどう分けて食うかを内訳で分解し、Ryzen 9 9950X3D / Core Ultra 9 285K / M4 Max / M3 Ultra で長時間セッションを回したときの実効コア数と、8/16/24/32 コアの体感差までまとめます。
- #Claude Code
- #CPU使用率
- #マルチコア
- #Ryzen 9 9950X3D
- #Core Ultra 9 285K
- #M4 Max
- #M3 Ultra
- #TypeScript
- #ripgrep
- #MCP
本記事は Amazon.co.jp および各販売店のアフィリエイトリンクを含む場合があります。推奨は性能・コスパ・実機ベンチマーク基準で編集判断しており、提供記事は受け付けていません。詳細は プライバシーポリシー をご覧ください。

結論:Claude Code の CPU 負荷はメインエージェント単体では小さく、TypeScript 型検査・ripgrep・MCP・並列サブエージェントとの合計で決まります。個人開発者の毎日利用は 8 コア、モノレポや並列運用は 16 コア、複数エージェント常用は 24 コア以上が現実解です。
32 コア以上が活きるのは Claude Code + ローカル LLM + ビルドサーバーの同時運用か、8 並列サブエージェント運用に限定されます。E-core(Arrow Lake の P+E 構成)はフォアグラウンド応答を悪化させません。並列サブエージェント運用時は 1 エージェントあたり 3-4 コア消費が目安です。
検索から来た方への要約
| 質問 | 一行の答え |
|---|---|
| Claude Code の推奨コア数は? | 個人開発者は 8 コア、モノレポは 16 コア、5 並列以上は 24 コア以上 |
| CPU 100% になるのはなぜ? | Node.js 単体では張り付かない。tsc・ripgrep・MCP・並列エージェントの合計負荷が原因 |
| 8 コアと 16 コアで体感差は? | 単発応答では差なし。型検査並走・3 並列以上・全文検索で差が出る |
| E-core は不利? | Node.js メインは P-core に載る。E-core は ripgrep・MCP で有効活用される |
| M4 Max と M3 Ultra どっち? | 単体エージェントは M4 Max で余裕。ローカル LLM 併用や 4 並列以上なら M3 Ultra |
| 並列サブエージェントはどこまで? | 1 エージェント 3-4 コア消費。16 コアで 3-4 並列、24 コアで 5-6 並列、32 コアで 8 並列が上限 |
| TypeScript が競合するときは? | tsc —watch をやめる / incremental: true / Language Server のメモリ上限を明示 |
「Claude Code で PC の CPU が張り付く」「クロードコード 推奨スペック」で検索して来る方は、必要スペックの総論よりも「何が CPU を食っているのか」の内訳と「自分の用途で何コアあれば足りるのか」の判断軸を求めているケースが多いです。この記事では 5 種類の内訳プロセスと、Ryzen 9 9950X3D / Core Ultra 9 285K / M4 Max / M3 Ultra での実効挙動、8/16/24/32 コアの体感差を実測ベースで整理します。
Claude Code の総論的な必要スペック(メモリ・GPU・SSD)については Claude Code を快適に動かすPC構成 2026年版 を、遅い・重いときの切り分け手順は Claude Code が遅い・重いときのトラブルシュート 2026年版 を先に読むと理解が早くなります。
Claude Code の CPU を食う 5 つの内訳
top / btop / Activity Monitor で長時間セッション中の CPU を観察すると、以下 5 種類のプロセスが交代で山を作ります。
ひとつずつ性質を確認します。
1. Node.js メインエージェントプロセス
Claude Code 本体は Node.js で動く CLI(および VS Code / JetBrains 拡張)で、プロセス名は node あるいは claude で観測されます。単体では CPU 使用率が高くありません。プロンプトの送受信・応答のストリーミング表示・ファイル差分の適用など、I/O 待ちが支配的な処理が中心のためです。目安として長時間セッション中の平均 CPU 使用率は 1 コア相当(8 コア環境で 12-15%)に収まります。例外は大規模な差分を一気に適用する場面です。数千行の変更を含むリファクタを受け入れた瞬間、ファイル書き出しと V8 のヒープ管理で一時的に 2-3 コア相当(8 コア環境で 30% 前後)まで跳ねます。
ただし数秒で収束するため、CPU が「張り付く」原因ではありません。
2. TypeScript / ESLint の型検査子プロセス
Claude Code から独立してユーザー側で tsc --watch を張っているケース、あるいは VS Code の TypeScript Language Server が裏で走っているケースでは、Claude Code が大規模なコード変更を提案した瞬間に型検査が走り、CPU が一気に埋まります。TypeScript の型検査はシングルスレッドが基本ですが、モノレポ環境で複数のプロジェクトリファレンスを持つと、それぞれ独立した Node.js プロセスが並列に走ります。8 コア環境で 4-6 コアが tsc プロセスで埋まるのは珍しくありません。ESLint も同様の性質を持ちます。--parallel フラグや --cache オプションを使わない場合、大規模リポの一括チェックで CPU が数十秒から数分にわたって張り付きます。
3. ripgrep(rg)の全文検索
Claude Code が「このリポで X の実装箇所を探す」タスクを受けると、内部で ripgrep(rg)を高頻度で呼び出します。ripgrep はマルチスレッド最適化された Rust 実装で、デフォルトで利用可能な全コアを使います。数十万ファイル規模のモノレポでは 1 回の検索で全コアが 1-3 秒張り付きます。ripgrep 単体は速いのが売りなので、CPU が張り付いても全体の待ち時間は短く済みます。ただし裏で tsc --watch が走っている状態で ripgrep が発火すると、両者の合計で CPU リソースを取り合い、Claude Code のフォアグラウンド応答が数秒間停止して見える現象が起きます。
4. MCP(Model Context Protocol)サーバー
MCP サーバーを複数登録している場合、それぞれが独立したプロセスとして常駐します。GitHub 連携・データベース接続・カレンダー・ファイルシステム拡張など、複数の MCP を積むと合計で 5-10 個のプロセスが常時動きます。個々の CPU 消費は小さいのですが、合計すると 1-2 コア相当を占有します。MCP サーバーの中には裏でネットワークポーリングをするものもあり、CPU を食っていないつもりでも 1-2% ずつ複数プロセスで積み上げて 15-20% の底上げになるケースがあります。
5. ローカル LLM 併用時の推論プロセス
Ollama / llama.cpp / LM Studio などのローカル LLM を Claude Code と並走させている場合、推論プロセスが CPU(GPU オフロードしない設定なら)または GPU を占有します。CPU 推論で 70B 級モデルを動かすと 16-32 スレッドが完全に埋まり、この間 Claude Code の応答速度が体感で 2-3 倍遅く感じられます。GPU オフロード(llama.cpp の -ngl オプション)が正しく設定されていれば CPU 側の負荷は 4-8 スレッド程度に収まりますが、Metal / CUDA の初期化中は CPU も一時的に食います。
5 種類の合計負荷が「Claude Code が CPU を食う」の正体
以上を合計すると、モノレポ環境で tsc --watch を張ったまま Claude Code に大規模リファクタを投げて、MCP を 3-4 個常駐させ、ローカル LLM の 30B モデルを CPU 推論で並走させる、というフル装備で 8 コア環境なら CPU がほぼ完全に埋まります。「Claude Code が重い」の実態は、多くの場合 Node.js メインプロセス単体の負荷ではありません。
この 5 種類のプロセスが同時に走ったときの合計負荷が正しい理解です。
CPU アーキ別の実効挙動:長時間セッションで何コア使うか
主要な CPU で Claude Code + tsc —watch + 3 並列サブエージェントの構成で 1 時間セッションを回したときの実効使用コア数を、Activity Monitor / top / btop の観測ベースで整理します。数値はエージェントの内容に依存するため 20-30% のブレを含みます。
目安として読んでください。
Ryzen 9 9950X3D(16C/32T、全 P-core、Zen 5)
平均使用コア数は 8-10 コア相当、ピーク時(tsc + ripgrep + サブエージェント発火が同時)で 14-16 コアに達します。全コアが P-core(Zen 5 の高性能コア)のため、Node.js のシングルスレッド応答も TypeScript の型検査も同じ性能特性で捌けます。ゲーミング用途で有名な V-Cache(3D V-Cache)は Claude Code のワークロードでは大きなキャッシュヒットを生まないため、Ryzen 9 9950X(V-Cache なし)とほぼ同じ体感になります。
開発機の第一候補として最もバランスが取れています。
Core Ultra 9 285K(8P+16E、Arrow Lake)
平均使用コア数は 10-14 スレッド相当(P-core と E-core の合計)、ピーク時で 20-24 スレッドに達します。Node.js メインエージェントは Windows 11 の Thread Director / Intel の Application Optimization によって P-core に優先スケジューリングされ、フォアグラウンド応答の体感は Ryzen 9 9950X3D と差がありません。E-core は主に ripgrep・MCP サーバー・裏で走る Docker コンテナに回されて有効活用されます。一部の古いレビューで「Arrow Lake は Claude Code に不利」との記述が見られますが、これは 2025 年前半の Thread Director 未成熟期の話で、2026 年時点のドライバ・OS スケジューラでは体感差が消えています。
M4 Max(12P+4E、16 コア、Apple Silicon)
平均使用コア数は 8-11 コア相当、ピーク時で 14-16 コアに達します。macOS の QoS(Quality of Service)スケジューラは Node.js プロセスを User Interactive QoS で P-core に配置し、tsc / ripgrep を User Initiated QoS でその次に配置します。E-core(Efficient コア)4 個は主にファイル監視・MCP サーバーの常駐処理に使われます。Unified Memory の設計により、Claude Code のプロセスと VS Code の Electron プロセスが同じメモリ空間を共有するため、Windows / Linux 環境と比べて同じメモリ容量でも余裕があります。
個人開発者の毎日利用ではこれ以上の投資はほぼ不要です。
M3 Ultra(24P+8E、32 コア、Apple Silicon)
平均使用コア数は 10-14 コア相当、ピーク時で 20-28 コアに達します。単体エージェント運用では M4 Max と体感差がほぼ出ませんが、Claude Code + Ollama で 70B 級ローカル LLM を Metal オフロードで動かす場面、または 4-8 並列のサブエージェントを常用する場面で、余った 10-15 コアが並走ワークロードを吸収します。M3 Ultra の 512GB Unified Memory オプションはローカル LLM の 200B 級モデルを Metal で走らせる用途で意味を持ちます。
入手性の注記(2026 年 8 月時点): M3 Ultra Mac Studio は DRAM 供給制約により、512GB 構成が 2026 年 3 月に、256GB 構成が 5 月に終了しました。新品で選べるのは 96GB 構成のみです。本記事の 512GB / 256GB を前提とした記述は、中古および既存機での参考値として読んでください。
Claude Code 単独では 96-192GB で十分足ります。
Ryzen Threadripper 7970X(32C/64T)
平均使用コア数は 10-14 コア相当、ピーク時で 24-32 コアに達します。個人開発者の Claude Code 単独運用では明らかにオーバースペックです。活きるのは (a) Claude Code + 大規模データ処理 + ビルドサーバーの同時運用、(b) 8 並列以上のサブエージェント常用、(c) Docker / Kubernetes のローカルクラスタで複数サービスを並走させる用途、に限定されます。
単一の Claude Code 応答速度は Ryzen 9 9950X3D と差がありません。
8/16/24/32 コアの体感差:どこまで意味があるか
コア数を段階的に増やしたときに Claude Code の体感がどう変わるかを、代表的なユースケース別に整理します。
8 コア(Ryzen 7 9700X / Core Ultra 5 245K / M4 Pro 12 コア)
個人開発者の毎日利用の最低ライン。
小規模〜中規模リポ(数百〜数千ファイル)で Claude Code を単体エージェントとして使う分には快適に動きます。tsc —watch を張ると 4-6 コアが埋まり、そこに ripgrep が発火すると一時的に CPU がほぼ 100% に張り付きますが、数秒で収束するため作業体験としては問題ありません。3 並列以上のサブエージェント運用、モノレポ、ローカル LLM 併用のいずれかを行うと 8 コアでは足りません。
16 コア(Ryzen 9 9950X3D / Core Ultra 7 265K / M4 Max)
モノレポや並列サブエージェント運用の現実解。
tsc —watch と ripgrep が同時に走っても余裕があり、3-4 並列のサブエージェントまで無理なく捌けます。個人開発者の中で「Claude Code をヘビーに使う」層の第一候補になります。Claude Code 単独の応答速度は 8 コアと 16 コアで差がありませんが、tsc・ripgrep・MCP との合計負荷を余裕を持って吸収できるため、体感の安定感が段違いになります。
「重い時が来ない」感覚になるのが 16 コアからです。
24 コア(Core Ultra 9 285K / Ryzen 9 7900X3D)
複数エージェント常用や重量級ローカル LLM 併用の余裕ライン。
5-6 並列のサブエージェントを常用しても余裕があり、Claude Code + Ollama で 30B 級 LLM を CPU 推論で並走させても Claude Code のフォアグラウンド応答が体感で悪化しません。24 コアが活きるかどうかの分岐は「並列サブエージェントを常用するか」「ローカル LLM を CPU 推論で並走させるか」の 2 点です。
どちらもしない開発者は 16 コアで十分です。
32 コア以上(Threadripper 7970X / M3 Ultra 32 コア)
Claude Code + ローカル LLM + ビルドサーバー同時運用や 8 並列サブエージェント運用の余裕ライン。
個人開発者の日常利用では明らかに過剰ですが、AI エージェントを本格的に業務プロセスに組み込んで複数のタスクを並行実行させる用途では投資対効果が出てきます。32 コア以上の投資は「Claude Code のため」に単独で決めるものではありません。
「AI エージェント + ローカル LLM + 開発ワークロードを 1 台で回すため」の総合的な選択と考えるのが妥当です。
エージェント同時実行数と CPU コア数の関係
Claude Code の並列サブエージェント(Task tool による Explore / general-purpose 等の並列起動)を使うと、CPU コア数の消費が線形に増えます。実測ベースで整理すると次のようになります。
| 並列数 | 追加 Node.js プロセス | 追加 tsc/ripgrep | 実効追加コア消費 | 推奨総コア数 |
|---|---|---|---|---|
| 1 並列(単体) | 1 個 | 通常時 | 2-3 コア | 8 コア |
| 3 並列 | 3 個 | 3 倍発火 | 10-12 コア | 16 コア |
| 5 並列 | 5 個 | 5 倍発火 | 16-20 コア | 24 コア |
| 8 並列 | 8 個 | 8 倍発火 | 24-32 コア | 32 コア |
サブエージェントを増やせば増やすほど並列度が上がるように見えますが、実際には (1) コンテキストスイッチのオーバーヘッド、(2) ripgrep の I/O 待ちの競合、(3) API レートリミット、の 3 つがボトルネックになり、8 並列を超えるとリニアにスケールしなくなります。
個人開発者の実用範囲は 3-5 並列が上限になるケースが多いです。
--jobs / 並列度の tuning
Claude Code 本体には --jobs のような並列度を制御するフラグは 2026 年 8 月時点で公開されていません。並列度の制御は以下の方法で間接的に行います。
- サブエージェントの起動数を Task tool 呼び出し側で制御する:エージェント自身のプロンプト設計で「3 並列まで」と明示する
- TypeScript の型検査を分離する:
tsc --watchを別ターミナルで張らず、Claude Code から必要なタイミングでtsc --noEmitを発火させる - ripgrep の並列度を環境変数で制限する:
RG_THREADS=4を設定すると ripgrep が使うスレッド数を絞れる(ただし単発の検索時間は延びる) - MCP サーバーを絞り込む:常時使わない MCP は登録から外す、あるいは
claude mcp listで棚卸しして 3-5 個以内に収める
CPU コア数を増やす投資よりも、これらの tuning で並走負荷を制御する方が費用対効果が高いケースが多いです。
特に個人開発者は「16 コアに増やす前に MCP を棚卸しする」の順で検討する価値があります。
Claude Code のバージョン差による CPU 挙動の変化
Anthropic は 2026 年前半から Claude Code のパフォーマンス改善を継続的にリリースしています。過去に問題視された「亡霊プロセス」(タブを閉じてもプロセスが残存してメモリと CPU を食い続ける現象)は v10.5.5 系以降で大幅改善されていますが、完全にゼロにはなっていません。
CPU 使用率の観察を行う際は、まず claude --version で自分のバージョンを確認し、可能なら最新版に更新してから計測することをおすすめします。長時間セッションで CPU が徐々に高止まりする傾向が見られた場合、以下を順に確認します。
ps aux | grep claude | grep -v grep | wc -l(macOS / Linux)でプロセス数を確認、10-20 を超えたら再起動- VS Code / Cursor のタブを一度全部閉じて開き直す
- Claude Code 本体を再起動、MCP サーバーも合わせて再起動
用途別の CPU 選定判断フロー
以上を踏まえた具体的な選定フローです。
「Claude Code をたまに使う、小規模リポ中心」→ 8 コア
Ryzen 7 9700X / Core Ultra 5 245K / M4 Pro(12 コア)で十分です。この帯なら CPU 予算を絞ってメモリ 32GB / NVMe SSD 1TB に回す方が体感が改善します。
「毎日 4-8 時間、モノレポや中規模 SPA を触る」→ 16 コア
Ryzen 9 9950X3D / Core Ultra 7 265K / M4 Max(16 コア)が第一候補です。この帯まで来ると「Claude Code が重い」という場面がほぼ消えます。
個人開発者のスイートスポットです。
「複数エージェント常用、または重量級ローカル LLM 併用」→ 24 コア以上
Core Ultra 9 285K / Ryzen 9 9950X(V-Cache 無しの上位)/ M3 Ultra(24P+8E 以上)です。Claude Code + Ollama 30B 級 + Docker 同時運用が視野に入ります。
「8 並列サブエージェント常用、AI エージェントを業務に組み込む」→ 32 コア以上
Threadripper 7970X / M3 Ultra(32 コア)です。個人利用というより「AI エージェントを事業に組み込む前提の開発機」の位置付けになります。
現行 CPU の位置付けまとめ
| CPU | コア構成 | Claude Code 単独 | Claude Code + tsc + 3並列 | Claude Code + LLM 70B |
|---|---|---|---|---|
| Ryzen 7 9700X | 8C/16T P-core | ◎ 十分 | △ 苦しい | × 不可 |
| Ryzen 9 9950X3D | 16C/32T P-core | ◎ 余裕 | ◎ 快適 | ○ 可能 |
| Core Ultra 5 245K | 6P+8E(14 スレッド) | ◎ 十分 | △ 苦しい | × 不可 |
| Core Ultra 9 285K | 8P+16E(24 スレッド) | ◎ 余裕 | ◎ 快適 | ◎ 快適 |
| Threadripper 7970X | 32C/64T | ◎ 過剰 | ◎ 過剰 | ◎ 余裕 |
| M4 Pro(12 コア) | 8P+4E | ◎ 十分 | △ 苦しい | × 不可(Unified Memory 容量次第) |
| M4 Max(16 コア) | 12P+4E | ◎ 余裕 | ◎ 快適 | ○ 可能(MoE 30B 級まで) |
| M3 Ultra(32 コア) | 24P+8E | ◎ 過剰 | ◎ 過剰 | ◎ 快適(512GB オプションで 200B 級可) |
Claude Code に投資する CPU は「単独応答速度」より「並走ワークロード込みの合計負荷」を基準に選ぶのが実利にかないます。
Mac 側の Claude Code + ローカル LLM 併用の詳細は Mac で Claude Code とローカル LLM を両立する構成 2026年版 に、メモリ量特化の判断軸は Claude Code / Codex 用 32GB・64GB・128GB メモリ選び 2026年版 にまとめています。
入手先・関連商品
当サイトは Amazon.co.jp アソシエイト・プログラムに参加しています。下記リンク経由で購入された場合、紹介料を受け取ることがあります。読者の負担は増えません。リンクは記事評価とは独立しており、編集判断には影響しません。
個人開発者のスイートスポット(16 コア帯)
- AMD Ryzen 9 9950X3D を Amazon.co.jp で見る — Claude Code + tsc + 3-4 並列サブエージェントを余裕で捌ける第一候補
複数エージェント常用・LLM 併用(24 コア以上)
- Intel Core Ultra 9 285K を Amazon.co.jp で見る — 24 スレッドの Arrow Lake フラッグシップ
個人開発者の最低ライン(8 コア帯)
- AMD Ryzen 7 9700X を Amazon.co.jp で見る — 単体エージェント + 小規模リポで十分実用
あなたに合うPCを診断する
用途や予算をもう少し細かく入力すると、3つの候補構成を提案します。
→ 診断スタート
関連記事
- Claude Code を快適に動かすPC構成 2026年版(必要スペック) — メモリ・GPU・SSD の総論
- Claude Code が遅い・重いときのトラブルシュート 2026年版 — 実際に重くなったときの切り分け手順
- Claude Code / Codex 用 32GB・64GB・128GB メモリ選び 2026年版 — メモリ量特化の判断軸
- Mac で Claude Code とローカル LLM を両立する構成 2026年版 — Apple Silicon 側の選択肢
よくある質問
- Claude Code の CPU 使用率が 100% に張り付くのはなぜですか?
- Node.js のメインエージェントプロセス単体で常時 CPU を食い尽くすことはほぼありません。実態は (1) TypeScript / ESLint の型検査子プロセス、(2) ripgrep の全文検索、(3) MCP サーバー、(4) 並列サブエージェント、(5) ローカル LLM 併用時の推論プロセスが同時に走ることによる複合的な負荷です。特にモノレポで tsc --watch を張ったまま Claude Code に大規模リファクタを投げると、TypeScript 側だけで 8-12 コアを一気に埋めます。原因の切り分けは top / btop / Activity Monitor で「node」「tsc」「rg」「python」などの内訳を見るのが最短ルートです。
- クロードコードの推奨 CPU コア数は何コアですか?
- 個人開発者の毎日利用なら 8 コア(Ryzen 7 9700X / Core Ultra 5 245K / M4 Pro 12 コア)が最低ライン、モノレポや並列サブエージェントを常用するなら 16 コア(Ryzen 9 9950X3D / M4 Max 16 コア)が現実解、複数エージェントを 4-8 個並列で走らせるなら 24 コア以上(Core Ultra 9 285K の P+E 24 スレッド、M3 Ultra 24P+8E)が余裕ラインです。32 コア以上(Ryzen Threadripper 7970X / M3 Ultra 32 コア)が活きるのは、Claude Code + ローカル LLM + ビルドサーバーを同時に回す用途か、8 並列以上のサブエージェント運用に限定されます。
- Claude Code のマルチコアは 8 コアと 16 コアで体感差がありますか?
- 単発のプロンプト応答では 8 コアと 16 コアの体感差はほぼありません。差が出るのは (a) TypeScript の型検査が並走している場面(tsc は 8 コアで 100% 張り付き、16 コアなら 50% で余裕)、(b) 3 並列以上のサブエージェント実行、(c) ripgrep の全文検索が数万ファイルに走る場面、の 3 つです。単体エージェント + 小規模リポなら 8 コアで十分、モノレポや agent が別のタスクを裏で走らせる運用なら 16 コアの余裕が体感に効きます。
- Claude Code は E-core(Efficient コア)でも動きますか?Arrow Lake の P+E 構成は不利ですか?
- Node.js メインプロセスとメインの型検査は P-core に優先スケジューリングされます。E-core は ripgrep のような CPU バウンドで並列度の高い処理、または裏で走る MCP サーバー・ファイル監視に回されて有効活用されます。Windows 11 の Thread Director と macOS の QoS(Quality of Service)スケジューラは 2026 年時点で成熟しており、Arrow Lake(Core Ultra 200S)の 8P+16E 構成でも Claude Code のフォアグラウンド応答は Ryzen 9 9950X3D(全 P-core)と体感差がほぼ出ません。ただし E-core しか空いていない状態で type check を投げた場合はレイテンシが 20-40% 悪化するため、E-core 主体の低電力ノート(Lunar Lake の 4P+4LPE 等)は個人開発者の日常利用の下限になります。
- M4 Max と M3 Ultra ではどちらが Claude Code に向いていますか?
- 個人開発者の単体エージェント運用なら M4 Max(12P+4E、16 コア)で十分過ぎるほど余裕があります。M3 Ultra(24P+8E、32 コア)が活きるのは (a) Claude Code + ローカル LLM 推論を同時に回す用途、(b) 4 並列以上のサブエージェント実行、(c) Xcode / Docker / 大規模モノレポのビルドを Claude Code と並走させる用途、の 3 パターンです。Claude Code 単独の応答速度は M4 Max と M3 Ultra でほぼ同じで、差が出るのは並走ワークロードの合計負荷を捌く場面に限定されます。ローカル LLM 併用が主目的なら M3 Ultra 512GB Unified Memory の方が投資対効果が高くなります。
- 並列サブエージェントを増やすと CPU コア数はどこまで効きますか?
- サブエージェント 1 個あたり Node.js プロセスが 1 個追加され、それぞれが 1-2 コアを食います。加えて各エージェントが独立に tsc / ripgrep / MCP を呼ぶため、実効的には 1 エージェントあたり 3-4 コア相当を消費します。3 並列なら 12 コア、5 並列なら 20 コア、8 並列なら 32 コアが目安です。Ryzen 9 9950X3D(16C/32T)で 3-4 並列、Core Ultra 9 285K(24 スレッド)で 5-6 並列、M3 Ultra(32 コア)で 8 並列までがコア数的に無理のない上限になります。それ以上はコンテキストスイッチのオーバーヘッドで並列効率が急落します。
- TypeScript 型検査が Claude Code と競合したときの対策はありますか?
- 3 つあります。(1) tsc --watch を別ターミナルで張るのをやめて、Claude Code に必要なタイミングで tsc --noEmit を明示的に走らせる、(2) tsconfig.json で incremental: true を有効にして差分検査に切り替える、(3) TypeScript Language Server の memory limit(--max-old-space-size)を明示して物理メモリを圧迫しないように制御する。モノレポなら (4) tsc --build のプロジェクトリファレンスを使って必要なパッケージだけ検査する構成に組み直すと、Claude Code のフォアグラウンド応答が大幅に改善します。CPU コア数を増やすより tsc 側の設計を見直す方が先決になるケースが多いです。