--- title: "3層アーキテクチャとインテグレーション層とは｜各層の役割とフロントエンド・バックエンドの担当領域" url: "https://www.issoh.co.jp/column/details/2909/" published: 2024-07-03 updated: 2026-07-28 categories: ["Webシステム"] publisher: "株式会社一創" --- # 3層アーキテクチャとインテグレーション層とは｜各層の役割とフロントエンド・バックエンドの担当領域 Webアプリケーションの設計で最初に押さえるのが、処理を役割ごとに分けるレイヤードアーキテクチャです。基本形はプレゼンテーション層・ビジネスロジック層・データ層の3層で、フロントエンドとバックエンドの担当範囲もこの層構造で決まります。さらにJava EE（旧J2EE）系の設計では、業務ロジックとデータの間に「インテグレーション層」を明示的に置き、外部システムやデータベースへの接続をこの層に閉じ込めます。この記事では3層アーキテクチャの各層の役割と構成、インテグレーション層の位置づけ、そして各層をAPIでどうつなぐかを整理します。 ## まとめ：3層アーキテクチャとインテグレーション層の要点 - **3層アーキテクチャ**＝プレゼンテーション層（画面・UI）／ビジネスロジック層（業務処理）／データ層（保存・取得）に責務を分ける構造。層ごとに独立して開発・変更・デプロイでき、保守性とスケーラビリティが上がる。 - **フロントエンドはプレゼンテーション層、バックエンドはビジネスロジック層とデータ層**を担当する。両者の境界はAPI（REST／GraphQL）で結ばれる。 - **インテグレーション層**は、ビジネスロジック層とデータ・外部リソースの間に置く「橋渡し」の層。DAO（Data Access Object）などでデータベースや外部システムへのアクセスを抽象化し、業務ロジックを永続化の詳細から切り離す（Core J2EEパターンのIntegration tier）。 - 3層は今も標準だが万能ではない。小規模なら過剰になり、大規模・高頻度変更ではマイクロサービスへ分割する判断が要る。 ## 3層アーキテクチャとは｜3つの層の役割と構成 3層アーキテクチャ（3-tier architecture）は、Webアプリケーションを役割の異なる3つの層に分けて設計する構造です。ユーザーが触れる画面から、業務の判断、データの保存までを一直線に扱わず、層で区切ることで、どこを直せば何が変わるかを明確にします。各層は上から下へ依存し、下の層は上の層を知りません。 | 層 | 担当 | 主な技術 | フロント/バック | | ---------- | ------------- | ------------------------------------- | -------- | | プレゼンテーション層 | 画面表示・入力受付 | HTML / CSS / JavaScript / React / Vue | フロントエンド | | ビジネスロジック層 | 業務処理・認証・API提供 | Java / Python / Node.js / PHP | バックエンド | | データ層 | データの保存・取得 | MySQL / PostgreSQL / MongoDB | バックエンド | 「web3層構造」「三層webアプリケーション」といった検索で想定されるのはこの構成です。ビジネスロジック層とデータ層はサーバー側で動くためバックエンドがまとめて担い、プレゼンテーション層をフロントエンドが担当します。 ### 3層に分けるメリット 層を分ける最大の利点は、変更の影響範囲が層の内側に収まることです。画面デザインを刷新してもビジネスロジックには手を入れず、データベースをMySQLからPostgreSQLへ替えてもデータ層の実装だけで済みます。層ごとに担当チームを分けられ、フロントエンドとバックエンドを並行して開発できます。負荷が高い層だけをスケールアウトできる点も、モノリシックな作りにはない強みです。 ### 3層アーキテクチャが向かない場面 層分割は無条件に正しいわけではありません。管理画面だけの小規模ツールや、数画面のプロトタイプでは、層の分離とAPI設計の手間がリターンに見合わず過剰設計になります。逆に、チームが数十人規模で機能ごとのリリース頻度が大きく異なるサービスでは、3層のまま単一デプロイを続けると1つの変更が全体のリリースを止めます。この段階に来たら、層ではなく機能単位で分割する[SOAやマイクロサービスへの移行](https://www.issoh.co.jp/column/details/2873/)を検討します。3層かマイクロサービスかは「古い/新しい」ではなく、規模と変更頻度で選ぶ判断です。 ## インテグレーション層とは｜業務ロジックとデータを橋渡しする統合レイヤ インテグレーション層（Integration tier）は、ビジネスロジック層と、データベース・外部システムなどのリソースとの間に置く層です。基本の3層では「データ層」がデータの保存・取得をまとめて担いますが、Java EE（旧J2EE）のCore J2EEパターンでは、この境界をさらに分け、外部リソースへの接続を専門に扱う層としてインテグレーション層を明示します。Oracleの階層モデルでも、ビジネス層とリソース層の間に位置づけられています。 ### インテグレーション層の役割とDAOパターン この層の中心にあるのがDAO（Data Access Object）です。DAOは、データベースへのSQL発行や外部APIの呼び出しといった「どこから・どうやってデータを取るか」の実装を1か所に閉じ込め、ビジネスロジック層には「データを取る/保存する」というインターフェースだけを見せます。これにより、業務ロジックはSQLやDBの種類を知らずに済み、保存先をリレーショナルDBからNoSQLへ替えてもDAOの差し替えだけで対応できます。外部の決済サービスやレガシーシステムとの連携も、この層に寄せることで業務ロジックへの影響を遮断できます。 ### 3層モデルとインテグレーション層を独立させた多層モデルの関係 混同しやすいので層の数で整理します。シンプルな3層モデルは「プレゼンテーション／ビジネスロジック／データ」で、データアクセスはデータ層に含めて考えます。ここにデータアクセス・外部連携を担う層を独立させると、3層＋インテグレーション層で4層になります。さらにクライアント層とリソース層まで切り分けると「クライアント／プレゼンテーション／ビジネス／インテグレーション／リソース」の5ティア（Core J2EEの論理ティア）です。つまりインテグレーション層は、3層の「データ層」から永続化・外部接続の責務を切り出して明示したもの、と捉えると整理しやすくなります。小規模ではデータ層に含め、連携先が増えるほど独立した層として切り出す価値が上がります。 ## プレゼンテーション層（フロントエンド）の担当領域 プレゼンテーション層は、ユーザーが直接操作する画面を担うフロントエンドの領域です。担当は、画面のレイアウトとスタイル、入力フォーム、ボタンやモーダルなどのインタラクションの実装で、HTML・CSS・JavaScriptを基礎に、React・Vue.js・Angularといったフレームワークで構築します。役割は「入力を受け取り、結果を表示する」ことに限られ、業務判断やデータ保存はこの層では行いません。 画面の内部構造をどう組み立てるかでは、Model・View・Controllerに分けるMVCや、その派生のMVVMがよく使われます。設計パターンの使い分けは[MVCとMVVM・MVPの違い](https://www.issoh.co.jp/tech/details/7040/)で整理しています。フロントエンドとバックエンドの役割・言語・体制の分け方は[フロントエンドとバックエンドの違い](https://www.issoh.co.jp/column/details/13169/)を参照してください。 ## ビジネスロジック層（バックエンド）の担当領域 ビジネスロジック層は、アプリの「頭脳」にあたるバックエンドの中核です。担当は、入力値の検証、業務ルールに沿った計算・判断、ユーザー認証と権限管理、そしてフロントエンドへ結果を返すAPIの提供です。サーバーサイドの言語（Java・Python・Node.js・PHPなど）で実装し、データの読み書きはインテグレーション層（DAO）を通してデータ層へ委ねます。 この層の設計では、処理の増加に耐えるスケーラビリティと、認証・入力検証などのセキュリティを最初から織り込みます。「バックエンド アーキテクチャ」で問われるのは、層の責務をここに集中させすぎず、外部連携をインテグレーション層へ、表示をプレゼンテーション層へ正しく振り分けられているかです。 ## 各層の連携とフロントエンド・バックエンドの境界 層に分けた以上、層と層をつなぐ約束事が必要です。フロントエンドとバックエンドの境界は、多くの場合API（Application Programming Interface）で引かれます。プレゼンテーション層はビジネスロジック層のAPIを呼び、必要なデータだけを受け取って画面に反映します。両者が同じAPI仕様を守る限り、フロントエンドとバックエンドは別々のチーム・別々のリリースで開発できます。 API方式は、URLとHTTPメソッドでリソースを操作するRESTと、必要な項目だけをクエリで取得するGraphQLが代表的です。過不足のないデータ取得や、画面ごとに必要な項目が違うケースではGraphQLが向くこともあります。選び方は[GraphQLとREST APIの違い](https://www.issoh.co.jp/tech/details/3591/)で比較しています。リアルタイム性が要る通知やチャットでは、WebSocketなどの常時接続を併用します。境界を曖昧にしたまま実装を進めると、業務判断がフロントエンドに漏れ出し、同じルールをフロントとバックの両方で持つ二重管理に陥ります。「判断はバックエンド、表示はフロントエンド」の線引きは崩さないのが原則です。 ## よくある質問 ### Web3層構造とは何ですか？ Webアプリケーションを、画面を扱うプレゼンテーション層、業務処理を行うビジネスロジック層、データを保存・取得するデータ層の3つに分けた構造です。層ごとに責務を分けることで、変更の影響を局所化し、保守や機能追加をしやすくします。 ### インテグレーション層とデータ層の違いは何ですか？ データ層はデータそのものの保管・取得を指し、インテグレーション層はビジネスロジック層からその保管先や外部システムへアクセスするための「橋渡し」を担います。DAOなどでアクセス方法を抽象化し、業務ロジックがDBの種類や接続方法を意識しなくて済むようにする層です。小規模な設計ではデータ層に含めて扱うこともあります。 ### 3層アーキテクチャは古いのですか？マイクロサービスに置き換わりますか？ 古いという評価は正確ではありません。3層は今も多くのWebアプリで標準です。ただしチーム規模が大きく機能ごとの変更頻度が異なると、単一デプロイが足かせになります。その場合に機能単位で分割するのがマイクロサービスで、置き換えというより規模に応じた選択です。詳細は[SOAとマイクロサービスの違い](https://www.issoh.co.jp/column/details/2873/)を参照してください。 ### フロントエンドとバックエンドの境界はどこですか？ 多くの場合APIが境界です。ユーザーの操作を受けて画面を描くのがフロントエンド、その要求を受けて業務判断とデータ処理を行い結果を返すのがバックエンドです。業務ルールに関わる判断はバックエンドに置き、フロントエンドは表示と入力に専念させるのが基本です。 ### バックエンドにはどんな言語が使われますか？ Java、Python、Node.js（JavaScript）、PHP、Ruby、Go、C#などが代表的です。大規模で堅牢性を重視するならJava、機械学習やデータ処理と組み合わせるならPython、リアルタイム処理やフロントと言語を揃えたいならNode.jsといった具合に、要件で選びます。 ## 関連記事 - [フロントエンドとバックエンドの違いとは？役割・言語・連携と開発発注時の体制設計を解説](https://www.issoh.co.jp/column/details/13169/) - [サービス指向アーキテクチャー（SOA）とマイクロサービスの違いと特徴を徹底解説](https://www.issoh.co.jp/column/details/2873/) - [MVCとは？MVVM・MVPとの違いと使い分けを整理](https://www.issoh.co.jp/tech/details/7040/) - [REST APIとGraphQLの違いと使い分け｜選定基準と運用コスト](https://www.issoh.co.jp/tech/details/3591/) --- 出典: [3層アーキテクチャとインテグレーション層とは｜各層の役割とフロントエンド・バックエンドの担当領域]()（株式会社一創）