フロントエンド / バックエンドを一言でいうと
フロントエンドは
「ユーザーの目に見える“表側”」。
バックエンドは
「見えないところで動いている“裏側の頭脳と心臓”」。
あなたが Java で書くのは、基本的にこの「バックエンド側」です。
でも、フロントエンドとセットで考えないと、Web アプリの全体像はつかめません。
フロントエンドとは何か
画面と操作を担当する「ユーザーの相手役」
フロントエンドは、
ユーザーが実際に触る部分を担当します。
ブラウザに表示される画面
ボタン、フォーム、一覧、モーダル
入力チェック（必須、形式など）
画面の切り替えやアニメーション
これらはすべてフロントエンドの仕事です。
技術的には、
HTML（構造）
CSS（見た目）
JavaScript（動き）
が中心になります。
最近は、React / Vue / Angular などのフレームワークを使って、
「画面側だけでかなり複雑なことをする」ことも増えています。
具体例：ユーザー一覧画面のフロントエンド
ユーザー一覧画面をイメージしてみましょう。
画面には、
「ユーザー一覧」というタイトル
検索フォーム
一覧テーブル
ページングボタン
などが表示されています。
ユーザーが検索条件を入力して「検索」ボタンを押すと、
フロントエンドは JavaScript でバックエンドにリクエストを送り、
返ってきた JSON をもとにテーブルの中身を書き換えます。
ここでやっているのは、
「画面の表示」と「ユーザー操作への反応」です。
これがフロントエンドの役割です。
バックエンドとは何か
ビジネスロジックとデータを担当する「裏方」
バックエンドは、
ユーザーからは直接見えませんが、
アプリの「中身」を全部握っています。
ビジネスロジック（料金計算、在庫チェック、権限判定など）
データベースとのやり取り（保存・検索・更新）
認証・認可（ログイン、権限チェック）
トランザクション管理（途中で失敗したらまとめて取り消す）
ログ記録、監査
これらはすべてバックエンドの仕事です。
Java で書くのは、まさにここです。
Spring Boot などを使って、
REST API や HTML を返すサーバーサイドアプリを作ります。
具体例：ユーザー一覧 API のバックエンド
先ほどのユーザー一覧画面の裏側には、
こんなバックエンドのコードがいます。
@RestController
@RequestMapping("/api/users")
class UserController {
private final UserService userService;
@GetMapping
List<UserResponse> list() {
var users = userService.findAll();
return users.stream()
.map(UserResponse::from)
.toList();
}
}
フロントエンドが /api/users にリクエストを送ると、
このメソッドが呼ばれます。
中では、
サービスを呼び出して DB からユーザー一覧を取得し、
レスポンス用の形に変換して JSON として返しています。
ユーザーはこのコードを直接見ることはありませんが、
画面に表示される一覧の中身は、
このバックエンドの処理によって決まっています。
フロントエンドとバックエンドの会話
HTTP と JSON が「共通言語」
フロントエンドとバックエンドは、
HTTP と JSON を共通言語として会話 します。
フロントエンド（ブラウザ側）は、
JavaScript でこんなコードを書きます。
fetch("/api/users")
.then(res => res.json())
.then(users => {
// ここで画面を書き換える
});
バックエンド（Java）は、
先ほどの UserController で JSON を返します。
このとき、
フロントエンドは「画面のことだけ考える」
バックエンドは「データとロジックのことだけ考える」
という分担になっています。
役割分担のイメージ
フロントエンド：
「どう見せるか」「どう操作させるか」を考える。
ボタンの位置、色、入力フォーム、エラーメッセージの表示など。
バックエンド：
「何が正しい状態か」「どう処理するか」を考える。
このユーザーはこの操作をしてよいか、
在庫は足りているか、
料金はいくらになるか、
など。
この分担がきれいにできていると、
画面を変えたいときはフロント側を中心に、
ルールを変えたいときはバックエンド側を中心に、
という形で変更しやすくなります。
Java エンジニア視点での「フロント / バック」の捉え方
Java は基本「バックエンド担当」だが、フロントを意識しないと設計がブレる
Java で Web アプリを書くとき、
あなたが直接書くのはバックエンドのコードです。
ただし、
バックエンドはフロントエンドとセットで動きます。
API の設計（URL、パラメータ、レスポンス形式）
エラーレスポンスの形（どんな JSON を返すか）
認証が必要なエンドポイントの設計
これらはすべて、
「フロントエンドがどう使うか」を意識して決める必要があります。
フロントエンドを無視してバックエンドだけで完結させようとすると、
「使いづらい API」
「エラー時に何が起きているか分からない」
といった状態になりがちです。
3 層アーキテクチャとの関係
バックエンドの中も、さらに分かれています。
フロントエンド
↓（HTTP / JSON）
バックエンドの Controller（プレゼンテーション層）
↓
Service（ビジネスロジック）
↓
Repository（DB アクセス）
フロントエンド / バックエンドという大きな分け方の中に、
バックエンド側の 3 層アーキテクチャが入っているイメージです。
よくある誤解とアンチパターン
「フロントエンドで全部チェックしてるから、バックエンドは適当でいい」
これは危険です。
フロントエンドのバリデーションは、
ユーザー体験を良くするための「親切」です。
でも、
ブラウザの開発者ツールを使えば、
フロントエンドのチェックをすり抜けて
バックエンドに直接リクエストを送ることができます。
だから、
本当に守りたいルール（必須チェック、権限チェック、整合性チェック）は必ずバックエンド側にも書く
必要があります。
フロントエンドのチェックは「補助」、
バックエンドのチェックが「本番」です。
「バックエンドで画面の細かい見た目まで決めようとする」
逆に、
バックエンド側で
「このボタンはここに置いて…」
「この色で…」
といった細かい見た目までコントロールしようとすると、
フロントエンドの自由度がなくなります。
モダンな設計では、
バックエンドは「データとルール」を返すだけにして、
「どう見せるか」はフロントエンドに任せる、
という分担が増えています。
初心者がまず持つべきフロント / バックのイメージ
あなたの言葉で整理すると、こうなります。
フロントエンドは、
ユーザーに画面を見せて、入力を受け取り、
必要なときにバックエンドにリクエストを送る「表側」。
バックエンドは、
そのリクエストを受けて、
ビジネスロジックを実行し、
データベースとやり取りし、
結果を JSON や HTML として返す「裏側」。
両者は HTTP と JSON を通じて会話していて、
Java で書くのは主にバックエンド側。
ただし、バックエンドの設計は、
フロントエンドがどう使うかを常に意識して行う必要がある。