「UNIX哲学」という言葉は、よく引用されますが、どの文章を指すのかは、意外とあいまいです。この記事では、1978年のベル研究所の論文誌に載った序文の原文を開き、そこに書かれていた4つの格言と、序文自身が挙げた例を整理します。そのうえで、あとから「UNIX哲学」としてまとめられた文言との違いを示し、小さなプログラムを設計するときの問いにつなげます。
この記事の根拠と限界（2026年10月29日確認）
- 1978年の序文は、Internet Archive にある全文テキストを開き、原文で確認しました。日本語は、筆者による訳・要約です。
- 「3つの文」の由来は、Wikipedia「Unix philosophy」の記載を開いて確認しました。Salus の著書そのものは、開いていません。
- Raymond の17のルールは、著書の公式サイト（catb.org）の該当節を開いて確認しました。
- 最後の「設計への当てはめ方」は、筆者の提案です。序文や著書に書かれたものではありません。
- 運営者が、この考え方で実際に設計した記録は、この記事にはありません。
1978年の序文が述べた4つの格言
序文は、M. D. McIlroy、E. N. Pinson、B. A. Tague の3名による「UNIX Time-Sharing System: Foreword」で、Bell System Technical Journal の第57巻第6号（1978年7〜8月）に載りました。その中の「Style」の節で、UNIX の作り手と使い手の間で通用している格言として、次の4つが挙げられています（日本語は筆者の要約）。
| 格言（要約） | 序文が挙げた例（要約） |
|---|---|
| 1. 一つのことをうまくやるプログラムにする。新しい仕事には、古いプログラムに新機能を足して複雑にするのではなく、作り直す（原文：Make each program do one thing well.） | UNIX のコンパイラは、リストを出力しない（印刷は別のプログラムのほうが柔軟） |
| 2. あらゆるプログラムの出力が、まだ見ぬ別のプログラムの入力になると想定する。出力に余計な情報を混ぜない。厳密な桁揃えや、バイナリの入力形式を避ける。対話的な入力を求めない（原文：Expect the output of every program to become the input to another, as yet unknown, program.） | 同じ文章から、実行用のコンパイルも、本の原稿としての組版もできる。テキスト処理の道具が、並べ替えや数え上げなどにも使える |
| 3. ソフトウェアは、早い段階（理想的には数週間以内）で試せるように設計して作る。まずいところは、ためらわずに捨てて作り直す | UNIX と C 言語は、初期の動くモデルから段階的に進化し、設計者自身が何度も作り直した |
| 4. 未熟な人手より、道具を使って作業を軽くする。そのために回り道して道具を作ることになっても、使い終えたあとに、その一部は捨てることになると覚悟する | 組版：体裁の規則を1か所で変えれば、1語も打ち直さずに新しい体裁で出力できる |
序文は、続けて、「Small is beautiful」という格言と、Brooks が「The Mythical Man-Month」で述べた「small is unreal（小さいものは非現実的）」という主張に触れ、自分たちは「一部だけ同意する」としています。理由として、計算技術を適切に使えば、大きかった仕事を扱える大きさまで圧縮できること、最初のシステムが約5人年の作業量で、Bell System の業務に使われ始めたことを挙げています。
4つに共通すること（筆者の整理）
4つの格言には、「小さな部品に分ける」「部品の間は、テキストでつなぐ」「早く試して作り直す」「繰り返す作業は道具にする」という考え方が共通しているように読めます。これは、筆者の整理です。序文がそう要約しているわけではありません。
コマンドで確かめる例（格言1・2・4）
序文の格言を、標準のコマンドの組み合わせで確かめます。次の実行は、2026年10月29日に、macOS（Darwin 25.5.0）の標準コマンドで行ったものです。運営者の使用経験ではなく、この記事の確認作業です。入力は、上で確認した序文の、Internet Archive のプレーンテキストです。
export LC_ALL=C curl -sL -A "Mozilla/5.0" https://archive.org/download/bstj57-6-1899/bstj57-6-1899_djvu.txt -o foreword.txt tr -cs 'A-Za-z' '\n' < foreword.txt | tr 'A-Z' 'a-z' | sort | uniq -c | sort -rn | head -5
実行結果は、次のとおりでした（出現回数の多い単語の上位5つ）。
101 the 73 and 52 of 49 to 38 a
- どのコマンドも、一つのことしかしません。
trは文字の置き換え（1つ目は英字以外を改行にし、2つ目は小文字にする）、sortは並べ替え、uniq -cは連続する同じ行の数え上げ、headは先頭の表示です。（格言1） - 前のコマンドの出力（テキスト）が、そのまま、次のコマンドの入力になっています。（格言2）
- 「単語の出現回数を数える専用のプログラム」を作らず、既存の道具を組み合わせています。（格言4）
上位が the・and・of のような一般的な語になるのは、英文では自然な結果です。この例は、設計の考え方を確かめるためのもので、結果の分析が目的ではありません。コマンドの版、ロケール、テキストの版によって、結果は変わる可能性があります。
よく引用される「3つの文」は、1978年の序文の原文ではありません
「一つのことをうまくやるプログラムを書け。共同作業できるプログラムを書け。テキストストリームを扱うプログラムを書け。それが普遍的なインターフェースだからだ」という3つの文は、広く知られています。Wikipedia の記載によると、これは、1994年に Peter H. Salus が「UNIX哲学」という名前で要約したもので、McIlroy の考えに帰されています。上の4つの格言とは、文言が異なります。引用するときは、どちらの文章を指すのかを区別する必要があります。
後世の整理：Raymond の17のルール
Eric S. Raymond は、著書「The Art of Unix Programming」（Addison-Wesley、2003年。書誌情報は Wikipedia の参考文献欄の記載による）で、UNIX の設計の考え方を、17のルールとして整理しました。公式サイトの該当節には、次の17のルール名があります。
- Modularity（モジュール性）：単純な部品を、きれいなインターフェースでつなぐ
- Clarity（明確さ）：巧妙さより、明確さが優れている
- Composition（組み合わせ）：ほかのプログラムとつながるように設計する
- Simplicity（単純性）：単純さを目指し、複雑さは必要なところだけに足す
- ほかに、Separation、Parsimony、Transparency、Robustness、Representation、Least Surprise、Silence、Repair、Economy、Generation、Optimization、Diversity、Extensibility があります。
上の4つは、公式サイトの原文の要旨で、日本語は筆者の訳です。残りのルールの内容は、この記事では扱っていません。1978年の序文とは、書かれた時期も書き手も異なる整理です。
小さな設計に当てはめるための問い（筆者の提案）
ここからは、筆者の提案です。序文の4つの格言を、スクリプトや小さなアプリを作るときの問いに置き換えました。効果の大きさは、題材や人によって異なります。
- このプログラムが「一つのこと」として何をするのか、一文で言えるか。（格言1）
- 出力は、ほかのプログラムが読み取れる形か。余計な情報を混ぜていないか。（格言2）
- 早い段階で動かして試せる形か。うまくいかない部分を、作り直せる余地を残しているか。（格言3）
- 繰り返している作業を、道具にできないか。（格言4）
更新履歴
2026年10月29日：全面的に改訂しました。1978年の序文の原文を開いて、4つの格言と序文が挙げた例を整理し、標準コマンドで確かめる例を追加しました。根拠のなかった実践ロードマップと、日数・時間の目安を削除しました。題名を内容に合わせて変更しました。
参考文献・出典（2026年10月29日確認）
- M. D. McIlroy, E. N. Pinson, B. A. Tague, “Unix Time-Sharing System: Foreword,” Bell System Technical Journal, Vol. 57, No. 6, 1978：全文テキスト（Internet Archive）
- Eric S. Raymond, “The Art of Unix Programming,” Addison-Wesley, 2003：公式サイトの該当節（Basics of the Unix Philosophy）
- Peter H. Salus, “A Quarter Century of UNIX,” Addison-Wesley, 1994：Wikipedia「Unix philosophy」の記載による（原著は未確認）。Wikipedia
あわせて読みたい記事
小さな単位で読む・設計するという点で、次の2本とつながります。
- コードリーディングの基本技法：トップダウンとボトムアップ、kiloを題材にした5日間の練習計画（小さなプログラムを読む）
- Web API設計の基本5ステップ：要件・命名・文書化・テスト・運用（インターフェースの設計）
プログラミングを学びたい方へ
公式サイトの情報をもとに、プログラミングスクール5校の料金や転職サポートの条件を比較しています。
無料カウンセリングのあるスクールも紹介しています。
この記事の内容について質問はありますか？
