ソフトウェアという段取りの話 ― 織機のカードからOSとアプリまで

記事

IT・テクノロジー

2026/10/05 13:13

はじめに ― 町はできた。では、誰が働くのか

この連載では、コンピューターをいちばん下の層から順に登ってきました。

最初の記事では、電気と波が情報を運ぶ仕組みを見ました。次の記事で、その電気が0と1になったあとの世界 ― 二進数、論理ゲート、記憶素子の話に進みました。三番目の記事ではプロセッサの中に入り、レジスタやパイプラインやマルチコアといった「計算を速くするための工夫」を追いかけました。そして四番目の記事で、それらの部品を載せる土台であるマザーボードを扱いました。あのときは、マザーボードを「道路と電線が敷かれた町の区画」にたとえましたね。

ここまでで、町はひととおり出来上がりました。道路があり、電気が通り、交差点には信号があり、大きな建物も建っています。

けれど、町は建物だけでは動きません。そこで働く人がいて、その人たちが「朝は何をして、次に何をして、もし雨が降ったらどうするか」という段取りを持っていて、はじめて町は機能します。

その「段取り」にあたるものが、ソフトウェアです。

今回の記事は、この連載にとってひとつの区切りになります。ここまではずっと、手で触れるもの ― ハードウェアの話をしてきました。ここから先は、手で触れないもの ― ソフトウェアの話に入ります。

そして最初に扱いたいのが、「ソフトウェアはどこから来たのか」という問いです。

というのも、ソフトウェアという考え方は、決して当たり前のものではなかったからです。コンピューターが生まれた直後、ソフトウェアという言葉すら存在しませんでした。プログラムを「機械とは別に置いておけるもの」として扱い、さらにそれを記憶装置の中に入れてしまうという発想は、どちらも発明されなければならなかったのです。

しかも面白いことに、その発想の原型は、コンピューターよりも百年以上前に、まったく別の分野で生まれています。

順番に見ていきましょう。

1. ソフトウェアとは、結局のところ何なのか

まず、言葉の整理からです。

ソフトウェアという言葉は日常的に使われますが、いざ「それは何か」と問われると、答えにくいところがあります。「アプリのこと」「パソコンに入れるもの」といった答えが返ってきそうですが、それは具体例であって定義ではありません。

もっとも素っ気なく、しかし正確な言い方をすると、こうなります。

ソフトウェアとは、コンピューターに対する「命令の並び」である。

ここで大事なのは「並び」の部分です。命令が一個あるだけでは、ソフトウェアとは呼びません。「この数とこの数を足せ」という命令が一つあっても、それは計算であって仕事ではありません。仕事になるのは、

まずこれをして

次にこれをして

もしこういう結果になったら、こっちに進み

そうでなければ、あっちに進み

これを百回繰り返す

というふうに、順番と条件と繰り返しが組み合わさったときです。

私はこれを「段取り」と呼びたいと思っています。料理でも掃除でも引っ越しでも、人間が何か手間のかかることをやるとき、頭の中には段取りがあります。何をどの順でやるか。うまくいかなかったらどうするか。同じことを何回やるか。ソフトウェアがやっているのは、この段取りを、人間ではなく機械が実行できる形で書き下すことです。

～～ハードウェアとの境界はどこにあるのか～～

ここでひとつ、初心者のうちに引っかかりやすいところを潰しておきます。

「ソフトウェアは形がないもの、ハードウェアは形があるもの」という説明をよく見ますが、これは実は少し雑です。というのも、ソフトウェアだって最終的には物理的な状態として存在しているからです。

前の記事で、メモリやフラッシュメモリの仕組みを見ました。あそこで確認したとおり、0と1は「電荷があるかないか」「電圧が高いか低いか」といった物理的な状態として蓄えられています。ソフトウェアがメモリに読み込まれているとき、それは間違いなく物理的に「そこにある」のです。

では何が違うのか。差し替えられるかどうかです。

プロセッサの回路は、工場で焼き付けられた時点でほぼ決まってしまいます。出荷後に配線そのものを引き直すことは、普通はできません。一方、メモリの中身は、電気的に何度でも書き換えられます。同じ機械が、朝は文章を書く道具になり、昼は計算機になり、夜は映像を再生する装置になれるのは、命令の並びを差し替えられるからです。

ハードとソフトの境界は「形の有無」ではなく、**「差し替えの手間が桁違いに小さいかどうか」**にある。この見方をしておくと、このあと出てくる話がずっと理解しやすくなります。

ひとつ断っておくと、この線引きも完全ではありません。書き換えのできない記憶素子に焼き込まれたソフトウェアもありますし、逆に、出荷後に内部の配線構成を何度でも書き換えられるハードウェアもあります。プロセッサの細かい振る舞いが、出荷後に配られる更新データで変わることすらあります。境界のあたりには、どちらとも言いにくいものが並んでいるのです。

それでも入門段階では、「差し替えやすい側がソフト、差し替えにくい側がハード」と捉えておけば、話の筋を見失わずに済みます。

そして、まさにこの「あとから差し替えられる」という発想が、どこから来たのかという話になります。

2. 機械に段取りを教える ― 穴の開いた紙の発明

コンピューターの歴史の本を開くと、決まって出てくる機械があります。織機です。

工業製品としての布の話が、なぜコンピューターの話に出てくるのか。ここには、はっきりした理由があります。

模様を織るという「手間のかかる段取り」

まず、布に模様を織り込む作業がどういうものかを考えてみてください。

織物は、縦にぴんと張った糸(たて糸)の間に、横糸を通していくことでできます。このとき、たて糸の一部を持ち上げて、その下を横糸がくぐるようにします。どのたて糸を持ち上げるかを変えると、横糸が表に出る場所と裏に隠れる場所が変わり、そこに模様ができます。

つまり模様を織るというのは、「横糸を一回通すたびに、どのたて糸を持ち上げるかを指定する」という作業を、何千回何万回と繰り返すことなのです。

複雑な模様であればあるほど、この指定は細かくなります。かつては、職人が織機の上によじ登り、指示を読み上げる人に合わせて、手で糸を持ち上げていました。ひとつ間違えれば模様が崩れます。とんでもなく手間のかかる、そして間違いやすい仕事でした。

～～カードの穴が、そのまま指示になる～～

ここで登場するのが、フランスのジョゼフ・マリー・ジャカールという人物です。

彼は1801年にパリの産業博覧会で改良した織機を出品し、銅メダルを受けています。ただし、このときのものはまだ穴あきカードで制御する方式ではありませんでした。カードによる制御を完成させたのは、そのあと1804年から1805年にかけてのことです。年号が資料によって揺れているのは、この二段階を区別しているかどうかの違いです。

では、そのカード制御がどういう仕組みだったか。

厚紙のカードに穴を開けます。そのカードを織機に当てると、穴が開いている場所では針が通り抜け、穴が開いていない場所では針が押し戻される。この針の動きが、たて糸を持ち上げる仕掛けにつながっている。

つまり、カード一枚が「今回の横糸を通すときに、どのたて糸を持ち上げるか」という指示そのものになっているわけです。そしてカードを何百枚も鎖のようにつなぎ、横糸を一回通すごとに一枚ずつ送っていく。

私はこれを、**「一枚ずつめくっていく手順書」**だと考えると、いちばんしっくりきます。ページをめくるたびに、その回にやるべきことが書いてある。全部めくり終えたとき、模様が一枚できあがっている。

そして、ここがこの記事全体でいちばん大事な点なのですが ―

カードの束を差し替えれば、同じ織機がまったく違う模様を織る。

機械そのものには一切手を加えていません。取り替えたのは紙の束だけです。それなのに、出てくるものが変わる。

これは、さきほど整理した「ハードとソフトの境界」そのものです。織機が、あとから変えられない部分(ハードウェア)。カードの束が、あとから差し替えられる部分(ソフトウェア)。

コンピューターが影も形もない時代に、この分離がすでに実現されていたわけです。

数字ではなく「穴の有無」であることの意味

もうひとつ、地味ですが重要なことがあります。

カードに記録されているのは、数字でも文字でもありません。「穴が開いているか、開いていないか」という二択です。

前の記事で、コンピューターがなぜ二進数を使うのかを見ました。理由は、二択なら判定が確実だからでしたね。電圧が「高いか低いか」だけを見るなら、多少ノイズが乗っても間違えない。十段階の電圧を見分けようとすると、たちまち怪しくなる。

織機のカードも、まったく同じ理屈で二択になっています。「穴が開いているか」なら、針が通るか通らないかで機械的に判定できます。そこに解釈の余地はありません。

情報を二択に落とし込むという発想は、電子回路が生まれるより前から、確実に動く機械を作るための王道だったということです。

3. 機械に仕事を奪われる、という最初の恐怖

ジャカールの織機の話には、決まって付いてくる後日談があります。少し寄り道になりますが、触れておきたい話です。

この仕組みが広まると、当然ながら、それまで手作業で模様を織っていた職人の仕事が減りました。熟練の技が必要だった工程が、カードを差し替えるだけの作業になったからです。

そして反発が起きました。ジャカールの地元であるリヨンの絹織工たちは、実際に導入された織機を焼き、ジャカール本人を襲撃したと伝えられています。リヨンに立つ彼の像は、織機が壊された場所に建てられたものだそうです。反発はその後も尾を引き、1830年代には絹織工による大規模な蜂起が二度起きています。

ここで、混同されやすい話を整理しておきます。

ほぼ同じ時期、1810年代のイギリスでも、機械を打ち壊す運動が起きました。ネッド・ラッドという(実在したかどうかもはっきりしない)人物の名にちなんで、ラッダイトと呼ばれる運動です。この言葉は今日でも「新しい技術に頑なに抵抗する人」という意味で英語に残っています。

ただし、**イギリスのラッダイトが壊した機械は、ジャカールの織機ではありません。**彼らが標的にしたのは、粗悪品を大量に作れる編機や、蒸気で動く力織機、羊毛の仕上げに使う機械などでした。動機も「模様を織る技が要らなくなった」ことではなく、「安物を作る機械のせいで賃金が下がった」「仕上げの熟練工が要らなくなった」ことにありました。

同じ十年間に、フランスとイギリスで、別々の機械をめぐって別々の反発が起きた。それだけの話です。ジャカール織機への反発を「ラッダイト運動」と書いている記事をときどき見かけますが、それは二つを混ぜてしまっています。

そのうえで、なぜこの寄り道をしたかというと、二百年前のこれらの出来事が、現在の私たちの議論と驚くほど地続きだからです。

自動化された道具が登場したとき、人は決まって二つの反応を示します。ひとつは「これで楽になる」。もうひとつは「自分の仕事はどうなる」。この二つはどちらも正当な反応で、どちらか一方が正しいという話ではありません。

ソフトウェアというものは、その本質からして「人間がやっていた段取りを機械に肩代わりさせる道具」です。だから、この二つの反応をずっと引き受け続けてきたし、これからも引き受け続けます。ソフトウェアの歴史を追いかけるということは、便利さの歴史を追いかけると同時に、この緊張の歴史を追いかけることでもあります。

寄り道はここまでにして、本筋に戻ります。

4. 配線を組み替える機械から、記憶に段取りを置く機械へ

時代は一気に二十世紀に飛びます。

命令をどこに置くか、という問題

初期の電子式コンピューターには、キーボードもディスプレイもありませんでした。そして、今でいうソフトウェアもありませんでした。

ただし、ここは正確に書き分ける必要があります。

「機械とは別のところに命令の並びを置く」という発想自体は、すでにありました。1940年代前半の計算機のなかには、紙テープや穴を開けたフィルムに命令を記録し、それを読み込みながら動くものがあったからです。これは考え方としては、ジャカールのカードの直系にあたります。

問題は、そうした計算機でも命令を記憶装置の中に置いてはいなかったことです。命令は外側の媒体にあり、一行ずつ読み込まれては実行されます。読み込みの速度は機械の速度に比べて桁違いに遅く、途中の判断で前に戻ることも簡単ではありません。

そして、当時もっとも有名だった電子式計算機に至っては、外部の媒体すら使っていませんでした。計算する内容の指定方法は、こうです。機械そのものを組み替えていました。

具体的には、大量のスイッチを一つずつ手で切り替え、ケーブルを差し替えて回路のつなぎ方を変えていました。「今日はこの計算をする」と決めたら、それに合わせて配線を組み直すのです。この作業には、場合によっては何日もかかりました。

前の記事で、プロセッサの中の加算器を見ました。論理ゲートを組み合わせると、足し算をする回路ができるという話です。初期のコンピューターがやっていたのは、あの「回路の組み合わせ方」自体を、計算のたびに人間が手で作り直すという作業でした。

計算そのものは数時間で終わるのに、その準備に数日かかる。これでは、機械がいくら速くても意味がありません。

～～「命令もデータと同じように記憶させればいい」～～

ここで決定的な転換が起こります。1945年前後に整理された、プログラム内蔵方式という考え方です。

発想は、言葉にしてしまえば単純です。

計算の対象となる数値(データ)を記憶装置に入れておけるのなら、計算の手順(命令)だって、同じように記憶装置に入れておけばいいのではないか。

命令も、結局のところ0と1の並びで表せます。「足せ」という命令に0001という番号を、「引け」という命令に0010という番号を割り当てておけば、命令は数値として書けます。数値として書けるなら、メモリに入ります。メモリに入るなら、電気的に一瞬で書き換えられます。

配線を組み替える必要は、もうありません。メモリの中身を入れ替えるだけでいい。

前の記事で、台所の作業台とレシピカード立てというたとえを使いました。作業台の上のスペースがレジスタで、すぐ横に立ててあるレシピカードが、次にやるべき指示である、という話でしたね。

プログラム内蔵方式というのは、まさにこのレシピカード立てを発明したということです。それまでは、違う料理を作るたびに厨房の配線を引き直していた。これからは、カードを差し替えるだけでいい。

そして気づいたでしょうか。これは、ジャカールの織機でカードの束を取り替えたのと、まったく同じ構造です。百四十年の時を隔てて、同じ発想が、まったく別の分野で再発明されたことになります。

～～この方式が生んだ、もうひとつの帰結～～

プログラム内蔵方式には、当時の人々も驚いたであろう副作用があります。

命令がメモリの中にある数値である以上、プログラムは自分自身を書き換えることができるのです。

これは今日ではあまり推奨されない書き方ですが、原理としては今も生きています。プログラムが別のプログラムを生成する、コンパイラがソースコードから実行可能な形式を作り出す、といった処理は、すべて「命令もまたデータである」という性質の上に成り立っています。

ハードとソフトを分離したつもりが、その分離の仕方があまりに徹底していたために、ソフトがソフトを作るという入れ子構造まで可能になってしまった。この記事の後半で出てくる話の多くは、この入れ子構造の応用だと思って読んでいただくと、見通しがよくなります。

5. 世界で最初に「読み込まれて動いた」プログラム

理屈の上で成立した考え方が、実際に動いたのはいつか。

記録に残っている最初のものは、1948年6月21日、イギリスのマンチェスター大学で作られた試験機での出来事です。

この機械の正式名称は「小規模実験機(Small-Scale Experimental Machine、略してSSEM)」といいますが、長いので当時から「ベイビー(Baby)」という通称で呼ばれていました。以下ではベイビーと書きます。名前のとおり、本格的な機械を作る前の実証用の小さな試験機です。のちにマンチェスター・マーク1という本格機へ発展し、さらにそれを商品化したフェランティ・マーク1が、汎用の電子式コンピューターとして最初に市販されたものになりました。

プログラムを書いたのは、トム・キルバーンという研究者です。

なお「世界初」という言い方には、毎回条件が付きます。ベイビーの場合は「書き換え可能な電子的記憶装置に置かれたプログラムを実行した最初の機械」というのが、記念碑に刻まれている正確な言い方です。プログラムを外部媒体から読む機械はそれ以前にもあった、という話をさきほどしましたね。その区別がここに効いています。

～～何を計算させたのか～～

計算させた内容は、いま見るとひどく地味です。

ある数の、最大の真の約数を求める。

真の約数というのは、その数自身を除いた約数のことです。ある数を割り切る数のうち、その数そのものを除いていちばん大きいもの、という意味になります。

そして、その求め方がまた力技でした。対象の数から1を引いた数から順に、一つずつ小さくしていきながら、割り切れるかどうかを試す。割り算は、引き算を繰り返すことで代用する。

6月21日に動いた最初の実行では、対象の数はかなり小さいものでした。そしてその数日のうちに、対象を大きくしていって、2の18乗(262,144)を相手にする実行までたどり着きます。

答えは131,072です。262,144の半分ですね。つまり、262,143から131,072まで、十三万回以上にわたって「これで割り切れるか」を試し続けたことになります。

このプログラムの長さは、わずか17命令でした。

そして、答えが出るまでにかかった時間は、約52分。その間に実行された命令はおよそ210万回、記憶装置への読み書きはおよそ350万回と記録されています。

～～この数字を、手持ちの知識で読み替えてみる～～

ここで、この連載を読んできた人にしかできない計算をしてみましょう。

52分は3,120秒です。210万回の命令を3,120秒で終えたのですから、

210万 ÷ 3,120 ≒ 毎秒およそ670命令

これがこの機械の処理速度ということになります。

前の記事で、クロックの話をしました。3GHzのプロセッサなら、1秒間に30億回の拍を刻む、という話です。そして現代のプロセッサは、パイプラインと複数の実行ユニットのおかげで、1クロックあたり平均して複数の命令を進められます。

つまり、ざっくり見て毎秒30億命令以上。1948年の機械の毎秒670命令と比べると、

30億 ÷ 670 ≒ およそ450万倍

七十数年で、処理速度がおよそ450万倍になった計算です。しかも、これはコアが一つだった場合の話で、記事3で見たマルチコアを考えれば、その差はさらに開きます。

ちなみに、この計算をするときに「210万」と「350万」のどちらを使うかで、答えは大きく変わります。350万を使うと毎秒1,100回という数字が出ますが、これは命令の数ではなく記憶装置にアクセスした回数です。現代のプロセッサの「毎秒何命令」と比べるなら、命令の数どうしで揃えなければ意味がありません。**数字を比べるときは、その数字が何を数えたものかを先に確かめる。**地味ですが、これを怠ると平気で桁がずれます。

もうひとつ、規模の比較もしておきましょう。

このプログラムは17命令でした。一方、現在広く使われているLinuxというOSの中核部分は、2025年1月末に公開された開発版でソースコードが4,000万行を超え、同年3月の安定版がその大台に乗った最初の正式版になりました。しかもこの規模は、十年間でほぼ倍になっています。

命令の数とソースコードの行数は厳密には別のものなので、この二つを直接割り算するのは乱暴です。それでも桁の感覚をつかむために、あえて割ってみると、

4,000万 ÷ 17 ≒ およそ230万倍

奇妙なことに、速度の伸びとほぼ同じ桁になりました。速くなった分だけ、複雑なことをさせるようになった、という読み方もできそうです。

このあたりを眺めていると、記事3で扱ったパイプラインや分岐予測といった「速くするための工夫」が、単なる技術者の趣味ではなく、こういう規模のソフトウェアを動かすために必要だったのだと実感できるはずです。

～～本や記事でよく混同されている点～～

なお、この1948年の出来事については、書き方が揺れている資料をよく見かけます。試験機のベイビーとその後継の本格機を取り違えていたり、6月21日の初回実行がそのまま2の18乗を52分かけて解いたことになっていたり、といった具合です。

そしてもうひとつ、計算させた数を「2の18乗」ではなく「218」と書いているものがあります。これは、上付き文字の18が印刷や転記の過程で落ちて、218という数字になってしまったものと思われます。

細かいことのようですが、**262,144と218では話がまるで違います。**218の最大の真の約数(109です)なら、人間が暗算で数十秒で求められます。それを52分かけて解いたのなら、機械が遅すぎるという話にしかなりません。262,144を十三万回の試行で解いて52分だったからこそ、「途方もなく遅いが、確実に、人間が命じたとおりに、休まず動き続けた」という意味を持つのです。

こういう取り違えは、孫引きを重ねるうちに増えていきます。数字が出てくる話ほど、元の記録にあたる価値があります。

6. 虫と、ハッカー ― 言葉の由来を正確に押さえる

ソフトウェアの世界には、由来が語られがちな言葉がいくつかあります。ところが、その語られ方がしばしば不正確です。せっかくなので、ここで二つだけ整理しておきます。

「バグ」は蛾が語源、ではない

プログラムの不具合を「バグ」と呼びます。bugは英語で虫のことです。

この言葉の由来として、あまりにも有名な逸話があります。1947年9月9日、ハーバード大学で稼働していた計算機の内部に蛾が挟まって動作不良を起こし、取り除かれた蛾が作業記録帳に貼り付けられた、というものです。その記録帳は現在も保存されています。

ここまでは事実です。しかし、そこからよく語られる「だからバグと呼ぶようになった」という部分は、正確ではありません。

理由は、その記録帳に書かれた一文そのものにあります。そこにはこう書かれています。

「バグが見つかった、実際の事例の第一号」

この書き方をよく読んでください。もし「バグ」という言葉がこのとき初めて生まれたのなら、こういう書き方にはなりません。**「バグという言葉はすでにあったが、本物の虫が原因だった事例は初めてだ」**という、ちょっとした洒落としてこう書かれているのです。

実際、機械の不具合を指して「バグ」と呼ぶ言い回しは、十九世紀の技術者の間ですでに使われていました。エジソンが1878年に書き残した文書にも登場します。

もうひとつ、この逸話にはよくある取り違えがあります。蛾を見つけたのはグレース・ホッパー本人ではありません。当時この機械の試験を担当していたウィリアム・バークという技術者と、その同僚だったとされています。ホッパーはこの機械のチームにいた研究者で、後年の講演でこの話を繰り返し取り上げ、面白い話として世に定着させた人です。

つまり、この逸話でホッパーが果たした役割は「発見」ではなく「語り継ぎ」でした。

この話が示しているのは、言葉の由来というのは、面白い話が語られるうちに、事実とすり替わっていくことがあるということです。技術の記事を書くときには、特に気をつけたいところだと感じます。

～～「ハッカー」は、もともと悪い意味ではなかった～～

もうひとつ。ハッカーという言葉です。

現在では、他人のシステムに不正に侵入する人という意味で使われることが多いですね。しかし、この言葉が生まれた場所と時期を追いかけると、まったく違う意味だったことが分かります。

1950年代から60年代にかけて、マサチューセッツ工科大学に鉄道模型のクラブがありました。彼らは模型のレイアウトを動かすために、当時の通信設備で使われていたリレー(継電器)の部品などを流用して、かなり凝った制御回路を自作していました。

彼らの間では、既存の仕組みを解きほぐし、本来想定されていない使い方で目的を達成することを「ハック」と呼び、それが得意な人を「ハッカー」と呼んでいました。そこには称賛のニュアンスがありました。

このクラブのメンバーの一部が、やがて大学の大型計算機に触れるようになり、同じ精神でプログラムを書き始めます。仕様書を読むだけでなく、機械の限界を探り、想定外の方法で性能を引き出す。ソフトウェアという文化の原型のひとつは、ここで作られました。

不正侵入を指す言葉として使われるようになったのは、ずっとあとのことです。今でも技術者の中には、そうした行為は「クラッキング」と呼んで区別すべきだと考える人がいます。

言葉の意味が変わること自体は自然なことですが、もとの意味を知っておくと、技術者が書いた古い文章を読むときに誤読しなくて済みます。

7. 同じ仕事を、何度も書き直していた時代

さて、話を実務に戻します。

1950年代から60年代にかけて、企業や大学に大型計算機が入り始めました。当時の計算機は一台が部屋ひとつを占めるような規模で、値段も相当なものでした。

この時代のプログラムには、今からすると信じがたい性質がありました。機械が違えば、同じ仕事をするプログラムでも、まるごと書き直さなければならなかったのです。

なぜ書き直しが必要だったのか

理由は二つあります。

ひとつは、機械ごとに命令の体系が違ったこと。ある機械では「足せ」が0001番の命令でも、別の機械では別の番号かもしれません。そもそも命令の種類そのものが違うこともありました。

もうひとつ、こちらのほうが実は深刻なのですが、周辺機器の扱い方が機械ごとに完全にばらばらだったことです。

プログラムというのは、計算するだけでは仕事になりません。データを読み込み、結果を書き出す必要があります。当時なら、カードを読む装置からデータを取り込み、印刷装置に結果を出す、といった具合です。

ところが、その「カードを読む」という処理の書き方が、機械ごとに違う。どの番地に何を書き込めば装置が動き出すのか、読み取りが終わったことをどうやって知るのか、エラーが起きたらどこを見ればいいのか ― こうしたことが、機種ごとにすべて独自でした。

結果として、プログラマは仕事の本体(給与を計算する、在庫を集計する)よりも、装置を動かすための手続きを書くことに、膨大な時間を使っていました。

しかも、その手続きは、どの会社のどのプログラムでも、中身はほとんど同じです。給与計算のプログラムだろうが在庫管理のプログラムだろうが、「カードを読む」処理はまったく同じことをしています。

同じものを、全員が、何度も、独立に書いていた。

これはどう考えても無駄です。

8. そこで生まれたのが、OSだった

この無駄をどう解消するか。答えは、いま思えば当然のものでした。

全員が書いている共通部分を、一回だけ書いて、全員で使えばいい。

装置を動かす手続き、メモリのどこが空いているかを管理する仕組み、ファイルを名前で探し出す仕組み ― こうした「どのプログラムにも必要な共通の下働き」をひとまとめにして、機械の側にあらかじめ用意しておく。

これがオペレーティングシステム、略してOSの出発点です。

町の役所と、上下水道

記事4で、マザーボードを「道路と電線が敷かれた町の区画」にたとえました。この比喩を、そのまま延長させてください。

町に店を出すことを考えてみます。カフェを開くとして、水が必要です。電気も必要です。ゴミも捨てなければなりません。

もし町に上下水道も電線もゴミ収集もなかったら、店主は自分で井戸を掘り、自家発電機を回し、ゴミを自分で処分場まで運ぶことになります。隣に別の店ができれば、その店主もまた井戸を掘ります。その隣の店も。

町じゅうの店主が、それぞれ井戸を掘っている。これが、OSがなかった時代です。

OSがあるというのは、町に上下水道とゴミ収集と役所ができたということです。店主は蛇口をひねれば水が出るし、決められた日にゴミを出せば持って行ってもらえる。井戸の掘り方を知る必要はありません。

そして店主は、井戸掘りに費やしていた時間を、本来やりたかったこと ― おいしいコーヒーを淹れること ― に使えるようになります。

～～「窓口」という考え方～～

ここで、もう一歩踏み込みます。

店主が水道を使うとき、水道局の内部で何が起きているかを知る必要はありません。蛇口という決まった作法があって、それをひねれば水が出る。それだけ分かっていればいい。

OSとアプリケーションの関係も、これとまったく同じです。

アプリケーションが「このファイルを開きたい」と思ったとき、ハードディスクの何番目の場所にデータがあるかを自分で調べたりはしません。OSに対して、決められた作法で「このファイルを開いてください」と頼みます。するとOSが、装置とのやりとりを全部引き受けて、結果だけを返してくれます。

この「決められた作法で頼む窓口」の全体を、専門的にはAPIと呼びます。そしてAPIのうち、OSの中核部分に直接取り次いでもらう特別な窓口を、システムコールと呼びます。

窓口が何種類もある役所を想像してください。たいていの用事は一般の窓口で片づきますが、住民票のように役所の台帳そのものを触る用事は、専用の窓口を通す必要がある。その専用窓口にあたるのがシステムコールです。逆に言えば、計算だけして返してくれるような窓口(たとえば平方根を求める関数)は、APIではあってもシステムコールではありません。

いずれにせよ、書式さえ守れば、中で誰がどう処理しているかは知らなくていい。これが要点です。

そして、この窓口があるおかげで、**窓口の作法さえ変えなければ、OSの中身が入れ替わってもアプリは動き続けます。**水道局が浄水場の設備を新しくしても、店主は今までどおり蛇口をひねるだけです。

記事の後半で、Windowsが何度も作り直されながら古いソフトを動かし続けてきた話が出てきます。それを可能にしているのが、この窓口の考え方です。

～～OSがやっていること、もう少し具体的に～～

窓口の話が抽象的なので、OSが実際に引き受けている仕事を挙げておきます。

ひとつめは、装置とのやりとりです。画面に文字を出す、キーボードの入力を受け取る、記憶装置に書き込む、通信回線にデータを流す。こうした処理を、機種ごとの違いを吸収した形で提供します。

ふたつめは、資源の分配です。メモリは有限で、プロセッサも有限です。複数のアプリが同時に動いているとき、誰にどれだけ割り当てるかを決める必要があります。記事3で見たマルチコアも、OSが「どの仕事をどのコアに回すか」を決めることで、はじめて活きてきます。

みっつめは、隔離です。あるアプリが暴走したときに、他のアプリや機械全体を巻き込まないようにする。あるアプリが、別のアプリのデータを勝手にのぞき見できないようにする。

この三つめは地味ですが、現代では最も重要な役割のひとつです。私たちが一台の機械でいろいろなソフトを動かしていられるのは、OSが壁を立ててくれているからです。

9. ソフトウェアが「商品」になった日

ここで、技術の話から少し離れて、商売の話をします。技術史を読むとき、商売の都合が技術の形を決めてしまう場面がしばしばあり、ここはその典型例だからです。

最初、ソフトウェアには値段がついていなかった

大型計算機の時代、ソフトウェアは基本的に機械のおまけでした。

計算機を売る会社は、その機械を動かすためのプログラムを一緒に提供しました。値段は機械の代金に含まれていました。ソフトウェアだけを取り出して売る、という発想がそもそもなかったのです。

考えてみれば当然で、当時のソフトウェアは特定の機械でしか動きません。機械を持っていない人に売っても使えないのですから、独立した商品として成り立ちにくい状況でした。

ただし、まったく無かったわけではありません。1960年代の半ばには、独立系のソフトウェア会社がすでに現れています。プログラムの流れ図を自動で描き起こす製品が1960年代半ばに商品として売られ、これが商用ソフトウェアの最初期の例とされています。1967年には、売上が百万ドルに達した製品も出ました。

とはいえ、こうした会社は苦しい立場にありました。同じような機能のものが、機械のおまけとして代金なしで付いてくるからです。値札のついた製品が、値札のない製品と競争しなければならない。市場は開いていましたが、ごく細く開いていただけでした。

1969年に起きたこと

この状況が変わる転換点が、1969年です。

当時、大型計算機市場で圧倒的な位置にあったIBMという会社が、ソフトウェアとサービスの価格を、機械本体の価格から切り離すと発表しました。「アンバンドリング」と呼ばれる出来事です。バンドル(抱き合わせ)を解く、という意味ですね。

同じ年の初めに、アメリカ司法省が独占禁止法違反の疑いでIBMを訴えています。ソフトウェアを代金なしで抱き合わせることが、他社の販売機会を奪っている、という趣旨でした。時期が重なっているため、「訴訟がきっかけだった」と説明されることが多い出来事です。

ただし、ここは断定を避けておきます。当時の関係者の回想などによれば、IBMは訴訟の数年前から価格の切り離しを検討していたとされ、大型機のソフトウェア開発費と保守費が膨らみすぎていたことや、独立系の会社が台頭してきたことのほうが本筋の理由だった、という見方も有力です。歴史の「きっかけ」は、後から分かりやすい一本の線として語られがちですが、実際には複数の事情が同時に効いていることのほうが多い、という例として押さえておくといいと思います。

いずれにせよ、この切り離しによって何が起きたか。

ソフトウェアの多くに、値札がついたのです。

正確には、すべてではありません。OSなどの基幹部分は、このあとも機械に付属する形で提供され続けました。値札がついたのは、応用寄りの製品群です。

それでも影響は決定的でした。値札がつくということは、他社も同じ土俵で勝負できるということだからです。IBMの計算機を買った会社が、IBM製ではない集計プログラムを買ってもよい。しかもそのほうが安くて高性能なら、そちらを選ぶ理由がある。

細く開いていた市場が、ここで一気に広がりました。カタログに「ソフトウェア」という項目が立ち、そこに複数社の製品が並ぶようになります。

～～なぜこの話を長々としたか～～

ここで言いたかったのは、ソフトウェアが産業として広がったのは、技術の進歩によってではなく、価格の付け方が変わったからだということです。

技術的には、1969年の前後でソフトウェアの作り方が変わったわけではありません。変わったのは、それを誰がいくらで売れるか、というルールのほうでした。

このあと出てくるパソコン時代の爆発的な広がりも、根っこにはこの変化があります。ソフトウェアに値段がつく世界だったからこそ、個人が作ったプログラムが商品になり得たのです。

技術の歴史を追うとき、「なぜそうなったのか」の答えが技術の外側にあることは、思っているよりずっと多いと感じます。

10. キラーアプリケーション ― ソフトがハードを売る

1970年代の後半になると、机の上に置ける大きさのコンピューターが登場します。パソコンです。

ただし、初期のパソコンは、今の感覚とはまったく違うものでした。

～～買っても、やることがなかった機械～～

登場したばかりの頃 ― 1970年代の半ばあたりのパソコンには、はっきり言って使い道がありませんでした。

買って、組み立てて、電源を入れる。すると何ができるか。自分でプログラムを書けば、書いたとおりに動きます。書かなければ、何も起きません。

つまり、プログラムを書ける人にとっては夢のような機械でしたが、書けない人にとってはただの箱でした。実際、この時期にパソコンを買ったのは、その多くが「自分でプログラムを書くことそのものを楽しむ人」でした。

パソコンを作る会社としては、ここが悩みどころです。機械の性能をいくら上げても、買う人の数が増えません。プログラムを書ける人の数以上には、市場が広がらないからです。

1970年代の後半に入ると、文書を書くためのソフトなど、買ってすぐ使える製品もぽつぽつ出てきます。ただ、それらは「あると便利なもの」であって、「これのために機械を買う理由」にはまだなっていませんでした。

～～「この一皿のために店に通う」～～

ここで登場する考え方が、キラーアプリケーションです。

意味はこうです。そのソフトを使いたいがために、人が機械のほうを買ってしまう。そういうソフトのこと。

前の記事で、常連客の注文を先読みする定食屋のたとえを使いました。その世界観をもう一度使わせてください。

ある定食屋に、名物の一皿があるとします。その一皿があまりに評判で、「あれを食べるために、わざわざ二駅先から通う」という客が出てくる。このとき、客を呼んでいるのは店構えでも立地でもなく、その一皿です。

キラーアプリケーションというのは、この名物の一皿にあたります。機械を買う理由が、機械そのものではなく、その上で動く特定のソフトになる。主客が逆転するわけです。

～～最初の一皿は、表計算だった～～

そして史上初のキラーアプリケーションとされているのが、1979年10月17日に登場したVisiCalcという表計算ソフトです。作ったのはダン・ブリックリンとボブ・フランクストン。当初はApple IIという機械の専用でした。

このソフトが、どれくらい機械を売ったか。記録に残っている数字が、なかなか強烈です。

1979年に売れたApple IIのうち、四分の一以上がVisiCalcを使うための購入だったと報じられています。当時の販売店からは「他のソフトを全部合わせたより、VisiCalcのほうが業務用途の機械を売った」という趣旨の証言も残っています。Apple IIを設計したスティーブ・ウォズニアック自身も後年、「自分たちが想定していた趣味人ではなく、小さな商店がApple IIの九割を買っていった」という趣旨のことを語っています。作り手の予想が外れた形ですね。

値段の対比も面白いところです。VisiCalcは100ドルを下回る価格でした。一方、それを動かすには本体に加えてディスク装置やメモリの増設が必要で、一式そろえると2,000ドル前後になりました。

100ドルのソフトを使うために、20倍の値段の機械一式を買った。

機械が主でソフトが従、という関係が、このとき完全にひっくり返りました。

11. 表計算の、何がそんなに衝撃だったのか

ここで疑問が湧くはずです。表計算ソフトの何が、そこまで人を動かしたのか。

今の私たちは表計算ソフトを当たり前に使っているので、かえって分かりにくくなっています。少し丁寧に見てみましょう。

～～紙の帳簿で何が起きていたか～～

表計算ソフトが登場する前、商売の計算は紙の上で行われていました。

縦横に線を引いた大きな紙に、項目と数字を並べます。列ごとに合計を出し、行ごとに合計を出し、全体の合計を出す。手で、電卓を叩きながらです。

さて、ここで問題が起きます。

途中の数字がひとつ変わったら、どうなるか。

その数字を含む列の合計が変わります。行の合計も変わります。それらを使って計算していた利益率も変わります。利益率から計算していた予測も変わります。

紙を全部やり直しです。

これがどれほど深刻かというと、たとえば「もし来月の売上が一割落ちたらどうなるか」を検討したいとします。紙の帳簿の時代には、この検討をするために、帳簿をもう一枚、丸ごと作り直さなければなりませんでした。

だから、検討は現実的に一回か二回しかできません。「もし」を三十通り試すなんて、時間的に不可能でした。

～～自動で計算し直される、ということ～～

表計算ソフトがやったのは、この「やり直し」を機械にさせることでした。

各マスに、数字そのものではなく計算の式を入れておく。「このマスは、上の三つのマスの合計である」というふうに。すると、上のマスの数字を書き換えた瞬間に、合計のマスが自動的に計算し直されます。そして、その合計を使っている次のマスも計算し直され、さらにその先も計算し直される。

身近な例で考えてみましょう。アルバイトのシフト表を作っているとします。日ごとの勤務時間があり、それに時給を掛けて日給が出て、日給を足し上げて月給が出て、全員分の月給を足して人件費の合計が出る。

ここで、時給を1円だけ上げてみます。

紙なら、全員分の全日分を電卓で計算し直しです。表計算なら、時給のマスを書き換えた瞬間に、日給も月給も人件費の合計も、すべて一斉に書き換わります。

「もし」を試すコストが、ほとんどゼロになった。

これが衝撃の正体です。表計算ソフトが売ったのは、計算の速さではありません。試行錯誤の自由を売ったのです。

～～検討の回数が、仕事の質を変える～～

ここが、この話でいちばん面白いところだと私は思っています。

一回しか検討できないときと、三十回検討できるときでは、出てくる結論の質が違います。一回しか試せないなら、人は最初に思いついた案を通すしかありません。三十回試せるなら、思いつかなかった案まで試して、いちばん良いものを選べます。

つまり表計算ソフトは、計算を速くしたのではなく、意思決定のやり方そのものを変えたわけです。

ソフトウェアが世の中に与える影響は、しばしばこういう形で現れます。「今までできたことが速くなる」のではなく、「今までやろうとも思わなかったことが、やれるようになる」。前者は便利さですが、後者は変化です。

～～追いかけた製品たち～～

1981年にIBMがパソコン市場に参入すると、この機械向けの表計算ソフトとして、1983年1月にLotus 1-2-3という製品が登場します。表計算に加えて、グラフを描く機能とデータを整理する機能が一体になっていたのが特徴でした。名前の1-2-3は、この三つの機能を指しています。

この製品は、IBMのパソコンとその互換機にとってのキラーアプリケーションになりました。VisiCalcがApple IIを売ったのと同じことが、別の機械で繰り返されたわけです。

このころから、ソフトが機械を選び、機械がソフトを選ぶという相互の関係が、業界の基本構造になっていきます。

12. 個人が作り、個人が配る ― もうひとつの流れ

大きな会社が作る商品としてのソフトウェアと並行して、まったく違う流れも生まれていました。

～～作った本人が、直接配る～～

1980年代の初め、プログラムを書いた個人が、それを自分で配り始めます。

配る手段は、当時としては最先端でした。パソコンに通信用の装置をつなぎ、家庭に引かれていた回線を通じて、別のパソコンとデータをやりとりする。そういう仕組みが使えるようになっていたのです。

有志が運営する電子掲示板があり、そこにプログラムを置いておく。欲しい人が回線をつないで取りに来る。会社も店も通しません。

～～「使ってみて、よければ払ってください」～～

ここで、面白い商売の形が生まれます。

**まず使ってもらう。気に入って使い続けるなら、作者に代金を送ってほしい。**金額は作者が自分で決め、店頭に並ぶ製品よりはずっと安いのが普通でした。支払うかどうかは利用者の判断に任されます。

この形を、現在ではシェアウェアと呼びます。

ひとつ注意が要るのは、言葉の来歴です。1982年に通信用のソフトを配った作者は、この方式を「フリーウェア」と名づけていました。つまり当初のフリーウェアは「代金なし」という意味ではなく、「気に入ったら送ってほしい」という意味だったのです。「シェアウェア」という語は翌年に別の作者が使い始め、そちらが定着しました。

現在では、フリーウェアは「代金がかからないもの」、シェアウェアは「試してから払うもの」という使い分けが一般的です。ただ、1980年代前半の文献を読むときは、この語がひっくり返っていることを頭に入れておかないと混乱します。

今から見ると牧歌的ですが、この仕組みには筋が通っています。ソフトウェアは、コピーするのに材料費がかかりません。だから、まず配ってしまっても損はしない。実際に気に入った人だけが払う形にすれば、宣伝費も店に払う手数料もかからず、その分を安くできる。

複製にコストがかからないというソフトウェアの性質を、商売の形にそのまま持ち込んだのが、この仕組みでした。

～～この流れが今につながっているもの～～

シェアウェアという言葉そのものは、今ではあまり使われません。しかし、考え方は形を変えて生き残っています。

基本機能は代金なしで使えて、追加機能に課金するアプリ。一定期間試してから購入を決める仕組み。どちらも「まず使ってもらう」という発想の子孫です。

もうひとつ、この時期に別の場所で生まれた流れがあります。ソフトウェアの設計図にあたるもの ― ソースコードそのものを公開し、誰でも読んで改良して再配布してよい、とする考え方です。

このやり方で作られた代表格が、先ほど規模の話で触れたLinuxです。1991年に一人の学生が公開した小さなものが、世界中の技術者の手で育てられ、今では4,000万行を超える規模になっています。

シェアウェアが「代金の取り方」の工夫だったのに対し、こちらは「作り方」そのものの工夫でした。一人では作れない規模のものを、作者を限定しないことで作ってしまう。まったく違う発想です。

13. OSとアプリ ― 境界線は、思ったよりあいまい

ここで、ソフトウェアの分類を整理しておきます。

大きく分ければ、ソフトウェアはOSとアプリケーションの二つに分かれます。OSは下働きをする側、アプリケーションは目的の仕事をする側です。

ただし、この境界線は見た目ほどはっきりしていません。

～～中に入ったり、外に出たりする～～

たとえば、文字を入力する仕組みを考えてみてください。日本語を打つには、ローマ字をひらがなに変え、漢字に変換する仕組みが必要です。

これはOSの一部でしょうか。それともアプリでしょうか。

答えは「時代と製品による」です。OSに組み込まれていることもあれば、別のソフトとして入れることもあります。

同じことが、いろいろな機能について起きてきました。画面に絵を描く仕組み、通信をする仕組み、動画を再生する仕組み、文字を検索する仕組み。これらは歴史上、OSの外にあったり中に入ったりを繰り返しています。

便利な機能は、時間が経つとOSに吸収されていくという傾向があります。最初は誰かが別売りのソフトとして作り、評判になり、やがて「これはみんなが使うのだから、最初から入れておけばいい」ということになる。

さきほどのOSの成り立ちを思い出してください。「全員が書いている共通部分を、一回だけ書いて、全員で使う」でしたね。この動きは、今も続いているわけです。

～～呼び名が場所によって違う～～

もうひとつ、混乱しやすい点を潰しておきます。

同じ「アプリケーション」でも、動く場所によって呼び名が変わります。机の上で使う機械では「アプリケーション」や「ソフト」。持ち運ぶ機械では「アプリ」。ただ短くしただけで、中身の考え方は同じです。

そして、机の上の機械と持ち運ぶ機械では、載っているOSが違います。それぞれのOSは窓口の作法が違うので、同じ仕事をするソフトでも、別々に作る必要があります。

ここで、この記事の最初のほうで見た問題が、形を変えて戻ってきていることに気づくでしょうか。機械が違えば書き直し、という、あの問題です。

規模は違いますが、構造は同じです。そして、この問題に対する答えも、また似たものになります。

14. 見た目をめぐる競争と、OSの覇権

パソコン向けOSの歴史を、駆け足で追いかけます。ここは製品名が多く出てきて退屈になりがちなので、何が争点だったのかに絞って見ていきます。

最初の争点 ― 文字で操作するということ

パソコンが登場した当初のOSは、画面に文字しか出しませんでした。

操作の仕方は、命令を文字で打ち込むというものです。「このファイルを消せ」と打てば消えるし、「このファイルの名前を変えろ」と打てば変わる。

この方式には、明確な長所があります。正確で、速いのです。何をするかを言葉で指定するので、あいまいさがありません。慣れた人なら、マウスを動かすより速く作業できます。

短所も明確でした。命令を覚えていないと、何もできない。画面を見ても、何ができるのかが分かりません。

初心者にとって、これは高い壁でした。

～～二つめの争点 ― 見て分かる画面～～

ここで登場したのが、画面に絵を出して、それを指し示して操作する方式です。グラフィカルユーザーインターフェイス、略してGUIと呼ばれます。

機能を小さな絵で表し、それを指し示す。フォルダを開けば中身が見える。捨てたいものはゴミ箱に入れる。

この方式の何が優れていたかというと、覚える必要がなくなったことです。文字で操作する方式では、できることを知っていなければ何もできませんでした。絵で示す方式なら、画面を見れば、何ができるかがそこに並んでいます。

この方式そのものを作ったのはApple社ではありません。研究所での試作を経て、1981年には業務用の製品として世に出ています。ただ、いずれも非常に高価で、広まりませんでした。

一般に手の届く価格でこの方式を普及させたのがApple社で、1984年に発売したマッキントッシュ(Macintosh)という機械で採用されました。追いかけたのがMicrosoft社で、1985年11月にWindowsという製品を出します。

～～当初のWindowsは、OSではなかった～～

ここは誤解されやすいところなので、はっきり書いておきます。

最初のWindowsは、OSではありませんでした。すでにあった文字ベースのOSの上に乗って、画面に窓を表示するだけのソフトでした。

ファイルを管理するのも、装置を動かすのも、下にある従来のOSがやっています。Windowsがやっていたのは、その上に絵を描くことだけです。

このため、初期のWindowsは動作が重く、評判もよくありませんでした。当時の機械の性能では、絵を描く処理の負担が大きすぎたのです。

Windowsが本格的に普及するのは、1990年に出た三代目からです。このとき効いたのが、プロセッサの進歩でした。記事3で見たとおり、プロセッサが一度に扱えるデータの幅は世代ごとに広がっています。三代目のWindowsは、当時の新しいプロセッサが持っていたメモリ管理の機能を活かすことで、それまでの窮屈さを一気に解消しました。

なお、この三代目も、その次の版も、まだ16ビットのソフトです。完全に32ビットになるのはもう少しあとで、**「32ビットになったから普及した」のではなく、「プロセッサの新しい機能を使えるようになったから普及した」**というのが正確なところです。ここは混同されやすい部分なので、書き分けておきます。

いずれにせよ、ハードの進歩がソフトの可能性を開いた、分かりやすい例です。

～～三つめの争点 ― 過去のソフトを動かし続けられるか～～

そして、Windowsが長く使われ続けた理由として、性能や見た目以上に大きかったと言われるのが、互換性です。

OSを新しくすると、普通は古いソフトが動かなくなります。窓口の作法が変わるからです。

しかし、利用者の立場で考えてみてください。長年使ってきた業務用のソフトが動かなくなるなら、OSを新しくする理由がありません。会社であれば、その一本のソフトのために、古い機械を使い続けることすらあります。

Microsoft社は、ここに徹底してこだわりました。OSの中身を何度も作り直しながら、古いソフトが動き続けるように、互換性を保つための仕組みを用意し続けたのです。

さきほどの「役所の窓口」のたとえを思い出してください。浄水場の設備を全部入れ替えても、蛇口の形と回し方さえ同じなら、店主は困りません。Microsoft社がやったのは、中身を全部作り直しながら、蛇口だけは変えなかったということです。

技術的にはこれは非常に面倒で、OSの中に古い作法を受け付けるための仕組みを抱え続けることになります。それでもそうした理由は、技術の優劣ではなく、すでに使われているソフトの数が競争を決めるからでした。

ここでも、技術の形を決めたのは技術の外側の事情だったわけです。

～～もうひとつの系統～～

一方で、まったく別の経路をたどったOSもあります。

さきほど触れたLinuxがそれで、1991年に公開されたあと、設計図を公開して誰でも改良できる形で育ちました。机の上の機械での利用は多くありませんが、性能と安定性が重視される場所 ― たとえば、ウェブサイトを動かしている機械などでは、広く使われています。

さらに面白いのは、持ち運ぶ機械の世界です。現在最も広く使われている携帯機器向けのOSは、このLinuxの中核部分を土台にして作られています。

机の上では少数派のものが、ポケットの中では多数派になっている。同じ技術が、置かれる場所によってまったく違う結果になるという、なかなか示唆的な話だと思います。

15. もう一段上の抽象 ― 「通訳を連れて行く」という発想

ここまでの話には、繰り返し現れる型があります。

違いを吸収する層を、間に一枚挟む。

機械ごとに装置の扱いが違う → OSを挟んで吸収する。OSの中身が変わる → 窓口の作法を固定して吸収する。

この発想を、もう一段推し進めたものが1990年代半ばに登場します。

～～問題は、相変わらず「機械が違えば書き直し」～～

OSが登場しても、根本的な問題は残っていました。OSが違えば、やはりソフトは書き直しです。

ある機械向けに書いたソフトは、別のOSの機械では動きません。窓口の作法が違うからです。会社としては、売りたい機械の種類だけ、別々に作る必要がありました。

仮想の機械を、先に作ってしまう

そこで出てきた考え方が、こうです。

どこにも実在しない「架空の機械」を決めて、ソフトはその架空の機械向けに書く。そして、実在する機械のそれぞれに、架空の機械のふりをする通訳を用意する。

ソフトから見えるのは、常に同じ架空の機械です。実際に動いているのが何であっても、違いは通訳が吸収します。

たとえて言うなら、通訳を一人連れて歩くようなものです。同じ原稿を持って、どの国に行っても、その国の通訳が現地の言葉に直してくれる。話す側は原稿を書き直す必要がありません。

この考え方を広く知らしめたのが、1995年に公開されたJavaという仕組みです。「一度書けば、どこでも動く」という趣旨の言葉が、この仕組みの合言葉になりました。

～～代償は、速度～～

もちろん、ただで手に入るものではありません。

間に通訳が入るぶん、直接その機械向けに書いたソフトより遅くなります。通訳が受け取って、訳して、伝える。この手間がそのまま処理時間になるからです。

ただし、この仕組みは登場した当時からずいぶん改良されています。

まず、書いたものをその場で一行ずつ訳しているわけではありません。あらかじめ「架空の機械向けの命令」という中間の形に変換しておき、通訳はそれを受け取ります。下訳を済ませた原稿を渡すようなものですね。

さらに1990年代の終わりからは、よく通る箇所を実行中に本物の機械語へ訳しておいて、二回目からはそれを直接動かすという仕組みが入りました。同じ台詞を何度も訳すくらいなら、一度きちんと訳して覚えておこう、というわけです。

このおかげで、今日では「通訳を挟むから常に遅い」とは言えなくなっています。起動直後や、使うメモリの量では不利ですが、長く動き続ける処理では差がかなり縮まります。

それでも、「速度を多少犠牲にして、動く場所を増やす」という取引の構図そのものは変わりません。そして、機械の性能が上がるほど、この取引は有利になります。多少遅くても、機械が十分に速ければ気になりません。

記事3で見たプロセッサの高速化は、こういうところにも効いているわけです。速くなった分を、使いやすさや作りやすさに回す。性能の向上が、そのまま「体感速度の向上」として現れるとは限らない、ということでもあります。

～～いまも同じことが起きている～～

この「間に一枚挟む」という発想は、今もあちこちで使われています。

ウェブブラウザの中で動くソフトは、まさにこの型です。ブラウザという共通の土台を挟むことで、どのOSの機械でも同じものが動きます。持ち運ぶ機械向けのアプリを、一度書けば複数のOS向けに出せるようにする仕組みも、同じ考え方です。

違いを吸収する層を挟む。

この記事で何度も出てきたこの一文が、ソフトウェアという分野の、もっとも基本的な問題解決の型です。織機のカードから始まったソフトウェアの歴史は、ある意味で、この型を繰り返し応用してきた歴史だと言えます。

16. いまの地図 ― 数字で眺めてみる

最後に、現在の状況を数字で確認しておきます。本の記述は出版時点のものなので、ここは自分で調べ直した数字です。

机の上で使う機械のOSについて、ウェブの閲覧記録をもとにした統計では、2026年6月時点でおおよそ次のような分布になっています。

Windows … 約56.6%

macOS(旧称のものと合算) … 約16%

Linux … 約4.4%

ChromeOS … 約1.2%

判別不能 … 約21%

ここで見落としてほしくないのが、最後の「判別不能」です。**2割強が、どのOSとも判定できていません。**しかもこの枠は近年になって急に膨らんでおり、Windowsの割合が下がって見える理由の大半は、実はここにあると指摘されています。上の数字だけを見て「Windowsが五年で一割落ちた」と読むと、話を取り違えます。

一方、持ち運ぶ機械では、様相がまったく違います。こちらは2026年8月時点の数字です。

Android … 約67.6%

iOS … 約32.4%

この二つで、携帯機器のほぼ全部を占めます。

注意点をもうひとつ。これらの数字は、ウェブサイトの閲覧記録を集計したもので、実際に世の中に存在する機械の台数を直接数えたものではありません。閲覧の頻度が高い機械ほど多く数えられるので、実態とはずれがあり得ます。月ごとの変動も小さくなく、たとえば携帯機器の比率は同じ年の中でも数ポイント動きます。

数字を引用するときは、それが何を数えたもので、いつ時点のものかを添えておく。地味ですが、これをやるかどうかで記事の信頼度はずいぶん変わると思います。

もうひとつ、規模の数字も挙げておきます。さきほど触れたLinuxの中核部分は、2025年1月末の開発版でソースコードが4,000万行を超えました。2015年時点ではおよそ2,000万行だったので、十年でほぼ倍になった計算です。

1948年の17命令から、4,000万行へ。

そして、机の上ではWindowsが多数派で、ポケットの中ではAndroidが多数派。同じ「OS」という言葉で呼ばれているものが、置かれる場所によってまったく違う勢力図を描いている。

おわりに ― 次は、その段取りをどう書くか

今回は、ソフトウェアというものがどこから来て、どうやって今の形になったのかを追いかけました。

振り返ると、いくつかの転換点がありました。

織機のカードで、機械と段取りが分離しました。プログラム内蔵方式で、その段取りが記憶装置の中に移り、電気的に差し替えられるようになりました。OSの登場で、全員が書いていた共通部分が一箇所にまとまりました。アンバンドリングで、ソフトウェアに値段がつき、産業になりました。キラーアプリケーションの登場で、ソフトが機械を売るようになりました。そして仮想機械の考え方で、機械の違いを超えてソフトが動くようになりました。

これらに共通しているのは、違いを吸収する層を間に挟むという型でした。層を一枚増やすたびに、書く人は下の面倒から解放され、代わりに少しだけ速度を失いました。そして機械が速くなるたびに、その取引は割に合うようになっていきました。

さて、ここまでずっと「ソフトウェアとは段取りである」と言ってきました。

では、その段取りは、どうやって書かれているのでしょうか。

人間が「まずこれをして、次にこれをして、もしこうなったらこっちへ」と考えたことが、どうやって0と1の並びに変わり、記事3で見たプロセッサが実行できる形になるのか。その変換は誰がやっているのか。

次の記事では、そこに踏み込みます。人間の言葉と機械の言葉のあいだをつなぐもの ― プログラミング言語の話です。