システムアーキテクチャとは？3層構造から発注者が知るべき設計の基礎

ベンダーから提出されたシステム構成図を眺めながら、「これで本当に大丈夫なのだろうか」と感じたことはないでしょうか。四角と矢印で描かれた図を前に、何を質問すればよいのかが分からず、結局「お任せします」と言ってしまう。発注者としてよくある悩みです。

しかし、システムアーキテクチャの妥当性は、リリース後の運用コスト・拡張性・障害発生時の影響範囲を左右する重要な意思決定です。ここを発注者がブラックボックス化したまま進めると、数年後に「拡張しようとしたら作り直しが必要」「障害が起きたら全停止する設計だった」といった事態に直面することになります。

幸いなことに、発注者がアーキテクチャの妥当性を判断するために、エンジニアと同じ深さの知識は必要ありません。基本的な構造（3層アーキテクチャ）と、構成図の読み方の勘所を押さえれば、「どこを質問すべきか」「どこに将来リスクがあるか」を見極めることができます。

本記事では、システムアーキテクチャの基本概念から、最も古典的で応用範囲の広い3層アーキテクチャの考え方、構成図を読むときに発注者が見るべきポイント、そしてアーキテクチャレビューで必ず確認すべき項目までを解説します。技術用語は最小限に抑え、ビジネス意思決定に必要な視点で整理しました。

システムアーキテクチャとは何か

システムアーキテクチャとは、システムを構成する要素（サーバー・データベース・通信経路など）と、それらの関係性を表した「設計の全体像」のことです。建築でいえば、間取り図と構造図を合わせたようなものに該当します。

ITシステムは、表に見える画面（UI）の裏側で、複数のソフトウェアやサーバーが連携して動いています。アーキテクチャは、この「裏側の設計思想」を可視化したもので、以下の問いに答える役割を持ちます。

• ユーザーからのリクエストはどのように処理されるのか
• データはどこにどのような形で保存されるのか
• 障害が起きたときに、どこまで影響が及ぶのか
• 利用者が増えたときに、どこを増強すれば対応できるのか

なぜ発注者がアーキテクチャを理解すべきか

「設計はベンダーに任せればよい」という考え方も一見合理的ですが、実際にはアーキテクチャの選択がビジネス判断と直結する場面が多くあります。例えば以下のような決断は、アーキテクチャの構造に大きく依存します。

• 将来、別の業務システムと連携させたい
• ユーザー数が10倍になったときに耐えられるようにしたい
• 一部の機能だけを別ベンダーに引き継ぎたい
• 海外拠点でも同じシステムを使いたい

これらの要望に対応できるかどうかは、初期のアーキテクチャ設計で大半が決まります。後から変更しようとすると、最悪の場合「作り直し」になるため、発注時点で発注者自身が大枠を理解しておく必要があります。

アーキテクチャと「システム構成図」の違い

実務で混同されがちですが、アーキテクチャは「設計思想」、システム構成図は「その設計を絵にしたもの」です。同じシステムでも、目的に応じて複数の構成図が存在します。

ベンダーが「構成図を提出しました」と言ってきたとき、それがどの種類の図なのかを確認するだけでも、議論の解像度が大きく上がります。

3層アーキテクチャ（プレゼンテーション層・ロジック層・データ層）

アーキテクチャを学ぶ最初のステップとして最も有用なのが、3層アーキテクチャです。1990年代から普及した古典的な設計パターンで、現代のWebシステム・業務システム・クラウドシステムのほぼすべてが、何らかの形でこの3層構造をベースにしています。

3層アーキテクチャでは、システムを以下の3つの役割に分けて設計します。

プレゼンテーション層（表示・入力を担当）

ユーザーが直接触れる部分を担当する層です。Webブラウザに表示される画面、スマートフォンアプリの画面、ボタンやフォームなどが該当します。

• 役割: ユーザーからの入力を受け取り、結果を分かりやすく表示する
• 代表的な技術: HTML / CSS / JavaScript / React / Vue.js
• 発注者の関心: UI/UXの使いやすさ、レスポンシブ対応（PC・スマホ両対応）

ロジック層（業務処理を担当）

「アプリケーション層」「ビジネスロジック層」とも呼ばれます。システムの「頭脳」に当たる層で、業務ルールに基づく処理を行います。

• 役割: 入力された情報を受け取り、業務ルールに従って処理し、結果を返す
• 処理の例: 「申請額が10万円を超えたら部長承認を必須にする」「在庫が3個以下になったら自動発注メールを送る」
• 代表的な技術: Node.js / Python / Java / Ruby on Rails
• 発注者の関心: 業務フローが正しく実装されているか、変更が容易か

データ層（データの保管を担当）

データベースを中心に、データの保存・検索・更新を担当する層です。

• 役割: 顧客情報・取引履歴・在庫データなどを永続的に保存し、必要に応じて取り出す
• 代表的な技術: PostgreSQL / MySQL / MongoDB
• 発注者の関心: データのバックアップ体制、個人情報の保護、データの所有権

データ層の選定や設計はシステムの根幹に関わるため、発注前に基礎を押さえておくと議論がスムーズです。データベースの基本的な分類についてはデータベースとはで詳しく解説しています。

3層に分ける3つの理由

なぜわざわざ3層に分けるのか。発注者の視点で見ると、以下の3つの実利があります。

1. 変更の影響範囲を限定できる: 画面のデザインを変えるとき、業務ロジックやデータベースに手を入れずに済む
2. 役割分担がしやすい: フロントエンド担当とバックエンド担当が並行作業できるため、開発スピードが上がる
3. 将来の拡張・置き換えが容易: データベースを別製品に変えたり、スマホアプリを後から追加したりしやすい

逆に、3層に分かれていない（一体化した）設計の場合、これらの利点が失われます。構成図を見て「層が混ざっている」場合は、変更コストが高くなる可能性があるため、ベンダーに設計の意図を確認すべきです。

モノリスとマイクロサービス

3層アーキテクチャを発展させた設計として、近年はマイクロサービスという選択肢もよく登場します。3層を1つの大きなアプリ（モノリス）として作るか、機能単位に分割した小さなアプリ群として作るかという選択です。発注時に「マイクロサービスにしましょう」と提案されることもあるため、違いを把握しておくとよいでしょう。詳しくはマイクロサービスとモノリスの違いを参照してください。

システム構成図の読み方：発注者が押さえる5つのポイント

ベンダーから提出された構成図を、発注者として読み解くための実践的なチェックポイントを紹介します。技術的な詳細を理解する必要はありません。「どこを見れば質問が生まれるか」を押さえることが目的です。

ポイント1: 矢印の向きと意味を確認する

構成図の矢印は、通常「データやリクエストの流れ」を示します。以下の質問をベンダーに投げかけてみましょう。

• この矢印は、誰が誰を呼び出しているのか
• 矢印が双方向の場合、どのようなやり取りが行われるのか
• 外部システムとつながっている矢印はあるか（あれば、どのデータが出入りするか）

特に、社外システムや外部APIとつながる矢印は、情報漏えい・依存リスクの観点で重要です。

ポイント2: 「箱」の単位とスケール感を把握する

構成図に描かれた1つの「箱」が何を表すかを確認します。サーバー1台なのか、機能のまとまりなのか、コンテナ1つなのかで、スケールアウト（増強）の単位が変わります。

• 利用者が10倍になったとき、どの箱を増やせばよいのか
• 障害が1つの箱で起きたとき、影響はどこまで及ぶのか
• 冗長化（同じ箱が2つ以上配置）されている箇所はどこか

ポイント3: データの保管場所と暗号化を確認する

データ層に該当する部分（データベース・ストレージ）について、以下を確認します。

• どの国・どのリージョン（地域）に保存されるのか
• 通信経路と保管時にデータが暗号化されているか
• バックアップは何世代保持され、復元手順は文書化されているか

特にBtoCサービスや個人情報を扱うシステムでは、データ保管場所が法令対応に直結します。

ポイント4: 「単一障害点」がないか確認する

単一障害点（SPOF: Single Point of Failure）とは、「そこが壊れるとシステム全体が止まる」箇所のことです。構成図上で1つしか描かれていない箱があれば、その箱が止まったときの影響をベンダーに確認しましょう。冗長化が必要かどうかは、業務の停止許容時間（RTO）とコストのバランスで判断します。

ポイント5: 凡例と前提を確認する

意外と見落とされがちですが、構成図には凡例（記号の意味）と前提条件が明記されているべきです。これらが省略された図は、読み手によって解釈がずれる温床になります。「凡例をください」「前提となるユーザー数・トラフィック量を教えてください」と質問するだけで、設計の透明性が一段上がります。

クラウドアーキテクチャとオンプレミスの選択

近年のシステム開発では、クラウド（AWS・Google Cloud・Azureなど）を前提とした設計が主流です。一方で、業界規制やレガシー資産との連携の都合で、オンプレミス（自社設備で運用）が選ばれるケースも残っています。両者の違いを発注者の視点で整理します。

クラウドアーキテクチャの特徴

クラウドサービス事業者が提供するインフラ上にシステムを構築する方式です。

• 長所: 初期投資が小さい / 利用量に応じて柔軟に増減できる / 災害対策が標準で組み込まれている
• 短所: 月額の運用費が継続的に発生 / 事業者依存（ベンダーロックイン）が起きやすい / 通信遅延が出るケースがある

クラウドの長所を最大限に引き出すには、クラウドの仕組みに合わせた設計（クラウドネイティブ設計）が必要です。

オンプレミスの特徴

自社の所有する物理サーバーやデータセンター設備上にシステムを構築する方式です。

• 長所: 既存の社内システムとの統合が容易 / 物理的なデータ管理が可能 / 長期利用ではコストが下がるケースがある
• 短所: 初期投資が大きい / 拡張に時間がかかる / 災害対策を自前で構築する必要がある

ハイブリッド・マルチクラウドという選択肢

最近は「業務データはオンプレミス、Webフロントはクラウド」のように、両者を組み合わせるハイブリッド構成や、複数のクラウド事業者を併用するマルチクラウド構成も増えています。これらの構成では、両環境を結ぶ通信経路の設計が複雑になるため、構成図のレビュー時にとくに注意が必要です。

サーバーレスとコンテナの位置付け

クラウド前提のシステムでは、「サーバーレス」「コンテナ」という選択肢が登場します。これらはサーバーの管理方法と利用形態の選択であり、3層アーキテクチャと組み合わせて使う技術です。ベンダーから提案されたときは、その選択理由と運用負荷の変化について確認するとよいでしょう。

アーキテクチャ設計レビューで発注者が確認すること

ベンダーからアーキテクチャ案が提出されたとき、発注者として最低限確認すべき項目をチェックリスト形式で整理します。すべての項目をエンジニアと同じ深さで理解する必要はなく、「答えが返ってくるか」「ベンダーが整理して説明できるか」を見ることが目的です。

ビジネス要件との整合性

• 想定ユーザー数・取引量に対して、構成は妥当か
• 業務フローの主要なパターンが、すべてアーキテクチャ上で実現可能か
• 業務時間外のメンテナンス時間は確保できるか

拡張性・将来対応

• 利用者が3倍・10倍になったときの増強方法と概算コスト
• 機能追加（例: 別事業の取り込み）が起きたときの拡張方針
• 他システムとの連携を後から追加する余地があるか

信頼性・可用性

• 単一障害点はどこにあるか、冗長化の方針は何か
• 障害発生時の検知・通知の仕組み
• 復旧目標時間（RTO）と復旧目標地点（RPO）の合意

セキュリティ

• 個人情報・機密情報がどこに保管され、誰がアクセスできるか
• 通信経路と保管時の暗号化方針
• 認証・認可の仕組み（誰がログインでき、何が操作できるか）

運用・保守

• 監視・ログ収集の仕組み
• バックアップ・復元の手順と検証頻度
• 月次の運用工数とランニングコストの見積もり

コストと依存

• クラウド利用料の月額見積もり（ピーク時・平常時）
• 特定ベンダーや特定製品への依存度
• 技術選定の理由（なぜその言語・フレームワーク・データベースを選んだのか）

レビューを進めるコツ

これらの項目を一度にすべて確認しようとすると、ベンダー・発注者の双方が疲弊します。実務では以下のように段階を分けて進めるのが有効です。

1. 要件定義時: ビジネス要件との整合性 / 拡張性
2. 基本設計時: 信頼性 / セキュリティ / コスト
3. 詳細設計時: 運用・保守 / 詳細な技術選定

まとめ

システムアーキテクチャは、エンジニアだけのものではなく、発注者が意思決定に関与すべき重要な領域です。本記事の要点を整理します。

• システムアーキテクチャは「システム全体の設計思想」であり、構成図はその可視化
• 古典的な3層アーキテクチャ（プレゼンテーション層・ロジック層・データ層）を理解すると、ほとんどのシステムが読み解ける
• 構成図を読むときは、矢印の向き・箱のスケール感・データ保管場所・単一障害点・凡例の5つを確認する
• クラウドとオンプレミスは長短があり、業務要件・規制・コストで選び分ける（ハイブリッド構成も選択肢）
• アーキテクチャレビューでは「ビジネス整合性・拡張性・信頼性・セキュリティ・運用・コスト」の6カテゴリで質問する
• すべてを技術的に理解する必要はなく、「ベンダーが整理して説明できるか」を見ることが発注者の役割

アーキテクチャの妥当性は、リリース後の運用コスト・拡張性・障害影響を左右します。提出された構成図を「お任せ」にせず、本記事のチェックポイントを片手に質問を投げかけてみてください。たった数回のやり取りで、設計の透明性とベンダーとの信頼関係は大きく前進します。発注者としての一歩を、まずは「構成図の凡例をください」と尋ねるところから始めてみましょう。