1. 【2.7．名前は最重要②】
命名の質を高めるために効果的とされる手法はどれか？
解説： 「ループバックチェック」は、命名後にその意味を説明できるかどうかを検証するプロセスであり、命名の妥当性を高めるのに役立つ。
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とは、同じことを何度も書かないという原則。コードのコピペも、コードをそのまま言い換えただけのコメントの重複も避ける。理由
同じ内容があちこちにあると、どれが最新か分からなくなり、読む人も直す人も迷う。どこか１か所を直し忘れると、テスト漏れや不具合につながる。結論
抽象化（共通部分を１つにまとめること）によって重複を減らし、「１か所直せば全体がそろう」構造にする。その他（手段と適用範囲）
- ループ化／関数化／モジュール化で処理を分解し、最小の部品にまとめる。
（モジュール：部品としてまとめたファイルやクラスなど） - DRYはビルド／テスト／デプロイなどの工程にも使える。
ビルド（プログラムをまとめて実行形式にする作業）／デプロイ（本番環境に反映すること）も、同じ流れは共通化・自動化して、人の手作業を減らす。
- ループ化／関数化／モジュール化で処理を分解し、最小の部品にまとめる。
💡AIワンポイント
DRYはコードだけでなくプロンプトにも効きます。共通制約を毎回書く代わりに、チェック関数やテンプレートテストへ寄せると重複修正を防げます。AIは似た処理を別名で増やしがちなので、同義関数の棚卸しを定例化します。
2.3 YAGNI（You Aren't Going to Need It.）
要旨
「多分いつか必要」と思って入れた機能は、多くの場合実際には使われない。今ほんとうに必要なものだけ実装する。理由
将来を心配して機能を盛り込みすぎると、使われないコードと余計な複雑さが増える。読む人もテストする人も大変になり、バグの可能性も上がる。結論
現時点の要件に集中し、「必要になったとき」にそのときのコストを払って追加する。今をシンプルに保つことで、結果的にあとからの変更にも強いコードになる。その他（実践のコツ）
- 将来の拡張に備えて余地（差し替えやすい形）は残しても、今いらない分岐や設定を増やして複雑さまで先取りしない。
- 何でも対応できるようにしすぎる過剰な汎用化や、まだ必要ないのに処理を軽くしようとする早すぎる最適化は避ける。（KISS / DRY と合わせて考える）
💡AIワンポイント
YAGNIの観点では、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）
要旨
コードは新しい機能の追加には開いていて、既存コードの書き換えには閉じているのが理想、という原則。理由
ソフトウェアは想定より長く使われ、次々に変更や追加が入る。そのとき毎回広い範囲を直していては、安全性（バグが出ないか）と作業コストの両方が厳しくなる。結論
インターフェース／抽象（共通の窓口や考え方）をしっかり決め、その境界の外側に新しい実装を「差し込む」形にする。むやみに抽象を増やさず、必要最小限でシンプルさも保つ。その他（適用指針・割り切り・戦略）
境界設計
ポリモーフィズム（同じ呼び出しで中身だけ変えられる仕組み）やDI（Dependency Injection）（依存性の注入：使う部品を外から渡すこと）、プラグイン方式などで、新しい機能はできるだけ追加で入れられるようにする。割り切り
最初から完璧な抽象を目指すとやり過ぎになりがち。まずは少し素直な実装で始めて、同じような変更が２回目・３回目と続いたところで、はじめてOCPを意識した構造に整える。関連原則
クラス化やカプセル化（中身を隠して外からは決められた操作だけさせること）で、影響範囲をできるだけ小さく閉じ込める。
💡AIワンポイント
OCPを使う場面では、新方式追加時に既存分岐を編集しない形をAIに指定します。戦略インターフェースと実装クラス追加で完了するかを受け入れ条件にします。
2.7 名前重要（Name is important）
AIで差が出る ★★★★AI核心原則
要旨
命名はとても重要。名前は読み手にとってのUI（ユーザーインターフェース：人がふれる窓口）であり、そのものの意味を一瞬で伝えるラベルになる。理由
よい名前は、「このコードは何をするのか」「どんな値なのか」といった仕様理解を直接助ける。結果として、誤解・やり直し・修正コストを大きく減らせる。結論
まず仕様（何を実現したいか）をしっかり理解し、その理解から名前を決めてコードを書く。書いたあとに読み返し、名前と中身が本当に合っているかを何度も見直す。その他（実践ポイント）
- 説明 → 命名 → 説明に戻ってチェック（ループバックチェック）というループを回す。（言葉で説明した内容と、付けた名前がズレていないかを確認する）
- その分野で普通に使われているドメイン（ビジネス領域）の言葉に合わせて命名する。一貫した用語を使い、あいまいな単語や意味の分からない略語は控える。
- 名前には意図と約束も含める。（例：単位・範囲・前提条件などが分かるようにする）
💡AIワンポイント
名前重要の実践として、AIに命名案を複数出させるならドメイン用語辞書を先に渡します。API名とDBカラム名の語彙がずれるとバグより先に会話が壊れます。略語は最小にし、別の意味を持つ既存語への上書き命名を避けます。
プリンシプル オブ プログラミング(第２章：原則)
1. 【2.7．名前は最重要②】
2. 【2.1．KISS（Keep It Simple, Stupid.）④】
KISS原則に従った適切な開発姿勢として最もふさわしいものはどれか？
解説： KISS原則では「今、実際に必要な要件」を「できるだけシンプルに」満たすことが重要であり、不必要な技術や拡張は避けるべきとされる。
3. 【2.2．DRY（Don't Repeat Yourself.）②】
DRY原則における「重複排除」の主な手段として適切でないものはどれか？
解説： DRY原則ではコードの重複を避けることが目的であり、コメントは補足のために使うものであって、重複排除の手段とはならない。
4. 【2.4．PIE（Program Intently and Expressively.）①】
PIE原則における「意図を明確に表現するコード」が重要とされる主な理由はどれか？
解説： PIEは「人にとって読みやすいコードを書く」ことを重視し、読み手が意図を正しく理解できるように、コードを明快に表現することを推奨している。
5. 【2.3．YAGNI（You Aren't Going to Need It.）②】
YAGNI違反によって起きやすい問題はどれか？
解説： 将来のために実装したコードが実際には使われないことは多く、コードベースが不要に複雑化し、理解・修正・テストの負担が増す。
6. 【2.5．SLAP（Single Level of Abstraction Principle.）⑤】
次のうち、SLAP原則に反するコード構造はどれか？
解説： SLAPでは、抽象度の異なる処理が1つの関数に混在することは避けるべきであり、適切に委譲・分離しておくことで構造の整合性が保たれる。
7. 【2.3．YAGNI（You Aren't Going to Need It.）④】
YAGNI原則の精神として最も近いものはどれか？
解説： YAGNIは「You Aren't Going to Need It.（それは必要にならない）」の略で、今の要件にのみ集中し、将来の可能性には過剰に備えない方針を指す。
8. 【2.3．YAGNI（You Aren't Going to Need It.）⑤】
YAGNIと矛盾しない設計上の配慮はどれか？
解説： YAGNIは「今は実装しない」が原則だが、「将来的な拡張の余地（柔軟性）」を構造として残すことは、矛盾しない設計的配慮である。
9. 【2.2．DRY（Don't Repeat Yourself.）⑤】
次のうち、DRY原則をコード以外に適用する事例として最も適切なものはどれか？
解説： DRY原則はコードだけでなくプロセスにも適用される。手作業による繰り返しを避け、スクリプト化などで共通処理を自動化することが重要である。
10. 【2.1．KISS（Keep It Simple, Stupid.）①】
KISS原則に基づいた設計判断として最も適切なものはどれか？
解説： KISS原則では「現在の要件に必要なものだけ」を「できるだけ単純な方法で」実装することが推奨される。将来の予測や余計な工夫は避ける。
参考文献・出典
- プリンシプル オブ プログラミング ～3年目までに身につけたい一生役立つ101の原理原則～
- 上田 勲（著）／秀和システム／第1版14刷／2025年／ISBN978-4-7980-4614-3
※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。
このページの著者
もちもちみかん（システムエンジニア）
社内SEとしてグループ企業向けの業務アプリを要件定義〜運用まで一気通貫で担当しています。
経験：Webアプリ／業務システム
得意：PHP・JavaScript・MySQL・CSS
個人実績：フォーム生成基盤／クイズ学習プラットフォーム 等
詳しいプロフィールはこちら！ もちもちみかんのプロフィール
