『プリンシプル オブ プログラミング』7つの設計原理を10問で学べるクイズサイト

AIリファクタの軸、7つの設計原理をクイズで習得！
第3章：思想｜7つの設計原理

公開日：
最終更新日：

AIリファクタの時代は、直し方より「何を軸に直すか」が大事です。本ページでは、『プリンシプル オブ プログラミング』第3章「7つの設計原理」で紹介される、変更に強い設計のための7つの原理を、要点を押さえた要約と4択クイズで整理します。

要約で原理の狙いをつかみ → 4択クイズ（10問・全問解説付き）で判断基準を確認 → 迷ったところは解説で復習。「読む→解く→わかる」で、将来の仕様変更にも振り回されにくい設計の軸を定着させましょう。

今すぐクイズに挑戦
（10問・約3分・解説つき）
プリンシプルオブプログラミング
AI時代を生き抜く「101の設計原則」

3-4：AIリファクタの軸、7つの設計原理クイズ！ 目次

  1. 3-4：AIリファクタの軸、7つの設計原理クイズ！の要点・要約を読む(5分)
    1. 3.29 ７つの設計原理（Seven design principles）
    2. 3.30 単純原理（Simplicity Principle）
    3. 3.31 同型原理（Isomorphism Principle）
    4. 3.32 対称原理（Symmetry Principle）
    5. 3.33 階層原理（Hierarchy Principle）
    6. 3.34 線形原理（Linearity Principle）
    7. 3.35 明証原理（Clarity Principle）
    8. 3.36 安全原理（Safety Principle）
  2. クイズに挑戦する(10問)
  1. プログラミング クイズ一覧へ
  2. 第3章：思想とセオリーの全体像をつかむ！ 目次へ
  3. 次のクイズへ(3-5：AI×普遍の知恵、UNIX思想クイズ！)
  4. 前のクイズへ(3-3：AIが苦手な非機能要件クイズ！)
  5. 『プリンシプル オブ プログラミング』101の原理・原則総まとめ
  1. 参考文献・出典
  2. このページの著者
  3. シェア

第３章：思想④
～７つの設計原理～

3.29 ７つの設計原理（Seven design principles）

  • 要旨

    バグを生み込みにくい設計にするための７つの重要な視点を、チームで共有された「共通のものさし」として使い、設計やレビューの考え方を揃えていこう、という考え方。

  • 理由

    人によって見るポイントがバラバラだと、レビューの指摘内容も毎回変わってしまい、品質が安定しない。共通の原理を持っておけば、「何を良しとするか」が揃い、レビューの軸もぶれにくくなるから。

  • 結論

    ここで挙げる７つの原理を、設計する時の規範やレビューのチェック項目として採用し、チェックリストにして日常的に使う。

  • その他（範囲・効果）

    • 原理一覧
      • 単純原理（Simplicity Principle）
      • 同型原理（Isomorphism Principle）
      • 対称原理（Symmetry Principle）
      • 階層原理（Hierarchy Principle）
      • 線形原理（Linearity Principle）
      • 明証原理（Clarity Principle）
      • 安全原理（Safety Principle）
    • 期待できる効果例レビューの質と再現性が上がる／暗黙知だった「感覚」が言葉になる／欠陥の早期発見や、そもそもの作り込み防止につながる。

3.30 ７つの設計原理①単純原理（Simplicity Principle）

  • 要旨

    とにかく常にシンプルさを大事にし、パッと見て筋道が追える、自然で分かりやすいコードを書くことを目指す原理。

  • 理由

    バグはたいてい、複雑でごちゃごちゃしたコードに集中しがちだから。シンプルさは「バグの入りづらさ」とほぼ直結している。

  • 結論

    かっこいいテクニックや一発芸的な書き方よりも、単純・まっすぐ・必要最小限を優先する。「これ以上足しても得が少ない」というところで止める。

  • その他（実践）

    • 意味のない抽象化や分岐を削る／1つの文には1つの意味だけ（1ステップ1責務）。
    • 名前を見ただけで役割が分かるような意図の伝わる命名を心がける。
    • 「まず動くいちばん小さな形」を基準にし、複雑な仕掛けは本当に必要だと分かったときだけ後から足す（計測結果や要件の裏付けがあるとき）。

  • 💡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ワンポイント

    対称原理では、作成操作を足したら取り消し操作のテストケースまでAIに作らせます。回復経路が設計段階で欠けると運用が詰みます。

3.33 ７つの設計原理④階層原理（Hierarchy Principle）

  • 要旨

    コードを階層（レイヤ）構造で整理し、「上位→下位」の関係をはっきりさせる原理。

  • 理由

    階層に分けておくと、「大づかみで全体像を見る」と「細部を読む」を行き来しやすくなり、理解もしやすいし、変更もしやすくなるから。

  • 結論

    大分類→中分類→小分類（セクション→章→段落→文）のような階層で構造化し、上位レベルのコードからは下位レベルを外側から見た視点（インターフェース単位）で扱う。

  • その他（実践）

    • コードをざっくりマップにすると：
      • セクション：モジュールやコンポーネントの集合。
      • 章：個々の関数やメソッド。
      • 段落：関数内のブロック（ifブロックなど）。
      • 文：1つ1つのステートメント。
    • 上位の層から下位の層を呼び出すのはOKだが、横方向への依存や、下位から上位への逆流依存はできるだけ避ける（依存の向きは一方向）。

  • 💡AIワンポイント

    階層原理を守るには、AI提案コードで上位層が下位実装詳細を参照していないか確認します。DTO変換やSQL文字列が上位へ漏れたら分離し直します。

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.36．７つの設計原理⑦『安全原理』③】
『安全原理』の思想に基づく対策として不適切なものはどれか？

2. 【3.31．7つの設計原理②『同型原理』③】
複数画面に同一“メールアドレス”入力がある。最も同型性を守っているのはどれか？

3. 【3.31．7つの設計原理②『同型原理』④】
エラーコード体系の“同型性”として最も適切なのはどれか？

4. 【3.34．７つの設計原理⑤『線形原理』⑤】
次のうち、『線形原理』に基づいた設計上の推奨事項として最も適切なものはどれか？

5. 【3.36．７つの設計原理⑦『安全原理』①】
『安全原理』における基本的な設計姿勢として正しいものはどれか？

6. 【3.34．７つの設計原理⑤『線形原理』①】
『線形原理』において最も重視すべき観点はどれか？

7. 【3.30．7つの設計原理①『単純原理』③】
次のうち『単純原理』に反するコードの例はどれか？

8. 【3.29．７つの設計原理③】
『対称原理（Symmetry Principle）』を最も適切に説明しているのはどれか？

9. 【3.31．7つの設計原理③『対称原理』②】
次のうち『命名における対称性』の例として適切なのはどれか？

10. 【3.33．７つの設計原理④『階層原理』②】
次のうち、階層原理に従った構造設計の例として適切なのはどれか？

次のクイズ(3-5：AI×普遍の知恵、UNIX思想クイズ！)へ

7つの設計原理
採点結果

正答率：0%

-

-

参考文献・出典

  • プリンシプル オブ プログラミング ～3年目までに身につけたい一生役立つ101の原理原則～
  • 上田 勲（著）／秀和システム／第1版14刷／2025年／ISBN978-4-7980-4614-3

※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。

このページの著者

もちもちみかん（システムエンジニア）

社内SEとしてグループ企業向けの業務アプリを要件定義〜運用まで一気通貫で担当しています。

経験：Webアプリ／業務システム

得意：PHP・JavaScript・MySQL・CSS

個人実績：フォーム生成基盤／クイズ学習プラットフォーム 等

詳しいプロフィールはこちら！　　もちもちみかんのプロフィール

もちもちみかん0系くん
TOPへ

もちもちみかん.comとは


このサイトでは、コーディングがめんどうくさい人向けのお助けツールとして、フォームやCSSをノーコードで生成できる、
　もちもちみかん.forms
　もちもちみかん.css1
　もちもちみかん.css2
と言ったジェネレーターを用意してます。

また、このサイトを通じて、「もちもちみかん」のかわいさを普及したいとかんがえてます！