/ ディレクトリ / プレイグラウンド / Redis
← 全サーバー ↗ GitHub
● 公式 redis 🔑 自分のキーが必要

Redis

作者 redis · redis/mcp-redis

Redisを自然な日本語（英語）で操作 — キーの検索、キャッシュ管理、有効期限の調整、pub/subのデバッグまで、Redisコマンドを暗記しなくても実行できます。

Redis公式MCPは、型付きツールを通じてRedisの全コマンドを提供します。文字列、ハッシュ、リスト、セット、ソート済みセット、ストリーム、pub/sub、キー管理に対応しています。単一のRedis URLをデフォルトとし、OSS Redis、Redis Stack、Redis Cloud、ElastiCache/MemoryDBで動作します。

▶ デモを見る 📦 インストール 💡 ユースケース

なぜ使うのか

主な機能

ライブデモ

実際の動作

redis.replay ▶ 準備完了
0/0

インストール

クライアントを選択

~/Library/Application Support/Claude/claude_desktop_config.json  · Windows: %APPDATA%\Claude\claude_desktop_config.json
{
  "mcpServers": {
    "redis": {
      "command": "uvx",
      "args": [
        "mcp-redis"
      ]
    }
  }
}

Claude Desktop → Settings → Developer → Edit Config を開く。保存後、アプリを再起動。

~/.cursor/mcp.json · .cursor/mcp.json
{
  "mcpServers": {
    "redis": {
      "command": "uvx",
      "args": [
        "mcp-redis"
      ]
    }
  }
}

Cursor は Claude Desktop と同じ mcpServers スキーマを使用。プロジェクト設定はグローバルより優先。

VS Code → Cline → MCP Servers → Edit
{
  "mcpServers": {
    "redis": {
      "command": "uvx",
      "args": [
        "mcp-redis"
      ]
    }
  }
}

Cline サイドバーの MCP Servers アイコンをクリックし、"Edit Configuration" を選択。

~/.codeium/windsurf/mcp_config.json
{
  "mcpServers": {
    "redis": {
      "command": "uvx",
      "args": [
        "mcp-redis"
      ]
    }
  }
}

Claude Desktop と同じ形式。Windsurf を再起動して反映。

~/.continue/config.json
{
  "mcpServers": [
    {
      "name": "redis",
      "command": "uvx",
      "args": [
        "mcp-redis"
      ]
    }
  ]
}

Continue はマップではなくサーバーオブジェクトの配列を使用。

~/.config/zed/settings.json
{
  "context_servers": {
    "redis": {
      "command": {
        "path": "uvx",
        "args": [
          "mcp-redis"
        ]
      }
    }
  }
}

context_servers に追加。保存時に Zed がホットリロード。

claude mcp add redis -- uvx mcp-redis

ワンライナー。claude mcp list で確認、claude mcp remove で削除。

ユースケース

実用的な使い方： Redis

キャッシュ値が古い・存在しない原因を調査する

👤 キャッシュのバグをデバッグするバックエンドエンジニア ⏱ ~10 min beginner

使うタイミング： ユーザーから「プロフィールを更新したのに古い名前が表示される」という報告があった場合 — キャッシュ無効化の問題が疑われます。

前提条件
  • 少なくとも読み取り権限のあるRedis URL — REDIS_URL=redis://:pw@host:6379/0
フロー
  1. 対象のキーを見つける
    user:profile:42*にマッチするキーをスキャンし、それぞれの型とTTLを表示してください。✓ コピーしました
    → マッチするキーの一覧
  2. 格納された値と有効期限を確認する
    user:profile:42をGETして値とTTLを表示してください。期待値と比べて古くなっていますか？✓ コピーしました
    → 値 + TTL + 判定結果
  3. 意図的にキャッシュを破棄する
    そのキー（および関連するlist/setキー）を削除し、次回の読み取り時にアプリが再取得するようにしてください。削除を確認してください。✓ コピーしました
    → DELが1以上を返す

結果： 何が古くなっていたか、なぜ古くなっていたかの記録とともに、キャッシュが修正されたことを確認できます。

注意点
  • 大規模インスタンスでKEYS *を実行するとサーバーが停止する — 常にSCANを使用してください（サーバーがscanツールをノンブロッキングカーソルに変換します）。KEYSは絶対に使わないこと

レートリミットカウンターを監査して不正利用パターンを検出する

👤 プラットフォーム／不正利用対策チーム ⏱ ~15 min intermediate

使うタイミング： クライアントがレートリミッターに対してバーストしている疑いがあり、ライブカウンターとTTLを確認したい場合。

フロー
  1. アクティブなカウンターを一覧表示する
    ratelimit:*にマッチするキーをスキャンし、プレフィックスごとにグループ化してください。グループごとの件数を表示してください。✓ コピーしました
    → プレフィックスのヒストグラム
  2. 上位の消費者を特定する
    ratelimit:api:*について、整数値が最も高い上位20キーを返してください。✓ コピーしました
    → 上位20の不正利用者
  3. ブロックまたはリセットする
    不正利用キーratelimit:api:client_abcをDELETEして次回の呼び出しがフェイルオープンになるようにし、client_abcをブロックリストセットabuse:blockedにEXPIRE 86400で追加してください。✓ コピーしました
    → キー削除 + ブロックリスト更新完了

結果： 不正利用のライブエビデンスと、わずかなRedisオペレーションによるターゲットを絞った対策が得られます。

注意点
  • レートリミットキーを削除するとクライアントが即座に再バーストできてしまう — 先にブロックリストセットに追加し、その後でカウンターを削除する — 逆の順序にしないこと
組み合わせ： sentry

メモリを消費している孤立セッションキーを検出・削除する

👤 Redisメモリアラートに対応するSRE ⏱ ~20 min intermediate

使うタイミング： Redisがmaxmemoryの85%に達しており、重要なキーがエビクトされる前に何がメモリを占有しているか把握する必要がある場合。

フロー
  1. 大きなキーをサンプリングする
    メモリ使用量が最も大きい上位50キーを見つけてください（SCANパスでサンプリングしたキーごとにMEMORY USAGEを使用）。✓ コピーしました
    → サイズ付きの最大キー一覧
  2. プレフィックスごとにグループ化して集計する
    そのサンプルから、最初のコロン区切りでキーをグループ化してください。グループごとにサイズを合計し、最も問題のあるプレフィックスを特定してください。✓ コピーしました
    → プレフィックス → 合計バイト数
  3. TTLを設定して整理する
    プレフィックスsession:のキーでTTLが設定されていない（永続化されている）ものに、EXPIRE 86400秒を設定してください。更新されたキーの数を報告してください。✓ コピーしました
    → TTLが設定されたキーの数

結果： メモリの解放と、根本原因（セッション書き込み時のEXPIRE設定漏れ）の特定。アプリコード側での修正につなげられます。

注意点
  • MEMORY USAGEは大きなハッシュ/zsetに対してコストが高い — 全キースペースではなく、SCANで5,000〜10,000キーをサンプリングする
組み合わせ： sentry

Redis Streamで滞留しているコンシューマーグループのエントリを調査する

👤 Redis Streamsをワークキューとして使用しているエンジニア ⏱ ~20 min advanced

使うタイミング： コンシューマーグループが遅延しており、メッセージがACKされず、スループットが低下している場合。

フロー
  1. ストリームとグループを確認する
    ストリームjobsのXLEN、コンシューマーグループ、グループごとのペンディング数を表示してください。✓ コピーしました
    → バックログの数値
  2. ペンディングエントリを確認する
    グループworkersのPELエントリ上位20件（XPENDING）を、アイドル時間とコンシューマーとともに表示してください。✓ コピーしました
    → 滞留メッセージID
  3. 再取得または破棄する
    idle>300000の滞留エントリを新しいコンシューマーにXCLAIMするか、破棄しても安全ならXACKしてください。実行前にどちらにするか確認してください。✓ コピーしました
    → 再取得/ACKのサマリー

結果： バッチごとのアクション（claimかACKか）が記録された状態で、ストリームのブロックが解消されます。

注意点
  • メッセージを確認せずにXACKすると、作業が静かに失われる — XACKの前に必ずメッセージ本文を取得（XRANGE）し、破棄して安全か確認する

Redisハッシュに格納されたフィーチャーフラグのロールアウトをデバッグする

👤 Redisベースのフラグを使用するプラットフォームチーム ⏱ ~10 min beginner

使うタイミング： 特定のユーザーサブセットに対してフラグが期待通りに動作しない場合。

フロー
  1. フラグのハッシュを確認する
    flags:new-checkoutをHGETALLしてください。すべてのフィールドと値を表示してください。✓ コピーしました
    → フラグの定義内容
  2. オーバーライドセットを確認する
    flags:new-checkout:allowlistとflags:new-checkout:blocklistのSMEMBERSを取得してください。ユーザー42はどちらかに含まれていますか？✓ コピーしました
    → メンバーシップの回答
  3. 修正して確認する
    ユーザー42をallowlistにSADDしてください。HGETALLを再取得して、フラグの状態がそれ以外変わっていないことを確認してください。✓ コピーしました
    → allowlist更新済み、他のフィールドは同一

結果： フラグが意図した状態と一致し、変更記録が検証された状態になります。

注意点
  • 調整なしにフラグキーへ書き込むと、他の管理者のテストを壊す可能性がある — 書き込みの前に#platformで告知する。できれば変更をログに記録する管理UIを使用する
組み合わせ： sentry

組み合わせ

他のMCPと組み合わせて10倍の力を

redis + sentry

キャッシュキーとそれを参照したSentryエラーを関連付ける

Sentryイベントでキャッシュキーuser:profile:42が欠落していると報告されています。そのキーをGETし、TTLを確認して、エビクトされたのか未作成だったのか判定してください。✓ コピーしました
redis + postgres

キャッシュされたカウントとPostgresの信頼できるソースを比較する

Redisからstats:active_users:todayをGETしてください。PostgresでSELECT COUNT(*) FROM users WHERE last_seen > ...を実行してください。差分を報告してください。✓ コピーしました
redis + filesystem

キーのスナップショットをエクスポートしてオフラインで分析する

session:*にマッチするすべてのキーをSCANし、キー+TTL+サイズを/tmp/session-audit.jsonlにダンプしてください。✓ コピーしました

ツール

このMCPが提供する機能

ツール入力呼び出すタイミングコスト
scan pattern: str, count?: int パターンでキーを検索する（常にこれを使用し、KEYSは絶対に使わない） free
type key: str 不明なキーに対してデータ型固有の操作を行う前に使用 free
get / set / del key, value?, ex? 文字列操作 — キャッシュ、カウンター、ロック free
hgetall / hset / hdel key, field?, value? ハッシュとして格納された構造化レコードの操作 free
sadd / smembers / sismember / srem key, member(s) ブロックリスト、許可リスト、メンバーシップの管理 free
zadd / zrange / zrangebyscore key, score+member(s) リーダーボード、優先度キュー free
xadd / xrange / xread / xpending / xclaim / xack stream ops Redis Streamsによるワークキュー free
ttl / expire / persist key, seconds? 有効期限の確認または設定 free
info / memory_usage section? / key 容量とパフォーマンスの検査 free

コストと制限

運用コスト

APIクォータ
Redisインスタンスのコマンド毎秒制限に依存します（MCPではなくお使いのインスタンスの制限）
呼び出しあたりのトークン
ほとんどのコマンドは200トークン未満。HGETALL/LRANGEはデータサイズに比例して増加します
金額
既存のRedisに対して無料。Redis Cloudの無料枠は30MBです。
ヒント
SCANには常に現実的なcountを指定してください（デフォルトの10は大規模環境では遅い。1000が適切なバッチサイズです）。

セキュリティ

権限、シークレット、影響範囲

最小スコープ： ACL user with `~pattern` and `+@read` for read-only work
認証情報の保管： REDIS_URL（パスワード含む）を環境変数に設定。rediss://によるTLS接続を推奨します
データ送信先： Redisエンドポイントへの直接TCP接続。サードパーティのプロキシは介在しません
絶対に付与しない： FLUSHALL FLUSHDB CONFIG SET SHUTDOWN

トラブルシューティング

よくあるエラーと対処法

NOAUTH Authentication required

REDIS_URLにパスワードが含まれていません。redis://:password@host:6379を使用してください。

確認： redis-cli -u $REDIS_URL PING
MOVED 1234 other-host:6379 (Redis Cluster)

標準のMCPはスタンドアロンクライアントを使用します。クラスター対応プロキシを指定するか、非クラスターのRedisエンドポイントを使用してください。

ERR unknown command 'JSON.GET'

これはRedis Stack専用のコマンドです。Redis Stack／Redis Cloudにアップグレードするか、ハッシュとして格納してください。

確認： redis-cli MODULE LIST
OOM command not allowed when used memory > 'maxmemory'

Redisの容量が上限に達しています。MEMORY STATSを確認し、エビクトまたはインスタンスを拡張して、今後の書き込みにTTLを設定してください。

確認： redis-cli INFO memory

代替案

Redis 他との比較

代替案代わりに使う場面トレードオフ
Memcached MCPデータ構造不要の単純なKVキャッシュが必要な場合対応範囲が大幅に小さい。リスト/セット/ストリームなし
DragonflyDB MCPRedis互換でマルチスレッド対応が必要な場合比較的新しく、すべてのモジュールが動作するわけではない

その他

リソース

📖 GitHub の公式 README を読む

🐙 オープンな issue を見る

🔍 400以上のMCPサーバーとSkillsを見る