先に要点
Redis ってよく聞くけど、結局何に使うの？ MySQL や PostgreSQL と何が違うの？
この疑問はかなり多いです。
特に Laravel や Web アプリの構成図を見ると、DB とは別に Redis が置かれていて、この箱は何の仕事をしているのか が分かりにくいことがあります。
この記事では、2026年4月14日時点の Redis 公式ドキュメントを確認しながら、Redis の基本と、初心者が実務で最初に出会いやすい キャッシュ セッション キュー の3つの使いどころを整理します。
Redisとは何か
Redis は、高速な読み書きを得意とするインメモリ中心のデータストアです。
初心者向けにかなりざっくり言うと、メモリ上に素早く出し入れできる保管場所 のようなイメージです。
一般的なリレーショナルデータベースと大きく違うのは、正規化した表をきっちり管理する より、一時的に持ちたい値を速く扱う ことが得意な点です。
そのため、実務では次のような用途で名前が出やすいです。
- 同じ結果を何度も作らないための キャッシュ
- ログイン状態などを持つセッション保存
- メール送信や通知などを後ろで処理するキュー
- 一時的なカウンターやレート制限
MySQLやPostgreSQLと何が違うのか
MySQL や PostgreSQL は、会員情報、商品情報、受注、記事本文のような 消えると困る本体データ を持つのが主な役割です。
一方 Redis は、速く扱いたい補助データ や 一時的な処理の置き場 として使われることが多いです。
| 観点 | Redis | MySQL / PostgreSQL |
|---|---|---|
| 得意なこと | 高速な読み書き、一時データ、非同期処理の補助 | 本体データの保存、厳密な整合性、複雑な検索 |
| 保存先のイメージ | メモリ中心 | ディスク中心 |
| 向いているデータ | キャッシュ、セッション、キュー、カウンター | 会員情報、注文、記事、マスタデータ |
| 実務での立ち位置 | 補助役として使われやすい | 中心のDBとして使われやすい |
つまり、Redis は DB の代わり というより、DB やアプリの処理を軽くするための相棒 と考えると分かりやすいです。
一番よく使われる用途1：キャッシュ
Redis が最初に使われやすいのは、やはり キャッシュ です。
キャッシュで何をしているのか
たとえば、
- 重い集計結果
- よく読まれる記事一覧
- 外部 API の取得結果
- 毎回同じ条件で作る検索結果
のようなものを、毎回ゼロから作ると遅くなります。
そこで、一度作った結果を Redis にしばらく置いておき、次回はそれを返すようにします。
リクエスト
→ Redis に結果があるか確認
→ あればそのまま返す
→ なければ DB や API から作る
→ Redis に保存して返す
この流れで、アプリや DB の負荷を下げやすくなります。
実務でありがちな場面
- トップページの人気記事一覧
- 商品一覧の並び替え結果
- ダッシュボードの集計値
- 短時間で何度も呼ばれる API
初心者が混乱しやすい点
キャッシュは速くなりますが、古い情報が残ることがあります。
そのため、何分持たせるか 更新時に消すか を決めずに入れると、速いけど古い 状態になりやすいです。
よく使われる用途2：セッション
セッションは、ログイン中の状態や一時的なユーザー情報を持つために使われます。
セッションで何をしているのか
たとえばログイン後、毎回ユーザー情報を全部送り直すのではなく、サーバー側で この人はログイン済み という状態を持っておきます。
その保存先として Redis を使うことがあります。
Redis が向いている理由は、次の通りです。
- 読み書きが速い
- 有効期限を持たせやすい
- 複数サーバー構成でも共有しやすい
特に Web サーバーが複数台あると、各サーバーのメモリだけにセッションを置くより、Redis にまとめた方が扱いやすくなります。
実務でありがちな場面
- ログイン中ユーザーの状態管理
- 多段フォームの一時保存
- 認証途中の一時的な情報保持
注意点
セッションは 消えてもその場で再ログインすれば戻れるか を考える必要があります。
絶対に失いたくない本体データを Redis セッションにだけ持たせるのは危険です。
よく使われる用途3：キュー
初心者が Redis ってこんな使い方もするのか と驚きやすいのがキューです。
キューで何をしているのか
キューは、今すぐ画面の返答に必要ではない重い処理 を後ろへ回すための仕組みです。
たとえば、
- メール送信
- 通知送信
- 画像変換
- CSV 出力
- 外部サービスへの連携
のような処理を、ユーザーのクリックと同時に全部やると画面が遅くなります。
そこで、やるべき仕事 だけを Redis に積んでおき、ワーカーが後から順に処理します。
ユーザーが登録ボタンを押す
→ 本体データだけ保存
→ メール送信ジョブをキューへ積む
→ 画面はすぐ完了
→ ワーカーが後からメール送信
これで体感速度がかなり変わります。
Laravelで出会いやすい場面
Laravel では、キューの保存先として Redis を使う構成がよく出てきます。
同期でやると遅い処理を、ジョブとして後ろに回す という考え方を覚えると、構成図の意味がかなり見えやすくなります。
初心者が混乱しやすい点
キューに積んだだけでは処理は終わりません。
ワーカーが動いていないと、ジョブはたまるだけです。
そのため、実務では 積む側 と 処理する側 の両方を見ないといけません。
Pub/SubやStreamsは何が違うのか
Redis を調べると、Pub/Sub や Streams も出てきます。
ただ、初心者の最初の理解としては、ここを深追いしすぎなくて大丈夫です。
- Pub/Sub: イベントを購読者へ配る仕組み
- Streams: 履歴を持ちながらメッセージを流せる仕組み
まず実務で多いのは、キャッシュ、セッション、キューです。
Pub/Sub や Streams は、リアルタイム処理やイベント連携の要件が強くなったときに見れば十分です。
Redisは何でも入れてよいのか
ここはかなり大事です。
Redis は便利ですが、速いから全部 Redis に置こう は危険です。
判断の目安はこうです。
| データの性質 | Redis向きか |
|---|---|
| 消えても作り直せるキャッシュ | 向いている |
| 有効期限つきのログイン状態 | 向いている |
| 後ろで処理したいジョブ | 向いている |
| 会員情報や注文などの本体データ | 基本は向かない |
| 長期保存が前提の厳密な記録 | 基本はDB向き |
大事なのは、Redis に入れるデータは「消えたら何が困るか」を考えること です。
実務で見るときのポイント
Redis を実務で使うときは、次の点を見ると事故が減ります。
- 保存期間を決めているか
- キャッシュ削除のタイミングが決まっているか
- ワーカー監視ができているか
- Redis が落ちたときにどこまで影響するか分かっているか
本体DBと補助データの役割分担が崩れていないか
速いことだけに目が行くと、あとで 古いデータが出る ジョブが詰まる セッションが飛ぶ という形で困りやすいです。
よくある誤解
Redisはただのキャッシュ専用ツール？
キャッシュ用途が有名ですが、セッションやキューでもかなり使われます。
速い一時データの置き場 と考えると理解しやすいです。
RedisがあればDBはいらない？
基本は違います。
本体データは MySQL や PostgreSQL のような DB に持たせ、Redis は補助役として使うのが一般的です。
Redisに積んだらキュー処理は終わったことになる？
なりません。
ジョブを積んだだけで、実際に処理するワーカーが動いていなければ完了しません。
まとめ
Redis は、高速な読み書きを得意とするインメモリ中心のデータストアで、一時的に持ちたい情報 とかなり相性がよいです。
初心者が最初に押さえたい用途は、キャッシュ、セッション、キューの3つです。
キャッシュは 毎回重い処理をしないため、セッションは ログイン状態などを持つため、キューは 重い処理を後ろで回すため に使われます。
大事なのは、Redis は速い補助役 であって、何でも入れる本体DBではないと分けて考えることです。
あわせて、キャッシュそのものの考え方を整理したいなら CDNとは？何が速くなるのか、どこまで必要なのかを解説 や glossary の キャッシュ もつながります。
データベースとの役割分担まで見たいなら PostgreSQLとMySQLの違いは？実務でどう選ぶかを初心者向けに比較 も続けてどうぞ。
参考リンク
- Redis Docs: What is Redis?
- Redis Docs: Data Types
- Redis Docs: Expiration
- Redis Docs: Pub/Sub
- Redis Docs: Streams
- Laravel Docs: Queues