CPUのスレッド数を徹底解説：SMT/Hyper‑Threadingの仕組みと最適スレッド数、実務での計測・運用ガイド

はじめに：CPUと「スレッド数」について

「スレッド数」はCPUの仕様やサーバーの性能議論で頻繁に出てくるキーワードです。だれもが「スレッドが多いほど速い」と誤解しがちですが、実態はやや複雑です。本コラムでは、ハードウェア側の「ハードウェアスレッド（論理プロセッサ）」とソフトウェア側の「ソフトウェアスレッド（OS/アプリのスレッド）」の違い、SMT（Simultaneous Multithreading）／Hyper-Threading概念、スレッド数が性能に与える影響、最適なスレッド数の考え方、運用・計測方法まで、実務で役立つ観点を深掘りして解説します。

用語整理：コア、スレッド、論理プロセッサとは何か

• 物理コア（Physical core）：実際の演算ユニット。整数演算ユニット・浮動小数点ユニット・キャッシュなどを備える。
• ハードウェアスレッド / 論理プロセッサ（Hardware thread / Logical processor）：OSがスケジューリング可能な「プロセッサ」として見える単位。物理コアあたり複数存在することがあり、それが表記上の「スレッド数」になることが多い。
• SMT（Simultaneous Multithreading）：1つの物理コア内で複数のハードウェアスレッドを同時に動作させ、コア内部の空きリソースを利用してスループットを高める技術。Intelの実装は「Hyper-Threading (HT)」、AMDも「SMT」として実装している。
• OS／アプリのスレッド：プログラムが生成する実行単位。カーネルスレッド（カーネルが直接スケジューリング）とユーザースレッド（ライブラリで管理、カーネルスレッドにマッピングされる）とでモデルは様々。

スレッド数の見方：スペック表の読み方

CPUの仕様で「コア数 × スレッド数/コア = 総スレッド数」という表記をよく見ます。例えば、6コアで「スレッド数：12」とあれば、各コアに2つのハードウェアスレッドがある（SMT=2）ことを意味します。OS上で表示される「論理プロセッサ数（logical CPUs）」は、通常この総スレッド数に一致します。

SMT（Hyper-Threading）の仕組みと効果

SMTは、1つの物理コア内部にある複数の実行コンテキスト（レジスタ等）を用い、命令発行・実行における空き時間を別のスレッドで埋めることでスループットを向上させます。完全に独立した追加コアを持つわけではなく、演算ユニット・キャッシュ・メモリ帯域など多くのリソースを共有します。

• 利点：単一コアのリソースをよりフルに活用でき、スループット（全体の仕事量）が増加する場合が多い。
• 欠点：キャッシュ競合やメモリ帯域の争奪が起こりやすく、特にメモリ帯域やキャッシュに依存するワークロードでは性能が伸びないか、逆に低下する場合もある。

ソフトウェアスレッド（OSスレッド）との関係

OSレベルでは「スレッド」はスケジューリング対象の単位です。アプリケーションが生成したスレッドはOSが割り当てられた論理プロセッサで実行されます。ユーザーレベルのスレッドライブラリを使うと複数のユーザースレッドを少ないカーネルスレッドで実行する（M:N）等のモデルも存在します。

並列性（Parallelism）と並行性（Concurrency）の違い

• 並列性：同時に複数の処理を物理的に実行すること（複数コアや複数の論理プロセッサを利用）。
• 並行性：複数の処理が並行して進行しているように見えるが、実際は時分割で処理される場合もある（単一コアでもスレッド切替で実現）。

スレッド数を増やせば並列度は高められますが、ボトルネック（メモリ・I/O・同期）により期待したスケーリングが得られないことがよくあります。

性能への影響：何スレッドが最適か？

最適なスレッド数はワークロードによって変わります。簡単な指針：

• CPUバウンド（計算中心）の場合：物理コア数に近いスレッド数が基本。SMT（論理プロセッサ）を有効にしているなら、物理コア数×(SMTの有効度合い)を上限の目安にする。多くは物理コア数～論理プロセッサ数の間で最大性能を得る。
• I/Oバウンド（ディスク/ネットワーク待ちが多い）の場合：待ち時間を隠すためにスレッド数を増やせる。理論上は待ち時間/処理時間の比に応じてスレッド数を増やすとよい。

経験的によく使われる簡易式：最適スレッド数 ≒ コア数 × (1 + 平均待ち時間/平均処理時間)。この式は待ち時間が多いほどスレッドを増やすべきことを示します（Littleの法則に関連した考え方）。

並列化の限界：Amdahlの法則

並列化には限界があり、プログラム全体のうち並列化できない部分が存在すると理論上の最大加速は制限されます（Amdahlの法則）。スレッド数を無限に増やしても、シリアル部分がボトルネックになれば速度は頭打ちになります。

実務での注意点とベストプラクティス

• まずは計測：負荷試験やプロファイリングでボトルネック（CPU、メモリ、I/O、ロック）を特定する。
• スレッドプールの活用：短命のスレッドを大量に作るのはコストが高い。スレッドプールで再利用する。
• 同期の最小化：ロック争奪（コンテンダー）があれば並列化効果が失われる。ロック粒度やロックフリー構造の検討を。
• SMTの挙動確認：SMTが効果を出すかはワークロード次第。ベンチで有効/無効を比較し、サーバーBIOSで切り替えるかOSレベルで論理CPUを制御する。
• NUMA考慮：複数ソケットやNUMAノードがある場合、スレッドとメモリ割当（CPUピニング、メモリバインド）を適切に行う。
• 仮想環境のvCPU管理：VMに割り当てるvCPU数を物理論理プロセッサ数以上に割り当てると過剰割付（oversubscription）となり性能低下する可能性がある。

計測と確認方法（主要OSでの確認）

• Linux: lscpu コマンドで「CPU(s)」「Core(s) per socket」「Thread(s) per core」が確認できる。/proc/cpuinfo でも詳細確認可能。nproc や getconf _NPROCESSORS_ONLN も利用。
• Windows: タスクマネージャーの「パフォーマンス」タブで論理プロセッサ数を確認。PowerShellでは Get-WmiObject Win32_Processor | Select NumberOfCores,NumberOfLogicalProcessors。
• macOS: sysctl -n hw.physicalcpu hw.logicalcpu で物理/論理コア数を確認。

仮想化・クラウド環境における注意

クラウドVMでは「vCPU」が公開スペックになりますが、vCPUはホストの論理プロセッサ上のスケジューリング単位です。ホスト側でvCPUを過剰に割り当てていると、突発的に性能劣化が起きます。クラウドベンダーのドキュメントやインスタンスタイプの仕様（物理コアか論理プロセッサベースか）を確認してください。

まとめ—スレッド数をどう扱うか

• 「スレッド数」は単純に多ければよいわけではない。ハードウェアスレッド（論理プロセッサ）が増えれば並列度は増えるが、共有資源（キャッシュ、メモリ帯域）がボトルネックになる。
• ワークロードに応じて物理コア基準で設計、SMTの有効/無効をベンチマークで検証、スレッドプールやCPUピニング・NUMA設定などの運用面を整えることが重要。
• まずは計測と小さな実験（SMT on/off、スレッド数スイープ）で最適点を見つけるのが最短の道。

参考文献

• Intel — Hyper-Threading Technology（公式）
• AMD — Simultaneous Multithreading (SMT)（公式）
• Wikipedia — Hyper-threading
• Wikipedia — Amdahl's law
• lscpu(1) — Linux man page
• Linux Kernel Documentation — CPU affinity / IRQ affinity（NUMA/ピニング参考）