1. 【3.57．UNIX哲学②『1つ1仕事』⑤】
「1つ1仕事」の原則は、文や関数の設計においてもどのように応用できるとされているか？
解説： 関数や文においても「1つのことだけを書く」ようにすることで、読みやすく保守しやすいコードになる。
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に対応する余裕ができ、その分新機能や品質改善に時間を回せるから。結論
ハードウェア依存の部分はきちんと切り出し、その他の大部分は環境に依存しない形で書く。
抽象化（共通化して隠すこと）や層分離（レイヤー分け）を使い、移植しやすいアーキテクチャを選ぶ。その他（実践）
💡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）
要旨
レバレッジ（てこの原理）のように、すでにある良いソフトウェアを組み合わせて使い、少ない労力で大きな成果を出す、という考え方。理由
「良いプログラマは良いコードを書く。偉大なプログラマは良いコードを借りてくる」という言葉があるように、再利用は開発スピードと品質の両方を上げる。
一から全部書くより、信頼できる部品を組み合わせたほうが、バグも少なくなる。結論
巨大な一体型システムを作るより、単機能のツールとグルー言語（つなぎ役のスクリプトやシェル）で構成し、全体として大きな仕事をさせる。その他（実践）
💡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.57．UNIX哲学②『1つ1仕事』⑤】
2. 【3.59．UNIX哲学④『効率性より移植性』⑤】
UNIX哲学で「効率性より移植性」が重視される最大の理由は何か？
解説： 移植性の高いソフトウェアは、将来のハードウェアやOS変更にも柔軟に対応でき、保守や機能拡張も行いやすくなる。
3. 【3.63．UNIX哲学⑧『対話インターフェース回避』①】
UNIX哲学⑧『対話インターフェース回避』では、なぜ対話的インターフェースが問題視されているのか？
解説： 対話的インターフェースは、ユーザーが明示的に終了操作をするまで拘束されるため、非効率で再利用性も低下する。
4. 【UNIX哲学 小定理⑨】
小定理⑨『劣るが優る』が象徴するUNIXの特徴は何か？
解説： UNIXは見た目では劣っていても、「最大公約数的システム」として長期間にわたって使われてきた実績がある。
5. 【3.64．UNIX哲学⑨『フィルタ化』④】
次のうち、「フィルタ化」の思想に合致するUNIXコマンドの例として最も適切なものはどれか？
解説： `grep` は「入力を受け取って加工（抽出）し、出力する」フィルタ型のコマンドであり、UNIX哲学の「フィルタ化」に最も適している。
6. 【3.61．UNIX哲学⑥『レバレッジ・ソフトウェア』①】
UNIX哲学⑥『レバレッジ・ソフトウェア』において、ソフトウェアの理想的な活用方法はどれか？
解説： レバレッジ・ソフトウェアとは、単機能のソフトウェアを組み合わせることで、全体として大きな力を発揮させるという考え方である。
7. 【3.60．UNIX哲学⑤『データはテキスト』②】
「データをテキストで保存する」ことの主な利点として適切でないものはどれか？
解説： テキスト形式は読みやすく扱いやすい点が利点だが、暗号化は別の処理で対応するものであり自動では行われない。
8. 【3.64．UNIX哲学⑨『フィルタ化』③】
フィルタ的な設計がもたらす利点として不適切なものはどれか？
解説： グラフィカルな出力はフィルタ的な構造とは無関係であり、標準出力・標準入力を使うテキストベースの処理が基本となる。
9. 【3.57．UNIX哲学②『1つ1仕事』③】
次のうち「1つ1仕事」の原則を破っている例として最も適切なものはどれか？
解説： 「取得」と「整形」は本来別々の関心事であり、1つの機能に集中していないため「1つ1仕事」に反する。
10. 【3.62．UNIX哲学⑦『シェルスクリプト活用』②】
「シェルスクリプトを使うと自ら実装する必要がなくなる」とされる理由として正しいものはどれか？
解説： シェルスクリプトは既存のコマンドやツールを呼び出してつなぎ合わせるため、自分で処理の詳細を再実装する必要がない。
参考文献・出典
- プリンシプル オブ プログラミング ～3年目までに身につけたい一生役立つ101の原理原則～
- 上田 勲（著）／秀和システム／第1版14刷／2025年／ISBN978-4-7980-4614-3
※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。
このサイトの運営者
もちもちみかん（社内SE）
運営者は、グループ企業向けの業務アプリを要件定義から運用まで担当している社内SEです。PHP・JavaScript・MySQL・CSSを使った実務経験をもとに、一次情報や実際の運用で得た気づきを整理しています。
AIにコードを書かせて終わりではなく、どこで迷ったか・どこを人がレビューすべきかまで含めて、 やさしく噛みくだいてまとめています。
経験：Webアプリ・業務システム
得意：PHP・JavaScript・MySQL・CSS
制作・運用中：フォーム生成基盤・クイズ学習プラットフォーム・htmx逆引きレシピ 等
AI時代のエンジニアタイプ診断：CSPF/とろとろみかん
詳しいプロフィールはこちら！ もちもちみかんのプロフィール
