1. 【2.1．KISS（Keep It Simple, Stupid.）④】
KISS原則に従った適切な開発姿勢として最もふさわしいものはどれか？
解説： KISS原則では「今、実際に必要な要件」を「できるだけシンプルに」満たすことが重要であり、不必要な技術や拡張は避けるべきとされる。
AIコードの良し悪しをクイズで見抜く！
プリンシプル オブ プログラミング 第2章：原則
公開日：
最終更新日：
AI生成コードの時代は、「書ける」より「良し悪しを判断できる」が価値になります。本ページでは、『プリンシプル オブ プログラミング』第2章「原則」で紹介される7つの設計原則（DRY, KISS など）を、要点を押さえた要約と4択クイズで定着させます。
要約で原則の狙いをつかみ → 4択クイズ（10問・全問解説付き）で判断基準をチェック → ひっかかった点は解説で復習。「読む→解く→わかる」で、AIコードをレビュー・改善できる良い設計の軸を身につけましょう。
第2章：AIコードを見抜く「原則」クイズ！ 目次
- プログラミング クイズ一覧へ
- 次のクイズへ(第3章：AIに差をつける設計「思想」クイズ！)
- 前のクイズへ(第1章：AI時代の「前提」をクイズで速習！)
- 『プリンシプル オブ プログラミング』101の原理・原則総まとめ
第２章：原則
～プログラミングのガイドライン～
2.1 KISS（Keep It Simple, Stupid.）
AI重要 ★★★★★AI核心原則
要旨
KISSとは、「とにかくシンプルに」という考え方である。できるだけ少ない部品と考え方で作り、必要なことだけをやる。理由
その場しのぎで機能を足していくと、ルールがバラバラになり、コードがごちゃごちゃして読みづらくなる。結果として、バグが増えたり直すのが大変になったりする。結論
まずは最小限の構成で設計・実装する。「足すより削る」を意識して、余計な分岐・設定・機能を持ち込まないことで、品質（分かりやすさ・直しやすさ）を守る。その他（指針）
- 新技術の無理な導入はしない。（「流行っているから」という理由だけでは入れない）
- 今いらない機能は今は書かない。（多くは本当に使われないままになる）
- プログラマが勝手に要件を盛らない。（「あったら便利そう」だけで仕様を増やさない）
- Less is more（レス・イズ・モア：少ないほど良いという考え方）。
- オッカムの剃刀（必要以上に多くの前提を持ち込むべきではない、という考え方）。
💡AIワンポイント
KISSでは、まず入出力が通る最短実装だけAIに作らせます。最初の提案にある補助クラスや設定階層が不要なら、その場で削ってから採用します。過剰抽象化が混ざったら、具体ユースケース1件で説明できる形まで戻します。
2.2 DRY（Don't Repeat Yourself.）
AI重要 ★★★★AI核心原則
要旨
DRYとは、同じことを何度も書かないという原則。コードのコピペも、コードをそのまま言い換えただけのコメントの重複も避ける。理由
同じ内容があちこちにあると、どれが最新か分からなくなり、読む人も直す人も迷う。どこか１か所を直し忘れると、テスト漏れや不具合につながる。結論
抽象化（共通部分を１つにまとめること）によって重複を減らし、「１か所直せば全体がそろう」構造にする。その他（手段と適用範囲）
💡AIワンポイント
DRYはコードだけでなくプロンプトにも効きます。共通制約を毎回書く代わりに、チェック関数やテンプレートテストへ寄せると重複修正を防げます。AIは似た処理を別名で増やしがちなので、同義関数の棚卸しを定例化します。
2.3 YAGNI（You Aren't Going to Need It.）
要旨
「多分いつか必要」と思って入れた機能は、多くの場合実際には使われない。今ほんとうに必要なものだけ実装する。理由
将来を心配して機能を盛り込みすぎると、使われないコードと余計な複雑さが増える。読む人もテストする人も大変になり、バグの可能性も上がる。結論
現時点の要件に集中し、「必要になったとき」にそのときのコストを払って追加する。今をシンプルに保つことで、結果的にあとからの変更にも強いコードになる。その他（実践のコツ）
- 将来の拡張に備えて余地（差し替えやすい形）は残しても、今いらない分岐や設定を増やして複雑さまで先取りしない。
- 何でも対応できるようにしすぎる過剰な汎用化や、まだ必要ないのに処理を軽くしようとする早すぎる最適化は避ける。（KISS / DRY と合わせて考える）
💡AIワンポイント
2.4 PIE（Program Intently and Expressively.）
AI核心原則
要旨
コードは人が読む文章でもある。コンピュータに命令するだけでなく、読む人に意図がはっきり伝わる書き方を目指す。理由
誰かがコードを正しく理解して初めて、安全な変更ができるから。ただしコードが示せるのは主にWhat（何をするか）とHow（どうやるか）であり、Why（なぜそうするか）は書かないとすぐに忘れられてしまう。結論
読みやすさ最優先でコードを書く。コード本体でできるだけ誤解を減らし、Why（設計理由や背景）はコメントや補足資料（ドキュメント）で補う。その他（実践ポイント）
- 意味が分かりやすい名前、似たものは同じ形にそろえた構造、短い文・小さな関数を心がける。
- コメントには意図・前提条件・トレードオフを書く。コードに書いてあることをそのまま繰り返すコメント（DRY違反）は書かない。
💡AIワンポイント
PIEを守るなら、AI生成コードの曖昧な変数名を先に直します。tmp や data2 を放置すると、次の修正で誤読が増えてレビューコストが跳ねます。文脈が抜けた命名は誤実装の温床なので、入力・出力・責務が見える語へ寄せます。
2.5 SLAP（Single Level of Abstraction Principle.）
要旨
１つの関数やブロックの中では、できるだけ同じ高さの話だけを書く。ざっくりした説明と細かい処理をごちゃまぜにしない。理由
抽象度（どれくらいざっくり書くかのレベル）がそろっていると、コードをひと目で要約しやすくなり、流れも追いやすくなるから。結論
プログラムを文章や本のように構造化し、上のレベルの関数は下のレベルの関数だけを呼ぶようにする。（横からの呼び出しや、下から上への「逆流」は避ける）その他（指針）
序章
プログラム全体の目的や前提を書くコメント。目次
関数やクラスの一覧など、外形を先に示す部分。セクション
関連するモジュールのまとまり。（モジュール：部品の集まり）章
各関数。１つの「役割」を担当する。段落
関数の中のコードブロック（処理のかたまり）。文
ステートメント（１行の命令）。なるべく１文１つの役割にする。呼び出し規律
基本は「上 → 下」方向だけを呼び出す。横や上方向への直接呼び出しは、構造を分かりにくくするので最小限にする。これはモジュール同士の疎結合（ゆるいつながり）を保つ助けにもなる。
💡AIワンポイント
SLAPでは、同じ関数内に業務判断と配列操作が混ざっていないかを見ます。AIが混在させたら、上位は手順、下位は詳細処理へ分離してください。
2.6 OCP（Open-Closed Principle）
要旨
コードは新しい機能の追加には開いていて、既存コードの書き換えには閉じているのが理想、という原則。理由
ソフトウェアは想定より長く使われ、次々に変更や追加が入る。そのとき毎回広い範囲を直していては、安全性（バグが出ないか）と作業コストの両方が厳しくなる。結論
インターフェース／抽象（共通の窓口や考え方）をしっかり決め、その境界の外側に新しい実装を「差し込む」形にする。むやみに抽象を増やさず、必要最小限でシンプルさも保つ。その他（適用指針・割り切り・戦略）
💡AIワンポイント
OCPを使う場面では、新方式追加時に既存分岐を編集しない形をAIに指定します。戦略インターフェースと実装クラス追加で完了するかを受け入れ条件にします。
2.7 名前重要（Name is important）
AIで差が出る ★★★★AI核心原則
要旨
命名はとても重要。名前は読み手にとってのUI（ユーザーインターフェース：人がふれる窓口）であり、そのものの意味を一瞬で伝えるラベルになる。理由
よい名前は、「このコードは何をするのか」「どんな値なのか」といった仕様理解を直接助ける。結果として、誤解・やり直し・修正コストを大きく減らせる。結論
まず仕様（何を実現したいか）をしっかり理解し、その理解から名前を決めてコードを書く。書いたあとに読み返し、名前と中身が本当に合っているかを何度も見直す。その他（実践ポイント）
- 説明 → 命名 → 説明に戻ってチェック（ループバックチェック）というループを回す。（言葉で説明した内容と、付けた名前がズレていないかを確認する）
- その分野で普通に使われているドメイン（ビジネス領域）の言葉に合わせて命名する。一貫した用語を使い、あいまいな単語や意味の分からない略語は控える。
- 名前には意図と約束も含める。（例：単位・範囲・前提条件などが分かるようにする）
💡AIワンポイント
名前重要の実践として、AIに命名案を複数出させるならドメイン用語辞書を先に渡します。API名とDBカラム名の語彙がずれるとバグより先に会話が壊れます。略語は最小にし、別の意味を持つ既存語への上書き命名を避けます。
プリンシプル オブ プログラミング(第２章：原則)
1. 【2.1．KISS（Keep It Simple, Stupid.）④】
2. 【2.5．SLAP（Single Level of Abstraction Principle.）②】
SLAP原則に従う場合、関数内で避けるべき行動はどれか？
解説： 抽象化の階層構造を守ることがSLAPの基本であり、下位層や異なる抽象度の関数を直接呼び出すと構造が崩れ、可読性が損なわれる。
3. 【2.2．DRY（Don't Repeat Yourself.）①】
DRY原則に違反している例として最も適切なものはどれか？
解説： DRY原則では「同じ情報やロジックは1箇所にしか存在してはならない」とされており、同じコードのコピー＆ペーストは典型的な違反例である。
4. 【2.1．KISS（Keep It Simple, Stupid.）⑤】
次の記述のうち、KISS原則違反となる可能性が最も高い行動はどれか？
解説： KISS原則では「今必要でないものは今書くべきではない」とされており、将来のための不要なコード追加は典型的な違反例となる。
5. 【2.6．OCP（Open-Closed Principle）④】
次のうち、OCPに反している設計はどれか？
解説： 条件分岐を増やす方法は、既存コードの変更を伴うためOCPに違反している。拡張性のある構造に切り替えるべきである。
6. 【2.7．名前は最重要①】
プログラミングにおいて「命名」が最重要とされる主な理由は何か？
解説： 命名はコードを読む人にとってのUIであり、意図や仕様を不可逆的に伝える重要な役割を持つため、最も重要な設計要素の一つとされる。
7. 【2.3．YAGNI（You Aren't Going to Need It.）③】
次のうち、YAGNI原則に従った適切な対応はどれか？
解説： 「今本当に必要なものだけを実装し、必要になったらそのときに書く」というのがYAGNIの核心である。
8. 【2.7．名前は最重要④】
以下のうち、命名の誤りとして最も悪影響が大きいものはどれか？
解説： 名前が実際の処理と一致していない場合、コードの誤解・バグ・保守性低下など重大な問題を引き起こす可能性がある。
9. 【2.6．OCP（Open-Closed Principle）②】
OCPの実践例として最も適切なものはどれか？
解説： インターフェースや抽象クラスを使った設計により、コードの拡張が可能になりつつ、安定している既存コードへの直接修正を避けられる。
10. 【2.2．DRY（Don't Repeat Yourself.）③】
「DRY原則を破ると、テスト漏れが発生しやすくなる」とされる理由として最も適切なものはどれか？
解説： 同じロジックが複数に分散して存在すると、修正漏れやテスト漏れが発生しやすくなり、結果として品質の低下を招く。
参考文献・出典
- プリンシプル オブ プログラミング ～3年目までに身につけたい一生役立つ101の原理原則～
- 上田 勲（著）／秀和システム／第1版14刷／2025年／ISBN978-4-7980-4614-3
※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。
このページの著者
もちもちみかん（システムエンジニア）
社内SEとしてグループ企業向けの業務アプリを要件定義〜運用まで一気通貫で担当しています。
経験：Webアプリ／業務システム
得意：PHP・JavaScript・MySQL・CSS
個人実績：フォーム生成基盤／クイズ学習プラットフォーム 等
詳しいプロフィールはこちら！ もちもちみかんのプロフィール
