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 のための原則というより、道具と共に考える人間 のための原則です。

参考文献