TanStackは、特定のフレームワークにすべてを任せる製品ではありません。データ取得、テーブル、ルーティング、フォーム、仮想スクロールといった、Webアプリで繰り返し現れる難題を個別に解くライブラリ群です。必要なものだけ導入でき、複数を組み合わせればフルスタック開発にも広げられます。
名前だけを見ると新しい統合フレームワークに思えますが、出発点は長く使われてきたReact向けライブラリでした。
小さなライブラリ群からTanStackへ育った
現在のTanStack Tableにつながるreact-tableのGitHubリポジトリは2016年に始まりました。行や列、並べ替え、絞り込みなどのロジックに集中し、表示方法は利用者に任せる「ヘッドレス」な設計です。この考え方は、後のTanStack製品にも共通しています。
2019年にはReact Queryのリポジトリが作られました。APIから取得したデータを「サーバー側に正本がある状態」と捉え、キャッシュ、再取得、失効、更新処理をまとめて管理します。画面ごとにuseEffectで通信処理を書くより、データの寿命を宣言的に扱えることが広く支持されました。
大きな転換点は2022年です。React Query v4はTanStack Queryへ改称され、フレームワークに依存しないコアと、ReactやVue、Solid、Svelte向けのアダプターを組み合わせる構成へ移りました。React専用ツールの集まりから、共通の設計思想を持つマルチフレームワークのプロジェクトへ変わった時期です。
その後、型安全なルーティングを担うTanStack Routerと、Routerを核にSSR、ストリーミング、サーバー関数を加えるTanStack Startが育ちました。2026年9月現在、Startはリリース候補版です。機能とAPIは安定段階に入っていますが、正式版前であることは導入判断に含める必要があります。
TanStackは「全部入り」より交換可能な部品を選ぶ
TanStackの公式サイトは、自らを「Webのためのオープンソース・アプリケーションスタック」と説明しています。共通する特徴は、ヘッドレス、型安全、組み合わせ可能という3点です。
ヘッドレスとは、状態と振る舞いを提供し、完成画面の組み立てを利用者に委ねる設計です。たとえばTableは表の見た目を決めません。利用中のデザインシステムに合わせてHTMLやコンポーネントを組み立てられる代わりに、表示部分は自分で用意します。
型安全は、TypeScriptの型定義が付いているというだけではありません。Routerはルート、パスパラメータ、検索パラメータまで把握し、存在しない遷移や不正な値を開発中に見つけます。Query、Form、Startも、入力から結果まで型をつなぐことを重視しています。
組み合わせ可能という性格も重要です。Queryだけを既存のReactアプリへ追加しても構いません。RouterとQueryを一緒に使うことも、さらにStartを加えてサーバー側まで担当させることもできます。TanStack側も、抽象化は任意かつ交換可能であるべきだと説明しています。
まず押さえたい主要ライブラリ
TanStack Queryは、APIなどの非同期データを取得し、キャッシュと同期を管理します。商品一覧、ユーザー情報、検索結果のように、サーバーが正本を持つデータに向いています。モーダルの開閉や入力途中の文字列など、画面だけで完結する状態を何でもQueryへ入れるものではありません。
TanStack Tableは、大量の表データを並べ替え、絞り込み、ページ分割するためのロジックを提供します。見た目を自由に作りたい管理画面や業務システムと相性がよい一方、完成済みの表コンポーネントをすぐ置きたい場合は別のUIライブラリのほうが早いこともあります。
TanStack Routerは、ReactとSolid向けの型安全なルーターです。パスだけでなく検索パラメータを第一級の状態として扱います。絞り込み条件やタブ、ページ番号をURLへ保存し、共有や再読み込みに耐える画面を作るときに強みが出ます。
TanStack Formはフォーム状態と検証を、TanStack Virtualは長い一覧のうち画面に見える範囲だけを描画する処理を担当します。どちらも、アプリが複雑になってから自作すると手間が膨らみやすい領域です。
TanStack Startは、Routerを中心にサーバーレンダリング、ストリーミング、サーバー関数、APIルート、ミドルウェアをまとめたフルスタックフレームワークです。Routerの考え方を保ったままサーバー側へ広げたい場合に選択肢となります。
既存アプリには困っている場所から足す
TanStackを使うために、アプリ全体を書き換える必要はありません。既存のReactアプリなら、最初の候補はQueryです。通信処理やローディング表示、再取得の判定が各画面に散らばっているなら、導入効果を確認しやすいでしょう。
次に、具体的な問題へ合わせてTable、Form、Virtualを追加します。複雑なURL状態や型の弱い画面遷移が負担になった段階でRouterを検討するのが自然です。ライブラリ名をそろえること自体を目的にすると、移行コストばかり増えます。
QueryとRouterは役割が重なって見えます。Routerのローダーは画面遷移に必要なデータを揃える役目、Queryは複数画面で再利用するサーバー状態のキャッシュと更新を担う、と分けると整理しやすくなります。単純なアプリならRouter内蔵のキャッシュだけでも足ります。
新規開発でも、Startを自動的な正解にしない
新しいSPAを作り、URL状態と型安全な遷移を重視するなら、TanStack Routerは有力です。公式CLIではRouterだけを使う構成も生成できます。
SSRやサーバー関数まで必要で、React Routerの設計をフルスタックで統一したいならTanStack Startを比較対象に入れます。ただし、Next.jsから機械的に乗り換える理由にはなりません。Next.jsはReact Server Components、画像、フォント、メタデータなどの統合機能を持ちます。一方のStartは、明示的なローダーとサーバー関数、ルート単位のレンダリング制御を重視します。チームが理解しやすい実行モデルと、必要な周辺機能で選ぶべきです。
Startは2026年9月時点でリリース候補版なので、新規プロジェクトでは試作を作り、デプロイ先、認証、データ取得、エラー処理まで一巡させてから採用を決めるのが安全です。
TanStackの価値は段階的に深く使えることにある
TanStackは、Queryという成功した単機能ライブラリを巨大なフレームワークへ置き換えたものではありません。現場で繰り返す問題を、独立した部品として解き続けた結果、必要に応じてフルスタックまで届く構成になりました。
まず困っている場所へ一つ入れ、効果を測る。ルーティングやサーバー側まで同じ思想で統一したくなったら、次の部品を足す。この順番なら、TanStackの強みである交換可能性を失わずに使えます。
公式情報:
