「コンテキストスイッチ（Context Switch）」はオペレーティングシステム（OS）の基礎的かつ重要な概念のひとつです。
マルチタスク処理を可能にするこの仕組みは、現代のコンピュータがなぜ同時に複数のアプリケーションを動かせるのかを理解するための鍵となります。
本記事では、コンテキストスイッチの仕組み・オーバーヘッド・最適化手法まで詳しく解説していきます。
コンテキストスイッチとは何か？基本的な仕組み
それではまず、コンテキストスイッチの基本的な仕組みについて解説していきます。
コンテキストスイッチとは、OSのスケジューラがCPUで実行中のプロセス（またはスレッド）を切り替える際に、現在の実行状態（コンテキスト）を保存し、次のプロセスの実行状態を復元する処理のことです。
現代のコンピュータでは単一のCPUコアが実際には1度に1つのプロセスしか実行できませんが、コンテキストスイッチを高速に繰り返すことで、ユーザーには複数のプロセスが同時に動作しているように見えます。
「コンテキスト（context）」とはこの場合「プロセスの実行状態の全情報」を指し、CPUレジスタ（汎用レジスタ・プログラムカウンタ・スタックポインタ）・メモリマップ・プロセスの優先度・I/O状態などが含まれます。
コンテキストスイッチはOSのカーネルが管理する低レベルの処理であり、マルチタスク・マルチプロセス・マルチスレッドの基盤となる仕組みなのです。
コンテキストスイッチの詳細な処理手順
コンテキストスイッチが発生してから完了するまでの詳細な手順を順番に見ていきましょう。
まず、コンテキストスイッチのトリガーとなるイベントが発生します（タイマー割り込み・システムコール・I/O待ち・プロセスの自発的な譲歩など）。
次に、現在実行中のプロセス（プロセスAとします）のCPUレジスタの内容・プログラムカウンタ・スタックポインタなどすべてのコンテキスト情報がプロセス管理ブロック（PCB：Process Control Block）に保存されます。
続いて、OSのスケジューラが次に実行すべきプロセス（プロセスB）を選択します（スケジューリングアルゴリズムに従って決定）。
【コンテキストスイッチの処理ステップ】
①割り込み・システムコール発生（CPUがカーネルモードに切替）
②現在プロセス（A）のコンテキストをPCBに保存
③スケジューラが次プロセス（B）を選択
④プロセスBのコンテキストをPCBからCPUに復元
⑤CPUがユーザーモードに戻り、プロセスBが実行再開
プロセスBのコンテキスト（PCBに保存された状態）がCPUのレジスタに復元され、プロセスBが前回停止した箇所から実行を再開します。
このプロセスは1秒間に数百〜数千回繰り返されており、CPUが高速でプロセスを切り替えることで複数のプロセスが並列動作しているように見えるわけなのです。
プロセスコンテキストとスレッドコンテキストの違い
コンテキストスイッチはプロセス間だけでなく、スレッド間でも発生しますが、両者には重要な違いがあります。
プロセス間のコンテキストスイッチでは、アドレス空間（仮想メモリマッピング）の切り替えも必要になるため、TLB（Translation Lookaside Buffer）のフラッシュ・ページテーブルの切り替えなど、スレッド間の切り替えよりも多くのオーバーヘッドが生じます。
同じプロセス内のスレッド間コンテキストスイッチでは、アドレス空間を共有しているためTLBフラッシュが不要であり、一般的にプロセス間切り替えより高速に処理できます。
これがマルチプロセス設計よりもマルチスレッド設計の方がコンテキストスイッチのオーバーヘッドが小さいといわれる理由のひとつであり、パフォーマンスを重視するシステム設計においてスレッドが好まれる根拠となっているでしょう。
コンテキストスイッチのオーバーヘッドと最適化
続いては、コンテキストスイッチのオーバーヘッドとその最適化手法について確認していきます。
コンテキストスイッチは必要不可欠な処理ですが、過剰に発生するとシステム全体のパフォーマンスに悪影響を及ぼします。
コンテキストスイッチのオーバーヘッドの内訳
コンテキストスイッチにかかるオーバーヘッドは複数の要素から構成されています。
直接コスト（Direct Cost）には、レジスタの保存・復元にかかる時間・カーネルの実行時間・PCBの読み書き時間などが含まれます。
間接コスト（Indirect Cost）には、TLBのキャッシュミス（アドレス空間切り替え後のTLBウォームアップ時間）・CPUキャッシュ（L1/L2/L3）の汚染（異なるプロセスのデータがキャッシュを上書きし、元のプロセスのキャッシュヒット率が低下）などが含まれ、直接コストを上回ることもあります。
現代のCPUでは1回のコンテキストスイッチに数マイクロ秒〜数十マイクロ秒かかるとされており、1秒間に数百回スイッチが発生するシステムでは無視できないオーバーヘッドが蓄積します。
`vmstat`（Linux）や`perfmon`（Windows）などのツールでコンテキストスイッチの発生頻度を監視し、異常に多い場合はシステムの設計・チューニングを見直すことが重要なのです。
コンテキストスイッチを最小化する設計と手法
コンテキストスイッチのオーバーヘッドを最小化するための設計手法と最適化アプローチを理解しておくことが、高性能システム開発において重要です。
スレッドプールの活用では、タスクごとに新しいスレッドを生成・破棄する代わりに、あらかじめ作成したスレッドのプールを再利用することで、スレッド生成コストとコンテキストスイッチの頻度を削減できます。
非同期I/O・イベントドリブン設計では、I/O待ちによるブロッキングを回避してスレッドを継続実行することでコンテキストスイッチを削減します（Node.js・nginx・Go goroutinesなどがこのアプローチを採用しています）。
CPU親和性（CPU Affinity）の設定では、特定のプロセス・スレッドを特定のCPUコアに固定することで、コアをまたいだコンテキストスイッチとキャッシュミスを防ぐことができます。
| 最適化手法 | 効果 | 適用シーン |
|---|---|---|
| スレッドプール | スレッド生成コスト・切り替え頻度の削減 | Webサーバー・バッチ処理 |
| 非同期I/O | ブロッキングによる切り替え削減 | I/O多発システム |
| CPU Affinity | コアをまたいだ切り替えの防止 | リアルタイム処理 |
| コルーチン | ユーザー空間での軽量な切り替え | Go・Python asyncio |
プログラマーが意識すべきコンテキストスイッチの影響
アプリケーション開発者の視点から、コンテキストスイッチを意識したプログラミングのポイントを押さえておきましょう。
ロック競合（Lock Contention）はコンテキストスイッチの大きな原因のひとつであり、複数スレッドが同じロックを奪い合う状況ではコンテキストスイッチが頻発し、スループットが大幅に低下します。
ロックフリーデータ構造（CAS命令を使ったアトミック操作）やロック粒度の最適化（ロックを小さくして競合時間を短縮）を採用することで、ロック競合に起因するコンテキストスイッチを削減できます。
Goのgoroutine・Pythonのasyncio・JavaのVirtual Thread（Java 21以降）など、近年の言語・ランタイムはユーザー空間で軽量なコンテキスト切り替えを実現するグリーンスレッド・コルーチンを提供しており、OSレベルのコンテキストスイッチコストを大幅に削減できるのです。
まとめ
本記事では、コンテキストスイッチの仕組み・処理手順・オーバーヘッド・最適化手法について解説しました。
コンテキストスイッチはOSが複数のプロセス・スレッドをCPU上で切り替える際に実行状態を保存・復元する根本的なメカニズムであり、現代のマルチタスク処理を支える基盤技術です。
オーバーヘッドを正しく理解し、スレッドプール・非同期I/O・CPU Affinity・コルーチンなどの最適化手法を適切に活用することで、高性能なシステム設計が実現できるでしょう。
