フロントエンドとバックエンドはどう“切る”？設計方針と責務の違いを整理する

システム設計で頻繁にぶつかる悩みのひとつが、「どこで、どのように分けるか？」という"分割"の問題です。

こうした悩みの背景には、フロントエンドとバックエンドでは"設計の前提"がそもそも違うため、分割の考え方や判断基準も異なるという事実があります。

本記事ではこの違いを明らかにし、それぞれの構成に合った分割と設計の考え方を紹介します。

フロントエンドとバックエンドは何が違う？

構成上の責務の違い

まず、フロントエンドとバックエンドの分担を考えるために、ソフトウェアシステムが一般的にどういった構造で成り立っているかを整理します。

ソフトウェアシステムを構成する基本的な要素は次の3つです。

• プレゼンテーション層: UI などのシステムの入出力
• ビジネスロジック層: 主要な機能やルールを実装したデータの処理や計算
• データアクセス層: データの永続化と取得

昔ながらのモノリシックなアーキテクチャでは、このすべての要素がひとつのシステムで構成されていました。

しかし現在では、UI の複雑化やユーザー体験の重要性の高まりにより、プレゼンテーション層だけを独立したシステム、つまりフロントエンドとして構成することが増えています。

これは、プレゼンテーション層が技術スタックや重要視する品質、開発チームなど、バックエンドとはまったく異なる前提で設計・運用されるようになったためです。

またビジネスロジックやデータアクセスと比較して、UI の改善やパッケージの更新が頻繁に起こるため、プレゼンテーションのみの変更が多発します。

つまり、プレゼンテーションは単なる UI 実装ではなく、独立したアプリケーション（=サブシステム）として扱う設計上の意味があるのです。

この観点で見ると、フロントエンドは主にプレゼンテーション層を、バックエンドはビジネスロジックとデータアクセス層を担います。

昨今のシステムでは、バックエンドはビジネスの責務ごとにマイクロサービス化されています。そのため、フロントエンドは複数の独立したバックエンドに対する「窓口」のような役割を果たします。

責務が異なれば設計の単位や粒度も変わります。つまり、構成上の"立ち位置"がそもそも異なるのです。

求められる品質特性の違い

フロントエンドとバックエンドの“切り方”が異なるのは、責務の違いだけではありません。

それぞれに求められる品質特性も設計判断に大きな影響を与えます。

例えば、フロントエンドでは「UI の応答性」「ユーザー体験の一貫性」「見た目や操作性の柔軟な改善」などが重視されます。一方、バックエンドでは「ビジネスロジックの正確性」「データの整合性」「システム全体の保守性や拡張性」などが重要視されます。

このように、どの品質を優先するかによって、システムの構成や分割の仕方も変わってきます。フロントエンドとバックエンドで異なる品質要件を意識することが、適切な設計や分割の第一歩となります。

システムを"どの観点"で分けるべきか？

フロントエンドとバックエンドの役割が分かったところで、具体的な分割基準を見ていきましょう。

バックエンドは「ビジネス領域」が設計軸

バックエンドの分割はビジネスの責務── つまりビジネスユースケースを実現する単位を軸にすることが重要です。

例えば E コマースビジネスでは、以下のような責務が存在します。

• 顧客管理
• 商品の在庫管理
• 注文受付と在庫引当
• 請求処理と決済
• 配送管理
• 売上集計と分析

これらをひとつのバックエンドでまとめると、以下の問題が起きやすくなります。

• 小さな変更が他領域に影響する
• 責務が入り混じってテストが困難になる
• チームで並行開発しづらい

そのため関心ごと（=ビジネス領域）を分離して自律的に管理できる構造にすることが重要です。

フロントエンドは「ユーザー行動」が設計軸

バックエンドが「ビジネスユースケース」に着目するのに対し、フロントエンドでは「ユーザーユースケース」や「ユーザー体験の流れ」に基づく分割が求められます。

例えばユーザーが実際に行う操作や目的ごとにユースケースを整理すると、次のようなものが挙げられます。

• サインアップ: アカウント登録のみのシンプルなフロー
• 登録情報の変更: マイページ → 情報編集の複数ステップフロー
• 商品購入: 商品検索 → カート追加 → 購入の連続操作フロー

これらは、ユーザー視点で見れば明確に目的が異なる行動です。フロントエンドでは、こうした目的ごとのユーザー行動の単位で切ることが重要になります。

また、ユーザーの一連のユースケースにおいて単一障害点を設けないことも重要です。

例えば「サインアップ」と「登録情報の変更」が別のフロントエンドなら、片方がダウンしてももう片方は利用できます。サインアップフロントエンドがダウンしていても、サインアップと登録情報の変更はそれぞれ独立したユーザーユースケースのため影響がありません。

しかし「商品購入」のような複数ステップのユースケースを複数のフロントエンドにまたがらせると、途中のフロントエンドがダウンした際にユーザーは購入を完了できなくなります。

このように、フロントエンドでは独立した一連のユーザーユースケースを軸にシステムを分割することが望まれます。

フロントエンドとバックエンドの粒度と責務の違い

ここまで述べてきたように、フロントエンドとバックエンドでは「どこで分けるか」「どう分けるか」の設計軸が異なります。

• バックエンドは「ビジネスユースケース」── 企業やサービス提供側の業務責務を中心に分割する
• フロントエンドは「ユーザーユースケース」── ユーザーが達成したい目的や体験の流れを中心に分割する

それぞれの立ち位置や守るべきものが異なるため、分割の粒度や責務も自ずと変化します。

つまり、フロントエンドは、ユーザーが目的を達成する一連の流れを自律的に実現できるよう、ユーザー体験の単位で設計することが重要です。一方バックエンドは、企業やサービス側の業務のまとまりごとに、ビジネス責務の単位で自律的に設計することが求められます。

この図のように、フロントエンドは「ユーザーの目的達成」を軸に、バックエンドは「ビジネスの目的達成」を軸に、それぞれ独立したサブシステムとして分割されるのが理想です。

なお、フロントエンドとバックエンドを1対1で対応させようとする設計も見られますが、両者は分割の基準が異なるため、必ずしも対応させる必要はありません。むしろ無理に合わせることで設計が複雑化する場合もあります。

それぞれの責務や設計軸に合わせて、最適な分割方針を選択することが重要です。「ユーザー体験」と「ビジネス責務」、この2つの視点を分けて考えることで、システム全体の健全性や拡張性を高めることができます。

分割のための具体的な分析手法

ここまで、フロントエンドとバックエンドの“役割の違い”や“分割粒度”について見てきました。では、それを実際にどう見極め、どう切っていけばよいのか──この章ではその分析手法を紹介します。

サブドメインや境界付けられたコンテキストによる分析

システムを分割する際には、まずビジネス全体をどのように捉えるかが重要です。サブドメインや境界付けられたコンテキストの考え方は、そのための有効なアプローチとなります。

サブドメインとは、広大なビジネス領域をビジネスの関心ごとによって分割統治する手法です。

一方、境界づけられたコンテキストとは、特定の意味で一貫した用語（ユビキタス言語）・モデルが用いられる領域であり、自律的にビジネス機能を提供できる境界を指します。

例えば同じ商品の概念でも、在庫管理コンテキストでは販売品の在庫、発送コンテキストでは発送品として、コンテキストによって意味が異なります。

このように、ビジネスの関心ごとや用語の違いを明確にし、それぞれを独立したコンテキストとして切り分けることで、バックエンドのシステム構成を異なるコンテキストに対応させることができます。これにより、それぞれが自律したシステム・組織・コミュニケーションとして機能しやすくなります。

境界づけられたコンテキストは、コンテキスト間の関係をコンテキストマップとして視覚化することで、マイクロサービスやチーム分担の指針となります。

イベントストーミングによる分析

イベントストーミングは、ビジネスの「出来事（イベント）」を時系列で並べて可視化し、関係者全員で業務やシステムの流れ・責務の境界を明らかにするワークショップ形式の設計手法です。この手法を使うことで、ビジネスユースケース（バックエンドの分割軸）やユーザーユースケース（フロントエンドの分割軸）を漏れなく洗い出せます。

たとえば「商品購入」なら「カート追加」「注文確定」「在庫引当」「決済」などのイベントを並べ、それぞれがどの責務・システムに属するかを整理できます。イベントストーミングは、分割の判断や関係者間の認識合わせに非常に有効なアプローチです。

サービスブループリントによる分析

サービスブループリントとは、ユーザーの行動を軸に、UI、裏側での処理、業務オペレーションを横断的に可視化し、体験設計と実装設計の整合性をとる手法です。

サービスブループリントでは、ユーザー行動に対するフロントステージと、サービス提供に至るまでの業務プロセスを明らかにします。

これによりユーザー行動を軸としたユーザーユースケースの発見や適切なサービス提供方法、つまり具体的なフロントエンドとバックエンドの構成の指針となります。

コンポーネント設計の原則

ここまでは“どう分けるか”を見つけるための分析手法を紹介してきましたが、次に紹介するのは“どう分けるべきか”の指針、つまり設計判断を支える原則です。

コンポーネント設計の原則はモジュール設計だけでなく、粒度が大きくなったシステム単位の設計にもそのまま応用できます。再利用・変更・依存といった課題は、モジュールやマイクロサービスといった単位でも本質的には同じ構造を持つためです。

再利用・リリース等価の原則（REP）

再利用・リリース等価の原則とは、再利用されるモジュールは、独立してリリース可能であるべきという設計原則です。

他のコードと強く結合していると、再利用したいときに不要な依存まで一緒に持ち込むこととなり、保守性や信頼性が下がります。

マイクロサービスでも同じです。たとえば「ユーザー認証」や「決済処理」など、他サービスから再利用される機能は、単独で開発・デプロイできるサービスとして切り出すことで、他サービスが明確な契約のもとで安定して利用できるようになります。

閉鎖性共通の原則（CCP）

閉鎖性共通の原則は、同じ理由によって変更されるものを1つのコンポーネントに閉じ込め、異なる理由で変更されるものを別のコンポーネントに分ける原則です。

例えば「UI の仕様変更」と「ビジネスルールの変更」は、それぞれ異なる理由（ユーザー体験の改善と業務要件の変更）で発生します。これらを同じコンポーネントに含めてしまうと、どちらか一方の変更がもう一方にも影響しやすくなり、不要な修正やテストのコストが増大します。

この原則をシステム分割に適用すると、同じ理由で頻繁に変更されるユーザーユースケースやビジネスユースケースは同じシステムにまとめるのが望ましいです。異なる理由で変更されるものはシステム単位で分離する、という指針になります。

例えば、EC サイトで「商品一覧画面の UI 変更」と「在庫引当ロジックの変更」は、それぞれフロントエンドとバックエンドの異なる責務・変更理由に基づきます。そのため、別々のシステムやコンポーネントとして分割することで、変更の影響範囲を最小化し、保守性や変更容易性を高めることができます。

このように、CCP は「なぜ変更されるのか？」という観点から分割単位を見極めるための重要な原則です。フロントエンドとバックエンドの分割でも、変更理由が異なるものは明確に分離することで、システム全体の健全性を保ちやすくなります。

全再利用の原則（CRP）

全再利用の原則は、一緒に使われるものだけを一緒にまとめるという考え方です。逆に言えば、一緒に使われないものは同じコンポーネントに含めないのが基本方針となります。

例えば、あるサービスに「ログイン処理」と「プロフィール画像のアップロード処理」が同じモジュールに含まれているとします。このとき、他のシステムが「ログイン機能だけを使いたい」場合でも、プロフィール画像の処理まで含めて依存しなければなりません。これは「必要のないものまで一緒に依存させられる」という、過剰な再利用（不要な依存）が発生している状態です。

このような設計では、不要な機能の変更や不具合が本来関係ない利用者にも影響を及ぼし、保守性や変更容易性が損なわれます。

CRP の観点では、一緒に再利用されるものはまとめ、一緒に再利用されないものは分けることが重要です。これにより、利用側は本当に必要な機能だけを選んで依存でき、提供側も機能単位での設計・変更・リリースがしやすくなります。

実際のシステム分割でも、「この機能群は常にセットで利用されるか？」という視点でコンポーネントやサービスの境界を見直すと、無駄な依存や影響範囲を最小化できます。

それぞれの中身はどうする？

次に、バックエンドとフロントエンドにおけるソフトウェアアーキテクチャの考え方の違いを見てみましょう。

バックエンドにおけるアーキテクチャの役割

システム全体から見たバックエンドは、ビジネスロジックとデータアクセスを責務とするサブシステムです。

中でもビジネスロジックは、業務ルールや意思決定の中枢を担う重要な資産です。一貫性や再利用性、そして変更のしやすさを保つためには、外部からの影響を受けない構造で守る必要があります。

そのため、ビジネスロジックを中心に据えて外部との境界を明確にするアーキテクチャが求められます。

具体的には、ドメイン駆動設計に基づいたレイヤードアーキテクチャ、ヘキサゴナルアーキテクチャ、オニオンアーキテクチャなどが挙げられます。

フロントエンドにおけるアーキテクチャの考え方

フロントエンドは、システム全体からプレゼンテーション層を切り出したサブシステムです。そのため、ビジネスロジックを保持する責務はなく、バックエンドほど厳密なロジックの隔離は求められません。

フロントエンドの本質的な役割は「ユーザー体験の提供」であり、画面構成や状態管理、入力制御などが主な関心事になります。よって、フロントエンドの設計では、UIの整合性や状態管理の扱いやすさを重視する構造が求められます。

ビジネスロジックをどう守るかよりも、どう見せるか・どう使いやすくするかが中心になる。これが、バックエンドとのアーキテクチャ設計の大きな違いです。

その他の構成：現実にはモノリスも存在する

ここまで、フロントエンドとバックエンドを役割に応じて分割する設計方針を見てきました。

ただし実務では、プロジェクトの規模やチーム体制、スケジュールの都合などにより、モノリスやハイブリッドな構成が選ばれる場面も少なくありません。

特に以下のような状況では有力な選択肢となります。

• 初期フェーズでの立ち上げ
• 単一のチームで一貫して開発・保守できる場合
• 機能間の連携が強く、分割によるメリットが薄いケース
• リアルタイム性を持ち、ビジネスロジックをプレゼンテーションの近くに配置する必要があるケース

ただし、こうした構成も「将来的に分割しやすいような設計」が求められることには変わりません。

まとめ：設計の軸が違うから、分け方も違う

	フロントエンド	バックエンド
主な責務	プレゼンテーション	ビジネスロジックとデータアクセス
分割の軸	独立したユーザーユースケース単位	独立したビジネスユースケース単位
主な品質	UI の使用性	ビジネスロジックの独立性と保守性
分析手法	サービスブループリント、イベントストーミング	サブドメイン、コンテキストマップ、イベントストーミング

システム全体を見通したとき、フロントエンドとバックエンドを"同じルール"で切ろうとするのではなく、それぞれの責務に合ったアプローチを選ぶことが、現実的かつ持続可能な設計につながります。