先UNIX時代（1980年あたりより前）のOSの本を少し読んだ。
OSとは何か。2025年現在では、事実上、Linux・Windows・macOSのコードベースから話が始まる。OSとは、貨幣や法制度のような現実の一部なのだ。銀行や商取引と同じように、誰もが毎日Linux・Windows・macOSを使っている。銀行が実際にどう動いているか、商取引が実際にどんな商習慣で動いているか、そういう現実の一部として、OSのコードベースが存在している。
「貨幣や法制度を取り替えることで人類に貢献する」というファンタジーには、それはそれで人気がある。UNIXの派生物ではない新しいOSも、このファンタジーに属する。このファンタジーも「OSとは何か」の言論状況を形づくっている。
現実への適応とファンタジー。もっぱらこの2方向からのみ「OSとは何か」が説明される2025年の状況に、「どうなのそれ」と思うようになった。先UNIX時代のOSの本を少し読んだせいだろう。
先UNIX時代のOSの本を読むと、当時OSなるものを成り立たせた根本的なテーマが伝わってくる。そのテーマを、このポエムとして書いておく。
タスク
2025年3月8日現在、Wikipediaのタスク（コンピューティング）には、日本語版がない。示唆的な事実であり、私がこのポエムを書いた理由でもある。
この事実が示すとおり、業界では、「タスク」という言葉には人気がない。対するに「プロセス」は大人気だ。UNIXの派生物におけるプロセスの意味は安定している。分離機能の一部を欠くプロセスを話題にするときには必ず、「このOSはプロセスの分離機能のうちこれを持たない」という説明がつく。つまり、UNIXのプロセスという大前提が共有されている。しかし、タスクにはそういうものがない。前述のWikipediaでも、「タスク」の曖昧さが強調されている。IBMは「タスク」という言葉を多用したが、その用法を見ると、"dozens of specific meanings" があるという。
このポエムでは、タスクという言葉を中心に据える。OSに実装された機能としてのタスクではなく、OSなるものを成り立たせる抽象化としてのタスクを説明する。
このポエムでのタスクという言葉は、すでに世の中で使われている多種多様な「タスク」の用法とはあまり関係がない。主にOSの「マルチタスク」のタスクと関係している。
資源
資源＝ハード✕時間である（お断り：チューリングマシンと同様に、記憶容量の限界を無視している）。
時間と半導体を交換する技術はたくさんある。主記憶の内容を二次記憶へと退避させる技術（ページイン・アウト）が代表だが、遅いCPUと速いCPUで同じプログラムが動くのも、そうした技術である。もし互換性がなくていいのなら、CPUの設計はいくらか楽な仕事になるはずで、ここにも時間と半導体を交換する技術が存在する。また、広い意味ではプロセスもそうした技術である。もし実行されるプロセスの数だけ計算機があれば、分離機能はいらないのだから、プロセスはいらない。たとえば電卓がそうだ。そして、コンパイラの最適化オプションの一部も、そうした技術である。
どれほど半導体が進歩しても、タスクが数学的なゼロ秒で終わることはない。ハードと時間のどちらかがゼロなら、資源もゼロである。
OSとは何か
OSとは、タスクと資源をつなぐソフトである。そのタスクとは何か。それを形成するのが、OSなのだ。
VisiCalc（Excelの始祖）登場直前、1979年の税理士のことを考えてみる。彼らは仕事で計算機（電卓）を使っていたが、ここにタスクという概念が出てくる余地はない。
VisiCalcが出てきて、税理士は事務所にApple IIとプリンタを導入した。ついでにワープロソフトも導入した、というケースを考えてみる。すると、ワープロソフトで印刷しながらVisiCalcを編集（またその逆も）したくなる。これは今ならOSの出番となる。しかし当時は、プリンタバッファの出番だった。プリンタバッファとは、今のオフィス用の共用プリンタのように、印刷データ全体をPCから受信して溜めておけるハードである（ただし当時のものなので制限は色々と厳しい）。物理的には、外付けの箱か、PCに取り付ける拡張カードだった。
- ユーザがワープロソフトで印刷データを送る
- プリンタに印刷させる
- ユーザがVisiCalcを編集する
プリンタバッファがあれば、ユーザは1のあと2の完了を待たずに3に行ける。
OSは、この3つを同じ「タスク」という概念に形成する。言い換えれば、OSという色眼鏡で見るがゆえに、この3つがすべてタスクに見えるのだ。1と3はどちらもユーザを占有するので、どんな理想的な計算機をもってしても、同時には行えない（ユーザに分身の術をかけて2人にしてしまえば可能だが、それは計算機とはいえない）。1・3を同じ箱に入れるのは自然だろう。しかし2が1・3と同じ箱に入るのは、OSがタスクという概念をそのように形成しているからだ。
タスクとは、「通信」と同じような抽象化である。通信という抽象化は、郵便葉書と電話とLINEを同じ箱に入れてしまう。同様に、タスクという抽象化は、プリンタスプーラとExcelを同じ箱に入れる。
「アプリAで印刷しながらアプリBを使いたい→プリンタバッファ」という状況は、その要求も対応策も、個別的・具体的である。これをタスクという概念で抽象化して対応するのがOSである。もし個別的・具体的なことに終始するなら、タスクという概念の出番はなく、OSもいらない。実装としてのOSと、抽象化としてのタスクは、表裏一体なのだ。
この抽象化には物質的な利益がある。すなわち、プリンタバッファがいらなくなる。プリンタバッファも半導体だが、印刷以外のことには使えない。現在ではOSがプリンタスプーラとExcelの同時実行（マルチタスク！）を可能にしているので、プリンタスプーラの使う半導体は、ChromeにもPowerPointにも使われる。言い換えれば、プリンタバッファでは、タスク2と半導体が結びついていて、つなぎ直せない。OSは、つなぎ直すことを可能にしている。OSとは、タスクと資源をつなぐソフトである。
タスクの要件と実現
実行ファイルやプロセスは、タスクと一対一対応しない。これらはタスクを実現する道具であり、タスク自体ではない。たとえば、Chromeはタブを1つしか開いていないときも、複数のプロセスが通信し連携して1つのタスク（Webブラウジング）を実行している。セキュリティを高めるためだ。
同様に、タスクは必ずしもアプリではないし（例：プリンタスプーラ）、OSの管理下にない場合もある。たとえば、現在のプリンタは多少のバッファを内蔵しており、OS管理下のプリンタスプーラが空になってからも印刷が続く。
タスク同士は、通信が必要な場合には通信できなければならず、そうでない場合には互いに無関係でいられなければならない。Excelにはプリンタスプーラとのいい関係が必要だろう。しかしSteamストアはそうではない。Steamストアの開発者は、プリンタスプーラとは無関係にSteamストアを開発できなければならないし、Steamストアのユーザは、プリンタスプーラとは無関係にSteamストアを使用できなければならない。もし配慮が必要なら、そのOSはあまりうまくいっていない。
タスクの実行にはソフトを使う。求める機能・性能を備えたソフトの開発が、コスト・期間等の制約の中で可能かどうか、もし可能ならどれくらい簡単かで、OSの能力は決まる。だから開発環境はOSの根本であり、カーネルは枝葉末節にすぎないが、歴史的経緯により、開発環境は一般的にはOSに含まれない。
シングルタスク
上で「タスク同士は、通信が必要な場合には通信できなければならず」と書いた。VisiCalcは通信できなかったのか。実は、できた。VisiCalcはフロッピーディスク内のVisiCalcファイルを他のソフト（たいていは後発の表計算ソフト）に読ませることができた。CP/MというOSの働きである。
「そうでない場合には互いに無関係でいられなければならない」も実現されている。ブート時に差すフロッピーディスクを換えるだけで、Apple IIはVisiCalcにもワープロにもなり、そしてVisiCalcとワープロは互いに無関係になっている。
CP/Mは、VisiCalcやワープロのようなアプリのOSでもあったが、開発環境のOSでもあった。言語処理系とテキストエディタがフロッピーディスク経由で通信することで、開発環境となっていた（ただし当時これは人気のあるワークフローではなかった。Turbo Pascal（1983年）のように一体化した開発環境のほうが好まれた）。
CP/Mにできなかったのは、マルチタスクである。もし「アプリAで印刷しながらアプリBを使いたい」をPC上のソフトで実現（プリンタスプーラ）しようとしたら、アプリAはいいとして、アプリBを開発するときもプリンタスプーラに配慮しなければならない。技術的には可能でも、アプリの流通にとって現実的ではない。
これが「シングルタスク」のOSである。シングルタスクという概念が、「マルチタスク」のレトロニムのようなものだということに注意されたい。もし世界にシングルタスクしかなければ、タスクという抽象化にはあまり利益がない。しかし、
- タスク間の分離と通信
- タスクと資源をつなぐ
が実現されており、タスクという抽象化は一応成り立っている。これが成り立たなくなるのは、プリンタバッファや電卓のように、タスクと半導体が常に結びついていて、つなぎ直せない世界だ。
製造の前にタスクと資源をつなぐ
そのプリンタバッファや電卓にしても、半導体を机にぶちまけただけで勝手にプリンタバッファや電卓になることはない。ハードの設計工程で、タスクと資源をつないでいる。いわゆる組み込み開発である。
太古のプリンタバッファや電卓なら、ソフトを一切使わずに設計されたかもしれない。その場合、OSはまったく介在しなかったことになる。しかし現在では、そういう設計工程は（商売としては）ありえない。また現在では、ほとんどの機能を、半導体の配線ではなくソフトで実装する。そのソフトを開発するために開発環境を使う。この開発環境もある種のOSと見なせるが、前述の歴史的経緯により、また「組み込みOS」の広大さにより、話が面倒になるので立ち入らない。
組み込みシステムでは、（原則としては）すべてのタスクをハードの設計時に実装してしまうので、無関係なタスク同士での配慮を求める特殊なマルチタスクが現実的になっている。先述のタスクの要件とは、OSに求められているエコシステムを反映したものなのだ。目指すエコシステムが異なるなら、タスクの要件も違ってくる。「タスクとは何か」を形成するのが、OSなのだ。
抽象化
あなたは、自分の生活のなかで、郵便葉書と電話とLINEをいっしょくたにして「通信」として扱ったことがあるだろうか。学者や行政の人でもないかぎり、一生に一度もやらないかもしれない。では「通信」という抽象化は異様で無益なものだろうか。少なくとも腕木通信の発明前まで文明を巻き戻さないかぎり、「通信」という抽象化は勝手に生えてくるだろう。それでも、ほとんどの人は、自分の生活のなかで通信という抽象化を扱うことはない。
これに対して、ビデオゲームの「据え置き機」という抽象化は、生活のなかでよく使う。OSでも「プリンタ」のような抽象化が使われる。
タスクという抽象化は、通信よりも馴染みがない。そして計算機では一般的に、馴染みのない抽象化のほうが強力だ。この「強力」とは、その抽象化なしでは見えなかった可能性が見えてくる、という意味である。OSがプリンタという抽象化によって得るものは、ユーザを驚かせないことだけだろう。タスクという抽象化は、OSの存在意義そのものだ。
ほとんどの人は、郵便葉書や電話やLINEを個別的・具体的に扱って生活している。同様に業界人は、プロセスやファイルやソケットを個別的・具体的に扱って生活している。プロセスやファイルやソケットについての情報がネットや本に腐るほどあるのは、生活に欠かせないから、現実に適応するために必要だからだ。それに対してタスクは、「OSとは何か」と問わないかぎり必要ない。
だが、「OSとは何か」を問うのなら、タスクという抽象化は必要だ。
先UNIX時代の記述
先UNIX時代には、プロセスやファイルやソケットではなくタスクが語られていたのか、というと、そうでもなかった。実際の記述を見てみる。原著1975年の『アセンブラプログラミング詳説 上巻』 21ページより：
オペレーティング・システム
システム/360 または370の オペレーティング・システム (operating system) は, 計算機の内部活動と入出力の両方を補助, 管理するために設計された一連のプログラムである. オペレーティング・システムには, 二重の目的がある. ユーザがハードウェアの複雑で高度な機能を利用するのを助けることと, 活動を注意深く計画し, また, 重複させることによって, その利用が効率良く行われるようにすることである. 計算機を効率良く利用できるようにするため, オペレーティング・システムは, 同時にいろいろな仕事ができるよう配慮をしている. 中央処理装置が命令を実行するのと同時に, 幾つかの入出力の操作を行うことができる. このように幾つかの仕事を同時に行うことができるためには, 計算機はかなり高度な機能を持っていなくてはならない. オペレーティング・システムは, 個々のプログラムでは恐ろしくやっかいで手に負えないような面倒なやり方によって, この機能を利用するわけである. このように, オペレーティング・システムのおかげで, 広範囲に, また, 矛盾なくサービスを受けることができ, 個々のプログラマは骨の折れる雑役から解放されるのである.
操作を同時に行うということが普通意味するのは, あるジョブの出力, 第2のジョブの内部処理, それに第3のジョブの入力を全部同時に行うということである. あるジョブの処理が終了すると直ちに, 別のジョブの処理が始まる. さらに, もっと高度なオペレーティング・システムでは, 時分割 (time-sharing) が許される. 時分割のもとでは, 幾つかのジョブのプログラムとデータが同時に計算機の中にあって, 交代で実行される. 計算機を効率的に利用するために必要な, このような環境においては, あるジョブのデータを, 別のジョブのデータによる破壊から保護する必要があるが, この保護もオペレーティング・システムが行う.
当時の常識が今ではわからなくなっている部分を補足しておく。当時の計算機が想定していたタスクはもっぱら
- "tape-to-tape" の集計・分析
- "tape-to-printer" の出力
の2種類のバッチ処理だけだった。対話的UIはもちろんオンライン処理も特殊なもので、眼中にない。tape-to-tapeとは、
- データとユーザ・プログラム（アプリ）を磁気テープから主記憶に読み込む
- 計算機で集計・分析を行う
- 結果を磁気テープに書き出す
という3段階の処理である。tape-to-printerなら、集計・分析のかわりに抽出を行う。「あるジョブの出力, 第2のジョブの内部処理, それに第3のジョブの入力」は、2種類のバッチ処理の3つの段階に対応している。
引用を見ての通り、タスクは「ジョブ」と呼ばれている。バッチ処理はどれもよく似ているので、このジョブという概念は、Excelとプリンタスプーラのように異質なものを同じ箱に入れてはいない。ゆえにタスクという抽象化とは一定の距離があるが、ジョブはタスクの一種といえる。
次は原著1974年の『オペレーティング・システム』 2-3ページより：
オペレーティング・システムという言葉は, 処理装置, 主記憶装置, 2次記憶装置, 入出力装置, ファイル装置などといった装置を制御するために計算機システム内に用意されたプログラム・モジュールを意味する.
これらのモージュルは予盾を解決し, 効率の最適化を図り, 手軽で効果的なシステム利用を可能にする. これらのモジュールは利用者プログラムと計算機ハードウェアとのインターフェースの役割りを果たす.
これらのモジュールを総称してモニタ, 制御プログラム, スーパバイザ, あるいはオペレーティングシステムなどと呼んでいる. 応用プログラム, 言語処理プログラム, ライブラリ・ルーチン, デバッギングエイドなどはオペレーティング・システムの定義に含めないことにする. これらは単にオペレーティング・システムの利用者であり, 他の書物で述べられている (Donovan, 1972; Knuth, 1968).
「OSとは何か」の議論には、タスク中心に見る立場と、資源中心に見る立場がある。先の『アセンブラプログラミング詳説』はOSユーザ向けの本なのでタスク中心、この『オペレーティング・システム』はOSプログラマ向けの本なので資源中心に見ている。
『アセンブラプログラミング詳説』の引用部には、「開発環境はOSに含まない」という話はなかった。『オペレーティング・システム』の引用部はそれよりずっと短いのに、「開発環境はOSに含まない」という話をしている。タスク中心と資源中心の違いが反映されているように思える。
結語
以上、タスクという抽象化について縷々説明した。ほかの論点を振り返ると：
- 現実への適応 vs 脱UNIXファンタジー vs 見落とされた抽象化
- OSが目指すエコシステム→タスクの要件（＝タスクとは何か）→OSの機能
- タスク中心 vs 資源中心
となる。
抽象化について説明するのは難しい。オブジェクト指向についての説明がしばしば奇怪なのは、オブジェクト指向が抽象化に対して難しいアプローチをしているからだろう。「据え置き機」や「プリンタ」のような馴染みのある（しかし利益の乏しい）抽象化と、「タスク」のような利益の多い強力な抽象化のあいだには、断絶がある。オブジェクト指向についての奇怪な説明はみな前者の話に終始している。このポエムはその轍を踏まないよう努めた。このポエムをここまで読んだほどの猛者なら、ネットで「わかりやすい」と言われるものを警戒する習慣をお持ちだろう。このポエムはそういう「わかりやすい」ものにならないよう努めた。
最後に、UNIX時代の始まりに触れておこう。当時、UNIXは「開発環境が快適」という動機で広まった。「快適」であって機能・性能ではない。というより、OSや言語処理系の機能・性能について、他のプレイヤーはみな間違ったところを最適化していた。UNIX以外のプレイヤーは、60年代に定義されたゲームを80年代まで続けていた。先に「求める機能・性能を備えたソフトの開発が、コスト・期間等の制約の中で可能かどうか、もし可能ならどれくらい簡単かで、OSの能力は決まる」と書いた。「どれくらい簡単か」であって、「どれくらい省資源か」や「どれくらいフールプルーフか」ではない。60年代に定義されたゲームは後者だった。OSの「簡単」という性能を測定する指標は今も昔もないので、ゲームとして定義できなかった。測定できないものは管理できないので、時々ゲームチェンジャーになる。
長い目で見れば、OSの地殻変動は終わっていない。私の見るところ、OracleがSolaris事業を2017年に打ち切ったのと同様に、MicrosoftはWindows事業を2040年までに打ち切る。UNIX時代も永遠ではない。新たなメインフレームとしてLinuxがクラウドに閉じ込められる日も、おそらくあなたが生きているうちに訪れるだろう。現実に適応するだけでなく、常に考え、備えるべきだ。
もちろん、間違ったところを最適化しても意味がない。何を考えるべきかを考えるうえで、このポエムが一助となれば幸いである。