システムアーキテクチャとは？意味と代表5方式の違い・選び方をわかりやすく解説

システムアーキテクチャとは、システムを構成する要素（ソフトウェア、サーバー、データベース、ネットワークなど）とその関係、そして設計と進化を方向づける原則のことです。家の設計図にたとえられますが、正確には「図」そのものではなく、図が表そうとしている骨組みと判断の方が本体です。IT分野で単に「アーキテクチャ」と言う場合も、この「構造と、それを決める基本方針」を指します。

この記事では、国際規格ISO/IEC/IEEE 42010の定義と、1964年のIBM System/360論文で定着した語の由来から意味を整理し、CPUから企業全体まで「アーキテクチャ」が指す対象の違いを並べたうえで、レイヤード・クライアントサーバ・モノリシック・マイクロサービス・イベント駆動の5方式を比較します。後半では、非機能要件の洗い出しから方式の決定・評価・記録までの設計の進め方と、マイクロサービスを選ぶべきでない条件を具体例で示します。

まとめ：システムアーキテクチャの意味と選び方の要点

• システムアーキテクチャは、構成要素・要素間の関係・設計と進化の原則をまとめた「システムの骨組み」です（ISO/IEC/IEEE 42010:2011の定義に沿った言い方）。2022年版の同規格は、アーキテクチャと、それを表す図や文書（アーキテクチャ記述）を別物として定義しています。
• IT用語の「アーキテクチャ」は、1959年ごろのIBM Stretch計画の文書に先例があり、1964年のIBM System/360の論文が「プログラマから見たシステムの属性」という意味で定義して広まりました。
• IT分野の「アーキテクチャ」は、CPUの命令セット、ネットワークの階層、ソフトウェア、データ、システム、企業全体と、対象によって指すものが変わります。システムアーキテクチャは、1つの情報システム全体の骨組みを指します。
• 代表的な方式は、レイヤード（3層）、クライアントサーバ、モノリシック、マイクロサービス、イベント駆動の5つです。どれが優れているかではなく、どの品質特性を優先するかで選びます。
• 設計は、非機能要件を洗い出し（IPAの非機能要求グレードは6大項目・238メトリクス）、ISO/IEC 25010:2023の9つの品質特性で優先順位を決め、方式の代償と突き合わせ、ATAMのような評価でトレードオフを確かめ、判断の理由をADR（アーキテクチャ決定記録）に残す、の順に進めます。
• チームが1つで、業務の境界がまだ固まっていない段階では、マイクロサービスから始めない方が安全です。Segment（現Twilio Segment）は140超のサービスを1つに統合し直しています。

以下、定義、方式の比較、設計の進め方の順に説明します。

システムアーキテクチャの意味と定義

IT用語「アーキテクチャ」の定着：1964年のIBM System/360

architectureはもともと「建築」「建築様式」を指す英語で、読みはアーキテクチャ（アーキテクチャー）です。「アーキテクスチャ」「アーキテクチュア」と書かれることもありますが、IT分野ではアーキテクチャが一般的で、現場では「アーキ」と略すこともあります。コンピュータの用語としては、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つに挙げています）。

システムアーキテクチャという言い方は、現在では1台のコンピュータにとどまらず、複数のソフトウェアやサーバーが連携する情報システム全体の構造を指して使われます。

ISO/IEC/IEEE 42010:2022の定義とアーキテクチャ記述

現在の標準的な定義は、2022年11月に発行されたISO/IEC/IEEE 42010:2022にあります。同規格の3.2はアーキテクチャを「環境の中にある対象の基本的な概念または性質と、その対象および関連するライフサイクルプロセスの実現と進化を方向づける原則」と定義しています。2011年版は「要素、関係、設計と進化の原則に具現化された、環境の中のシステムの基本的な概念または性質」としており、2022年版は対象をsystemからentityに広げて、システム以外（企業全体など）にも当てはめられるようにしました。

実務で効くのは、同規格がアーキテクチャとアーキテクチャ記述（architecture description、3.3）を分けている点です。アーキテクチャ記述は「アーキテクチャを表すための成果物」で、構成図や設計書がこれにあたります。図が古くなっても骨組みは実在し続けるので、図を描けば設計が終わるわけではありません。記述の側は、発注者向けのシステム構成図の種類と書き方や、詳しさを段階で分けるアーキテクチャ図の書き方とC4モデルといった作法で整えます。

IT分野で「アーキテクチャ」が指す対象：CPUから企業全体まで

IT分野の「アーキテクチャ」は、どの層を対象にするかで指すものが変わります。「アーキテクチャとは」と調べて説明が食い違って見えるのは、たいてい対象が違うためです。小さい対象から順に並べると次のとおりです。

CPUの「x86アーキテクチャ」「Armアーキテクチャ」は、System/360論文の「プログラマから見た属性」をそのまま受け継いだ用法です。Armは命令セットアーキテクチャ（ISA）を「プロセッサのハードウェアと、その上で動くソフトウェアとの間の抽象的なインターフェース」と説明しており、同じ命令セットなら、作りの違うプロセッサでも同じ機械語の命令を実行できます（アプリケーションが動くには、OSなどの実行環境も揃っている必要があります）。命令体系の違いが実際にどう現れるかは、ARMアーキテクチャとx86の違いやRISC-VとArm・x86の違いが具体例になります。ネットワークでは、1994年11月発行のISO/IEC 7498-1が定める7層のOSI参照モデルが代表で、各層の役割はOSI参照モデルの7階層とTCP/IPとの違いにまとめています。データの置き場所と管理責任を業務領域ごとに分ける考え方の例には、データメッシュの4原則があります。

システムアーキテクチャはハードウェアやネットワークを含めた全体の配置を扱い、ソフトウェアアーキテクチャはそのうちソフトウェアの要素（モジュールやサービス）と、要素どうしの依存や連携を扱います。対象は1つのアプリケーションの内部に限らず、複数のサービスの連携も含みます。クリーンアーキテクチャ、オニオンアーキテクチャ、ヘキサゴナルアーキテクチャは、いずれもソフトウェア側の依存の向きを決める設計です。アプリケーションアーキテクチャという語も、多くはこのソフトウェア側の構造を指します。企業全体を対象にする場合の枠組みは、エンタープライズアーキテクチャの4体系で整理しています。

アーキテクチャで決める範囲と後から変えにくい理由

「後から変えにくい決定」がアーキテクチャになる理由

アーキテクチャ設計で決めるのは、たとえば次のような事項です。

• 機能をどの単位で分けるか（1つのアプリケーションか、複数のサービスか）
• 要素どうしをどうつなぐか（同期のAPI呼び出しか、キューを介した非同期か）
• データをどこに持つか（共有データベースか、サービスごとに分けるか）
• どこで動かすか（オンプレミス、クラウド、サーバーレス）

どれも、決めた後で変えるとコードの大半や運用手順に手が入ります。Martin Fowlerは自身のアーキテクチャ解説で、Ralph Johnsonの「アーキテクチャとは重要なもののことだ。それが何であれ」という言葉と、「プロジェクトの初期に正しく決められたらよかったと思う決定」という言い換えを紹介しています。何がアーキテクチャかは固定の一覧ではなく、そのシステムで変更コストが大きい決定がアーキテクチャになる、ということです。クラウドで動かす場合は、アカウントやネットワークの分け方もこの段階で決まり、後から変えると権限、接続経路、移行手順の見直しが必要になります。設計段階からAWS・Google Cloud・Azureのインフラ構築を含めて検討しておくと手戻りを減らせます。

組織の構造が設計に写る：コンウェイの法則

Melvin Conwayは1968年4月のDatamation誌の論文で、「システムを設計する組織は、その組織のコミュニケーション構造を写した設計を生み出すよう制約される」と述べました。これがコンウェイの法則です。

論文自身が挙げる例では、8人の組織がCOBOLとALGOLのコンパイラを作る際に5人と3人に分かれた結果、COBOLコンパイラは5フェーズ、ALGOLコンパイラは3フェーズで動くものになりました。逆に1チームで開発するシステムを10のサービスに分けても、分割に対応する担当の境界が無く、独立して増強したい部分や障害を隔離したい部分も無いなら、デプロイと監視の手間だけが増えます。方式を選ぶときは、技術の比較と同じ重さで「何チームで、誰が何を持つか」を確認してください。

代表的なシステムアーキテクチャ5方式の比較

よく比較される5方式を、分割の単位と通信の仕方で並べます。5方式は同じ軸の選択肢ではなく、組み合わせて使うのが普通です。たとえば「3層のWebシステムを、注文処理だけイベント駆動にする」といった形です。

このほか、SOA（サービス指向アーキテクチャ）、P2P、マイクロカーネル、パイプ＆フィルターなども分類に挙がりますが、本記事では、新規の業務システムで比較に挙がりやすい上の5つに絞ります。

レイヤード（3層）アーキテクチャの層分けと変更範囲

画面（プレゼンテーション層）、業務ロジック（アプリケーション層）、データアクセス（データ層）のように、技術的な役割で層を分ける方式です。IPAの基本情報技術者試験のシラバスは、同じ3層を「プレゼンテーション層、ファンクション層、データベースアクセス層」と呼んでいます。上の層は下の層だけを呼ぶので、画面の作り替えがデータベースに波及しにくくなります。一方、割引の計算式を変えるだけなら業務ロジックの層で済みますが、「割引コードの入力欄を足し、使った履歴も保存する」ような機能追加は画面・業務ロジック・データの全層に手が入ります。機能が増えるほど、この横に広がる変更が増えます。外部システムとの連携を独立させる3層アーキテクチャとインテグレーション層の分け方もあります。

クライアントサーバアーキテクチャの役割分担と集中管理

サービスを要求するクライアントと、提供するサーバーに役割を分ける方式で、Webシステムもこの一種です。データをサーバーに集めるので管理と更新が一か所で済む反面、サーバーを冗長化していなければ、止まったときに全員が使えなくなります。HTTPの仕様RFC 9110が「同じプログラムが、ある接続ではクライアント、別の接続ではサーバーとして振る舞うことがある」と書くとおり、役割は接続ごとに決まるもので、機械ごとに固定されたものではありません。クライアントサーバシステムの仕組みでは、2層と3層の違いやP2Pとの比較を具体例で示しています。

モノリシックの一体デプロイとモジュラモノリスの境界

全機能を1つのアプリケーションとしてビルドし、1つの単位でデプロイする方式です。アプリケーション内部の機能間の呼び出しはプロセス内で完結するので、内部の通信遅延や部分的な通信障害を考えずに済み、デプロイの単位も1つで足ります（データベースや外部APIとの通信は残ります）。代償は、注文処理だけ負荷が高くても全体を増やすしかないことと、コードの境界が崩れやすいことです。

後者への対策が、1つのデプロイ単位のまま内部をモジュールに厳密に区切るモジュラモノリスです。モジュール間の依存をCIで検査して境界の崩れを止める方法は、モジュラモノリスのモジュール境界設計で実装例とともに示しています。

マイクロサービスアーキテクチャの独立デプロイと分散の代償

James LewisとMartin Fowlerは2014年3月に分載した記事（3月10日初回、25日完結）で、マイクロサービスを「1つのアプリケーションを小さなサービスの集まりとして開発する手法で、各サービスは自分のプロセスで動き、軽量な仕組み（多くの場合はHTTPのリソースAPI）で通信する」と説明し、サービスは業務の機能ごとに作られ、自動化されたデプロイの仕組みで独立してリリースできるとしています。

チームごとに独立してリリースでき、負荷の高いサービスだけを増やせるのが利点です。その代わり、サービス間の通信障害、サービスをまたぐトランザクション、ログと監視の分散といった分散システム特有の課題を引き受けます。サービスをまたぐ整合性は、結果整合性と取り消し処理（補償）を業務として許容できるなら、Sagaパターンの補償トランザクションが選択肢になります。モノリスとの損得を並べた比較はマイクロサービスとモノリスの違いにあります。

イベント駆動アーキテクチャの疎結合と整合性管理

「注文が確定した」といった出来事（イベント）を発行し、関心のある処理がそれを購読して動く方式です。発行側は誰が受け取るかを知らないので、在庫引当・メール送信・ポイント付与を後から足しても注文処理のコードは変わりません。キューが間に入るため、アクセスが集中しても処理を後ろにずらして受け止められます。

代償は、処理の順序と整合性をアプリケーション側で管理する必要があることです。たとえばAmazon SQSの標準キューは、少なくとも1回の配信（at-least-once）を保証する代わりに、同じメッセージが複数回届くことや順序が入れ替わることがあると公式ドキュメントに明記しています。同じイベントが2回届いても結果が変わらない作り（冪等性）や、失敗したイベントの退避先を最初から設計しておかないと、障害時に原因を追えなくなります。イベントを起点に関数を動かす構成を選ぶなら、サーバーレスとコンテナの使い分けも判断材料になります。

システムアーキテクチャ設計の進め方：非機能要件から方式の決定まで

設計は次の5段階で進めます。方式の名前から入らず、要件と優先順位を先に固めるのが要点です。

1. 非機能要件を洗い出す
2. 品質特性の優先順位と数値目標を決める
3. 優先する特性に有利な方式を選び、代償を確かめる
4. 評価にかけて、トレードオフとリスクを書き出す
5. 判断の理由をADRに記録する

非機能要件の洗い出し：IPA非機能要求グレードの6大項目

方式を左右するのは、機能の一覧より「何時間止まってよいか」「何人が同時に使うか」といった非機能要件です。洗い出しの抜けを防ぐ道具に、IPAの非機能要求グレードがあります。可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6大項目の下に238のメトリクス（2018年版）を並べ、項目ごとに段階的なレベルを発注者と合意する形式です。IPAの同事業は2009〜2018年度に実施されて終了しており、資料はアーカイブとして公開が続いています。レベルの選び方とグレード表の読み方はIPAの非機能要求グレードの6大項目とグレード表で説明しています。

品質特性の優先順位付け：ISO/IEC 25010:2023の9特性

洗い出した要件を、「このシステムで何を最優先するか」の順に並べます。ものさしには、ICT製品とソフトウェア製品の品質モデルを定めたISO/IEC 25010が使えます。2023年11月発行の第2版は、機能適合性、性能効率性、互換性、インタラクション能力、信頼性、セキュリティ、保守性、柔軟性、安全性の9特性です。2011年版からの主な変更点は、安全性の追加、使用性がインタラクション能力に、移植性が柔軟性に置き換わったこと、そしてスケーラビリティが柔軟性の副特性として加わったことです。副特性まで含めた一覧はISO/IEC 25010の9品質特性と副特性にあります。

予算と納期の制約の中で、9特性すべてを最高の水準にはできません。「年に数回しか変更しないがデータ不整合は許されない会計システム」と「毎週機能を足すECサイト」では、上位に来る特性が違います。上位2〜3特性を決め、それぞれに「ピーク時に毎秒何件」「月間停止何分以内」のような数値の目標を付けてから次の手順に進みます。目標値の決め方と負荷試験での確かめ方は、非機能要件の数値化の手順が使えます。

優先する品質特性と有利な方式の対応

優先度の高い特性が決まったら、有利な方式とその代償を突き合わせます。

表の右列が判断の本体です。たとえば信頼性を優先してイベント駆動を選ぶと、「画面で注文直後に在庫数が古いまま見える」状態を業務として許容できるかという問いが残ります。許容できないなら、その部分だけ同期処理に戻す判断になります。

ATAMによるトレードオフとリスクの評価

方式を決めたら、作り込む前に評価にかけます。代表的な手法が、カーネギーメロン大学ソフトウェア工学研究所（SEI）のRick Kazman、Mark H. Klein、Paul C. Clementsが2000年8月の技術報告CMU/SEI-2000-TR-004で示したATAM（Architecture Tradeoff Analysis Method）です。発注者・アーキテクト・利用者・運用担当などの関係者を集め、手法の説明から結果の報告まで9つのステップで、品質特性を具体的なシナリオに落として方式を検証します。

ATAMで書き出すのは、リスク、感度点、トレードオフ点です。感度点は、ある品質特性の結果と強く結びついた設計上のパラメータで、報告書は「1本の通信路の速度」を例に挙げています。その速度を上げるとスループットは上がるが信頼性は下がる、というように1つのパラメータが複数の特性に逆向きに効くなら、それがトレードオフ点です。前の表の右列は、評価で確かめるべきトレードオフの候補です。候補ごとに「ピーク時に在庫照会が5倍になったら」のようなシナリオを当て、どのパラメータが複数の特性に効くのかを特定しておくと、どこで何を諦めたのかが関係者の間で揃います。

判断理由の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へ逃がし、引当の判定は主DBで行う

## Consequences
- 良い点: デプロイと監視の仕組みが1つで済む
- 悪い点: 在庫照会のアプリケーション処理だけを独立して増強できない（DBの読み取りはレプリカで分散する）
- 見直す条件: チームが2つ以上になった時点、または在庫照会の遅延が目標を超えた時点

「見直す条件」を書いておくと、状況が変わったときに判断をやり直すきっかけになります。書き方とテンプレートの比較はADR（アーキテクチャ決定記録）の書き方にまとめています。

マイクロサービスを採用すべきでない条件と失敗例

方式選びでよく語られる失敗が、規模に合わないマイクロサービスの採用です。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つで、サービスごとに担当を分けられない
• 業務の境界がまだ変わる段階で、どこで分けるべきか決められない
• サービスごとのデプロイ、監視、ログ収集を自動化する体制がない
• 一部の機能だけ負荷が突出する、といった部分的な拡張の必要が見えていない

逆に、複数チームがそれぞれ週に何度もリリースし、互いの待ち合わせが開発の遅れの主因になっているなら、分割を検討する時期です。どの業務から切り出すかは、マイクロサービスの向き不向きと判断基準で整理しています。

システムアーキテクチャと関連職種・試験のよくある質問

システムアーキテクチャの具体例は？

一般的なECサイトなら、ロードバランサーの後ろにWebサーバーを複数台置き、アプリケーションサーバーとデータベースを分けた3層構成が土台になります。そのうえで、注文確定後の在庫引当やメール送信だけをキュー経由のイベント駆動にし、商品画像は配信用のCDNから返す、というように複数の方式を組み合わせたもの全体が、そのシステムのアーキテクチャです。

システムアーキテクチャ図とは何ですか？

システムアーキテクチャを表すための図で、ISO/IEC/IEEE 42010でいうアーキテクチャ記述の一種です。サーバーやサービスの配置と接続を描く構成図のほか、C4モデルのように詳しさの段階を分けて描く方法があります。描く手順はアーキテクチャ図の書き方とC4モデルが参考になります。

アプリケーションアーキテクチャとは何ですか？

1つのアプリケーションの内部構造、つまりコードをどの層やモジュールに分け、依存をどちら向きにするかの設計を指すことが多い言葉です。システムアーキテクチャがサーバーやネットワークを含む全体の配置を扱うのに対し、アプリケーションアーキテクチャはその中の1つのプログラムを扱います。MVC、クリーンアーキテクチャ、ヘキサゴナルアーキテクチャなどがこの領域の代表例です。

システムアーキテクトとSE（システムエンジニア）の違いは何ですか？

IPAのシステムアーキテクト試験は、対象者像を「要件を定義し、それを実現するためのアーキテクチャを設計し、開発を主導する者」としています。SEが担う設計・開発のうち、システム全体の構造と方式を決める上流側を専門にする役割と考えると区別しやすくなります。クラウドベンダーの職種名として使われるソリューションアーキテクトとの違いはソリューションアーキテクトの役割と仕事内容を参照してください。

システムアーキテクト試験は国家資格ですか？難易度は？

IPAが実施する情報処理技術者試験の高度試験の1区分で、IPAの試験の概要は情報処理技術者試験を「情報処理の促進に関する法律」に基づき経済産業省が認定する国家試験としています。ただし業務独占の資格ではないので、合格していなくてもアーキテクチャ設計の仕事はできます。2025年度春期の合格発表では、受験者3,963人に対し合格者616人、合格率15.5%でした。2026年度はCBT方式で前期に実施され、科目A-1（50分・30問）、A-2（40分・25問）、B-1（90分・記述式で3問中2問）、B-2（120分・論述式で2問中1問）で構成されます。現行の試験制度は2026年度の実施をもって終了し、2027年度から新制度に移行する予定です。

関連記事

• マイクロサービスとは？モノリスとの違い・メリット・デメリットと選び方、モジュラモノリスまで整理
• 3層アーキテクチャとインテグレーション層とは｜各層の役割とフロントエンド・バックエンドの担当領域
• クライアントサーバとWebシステムの違いとは？仕組み・2層と3層・P2Pとの違いを具体例とコードで解説
• ADR（Architecture Decision Record）とは｜書き方・Markdownテンプレート・design docとの違い
• システム構成図とは？書き方の手順と例・アーキテクチャ図との違いを図解