🖥️ バックエンド基礎講座【第一回】バックエンドとは何か・サーバーの基本を理解しよう！

1. 👋 はじめに

「バックエンドって結局何をしているの？」
「サーバーって何？」
「リクエストとかレスポンスってよく聞くけど…」

フロントエンド基礎講座に続いて、今回からは バックエンド開発の基礎 を解説するシリーズをお届けします！

このシリーズの特徴：
特定の言語・フレームワークに依存せず、「バックエンドの考え方・概念」 を中心に解説します。
Python・Node.js・Go・Javaなど、どの言語を学ぶ場合にも役立つ内容です。

AIを使いこなすエンジニアになるために、大切なことのひとつとして基礎概念の理解があります。
ツールは変わっても、「リクエスト・レスポンス」「認証」「DB設計」といった概念は変わりません。
このシリーズで学ぶ知識は、どんな時代になってもきっと色褪せない財産になると思います💪

この記事を読めば：

• ✅ バックエンドとフロントエンドの役割の違いがわかる
• ✅ サーバーとクライアントの仕組みがわかる
• ✅ リクエスト・レスポンスの流れがわかる
• ✅ ステートレス・ステートフルの違いがわかる

---

2. 🤔 バックエンドとは？

一言で言うと

バックエンドとは「ユーザーには見えない裏側の処理を担当する部分」です。
データの保存・計算・認証・ビジネスロジックなどを担当します。

レストランで例えると

🏠 Webアプリケーション = レストラン

👀 フロントエンド = 接客・店内の内装
  └─ お客様が直接見て・触れる部分
  └─ メニュー表・テーブル・店員の対応

🍳 バックエンド = 厨房
  └─ お客様からは見えない部分
  └─ 食材の管理・調理・在庫管理

📋 注文の流れ：
  お客様（フロントエンド）が注文 →
  店員が厨房（バックエンド）に伝える →
  厨房で調理 →
  店員が料理を運ぶ →
  お客様に届く

フロントエンドとバックエンドの役割分担

	フロントエンド	バックエンド
動く場所	ブラウザ（クライアント）	サーバー
主な仕事	見た目・操作感の提供	データ処理・保存・計算
扱う技術	HTML・CSS・TypeScript・React	Python・Node.js・Go・DB など
ユーザーから見えるか	✅ 見える	❌ 見えない
主な関心事	UI/UX・表示速度	データの整合性・セキュリティ・処理速度

---

3. 🌐 サーバーとクライアントの仕組み

サーバーとは？

サーバー（Server）とは「サービスを提供する側のコンピュータ」です。
「serve（提供する）」という単語から来ています。

クライアントとは？

クライアント（Client）とは「サービスを受け取る側」です。
普段使っているブラウザ・スマホアプリがクライアントにあたります。

クライアントサーバーモデルとは？

「サービスを提供する側（サーバー）」と「受け取る側（クライアント）」に役割を分けたネットワークの設計モデルのことです。
現代のWebアプリ・スマホアプリ・オンラインゲームなど、インターネットを使うほぼすべてのサービスがこのモデルで動いています。

身近な例で理解する

📞 電話に例えると：

クライアント（あなた）が電話をかける（リクエスト）
        ↓
サーバー（コールセンター）が対応する
        ↓
サーバーが回答を返す（レスポンス）

🍔 ファストフード店に例えると：

クライアント（お客様）が注文する（リクエスト）
        ↓
サーバー（店員・厨房）が商品を準備する
        ↓
サーバーが商品を渡す（レスポンス）

---

4. 📨 リクエストとレスポンスの流れ

HTTPでの実際のやり取り

Webアプリでは HTTP（HyperText Transfer Protocol） という通信のルールに従って、クライアントとサーバーがやり取りします。

リクエストの中身

リクエストには「何をしてほしいか」の情報が詰まっています。

リクエストは大きく3つの部分で構成されています。

① リクエストライン（最初の1行）

GET /users/123 HTTP/1.1
↑    ↑          ↑
│    │          └─ HTTPのバージョン
│    └─ パス（どこに対しての操作か）
└─ メソッド（何をしたいか）

② ヘッダー（追加情報）

Host: api.example.com          ← アクセス先のサーバー名
Authorization: Bearer xxxxx    ← 認証情報（ログイン済みかどうかなど）
                  ↑
                  Bearer = 「この人は正規のトークンを持っている」という意味
                  xxxxx の部分に実際のトークン（合言葉）が入る
Content-Type: application/json ← 送るデータの形式

③ ボディ（送信するデータ・POSTやPUTのときに使う）

{
  "name": "田中太郎",
  "email": "[e-mail]"
}

要素	説明	例
メソッド	何をしたいか	GET（取得）・POST（作成）など
パス（URL）	どこに対しての操作か	/users/123
ヘッダー	追加情報	認証情報・データ形式など
ボディ	送信する具体的なデータ	{"name": "田中太郎"} など

レスポンスの中身

レスポンスには「結果がどうだったか」の情報が詰まっています。

① ステータスライン（最初の1行）

HTTP/1.1 200 OK
↑        ↑   ↑
│        │   └─ ステータスの説明（OKなら成功）
│        └─ ステータスコード（結果を表す3桁の数字）
└─ HTTPのバージョン

② ヘッダー（レスポンスの追加情報）

Content-Type: application/json ← 返すデータの形式
Cache-Control: no-cache        ← キャッシュの設定

③ ボディ（実際に返されるデータ）

{
  "id": 123,
  "name": "田中太郎",
  "email": "[e-mail]"
}

要素	説明	例
ステータスコード	結果を表す番号	200（成功）・404（見つからない）など
ヘッダー	レスポンスの追加情報	データ形式・キャッシュ設定など
ボディ	実際に返されるデータ	JSON形式のユーザー情報など

---

5. 🔢 ステータスコードを知ろう

ステータスコードとは「リクエストの結果を表す3桁の数字」です。
先頭の数字でおおまかな意味が決まっています。

範囲	意味	よく使うコード
2xx	成功	200 OK・201 Created
3xx	リダイレクト	301 Moved Permanently
4xx	クライアント側のエラー	400 Bad Request・401 Unauthorized・404 Not Found
5xx	サーバー側のエラー	500 Internal Server Error

よく使うステータスコード一覧

コード	意味	使う場面
200 OK	成功	データの取得・更新が成功
400 Bad Request	リクエストが不正	必須項目が足りない・形式が間違っている
401 Unauthorized	認証が必要	ログインしていない
403 Forbidden	アクセス禁止	ログインはしているが権限がない
404 Not Found	見つからない	指定したデータ・URLが存在しない
500 Internal Server Error	サーバーエラー	サーバー側でエラーが発生

💡 覚え方のコツ：
開発者目線（サーバー側）で表現しています
4xx ＝「あなた（クライアント）のせい」
5xx ＝「サーバー（私たち）のせい」

---

6. 🔄 ステートレス・ステートフルとは？

ステートレスとは？

ステートレス（Stateless）とは「サーバーが状態（前のやり取り）を覚えていない」仕組みです。

HTTPはステートレスな通信です。すごく大事なことなので、これだけでも覚えておきましょう。

なぜHTTPはステートレス？
繋ぎっぱなし（ステートフル）にすると、サーバーのメモリがすぐに限界を迎えてパンクしちゃうから

😵 ステートレスの問題：

リクエスト①：「私はログイン済みです」
        ↓
サーバー：「はい、ようこそ」
        ↓
リクエスト②：「商品を買いたいです」
        ↓
サーバー：「あなたは誰ですか？」
        ↓
（さっきログインしたことを覚えていない！）

ステートフルにする方法

実際のWebアプリでは「ログイン状態を覚えておく」必要があります。そのための仕組みが必要です。

方法	仕組み
🍪 Cookie	ブラウザに情報を保存する「入れ物」
📋 セッション	サーバー側に状態を保存する仕組み（多くはCookieにセッションIDだけ渡す方法を採用）
🔑 トークン（JWT等）	クライアント側に状態の情報自体を持たせる

それぞれの仕組みを詳しく見てみましょう。

🍪 Cookie

ブラウザに「小さなデータ」を保存する仕組み。

例：ショッピングサイトで「カートの中身」を保持する
  → ブラウザ側に情報を保存しておく
  → 次回アクセス時に自動で送信される

📋 セッション

サーバー側に状態を保存する仕組み。
ブラウザには「セッションID（合言葉）」だけをCookieで渡す。

【流れ】
① ログイン成功
        ↓
② サーバーが「セッション情報」を保存
   （「ユーザーID:123 がログイン中」など）
        ↓
③ ブラウザに「セッションID: abc123」をCookieで渡す
        ↓
④ 次回リクエスト時にセッションIDを送る
        ↓
⑤ サーバーがIDをもとにセッション情報を照合

→ 実際のデータはサーバーが管理・ブラウザはIDだけ持つ

🔑 トークン（JWT等）

クライアント側に「状態の情報自体」を持たせる仕組み。

【流れ】
① ログイン成功
        ↓
② サーバーが「トークン」を生成して返す
   （「ユーザーID:123・有効期限:24h」などを暗号化した文字列）
        ↓
③ クライアントがトークンを保存（localStorage等）
        ↓
④ 次回リクエスト時にヘッダーに付けて送る
   Authorization: Bearer xxxxx
        ↓
⑤ サーバーがトークンを検証するだけでOK
   （セッション情報をサーバーで管理しなくていい！）

→ サーバーは状態を保存しない → スケールしやすい

第四回（認証・認可の基礎）で詳しく解説します！

なぜステートレスが基本なのか

メリット	説明
📈 スケールしやすい	サーバーを増やしても問題なく動く（どのサーバーが対応しても同じ）
🔧 シンプル	サーバー側で複雑な状態管理をしなくていい
🐛 障害に強い	1つのサーバーが落ちても他のサーバーで対応できる

---

🏗️ バックエンドが担当する主な仕事

具体例：ECサイトの注文処理

① クライアント：「この商品を注文したい」とリクエスト
        ↓
② バックエンド：認証確認「このユーザーはログイン済みか？」
        ↓
③ バックエンド：在庫確認「商品の在庫はあるか？」
        ↓
④ バックエンド：金額計算「税込み価格・送料を計算」
        ↓
⑤ バックエンド：DB保存「注文データをデータベースに保存」
        ↓
⑥ バックエンド：メール送信「注文確認メールを送る」
        ↓
⑦ クライアント：「注文完了しました」というレスポンスを受け取る

このように、バックエンドは「目に見えない多くの処理」を担当しています。

---

7. 🎯 まとめ

概念	一言で言うと
🖥️ バックエンド	ユーザーに見えない裏側の処理を担当
🌐 サーバー	サービスを提供する側のコンピュータ
💻 クライアント	サービスを受け取る側（ブラウザ・アプリ）
📨 リクエスト	クライアントからサーバーへの「お願い」
📤 レスポンス	サーバーからクライアントへの「返事」
🔢 ステータスコード	リクエストの結果を表す3桁の数字
🔄 ステートレス	サーバーが前のやり取りを覚えていない仕組み

バックエンドの本質：
「リクエストを受け取り → 処理をして → レスポンスを返す」
このシンプルな流れの中に、認証・DB・ビジネスロジックなど
たくさんの要素が詰まっています。

次回は API設計の基礎 を解説します！
RESTfulな設計・HTTPメソッドの使い分け・
良いエンドポイント設計の考え方を学びます🌟

💬 質問や感想があれば、コメント欄でお気軽にどうぞ!
👍 役に立ったら、いいね&ストックをお願いします!
🎓 ここまで読んでくださって、本当にありがとうございました!

---

🔗 シリーズ記事

• 【第一回】バックエンドとは何か・サーバーの基本（この記事）
• 【第二回】API設計の基礎（近日公開）
• 【第三回】データベースの基礎（近日公開）
• 【第四回】認証・認可の基礎（近日公開）
• 【第五回】バックエンド設計の実践（近日公開）
• 【第六回】まとめ・デプロイ・次のステップ（近日公開）