【厳選】もう戻れない！2025年版 快適すぎる開発スタック 10選

はじめに

2025年、私の開発者体験（DX）は大きく進化しました。

SQL、'use client'の分断、認証実装、Stripeの税金地獄...いよいよ、これらから解放される時が来たのです。
なぜ開発はつまらないと感じるのか。
もちろんAIの影響もあるでしょうが、私は根本原因として、「やりたくないことや面倒なことまで開発者自身がやらないといけない」というのが大きな原因だと思います。

また、開発というものはAIを使うにしても本来クリエティブであるべきと考えています。
もう面倒なことは手放し徹底的にDXを追求し、本来のあるべき開発を取り戻しましょう！

この記事では、私が実際に使って「もう戻れない」と感じた技術スタックを10個紹介します。
良いDXは良いUXを生み出します。開発者の心の余裕が、クリエイティビティが、ユーザーのことを考える余裕と素晴らしい体験を生むからです。

1. TanStack Start

Next.jsに苦しめられるのやめませんか？

Next.jsはパフォーマンスを追求するのであれば、最高のソリューションの1つといえますが、往々にしてOverspecになりがちです。

さらに面倒なのがディレクティブです。
Next.js 16以降ではCache Componentが正式な機能となり、'use client'や'use server'に加え'use cache'というディレクティブが追加されました。

これまでのNext.jsのcacheを考えると'use cache'は確かに良いです。
ただ、そもそもディレクティブって本当にいるか？ と最近違和感を感じています。
これらが増え続けた先はどうなるのでしょうか？そこにDXはあるのか疑問に感じています。

例えば、'use client'は、本来1つのコンポーネントでいいものが、Server ComponentとClient Componentと2つに分けないといけなかったりします。

一方、TanStack Startではディレクティブの概念が存在せず、今後も導入されることはないだろうと私は見ています。
根拠は以下の記事で、作者のTanner Lisleyさんがディレクティブの増殖に対して懸念とソリューションを示しているためです。

またServer Componentでのfetchについて、標準のfetch関数では型がつかないので、自力で型付けするか、しっかり型定義する場合、openapi-fetch・oRPC・Honoなどを導入するなどする必要があります。

Server Functions - Type-safe RPCs between client and server

一方TanStackはデフォルトでTypeScript 100%サポートされており、型安全が最初から担保されています。

さらに、Routeの型安全性にも難点があります。
確かにNext.jsにはtypedRouteがありますが、不完全です。
SearchParamsなどはどうしてもnuqsなど外部ライブラリで型をつけるしかありません。

TanStack Start relies 100% on TanStack Router for its routing system.

この点もTanStackはもちろん型がつきます。

2. Convex

SQL書くのやめませんか？

Convexはオープンソースのリアクティブデータベースで、DB以外にも、認証・Function・Cron・Storageなどバックエンドに必要なソリューションが揃ったSupabaseと同じBaaSのような存在です。

SupabaseやORMなどを使っていると、どうしてもSQLを書かないといけない場面が出てきます。
非常に面倒くさいです。

例えば、Schemaですが、Supabaseは明示的にSQLでテーブル定義しますが、ConvexはTypeScriptによる宣言的な定義で記述できます。

supabase/schema.sql

-- `tasks`テーブルのスキーマ定義
CREATE TABLE tasks (
  id SERIAL PRIMARY KEY,
  text TEXT NOT NULL,
  is_completed BOOLEAN DEFAULT FALSE,
);

-- `tasks`テーブルの変更をリアルタイム機能で有効化
ALTER PUBLICATION supabase_realtime ADD TABLE tasks;

convex/schema.ts

import { defineSchema, defineTable } from "convex/server";
import { v } from "convex/values";

export default defineSchema({
  // "tasks"テーブルのスキーマをオブジェクトとして定義
  tasks: defineTable({
   text: v.string(),
   isCompleted: v.boolean(),
 }),
});

そう、Convexは一切、SQLを書く必要がないのです。

さらに言えば、ConvexはDXを中心に設計されています。

例えば、サーバーを起動すれば以下のようなことが自動で起こります

• 環境変数ファイルは自動生成
• SchemaをDBに自動反映
• もちろんFunctionやCronなども自動反映
• 当然、ファイルが更新されれば、更新内容も自動反映
• etc

Convex is a "document-relational" database. "Document" means you put JSON-like nested objects into your database. "Relational" means you have tables with relations, like tasks assigned to a user using IDs to reference documents in other tables.

加えて、Convexはdocument-relational DBなので、JSONも扱えるうえにIDによるRelationを持つことも可能なのです。
さらに、デフォルトでリアルタイム機能が備わっているのも高ポイントです。

SQLから解放されるときが来たのです。

3. Clerk

認証に時間を使うのやめませんか？

Clerkは、認証・ユーザー管理に特化した認証系SaaSです。認証およびユーザー管理に必要な機能は揃っているという充実性。

これだけでも素晴らしいですが、公式UIコンポーネントの充実度も高いです。

基本的に、公式ドキュメントの手順に沿って、画面ポチポチ、コードコピペするだけで、認証についてはあらかた完成してしまいます。

認証の機能もUIもできるなら自分で用意したくないというのが大多数です。
そして、そんな最高のDXを実現できるのがClerkです。

車輪の再開発をしたい人なんて誰もいないですよね？

4. ElysiaJS

OpenAPI生成で苦しむのやめませんか？

ElysiaJSは、Bun上で動作する高性能なTypeScript Webフレームワークです。「JS/TS界隈のFastAPI」と呼ばれています。

クライアントワークをしているとどうしてもOpenAPI準拠しドキュメントを生成しないといけない場面がかなり訪れます。

私は現状普段の個人開発はすべて、Convexでやっていますが、業務でConvexを使う日は日本ではまだまだ遠いんだろうなと思ってしまうくらい、RDB・OpenAPIが好きな人が多いようです。

そこでElysiaJSです。
OpenAPIならHonoでも準拠できるだろと思いますが、ElysiaのDXはHonoを遥かに凌駕します。

ElysiaJS自体がOpenAPIを採用しているので、この1行を追加するだけで、OpenAPIドキュメントの生成が可能です。

import { Elysia, t } from 'elysia'
import { openapi } from '@elysiajs/openapi'

new Elysia()
+    .use(openapi()) 
    .get('/user/:id', ({ params: { id } }) => id, {
        params: t.Object({
            id: t.Number()
        })
    })
    .listen(3000)

さらに型からOpenAPIスキーマを生成することもできます。

import { Elysia, t } from 'elysia'
import { openapi, fromTypes } from '@elysiajs/openapi'

export const app = new Elysia()
    .use(openapi({
+    	references: fromTypes() 
    }))
    .get('/user/:id', ({ params: { id } }) => id, {
        params: t.Object({
            id: t.Number()
        })
    })
    .listen(3000)

それ以外にはoRPCという選択肢もあり、OpenAPI準拠に関しては、oRPCもDXも負けず劣らずという感じです。

しかし、ElysiaJSはOpenAPI準拠だけではないのです。
型安全性は言うまでもないですが、Bunネイティブなフレームワークであるがゆえ、パフォーマンスも非常によく、マルチランタイム対応されているなど、多くのメリットがあります。

もうOpenAPIで苦しむのには終止符を打ちましょう。

5. Polar.sh

Stripeの税金地獄から解放されませんか？

Polar.shは、ソフトウェア開発者向けの決済プラットフォームです。Merchant of Record（MoR）として、グローバルな税務コンプライアンスを代行してくれます。

Polar内部ではStripeを使っているので信頼性は担保されています。Polar.shはStripeの上に構築された「MoR + 請求 + エンタイトルメント」レイヤーです。

さらに、Polar.shの最大のメリットは、国際的な税務コンプライアンスをすべて管理してくれることです。

デジタル製品を世界中で販売するには、数十もの管轄区域でVAT、GST、売上税を取り扱う必要があり、それぞれの税率、規則、申告要件が異なります。多くの開発者は、この点（リスクが高いため）を無視するか、国際販売を完全に避けています。

Polar.shはお客様の販売責任者（Merchant of Record）として、世界中で税金の計算、徴収、納税を行います。お客様はプロダクト開発に集中し、事務手続きはPolar.shが行います。

そのため、どの国に向けても決済を組み込んだサービス展開をできるようになるため、今まで税制などが壁になっていたものをPolar.shに任せれば、一気にサービスを拡大できます。

簡単に言えば、日本国内・日本人開発者も国外に目を向けてマーケティングできたり、国内外問わずサービスをリーチできるようになります。

さらに、DXでもStripeの完全上位互換を達成しています。

Stripeを使って開発したことがある人なら、その複雑さに辟易した経験があるはずです。従量課金の実装ではサブスク扱いになるなどはあるあるだと思います。
要するに、Stripeは結構、直感と反することが多いのです。

一方、Polarは人間工学に基づいているので、直感的に開発を進めることができます。

Stripeの税金地獄から解放される時が来たのです。

6. Vercel

インフラを意識するのやめませんか？

Vercelは、フロントエンド開発者向けのデプロイ・ホスティングプラットフォームです。Next.jsの開発元でもあります。

Vercelと既存インフラのAWSなどの比較は言うまでもないですが、開発に集中するやDXだけ見たらVercelの圧勝です。

さらにいうと、Vercel Market Placeの充実度合いが半端ないです。
ここにあるサードパーティーのサービスを簡単にVercelに統合することが可能になるのです。

例えば、2025年11月24日には本記事でも紹介したConvexが追加されたり、同年12月1日にはAWSの各種Databaseが追加されたりしており、Vercelさえ使っていれば、大抵のサービスとの統合や連携ができるのです。

確かにAWSは素晴らしいインフラですが、Vercelに比べて手間や管理コストが掛かります。
さらにいえば、Market Placeのような概念もないので、サードパーティーのライブラリの組み込みにも非常にコストがかかります。

また、ダッシュボードもAWSはごちゃごちゃしている印象を受け、私個人としては、決して使いやすいとは言えません。
ここはさすがNext.jsを手掛けているVercelという感じではあります。

こういった本来取られるべきではなかった時間やコストを、Vercelに任せてプロダクト開発に集中するときが来ました。

インフラを意識しない開発体験。これに尽きます。

追加で言うと、Vercelは独自のFluid Computeを使っており、これが従来のコールドスタートがあるサーバーレスの上位互換として注目されています。
実際にコストも削減されますし、本当に使っているときしか課金されないのです。

まさに開発者のことを考えられたプラットフォームの1つがVercelなのです。

7. Cursor

CLI・IDE・Desktopの往復終わりにしませんか？

Cursorは、AI補完をネイティブに統合したコードエディタです。

昨今、CLI型AIエージェントが台頭もしてきており、CLI上で作業したり、IDE上で作業したりと、とにかくツール間の移動が多く、非常に手間です。
フロントエンドはここにブラウザも加わってきます。

Cursorはそんな手間をなくしてくれます。

Cursor 2.0以降の機能はそんな手間をなくし、開発者が欲しかった機能を提供してくれます。

それが、Composer・AIコードレビュー・ブラウザー機能です。

Composerは、同等の知性を持つモデルと比べて4倍速い最先端のエージェント型コーディングモデルです。さらに、マルチエージェント機能により、1つのプロンプトで最大8つのエージェントを並列実行できます。

各エージェントはコードベースの独立したコピー上で個別に動作するため、ファイル競合を防ぎながら、複数のタスクを同時に進められます。
また、各エージェントのアウトプットの比較も容易にすることができます。

AIコードレビュー機能では、Cursor上でバグの検出と修正まで直接行えます。
変更内容を解析し、問題点を検出してサイドパネルに表示します。

GitHubやGitLabなどのソースコード管理プロバイダ上で動作するBugbotと連携し、PRの要約も自動生成してくれます。

ブラウザー機能は、エディタ内にブラウザを埋め込んで、要素の選択やDOM情報をエージェントへ渡すことができます。

さらにCursorにはボイスモードというものがあり、音声認識を使って声でエージェントを操作することも可能です。
現状、promptの入力音声入力が最速です。

この最高のDXを体感してほしい。

8. ni

パッケージマネージャーを意識するのやめませんか？

npm iをyarnプロジェクトで実行してしまった経験、ありませんか？

あるいは、プロジェクトごとにパッケージマネージャーが違って、毎回「あれ、このプロジェクトはpnpmだっけ？yarnだっけ？」と確認する手間。

niは、ロックファイル（package-lock.json、yarn.lock、pnpm-lock.yaml、bun.lockなど）を自動検出して、適切なパッケージマネージャーでコマンドを実行してくれるツールです。

npm、yarn、pnpm、bun、denoの違いを意識する必要がなくなります。

# どのプロジェクトでも同じコマンド
ni vite
# → npmプロジェクトなら npm i vite
# → yarnプロジェクトなら yarn add vite
# → pnpmプロジェクトなら pnpm add vite
# → bunプロジェクトなら bun add vite

nr dev --port=3000

# npm run dev -- --port=3000
# yarn run dev --port=3000
# pnpm run dev --port=3000
# bun run dev --port=3000
# deno task dev --port=3000

nun webpack
# npm uninstall webpack
# yarn remove webpack
# pnpm remove webpack
# bun remove webpack
# deno remove webpack

さらに、ni -iでインタラクティブにパッケージを検索してインストールできたり、nrでスクリプトを選択実行できたりと、開発体験が大幅に向上します。

パッケージマネージャーの違いに悩まされる時代は終わりました。

ちなみに、Catnoseさんも2025年かなり使われたようです。

9. Nani

翻訳に時間を使うのやめませんか？

Naniは、新しいAI翻訳ツールです。
ただ翻訳するだけではなく、AIが入力された内容に応じて解説や例文を添えて翻訳してくれます。

個人的にPromptは英語で入力するのですが、そんなときに、どういう表現がネイティブっぽいのかを瞬時にレスポンスしてくれるのがNaniです。
（個人で英語も学習しているため、これは本当に重宝してます）

従来の翻訳ツールは、単に文字列を置き換えるだけでした。
しかし、スラングや文脈に依存する表現、ニュアンスの違いなどは、単純な置き換えでは伝わりません。

Naniは、シーンやニュアンスごとのちょうどいい表現を複数提案してくれます。
さらに、翻訳後にAIが返信を作成する機能もあり、より細かいやり取りも可能です。

デスクトップ版を使えば、どのアプリのテキストもショートカットですぐに翻訳できます。翻訳した内容は端末上に安全に保存され、いつでも振り返れます。

翻訳に悩まされる時代は終わりました。

10. Resend

メールプロバイダー選択とメールHTML地獄から解放されませんか？

Resendは、開発者向けのメール送信APIです。そして、React Emailとの組み合わせで、メール送信のDXを劇的に向上させてくれます。

メール送信を実装する際、まず「どのプロバイダーを選ぶべきか？」という意思決定に悩まされます。
SendGrid、AWS SES、Mailgun、Postmark...選択肢は多く、それぞれの特徴や料金体系を比較するだけでも時間がかかります。

さらに、メールのHTMLは、使えるstyleが限られていたり、プロバイダーごとに挙動が異なったりと、一言で言うと面倒すぎるのです。

それを抽象化してくれるのがReact Emailです。Reactコンポーネントでメールテンプレートを作成でき、TypeScriptで型安全にメールを作成できます。

// React Emailでメールテンプレートを作成
import { Html, Body, Container, Text, Button } from '@react-email/components';

export function WelcomeEmail({ name, url }: { name: string; url: string }) {
  return (
    <Html>
      <Body>
        <Container>
          <Text>こんにちは、{name}さん！</Text>
          <Button href={url}>アカウントを有効化</Button>
        </Container>
      </Body>
    </Html>
  );
}

// Resendでメール送信
import { Resend } from 'resend';
import { WelcomeEmail } from './emails/welcome';

const resend = new Resend(process.env.RESEND_API_KEY);

await resend.emails.send({
  from: '[e-mail]',
  to: '[e-mail]',
  subject: 'ようこそ！',
  react: WelcomeEmail({ 
    name: '山田太郎',
    url: 'https://example.com/verify?token=xxx'
  }),
});

もちろん、主要なメールクライアント（Gmail、Apple Mail、Outlook、Yahoo Mailなど）をサポートしており、各クライアントでの互換性もサポートされています。

さらに強力なのが、Resendのメールテンプレート生成AIのnew.emailです。
簡単に言うと、v0のメール版です。

promptを打てば欲しいメールテンプレートがReact Emailの形式ですぐに作成されます。
このDXが実現できるのはResendだけです。

そして私が最も評価しているものが、React Emailのツール機能です。

まずは、SpamAssassin統合です。
これは、オープンソースのSpamAssassinライブラリを使ってメールコンテンツを分析し、メールプロバイダーによってスパムとしてマークされる可能性を予測できるというものです。

つまり、スパムのトリガーを特定できるということです。
過度な大文字使用、問題のあるフレーズ、隠しテキストなど、スパムの一般的な指標をフラグ付けしてくれます。

React Emailコードでこれらの問題を修正することで、スパムスコアを改善し、受信者の受信トレイに届く可能性を高められます。

やはり一番困るのは、何と言っても、スパム判定を食らいユーザーに届かないことです。
これがあるのとないのとでは随分サービスの質が違ったものになると私は考えています。

次に紹介するのは、Linter機能です。
これにより、メール特有のチェックを実行することが可能となります。

• メールリンクがHTTPSを使用し、有効であることを確認
• 画像にaltタグがあり、1MB以下のサイズ制限内であることを確認
• 互換性チェッカーがHTMLとCSSを分析し、Outlook、Gmail、Apple Mailなどの人気メールクライアントでサポートされていない可能性のあるスタイルやタグを特定

正直、普通のエンジニアがスパム判定されるかどうかなんて判断できるわけがないですし、Linterによる各種チェックが正確にできるとも思えません。
一言で言うと、こういうツールがあるのとないのとでは全く違うということです。

さらに、React EmailはHTMLにビルドも可能なので、SendGridやAWS SESなど他のメールプロバイダーにも、コンポーネントで作成したものを使い回せます。
つまり、プロバイダーを変更しても、メールテンプレートのコードはそのまま使えるのです。

React Email v5でさらに強力になった

もともとv4でも強力でしたが、v5でさらにReact Emailは使いやすく強力になりました。
追加されたものは複数ありますが、特にResend Templatesが大きなものかなと思います。

Resend Templatesは、チームでメールを共同編集するための機能です。

React EmailテンプレートをResendにアップロードすれば、技術者でないチームメンバーも、ビジュアルエディタでリアルタイムに共同編集できます。
つまり、Figmaのようなことが可能になったのです。

v5では、その他にもTailwind v4対応されたり、8つのコンポーネントが新しく追加となったり、そのDXがよくなる対応もされました。

つまり、React Emailを使わないのは、本当にもったいなすぎるのです。

メールプロバイダー選択とメールHTML地獄から解放される時が来たのです。

最近ExpoにもResend統合の新たなドキュメントが追加されたので、Webもモバイルも簡単にResendでメール機能の実現が可能になりました。

【番外編】 React Compiler Marker

Reactコンポーネント最適化に悩むのやめませんか？

React Compiler Markerは、VSCode/Cursor向けの拡張機能です。React Compilerによって最適化されたコンポーネントを視覚的にマーキングしてくれます。

React Compilerを導入しても、実際にどのコンポーネントが最適化されているのか分かりにくいです。

この拡張機能を入れると、エディタ上で✨または🚫マークが表示されます。

コードを書きながらリアルタイムで最適化状況が分かるという即座にフィードバック、これが本当に素晴らしいです。

さらに学習ツールとしても使え、なぜ最適化されないのか、ツールチップで理由が分かります。

この機能のお陰で、反復的な改善も可能で、コードを変更 → マークが🚫から✨に変わるのを確認できます。

// ✨ このコンポーネントは最適化されました
function OptimizedComponent() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(c => c + 1)}>{count}</button>;
}

// 🚫 クロージャの問題で最適化されませんでした
function NotOptimizedComponent({ callback }) {
  // ツールチップで理由が分かる
}

つまり、これまで開発者ツールでReact DevToolsを開いてベンチマークを取ったり、確認する手間が省けるのです。

Reactを使うなら個人的には必須の神拡張機能です。

React最適化の可視化から解放される時が来たのです。

おわりに

2025年、私のDX（開発者体験）は劇的に進化しました。

SQL、Next.jsのディレクティブ、認証実装、Stripeの税金処理...これら「やりたくないこと」から解放される時代が来ています。

本記事で紹介した10個の技術スタック・ツールは、すべて「面倒なことを手放す」という共通の思想を持っています。開発者が本来集中すべき「クリエイティブな部分」に時間を使えるよう、煩雑な作業を自動化・抽象化してくれます。

DXが良ければUXも良くなる。開発者の心の余裕が、ユーザーのことを考える余裕を生み、結果として素晴らしい体験を生み出すからです。

TypeScriptを知ってしまったらJavaScriptには戻れないように、これらの次世代開発者体験を知ってしまったら、もう元には戻れないことを保証します。

面倒なことは手放し、本来の開発を取り戻しましょう。

参考文献

1. TanStack Start

2. Convex

3. Clerk

4. ElysiaJS

5. Polar.sh

6. Vercel

7. Cursor

8. ni

9. Nani

10. Resend

【番外編】 React Compiler Marker