カーネルとは｜OSの中核の役割・仕組みをstraceと/procの実物で

アプリ（ブラウザ・エディタ・Python のスクリプト）は、ファイルを読むときもネットワークに送るときも、自分では何もせず、カーネルに「読んで」「送って」と頼みます。カーネルだけがハードウェアに触れられる、という分け方が OS の土台です。

flowchart TD
    subgraph U[ユーザー空間]
        A[アプリ<br>cat・Python・ブラウザ]
        L[ライブラリ glibc]
    end
    subgraph K[カーネル空間]
        S[システムコールの窓口<br>openat・read・write]
        C[プロセス・メモリ・ファイル<br>デバイス・ネットワークの管理]
    end
    H[ハードウェア<br>CPU・メモリ・ディスク・NIC]
    A --> L --> S --> C --> H

よく調べられることの答えを先にまとめます。

確認環境：Linux カーネル 6.18.44（uname -r は 6.18.44-fc-v185、x86_64・2 CPU・メモリ 8GB）の上で動く Ubuntu 24.04.5 LTS のコンテナ的な作業環境です。/proc/cmdline に --firecracker-init・nomodule・panic=1 があり、仮想マシン（ハイパーバイザー上の microVM）で、ローダブルモジュールを持たないカーネルです。そのため /proc/modules と /lib/modules が無く、lsmod も入っていません。ディスクとネットワークは virtio（virtio_blk・virtio_net）で、一般的な PC のような SATA・NVMe・Wi-Fi のドライバーは見えません。この違いは、該当する節にそのまま書いています。観察は読み取りだけ（uname・/proc・/sys の閲覧・strace 6.8・ps／free（procps-ng 4.0.4）・mount（util-linux 2.39.3）・ip（iproute2 6.1.0）・dmesg）で、カーネルの設定・モジュール・sysctl は変えていません。システムコールの実測は Python 3.13.18 で行いました。カーネルの版と LTS は kernel.org、WSL2 は Microsoft Learn、Windows のユーザーモード／カーネルモードは Microsoft Learn、XNU は Apple の Kernel Programming Guide、sysctl の意味は kernel.org の admin-guide で確かめました。図は mermaid 11.16.0 で描画を確かめています（確認日 2026年10月29日）。

カーネルとは（OSの中核を一言で）

この節では、カーネルという言葉の意味と、OS・シェル・ディストリビューションとの関係が分かります。

カーネル（kernel）は、OS の中でハードウェアに直接触れる唯一の部分です。 名前は「果実の核・種」から来ていて、OS の芯という意味で使われます。電源を入れると、ブートローダーがカーネルをメモリに読み込み、カーネルが CPU・メモリ・ディスク・ネットワークカードを初期化し、最初のプロセス（init・systemd など）を起動します。それ以降、画面に見えるものはすべて、カーネルの上で動くプロセスです。

「OS」と「カーネル」は、日常の会話では同じように使われますが、正確には次の関係です。

Red Hat の解説は、カーネルを「コンピュータのハードウェアとプロセスの間のコアインタフェース」と定義し、「責任ある重役（ハードウェア）の多忙な個人秘書」にたとえています。要求を取り次ぎ、誰が何をいつ使うかを覚えておき、順番を決める役です。

カーネルの5つの役割（1コマンドずつ実演）

この節では、カーネルが担う5つの管理を、それぞれ1つのコマンドの出力で確かめられます。

カーネルの仕事は、プロセス・メモリ・ファイル・デバイス・ネットワークの5つの管理と、それらをアプリに貸し出す窓口（システムコール）です。 ここで使うコマンドは、どれもカーネルが持っている情報を読んで表示しているだけです。

1. プロセス管理：ps

$ ps -eo pid,ppid,stat,pri,ni,rss,comm --sort=pid | head -8
  PID  PPID STAT PRI  NI   RSS COMMAND
    1     0 SLl   19   0  6324 process_api
    2     0 S     19   0     0 kthreadd
    3     2 S     19   0     0 pool_workqueue_release
    4     2 I<   39 -20     0 kworker/R-rcu_gp
    5     2 I<   39 -20     0 kworker/R-sync_wq
    6     2 I<   39 -20     0 kworker/R-kvfree_rcu_reclaim
    7     2 I<   39 -20     0 kworker/R-slub_flushwq
$ ps -e --no-headers | wc -l
73

PID 1 は最初のユーザープロセス（一般的な Linux では systemd。この環境では process_api という独自の init）です。PID 2 の kthreadd とその子（kworker/…）は、カーネルが自分の仕事のために動かしているスレッドで、RSS（使っているユーザー空間のメモリ）が 0 です。 STAT の S は待機中、I はアイドルのカーネルスレッド、PRI と NI は優先度で、カーネルのスケジューラーがこれを見て CPU を割り当てます。プロセスの見方と止め方は、関連記事「Linuxプロセス確認と停止｜ps・top・kill逆引きコマンド一覧」で扱っています。

2. メモリ管理：free と /proc/meminfo

$ free -m
               total        used        free      shared  buff/cache   available
Mem:            8027        1083        6567          15         726        6944
Swap:              0           0           0
$ grep -E 'MemTotal|MemAvailable|^Cached|SwapTotal|Dirty' /proc/meminfo
MemTotal:        8220248 kB
MemAvailable:    7110944 kB
Cached:           677736 kB
SwapTotal:             0 kB
Dirty:              1884 kB

free は /proc/meminfo を読んで表にしているだけです。buff/cache の 726MB は、カーネルが「一度読んだファイルの中身」を空いたメモリに置いているもので、アプリがメモリを欲しがれば手放します。 Dirty はディスクに書き戻していない変更分で、これもカーネルがタイミングを決めて書きます。free の各欄の読み方は、関連記事「Linuxメモリ・ディスク確認｜free・df・du・vmstat・iostat見方」で扱っています。

3. ファイルシステム：mount

$ mount | head -6
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=4098912k,nr_inodes=1024728,mode=755)
tmpfs on /dev/shm type tmpfs (rw,relatime,size=8220248k)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
/dev/vda on / type ext4 (rw,relatime,discard,no_prefetch_block_bitmaps,resv_strict,resuid=65534,resgid=65534)
$ mount | wc -l
28
$ grep -c . /proc/filesystems
32

ルート / は /dev/vda（virtio のディスク）の ext4 で、/proc・/sys・/dev/shm はディスクを持たない「カーネルの中の情報を見せる」ファイルシステムです。アプリは、ext4 でも tmpfs でも proc でも、同じ open・read で読めます。 違いを吸収しているのがカーネルの VFS（仮想ファイルシステム）の層です。/proc/filesystems には、このカーネルが扱える32種類（ext4・xfs・squashfs・overlay・fuse など）が並んでいました。

4. デバイス管理：/sys/module・/proc/devices・/proc/interrupts

$ readlink /sys/class/net/eth0/device/driver
../../../../bus/virtio/drivers/virtio_net
$ readlink /sys/block/vda/device/driver
../../../../bus/virtio/drivers/virtio_blk
$ ls /sys/bus/virtio/drivers
nvproxy  virtio_balloon  virtio_blk  virtio_console  virtio_mem  virtio_net  virtio_pmem  virtio_rng  virtio_rproc_serial  vmw_vsock_virtio_transport
$ head -4 /proc/interrupts
           CPU0       CPU1
 24:          1          0  IO-APIC   5-edge      ACPI:Ged
 25:          0          1  IO-APIC   6-edge      ACPI:Ged
 26:          4          0  IO-APIC   4-edge      ttyS0
$ grep virtio1-req /proc/interrupts
 37:          0     604452 PCI-MSIX-0000:00:02.0   1-edge      virtio1-req.0

ネットワークカード eth0 は virtio_net、ディスク vda は virtio_blk というドライバーが動かしています。/proc/interrupts は「ハードウェアがカーネルを呼んだ回数」で、ディスクの要求（virtio1-req.0）が 604,452 回、CPU1 に届いていました。 割り込みを受け取り、ドライバーを呼び、待っていたプロセスを起こすのもカーネルの仕事です。一般的な PC では、ここに nvme・ahci・iwlwifi・i915 のような名前が並びます。

5. ネットワーク：ip

$ ip -br a
lo               UNKNOWN        127.0.0.1/8
ifb0             DOWN
ifb1             DOWN
eth0             UP             192.0.2.2/24
$ ip r
default via 192.0.2.1 dev eth0
192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.2
$ cat /proc/sys/net/ipv4/ip_forward
0

IP アドレス・経路表・転送の可否は、すべてカーネルが持っている状態です。proto kernel の行は、アドレスを付けたときにカーネルが自動で作った経路です。TCP の再送・輻輳制御（この環境は tcp_cubic）・ポートの管理もカーネルの中にあり、アプリは socket・connect・send を頼むだけです。 ip・ss の使い方は、関連記事「Linuxネットワークコマンド一覧｜ip/ss/ncで障害切り分け」で扱っています。

ユーザー空間とカーネル空間（ユーザーモード・カーネルモード）

この節では、「アプリはハードウェアに触れない」という決まりが、どの仕組みで守られているかが分かります。

CPU には「特権モード（カーネルモード）」と「非特権モード（ユーザーモード）」があり、カーネルだけが特権モードで動きます。 アプリはユーザーモードで動くため、ハードウェアのレジスタに触ったり、他のプロセスのメモリを読んだりする命令を実行すると、CPU がそれを止めてカーネルに知らせます。この分け方があるので、アプリ1つが落ちても OS 全体は落ちません。

Microsoft Learn は Windows について同じ構造を説明しています。ユーザーモードのプロセスは「プライベート仮想アドレス空間」を持ち「アプリケーションがクラッシュしても、他のアプリケーションやオペレーティング システムには影響しません」。一方「カーネル モードで実行されるすべてのコードは、1 つの仮想アドレス空間を共有」し「カーネル モード ドライバーがクラッシュすると、オペレーティング システム全体がクラッシュします」。Linux も Windows も、この点は同じです。

プロセスの仮想アドレス空間は /proc/<pid>/maps で見えます。bash 自身の例です。

$ head -5 /proc/$$/maps
55becb4e4000-55becb514000 r--p 00000000 fe:00 322639   /usr/bin/bash
55becb514000-55becb603000 r-xp 00030000 fe:00 322639   /usr/bin/bash
55becb603000-55becb638000 r--p 0011f000 fe:00 322639   /usr/bin/bash
55becb638000-55becb63c000 r--p 00154000 fe:00 322639   /usr/bin/bash
55becb63c000-55becb645000 rw-p 00158000 fe:00 322639   /usr/bin/bash
$ grep -E 'VmSize|VmRSS|Threads|Cpus_allowed_list' /proc/$$/status
VmSize:     4628 kB
VmRSS:      3540 kB
Threads:    1
Cpus_allowed_list:  0-1

r-xp は「読める・実行できる・書けない」という、カーネルが付けたメモリの保護です。この領域に書き込もうとすると、カーネルが SIGSEGV（Segmentation fault）を送ってプロセスを止めます。

システムコールとは（straceでcatのopen→read→writeを見る）

この節では、アプリがカーネルに仕事を頼む「システムコール」が、実際にどう並んでいるかが strace の出力で分かります。

システムコール（syscall）は、ユーザー空間からカーネルに仕事を頼む唯一の正規の窓口です。 ファイルを開くのは openat、読むのは read、書くのは write、プロセスを作るのは clone、終わるのは exit_group という具合に、1つ1つに名前と番号があります。strace は、プロセスが呼んだシステムコールを1行ずつ記録する道具です。13バイトのファイルを cat で表示したときの、後半の部分です。

$ printf 'hello kernel\n' > hello.txt
$ strace -e trace=openat,read,write,close cat hello.txt
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
close(3)                                = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\243\2\0\0\0\0\0"..., 832) = 832
close(3)                                = 0
openat(AT_FDCWD, "hello.txt", O_RDONLY) = 3
read(3, "hello kernel\n", 131072)       = 13
write(1, "hello kernel\n", 13)          = 13
read(3, "", 131072)                     = 0
close(3)                                = 0
close(1)                                = 0
close(2)                                = 0
+++ exited with 0 +++

この cat は、全部で 43 回のシステムコールを呼んでいました（strace -c の集計）。本来の仕事は openat・read・write・close だけで、残りはプログラムの起動（libc の読み込み・メモリの確保・乱数の取得）です。

$ strace -c cat hello.txt > /dev/null
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
  0.00    0.000000           0         8           mmap
  0.00    0.000000           0         5           close
  0.00    0.000000           0         4           fstat
  0.00    0.000000           0         4           brk
  0.00    0.000000           0         3           read
  0.00    0.000000           0         3           openat
  0.00    0.000000           0         3           mprotect
  0.00    0.000000           0         1           write
  0.00    0.000000           0         1         1 access
  0.00    0.000000           0         1           execve
  …
100.00    0.000000           0        43         1 total

失敗もシステムコールの戻り値で分かる

無いファイルを cat すると、カーネルが openat の戻り値で ENOENT を返し、cat がそれを「No such file or directory」と表示します。エラーメッセージの文言は、カーネルが返した番号（errno）をアプリが文字に直したものです。

$ strace -e trace=openat cat nonexist.txt
openat(AT_FDCWD, "nonexist.txt", O_RDONLY) = -1 ENOENT (No such file or directory)
cat: nonexist.txt: No such file or directory
+++ exited with 1 +++

プロセスを作るのも、Python が書くのもカーネル

bash が ls を動かすときは clone（複製）→ execve（別のプログラムに差し替え）→ wait4（終わるのを待つ）の順で、Python の open().write() も最後は同じ openat・write です。

$ strace -f -e trace=clone,execve,wait4 bash -c 'ls / >/dev/null'
23439 execve("/usr/bin/bash", ["bash", "-c", "ls / >/dev/null"], …) = 0
23439 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, …) = 23440
23439 wait4(-1,  <unfinished ...>
23440 execve("/usr/bin/ls", ["ls", "/"], …) = 0
23440 +++ exited with 0 +++
23439 <... wait4 resumed>[{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 23440
23439 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=23440, …} ---

$ strace -e trace=openat,write,close python3 -c "f=open('out.txt','w'); f.write('カーネル経由で書く\n'); f.close()" 2>&1 | grep -A2 out.txt
openat(AT_FDCWD, "out.txt", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 3
write(3, "\343\202\253\343\203\274\343\203\215\343\203\253\347\265\214\347\224\261\343\201\247\346\233\270\343\201\217\n", 28) = 28
close(3)                                = 0

日本語9文字＋改行が 28 バイトで書かれています。どの言語で書いても、ファイルに触る瞬間は必ずカーネルのシステムコールを通ります。

システムコール1回のコストを実測した

ユーザーモードからカーネルモードへの切り替えには時間がかかります。Python で「何もしない関数」と「os.getpid()（カーネルに自分の PID を聞く）」を 100万回ずつ呼んで比べました。

この環境（仮想マシン・Intel Xeon 2.10GHz）では、最も軽いシステムコールでも Python の関数呼び出しの約4.5倍かかりました。「ファイルを1バイトずつ write すると遅い」「ループの中で os.stat を呼ぶと遅い」のは、この切り替えの回数が増えるためです。 ライブラリがバッファリング（まとめて1回の write）をするのは、カーネルへの往復を減らすためです。

カーネルの確認方法（uname -r・/proc/version・/proc/sys/kernel）

この節では、今動いているカーネルの版・種類・ビルド情報を確かめるコマンドと、出力の読み方が分かります。

カーネルの版は uname -r で分かります。 同じ情報が /proc/version・/proc/sys/kernel/osrelease・dmesg の先頭にもあります。

$ uname -r
6.18.44-fc-v185
$ uname -a
Linux vm 6.18.44-fc-v185 #1 SMP PREEMPT_DYNAMIC @0 x86_64 x86_64 x86_64 GNU/Linux
$ cat /proc/version
Linux version 6.18.44-fc-v185 (builder@sandboxing) (gcc (GCC) 15.3.0, GNU ld (GNU Binutils) 2.46) #1 SMP PREEMPT_DYNAMIC @0
$ cat /proc/sys/kernel/ostype /proc/sys/kernel/osrelease /proc/sys/kernel/version
Linux
6.18.44-fc-v185
#1 SMP PREEMPT_DYNAMIC @0
$ sysctl kernel.osrelease
kernel.osrelease = 6.18.44-fc-v185
$ cat /etc/os-release | head -2
PRETTY_NAME="Ubuntu 24.04.5 LTS"
NAME="Ubuntu"

uname -r（カーネル）と /etc/os-release（配布物）は別物で、Ubuntu 24.04 の上で 6.18 のカーネルが動く、という組み合わせがあり得ます。この使い分けは、関連記事「LinuxのOS・バージョン確認コマンド｜os-releaseとunameの違い」で扱っています。

起動時のパラメーターとログ

$ cat /proc/cmdline
mitigations=auto,no_guest_host,no_guest_guest deferred_init=lazy dhash_entries=131072 ihash_entries=65536 console=ttyS0 reboot=k panic=1 nomodule random.trust_cpu=1 ipv6.disable=1 swiotlb=noforce psi=1 rdinit=/process_api -- --firecracker-init …
$ dmesg | head -2
[    0.000000] Linux version 6.18.44-fc-v185 (builder@sandboxing) (gcc (GCC) 15.3.0, GNU ld (GNU Binutils) 2.46) #1 SMP PREEMPT_DYNAMIC @0
[    0.000000] Command line: deferred_init=lazy … console=ttyS0 reboot=k panic=1 nomodule random.trust_cpu=1 ipv6.disable=1 …
$ dmesg | grep -m3 virtio-pci
[    1.059440] virtio-pci 0000:00:01.0: enabling device (0000 -> 0002)
[    1.064194] virtio-pci 0000:00:02.0: enabling device (0000 -> 0002)
[    1.068884] virtio-pci 0000:00:03.0: enabling device (0000 -> 0002)

/proc/cmdline は、ブートローダーがカーネルに渡した起動時の指定です。この環境では nomodule（モジュールを読み込まない）・panic=1（パニックしたら1秒で再起動）・ipv6.disable=1・--firecracker-init が並んでいて、「仮想マシンの中の、最小構成のカーネル」であることがここから読み取れます。 dmesg はカーネルのログで、起動直後にどのデバイスを見つけたかが時刻付きで残っています。

/procと/sysの読み方（カーネルの中を見る仮想ファイル）

この節では、/proc と /sys が何なのか、なぜサイズが 0 なのか、どこを見ると何が分かるかが分かります。

/proc と /sys はディスク上に実体が無く、読んだ瞬間にカーネルが中身を作って返す仮想のファイルです。 ls -l でサイズが 0 なのはそのためで、cat すると中身が出ます。

$ ls -l /proc/version /proc/meminfo /sys/class/net/eth0/mtu
-r--r--r-- 1 root root    0 Oct 29 21:43 /proc/meminfo
-r--r--r-- 1 root root    0 Oct 29 21:43 /proc/version
-rw-r--r-- 1 root root 4096 Oct 29 22:34 /sys/class/net/eth0/mtu
$ cat /sys/class/net/eth0/mtu /sys/class/net/eth0/address /sys/class/net/eth0/operstate
1400
02:fc:00:00:00:01
up
$ ls /proc/self | tr '\n' ' '
arch_status attr autogroup auxv cgroup clear_refs cmdline comm coredump_filter cpuset cwd environ exe fd fdinfo gid_map io … maps mem mountinfo mounts net ns oom_score root sched stat statm status syscall task …
$ cat /proc/self/cmdline | tr '\0' ' '
cat /proc/self/cmdline
$ ls -l /proc/self/fd/
lr-x------ 1 root root 64 Oct 29 22:36 0 -> /dev/null
l-wx------ 1 root root 64 Oct 29 22:36 1 -> /path/to/output
l-wx------ 1 root root 64 Oct 29 22:36 2 -> /path/to/output
lr-x------ 1 root root 64 Oct 29 22:36 3 -> /proc/25629/fd

$ cat /proc/sys/kernel/panic /proc/sys/kernel/panic_on_oops /proc/sys/vm/swappiness /proc/sys/fs/file-max /proc/sys/kernel/pid_max
1
0
60
819169
32768
$ cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
$ cat /proc/self/cgroup | tail -2
1:cpu:/
0::/

/proc/sys/kernel/panic の 1 は、起動パラメーターの panic=1 がそのまま反映された値です。sysctl -a で表示される項目は、すべて /proc/sys/ 以下のファイルです。この記事では読んでいるだけですが、/proc/sys と /sys の多くは root が書き込むと、再起動なしでカーネルの動きが変わります（ip_forward を 1 にするとルーターになる、など）。

カーネルモジュールとドライバー（lsmod・/sys/module）

この節では、カーネルの機能を後から足す「モジュール」の仕組みと、この環境で lsmod が無い理由が分かります。

Linux のドライバーやファイルシステムの多くは、カーネル本体に組み込む（built-in）か、必要なときに読み込むモジュール（.ko ファイル）にするかを、ビルド時に選べます。 一般的なディストリビューションのカーネルは大半をモジュールにしていて、lsmod（/proc/modules の整形）で読み込み済みの一覧が見え、modprobe で足したり外したりできます。

$ lsmod
/bin/bash: line 1: lsmod: command not found
$ cat /proc/modules
cat: /proc/modules: No such file or directory
$ ls /lib/modules
ls: cannot access '/lib/modules': No such file or directory
$ grep -o nomodule /proc/cmdline
nomodule
$ ls /sys/module | wc -l
75
$ ls /sys/module | tr '\n' ' '
8250 acpi amd_uncore blk_cgroup block bridge clocksource cpufreq cpuidle cpuidle_haltpoll cryptomgr dns_resolver eeprom_93cx6 erofs firmware_class fscrypto fuse haltpoll hid intel_idle ip_set ipv6 jbd2 kernel keyboard kvm kvm_pvm libnvdimm loop memory_hotplug nf_conntrack … overlay page_alloc page_reporting pcie_aspm pnp printk processor pstore random rcupdate rcutree rng_core sch_htb secretmem slab_common spurious srcutree tcp_cubic virtio_blk virtio_mem virtio_net virtio_pci virtio_pci_modern_dev vmw_vsock_virtio_transport vsock vt vxlan watchdog workqueue x86_pkg_temp_thermal xt_recent xz_dec zswap
$ cat /sys/module/kernel/parameters/panic /sys/module/loop/parameters/max_loop
1
8

モジュールはカーネル空間で動くため、カーネル本体と同じ権限を持ちます。ドライバーの不具合でシステム全体が止まるのは、この構造のためです。

モノリシックカーネルとマイクロカーネルの違い

この節では、カーネルの設計の2つの方針と、Linux がどちらで、何を取り入れているかが分かります。

モノリシックカーネルは、ファイルシステム・ドライバー・ネットワークをすべてカーネル空間の1つのプログラムに入れる設計、マイクロカーネルは、カーネルにはスケジューリング・メモリ・プロセス間通信だけを残し、それ以外をユーザー空間のサーバーとして動かす設計です。 Linux はモノリシックで、そこにモジュールの仕組みを足して「必要な部品だけ後から入れる」柔軟さを持たせています。

「速さを取るか、分離を取るか」の選択です。Linux は速さを取り、ドライバーをモジュール化して開発のしやすさを補っています。Apple の文書は、XNU を Mach（マイクロカーネル）・BSD・I/O Kit の組み合わせと説明していて、分類としてはハイブリッドに当たります。

Linux・Windows NT・XNU（macOS）のカーネル比較

この節では、主要な OS のカーネルの名前・設計・確認方法が一覧で分かります。

Microsoft Learn は、Windows のアプリがユーザーモード、「コア オペレーティング システム コンポーネントはカーネル モードで機能」し、「多くのドライバーはカーネル モードで動作しますが、ユーザー モードで機能するドライバーもあります」と説明しています。Apple の Kernel Programming Guide は「OS X のカーネル環境は Mach カーネル、BSD、I/O Kit、ファイルシステム、ネットワークのコンポーネントを含み、これらをまとめてカーネルと呼ぶことが多い」と書いています。

カーネルパニックとは（oopsとの違い・panic=1の意味）

この節では、「カーネルパニック」という言葉の意味と、それが起きたときに何が決まっているかが分かります。

カーネルパニックは、カーネル自身が「これ以上安全に続けられない」と判断して停止することです。 アプリが落ちるのとは違い、カーネルが止まるとすべてのプロセスが止まり、画面にはログが残るか、設定によっては自動で再起動します。原因は、ドライバーの不具合、ハードウェアの故障（メモリ・ディスク）、ルートファイルシステムが見つからない（VFS: Unable to mount root fs）、カーネルの更新の失敗、などです。

kernel.org の admin-guide は /proc/sys/kernel/panic について「0 なら無限に待ち続ける、負なら即座に再起動、正ならその秒数の後に再起動」と説明しています。サーバーや仮想マシンで panic=1 や panic=10 を指定するのは、人が画面を見に行けないので自動で立ち上がらせるためです。デスクトップでは 0 のまま、画面に残ったメッセージ（Kernel panic - not syncing: …）を読んで原因を探します。

• 1直前に変えたものを戻すカーネルの更新・ドライバーの追加・ハードウェアの増設の直後なら、ブートメニューで前の版のカーネルを選んで起動する
• 2メッセージの1行目を記録するKernel panic - not syncing: の後ろに理由がある。写真でもよい
• 3再起動後に dmesg・journalctl -k -b -1 を見る前回起動時のカーネルログが残っていれば、oops のスタックトレースが読める
• 4繰り返すならハードウェアを疑うメモリテスト・ディスクの SMART。仮想マシンならホスト側のログ

Linuxカーネルの更新とLTS（kernel.orgの版の読み方）

この節では、Linux カーネルの版がどう付き、どれがどのくらい保守されるかが、kernel.org の公開情報で分かります。

Linux カーネルは、Linus Torvalds が管理する mainline が約9〜10週ごとに新しい版を出し、その後は stable・longterm として修正だけが続きます。 kernel.org の 2026年10月29日時点の表です。

この環境の 6.18.44 は longterm の 6.18 系で、kernel.org の最新は 6.18.59 です。第3の数字（パッチ版）が上がっても機能は変わらず、修正だけが入ります。 一方、Ubuntu や RHEL のようなディストリビューションは、kernel.org の版をそのまま配るのではなく、自分たちで修正を選んで当てた独自の版（6.8.0-xx-generic のような名前）を配ります。そのため「配布物のカーネルが kernel.org の表で保守終了になっている版でも、配布元が保守している」ことがあります。

1. 1配布物の更新で入れる（多くの人はこれ）apt・dnf でカーネルのパッケージが更新され、再起動で切り替わる。前の版は残るので戻せる
2. 2配布物が用意する新しめの系列を選ぶUbuntu の HWE カーネル、RHEL の kernel-ml など。新しいハードウェアを使いたいとき
3. 3kernel.org のソースから自分でビルドする組み込み・検証・特定の機能が要るとき。make menuconfig で組み込みかモジュールかを選ぶ
4. 4再起動せずに修正を当てる（ライブパッチ）Red Hat の解説にある「ライブパッチ適用中も Linux カーネルは動作し続ける」仕組み。止められないサーバー向け

WSL2・仮想マシン・コンテナとカーネルの関係

この節では、Windows の WSL2、仮想マシン、コンテナのそれぞれで「カーネルがどこにいるか」が分かります。

仮想マシンはカーネルを1つ丸ごと持ち、コンテナはホストのカーネルを借りて動きます。 この違いが、起動の速さ・分離の強さ・カーネルの版を選べるかどうかの差になります。

Microsoft Learn は WSL2 について、「WSL 2 の Linux カーネルは、kernel.org で使用可能なソースに基づいて、最新の安定したブランチから Microsoft によって構築されています」「カーネルは Windows 更新プログラムによって処理されます」「WSL 1 は WSL チームによって構築された変換レイヤーを使用していましたが、WSL 2 には、システム呼び出しの完全な互換性を備えた独自の Linux カーネルが含まれています」と説明しています。WSL1 はシステムコールを Windows の呼び出しに「翻訳」していたのに対し、WSL2 は本物の Linux カーネルが動いている、という違いです。WSL2 の環境の整え方は、関連記事「WSL2環境構築｜Ubuntu開発環境をコマンドだけで整える手順」で扱っています。

コンテナが「ホストのカーネルを共有したプロセス」であることを、namespace と cgroup で手作りして確かめた記事「コンテナとは？仮想マシンとの違い｜namespace・cgroupで手作りして理解」も、この記事の続きとして読めます。この環境の /proc/self/cgroup にも、メモリの cgroup にこの作業用の名前が付いていました。

よくあるエラー・つまずきと判断表

この節では、カーネルを調べるときに出る文言と、その意味・対処が分かります。

何を見るかの判断表

よくある質問

Q. カーネルとは何ですか？ A. OS の中核にあるプログラムで、CPU・メモリ・ファイル・デバイス・ネットワークを管理し、アプリからの要求をシステムコールで受け付けます。ハードウェアに直接触れるのはカーネルだけです。

Q. カーネルと OS は同じものですか？ A. 違います。OS はカーネルに加えて、シェル・ライブラリ・コマンド・画面・パッケージ管理を含んだ全体です。Ubuntu は OS（配布物）、その中で動く Linux 6.x がカーネルです。

Q. Linux カーネルとは何ですか？ A. Linus Torvalds が1991年に始め、今も mainline として管理されているカーネルです。kernel.org で配られているのはカーネルだけで、Ubuntu・RHEL・Android はそれに周りのソフトを足した配布物です。

Q. カーネルのバージョンはどう確認しますか？ A. uname -r です。cat /proc/version ならコンパイラーの情報も出ます。配布物の版は cat /etc/os-release で、別物です。

Q. システムコールとは何ですか？ A. アプリがカーネルに仕事を頼む窓口です。openat・read・write・clone などがあり、strace を付けて実行すると1行ずつ見えます。手元の cat は43回呼んでいました。

Q. カーネル空間とユーザー空間の違いは？ A. カーネル空間は CPU の特権モードで動き、ハードウェアに触れ、1つの空間を共有します。ユーザー空間はプロセスごとに分かれた仮想アドレス空間で、ハードウェアには触れません。アプリが落ちても他に影響しないのはこの分離のためです。

Q. カーネルパニックとは何ですか？ A. カーネル自身が続行できないと判断して止まることです。/proc/sys/kernel/panic の秒数で自動再起動するかが決まり、原因はドライバー・ハードウェア・ルートファイルシステムが見つからない、などです。

Q. モノリシックカーネルとマイクロカーネルの違いは？ A. モノリシックはドライバーやファイルシステムまで全部カーネル空間に入れる設計（Linux）、マイクロカーネルは最小限だけ残して他をユーザー空間に出す設計（MINIX 3・seL4）です。Windows NT と XNU はその中間（ハイブリッド）です。

Q. カーネルモジュールとは何ですか？ A. カーネルに後から読み込める部品（.ko ファイル）で、ドライバーやファイルシステムが多いです。lsmod で一覧、modprobe で追加します。この記事の環境は nomodule で全部組み込みでした。

Q. WSL2 のカーネルは本物の Linux ですか？ A. はい。Microsoft Learn によると、kernel.org のソースから Microsoft がビルドした Linux カーネルが軽量 VM の中で動き、Windows Update で更新されます。WSL1 は変換レイヤーで、カーネルは持っていませんでした。

Q. Docker のコンテナにカーネルはありますか？ A. ありません。コンテナはホストのカーネルを共有するプロセスです。コンテナの中で uname -r するとホストの版が出ます。

Q. カーネルを更新すると何が変わりますか？ A. パッチ版（第3の数字）の更新は修正だけで機能は変わりません。系列（6.12→6.18 など）が上がると新しいハードウェアの対応や機能が入ります。配布物の更新なら前の版が残るので、問題があればブートメニューで戻せます。

まとめ

• カーネルは OS の中核で、プロセス・メモリ・ファイル・デバイス・ネットワークを管理し、システムコールでアプリの要求を受け付ける。ハードウェアに触れるのはカーネルだけ。
• strace で見ると、cat は openat→read→write→close をカーネルに頼んでいた。全部で43回、エラーは errno の番号で返る。システムコール1回は Python の関数呼び出しの約4.5倍（196ns）かかった。
• 版は uname -r、起動時の指定は /proc/cmdline、調整値は /proc/sys、デバイスは /sys。どれも読むとカーネルが中身を作る仮想ファイル。
• この環境は仮想マシン内の最小構成（nomodule・virtio）で lsmod も /proc/modules も無かった。一般的な PC では lsmod にドライバーが並ぶ。
• Linux はモノリシック＋モジュール、Windows NT と XNU はハイブリッド。longterm（LTS）は kernel.org で保守終了の予定が公開され、配布物は独自の版を保守する。WSL2 は本物の Linux カーネルを VM で動かし、コンテナはホストのカーネルを共有する。

参考・出典

確認日はいずれも 2026年10月29日です。

• The Linux Kernel Archives（mainline・stable・longterm の一覧）：https://www.kernel.org/
• The Linux Kernel Archives「Releases」（longterm の保守終了予定・各種別の定義）：https://www.kernel.org/category/releases.html
• The Linux Kernel documentation「Documentation for /proc/sys/kernel/」（panic・panic_on_oops・osrelease・dmesg_restrict）：https://www.kernel.org/doc/html/latest/admin-guide/sysctl/kernel.html
• Microsoft Learn「WSL 1 と WSL 2 の比較」：https://learn.microsoft.com/ja-jp/windows/wsl/compare-versions
• Microsoft Learn「ユーザー モードとカーネル モード」：https://learn.microsoft.com/ja-jp/windows-hardware/drivers/gettingstarted/user-mode-and-kernel-mode
• Apple Developer「Kernel Programming Guide: Kernel Architecture Overview」：https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/Architecture/Architecture.html
• Red Hat「Linux カーネルとは」：https://www.redhat.com/ja/topics/linux/what-is-the-linux-kernel
• strace「strace - linux syscall tracer」：https://strace.io/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。