# Django `LocMemCache`（ローカルメモリキャッシュ）とは？

![ロボットのデータ保管庫画像](/media/editor_temp/6/62743df3-4837-47d2-b16a-a458240f5629.png)

`LocMemCache`は、Djangoが提供する**ローカルメモリ（Local‑memory）キャッシュバックエンド**です。キャッシュ設定を行わない場合、Djangoはデフォルトでこのローカルメモリキャッシュを使用します。構造が比較的シンプルなアプリケーションで、メモリ共有を行わずに高速かつ簡単に運用したい場合や、開発用サーバでRedisを設定する前に素早くテストしたい場合に利用されます。

## 特徴まとめ {#sec-1ab8bf148cf4}

- **保存場所**：現在実行中の**DjangoプロセスのRAM**
- **共有範囲**：**プロセス外には共有されない（per‑process）**
- **特性**：**thread‑safe**

---

## どんな問題を解決するのか {#sec-a43c966021ff}

キャッシュは「高価に計算・取得した結果」を一時的に保存し、次のリクエストで再利用するために使われます。

例えば、頻繁に参照されるデータをデータベースから取得してキャッシュに入れると、

- 最初のリクエスト：DBクエリ → 結果をキャッシュに保存
- 以降のリクエスト：キャッシュから即座に返却（高速）

`LocMemCache`は、**外部システム（Redis/Memcached など）を使わずに、自プロセスのメモリへ直接**キャッシュを保存します。

---

## 動作の核心 3つ {#sec-e1d14f422616}

### 1) 「プロセス単位」のキャッシュ（最重要） {#sec-4cad51e104e0}

Django のドキュメントでは、ローカルメモリキャッシュは **per-process** だと明記されています。つまり、

- Gunicorn ワーカーが 4 つなら → **キャッシュも 4 つ**
- サーバが 2 台なら → **サーバごとにキャッシュが別々**

したがって **プロセス／サーバ間でキャッシュを共有できません**。

### 2) 「thread‑safe」 {#sec-54bf2b28b2bd}

同一プロセス内で複数スレッドが同時にアクセスしても安全に動作するよう設計されています。

### 3) 再起動するとキャッシュが消える {#sec-9c3d1cb66224}

メモリにのみ存在するため、プロセスが再起動するとキャッシュも同時に初期化されます。

---

## 設定方法 {#sec-db7311714572}

`settings.py` の `CACHES` に `BACKEND` を指定します。

```python
CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.locmem.LocMemCache",
        "LOCATION": "unique-snowflake",
    }
}
```

公式ドキュメントの例は上記の形で、`LOCATION` はキャッシュインスタンスを区別する識別子として機能します。

---

## 利点 {#sec-25710dcb814a}

- **設定がほぼ不要**：外部キャッシュサーバを立てる必要がない
- **高速**：同一プロセスのメモリアクセスで遅延が低い
- **開発／テストに便利**：キャッシュの概念を試したいときに最適

---

## 欠点と注意点 {#sec-f000fc34bd78}

- **マルチプロセス／マルチサーバでキャッシュが分散** → 「キャッシュが効いていないように見える」状況が発生
- **本番環境で予測が難しい**：トラフィックが複数プロセスに分散するとキャッシュヒット率が低下する可能性
- **セッションストレージとしては推奨されない**：Django のセッションドキュメントでは、ローカルメモリキャッシュは長期保持されず、マルチプロセスでも安全ではないと警告されています。

---

## 使いどころ {#sec-723e29575ca2}

- ローカル開発環境
- 単一プロセス（または「キャッシュ共有が不要」な作業）
- 機能検証／テスト（外部依存を最小化したい）

逆に **複数プロセス／複数サーバで「同じキャッシュを共有」する必要がある** 場合は、ローカルメモリキャッシュよりも Redis/Memcached などの **共有キャッシュ** を検討するのが一般的です。