Execution Atlas
SOFTWARE 10 min read

UNIX — 独占禁止訴訟が、商品化できないOSに世界を取らせた話

2026-07-12 ソフトウェア・IT

1969年4月、Bell Labsは7年続いたOS開発プロジェクトから撤退した。MIT・GE・AT&Tの三組織連合、数百人体制で進めていた「Multics」。約束した時期にも、その先の延期した時期にも、実用システムは届かなかった。

撤退会議の数ヶ月後、その元メンバーのひとりが、研究所の倉庫に転がっていた古いPDP-7というミニコンピュータの前に座っていた。Ken Thompson、26歳の研究員。書こうとしていたのはOSではなく、宇宙船を操縦するゲームだった。

UNIXはここから始まる。

承認なし、予算なし、人員4〜5人、初期実装期間およそ1ヶ月。半世紀後、その直系と甥っ子の子孫がiPhoneを動かし、AWSのサーバを動かし、Androidの上で世界の大半の人間がメッセージを送っている。

Mission：撤退から始まる

時系列を1964年に戻す。

Multicsは、コンピュータ史上もっとも野心的なOSプロジェクトだった。マルチユーザー、リング保護、動的リンク、大規模時系列共有。当時としては未来の概念をすべて同じシステムに乗せようとした。MITとBell Labs、それにGEの三組織が組み、Bell Labsからも10人以上が参加した。

Multicsの目的は、Bell Labs内部の技術者が共同で使える時系列共有システム（タイムシェアリング）を持つこと。1964年に合意した時点では、数年で動くはずだった。

5年経って、動かなかった。

1969年3月から4月、Bell LabsはMulticsから撤退する。Dennis Ritchieが後年回想している。「1969年までに、Bell Labsの経営陣と研究者たち自身ですら、Multicsの約束が叶うのはあまりにも遅く、あまりにも高くつくと信じるようになった」。

当時のComputing Science Research Directorだった Sam Morgan の言い方は、もう少し容赦がない。「Multicsは一度に多くの木に登ろうとしていた」。

撤退後、Ken Thompsonとその同僚はBell Labsの管理層に新しいOS開発を提案した。却下された。Multicsの数百万ドルが消えた直後だ。OS開発という単語自体がしばらく組織のタブーになっていた。

ここでThompsonは別の動機に切り替える。彼は「Space Travel」という宇宙船操縦ゲームを書きたかった。Multics上で動いていたが、計算時間が高く、操作性も悪い。Bell Labsの倉庫を歩き回って見つけたのが、誰も使っていないPDP-7だった。1965年あたりに導入されたが、もう陳腐化しかかっていたミニコンピュータだった。

ゲームを移植するためには、ファイルシステムが要る。ファイルシステムを書くなら、その上でアセンブラとローダが要る。書いていったら、それはほとんどOSになっていた。

Design：Multicsから1番良いものを抜き出す

UNIXの設計判断の特徴は、Multicsを否定したことではない。Multicsの中から「これだけは絶対残す」というものを抜き出し、その他を全部捨てたことだった。

残されたもの。

階層型ファイルシステム。Multicsの最大の発明のひとつだった。ファイルが入れ子のディレクトリで整理される。今となっては当たり前だが、当時のOSの多くはフラットなファイルリストだった。

シェル。OSとユーザーが対話するための薄い層。コマンドを打つと実行される。

時系列共有。複数ユーザーが同時に使える。ただしMulticsのような大規模ではなく、当初は2人。

捨てられたもの。

リング保護機構。動的リンク。仮想メモリの精緻な管理。マルチユーザー認証の複雑なポリシー。Multicsを「Multics」たらしめていた高機能の数々。

そして、決定的に違うのが2つあった。

ひとつめは「すべてがファイル」という抽象化。ハードディスクの中身も、テープデバイスも、プリンタも、UNIXからは同じファイルとして見える。read()とwrite()という同じ命令で操作できる。デバイスごとに違う命令体系を覚える必要がない。

ふたつめは「パイプ」。Doug McIlroy が1960年代から温めていた構想を、1973年に Thompson が実装した。あるプログラムの出力を、そのまま次のプログラムの入力につなぐ。| 記号でつなぐだけだ。

ls /usr | grep ".txt$" | sort | wc -l

4つの小さなツールが3本のパイプで繋がっている。ls はファイルを並べることだけを知っている。grep は文字列を絞ることだけを知っている。sort は並び替えることだけを知っている。wc は数えることだけを知っている。誰も全体の意図を知らないまま、結果として「テキストファイルの個数」が出る。

McIlroy はこの設計思想を、1978年に Bell System Technical Journal の UNIX 特集号 foreword に4つの原則として書き残した。

  1. 各プログラムは一つのことをうまくやれ。新しい仕事のためには、既存のプログラムに「機能」を足すのではなく、新しく作り直せ。
  2. すべてのプログラムの出力が、まだ知られていない別のプログラムの入力になることを想定せよ。出力に余計な情報を混ぜるな。整列された列入力や厳格なバイナリ入力形式を避けよ。対話的入力を強要するな。
  3. ソフトウェア（OSを含む）は、できるだけ早く試せるように設計せよ。理想は数週間。不格好な部分は迷わず捨てて、作り直せ。
  4. プログラミングを楽にするためには、訓練されていない人手より道具を使え。道具を作るための回り道を厭うな。使い終わったら捨てよ。

後年、これをさらに圧縮した3行が、もっともよく引用される「Unix哲学」として独り歩きする。

プログラムは一つのことをうまくやれ。 プログラム同士が協調するように書け。 テキストストリームを共通インターフェイスにせよ。

4原則と3行を並べると、原典の方が「捨てる」という動詞を2回使っているのに気づく。McIlroy の哲学の核は「組み合わせ」ではなく、「捨てる」だったのかもしれない。Multics が捨てられなかった機能を、UNIX は最初から捨てる前提で書いた。

Multicsが「すべてを内部に持つ巨大OS」だったのに対し、UNIXは「小さな道具を組み合わせる空間」だった。同じBell Labsで生まれた、対照的な設計思想。

Execution：1ヶ月のカーネル、特許部門の予算、Cという賭け

最初のUNIXは1969年の夏に書かれた。Thompsonが約4週間で、PDP-7のアセンブリで実装した。クロスアセンブラはGECOS（GEのメインフレーム）上で動かし、紙テープに穿孔してPDP-7に運んだ。

紙テープでOSをロードするマシンに、ファイルシステムとシェルとエディタを実装した1ヶ月。Multicsの数百人×5年に対する、ひとりの夏休み。

ただし、ここから先に進むためには予算が要る。Bell Labsは公式にはOS開発を承認していない。Thompsonたちは別の言い方を見つける必要があった。

Bell Labsの特許部門が、ちょうど文書作成ツールを探していた。当時の特許申請は機械式タイプライタで書かれていて、訂正のたびに全ページを打ち直していた。Doug McIlroyが書いた組版プログラム「roff」がPDP-11上のUNIXで動くようになり、Joe Ossannaがその後継として nroff と troff へと発展させていく。特許部門は喜んだ。彼らがPDP-11/20の購入予算を出した。

OSとしての予算ではなく、組版ツールとしての予算。

これでUNIXは公式の存在になる。1971年、初版マニュアル（V1）が出る。社内では、ベル研究所の研究者たちが文書を書くためにUNIXを使い始めていた。OSは、文書作成という副次的な目的の付属物として、こっそり存在していた。

ここで1973年の決定的な賭けに進む。

Ken Thompsonは1969年から1970年にかけて「B」という言語を作っていた。Dennis Ritchieがそれを発展させ、1971年から1973年にかけて「C」という言語にした。型を持ち、構造体を持ち、PDP-11の特性に合わせて設計された。

1973年、Thompsonと Ritchieは UNIXカーネル本体をCで書き直す。

当時のOSは機種ごとにアセンブリで書かれていた。マシンが変われば、全部書き直しだ。OSをコンパイラ言語で書くというのは、性能を捨てる代わりに移植性を取るという賭けだった。

短期的にはコストだ。動いていたものを書き直すのだから。

長期的には何が起きたか。1976年、UC Berkeleyが PDP-11上でUNIXを使い始めた。Cで書かれていたから、移植は数ヶ月で済んだ。1977年、Bell Labsの内部で UNIXは VAX-11/780に移植された。同じく数ヶ月。その後 IBM 370、各種のミニコンピュータ、ワークステーション、そしてPCへ。

1973年の手戻りひとつで、その後の何十回もの移植が安価になった。

UNIXがCで書かれていなければ、80年代のワークステーション市場も、Linuxも、macOSも生まれていない。

People：4人の研究員と、訴訟という追い風

Ken Thompson。1943年生まれ。UC Berkeley出身。MITでMulticsに関わり、Bell Labsへ。チェスのプログラムも書く、数学もできる、ハードウェアもいじる。UNIXの最初のカーネルを書いた。

Dennis Ritchie。1941年生まれ。ハーバードで物理学、その後コンピュータサイエンス。ThompsonとともにMulticsからUNIXへ移った。C言語の設計者。物静かで、論理的で、文章がうまかった。後年の UNIX論文の多くを書いている。

Doug McIlroy。1932年生まれ。Computing Techniques Research Department head（1965-1986）。組織として UNIXを守った人。「パイプ」のアイデアを提唱し、Unix哲学を1978年のBell System Technical Journal UNIX特集号の foreword で言語化した。Thompsonたちより一回り上の世代で、上層部との緩衝材だった。

Joe Ossanna。1928年生まれ。troff（組版）の開発者。特許部門との橋渡し役。1977年11月に48歳で亡くなったが、UNIXの「事実上の予算化」を可能にした人物。

このメンバーが、Multicsの撤退会議の余白で集まっていた。4人とも、Multicsという大計画が動かなくなる過程を内側から見ていた。何を入れると重くなるか、何を抜くと動き始めるかを、文章ではなく身体で覚えていた。

そして、ここに偶然の外部要因が重なる。

AT&Tは独占禁止法の訴訟下にあった。1956年の同意判決により、AT&Tは通信事業以外の商売を実質的に禁じられていた。UNIXはソフトウェアであり、商品にできなかった。

商品にできないものは、配るしかない。

1974年、AT&Tは大学にUNIXのソースコードを「教育目的に限り、ほぼ無償で」配布し始める。UC Berkeleyが受け取り、それを改良し、再配布した。これがBSDになる。MITも受け取った。各国の大学も受け取った。

商売にできなかったことが、結果的にエコシステムを生んだ。1982年にAT&Tの独占が解かれてUNIXを売り始める頃には、もう世界中の大学にUNIX文化が根付いていた。

訴訟が UNIXを救った、と言うこともできる。Ritchieは控えめに次のように書いている。「私たちはUNIXが普及するとは思っていなかった。少なくとも、それが目的ではなかった」。

Thompsonと Ritchieは1983年、ACMチューリング賞を共同受賞する。受賞理由は「汎用OSの理論の発展、そしてその顕著な実装であるUNIXの実装」。Multicsの撤退から14年経っていた。

Legacy：4人が書いたものは、いま地球上で何回動いているか

2026年現在の数字を並べる。

世界のサーバの大半はLinuxで動いている。Linuxは1991年、フィンランドの大学生 Linus Torvaldsが「自分のPCで動かしたいUNIX的なもの」を独立に書き始めたカーネルだ。Bell Labsのコードは入っていないが、設計思想、APIの形、システムコールの哲学、すべてがUNIXから来ている。

macOSはDarwinというカーネルの上で動き、その血統はBSD（UC Berkeleyの UNIX系列）に直接つながる。1973年のCの書き直しが、2026年のMacBookで動いているのは、過剰な詩的表現ではなくて、実際にそうだ。

iOSはmacOSと同じ系譜。AndroidはLinuxカーネルの上で動く。世界のスマートフォンのほぼ全てが、UNIXの直系か甥っ子だ。

AWSのEC2インスタンス、Google CloudのVM、Microsoft Azureの主要な仮想マシン。ほとんどがLinux。インターネットを動かすルータの中のOSも、たいていはUNIX系。

世界中で、毎秒、UNIXのシステムコールが何兆回呼ばれているか、正確な数字は誰も持っていない。

Multicsは1970年代後半まで Honeywell が販売し、1985年に新規開発が止まった。最後のMulticsシステムは2000年に停止された。

4人が3ヶ月で書いたOSが、数百人が7年かけて書いたOSを30年以上生き延びた、と書いても歴史を歪めない。

数字でもう一段。

1973年10月、Bell LabsはSOSP（Symposium on Operating Systems Principles）という学会でUNIXを発表した。Ritchieの後年の論文によれば、当時の社外の利用機関は16前後。それが80年代に入る頃には主要大学とミニコンピュータメーカーの大半に広がり、90年代以降は「数えること自体が意味を失う」規模になった。1991年にLinuxが登場し、累計利用台数の概念がついに崩れる。

UNIXの後継たちは、IBM System/360、Multics、CTSS、VMS、Windows NT、これらすべてを世代交代の過程で吸収するか、置き換えるか、共存するかしてきた。

唯一の例外は、UNIXとは別系統で進化し続ける Windows系だが、その Windows もWSL（Windows Subsystem for Linux）でUNIXを内部に取り込んでいる。

OS本体だけでなく、Unix哲学そのものが現代の設計思想に染み込んでいる。マイクロサービス・アーキテクチャの「サービスは一つのことをうまくやれ」、REST API の「テキストを共通インターフェイスに」、Docker コンテナの「使い終わったら捨てよ」、これらは McIlroy が1978年に書いた4原則のほとんど直訳だ。半世紀前に Bell Labs の特許部門の予算で動いていた小さなOSの設計思想が、Amazon や Netflix のインフラ設計の議論の前提になっている。

学び：計画されないプロジェクトが、計画されたプロジェクトに勝つ構造

UNIXの物語から取り出せる教訓のうち、もっとも鋭いものを1つだけ書く。

承認を取らずに進めた方が、結果的に長く生き残るプロジェクトが存在する。

これは「承認制が悪い」という話ではない。承認制が必要なプロジェクトは多い。インフラ、法規制、安全性、これらは承認なしでは進められない。

しかしソフトウェアのある種のプロジェクトは、承認制と相性が悪い。理由は3つある。

1つめ。承認制は「失敗のコスト」を可視化する。可視化されたコストは、撤退判断を遅らせる。Multicsは「数百万ドル投じた後だから引けない」という形で長く生き延びた。当事者たちは「動かない」と感じていたが、撤退の合意形成に時間がかかった。

2つめ。承認制は「合意の範囲」を縛る。提案時に書いたものから外れた変更は、再承認が要る。再承認には時間が要る。「Multicsから一番良いものを抜き出して小さくする」というUNIXの設計判断は、承認制の中では発生しなかった。提案として通せる形ではなかったからだ。

3つめ。承認制は「責任」を分散する。何かが動かなかったとき、誰の責任かが明確になる構造は、誰も決定的な判断をしなくなる構造でもある。UNIXは、Thompsonが「自分が使うために書いた」だけだったので、誰の責任もなかった。誰の責任もないものは、誰にも止められない。

ここで逆説に踏み込む。

UNIXが10年後、20年後に世界を支配することを、誰も予測していなかった。Thompson本人も、Ritchieも、McIlroyも、上層部の誰も。だから誰も「重要なプロジェクト」として扱わなかった。重要なプロジェクトでなかったから、組織政治が介入しなかった。介入しなかったから、4人が良いと思う設計判断がそのまま実装された。

そして、その良い設計判断が、結果的に世界を支配した。

このパターンは何度か繰り返されている。Linuxは Linus Torvaldsが大学生のときに「自分のPCで動くMinix代替が欲しい」と思って書き始めた。AWSは Amazonの内部インフラとして始まり、外販する予定はなかった。Gitは Linuxカーネル開発の道具として2週間で書かれた。

承認制の外側で生まれ、結果的に内側を凌駕する。

ここから取り出せる問いは「正解を選べ」型ではなく、構造のトレードオフだ。

あなたの組織には、承認を取らずに進んでいるプロジェクトがあるか？ それは何の予算で動いているか？ もし「本業」として承認制に乗せた瞬間に、何が変わるか？

Bell Labsの特許部門が UNIXの予算を出していなければ、UNIXは1972年に消えていた。承認を取らずに進めるためには、組織のどこかに「副次的な目的」を見つけるか、自分の余暇時間を使うか、別の予算名目を借りるか、いずれかが要る。

UNIXは「特許部門の文書作成ツール」という形で承認制と共存した。承認制を否定したのではなく、承認制の隙間に落ちていた。

組織の中の小さな余白を見つけられる人だけが、計画されないプロジェクトを生かし続けられる。

Multicsが約束したものは、いまもまだ完成していない。Thompsonが「自分のために」書いたものは、いまも動き続けている。

出典・参考資料

関連記事

航空・宇宙

アポロ計画 — 方法を知らないまま月を目指した8年間

通信インフラ

Starlink — 一企業が国家インフラになるまでの11年

鉄道・道路・交通

設計図が完成する前に着工した代償 — ベルリン空港はなぜ14年かかったのか

Project Timeline