したがって、「保存ボタンを押した＝その瞬間にSSDへ書き終えた」「ファイル＝連続した物理領域」という理解は正確ではありません。この記事では、テキストエディタでmemo.txtにAを追記して保存する一例を、パス探索から永続化まで途切れずに追います。

SSDの中に、フォルダ型の箱やmemo.txtという札がそのまま置かれているわけではありません。ファイルシステムが「名前から内容へたどれる対応関係」を作るから、同じファイルとして保存・再読込できます。

まず一枚で：名前を探してから、内容を永続化する

次の図は、/home/ken/Documents/memo.txtを開き、Aを追記して保存するときの基本モデルです。WindowsではC:\Users\Ken\Documents\memo.txtのように表記やAPIが変わりますが、「パスを探索して対象を開き、論理位置へ書き、キャッシュからストレージへ反映する」という骨格は共通しています。

図中の「inode」「ページキャッシュ」「ファイル記述子」はLinux／POSIX系で理解しやすい実装例です。Windowsにはファイルハンドルとシステムキャッシュ、NTFSにはMFT、APFSには独自のオブジェクトやツリーがあります。名称やデータ構造が違っても、名前空間・ファイル識別・論理データ・割り当て・I/Oを対応付ける必要がある、という一般原理を先に押さえてください。

memo.txtは「1つの物理的な箱」ではない

エクスプローラーやFinderに見えるmemo.txtは、利用者向けの論理的な見え方です。ローカルストレージ上の一般的なファイルシステムでは、少なくとも次の対応関係が必要になります。

ファイル名は、内容そのものではない

まず区別したいのは、名前とその名前が参照するファイルです。たとえばext4の公式資料では、ディレクトリエントリが名前をinode番号へ対応付けます。同じinodeを複数のディレクトリエントリから参照できるため、ハードリンクでは1つのファイルに複数の名前を付けられます。

これはext4の具体例ですが、「名前の管理」と「ファイルの管理情報」を分けて考える助けになります。名前を変更するrenameで、内容の全バイトを別の場所へコピーする必要がない場合があるのも、この分離があるからです。

inodeは一般名ではなく、実装例

LinuxのVFSでは、ディレクトリエントリがinodeオブジェクトを指し、inodeがファイルの種類、権限、時刻、サイズやデータへの操作を表します。しかし、すべてのOSやファイルシステムが同じ形のinodeを媒体へ保存するわけではありません。

NTFSではMFT（Master File Table）のエントリ内、またはMFTが記述する外部領域に、サイズ、時刻、権限、データ内容などが格納されます。APFSにも独自のファイルシステムオブジェクトとツリーがあります。この記事では、これらをまとめて「ファイルを識別し、その属性と内容への対応を持つ管理情報」と呼びます。

ファイルの連続性は「論理上」の話

アプリから見る通常のファイル内容は、先頭から順番に並ぶバイト列です。エディタが「末尾へAを追加する」ときは、SSDのセル番号ではなく、ファイル内のどのオフセットへ何バイト書くかを指定します。

ファイルシステムは、その論理範囲をストレージの割り当て単位へ変換します。複数の連続ブロックをまとめた対応をextentと呼ぶ実装もあり、ext4ではextent treeが論理ブロックとデータブロックを対応付けます。ただし、1つのファイルが媒体上の1本の連続領域に置かれる保証はありません。断片化、遅延割り当て、スパースファイル、コピーオンライトなどにより、論理的な並びと割り当ては異なります。

パスは「保存場所の文字列」ではなく、探索手順

/home/ken/Documents/memo.txtを1本の住所として一気に照合するのではありません。OSは起点を決め、区切られた名前を前から順に解決します。

1. /から探索を開始する。
2. ルートディレクトリでhomeという名前を探し、対応するディレクトリを得る。
3. その中でken、次にDocumentsを探す。
4. Documentsの中でmemo.txtを探し、対応するファイルの管理情報へ到達する。
5. 各段階で、存在、ディレクトリであるか、探索権限、シンボリックリンクやマウント境界などを必要に応じて処理する。

Linux VFSの資料では、パス名をディレクトリエントリキャッシュから探索し、不足があれば対象ファイルシステムのlookup処理を使ってinodeを読み込みます。キャッシュは探索を速くするための仕組みであり、「キャッシュにない＝ファイルがない」という意味ではありません。

絶対パスと相対パスの違いは「探索の起点」

絶対パスは、ルートやボリュームなど決められた起点から書きます。WindowsならC:\Users\Ken\Documents\memo.txt、Linuxなら/home/ken/Documents/memo.txtです。相対パスは、現在の作業ディレクトリなど別途定まった起点から書きます。いまDocumentsにいるなら、memo.txtだけでも探索できます。

つまり、相対パスは情報が欠けた絶対パスではなく、起点を別の状態から受け取る表現です。.は現在位置、..は親を表す場面があります。実際のディレクトリ移動や一覧表示は、コマンドプロンプト入門のcd、dir、mkdirにつながります。WindowsのPATHのようにパスを設定値として使う例は、Windowsの環境変数で確認できます。

open後は、パスではなくハンドルで操作する

パス探索が成功して権限も認められると、OSは開いた対象を表すハンドルをアプリへ返します。POSIXのopenではファイル記述子（file descriptor）を返し、WindowsのCreateFileではファイルハンドルを返します。名称や型は違いますが、どちらも以後の読み書きで「すでに開いた対象」を参照するための窓口です。

POSIXのopenは、ファイルとopen file descriptionを結び、その説明を参照するファイル記述子を作る操作として定義されています。Linux VFSでは、開いたファイルを表すカーネル内のstruct fileがプロセスのファイル記述子表へ登録されます。

ここが大きな転換点です。パスは「対象を見つけて開くまで」に使い、開いた後のwriteは通常、そのハンドルとファイル内オフセットを使います。毎回パスを最初から探索しているわけではありません。

この分離があるため、POSIX系では開いた後に名前が変更されても、既存のファイル記述子は同じ開いた対象を参照し続けます。また、最後の名前がunlinkされても、開いている記述子が残る間はファイルの資源が直ちに回収されないことがあります。Windowsでは共有モードや削除保留など規則が異なりますが、「名前」と「開いた対象」は同一概念ではありません。

アプリのAPI呼び出しが、どのように保護されたOS処理へ渡るかはシステムコールの解説で詳しく扱います。

保存ボタンから媒体まで：Aはどこを通るのか

「保存」はOSが定めた1個の万能操作ではなく、エディタが組み立てる処理です。ここでは理解の土台として、開いているmemo.txtへAを書き足す一般的なバッファ付きI/Oを追います。実際には、文字コード、エディタの内部バッファ、既存内容の再生成、一時ファイルなどにより呼び出し回数は変わります。

1. 画面上のAは、まずエディタのメモリにある

キー入力されたAは文字コードに従うバイト列としてエディタのメモリへ置かれ、画面表示も更新されます。この時点では、ファイルシステム上のmemo.txtが変わったとは限りません。エディタは「未保存」の状態を自分で管理しています。

2. エディタがハンドルを使って書き込みを依頼する

エディタは、開いたファイルのハンドル、書き込むバイト列、長さ、位置などをOSへ渡します。POSIXのwriteは、ファイル記述子に対応するファイルへ、現在のファイルオフセットなどに基づいて指定バイト数の書き込みを試みる操作です。

3. 通常のバッファ付き書き込みでは、まずメモリ上のキャッシュが変わる

Linuxの一般的なバッファ付きI/Oでは、ファイル内容をメモリ上のページキャッシュで読み書きします。Aを含むページが更新されると、そのページは「ストレージ上の内容より新しい」という意味でdirty（変更済み）になります。Windowsにもシステム管理のファイルキャッシュがあり、変更データを後でディスクへ書き出します。

この段階でwriteが成功を返すことがあります。これは重要な成功ですが、通常は「OSが書き込みを受け付け、後で処理できる状態になった」という意味であり、必ずしも不揮発性媒体への到達を意味しません。キャッシュが必要な理由と、バッファ・キャッシュの違いはバッファの解説で掘り下げています。

4. ファイルシステムが論理位置を割り当て先へ対応付ける

追記によってファイルが大きくなるなら、ファイルシステムは空き領域を割り当て、ファイルの論理オフセットをブロックやextentへ対応付けます。サイズや更新時刻などのメタデータも更新対象になります。ただし、ext4の遅延割り当てのように、dirtyデータを書き戻す時点まで具体的な配置決定を遅らせる実装もあります。

5. writebackがストレージI/Oを発行する

OSはdirtyなキャッシュをいつまでもメモリだけに置けないため、バックグラウンド処理、メモリ圧力、一定時間の経過、明示的な同期要求などを契機にwriteback（書き戻し）します。ファイルシステムが論理範囲を保存先へ対応付け、OSのI/O層とデバイスドライバを通してストレージへ要求を渡します。

その下では、要求キュー、DMA、割り込みやポーリング、ストレージ制御装置、機器内キャッシュ、媒体が関わります。この「要求を出して、完了を待ち、通知で再開する」流れはI/O（入出力）の解説につながります。

6. 永続化が必要なら、明示的な同期を要求する

電源断後も取得できる状態まで必要なアプリは、OSとファイルシステムへ永続化を要求します。POSIXにはfsync、WindowsにはFlushFileBuffersなどがあります。Linuxのfsyncは、変更済みのファイルデータと関連メタデータをストレージへ送り、機器が転送完了を報告するまで待ちます。

ただし、新しく作った名前やrenameした結果までクラッシュ後に残すには、Linuxでは対象ファイルだけでなく親ディレクトリの同期も必要になる場合があります。さらに保証の最終範囲は、OS、ファイルシステム、マウント設定、機器のキャッシュ制御、ハードウェアが仕様どおり応答することに依存します。

安全な保存では、一時ファイルから名前を切り替えることがある

既存のmemo.txtを先頭から直接書き換えると、途中でアプリやOSが停止したとき、古い内容を失ったうえで新しい内容も途中、という状態になり得ます。そこでエディタは、次のようなsafe saveを採用することがあります。

1. 同じディレクトリ、または同じファイルシステム内に一時ファイルを作る。
2. 新しい内容を一時ファイルへ最後まで書く。
3. 必要な耐障害性に応じて、一時ファイルを同期する。
4. renameやOS固有のreplace操作で、memo.txtという名前が新しいファイルを参照するよう切り替える。
5. 必要なら親ディレクトリも同期し、名前の切り替えを永続化する。

POSIXのrenameでは、置換先の名前が処理中に消えた状態を他プロセスへ見せず、旧ファイルまたは新ファイルのどちらかを参照させられます。WindowsのReplaceFileは、新しいファイルで既存ファイルを置き換え、元ファイルの属性やACLなどを引き継ぐ処理をまとめています。AppleもAPFSの特徴としてatomic safe-save primitivesを挙げています。

ジャーナリングは何を守り、何を必ずしも守らないか

ジャーナリングは、更新内容の一部を先にログへ記録し、クラッシュ後に完了済みの取引を再生または未完了分を破棄できるようにする仕組みです。主な狙いは、空き領域の管理、ディレクトリ、ファイルサイズなどのファイルシステム構造が更新途中の矛盾した状態で止まることを防ぐことです。

しかし、「ジャーナリング対応＝保存ボタン直前の本文が必ず残る」ではありません。ext4の公式資料では、標準のdata=orderedモードは主にメタデータをジャーナルへ記録し、クラッシュ後のファイルデータブロックが常に期待どおりであることまでは保証しないと説明されています。data=journalのようにデータも扱う設定はありますが、性能と保証の範囲が変わります。

この3つは競合する機能ではなく、守る問題が違います。堅牢な保存を設計するなら、「途中の内容を見せない」「ファイルシステム構造を壊さない」「必要なデータを永続化する」を分けて考えます。

よくある4つの誤解を、内部構造から直す

特に削除は、「見えなくする」「開いている参照を終える」「割り当てを解放する」「媒体上の痕跡を消す」が別段階です。機密データの消去では、通常の削除操作を安全消去とみなさず、媒体と暗号化方式に合う手段を選ぶ必要があります。

NTFS・ext4・APFSは、同じ役割の異なる実装

ファイルシステムの本質は製品名ではありません。NTFS、ext4、APFSはいずれも名前からデータへたどれる状態を作りますが、管理構造、更新方式、対応OS、権限、暗号化、スナップショット、互換性などが異なります。

外付けストレージの形式を選ぶときは、単に「新しい形式」を選ぶのではなく、利用するOS、機器間の互換性、必要な最大ファイルサイズ、権限、暗号化、障害復旧、取り外し方を確認します。ネットワーク越しにファイルを置く場合は、ローカルのファイルシステムだけでなく、通信、サーバー側キャッシュ、共有プロトコルも永続化経路へ加わります。配置方式の違いはNAS・SAN・DASの違いで確認できます。

まとめ：ファイルシステムは「名前・論理データ・媒体」をつなぐ

memo.txtにAを保存できるのは、ファイルシステムが単にファイルとフォルダを一覧表示するからではありません。パスの各名前を探索してファイルを識別し、ファイル内の論理位置を割り当て先へ変換し、キャッシュ上の変更をストレージI/Oへつなぎ、必要なら永続化まで完了させるからです。ファイルシステムとは、名前の世界と、論理的なバイト列と、実際の保存領域を一貫して結び付ける仕組みなのです。

ただし、0と1の並びだけを見ても、それが文字なのか数値なのかは決まりません。ビット列に意味を与える規則まで分かって、初めて「文字A」「数値65」「設定フラグ」などとして扱えます。

「bitは0か1、byteは8bit」は入口です。本当に押さえたいのは、なぜ二状態で情報を表せるのか、8bitがなぜ実務単位になり、どの規則で文字や数値へ変わるのかです。

ビットは「二つの状態を区別できる」という情報

NISTの用語集では、bitを「0または1の二進数字」と定義しています。ここで大切なのは、0や1という文字の形ではなく、二つの状態を区別して同じ規則で読み戻せることです。

たとえばスイッチに「開いている」「閉じている」という二状態があり、送る側と受け取る側が「開いている状態を0、閉じている状態を1と呼ぶ」と決めたとします。受け取る側は状態を見分ければ、0か1のどちらが送られたか判断できます。これが、二状態で1ビット分の情報を表せるという意味です。

実際の機器の中に、数字の0や1が小さく書かれているわけではありません。論理回路では電圧の低い範囲と高い範囲、DRAMやフラッシュメモリでは電荷やしきい値、磁気媒体では磁化の状態など、実装ごとに異なる物理状態を規則に従って0または1へ対応づけます。

nビットなら2ⁿ通りを区別できる

1ビットには0と1の2通りがあります。2ビットに増やすと、1桁目の2通りそれぞれに2桁目の2通りを組み合わせられるため、2 × 2 = 4通りです。

1 bit : 0, 1                                      → 2通り
2 bit : 00, 01, 10, 11                           → 4通り
3 bit : 000, 001, 010, 011, 100, 101, 110, 111  → 8通り
8 bit : 00000000 ～ 11111111                     → 256通り

桁が一つ増えるたびに、既存の各パターンへ0を付ける場合と1を付ける場合が生まれるので、通り数は2倍になります。したがって、制約のないn桁のビット列が持てるパターン数は次の式です。

2 × 2 × …… × 2 ＝ 2ⁿ 通り
  （n回）

8ビットなら256通りあるため、符号なし整数として読む規則なら0〜255を表せます。ただし「256通りある」ことと「0〜255という数値である」ことは別です。0〜255になるのは、各桁へ2の累乗の重みを割り当てる二進数として読んだ場合です。桁の重みと16進表記は2進数と16進数の仕組みで詳しく解説しています。

ビット列そのものに「文字」「数値」という意味はない

8ビット列01000001を見てみます。これは一つのパターンですが、パターンだけから用途は決まりません。

つまり、ビット列は意味を入れる容器というより、区別できるパターンです。データ型、文字エンコーディング、ファイル形式、通信プロトコルなどの規則が「この位置のこのビット列をどう解釈するか」を決めます。

なぜ8ビットをまとめた「バイト」が実務の単位になるのか

NISTの定義では、1バイトは8ビットの並びです。歴史上はbyteの幅が異なる機械もありましたが、現在の一般的なIT文脈では1 B = 8 bitとして扱います。8ビットを明示したい規格では「octet（オクテット）」という語も使われます。

8という数が自然法則から必然的に出てきたわけではありません。8ビット単位が規格や機器で定着し、その単位を前提にメモリ、OS、ファイル、通信のインターフェースがつながっているため、バイトが実務上の共通単位になっています。

NIST IR 8289も、個々のビットを直接アドレス指定できない多くの文脈では、バイトが実用上のデータ単位になると整理しています。またPOSIXのread()やwrite()も、読み書きする量をバイト数で受け取ります。

memo.txtへAを追加すると、どこでビット列になるのか

ここからは、テキストエディタでmemo.txtを開き、半角英字のAを追加し、UTF-8で保存する例を最後まで追います。

キーを押した瞬間から「A = 01000001」が届く、と一気に考えないことがポイントです。入力イベント、文字の識別番号、保存用バイト列、物理状態は別の層です。

1. Aキーの操作が入力イベントになる
   キーボード側の信号をOS、入力メソッド、UIフレームワークなどが処理します。キー位置、修飾キー、入力方式などが関係するため、この段階をそのままUTF-8の0x41とみなすことはできません。
2. テキスト入力として「A」が確定する
   UnicodeではAへコードポイントU+0041が割り当てられています。コードポイントは文字を識別する番号であり、まだ「ファイルへ並べる1バイト」と同じものではありません。アプリ内部で実際に使う文字列表現も、UTF-8、UTF-16など実装により異なります。
3. 保存時にUTF-8でエンコードする
   テキストエディタがUnicodeのコードポイント列を、UTF-8の規則でバイト列へ変換します。U+0041はUTF-8では1バイト0x41です。
4. 1バイトを8ビットの並びとして書き渡す
   0x41は16進表記であり、同じ8ビットパターンを二進表記にすると01000001です。OSはこのバイトを既存内容に加えたバイト列としてファイルへ書き込みます。
5. 装置がビット列を物理状態へ対応づける
   メモリ、バス、ストレージ制御装置、媒体は、それぞれの方式で電圧・電荷・磁化などの状態を扱います。後で読み出すと、規則に従って同じ論理バイト列へ復元されます。

Unicode Standard 17.0とRFC 3629では、UnicodeのU+0000〜U+007FはUTF-8で同じ値の1バイト0x00〜0x7Fになります。そのためAでは、コードポイント表記のU+0041とUTF-8バイトの0x41が似て見えます。

「1文字 = 1バイト」ではない

UTF-8は、コードポイントに応じて1〜4バイトを使う可変長の符号化方式です。同じ「画面上では1文字に見えるもの」でも、必要なバイト数は異なります。

したがって、memo.txtへ追加する内容がAなら1バイト、あなら3バイト、😀なら4バイトです。さらに、複数のコードポイントを組み合わせて一つに見せる絵文字や結合文字もあるため、見た目の文字数・コードポイント数・バイト数は別々に考える必要があります。

小文字bと大文字Bを読み分ける

単位記号では、一般に小文字のbをbit、大文字のBをbyteとして使います。100 Mbと100 MBは8倍違うため、大文字・小文字は単なる表記ゆれではありません。

単位として厳密に書くならMb/sやMB/sですが、製品画面ではMbpsも広く使われます。MBpsのような表記は見間違えやすいため、バイト毎秒はMB/sと書くほうが明確です。

100 MbpsをMB/sへ換算する

ここでMを10進のmega、つまり100万倍としてそろえます。100 Mbpsは1秒あたり100,000,000ビットです。1バイトは8ビットなので、バイト毎秒へ直すときは8で割ります。

100 Mbps
= 100,000,000 bit/s
÷ 8
= 12,500,000 B/s
= 12.5 MB/s

したがって、100 MB = 100,000,000 Bのファイルを100 Mbpsで送る最短時間は、単純計算では8秒です。

100 MB × 8 ÷ 100 Mb/s = 8 s

ただし、これは回線のビットレートをすべてファイル本体へ使えたと仮定した理論値です。実際の通信では、TCP/IPなどのヘッダー、確認応答、暗号化に伴う付加情報、再送があり、端末・Wi-Fi・サーバー・ストレージ側にも上限があります。TCP仕様のRFC 9293にも、ユーザーデータとは別のヘッダー項目や再送処理が定められています。

MBとMiB：10進接頭語と2進接頭語を分ける

kilo、mega、gigaというSI接頭語は、10の累乗です。BIPMのSI接頭語では、kは10³、Mは10⁶、Gは10⁹と定められています。2の累乗を明示する接頭語がKi、Mi、Giです。

NISTの二進接頭語の整理でも、1 MBは1,000,000 B、1 MiBは1,048,576 Bと区別されています。したがって、100 MiBのファイルを100 Mb/sで送る理論時間は8秒ではなく、約8.39秒です。

100 MiB × 1,048,576 B/MiB × 8 bit/B
÷ 100,000,000 bit/s
= 8.388608 s

歴史的経緯から、画面や製品によっては2の累乗で数えた値にMB・GBと表示することもあります。容量差を正確に確認するときは、ラベルだけで判断せず、可能なら総バイト数も確認します。保存装置の接続形態を比較する場合は、既存のNAS・SAN・DASの違いも参考になります。

実務では「数字」より先に4つの前提を確認する

ビットとバイトの混乱は、計算よりも「何を数えているか」が抜けたときに起きます。ログ、設定、製品仕様を見るときは、次の順に確認すると整理できます。

1. 単位はbかBか
   bitなのかbyteなのか。速度なら毎秒を示す/sが付いているか。
2. 接頭語は10進か2進か
   MBなのかMiBなのか。製品独自の表示なら総バイト数も見る。
3. ビット列へ意味を与える規則は何か
   整数、UTF-8、画像形式、プロトコルなど、どの規則で解釈しているか。
4. どの層の量か
   回線の理論ビットレート、プロトコルを含む転送量、アプリのファイル本体、ストレージ上の使用量を混ぜていないか。

まとめ：情報はbitで区別し、byteで実務へつなぐ

memo.txtへAを保存できるのは、物理状態を0と1へ対応づけ、複数ビットで多数のパターンを作り、UnicodeとUTF-8の規則でその一つを文字Aのバイト列へ結びつけているからです。bitは区別できる情報の土台、byteはそのbit列をアドレス・容量・入出力で扱う共通単位と考えると、定義と実際の動作がつながります。

「アプリがOSへお願いする窓口」は入口として正しい説明です。この記事では、その“お願い”が実際にはどのレジスタへ何を入れ、CPUのどの境界を越え、カーネルが何を確かめ、どんな値を返す往復なのかまで分解します。

システムコールは「特権関数」ではなく、制御された往復である

Linux man-pagesのsyscalls(2)は、システムコールをアプリケーションとLinuxカーネルの基本インターフェースと説明しています。ただし、「カーネルの関数を普通に呼ぶ」と理解すると、本質を外します。ユーザープログラムはカーネル内の任意のアドレスへジャンプできず、OSがあらかじめ用意した入口、番号、引数形式、戻り値形式に従う必要があります。

普通の関数呼び出しと比べると、違いが見えます。

この境界が必要なのは、一般アプリを不自由にするためではありません。1つのアプリのバグや悪意が、OS全体、他プロセス、任意の機器を直接壊さないようにするためです。ユーザーモードとカーネルモードを含むOSの全体像は、先にOSとはを読むとつながります。

API・ライブラリ・システムコール・ABIは同じものではない

「コードにwrite()と書いたから、そこがシステムコールそのもの」とは限りません。動作を正確に追うには、次の4層を分けます。

open()がopenatを呼ぶ――名前は1対1ではない

LinuxのCプログラムでopen("memo.txt", ...)と書いても、現在のglibcでは、同名のカーネルシステムコールopenが実行されるとは限りません。open(2)によると、glibc 2.26以降のopen()ラッパーは、すべてのアーキテクチャで実際にはopenat()システムコールを使います。概念的には、基準ディレクトリをAT_FDCWDとしてopenat(AT_FDCWD, "memo.txt", ...)へ置き換えられます。

ラッパーは薄いこともあれば、OS・CPU・ライブラリの版に応じて別のシステムコールを選ぶこともあります。syscalls(2)も、ラッパー名とシステムコール名は「しばしば同じだが、常にではない」と説明しています。したがって、API名だけを見て、監視すべきシステムコールや番号を決めることはできません。

fwrite()は、その場でカーネルへ入らないこともある

Cの標準入出力のような高水準ライブラリは、ユーザー空間にバッファを持ちます。fwrite()で「A」を渡しても、まずライブラリのバッファへコピーされ、バッファが満杯になる、fflush()を呼ぶ、ストリームを閉じる、といった時点までwriteシステムコールが発生しない場合があります。つまりAPIを1回呼ぶ＝システムコールを1回実行するではありません。

呼び出しをまとめる理由は、権限境界の往復と小さなデータ処理を何度も繰り返さずに済ませるためです。ユーザー空間・OS・装置にある一時領域の違いはバッファとはで詳しく確認できます。

memo.txt保存の一往復を図でつかむ

図の中心は、「アプリ → カーネル」という一方向の矢印ではなく、要求を符号化して渡し、検査された結果を復号して戻す往復です。以下では、Linux上の通常のバッファ付きファイル書き込みを例に、各段階の入力と出力を追います。実際のエディタは、直接上書きせず、一時ファイルへ書いてrenameするなど、より安全な保存方式を使うことがあります。

第1段階：ライブラリがシステムコール番号と引数を整える

説明用に、低水準APIで次の操作をするとします。これは保存の因果を示すPOSIX風の疑似コードであり、エラー処理を省いた完成プログラムではありません。

fd = open("memo.txt", O_WRONLY | O_CREAT, 0666)
write(fd, "A", 1)
fsync(fd)       // 電源断後にも残す保証が必要な場合
close(fd)

write(fd, buf, count)ラッパーが受け取る主な入力は、開いている対象を示すファイル記述子、ユーザー空間にあるバイト列の先頭アドレス、書きたいバイト数です。ラッパーは、対象CPUとOSのシステムコールABIに従い、システムコール番号と引数を所定のレジスタへ移します。

Linux syscall(2)が示す代表例は次のとおりです。これはLinuxの各ABIの例であり、他OSへそのまま持ち込めません。

第2段階：専用命令で、CPUが決められたカーネル入口へ移る

番号と引数を準備した後、x86-64ならsyscall、Arm AArch64ならSVCのような命令を実行します。Intel 64 / IA-32 Software Developer’s ManualはSYSCALL命令と保護機構を、ArmのSystem calls資料はSVCが例外を発生させ、より高いException levelへ制御された入口を作ることを説明しています。

CPUとカーネルの入口コードは、ユーザーモードへ戻るために必要な命令位置や状態を保ち、OSが設定したカーネル入口へ制御を移します。ユーザープログラムが「カーネルモードになる場所」を自由に選ぶのではありません。CPUが認めた入口へしか入れず、その後もシステムコール番号で許された処理へ振り分けられます。

モード切り替えは、コンテキストスイッチではない

ここは最も混同されやすい点です。システムコール入口では、通常、呼び出したスレッド自身が、そのスレッドの依頼を処理するためにカーネルコードを実行します。ユーザー→カーネルというCPU権限の切り替えは起きますが、ただちに別プロセスや別スレッドへCPUが移るとは限りません。Linuxカーネル文書も、システムコールをprocess contextで実行される処理として扱っています。

ただし、システムコールがディスクやネットワークの完了を待ってブロックした場合、または途中でスケジューラが実行権を渡した場合には、別スレッドへのコンテキストスイッチが起こり得ます。関係は次のとおりです。

システムコール入口
  → モード切り替えは必要
  → コンテキストスイッチは必須ではない
  → 待ち・プリエンプト・スケジューリングがあれば起こり得る

MicrosoftのVTrace解説にも、ユーザーモードからカーネルの処理を呼ぶ際、カーネルトラップは必要でもコンテキストスイッチは不要な例が示されています。

第3段階：カーネルは番号を振り分け、引数を信頼せず検査する

カーネル入口は、レジスタからシステムコール番号を読み、対応する実装へ振り分けます。番号が存在しなければLinuxではENOSYSに相当するエラーです。しかし、正しい番号だっただけで処理が許可されるわけではありません。

write(fd, buf, count)なら、少なくとも次の異なる種類の値を扱います。

特にbufは、ユーザープロセスの仮想アドレスです。カーネルは、渡された数値をそのまま信頼して通常のポインタのように触れません。LinuxカーネルのUser Space Memory Access文書が示すaccess_ok()やget_user()等の仕組みを使い、ユーザー領域へのアクセス失敗を-EFAULTとして扱える形で読み書きします。

第4段階：VFSがファイル記述子を、対象ファイルの書き込み処理へつなぐ

fdはファイル名そのものではなく、そのプロセスのファイル記述子表からカーネル内のopen file descriptionをたどるための小さな整数です。Linux VFS文書は、VFS（Virtual File System）がユーザー空間へ共通のファイルシステムインターフェースを提供し、ファイル記述子から対応するstruct fileとファイル操作へつなぐことを説明しています。

通常のバッファ付きファイル書き込みでは、VFSと対象ファイルシステムの処理が、ユーザーバッファからカーネル側のページキャッシュへデータを取り込み、該当ページを「変更あり（dirty）」として扱います。この時点で、ストレージ装置へ物理書き込みが完了している必要はありません。ファイル名・ディレクトリ・メタデータ・データブロックの対応はファイルシステムとは、装置固有の要求への変換はデバイスドライバとはに委ね、この記事では境界の往復に焦点を戻します。

第5段階：生の結果が戻り、ラッパーがerrnoへ翻訳する

カーネル処理が終わると、結果はABIで決められた戻り値レジスタへ置かれます。Linuxの多くのアーキテクチャでは、成功なら書けたバイト数などの非負値、失敗なら負のエラー番号がカーネルから返ります。

glibcのようなラッパーは、その生の結果をCプログラム向けに翻訳します。syscalls(2)が説明する一般形は次のとおりです。

カーネルの生の結果      libcラッパーがアプリへ見せる結果
書けたバイト数 n   →    n
-EACCES など       →    -1 を返し、errno = EACCES

したがって、errnoは「CPUが直接返す別の戻り値」ではありません。多くの場合、ユーザー空間のラッパーが、カーネルの負のエラー番号を正のエラー番号へ直して、スレッドごとのerrnoへ保存します。またerrnoを見るのは、関数が失敗を示したときだけです。成功後に残っている古いerrnoを読んでも、今回の結果は分かりません。

最後にCPUは保存していたユーザー側の状態へ戻り、ラッパーからアプリの次の命令へ進みます。入口から出口まで、別スレッドへ切り替わる事情がなければ、同じスレッドの実行文脈がユーザー→カーネル→ユーザーと往復したことになります。

write()は「全部書けた」か「全部失敗」の二択ではない

Linux write(2)とPOSIXのwrite仕様では、write()は要求したcountバイトまでを書こうとします。成功の戻り値は、実際に書けたバイト数です。返った数がcountより小さい部分書き込みも成功結果であり、残りは呼出側が位置を進めて再度書く必要があります。

シグナルで中断された場合も、いつ中断されたかで結果が変わります。

低水準APIで全バイトを書き切る考え方は次のようになります。実用コードでは、シグナル、非ブロッキングI/O、ファイル種別、キャンセル、タイムアウト、ログ方針まで設計します。

p = buffer
remaining = length

while (remaining > 0) {
    n = write(fd, p, remaining)
    if (n > 0) {
        p += n
        remaining -= n
        continue
    }
    if (n == -1 && errno == EINTR) {
        continue                 // まだ1バイトも進んでいない
    }
    if (n == -1 && (errno == EAGAIN || errno == EWOULDBLOCK)) {
        wait_until_writable()
        continue
    }
    report_error_and_stop()
}

fwrite・fflush・write・fsyncの成功地点を分ける

「保存に成功した」という言葉は、どの層まで成功したかを省略しています。memo.txtへ「A」を残すなら、少なくとも次の境界を分けます。

fflush(3)は、ユーザー空間のバッファを下位のwrite関数へ渡す操作です。一方、write(2)は、成功してもデータがディスクへ確定した保証はないと明記しています。通常のバッファ付き書き込みでは、データはまずページキャッシュでdirtyになり、後でwritebackされ得ます。

fsync(2)は、変更されたファイルデータと関連メタデータを永続装置へ送って、装置が完了を報告するまで待ちます。ただし、ファイル自身のfsyncだけでは、そのファイル名を持つディレクトリエントリが装置へ到達したとは限りません。新規作成やrenameを障害後も確実に残す設計では、親ディレクトリも開いてfsyncする必要があります。

システムコールのコストは、権限境界だけでは決まらない

システムコールには、番号と引数の準備、CPUの入口・出口、状態の保存復元、番号のディスパッチ、引数検証、安全なユーザーデータコピー、ロックやキャッシュ処理などの仕事があります。普通の小さなユーザー空間関数より仕事が増えやすいのは確かですが、「1回何ナノ秒」「必ず遅い」と固定値で覚えるのは不正確です。CPU、OS、セキュリティ緩和策、キャッシュ状態、引数サイズ、処理内容、競合で変わります。

さらに、システムコール入口のコストと、その後に依頼する仕事のコストを分けます。1バイトをページキャッシュへコピーするwriteと、ネットワーク応答を待つreadでは、支配的な時間が違います。後者がブロックしてスケジューラが別スレッドを動かせば、そこで初めてコンテキストスイッチや待ち時間も加わります。

小さなwriteを大量に呼ぶ代わりに、ユーザー空間バッファへまとめて大きなwriteにすると、入口・出口の回数を減らせます。ただし、まとめたデータがバッファへ滞留する時間、失敗時にどこまで処理済みか、必要なレイテンシ、メモリ使用量とのトレードオフがあります。「呼び出し回数が少ないほど常に正しい」のではなく、必要な単位と保証に合わせてまとめます。

LinuxとWindows、x86-64とArmで名前・番号・入口は変わる

システムコールの役割は、多くのOSで「低い権限のプログラムが、制御された境界からOS中核のサービスを使うこと」です。しかし、公開API、システムコール名、番号、レジスタ、命令、エラー表現は同じではありません。

• Linux x86-64とLinux arm64だけでも、番号・引数レジスタ・専用命令が異なる。
• 同じLinuxでも、ABIやアーキテクチャによって存在するシステムコールと番号が異なる。
• glibcの版やアーキテクチャにより、同じラッパーが別のシステムコールを選ぶことがある。
• Windowsの一般アプリは通常Win32等の公開APIを使い、その下でNative System Servicesへつながる。Linuxのwriteと同じ名前・番号を前提にしない。

MicrosoftのUser mode and kernel modeは、アプリがユーザーモード、OS中核がカーネルモードで動く保護境界を説明しています。ファイル書き込みに対応する低水準サービスの一例としてNtWriteFileがありますが、通常のアプリがOS内部のシステムコール番号を固定して直接呼ぶ設計は、公開Win32 APIを使う設計より移植性・互換性が低くなります。

実際に観測すると、APIとシステムコールの差が見える

Linuxではstraceを使うと、プロセスが実際に発行したシステムコールと戻り値を観測できます。たとえば、説明用の小さなプログラムなら次のような形が見えます。番号やファイル記述子、フラグ、実際の保存方式は環境とプログラムで変わります。

openat(AT_FDCWD, "memo.txt", O_WRONLY|O_CREAT, 0666) = 3
write(3, "A", 1)                                      = 1
fsync(3)                                               = 0
close(3)                                               = 0

コードにはopen()と書いたのにトレースにはopenat()が出る、複数のfwrite()が1回のwrite()へまとまる、という観測があり得ます。逆に、実用エディタでは一時ファイルの作成、複数回のwrite、fsync、rename、ディレクトリ同期などが現れる場合があります。トレースは「自分の想像したAPI対応」ではなく、実際の境界通過を確かめる道具です。

6つの誤解を、正しい境界へ置き換える

まとめ：関数呼び出しがカーネル処理へ変わる因果

memo.txtへ「A」を保存するとき、アプリの関数呼び出しは、そのままカーネル関数へ飛ぶのではありません。ライブラリが要求をシステムコール番号と引数へ変換し、CPUの専用命令が制御された権限境界を越え、カーネルが入力を検証してVFSの書き込み処理へつなぎ、結果を同じスレッドへ返します。その戻り値を確認し、部分書き込みを処理し、必要ならfsyncで耐久性の境界を進めるところまで含めて、初めて「OSへ正しく仕事を依頼した」と説明できます。

関連する基礎用語

• OSとは：ユーザーモード、カーネル、保護・共有・抽象化の全体像を確認する
• ファイルシステムとは：パス、ファイル記述子の先にあるファイル、メタデータ、データブロックを追う
• バッファとは：fwrite、ページキャッシュ、装置キャッシュ、flushを層ごとに分ける
• デバイスドライバとは：カーネルの共通I/O要求が、機器固有のコマンドへ変換される先を追う

「プロセスは作業場所、スレッドは作業担当」と覚えるだけでは、なぜデータ共有が速いのか、なぜ競合するのか、CPUが何を切り替えるのかまでは分かりません。この記事では、その比喩をメモリとCPUの実体へ戻します。

起動前のプログラムは、まだプロセスではない

ストレージ上のテキストエディタの実行ファイルは、命令や初期データを一定の形式で並べたプログラムファイルです。ファイルが置かれているだけでは、次に実行する命令位置も、作業中の文字列も、CPUへ割り当てる実行文脈もありません。

エディタを起動すると、OSとプログラムローダーが実行環境を準備します。細部はOSや実行形式によって異なりますが、概念上は次のものがそろった時点で「実行中」になります。

1. プロセスを識別するIDやセキュリティ情報を用意する
2. そのプロセス用の仮想アドレス空間を作る
3. 実行コード、初期データ、必要な共有ライブラリなどをアドレス空間へ対応付ける
4. 動的なデータに使うヒープや、最初のスレッドに使うスタックを用意する
5. 最初のスレッドの開始位置とレジスタ状態を作り、実行可能な状態にする

WindowsのCreateProcessは、新しいプロセスとその主スレッドを作ります。一方、Linuxを含むPOSIX系では、既存プロセスを複製してからexecveでプログラムイメージを置き換える形や、posix_spawnを使う形があります。つまり「ファイルを起動するとプロセスができる」という結果は同じでも、生成手順はOS APIごとに同一ではありません。

プロセスは「資源」と「保護」の境界

「プロセス＝実行中のプログラム」は入口として正しい説明です。ただし本質をつかむには、実行に必要な資源をまとめ、別のプロセスから原則として分離する境界だと捉える必要があります。

たとえばエディタのプロセスには、次のような要素があります。

プロセスAの仮想アドレス0x1000と、プロセスBの0x1000は、同じ物理メモリを意味するとは限りません。OSとCPUのアドレス変換機構がプロセスごとの対応表を使うため、Aの誤ったポインタがBのヒープを通常のメモリアクセスで自由に書き換えないようにできます。これが保護境界です。

ただし完全に何も共有しないわけではありません。読み取り専用のライブラリコードを物理的に共有したり、明示的な共有メモリを複数プロセスへ割り当てたりできます。重要なのは、別プロセス間の共有はOSへ明示し、権限と対応付けを作る必要があることです。

スレッドは、CPUが途中から再開できる「実行文脈」

スレッドを単なる「処理の流れ」と呼ぶと、流れの正体が見えません。CPUが処理を中断し、あとで同じ続きから再開するには、少なくとも次に実行する位置と計算途中の状態を覚えておく必要があります。そのまとまりがスレッドの実行文脈です。

一方、同じプロセスのスレッドは、コード、静的データ、ヒープ、読み込んだライブラリ、開いたファイルなど、プロセス側の資源を共有します。スタックは各スレッド専用ですが、そのメモリ領域自体はプロセスの仮想アドレス空間の中にあります。

ここで「作業場所と作業担当」の比喩へ戻すと、作業場所に相当するのは共有ヒープや開いた資源です。作業担当に相当するのは、PC・レジスタ・スタックを持つ実行文脈です。この対応まで言えれば、比喩が実体につながります。

memo.txtの入力・画面・保存を3本のスレッドで追う

説明用に、テキストエディタが次の3本を使うとします。実際のスレッド構成や画面更新の制約は、エディタやGUIフレームワークによって異なります。

• UIスレッド：キー入力を受け取り、編集内容を更新して画面を描く
• 保存スレッド：保存操作を受け、memo.txtへ書き込む
• 自動保存スレッド：一定条件で編集内容のスナップショットを保存する

1．UIスレッドがAを編集バッファへ加える

キーボード入力の通知を受けたUIスレッドが実行可能になると、OSのスケジューラは空いた論理CPUへそのスレッドを割り当てます。CPUにはUIスレッドのPC、レジスタ、スタック位置が復元され、前回止まった命令の続きから動きます。

UIスレッドは、ヒープにあるmemo.txtの編集バッファへAを追加します。このヒープはUIスレッド専用ではなく、同じプロセスの保存スレッドや自動保存スレッドからも同じ仮想アドレスで参照できます。CPUが命令を実行する基本はCPUとはで詳しく扱っています。

2．保存スレッドは同じバッファからデータを受け取れる

保存ボタンが押されると、UIスレッドが保存要求をキューへ入れ、保存スレッドを起こす設計が考えられます。保存スレッドは別プロセスへ文字列を送り直す必要がなく、同じヒープ上の編集データを参照できます。必要なのは「どの時点の内容を保存するか」を同期することです。

保存スレッドがOSへ書き込みを依頼すると、ストレージI/Oの完了待ちになる場合があります。このとき待機しているのは保存スレッドであり、CPUそのものではありません。OSは保存スレッドを待機状態へ移し、UIスレッドや別アプリの実行可能なスレッドへCPUを渡せます。アプリからOSへ依頼する境界はシステムコールとはでつながります。

3．I/O完了後、保存スレッドは止めた続きへ戻る

I/Oの完了が通知されると、保存スレッドは待機中から実行可能へ戻ります。ただし、その瞬間に必ずCPUを得るとは限りません。スケジューラが優先度や他の実行可能スレッド、利用できるCPUなどを見て選び、選ばれたときに保存スレッドのPCとレジスタを復元します。

復元されたPCは「書き込み依頼の次に処理すべき命令」を示します。だから保存スレッドは、I/O待ちの間に別のスレッドが何度動いても、自分の続きから完了処理を再開できます。

同じプロセス内の共有は速い。しかし、順序は自動ではそろわない

同じプロセスのスレッド間では、ヒープ上のオブジェクトを同じアドレスで参照できます。別プロセス向けのメッセージ形式へ変換し、カーネルのIPC経路で渡し、相手側で復元する手順を省けるため、プロセス間通信と比べて小さなデータを頻繁に共有しやすいのが利点です。

ただし「同じメモリが見える」と「複数の操作がひとまとまりで正しい順序に見える」は別です。次の自動保存を考えます。

最後のメモリ上にはABがありますが、ストレージにはAまでしかなく、未保存フラグはOFFです。正しさがスレッドの実行順序に依存して壊れるのがrace condition（競合状態）の一例です。単一コアでも、手順2と3の間でスレッドが切り替われば起こり得ます。

対策は、共有する「編集内容・版番号・保存済み状態」の関係を設計し、mutexなどのロック、atomic操作、メッセージキュー、変更不能なスナップショットなどで同期することです。たとえば短時間だけロックして内容と版番号のスナップショットを作り、I/O完了後は「保存した版番号」を更新すれば、現在の版との差から未保存か判断できます。

別プロセスなら、なぜIPCが必要なのか

自動保存を別プロセスへ分けた場合、そのプロセスはエディタとは別の仮想アドレス空間を持ちます。エディタのヒープを指すポインタ値だけ渡しても、自動保存プロセスでは同じデータを指しません。通常のメモリアクセスも保護機構に拒否されます。

そこで、pipe、socket、メッセージ、RPC、共有メモリ、ファイルマッピングなどのIPC（Inter-Process Communication／プロセス間通信）を使います。OSは、通信相手、権限、データの受け渡し、共有ページの対応付けなどを仲介します。

この手間と引き換えに、一方のプロセスが不正なアドレスへ書いて異常終了しても、別プロセスの私有メモリまで直接壊しにくくなります。権限もプロセス単位などで分けられます。そのためブラウザのように、安定性や権限分離を優先して1つのアプリを複数プロセスへ分ける設計もあります。

1コアでも複数スレッドが進むのは、OSが実行文脈を切り替えるから

ある論理CPUが、ある瞬間に実行するのは、OSに選ばれた1本のスレッドの実行文脈です。実行可能なスレッドが複数あれば、OSは一定時間の経過、優先度の高いスレッドの準備完了、実行中スレッドの待機などを契機に、別のスレッドへ切り替えます。

概念上のcontext switch（コンテキストスイッチ）では、現在のスレッドのPC・レジスタ・スタック位置など、再開に必要な状態を保存し、次のスレッドの状態をCPUへ復元します。別プロセスのスレッドへ移る場合は、利用する仮想アドレス空間の対応も切り替わります。実際にどの状態をいつ保存するか、キャッシュやアドレス変換情報へどの程度影響するかはCPUとOSの実装で異なります。

このように、複数処理がある時間幅の中で少しずつ前進する状態が並行（concurrent）です。複数の論理CPUがUIスレッドと保存スレッドを同じ瞬間に実行する状態が並列（parallel）です。並列なら並行でもありますが、1コア上の時分割による並行は並列ではありません。

スレッドを増やしても、必ず速くなるわけではない

スレッドを分ける価値は、処理時間の短縮だけではありません。保存スレッドがI/Oを待つ間もUIスレッドを動かせれば、保存自体が速くならなくても画面の応答性は保ちやすくなります。まず「完了を速めたいのか」「待ちの間も別の仕事を進めたいのか」を分けます。

したがって「スレッドはプロセスより軽いから大量に作る」が結論ではありません。同一プロセスのスレッドはアドレス空間を共有するため、別プロセスより作成・切替の負担が小さいことが多い一方、実際のコストはOS、CPU、ランタイム、スレッドの状態で変わります。一般論だけで本数を決めず、CPU使用率、実行可能な待ち、I/O待ち、ロック競合、context switch数を観測します。

Windows・Linux・POSIXで共通する芯と異なる実装

この記事の「プロセスは資源・保護境界、スレッドは実行文脈」というモデルは、現代のWindowsやLinuxで使える共通の理解です。実際に、Microsoftのprocess/thread資料はaddress spaceとthread contextを分け、Linuxのpthreads資料はdata・heapの共有とthreadごとのstackを分けています。ただし、用語の属性や実装細部まで全OSで同じではありません。

さらに、言語ランタイムは「タスク」「コルーチン」「仮想スレッド」など、OSスレッドより上位の実行単位を持つことがあります。ここで扱ったのは主にOSがスケジュールするネイティブスレッドのモデルです。アプリから見える実行単位がOSスレッドと1対1かどうかは、利用するランタイムの仕様を確認します。

実機ではPID・TID・メモリマップ・待機を対応付ける

Windowsのタスクマネージャーでアプリ別に見えるのは主にプロセスです。「詳細」等でPIDを確認し、必要に応じてスレッド数やCPU使用率を表示すると、1つのプロセス内に複数の実行文脈があることを観測できます。詳しい性能分析ではWindows Performance Analyzerなどでthread stateやcontext switchを追います。

Linuxでは、権限の範囲内で次の情報を対応付けられます。

# PID 1234に属するthreadと現在の状態・実行CPUを見る例
ps -L -p 1234 -o pid,tid,stat,psr,pcpu,comm

# process内のthread IDを列挙
ls /proc/1234/task/

# processの仮想メモリ領域と権限を見る
cat /proc/1234/maps

mapsには実行ファイル、共有ライブラリ、heap、stackなどの対応が見えます。ただし、表示名や可視範囲はカーネル版・権限・デバッグ制限で異なり、個々の行がソースコードの変数へそのまま対応するわけではありません。

JavaのThreadとRunnableへつなげる

JavaのThreadを理解するときも、「何をCPUで再開できる実行文脈として扱うか」が土台です。start()は同じメソッドを普通に呼ぶのではなく、別の実行の流れを開始する操作だと捉えられます。

Runnableは実行したい処理を表し、Threadはその処理を進める実行の流れに関係します。ただし、Java APIとOSスレッドの対応はJVMやThreadの種類によって異なるため、常に1対1だと決め付けないことが大切です。JVM内のheapやstackはJavaのメモリ管理で区別できます。

まとめ：プロセスは境界、スレッドは再開できる状態

memo.txtへAを入力して保存するとき、プロセスは編集バッファや開いたファイルを共有できる境界を用意します。その中でUIスレッドと保存スレッドは、それぞれのPC・レジスタ・スタックを持ち、OSに選ばれたときだけCPU上で続きを実行します。保存スレッドがI/Oを待てばCPUは別スレッドへ移り、同じヒープを同時に更新するなら同期が必要になります。「資源を分けるプロセス」と「実行状態を切り替えるスレッド」という因果までつなげると、2つの違いを暗記ではなく説明できます。

「OSとハードウェアの橋渡し」という説明は正しい入口ですが、橋を渡るだけではありません。ドライバは要求をキューへ割り当て、機器がアクセスできるメモリアドレスを準備し、開始を通知し、割り込みまたはポーリングで完了を回収します。

この記事では、テキストエディタでmemo.txtへAを追記する例を、LinuxのブロックI/OとPCIe接続のNVMe SSDを具体例として最後まで追います。NVMe固有の用語は一般原理を見える形にするための実装例であり、USB機器、GPU、ネットワークアダプターではコマンドや転送方式が異なります。

ドライバは「翻訳機」に例えられます。ただし翻訳するのは文章ではなく、操作、アドレス、キュー、完了状態です。「どこへ何バイト書く」という共通要求を、「この装置のこの形式で、ここへ並べ、開始レジスタを更新する」へ具体化します。

ドライバが変換するのは「要求」と「完了」

アプリは「NVMe Submission Queueの何番へ命令を置くか」や「どのMMIOレジスタを更新するか」を指定しません。ファイルへ書くという意味をOSへ渡し、ファイルシステムやブロック層が機器に依存しない要求を組み立てます。

つまり、ドライバはデータ形式だけを変えるのではありません。OSが管理する要求のライフサイクルを、装置が理解するプロトコルのライフサイクルへ対応付けるのが中心です。

memo.txtのAがSSDへ届くまで

ここでは、ページキャッシュ上の変更をストレージへ書き戻す段階から見ます。保存ボタン、write成功、媒体への永続化は同じ時点ではありません。この前段はファイルシステムとは、待ちとflushの境界はバッファとはで詳しく説明しています。

1. VFS・ファイルシステム・ブロック層が共通requestを作る

テキストエディタはシステムコールの入口からOSへ書き込みを依頼します。VFSとファイルシステムはパス、開いたファイル、権限、論理オフセット、ファイルシステム上の割り当てを扱います。その結果、ストレージへ必要な論理ブロック範囲とデータのあるメモリ領域がI/O要求になります。

Linuxのblk-mqでは、bioからブロックドライバへ渡すstruct requestが作られ、ソフトウェア側キューとハードウェアdispatch queueで管理されます。この段階の「write request」は、NVMeやSATAの細かな命令形式にはまだ依存しない共通モデルです。

2. ドライバがqueue・tag・command descriptorを割り当てる

ブロック層がNVMeドライバのqueue_rq相当を呼ぶと、ドライバは空いているqueue slotとtagを確保し、共通requestからNVMe Write commandを作ります。開始LBA、ブロック数、namespace、command ID、制御フラグなどを、NVMe仕様で定められたcommand entryへ配置します。

tagやcommand IDが重要なのは、複数の要求を同時に進め、完了順が投入順と異なっても、どのOS requestが終わったかを特定するためです。NVMe仕様でも、commandは順不同で完了し得ると定められています。

3. DMA mappingで「装置から見えるRAMの住所」を作る

CPUが使う仮想アドレスを、そのままPCIe装置が使えるとは限りません。ドライバはOSのDMA APIへRAM領域を渡し、IOMMU等で必要な対応付けを作り、装置が使うDMA addressを受け取ります。NVMe commandにはPRPやSGLのようなデータポインタとして、この転送先情報を載せます。

ここでの重要点は、ドライバが毎回CPUでデータ本体を装置へコピーするとは限らないことです。ドライバは主に転送可能な領域とアドレスを準備し、DMA engineを持つコントローラがRAMと装置の間でデータを転送します。CPUは設定と完了処理を担います。

4. commandをSubmission Queueへ置き、doorbellを鳴らす

PCIe接続NVMeでは、Submission QueueとCompletion Queueはホストからアクセスできるメモリ上に置かれます。ドライバはcommand entryをSubmission Queueへ書き、必要な順序を保証したうえで、MMIOのSubmission Queue Tail Doorbellレジスタを更新します。

doorbellはデータ本体ではなく、「queueのtailがここまで進み、新しいcommandがある」ことをコントローラへ知らせる制御信号です。Linuxでは、機器のMMIOレジスタへアクセスするためにioremap、readl、writel等のAPIが使われます。バスの順序規則があるため、普通のメモリ変数と同じ書き方では扱えません。

5. コントローラとファームウェアがcommandを実行する

NVMeコントローラはdoorbellの更新を知るとSubmission Queueからcommandを取得し、DMAでRAM上のデータを読み、装置内部で処理します。SSDのファームウェアはコントローラ内のプロセッサ等で動き、論理ブロックをNAND上の配置へ対応付け、誤り訂正、ウェアレベリング、ガベージコレクションなどを制御します。

ドライバがNANDセルへ直接電荷を書き込むわけではありません。ドライバはホスト側でNVMeという公開インターフェースを扱い、コントローラとファームウェアが装置内部の詳細を扱います。物理的な保持原理はストレージとはへ分離します。

6. Completion Queueへstatusが書かれ、割り込みまたはpollingで回収する

commandが完了すると、コントローラは対応するCompletion Queueへcompletion entryを書きます。そこには、どのSubmission Queue・command IDに対応するか、成功かエラーか、といったstatusが入ります。

コントローラはMSI-X等の割り込みで「新しいcompletionがある」とCPUへ通知できます。ただし、割り込みをまとめるcoalescingや、ドライバがqueueを能動的に確認するpollingを使う場合もあり、1要求につき必ず1割り込みとは限りません。

7. ドライバが装置statusをOSのcompletionへ戻す

ドライバはcompletion entryのqueue IDとcommand ID／tagから元のrequestを特定し、DMA mappingやqueue slotを解放します。装置固有statusを、成功、I/O error、timeout、再試行、媒体エラー等のOS側statusへ対応付け、ブロック層へ完了を返します。

その上でファイルシステムや待機中の処理が完了を受け取ります。ページキャッシュを使う通常の書き込みでは、アプリのwriteがこの媒体I/Oより前に成功している場合があります。一方、同期的な永続化要求なら、この下位completionを待つ経路が重要になります。

5つの境界を混ぜない

「ハードウェア側」という一言には、異なる役割が含まれます。境界を分けると、ドライバがどこまで担当するかが見えます。

ドライバとファームウェアは協調しますが、同じものではありません。ドライバは通常ホストOS側、ファームウェアは通常デバイス内部で動きます。両者のversionや機能交渉が合わなければ、認識はしても一部機能が使えない、復帰に失敗する、timeoutになる、といった問題が起き得ます。

Plug and Playは「ID照合 → 初期化 → 資源割り当て」

機器を接続すると、まずPCIe、USB等のバス側が機器を列挙し、device ID、compatible ID、MMIO範囲、interrupt等の資源情報をOSへ知らせます。OSは、そのIDをサポートすると宣言するドライバを探します。

Linuxのdriver modelでは、bus固有のmatchでdevice IDとdriverの対応を調べ、一致するとdriverのprobeを呼びます。probeは実機を確認し、deviceを有効化し、MMIOをmapし、DMA条件を設定し、queueやinterrupt handlerを準備します。成功して初めてdeviceとdriverがbindされます。

Windowsでも、機器が報告したhardware ID／compatible IDとdriver packageのINFを照合します。候補が複数あると、署名、機能、IDの一致度等を含むrankが優先され、同rankなら日付・versionが比較されます。単にversion番号が最大のdriverを無条件で選ぶわけではありません。

すべてのドライバがカーネルモードとは限らない

MMIO、DMA、interrupt、電源管理などへ直接関わる低水準driverは、強い権限と短い応答時間が必要なためkernel modeで動くことが多いです。しかし、「driver＝必ずkernel mode」ではありません。

Windows Driver FrameworksにはKMDF（Kernel-Mode Driver Framework）とUMDF（User-Mode Driver Framework）があります。UMDF driverはdriver host processで動き、I/O requestやPlug and Play通知を受けます。必要ならkernel mode部分とuser mode部分に分ける構成も可能です。

Microsoftの公式説明では、kernel mode codeはOSや他driverと同じvirtual address spaceを共有するため、誤ったaddressへの書き込みやcrashがOS全体へ影響します。UMDFではdriver failureを検出し、device stackを再構築してdriverを再起動または無効化する仕組みがあります。

署名・権限・互換性は別々に確認する

署名は「出所と改ざん検出」であり、無欠陥の保証ではない

driverは高い権限で動く場合があるため、OSはdriver packageの署名と信頼経路を確認します。現在のWindowsでは、新しいkernel-mode driverをloadする際にMicrosoftの署名policyが適用されます。

ただし、正しく署名されたdriverにもbugや脆弱性はあり得ます。署名は主に発行者・配布経路・改ざんを検証する材料であり、性能向上、完全な安全性、対象deviceへの最適性を自動的に保証しません。

権限が大きいのは、機器がmemoryとOS状態へ影響できるから

DMA対応deviceは、設定されたaddressへCPUを介さずアクセスできます。driverがmapping範囲、転送方向、lifetime、cache同期を誤れば、別データの破壊や漏えいにつながります。MMIO registerの誤操作も、device停止、誤転送、interrupt storm等を起こし得ます。

互換性はdevice IDだけでは決まらない

とくにLinuxのkernel内部interfaceは、userspace ABIとは異なり、すべてのversionで安定したbinary driver ABIを提供する設計ではありません。配布kernel外で作られたbinary moduleは、kernel更新に合わせた再buildや提供元の対応が必要な場合があります。

driver更新で必ず速くなるわけではない

driver更新の目的は、性能向上だけではありません。脆弱性修正、crash修正、新しいOSへの対応、新device IDの追加、power management改善、既知の回避策、telemetry改善などがあります。

性能が変わるのは、driverのqueueing、interrupt coalescing、DMA、offload、error recovery等が実際のbottleneckだった場合です。CPU、bus帯域、controller、媒体、filesystem、applicationが律速なら、driver更新だけで速くなるとは限りません。新versionが特定環境でregressionを起こす可能性もあります。

機器が動かないときは、往路と復路を分けて見る

「driverの問題」と一括りにせず、要求がどこまで進み、completionがどこで止まったかを確認します。

WindowsではDevice Managerのhardware ID、driver provider／version、status code、Event Viewerが入口です。Linuxではlspci -kやlsusbでdeviceと使用中driverを確認し、dmesgやjournalでprobe、IOMMU、timeout、reset、I/O errorを探します。管理者権限や追加toolが必要な場合があります。

よくある誤解を仕組みから直す

まとめ：driverは要求と完了の対応表を実機へつなぐ

デバイスドライバの本質は、OSと機器の間に存在することではなく、両側の「要求の表し方」と「完了の表し方」を対応付けることです。memo.txtのAについて、共通requestをcommandへ変え、RAMをDMA可能にし、doorbellで開始を知らせ、completionを元requestへ戻せれば、「橋渡し」の中身を説明できます。

関連する基礎用語

• OSとは：driverを含む抽象化・共有・保護の全体像を確認する
• I/O（入出力）とは：request queue、DMA、interrupt、pollingという共通I/O機構を確認する
• システムコールとは：アプリの要求がuser modeからkernelへ入る境界を確認する
• ファイルシステムとは：ファイル名、logical block、page cache、writebackの前段を確認する
• バッファとは：各queueの容量、待ち、backpressure、flushを確認する
• ストレージとは：controller、firmware、NAND／磁気媒体、永続化の後段を確認する

この記事では、テキストエディタでmemo.txtに「A」を追記して保存する1回の操作を追います。「A」はどのように番号付きブロックへ変わり、SSDやHDDの物理状態として残り、再び「A」として読めるのでしょうか。

「データが残る」とは、同じビット列を再構成できること

NISTの用語集はstorageを、データを後から取り出せるよう保持すること、またはデータを入れて取り出せる要素と定義しています。ここで大切なのは、単に物理状態が残るだけでなく、後から同じデータとして取得できることです。

ビットは「0か1のどちらかを区別する情報の単位」であり、それ自体が小さな物体ではありません。記憶装置は、ビット列を区別可能な物理状態へ対応付けます。読み出すときは、その状態を電気信号として測り、符号化規則と誤り訂正を使って論理上のビット列へ戻します。ビットと物理状態の関係は、ビットとバイトの解説を前提にすると整理しやすくなります。

memo.txtの保存を、論理から物理まで一気に追う

ここからは、memo.txtへ「A」を追記し、保存ボタンを押した後を追います。実際のエディタには、同じファイルへ上書きするもの、一時ファイルへ書いてから名前を置き換えるもの、自動保存を併用するものがあります。以下は、それらに共通する「最終的にストレージへブロックI/Oが届く部分」のモデルです。

1. ファイルシステムが、ファイル内の位置を論理ブロックへ対応付ける

保存要求を受けたOSは、memo.txtという名前、ファイル内の書き込み位置、追加するバイト列を扱います。ファイルシステムは、ディレクトリエントリやファイルのメタデータをたどり、どのファイルシステム上の論理ブロックを更新するかを決めます。一般的なバッファ付きI/Oでは、変更はまずRAM上のページキャッシュへ反映され、後で書き戻されることもあります。

ここでいうファイルシステムの論理ブロックと、ストレージ装置が公開する論理セクタ／論理ブロックは同じ言葉でも層が違います。たとえば、ファイルシステムが4KiB単位で管理し、装置が512Bまたは4KiBの論理ブロックを公開する構成があります。暗号化、RAID、LVMなど別の変換層を挟む場合もあり、1つのファイルが物理媒体上で連続しているとは限りません。名前・パス・メタデータとデータブロックの対応は、ファイルシステムの解説で詳しく扱っています。

2. OSが、LBA・長さ・データを含むI/O要求にする

書き戻す段階になると、OSのブロックI/O層は「この論理ブロック番号から、この長さのデータを書いてほしい」という要求を組み立てます。LBA（Logical Block Address）は、装置が外部へ見せる番号付きの保存領域です。Linuxカーネルの資料では、logical_block_sizeは装置がアドレス指定できる最小単位と説明されています。

ストレージ装置が受け取る中心情報は、memo.txtというファイル名ではなく、LBA、ブロック数、read／writeの種類、転送するデータです。OSは隣接する要求をまとめたり、キューで順序や公平性を調整したりすることがあります。要求キュー、DMA、割り込みなどI/O全体の動きはI/O（入出力）の解説へ、共通要求を装置のコマンドへ変える境界はデバイスドライバの解説へつながります。

3. NVMeやSATAのコマンドが、ストレージコントローラへ届く

ドライバはI/O要求を、NVMe、SATA、SAS、USBなど接続方式・プロトコルに応じたコマンドとしてコントローラへ渡します。NVMeのWriteコマンドを例にすると、ホストは開始LBAと書き込む論理ブロック数を指定します。ホストが指定するのは論理上の住所であり、NANDセルやHDDヘッドの座標ではありません。

NVMeは、PCIe上などで不揮発性ストレージへコマンドを渡すための仕様です。多数のキューと並列要求を扱いやすくし、ホストからコントローラまでのボトルネックを減らせます。しかし、NVMeという名称自体が記録媒体を表すわけではなく、NANDの消去単位や寿命を消してくれるわけでもありません。NVMe SSDでも、コントローラの内側では論理→物理変換、ECC、garbage collectionなどが必要です。

4. コントローラが、論理ブロックを媒体上の状態へ変換する

コントローラは装置の「受付窓口」だけではありません。論理アドレスを内部の保存位置へ対応付け、媒体に合う形へデータを符号化し、ECC（Error Correcting Code）などの管理情報を追加し、読み出し時には誤りを検出・訂正して論理ブロックを返します。

SSDではFTL（Flash Translation Layer）がLBAをNAND上の物理位置（ページなど）へ対応付けます。HDDでも、ホストから見えるLBAと内部の物理位置の間をコントローラが管理し、不良セクタを予備領域へ置き換える場合があります。そのため、同じLBAが常に同じ物理場所を指すとは限らず、ファイルの並びを媒体表面へそのまま描けるわけでもありません。

5. 完了通知が戻る。ただし「どこまで届いたか」を分ける

装置が処理完了を返すと、ドライバ、OS、待っていたアプリへ結果が戻ります。しかし、完了の意味は一段ではありません。OSのページキャッシュへ受け付けた時点、装置内の揮発性write cacheへ入った時点、不揮発媒体へ到達した時点は区別が必要です。

Linuxカーネルのwrite-back cache資料は、揮発性cacheを持つ装置が不揮発媒体への到達前にI/O完了を返し得ること、そのためデータ整合性が必要な処理でflushやFUA（Force Unit Access）を使うことを説明しています。NVMe NVM Command Set仕様も、揮発性write cacheが有効でFUAや完了済みflushがないまま電源を失う条件では、後のreadが古いデータを返し得ると定めています。

OSや装置が一時領域を挟む理由と、flushという言葉の層ごとの違いはバッファの解説で掘り下げています。

SSDは、NANDセルの電荷状態をどう使うのか

NISTはSSDを、solid-state memoryを使って永続データを保持するストレージ装置と定義しています。現在の一般的なSSDではNANDフラッシュが使われ、機械的なヘッド移動やプラッタ回転はありません。

NANDセルでは、蓄えた電荷によってトランジスタのしきい値電圧が変わります。コントローラは電圧の範囲を読み分け、ビットパターンへ復号します。SLCは1セルで1ビットを表しますが、TLCやQLCなどは複数の電圧範囲を区別して1セルに複数ビットを対応付けます。したがって、「電荷がある＝1、ない＝0」と二択で説明するのは、現在のSSD全般には粗すぎます。

read／programはページ、eraseはより大きなブロック

NANDでは、読み出しとprogram（書き込み）はページ単位、消去は多数のページをまとめたブロック単位で行うのが基本です。既存データのあるページを、RAMのようにその場で自由に上書きできません。書き換えるときは、消去済みの空きページへ新しいデータをprogramし、FTLの対応表を新しい物理位置へ切り替え、古いページを無効として扱う方式が使われます。

この非対称性から、SSDの内部処理が必要になります。

KIOXIAの技術資料はLBAをソフトウェア向けの抽象化、PBAを実際のハードウェア位置として整理しています。また、同社のgarbage collection資料では、有効データを新しい場所へ移し、元のブロック全体を消去して空き領域へ戻す流れが説明されています。

つまりSSDへの1回のwriteは、「指定されたセルへ同じ量だけ書く」単純な1対1処理ではありません。空きページへのprogram、対応表の更新、後のGCによるデータ移動があるため、ホストが書いた量よりNAND内部の書き込み量が増えることもあります。

空き領域が少ない状態や継続的なrandom writeでは、GCがホストのwriteと重なり、レイテンシやスループットが変動する場合があります。だからSSDの速度は「NANDだから一定」ではなく、コントローラ、ファームウェア、空き領域、read／write比、アクセスパターン、温度などの条件で変わります。

HDDは、回転するプラッタの磁化をどう使うのか

HDDは、磁性材料で覆われたプラッタを回転させ、read／write headで磁化パターンを書き込み、読み取ります。Seagateが公開するHDD製品マニュアルでは、プラッタが磁極性の遷移としてデータを保持し、headが磁気パターンを生成・読み戻すと説明されています。

プラッタ表面は同心円状のtrackに整理され、trackはsectorに区切られます。ただし、OSが「何枚目のプラッタの何番track」と指定するわけではありません。OSはLBAを指定し、HDDのコントローラが内部位置への対応、不良sectorの再配置、信号の符号化・復号、ECCを管理します。

HDDのrandom accessで時間がかかりやすい理由は、媒体が磁気だからというより、目的の位置へ機械的に移動して待つからです。

1. seek：actuatorがheadを目的のtrackへ移動する。
2. rotational latency：目的のsectorがheadの下へ回ってくるまで待つ。
3. transfer：headの下を通る磁化パターンを読み書きする。

連続したLBAを大きく読み書きすると、head移動と回転待ちを何度も繰り返さずに転送しやすいため、sequential throughputを出しやすくなります。離れた小さな領域を次々に読むrandom I/Oではseekと回転待ちが増え、1回ごとのレイテンシが支配的になります。SSDにはこの機械的なseekと回転待ちはありませんが、SSDでも要求サイズ、並列性、FTL、GCによりrandomとsequentialの性能差は残ります。

RAMとストレージは、役割だけでなくアクセスの仕方が違う

「RAMは作業机、ストレージは本棚」というたとえは入口として便利ですが、本質的な違いは、保持性だけでなくCPUから見えるアクセス経路にもあります。

アプリを起動すると、ストレージ上の実行ファイルやデータの必要部分がRAMへ読み込まれ、CPUが処理します。memo.txtを編集している間は主にRAM上の状態が変わり、保存によってストレージの論理ブロックへ反映されます。両者は代用品ではなく、速度、容量、保持性、アクセス方式を分担しています。RAM側の詳細はメモリとはで確認できます。

性能値は「どんなI/Oを何個同時に出したか」とセットで読む

ストレージ性能の数値は、単独では比較できません。最低でも、request size、random／sequential、read／write比、queue depthをそろえます。SNIAのSSD解説でも、workloadをblock size、IOPS、throughput、latency、queue depthなどで表すと整理されています。

IOPSとthroughputは、1回の大きさでつながる

すべての要求が同じ大きさで、同じ測定境界を使うなら、次の関係でおおよそ結び付けられます。

throughput ≈ IOPS × 1回のI/Oサイズ

例：25,000 IOPS × 4 KiB
  = 102,400,000 byte/s
  ≈ 97.7 MiB/s

1GiBを読む場合でも、4KiBずつなら262,144回、1MiBずつなら1,024回のI/Oです。前者は多くの操作をさばくIOPSが、後者は大きな連続転送を運ぶthroughputが効きやすくなります。OSが要求をmergeしたりcacheで応答したりすると、アプリ側とdevice側で数えるI/O回数が違うことにも注意が必要です。

queue depthは並列性を増やすが、待ち時間も作る

QD 1は、1つのI/Oが終わってから次を出す状態です。QDを増やすと、SSDの複数channelやNVMeのqueueなど内部並列性を使いやすくなり、一定範囲ではIOPSやthroughputが上がります。しかし処理能力を超えて要求を積めば、queue内の待ち時間が増え、latencyは悪化します。

何を知りたいかで、見る条件を変える

5つの誤解を、正しい境界へ置き換える

ローカル、NAS、クラウドでも芯は同じ

内蔵SSDや外付けHDDでは、コンピュータからdevice controllerまでが比較的近くにあります。NASやSANでは、その手前にnetwork、remote protocol、server cache、RAIDなどが加わります。cloud storageも物理媒体が消えるわけではなく、API、冗長化、分散配置、運用管理をサービスとして重ねています。

したがって遠隔storageのlatencyを考えるときは、「媒体のread／write時間」だけでなく、network往復、server処理、cache hit、冗長書き込み、混雑も分離します。DAS・NAS・SANの接続形態はネットワークストレージの解説へつながります。

まとめ：ストレージは「物理状態を論理データとして守る層」

memo.txtへ「A」を保存すると、文字を表すバイト列はファイルシステムの論理ブロックへ反映され、OSのブロックI/OとしてLBAとともにコントローラへ届きます。コントローラはSSDならNANDの物理ページ、HDDなら磁気媒体上の位置へ対応付け、ECCや管理情報とともに記録します。読み出し時は逆に物理状態を検出・訂正・復号し、同じ論理ブロックを返す――この往復が、ストレージの本質です。

「取り出す・解釈する・実行する」だけでは、何を取り出し、何が変わったら実行完了なのかが見えません。この記事では、その3語をCPU内部の部品と状態変化へ結び直します。

画面の「Aを保存」とCPUの仕事は、説明の階層が違う

この記事では、テキストエディタでmemo.txtを開き、半角の「A」を入力して保存する場面を最後まで使います。人から見ると「Aを保存した」という1つの操作ですが、CPUに届く「Aを保存」という命令はありません。

テキストエディタは、入力イベントを受け取り、作業中の文字列へAを追加し、保存操作を受けたらOSへ書き込みを依頼します。そのアプリもOSも、最後はCPUが実行できる細かな機械語命令の列として動きます。

CPUが実行する「命令」は、意味の決まったビット列

人が書いたJavaやCなどのソースコードは、そのままCPUへ渡りません。コンパイラや実行環境などを経て、対象CPUの命令セット（ISA：Instruction Set Architecture）に合う機械語命令になります。詳しい橋渡しはコンパイラとインタプリタの違いで解説しています。

1つの機械語命令には、一般に「何をするか」を表すオペコードと、「どの値を使い、どこへ結果を置くか」を表すオペランドの情報が含まれます。命令の長さやビット配置は、x86、Arm、RISC-Vなど命令セットごとに異なります。

RISC-Vの基本命令仕様を例にすると、演算命令はレジスタを読み結果をレジスタへ書き、ロードとストアがレジスタとメモリの間で値を移し、分岐命令が条件に応じて次の命令位置を変えます。CPUが「解釈する」とは、人の意図を理解することではなく、命令中のビット欄を回路が判別し、使うレジスタや演算回路を選ぶことです。

「取り出す・解釈する・実行する」を中身まで分解する

CPUの基本サイクルは、次の命令位置を定め、命令を取得し、命令の種類と材料を判別し、必要な回路で処理し、結果と次の位置を確定する流れです。まず全体を図でつなげます。

1．プログラムカウンタが命令列の位置を示す

実行中のプログラムは、機械語命令の列としてメモリ上に置かれています。CPUは、プログラムカウンタ（PC）と呼ばれる状態を手掛かりに、命令列のどこから取得するかを決めます。

この記事ではPCを「次に取得する命令の位置」として説明します。実際の命令セットでは「現在の命令のアドレス」と定義する場合や、別名を使う場合があります。たとえばx86-64では命令ポインタをRIPと呼び、RISC-Vではpcが現在の命令アドレスを保持すると定義されています。共通する本質は、CPUが命令列のどこを進んでいるかを示す基準であることです。

2．フェッチで、その位置の命令ビットを取得する

CPUはPCが示すアドレスを使い、命令を取得します。これがFetch（フェッチ）です。現代のCPUでは、多くの場合、まずCPUに近い命令キャッシュを調べ、そこになければ下位のキャッシュやメインメモリから取り寄せます。

単純なCPUの説明では、取得した命令を一時保持する場所を命令レジスタ（IR：Instruction Register）と呼びます。この言葉は流れを理解するのに便利ですが、すべての実製品に1個の公開されたIRがある、という意味ではありません。現代CPUでは、命令キューやパイプライン内の保持領域へ複数命令をためる実装が一般的で、IRはそれらを代表させた基本モデルです。

3．デコードで、オペコードとオペランドを判別する

Decode（デコード）では、命令のビット列を欄ごとに分け、「これは加算か、ロードか、分岐か」「どのレジスタを読むか」「結果をどこへ置くか」を判別します。その結果に応じて、レジスタ、ALU、ロード・ストア部などへ制御信号を出します。

4．レジスタから、処理に使う値を取り出す

レジスタはCPUコア内部にある小さな値の保持場所です。演算器が今すぐ使う値、メモリアドレス、計算途中の結果などを置きます。命令に「R1とR2を加えてR3へ」と書かれていれば、CPUはR1とR2のビットを読み、後段の演算回路へ渡します。

メモリはレジスタより大容量ですが、CPUから遠く、取得にはより長い待ち時間がかかります。その差を縮めるため、CPUとメインメモリの間に複数段のキャッシュがあります。レジスタ、キャッシュ、メモリはすべてデータを置けますが、CPUからの距離、容量、管理方法が違います。メインメモリの役割はメモリとはで補えます。

5．ALUまたはロード・ストア部が、命令どおりの変化を起こす

加算、減算、論理演算、比較などは、ALU（Arithmetic Logic Unit／算術論理演算装置）が担う代表的な処理です。メモリアドレスの計算や、レジスタとメモリ階層の間のデータ移動は、ロード・ストア部が担います。実際のCPUには、浮動小数点、ベクトル演算、分岐など用途別の実行ユニットもあります。

大切なのは、Execute（実行）が「何か大きな機能を完成させる」ことではなく、1個または内部で分解された命令が指定した状態変化を進めることです。Aを画面へ追加するだけでも、このような小さな状態変化が多数つながります。

6．結果を書き戻し、PCを次の位置へ進める

演算結果は宛先レジスタへ書き戻され、ストア命令ならメモリ階層へ書き込みが進みます。通常はPCを命令列の次へ進めます。分岐が成立した場合は、PCの基準を分岐先へ変えます。これで次のフェッチ先が決まり、同じ循環が続きます。

つまり「フェッチ・デコード・実行」は3枚の独立したカードではありません。PCが取得位置を決め、デコード結果がレジスタと実行回路を動かし、その結果がレジスタ・メモリ・PCを変え、次のフェッチにつながる循環です。

memo.txtへAを追加する命令を追ってみる

ここでは、キーボードの入力イベントがすでにOSからテキストエディタへ届き、エディタがUTF-8の作業用バッファへAを1バイト追加する、という単純な場面に絞ります。実際のエディタはもっと複雑ですが、CPUの役割は同じです。

次は、動きを見せるための架空の擬似命令です。特定のCPUでそのまま実行できるコードではありません。

LOAD    R1, [buffer_end_ptr]   ; 追記位置のアドレスをR1へ読む
STORE8  [R1], 0x41             ; Aを表す1バイトをバッファへ置く
ADD     R1, R1, 1              ; 次の追記位置を計算する
STORE   [buffer_end_ptr], R1    ; 更新した位置をメモリへ戻す

最初のLOADでは、デコーダがロード命令だと判別し、ロード・ストア部がメモリアドレスから値を取得してR1へ置きます。STORE8ではR1が示す位置へ0x41を書きます。ADDではALUがR1へ1を足します。最後のSTOREで、次回の追記位置をメモリへ戻します。

ここまでで変わったのは、実行中のエディタが持つメモリ上の作業データです。まだmemo.txtがストレージへ永続化されたとは限りません。画面の保存ボタンを押すと、別の機械語命令列が実行され、エディタは書き込み対象、バッファのアドレス、長さなどを用意してOSへ処理を依頼します。

CPUがファイル名を理解してSSDへ直接Aを刻むのではありません。CPUはアプリの命令を実行し、システムコール後はOS、ファイルシステム、ドライバの命令も実行します。ファイルとして扱う規則はソフトウェア側にあります。

アプリからOSへ制御が移る詳しい仕組みはシステムコールとは、パスやファイル名を保存領域へ結び付ける仕組みはファイルシステムとはで扱います。CPU記事の境界は、アプリ側でもOS側でも、CPUが実行する対象は機械語命令である、という点までです。

分岐は、PCの行き先を条件で変える命令

テキストエディタは「入力イベントなら文字を追加する」「保存イベントなら書き込みを依頼する」「終了イベントなら閉じる」のように処理を選びます。CPU上では、値を比較し、条件分岐命令によってPCの行き先を変えることで、この選択を実現します。

ループも同じです。PCを前の命令位置へ戻す分岐を使えば、イベント待ちや繰り返し処理になります。CPUが業務上の判断をしているのではなく、比較結果のビットに従って、次の命令アドレスを選んでいます。

クロックとパイプライン：1クロック＝1命令ではない

クロックは、CPU内部の回路が段階的に状態を受け渡すための時間の基準です。3GHzなら1秒あたり約30億サイクルですが、「1秒に必ず30億命令を完了する」という意味ではありません。命令によって必要な処理が違い、キャッシュミスや分岐予測の失敗などによる待ちもあるからです。

そこでCPUは、1個の命令がすべて終わるまで次を待つのではなく、工程を重ねます。これがパイプラインです。単純な3段モデルなら、次のように複数命令が同時に別工程を進みます。

これは説明用の単純化です。現代の高性能CPUは工程をさらに細かくし、1サイクルに複数命令を取り込み、独立した命令を複数の実行ユニットへ出すことがあります。分岐では行き先を予測して先の命令を取得し、予測を外したら途中の処理を破棄して正しい位置からやり直します。

アウト・オブ・オーダー実行でも、基本モデルは壊れない

ある命令がメモリ待ちになったとき、後ろにある独立した命令まで止める必要はありません。アウト・オブ・オーダー実行に対応したCPUは、依存関係を確認し、実行可能な後続命令を先に進めます。

ただし、ソフトウェアから見える結果は命令セットの規則やメモリ順序の規則を守る必要があります。多くのCPUは、内部では予測や並べ替えをしても、結果を確定する段階で整合を取ります。したがってフェッチ・デコード・実行は「各命令が時計どおり1列に進む実装図」ではなく、命令を受け取り、指定された状態変化を、CPUの規則に従って確定する論理モデルとして使うのが正確です。

CPUが実行する相手を決めるのはOS

テキストエディタ以外にもブラウザや常駐ソフトが動いているとき、どの処理へCPU時間を渡すかを決めるのはCPU自身ではなく、OSのスケジューラです。OSは実行可能なスレッドを選び、そのスレッドのPCや各レジスタ（スタック位置を示すレジスタを含む）などの実行文脈を、CPUで再開できる状態にします。

保存処理がストレージの完了待ちになると、エディタのスレッドはCPUを使わず待機し、OSは別の実行可能スレッドを動かせます。1つの論理CPUでは時間を分けて進め、複数コアがあれば複数の命令列を物理的に並行して実行できます。プロセスとスレッドの違いはプロセスとスレッドとは、OS全体の役割はOSとはでつなげて確認できます。

CPU使用率が示すのは「実行に使われた時間」

CPU使用率は、観測時間のうちCPUがどの程度、スレッドや割り込み処理などの実行に使われたかを見る指標です。高い状態が続けば実行したい処理がCPU能力に近づいている可能性がありますが、瞬間的な100%だけで異常とは決まりません。

反対に、memo.txtの保存が遅くてもCPU使用率が低い場合があります。スレッドがストレージ、ネットワーク、ロックなどを待っていれば、CPUは別処理やアイドルへ移れるためです。性能を見るときは、CPU使用率とともに、実行可能なのに待っているスレッド、I/O待ち、キャッシュミスなど、どこで命令の進行が止まったかを確認します。

ここまでで解消したい5つの誤解

Javaプログラムで見える変数やヒープも、最終的にはCPUが命令を実行して扱います。ただし、Java仮想マシンが管理する論理的な領域とCPUレジスタやキャッシュは同じものではありません。Java固有の続きを知りたい場合はJavaのメモリ管理へ進んでください。

まとめ：CPUとは、命令を状態変化へ変換する装置

memo.txtへAを入力して保存するとき、CPUが理解するのは「A」や「ファイル」ではありません。PCが示す位置から命令ビットを取得し、デコーダが使うレジスタと回路を選び、ALUやロード・ストア部が値を変え、結果と次のPCを確定します。この小さな循環を、アプリとOSの膨大な命令について高速に重ねた結果が、画面で見る「Aを保存できた」という動作です。

NISTの用語集でも、コンピュータはデジタルデータを受け取り、プログラムや命令列に基づいて情報を操作する装置と定義されています。ただし、この定義だけでは「処理の中で何が変わったのか」が見えません。そこで本記事では、memo.txtに「A」を追加して保存する1回の操作を、入力から永続化まで途切れずに追います。

CPUが「A」という文字の意味を理解しているわけではありません。文字や命令を表すビット列を、決められた規則どおりに読み、内部の状態を次の状態へ変えています。

コンピュータの本質は「情報を表す状態を変えること」

人は、画面に見える「A」を文字として理解します。しかし、コンピュータの部品が直接扱うのは文字の意味ではなく、区別できる物理的な状態です。回路の電圧、メモリやSSDの電荷、HDDの磁化などの状態を、コンピュータは0と1の組み合わせとして扱います。

重要なのは、ビット列だけでは意味が決まらないことです。たとえば01000001は、10進数の65とも、UTF-8の文字「A」とも解釈できます。どの規則で読むかによって、同じ並びの意味が変わります。

そして、データだけでなくプログラムの命令も、コンピュータ内では符号化されたビット列です。CPUは命令を取り出して実行し、レジスタやメモリの状態を変えます。つまり、コンピュータの動作を一段深く言い直すと、「命令を表す状態」に従って、「データを表す状態」を別の状態へ変えることです。

「A」は最初から01000001として届くわけではない

ここは混同しやすい点です。キーボードのAキーを押すと、まず「どのキーが、どの修飾キーとともに操作されたか」を表す入力イベントが発生します。キーボード配列、Shiftキー、入力モードなどをOSやアプリが解釈して、初めて文字「A」が決まります。

文字が決まった後、その文字を保存・通信できる数値へ対応づけるのが文字コードです。Unicodeの公式解説では、ラテン大文字のAにU+0041というコードポイントが割り当てられています。UTF-8でファイルへ保存する場合、Aは次の1バイトになります。

memo.txtに「A」を追加して保存するまで

0．入力前から、命令とデータは動いている

テキストエディタを開いた時点で、すでに準備は始まっています。エディタのプログラムはストレージから読み出され、実行に必要な命令やデータがメモリへ置かれます。memo.txtの内容も読み込まれ、編集用のデータとしてメモリ上に保持されます。

この段階で区別したいのは、ストレージ上の元ファイルと、メモリ上の編集中データです。エディタは通常、SSD上の文字を直接その場で削ったり足したりしているのではなく、まず作業用の状態をメモリに持ちます。

1．キー操作が入力イベントとして届く

Aキーを押すと、その操作が電気信号として機器から届き、OSを介してテキストエディタへ入力イベントが渡ります。エディタは現在のカーソル位置や入力モードを確認し、「編集中の文字列へAを追加する」という処理を選びます。

2．CPUが命令を実行し、メモリ上の編集中データが変わる

CPUには「Aを追記する」という人間向けの命令が一つだけ用意されているわけではありません。エディタを構成する多数の機械語命令を順番に実行し、文字の値をレジスタへ読み込み、メモリ上の適切な位置へ書き、文字列の長さやカーソル位置なども更新します。

結果として、メモリ上の編集状態が「Aを含まない状態」から「末尾にAを含む状態」へ変わります。これが、この例における「処理」の中心です。CPUが命令を取り出して実行する循環はCPUとは、実行中の命令とデータを置く場所はメモリとはで掘り下げています。

3．メモリ上の結果が、画面の「A」として出力される

エディタは更新した文字データをもとに、どの形・色をどの位置へ描くかを決めます。その描画データが画面側へ渡り、画素の状態が変わることで、人には「A」が見えます。

ここで画面にAが見えていても、memo.txtへの保存が完了したとは限りません。確実に変わったのは、まずメモリ上の編集中データと画面表示です。保存前にアプリを強制終了すると入力内容が消えることがあるのは、この二つと永続化が別だからです。

4．保存操作を受けると、アプリがOSへ書き込みを依頼する

保存ボタンやCtrl+Sも、新しい入力です。エディタはメモリ上の文字列を指定された文字コードのバイト列へ変換し、OSへ「この内容をmemo.txtとして書き込みたい」と依頼します。

アプリがOSへ処理を依頼する境界はシステムコール、ファイル名と保存領域を対応づける仕組みはファイルシステムの記事で詳しく説明しています。実際のエディタが元ファイルを直接更新するか、一時ファイルを作って置き換えるかなど、具体的な保存方法はアプリによって異なります。

5．ストレージの状態が変わると、電源を切っても残る

OSは書き込み要求を整理し、デバイスドライバやストレージの制御装置を通じて、SSDやHDDへデータを渡します。最終的に媒体上の電荷や磁化などの状態へ反映されると、電源を切った後にmemo.txtを開き直してもAを復元できます。長期保存を担う媒体側の仕組みはストレージとはでつながります。

入力・処理・記憶・出力を、状態変化として言い直す

この整理なら、「記憶」は最後に一度だけ起きる工程ではないと分かります。CPUが次の命令を実行できるのも途中状態がメモリにあるからで、保存後に内容を復元できるのもストレージが状態を保つからです。

ハードウェア・ソフトウェア・データ・OSは何が違うのか

同じ流れを「何が状態を持ち、何が変え方を決めるのか」という視点で分けると、各用語の関係が見えます。

NISTが定義するハードウェアは物理的な構成要素です。一方、ソフトウェアは命令と関連データです。ただし、これは材質の違いではなく役割の違いでもあります。プログラムはソフトウェアですが、ストレージやメモリに置かれているときは、ほかのデータと同じようにビット列として保持されます。

また、アプリがCPU・メモリ・SSDを好き勝手に使うと、ほかのアプリのデータや動作を壊しかねません。そこでOSが、資源の共有、保護、機器ごとの差の吸収を担当します。本記事では全体の受け渡しだけを扱い、OS内部の保護やスケジューリングは個別記事へ委ねます。

この見方ができると、不具合の場所を切り分けられる

入力から永続化までを一つの塊にせず、「どの状態までは変わったか」で見ると、問題の範囲を絞れます。

「パソコンが遅い」で終わらせず、入力・メモリ上の処理・画面出力・保存のどこで状態変化が止まったかを見る。これが、性能や障害を調べるときの土台になります。

パソコン以外も、同じ原理で考えられる

スマートフォンも、画面へのタッチを入力として受け、プログラムの命令に従って内部状態を変え、画面・音・通信へ出力します。サーバーは手元に画面がなくても、ネットワークから要求を入力として受け、処理結果を応答データとして出力するコンピュータです。

コンピュータ同士がビット列を受け渡す仕組みはネットワークとは、他のコンピュータへサービスを提供する役割はサーバーとはへ進むと、今回の全体像がそのまま広がります。

まとめ：コンピュータとは何をしている装置か

コンピュータとは、単にCPU・メモリ・SSDを集めた箱ではありません。情報を表す状態と、その状態をどう変えるかを示す命令を受け取り、物理的な状態変化を積み重ねて目的の結果を作る装置です。この軸を持つと、CPU、メモリ、OS、ファイル、ネットワークといった個別の仕組みを、ばらばらな用語ではなく一続きの因果として理解できます。

ただし、OSがアプリの命令を一つずつ代わりに実行しているわけではありません。通常の命令はCPUがアプリのコードとして直接実行し、ファイル保存のように権限が必要な処理、例外、機器からの通知が発生したところで、OSの中核であるカーネルが処理へ入ります。

OSを「アプリとハードウェアの間にある中継役」と覚えるだけでは、動きは見えてきません。この記事では、テキストエディタでmemo.txtに「A」を入力して保存する1回の操作を、アプリ起動から保存完了まで途切れずに追います。

OSが必要な理由は「抽象化・共有・保護」

NISTの用語集は、OSをハードウェア資源を管理し、プログラムへ共通サービスを提供するソフトウェア群と整理しています。ここでいう資源は、CPUの実行時間、物理メモリ、ストレージ、画面、キーボード、ネットワーク機器などです。

OSの必要性は、OSがない世界を考えると見えてきます。テキストエディタがSSDの機種ごとの命令を知り、空いているメモリを自力で探し、ブラウザとCPUを取り合い、別アプリのデータを壊さないよう自分で防ぐ――これでは、アプリを1本作るたびにコンピュータ全体の制御を作り直すことになります。

OSはアプリの処理へ毎回割り込むわけではない

OSを理解するときに最も重要なのは、アプリが動く時間と、カーネルが動く時間を分けて考えることです。一般的なデスクトップOSでは、アプリは制限された「ユーザーモード」、カーネルや多くのドライバは強い権限を持つ「カーネルモード」で実行されます。

Microsoftの説明でも、ユーザーモードのプロセスには私有の仮想アドレス空間が与えられ、OS用の領域へはアクセスできないとされています。この境界はアプリの自主性だけに任せるのではなく、CPUの実行モードやメモリ管理機構によって強制されます。

カーネルが処理へ入る主なきっかけは次の3つです。

つまりOSは、アプリの横で全命令を中継する常駐係ではありません。OSは先にプロセスの境界やメモリの対応表を用意し、CPU時間を割り当て、その範囲ではアプリを走らせます。そして必要な地点だけ、制御された入口からカーネル処理へ移ります。

memo.txtに「A」を保存するまでを一気に追う

ここからは、デスクトップのmemo.txtを開き、「A」を入力して保存する流れを追います。Windows、macOS、Linuxで名称や実装は異なるため、以下は共通部分をつないだモデルです。具体的なシステムコール名や、エディタが一時ファイルを使うかどうかまでは製品ごとに変わります。

1. エディタを「プロセス」として起動する

memo.txtをダブルクリックすると、まずデスクトップを管理するプログラムが拡張子の関連付けからテキストエディタを選び、OSのプロセス作成機能を呼び出します。WindowsのCreateProcessを例にすると、新しいプロセスと最初のスレッドが作られます。

このときOSは、エディタ専用の仮想アドレス空間を用意し、実行ファイルや共有ライブラリをその空間へ対応付けます。「プログラム全体を最初にRAMへ丸ごとコピーする」とは限りません。必要になったページを後から読み込む方式も使われます。

仮想アドレスは、アプリが見るメモリ上の住所です。CPUはOSが管理する対応表を使って仮想アドレスを物理メモリへ変換します。そのため、別のアプリが同じ数値の仮想アドレスを使っていても、通常は別の物理領域へ対応し、互いのデータへ勝手に触れません。プロセスとスレッドの境界はプロセスとスレッドの解説で詳しく扱います。

2. スケジューラがスレッドへCPU時間を渡す

プロセスを作っただけでは、エディタはまだ命令を実行できません。実際にCPUで動く候補はスレッドであり、OSのスケジューラが実行可能なスレッドから次に動かすものを選びます。

エディタのスレッドが選ばれると、CPUは保存ボタンの表示、入力処理、文字列編集など、アプリ自身の命令をユーザーモードで実行します。「A」を入力すると、キーボード側の通知がドライバや画面システムを経て入力イベントとなり、エディタは文字コードで表された「A」を自分の仮想メモリ上の編集データへ反映します。この時点の「A」は、まだmemo.txtの永続データではありません。

CPUコアより動かしたいスレッドが多ければ、タイマー割り込みなどを契機にスケジューラが切り替えます。その際は、実行途中のレジスタ状態などを保存し、別のスレッドの状態を復元します。短い切り替えを重ねることで、多数のアプリが並行して動いて見えます。

3. 保存APIからシステムコールへ進む

保存ボタンを押すと、エディタはまず自分やライブラリが提供する保存APIを呼びます。そこから最終的に、ファイルを開く・書く・名前を変更する・同期するといったOSの処理が必要になり、1回以上のシステムコールへ進みます。

システムコールは、普通の関数呼び出しを難しく言い換えたものではありません。専用の命令やOS固有の仕組みによってCPUがカーネル側の入口へ移り、カーネルは渡されたハンドル、メモリアドレス、長さ、アクセス権などを検証します。不正な書き込み先や権限のないファイルなら、要求を拒否してエラーを返します。

ここが保護の要です。アプリに強い権限を渡すのではなく、「何をしたいか」を一度カーネルへ申請させ、OSが条件を確認してから処理します。APIとシステムコールが1対1とは限らない点も重要です。

ユーザーモードからカーネルモードへ移る仕組みは、システムコールの解説で、ラッパー関数・引数・戻り値まで掘り下げます。

4. VFSとファイルシステムが「名前」を保存領域へ結び付ける

カーネルへ入ると、ファイル操作はそのOSのVFS（Virtual File System）に相当する共通層や、各ファイルシステムの処理へ渡ります。この層は、NTFS、APFS、ext4、ネットワークファイルシステムなど、そのOSが扱う実装の違いを共通のファイル操作へまとめます。LinuxカーネルのVFS資料でも、ユーザー空間へファイルシステムの共通インターフェースを提供し、異なる実装を共存させる抽象化層と説明されています。

OSは、memo.txtのパスや既に開いているファイルのハンドルから、対象のファイル、メタデータ、書き込み位置を特定します。ここで確認しているのは「名前の文字列」だけではありません。どのファイルシステムに属するか、どの利用者に権限があるか、ファイルのどの位置へ何バイト書くかを、カーネル内部のオブジェクトへ対応付けます。

一般的なバッファ付きI/Oでは、書き込む内容はいったんRAM上のページキャッシュへ反映され、「まだストレージへ書き戻していない変更」として管理されます。これにより、小さな書き込みをまとめたり、アプリを長く待たせずに処理したりできます。ファイル名から保存領域へたどる詳細はファイルシステムの解説、一時領域を挟む理由はバッファの解説へつながります。

5. ドライバが要求を機器固有の命令へ変え、完了を待つ

ページキャッシュの変更を書き戻す段階になると、ファイルシステムは論理的な保存位置に対するI/O要求を組み立てます。要求はOSのI/O層やキューを経て、ストレージ用のデバイスドライバへ渡ります。

ドライバは、共通的な「このデータをこの位置へ書きたい」という要求を、接続方式や制御装置が理解できるコマンドへ変換します。必要なら転送用のメモリ領域やDMAを設定し、ストレージ制御装置へ処理開始を指示します。制御装置と機器内のファームウェアが、実際のデータ転送やNANDフラッシュなど媒体への書き込みを進めます。

I/O完了まで待つ必要がある場合、エディタのスレッドは待機状態にでき、スケジューラはそのCPUを別の実行可能なスレッドへ渡せます。ストレージ側の処理が終わると、多くの構成では制御装置が割り込みで完了を通知します。高性能I/Oなどではポーリングで完了を確かめる方式もあります。

カーネルは完了した要求の状態を更新し、待っていたスレッドを実行可能に戻します。スケジューラが再びそのスレッドを選ぶと、システムコールからユーザーモードへ戻り、エディタは成功または失敗を受け取ります。この「要求を出す・待つ・完了通知で再開する」全体像はI/O（入出力）の解説につながります。

6. 「保存成功」と「電源断後も残る」は同じとは限らない

ここで、保存の理解をもう一段正確にします。Linuxの一般的なバッファ付きI/Oでは、カーネル資料にあるとおり、ファイル内容はページキャッシュに置かれ、変更済みのページは後からストレージへ書き戻されます。したがって、通常の書き込み要求が成功した時点で、データが必ず不揮発性媒体へ到達したとは限りません。

耐障害性が必要なアプリは、OSに同期を依頼し、必要なデータやメタデータ、機器内キャッシュまで書き出させます。たとえばLinuxのfsyncは、変更済みデータと必要なメタデータを永続ストレージへ同期し、機器が完了を報告するまで待つためのシステムコールです。

ストレージ内部でビットを保持する仕組みや書き込みキャッシュの役割は、ストレージの解説で扱います。

OSの各機構は3つの目的へどう結び付くか

ここまで登場した用語を、機能名の暗記ではなく「なぜ必要か」で整理します。

この表の出力が次の機構の入力になります。プロセスを用意してもスケジューラがCPUを渡さなければ動かず、システムコールを受けてもファイルシステムが保存先を解決しなければ書けず、ドライバが要求を出しても完了処理がなければ待っているアプリへ結果を返せません。OSは、これらを一続きの制御として成立させています。

OS・カーネル・ドライバ・ファームウェアの境界

「どこまでがOSか」は製品や説明の文脈で多少変わります。初心者がまず区別したい境界は次のとおりです。

OSとカーネルは同義ではありません。また、ドライバの多くはカーネルモードで動きますが、すべてのドライバが必ずカーネルモードとは限りません。重要なのは、「アプリ → OSの共通窓口 → ドライバ → 制御装置・ファームウェア」という役割の変換を追うことです。

画面のないサーバーでも、この資源管理は同じように必要です。また、Dockerコンテナは、独立したプロセス環境を見せながら、基本的にはホスト側のOSカーネルを共有します。OSの抽象化・共有・保護を理解すると、コンテナが「軽い仮想マシン」とだけ説明されると不十分な理由も見えてきます。

実際の画面ではOSの何を見ているのか

Windowsのタスクマネージャー、リソースモニター、Linuxのtopやpsは、OSが持つ管理情報を見やすく表示しています。数値を「PCが重い」の一言でまとめず、どの資源の状態かへ戻すと理解しやすくなります。

CPU使用率が低いからアプリが何もしていない、とは限りません。スレッドがストレージの完了を待っていればCPUを使わずに止まって見えます。逆にCPU使用率が高いことは、OSが遅いという意味ではなく、そのスレッドがCPU時間を多く得ている状態です。OSへコマンドで問い合わせる入口はコマンドプロンプト入門で確認できます。

まとめ：OSは資源を「使える世界」に作り替える

OSとは、単にアプリとハードウェアの間へ置かれた仲介ソフトではありません。アプリには「自分専用のメモリ」「共通のファイル」「使えるCPU」があるように見せながら、裏では実物の資源を割り当て、競合を整理し、越えてはいけない境界を守る仕組みです。だから複数のアプリが同じコンピュータ上で、機器の細部を知らずに、安全かつ同時に動けます。

重要なのは、バッファ自体が受け手を速くするわけではないことです。バッファは、短時間の速度差を吸収し、小さなデータをまとめ、送り手と受け手が同時に動かなくてもよい時間を作ります。ただし、送り手の平均速度が受け手を上回り続ければ、有限のバッファはいつか必ず満杯になります。

バッファは「待合室」に似ています。診察を速くするのではなく、到着のばらつきを受け止めます。待合室が満員になったら、入口で待ってもらう、受付を断る、別の場所へ案内する、といった方針が必要です。

まず全体像：送り手、バッファ、受け手で考える

バッファを理解する最小モデルは、次の3要素です。

「バッファ」と「キュー」は完全な同義語ではありません。バッファはデータを置く領域、キューはデータを並べて取り出す規則や構造です。ただし、処理待ちデータを入った順に扱うバッファは、実質的にFIFOキューとして動きます。

なぜバッファが必要なのか

1. 一時的な速度差を吸収する

送り手は一定速度でデータを作るとは限りません。短い時間に集中して作ることもあれば、受け手が別の処理で一時的に止まることもあります。バッファに空きがあれば、その短いずれの間も送り手はすぐに停止せず、受け手は後から順に処理できます。

ただし、吸収できるのは容量の範囲内の一時的な差だけです。バッファは、遅い受け手を速くしたり、処理能力の不足を消したりはしません。

2. 小さな処理をまとめる（バッチ化）

I/Oには、データ量に比例する時間だけでなく、「処理を1回依頼する」たびにかかる固定的な手間があります。1バイトごとに下位層へ依頼するより、バッファへためてまとまった単位で渡すほうが、呼び出し回数や管理処理を減らせます。

JavaのBufferedOutputStream公式仕様も、各バイトの書き込みごとに下位システムを呼ばずに済むことを目的として説明しています。LinuxのブロックI/O層でも、隣接する要求をまとめて個別要求数を減らす場合があります。

3. 送り手と受け手の時刻を切り離す（疎結合）

バッファがなければ、送り手は受け手がその場で処理を終えるまで待つ必要があります。バッファがあれば、送り手は「受け付けてもらった」時点で次へ進み、受け手は自分の都合で取り出せます。これが時間方向の疎結合です。

容量は「どれだけ速いか」ではなく「何秒しのげるか」

バッファの挙動は、次の4つで考えると整理できます。

単純化すると、一定時間の占有量の増加は「到着した量 − 処理できた量」です。たとえば、送り手が毎秒100件、受け手が毎秒80件、空のバッファ容量が100件なら、差の毎秒20件ずつ増え、5秒で満杯になります。

満杯までの時間 ≒ 空き容量 ÷（到着率 − 処理率）

例：100件 ÷（100件/秒 − 80件/秒）＝ 5秒
※到着率が処理率を上回る単純な一定モデル

この例で容量を1,000件へ増やせば50秒しのげますが、原因である毎秒20件の能力不足は残ります。50秒後にはやはり満杯です。逆に、平均では処理率のほうが高くても、短時間の到着集中を吸収するためにバッファは役立ちます。

大きいバッファほど待ち時間も大きくなり得る

バッファに並ぶ量が多いほど、後ろのデータは長く待ちます。単純なFIFOで前に40件あり、受け手が毎秒80件処理するなら、処理時間のばらつきを無視した待ち時間は約0.5秒です。容量を増やすことはバースト耐性を高める一方で、遅延、メモリ使用量、未処理データの損失範囲も増やし得ます。

空なら受け手が待つ（アンダーフロー）

受け手が取り出そうとしたときにバッファが空なら、受け手は待つか、空であることを示す結果を受け取ります。音声・動画の再生では、次のデータが間に合わず再生が途切れる状態をバッファアンダーラン（アンダーフロー）と呼ぶことがあります。これは満杯とは逆向きの問題です。

満杯になる前に返す信号がバックプレッシャー

バッファが満杯になってから慌てるのではなく、占有量が一定のしきい値へ達したら送り手を遅くする仕組みがバックプレッシャーです。たとえば80%を高水位（high-water mark）として書き込みを一時停止し、50%の低水位まで減ったら再開します。2つのしきい値を分けるのは、境界付近で停止と再開を何度も繰り返さないためです。

Pythonのasyncio StreamWriterでは、書き込みバッファが高水位へ達するとdrain()が待ち、低水位まで減ると再開します。これは「下流が追いつくまで上流を待たせる」というバックプレッシャーの具体例です。

JavaのBlockingQueue公式仕様は、空きができるまで待つ、特別な値を返す、例外にする、一定時間だけ待つ、という複数の方針をAPIとして分けています。満杯は単なる状態であり、そのとき何を守るかは設計判断です。

memo.txtにAを保存するとき、バッファは何層あるのか

ここからは、テキストエディタでmemo.txtへAを追記して保存する流れを追います。実際のエディタは一時ファイルを作って置換する安全保存、メモリマップドI/O、独自APIなどを使う場合があります。以下は、バッファ付きファイルI/Oの基本モデルです。

第1層：エディタの編集中データ

入力したAは、まずエディタのメモリ上の文書モデルや編集領域へ反映されます。この時点では画面に見えていても、ファイルへの出力はまだ始まっていないかもしれません。編集内容を保持する領域と、下位層へ出力するためのバッファは目的が異なります。

第2層：言語・ライブラリの出力バッファ

保存操作で文字を文字コードに従ったバイト列へ変換し、標準I/OやBufferedOutputStreamのようなバッファ付き出力へ渡すことがあります。ここでは小さな書き込みをまとめ、下位ストリームやOSへの呼び出し回数を減らします。

C/POSIXの標準I/Oには完全バッファ、行バッファ、非バッファの方式があり、setvbuf()で方式を指定できます。fflush()、Pythonのファイルオブジェクトのflush()、JavaのBufferedOutputStream.flush()は、この層に残る出力を下位のストリームへ渡します。

第3層：システムコールとLinuxのページキャッシュ

ライブラリが下位へ書くと、最終的にはwrite相当のシステムコールでOSへ依頼します。Linuxの通常のbuffered I/Oでは、ファイル内容はメモリ上のページキャッシュへ反映され、更新済みで媒体へ未反映のページはdirtyとして管理されます。

この段階のwrite成功は、OSがデータを受け付けたことを意味し得ますが、不揮発性媒体への定着完了とは限りません。Linuxカーネル文書も、ページキャッシュ上のdirtyデータは後からwritebackされ、fsync等で強制できると説明しています。

第4層：writebackとブロックI/O要求キュー

OSはdirtyデータを書き戻す時期を決め、ファイルシステムが論理位置をストレージ上の領域へ対応付け、ブロックI/O要求を作ります。Linuxのblk-mqでは、要求をソフトウェア側の待ち行列とハードウェア側のディスパッチキューで管理し、隣接要求の結合や並列投入を行えます。

ここでも、要求がキューに入ったこと、装置へ送られたこと、装置が完了を返したことは別の時点です。装置固有の命令や完了通知へつなぐ役割はデバイスドライバが担います。

第5層：ストレージ装置内の揮発性書き込みキャッシュ

SSDやHDDの制御装置は、装置内の高速な書き込みキャッシュへ受け取った時点で、OSへ完了を返す場合があります。そのキャッシュが揮発性なら、データはまだNANDフラッシュや磁気媒体へ定着しておらず、突然の電源断で失われる可能性があります。

Linuxのブロック層は、データ整合性が必要な操作で装置の揮発性キャッシュを排出するflush要求や、対象書き込みを不揮発性媒体へ反映してから完了させるFUAを扱います。具体的な保証は、OS、ファイルシステム、ドライバ、装置の対応、電源断保護の有無で決まります。

flushは「どの層から、どの層へ」なのか

flushという語だけでは、到達先は決まりません。flushは、そのAPIや層が持つ保留データを、定義された次の層へ進める操作です。したがって、「flushしたからSSDへ残った」とは限りません。

Python公式文書は、バッファ付きファイルfをディスクへ同期したい場合、まずf.flush()を行い、その後os.fsync(f.fileno())を呼ぶ順序を示しています。JavaのFileDescriptor.sync()も、アプリ内のBufferedOutputStreamに残るデータを先にflush()しなければ、そのデータは同期の対象にならないと明記しています。

# Pythonで「上位バッファを出す」→「OSへ同期を要求する」を分ける例
import os

with open("memo.txt", "a", encoding="utf-8") as f:
    f.write("A")
    f.flush()                 # Python側のバッファから下位へ
    os.fsync(f.fileno())      # 開いたファイルをストレージへ同期するよう要求

バッファとキャッシュは目的で見分ける

ただし、同じメモリ領域が両方の役割を持つことがあります。Linuxのページキャッシュは、読み出した内容を再利用する点ではキャッシュです。一方、書き込みをいったん受け止めて後でwritebackする点ではバッファの性質も持ちます。名前だけで決めず、その場面で何を待たせ、何を再利用しているかを見ます。より詳しい違いはキャッシュとはで確認できます。

「大きくすれば速い」とは限らない

バッファを大きくすると、より長いバーストを吸収し、まとめる単位を増やせる場合があります。しかし、性能の最適値は処理内容によって変わります。

必要容量は、「平均負荷の何倍」という決め方ではなく、許容するバーストの大きさ・継続時間、下流の処理率、許容待ち時間、欠落の可否から決めます。ファイルI/Oなら、バッファサイズごとのスループットだけでなく、flushの待ち時間、データが外部から見えるまでの遅れ、エラーが表面化する時点も測ります。

不調時は「量・速さ・方針」を観測する

バッファが原因かを判断するには、「バッファがある」という設定値だけでなく、流れを観測します。

• 現在の占有量と増減傾向：満杯へ向かって増え続けているか
• 到着率と処理率：どの時間帯に差が生まれるか
• 高水位到達回数：バックプレッシャーがどれほど頻繁に働くか
• 送り手の待ち時間：ブロックが上流の応答時間へどう伝わるか
• 拒否・破棄・上書き件数：見えないデータ損失が起きていないか
• キュー内待ち時間：処理そのものより待ちが支配していないか
• flush・writeback・同期の所要時間：どの境界が詰まっているか
• 下流のエラー：上位の書き込み成功後に遅れて表面化していないか

ログがすぐ表示されない場合は、処理が止まったとは限りません。行バッファの改行条件、完全バッファの満杯条件、明示的なflush、正常終了時のcloseのどこで出力されるかを確認します。逆に、出力が見えたことも媒体への永続化を意味しません。

よくある誤解を因果で直す

まとめ：バッファは「待ち時間を管理する有限の境界」

バッファの本質は、データをためること自体ではありません。 どこで一時的に待たせ、どの単位で次へ渡し、満杯時に誰を止め、どの完了を利用者へ約束するかを制御することです。memo.txtのAがどの層にいるかを問い直せば、速さ、遅延、欠落、永続化を同じ「流れ」の問題として説明できます。

関連する基礎用語

• I/O（入出力）とは：送り手と受け手の間で何が受け渡されるのかを確認する
• キャッシュとは：再利用を目的とする一時保存との違いを深掘りする
• ファイルシステムとは：ページキャッシュ、writeback、fsyncをファイル保存の流れとして確認する
• ストレージとは：制御装置、装置内キャッシュ、不揮発性媒体の違いを確認する
• システムコールとは：アプリの書き込みがOSへ渡る保護境界を確認する
• デバイスドライバとは：OSのI/O要求が装置固有の命令へ変換される仕組みを確認する