システムを作るとき、いきなりコードを書き始めるわけではありません。まず「どんな構造で作るか」という大枠の設計図が必要です。それを担うのがシステムアーキテクチャ設計です。
対象試験と出題頻度
システムアーキテクチャ設計は、基本情報技術者・応用情報技術者で出題されるテーマです。
処理形態（集中処理・分散処理）、システム構成（デュプレックス・デュアル）、3層クライアントサーバなど、複数の論点が組み合わさって出題されます。
特に応用情報の午後問題では「システムアーキテクチャ」として独立した大問が用意されており、配点も大きい重要分野です。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★☆☆
ランクB（標準）覚えておくと有利
用語の定義
情報処理試験を勉強していると、「システムアーキテクチャ設計って結局何を決める作業なの？」と混乱しがちです。
システムアーキテクチャ設計（System Architecture Design）とは、一言で言うと
「システム全体の骨組み（処理形態・構成・配置）を決める設計工程」
のことです。
イメージとしては、「家を建てるときの基本設計図」です。
家を建てるとき、いきなり壁紙の色を選んだりはしません。
先に「平屋にするか2階建てか」「鉄骨か木造か」「水回りはどこに置くか」といった大枠を決めます。これが基本設計です。壁紙やドアノブの選定（詳細設計）はその後の話です。
システムも同じで、「集中処理にするか分散処理にするか」「サーバを何台用意するか」「層をいくつに分けるか」といった土台部分を最初に決めます。
この土台がしっかりしていないと、後から個別機能をどれだけ作り込んでも全体がうまく機能しません。
📊 システムアーキテクチャ設計の基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | System Architecture Design |
| 分類 | テクノロジ系 / 開発技術 |
| 主な利用工程 | システム方式設計・基本設計 |
| 主な論点 | 処理形態、システム構成、層構造、信頼性設計 |
解説
システムアーキテクチャ設計で決めるべき論点は、大きく3つに整理できます。
「処理を1か所に集めるか分けるか（処理形態）」「サーバを何台でどう冗長化するか（システム構成）」「機能をどう層に分けるか（層構造）」です。
論点1：処理形態（集中処理 vs 分散処理）
処理を1台のホストに集約するのが集中処理、複数台に分散させるのが分散処理です。
クライアントサーバ方式は分散処理の一種で、要求を出すクライアントと処理を担うサーバに役割を分けます。
集中処理
（1台で
全処理）
○ 長所：管理が容易／セキュリティ確保しやすい
× 短所：ホスト故障で全停止／負荷集中
分散処理
○ 長所：負荷分散／障害の影響範囲を限定
× 短所：管理が複雑／整合性確保が難しい
▲ 集中処理は要求が1台に集まる／分散処理は要求が複数サーバに分かれ、サーバ同士も連携する
論点2：システム構成（信頼性を高める冗長化）
1台で動かすか、2台で備えるか。冗長化の度合いによって名称が変わります。試験ではこの区別が頻出です。
| 構成名 | 特徴 | 身近な例え |
|---|---|---|
| シンプレックス | 1系統のみ。故障すると停止する最小構成 | 予備のない1台のPC |
| デュプレックス | 主系（オンライン処理）と待機系（普段はバッチ等）の2系統。故障時に切り替える | 控えの選手がいるサッカーチーム |
| デュアル | 2系統が常に同じ処理を実行し、結果を照合する | 2人で同じ計算をして答え合わせ |
| ホットスタンバイ | 待機系も常に起動状態。瞬時に切替可能 | エンジン起動済みの救急車 |
| コールドスタンバイ | 待機系は停止状態。故障時に起動して切替 | 倉庫にしまった予備機 |
論点3：3層クライアントサーバ
機能を3つの層に論理的に分割する構成方式です。Webアプリケーションのほぼ全てがこの形を採用しており、試験でも頻出論点です。
🏗️ 3層クライアントサーバの構造
① プレゼンテーション層
画面表示・入力受付（ブラウザ／クライアント側）
② ファンクション層（アプリケーション層）
業務処理・データ加工（APサーバ）
③ データベースアクセス層
データ保存・検索（DBサーバ）
▲ 各層が独立しているため、片方の変更が他層に影響しにくい
層を分ける最大の利点は「独立性」です。例えば画面デザインを変えてもDBには影響せず、DB製品を切り替えても画面側は無修正で済みます。保守性と拡張性が大きく向上します。
論点4：シンクライアントとシッククライアント
クライアント端末にどこまで処理を持たせるかの設計判断です。
業務システム設計では情報漏洩対策の観点から特に重視されます。
| 方式 | 端末側の役割 | 主な狙い |
|---|---|---|
| シンクライアント | 画面表示と入力のみ。処理・データはサーバ側 | 情報漏洩防止、運用集中管理 |
| シッククライアント | 処理・データを端末側でも保持 | レスポンス向上、オフライン稼働 |
💡 全体像を3行で
・処理形態（集中／分散）でシステムの性格が決まる
・冗長構成（シンプレックス／デュプレックス／デュアル）で信頼性が決まる
・3層構造で保守性・拡張性が決まる
では、これらの論点が試験でどのように出題されるか見ていきましょう。
試験ではこう出る！
システムアーキテクチャ設計は、FE・APの午前で「個別構成方式の説明問題」として、APの午後では「最適な構成を選ぶ記述問題」として出題されます。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| AP H26春 午前 問12 |
3層クライアントサーバの説明として正しいものを選ぶ問題。 | プレゼンテーション層・ファンクション層・データベースアクセス層の3層に分けることが正解。 |
| FE R4免除 問16 |
3層C/Sにおける各層の役割を問う問題。 | 「Webサーバ・FW・クライアント」のような物理構成を答えさせるひっかけが頻出。 |
| FE H23秋 問15 |
システム構成と稼働率に関する問題（デュプレックス／デュアルの区別）。 | 「常に同じ処理を実行＝デュアル」「待機系がある＝デュプレックス」の判別。 |
| AP R5秋 午後 問4 |
企業統合に伴うシステム統廃合の設計を問う記述問題。 | 業務要件から最適な配置を導き出す力。論述形式。 |
| AP R6秋 午後 問4 |
データ処理機能の配置に関する記述問題。 | 機能をクライアント／サーバのどちら側に置くべきかの判断根拠。 |
📝 IPA試験での出題パターン
パターン1：「3層C/Sの説明を選べ」
「Webサーバ・FW・クライアント」「アプリ・Web・DBの物理サーバ構成」など、物理的な分け方をさせるひっかけが頻出。正解は必ず論理的な機能分割（プレゼンテーション／ファンクション／データベースアクセス）です。
パターン2：「冗長構成の名称を選べ」
「常に同じ処理を実行する＝デュアル」「主系・待機系がある＝デュプレックス」「待機系が起動済み＝ホットスタンバイ」のキーワード対応で解けます。
パターン3：午後の記述問題（AP）
R5秋・R6秋のように「システム統合」「機能配置」を題材にした論述。要件を読み取り、集中／分散の判断、層構造、信頼性のトレードオフを根拠とともに記述する力が問われます。
試験ではここまででOKです。EAやTOGAFのようなアーキテクチャフレームワークまでは深追い不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. 3層クライアントサーバシステムの説明として、最も適切なものはどれでしょうか？
- A. システムを物理的にWebサーバ、ファイアウォール、クライアントの3階層に分けたシステムである。
- B. システムを機能的にプレゼンテーション層、ファンクション層、データベースアクセス層の3つに論理分割した構成である。
- C. 主系と待機系の2系統で構成し、両方が常に同じ処理を実行して結果を照合する構成である。
正解と解説を見る
正解：B
解説：
3層クライアントサーバは「論理的な機能分割」がポイントです。画面処理（プレゼンテーション層）、業務処理（ファンクション層）、データベースアクセス（データベースアクセス層）に分け、各層を独立させることで保守性と拡張性を高めます。
選択肢Aは物理的なネットワーク機器の構成を述べたもので、3層C/Sの説明としては不適切です（典型的なひっかけ選択肢）。選択肢Cはデュアルシステムの説明で、信頼性を高めるための冗長構成方式の一種です。
よくある質問（FAQ）
Q. システムアーキテクチャ設計とソフトウェアアーキテクチャ設計は何が違いますか？
スコープが違います。前者はハードウェア配置・ネットワーク・サーバ構成までを含めたシステム全体の骨組みを決める工程で、後者はソフトウェア内部の構造（モジュール分割やデザインパターンの適用方針）を決める工程です。応用情報の午後問4は前者、問8（情報システム開発）は後者寄りの観点で出題される傾向があります。
Q. 3層C/Sは必ず3台のサーバが必要ですか？
必要ではありません。3層は「論理構造」の話なので、1台のサーバ上にプレゼンテーション層・ファンクション層・DB層を同居させても3層C/Sと呼べます。逆にファンクション層を10台のAPサーバで負荷分散しても、論理的には1層分です。物理台数と論理層数を切り離して考えるのが試験対策の肝です。
Q. クラウドネイティブやマイクロサービスは試験範囲ですか？
基本情報・応用情報の午前ではキーワードレベルで登場します。マイクロサービスは「機能ごとに小さなサービスに分割し、独立してデプロイ可能にする分散アーキテクチャ」と理解しておけば十分です。深い実装知識は高度試験（システムアーキテクト）の範囲なので、FE/APでは概要把握で割り切ります。
Q. デュアルシステムとホットスタンバイの違いは何ですか？
処理の実行方法が違います。デュアルは2系統が常時並行で同じ処理を行い結果を照合します。ホットスタンバイは2系統のうち主系だけが本番処理を行い、待機系は起動状態のまま待機します。デュアルは結果照合により誤りを検出できる一方コストが高く、ホットスタンバイは切替が瞬時にできるためバランス型です。
Q. 実務で構成方式を選ぶときの判断基準は？
主に「停止できる時間（RTO）」「データ損失の許容量（RPO）」「コスト」の3点で決めます。停止が許されない金融系はデュアルやホットスタンバイ、夜間バッチで復旧可能な社内システムはコールドスタンバイで十分、という判断軸です。応用情報の午後では、与えられた業務要件からこの判断軸を使って根拠を述べる力が問われます。
