1.1 プログラミングに銀の弾丸はない（No Silver Bullet）
要旨一発で全部解決する“魔法の方法”はない。ソフトウェアはそもそも複雑。
結論歴史に学び、小さな改善を積み重ねよう。道具や設計のムダ（偶有的な複雑さ）は減らして本質に集中する。
プリンシプル オブ プログラミング
AI時代の設計指針：101原則を網羅！
公開日：
最終更新日：
AIがコードを書く時代だからこそ、古典的原則が「最強の武器」になります。
このページは、101原則を“ただの要約”で終わらせず、管理人の提言として「AI時代なら、こう読むべきだ！」という視点で再解釈していくための入口です。
本書『プリンシプル オブ プログラミング』に凝縮された101の原理・原則を、効率的に、かつ深く理解するための「総合ナビゲーション」として設計しました。
各章の詳細解説にもすぐアクセスできます。あなたの「学習のスタート地点」として、まずはここから進めてください。
🍊1分で理解する『プリンシプル オブ プログラミング』
『プリンシプル オブ プログラミング』は、プログラミングにおける設計原則などを 7章・101の原理・原則にまとめた本で、本書が目指す 「最高のコード」とは、次の4つを満たすことだと位置づけています。
- 拡張しやすい
- ムダが少ない
- 読みやすい
- 理解しやすい
本書では、前提・原則・思想・視点・習慣・手法・法則という7つの切り口で101の原理・原則を整理していますが、 このページではその中でも、毎日のコーディングに一番直結する 「3つの前提」「7つの設計原則」「6つの実践テクニック」にフォーカスします。
まずはここを押さえるだけで、「このコードの書き方でいいかな？」という迷いに対して、 共通のものさしを持って判断できるようになります。そのエッセンスを1分でつかめるようにギュッと凝縮しています。
1. 変化に強いコードを書くための「3つの前提」
1.1 プログラミングに銀の弾丸はない（No Silver Bullet）
どんな技術にも魔法はなく、地道な設計の積み重ねが必要。
1.2 コードは設計書である（Code as design）
最終的に読まれるのはコードだけ。設計の意図はコードに表現する。
1.3 コードは必ず変更される（Code will be changed）
要件も環境も変わる前提で、変更しやすい構造にしておく。
2. 最高のコードへ導く「7つの設計原則」
2.1 KISS（Keep It Simple, Stupid.）
できるだけシンプルに、余計な複雑さを持ち込まない。
2.2 DRY（Don't Repeat Yourself.）
同じ知識を重複させず、1か所を直せば全体が整うようにする。
2.3 YAGNI（You Aren't Going to Need It.）
いつか使うかも、で作らない。本当に必要になってから実装する。
2.4 PIE（Program Intently and Expressively.）
意図をはっきり持ち、その意図が伝わるようにコードで表現する。
2.5 SLAP（Single Level of Abstraction Principle.）
関数内で扱う抽象度のレベルを揃える。
2.6 OCP（Open-Closed Principle）
変更ではなく「拡張」で対応できる構造にしておく。
2.7 名前重要（Name is important）
役割が一目で分かる名前を付ける。いい名前は最高のコメント。
3. 現場で使える「6つの実践テクニック」
6.1 曳光弾（Tracer Bullet Development）
細く速い“試し撃ち”で全体の通り道を先に確認する。
6.2 契約による設計（Design by Contract）
前提条件・戻り値などの「約束」を明確にして設計する。
6.3 防御的プログラミング（Defensive Programming）
想定外の入力や状態を常に疑い、早めに検知して安全側に倒す。
6.4 ドッグフーディング（Dogfooding）
自分たちで自分たちのソフトを使い、使い勝手や問題を体験する。
6.5 ラバーダッキング（Rubber Duck Debugging）
誰か（ダック）に説明するつもりでコードの意図を言語化し、バグや違和感を見つける。
6.6 コンテキスト（Context）
どんな状況・背景のもとで使われるコードかを踏まえて、最適な設計を選ぶ。
忙しい人向け：AI時代にまず押さえる“核心”ショートカット
忙しい方は、まずここからどうぞ。いまの課題に近い入口へ最短で案内します。
A. AIの精度を上げる原則
指示の曖昧さを減らし、生成コードのぶれを抑える入口です。
B. AIコードの負債化を防ぐ原則
変更で壊れにくい構造を先に作り、保守コストを抑える軸です。
C. AIには代替しづらい人の仕事
境界設定・概念化・文脈判断など、人が握るべき設計判断です。
AI時代に抑えるべき設計用語（深掘りはこちら）
AI時代の設計判断で差が出る“用語”を、深掘り記事でまとめました。迷ったらここからどうぞ。
章フィルタ
全101の原理・原則を表示しています。
プリンシプル オブ プログラミング 目次
- 第１章：前提（プログラミングの変わらぬ真実）
- 第２章：原則（プログラミングのガイドライン）
- 第３章：思想（プログラミングのイデオロギー）
-
第３章：思想①（プログラミングセオリー）
- 3.1 プログラミングセオリー（Programming theory）
- 3.2 ３つの価値①：コミュニケーション（Communication）
- 3.3 ３つの価値②：シンプル（Simplicity）
- 3.4 ３つの価値③：柔軟性（Flexibility）
- 3.5 ６つの原則①：結果の局所化（Local consequences）
- 3.6 ６つの原則②：繰り返しの最小化（Minimize repetition）
- 3.7 ６つの原則③：ロジックとデータの一体化（Logic and Data together）
- 3.8 ６つの原則④：対称性（Symmetry）
- 3.9 ６つの原則⑤：宣言型の表現（Declarative Expression）
- 3.10 ６つの原則⑥：変更頻度（Rate of Change）
-
第３章：思想②（アーキテクチャ根底技法）
- 3.11 アーキテクチャ根底技法（Architecture core techniques）
- 3.12 抽象（Abstraction）
- 3.13 カプセル化（Encapsulation）
- 3.14 情報隠蔽（Information Hiding）
- 3.15 パッケージ化（Packaging）
- 3.16 関心の分離（Separation of Concerns）
- 3.17 充足性・完全性・プリミティブ性（Sufficiency, Completeness, Primitiveness）
- 3.18 ポリシーと実装の分離（Separation of Policy and Implementation）
- 3.19 インターフェースと実装の分離（Separation of Interface and Implementation）
- 3.20 参照の一点性（Single Point of Reference）
- 3.21 分割統治（Divide and Conquer）
- 第３章：思想③（アーキテクチャ非機能要件）
-
第３章：思想④（7つの設計原理）
- 3.29 ７つの設計原理（Seven design principles）
- 3.30 ７つの設計原理①：単純原理（Simplicity Principle）
- 3.31 ７つの設計原理②：同型原理（Isomorphism Principle）
- 3.32 ７つの設計原理③：対称原理（Symmetry Principle）
- 3.33 ７つの設計原理④：階層原理（Hierarchy Principle）
- 3.34 ７つの設計原理⑤：線形原理（Linearity Principle）
- 3.35 ７つの設計原理⑥：明証原理（Clarity Principle）
- 3.36 ７つの設計原理⑦：安全原理（Safety Principle）
-
第３章：思想⑤（UNIX思想）
- 3.37 UNIX思想（UNIX Thought）
- 3.38 UNIX思想①：モジュール化の原則（Rule of Modularity）
- 3.39 UNIX思想②：明確性の原則（Rule of Clarity）
- 3.40 UNIX思想③：組み立て部品の原則（Rule of Composition）
- 3.41 UNIX思想④：分離の原則（Rule of Separation）
- 3.42 UNIX思想⑤：単純性の原則（Rule of Simplicity）
- 3.43 UNIX思想⑥：倹約の原則（Rule of Parsimony）
- 3.44 UNIX思想⑦：透明性の原則（Rule of Transparency）
- 3.45 UNIX思想⑧：安定性の原則（Rule of Robustness）
- 3.46 UNIX思想⑨：表現性の原則（Rule of Representation）
- 3.47 UNIX思想⑩：驚き最小の原則（Rule of Least Surprise）
- 3.48 UNIX思想⑪：沈黙の原則（Rule of Silence）
- 3.49 UNIX思想⑫：修復の原則（Rule of Repair）
- 3.50 UNIX思想⑬：経済性の原則（Rule of Economy）
- 3.51 UNIX思想⑭：生成の原則（Rule of Generation）
- 3.52 UNIX思想⑮：最適化の原則（Rule of Optimization）
- 3.53 UNIX思想⑯：多様性の原則（Rule of Diversity）
- 3.54 UNIX思想⑰：拡張性の原則（Rule of Extensibility）
- ソフトウェア入出力の箴言（Software Input/Output Proverbs）
-
第３章：思想⑥（UNIX哲学）
- 3.55 UNIX哲学（UNIX Philosophy）
- 3.56 UNIX哲学①：小は美なり（Small is beautiful）
- 3.57 UNIX哲学②：１つ１仕事（Make each program do one thing well）
- 3.58 UNIX哲学③：即興プロトタイプ（Build a prototype as soon as possible）
- 3.59 UNIX哲学④：効率性より移植性（Choose portability over efficiency）
- 3.60 UNIX哲学⑤：データはテキスト（Store numerical data in flat ASCII files）
- 3.61 UNIX哲学⑥：レバレッジ・ソフトウェア（Use software leverage）
- 3.62 UNIX哲学⑦：シェルスクリプト活用（Use shell scripts for leverage and portability）
- 3.63 UNIX哲学⑧：対話インターフェース回避（Avoid captive user interfaces）
- 3.64 UNIX哲学⑨：フィルタ化（Make every program a filter）
- UNIX哲学：小定理（UNIX little theorem）
- 第４章：視点（プログラマの見る角度）
- 第５章：習慣（プログラマのルーティン）
- 第６章：手法（プログラマの道具箱）
- 第７章：法則（プログラミングのアンチパターン）
第1章:プログラミングの前提をクイズで学ぶ！
1.2 コードは設計書である（Code as design）
要旨要件定義〜テストまで全部が“設計”。最終的に設計を確定するのは動くコード。
結論プログラミング＝設計として、早めにコードで確かめる。設計理由（Why）はコメントやドキュメントに残す。
✨AIワンポイント
設計案をAIに文章で作らせたら、同じ場で最小の実装スケッチまで出させて挙動で確定させます。理由はPR本文に残し、次の変更時に参照できる形にします。1.3 コードは必ず変更される（Code will be changed）
AIで差が出る ★★★★★AI核心原則
要旨一度書いて終わりではない。要件変更や修正で、コードは必ず更新される。
結論“いずれ変わる”前提で、読みやすく変更しやすい設計に。よい命名・分割・疎結合・テストで安心して直せるようにする。
✨AIワンポイント
変更前提なら、AIへの依頼単位を小さな責務に分けるのが安全です。命名変更とロジック変更を同時にさせず、コミットを分離すると戻しやすくなります。AIは正常系だけ通して満足しやすいので、変更時は失敗系の回帰確認を先に置きます。第2章:良い設計の原則をクイズで学ぶ！
2.1 KISS（Keep It Simple, Stupid.）
AI重要 ★★★★★AI核心原則
要旨まずは“シンプル”。動かすための最小限だけ作り、余計なことはしない。
結論最小構成で作って、複雑さを足さない。新技術の無理な導入や「今いらない機能」は避ける。
2.2 DRY（Don't Repeat Yourself.）
AI重要 ★★★★AI核心原則
要旨同じことを何度も書かない。コードもコメントも重複はバグのもと。
2.3 YAGNI（You Aren't Going to Need It.）
要旨「多分必要」はたいてい不要。今必要なものだけを作る。
結論将来のための作り込みはしない。必要になった時に、その時の最適解で足す。シンプルさは結果的に変更に強い。
2.4 PIE（Program Intently and Expressively.）
AI核心原則
要旨コードは人が読む。意図が伝わるように、はっきり・分かりやすく書く。
結論読みやすさ最優先。命名・分割・整った構造で誤解を減らし、Why（設計理由）はコメントやドキュメントで補う。
✨AIワンポイント
PIEを守るなら、AI生成コードの曖昧な変数名を先に直します。tmp や data2 を放置すると、次の修正で誤読が増えてレビューコストが跳ねます。文脈が抜けた命名は誤実装の温床なので、入力・出力・責務が見える語へ寄せます。2.5 SLAP（Single Level of Abstraction Principle.）
要旨関数やブロックの“抽象度”を揃えて書くと、読みやすくなる。
結論上位は下位だけを呼ぶように分割し、横刺しや逆流を避ける。文書の目次のように構造を整える。
2.6 OCP（Open-Closed Principle）
要旨コードは“拡張に開き、既存修正には閉じる”ように設計する。
2.7 名前重要（Name is important）
AIで差が出る ★★★★AI核心原則
要旨命名はソフトの“UI”。分かる名前はバグも手戻りも減らす。
結論仕様理解を深めたうえで命名し、実装と照らして常に見直す。ドメイン語彙で一貫性と具体性を保つ。
✨AIワンポイント
名前重要の実践として、AIに命名案を複数出させるならドメイン用語辞書を先に渡します。API名とDBカラム名の語彙がずれるとバグより先に会話が壊れます。略語は最小にし、別の意味を持つ既存語への上書き命名を避けます。リンク：
第3章:思想とセオリーの全体像をつかむ！
3-1.設計セオリーをクイズで定着！
3.1 プログラミングセオリー（Programming theory）
要旨良いコード＝拡張しやすく、ムダがなく、読みやすく、理解しやすい。これを支える考え方が「セオリー」。
結論3つの価値（伝わる・シンプル・柔軟）を土台に、6つの原則を道しるべにして、具体のコードへ落とし込む。
3.2 ３つの価値①：コミュニケーション（Communication）
要旨コードは人に見せるドキュメント。読み手（未来の自分を含む）が分かることが最重要。
結論他者視点で書く。命名の一貫性、意図（Why）のコメント、驚き最小の設計を徹底する。
✨AIワンポイント
コミュニケーション重視なら、AI生成PRには変更意図と非採用案を必ず添えます。コードだけより、判断理由がある方が将来の修正判断が速くなります。3.3 ３つの価値②：シンプル（Simplicity）
要旨シンプル＝余分な複雑さを除いた状態。ムダは不具合や読みづらさの原因になる。
3.4 ３つの価値③：柔軟性（Flexibility）
要旨柔軟性＝変更しやすさ。コードは必ず変わる前提で備える。
3.5 ６つの原則①：結果の局所化（Local consequences）
要旨変更の影響が広がらず、特定の場所に閉じるように設計する。
結論責務と境界を明確にして近接配置。変更は特定モジュールで完結できる構造にする。
✨AIワンポイント
結果の局所化では、AIが提案した修正の影響ファイル数を計測して判断します。影響が広いなら境界が漏れているので、先に責務分割を入れてから機能追加します。3.6 ６つの原則②：繰り返しの最小化（Minimize repetition）
要旨重複は不整合やテスト漏れを招く。1か所を直せば全体が更新される構造にする。
結論ループ化・関数化・モジュール化で共通化。テンプレート化やライブラリ化も活用する。
✨AIワンポイント
繰り返し最小化の観点では、似たテストデータ生成をAIにまとめさせると効果が大きいです。fixtureビルダーを作れば仕様変更時の修正点が一箇所に集まります。3.7 ６つの原則③：ロジックとデータの一体化（Logic and Data together）
要旨処理とその対象データを近くに置くと、変更が楽で齟齬も減る。
結論データの近くに振る舞いを置く（カプセル化）。境界でデータを変換してから処理する。
✨AIワンポイント
ロジックとデータの一体化として、AI生成の変換ロジックをDTO近くへ寄せます。別層に散ると仕様変更時にマッピング漏れが起きやすくなります。リンク：
3.8 ６つの原則④：対称性（Symmetry）
要旨同じ種類のものは同じ表現にそろえると、予測しやすく読みやすい。
結論命名・引数・抽象度をそろえる。「追加」があれば「削除」も用意、SLAPでレベルも統一。
✨AIワンポイント
対称性では、AI提案に add があるなら remove の契約も同時に確認します。片側だけ実装されると運用時に回復経路がなくなります。3.9 ６つの原則⑤：宣言型の表現（Declarative Expression）
要旨命令手続きより、意図がそのまま読める宣言型の方が分かりやすいことが多い。
結論宣言的構文やデータ駆動を採用。アノテーションやDSLで意図をシンプルに記述する。
✨AIワンポイント
宣言型を活かすなら、AIに分岐ロジックをルールテーブルへ落とさせます。if連鎖より設定差分でレビューできる形の方が誤りを見つけやすいです。3.10 ６つの原則⑥：変更頻度（Rate of Change）
要旨「同じ理由・タイミングで変わるもの」は同じ場所に集めると強い。
結論単一責任の原則に沿って配置。変わりやすい部分は分離し、境界で隔離して影響を小さくする。
3-2.設計の10の技法をクイズで学ぶ！
3.11 アーキテクチャ根底技法（Architecture core techniques）
要旨良いコードを支える共通の基礎原理をチームで共有し、設計判断のブレを無くす。
結論プロダクト横断のチェックリスト化して、日々の設計・レビューで使う。
リンク：
3.12 抽象（Abstraction）
AI核心原則
要旨概念に線を引き、何を扱い何を捨てるかを決めてモジュールを区別する。
3.13 カプセル化（Encapsulation）
AI重要 ★★★★★
要旨関連するデータとロジックをひとつのモジュールに包み、外部からの混入を防ぐ。
結論関係が強い要素を同一モジュールにまとめ、影響範囲をモジュール内部に閉じる。
✨AIワンポイント
カプセル化では、AIが直接フィールド更新を広げていないかを見ます。状態変更はメソッド経由に寄せ、検証ロジックを一箇所に閉じ込めます。リンク：
3.14 情報隠蔽（Information Hiding）
要旨内部の詳細は隠し、外からは最小のインターフェースだけを見せる。
結論公開は必要最小限。利用者に必要な情報のみを提供し、実装詳細は隠す。
✨AIワンポイント
情報隠蔽を守るなら、AIが返すオブジェクトから内部IDや管理用フラグを外します。公開APIは利用者の判断に必要な項目だけに絞るのが安全です。3.15 パッケージ化（Packaging）
要旨関連モジュールを意味単位で束ね、全体を分かりやすい塊にする。
結論関連性を見てボトムアップで集合化。進行に合わせて構成を育てていく。
✨AIワンポイント
パッケージ化では、AI生成ファイルを機能単位で置き直してからレビューします。レイヤーと業務概念が混ざる配置は、探索コストを毎日増やします。3.16 関心の分離（Separation of Concerns）
要旨機能や目的ごとにコードを分け、互いを独立させる。
結論異なる責務は分割（例：UI／DB／制御）。横断的関心事はAOP等で切り出す。
✨AIワンポイント
関心の分離として、AIにUI表示文言と業務判定を同居させないよう指定します。翻訳修正でビジネスロジックを触る構造は事故率が高いです。3.17 充足性・完全性・プリミティブ性（Sufficiency, Completeness, Primitiveness）
要旨抽象は十分で漏れなく、操作は原子的であるべき。
結論提供関数を見直し、十分・完全・純粋な最小セットに整える。余計は削除か分離。
✨AIワンポイント
充足性とプリミティブ性では、AI提案APIの最小操作集合を見直します。似た意味の関数が多い時は、責務の切り方が曖昧な合図です。3.18 ポリシーと実装の分離（Separation of Policy and Implementation）
要旨変わりやすい方針（ポリシー）と安定しやすい実装を同居させない。
3.19 インターフェースと実装の分離（Separation of Interface and Implementation）
要旨使い方の契約（インターフェース）と中身（実装）を分け、利用側は契約だけに依存する。
結論「インターフェースに対してプログラムする」を徹底し、直接実装を呼ばない。
3.20 参照の一点性（Single Point of Reference）
要旨宣言・定義は一度きりにし、再代入や共有可変状態を減らす。
結論参照透過な関数と不変データ中心へ。副作用を抑え検証しやすくする。
✨AIワンポイント
参照の一点性では、AI生成コードの共有可変状態を疑います。再代入が多い処理はテストが不安定になるため、不変データと戻り値中心へ寄せます。3.21 分割統治（Divide and Conquer）
要旨大きな問題は小さく分けて、それぞれ解決してから統合する。
結論責任・データ・計算の単位で境界を引き、小さくして各個撃破する。
✨AIワンポイント
分割統治では、AIへの依頼を入力検証、計算、整形の三段に分けると精度が上がります。問題を細かく切るほどレビュー観点も明確になります。3-3.6つの非機能要件をクイズで学ぶ！
3.22 アーキテクチャ非機能要件（Architecture quality attributes）
要旨機能以外の品質（非機能）は、運用・保守・拡張のコストとリスクを左右する最重要領域。
結論要件定義→設計→テストの各段で非機能の基準を明確化し、構造で満たす設計を徹底する。
リンク：
3.23 変更容易性（Changeability）
要旨素早く安全に修正・拡張・再構成・移植できる力。
3.24 相互運用性（Interoperability）
要旨他システムと機能/データをやり取りできる能力。
結論契約ベースのAPIと標準プロトコル/データ形式を採用し、スキーマとバージョニングを管理する。
3.25 効率性（Efficiency）
要旨限られたリソースで必要な性能を出す（時間効率＋資源効率）。
結論計測指標を明確化し、ムダの削減とスケール手段（キャッシュ/キュー/抽象化層）をバランスよく設計する。
✨AIワンポイント
効率性では、AI最適化案を採る前に計測値を比較します。体感ではなくp95遅延やメモリ使用量で判断し、効果が無い変更は戻します。3.26 信頼性（Reliability）
要旨例外や誤操作、異常時でも機能を保つ力（フォールトトレランス＋ロバストネス）。
結論冗長化/フェールソフト/フェールセーフを設計に組み込み、必要に応じてフールプルーフで誤操作自体を無害化。
✨AIワンポイント
信頼性を高めるなら、AI生成処理の失敗モードを列挙します。例外時に再試行するのか停止するのかを分けないと、障害時に挙動がぶれます。3.27 テスト容易性（Testability）
要旨効果的・効率的に検証できる構造かどうか。
3.28 再利用性（Reusability）
要旨再利用される/する双方で価値を高め、「作らないこと」で品質と速度を上げる。
結論“3の法則”を目安に汎用化し、API安定化・ドキュメント・バージョニングで採用性を高める。
✨AIワンポイント
再利用性を狙うなら、AIが作る共通関数の入力契約を厳密にします。曖昧な型を許すより、受け付ける形を狭めた方が利用側の事故が減ります。3-4.7つの設計原理をクイズで身につける！
3.29 ７つの設計原理（Seven design principles）
要旨障害を作り込まないための７つの観点を共通言語にし、設計とレビューの軸をそろえる。
3.30 ７つの設計原理①：単純原理（Simplicity Principle）
要旨常にシンプルを選び、見通しの良い自然なコードを書く。
結論高等テクより「単純・直截・最小」。まず動く最小で止め、複雑化はそれが必要だと言う根拠が出たときだけ。
✨AIワンポイント
単純原理では、AIに一つの実装案だけでなく最短案も出させて比較します。短い方で要件を満たすなら、複雑な案を採る理由はありません。3.31 ７つの設計原理②：同型原理（Isomorphism Principle）
要旨同じことは同じ形で表現し、コードの一貫性を保つ。
結論スタイル／命名／構造／パターンを統一。似た処理はシグネチャや戻り値、例外方針もそろえる。
✨AIワンポイント
同型原理として、AI生成APIの戻り値形を既存に合わせます。成功時だけ配列、失敗時だけ文字列のような揺れは呼び出し側を汚します。3.32 ７つの設計原理③：対称原理（Symmetry Principle）
要旨対称（対）を意識して設計すると、予測しやすく読みやすい。
結論条件には反条件、操作には逆操作を用意。対称が崩れるなら要件から見直す。
3.33 ７つの設計原理④：階層原理（Hierarchy Principle）
要旨階層構造で編成し、上位→下位の主従関係を明確にする。
結論大→中→小の秩序で構造化し、上位は下位を外部視点で扱う。横刺しや逆流の依存は避ける。
✨AIワンポイント
階層原理を守るには、AI提案コードで上位層が下位実装詳細を参照していないか確認します。DTO変換やSQL文字列が上位へ漏れたら分離し直します。3.34 ７つの設計原理⑤：線形原理（Linearity Principle）
要旨処理はできる限り直線的に。分岐と状態は最小にする。
結論ガード節で早期return、複雑条件は述語化/表引き、必要なら明示的ステートで管理する。
✨AIワンポイント
線形原理では、AIが深いネストを作ったらガード節へ置き換えます。分岐条件を述語関数へ分離すると読み筋が一本になります。3.35 ７つの設計原理⑥：明証原理（Clarity Principle）
要旨一見して正しいと分かる明瞭なロジックを書く。
結論単機能関数・一文一義・意味のある命名。Why/契約/前後条件をコードやコメント、図で明示する。
✨AIワンポイント
明証原理の実践として、AIが導入した式の前提条件をテスト名に書き込みます。数式だけ正しくても、適用条件が不明だと誤用されます。3.36 ７つの設計原理⑦：安全原理（Safety Principle）
要旨想定外も起こる前提で、安全側に倒す設計・実装を行う。
結論else/default/セーフガード必須。フェールセーフ/ソフト/FTを織り込み、リトライやRBを設計判断で使い分ける。
✨AIワンポイント
安全原理では、AI生成のdefault分岐に監視通知を入れます。未知値を黙殺せず、ログとメトリクスで早期検知できる形にします。3-5.長寿のUNIXの思想をクイズで学ぶ！
3.37 UNIX思想（UNIX Thought）
要旨長年の実践から生まれた設計・実装の技法群で、今も通用する普遍的な指針。
3.38 UNIX思想①：モジュール化の原則（Rule of Modularity）
要旨関係の強い要素をひとまとまりにして最小のインターフェースに削る。
3.39 UNIX思想②：明確性の原則（Rule of Clarity）
要旨巧妙さより明確さ。人が一目で理解できるコードにする。
結論意図が伝わる命名・整形・コメントを徹底し、推測を要する書き方を排除する。
✨AIワンポイント
明確性の原則として、AIが短縮記法を多用したら可読優先へ戻します。三項演算子の入れ子は一見速いが、保守時の誤読を増やします。3.40 UNIX思想③：組み立て部品の原則（Rule of Composition）
要旨入出力をテキスト/JSONなどのストリームで扱い、部品同士をつなげやすくする。
結論独自バイナリよりシンプルなストリームIFを優先。パイプ可能な設計で疎結合とテスト容易性を高める。
✨AIワンポイント
組み立て部品化を意識するなら、AIに入出力をJSON Linesなど直列可能な形へ寄せさせます。中間成果物をパイプしやすくなると検証が速いです。3.41 UNIX思想④：分離の原則（Rule of Separation）
結論設定/DI/プラグインで方針を外出し。ポリシー変更はメカニズム非改変で差し替え可能に。
✨AIワンポイント
分離の原則では、AIが判定ルールをコードへ埋め込んだら設定へ外出しします。運用で変わる値を実装と分離すると改修リードタイムが縮みます。3.42 UNIX思想⑤：単純性の原則（Rule of Simplicity）
要旨設計・実装は常にシンプル最優先。複雑さは自然に増えるため自制が必要。
結論「Less is more」を合言葉に最小構成でデプロイ。足す前に削るを検討する。
✨AIワンポイント
単純性の原則に沿って、AI提案差分から未使用オプションを落とします。実装量を削るだけで障害面積が小さくなります。3.43 UNIX思想⑥：倹約の原則（Rule of Parsimony）
要旨大きさ（量と複雑さ）を避け、小さく作る。
結論小さな関数/モジュールで構成し、使ってないコードや重複を除去。LOCや引数数に上限目安を設ける。
✨AIワンポイント
倹約の原則では、AIが生成した長関数を早めに分解します。引数数と行数に上限を設けると、肥大化をレビューで止めやすくなります。3.44 UNIX思想⑦：透明性の原則（Rule of Transparency）
要旨外から挙動が理解でき、内部状態も観測できる設計にする。
結論ログ/メトリクス/トレース/ヘルスチェックを組み込み、本番コードにもデバッグ容易性を内蔵する。
✨AIワンポイント
透明性を上げるには、AIコードに入力値と結果を結ぶログキーを埋めます。障害調査で再現不能になる主因は観測不足です。3.45 UNIX思想⑧：安定性の原則（Rule of Robustness）
要旨透明・単純な内部構造で、異常や入力変動に強い実装を保つ。
結論作者が説明できる構造を維持。特異/極端入力でストレステストし、安定性を常時確認する。
✨AIワンポイント
安定性の原則として、AI提案を極端値テストに通します。空配列や巨大入力で崩れるなら、平常時の見た目が良くても採用しません。3.46 UNIX思想⑨：表現性の原則（Rule of Representation）
要旨ロジックではなくデータで表現する（テーブル/設定駆動）。
結論分岐はDBや設定へ外出し。ルールテーブルやDSLで意図を宣言的に表す。
✨AIワンポイント
表現性の原則では、AIに分岐条件のテーブル化を求めます。ルール変更をコード修正から設定差分へ移せると運用が軽くなります。3.47 UNIX思想⑩：驚き最小の原則（Rule of Least Surprise）
結論既存の慣習・用語・挙動に合わせ、一貫性を保つ。似て非なる挙動は避ける。
3.48 UNIX思想⑪：沈黙の原則（Rule of Silence）
要旨出力は最小限にして重要情報だけを見せる。
結論本当のエラーのみ標準エラーへ。詳細はverbose切替で提供し、デフォルトはサイレントに。
3.49 UNIX思想⑫：修復の原則（Rule of Repair）
要旨回復できないエラーは早期に大きく失敗させ、発見を容易にする。
結論握りつぶさずに中断して大きく通知。ロールバック/再試行/隔離停止の方針を事前に設計する。
✨AIワンポイント
修復の原則では、AIに失敗時の停止条件を明示させます。回復不能エラーを継続実行すると、後段で汚染データが広がります。3.50 UNIX思想⑬：経済性の原則（Rule of Economy）
要旨最も高価なのは開発者の時間。環境投資は最終的にコスト削減に効く。
結論良いハード/ツール/情報アクセスに投資し、待ち時間や手作業のボトルネックを除去する。
✨AIワンポイント
経済性の原則では、AI導入で削れる待ち時間を数値で見ます。レビュー準備やテスト実行の自動化に投資すると、日次の総時間が減ります。3.51 UNIX思想⑭：生成の原則（Rule of Generation）
要旨コードを生むコード（生成/テンプレ/AI）を活用して反復を自動化する。
結論定型は自動生成し、人は設計判断とレビューに集中。CIで再生成と差分検知を体制化する。
✨AIワンポイント
生成の原則を使うなら、AI生成物は再生成可能な手順とセットで管理します。手修正混入を検知するチェックをCIへ置くと破綻しません。3.52 UNIX思想⑮：最適化の原則（Rule of Optimization）
要旨速さより正しさ。最適化は計測に基づいて段階的に行う。
結論必要性の証明→計測→改善→再計測。削除は最大の最適化であることも忘れない。
✨AIワンポイント
最適化の原則では、AIの高速化提案を一気に入れず一本ずつ検証します。改善前後の計測ログを残して、逆効果なら即戻します。3.53 UNIX思想⑯：多様性の原則（Rule of Diversity）
要旨唯一の正解はない。選択肢を持ち、文脈で選ぶ。
結論断定を避け複数案を比較検証。言語/フレームワーク/配置/プロセスの多様性を前提に意思決定を記録する。
✨AIワンポイント
多様性の原則として、AIには異なる実装方針を最低二案出させます。採用理由を記録しておくと、将来の技術移行判断が速くなります。3.54 UNIX思想⑰：拡張性の原則（Rule of Extensibility）
要旨将来の拡張を前提に、後方互換を保ちながら差し替え/追加できる構造にする。
結論プラガブルな接続部と拡張ポイントを用意。将来フックの意図をコメントで明示する。
✨AIワンポイント
拡張性を狙うなら、AIが追加するフック点に利用例を付けさせます。使い道の無い拡張ポイントは将来の負債になりやすいです。ソフトウェア入出力の箴言（Software Input/Output Proverbs）
要旨入力は寛容に、出力は厳格に。ただし「寛容」は仕様解釈ではなく動作で行う。
結論入力は検証・正規化して受容、出力は規格に忠実に整形。互換テストを自動化し、仕様解釈は厳密に保つ。
✨AIワンポイント
入出力の箴言では、AIが作る受信処理に正規化層を置きます。受け入れは広く、外部へ返す値はスキーマ検証で厳密に固定します。3-6.堅牢なUNIXの哲学をクイズで学ぶ！
3.55 UNIX哲学（UNIX Philosophy）
要旨UNIXの長寿を支えた設計の哲学を、現代開発の指針として活かす。
結論小さく作る／一仕事に集中／早い試作／移植性重視／テキスト志向／組み合わせ活用を日常の設計・実装に適用する。
3.56 UNIX哲学①：小は美なり（Small is beautiful）
要旨ソフトは小さいほど理解しやすく、保守しやすく、組み合わせやすい。
結論小さく始めて小さく保つ。追加は必要が証明された最小限に（Less is more）。
✨AIワンポイント
小は美なりの観点で、AIへの依頼も小さい単位に分けます。1回で巨大差分を作るより、目的別に分割した方が品質確認が安定します。3.57 UNIX哲学②：１つ１仕事（Make each program do one thing well）
結論関心を分離し、1文1処理で本質を明確に。
3.58 UNIX哲学③：即興プロトタイプ（Build a prototype as soon as possible）
要旨早く作って見せれば、誤りや不足を早期に潰せる。
結論早期プロト→短サイクル改善→段階リリースで最適点に収束させる。
✨AIワンポイント
即興プロトタイプでは、AIに骨格実装を先に作らせて早期に実環境へ当てます。正解を考え切るより、差分観測を早く始める方が得です。3.59 UNIX哲学④：効率性より移植性（Choose portability over efficiency）
要旨長い目では移植性の方が価値を生むことが多い。
3.60 UNIX哲学⑤：データはテキスト（Store numerical data in flat ASCII files）
要旨テキスト（今ならJSON等）は最も扱いやすくポータブル。
結論独自バイナリは最小限にし、標準的なテキスト形式を優先する。
✨AIワンポイント
データはテキストの原則に沿って、AI出力フォーマットは可読な標準形式を選びます。独自バイナリ化は相互運用の障壁になります。3.61 UNIX哲学⑥：レバレッジ・ソフトウェア（Use software leverage）
要旨良い部品を組み合わせ、他者の成果を「てこ」にする。
結論単機能ツール＋グルー言語で大仕事を成す。内製は核に集中する。
✨AIワンポイント
レバレッジでは、AIに既存ライブラリ利用前提で案を出させます。自作は中核価値に絞ると、保守対象が増えすぎません。3.62 UNIX哲学⑦：シェルスクリプト活用（Use shell scripts for leverage and portability）
3.63 UNIX哲学⑧：対話インターフェース回避（Avoid captive user interfaces）
要旨過度な対話UIは学習・連携・自動化の足かせになりやすい。
結論基本は非対話（CLI/設定/ファイルI/O）。必要なら初心者UIと非対話の両方を用意。
3.64 UNIX哲学⑨：フィルタ化（Make every program a filter）
要旨すべてのプログラムを「受けて加工して出す」直列可能な部品にする。
結論標準入力→処理→標準出力の設計を基本に、テキスト/JSONで疎結合にする。
✨AIワンポイント
フィルタ化を徹底するなら、AIに入力一件ごとの独立処理を作らせます。副作用を局所化でき、並列化や再実行が容易になります。UNIX哲学：小定理（UNIX little theorem）
要旨日々の細部判断を支える軽量ルール集で、UNIX的実用主義を徹底する。
結論環境カスタマイズ／小さなカーネル／小文字命名／紙依存排除／沈黙／並列思考／部品連携／90%解／最小公約数重視／階層指向をチームの共通ルールにする。
第4章:設計で迷わない目をクイズで養う！
4.1 凝集度（Cohesion）
AI重要 ★★★★AI核心原則
要旨1つのモジュールの中身が「同じ目的」にどれだけ集中しているかの度合い。高いほど良い。
結論目標は「機能的強度」＝1モジュール1役割。責務をはっきり決めて、関係ない処理を入れない。
4.2 結合度（Coupling）
AI重要 ★★★★★AI核心原則
要旨モジュールどうしのつながりの強さ。弱いほど変更の影響が広がらず安全。
結論目標はデータ結合。必要最小の引数でやり取りし、グローバルや制御フラグ依存を避ける。
4.3 直交性（Orthogonality）
要旨部品同士を独立させ、片方の変更がもう片方に波及しない状態を作る考え方。
結論明確な境界とレイヤーで疎結合に。重複データや暗黙依存をなくし、変更は局所で完結させる。
✨AIワンポイント
直交性では、AI生成設定値の重複定義をなくします。同じ意味のフラグが複数箇所にあると、修正時に食い違いが起きます。4.4 可逆性（Reversibility）
要旨あとで戻せる設計にしておく発想。不可逆な選択は避ける。
結論技術や前提に縛られすぎないよう、間接化や独立モジュール化で「やり直し可能」を確保する。
✨AIワンポイント
可逆性を意識して、AIによる大規模変更は機能フラグで段階導入します。戻し手順を先に用意すると本番判断が速くなります。4.5 コードの臭い（Bad smell in code）
要旨読みづらい・直しづらい前ぶれサインのこと。見つけたら小さく安全に直す。
結論重複はまとめる／長い・大きいは分割／不要な仲介は削除／名前は実態に合わせて即修正する。
✨AIワンポイント
コードの臭い検知には、AI生成差分へ複雑度と重複率チェックを通します。匂いを見つけた時点で小さく直す方が安上がりです。4.6 技術的負債（Technical Debt）
要旨急ぐために残した粗い実装は「借金」。放置すると利息（手戻り・遅さ）になる。
結論やむなく負債を取るなら内容・影響・返済期限を見える化し、テストで守りつつ速やかに返済する。
✨AIワンポイント
技術的負債を取るなら、AIが生んだ暫定実装に返済条件を添えます。期限と置換先が無い仮対応は、ほぼ恒久化します。第5章:良い設計習慣をクイズで身につける！
5.1 プログラマの三大美徳（Three great virtues of programmer）
要旨怠惰・短気・傲慢を「仕組み化・自動化・プロ意識」に変えて、無駄と手戻りを減らす。
結論面倒はツール化し、コンピューターに任せ、胸を張れるコードを作る。長時間労働で解決しようとしない。
✨AIワンポイント
三大美徳の実践として、AIには繰り返し作業の自動化スクリプトを優先的に作らせます。手作業を減らすほどミスと疲労が下がります。5.2 ボーイスカウトの規則（Boy Scout Rule）
要旨触れたコードは「来たときより少しきれい」に直して戻す。
結論プル前より良くしてコミットを習慣化。命名改善・重複削減・関数抽出・コメント整備・テスト追加をコツコツ。
✨AIワンポイント
ボーイスカウト規則では、AIに触れた箇所の小改善を同時提案させます。命名修正や不要分岐削除を一緒に入れると腐敗を抑えられます。5.3 パフォーマンスチューニングの箴言（Proverb of performance tuning）
要旨時期尚早な最適化は害。まずは変更を局所化できる「良い設計とコード」。最適化は必要時のみ計測に基づいて。
結論必要性を証明→計測→ボトルネックだけ直す→再計測。可読性や移植性を犠牲にしない。
✨AIワンポイント
性能チューニングでは、AI案の前提計測条件を固定します。ベンチの入力サイズと回数を揃えない比較は判断を誤らせます。5.4 エゴレスプログラミング（Egoless programming）
要旨人ではなくコードを批評。指摘を歓迎し学ぶ姿勢で品質を上げる。
結論謙虚さと尊重を持ち、十戒を意識。相談なしの全面書き直しは避け、バランスよく継続改善する。
✨AIワンポイント
エゴレスの観点で、AIレビュー結果は人ではなく差分へ向けます。人格評価を排し、再現可能な指摘形式へ統一してください。5.5 １歩ずつ少しずつ（One by One）
要旨小さな作業を1つずつ進め、確認→次へを繰り返すと品質も速度も上がる。
結論結論を急がず段階を刻む。考えを記録し、直感は試しつつも検証で決める。
✨AIワンポイント
1歩ずつ進めるなら、AI作業も小タスク化して都度テストします。途中で逸れた時に、どの変更が原因か即特定できます。5.6 TMTOWDI（There's more than one way to do it.）
要旨やり方は1つではない。文脈に合う選択肢を比較して選ぶ。
結論評価基準を明確にし、複数案を検討・試作。よりシンプルで持続可能な方法を選ぶ。
第6章:設計現場で使える手法をクイズで学ぶ！
6.1 曳光弾（Tracer Bullet Development）
要旨まず最小でも実環境で動く“骨格”を通し、学びと調整のサイクルを早める。
結論本物の最小コードで端から端まで動かし、以後は肉付けしつつ狙いとの差を常時修正する。
✨AIワンポイント
曳光弾では、AIにエンドツーエンドの最小経路を先に作らせます。仮の固定値でも本番経路を通すと、欠落要件が早く見えます。6.2 契約による設計（Design by Contract）
AI重要 ★★★★★AI核心原則
要旨呼び手と受け手で「前提条件・事後条件」を合意し、その契約どおりに実装する。
結論仕様はコメントで明示し、アサーションで契約を検証。前提を満たさず呼ばない／満たせないなら早期に失敗させる。
6.3 防御的プログラミング（Defensive Programming）
AI注意 ★★★★
要旨「かもしれない」を前提に、入力と境界を徹底チェックして被害を最小化する。
結論入口で検証→内部はクリーンに。想定外はアサートで即検出、想定内は方針に従って安全に処理する。
✨AIワンポイント
防御的実装として、AIコードの入口でバリデーションを完了させます。内部で何度も同じ検証をしない構造にすると見通しが良くなります。境界で弾かなかった値が内部へ広がると、障害時の原因特定が急に難しくなります。6.4 ドッグフーディング（Dogfooding）
要旨自分のソフトを自分で使い、ユーザー視点の欠点や不便をあぶり出す。
結論実環境・実データで正常系も異常系も操作し、体験のギャップを発見して優先度をつけて直す。
✨AIワンポイント
ドッグフーディングでは、AIで作った機能を自分の実データで必ず回します。使いにくさは仕様書より操作時に露出します。6.5 ラバーダッキング（Rubber Duck Debugging）
要旨問題を順序立てて“誰か”に説明すると、矛盾や見落としに自分で気づける。
結論再現手順→期待→現状→差分→仮説の順に声に出して説明し、最小再現へ縮めていく。
✨AIワンポイント
ラバーダッキングをAIと行う時は、再現手順を時系列で渡して矛盾点を突きます。説明途中で曖昧になる箇所が不具合の起点です。6.6 コンテキスト（Context）
AIで差が出る ★★★★★AI核心原則
要旨背景・状況（文脈）を設計・実装・会話に組み込み、判断の質を上げる。
結論ドメインモデルで文脈を共有し、階層化・驚き最小でコードに反映。中断を減らし、全体最適の視点で決める。
✨AIワンポイント
コンテキスト重視なら、AIへ業務背景と制約を最初に与えます。断片コードだけ渡すと、正しそうで使えない案が増えます。特に例外時の業務優先順位を渡さないと、復旧方針が現場とずれやすくなります。リンク：
第7章:現場で使える設計法則をクイズで学ぶ！
7.1 ブルックスの法則（Brooks's Law）
要旨炎上中に人を足しても、教育や調整が増え、むしろ遅くなる。
結論人海戦術に逃げず、早めに計画を組み直し、優先度を付けて段階的に出す。
✨AIワンポイント
ブルックスの法則を踏まえ、遅延時はAIで受け入れ基準を再分解して優先度を付け直します。人を足す前にスコープを削る方が効きます。7.2 コンウェイの法則（Conway's Law）
要旨設計は組織構造の写し鏡になりやすい。
結論理想のアーキテクチャに合わせてチーム編成を組み、境界を一致させる。
✨AIワンポイント
コンウェイの法則では、AI提案アーキテクチャをチーム境界と突き合わせます。担当境界とコード境界がずれると調整コストが跳ねます。リンク：
7.3 割れた窓ガラスの法則（Broken Windows Theory）
要旨小さな乱れの放置が、全体の劣化を加速させる。
結論気づいたらすぐ直す。時間がなければタグで可視化し、必ず後で修復する。
✨AIワンポイント
割れ窓対策として、AIが触った周辺の小さな警告や命名乱れを同時に直します。微小な乱れを放置しない習慣が品質低下を防ぎます。7.4 エントロピーの法則（Law of Entropy Increase）
要旨コードは放っておくと必ず乱れていく。
結論小さなリファクタリングとテストを継続し、腐敗の兆候を常に監視して戻す。
✨AIワンポイント
エントロピー対策では、AI生成後に定期リファクタ枠を確保します。変更のたびに少し整える運用で崩壊速度を抑えられます。リンク：
7.5 80-10-10の法則（80-10-10 Rule）
要旨多くの要求はすぐ満たせるが、残りはコスト高 or 実現困難になりがち。
結論100％に固執せず、重要な少数に集中。ホットスポットを計測して手当てする。
✨AIワンポイント
80-10-10では、AIに要件を重要度順で渡して上位から実装します。残り10%の難所を早く可視化すると計画が現実的になります。7.6 ジョシュアツリーの法則（Joshua Tree Principle）
要旨名前を付けると現象が見えるようになる。
結論概念に良い名前を与え、用語をチームで統一して認知と共有を加速する。
✨AIワンポイント
ジョシュアツリーの法則に従い、AIとの会話でも曖昧事象へ名前を付けます。エラー群を分類名で扱えると対策の再利用が進みます。7.7 セカンドシステム症候群（Second System Syndrome）
要旨v2で機能を盛りすぎ、重く使いにくくなりやすい。
結論KISS/YAGNIを守り、ユーザーと用途に立ち返って必要最小で仕上げる。
✨AIワンポイント
セカンドシステム症候群を避けるため、AIが提案する追加機能を用途ごとに棚卸しします。初版で必要性が証明できないものは外します。7.8 車輪の再発明（Reinvented Wheel）
要旨既存で足りるのに同等機能を自作してしまう。
結論着手前に標準/OSSを調査し相談。自作は差別化の核や学習目的に限定する。
✨AIワンポイント
車輪の再発明を防ぐには、AIに既存OSS比較表を先に作らせます。差別化点が説明できる時だけ自作へ進む判断が妥当です。7.9 ヤクの毛刈り（Yak Shaving）
要旨前提タスクに追われ、本来の目的を見失う連鎖。
結論目的と制約を明文化し、逸脱に気づいたら停止→相談→別ルートを検討する。
✨AIワンポイント
ヤクの毛刈り対策として、AIタスクには終了条件を明記します。目的外の前提作業が増えたら、そこで止めて別経路を選び直します。参考文献・出典
- プリンシプル オブ プログラミング ～3年目までに身につけたい一生役立つ101の原理原則～
- 上田 勲（著）／秀和システム／第1版14刷／2025年／ISBN978-4-7980-4614-3
※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。
免責事項
本クイズは、プログラミングおよびソフトウェア設計に関する理解を深めることを目的として作成されたものであり、正確性・完全性・最新性を保証するものではありません。
本クイズの内容は、一般的な設計原則や哲学的背景に基づいて構成されていますが、すべての現場や状況に適用できるとは限りません。
出題内容や解答・解説において、誤りや誤解を招く表現が含まれている可能性があります。あらかじめご了承ください。
本クイズの利用により生じたいかなる損害・損失についても、当方は一切の責任を負いかねます。
問題文・選択肢・解説の内容は予告なく変更・更新される場合があります。
教育・学習・社内研修などに利用される場合は、各自の判断と責任のもとでご活用ください。
このページの著者
もちもちみかん（システムエンジニア）
社内SEとしてグループ企業向けの業務アプリを要件定義〜運用まで一気通貫で担当しています。
経験：Webアプリ／業務システム
得意：PHP・JavaScript・MySQL・CSS
個人実績：フォーム生成基盤／クイズ学習プラットフォーム 等
詳しいプロフィールはこちら！ もちもちみかんのプロフィール
