1. 【3.5．６つの原則①『結果の局所化』⑤】
結果の局所化を高めるための有効な方法として最も適切なものはどれか？
解説： 機能の分離や役割の明確化により、1つの変更が他に影響しないよう設計することが「結果の局所化」の鍵である。
AIを導くセオリーをクイズで定着！
第3章：思想｜プログラミングセオリー
公開日：
最終更新日：
AIに設計を任せるほど、まず必要になるのは「何を価値として守るか」という判断軸です。本ページでは、『プリンシプル オブ プログラミング』第3章「プログラミングセオリー」で語られる3つの価値と、それを支える6つの原則を、要約と4択クイズで整理します。
要約でセオリーの全体像をつかみ → 4択クイズ（10問・全問解説付き）で腕試し → 迷ったところは解説で復習。「読む→解く→わかる」で、AI生成コードの品質を支える思考プロセスを定着させていきましょう。
3-1：AIを導くセオリーをクイズで定着！ 目次
-
3-1：AIを導くセオリーをクイズで定着！の要点・要約を読む(5分)
- 3.1 プログラミングセオリー（Programming theory）
- 3.2 ３つの価値①：コミュニケーション（Communication）
- 3.3 ３つの価値②：シンプル（Simplicity）
- 3.4 ３つの価値③：柔軟性（Flexibility）
- 3.5 ６つの原則①：結果の局所化（Local consequences）
- 3.6 ６つの原則②：繰り返しの最小化（Minimize repetition）
- 3.7 ６つの原則③：ロジックとデータの一体化（Logic and Data together）
- 3.8 ６つの原則④：対称性（Symmetry）
- 3.9 ６つの原則⑤：宣言型の表現（Declarative Expression）
- 3.10 ６つの原則⑥：変更頻度（Rate of Change）
- クイズに挑戦する(10問)
- プログラミング クイズ一覧へ
- 第3章：思想とセオリーの全体像をつかむ！ 目次へ
- 次のクイズへ(3-2：AI共創の土台、10の設計技法クイズ！)
- 前のクイズへ(第2章：AIコードを見抜く「原則」クイズ！)
- 『プリンシプル オブ プログラミング』101の原理・原則総まとめ
第３章：思想①
～プログラミングセオリー～
3.1 プログラミングセオリー（Programming theory）
要旨
「最高のコード」とは、拡張しやすく、ムダが少なく、読みやすく、理解しやすいコードのこと。その土台になる考え方が「セオリー（理論・考え方の枠組み）」で、3つの価値（コミュニケーション／シンプル／柔軟性）を大事にしている。理由
「大事にしたい価値」→「守るべき原則」→「具体的なコード」というつながりをはっきりさせておくと、読みやすさ・拡張しやすさなどの品質と、日々の「この書き方でいいかな？」という細かい判断を結びつけやすくなるから。結論
3つの価値をスタート地点（動機）にして、6つの原則を中継地点（考え方のルール）として使い、最終的にコードという形の解決策に落とし込んでいく。その他（範囲・効果・構成要素）
3つの価値（Three values）
- コミュニケーション（Communication）…人に意味が伝わることを重視する。
- シンプル（Simplicity）…ムダな複雑さを削ることを重視する。
- 柔軟性（Flexibility）…あとから変えやすいことを重視する。
6つの原則（Six principles）
- 結果の局所化（Local consequences）…変更の影響を狭い範囲に閉じ込める。
- 繰り返しの最小化（Minimize repetition）…同じことを何度も書かない。
- ロジックとデータの一体化（Logic and Data together）…処理とデータを近くにまとめる。
- 対称性（Symmetry）…同じ種類のものは同じパターンで書く。
- 宣言型の表現（Declarative Expression）…「どうやるか」より「何をしたいか」を書く。
- 変更頻度（Rate of Change）…同じ理由・同じタイミングで変わるもの を同じ場所に集める。
関連用語（用語集で復習）
3.2 ３つの価値①コミュニケーション（Communication）
要旨
コードはコンピュータに命令するためのものであると同時に、人に見せるドキュメント（説明書）＝コミュニケーションの道具でもある。理由
開発にかかるコストの多くは、新規開発よりも保守（あとから直したり追加したりする作業）で発生する。そこで、他の人（＝未来の自分も含む）がコードを読みやすいかどうかが、作業の速さ・バグの少なさにそのまま効いてくるから。結論
常に「他の人はこのコードを見てどう感じるだろう？」を想像し、読みやすさと意図（Why）が伝わることを最優先にする。その他（効果・実践）
💡AIワンポイント
コミュニケーション重視なら、AI生成PRには変更意図と非採用案を必ず添えます。コードだけより、判断理由がある方が将来の修正判断が速くなります。関連用語（用語集で復習）
3.3 ３つの価値②シンプル（Simplicity）
要旨
ここで言う「シンプル」とは、機能を削ることではなく、必要以上の複雑さを取り除いた状態のこと。動かすために必要な最小限で設計する。理由
余計な複雑さは、ユーザーにとっても開発者にとってもあまり価値を生まず、バグ・読みづらさ・話が通じにくくなる原因になりやすいから。結論
本当に必要な部分（玉）を見きわめて取り出し、不要な部分（石）は勇気を持って捨てる設計を徹底する。「毒をもって毒を制す」のように、「一時しのぎのパッチを何枚も当てる」ようなコードでごまかすのではなく、根本原因を直してシンプルにすることを優先する。その他（範囲・指針）
💡AIワンポイント
シンプルの価値を守るには、AI提案から副作用の多い便利関数を除去します。入力と戻り値が追える純粋関数へ寄せると、挙動確認が一気に楽になります。関連用語（用語集で復習）
3.4 ３つの価値③柔軟性（Flexibility）
要旨
柔軟性とは、あとから変更しやすいかどうかという性質。コードは最初から完成ではなく、変わり続ける前提で書くべきもの。理由
現実の要求や環境は常に変化するので、コードも必ずどこかで変更が入る。そこで、変更しやすさ（変更容易性）が、長期的な品質（壊れにくさ・続けやすさ）を大きく左右するから。結論
「拡張には開き、既存の修正には閉じる」というOCP（Open-Closed Principle）の考え方を意識する。関係が深いコードは近くにまとめ、関係が薄い部分同士は、できるだけ依存しないように設計する。その他（効果・実践）
💡AIワンポイント
柔軟性を狙うなら、AIに変更予定の高い箇所だけ抽象化させます。滅多に変わらない部分まで抽象化すると、読みにくさだけが残ります。関連用語（用語集で復習）
3.5 ６つの原則①結果の局所化（Local consequences）
要旨
1か所を直したときに、その影響ができるだけ小さい範囲（局所）の中でおさまるようにコードを組み立てる考え方。理由
変更の影響が広いと、「ここを直したら、あっちもこっちも動かなくなった…」という状態になり、テストも修正も爆発的に大変になってしまうから。結論
「修正に対して閉じる」（OCP）の考えを取り入れ、変更は特定のモジュールの中だけで完結させられるように設計する。その他（指針・効果）
- 指針
- 一緒に変わりやすいコード同士は、近くにまとめて配置する。
- 1つのモジュールの責務（役割）を明確にしておく。
- モジュールの境目（インターフェース）では、責任の範囲をはっきり分ける。
- 効果：回帰バグが減る／レビュー・テストの「見るべき場所」を絞りやすい／リリース時のリスクが下がる。
- 指針
💡AIワンポイント
結果の局所化では、AIが提案した修正の影響ファイル数を計測して判断します。影響が広いなら境界が漏れているので、先に責務分割を入れてから機能追加します。関連用語（用語集で復習）
3.6 ６つの原則②繰り返しの最小化（Minimize repetition）
要旨
同じ意味や同じ処理を何度も書かないようにする原則。1か所を変えれば、関連するところがまとめて変わる構造（DRY原則）を目指す。理由
同じ内容があちこちにバラバラに書かれていると、「結果の局所化」が壊れてしまい、変更のたびに修正漏れや不整合（片方だけ直し忘れなど）が起きやすくなるから。結論
コードを小さい部品に分解して整理し、共通する部分は1つにまとめて再利用する。その他（手段）
- ループ化／関数化／モジュール化で、処理を「最小の意味のかたまり」に分ける（数式の素因数分解のイメージ）。
- よく使うパターンは、テンプレートやコード生成、ライブラリとして切り出し、コピペではなく再利用する。
💡AIワンポイント
繰り返し最小化の観点では、似たテストデータ生成をAIにまとめさせると効果が大きいです。fixtureビルダーを作れば仕様変更時の修正点が一箇所に集まります。関連用語（用語集で復習）
3.7 ６つの原則③ロジックとデータの一体化（Logic and Data together）
要旨
処理の流れ（ロジック）と、その処理が扱うデータを、できるだけ近い場所（同じ関数・同じモジュールなど）にまとめておく。理由
実際の変更では、ロジックだけ・データだけが変わることは少なく、多くの場合「データの形」と「それをどう扱うか」がセットで変わる。離れた場所にあると、修正漏れやズレが起きやすくなるから。結論
関連するロジックとデータを物理的に近く（コロケーション）に置き、データの近くにそのデータ用の処理を持たせる（カプセル化）ようにする。その他（実践）
- 特定のデータ型に対しては、そのデータに関するメソッド（操作）を一緒に持たせる。
- 関連するデータとロジックの集まりを、1つのモジュールやクラスとして扱う。
- DTO（Data Transfer Object＝データの入れ物）や生データをアプリ全体にバラまくのではなく、境界部分で専用の型や構造に変換してから内部で使う。
💡AIワンポイント
ロジックとデータの一体化として、AI生成の変換ロジックをDTO近くへ寄せます。別層に散ると仕様変更時にマッピング漏れが起きやすくなります。関連用語（用語集で復習）
3.8 ６つの原則④対称性（Symmetry）
3.9 ６つの原則⑤宣言型の表現（Declarative Expression）
要旨
コードでは、できるだけ「どうやるか」より「何をしたいか」を中心に書く（命令型より宣言型のスタイルを選ぶ）。理由
命令型（「まずAをして、そのあとBをして…」のような書き方）は、順番・分岐・状態を頭の中で追いかけないと理解しづらい。一方、宣言型は「こういう条件を満たすデータがほしい」のように、事実そのものを読む感覚で理解しやすいから。結論
使える場面では積極的に宣言的な記述やデータ駆動（設定で動作を変えるスタイル）を取り入れ、意図が一目で分かるコードを目指す。その他（手段）
💡AIワンポイント
宣言型を活かすなら、AIに分岐ロジックをルールテーブルへ落とさせます。if連鎖より設定差分でレビューできる形の方が誤りを見つけやすいです。関連用語（用語集で復習）
3.10 ６つの原則⑥変更頻度（Rate of Change）
要旨
「なぜ変えるのか（変更理由）」と「どのタイミングで変わるのか」が同じもの同士を、同じ場所に集めておくという考え方。理由
1つのモジュールが、いくつも違う理由でしょっちゅう変更されていると、そのモジュールは壊れやすく、設計も分かりづらいものになっていくから。結論
単一責任の原則（1モジュール＝1つの変更理由）に従って配置し、モジュール同士はできるだけ疎結合に保つことで、「何のためのモジュールか」を明確にする。その他（実践・効果）
- 実践：
- 頻繁に変わる部分（例：画面や文言）と、あまり変わらない部分（例：ドメインルール）を別レイヤーに分ける。
- 設定値・定数・メッセージなど「一括で変えたいもの」は、専用の場所に集約する。
- 効果：同じファイルを複数人で編集して衝突することが減る／どこを直せばいいか分かりやすい／変更にかかる時間を見積もりやすくなる。
- 実践：
💡AIワンポイント
変更頻度で分けるなら、AIに直近で頻繁に変わる設定値をコード外へ退避させます。毎回リリースが必要な設計は、運用負荷の増幅点になります。関連用語（用語集で復習）
プリンシプル オブ プログラミング(第３章－プログラミングセオリー)
1. 【3.5．６つの原則①『結果の局所化』⑤】
2. 【3.1．プログラミングセオリー④】
「無駄を削ぎ落とした簡潔な構造」に関係する価値はどれか？
解説： 「シンプル」は、構造を簡潔に保ち、理解・保守・バグ修正を容易にする価値である。
3. 【3.7．６つの原則③『ロジックとデータの一体化』①】
『ロジックとデータの一体化』とは、どのような設計指針を指すか？
解説： 『ロジックとデータの一体化』とは、処理（ロジック）と対象データを同じ関数やモジュール内に配置することで、修正時の影響範囲を把握しやすくする原則である。
4. 【3.1．プログラミングセオリー⑧】
「処理」と「それが扱うデータ」を近くに置くことで得られる利点はどれか？
解説： 「ロジックとデータの一体化」は、構造を明快にし、理解や修正をしやすくする。
5. 【3.7．６つの原則③『ロジックとデータの一体化』④】
ロジックとデータの距離が離れていると、どのような問題が起こりやすいか？
解説： ロジックとデータが離れていると、どのデータがどの処理に関与しているかが把握しづらくなり、修正や保守の際に不具合を招く原因になる。
6. 【3.8．６つの原則④『対称性』①】
『対称性』の原則が目指す主な効果はどれか？
解説： 『対称性』により、「同じ種類の処理は同じように書かれている」ことで、読み手がコードの意図や構造を直感的に把握しやすくなる。
7. 【3.4．３つの価値③『柔軟性』②】
柔軟性のあるコードを設計する上で**特に意識すべき原則**はどれか？
解説： OCP（拡張に対して開かれ、修正に対して閉じている設計）は、柔軟なコードの中核となる原則である。
8. 【3.7．６つの原則③『ロジックとデータの一体化』②】
『ロジックとデータの一体化』を実践する主な理由はどれか？
解説： コードを修正する際、ロジックとその対象データが同時に変更されることが多く、それらを近くに置くことで修正漏れや不整合を防ぎやすくなる。
9. 【3.1．プログラミングセオリー⑥】
「副作用の影響範囲を最小限に抑える」原則はどれか？
解説： 「結果の局所化」は、副作用による影響範囲を狭め、バグ発見や修正を容易にする原則である。
10. 【3.5．６つの原則①『結果の局所化』④】
結果の局所化が実現されたコードの特徴として**適切でないもの**はどれか？
解説： 影響が広がる設計は「結果の局所化」が実現できておらず、保守性を著しく損なう。
参考文献・出典
- プリンシプル オブ プログラミング ～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/とろとろみかん
詳しいプロフィールはこちら！ もちもちみかんのプロフィール
