情報管理技術士 学習ノート
← 一覧へ
SW工学・管理
#아키텍처스타일#디자인패턴#GoF#MSA#131회
最終更新 · 2026-09-27

アーキテクチャスタイルとデザインパターン

1. 概要

A. 定義

アーキテクチャスタイル(Architecture Style)は、システム全体の構造を組織する巨視的(Macro)な設計の枠組みであり、デザインパターン(Design Pattern)は、特定の設計問題を繰り返し解決する微視的(Micro)・再利用可能な解法である。前者はコンポーネントの配置と連結・品質属性を規定し、後者はクラス・オブジェクトレベルの生成・構造・振る舞いを規定する。

二つの概念の関係は「建物の構造様式」と「部屋を飾る定型化された技法」に例えれば明確になる。アーキテクチャスタイルがマンションか一戸建てかという建物全体の骨格(階層型・MSA・イベント基盤など)を定めるとすれば、デザインパターンはその建物の中で繰り返し出会う局所的な問題—たとえば「どうすれば特定のオブジェクトを一つだけ作って共有できるか」—を検証済みの方式で解く解法である。建物の様式を変えることは基礎工事からやり直すことに近いが、部屋の中の家具配置の技法を変えることは相対的に局所的で元に戻しやすい。

両者の本質的な違いは、抽象化レベル(Abstraction Level)と影響範囲(Scope of Impact)にある。アーキテクチャスタイルの選択は、性能・拡張性・可用性・セキュリティのようなシステム全体の品質属性(Quality Attribute)を左右する、元に戻しにくい(irreversible)決定である。一方、デザインパターンは特定のクラス・コンポーネントレベルの柔軟性・再利用性を扱うため、リファクタリングで比較的容易に置き換えられる。マーチン・ファウラー(Martin Fowler)が「アーキテクチャとは元に戻しにくい決定の集合である」と表現したのもこの文脈である。

B. 登場背景と必要性

ソフトウェアが大きく複雑になるほど、毎回最初から構造を考えるのは非効率であり失敗のリスクが大きい。1960年代後半のいわゆる「ソフトウェア危機(Software Crisis)」以後、検証済みの構造的解法を再利用しようとする努力が蓄積された。アーキテクチャスタイルはデビッド・ガーラン(David Garlan)とメアリー・ショウ(Mary Shaw)が1990年代に体系化し、デザインパターンは1994年に GoF(Gang of Four)の著書 Design Patterns: Elements of Reusable Object-Oriented Software によって23個のパターンが定型化された。

この二つの道具が必要な理由は三つに整理される。第一に、再利用性—先輩開発者たちが試行錯誤で検証した解法を再利用し、車輪の再発明をしない。第二に、意思疎通—「この部分はオブザーバーパターン」「全体は MSA」という共通の語彙(Vocabulary)で設計意図を圧縮して伝える。第三に、品質の予測可能性—検証済みの構造はどの品質属性を得て何を犠牲にするかが知られているため、トレードオフを事前に判断できる。

2. アーキテクチャスタイルとデザインパターンの全体構図

二つの概念は一つのシステムの中で異なる層位を担う。以下の概念図は、巨視(スタイル)と微視(パターン)がどのように階層的にともに作動するかを示す。

flowchart TB
  subgraph MACRO["巨視 · システム全体(Architecture Style)"]
    L["階層型(Layered)"]
    M["マイクロサービス(MSA)"]
    E["イベント基盤(Event-driven)"]
  end
  subgraph MICRO["微視 · コンポーネント内部(Design Pattern)"]
    C["生成(Creational)"]
    ST["構造(Structural)"]
    B["振る舞い(Behavioral)"]
  end
  MACRO -->|"構造の骨格を定めた後に内部を埋める"| MICRO
  QA["品質属性(性能・拡張・セキュリティ)"] --- MACRO
  RU["コード再利用・柔軟性"] --- MICRO
  style MACRO fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
  style MICRO fill:#fef3e8,stroke:#ed8a2f,stroke-width:2px

上図で強調される点は、二つの層位が競争ではなく補完関係であるということである。アーキテクチャスタイルがシステムの骨組みとコンポーネント境界を定めれば、各コンポーネント内部はデザインパターンで実装される。たとえば MSA において各マイクロサービス内部の決済モジュールは、戦略(Strategy)パターンで決済手段を交換し、ファクトリ(Factory)パターンで決済オブジェクトを生成し、オブザーバー(Observer)パターンで決済完了イベントを通知できる。

二つの概念の違いを実務の観点で整理すると次のとおりである。表は比較を助ける補助手段であり、核心は「なぜその違いが生じるのか」である。範囲が異なるため変更の波及効果が異なり、変更の波及が異なるため元に戻す難易度が変わる。

区分 アーキテクチャスタイル デザインパターン
範囲 システム全体(巨視) クラス・コンポーネント(微視)
関心事 構造・コンポーネント・連結・品質属性 オブジェクト生成・構造・振る舞い
影響 性能・拡張・セキュリティ(元に戻しにくい) コード再利用・柔軟性(交換容易)
代表成果物 アーキテクチャ仕様書・C4 ダイアグラム クラスダイアグラム・UML
例 階層型, MSA, イベント基盤, パイプ-フィルタ シングルトン, ファクトリ, オブザーバー, 戦略

3. 代表的なアーキテクチャスタイル

アーキテクチャスタイルは問題領域と品質要求によって選択される。ここでは実務で最も頻繁に使われる三つ—階層型、マイクロサービス、イベント基盤—を原理とトレードオフまで詳細に扱う。

flowchart TB
  S["アーキテクチャスタイルの選択"] --> L["階層型(Layered)<br/>単純・普遍"]
  S --> M["マイクロサービス(MSA)<br/>拡張・自律"]
  S --> E["イベント基盤(Event-driven)<br/>リアルタイム・非同期"]
  L --> LT["トレードオフ: 貫通変更に脆弱"]
  M --> MT["トレードオフ: 分散の複雑性"]
  E --> ET["トレードオフ: 流れの追跡が困難"]
  style S fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px

A. 階層型(Layered)アーキテクチャ

階層型は、システムを表現(Presentation)・ビジネス(Business)・データ(Data Access)の層へ水平分離して関心事を分ける、最も普遍的で理解しやすいスタイルである。各層はすぐ下の層のみに依存する単方向の流れを原則とし、この規則のおかげで特定の層の内部変更が他の層へ伝播しない。たとえばデータアクセス技術を MyBatis から JPA へ変えても、ビジネス層はインターフェースさえ維持すれば影響を受けない。

このスタイルの強みは低い学習コストと明確な責任分離である。ほとんどのエンタープライズ Web アプリケーション(伝統的な Spring MVC 3-tier 構造)がこの方式を採用する理由がここにある。しかし限界も明白である。一つの要求事項の変更が表現・ビジネス・データ層をすべて貫通(sinkhole)する場合—たとえばフィールドを一つ追加するために画面・サービス・DTO・エンティティ・テーブルをすべて修正せねばならない状況—が頻発すると、層分離の利点が色あせる。また、すべての要求が層を逐次通過するため、トラフィックが急増する大規模サービスでは水平拡張(scale-out)の単位がアプリケーション全体となり非効率である。

実務的には、ドメイン規則が単純で寿命が予測される社内管理システムや、初期スタートアップの MVP のように速い開発が重要な場に適する。逆に、トラフィックとドメイン複雑度がともに大きくなる大型コマースでは階層型だけで持ちこたえるのが難しく、MSA へ進化する場合が多い。

B. マイクロサービス(MSA)アーキテクチャ

マイクロサービスは、システムを独立してデプロイ可能な小さなサービス群へ分解するスタイルである。各サービスは自らのデータベースを所有(Database per Service)し、サービス間では REST・gRPC・メッセージで通信する。ネットフリックス(Netflix)は2009年から約7年をかけてモノリスを700個以上のマイクロサービスへ転換し、毎秒数百万リクエストを処理する代表事例であり、アマゾン・ウーバー・クーパンなども類似の経路をたどった。

MSA の核心的な利点は三つである。第一に独立デプロイ—決済サービスだけを一日に数十回デプロイでき、デプロイリスクが隔離される。第二にサービス別拡張—トラフィックが集中する商品照会サービスだけインスタンスを増やして資源を効率的に使う。第三に障害隔離(Fault Isolation)—推薦サービスが停止しても注文サービスは動作し続けるよう、サーキットブレーカーで遮断できる。

しかしこの利点の代償は、分散システムの本質的な複雑性である。ネットワークは信頼できず(遅延・断絶)、複数のサービスにまたがるデータ一貫性は分散トランザクションの代わりにサガ(Saga)・結果整合性(Eventual Consistency)で解かねばならず、ログ・トレース・モニタリングのための可観測性(Observability)インフラとサービスメッシュ(Service Mesh)が追加で必要となる。すなわち開発の複雑度が運用の複雑度へ転移する。マーチン・ファウラーが「MSA を担うには最低限の成熟度(デプロイ自動化・モニタリング・障害対応)をまず備えねばならない」と警告した理由である。

以下はユーザーの注文要求が MSA 環境で処理される流れの詳細図である。

sequenceDiagram
    participant U as ユーザー
    participant G as API ゲートウェイ
    participant O as 注文サービス
    participant P as 決済サービス
    participant I as 在庫サービス
    participant Q as メッセージブローカー
    U->>G: 注文要求
    G->>O: ルーティング
    O->>P: 決済承認要求
    P-->>O: 承認完了
    O->>Q: 注文生成イベント発行
    Q->>I: 在庫控除の購読
    I-->>Q: 在庫確定イベント
    O-->>U: 注文受付応答

C. イベント基盤(Event-driven)アーキテクチャ

イベント基盤は、コンポーネントが状態変化を「イベント」として発行(Publish)し、関心のあるコンポーネントがそれを購読(Subscribe)して反応するスタイルである。発行者と購読者が互いを直接知らないため疎結合(Loose Coupling)が極大化し、非同期処理でリアルタイム性と拡張性を得る。カフカ(Apache Kafka)を中心としたイベントストリーミングが代表的な実装であり、リアルタイム推薦・IoT センサー処理・金融取引監査ログのように毎秒数十万件のイベントを扱う場で威力を発揮する。

このスタイルの強みは拡張性と進化可能性である。新たな購読者(例: マーケティング分析サービス)を追加しても発行者コードを修正する必要がなく、システムを漸進的に拡張できる。一方、流れが複数のイベントを経て非同期に広がるため、全体の処理の流れを一目で追跡・デバッグするのが難しく、イベント順序の保証・重複処理(冪等性)・結果整合性を別途設計せねばならない。障害時に「どこまで処理されたか」を把握するために分散トレース(Distributed Tracing)が必須となる。

三つのスタイルのトレードオフを比較すると、選択基準は結局要求される品質属性にある。単純さが優先なら階層型、独立拡張・自律開発が優先なら MSA、リアルタイム・疎結合が優先ならイベント基盤である。

スタイル 核心の強み トレードオフ 代表的な適用
階層型 単純・明確な責任分離 貫通変更に脆弱, 拡張単位が全体 社内管理システム, MVP
マイクロサービス 独立デプロイ・拡張・障害隔離 分散の複雑性・運用負担 ネットフリックス, 大型コマース
イベント基盤 疎結合, リアルタイム・非同期 流れの追跡・順序・重複処理が困難 リアルタイム推薦, IoT, 金融

4. GoF デザインパターン

GoF デザインパターンは目的によって三つの類型に分かれる。生成(Creational)パターンはオブジェクトをどう生成するかをカプセル化して生成ロジックと使用ロジックを分離し、構造(Structural)パターンはオブジェクト・クラスをどう組み合わせてより大きな構造を作るかを扱い、振る舞い(Behavioral)パターンはオブジェクト間の責任分配と相互作用・通信を扱う。この分類の根底には「変わるものを変わらないものから分離せよ」というカプセル化原則と SOLID 設計原則が敷かれている。

flowchart TB
  G["GoF 23個のパターン"] --> CR["生成(5)<br/>オブジェクト生成のカプセル化"]
  G --> STR["構造(7)<br/>オブジェクト・クラスの組み合わせ"]
  G --> BEH["振る舞い(11)<br/>責任分配・相互作用"]
  CR --> C1["シングルトン・ファクトリメソッド<br/>抽象ファクトリ・ビルダー・プロトタイプ"]
  STR --> S1["アダプター・デコレーター・プロキシ<br/>ファサード・コンポジット・ブリッジ・フライウェイト"]
  BEH --> B1["オブザーバー・戦略・コマンド・状態<br/>イテレータ・テンプレートメソッド・責任連鎖"]
  style G fill:#fef3e8,stroke:#ed8a2f,stroke-width:2px

A. 生成パターン(Creational)

生成パターンの核心的な動機は「オブジェクトを生成する方式が変わるとき、そのオブジェクトを使用するコードが揺らがないようにすること」である。シングルトン(Singleton)はインスタンスを一つだけ生成・共有し、設定・ログ・コネクションプールのように全域的に一つだけ必要な資源に使う。ただし全域状態を作ってテストを難しくし、マルチスレッド環境で同期コストが生じるため、現代では DI コンテナ(Spring の Bean スコープ)がシングルトン管理を代行する場合が多い。

ファクトリメソッド(Factory Method)はオブジェクト生成をサブクラスに委任し、クライアントと具体クラス間の結合度を下げる。新しい型が追加されてもクライアントコードを修正せずファクトリだけ拡張すればよいため、開放閉鎖原則(OCP)を支援する。ビルダー(Builder)は生成子の引数が多く選択的なとき、段階的にオブジェクトを組み立てて可読性と不変性を高める(例: Java の StringBuilder、各種 SDK の Builder API)。

B. 構造パターン(Structural)

構造パターンは、すでに存在するクラス・オブジェクトを組み合わせて新しい機能やインターフェースを作るが、既存コードを修正しないことに焦点を置く。アダプター(Adapter)は互換性のないインターフェースを変換して連結する—レガシーシステムや外部ライブラリを新しいコードに合わせるとき必須であり、ヘキサゴナルアーキテクチャの「アダプター」概念と直結する。デコレーター(Decorator)は継承の代わりに組み合わせでオブジェクトに機能を動的に付け加える(例: Java I/O ストリームの BufferedReader(new FileReader(...)))。プロキシ(Proxy)は実オブジェクトへのアクセスを代理オブジェクトが制御し、遅延ロード・アクセス制御・キャッシング・リモート呼び出しを透過的に処理する(例: JPA の遅延ロードプロキシ、RPC スタブ)。

C. 振る舞いパターン(Behavioral)

振る舞いパターンは、オブジェクト間の責任をどう分け、どう疎通させるかを扱う。オブザーバー(Observer)は一つのオブジェクト(Subject)の状態変化を購読者たちに自動通知して発行-購読をコードレベルで実装し、MVC のモデル-ビュー更新やイベントリスナーの基盤となる。興味深いことに、オブザーバーパターンは先に見たイベント基盤アーキテクチャの微視版と見なせ、スタイルとパターンが同じ原理の異なるスケールであることを示す。戦略(Strategy)はアルゴリズム群をそれぞれカプセル化し、実行時に交換できるようにする—決済手段(カード・口座・簡易決済)や整列・割引ポリシーのように「何をするかは同じだが方式が異なる」場合に使われる。コマンド(Command)は要求をオブジェクトとしてカプセル化し、実行・取消(Undo)・キューイング・ロギングを可能にする。

類型 目的 代表パターン 実務例
生成 オブジェクト生成のカプセル化 シングルトン, ファクトリメソッド, ビルダー DI コンテナ, SDK Builder
構造 オブジェクト・クラスの組み合わせ アダプター, デコレーター, プロキシ I/O ストリーム, JPA 遅延ロード
振る舞い 責任分配・相互作用 オブザーバー, 戦略, コマンド MVC, 決済戦略, Undo

5. 発展: クラウドネイティブ時代の分散アーキテクチャパターン

伝統的な GoF パターンが単一プロセス内のオブジェクトレベルの問題を扱うとすれば、MSA・クラウドネイティブ環境は「プロセスとネットワークをまたぐ」新たな部類のパターンを要求する。これは GoF を代替するのではなく、より高いスケールで補完するものである。

第一に、サーキットブレーカー(Circuit Breaker)はネットフリックス Hystrix(現在は Resilience4j)で大衆化したパターンで、下位サービスの連鎖障害(Cascading Failure)を防ぐ。呼び出し失敗率が臨界値を超えると回路を「開いて(Open)」即座に失敗応答を返し、一定時間後に「半開放(Half-Open)」で試験呼び出しを送って復旧を確認する。これは障害がシステム全体へ広がることを物理的に遮断する。

第二に、サガ(Saga)は MSA において分散トランザクションを代替するパターンである。複数のサービスにまたがる業務をローカルトランザクションの連鎖に分け、途中で失敗すればすでに実行した段階を元に戻す補償トランザクション(Compensating Transaction)を実行する。オーケストレーション(中央調整者)方式とコレオグラフィ(イベント連鎖)方式があり、注文-決済-配送のように複数のサービスを経る業務で結果整合性を保証する。

第三に、API ゲートウェイ(API Gateway)と BFF(Backend for Frontend)は、クライアントと多数のマイクロサービスの間で認証・ルーティング・集約・レート制限を単一の入口で処理する。第四に、CQRS・イベントソーシング(Event Sourcing)は命令(書き込み)と照会(読み込み)モデルを分離し、状態をイベントの累積として保存して、読み込み拡張と完全な監査追跡を提供する。

既出連携の観点で、情報管理技術士試験はアーキテクチャスタイル(階層型・MSA・イベント基盤)と GoF 分類、そして近年は MSA 転換戦略・サーキットブレーカー・サガを単独または事例型で出題してきた。したがって答案は「スタイルとパターンの違い → 代表スタイルのトレードオフ → GoF 3分類 → クラウドネイティブパターンへの拡張」という階層的構成で展開すれば、深さと最新性を同時に示せる。

6. 考慮事項および示唆点

  1. アーキテクチャスタイルで品質属性を、デザインパターンでコードの柔軟性を確保する。 二つの層位は目的と影響範囲が異なるため、競争ではなく相互補完的に適用せねばならない。スタイル決定を先送りしたままパターンだけを積めば局所最適化にとどまり、パターンなしにスタイルだけを定めれば実装段階で結合度が高まる。

  2. パターンの濫用は過設計(Over-engineering)である。 問題がないのに「パターンのためのパターン」を適用すれば複雑度だけが増す。YAGNI(You Aren't Gonna Need It)原則に従い、実際に変化が予想される地点にのみ節制して適用し、変更の理由(変更の軸)が実在するかをまず検証する。

  3. アーキテクチャは元に戻しにくい決定であるため、トレードオフを明示的に判断する。 MSA は組織のデプロイ自動化・モニタリング・障害対応の成熟度が前提とならねばならず、成熟度なしに導入すれば「分散モノリス(Distributed Monolith)」という最悪の結果を生む。コンウェイの法則(Conway's Law)のように、組織構造とアーキテクチャの整合性もともに考慮する。

  4. クラウドネイティブ・MSA 時代には伝統的な GoF を補完する分散パターンが必須である。 サーキットブレーカー・サガ・CQRS・イベントソーシングなどを理解し、可観測性(ログ・メトリクス・トレース)・サービスメッシュ(Istio など)・コンテナオーケストレーション(Kubernetes)と結合して運用の観点まで設計に含めねばならない。

  5. 技術士の観点からの戦略的選択。 スタイル・パターンは銀の弾丸(Silver Bullet)ではなく、ビジネス要求・チーム能力・予想寿命・トラフィック特性を総合して選択する。初期はモノリスで単純に始め、必要が明確になったときに漸進的に MSA・イベント基盤へ進化(Strangler Fig パターン)するのが、リスクを下げる実用的な戦略である。

参考資料

一言まとめ: アーキテクチャスタイル(階層型・MSA・イベント基盤)はシステム全体の構造と品質属性を決定する巨視的・元に戻しにくい枠組みであり、GoF デザインパターン(生成・構造・振る舞い)は繰り返される設計問題の微視的な解法であり、クラウドネイティブ時代にはサーキットブレーカー・サガなど分散パターンがこれを補完するため、トレードオフを明示的に判断して節制しつつ相互補完的に適用せねばならない。