1. 【3.33．７つの設計原理④『階層原理』③】
階層原理の効果として最も適切なものはどれか？
解説： **階層的な構造を持たせることで、個々の部品に分割されたコードを「抽象的に把握」しやすくなり、理解・保守・再利用が容易になる**。
AIリファクタの軸、7つの設計原理をクイズで習得！
第3章：思想｜7つの設計原理
公開日：
最終更新日：
AIリファクタの時代は、直し方より「何を軸に直すか」が大事です。本ページでは、『プリンシプル オブ プログラミング』第3章「7つの設計原理」で紹介される、変更に強い設計のための7つの原理を、要点を押さえた要約と4択クイズで整理します。
要約で原理の狙いをつかみ → 4択クイズ（10問・全問解説付き）で判断基準を確認 → 迷ったところは解説で復習。「読む→解く→わかる」で、将来の仕様変更にも振り回されにくい設計の軸を定着させましょう。
3-4：AIリファクタの軸、7つの設計原理クイズ！ 目次
- プログラミング クイズ一覧へ
- 第3章：思想とセオリーの全体像をつかむ！ 目次へ
- 次のクイズへ(3-5：AI×普遍の知恵、UNIX思想クイズ！)
- 前のクイズへ(3-3：AIが苦手な非機能要件クイズ！)
- 『プリンシプル オブ プログラミング』101の原理・原則総まとめ
第３章：思想④
～７つの設計原理～
3.29 ７つの設計原理（Seven design principles）
要旨
バグを生み込みにくい設計にするための７つの重要な視点を、チームで共有された「共通のものさし」として使い、設計やレビューの考え方を揃えていこう、という考え方。理由
人によって見るポイントがバラバラだと、レビューの指摘内容も毎回変わってしまい、品質が安定しない。共通の原理を持っておけば、「何を良しとするか」が揃い、レビューの軸もぶれにくくなるから。結論
ここで挙げる７つの原理を、設計する時の規範やレビューのチェック項目として採用し、チェックリストにして日常的に使う。その他（範囲・効果）
- 原理一覧
- 単純原理（Simplicity Principle）
- 同型原理（Isomorphism Principle）
- 対称原理（Symmetry Principle）
- 階層原理（Hierarchy Principle）
- 線形原理（Linearity Principle）
- 明証原理（Clarity Principle）
- 安全原理（Safety Principle）
- 期待できる効果例レビューの質と再現性が上がる／暗黙知だった「感覚」が言葉になる／欠陥の早期発見や、そもそもの作り込み防止につながる。
- 原理一覧
関連用語（用語集で復習）
3.30 ７つの設計原理①単純原理（Simplicity Principle）
要旨
とにかく常にシンプルさを大事にし、パッと見て筋道が追える、自然で分かりやすいコードを書くことを目指す原理。理由
バグはたいてい、複雑でごちゃごちゃしたコードに集中しがちだから。シンプルさは「バグの入りづらさ」とほぼ直結している。結論
かっこいいテクニックや一発芸的な書き方よりも、単純・まっすぐ・必要最小限を優先する。「これ以上足しても得が少ない」というところで止める。その他（実践）
💡AIワンポイント
単純原理では、AIに一つの実装案だけでなく最短案も出させて比較します。短い方で要件を満たすなら、複雑な案を採る理由はありません。関連用語（用語集で復習）
3.31 ７つの設計原理②同型原理（Isomorphism Principle）
要旨
同じ種類のことは、同じ形・同じルールで書くようにして、コード全体の一貫性を保つ原理。理由
形が揃っていると、ちょっと違う書き方をしている部分が「あれ？ここだけ違うぞ」とすぐに目につく。それが早めのバグ発見につながるから。結論
個人のクセだけで書くのは避けて、スタイル・パターン・命名・構造などをチームで統一しておく。その他（実践）
💡AIワンポイント
同型原理として、AI生成APIの戻り値形を既存に合わせます。成功時だけ配列、失敗時だけ文字列のような揺れは呼び出し側を汚します。関連用語（用語集で復習）
3.32 ７つの設計原理③対称原理（Symmetry Principle）
要旨
コードの構造・制御・命名などを考えるときに、ペア（対称性）を意識してデザインする原理。理由
対称性があると、ふるまいが予測しやすくなり、読み手は「こうなっているなら、反対側はこうだろう」と推測しやすい。そのおかげで理解しやすくなり、欠陥にも気づきやすくなる。結論
条件には対になる条件を、操作には逆方向の操作を用意する。どうしても対称が崩れてしまうなら、そもそもの要件が整理されているかを見直すサインと考える。その他（実践・例）
- 命名の分かりやすい対：get/set, start/stop, from/to, begin/end, open/close など。
- 制御の対：if に対する else、try に対する finally、生成に対する破棄（open に対する close など）。
- 「例外ケースだらけで対称が崩れまくる」場合は、要件の切り分けやモデリングをやり直すべきサインとして受け止める。
💡AIワンポイント
関連用語（用語集で復習）
3.33 ７つの設計原理④階層原理（Hierarchy Principle）
3.34 ７つの設計原理⑤線形原理（Linearity Principle）
要旨
処理の流れをできるだけ一直線（直線的）に保ち、分岐や状態を必要最小限に抑える原理。理由
条件分岐だらけ・フラグだらけのコードは、読み手が頭の中で状態を追いかけるのが大変で、可読性が下がり、バグも入りやすくなるから。結論
分岐はできるだけ減らし・単純化する。上から下に読んだときに、流れが自然につながるコードを目指し、全体を俯瞰して「複雑になりすぎていないか」を常にチェックする。その他（実践・効果）
- ガード節（早期return）を使って、「異常系は先に帰す」ことでネストを浅く保つ。
- 複雑な条件式は、そのまま書かずに意味のある名前を持った関数に切り出すか、表（テーブル）で管理するデータ駆動にする。
- 状態遷移が必要なときは、暗黙のフラグをバラバラに増やすのではなく、状態マシン（ステートと遷移表）として明示的に設計する。
- 処理を小さなステップの直列パイプラインに分解し、「1ステップ1責務」で組み合わせると、全体の流れも追いやすくなる。
💡AIワンポイント
線形原理では、AIが深いネストを作ったらガード節へ置き換えます。分岐条件を述語関数へ分離すると読み筋が一本になります。関連用語（用語集で復習）
3.35 ７つの設計原理⑥明証原理（Clarity Principle）
要旨
読んだ人が「見た瞬間に、ロジックの正しさを納得できる」ような、明快なコードを書くことを重視する原理。理由
コードは一度書いたら、何度も何度も読み返されるもの。読みやすさを保てるかどうかが、そのまま保守性＝品質とつながっていくから。結論
ロジックの根拠や考え方を、コードそのもの・コメント・図や文書などを使って示す。コードだけでは伝わりにくい「なぜ（Why）」「いつ・どこで・誰が（5W1H）」は、コメントや別資料で補っていく。その他（実践・範囲）
- 単機能な関数、1ステップ1責務、意味のある命名、トリッキーなワザの封印（読み手を驚かせない）。
- 不変条件・前提条件・事後条件（契約）・アサーションを明文化し、「どんなときにこの関数は正しいのか」をはっきりさせる。
- 境界値・例外系・時刻やロケールなどのハマりやすいポイントは、コメントやテストケースにしっかり落とし込む。
- サンプルコードやテストコードを、動く仕様書（Executable Specification）として添えると理解がぐっと楽になる。
💡AIワンポイント
明証原理の実践として、AIが導入した式の前提条件をテスト名に書き込みます。数式だけ正しくても、適用条件が不明だと誤用されます。関連用語（用語集で復習）
3.36 ７つの設計原理⑦安全原理（Safety Principle）
要旨
「そんなことは起こらないだろう」と決めつけず、起こり得る異常系もちゃんと想定したうえで、安全側に倒れる設計・実装を行う原理（if の else や switch の default をサボらない）。理由
実運用では、想定外の入力・バグ・外部要因などが必ず起きる。それを放置すると、データ破壊・サービス停止・セキュリティ事故など、大きなトラブルに繋がってしまうから。結論
フェールセーフ（安全側に倒す）・フェールソフト（一部機能を落としてでも全体を守る）・フォールトトレランス（障害に耐える）という考え方を設計に織り込み、中断・ロールバック・リトライなどを組み合わせて「もっとも安全なふるまい」を選ぶ。その他（実践・効果）
- if には基本的にelseを用意し、switch にはdefaultを用意する。ループには上限カウンタやタイムアウトを設定して、無限ループを防ぐ。
- 入力値の検証・サニタイズ（危険な部分を無害化）、タイムアウト設定、再試行＋冪等(べきとう＝ある操作を何回行っても結果は同じ)な設計、サーキットブレーカ(障害を一定回数検知すると即時エラーを返す)、トランザクションとロールバックなどで、安全側への退避ルートを用意する。
- エラーが起きたときにどうするか（処理を続ける／縮退運転に切り替える／即停止して大きく通知する）というエラー方針を、ドメインに照らして決めておく。
- 最小権限（権限を必要最低限に絞る）・確実なリソース解放・監視とアラートなどで、万が一のときも被害を最小限に抑える。
- 例：DBエラーが起きたとき、「そのまま継続」「ひたすらリトライ」「いったんロールバックして中断」という選択肢を比較し、そのシステムにとって本当に安全な選択を設計段階で決めておく。
💡AIワンポイント
安全原理では、AI生成のdefault分岐に監視通知を入れます。未知値を黙殺せず、ログとメトリクスで早期検知できる形にします。関連用語（用語集で復習）
プリンシプル オブ プログラミング(第３章－7つの設計原理)
1. 【3.33．７つの設計原理④『階層原理』③】
2. 【3.30．7つの設計原理①『単純原理』⑤】
単純原理における「シンプルさ」の考え方として正しいのはどれか？
解説： 単純原理は「**他者が読んで理解できる構造であること**」が重要。チーム開発では特にこの考え方が価値を持つ。
3. 【3.36．７つの設計原理⑦『安全原理』①】
『安全原理』における基本的な設計姿勢として正しいものはどれか？
解説： 『安全原理』では、「起こらないはず」の状況にも備える設計姿勢が重要。例外や想定外の状態にも対処すべきである。
4. 【3.33．７つの設計原理④『階層原理』②】
次のうち、階層原理に従った構造設計の例として適切なのはどれか？
解説： **各責任に応じて層を分離することで、全体構造を俯瞰しやすくなり、再利用性や保守性が高まる**。これは階層原理の典型的な実践例である。
5. 【3.29．７つの設計原理①】
『単純原理（Simplicity Principle）』において最も重視すべき設計姿勢はどれか？
解説： 単純原理は「**必要以上に複雑な設計を避け、理解しやすく保つ**」という考え方。過剰な抽象化や凝りすぎた設計は避けるべき。
6. 【3.33．７つの設計原理④『階層原理』④】
階層原理の考えに基づく設計上の行動として最も適切なものはどれか？
解説： 階層原理では、**上位構造から見下ろす形で全体を俯瞰し、関係性を整理したうえで、下位構成を明確にする**ことが求められる。
7. 【3.36．７つの設計原理⑦『安全原理』⑤】
『安全原理』の実践によって得られる最も重要な効果はどれか？
解説： 安全原理の本質は「異常事態に備えること」にある。これにより障害時の影響が最小限に抑えられ、システム全体の信頼性が向上する。
8. 【3.34．７つの設計原理⑤『線形原理』①】
『線形原理』において最も重視すべき観点はどれか？
解説： 『線形原理』では、処理の流れを上から下へ素直に通すことに重点を置く。過度な状態遷移や複雑な分岐は保守性を下げる原因となる。
9. 【3.31．7つの設計原理②『同型原理』①】
API群の引数順として“同型性”を最も満たしているのはどれか？
解説： 同じ責務の API 群では引数の並びを統一する。id→payload の順で統一（または payload→id で統一）するのが同型性。
10. 【3.31．7つの設計原理②『同型原理』⑤】
同一ドメインの DTO 群における同型性の観点で“最も適切”なのはどれか？
解説： 同一ドメインのオブジェクト群では共通フィールドの順序と命名を統一することで可読性・保守性を高める。
参考文献・出典
- プリンシプル オブ プログラミング ～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/とろとろみかん
詳しいプロフィールはこちら！ もちもちみかんのプロフィール
