1. 【3.17．アーキテクチャ根底技法⑥『充足性・完全性・プリミティブ性』⑤】
以下のうち、『充足性・完全性・プリミティブ性』をすべて**欠いている可能性が高い**モジュールはどれか？
解説： 複数の異なる責務や機能が混在した巨大なモジュールは、情報が冗長になりやすく、**抽象の質が低下**しやすい。充足性・完全性・プリミティブ性のいずれも損なう可能性がある。
AI共創の土台、10の設計技法をクイズで習得！
第3章：思想｜アーキテクチャ根底技法
公開日：
最終更新日：
AIが実装を加速しても、設計の骨格は人間が決めます。本ページでは、『プリンシプル オブ プログラミング』第3章「アーキテクチャ根底技法」で紹介される、アーキテクチャ設計の土台となる10の設計技法を、要約と4択クイズで身につけます。
要約で「何のための技法か」を押さえ → 4択クイズ（10問・全問解説付き）で使いどころを確認 → 迷ったところは解説で復習。「読む→解く→わかる」で、AI共創でもブレない設計の道具箱を増やしましょう。
3-2：AI共創の土台、10の設計技法クイズ！ 目次
-
3-2：AI共創の土台、10の設計技法クイズ！の要点・要約を読む(5分)
- 3.11 アーキテクチャ根底技法（Architecture core techniques）
- 3.12 抽象（abstraction）
- 3.13 カプセル化（Encapsulation）
- 3.14 情報隠蔽（Information Hiding）
- 3.15 パッケージ化（Packaging）
- 3.16 関心の分離（Separation of Concerns）
- 3.17 充足性・完全性・プリミティブ性（Sufficiency / Completeness / Primitiveness）
- 3.18 ポリシーと実装の分離（Separation of Policy and Implementation）
- 3.19 インターフェースと実装の分離（Separation of Interface and Implementation）
- 3.20 参照の一点性（Single Point of Reference）
- 3.21 分割統治（Divide and Conquer）
- クイズに挑戦する(10問)
- プログラミング クイズ一覧へ
- 第3章：思想とセオリーの全体像をつかむ！ 目次へ
- 次のクイズへ(3-3：AIが苦手な非機能要件クイズ！)
- 前のクイズへ(3-1：AIを導くセオリーをクイズで定着！)
- 『プリンシプル オブ プログラミング』101の原理・原則総まとめ
第３章：思想②
～アーキテクチャ根底技法～
3.11 アーキテクチャ根底技法（Architecture core techniques）
要旨
良いコードや設計を支える土台となる考え方（基礎原理のセット）をチームで共有し、どんな場面でも迷いにくい共通の判断基準にする。理由
この基礎原理を共有しておくと、誰が設計しても、複雑さのコントロール・再利用のしやすさ・変更のしやすさに一貫性が生まれ、プロダクト（製品）全体の質がそろいやすくなるから。結論
これらの原理を、プロダクト（製品）共通のチェックリストとして扱い、設計やコードレビューのときに「ちゃんと守れているか？」を確認する道具として使う。その他（基礎原理リスト）
- 抽象（abstraction）…本質だけを取り出して「分かりやすい概念」にまとめる。
- カプセル化（Encapsulation）…関連するデータと処理を1つのまとまりとして包む。
- 情報隠蔽（Information Hiding）…中身の細かい構造は隠し、外側には最小限の情報だけ見せる。
- パッケージ化（Packaging）…モジュールを意味ごとにグループ分けし、整理する。
- 関心の分離（Separation of Concerns）…役割ごとにコードを分け、混ざらないようにする。
- 充足性、完全性、プリミティブ性（Sufficiency, Completeness, Primitiveness）…「十分・漏れなし・純粋」な抽象にする。
- ポリシーと実装の分離（Separation of Policy and Implementation）…「何をするか」と「どうやるか」を分ける。
- インターフェースと実装の分離（Separation of Interface and Implementation）…「使い方」と「中身」を分ける。
- 参照の一点性（Single Point of Reference）…同じことは1か所で定義し、何度も書かない。
- 分割統治（Divide and Conquer）…大きな問題を小さく分割してから解いていく。
3.12 アーキテクチャ根底技法①抽象（abstraction）
AI核心原則
要旨
ごちゃごちゃした現実から、共通して大事な部分だけを取り出して「1つの概念」としてまとめること。これにより、モジュール同士の役割や境界をはっきり区別できる。理由
良い抽象は、ムダな情報をそぎ落としつつ、使いやすい形にまとまっているので、いろいろな場面で広く再利用できるし、考えるときも「この抽象として捉えればいい」となり、思考がスッキリするから。結論
本質に関係ない細かさは思い切って捨て（捨象）、抽象の境界に対して分かりやすい名前と契約（どう振る舞うべきか）を与える。その他（実践）
- 「捨てる勇気」を持つ：めったに使わない特殊ケースや、細かすぎる属性・分岐は抽象から外し、共通部分に集中する。
- ドメイン（業務・問題領域）の言葉で境界に名前をつけ、抽象に対して契約テスト（「この抽象はこう振る舞うはず」というテスト）を用意しておく。
💡AIワンポイント
抽象を作る時は、AIに具体実装を二つ仮置きして共通面だけ残します。実例なしの抽象名は意味が広すぎて、後で契約が崩れます。抽象語が増えたら、禁止事項と非責務も同時に書いて境界を固定します。
3.13 アーキテクチャ根底技法②カプセル化（Encapsulation）
AI重要 ★★★★★
要旨
強く関係しているデータとロジックを、1つのモジュールの中にまとめて包み込むこと（外側からはひとまとまりとして扱えるようにする）。理由
バラバラに置いておくと、関係ないものが紛れ込んだり、あちこちから勝手に触られたりして全体が分かりづらくなる。カプセル化しておけば、見通しがよくなり、変更の影響もそのモジュール内部に閉じ込めやすくなるから。結論
関係の強い要素（データ＋処理）を同じモジュールにグルーピングし、その中で完結するように設計することで、変更範囲と影響範囲を分かりやすくする。その他（たとえ・効果）
- 例：じゃがいも・にんじん・玉ねぎなどの材料を、その都度「カレー用」「シチュー用」とバラバラに扱うのではなく、「野菜セット」という単位でカプセル化しておけば、カレーにもシチューにも肉じゃがにも使い回しやすくなる。
- 効果：コードの見やすさ／影響範囲の局所化／変更のしやすさが向上する。
💡AIワンポイント
カプセル化では、AIが直接フィールド更新を広げていないかを見ます。状態変更はメソッド経由に寄せ、検証ロジックを一箇所に閉じ込めます。
3.14 アーキテクチャ根底技法③情報隠蔽（Information Hiding）
要旨
モジュールの中身の細かいしくみはできるだけ外から見えないように隠し、外側からは最低限のインターフェースだけで扱えるようにする。理由
外から何でも見えて何でも触れてしまうと、使う側も覚えることが増え、全体のつながりが複雑になる。情報隠蔽を徹底すると、やり取りする情報がシンプルになり、システム全体の複雑さを下げられるから。結論
外に公開するのは利用に本当に必要な部分だけに絞り、実装の細部は隠しておくことで、あとから中身を変えても外側との約束（インターフェース）は守れる余地を残す。その他（指針）
- モジュールの利用者には、「どう使えばよいか」が分かる情報だけを渡し、それ以上の内部事情は見せない。
- モジュールの実装者には必要な内部情報を見せてよいが、その情報を外部に漏らさないよう設計する。
💡AIワンポイント
情報隠蔽を守るなら、AIが返すオブジェクトから内部IDや管理用フラグを外します。公開APIは利用者の判断に必要な項目だけに絞るのが安全です。
3.15 アーキテクチャ根底技法④パッケージ化（Packaging）
要旨
たくさんのモジュールを、意味のある単位でまとめてグループ化し、「この束は何を担当するのか」が分かるように整理すること。理由
モジュールが増えてくると、そのままでは「森の中で木を見ている」状態になってしまう。関連したものを1つのパッケージとして束ねると、全体像がつかみやすくなり、複雑さを下げられるから。結論
まずは小さなモジュールを作りながら、徐々に関連の強いもの同士をボトムアップに集合化してパッケージにまとめ、開発が進むにつれてパッケージ構造も成長・整理していく。その他（位置づけ）
- モジュール化…1つ1つの機能や責務に注目した、ミクロな複雑性の削減。
- パッケージ化…モジュール群をどうグループ分けするかという、マクロな複雑性の削減。
💡AIワンポイント
パッケージ化では、AI生成ファイルを機能単位で置き直してからレビューします。レイヤーと業務概念が混ざる配置は、探索コストを毎日増やします。
3.16 アーキテクチャ根底技法⑤関心の分離（Separation of Concerns）
要旨
「画面表示」「データ保存」「ログ」「認証」など、性質や目的が違う関心ごとを、きちんと別々のモジュールに分けておき、できるだけ混ざらないようにする。理由
実際の変更は「画面を変えたい」「保存方法を変えたい」のように、関心ごと単位で起こることが多い。あらかじめ分離しておけば、その関心に関係するところだけを直せば済むから。結論
役割が違うものはきちんと分ける（例：MVC＝Model-View-Controllerなど）。「どこにでも顔を出す共通処理」（ログ、エラー処理など）のような横断的関心事は、AOP（＝Aspect Oriented Programming）などで別枠に切り出す。その他（例）
- DBとのやり取り（永続化）／UI（見せ方）／その間をつなぐ処理（アプリケーションロジック）を分離する。
- 本体の処理と、ログや監視の処理を分離しておき、必要に応じてあとから差し込める形にしておく。
💡AIワンポイント
関心の分離として、AIにUI表示文言と業務判定を同居させないよう指定します。翻訳修正でビジネスロジックを触る構造は事故率が高いです。
3.17 アーキテクチャ根底技法⑥充足性・完全性・プリミティブ性（Sufficiency, Completeness, Primitiveness）
要旨
モジュールが表す抽象は、充足性（やりたいことを十分に表せているか）、完全性（必要な機能に漏れがないか）、プリミティブ性（余計な合成が混じっておらず、素の操作になっているか）を満たしているべき、という考え方。理由
充足性が足りないと「やりたいことがこのモジュールでは表しきれない」状態になる。完全性が足りないと「結局ここにも別の処理を足さないといけない」となり使いづらい。プリミティブ性がないと、操作がごちゃごちゃして再利用しづらくなる。結論
モジュールの抽象を見直し、提供する関数やメソッドのセットが十分・漏れなし・純粋になっているかを確認する。余計な機能や例外的操作が混ざっている場合は、別モジュールに切り出したり削除したりして整理する。その他（判断基準の再掲）
充足性
このモジュールを使えば、その抽象がやりたいことを一通り表現できるか？完全性
本来その抽象が持つべき機能を取りこぼしていないか？プリミティブ性
操作が混ぜ込み料理のようになっていないか？もっと小さく素の操作に分けられないか？
💡AIワンポイント
充足性とプリミティブ性では、AI提案APIの最小操作集合を見直します。似た意味の関数が多い時は、責務の切り方が曖昧な合図です。
3.18 アーキテクチャ根底技法⑦ポリシーと実装の分離（Separation of Policy and Implementation）
要旨
「ポリシー」＝ビジネスルールや前提条件にもとづいた「どの選択肢を選ぶか」という決めごと と、「実装」＝前提に依存しない汎用的な処理ロジックを、同じモジュールの中にごちゃまぜにしない。理由
ポリシー（ビジネスルール側）は状況の変化で変わりやすく、実装（一般的なロジック側）は比較的安定しやすい。ここを混ぜてしまうと、ポリシーを変えたいだけなのに実装まで巻き込まれて、再利用しづらくなり、変更も重くなるから。結論
ポリシーと実装を別々のモジュールとして切り分け、設定ファイル・DI（Dependency Injection＝依存性注入）・戦略パターンなどを使って連携させる。その他（範囲・効果）
ポリシーモジュール
前提条件・ビジネスロジック・選択ルールなどを持つ部分。実装モジュール
前提に依存しない、汎用的な処理ロジック。ポリシーは引数やインターフェースとして注入して使う。- 効果：ポリシー変更の影響を局所化できる／テストしやすくなる／他プロジェクトへの流用もしやすくなる。
💡AIワンポイント
ポリシーと実装の分離では、しきい値や判定基準をAIに設定層へ逃がさせます。数値をロジックへ直書きすると、運用調整のたびに再ビルドが発生します。
3.19 アーキテクチャ根底技法⑧インターフェースと実装の分離（Separation of Interface and Implementation）
要旨
モジュールには、「インターフェース＝使い方の約束（どんなメソッドがあり、どんな引数・戻り値か）」と、「実装＝その中でどう動いているか」という2つの面がある。利用側はインターフェースだけに依存し、実装には直接依存しないようにする。理由
インターフェースと実装を分けることで、公開する面がシンプルになり、使う人にとって理解しやすくなる。また、実装は裏側で自由に改良・最適化できるので、差し替えやバージョンアップに強くなる。結論
「インターフェースに対してプログラムし、実装に対してではない」という原則を徹底する。利用側のコードから、具体クラスや中身の詳細に直接べったり依存する書き方を避ける。その他（範囲・効果）
- インターフェースは契約、実装はその契約を満たすための隠れた仕組みと考えると分かりやすい。
- テストでは、インターフェースを基準にした契約テストと、具体的な実装についてのユニットテストを組み合わせることで、安心して差し替えられる構造を作れる。
💡AIワンポイント
インターフェース分離の実践として、AIが具象クラス名を呼び出し側に書いていたら止めます。依存先を契約型に固定すると差し替え検証が短時間で済みます。
3.20 アーキテクチャ根底技法⑨参照の一点性（Single Point of Reference）
要旨
1つの情報や定義は必ず1か所だけに置き、何度もコピーして書かない。また、変数にはできるだけ一度だけ代入し、その後は変更しないようにする（単一代入）。理由
同じ情報が複数箇所にあると、どこか1つだけ更新し忘れたときに不整合やバグを生む。再代入や共有の書き換えが多いと、「いつ・どこで値が変わったのか」を追うのが大変になり、バグの温床になるから。結論
同じ意味の情報は1か所に集約し、変数の再代入を避けて、できるだけ参照透過な関数（同じ入力なら必ず同じ結果が返り、副作用がない関数）と不変なデータを中心に設計する。その他（概念整理）
単一代入
変数には一度だけ値を入れ、その後は書き換えないスタイル。値を変えたいときは、新しい変数として扱う。参照透過性
- ① 関数の戻り値が引数だけに依存して決まる（隠れた状態を使わない）。
- ② 関数を呼び出しても、他の部分の動作に副作用を与えない（グローバル変数の書き換えなどをしない）。
💡AIワンポイント
参照の一点性では、AI生成コードの共有可変状態を疑います。再代入が多い処理はテストが不安定になるため、不変データと戻り値中心へ寄せます。
3.21 アーキテクチャ根底技法⑩分割統治（Divide and Conquer）
要旨
一度に解くには大きすぎて複雑な問題を、解きやすい小さな問題に分割し、それぞれを解いてから組み合わせて全体を解決する、という考え方。理由
大きな問題をそのまま眺めていても、全体が複雑すぎて最適解にたどり着きにくい。分割統治を使って、問題を小さく区切ることで、見通しがよくなり、並列作業もしやすくなり、検証もしやすくなるから。結論
問題の粒度（大きさ）を調整しながら、「ここまでなら1人で理解できる」「ここまでなら1回でテストできる」と感じるサイズまで分割し、それぞれを各個撃破してから、結果を組み合わせて全体を完成させる。その他（適用例）
- 全体設計：システム全体を、それぞれ独立して設計できる部分に分ける。
- モジュール設計：1つの巨大なクラスではなく、責任や役割ごとにモジュールを分ける。
- アルゴリズム：大きな処理を、より小さいサブ問題に分けてボトムアップに解いていく。
- 大量データ処理：データを小さい単位に分割し、分散処理や並列処理を検討する。
- 補足：「まず外側をざっくり固めてから、内側を順に細かくしていく」ようなアプローチも、分割統治の一種と考えてよい。
💡AIワンポイント
分割統治では、AIへの依頼を入力検証、計算、整形の三段に分けると精度が上がります。問題を細かく切るほどレビュー観点も明確になります。
プリンシプル オブ プログラミング(第３章－アーキテクチャ根底技法)
1. 【3.17．アーキテクチャ根底技法⑥『充足性・完全性・プリミティブ性』⑤】
2. 【3.14．アーキテクチャ根底技法③『情報隠蔽』②】
情報隠蔽を適切に行うことで得られる**主な効果**として不適切なものはどれか？
解説： 内部構造を公開しすぎると他モジュールとの結合度が高まり、再利用性・保守性が損なわれる。隠蔽により変更の影響範囲を限定できる。
3. 【アーキテクチャ根底技法⑥】
『充足性・完全性・プリミティブ性』に関する記述として適切なものはどれか？
解説： 『充足性・完全性・プリミティブ性』は、過不足なく必要な機能を持ち、かつシンプルで明快な構成を保つことを意味する。
4. 【3.14．アーキテクチャ根底技法③『情報隠蔽』①】
『情報隠蔽』の主な目的として最も適切なものはどれか？
解説： 情報隠蔽は、モジュールの内部実装を外部に晒さず、必要な最小限の情報だけを公開することで、複雑性の低減や柔軟性の向上を実現する。
5. 【3.14．アーキテクチャ根底技法③『情報隠蔽』③】
次のうち、情報隠蔽の原則に**最も反する設計**はどれか？
解説： すべてを公開する設計は、モジュールの内部に強く依存する構造を招き、情報隠蔽の考えに反する。
6. 【3.13．アーキテクチャ根底技法②『カプセル化』⑤】
カプセル化を適切に行うことで得られる**設計上の効果**として最も適切なものはどれか？
解説： カプセル化されたモジュールは、内部の実装が他から隔離されているため、変更が外部に波及しづらくなり、保守性が向上する。
7. 【3.15．アーキテクチャ根底技法④『パッケージ化』④】
次の説明のうち、『パッケージ化』に該当する設計行為はどれか？
解説： 『パッケージ化』とは、意味や機能の近いモジュールをグループ化し、全体構造を整理・簡素化することを指す。
8. 【3.20．アーキテクチャ根底技法⑨『参照の一点性』②】
『参照の一点性』の実現がもたらす効果として**最も適切なもの**はどれか？
解説： 『参照の一点性』を守ると**副作用がなくなり、関数の動作が予測しやすくなる**ため、テストやバグ修正がしやすくなる。
9. 【3.15．アーキテクチャ根底技法④『パッケージ化』③】
パッケージ化を設計する際の**望ましい方針**として適切でないものはどれか？
解説： パッケージ化は初期設計で終わらせず、変化に応じて継続的に進化させることが重要である。構成の固定は柔軟性を損なう。
10. 【3.18．アーキテクチャ根底技法⑦『ポリシーと実装の分離』①】
『ポリシーと実装の分離』において、「ポリシー」とは主にどのような役割を担うか？
解説： ポリシーとは、**処理の方針やビジネスルール、引数の選定**などを定義する部分であり、アプリケーション固有の前提に基づいて判断を行う役割を持つ。
参考文献・出典
- プリンシプル オブ プログラミング ～3年目までに身につけたい一生役立つ101の原理原則～
- 上田 勲（著）／秀和システム／第1版14刷／2025年／ISBN978-4-7980-4614-3
※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。
このページの著者
もちもちみかん（システムエンジニア）
社内SEとしてグループ企業向けの業務アプリを要件定義〜運用まで一気通貫で担当しています。
経験：Webアプリ／業務システム
得意：PHP・JavaScript・MySQL・CSS
個人実績：フォーム生成基盤／クイズ学習プラットフォーム 等
詳しいプロフィールはこちら！ もちもちみかんのプロフィール
