🏗️ バックエンド基礎講座【第五回】バックエンド設計の実践！レイヤードアーキテクチャ・バリデーション・ロギング・キャッシュ

1. 👋 はじめに

前回は認証・認可の基礎（セッション・JWT・パスワードの安全な扱い方）を学びました。

今回は バックエンド設計の実践 を解説します！

「動くコードと良いコードは別物」
コーディング基礎講座でも学びましたが、
バックエンドでも「長く・安全に・チームで使えるコード」を
作るための設計の考え方があります。

この記事を読めば：

• ✅ レイヤードアーキテクチャの考え方がわかる
• ✅ バリデーションの重要性と実装方法がわかる
• ✅ ロギングの基本がわかる
• ✅ キャッシュの仕組みと使い方がわかる

---

2. 🏗️ レイヤードアーキテクチャ

アーキテクチャとは？

アーキテクチャとは「コードをどう整理・分割するかの設計方針」です。
建物の設計図のように、コードの構造を事前に決めておくことで
「どこに何を書けばいいか」が明確になります。

レイヤードアーキテクチャとは？

レイヤードアーキテクチャとは「役割ごとにコードを層（レイヤー）に分ける設計」です。
各レイヤーは決まった役割だけを担当し、隣のレイヤーとだけやり取りします。

【データの流れ（一方通行）】

クライアント
    ↓ リクエスト
┌─────────────────────────────┐
│ 🌐 Controller               │ ← リクエストを受け取り・バリデーション
│  「POST /users を受け取った」 │
└────────────┬────────────────┘
             ↓ 処理を依頼
┌─────────────────────────────┐
│ 💼 Service                  │ ← ビジネスロジックを実行
│  「メールが重複しないか確認」  │
└────────────┬────────────────┘
             ↓ データを要求
┌─────────────────────────────┐
│ 🗄️ Repository               │ ← DBとやり取り
│  「DBにユーザーを保存する」   │
└────────────┬────────────────┘
             ↓
         🗃️ DB
             ↓ 結果を返す（逆順に伝わっていく）
    クライアントにレスポンス

ポイント：Controller は Repository を直接呼ばない！
         必ず Service を経由する（層を飛ばさない）

各レイヤーの役割

レイヤー	別名	役割	例
🌐 プレゼンテーション層	Controller	リクエストの受け取り・バリデーション・レスポンスの返却	POST /users を受け取る
💼 ビジネスロジック層	Service	アプリ固有のルール・計算・判断	「同じメールは登録できない」
🗄️ データアクセス層	Repository	DBへのデータの読み書き	ユーザー情報をDBから取得

なぜ分けるのか？

❌ 分けない場合：1つの関数にすべてが詰まっている

def create_user(request):
  # リクエストの処理
  # バリデーション
  # メールが重複していないかチェック
  # パスワードのハッシュ化
  # DBへの保存
  # メール送信
  # レスポンスの返却
  → 何百行にもなる・テストが難しい・修正が怖い 😱

✅ 分けた場合：各レイヤーが1つのことだけを担当

Controller：リクエストを受け取ってServiceに渡す
Service：ビジネスロジック（重複チェック・ハッシュ化など）
Repository：DBへの保存だけ

→ コードが読みやすい・テストしやすい・修正しやすい 🎉

💡 コーディング基礎講座の「単一責任の原則」と同じ考え方です！
関数レベルで学んだ「1つのことだけ担当する」を、アーキテクチャ（設計）レベルで適用したものがレイヤードアーキテクチャです。

---

3. ✅ バリデーション

バリデーションとは？

バリデーション（Validation）とは「入力値が正しい形式かを検証すること」です。
不正なデータがシステムに入り込むのを防ぐ「門番」の役割を果たします。

なぜバリデーションが重要なのか？

❌ バリデーションなし：
  ユーザーが "age": "abc" を送ってくる
         ↓
  そのままDBに保存しようとする
         ↓
  DBがエラー（age は整数型なのに文字列が来た）
         ↓
  サーバーがクラッシュ or 予期しない動作 😱

  さらに悪いケース：
  SQLインジェクション・XSSなどの攻撃にも使われる！

✅ バリデーションあり：
  不正な入力を早い段階で弾いて 400 Bad Request を返す
         ↓
  DBやビジネスロジックには正しいデータだけが届く 🎉

バリデーションの種類

種類	説明	例
必須チェック	値が空でないか	name は必須
型チェック	正しいデータ型か	age は整数か
長さチェック	文字数が適切か	password は8文字以上か
形式チェック	正しい形式か	email に @ が含まれるか
範囲チェック	値が適切な範囲か	age は0以上150以下か
一意性チェック	重複していないか	同じ email のユーザーがいないか

バリデーションはどこで行う？

【多層防御：複数の場所でバリデーションする】

① フロントエンド（入力フォーム）
  → ユーザーへの即時フィードバック
  → ただし「スキップできる」ので信頼してはいけない！

② バックエンド（Controller層）
  → 必ずここでバリデーションする（最重要）
  → フロントが改ざんされてもここで弾ける

③ データベース（型・制約）
  → 最後の砦（NOT NULL・UNIQUE制約など）

バックエンドのバリデーションは絶対に省略してはいけません！
フロントエンドのバリデーションはユーザー体験のためであり、セキュリティのためのバリデーションはバックエンドで必ず行います。

バリデーションを行う場所	目的	信頼性	💡 役割のイメージ
① フロントエンド（ブラウザ側）	ユーザー体験（UX）の向上	❌ 低い（開発者ツールで簡単に回避できる）	「優しい道案内」（間違えそうなら教えてあげる）
② バックエンド（サーバー側）	セキュリティと整合性の維持	✅ 絶対（高い）	「頑丈な砦の門番」（ダメなものは絶対に通さない）

---

4. 📋 ロギング（Logging）

ロギングとは？

ロギングとは「アプリケーションの動作・エラーを記録すること」です。
問題が起きたとき「いつ・何が・どこで起きたか」を調べるために使います。

ログがないと何が困るのか？

❌ ログなし：
  「昨日の夜にサービスが止まったらしい」
  「なぜ止まったかわからない…」
  「どのユーザーに影響が出たかもわからない…」
  → 原因究明に何日もかかる 😭

✅ ログあり：
  「2026-01-01 03:15:22 ERROR DB接続タイムアウト」
  「影響を受けたリクエスト：1,234件」
  → 即座に原因と影響範囲を特定できる 🎯

ログレベル

レベル	意味	使う場面
DEBUG	詳細なデバッグ情報	開発時の細かい動作確認
INFO	通常の操作ログ	ユーザーのログイン・注文などの重要な操作
WARN	警告（動作はしている）	パフォーマンスの低下・非推奨の機能使用
ERROR	エラー（一部機能が停止）	API呼び出し失敗・DB接続エラー
FATAL,CRITICAL	致命的なエラー（全体停止）	サーバーがクラッシュするレベルのエラー

💡 FATAL と CRITICAL は同じ意味です！
最高レベルのログの名称は、言語・フレームワークによって異なります。

言語・フレームワーク	最高レベルの名称
Java・Log4j	FATAL
Ruby on Rails	FATAL
Python（logging）	CRITICAL
Node.js（Winston）	error（FATALに相当する専用レベルはデフォルトでは存在しない）

どちらも「サーバー全体が停止するほどの致命的なエラー」を意味します。
使っている言語やフレームワークのドキュメントに合わせて呼び方を使い分けましょう。

良いログの書き方

❌ 悪いログ：
  "エラーが発生しました"
  "処理完了"
  "NG"

✅ 良いログ：
  "[2026-01-01 12:00:00] INFO  user_id=123 がログインしました（IP: 192.168.1.1）"
  "[2026-01-01 12:01:30] ERROR user_id=456 の注文処理中にDBエラー発生
                               order_id=789 金額=5000円
                               エラー内容: Connection timeout after 30s"

良いログに含めるべき情報：
  ✅ 日時（タイムスタンプ）
  ✅ ログレベル
  ✅ 関連するID（user_id・order_id など）
  ✅ 何が起きたか（具体的に）
  ✅ エラーの場合は詳細なエラーメッセージ

ログに含めてはいけないもの

⚠️ 以下の情報はログに残さない！

  ❌ パスワード・秘密鍵
  ❌ クレジットカード番号
  ❌ 個人情報（必要最低限に留める）
  ❌ JWTトークンの全体

---

5. ⚡ キャッシュ

キャッシュとは？

キャッシュとは「よく使うデータを一時的に保存して、素早く取り出せるようにする仕組み」です。
重い処理の結果を覚えておくことで、次回は即座に返せます。

キャッシュがなぜ必要なのか？

❌ キャッシュなし：
  ユーザーが「人気商品ランキング」を見るたびに
         ↓
  毎回DBに重いクエリを実行
         ↓
  DB負荷が高い・レスポンスが遅い・大量アクセスでサーバーが落ちる 😱

✅ キャッシュあり：
  最初の1回だけDBにクエリを実行
         ↓
  結果をキャッシュに保存（例：5分間）
         ↓
  5分以内のリクエストはキャッシュから即座に返す
         ↓
  DB負荷が激減・レスポンスが速い 🚀

キャッシュの種類

種類	説明	代表例
インメモリキャッシュ	メモリ上にデータを保存・超高速	Redis・Memcached
ブラウザキャッシュ	ブラウザが画像・CSSなどを保存	HTTPキャッシュヘッダー
CDNキャッシュ	世界中のサーバーにコンテンツを配置	Cloudflare・AWS CloudFront
DBキャッシュ	DBが内部でクエリ結果を保存	DBエンジン内蔵機能

Redisとは？

Redis（レディス）とは「インメモリ型のデータストア」です。
キャッシュとして最もよく使われます。

【Redisのイメージ】

バックエンド ──→ Redis（メモリ上）
                  ↑ なければDBへ
バックエンド ──→ DB（ディスク上）

DBよりも100倍以上速い！

キャッシュの注意点

⚠️ キャッシュを使うときの注意点：

① キャッシュの有効期限（TTL）を適切に設定する
   → 長すぎると古いデータが表示される
   → 短すぎるとキャッシュの効果がなくなる

② データが更新されたらキャッシュを削除（無効化）する
   → 商品の価格が変わったのに古い価格がキャッシュされていると困る

③ 何でもキャッシュすればいいわけではない
   → ユーザーごとに異なるデータはキャッシュが難しい
   → リアルタイム性が必要なデータはキャッシュできない

「キャッシュには2つの難しい問題がある。
 キャッシュの無効化と、名前のつけ方だ」
（Phil Karlton / コンピュータサイエンスの有名な格言）

💡 「キャッシュの無効化」がなぜ難しいのか？実務の超定番トラブル

例えば「ECサイトで商品の在庫数をキャッシュしていた」とします。
ユーザーAが商品を購入して在庫が0になったのに、
キャッシュが残っているせいで別のユーザーBには「在庫あり」と表示され続け、購入しようとすると「在庫切れエラー」が多発する…というトラブルは実務の定番です。

キャッシュを使うときは「いつ・どのタイミングでキャッシュを消すか（無効化）」のルール設計が、実装以上に頭を使うポイントになります。
「とりあえずキャッシュしよう」ではなく、このデータはいつ古くなるのか？」を先に考えることが重要です。

---

6. 🔍 エラーハンドリングの設計

エラーレスポンスの形式を統一する

❌ 形式がバラバラなエラーレスポンス：
  { "msg": "error" }
  { "message": "Not found", "code": 404 }
  { "error_message": "Unauthorized" }

✅ 形式を統一したエラーレスポンス：
  {
    "status": 400,
    "error": "Bad Request",
    "message": "メールアドレスの形式が正しくありません",
    "path": "/api/v1/users",
    "timestamp": "2026-01-01T12:00:00Z"
  }

エラーの種類と対応

エラーの種類	ステータスコード	対応
バリデーションエラー	400	エラー内容をユーザーに伝える
認証エラー	401	ログインを促す
認可エラー	403	アクセス権限がないことを伝える
リソース不在	404	見つからないことを伝える
サーバーエラー	500	詳細はログに記録（ユーザーには詳細を見せない）

⚠️ 500エラーの詳細をユーザーに見せてはいけません！
スタックトレースやDB情報が漏れると、攻撃者に情報を与えることになります。
エラーの詳細はログに記録し、ユーザーには「エラーが発生しました」とだけ伝えましょう。

---

7. 🎯 まとめ

概念	一言で言うと
🏗️ レイヤードアーキテクチャ	役割ごとにコードを層に分ける設計
✅ バリデーション	入力値が正しい形式かを検証する「門番」
📋 ロギング	アプリの動作・エラーを記録する仕組み
⚡ キャッシュ	よく使うデータを一時保存して高速化
🔍 エラーハンドリング	エラーレスポンスの形式を統一する

バックエンド設計の基本原則：
① 役割を分離する（レイヤードアーキテクチャ）
② 入力は必ず検証する（バリデーション）
③ 問題の記録を残す（ロギング）
④ 重い処理は覚えておく（キャッシュ）
⑤ エラーは一貫した形式で返す（エラーハンドリング）

これらはすべて「長く・安全に・チームで使えるコード」を
作るための実践的な知恵です💪

次回はシリーズ最終回！デプロイ・環境設定・学習ロードマップ を解説します！
バックエンドをインターネットに公開するための知識と、これからの学び方をまとめます🌟

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

---

🔗 シリーズ記事

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