--- title: "システムアーキテクチャとは？意味と代表5方式の違い・選び方をわかりやすく解説" url: "https://www.issoh.co.jp/column/details/3089/" published: 2024-07-17 updated: 2026-09-29 categories: ["アーキテクチャ"] publisher: "株式会社一創" --- # システムアーキテクチャとは？意味と代表5方式の違い・選び方をわかりやすく解説 システムアーキテクチャとは、システムを構成する要素（ソフトウェア、サーバー、データベース、ネットワークなど）とその関係、そして設計と進化を方向づける原則のことです。家の設計図にたとえられますが、正確には「図」そのものではなく、図が表そうとしている骨組みと判断の方が本体です。IT分野で単に「アーキテクチャ」と言う場合も、この「構造と、それを決める基本方針」を指します。 この記事では、国際規格ISO/IEC/IEEE 42010の定義と、1964年のIBM System/360論文で定着した語の由来から意味を整理し、レイヤード・クライアントサーバ・モノリシック・マイクロサービス・イベント駆動の5方式を比較します。後半では、品質特性の優先順位から方式を選ぶ手順と、マイクロサービスを選ぶべきでない条件を具体例で示します。 ## まとめ：システムアーキテクチャの意味と選び方の要点 - システムアーキテクチャは、構成要素・要素間の関係・設計と進化の原則をまとめた「システムの骨組み」です（ISO/IEC/IEEE 42010:2011の定義に沿った言い方）。2022年版の同規格は、アーキテクチャと、それを表す図や文書（アーキテクチャ記述）を別物として定義しています。 - IT用語の「アーキテクチャ」は、1959年ごろのIBM Stretch計画の文書に先例があり、1964年のIBM System/360の論文が「プログラマから見たシステムの属性」という意味で定義して広まりました。 - 代表的な方式は、レイヤード（3層）、クライアントサーバ、モノリシック、マイクロサービス、イベント駆動の5つです。どれが優れているかではなく、どの品質特性を優先するかで選びます。 - 選ぶ手順は、ISO/IEC 25010:2023の9つの品質特性から優先順位を決め、方式ごとの代償と突き合わせ、判断の理由をADR（アーキテクチャ決定記録）に残す、の順です。 - チームが1つで、業務の境界がまだ固まっていない段階では、マイクロサービスから始めない方が安全です。Segment（現Twilio Segment）は140超のサービスを1つに統合し直しています。 以下、定義、方式の比較、選び方の順に説明します。 ## システムアーキテクチャの意味と定義 ### IT用語「アーキテクチャ」の定着：1964年のIBM System/360 architectureはもともと「建築」「建築様式」を指す英語で、読みはアーキテクチャ（アーキテクチャー）です。コンピュータの用語としては、1959年ごろIBMのLyle R. JohnsonがスーパーコンピュータStretchの社内文書で「system architecture」と書いた例が先にあります。広く定着させたのは、IBMのAmdahl、Blaauw、Brooksが1964年にIBM Journal of Research and Development（第8巻第2号）に発表した論文「Architecture of the IBM System/360」です。 この論文はアーキテクチャを「プログラマから見たシステムの属性、つまり概念上の構造と機能上の振る舞い」と定義し、データの流れと制御の編成、論理設計、物理的な実装とは区別しました。同じ命令体系のまま、性能差50倍にわたる6機種で中身の作りを変えられるようにするための区別です（論文の要旨は、6機種の間で機械語の上位・下位互換を保つことを4つの革新の1つに挙げています）。CPUの世界で「x86アーキテクチャ」「Armアーキテクチャ」と呼ぶのは、この意味を受け継いでいます。命令体系の違いが実際にどう現れるかは、[ARMアーキテクチャとx86の違い](/tech/details/10467/)が具体例になります。 システムアーキテクチャという言い方は、現在では1台のコンピュータにとどまらず、複数のソフトウェアやサーバーが連携する情報システム全体の構造を指して使われます。 ### ISO/IEC/IEEE 42010:2022の定義とアーキテクチャ記述 現在の標準的な定義は、2022年11月に発行されたISO/IEC/IEEE 42010:2022にあります。同規格の3.2はアーキテクチャを「環境の中にある対象の基本的な概念または性質と、その対象および関連するライフサイクルプロセスの実現と進化を方向づける原則」と定義しています。2011年版は「要素、関係、設計と進化の原則に具現化された、環境の中のシステムの基本的な概念または性質」としており、2022年版は対象をsystemからentityに広げて、システム以外（企業全体など）にも当てはめられるようにしました。 実務で効くのは、同規格がアーキテクチャと**アーキテクチャ記述**（architecture description、3.3）を分けている点です。アーキテクチャ記述は「アーキテクチャを表すための成果物」で、構成図や設計書がこれにあたります。図が古くなっても骨組みは実在し続けるので、図を描けば設計が終わるわけではありません。記述の側は、発注者向けの[システム構成図の種類と書き方](/column/details/13136/)や、詳しさを段階で分ける[アーキテクチャ図の書き方とC4モデル](/tech/details/4024/)といった作法で整えます。 ### システム・ソフトウェア・エンタープライズ：範囲の違い 「アーキテクチャ」は、どこまでを対象にするかで呼び名が変わります。混同しやすい3つを範囲で並べると次のとおりです。 | 呼び名 | 対象の範囲 | 決めることの例 | | --------------- | ----------- | ---------------- | | エンタープライズアーキテクチャ | 企業全体の業務とIT | 業務・データ・システムの全社配置 | | システムアーキテクチャ | 1つの情報システム | サーバー構成、分割単位、通信方式 | | ソフトウェアアーキテクチャ | 1つのプログラムの内部 | 層の分け方、依存の向き | システムアーキテクチャはハードウェアやネットワークを含めた全体の配置を扱い、ソフトウェアアーキテクチャはその中の1つのアプリケーションのコード構造を扱います。[クリーンアーキテクチャ](/column/details/3406/)、[オニオンアーキテクチャ](/column/details/3431/)、[ヘキサゴナルアーキテクチャ](/tech/details/2965/)は、いずれもソフトウェア側の依存の向きを決める設計です。アプリケーションアーキテクチャという語も、多くはこのソフトウェア側の構造を指します。企業全体を対象にする場合の枠組みは、[エンタープライズアーキテクチャの4体系](/column/details/4645/)で整理しています。 ## アーキテクチャで決める範囲と後から変えにくい理由 ### 「後から変えにくい決定」がアーキテクチャになる理由 アーキテクチャ設計で決めるのは、たとえば次のような事項です。 - 機能をどの単位で分けるか（1つのアプリケーションか、複数のサービスか） - 要素どうしをどうつなぐか（同期のAPI呼び出しか、キューを介した非同期か） - データをどこに持つか（共有データベースか、サービスごとに分けるか） - どこで動かすか（オンプレミス、クラウド、サーバーレス） どれも、決めた後で変えるとコードの大半や運用手順に手が入ります。Martin Fowlerは自身のアーキテクチャ解説で、Ralph Johnsonの「アーキテクチャとは重要なもののことだ。それが何であれ」という言葉と、「プロジェクトの初期に正しく決められたらよかったと思う決定」という言い換えを紹介しています。何がアーキテクチャかは固定の一覧ではなく、そのシステムで変更コストが大きい決定がアーキテクチャになる、ということです。 ### 組織の構造が設計に写る：コンウェイの法則 Melvin Conwayは1968年4月のDatamation誌の論文で、「システムを設計する組織は、その組織のコミュニケーション構造を写した設計を生み出すよう制約される」と述べました。これがコンウェイの法則です。 論文自身が挙げる例では、8人の組織がCOBOLとALGOLのコンパイラを作る際に5人と3人に分かれた結果、COBOLコンパイラは5フェーズ、ALGOLコンパイラは3フェーズで動くものになりました。逆に1チームで開発するシステムを10のサービスに分けても、分割に対応する担当の境界が無いため、デプロイと監視の手間だけが増えます。方式を選ぶときは、技術の比較と同じ重さで「何チームで、誰が何を持つか」を確認してください。 ## 代表的なシステムアーキテクチャ5方式の比較 よく比較される5方式を、分割の単位と通信の仕方で並べます。5方式は同じ軸の選択肢ではなく、組み合わせて使うのが普通です。たとえば「3層のWebシステムを、注文処理だけイベント駆動にする」といった形です。 | 方式 | 分割の単位 | 主な通信 | 向く条件 | 主な代償 | | --------- | ---------- | -------------- | ------------ | ------------ | | レイヤード（3層） | 技術的な役割 | 上の層から下の層へ | 業務システム全般 | 機能追加で全層に手が入る | | クライアントサーバ | 要求側と提供側 | 要求と応答 | データの集中管理 | サーバーへの負荷集中 | | モノリシック | 1つのアプリ | プロセス内の呼び出し | 小規模・初期開発 | 部分だけの増強が難しい | | マイクロサービス | 業務の機能 | HTTP API・メッセージ | 複数チーム・独立リリース | 分散システムの運用負担 | | イベント駆動 | イベントの発行と購読 | 非同期メッセージ | 処理の分離・負荷の平準化 | 処理順と整合性の管理 | このほか、SOA（サービス指向アーキテクチャ）、P2P、マイクロカーネル、パイプ＆フィルターなども分類に挙がりますが、本記事では、新規の業務システムで比較に挙がりやすい上の5つに絞ります。 ### レイヤード（3層）アーキテクチャの層分けと変更範囲 画面（プレゼンテーション層）、業務ロジック（アプリケーション層）、データアクセス（データ層）のように、技術的な役割で層を分ける方式です。IPAの基本情報技術者試験のシラバスは、同じ3層を「プレゼンテーション層、ファンクション層、データベースアクセス層」と呼んでいます。上の層は下の層だけを呼ぶので、画面の作り替えがデータベースに波及しにくくなります。一方、「割引ルールを1つ足す」ような機能追加は全層に手が入るため、機能が増えるほど変更範囲が横に広がります。外部システムとの連携を独立させる[3層アーキテクチャとインテグレーション層](/column/details/2909/)の分け方もあります。 ### クライアントサーバアーキテクチャの役割分担と集中管理 サービスを要求するクライアントと、提供するサーバーに役割を分ける方式で、Webシステムもこの一種です。データをサーバーに集めるので管理と更新が一か所で済む反面、サーバーを冗長化していなければ、止まったときに全員が使えなくなります。HTTPの仕様RFC 9110が「同じプログラムが、ある接続ではクライアント、別の接続ではサーバーとして振る舞うことがある」と書くとおり、役割は接続ごとに決まるもので、機械ごとに固定されたものではありません。[クライアントサーバシステムの仕組み](/tech/details/9655/)では、2層と3層の違いやP2Pとの比較を具体例で示しています。 ### モノリシックの一体デプロイとモジュラモノリスの境界 全機能を1つのアプリケーションとしてビルドし、1つの単位でデプロイする方式です。機能間の呼び出しはプロセス内で完結するので、ネットワーク越しの遅延や部分的な通信障害を考えずに済み、テストとデプロイの仕組みも1つで足ります。後述するSegmentは、140超のサービスを1つに統合した後、1人のエンジニアが数分でデプロイできるようになったと報告しています。代償は、注文処理だけ負荷が高くても全体を増やすしかないことと、コードの境界が崩れやすいことです。 後者への対策が、1つのデプロイ単位のまま内部をモジュールに厳密に区切るモジュラモノリスです。モジュール間の依存をCIで検査して境界の崩れを止める方法は、[モジュラモノリスのモジュール境界設計](/tech/details/5842/)で実装例とともに示しています。 ### マイクロサービスアーキテクチャの独立デプロイと分散の代償 James LewisとMartin Fowlerは2014年3月に分載した記事（3月10日初回、25日完結）で、マイクロサービスを「1つのアプリケーションを小さなサービスの集まりとして開発する手法で、各サービスは自分のプロセスで動き、軽量な仕組み（多くの場合はHTTPのリソースAPI）で通信する」と説明し、サービスは業務の機能ごとに作られ、自動化されたデプロイの仕組みで独立してリリースできるとしています。 チームごとに独立してリリースでき、負荷の高いサービスだけを増やせるのが利点です。その代わり、サービス間の通信障害、サービスをまたぐトランザクション、ログと監視の分散といった分散システム特有の課題を引き受けます。サービスをまたぐ整合性は、[Sagaパターンの補償トランザクション](/tech/details/16175/)で取るのが定石です。モノリスとの損得を並べた比較は[マイクロサービスとモノリスの違い](/column/details/2910/)にあります。 ### イベント駆動アーキテクチャの疎結合と整合性管理 「注文が確定した」といった出来事（イベント）を発行し、関心のある処理がそれを購読して動く方式です。発行側は誰が受け取るかを知らないので、在庫引当・メール送信・ポイント付与を後から足しても注文処理のコードは変わりません。キューが間に入るため、アクセスが集中しても処理を後ろにずらして受け止められます。 代償は、処理の順序と整合性をアプリケーション側で管理する必要があることです。たとえばAmazon SQSの標準キューは、少なくとも1回の配信（at-least-once）を保証する代わりに、同じメッセージが複数回届くことや順序が入れ替わることがあると公式ドキュメントに明記しています。同じイベントが2回届いても結果が変わらない作り（冪等性）や、失敗したイベントの退避先を最初から設計しておかないと、障害時に原因を追えなくなります。イベントを起点に関数を動かす構成を選ぶなら、[サーバーレスとコンテナの使い分け](/column/details/13005/)も判断材料になります。 ## 品質特性から方式を選ぶ手順 ### ISO/IEC 25010:2023の9特性による優先順位付け 方式の比較を始める前に、「このシステムで何を最優先するか」を決めます。ものさしには、ICT製品とソフトウェア製品の品質モデルを定めたISO/IEC 25010が使えます。2023年11月発行の第2版は、機能適合性、性能効率性、互換性、インタラクション能力、信頼性、セキュリティ、保守性、柔軟性、安全性の9特性です。2011年版からの主な変更点は、安全性の追加、使用性がインタラクション能力に、移植性が柔軟性に置き換わったこと、そして[スケーラビリティ](/column/details/4129/)が柔軟性の副特性として加わったことです。 9特性すべてを「高く」はできません。「年に数回しか変更しないがデータ不整合は許されない会計システム」と「毎週機能を足すECサイト」では、上位に来る特性が違います。上位2〜3特性を決め、それぞれに「ピーク時に毎秒何件」「月間停止何分以内」のような数値の目標を付けてから次の手順に進みます。目標値の決め方と負荷試験での確かめ方は、[非機能要件の数値化](/tech/details/17610/)の手順が使えます。 ### 優先する品質特性と有利な方式の対応 優先度の高い特性が決まったら、有利な方式とその代償を突き合わせます。 | 優先したい特性 | 有利な方式 | 引き換えに増えるもの | | -------------- | ----------------- | ----------- | | 性能効率性（低遅延） | モノリシック | 部分的な増強ができない | | 保守性（変更の局所化） | モジュラモノリス、マイクロサービス | 境界設計の手間 | | 柔軟性（部分的な拡張） | マイクロサービス、イベント駆動 | 監視・運用の負担 | | 信頼性（障害の局所化） | イベント駆動、マイクロサービス | 結果整合性への対応 | | セキュリティ（DB層の隔離） | レイヤード | 層をまたぐ変更の手間 | | 互換性（他システム連携） | イベント駆動、マイクロサービス | スキーマの版管理 | 表の右列が判断の本体です。たとえば信頼性を優先してイベント駆動を選ぶと、「画面で注文直後に在庫数が古いまま見える」状態を業務として許容できるかという問いが残ります。許容できないなら、その部分だけ同期処理に戻す判断になります。 ### 判断理由のADRへの記録 選んだ方式と、選ばなかった方式の理由は、ADR（Architecture Decision Record）として残します。Michael Nygardが2011年11月15日の記事で提案した形式で、タイトル・背景（Context）・決定（Decision）・状態（Status）・結果（Consequences）の5項目を1〜2ページで書きます。Nygardは結果の欄に、良い影響だけでなく悪い影響や中立の影響も含めて全て書くよう求めています。記入例は次のとおりです（状態を先頭に置く一般的なテンプレートの並びにし、簡潔さのため箇条書きにしています。Nygard自身は各欄を完全な文で書くよう勧めています）。 ``` # ADR 1: 受注システムはモジュラモノリスで開始する ## Status Accepted（2026-09-29） ## Context - 開発は1チーム6名。受注・在庫・請求の業務境界はまだ固まっていない - 優先する品質特性は保守性と信頼性。ピーク時の注文は毎秒20件を想定 - 年末のセール期は在庫照会だけ負荷が5倍になる。在庫照会の応答目標は95パーセンタイルで300ミリ秒以内 ## Decision - 1つのデプロイ単位で開始し、受注・在庫・請求をモジュールに分ける - モジュール間の直接参照を禁止し、公開インターフェース経由に限定する - 在庫照会は読み取り専用のレプリカDBへ逃がす ## Consequences - 良い点: デプロイと監視の仕組みが1つで済む - 悪い点: 在庫照会のアプリケーション処理だけを独立して増強できない（DBの読み取りはレプリカで分散する） - 見直す条件: チームが2つ以上になった時点、または在庫照会の遅延が目標を超えた時点 ``` 「見直す条件」を書いておくと、状況が変わったときに判断をやり直すきっかけになります。書き方とテンプレートの比較は[ADR（アーキテクチャ決定記録）の書き方](/tech/details/9198/)にまとめています。 ## マイクロサービスを採用すべきでない条件と失敗例 方式選びでよく語られる失敗が、規模に合わないマイクロサービスの採用です。Martin Fowlerは2015年6月3日の記事「MonolithFirst」で、成功したマイクロサービスの事例のほぼ全てが大きくなりすぎたモノリスを分割したものであり、最初からマイクロサービスで作ったと聞いた事例のほぼ全てが深刻な問題を抱えたと書いています。 実例として、顧客データ基盤のSegment（2020年にTwilioが買収し、現Twilio Segment）は2018年7月10日の記事「Goodbye Microservices」で、送信先ごとにサービスを分けた結果、フルタイムのエンジニア3人がほとんどの時間をシステムの維持だけに費やす状態になり、140を超えるサービスを1つのサービスに統合したと公表しています。同社は統合の代償として、1つの送信先のバグがサービス全体を止めうる、つまり障害の隔離が難しくなった点も明記しています。一方で、共有ライブラリの改善は分割していた時期の32件に対し、統合後の1年で46件に増えたとしています。 次の条件に1つでも当てはまるなら、モノリシックかモジュラモノリスから始めるべきです。 - 開発チームが1つで、サービスごとに担当を分けられない - 業務の境界がまだ変わる段階で、どこで分けるべきか決められない - サービスごとのデプロイ、監視、ログ収集を自動化する体制がない - 一部の機能だけ負荷が突出する、といった部分的な拡張の必要が見えていない 逆に、複数チームがそれぞれ週に何度もリリースし、互いの待ち合わせが開発の遅れの主因になっているなら、分割を検討する時期です。どの業務から切り出すかは、[マイクロサービスの向き不向きと判断基準](/column/details/2873/)で整理しています。 ## よくある質問 ### システムアーキテクチャの具体例は？ 一般的なECサイトなら、ロードバランサーの後ろにWebサーバーを複数台置き、アプリケーションサーバーとデータベースを分けた3層構成が土台になります。そのうえで、注文確定後の在庫引当やメール送信だけをキュー経由のイベント駆動にし、商品画像は配信用のCDNから返す、というように複数の方式を組み合わせたもの全体が、そのシステムのアーキテクチャです。 ### システムアーキテクチャ図とは何ですか？ システムアーキテクチャを表すための図で、ISO/IEC/IEEE 42010でいうアーキテクチャ記述の一種です。サーバーやサービスの配置と接続を描く構成図のほか、C4モデルのように詳しさの段階を分けて描く方法があります。描く手順は[アーキテクチャ図の書き方とC4モデル](/tech/details/4024/)が参考になります。 ### アプリケーションアーキテクチャとは何ですか？ 1つのアプリケーションの内部構造、つまりコードをどの層やモジュールに分け、依存をどちら向きにするかの設計を指すことが多い言葉です。システムアーキテクチャがサーバーやネットワークを含む全体の配置を扱うのに対し、アプリケーションアーキテクチャはその中の1つのプログラムを扱います。MVC、クリーンアーキテクチャ、ヘキサゴナルアーキテクチャなどがこの領域の代表例です。 ### システムアーキテクトとSE（システムエンジニア）の違いは何ですか？ IPAのシステムアーキテクト試験は、対象者像を「要件を定義し、それを実現するためのアーキテクチャを設計し、開発を主導する者」としています。SEが担う設計・開発のうち、システム全体の構造と方式を決める上流側を専門にする役割と考えると区別しやすくなります。なお同試験を含む現行の試験制度は2026年度の実施をもって終了し、2027年度から新しい試験制度に移行する予定です（2026年度はCBT方式の前期試験として実施され、申込受付は2026年10月6日〜24日、科目A-1・A-2は10月17日〜27日、科目B-1・B-2は11月11日〜23日です）。クラウドベンダーの職種名として使われるソリューションアーキテクトとの違いは[ソリューションアーキテクトの役割と仕事内容](/tech/details/13380/)を参照してください。 ### アーキテクチャの読み方と英語のつづりは？ 英語はarchitectureで、読みはアーキテクチャ、またはアーキテクチャーです。「アーキテクスチャ」「アーキテクチュア」と書かれることもありますが、IT分野ではアーキテクチャが一般的です。設計者はarchitect（アーキテクト）です。現場ではアーキテクチャやアーキテクトを「アーキ」と略すこともあります。 ## 関連記事 - [マイクロサービスとは？モノリスとの違い・メリット・デメリットと選び方、モジュラモノリスまで整理](/column/details/2910/) - [3層アーキテクチャとインテグレーション層とは｜各層の役割とフロントエンド・バックエンドの担当領域](/column/details/2909/) - [クライアントサーバシステムとは？仕組みと2層・3層の違い、Webシステム・P2Pとの違いを具体例で解説](/tech/details/9655/) - [ADR（アーキテクチャ決定記録）とは｜書き方・テンプレート・design docとの違い](/tech/details/9198/) - [システム構成図とは：種類と書き方・Mermaidでの作例、発注者が確認すべき観点](/column/details/13136/) --- 出典: [システムアーキテクチャとは？意味と代表5方式の違い・選び方をわかりやすく解説]()（株式会社一創）