Valkeyとは｜Redisとの違い・ライセンス・移行判断を解説

Valkeyとは｜Redis 7.2から分岐したBSDライセンスのフォーク

Valkeyは、Redis 7.2.4のソースコードを起点に分岐したインメモリのキーバリューストアです。プロジェクトはLinux Foundationがホストし、ライセンスはBSD-3-Clauseという許容度の高いものが採用されています。

フォーク元がRedis 7.2系であるため、データ型・コマンド体系・通信プロトコル（RESP）はRedisから引き継がれています。つまり、アプリケーション側から見ると接続先が入れ替わっただけ、という状態を作りやすい設計です。

Linux Foundation配下という体制の意味

単一ベンダーが権利を持つプロジェクトと、財団がホストするプロジェクトでは、ライセンス変更のリスクの所在が変わります。

Redisのライセンス変更は、権利を一社が保有していたからこそ実行できました。Valkeyは財団ホスト・複数企業参加という体制を取っており、同種の変更が起きにくい構造になっています。AWS、Google Cloud、Oracle、Alibaba、Tencentなどが参加企業として名を連ねます。

ここは技術仕様ではなく統治構造の話です。しかし長期運用するシステムの基盤を選ぶとき、実はこちらのほうが効いてきます。

「Redis互換」はどこまでの互換か

互換性の範囲は、素のRedisコア機能とモジュール機能で分けて考える必要があります。

Redis OSSのコア機能（String、List、Hash、Set、Sorted Set、Stream、HyperLogLog等のデータ型と基本コマンド）については、ValkeyはRedis 7.2相当を引き継いだうえで独自に拡張しています。jedis、lettuce、go-redis、redis-pyといった既存クライアントライブラリは、接続先をValkeyに向ければ動作するケースがほとんどです。

一方、RediSearchやRedisJSONなどRedis社が提供するモジュール群は、Redis本体に内蔵されている機能ではなく別配布のモジュールです。ここに依存している場合、Valkey側に同等の実装があるかを個別に確認する必要があります。「Redis互換だから全部動く」と雑にまとめないでください。

ミニFAQ：Valkeyのデータファイルは、Redisのものをそのまま読めますか。

Redis 7.2系のRDB／AOFであれば読み込める設計になっています。ただしバージョンの組み合わせによって挙動が変わるため、本番適用前に実データでの復元テストを必ず挟んでください。

なぜValkeyが生まれたのか｜ライセンス変更の経緯と現在地

Valkey誕生の背景は、2024年3月のRedisライセンス変更です。ただし、この話は「2024年で止まっている解説」が多く、現在地を取り違えやすい論点でもあります。

2024年3月：BSDからRSALv2／SSPLv1へ

Redis社は、それまでBSDライセンスで配布していたRedisのコア部分を、RSALv2（Redis Source Available License v2）とSSPLv1のデュアルライセンスへ変更しました。

どちらもOSI承認のオープンソースライセンスではありません。特にマネージドサービスとしてRedisを提供するクラウド事業者にとっては、事業の前提が崩れる変更でした。

この直後、Redisの主要コントリビューターとクラウド事業者が中心となってValkeyが立ち上がります。フォークの起点となったのが、ライセンス変更前の最終版にあたるRedis 7.2.4でした。

2025年5月：Redis 8でAGPLv3が追加された

ここが見落とされやすい転換点です。

2025年5月、Redis 8のリリースにあわせて、Redis社はAGPLv3を第3のライセンス選択肢として追加しました。AGPLv3は、ネットワーク越しにサービスを提供する場合にもソース公開義務が及びうるコピーレフト型のライセンスで、OSIが承認しているライセンスの一つです。

つまり2026年10月時点の構図は、「オープンソースのValkey対プロプライエタリなRedis」という単純な対立ではありません。どちらもOSI承認ライセンスのもとで入手できる経路があり、違いはライセンスの性質（BSD系の許容型かAGPL系のコピーレフト型か）にある、というのが実務上の整理です。

ただし、どの配布物にどのライセンスが適用されるかは、入手経路や製品名称（Redis Open Source、Redis Softwareなど）によって異なります。自社の利用形態で問題になるかを判断するときは、Redis公式のライセンス表記で対象物を特定したうえで確認してください。

ライセンス種別そのものの違いはOSSライセンスとは｜GPL・MIT・Apacheの違いと商用利用の注意点で整理しています。AGPLはネットワーク越しの提供にもソース公開義務が及びうる点が、BSDと大きく異なります。

確定している事項と、変わりうる事項を分ける

ライセンス周りの情報は陳腐化が早い領域です。記事や社内ドキュメントを読むときは、次の3層に分けて読むと誤解が減ります。

同じ構図は他のOSSでも起きています。Terraformのライセンス変更を受けて生まれたOpenTofuがその一例で、判断の考え方はOpenTofuとは｜Terraformとの違い・ライセンスと選定基準にまとめています。フォークが生まれた背景と選定軸はValkeyとよく似ています。

ValkeyとRedisの違い｜ライセンス・ガバナンス・機能

結論から言えば、素のキャッシュ用途であれば実装上の違いを意識する場面は多くありません。差が出るのは、ライセンス・運用体制・一部の拡張機能です。

実装面の差は「拡張部分」に出る

コアのデータ型とコマンドを使う限り、置き換えで問題になることは稀です。

差が出やすいのは次のあたりです。Redis社独自のモジュール（全文検索、JSON、ベクトル検索など）を使っている場合、Valkey側で同等機能を得るには別のモジュールや構成が必要になります。また、監視まわりではメトリクス名やINFOコマンドの出力項目が一部異なることがあり、ダッシュボードやアラート定義の調整が発生します。

この監視側の手当ては見落とされがちです。Prometheus & Grafanaとは｜メトリクス監視の基本・Datadogとの違い・案件単価をフリーランス視点で解説で触れているようなexporter経由の構成を取っている場合、exporterのValkey対応状況も確認対象に入ります。

Valkeyのバージョンと性能改善（執筆時点）

バージョン情報は変わります。導入前にValkey公式のリリース一覧で最新状況を確認してください。本記事執筆時点（2026年10月）では、9.1系が最新のリリース系列です。

公式が示している改善幅

Valkey 9.0の公式announcementでは、パイプライン処理でのメモリプリフェッチにより最大40%のスループット向上、ゼロコピーレスポンスで最大20%の向上、BITCOUNTやHyperLogLogのSIMD最適化で最大200%の向上が示されています。Multipath TCPによるレイテンシ削減は最大25%とされています。

メモリ面では、Valkey 9.1のメモリ効率に関する公式記事でオーバーヘッドの最大44%削減が報告されています。

いずれもValkeyプロジェクトが自プロジェクトのベンチマーク条件下で示した「最大値」です。対象コマンド・データサイズ・並列数・インスタンスタイプが指定された条件での測定であり、一般的なワークロードで同じ改善幅が出ることを示すものではありません。移行の根拠に使うなら、自社の実ワークロードで測り直してください。

また、これらの数値はValkeyの旧バージョンとの比較であり、同時期のRedisとの比較ではない点にも注意が必要です。

古いバージョンを引き継ぐときの注意

案件によっては、Redis 6系やValkey 7.2系がそのまま動いている環境に入ることがあります。

古い系列は公式のメンテナンス対象から外れている可能性があり、セキュリティ修正が提供されないリスクがあります。参画時には、バージョンの確認とあわせてアップグレード計画の有無を必ず聞いてください。「動いているから問題ない」と「安全に運用できている」は別の話です。

マネージドサービスの対応状況｜ElastiCache・Memorystore

主要クラウドのマネージドサービスは、いずれもValkeyを標準的な選択肢として扱っています。実務上、移行の動機が最もはっきり出るのがこの領域です。

AWS ElastiCache

ElastiCacheはValkey、Redis OSS、Memcachedの3エンジンに対応しています。

料金面では、ElastiCacheの料金ページにValkeyのほうが低価格である旨が明記されています。ElastiCache Serverlessで33%低い料金、ノードベースで20%低い料金という記載です。既存のRedis OSSリザーブドノードを持っている場合も、Valkeyエンジンへアップグレードしたうえで予約の特典を引き継げるとされています。

この割合は、同一構成のRedis OSSと比較した場合の定価ベースの差としてAWSが公表している数値です。実際の削減額は、リージョン、インスタンスタイプ、リザーブドインスタンスの有無、データ転送量によって変わります。見積もりは自社構成で試算してください。後述する国内企業の移行事例では、年間で約7万円の削減という規模感が報告されています。規模によっては、移行工数に見合わないこともあるという目安になります。

バージョン対応では、AWSの発表により2026年5月5日からValkey 9.0が利用可能になっています。全商用リージョン、GovCloud、中国リージョンが対象で、追加費用なしとされています。

ElastiCacheそのものの位置づけは、マネージドDB全般の考え方を整理したAWS RDSとは｜マネージドDBの基本・MySQL/PostgreSQLとの違い・案件単価をフリーランス視点で解説とあわせて読むと理解しやすいはずです。

Google Cloud Memorystore

Memorystore for Valkeyでは、サポートバージョン一覧のとおりValkey 9.0が2026年3月11日に、9.1が2026年9月24日にGAとなっています。

性能面では、Memorystore for Valkey 9.1に関するGoogle Cloudの発表で、Memorystore for Redis Clusterと比較して最大3倍のQPSが示されています。これはGoogle Cloudが自社サービス間を比較したベンチマーク条件下の数値で、比較対象はOSSのRedisではなくMemorystore for Redis Clusterである点に注意してください。

ミニFAQ：マネージドサービスを使っている場合、OSSのバージョンアップにすぐ追随できますか。

できません。マネージドサービスは対応バージョンが提供されてから利用可能になるため、OSS本体のリリースから数か月の時差が生じます。上の日付を見ると、Valkey 9.0のOSSリリース（2025年10月）からElastiCache対応（2026年5月）まで約7か月の開きがありました。

Redisから移行すべきか｜判断フローとチェックリスト

ここが本記事の中心です。移行は「できるかどうか」ではなく「やる理由があるかどうか」で決めてください。

判断を3分岐で切り分ける

この表が本記事の要点です。ライセンス制約とコスト差が移行を押す要因、モジュール依存が移行を止める要因、というのが基本構造になります。

移行前チェックリスト

着手前に次を確認してください。上から順に、答えが出ないと先に進めない順番で並べています。

1. 現行のRedisバージョンとエンジン種別（Redis OSS／Redis Enterprise／ElastiCache for Redis OSS等）を特定したか

2. Redis社提供モジュール（RediSearch、RedisJSON、ベクトル型等）を使っていないか

3. 使用しているクライアントライブラリとそのバージョンを洗い出したか

4. Luaスクリプト、独自コマンド、クライアント側の特殊な接続設定がないか

5. 監視のメトリクス名・アラート条件がエンジン名に依存していないか

6. 永続化方式（RDB／AOF）と、スナップショットからの復元手順を確認したか

7. ライセンス要件について法務・契約担当の確認を取ったか

8. ロールバック手順を、実際に試したうえで文書化したか

9. 切替時の許容ダウンタイムを関係者と合意したか

10. マネージドサービス側が目的のValkeyバージョンに対応しているか

8番は特に重要です。後述する先行事例でも、ロールバック手順を用意していたことが事故回避につながっています。

移行の実務手順と所要期間の目安

移行の進め方は、自前運用かマネージドかで変わります。ここではマネージドサービス（ElastiCache）を前提に整理します。

基本的な進め方

検証環境での互換性確認から始め、ステージング、本番の順で進めます。本番の切替方式は主に2通りです。

ひとつはエンジンアップグレードによるインプレース移行。もうひとつはスナップショットから新しくValkeyクラスタを作成し、接続先を切り替える方式です。後者はロールバックが容易で、切り戻しの判断をしやすくなります。

期間の目安

期間は規模と用途で大きく変わるため、あくまで計画時の当たりとして扱ってください。

素のキャッシュ用途で、モジュール依存がなく、クライアントが標準的なライブラリのみという条件なら、検証からステージング適用まで2〜4週間程度を見込んでおくと余裕を持って進められます。セッションストアやジョブキューとして使っており、データロストが許容できない場合は、二重書きや段階的な切替の設計が加わるため、さらに時間がかかります。

この数字は条件付きの計画目安です。モジュール依存がある場合や、クラスタ構成・マルチリージョン構成を取っている場合は前提が変わります。

先行事例

実際の移行記録が公開されています。参考事例として読む価値があります。

DeNAのインフラSREチームによるElastiCache for RedisからValkeyへの移行記録、freeeの移行事例などが公開されており、いずれも自社での実施内容を一次情報として記録したものです。自社の構成に近いケースを探して読むと、見落としに気づけます。

このあたりの移行作業はインフラ寄りの領域で、SREとは？仕事内容・年収・必要スキルとDevOpsとの違いをエンジニア視点で解説で扱う役割の担当範囲と重なります。

移行でつまずきやすい落とし穴

事例ベースで、実際に報告されている詰まりどころを挙げます。

IaC側の設定漏れで移行が始まらない

JMDCの技術ブログ（2025年12月公開）では、ElastiCache for Redis 6.2からValkey 7.2への移行にあたり、TerraformでエンジンをValkeyに変更してapplyしたにもかかわらず、移行が開始されない事象が報告されています。

原因はapply_immediatelyの設定漏れでした。この指定がないと、エンジンアップグレードはメンテナンスウィンドウ待ちの状態に入ります。コンソール上では保留中のアクションによってブロックされている旨が表示されたとのことです。

この事例では、あらかじめ用意していたロールバック手順を使い、スナップショットからValkeyを指定して復元する形で完了させています。IaCのコードが通ったことと、クラウド側で変更が適用されたことは別という、わかっていても踏みやすい落とし穴です。

Terraformでの変更適用タイミングの扱いはTerraformとは？IaCの仕組み・できること・フリーランス案件の単価をエンジニア視点で解説でも触れている基本論点ですが、マネージドサービスのエンジン変更という文脈だと見落としやすくなります。

モジュール依存に後から気づく

検証環境でコアコマンドだけを試して「問題なし」と判断し、本番の一部機能で全文検索やJSON操作を使っていたことに後から気づくパターンです。チェックリストの2番を最初に潰してください。

監視・アラートが無言で壊れる

メトリクス名やINFO出力の差異により、ダッシュボードの一部が値を取れなくなることがあります。グラフが空になるだけなら気づけますが、アラート条件が評価されなくなると障害時に通知が飛ばない状態になります。切替後にアラートの発火テストまでやってください。

クラスタ構成の挙動差

クラスタモードを使っている場合、スロット移行やノード追加時の挙動がバージョンによって変わります。Valkey 9.0ではアトミックスロット移行が入っており、移行中の部分的な状態に起因する問題が改善されています。クラスタ運用をしているなら、対象バージョンの変更点は読んでおいたほうが安全です。Kubernetesとは？仕組み・Dockerとの違い・フリーランス案件の単価をエンジニア視点で解説で扱うような環境でセルフホストしている場合は特に該当します。

フリーランスエンジニアから見たValkey案件

実務での見え方を整理します。結論としては、Valkeyを単独のスキル要件として掲げる案件はまだ多くありません。評価されるのは移行を含む周辺実務のほうです。

案件要件での見え方

公開案件の要件欄では、Valkeyは「Redis／Valkey」のように併記される形で現れることが多く、単独で指定されるケースは限定的です。ElastiCacheやMemorystoreの運用経験を求める記載のなかに含まれている、という見え方もあります。

案件で「Redisを使っています」と書かれていても、実体はRedis OSS、Redis Community Edition、Valkey、ElastiCacheのいずれかに分かれます。参画前の確認事項として、エンジン種別とバージョンは聞いておくと認識齟齬を防げます。

単価への影響をどう見るか

以下は、2026年10月時点で首都圏中心の主要フリーランスエージェント数社の公開案件ページを確認し、Redis／Valkeyやインメモリキャッシュの運用に言及のある募集を観測ベースで整理した目安です。公開案件数がまだ多くない領域のため、相場というより傾向として読んでください。

Valkeyというキーワード単体で単価が上振れする、という傾向は公開案件からは確認できません。単価に効いているのは、キャッシュ層を含むインフラ全体の設計・運用経験、マネージドサービスでの移行実績、監視・障害対応の経験といった周辺スキルのほうです。

高めのレンジで募集されるのは、クラウドのマネージドサービス運用に加えて、IaCでの構成管理経験と、本番環境での無停止または短時間停止での移行を主導した経験を持つ層です。実務経験としては、インフラ／SRE領域で5年以上、かつデータストアの運用責任を持った経験があるケースが目立ちます。単なる「Redisを使ったことがある」とは評価が分かれます。

自分の経験でどのくらいのレンジを狙えるかは、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。単価を体系的に上げる考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？で整理しています。

どのポジションから入るか

Valkey単体を軸に案件を探すより、インフラ・データベース領域の案件から入るほうが現実的です。役割の全体像はインフラエンジニアとは？仕事内容や年収、将来性について解説やデータベースエンジニアとは？仕事内容から必要なスキル、年収について解説を参照してください。

実際の募集状況はフリコンの案件一覧で確認できます。

まとめ

Valkeyは移行の選択肢として現実的だが、全員が急いで移るべきものではありません。ライセンス制約とマネージドサービスのコスト差という2つの動機のどちらかが当てはまるなら検討する、というのが判断の基本線です。

• Valkeyは2024年3月にRedis 7.2.4から分岐し、Linux Foundation配下でBSD-3-Clauseのもと開発されています

• 2025年5月のRedis 8でAGPLv3が加わり、「Redisは非OSS」という前提は現在成り立ちません。ライセンスの性質の違いとして捉え直してください

• 移行を押す要因はライセンス要件とコスト差、止める要因はRedis社モジュールへの依存です

• ElastiCacheではValkeyがServerlessで33%、ノードベースで20%低い料金とされており、規模が大きいほど効きます

• 移行前チェックリストの10項目、特にモジュール依存の確認とロールバック手順の実地テストは着手前に終わらせてください

• 案件では「Redis／Valkey」併記で現れることが多く、評価されるのはエンジン名の知識より移行と運用の実績です

次のステップとして、現行環境のエンジン種別とバージョン、モジュール依存の有無を洗い出すところから始めてください。ここが確定しないと、移行の難易度も期間も見積もれません。

参照した一次情報は以下のとおりです。

• Valkey公式サイト

• Valkeyリリース一覧

• Valkey 9.0 announcement

• Valkey 9.1 メモリ効率に関する記事

• Amazon ElastiCache 料金

• ElastiCache Valkey 9.0 対応の発表

• Memorystore for Valkey サポートバージョン