Valkeyとは？Redisとの違い・Streamsの使い方と導入手順【Valkey 9.1】

Valkey（バルキー）は、Redisが2024年3月にライセンスを変えたことを受けて、Redis OSS 7.2.4から分かれたインメモリのキーバリューストア（KVS）です。Linux Foundationのプロジェクトとして、BSD-3-Clauseライセンスのまま開発が続いています。2026年10月16日時点の最新安定版は9.1.2（GitHubでの公開は2026年9月1日、リリースノートの日付は8月31日）で、9.2.0のリリース候補版（rc1）も公開されています。

この記事では、Redisとの違いと選び方、各版のサポート期間を最初に整理し、そのあと実務で使うStreams、Pub/Sub、TTL、JSONの使い方と、Docker・Ubuntu・Windowsへの導入手順を説明します。コマンドの出力は、Homebrewで入れたValkey 9.1.2で実際に実行して確かめたものです。

まとめ：Valkeyを選ぶ判断の要点

• Redis 7.2までのコマンドはそのまま動く：Valkey 9.1.2も INFO server で redis_version:7.2.4 を返します。既存のRedisクライアントからはコードを変えずに接続できます。
• ライセンス・料金・機能を分けて判断する：Redis 8は2025年5月1日からAGPLv3も選べるようになりましたが、BSDと同じ条件ではありません。自社の配布・提供形態でAGPLv3を受け入れられるかを確かめたうえで、使っているクラウドの料金と、Redis 8のベクトルセットや同梱モジュールなどValkeyに無い機能への依存を見ます。
• AWSではValkeyが安い：ElastiCacheはRedis OSSより、ノード型で20%、Serverlessで33%安い料金です。Google CloudのMemorystore for Valkeyは、Memorystore for Redis Clusterと同じ単価です。Azureのマネージドサービス（Azure Managed Redis）はRedis Enterpriseが基盤です。
• Streamsで永続的なキューを組める：Pub/Subと違ってメッセージが保存され、コンシューマグループで配信とACKを管理できます。取りこぼしを抑えるには、AOFのfsync設定まで決めておく必要があります。
• 本番は9.1か8.1に載せる：公式のサポート表では、9.1のバグ修正が2029年5月19日まで、8.1と7.2は拡張セキュリティサポートの対象です。9.0と8.0には拡張セキュリティサポートがありません。
• Windowsは公式サポート外：開発用途ならWSLかDockerで動かします。

Valkeyが生まれた経緯とRedisとの関係

Redisの開発元は、2024年3月にRedisのライセンスをBSDから、RSALv2とSSPLv1を選べるソースアベイラブルライセンスへ変更しました。どちらもOSI承認のオープンソースライセンスではなく、クラウド事業者がRedisをマネージドサービスとして提供することを制限する内容です。これを受けて、2024年3月28日にLinux Foundationの支援でValkeyが立ち上がりました。フォーク元はRedis OSS 7.2.4で、ライセンスはBSD-3-Clauseのままです。

その後、Redis側も方針を変えています。2025年5月1日の発表で、Redis 8からはRSALv2・SSPLv1に加えて、OSI承認のAGPLv3も選べるようになりました。ただしAGPLv3第13条は、改変版とネットワーク経由でやり取りする利用者に、その改変版の対応するソースコードを無償で取得する機会を提供するよう求めます。社内のサービスで改変せずに使うだけなら、どちらのライセンスでも実務上の制約は小さく、ライセンスの差が効くのは、Redisを組み込んで配布したりサービスとして提供したりする場合に限られます。

互換性の目安は INFO server の出力で確認できます。Valkey 9.1.2では次のように表示されました。

$ valkey-cli INFO server | grep -E "valkey_version|redis_version|server_name"
redis_version:7.2.4
server_name:valkey
valkey_version:9.1.2

redis_version は7.2.4のまま固定されており、クライアントライブラリはRedis 7.2.4のサーバーとみなして接続します。Valkey側の新機能は valkey_version で判定します。

RedisとValkeyの違い（2026年10月時点）

機能差：Redis 8の同梱機能とvalkey-bundle

Redis 8は、JSON・検索・時系列・確率的データ構造を本体に同梱しています。ValkeyではJSON・Bloom・検索を別モジュールとして開発しており（時系列のモジュールはありません）、Docker Hubの valkey/valkey-bundle イメージにValkey JSON・Valkey Bloom・Valkey Search・Valkey LDAPがまとめて入っています。9.1系のbundleに入っているのは、valkey-json 1.0.3・valkey-bloom 1.0.1・valkey-search 1.2.1です。素の valkey/valkey イメージや、OSのパッケージで入れたValkeyにはモジュールが入っていません。JSON.SET や FT.SEARCH を使うなら、bundleのイメージを選ぶかモジュールを自分で読み込みます。

Valkey JSONとValkey Searchの実行例（valkey-bundle 9.1）

「ValkeyはRedisJSONに対応していない」と書く記事がありますが、bundleのイメージではJSONのコマンドがそのまま動きます。valkey/valkey-bundle:9.1 を起動して実行した結果です（素の valkey/valkey:9.1 で同じ JSON.SET を送ると ERR unknown command になります）。

$ docker run -d --name vk -p 127.0.0.1:6379:6379 valkey/valkey-bundle:9.1
$ valkey-cli JSON.SET user:1 '$' '{"name":"taro","tags":["a","b"],"age":30}'
OK
$ valkey-cli JSON.GET user:1 '$.name'
["taro"]
$ valkey-cli JSON.NUMINCRBY user:1 '$.age' 1
[31]
$ valkey-cli JSON.ARRAPPEND user:1 '$.tags' '"c"'
3
$ valkey-cli TYPE user:1
ReJSON-RL
$ valkey-cli FT.CREATE idx ON JSON PREFIX 1 user: SCHEMA '$.age' AS age NUMERIC '$.name' AS name TAG
OK
$ valkey-cli FT.SEARCH idx '@age:[30 40]'
1
user:1
$
{"name":"taro","tags":["a","b","c"],"age":31}

TYPE がRedisJSONと同じ ReJSON-RL を返し、JSONPath（$.name）と旧形式のパス（.name）の両方が通りました。JSONのキーにも通常どおり EXPIRE で有効期限を付けられます。MODULE LIST で見ると、読み込まれていたのはjson（1.0.3）・search（1.2.1）・bf（Bloom 1.0.1）・ldapの4つです。Valkey Searchは数値・タグの索引に加えて、HASHの TEXT フィールドへの全文検索も通りました。ただし、RediSearchの集計（FT.AGGREGATE）や索引定義のオプションまで同じとは限らないため、既存の索引定義はbundleで1つずつ流して確かめてください。

RDBファイルの互換性：Redis 7.4以降の形式と読み込み制限

移行で見落としやすいのがRDB（スナップショット）の形式です。Redis 7.2系のRDBは版11（7.0は10）で、Redis 7.4.0以降は版12以上を書き出します（8.6は13、8.10は15）。Valkey 9.1.2のソース（src/rdb.h）は、12〜79を「foreign（非サポート・非OSS）」の形式として予約しており、既定の rdb-version-check strict では読み込みを拒否します。つまり、Redis 7.4やRedis 8のRDBファイルやレプリケーションから、そのままValkeyへ移すことはできません。relaxed に変えるとベストエフォートで読み込みを試みますが、Valkeyが知らない情報があればその時点で中断します。

逆方向も同じです。Valkey 9.0以降は版80でRDBを書き出すため、9系で取ったスナップショットはValkey 8系やRedisに戻せません。9系へ上げる前に、戻し先のバージョンでスナップショットを取っておく必要があります。

性能とメモリ：8.0のI/Oスレッドと8.1のハッシュテーブル

Valkey 8.0（2024年9月）では、I/Oスレッドが非同期化され、コマンドが使うキーをまとめてメモリへ先読みするプリフェッチと、デュアルチャネルのレプリケーションが加わりました。コマンドの実行自体はメインスレッドのままで、ネットワークの読み書きを複数スレッドに分けて処理します。既定値は io-threads 1（Homebrew版の設定ファイルでも同じ）なので、効果を得るには設定の変更が必要です。8.1（2025年3月）では、キー空間とHash・Set・Sorted Setのハッシュテーブルが新しい実装に置き換えられ、キーあたりのメモリ使用量が減りました。9.0では、ハッシュテーブルの処理にSIMD命令が使われるようになっています。

8.0の性能として引用される「毎秒119万リクエスト」は、Valkeyの公式ブログ（Unlock 1 Million RPS part 2、2024年9月13日）の値です。測定条件は、AWSのc7g.4xlarge（16コアのARM）に --io-threads 9（メインスレッド＋I/Oスレッド8本）で起動し、ネットワーク割り込みを処理するコアとメインスレッドのコアを分けたうえで、別のインスタンスから650クライアント・512バイトの値でSETを送り続けたものです。クライアントとサーバーを同じ開発用PCで動かす測定は、別インスタンスを使う公式の測定条件と異なります。CPU競合の影響も受けるため、公式値との単純比較は避けてください。io-threads の効果は、本番と同じインスタンス型でクライアントを別マシンに置いて測ってください。

Valkeyのバージョンとサポート期間（8.0〜9.2 RC）

8.0〜9.2 RCの主な変更

表のGA日はGitHubでの公開日（UTC）です。2026年8月31日〜9月1日には、4系列が同時にパッチ版（9.1.2・9.0.6・8.1.10・8.0.11）を出しました。9.1.2のリリースノートでは緊急度が「SECURITY」で、認証なしで突けるLuaインタプリタのuse-after-free（GHSA-fq2f-crmw-q97r）が修正されています。本番ではマイナー版を固定し、パッチ版は速やかに上げてください。

9.2.0-rc1のリリースノートには、ほかにもパス検索向けの新しいデータ型Path Hash（PH* コマンド）や、大きなSorted SetをB+木で持つ変更（OBJECT ENCODING が skiplist でなく btree を返す）が入っています。OBJECT ENCODING の値を監視や移行スクリプトで判定している場合は、9.2へ上げる前に確認が必要です。2026年10月16日時点で9.2.0の正式版は出ていません。

サポート期間：保守3年と拡張セキュリティ5年

Valkeyには「LTS」という名前の版はありません。代わりに、公式ドキュメントの「Releases and versioning schema」が、マイナー版ごとの期限を定めています。各マイナー版は最初のリリースから3年間、バグ修正とセキュリティ修正のパッチが出ます。メジャー版ごとに最後のマイナー版1つだけは、初回リリースから通算5年間、拡張セキュリティサポートの対象になります。保守3年の終了後に、さらに5年が加算される制度ではありません。

出典はValkeyの公式ドキュメント（Releases and versioning schema）の表です。LTSに当たる長期の選択肢は8.1と7.2で、9.0と8.0は保守の終了と同時にセキュリティ修正も終わります。9.xのどのマイナー版に拡張サポートを付けるかは、次のメジャー版が出た時点で決めると書かれているため、9.1の2031年は確定ではありません。いま新しく入れるなら9.1、Ubuntu 24.04のaptで入る7.2系をそのまま使うなら、保守が2027年4月16日に切れることを前提に更新計画を立ててください。

マイナー版をまたぐ更新は、既定の設定なら混在させても互換が保たれます。ただし公式ドキュメントは、マイナー版の違うサーバーでクラスタを組み続けることを推奨しておらず、メジャー版の更新ではレプリカを先に上げるよう求めています。

Valkey Streamsの使い方：コンシューマグループとACKによる再配信

Streamsは、追記専用のログにIDの付いたエントリーを積むデータ型です。Valkeyのドキュメントは、Pub/Subのメッセージが「fire and forget」で保存されないのに対し、Streamsはリストのように取り出しても消えない点で根本的に違うと説明しています。ストリーム本体とコンシューマグループの状態は、どちらもAOF・RDBとレプリカへ伝わります。

XADDからXACKまでの基本の流れ

注文イベントを課金処理のワーカーへ配る例です。XGROUP CREATE の MKSTREAM を付けると、キーが無くてもストリームごと作成されます。

$ valkey-cli XGROUP CREATE orders billing '$' MKSTREAM
OK
$ valkey-cli XADD orders '*' order_id 1001 amount 3200
1790543228399-0
$ valkey-cli XADD orders '*' order_id 1002 amount 1800
1790543228412-0
$ valkey-cli XREADGROUP GROUP billing worker-1 COUNT 10 STREAMS orders '>'
# （出力は省略：2件が worker-1 に配信される）
$ valkey-cli XPENDING orders billing
2
1790543228399-0
1790543228412-0
worker-1
2
$ valkey-cli XACK orders billing 1790543228399-0
1

XREADGROUP で配信されたエントリーは、ACKされるまでPending Entries List（PEL）に残ります。XPENDING の結果が「件数・最小ID・最大ID・コンシューマ別の件数」の順で返っており、XACK した1件だけがPELから外れます。ACKし忘れるとPELが増え続けるので、処理が成功した直後にACKする設計にします。

Pythonでのコンシューマ実装（valkey-py 6.2.0）

ワーカーが処理の途中で落ちると、配信済みでACKされていないエントリーがPELに残ります。再起動したワーカーがそれを拾い直すには、IDに >（新着）ではなく 0（自分宛ての未ACK分）を指定して読みます。下のコードは、Valkey 9.1.2とvalkey-py 6.2.0（Python 3.12）で未ACK分と新着を処理した単発の検証例です。各読み取りは最大10件で終了します。常駐ワーカーにする場合は、自分の未ACK分を空になるまで読み、XAUTOCLAIMの返却カーソルをたどる回収処理と、新着の継続取得を組み込みます。2026年10月12日に出た6.2.0はPython 3.11以上が必要で、3.9や3.10の環境では6.1.1までしか入りません。

import valkey

r = valkey.Valkey(host="localhost", port=6379, decode_responses=True)
STREAM, GROUP, CONSUMER = "orders", "billing", "worker-1"

try:
    r.xgroup_create(STREAM, GROUP, id="$", mkstream=True)
except valkey.exceptions.ResponseError as e:
    if "BUSYGROUP" not in str(e):   # 2回目以降の起動ではグループが既にある
        raise

def handle(entry_id, fields):
    print("charge", entry_id, fields["order_id"], fields["amount"])
    r.xack(STREAM, GROUP, entry_id)

# 1) "0" = 自分に配信済みで未ACKのもの（前回落ちた分）  2) ">" = 新着
for start in ("0", ">"):
    for _stream, entries in r.xreadgroup(GROUP, CONSUMER, {STREAM: start}, count=10, block=2000):
        for entry_id, fields in entries:
            handle(entry_id, fields)

# 3) 他のコンシューマが60秒以上ACKしていないものを引き取る
_next, claimed, _deleted = r.xautoclaim(STREAM, GROUP, CONSUMER, min_idle_time=60000, start_id="0-0", count=10)
for entry_id, fields in claimed:
    handle(entry_id, fields)

print("pending:", r.xpending(STREAM, GROUP)["pending"])

valkey-pyはredis-pyからフォークしたクライアントで、メソッド名はredis-pyと同じです。既存のredis-pyのコードは、import redis を import valkey as redis に替えるだけで動きます（valkey.Redis は valkey.Valkey の別名です）。

ACKの前にワーカーが落ちると、同じエントリーがもう一度処理されます。Streamsの配信は「少なくとも1回」なので、課金のように重複が許されない処理では、order_id を処理済みとして記録し、2回目は何もせずACKだけ返すようにします。

止まったワーカーの分を回収するXAUTOCLAIM

ワーカーが落ちたまま戻らない場合、そのワーカー宛てのエントリーは誰にも処理されません。XAUTOCLAIM は、指定した時間以上ACKされていないエントリーの所有権を、呼び出したコンシューマへ移します。上のコードでは、他のワーカーに配信されて60秒以上放置された分を引き取っています。検証では、worker-9 に配信したまま放置した1件を worker-1 が引き取り、処理後に pending: 0 になりました。

同じエントリーが何度も回収される場合は、処理側の不具合を疑います。XPENDING の拡張形式が返す配信回数を見て、一定回数を超えたものは別のストリームへ退避します。こうしないと、処理できないメッセージが延々と再配信されます。ストリームの長さは、XADD の MAXLEN ~ 100000 で近似的に制限できます。ただし、未処理・未ACKのエントリーも削除対象になります。注文や決済のキューでは、全グループの処理状況と必要な保持期間を確認してから削除条件を決めます。

Pub/SubとStreamsの使い分け

Valkeyのドキュメントは、Pub/Subの配信を「at-most-once」（届くとしても1回まで）と明記しています。購読者が接続していない間に発行されたメッセージは失われ、後から取り直せません。チャットの入力中表示のように、通知の取りこぼしを許容できる用途にはPub/Subを使えます。キャッシュ無効化に使う場合は、通知が失われても古い値が残り続けないよう、TTLや再接続時のキャッシュ破棄を併用します。注文や決済のように取りこぼしを避けたいイベントはStreamsを使います。ただし、Valkeyのドキュメントは、既定の非同期レプリケーションではフェイルオーバー時に XADD やコンシューマグループの状態が失われうると注意しています。消失を減らすには、AOFを appendfsync always にし、必要に応じて WAIT でレプリカへの反映を待ち、戻り値が要求したレプリカ数を満たすか確認します。それでも、フェイルオーバー時の書き込み消失を完全には防げません。注文や決済では、永続的な正本からイベントを再送できる設計も必要です。

ジョブキューとして使うなら、Streamsを直接扱うより、BullMQのようなライブラリに任せる方法もあります（BullMQとは？v6のPostgreSQL対応・リトライとワーカー運用を実装者目線で解説）。

9.2で追加予定のXACKDELとXDELEX

9.2.0-rc1では、ACKとエントリーの削除を1回で行う XACKDEL と、条件付きで削除する XDELEX が追加されました。どちらも KEEPREF（既定）・DELREF・ACKED のモードを持ちます。ACKED を指定すると、すべてのコンシューマグループでACK済みになったエントリーだけを消せます。9.1.2で実行すると ERR unknown command 'XACKDEL' が返ります。9.2.0-rc1では試せますが、本番への採用は9.2正式版の公開後に互換性と動作を確認して判断します。

有効期限（TTL）の設定：キー単位とハッシュのフィールド単位

キー単位の有効期限は、Redisと同じく EX オプションや EXPIRE で付けます。TTL の戻り値は、残り秒数、有効期限なしなら -1、キーが無ければ -2 です。

$ valkey-cli SET session:abc u42 EX 1800
OK
$ valkey-cli TTL session:abc
1800
$ valkey-cli PERSIST session:abc      # 有効期限を外す
1
$ valkey-cli TTL session:abc
-1
$ valkey-cli TTL nokey
-2

Valkey 9.0からは、ハッシュの個々のフィールドにも有効期限を付けられます。APIはRedis 8.0と互換です。ユーザー情報のハッシュの中で、ワンタイムパスワードのフィールドだけを60秒で消す例です。この例は、JSONの例とは別の検証用DBで、キー user:1 が存在しない状態から実行します。

$ valkey-cli HSET user:1 name taro otp 123456
2
$ valkey-cli HEXPIRE user:1 60 FIELDS 1 otp
1
$ valkey-cli HTTL user:1 FIELDS 2 otp name
60
-1

9.1では、複数のキーを同じ有効期限付きで一度に書き込む MSETEX も追加されました（MSETEX 2 a 1 b 2 EX 100 のように、先頭にキーの数を書きます）。HEXPIRE系は9.0から、MSETEXは9.1からのコマンドなので、クライアント側で valkey_version を確認してから使います。

Valkeyの導入手順（Docker・macOS・Ubuntu/Debian・Windows）

Docker公式イメージでの起動

公式のコンテナイメージはDocker Hubの valkey/valkey で、Valkeyコミュニティが管理しています。以下はJSONの章とは別の起動例です。先に起動したコンテナやHomebrewのValkeyが6379番ポートを使っている場合は、そちらを停止してから実行します。マイナー版のタグ（9.1）は、その系列のパッチ版に更新されます。ただし、起動済みコンテナは自動更新されないため、新しいイメージを取得してコンテナを再作成する運用が必要です。

docker run -d --name valkey -p 127.0.0.1:6379:6379 \
  -v valkey-data:/data \
  valkey/valkey:9.1 valkey-server --appendonly yes

docker exec -it valkey valkey-cli PING

公式イメージは設定ファイルなしで起動し、protected-mode を無効にしてビルドされています。そのため -p 6379:6379 と書くと、認証なしのValkeyがホストの全インターフェースに公開されます。上の例のように 127.0.0.1 に限定し、外部へ公開するなら requirepass かACLを必ず設定してください。JSONや検索のモジュールが必要なら、イメージを valkey/valkey-bundle:9.1 に替えます。

macOSのHomebrewでの導入

Homebrewのformulaは9.1.2です。brew install valkey で入れると、valkey-cli などに加えて redis-cli・redis-server という名前のシンボリックリンクも作られるので、既存のスクリプトもそのまま動きます。同じ名前のコマンドを入れるため、Homebrewのredisとは同時にインストールできません。設定ファイルは /usr/local/etc/valkey.conf（Apple Silicon機では /opt/homebrew/etc/valkey.conf）にあります。

brew install valkey
brew services start valkey   # 常駐させる場合
valkey-cli PING

Ubuntu・Debianのaptでの導入と版の差

sudo apt install valkey-server で入りますが、入る版はOSのリリースによって大きく違います。2026年9月時点で公式リポジトリから入る版は次のとおりです。

Ubuntu 24.04のaptで入るのは7.2系で、ハッシュフィールドのTTLやI/Oスレッドの改善は使えません。9系が必要ならDockerイメージかソースからのビルドを選びます。redis-cli という名前で呼びたい場合、Ubuntu 24.04では valkey-redis-compat パッケージを追加します。Ubuntu 26.04とDebianにはこのパッケージがありません。

Windowsの公式サポート外とWSL・Docker運用

Valkeyの公式ドキュメント（Installation）は「Valkey is not officially supported on Windows」と明記しており、Windows向けのネイティブバイナリは配布されていません。開発用途では、WSL上のUbuntuに上のaptの手順で入れるか、Docker Desktopでコンテナを動かします。WSL 2で起動したValkeyには、Windows側から localhost:6379 で接続できます。本番のWindows Serverで動かす構成は避け、Linuxのサーバーかマネージドサービスを使います。

最初に見直す設定（valkey.conf）

• valkey.confの既定は bind 127.0.0.1 -::1（Homebrew版は ::1）と protected-mode yes です（Dockerイメージは前述のとおり例外）。外部から接続させる場合は、bindを変えたうえで requirepass かACLを必ず設定します。
• maxmemory は既定で無制限、maxmemory-policy は noeviction です。キャッシュ用途では maxmemory で上限を決め、ポリシーを allkeys-lru などに変えます。noeviction のままだと、上限に達した後の書き込みがエラーになります。
• appendonly no が既定です。Streamsをキューとして使うなら appendonly yes にし、appendfsync（既定は everysec＝最大1秒分を失いうる）を要件に合わせて選びます。

監視：redis_exporterでPrometheusへ出す

Valkeyの公式ブログ（Valkey Metrics in Prometheus、2026年9月22日）は、Prometheusで監視する出発点として、Redis用に広く使われてきたredis_exporterと、クラスタ全体とスロット単位の指標を出すBetterDB Monitorの2つを挙げています。redis_exporterはValkeyをそのまま監視でき、v1.94.0をvalkey-bundle 9.1に向けて起動すると、9121番ポートの /metrics から次の値が取れました。

$ docker network create vknet
$ docker network connect vknet vk      # 上で起動したvalkey-bundleのコンテナ
$ docker run -d --network vknet -p 127.0.0.1:9121:9121 oliver006/redis_exporter:v1.94.0 \
    --redis.addr=redis://vk:6379
$ curl -s localhost:9121/metrics | grep -E "^redis_(up|memory_used_bytes|instance_info)"
redis_instance_info{...,redis_version="7.2.4",...,valkey_release_stage="ga",valkey_version="9.1.2"} 1
redis_memory_used_bytes 5.760824e+06
redis_up 1

指標名は redis_ で始まりますが、redis_instance_info のラベルに valkey_version が入るので、RedisとValkeyが混在する環境でもダッシュボードで区別できます（上の出力は長いラベルを一部省略しています）。8.1で入ったCOMMANDLOGの指標と、CLUSTER SLOT-STATS によるスロット別の書き込み数は、BetterDB側でしか取れません。

クライアントライブラリ：Valkey GLIDEと既存Redisクライアントの比較

Valkeyの移行ガイドは、既存のRedisクライアントがコード変更なしで接続できるとしています。新規に選ぶなら、Valkey組織が管理するクライアントも候補にし、必要な9系コマンドへの対応状況を各クライアントのリリースノートで確認します。

Valkey GLIDEは、Rustで書いたコアを各言語から呼ぶ構造のクライアントです。Python・Java・Node.js・Goに対応し、C#（NuGetのValkey.Glide 1.1.0）とPHP（1.1.2）も正式版が出ています。Spring Data Valkeyは、GLIDE・Lettuce・Jedisの3つをドライバーとして選べます。Djangoでは、django-commonsが管理するdjango-valkey（0.4.1）をキャッシュバックエンドに使えます。セッションの保存先をどう選ぶかは、Djangoのセッション設定：保存先5種の選び分けとRedis構成の判断で整理しています。

マネージドサービスの提供状況（AWS・Google Cloud・Azure）

AWSでは、Amazon ElastiCacheとAmazon MemoryDBがValkeyをエンジンとして提供しています。ElastiCacheの料金ページは、ValkeyがRedis OSSなど他のエンジンより、ノード型で20%、Serverlessで33%安いと明記しています（原文は「33% lower price on ElastiCache Serverless and 20% lower price on ElastiCache node-based」）。Serverlessは最小データ容量も100MBで、他エンジンより90%小さくなります。Redis OSS用に買ったリザーブドノードは、同じインスタンスファミリー・リージョンのValkeyノードにそのまま適用されます。MemoryDBでもValkeyの方が30%安く、東京リージョンのdb.r7g.largeで毎時0.2597ドル対0.371ドルです（AWS Price List、2026年9月11日版）。詳細はAmazon ElastiCacheとは？対応エンジン・Serverlessとノードベースの違いと料金・採用判断を実装者目線で解説とAmazon MemoryDBとは？ElastiCacheとの違い・料金と2026年の選び方を実装者目線で解説を参照してください。

Google Cloudには、フルマネージドのMemorystore for Valkeyがあります。アイオワ（us-central1）の単価は、shared-core-nano（1.4GB）が1ノード毎時0.0318ドル、standard-small（6.5GB）が毎時0.1425ドルです。Memorystore for Redis Clusterの同じ構成（redis-shared-core-nano・redis-standard-small）も同額なので、Google CloudではエンジンをValkeyに替えても料金は下がりません。クラスタモードとノードタイプの選び方、gcloudでの作成手順、自前Redisからの移行はMemorystore for Valkeyの作成と移行の手順をまとめた記事で扱っています。

Azureのマネージドサービスは、Azure Cache for Redisの後継にあたるAzure Managed Redisで、Microsoftのドキュメントによると基盤はRedis Enterpriseです。Valkeyについては、Azure Kubernetes Service（AKS）上にValkeyクラスタを自前で構築する手順がMicrosoft Learnで公開されています。AzureでValkeyを使うならAKSで自前運用し、マネージドを優先するならAzure Managed Redisを選ぶ、という分かれ方になります（Azure Cache for Redisとは？仕組み・5つの階層と料金・Azure Managed Redisへの移行手順を実装者目線で解説）。

どのクラウドのどのサービスに載せるか、自前運用とマネージドの境目から決めたい場合は、弊社のインフラ構築（AWS・Google Cloud・Azure）の支援でもご相談を受けています。

RedisからValkeyへ移行する判断と注意点

移行して得になるのは、AWSのマネージドサービスで、Redis 7.2以前の機能だけを使っているケースです。エンジンを切り替えるだけで料金が下がり、アプリのコードは変わりません。

次のどれかに当てはまる場合は、移行を見送るか、先に使用機能を洗い出してください。

• Redis 8のベクトルセットや、Redis Stackのモジュール（RedisJSON・RediSearch）のコマンドや索引定義に依存している。Valkeyのモジュールは別実装で、コマンドの互換範囲はモジュールごとに異なります。
• Redis 7.4以降で取ったRDBファイルから復元する計画になっている。前述のとおり、版12以上のRDBは既定の設定では読み込めません。
• Azureを使っていて、マネージドサービスをやめる予定がない。

ElastiCacheでは、既存のRedis OSSクラスタをValkeyへその場でアップグレードできます。JMDCの技術ブログ（2025年12月24日）によると、Terraformで engine = "valkey" に変えたとき apply_immediately = true を入れ忘れ、切り替えがメンテナンスウィンドウ待ちになって取り消せなくなりました。このケースでは、事前に用意していたスナップショットからValkeyとして復元し、接続先を切り替えて移行を完了しています。切り替え前のスナップショットと、戻す手順の確認は省かないでください。

用途別の設計は、セッション管理とは？セッションIDの発行から失効までの実装と保存先選定を解説も参考になります。サーバーを持たずにHTTP経由で使いたい場合は、Upstashとは？サーバーレスRedisの料金・無料枠と使い方【2026年9月】のようなサーバーレスの選択肢もあります。

Valkeyのよくある質問

Valkeyの読み方は？

国内では「バルキー」と表記されることが多く、英語の発音に近い表記は「ヴァルキー」です。

AWSのValkeyとは何ですか？

Amazon ElastiCacheとAmazon MemoryDBでエンジンとして選べるValkeyのことです。ElastiCacheではRedis OSSよりノード型で20%、Serverlessで33%安い料金が設定されています。サーバーレス版の概要はElastiCache Serverless for Valkeyとは？ サービスの基本概要と特徴を解説で解説しています。

Valkeyは永続化できますか？

できます。Redisと同じく、RDB（定期スナップショット）とAOF（書き込みログ）の2方式があります。どちらも設定ファイルの save と appendonly で指定し、併用もできます。

ValkeyはWindowsで使えますか？

公式にはサポートされていません。開発用途ならWSL上のLinuxにインストールするか、Dockerで valkey/valkey イメージを動かします。

Valkeyの最新バージョンはいくつですか？

2026年10月16日時点の安定版は9.1.2（GitHubでの公開は2026年9月1日）です。9.2.0-rc1が2026年9月16日に公開されており、正式版はまだです。長く使う版を選ぶなら、拡張セキュリティサポートの対象になっている8.1（2030年3月31日まで）か、新しい9.1を選びます。最新の版はGitHubのvalkey-io/valkeyのリリースページで確認できます。

関連記事

• Amazon ElastiCacheとは？対応エンジン・Serverlessとノードベースの違いと料金・採用判断を実装者目線で解説
• Amazon MemoryDBとは？ElastiCacheとの違い・料金と2026年の選び方を実装者目線で解説
• Azure Cache for Redisとは？仕組み・5つの階層と料金・Azure Managed Redisへの移行手順を実装者目線で解説
• BullMQとは？v6のPostgreSQL対応・リトライとワーカー運用を実装者目線で解説
• Upstashとは？サーバーレスRedisの料金・無料枠と使い方【2026年9月】