---
title: 設計原則と普遍的な判断軸
tags:  #設計  
author: [yonekubo / アーキテクトの教科書](https://docswell.com/user/tyonekubo)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/GE89V3QY7D.jpg?width=480
description: 勉強会「AI×設計入門 〜設計原則とドメイン駆動開発で見つける次のステップ〜」での登壇資料 https://wake-career.connpass.com/event/371091/
published: October 29, 25
canonical: https://docswell.com/s/tyonekubo/ZQXJG3-design-principles
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/GE89V3QY7D.jpg)

設計原則と
普遍的な判断軸
Takeshi Yonekubo
Oct. 29, 2025
AI×設計入門 〜設計原則とドメイン駆動開発
で見つける次のステップ〜


# Page. 2

![Page Image](https://bcdn.docswell.com/page/LELW5VX9JR.jpg)

About Me
米久保 剛 (よねくぼ たけし)
ITアーキテクトとして自社プロダクト
開発業務をリード
最近は組織のアーキテクティングに興味
『アーキテクトの教科書』（翔泳社）
X: @tyonekubo
note: https://note.com/yonekubo


# Page. 3

![Page Image](https://bcdn.docswell.com/page/4JM93GLVEW.jpg)

本日お話すること
よい設計をするために、
大事にすべきこと


# Page. 4

![Page Image](https://bcdn.docswell.com/page/PJRGQZKWE9.jpg)

SOLID原則
DRY原則
KISS原則
Tell, Don’t Ask原則
..and more
設計原則


# Page. 5

![Page Image](https://bcdn.docswell.com/page/PEXX59LVEX.jpg)

なぜ設計原則は大事なのか？
良い設計とは何なのか？
そもそも設計とは何なのか？


# Page. 6

![Page Image](https://bcdn.docswell.com/page/3EKW6PL5ED.jpg)

ユーザーとソフトウェア
ユーザーにとって、ソフトウェアはブラックボックス
ソフトウェア
ユーザー
振る舞い
例）
ラーメン屋を検索する
品質特性
例）
1秒以内に応答が返る


# Page. 7

![Page Image](https://bcdn.docswell.com/page/L7316X31J5.jpg)

開発者とソフトウェア
振る舞い（機能適合性）と、その他の品質特性が
要求を満たしてさえいればOKだろうか？
ソフトウェア
ユーザー
開発者
振る舞い
例）
ラーメン屋を検索する
品質特性
例）
1秒以内に応答が返る


# Page. 8

![Page Image](https://bcdn.docswell.com/page/87DXV24KEG.jpg)

ソフトウェアの宿命
ソフトウェアが使用され続ける限り、
変更を受け入れなければならない。
妥当なコストと、スピードで。


# Page. 9

![Page Image](https://bcdn.docswell.com/page/VJPPV1M3J8.jpg)

生成AIは？
実用的・大規模なソフトウェアを、長期間にわたって
保守し続けることは、現世代の生成AIには難しい
ソフトウェア
生成AI
振る舞い
品質特性


# Page. 10

![Page Image](https://bcdn.docswell.com/page/2EV2ZY9NEQ.jpg)

開発者がソフトウェア設計を主導する
生成AIを活用するにしても、完全にブラックボックス化
されない以上、人間（開発者）がソフトウェアの
内部構造の設計を主導する必要がある
ソフトウェア
開発者
振る舞い
品質特性


# Page. 11

![Page Image](https://bcdn.docswell.com/page/57GR49Z5EL.jpg)

分割
ソフトウェア設計の基本は、分けること
一枚岩のプログラム
分割されたプログラム
振る舞い
振る舞い
提供する振る舞いは変わらないなら、なぜ分割するの？


# Page. 12

![Page Image](https://bcdn.docswell.com/page/4EQVGWLLJP.jpg)

分割理由① 認知容量の問題
大きすぎるものは
人間の脳にとって
認知負荷が高すぎる
Divide and Concur
分割して統治せよ


# Page. 13

![Page Image](https://bcdn.docswell.com/page/KJ4M5KD5E1.jpg)

分割理由② 能力の獲得
分割によって生まれる
構造と（要素同士の）相互作用が
振る舞い以上の力を与える
たとえば、
✓理解容易性
✓テスト容易性
✓拡張性


# Page. 14

![Page Image](https://bcdn.docswell.com/page/LE18WXZ27G.jpg)

どのように分割するのか？


# Page. 15

![Page Image](https://bcdn.docswell.com/page/GEWZ6N92E2.jpg)

ソフトウェア設計はネットワーク型システム
ネットワーク型システムにおける成長のダイナミクス:
リニア／スーパーリニア／サブリニア
出典 『ソフトウェア設計の結合バランス』 図12.2
https://book.impress.co.jp/books/1124101149


# Page. 16

![Page Image](https://bcdn.docswell.com/page/47Z1Y394J3.jpg)

ソフトウェア設計の成長のダイナミクス
機能：線形成長 知識：サブリニア成長
複雑性：スーパーリニア成長 認知的限界：成長なし
出典 『ソフトウェア設計の結合バランス』 図12.6
https://book.impress.co.jp/books/1124101149


# Page. 17

![Page Image](https://bcdn.docswell.com/page/YJ6LDXKGEV.jpg)

人間の認知能力を基準に
システムの形状を適応させる
※生成AI（LLM）もコンテキスト長の制限がある


# Page. 18

![Page Image](https://bcdn.docswell.com/page/GJ513XPX74.jpg)

認知負荷
脳内のワーキングメモリの容量は限られており、
認知負荷が大きいとオーバーフローを起こす
→課題外在性負荷（偶有的複雑さ）を減らすこと
対象そのものが本質的に持つ
課題内在性負荷
複雑さによる認知負荷
対象とは直接関係しない、
課題外在性負荷
外的要因による認知負荷
学習のための認知活動で発生する
学習関連負荷
負荷


# Page. 19

![Page Image](https://bcdn.docswell.com/page/LE316X3475.jpg)

まずい設計
あちこちソースを見て、直さないといけないのは
それだけで認知負荷が高い
変更


# Page. 20

![Page Image](https://bcdn.docswell.com/page/8EDXV245JG.jpg)

まずい設計
変更の影響が波及したり・・・
変更


# Page. 21

![Page Image](https://bcdn.docswell.com/page/V7PPV1MD78.jpg)

まずい設計
見落としてしまったり・・・
変更


# Page. 22

![Page Image](https://bcdn.docswell.com/page/2JV2ZY9GJQ.jpg)

望ましい設計
同じ変更理由で修正するコンポーネントをなるべく
少なく、近くに集めたい（局所化）
変更


# Page. 23

![Page Image](https://bcdn.docswell.com/page/5EGR494DJL.jpg)

原理と原則
原理は、普遍的、根本的な理（ことわり）
原則は、原理によって導かれる、共通的な決まり


# Page. 24

![Page Image](https://bcdn.docswell.com/page/4JQVGWGX7P.jpg)

設計原理
「CLEAN」：5つのコード品質
Cohesive
Loosely Coupled
Encapsulated
Assertive
Nonredundant
{ 設計原理 }
凝集性
高凝集
❷
疎結合
疎結合
❸
カプセル化
抽象化
❹
断定的
関心の分離
❶
非冗長
非冗長
❺
出典：David Scott Bernstein『レガシーコードからの脱却』オライリー(2019) をもとに作成


# Page. 25

![Page Image](https://bcdn.docswell.com/page/K74M5K52J1.jpg)

設計原理❶ 関心の分離
大きなもの、複雑なものをそのまま取り扱わない
まずは関心事によって分離する
観点の例：
✓業務、ユースケース
✓手続き、ビジネスルール
✓種別、区分
✓利用者（アクター）
✓抽象度（方針と詳細）


# Page. 26

![Page Image](https://bcdn.docswell.com/page/LJ18WXWKEG.jpg)

設計原理❷ 高凝集
分けたものそれぞれの凝集度を高くする
関連性の高いデータと操作が、
一箇所にぎゅっとまとまっていて、
余分なものがない状態
データ
操作
操作
データ
操作


# Page. 27

![Page Image](https://bcdn.docswell.com/page/GJWZ6N6PJ2.jpg)

設計原理❸ 疎結合
他の設計要素に対する依存度を弱くする
✓依存する要素数を減らす
✓呼び出す操作を粗粒度にする
✓インターフェースに依存する


# Page. 28

![Page Image](https://bcdn.docswell.com/page/4EZ1Y3Y673.jpg)

設計原理❹ 抽象化（方針と詳細の分離）
設計要素のクライアント（別の設計要素）にとって
本質的で重要なものを抽出する（抽象化）
抽象化されたインターフェースが示す方針と、
実装の詳細とを分離し、
後者はクライアントから隠蔽する


# Page. 29

![Page Image](https://bcdn.docswell.com/page/Y76LDXDLJV.jpg)

設計原理❺ 非冗長
複数の箇所で繰り返して同じことを行う、
冗長性があれば取り除く
“冗長性は必ずしも形状の繰り返しではない。冗長性とは
意図の繰り返しなのだ。”
出典：David Scott Bernstein『レガシーコードからの脱却』第9章


# Page. 30

![Page Image](https://bcdn.docswell.com/page/G7513X3ME4.jpg)

設計原理は互いに関連し合う
{ 設計原理 }
関心の分離
❶
高凝集
❷
疎結合
❸
抽象化
❹
非冗長
❺
“「CLEAN」コードの品質はお互いに
助け合う。1つの品質を向上させれば、
ほかの品質も向上する。”
出典：David Scott Bernstein『レガシーコードからの脱却』第9章


# Page. 31

![Page Image](https://bcdn.docswell.com/page/9J21ZXZR7R.jpg)

例）SOLID原則
設計原理の観点でSOLIDを眺めると…
SRP
OCP
LSP
ISP
DIP
単一責任の原則
オープン・クローズド
の原則
リスコフの置換原則
インターフェース分離
の原則
依存関係逆転の原則
関心の分離、高凝集
抽象化（方針と詳細）
N/A
関心の分離、疎結合
抽象化（方針と詳細）、疎結合
→OODの特定の文脈で、従うとよいガイドライン


# Page. 32

![Page Image](https://bcdn.docswell.com/page/DEYZR8R57M.jpg)

まとめ
設計における普遍的な判断軸：
✓長期にわたり変更に対応できるような構造
を設計しよう
✓人間（開発者）の認知能力を考慮し、複雑
さを制御できる形状を生み出そう
✓設計原理を理解し、状況に合わせて設計原
則を適切に使えるようになろう


# Page. 33

![Page Image](https://bcdn.docswell.com/page/VJN3DQD4J8.jpg)

詳しくはデブサミ資料、レポート記事をご参照ください
https://www.docswell.com/s/tyonekubo/5R2Y4E-architecture2design
https://codezine.jp/article/detail/21430


# Page. 34

![Page Image](https://bcdn.docswell.com/page/YE99GDG4E3.jpg)

Fin
ENJOY DESIGNING!


