1. 【3.64．UNIX哲学⑨『フィルタ化』②】
「すべてのデータは人間によって生成される」という前提が示す、ソフトウェアの本質は何か？
解説： ソフトウェアは「データを受け取り、加工し、次へ渡す」フィルタであるという前提に基づき、UNIXではこの構造を重視する。
AI時代こそミニマリズム、UNIX哲学をクイズで学ぶ！
第3章：思想｜UNIX哲学
公開日：
最終更新日：
AI時代に複雑さを削ぎ落とすなら、合言葉は「1つのことをうまくやる」です。本ページでは、『プリンシプル オブ プログラミング』第3章「UNIX哲学」で取り上げられる9つの哲学と10の小定理を、要点を押さえた要約と4択クイズで整理します。
要約で目指す設計の姿をつかみ → 4択クイズ（10問・全問解説付き）で腕試し → 迷ったところは解説で復習。「読む→解く→わかる」で、AIが出力するコードを“ミニマルに整える”ための考え方の軸を身につけましょう。
3-6：AI時代のミニマリズム、UNIX哲学クイズ！ 目次
-
3-6：AI時代のミニマリズム、UNIX哲学クイズ！の要点・要約を読む(5分)
- 3.55 UNIX哲学（UNIX Philosophy）
- 3.56 小は美なり（Small is beautiful）
- 3.57 １つ１仕事（Make each program do one thing well）
- 3.58 即興プロトタイプ（Build a prototype as soon as possible）
- 3.59 効率性より移植性（Choose portability over efficiency）
- 3.60 データはテキスト（Store numerical data in flat ASCII files）
- 3.61 レバレッジ・ソフトウェア（Use software leverage to your advantage）
- 3.62 シェルスクリプト活用（Use shell scripts to increase leverage and portability）
- 3.63 対話インターフェース回避（Avoid captive user interfaces）
- 3.64 フィルタ化（Make every program a filter）
- UNIX哲学：小定理（UNIX little theorem）
- クイズに挑戦する(10問)
- プログラミング クイズ一覧へ
- 第3章：思想とセオリーの全体像をつかむ！ 目次へ
- 次のクイズへ(第4章：AI駆動で迷わない設計の「視点」クイズ！)
- 前のクイズへ(3-5：AI×普遍の知恵、UNIX思想クイズ！)
- 『プリンシプル オブ プログラミング』101の原理・原則総まとめ
第３章：思想⑥
～UNIX哲学～
3.55 UNIX哲学（UNIX Philosophy）
要旨
UNIX哲学は、OS「UNIX」を作る中で育ってきた「どう設計し、どう作るか」の考え方セット。
小さく作る・一仕事に集中する・早く試す・移植性（別環境に移しやすい性質）・テキスト志向・組み合わせ活用などをまとめたもの。理由
この考え方を軸にしてきたからこそ、UNIX系のソフトウェアは何十年も第一線で動き続けている。
考え方そのものが普遍的（時代をこえて通用する）で、Webサービスやクラウドなど今の開発にもそのまま使えるから。結論
ここから出てくるそれぞれの原則を、日々の設計・コーディング・運用のチェックリストとして使う。
判断に迷ったときの「よりどころ」として、UNIX哲学に立ち返る。その他（範囲）
設計（どう作るか）／実装（どう書くか）／運用（どう動かすか）の全部で、意思決定の軸として活用する。
3.56 UNIX哲学①小は美なり（Small is beautiful）
要旨
ソフトウェアは小さく・シンプルに作るほど価値が高くなる、という考え方。
やることを絞り、コード量や機能をむやみに膨らませない。理由
小さいプログラムは、理解しやすく、直しやすく、軽く（CPUやメモリの負荷が小さく）、他と組み合わせやすい。
逆に巨大なプログラムは、理解もデバッグも難しくなり、想定外の入力や障害に弱くなる。結論
小さく始めて、小さいまま保つことを基本にする。
機能追加は「本当に必要か？」を確かめてから慎重に行い、Less is more（より少ないことは、より豊かなこと）を合言葉にする。その他（効果・具体）
- 小さいコードは、読みやすく理解しやすい → レビューや学習が楽になる
- 修正範囲も小さくなり、バグの影響範囲も限定しやすい
- 軽いので、古いマシンや小さな環境でも動かしやすい
- いくつかの小さなツールを組み合わせることで、柔軟に新しい機能を作れる
💡AIワンポイント
小は美なりの観点で、AIへの依頼も小さい単位に分けます。1回で巨大差分を作るより、目的別に分割した方が品質確認が安定します。
3.57 UNIX哲学②１つ１仕事（Make each program do one thing well）
要旨
1つのプログラム（関数／モジュール）は1つの役割だけを、きちんとやるようにする原則。
あれもこれも詰め込まず、「この子はこれを担当」とはっきり決める。理由
役割を絞ると、不要なものを削りやすくなり、本質（何をしたいのか）が見えやすくなる。
結果として理解しやすく、テストしやすく、再利用しやすい部品になる。結論
「取得」と「整形」など、関心ごとが違う処理は必ず分ける。
コードのレベルでは、1文1処理（1つの文に1つの動作）を基本にし、長い複合文に詰め込まない。その他（例・注意）
- 例：ディレクトリ一覧
- ①ファイル情報を取得する処理
- ②人間向けに一覧を整形して表示する処理
- 1つの関数があれもこれも抱え込むと、スパゲッティコード（絡まったコード）になりやすい
- 関数名・引数・コメントが「この関数は1つの仕事に集中しているか？」のチェックポイントになる
- 例：ディレクトリ一覧
💡AIワンポイント
1つ1仕事を守るには、AI生成関数が複数の副作用を持っていないかを確認します。保存と通知を分けるだけでテストが簡単になります。
3.58 UNIX哲学③即興プロトタイプ（Build a prototype as soon as possible）
要旨
できるだけ早くプロトタイプ（動く試作品）を作り、手を動かしながら考える原則。
頭の中だけで考えず、早く形にして試す。理由
メカニズム（どう動くかの仕組み）はわりと安定するが、ポリシー（どう使うかの方針）は変わりやすい。
早く画面や動きが見えると、「そもそもの前提が違う」「欲しいのはこの機能じゃない」といったズレに早く気づける。結論
早期プロトタイプ → 短いサイクルで改善 → 段階的リリースという流れで最適な形に近づけていく。
最初から完璧を狙わず、「まず動くもの」「使ってもらってフィードバックをもらうもの」を目指す。その他（効果・段階）
- 前提や要件の勘違いに早く気づける → 後の手戻り（やり直し）を減らせる
- 初期の段階から実際の動きで確認できるので、欠陥や使いにくさを早めに発見できる
- 典型的な変化の流れ
- ① 高性能だけど機能不足の段階（まず動かす）
- ② 機能を盛りすぎて性能が落ちる段階（欲張りすぎ）
- ③ 不要なものを削って、必要十分な機能と性能のバランスが取れた段階
💡AIワンポイント
即興プロトタイプでは、AIに骨格実装を先に作らせて早期に実環境へ当てます。正解を考え切るより、差分観測を早く始める方が得です。
3.59 UNIX哲学④効率性より移植性（Choose portability over efficiency）
要旨
「効率（速さ）」と「移植性（別の環境に持っていきやすさ）」がぶつかったら、移植性を優先するという考え方。理由
ある環境だけでしか動かない高速コードより、いろいろな環境で長く動かせるコードのほうが、トータルで見ると価値が高い。
移植コストが低いと、新しい環境やCPUに対応する余裕ができ、その分新機能や品質改善に時間を回せるから。結論
ハードウェア依存の部分はきちんと切り出し、その他の大部分は環境に依存しない形で書く。
抽象化（共通化して隠すこと）や層分離（レイヤー分け）を使い、移植しやすいアーキテクチャを選ぶ。その他（実践）
- OS／CPU依存の処理は専用モジュールにまとめ、インターフェース越しに呼び出す
- 標準ライブラリや標準規格（POSIXなど）を優先し、ベンダー独自機能にロックインされないようにする
- 「この最適化は、この環境だけの裏技になっていないか？」を常に自問する
💡AIワンポイント
移植性優先なら、AI提案の環境依存コードを境界に隔離します。OS依存パスやシェル差異を一箇所へ閉じると将来移行が軽くなります。
3.60 UNIX哲学⑤データはテキスト（Store numerical data in flat ASCII files）
要旨
データの保存ややりとりには、テキスト形式（人が読める文字データ）を基本にする、という原則。
昔はASCII（文字コードの一種）の素朴なテキスト、今ならJSONやCSVなどがこれにあたる。理由
テキストは最もポータブルで、多くのツールからすぐ扱える。
人が目で見て確認しやすく、ログやデバッグでも強い。バイナリ専用形式だけに閉じると、ツールも人間も扱いづらくなる。結論
独自バイナリ形式は「どうしても必要なところ」に限り、基本は標準的なテキスト形式を採用する。
テキストI/O（テキストの入出力）を前提に、パイプ連携や他ツールとの組み合わせを設計に織り込む。その他（補足）
- 構造化データはJSONやYAMLなど、広く使われているテキスト形式を選ぶ
- 表のようなデータはCSV/TSVで扱い、既存ツール（表計算・スクリプト）をフル活用する
- テキストで持つことで、差分ツール（diff）やバージョン管理（Git）とも相性が良くなる
💡AIワンポイント
データはテキストの原則に沿って、AI出力フォーマットは可読な標準形式を選びます。独自バイナリ化は相互運用の障壁になります。
3.61 UNIX哲学⑥レバレッジ・ソフトウェア（Use software leverage to your advantage）
要旨
レバレッジ（てこの原理）のように、すでにある良いソフトウェアを組み合わせて使い、少ない労力で大きな成果を出す、という考え方。理由
「良いプログラマは良いコードを書く。偉大なプログラマは良いコードを借りてくる」という言葉があるように、再利用は開発スピードと品質の両方を上げる。
一から全部書くより、信頼できる部品を組み合わせたほうが、バグも少なくなる。結論
巨大な一体型システムを作るより、単機能のツールとグルー言語（つなぎ役のスクリプトやシェル）で構成し、全体として大きな仕事をさせる。その他（実践）
- 既存ライブラリやCLIツールを調査し、「車輪の再発明」を避ける
- 小さなコマンドをパイプやスクリプトで連結し、大きな処理フローを組み立てる
- 内製コードは、自分たちの強みやドメイン知識が生きる「核」の部分に集中させる
💡AIワンポイント
レバレッジでは、AIに既存ライブラリ利用前提で案を出させます。自作は中核価値に絞ると、保守対象が増えすぎません。
3.62 UNIX哲学⑦シェルスクリプト活用（Use shell scripts to increase leverage and portability）
要旨
シェルスクリプト（コマンドを並べて書く小さなプログラム）を「グルー言語（つなぎ役の言語）」として使い、既存コマンドの力を引き出す原則。理由
UNIXには多くのコマンドがあり、それぞれが単機能のツールとしてよくできている。
シェルスクリプトはそれらをパイプでつなぎ、自動化し、まとめて動かすための道具。多くの環境で動くので、移植性も高い。結論
小さなソフトをパイプで連結し、シェルスクリプトから編成・自動化して、大きな仕事をこなすスタイルを基本にする。その他（実践ヒント）
- 標準入力・標準出力・標準エラー、終了コード（0=成功／0以外=失敗）を正しく使い、連結しやすくする
- POSIX準拠のシェルやコマンドを意識して書き、できるだけ多くの環境で動くようにする
- 対話的な質問に頼らず、設定ファイルや引数で動作を切り替えられるようにする
💡AIワンポイント
シェル活用では、AI生成スクリプトの終了コードと標準エラー運用を必ず確認します。自動化の信頼性はここで決まります。
3.63 UNIX哲学⑧対話インターフェース回避（Avoid captive user interfaces）
要旨
クリックや入力を何度も要求するような「対話専用UIだけ」のソフトは避け、スクリプトからも使えるインターフェースを優先する原則。理由
対話だけに頼ると、毎回操作方法を覚え直す必要があり、自動化もしづらい。
入力待ちで時間を失いやすく、処理内容も他のソフトから見えにくくなる。結果として、「小は美なり」や「レバレッジ」の考え方にも反する。結論
基本は非対話型（CLI（Command Line Interface）／設定ファイル／ファイルI/O）で動かせるようにし、必要なら初心者向けにGUIや対話UIを「追加で用意する」形にする。その他（問題点の内訳）
- アプリごとに独自UIを覚える必要があり、学習コストが高くなる
- ボタン操作前提だと、ソフト同士が直接「会話（連携）」しづらい
- 人の入力待ち時間が増えて、夜間バッチなどの自動処理にも向かない
- あいまいな入力を解析するコードが巨大になり、かえって中身が複雑になる
💡AIワンポイント
対話UI回避の観点で、AI提案ツールは非対話モードを先に実装します。CIで動かせない機能は運用に乗りません。
3.64 UNIX哲学⑨フィルタ化（Make every program a filter）
要旨
すべてのプログラムを、「データを受け取って加工し、またデータとして返す」フィルタとして設計する原則。
フィルタ＝流れてきたデータを変換する部品、というイメージ。理由
人やシステムが扱うデータ処理の本質は「変換」。
フィルタとして設計しておくと、組み合わせやすく、再利用しやすく、テストもしやすい部品になる。結論
標準入力 → 処理 → 標準出力（＋エラーは標準エラー）という流れを基本に設計する。
ファイルや他のプログラムとつなぎやすい「直列パイプライン」を意識する。その他（設計要点）
- テキスト（例：JSONやCSV）を基本形式にしておくと、他ツールと連結しやすい
- 内部状態をできるだけ少なくし、副作用（思わぬ場所を書き換えること）を避ける → チェーン（連結）に強くなる
- 終了コードとエラーメッセージで、成功／失敗や原因をはっきり伝える
💡AIワンポイント
フィルタ化を徹底するなら、AIに入力一件ごとの独立処理を作らせます。副作用を局所化でき、並列化や再実行が容易になります。
UNIX哲学小定理（UNIX little theorem）
要旨
UNIX哲学を細かい場面で使いやすくするための、小さな指針セット。
日々の「ちょっとした選択」の積み重ねが、移植性・生産性・保守性の差になっていく。理由
大きな設計方針だけでなく、命名・ログ・並列処理などの細部も、長い目で見ると大きな影響を持つから。結論
以下の10項目を、重くなりすぎないチーム共通ルールとしてゆるく適用し、UNIX的な実用主義を徹底する。その他（小定理一覧）
①環境カスタマイズ
ユーザーが自分の好みに合わせて調整できる余地を用意する。
設定ファイル・エイリアス・スクリプトなどで「自分仕様」にできるようにする。②軽薄短小カーネル
カーネル（OSの核となる部分）は小さく保ち、追加機能は外側のアプリやライブラリで拡張する。③小文字使用
コマンド名やファイル名は、短く・小文字でそろえ、入力と読みやすさを両立させる。④森林保護
紙に印刷して配るより、検索・編集・再利用しやすいデジタル文書を活用する。⑤沈黙は金
意味のない出力を避け、本当に重要な情報だけを表示する。
ログレベルやverboseモードで調整できるようにする。⑥並列思考
仕事を小さく分割し、並列実行（同時に動かすこと）でスループット（こなせる量）を上げる。⑦商品コラボレーション
小さな部品同士を組み合わせて、単体を足し合わせた以上の価値を生み出すことを意識する。⑧90パーセント解
最後の10%に固執していつまでも完成しない状態を避け、現実的にちょうどよい解を狙う。⑨劣るが優る
一見「地味で劣って見える」方式でも、最大公約数（みんなが使える共通部分）を大事にしたほうが、長く生き残ることが多い。⑩階層指向
自然界と同じように、システムも階層構造で整理する。
大きな単位 → 中くらい → 小さな単位というふうに分けて、理解しやすくする。
プリンシプル オブ プログラミング(第３章－UNIX哲学)
1. 【3.64．UNIX哲学⑨『フィルタ化』②】
2. 【3.55．UNIX哲学④】
UNIXの設計思想はなぜ「哲学」と呼ばれるのか？
解説： UNIXの「哲学」とは、具体的な実装や仕様にとどまらず、ソフトウェア設計におけるシンプルかつ普遍的な考え方を含んでいるためである。
3. 【3.56．UNIX哲学①『小は美なり』①】
「UNIX哲学① 小は美なり」において、小さなソフトウェアの価値として正しいものはどれか？
解説： 「小は美なり」では、小さなソフトウェアは「理解しやすく保守しやすい」という点に価値があるとされている。
4. 【3.64．UNIX哲学⑨『フィルタ化』⑤】
UNIX哲学で推奨されるフィルタ的設計において、最も重要な入出力の形態は何か？
解説： フィルタ的な設計では、標準入力（stdin）と標準出力（stdout）を通じて他のソフトウェアと連携できることが重視される。
5. 【3.62．UNIX哲学⑦『シェルスクリプト活用』⑤】
シェルスクリプトの利用が増えるほど「てこの効果」が高まる理由として正しいものはどれか？
解説： 移植性が高いため、さまざまな環境で再利用できる＝「活用されるほど効果が増す」という意味で「てこの原理」が強く働く。
6. 【UNIX哲学 小定理⑧】
小定理⑧『90パーセント解』が推奨する開発方針はどれか？
解説： 残りの10%にかかるコストは大きいため、完璧を求めすぎず、現実的で効率的な「90%」を目指すのが合理的とされる。
7. 【3.58．UNIX哲学③『即興プロトタイプ』⑤】
UNIX哲学③に基づく「3段階のリリースモデル」の最終段階（第3段階）の特徴として正しいものはどれか？
解説： 第3段階では「機能と性能のバランスが最適化」され、「本当に必要な機能だけが残る」完成形が目指される。
8. 【UNIX哲学 小定理⑥】
小定理⑥『並列思考』が重視するのはどのような処理方法か？
解説： 小さな作業単位を並列実行することでCPU資源を効率よく使い、スループットを向上させるのが並列思考の目的である。
9. 【3.56．UNIX哲学①『小は美なり』②】
「小さく始めて、小さいまま保つ」という設計方針の主な目的は何か？
解説： 「小さいまま保つ」ことによって、コードの複雑化を防ぎ、意図や処理の流れを見失わないようにすることが目的とされている。
10. 【3.57．UNIX哲学②『1つ1仕事』②】
「1つ1仕事」の原則を守ることによって得られるメリットとして正しいものはどれか？
解説： 1つの機能に集中することで、不要な処理を避けられ、目的が明確なシンプルなコードになる。
参考文献・出典
- プリンシプル オブ プログラミング ～3年目までに身につけたい一生役立つ101の原理原則～
- 上田 勲（著）／秀和システム／第1版14刷／2025年／ISBN978-4-7980-4614-3
※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。
このページの著者
もちもちみかん（システムエンジニア）
社内SEとしてグループ企業向けの業務アプリを要件定義〜運用まで一気通貫で担当しています。
経験：Webアプリ／業務システム
得意：PHP・JavaScript・MySQL・CSS
個人実績：フォーム生成基盤／クイズ学習プラットフォーム 等
詳しいプロフィールはこちら！ もちもちみかんのプロフィール
