📅 執筆：2026年7月
⚠️ Bell Labsのオリジナル文書および開発者のメモに基づく

「世界で一番優れたオペレーティングシステムは何か」と尋ねられたら、おそらくLinux、macOS、Windowsと答えるでしょう。

しかし、Unixを作ったKen ThompsonとDennis Ritchieに聞けば、答えはPlan 9になるでしょう。

Plan 9は1980年代後半から1990年代初頭にかけてBell Labsで開発されたOSで、Unixを作ったのと同じチームによるものです。ただし、これは単なる「新しいUnix」ではなく、ゼロからの完全な再設計でした。

今日、Plan 9を日常的に使っている人はほとんどいませんが、そのコンセプトは今使っているすべてのOSに浸透しています。

始まり — 「Unixはもう古くなった」

Unixが抱えていた問題

Unixは1969年に誕生しました。当時のコンピュータは1台のマシンに複数の端末が接続されるだけでした。

1980年代になると世界は変わりました — ネットワークが標準となり、グラフィックスが重要になり、分散コンピューティングが始まりました。

しかしUnixはこれらを想定して設計されていませんでした。パッチを当て、拡張し、後付けを繰り返した結果、開発者自身も複雑さに辟易するシステムになっていました。

Ken Thompsonはこう述べています：「Unixはシンプルに始まったが、徐々に複雑さを溜め込んでいった — もう一度最初からやり直す時が来た」

なぜ「Plan 9」という名前か

「Plan 9」という名前は、Ed Wood監督のB級映画の古典「Plan 9 from Outer Space」（1959年）から来ています。この映画は「史上最悪の映画」と呼ばれています。

しかしこの名前はOSが悪いという意味ではありません — Bell Labsのチームが好んだ内輪ネタです（Unix自体もMulticsを揶揄した名前でした）。

Plan 9の核心 — 「すべてはファイル」

UnixからPlan 9へ — 徹底した拡張

Unixには有名な考え方があります：「すべてはファイル」

  • ファイルシステム → /home/user/document.txt
  • デバイス → /dev/sda, /dev/tty
  • プロセス → /proc/1234

しかし例外がありました — ネットワークソケット、グラフィックス、ウィンドウシステムなどはUnixではファイルではありませんでした。

Plan 9はこの考え方を極限まで推し進めました — Plan 9ではすべてがファイルで、例外はありません。

9P — すべてを繋ぐ単一のプロトコル

Plan 9の核心は9Pです — すべての要素がファイルシステム経由で通信するプロトコルです。

GUIウィンドウ → ファイルとしてマウント
ネットワーク接続 → ファイルとしてマウント  
ネットワーク上の他マシン → ファイルとしてマウント

Enter fullscreen mode Exit fullscreen mode

想像してみてください：他のマシンのファイルをlsで表示でき、それがローカルディスクのように見えます — NFSやSambaなどの複雑な仕組みは必要ありません。

実際の例： Plan 9でエディタ（acme）を開くと、そのウィンドウは/mnt/acme/内のファイルとして存在します。echo "hello" > /mnt/acme/bodyとすると、即座にエディタにテキストが表示されます。

Plan 9のGUIは「画面に絵を描くプログラム」ではなく、「たまたまグラフィック表示できるファイルシステム」です。

Namespace — 各プロセスごとのプライベートビュー

Linuxでは、すべてのプロセスが同じファイルシステムを見ています。

Plan 9では、各プロセスが独自のnamespaceを持っています — 他のプロセスに影響を与えずに、ファイルシステムのマウント・アンマウント・再構成が可能です。

プロセスA: /bin → /usr/local/bin
プロセスB: /bin → /remote/machine/bin

Enter fullscreen mode Exit fullscreen mode

これら2つのプロセスは異なるファイルシステムを見ていますが、同じマシン上で動作しています。

この考え方は、Dockerやコンテナで使われているLinux namespacesの起源です。

Plan 9での生活 — 実際の使い心地

Rio — タイトルバーのないウィンドウ

RioはPlan 9のウィンドウシステムで、極めてミニマルです。

タスクバー、デスクトップアイコン、最小化ボタンはなく、マウスの3ボタンだけでウィンドウを操作します。

  • 左ボタン = テキスト選択
  • 中央ボタン = 実行（選択したテキストを実行）
  • 右ボタン = メニュー（New, Resize, Delete など）

実際の使用例：

ターミナルを開いてls -laと入力すると結果が表示されます。興味のあるファイル名を左ボタンで選択 → 中央ボタンを押す → Plan 9が自動的にそのファイルを次のコマンドの引数にします。

エディタでも同様です：man 9pと入力 → 選択 → 中央ボタン → manページが即座に開きます。

基本的な考え方は：コピー＆ペーストは不要 — 選択して実行するだけです。選択したものはすべてコマンドになります。

これは現代の使い方とは全く異なるUXです — クリップボードもCtrl-C/Ctrl-Vもありませんが、慣れると遥かに高速で自然です。

Acme — エディタ以上の存在

AcmeはRob Pikeが作った伝説的なテキストエディタで、「ハイパーテキスト風のマウス操作ウィンドウ」です。

  • Acme内のすべての単語がクリック可能なリンク
  • シェルコマンドをバッファに書いてクリックするだけで実行可能
  • 開いているすべてのファイルがマウスジェスチャーで操作可能なウィンドウ

現代から見れば原始的に見えますが、これは現代のIDEの原型です：コード + ターミナル + ファイルブラウザが1つのウィンドウに統合されています。

Plumbing — D-Bus以前のメッセージバス

PlumbingはPlan 9内のプログラム間メッセージングシステムです。

URLをクリック → ブラウザに送られる
エラーメッセージをクリック → その行のファイルが開かれる

すべてがファイルで繋がっており、plumbingは読み書き可能な特殊なファイルです。

Plan 9の遺産 — 今日まで残るもの

1. UTF-8 — ダイナーの紙ナプキンで生まれた

1992年の夜 — Ken ThompsonとRob Pikeがニュージャージーのダイナーで夕食を食べていました。

彼らは当時の問題を議論していました — コンピュータの世界にはASCII、Latin-1、Shift-JISなど何百ものエンコーディングがあり、それぞれが単一の言語に対応していました。

2人は紙ナプキンを取り出してUTF-8を設計しました — ASCIIと後方互換性があり、世界中のすべての言語をサポートするエンコーディングです。

今日、UTF-8は世界中のウェブの98%で使用されています。

そしてそれはPlan 9の開発中に、Plan 9の開発者たちによって設計されたのです。

2. /proc ファイルシステム — Unixで生まれたが、Plan 9が完成させた

Linuxユーザーは/procを知っています — プロセス情報を格納するファイルシステムです：

cat /proc/cpuinfo    # CPU情報を表示
cat /proc/meminfo    # メモリ情報を表示

Enter fullscreen mode Exit fullscreen mode

/procはUnix第8版（1984年）でTom Killianによって初めて実装されました。彼は1984年6月のUSENIXで「Processes as Files」という論文を発表しました。これはPlan 9の開発開始前です。

しかしUnix 8版の/procはフラット構造でした — 1プロセス = 1ファイル

Plan 9はこの考え方を発展させ、各プロセスをディレクトリにし、複数のサブファイルを持たせました（lsで表示、catで値を読み取り可能） — これが今日使われている階層的な/procの原型です。

Linuxはこの階層モデルをPlan 9から継承し、/procは今や標準となっています。

3. Linux Namespaces — すべてのコンテナのルーツはPlan 9

Docker、Kubernetes、すべてのコンテナ — Linux namespacesを使ってプロセスを分離しています。

「各プロセスが異なるシステムビューを持つ」という考え方 — これはPlan 9で生まれました。

イメージで言うと：Plan 9は1980年代後半からper-process namespaceを考えていました — Dockerやコンテナの基盤となるLinux namespacesがカーネルに登場したのは2008年頃で、約20年後です。

4. Go — Plan 9のDNAを受け継ぐプログラミング言語

GoはRob Pike、Ken Thompson、Robert Griesemerによって作られました — 3人ともPlan 9での経験があります。

そしてGoにはPlan 9の考え方が満載です：

  • Goroutines — 軽量スレッド → Plan 9の軽量プロセスの原型
  • Channels — メッセージパッシングによる通信 → 9Pとplumbingの原型
  • Gofmt — 誰もが同じ見た目のコードを書く → Plan 9の「一つの最善の方法」という哲学の原型
  • 静的バイナリ — 単一ファイルにコンパイル → Plan 9バイナリの原型

Goはプログラミング言語の形をしたPlan 9です。

なぜPlan 9は成功しなかったのか

解決できなかった問題

  1. 鶏と卵の問題 — ユーザーがいないからアプリケーションがない → アプリケーションがないからユーザーがいない
  2. ライセンス — 1990年代にBell Labsが何度も売却され（AT&T → Lucent → ...）、Plan 9のライセンスが複雑化した
  3. Linuxの勝利 — Plan 9が安定した頃（1990年代中盤）、Linuxは急成長中でエコシステムがはるかに大きかった
  4. ハードウェアサポート — Plan 9はLinux/Windowsに比べて対応ハードウェアが非常に少なかった

しかし根本的な問題は：Plan 9は「Unixより少し良いもの」を目指したのではなく、「完全に新しいもの」を目指したことです。

そして世界は新しいアイデアのためにOS全体を置き換える準備ができていませんでした — たとえそれらのアイデアが優れていたとしても。

2026年のPlan 9

Plan 9はまだ生きています — 9front（コミュニティフォーク）とPlan 9 from User Space（Linux/macOS向けツールの移植版）という形で。

Plan 9を日常的に使っている熱心なグループが存在します — 小さいですが情熱的です。

そしてPlan 9が考えたすべてのコンセプトは、20年後にLinuxで再実装されました。

Plan 9が私たちに教えること

「優れたアイデアが必ず勝つわけではない — しかし盗まれる」

Plan 9は製品としては失敗しましたが、アイデアとしては勝利しました。

Kubernetes上で動くすべてのコンテナ...
ネットワークを通じて送信されるすべてのUTF-8バイト...
クラウド上で動作するすべてのGoルーチン...

これらすべてにPlan 9のDNAが含まれています。

出典: Bell Labs Technical Journal, Plan 9マニュアルページ, Rob Pike's personal blog (herpolhode.com), 9fans.net, Wikipedia