Windows NTカーネルのアーキテクチャ

NTカーネルは「層」でできている

Windows NT 系（現在の Windows 10/11 や Server もこの系譜）のカーネルは、責務ごとにきれいに層分けされた設計が特徴です。Linux のようなモノリシックでもなく純粋なマイクロカーネルでもない、ハイブリッドカーネルに分類されます（位置づけは マイクロカーネルとモノリシックカーネルの設計比較 を参照）。すべての層がカーネルモードの単一アドレス空間で動くため境界越えは関数呼び出しで速く、一方で内部はマイクロカーネル的に役割が分離されています。

カーネルモードの中身は、下から大きく3層です。

ポイントは Kernel 層と Executive 層を分けている ことです。Kernel 層は「機構（mechanism）」だけを持ちます——スレッドをどう切り替えるか、どうロックを取るか、といった最小の道具立てです。その上の Executive が「ポリシー（policy）」と高レベルの抽象（オブジェクト、プロセス、I/O）を構築します。この機構とポリシーの分離は、マイクロカーネルの発想をモノリシックな実装の中に取り込んだものと言えます。HAL がさらに下にいるため、Kernel/Executive はチップセットの違いを意識せずに書けます。

すべては「オブジェクト」：オブジェクトマネージャとハンドル

NT 設計の最大の個性が オブジェクトマネージャ です。プロセス、スレッド、ファイル、ミューテックス、セマフォ、イベント、レジストリキー、デバイス、トークン——これらカーネルが管理する資源がすべて統一的な「オブジェクト」として表現されます。各オブジェクトは共通のヘッダ（型情報・参照カウント・セキュリティ記述子・名前など）を持ち、\Device\、\BaseNamedObjects\ のような名前空間にツリー状に配置されます。

アプリがオブジェクトを使うときは、直接ポインタを触らず ハンドルを介します。ハンドルはプロセスごとのハンドルテーブルのインデックスで、テーブルのエントリがカーネル内オブジェクトへのポインタとアクセス権ビットを保持します。

ユーザー空間            カーネル空間
  handle (整数) ──→ [プロセスのハンドルテーブル]
                        │ entry: { オブジェクト*, 許可されたアクセス権 }
                        ↓
                  [オブジェクトヘッダ: 型/参照カウント/SD/名前]
                        ↓
                  [オブジェクト本体: FILE_OBJECT, ETHREAD, ...]

この構造はUnixのファイルディスクリプタとよく似ていますが（ファイルディスクリプタとオープンファイルテーブルの構造 を参照）、対象が file に限られない点が決定的に異なります。Unix では「ファイル以外」の資源（プロセスやセマフォ等）はそれぞれ別 API・別 ID で扱いますが、NT では1つのハンドル機構ですべてを扱うため、WaitForSingleObject のような汎用APIで「スレッドの終了待ち」も「ミューテックスの取得」も同じ形で書けます。

オブジェクトには**セキュリティ記述子（SD）**が結び付き、ハンドルを開く瞬間にアクセスチェックが走ります。要求したアクセス権が許可されると、その権限がハンドルエントリに刻まれ、以後の操作はその範囲に限定されます。「オープン時に一度チェックし、結果をハンドルに焼き付ける」というモデルは、Unix の open 時パーミッションチェックと発想が近い一方、ACL ベースで粒度が細かいのが特徴です。

I/OマネージャとIRP：ドライバを積み重ねる

I/O の中核は I/Oマネージャ と IRP（I/O Request Packet） です。アプリが ReadFile を呼ぶと、I/Oマネージャは要求を1つの IRP という構造体に詰め、対象デバイスのドライバスタックへ送り込みます。

NT のドライバは縦に積層されます。たとえばファイル読み取りなら、上から「ファイルシステムドライバ → ボリューム/パーティション → ディスククラスドライバ → ポート/ミニポート（実ハード）」のように複数層が並びます。IRP はこのスタックを上から下へ降りていき、各層がスタックロケーション（自分用の領域）を見て処理し、必要なら下位へ渡します。完了は逆向きに、下から上へ completion ルーチンを呼びながら戻ります。

ReadFile()
   │  I/Oマネージャが IRP を生成
   ↓
[ファイルシステムドライバ]   ← フィルタ（暗号化/AV等）も間に挟める
   ↓ IoCallDriver
[ボリューム / ディスククラス]
   ↓
[ポート / ミニポートドライバ] → 実デバイスへ
   ↑ IoCompleteRequest（completion を上へ伝播）

この設計の利点はフィルタドライバを任意の層の間に差し込めることです。暗号化、ウイルススキャン、ボリュームシャドウコピーなどが、既存ドライバを書き換えずにスタックへ挿入する形で実現されます。さらに IRP は本質的に非同期で、IoCallDriver 後に STATUS_PENDING を返して呼び出し元を解放し、完了時に I/O完了ポート（IOCP）等で通知する、という流れが自然に組めます。

Unixとの設計差：IPCと同期

NT と Unix 系は、IPC と同期の設計思想がはっきり分かれます。共通の入口は プロセス間通信（IPC） で押さえつつ、NT 固有の選択を整理します。

とりわけ重要なのが待機の統一性です。NT の Kernel 層には「ディスパッチャオブジェクト」という、待機可能（waitable）状態を持つオブジェクト群があります。スレッド、プロセス、イベント、ミューテックス、セマフォ、タイマがこれにあたり、いずれも「シグナル状態／非シグナル状態」を持ちます。WaitForMultipleObjects は型を問わずこれらをまとめて待てるため、「ファイルの読み取り完了とスレッドの終了とタイマ満了を同時に待つ」が1呼び出しで書けます。Unix では epoll が扱うのは主に fd であり、スレッド終了は wait/pthread_join、と窓口が分かれます（軽量ロックの内部は futexの内部動作 が参考になります）。

まとめ