OS（Operating System／オペレーティングシステム）とは、CPU・メモリ・ファイル・機器を、複数のアプリが安全に使える形へ整える基本ソフトウェアです。Windows、macOS、Linux、Android、iOSはいずれもOSの製品・系統です。OSの本質は、難しい違いを隠す「抽象化」、限られた資源を分ける「共有」、勝手な操作を止める「保護」の3つにあります。
ただし、OSがアプリの命令を一つずつ代わりに実行しているわけではありません。通常の命令はCPUがアプリのコードとして直接実行し、ファイル保存のように権限が必要な処理、例外、機器からの通知が発生したところで、OSの中核であるカーネルが処理へ入ります。
OSを「アプリとハードウェアの間にある中継役」と覚えるだけでは、動きは見えてきません。この記事では、テキストエディタでmemo.txtに「A」を入力して保存する1回の操作を、アプリ起動から保存完了まで途切れずに追います。
OSが必要な理由は「抽象化・共有・保護」
NISTの用語集は、OSをハードウェア資源を管理し、プログラムへ共通サービスを提供するソフトウェア群と整理しています。ここでいう資源は、CPUの実行時間、物理メモリ、ストレージ、画面、キーボード、ネットワーク機器などです。
OSの必要性は、OSがない世界を考えると見えてきます。テキストエディタがSSDの機種ごとの命令を知り、空いているメモリを自力で探し、ブラウザとCPUを取り合い、別アプリのデータを壊さないよう自分で防ぐ――これでは、アプリを1本作るたびにコンピュータ全体の制御を作り直すことになります。
| OSの仕事 | 何を隠す・調整するか | memo.txtの例 |
|---|---|---|
| 抽象化 | 機器・ファイルシステムごとの違いを、共通の操作へまとめる | エディタはSSDの型番を知らなくても「ファイルへ書く」と依頼できる |
| 共有 | CPU、メモリ、I/O装置など有限の資源を、複数の処理へ割り当てる | 保存待ちの間に、ブラウザや別のアプリをCPUで実行できる |
| 保護 | アプリが触れられるメモリ、ファイル、機器、権限を制限する | エディタが権限のないファイルやOS内部のメモリを書き換えるのを防ぐ |
OSはアプリの処理へ毎回割り込むわけではない
OSを理解するときに最も重要なのは、アプリが動く時間と、カーネルが動く時間を分けて考えることです。一般的なデスクトップOSでは、アプリは制限された「ユーザーモード」、カーネルや多くのドライバは強い権限を持つ「カーネルモード」で実行されます。
Microsoftの説明でも、ユーザーモードのプロセスには私有の仮想アドレス空間が与えられ、OS用の領域へはアクセスできないとされています。この境界はアプリの自主性だけに任せるのではなく、CPUの実行モードやメモリ管理機構によって強制されます。
カーネルが処理へ入る主なきっかけは次の3つです。
| きっかけ | 何が起きたか | memo.txtとの関係 |
|---|---|---|
| システムコール | アプリがOSへ、権限の必要な処理を明示的に依頼した | ファイルを開く、書く、同期するなどを依頼する |
| 例外 | 実行中に、カーネルの助けが必要な事象が起きた | まだRAMへ対応付けられていない仮想メモリを初めて参照し、ページフォールトが起きる場合がある |
| 割り込み | タイマーや機器が、CPUへ処理の必要を通知した | キーボード入力、CPU時間の切り替え、I/O完了の通知などに使われる |
つまり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では、カーネル資料にあるとおり、ファイル内容はページキャッシュに置かれ、変更済みのページは後からストレージへ書き戻されます。したがって、通常の書き込み要求が成功した時点で、データが必ず不揮発性媒体へ到達したとは限りません。
| 段階 | 「A」はどこにあるか | 何が言えるか |
|---|---|---|
| 編集直後 | 主にエディタのプロセス内メモリ | 画面には見えるが、ファイルへは未反映 |
| 書き込み受付後 | OSのページキャッシュなど | ファイル操作は成功しても、媒体への書き戻し前の場合がある |
| 同期・フラッシュ完了後 | 機器が完了を保証する不揮発性の範囲 | 電源断後も取得できることを意図した段階。ただし機器・ファイルシステムの保証に従う |
耐障害性が必要なアプリは、OSに同期を依頼し、必要なデータやメタデータ、機器内キャッシュまで書き出させます。たとえばLinuxのfsyncは、変更済みデータと必要なメタデータを永続ストレージへ同期し、機器が完了を報告するまで待つためのシステムコールです。
ストレージ内部でビットを保持する仕組みや書き込みキャッシュの役割は、ストレージの解説で扱います。
OSの各機構は3つの目的へどう結び付くか
ここまで登場した用語を、機能名の暗記ではなく「なぜ必要か」で整理します。
| 機構 | 入力 | OSが行うこと | 主な目的 |
|---|---|---|---|
| プロセス・仮想メモリ | 起動するプログラム | 実行環境と私有のアドレス空間を作る | 保護・抽象化 |
| スケジューラ | 実行可能・待機中のスレッド | 次にCPUで動かすスレッドを選ぶ | 共有 |
| システムコール | アプリの要求と引数 | 権限と引数を検証し、カーネル機能へ渡す | 保護・抽象化 |
| VFS・ファイルシステム | パス、ハンドル、書き込み内容 | 名前とファイル、保存位置を対応付ける | 抽象化・保護 |
| I/O層・ドライバ | 論理的なI/O要求 | 要求を並べ、機器固有の操作へ変換する | 共有・抽象化 |
| 割り込み・完了処理 | 機器やタイマーからの通知 | 必要な処理を行い、待機中スレッドを再開可能にする | 共有 |
この表の出力が次の機構の入力になります。プロセスを用意してもスケジューラがCPUを渡さなければ動かず、システムコールを受けてもファイルシステムが保存先を解決しなければ書けず、ドライバが要求を出しても完了処理がなければ待っているアプリへ結果を返せません。OSは、これらを一続きの制御として成立させています。
OS・カーネル・ドライバ・ファームウェアの境界
「どこまでがOSか」は製品や説明の文脈で多少変わります。初心者がまず区別したい境界は次のとおりです。
| 名称 | 主な役割 | memo.txt保存時の例 |
|---|---|---|
| OS | カーネル、システムサービス、標準機能などを含む基本ソフトウェア全体 | プロセス、メモリ、ファイル、I/O、権限を一体として管理する |
| カーネル | 強い権限で資源管理と保護境界を担うOSの中核 | システムコールを受け、検証・スケジューリング・I/Oを統制する |
| デバイスドライバ | OSの共通要求と機器固有の操作を接続するソフトウェア | 書き込み要求をストレージ制御装置向けの処理へ変換する |
| ファームウェア | 機器内などで、その機器の低レベル制御を行うソフトウェア | SSD内部でアドレス変換、誤り訂正、NAND管理などを行う |
| ハードウェア | CPU、RAM、制御装置、記憶媒体など物理的な回路 | 命令実行、データ転送、電気的状態の保持を行う |
OSとカーネルは同義ではありません。また、ドライバの多くはカーネルモードで動きますが、すべてのドライバが必ずカーネルモードとは限りません。重要なのは、「アプリ → OSの共通窓口 → ドライバ → 制御装置・ファームウェア」という役割の変換を追うことです。
画面のないサーバーでも、この資源管理は同じように必要です。また、Dockerコンテナは、独立したプロセス環境を見せながら、基本的にはホスト側のOSカーネルを共有します。OSの抽象化・共有・保護を理解すると、コンテナが「軽い仮想マシン」とだけ説明されると不十分な理由も見えてきます。
実際の画面ではOSの何を見ているのか
Windowsのタスクマネージャー、リソースモニター、Linuxのtopやpsは、OSが持つ管理情報を見やすく表示しています。数値を「PCが重い」の一言でまとめず、どの資源の状態かへ戻すと理解しやすくなります。
| 表示・観測対象 | OS内部では何を見ているか | 保存が遅いときの読み方 |
|---|---|---|
| プロセス一覧 | OSが管理する実行環境、PID、状態 | エディタ自体が応答しているか、終了しているかを確認する |
| CPU使用率 | 各スレッドがCPUで実行された時間 | 高ければ計算や繰り返し処理、低くてもI/O待ちの可能性がある |
| メモリ | 仮想メモリ、物理メモリ上の常駐量、ページング | メモリ圧迫や大量のページフォールトがないかを見る |
| ディスク活動 | I/O要求の量、転送量、応答時間、待ち | 保存時にストレージI/Oが詰まっていないかを見る |
| イベントログ・カーネルログ | ファイルシステム、ドライバ、機器が報告した状態 | 権限、容量不足、媒体・ドライバのエラーを探す |
CPU使用率が低いからアプリが何もしていない、とは限りません。スレッドがストレージの完了を待っていればCPUを使わずに止まって見えます。逆にCPU使用率が高いことは、OSが遅いという意味ではなく、そのスレッドがCPU時間を多く得ている状態です。OSへコマンドで問い合わせる入口はコマンドプロンプト入門で確認できます。
まとめ：OSは資源を「使える世界」に作り替える
OSとは、単にアプリとハードウェアの間へ置かれた仲介ソフトではありません。アプリには「自分専用のメモリ」「共通のファイル」「使えるCPU」があるように見せながら、裏では実物の資源を割り当て、競合を整理し、越えてはいけない境界を守る仕組みです。だから複数のアプリが同じコンピュータ上で、機器の細部を知らずに、安全かつ同時に動けます。