【Programmer Legends #03】Ken Thompson：Unixを生んだ“簡潔さ”の鬼、信頼を問い続けた思想家

1. “小さい核＋繋がる道具”という発明（Unix）

誕生の背景

1960年代後半、AT&T Bell Labs では大型分散システム Multics の開発に関わっていました。 しかし Multics は 巨大で複雑すぎる ことから、Bell Labs は 1969 年に撤退します。

その後、Ken Thompson は PDP-7 という小型マシンを手に入れ、 「もっと小さく、もっと簡単に動くシステムを自分で作ろう」と考えました。 これが Unix の原点です。

→ つまり、Unix は「巨艦 Multics へのアンチテーゼ」として生まれたんです。

Unix の基本構造

Unix は大きく分けて二つの要素で構成されました：

  1. 小さなカーネル（kernel）

    • メモリ管理、プロセス管理、ファイルシステムといった最低限の核機能だけを持たせる。
    • OS が“全部を抱える”のではなく、核は小さく保ち、拡張はユーザ空間の道具で行う。

  2. ユーティリティ群（tools）

    • ls, cat, grep, sort など小さなプログラムを多数用意。
    • それぞれは単機能だが、パイプ（|） を使って連携できる。

例：

cat logfile | grep ERROR | sort | uniq -c

たった数行の小道具を繋ぐだけで、専用プログラムを書かずに強力な処理ができる。

パイプと「テキスト文化」

Thompsonの思想を象徴するのが 「テキストで合成できるI/O」 です。

  • 標準入力（stdin）、標準出力（stdout）、標準エラー（stderr）をすべてファイルのように扱える
  • だから「出力を次の入力に繋ぐ」パイプが成立する
  • 複雑なシステムも小さいコマンドの合成で構築できる

→ これは今日の CLI設計の原則 にも直結しています。 （Docker, Kubernetes, Git など、すべて「小さいコマンドを組み合わせる思想」を継承）

Thompson流の設計原則（実装視点）

  • 機能は小さく独立させる → 例：sort はソートしかしない、uniq は重複を除くだけ。

  • テキストで合成できるI/Oを持つ → 例：テキストファイルを介せば、異なるプログラムが即座に連携できる。

  • 実装は簡潔に、拡張は外で → カーネルは最小限。新しい機能は後からユーザ空間に追加すればいい。

文化的インパクト

Unix の哲学は 「モジュール性」「合成性」「シンプルさ」 に尽きます。 この考え方が根付いたことで：

  • Linux, BSD, macOS, Android など Unix 系 OS が世界を席巻
  • ソフトウェアツールチェーンの発展（gcc, make, awk, sed…）
  • マイクロサービスアーキテクチャやUnixフィロソフィという開発文化へ直結

→ つまり Thompson の発明は OS を超えてソフトウェア工学全体の思想を変えた、といえます。

Turing Award 受賞（1983年）

Ken Thompson と Dennis Ritchie は、この Unix と C 言語の業績で 1983年 A.M. Turing Award を共同受賞しました。 受賞理由の一節はこうです：

「Unix オペレーティングシステムを通じて、コンピュータの概念を簡潔に表現し、 ソフトウェアの設計に新しい哲学をもたらした」

まとめ（第1節）

Ken Thompson が Unix で示したのは、 「核は小さく、道具は単機能、合成はパイプで」 というシンプルな原則。

これは半世紀を経た今でも、

  • CLI の設計
  • マイクロサービスの分割
  • DevOps の自動化パイプライン

など、現代の開発現場の基盤に息づいています。

2. B言語→Cへ：ミニマリズムが作った土壌

BCPLからBへ

1966年、Martin Richards が開発した BCPL (Basic Combined Programming Language) は、システムプログラミングのために設計された高水準言語でした。 Ken Thompson は Bell Labs で Unix の初期開発を進める中、BCPL を「もっと小さくしたい」と考えます。

→ そこで彼が作ったのが B言語（1969年頃）。名前の由来は「BCPLの頭文字を削った」「Bon（ベル研究所内の別プロジェクト）」など諸説あり。

B言語の特徴

  • 型なし：すべてのデータは「ワード単位」で扱う。整数もポインタも同じ扱い。
  • 簡潔さ重視：当時の小型マシン PDP-7 でも動作できるように、言語機能は最小限。
  • システム開発用：Unix カーネルやユーティリティの一部が B で書かれた。

イメージ：アセンブリよりちょっと高級、でも「型安全」とか「移植性」とは無縁。

C言語への橋渡し

Dennis Ritchie は、PDP-11 の普及や ASCII の広がりを背景に、「Bではもう足りない」と痛感します。 特に課題は：

  • 型が無いため、文字と整数を区別できない
  • PDP-11 のバイトアドレッシング（8bit単位）をうまく扱えない
  • 大規模化で抽象化の不足が露呈

そこで B を拡張し、型付き言語として進化させたのが C（1972年頃）。

Bの美徳と限界

  • 美徳：シンプルすぎるほどシンプル。コンパイラも軽量で、PDP-7 のような弱い環境で動かせた。
  • 限界：実務では「型のない言語」は厳しい。ポインタ操作も曖昧で、より強い抽象化が求められた。

結果、“足りないから足す” → BからCへ という段階的な進化が生まれました。

Thompson流の「段階的進化」

Ken Thompsonは「最初から完璧なものを作らない」人でした。

  • まずは「必要最低限で動くもの」を作る
  • そこから「必要に応じて進化させる」

これは後の Plan 9 や Go言語 にも通じるスタイル。 「欠けていること」すら進化のための土壌になるという発想は、まさに Thompson 流の実装哲学でした。

現代に引きつけると…

  • スタートアップのMVP開発：まずは最小限で出して、足りない部分をユーザーや環境の声で育てる。
  • プログラミング言語進化：JavaScript も最初は「おもちゃ言語」扱い → 今では巨大エコシステム。
  • lainさんのプロジェクト：IndexedDBやP2Pの実装も「まずは最低限」から育ててますよね。まさに「B→C」的プロセス。

まとめ（第2節）

  • B言語は 「型なしの最小言語」 として Unix を支えた。
  • その限界が C言語 の誕生を促し、現代まで続く巨大な系譜を生んだ。
  • Thompson流の哲学：まず小さく作り、足りなければ進化させる。

3. grepと正規表現：開発者の語彙を広げた道具

「grep」の誕生

1973年頃、Ken Thompson は Unix のエディタ ed に正規表現検索機能を実装していました。 ed には g/re/p というコマンドがあり、これは

  • g = global（全文検索）
  • re = regular expression（正規表現）
  • p = print（表示する）

を意味します。

→ このコマンドが独立してgrepというユーティリティになったのです。 つまり 「grep = g/re/p」。

正規表現の普及

Thompson は Unix に「正規表現エンジン」を持ち込みました。これは数理的には Kleene の形式言語理論を実装したものですが、Unix ユーザーにとっては 「テキストを柔軟に探せる魔法の構文」 になったのです。

例：

grep "ERROR.*timeout" logfile.txt

わずか数文字で「ERROR の後に timeout がある行」を抽出できる。 → これが当時のプログラマに与えたインパクトは計り知れません。

egrep, fgrep への発展

Thompson の grep をもとに、同僚の Alfred Aho らがさらに拡張しました：

  • egrep (extended grep)

    • 括弧 ()、パイプ |、プラス + などの拡張正規表現を導入。
    • より複雑なパターンが表現可能に。

  • fgrep (fast grep)

    • Aho–Corasick アルゴリズムを採用。
    • 正規表現ではなく固定文字列を高速検索。

これにより grep 系は「検索ツールの生態系」へと広がりました。

「検索は対話から構文へ」の転換

Unix以前、多くの検索は「対話的」でした。

  • 目で探す
  • エディタで「次を検索」する

それが Unix では、「構文（正規表現）」で記述 → 自動処理 → 組み合わせてパイプライン化 が可能になりました。

例：

cat access.log | grep "POST" | grep -E "200|201" | wc -l

→ 「POST で成功したリクエスト数」を一発で集計。

検索が“言葉”ではなく“言語”になった瞬間でした。

Thompsonの功績の意味

Ken Thompson の正規表現導入は、

  • プログラマの語彙を広げた（複雑な検索を数文字で表現可能に）
  • テキスト処理をプログラマブルにした（パイプで組み合わせ、スクリプトに組み込める）
  • 形式言語理論を日常ツールに落とし込んだ（抽象数学が実務の道具に）

現代への影響

  • プログラミング言語（Perl、JavaScript、Python…）は標準で正規表現を実装。
  • IDEやエディタはすべて「正規表現検索」をサポート。
  • ログ解析・セキュリティ・スクレイピングなど、grep 的発想が基盤。

→ 今日の DevOps、セキュリティ監視、AIデータ前処理まで、grep のDNA が染み込んでいます。

まとめ（第3節）

  • grep = g/re/p から生まれた 小さな道具。
  • 正規表現を Unix に持ち込んだことで、検索が“構文”に昇格。
  • Aho らが拡張し、生態系（egrep, fgrep）が育った。
  • プログラマの語彙を広げ、日常を変えたツール。

4. Plan 9：分散時代の“すべてはファイル”

背景

1980年代後半、Bell Labs の研究者たちは「Unixの成功で学んだものをさらに純化し、分散システムの時代に合わせよう」と動きました。 その中心人物が Ken Thompson, Rob Pike, Dennis Ritchie ら。 こうして生まれたのが Plan 9 from Bell Labs です。

名前の由来は Ed Wood の映画 Plan 9 from Outer Space からの引用（遊び心）。

Unix との違い

Unixの思想を「小さい核＋ファイル＋パイプ」でまとめた Thompson たちは、Plan 9 でその原則をさらに推し進めます。

  1. すべてはファイル（Everything is a file）を徹底

    • デバイス、GUI、ネットワーク、さらにはリモート資源まで、全部ファイルとして表現。

  2. 名前空間の私有化

    • Unix では「全員で共有する /etc や /dev」しかなかった。
    • Plan 9 では、ユーザーごとに独自の名前空間を持てる。
    • 例：あるユーザーは /net/ether0 をローカルNICに、別のユーザーはそれをリモートNICに割り当て可能。

  3. 9P プロトコル

    • 分散システムの通信は 9P というシンプルなファイル操作プロトコルで行う。
    • ファイルシステムの延長でリモート資源も扱える。

実装例

  • Rio ウィンドウシステム

    • X11 のような複雑さを避け、ウィンドウをファイルとして扱う。

  • /acme エディタ

    • Rob Pike が作った統合エディタ。マウス操作とテキスト指向を融合。

  • 分散計算

    • リモートマシンの資源を自分のファイルシステムにマウントして、透過的に利用。

なぜ普及しなかった？

  • 商業的サポートが弱い（Bell Labs の研究色が強すぎた）
  • 当時のPC/UNIX市場では Linux, BSD, Windows NT が実用性で勝った
  • “Unixとの互換性”を切り捨てた分、ユーザー獲得が難しかった

結果、Plan 9 は「研究用OS」のままに終わります。

それでも残ったもの

  • Linuxの/procファイルシステム → Plan 9 から強い影響
  • FUSE (Filesystem in Userspace) → どんなリソースも「ファイル」として扱う発想
  • コンテナやKubernetesの抽象化 → 名前空間の分離・統合という思想
  • Go言語開発チーム → Rob PikeやKen Thompsonが再び中心になり、Plan 9 の哲学が Go の簡潔さに受け継がれる

実務ヒント

Plan 9 の失敗は、商業的には「市場に早すぎた」ことですが、設計的には宝の山です。

  • 「ファイル＝API」モデル → REST/GraphQL前にすでに「すべてを統一インターフェイスで扱う」思想があった
  • 名前空間の私有化 → Kubernetes の Namespace、Linuxのcgroups につながる
  • 単純なプロトコル（9P） → 今日のマイクロサービス間通信でも学べる点あり

まとめ（第4節）

  • Plan 9 は「Unixを徹底的に純化した分散OS」だった
  • 名前空間の私有化、9Pプロトコル、すべてをファイルとして扱う思想が特徴
  • 普及はしなかったが、Linuxの/proc、FUSE、コンテナの基盤設計に思想が受け継がれている
  • **「すべてをファイルに見立てる」**発想は、現代のクラウドネイティブ設計を読み解くヒントになる

5. “信頼をどう証明するか” — Trusting Trust の衝撃

Turing Award 受賞講演（1984年）

1983年、Ken Thompson と Dennis Ritchie は Unix と C 言語の功績で A.M. Turing Award を受賞しました。 翌年の講演で Thompson が選んだテーマは、意外にも「UnixやCの技術的解説」ではなく、ソフトウェアにおける信頼とセキュリティの根源的な問題でした。

タイトルは 「Reflections on Trusting Trust」。 つまり「信頼を信じるとはどういうことか？」です。

問題提起：ソースコードは本当に信頼できるか？

Thompson はまずこう指摘しました：

「セキュリティを保証するには、ソースコードを精査すればよい、と人は考える。だが、それは幻想かもしれない。」

理由はシンプルです。 ソースをコンパイルする コンパイラ自体 に悪意のある仕掛けが入っていたら、いくらソースを見ても意味がないからです。

実験的なバックドアの例

Thompson が示したのは以下の二段構えのバックドアです：

  1. ログインプログラムにバックドアを注入するコードをコンパイラに仕込む → ある秘密のパスワードで誰でもログイン可能になる

  2. コンパイラ自身を改変するコードも同時に仕込む → ソースコードにはその痕跡を残さず、次に自分自身を再コンパイルしたときにもバックドアを温存

この結果、ソースコードは完全に無害に見えるのに、生成物には常にバックドアが入る──という恐るべき状況が成立します。

これがいわゆる “Trusting Trust Attack” です。

講演のラストメッセージ

Thompson はこう締めくくりました：

「ソフトウェアを信頼するとは、結局のところ、人を信頼することだ。」

つまり、技術的な完全保証は不可能であり、最終的には「そのコードを書いた人・ビルドした人を信じるしかない」という逆説的な結論です。

今日への示唆

この問題提起は、40年経った今でも解決困難な課題として残っています。 ただし現代ではいくつかのアプローチが広まっています：

  • 再現可能ビルド（Reproducible Builds） → ソースコードと同じバイナリを誰でも再現できるようにし、ビルド過程に「透明性」を与える。

  • TOFU（Trust On First Use）の明示化 → SSHや証明書交換で「最初の信頼」をどう担保するかを明示する。

  • 最小特権設計とコード署名 → ソフトウェア配布時に署名し、チェーン・オブ・トラストで検証。

  • 二重コンパイルアプローチ → 異なるコンパイラで同じソースをビルドし、差異を検証する。

なぜ「衝撃」だったのか

当時の聴衆は Unix や C の話を期待していたところに、いきなり「人を信じるしかない」という哲学的かつ不気味な問題提起をぶつけられました。 つまり Thompson は 「コンピュータ科学の頂点の場で、ソフトウェアの限界と人間の倫理を突きつけた」 のです。

まとめ（第5節）

  • 「Trusting Trust Attack」＝ コンパイラ自身に仕込まれたバックドアは、ソース精査では見抜けない
  • Thompson の結論：「技術の最後は人への信頼に帰着する」
  • 現代の対策は Reproducible Builds、署名、TOFU、二重コンパイルなど
  • 依然として「完全な保証」は存在せず、信頼の哲学が今も問われ続けている

6. “遊び”も規格外：チェス専用機 Belle

Belle 誕生の背景

1970年代後半、Ken Thompson は Bell Labs の同僚 Joe Condon とともに「チェス専用コンピュータ」の開発にのめり込みました。 目的は単純で、強いチェスを指す機械を作りたい。

Thompson は当時からチェス愛好家で、ソフトウェアだけでは限界があると見抜き、ハードウェアから設計することに挑戦しました。

Belle の特徴

  • 専用ハードウェア

    • 評価関数や合法手生成をハード化し、1秒あたり数百万局面の探索を可能にした。
    • CPUに頼らず、**「チェスを解く回路」**を直接設計。

  • 探索アルゴリズム

    • アルファベータ探索（効率的に木を刈り込む手法）を中心に実装。
    • Thompson はソフト面も改良し、ハードと組み合わせて性能を引き上げた。

世界的な快挙

  • 1980年：世界コンピュータチェス選手権で優勝。
  • 1983年：US Chess Federation によるレーティングで 2200超え（人間のマスター相当）を達成。 → これは当時、人間のトップアマと同等という驚異的な記録。

Belle の遺産

Belle の設計はその後のコンピュータチェス研究に大きな影響を与えました。

  • ChipTest（カーネギーメロン大学） → IBM Deep Thought → Deep Blue へと繋がる系譜に刺激を与えた。
  • 目的特化ハードウェアで機械学習を加速する、という発想は → 今日の GPU/TPU/AIアクセラレータ の先駆けといえる。

「遊び」が次の技術を拓く

Belle は一見「遊びの産物」でしたが、そこから見えてくるのは：

  • 特定分野に特化したハード設計は、汎用計算を超える力を持つ
  • 探索アルゴリズム＋専用ハードの組み合わせは、AI時代にも直結する考え方
  • Thompson の「遊び」は、研究コミュニティにとって 新しい可能性の実験場 になった

まとめ（第6節）

  • Belle は 世界初のマスター級コンピュータチェス機
  • Thompson は遊びの中で 専用ハード×探索アルゴリズムという発想を体現した
  • その成果は後の Deep Blue、さらには今日の GPU/TPU へと思想的に継承されている

7. Go：実用のための“少なさ”

Go誕生の背景

2006年頃、Google社内では巨大化するコードベースにC++やJavaを使うことへの不満が溜まっていました。

  • C++ → 強力だがビルドが遅い、複雑すぎる
  • Java → VM上で動き、速度やシステム連携で物足りない

そこで Rob Pike, Robert Griesemer, Ken Thompson が中心となり、 「システムプログラミングに耐える性能を持ちつつ、開発効率も高い言語」を目指して設計したのが Go です。

Goの設計思想

Goの根本は 「シンプルさ＝力」 という Unix 的発想。

  1. 少ない言語機能

    • 継承なし（クラス階層は持たない）
    • ジェネリクスも長らく導入しなかった（※2022年に追加）
    • 「多くを排除して読みやすさを最優先」

  2. 高速ビルド

    • 巨大なGoogleコードベースでも数秒でコンパイル。
    • これは Thompson が B や C でこだわった「コンパイラの軽さ」と通じる。

  3. CSP風の並行処理

    • Hoare の Communicating Sequential Processes (CSP) の思想を取り入れた。
    • go キーワードで軽量スレッド（goroutine）を起動し、channel で安全に通信。
    • → Unix の「プロセス＋パイプ」の並行処理を現代的に再設計。

Goに息づく「Unix流」

  • 簡潔さ×合成 → ひとつのgoroutineは小さい役割を持ち、channelを通じて組み合わせられる。これはUnixの「小さなプログラム＋パイプ」の再解釈。

  • 標準ライブラリの充実 → 外部ライブラリに頼らず、最小限の機能で多くの現場をカバー。Unixの「付属ツール群」に似ている。

  • 実務重視 → 理論的に美しい言語ではなく、Googleのエンジニアが毎日安心して使える実用言語に徹した。

現代への影響

  • Webサーバ／クラウド基盤：Docker, Kubernetes など、Go製プロジェクトがインフラの中心に。
  • 「読みやすさ最優先」の潮流：チーム開発において「個人の技巧より共通理解を優先」という文化を広めた。
  • 教育的価値：シンプルな文法と明確な並行処理モデルは、学習者に「プログラミングとは何か」を分かりやすく伝える。

Thompsonの晩年とGo

Ken ThompsonはGoogleに在籍し、Go言語の開発初期から深く関わりました。 彼の役割は「余計な複雑さを削る」こと。

  • 「これは本当に必要か？」
  • 「なくても動くなら捨てよう」

→ これは Unix の頃から一貫した Thompson 流。**「少なさは力」**という哲学が Go にも刻まれています。

まとめ（第7節）

  • Goは 「実用のための少なさ」 を徹底したシステム言語
  • 高速ビルド＋簡潔な文法＋CSP風並行処理 が柱
  • Unixの「小ささ」「合成可能性」が、Google規模の課題に応える形で再生された
  • Thompson晩年の到達点は、やはり 「シンプルさこそ力」 だった

8. 何を学び、どう活かすか（実務に効く要点）

Ken Thompson の仕事は「天才的発明」というより、**「簡潔さを貫く実践」**の積み重ねでした。UnixからGoまで一貫する哲学は、現代の私たちが日々の開発に直結させられる知恵です。

小さく作り、繋いで強くする

  • Unix の哲学：単機能プログラムをパイプで繋ぐ

  • 現代の応用：

    • マイクロサービス → 小さなAPIを組み合わせて巨大サービスを構築
    • CLIツールチェーン → grep | sort | uniq の発想が DevOps や ETL パイプラインに生きている

  • 教訓：大きなモノリスを避け、小さな部品の合成で柔軟に。

道具は“言語”である

  • Thompson が正規表現を Unix に持ち込んだことで、**検索が「言語化」**された

  • 現代でも：

    • SQL、正規表現、JSONPath、jq… → すべて「開発者の語彙を増やす道具」
    • チームで共通の道具を持てば、理解と協調が速くなる

  • 教訓：よく設計された道具はチームの共通言語になる。

信頼は工程で担保する

  • 「Trusting Trust」問題は、ソースコードだけでは不十分だと示した

  • 現代の実務：

    • 再現可能ビルド（Reproducible Builds）
    • サプライチェーン監査（SBOM, 署名, TOFU）
    • 二重コンパイル検証

  • 教訓：“信頼”は人・道具・手順の3層構造でしか保証できない。

実験を恐れない

  • Plan 9 は商業的に失敗したが、思想は /proc, FUSE, コンテナ に受け継がれた

  • 現代の実務：

    • OSSの新技術を「実験場」として使い倒す
    • 失敗した技術からもアイデアを回収する

  • 教訓：「無駄に見える実験」が未来の常識になる。

少なさは力

  • Go 言語は「機能を削ることでチームの生産性を最大化」した

  • 現代の実務：

    • フレームワーク選定で「多機能よりシンプル」を優先
    • 「学習コストの低さ」＝「開発速度と保守性の高さ」

  • 教訓：少ない機能で大きく動かす方が、長期的に強い。

総括

Ken Thompson の足跡は、

  • 小さい核（Unix）
  • 道具の言語化（grep）
  • 信頼の哲学（Trusting Trust）
  • 実験精神（Plan 9）
  • 少なさの美徳（Go）

として今日の開発文化に息づいています。 つまり私たちは日々 Thompson の影の上を歩いていると言っても過言ではありません。

参考リンク（一次資料・公的情報を優先）

  • Ken Thompson（概要・略歴）：Wikipedia / Britannica（基礎情報として）
  • Turing Award 講演：Reflections on Trusting Trust（PDF, ACM）
  • B言語とCの発展：B言語の項 / C発展史ノート
  • Plan 9：公式Overview / USENIX・CSAILの解説論文
  • Belle（チェス）：IEEE Spectrum / Chessprogramming Wiki（戦績・影響）
  • Go言語：公式サイト / Wikipedia（来歴・設計）