UNIXという考え方 — Gancarz が 9 つの定理に圧縮した道具の哲学

「UNIX という考え方」と聞いて思い浮かべるものは、人によって大きく違うのではないでしょうか。シェルでパイプを繋ぐ流儀、grep と sort の組合せの妙、テキストファイル中心の設計、あるいはオープンソース文化の精神的下地 ── それぞれが間違いではないものの、断片的だといえるでしょう。Mike Gancarz (Digital Equipment Corporation の元エンジニア、X Window System の設計者の一人) が 1994 年に The UNIX Philosophy を発表したのは、これらの断片を 9 つの主要定理 + 10 のマイナー定理 に圧縮し、UNIX を支えた設計態度を一つの教義としてまとめ直すという企てだったといえるでしょう¹。本書は 2001 年にオーム社から邦訳が出版されています²。

特定のコマンドの解説書ではなく、道具に対する態度の本 ── というのが本書の独自の位置です。1994 年刊行から 30 年を超えてなお読み継がれているのは、UNIX という具体的なシステムを離れても、原則が知的生産の設計判断に転用可能だからだと整理することができるでしょう。

9 つの主要定理

著者が冒頭に置く 9 つの主要定理は、次のように整理されます¹。

これらは独立した教訓のリストではなく、互いを支え合う一つの設計態度の異なる側面だと読むことができるでしょう。たとえば「小ささ」(#1) は「単一責務」(#2) の自然な帰結であり、「フィルタとして設計」(#9) はそれをデータの流れの中に置く宣言です。「テキストファイル」(#5) は層と層の境界を可視化する選択であり、「シェルスクリプト」(#7) はその境界を組合せて新しい機能を立ち上げる手段です。

小さく作り、組合せる ── UNIX 哲学は、ひとつの構えの 9 つの側面である。

中心 ── 単一責務とパイプ

著者の議論で最も歴史的重みを持つのが、定理 #2 「一つのプログラムには一つのことをうまくやらせる」でしょう。これは Bell 研究所の Doug McIlroy が 1978 年に Bell System Technical Journal で示した命題の継承です⁴。

Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features.”⁴

McIlroy が組合せの哲学として提示したものを、著者は 設計判断の現場での問いかけ に翻訳しています。新機能を追加したくなったとき、それを別ツールとして独立させたら何が困るか ── 困らないなら独立させよ、というのが著者の言い換えだと整理できるでしょう。

この命題は、本サイトでも複数の角度から扱っています。ツールとオーケストレーターを分けるでは、年単位で蓄積する個人用ソフトウェア・エコシステムの設計判断として、単一責務のツール層と、それらを組合せるオーケストレーター層の二層分離を論じています。一行で言える責務を持つツールを増やし、両層の境界を標準形式 (SRT、PDF、JSON 等) で引く ── これは著者の定理 #2 + #5 + #9 を、現代の個人開発のスケールに合わせて実装したものだといえるでしょう。

「てこ」── 書かない設計の源流

定理 #6 「ソフトウェアの『てこ』を使う」は、おそらく 9 定理のなかで最も射程の広い命題でしょう。著者は、既存の優秀なコードを てこ (leverage) として活用することが、個人プログラマの生産性を桁違いに引き上げると論じています¹。

この発想は、5 年後の 1999 年に Eric S. Raymond が The Cathedral and the Bazaar で打ち出すことになる命題と直接接続します。

Good programmers know what to write. Great programmers know what to rewrite (and reuse)⁵。

著者の「てこ」と Raymond の「再利用」は、別の言葉で同じ態度を語ったものだと読むことができるでしょう。本サイトの 書かない設計 ── 偉大なプログラマは優秀なプログラマのコードを利用するでは、この系譜を McIlroy (1978) → Gancarz (1994) → Raymond (1999) → Kernighan & Pike (1999) → Git の陶器と配管 (2005) として整理しています。書かない設計の倫理 ── 借りる側が借りていることを意識し、書く側は再利用される前提で書く ── が、個人プログラマの効率の話に留まらず、オープンソースの生態系全体を支える対称的な責任の構造であることを示しています。

標準形式と「腐らない」設計

定理 #4 「効率より移植性を選ぶ」と定理 #5 「データはフラットなテキストファイルに保存する」は、現代の言葉でいえば 時間に対する設計 だと言い換えることができるでしょう。著者は、ある時点で最適化された二進形式は移植性を犠牲にし、結果として長期的な再利用可能性を毀損すると論じています¹。フラットなテキストファイルは効率では劣るが、人間が読め、他のプログラムが読め、未知のツールでも処理できる ── これが本質的価値だ、という主張です。

これは本サイトの 腐らない資産を設計する ── 1995 年の TeX ソースが 2026 年にもコンパイルできる理由の議論と完全に重なります。TeX、PostScript、Make、SRT、PDF/A ── いずれも公開仕様 + 複数実装 + プレーンテキスト寄りという条件を満たしている形式が、30 年級の耐久性を獲得してきました。これらの形式の長期生存は偶然ではなく、著者の定理 #4 + #5 を真摯に実装した結果だと整理することができるでしょう。

フィルタとパイプ ── データの流れの哲学

定理 #9 「すべてのプログラムをフィルタとして設計する」は、UNIX のパイプ機構そのものを設計原則として一般化したものです。プログラムは状態を抱えるシステムではなく、入力ストリームを出力ストリームに変換する関数 として扱われるべきだ、という宣言だと読むことができるでしょう。

この発想は、現代の関数型プログラミングの「純粋関数の組合せ」、データエンジニアリングの ETL パイプライン、機械学習のデータローダ → モデル → 後処理という流れにそのまま接続します。著者は 1994 年の時点で、これらの 21 世紀のデータ中心設計のすべてを支える原則を、UNIX の経験から抽出していたと整理できるでしょう。

「フィルタとしての設計」は単一責務 (#2) と組合せの自由 (#7) の橋渡し役でもあります。各ツールがフィルタなら、それらは Make や シェルパイプで自由に連結でき、データ形式 (#5) を境界として置き換え可能になる。9 定理の相互依存性は、ここに最もきれいに現れているといえるでしょう。

試作と漸進 ── 「Worse is better」へ

定理 #3 「できるだけ早く試作を作る」は、当時のソフトウェア工学の本流 (要件定義 → 設計 → 実装の滝モデル) に対する明確な反対表明でした。完璧な計画から始めるのではなく、動く粗雑な試作を早く作り、使いながら磨く ── これが UNIX 文化の実践だ、というのが著者の整理です¹。

著者はこの議論を、Richard Gabriel が 1991 年に提唱した「Worse is better」と接続させています⁶。完璧な MIT 流の設計より、不完全だが移植性と単純性を持つ New Jersey 流 (UNIX) の設計のほうが、結果として広く生き残った ── この経験則は、漸進的な試作・反復の文化的根拠でもあります。

本サイトの 記録を標準化するで扱った会議録パイプラインも、この発想で組み立てられています。最初から完璧な統合システムを目指さず、Whisper + Claude + LuaTeX という既存の優秀な部品を SRT という境界形式で繋いだ薄い試作から始め、使いながら層を整えていく ── これが著者のいう「99% の解を探せ」(マイナー定理 #8) の現代的実装だといえるでしょう。

拘束的 UI を避ける ── オーケストレーション可能性

定理 #8 「拘束的なユーザインターフェイスを避ける」は、見落とされがちですが、現代の設計判断に直接効く命題です。著者の意味するところは、対話的な GUI を一切作るな、ということではありません ── GUI の背後に必ず CLI/API レイヤを置き、自動化と組合せに開いておけ ということです¹。

GUI に閉じたツールは、それ単体では便利でも、他のツールと組合せられず、スクリプトから呼べず、結果として 再利用の可能性を失う。一方、CLI/API を提供するツールは、人間が直接叩くことも、Make や Python から呼ぶことも、別の GUI に被せることもできる。後者のほうが、長期的にはエコシステムへの貢献度が桁違いに高い ── というのが著者の論点でした。

この主張は AI 時代に新しい意味を獲得しています。LLM がエージェントとして他ツールを呼ぶ世界では、CLI/API を持たないツールは LLM から触れない ── つまり、自動化と組合せの場から排除されます。30 年前の著者の警告は、生成 AI を含めたオーケストレーションの基盤としての CLI/API の重要性を、先取りしていたといえるでしょう。

マイナー定理 ── 周辺の倫理

著者は 9 つの主要定理に加え、10 のマイナー定理を提示しています。代表的なものを挙げると¹:

• ユーザに環境設定の自由を与える ── ドットファイル文化、設定の外出し
• 沈黙は金 (Silence is golden) ── ツールは成功時は何も出力しない、必要なときだけ語れ
• 部分の総和は全体より大きい ── 単一責務ツールの組合せは、巨大な統合システムの個別機能を凌ぐ
• 99% の解を探せ ── 完全主義より実用主義
• Worse is better ── 不完全で移植性のある解は、完全だが特殊な解に勝つ
• 階層的に考える ── ファイルシステム、プロセス、ネットワーク ── あらゆる構造に階層を見出す

これらが主要定理の倫理的・文化的下地として機能しています。「沈黙は金」 ── これは Make や zsh で複雑なパイプラインを書いたことのある人なら、その実用的価値を実感しているはずでしょう。エラー時だけ語るツールは、組合せたときに認知負荷を桁違いに下げます。

著者の独自性

UNIX に関する書籍は無数にあるなかで、本書を独立した位置に置く特徴を三つ挙げるとすれば、次のようになるでしょう。

第一に、態度の一般化。UNIX という具体的なシステムを離れても通用する形に、設計原則を抽出している。Windows や macOS、組込みシステム、果ては LLM の道具立てに至るまで、9 定理の射程は驚くほど広い ── これは原則を 特定の実装から切り離して 提示した著者の編集判断によるものだといえるでしょう。

第二に、人間中心の語り口。本書は技術書というより 設計者のための態度の本 として書かれています。コードはほとんど登場せず、代わりに「なぜそう設計するか」「他の選択肢と比べてどこが違うか」「何を妥協するか」が繰り返し論じられます。これが読者層の広さ ── プログラマだけでなく、システム管理者、技術書編集者、IT 投資判断を行う経営層 ── に貢献しているのでしょう。

第三に、定理という形式。Hippokrates 流の医学箴言や Wittgenstein の『論考』を想起させる、番号付きの定理形式は、原則を 議論の対象として固定する 効果を持ちます。読者は「定理 #6 はどこまで一般化可能か」「定理 #4 と #3 が衝突する場面はあるか」と、原則そのものを点検する位置に置かれる ── これは本書を、読み返すたびに違う側面が立ち上がる対話的なテキストにしているといえるでしょう。

批判と限界

本書への批判は主に二つの方向から提起されてきました。

論点 1: 9 定理の経験的妥当性 ── 著者は UNIX の歴史的経験から原則を抽出したと主張するが、実際には UNIX が「そうあるべきだった」という規範的な再構成も混じっており、歴史的事実としての UNIX 開発過程と一致しない部分がある、という批判です⁸。「Worse is better」の解釈にも論争があり、Gabriel 自身が後に立場を揺り動かした経緯もあります⁷。

論点 2: 現代のソフトウェア開発との距離 ── 9 定理は単独プロセス、ファイルシステム、ローカルでの組合せを暗黙の前提にしており、現代の分散システム、マイクロサービス、コンテナ・オーケストレーション、クラウドネイティブ開発との接続が弱い、という指摘です。著者の続編 Linux and the Unix Philosophy (2003) でも、この方向への拡張は限定的にしか行われていません³。

これらの批判は妥当ですが、本書の射程を絞ることはあっても、原則そのものの価値を毀損するものではないでしょう。むしろ「9 定理がそのまま通用しない現代の問題」を識別する道具として、本書は今も有効に機能しているといえるでしょう。

AI 時代の再評価

本書の射程が最も鮮明になるのは、生成 AI と LLM が「書く側」として参入してきた 2020 年代の局面においてだと整理することができるでしょう。

LLM の役割を「フィルタ」(定理 #9) として捉え、CLI/API (定理 #8) 経由で他ツールと接続し、テキスト形式 (定理 #5) を境界として持つ ── この組合せが、現代の AI 道具立ての標準パターンになりつつあります。本サイトの ツールとオーケストレーターを分けるで扱った設計判断は、まさに「LLM を含む現代の道具立てに 9 定理をどう適用するか」の実装例だといえるでしょう。

LLM 時代の新しい問いは二つあります。

問い 1: 「書く側」が LLM になったとき、著者の「てこ」(定理 #6) の倫理はどう更新されるか ── 借りているコードが他者の労働の蓄積ではなく、確率的に生成された出力であるとき、貢献の返し方は変わるのか。

問い 2: LLM 自身が単一責務 (定理 #2) を満たすツールではなく、汎用的な何でも屋である事実は、9 定理にどう吸収されるか ── LLM を「無責務な万能ツール」ではなく、「文脈で責務を限定したフィルタ」として使う設計判断が、9 定理の現代的更新を要求している。

著者はこれらの問いに直接答える本ではありません。けれども、問いを立てるための語彙 ── 単一責務、てこ、フィルタ、移植性、テキスト形式 ── を 9 つの定理として手渡してくれる一冊だといえるでしょう。

結語

『UNIX という考え方』は、UNIX システムの解説書ではなく、道具に対する態度の本 です。9 つの定理は、特定のコマンドや言語を覚えるための知識ではなく、新しい道具を設計する/選定する/組合せる際の判断の枠組みを提供しています。

この枠組みの強さは、抽象レベルの自由さ にあるといえるでしょう。シェルスクリプトの設計から、個人用ソフトウェア・エコシステムの設計、企業の IT インフラの設計、LLM を含む知的生産ワークフローの設計まで、9 定理は同じ言葉で語れる ── これは原則を実装から切り離した著者の編集の勝利だと位置づけられます。

本書を一度読み終えても、UNIX を使いこなせるようにはなりません。けれども、自分が日々使っている道具を 9 定理の物差しで点検し直す視角 が手に入ります。GUI に閉じすぎていないか、移植性を効率と引き換えに失っていないか、書かなくてよいコードを書いていないか、再利用を妨げる方向に進化させていないか ── これらの問いを抱え続けることが、著者の言う「UNIX という考え方」を継承することなのだと読むことができるでしょう。

UNIX という考え方は、道具に対する態度の名前である。

ここから少し、本書を本サイトの全体構図に置き直してみたいと思います。

本サイトの基礎記事 決定論的にではなく、相対的に では、道具を「目的と作業のあいだに立つ媒介物」── 何が見えるか・何ができるか・何が考えやすいかを規定する装置 ── として位置づけました。著者の 9 定理は、この 媒介性 の操作的な実装ガイドだと読むことができるでしょう。

• 単一責務 (#2) は、媒介の範囲を意図的に絞り、規定される「思考の形」を予測可能にする
• てこ (#6) は、媒介を他者の優秀な実装に委ねる選択を肯定する
• テキストファイル (#5) は、媒介の境界を可視化し、置換可能にする
• 拘束的 UI を避ける (#8) は、媒介を組合せの場に開いたまま保つ
• 試作と漸進 (#3) は、媒介を固定せず、使いながら更新する態度を支える

UNIX という具体的なシステムは時代と共に変わっていきますが、媒介としての道具にどう向き合うかという態度は、システムを超えて継承される ── 本書が 30 年読み継がれている理由は、おそらくここにあるのでしょう。9 定理は、UNIX のための原則というより、道具と共に考える人間 のための原則だといえるでしょう。

参考文献