設計原則と普遍的な判断軸

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• https://book.impress.co.jp/books/1124101149

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

• https://book.impress.co.jp/books/1124101149

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• https://www.docswell.com/s/tyonekubo/5R2Y4E-architecture2design
• https://codezine.jp/article/detail/21430

Fin ENJOY DESIGNING!