Redux Toolkitとは？createSliceとRTK Queryの実装と採用判断【2026年8月版】

Redux Toolkit（RTK）は、Reduxのロジックを書くための公式ツールセットです。npm registryで2026年8月1日に確認した最新版は2.12.0で、内部にredux 5系・immer 11系・reselect 5系・redux-thunk 3系を抱えています。別物のライブラリではなく、Reduxそのものを少ない記述量で書くための包みだと捉えると位置づけを誤りません。この記事では、公式が減らそうとした定型コードの正体、createSliceが自動生成するアクションの対応関係、非同期処理をcreateAsyncThunkとlistenerMiddlewareへ振り分ける基準、RTK Queryを他のデータ取得ライブラリと比べる物差し、そして受託開発で採用してよい案件の条件までを実装目線で扱います。

まとめ：Redux Toolkitを採用してよい条件と見送るべき場面

結論から示します。Reduxを使うと決めた案件では、2026年時点でRTKを選ばない理由がありません。手書きのcreateStoreとswitch文のリデューサーは公式が非推奨として扱う書き方であり、新規に選ぶ利点は残っていません。加えて、複数画面をまたいで同じ状態を読み書きする、更新の履歴を追う必要がある、DevToolsで状態遷移を再生しながら不具合を追いたい、この3条件のいずれかに当たる中規模以上の業務アプリでは、RTKの構造が保守の助けになります。

見送るべき場面も明確です。状態がコンポーネント数個の範囲で閉じている画面、サーバーから取得したデータを表示するだけでクライアント固有の状態をほとんど持たない画面、そしてチームにReduxの経験者がいない小規模案件。この3つでRTKを持ち込むと、slice・store・selectorの層を維持するコストが、得られる見通しの良さを上回ります。サーバー状態の管理だけが目的ならRTK Queryか他のデータ取得ライブラリを単独で選び、クライアント状態だけが目的なら軽量ライブラリで足ります。以降の章は、この線引きの根拠になるAPIの中身を順に扱う構成です。

Redux Toolkitの定義｜Reduxコアとの関係と2.12系の構成

まずRTKが何を包んでいるのかを、公式の説明と実際の依存関係の両面から押さえます。ここを誤解したまま導入すると、Reduxとは別のライブラリを入れたつもりになり、後の判断がぶれます。

Redux公式が挙げた3つの不満とRTKのAPIが返した具体的な答え

Redux Toolkitの公式ドキュメントは、開発対象とした課題を3つ挙げています。「Reduxストアの設定が複雑すぎる」「Reduxを機能させるために多くのパッケージを追加する必要がある」「Reduxは過剰なボイラープレートコードを必要とする」の3点です。裏を返せば、RTKが提供する価値はこの3つに対応します。ストア設定を1関数へまとめること、必要なパッケージを同梱すること、リデューサーとアクションの記述を1箇所へ畳むこと。この3対応がAPIの設計思想そのものになっており、個別の関数の意図もここから逆算すると読み解けます。

npm実測で見る2.12.0の依存構成とreact-redux 9.3.0

数字で現在地を確認します。2026年8月1日時点のnpm registryでは、@reduxjs/toolkitのlatestタグが2.12.0でした。依存として抱えているのはredux 5系、immer 11系、reselect 5系、redux-thunk 3系、そしてスキーマ仕様のパッケージ群です。ReactとReact Reduxはピア依存かつ任意扱いで、React以外の環境でも成立する構成になっています。UI側を担うreact-reduxは別パッケージで、こちらのlatestは9.3.0、ピア依存はReact 18系または19系です。React 19で変わった仕様と新機能を踏まえると、React 19へ上げる案件ではreact-reduxを9系へ揃える手当てが前提になります。

既存Reduxを残したままRTKへ段階移行できる互換性の考え方

RTKはReduxコアを内包するため、既存のReduxアプリへ部分的に混ぜられます。configureStoreが返すのはRedux標準のストアであり、手書きのリデューサーをそのままreducerオプションへ渡せます。既存のミドルウェアも追加できるため、全面書き換えを待たずに新規のslice分だけをRTKで書く進め方が成立する方法です。導入の入口としては、Viteで組んだReactプロジェクトの構成に対して公式のViteテンプレートを参照しながらストアを差し込むのが手数の少ない順路です。

createSliceとconfigureStoreの実装｜定型コードが消える仕組み

RTKの体感的な差はこの2関数に集約されます。何が自動生成され、何が手元に残るのかを具体的に見ます。

createSliceが生成するreducerとactionの対応関係

createSliceは、スライス名を表す文字列、初期状態、そして名前付きのリデューサー関数群を受け取ります。戻り値はスライスのリデューサーと、対応するアクションクリエーターを含むオブジェクトです。ここで押さえるべきは命名規則で、name に「counter」を渡しreducers に「increment」を書けば、生成されるアクションのtypeは「counter/increment」になります。従来は定数ファイルにtypeを並べ、アクションクリエーターを書き、switch文で分岐させる3工程が必要でした。createSliceはその3工程を1つの定義へ畳みます。TypeScript環境では初期状態の型からstateの型が推論されるため、リデューサー内で型注釈を書き足す手間も減ります。

createSlice内部でImmerによる書き換え記法が不変更新に変換される仕組み

createSliceのリデューサー内では、stateを直接書き換えるように見えるコードを書けます。配列へのpush、プロパティへの代入がそのまま通ります。これはcreateSliceが内部でImmerを使い、書き換えの記述を不変更新へ変換しているためです。公式ドキュメントも、この仕組みによって誤った直接変更を避けられると説明しています。注意点は2つ。1つはこの記法が通用するのはRTKが用意したリデューサーの内側だけで、外部の関数へstateを渡して書き換えても反映されないこと。もう1つは、書き換え記法と新しいオブジェクトを返す記法を1つのリデューサーで混ぜないことです。混在させると変換の前提が崩れ、更新が握り潰される事故につながります。

configureStoreが既定で組み込むmiddlewareとDevTools

configureStoreは、ストアの生成に加えてRedux DevTools拡張の設定を自動で行います。thunkミドルウェアも既定で組み込まれるため、非同期のアクションを書き始めるのに追加設定は要りません。開発時には、状態を直接書き換えていないかを検査するミドルウェアと、シリアライズできない値がストアへ入っていないかを検査するミドルウェアも既定で動きます。この2つは開発中に警告を出す性質のもので、Dateオブジェクトやクラスインスタンスをそのままストアへ入れると警告対象です。警告を消すために検査を無効化する前に、値を文字列やプレーンオブジェクトへ直して格納するほうが後の不具合を減らせます。

非同期処理｜createAsyncThunkとlistenerMiddlewareの分担

非同期を扱う手段はRTKに複数あり、どれを選ぶかで保守性が変わります。使い分けの基準を実装単位で示します。

createAsyncThunkが吐く3つのアクションとextraReducers

createAsyncThunkは、非同期関数をラップして「開始」「成功」「失敗」の3種類のアクションを自動で送出します。typeの接尾辞はpending・fulfilled・rejectedで、スライス側ではextraReducersでこの3つを受け取り、読み込み中フラグやエラーメッセージへ反映させます。ローディング表示とエラー表示を状態として持ちたい画面では、この構造が素直に有効です。逆に、取得したデータをそのまま表示するだけで状態として保持する必要がない画面では、3アクション分の記述が過剰です。その判断は後述するRTK Queryの採否と直結します。

createListenerMiddlewareで副作用を宣言的に切り出す

アクションが送られたことを契機に別の処理を走らせたい場合、リデューサーへ副作用を書くのは筋が悪くなります。createListenerMiddlewareは、特定のアクションやstateの変化を条件に処理を登録する仕組みで、入力の間引き、通信のキャンセル、条件付きの再取得といった処理を本体のロジックから切り離せます。以前はsagaやobservableの導入で解いていた領域の一部を、追加パッケージなしで書けるようになった格好です。ただし複雑な並行制御を大量に組む案件では、専用ライブラリのほうが表現力が上回る場面が残ります。判断の目安は、リスナーの数が10を超えて相互に依存し始めたら専用ライブラリの検討へ移ることです。

createEntityAdapterで一覧データを正規化する実装

一覧と詳細を持つ画面では、配列をそのままストアへ入れると更新のたびに全件を走査する処理が増えます。createEntityAdapterは、idをキーにしたオブジェクトとidの配列という正規化された形を用意し、追加・更新・削除・並べ替えのリデューサーとセレクタを生成する仕組みです。数百件を超える一覧を扱う管理画面では、この形へ寄せておくと更新処理の記述量と描画コストの両方が下がります。件数が数十件で更新頻度も低い画面なら、素の配列のままで支障はありません。

RTK Queryの位置づけ｜TanStack Queryとの判断基準

RTKにはデータ取得とキャッシュを担うRTK Queryが同梱されています。これを使うかどうかは、状態管理の設計そのものを左右します。

RTK QueryのcreateApiとtagによるキャッシュ無効化の実装手順

RTK Queryでは、createApiでエンドポイントをまとめて定義します。定義したエンドポイントごとにReactのフックが自動生成され、読み込み中とエラーの状態、キャッシュの保持と再取得までを引き受ける仕組みです。更新系の処理を書く際は、providesTagsとinvalidatesTagsでタグの依存関係を宣言し、投稿が更新されたら一覧のキャッシュを無効化する、といった連鎖を定義します。手動でdispatchを呼んで再取得を書く必要がなくなるのが実装上の差です。通信部分はfetchBaseQueryが既定で用意されており、認証ヘッダの付与などはここへ集約できます。

RTK QueryとTanStack Query・SWRの選び分け

データ取得ライブラリは選択肢が複数あり、比較を求められる場面が多い領域です。判断軸は「Reduxストアを既に持つか」です。RTKでクライアント状態を管理しているなら、RTK Queryはストアの中に同居し、DevToolsで通信状態も一緒に追えます。Reduxを持たない構成であれば、TanStack Queryのv5系の仕様と使い方やuseSWRのfetcherとオプション設定のほうが導入は軽く済みます。Reduxを入れていない案件へ、RTK Queryのためだけにストアを立てる判断は勧めません。逆に、既にRTKを入れている案件へ別のデータ取得ライブラリを重ねると、キャッシュの置き場所が2箇所に分かれて状態の追跡が難しくなります。

旧Reduxと軽量ライブラリからの移行判断｜受託開発での線引き

ここからは見積りを立てる側の視点で、採否と移行の判断を言い切ります。技術的に書けるかどうかと、案件として選ぶべきかは別の問題です。

既存プロジェクトでcreateStore時代のコードをRTKへ寄せる手順

旧来の書き方が残るプロジェクトでは、次の順で寄せると差し戻しが起きにくくなります。第一に、createStoreをconfigureStoreへ置き換える。既存のリデューサーをそのまま渡せるため、この段階でアプリの挙動は変わりません。第二に、更新頻度の高いスライスから順にcreateSliceへ書き換える。第三に、定数ファイルへ並べたアクションtypeを削除する。createStoreとswitch文で組む旧来Reduxの構成を把握していれば、どのファイルが消える対象かは機械的に判別できます。全スライスを一度に書き換えず、機能単位で区切って進めるのが安全です。

Zustand・Jotai・Contextで足りる場面との線引き

状態管理を入れる前に、入れない選択肢を検討する順序が妥当です。テーマや認証情報のように更新頻度が低く読み取りが中心の値なら、React Context APIによる受け渡しで足ります。クライアント状態はあるが履歴の追跡もミドルウェアも要らないなら、Zustandの最小記述による状態管理やJotaiのアトム単位の設計のほうが記述量は少なく済みます。RTKを選ぶ根拠になるのは、状態遷移を追跡したい、ミドルウェアで副作用を統制したい、チームで書き方を揃えたいという3点です。この3点に当てはまらない案件でRTKを選ぶと、層の維持だけが残ります。

受託開発の見積りで画面規模と長期運用を踏まえて織り込む状態管理の保守コスト

状態管理の選定は、納品後の保守工数へ直接跳ね返ります。RTKを採る場合に見積りへ織り込むべきは、slice設計のレビュー時間、シリアライズ可能な形へ値を整える設計時間、そしてreact-reduxとReactのバージョン整合を追う保守時間の3つです。逆に軽量ライブラリを選ぶ場合は、規模が伸びたときに構造を入れ直す改修リスクを織り込みます。どちらが安いかは規模と保守期間で反転するため、着手前に画面数と想定運用年数を確認するのが実務の順序です。技術選定の根拠と運用体制まで含めて外部に任せる前提なら、業務用・Webアプリ開発の受託のように選定理由を提示できる相手を選ぶと、後の判断がぶれません。

よくある質問

Redux Toolkitの導入検討でよく挙がる質問に、実装と判断の両面から答えます。

Redux ToolkitはReduxとは別のライブラリですか？

別物ではありません。RTKはReduxコアを依存に含み、configureStoreが返すのもRedux標準のストアです。npm registryで2026年8月1日に確認した2.12.0は、redux 5系を内部に抱えています。公式もRTKをReduxロジックを書くための推奨手段として位置づけており、Reduxを使う判断とRTKを使う判断は分けて考える必要がありません。既存のRedux資産と混在させることも可能です。

createSliceの中でstateを直接書き換えても問題ないのですか？

createSliceのリデューサー内に限れば問題ありません。内部でImmerが働き、書き換えの記述を不変更新へ変換します。ただし通用する範囲は限定的で、リデューサーの外へstateを渡して書き換えた場合は反映されません。また、1つのリデューサーの中で書き換え記法と新しい状態を返す記法を混在させると、意図した更新が失われます。どちらか一方に統一してください。

RTK QueryとTanStack Queryはどちらを選ぶべきですか？

判断基準はReduxストアを既に持っているかどうかです。RTKでクライアント状態を管理している構成なら、RTK Queryを選ぶとキャッシュと状態が同じストアへ収まり、DevToolsで一緒に追跡できます。Reduxを使っていない構成であれば、TanStack Queryのほうが単体で完結し導入も軽く済みます。RTK Queryを使いたいという理由だけでReduxストアを立てる判断は勧めません。

Redux Toolkitは小規模なアプリにも向いていますか？

状態がコンポーネント数個で閉じる規模なら向いていません。useStateとContextで足ります。判断の目安は、3つ以上の画面が同じ状態を読み書きするか、状態遷移の履歴を追う要件があるか、副作用をミドルウェアで統制したいかの3点です。いずれにも当てはまらない場合、slice・store・selectorの層を維持するコストのほうが上回ります。

TypeScriptでRedux Toolkitを使う際に注意する点はありますか？

ストアの型からRootStateとAppDispatchの型を導出し、型付きのフックを1箇所で定義して全体で使い回す構成にしてください。createSliceは初期状態から型を推論するため、リデューサーごとの型注釈は基本的に不要です。createAsyncThunkでは、返り値の型と引数の型を明示すると、extraReducersで受け取るactionの型が確定します。react-reduxの型定義はReactの型に依存するため、React 19へ上げる場合はreact-redux 9系と型定義の版を揃える確認を先に済ませておくと手戻りが減ります。

関連記事

• Reduxの基本的な使い方：ステート管理の基礎：RTK以前のcreateStoreとリデューサーの書き方を確認できます
• TanStack Queryとは？React Queryとの違い・v5の使い方と脆弱性対策：RTK Queryと比較する際の対抗馬になります
• Zustandとは？Reactの状態管理を最小コードで実現する使い方：軽量ライブラリで足りる場面の判断材料になります
• Jotaiとは？概要や基本機能、状態管理の位置づけを解説：アトム単位の設計との比較検討に使えます
• Preactとは？Reactとの違いと採用判断を実装目線で解説：フロントエンド構成そのものを軽くする選択肢です