1. 【2.5．SLAP（Single Level of Abstraction Principle.）③】
SLAP原則の実践として「1つのステートメントには1つのことだけを書く」理由として最も適切なのはどれか？
解説： 短く明快なステートメントは、意図の把握を容易にし、変更やバグ修正時の影響範囲も限定しやすくなるため、保守性が高まる。
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.5．SLAP（Single Level of Abstraction Principle.）③】
2. 【2.7．名前は最重要④】
以下のうち、命名の誤りとして最も悪影響が大きいものはどれか？
解説： 名前が実際の処理と一致していない場合、コードの誤解・バグ・保守性低下など重大な問題を引き起こす可能性がある。
3. 【2.6．OCP（Open-Closed Principle）②】
OCPの実践例として最も適切なものはどれか？
解説： インターフェースや抽象クラスを使った設計により、コードの拡張が可能になりつつ、安定している既存コードへの直接修正を避けられる。
4. 【2.1．KISS（Keep It Simple, Stupid.）③】
KISS原則において「Less is more」が示す本質的な意味は何か？
解説： 「Less is more」は、機能やコードの量を絞り込むことで、逆に本質が明確になり、理解・保守・品質が向上するというKISSの核心を表す。
5. 【2.3．YAGNI（You Aren't Going to Need It.）⑤】
YAGNIと矛盾しない設計上の配慮はどれか？
解説： YAGNIは「今は実装しない」が原則だが、「将来的な拡張の余地（柔軟性）」を構造として残すことは、矛盾しない設計的配慮である。
6. 【2.7．名前は最重要③】
命名に必要なスキルとして最も適切なものはどれか？
解説： 命名には、仕様を正しく理解する力と、それに基づいた直感的な命名を行うセンスが必要である。
7. 【2.5．SLAP（Single Level of Abstraction Principle.）④】
SLAPに基づいたコード構成の説明として、正しいものはどれか？
解説： SLAPでは、関数の中身がすべて同じレベルの抽象度で書かれていることが重要であり、階層の上下関係を守ることで構造が明確になる。
8. 【2.5．SLAP（Single Level of Abstraction Principle.）⑤】
次のうち、SLAP原則に反するコード構造はどれか？
解説： SLAPでは、抽象度の異なる処理が1つの関数に混在することは避けるべきであり、適切に委譲・分離しておくことで構造の整合性が保たれる。
9. 【2.4．PIE（Program Intently and Expressively.）⑤】
コードとコメントが矛盾していた場合、PIEの観点から最も適切な対応はどれか？
解説： PIEでは「人が読む」ことを前提に、コードが意図（What/How）を明快に表現している状態を優先する。非自明な選択や背景（Why）は、最新の事実に合わせてコメントで補完する。
10. 【2.5．SLAP（Single Level of Abstraction Principle.）②】
SLAP原則に従う場合、関数内で避けるべき行動はどれか？
解説： 抽象化の階層構造を守ることがSLAPの基本であり、下位層や異なる抽象度の関数を直接呼び出すと構造が崩れ、可読性が損なわれる。
参考文献・出典
- プリンシプル オブ プログラミング ～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/とろとろみかん
詳しいプロフィールはこちら！ もちもちみかんのプロフィール
