はじめに
概要
本記事は、Webアプリケーションで広く使われる「Web 3層構造」について分かりやすく解説します。プレゼンテーション層（見た目・操作）、アプリケーション層（処理・ルール）、データ層（保存）の三つの役割と、それぞれでよく使われる技術例や利点を丁寧に説明します。
なぜ重要か
層を分けることで開発や運用が楽になります。たとえば、画面（プレゼンテーション）を変えてもデータの保存方法に影響を与えません。保守性や拡張性、セキュリティの向上につながります。具体例を交えてイメージしやすく解説します。
誰に向けているか
エンジニア初心者、プロダクト担当者、学生、システム設計を学びたい方など幅広い読者を想定しています。専門用語は最小限にし、具体例で補足します。
本記事の読み方
次章以降で各層を順に詳しく見ていきます。実際の技術例や設計のポイントも紹介しますので、実務や学習にすぐ役立ててください。
Web 3層構造とは何か？基本概念と定義
概要
Web 3層構造は、Webアプリケーションを「プレゼンテーション層」「アプリケーション層」「データ層」の三つに分けて設計・運用する考え方です。各層が果たす役割を明確にすることで、開発や運用がわかりやすくなります。
各層の役割（簡潔に）
- プレゼンテーション層：ユーザーと直接やり取りする部分です。画面表示や入力受付を担当します。例えばウェブページやスマホの画面です。
- アプリケーション層：ビジネスロジックを実行します。入力を処理したり、外部サービスと連携したり、処理のルールを管理します。
- データ層：情報を保存・取得する場所です。データベースやキャッシュが該当します。
なぜ分けるのか
役割を分離すると、個別に改善や拡張ができます。性能問題が出ても原因を特定しやすく、別々のチームで開発しやすくなります。セキュリティ対策も層ごとに集中できます。
身近な具体例
通販サイトを例にすると、商品一覧を表示するのがプレゼンテーション層、在庫確認や注文処理がアプリケーション層、商品情報や注文履歴の保存がデータ層です。
設計の基本原則
- 単一責任：各層は自分の役割だけに集中します。
- 明確なインターフェース：層間のやり取りは決まった契約（APIなど）で行います。
- 再利用性：共通処理はアプリケーション層に集約します。
この章では概念と定義を丁寧に説明しました。次章から各層を詳しく見ていきます。
プレゼンテーション層（Web層・フロントエンド）
役割と特徴
プレゼンテーション層はユーザーが直接触れる入口です。画面表示（UI）の提供、ユーザーからのリクエストの受け付けとルーティング、静的ファイルの配信、SSL/TLS終端などを担います。ここでの働きが利用者の第一印象を決めます。
主な技術例
- HTML/CSS/JavaScript：ページと見た目、動きを作ります。例：ボタンやフォーム。
- フレームワーク：ReactやVue.jsなどでインタラクティブな画面を作ります。
- Webサーバ：NGINXやApacheが静的ファイルやリバースプロキシを受け持ちます。
静的と動的の分担
画像やCSS、JavaScriptなどの静的コンテンツはWebサーバやCDNが直接配信します。動的な情報はアプリケーション層のAPIにリクエストして取得します。ユーザー操作はまずフロントで処理し、必要に応じてバックエンドとやり取りします。
性能・可用性の工夫
キャッシュやCDN、圧縮、画像最適化で表示を速くします。負荷分散で障害に強くします。クライアント側レンダリングとサーバー側レンダリングを状況に応じて使い分けます。
ユーザビリティとアクセシビリティ
レスポンシブ設計で画面サイズに対応します。キーボード操作やスクリーンリーダー向けの配慮（ラベル、色のコントラスト）も重要です。
セキュリティと運用のポイント
HTTPSを常時有効にし、XSS対策やContent Security Policyを導入します。CORSやCookieの設定も注意します。ビルドやデプロイはCI/CDで自動化し、監視とログで問題を早期検知します。
アプリケーション層（ビジネスロジック層・バックエンド）
概要
アプリケーション層は動的な処理を担う部分です。Webサーバからの要求を受け、業務ルールに従ってデータを加工し、結果をプレゼンテーション層へ返します。一般的にはJava、Python、Node.jsなどで実装し、外部から直接触れられないプライベート領域に配置します。
主な役割
- リクエスト受信とルーティング：どの処理を実行するか判断します。
- ビジネスロジック実行：注文処理や料金計算などの業務ルールを処理します。
- データ検証：入力の妥当性をチェックします。
ユーザー認証とアクセス制御
ログイン時にトークンを発行し、そのトークンでAPIの利用可否を判断します。権限によって操作を制限し、不正アクセスを防ぎます。
具体例（注文処理）
- 注文受信：注文情報を受け取る。2. 在庫確認：データ層へ在庫問い合わせ。3. 価格計算・割引適用：ビジネスルールで計算。4. 決済連携：外部サービスへ送信。5. 結果通知：フロントへ応答。
API設計と通信
RESTやGraphQLでエンドポイントを提供します。入力は最小限にし、エラーは分かりやすく返します。APIはプレゼンテーション層だけでなく、他サービスからも利用されます。
非同期処理とキャッシュ
時間がかかる処理はキューで非同期に実行します。頻繁に使うデータはキャッシュし応答を早めます。
セキュリティと配置
アプリケーション層はファイアウォール内に置き、通信は暗号化します。ログ記録と監査を行い、不正な振る舞いを早期に検知します。
テストと運用
ユニットテストでロジックを検証し、統合テストで外部連携を確認します。モニタリングで性能とエラーを常時監視します。
データ層（データベース層）
概要
データ層は永続的な情報を保存する場所です。ユーザー情報やトランザクション、設定などを長期的に保管します。WebアプリではAP（アプリケーション）サーバからのみアクセスする、プライベートな領域に置きます。
主なデータベースの種類と使い分け
- リレーショナル（例：MySQL、PostgreSQL）: 表形式で整ったデータに向きます。トランザクションや整合性が重要な場合に選びます。
- NoSQL（例：DynamoDB、MongoDB）: 柔軟なスキーマや大規模な読み書きに強いです。ログやセッション、JSON型データに便利です。
保存と取得の基本
アプリ側はCRUD（作成・読み取り・更新・削除）操作をAPI経由で行います。クエリは効率を考えて設計し、必要な項目だけ取得することが重要です。簡単な例として、ユーザーIDで検索してプロフィールを取得します。
セキュリティと運用
データは暗号化やアクセス制御で保護します。バックアップやレプリケーションで可用性を確保し、監視で異常を早く検知します。マイグレーションやスキーマ変更はテスト環境で検証してから本番反映します。
パフォーマンス向上の手法
インデックスで検索を速くし、キャッシュ（例：Redis）で頻繁に使うデータを保持します。読み取り負荷にはリードレプリカ、書き込み負荷にはシャーディングで対応します。
実務でのポイント
運用しやすいスキーマ設計、適切なバックアップポリシー、定期的な性能チェックが重要です。ログやアクセス履歴を残してトラブル時に原因を追跡できるようにします。
Web 3層構造の利点と効果
モジュール化と再利用性
各層が明確に分かれるため、部品を切り離して使えます。例えば、認証機能をアプリケーション層に実装すれば、複数のフロントエンド（Web・モバイル）で共通利用できます。UIを変えてもビジネスロジックは影響を受けにくく、再利用が進みます。
保守性と拡張性の向上
変更箇所が限定されるため、バグ修正や機能追加の影響範囲が小さくなります。データ量が増えればデータ層だけをスケールする、負荷が高ければアプリ層にサーバを追加する、といった柔軟な対応が可能です。
開発プロセスの効率化
役割分担しやすく、フロントエンドとバックエンドを別々のチームが並行して開発できます。CI/CDや自動テストを層ごとに整備するとリリースの信頼性が高まります。
負荷分散とパフォーマンス改善
キャッシュやCDNをプレゼンテーション層に置き、重い処理をアプリ層に集約することで全体の応答性が上がります。データ層はレプリケーションやシャーディングで対応できます。
障害の隔離とセキュリティ
一つの層で問題が起きても他の層に波及しにくく、原因特定が容易です。認証や入力検証を各層で役割分担すれば防御が強化されます。
全体として、3層構造は変更へ強く、開発と運用を効率化する設計法です。
