さとまたwiki

🧭 ベストプラクティスが多すぎて選べない

✍️ 執筆: Claude Opus

JavaScript疲れに、プロは"決めない技術"で勝つ — 2026・Vercel × AI起業の意思決定

結論を一言で 「最適解が複数あって常に選ばされている」感覚は、あなたの実力不足ではなくエコシステムの構造（JavaScript疲れ）。プロは個別の正解を覚えるのではなく、①多数派に乗る ②枯れた技術を選ぶ ③オピニオネイテッドな"束"に乗る ④一度決めて記録する(ADR) ⑤AIを制約する——という「決め方（意思決定の型）」で選択そのものを消している。本記事はその型を、2026年の一次データと原典で渡す。

🧭 Section 1: なぜ選べないのか — JavaScript疲れの正体

このセクションの3点

① あなたの「常に選ばされている」という感覚は気のせいでなく、構造的に正しい

② "JavaScript疲れ（JS Fatigue）"は 2015年に命名された、10年来の既知の現象

③ 原因はnpmの細分化思想 × JSの汎用言語化 × 低参入障壁による選択肢の組合せ爆発

状態管理に Zustand か Jotai か Redux かで迷い、CSSは素の CSS か Tailwind か CSS Modules か styled-components かで分岐し、 AIに「ベストプラクティスで書いて」と頼んでもなんとなく微妙なコードが出てくる。 そんな経験をしているあなたへ — これはあなたの実力不足ではありません。 エコシステムの構造そのものが、選択を無限に生み出すように設計されているのです。
Django や Rails を触ったことがある人なら分かるはずです。 あのフレームワークでは「ORMはこれ」「ルーティングはこれ」とほぼ自動的に決まる。 ところが JavaScript の世界に来た途端、すべてのレイヤーで「さあ、選んでください」が始まります。

JS疲れ（JavaScript Fatigue）の起源

この現象に最初に名前をつけたのは Eric Clemmons です。 2015年12月の記事 "Javascript Fatigue" で、 「JSエコシステムの選択疲れ」を初めて構造的に言語化しました。 2015年の記事がいまだに共感を呼び続けているということは、原因が表面的なトレンドではなく、 エコシステムの根本構造にあることを示しています。

なぜ選択肢が爆発するのか — 3つの構造的原因

原因具体的な現象帰結（あなたへの影響）
① npmの細分化思想状態管理・ルーター・バンドラーがそれぞれ独立パッケージ。 Redux / React Router / webpack を別々に選ぶ設計になっている。組合せ数が爆発し「正しいスタック」が無限に存在するように見える。
② JSがブラウザ唯一の汎用言語SPA / SSR / SSG / モバイル / CLI まで同一言語。 ユースケース全域で競合フレームワークが乱立する。「自分の用途に合うのはどれか」という問いが永遠に続く。
③ npmの低参入障壁誰でも数分でパッケージを公開できる。 2026年現在 npm には 300万超のパッケージが存在する。「最新・最良」を探すほど候補が増え、情報が古くなるサイクルが速い。

300万+

npmパッケージ総数（2026年現在）

2015

JS疲れが命名された年（Clemmons）

10年

解決されずに続く構造問題

この記事が渡すもの
この記事は「正解を1つ覚える」ためのものではありません。
どのフレームワークが最強かを告げる代わりに、「どう決めるか」という意思決定の型を渡します。
型を持てば、今後どれだけ新しいツールが登場しても、同じ手順で素早く決断できるようになります。

→ 次の Section 2 では「データで見る2024-2026の多数派（収束先）」を解説する。まず現実の多数派を把握することが、最初の選択コストを最小化する。

📊 Section 2: データで見る"今の多数派"

このセクションの3点

① 迷ったらまず多数派に乗るのが探索コスト最小——正解を探すより"情報量が多い選択"を選ぶ

② 2024〜2026 の収束先は明確——State of JS 2024 / JS Rising Stars 2024 のデータが裏付け

③ Tailwind / shadcn / Next.js / Zustand + RSC が事実上の標準——迷う必要はすでに消えている

7.8M

Tailwind CSS 採用案件数（Bootstrap 5.2M を抜き 1 位）

+38k

shadcn/ui 2024 新規スターJS Rising Stars 総合 1 位

+10.8k

Zustand 2024 新規スター状態管理カテゴリ 1 位

44%

Next.js 使用率メタFW 最大シェア

出典: State of JS 2024 / JS Rising Stars 2024

メタフレームワーク — 使用率 × 保持率

フレームワーク使用率 / 規模保持率・満足度特徴
Next.js44%（最大）68%（メタFW中 低め）エコ最大・Vercel公式・LLM学習量最多。RSC移行で覚えることが増えた
Astro小〜中規模94%（最高）コンテンツ重視・Islands Architecture・JS送信量ゼロが基本
SvelteKit小〜中規模90%Runes(v5)・Form Actions・シンプル設計。Vercel × Cloudflare で動く
Nuxt~18%中程度Vue.js 案件で安定。Vue経験者以外は採用メリット薄
Remix~8%中程度Web標準重視。React Router v7 と統合。Epic Stack の土台
出典: State of JS 2024 Libraries

状態管理 — 2024 新規スター数 × 位置づけ

ライブラリ2024 新規スター位置づけ2026の採用判断
Zustand+10.8k（1位）グローバル UI 状態の新規標準テーマ・モーダル等の真のグローバル状態に使う
Jotai+3.1kアトミック状態管理Zustand より細粒度。Recoil の後継として選ばれる傾向
TanStack Query急成長サーバー状態の実質標準CSRでキャッシュ/再取得/楽観更新が要る場合。RSCなら不要になることも
XState+2.1kステートマシン・複雑フロー複雑な状態遷移が必要な場面限定。学習コスト高め
Redux Toolkit絶対量最多・新規減少レガシー維持新規プロジェクトでは基本選ばない。既存コードの保守用
出典: JS Rising Stars 2024

スタイリング / UI コンポーネント — 2024〜2026 の状況

ツール2024〜2026 の状況採用判断備考
Tailwind CSS v47.8M 案件・1 位（Bootstrap 5.2M を抜く）積極採用CSS-first・Oxide エンジン。UIの記述場所が 1 箇所に固定
shadcn/uiRising Stars 総合 1 位 (+38k)・90k+ stars積極採用コピペ所有モデル（ロックインなし）+ RSC 対応 + Radix プリミティブ
CSS Modules安定継続スコープ CSS 必要時RSC と相性良好。Tailwind と組み合わせ可
vanilla-extract台頭・静的抽出型安全 CSS が要る場合ゼロランタイム CSS-in-TS。デザインシステム構築向け
styled-components2025-03-17 メンテナンスモード入り新規非推奨Context API 依存で RSC 非互換。既存コードの保守のみ
出典: State of JS 2024 / JS Rising Stars 2024 / styled-components メンテモード告知
多数派 ≠ 正義だが、多数派には「情報量・AI 学習量・採用容易性」で複利が効く。 Stack Overflow の解決策が豊富で、LLM の出力品質が高く、チームメンバーが入りやすい。 個人起業 × Vercel の文脈では、エコシステムの大きさ自体がリスクヘッジになる。 「最新・ニッチ」より「使われている・情報が多い」を優先するのは合理的な選択だ。

→ 次の Section 3 では「最適解が複数ある」という感覚の正体を、発想の転換から解剖する。

🔀 Section 3: 発想の転換 — 「最適解が複数」は意思決定の問題

このセクションの3点

① ベストプラクティスが複数あるのは「局所最適が多数ある」だけで、差は小さく可逆

② プロは各選択を最適化しない。「選択の回数」を減らすメタ戦略を最適化している

③ 以降の3戦略（枯れ技術 / オピニオネイテッドな束 / 一度決めて記録）が具体的な処方箋

「React の状態管理、どれを選べばいい?」「Tailwind か CSS Modules か、いつまで迷えばいい?」—— この悩みの正体は、あなたの技術力の問題ではありません。 どの選択肢もそれぞれの文脈で正しい、すなわち局所最適が多数存在しているだけです。 差は多くの場合小さく、後から変更も可能。つまり「どれが一番か」を突き詰める行為そのものが消耗です。
経験あるエンジニアが「迷う時間が短い」のは、より深い知識を持っているからではなく、 選ぶ回数を減らす仕組みを持っているからです。 1つひとつの選択を最適化するのではなく、「決め方（メタ戦略）」を最適化している。 あなたの悩みはこの構造に気づいていない段階で発生しています。
💡 Rails / Django 経験者へ — あなたはすでに知っている
Rails（2004）と Django が解いた問題は「設定より規約（Convention over Configuration）」です。 モデル・ビュー・コントローラの置き場所、URLの命名、DB マイグレーションの手順—— 「どこに何を置くか」を毎回決めなくていい仕組みがフレームワークに最初から入っていた。 その感覚を JS に持ち込むのが最短ルートです。Next.js や SvelteKit の「ファイル＝ルーティング」はまさにその思想の実装です。

選択を消す 3 つのメタ戦略

戦略一言で言うと何の選択を消すか詳細
① 枯れた技術を選ぶ
Choose Boring Technology		「新しい」より「既知の失敗モードがある」を優先する「最先端 vs 安定」の比較検討コスト。未知のバグ調査コスト。sec4 →
② オピニオネイテッドな束に乗る
T3 / Epic Stack / next-forge		個別に選ぶのをやめ、「誰かが決めた一式」を採用するFW・ORM・認証・スタイリング…初期の数十個の選択がまとめて消える。sec5 →
③ 一度決めて、記録する
ADR		決定を文書化し「なぜそうしたか」を残すことで再検討コストをゼロにする毎回の蒸し返し。AIが別技術を提案してくる際の迷い。sec6 →
📌 「どれも局所最適」という見方が正しい理由
State of JS 2024 のデータを見ると、満足度・保持率の上位に複数のフレームワークが並んでいます （Astro 94%・SvelteKit 90%・Next.js 68%——それぞれ異なるユースケースで高評価）。 これは「どれかが圧倒的に正しい」のではなく、ユースケース×チーム×規模の組み合わせで最適解が変わることを示しています。
個人起業×Vercel×AI 補助のケースなら「多数派×LLM 学習量が多い×エコシステムが大きい」の掛け算が判断軸になり、 選択は大幅に絞り込まれます。出典: State of JS 2024 Libraries

このセクションの結論

「どれが正解か」を調べ続けることに時間を使うのをやめる。 代わりに 「選ばなくてよくなる仕組み」 を手に入れることに1回だけ投資する。 プロが速い理由はここにあります。次の sec4〜6 で、3つのメタ戦略をそれぞれ具体的に展開します。

→ 次の Section 4 では「枯れた技術を選ぶ（Choose Boring Technology）」を Dan McKinley のイノベーショントークン概念とともに解説する。

🛠️ Section 4: 戦略① 枯れた技術を選ぶ（Choose Boring Technology）

このセクションの3点

① 新技術採用には「イノベーショントークン」という固定枠がある。枠を技術選定に溶かすとプロダクト本体に使えない

② 枯れた技術の強みは「既知の失敗モード」。新技術の怖さは「未知の未知（unknown unknowns）」

③ 2026年はAIに書かせる時代。枯れた・人気のスタックほどLLMのコード品質が高い

「新しい技術を試したい」という衝動はエンジニアとして自然なものです。しかし個人起業のフェーズで、その衝動に毎回応えていると技術選定にリソースを溶かし続ける罠にはまります。 Dan McKinley（Stripe・Etsy元エンジニア）が2015年に提唱した Choose Boring Technology は、その罠を構造的に可視化した概念です。

イノベーショントークンとは

McKinleyの主張は明快です。企業・プロジェクトが持てる新技術採用の枠（トークン）は固定されている。目安は約3枚。 1つの新技術を採用するたびに1枚を消費する。枚数を使い切ったら、あとは枯れた実績技術しか選べない——という制約を意識的に設けることで、「何に新規性を賭けるか」の優先度が明確になります。 出典: mcfunley.com / boringtechnology.club

3枚

イノベーショントークンの目安

未知

新技術が持つ「未知の未知」

既知

枯れた技術が持つ「既知の失敗モード」

枯れた技術が合理的な3つの理由

観点枯れた技術（例: PostgreSQL / React / Tailwind）新しい技術（導入直後）
失敗モード既知 — 過去の障害がドキュメント化されている。「あの問題はこう直す」が素早く分かる未知の未知 — まだ誰も踏んでいないバグが本番で出る。解決策が存在しないことも
解決コスト低い — Stack Overflow・GitHub Issues・公式ブログに解答が山積。数分で解決高い — 情報が少なく自力解決か Issue を立てるしかない。数時間〜数日を消費
LLMのコード品質（2026）高い — 学習データが豊富なほど良質なコードを生成。ReactやPostgreSQLはLLMの学習量が圧倒的低下しやすい — 学習データが少ないマイナー技術や最新リリース直後は誤ったコードを出す確率が上がる
採用・引き継ぎ容易 — 経験者が多く、将来チームを組む際にも参入障壁が低い難 — 経験者が少なく採用コストが上がる。2〜3年後に廃れたら負債になる
出典: Dan McKinley「Choose Boring Technology」 mcfunley.com / boringtechnology.club
2026年の含意: AIに書かせるなら尚更「枯れた・人気スタック」を選べ LLMは学習データの多い技術ほど質の高いコードを出力します。ReactやPostgreSQL、Tailwind CSSのような「何百万もの実装例が存在する」技術は、LLMの出力が安定しています。 一方、リリースから間もない新ライブラリやニッチなフレームワークでは、LLMが古いAPIや誤ったパターンを出しやすい。 バイブコーディングを活かすためにも、「枯れた・人気」を選ぶことはAI活用の最適化でもあるのです。

あなたのトークン、どこに使うか

個人起業×Vercel×AIというスタックでプロダクトを作る場合、技術選定そのものに革新は要りません。 あなたのイノベーショントークンを使うべき場所は「プロダクトが解決するユーザー課題の独自性」です。 Next.js・Tailwind・shadcn/ui は枯れた・人気スタックで選んで、残った3枚のトークンを「誰も解いていない問題への挑戦」に注ぎ込む——それがスピードと差別化を同時に得る道です。

❌ トークンを無駄遣いしている例

  • 「話題の新しいORM試してみよう」
  • 「Next.jsをやめてRemixに乗り換えてみよう」
  • 「CSS-in-JSを比較して最良を選ぼう」
  • 「最新バンドラーのベンチマークを測ろう」

✅ トークンを活かしている例

  • 「競合が解いていない顧客課題の設計」
  • 「AIを使った独自ワークフローの実装」
  • 「差別化となるユーザー体験の発明」
  • 「収益化モデルの実験」

→ 次の Section 5 では「戦略②：オピニオネイテッドな"束"に乗る」を解説する。T3 Stack・Epic Stack・next-forge など「誰かが決めた一式を丸ごと採用する」ことで、個別選択の数十個を一気に消す方法を見ていく。

📦 Section 5: 戦略② オピニオネイテッドな"束"に乗る

このセクションの3点

① 個別に最適解を探すのをやめ、「誰かが決めた一式（束）」をそのまま採用する

② T3 Stack / Epic Stack / next-forge が代表例。悩みを構造ごと外部委託できる

③ Convention over Configuration はあなたが Rails/Django で既に体験済みの思想—JS でも同じことが起きている

前のセクションで「枯れた技術を選ぶ」という戦略を見た。しかし「枯れた技術を選んだとして、そこからさらに何十個も選択が残る」という問題は消えない。 状態管理は Zustand か Jotai か、ORMは Drizzle か Prisma か、認証は Clerk か NextAuth か——。 戦略②の答えは明快だ。「自分で選ぶのをやめる」。 すでに意見を持つエキスパートが決めた一式ごと採用することで、最初の数十個の選択が一括して消える。

代表的なオピニオネイテッドスターター 比較

スターター主な同梱技術思想・誰向け出典
create-t3-app
T3 Stack		Next.js + TypeScript + tRPC + Tailwind CSS + Prisma / Drizzle + NextAuth型安全を最優先。tRPC でフロント→バック間の型ズレを根絶。フルスタック個人開発に最適create.t3.gg
Epic Stack
Kent C. Dodds		Remix + SQLite + Prisma + Fly.io + 監視 / メール 一式「analysis paralysis を越えるために確固たる選択を与える」が明示目的。Remix 派向けepicweb.dev
next-forge
Vercel 公式		Turborepo モノレポ + Next.js + TypeScript + Tailwind + shadcn/ui + Radix + Clerk + Prisma / Neon + Stripe + Sentry + Resend本番 SaaS グレード。必須 env は DATABASE_URL のみ。Vercel × 個人起業で最短ゼロから本番へnext-forge.com
SvelteKit sv CLI
公式		ファイルベースルーティング / フォームアクション / Runes + アドオン選択（Drizzle / Lucia / Tailwind / Playwright）必要なものだけ対話で選ぶ軽量路線。保持率90%（State of JS 2024）。React に疲れた人向けsvelte.dev

🚂 Convention over Configuration — あなたはすでにこれを知っている

Rails（2004年）と Django が確立した「設定より規約（Convention over Configuration）」の思想は、「デフォルトが正しければ差分だけ設定すればいい」という考え方だ。 あなたが Rails で app/models/user.rb に置けばモデルが認識され、config/routes.rb でルーティングが決まるという体験を持っているなら、それと同じ感覚がモダン JS でも再現されている。

フレームワーク 規約の例（設定不要） Rails / Django との対応
Next.js App Router app/dashboard/page.tsx → /dashboard にルーティング Rails: resources :dashboards
SvelteKit src/routes/blog/+page.svelte → /blog、+server.ts → API エンドポイント Django: urls.py + views
next-forge 認証・決済・メール・監視がセット。DATABASE_URL だけ渡せば動く Rails の rails new --all に相当する一括宣言

あなたはこの思想を Rails / Django で身体で覚えている。「JS は設定が多くて辛い」と感じているなら、 それはオピニオネイテッドな束に乗っていないからだ——束を使えば体験は変わる。

📌 個人起業 × Vercel への推奨 とにかく早く本番に出したいなら next-forge（Vercel 公式・本番 SaaS 構成済み）を土台にする。 型安全を徹底したいなら create-t3-app で対話的に必要なものだけ選ぶ。 どちらも最初の数十個の選択が消える。 「全部入りが重い」と感じたら、後で層を一つずつ外せる。最初から軽くしようとして選択に溺れるより、重い束から削る方が速い。

10+

next-forge が消す選択数（認証/DB/UI/決済/メール/監視…）

1

next-forge に必須の env（DATABASE_URL のみ）

90%

SvelteKit 保持率（State of JS 2024）

2004

CoC の起源（Rails 登場年）

※ 保持率出典: State of JS 2024

→ 次の Section 6 では「一度決めたら決め直さない」仕組み—ADR（Architecture Decision Records）を解説する。束を選んだ後、その選択をチームと AI に伝え続けるための記録術だ。

📝 Section 6: 戦略③ 一度決めて、決め直さない（ADR）

このセクションの3点

① 技術選定の最大コストは「決定そのもの」ではなく「何度も蒸し返すこと」にある

② ADR（Architecture Decision Records）は1決定1ファイルで"なぜそう決めたか"を残す仕組み

③ ADRをCLAUDE.mdからリンクしておくと、AIが勝手に別技術を使い始めたときに即指摘できる

「Drizzleにしたのに、AIがまたPrismaのコードを書いてきた」「新メンバーが追加したライブラリが、既存スタックと思想が違う」——この感覚、身に覚えがあるなら、あなたが悩んでいるのは選択の問題ではなく記録の問題です。決めたのに、なぜ決めたかを残していない。だから何度も同じ議論が戻ってくる。 ADR（Architecture Decision Records）は、Michael Nygard が 2011 年に提唱した「1決定1ファイル」方式で、この問題を構造ごと消します。

ADR テンプレート（Nygard 形式）

出典: Nygard 2011 / adr.github.io / Fowler
# ADR 0001: ORM に Drizzle を使う

## Status
accepted

## Context
Neon (サーバーレス Postgres) を使う。型安全な ORM が必要。
候補は Prisma と Drizzle。個人起業フェーズで bundle サイズと
Cold Start を最小化したい。

## Decision
We will use Drizzle ORM.
- Prisma より bundle が小さく、Neon の HTTP ドライバと相性がよい
- TypeScript の型推論がスキーマから自動生成される
- 移行コストが低い（SQLに近い書き方）

## Consequences
良い: 型安全・Cold Start 短縮・schema-first で AI が迷わない
悪い: Prisma ほど学習資料が多くない（2026時点では追いついてきた）
中立: Prisma Studio のような GUI は別途用意が必要

ADRがあるとないで何が変わるか

場面ADR なしADR あり
新メンバー参加なぜ Drizzle か誰も知らない → 無思慮な踏襲 or 無思慮な入れ替えADR を読めば判断の背景が分かる → 理由を理解して従うか意識的に更新
技術の再検討毎回ゼロから議論が再燃。決定コストを何度も払うStatus を "superseded" に更新するだけ。変更理由も記録される
AI（Copilot / Claude）セッションをまたぐと記憶がリセット → 毎回別ORMを使い始めるCLAUDE.md から ADR へリンク → AI が逸脱したら即「ADR 0001 参照」と指摘できる
個人開発（1人）3ヶ月後の自分が「なんでこれ入れたんだっけ」と迷う過去の自分へのメモとして機能。コンテキストスイッチコストが消える

最小構成で始める ADR 運用

ディレクトリ

docs/adr/

連番ファイルを置くだけ。専用ツール不要。0001-use-drizzle.md のような命名が標準。

CLAUDE.md との接続

AI へのコンテキスト

CLAUDE.md（または AGENTS.md）に「技術選定は docs/adr/ を参照すること」と1行書く。AIへの記憶代わりになる。

更新のルール

既存ファイルは書き換えない

古い ADR を編集するのでなく、Status を superseded by 0007 に変え、新ファイルを追加する。変更履歴が残る。

ADR は「メモ」ではなく「決定の終止符」
ADR を書くことで「この選択は終わった」と宣言できます。Status: accepted になった決定は、状況が変わるまで再検討しない。これは思考停止ではなく、消耗の節約です。個人起業では、技術選定に費やす認知コストを削った分だけ、プロダクトの核心（ユーザーへの価値）に集中できます。

→ 次の Section 7 では、戦略①②③を踏まえた「2026年の"とりあえずこれ"デフォルト構成」を一覧で示す。迷う時間をゼロにする具体的な技術スタックを確認しよう。

✅ Section 7: 2026の"とりあえずこれ"デフォルト構成

このセクションの3点

① 迷っている時間そのものが最大のコスト — 「まず動く構成」を手に入れることが先決

② ここで紹介する構成は next-forge（Vercel公式） 等の本番SaaSで実際に採用されている鉄板

③ "とりあえずこれ"で始め、不満が出た箇所だけ後で替える — それが最速の道

sec1〜6で「なぜ選べないか」「3つの戦略」を整理してきた。このセクションでは具体的な答えを出す。 「とりあえずこれ」と言い切れるのは、次のような先人たちが同じ選択をして本番で動かしているからだ。 選択を全部自分でゼロから考え直す必要はない。構成ごとコピーするのが最速。
レイヤー推奨理由
フレームワークNext.js 16（App Router） / 慣れてればSvelteKitReactエコ最大・LLM学習量最多・Vercelゼロコンフィグ。使用率44%（State of JS 2024）
言語TypeScriptフルスタック型安全。AIの補助精度が上がり、型のズレをコンパイル時に検知できる
スタイリングTailwind CSS v4UIの記述場所が1か所に固定 = 迷いゼロ。案件数7.8Mでシェア1位
UI部品shadcn/uiコピペ所有モデル（ロックインなし）・Rising Stars 2024総合1位(+38k stars)・Radix+RSC対応
クライアント状態基本"不要" （RSC+Server Actions）
要るなら Zustand / Jotai		RSCで`async/await`直取得が主流に。新規でReduxは選ばれない（react.dev）
サーバー状態TanStack Query or Server Actions直キャッシュ/再取得/楽観更新を委譲。自前で書かない
DBNeon（サーバーレスPostgres）無料枠・Vercel統合・自動スケール。Vercelダッシュボードから直接セットアップ可
ORMDrizzle（推奨） or PrismaDrizzle = 軽量・型推論強・Neon親和性高。Prisma = 学習資料が多く移行もしやすい
認証Better Auth （無料・自己ホスト）
or Clerk（速度優先）		UIをゼロから作らない選択をする。Better Auth = 無料/自前DB。Clerk = MAU課金・最速導入
デプロイVercelNextゼロコンフィグ。個人は無料枠で十分。`git push`だけで本番反映
メールResend + React EmailテンプレをReactコンポーネントで書ける。無料枠あり
決済Stripe業界標準・LLMがStripeの良いコードを出す（学習データ量が多い）
2026の最大の答え
クライアント状態管理は「まず要らない」
React 19 + Next.js 16 のApp Routerでは、Server Componentsがasync/awaitでサーバーデータを直接取得できる。 フォーム送信はServer Actions（useActionState/useOptimistic）が担う。 「なんでもuseState + useEffect + fetch」という2020年代前半の書き方は、もう標準ではない。

サーバーデータ

RSC で async/await

状態管理ライブラリ不要

フォーム/送信

Server Actions

useActionState で統合

真にグローバルなUI状態

Zustand / Jotai

テーマ・モーダル等に限定

出典: react.dev — Server Components
土台の選び方 — 2択だけ考えればいい

対話形式で必要なものだけ選びたい

create-t3-app

Next.js + TS + tRPC + Tailwind + Prisma/Drizzle + NextAuth を CLIの質問に答えながら組み合わせる。必要最小限から始めたい人に。

https://create.t3.gg/

本番SaaSを最初から見据えたい

next-forge（Vercel公式）

Turborepoモノレポ。Next + TS + Tailwind + shadcn/ui + Clerk + Neon + Stripe + Sentry + Resend を本番グレードで同梱。必須envは DATABASE_URL のみ。

https://www.next-forge.com/

SvelteKit派なら sv CLI でDrizzle/Lucia/Tailwind/Playwrightをアドオン選択するパターンが対応する。

→ 次のSection 8では「React状態管理とCSS、あなたの2大悩みの決着」を決定木で解説する。

🎯 Section 8: あなたの2大悩みの決着 — React状態管理 と CSS

このセクションの3点

① 状態管理の最適解は2026では「ほぼ要らない」に収束した — RSC + Server Actions が置き換える

② CSS は Tailwind + shadcn/ui で事実上決着。styled-components は2025年3月にメンテナンスモード入り

③ 「決定木」を持てば、個別ケースで迷わなくなる — 選択を毎回ゼロから考えない

React の状態管理と CSS — この2つは「最適解が多すぎて選べない」問題の代表格です。 Redux vs Zustand vs Jotai vs Context、Tailwind vs styled-components vs CSS Modules……あなたが迷うのは当然で、実際にどれも「ある文脈では正解」です。 ただ、2024〜2026年の RSC（React Server Components）革命によって、この選択肢の地図は大きく塗り替わりました。 古い記事の選択肢をそのまま引きずると、「もう解決済みの問題」を再度解こうとすることになります。

React 状態管理の決定木 — 2026年版

2026年の大原則
React 公式（react.dev/reference/rsc/server-components）は「データ取得は Server Components の async/await で」「クライアント状態は対話的UIのみ」と明言。 useState + useEffect + fetch の組み合わせは、新規コードでは「要らない選択肢」になっています。
状態の種類2026の答え具体例 / 補足
サーバーのデータ取得RSC で async/await 直取得キャッシュ・再取得が必要なら TanStack Query を追加。useEffect+fetch は不要
フォーム送信・ミューテーションServer Actions（useActionState / useOptimistic）React 19 で標準統合。楽観更新も組み込みで実現可能
URL に乗る状態URLSearchParams（状態管理不要）フィルタ・ページ番号・検索クエリ。URL で共有可能になり UX も向上
局所 UI 状態useState（そのまま）ドロップダウン開閉・入力中テキスト。コンポーネント外に出さない
真にグローバルな UI 状態Zustand または Jotai（軽量）テーマ切替・モーダル管理・ツアー進捗など。Redux は新規では基本不要
Redux は新規プロジェクトで基本選ばない Redux は既存の大規模コードベースの保守では合理的ですが、新規個人プロジェクトで選ぶ理由はほぼありません。 JS Rising Stars 2024（risingstars.js.org/2024/en）では Zustand が状態管理の新規スター数1位（+10.8k）、Redux は新規採用が減少傾向です。

+10.8k

Zustand 2024年新規スター数（状態管理1位） 出典: Rising Stars 2024

React 19

useActionState / useOptimistic で Server Actions 統合済み 出典: react.dev

2025-03

styled-components がメンテナンスモード入り 出典: GitHub Discussion #5568

CSS の決定木 — 2026年版

styled-components / Emotion に代表される CSS-in-JS は、React Server Components と根本的に非互換です。 Context API に依存しているため、RSC 環境では動作しません（styled-components/discussions#5568）。 2025年3月17日にメンテナンスモード入りが公式アナウンスされており、新規採用の理由はなくなりました。
状況・要件2026の答え理由・補足
基本のスタイリング全般Tailwind CSS v4案件数 7.8M（Bootstrap 5.2M を抜き1位）。CSS ファイルを別途管理しなくてよい。v4 は CSS-first で設定ファイル不要
UI 部品（ボタン・ダイアログ等）shadcn/uiRising Stars 2024 総合1位（+38k stars）。コピペ所有モデルでロックインなし。Tailwind + Radix プリミティブ + RSC 対応
styled-components / Emotion新規採用しないContext API 依存で RSC 非互換。styled-components は 2025-03 にメンテモード入り（公式 Discussion #5568）
CSS をファイルに分けたい・静的抽出したいCSS Modules または vanilla-extractCSS Modules はビルドツール標準対応で安定。vanilla-extract は TypeScript 型付きでゼロランタイム
SvelteKit を使っている場合Tailwind CSS v4 + shadcn-svelteSvelte の <style> スコープと Tailwind は共存可能。scoped CSS は複雑なコンポーネントで補完的に使う
「最適解が複数」に見えるのは、古い記事を引きずっているから
2022年以前の記事では「Redux vs Context vs Recoil vs Jotai vs Zustand」がフラットな選択肢として並んでいます。 しかし 2023〜2024 年の RSC 革命（React 18→19 / Next.js App Router）で「サーバーのデータはサーバーで取る」が標準になり、 クライアント状態管理ライブラリが必要な場面は劇的に減りました。 古い記事が示す「5択」は、今では「まず RSC → 足りなければ Zustand」という2ステップに整理されています。 検索して出てくる記事の公開年を必ず確認してください。
参照: react.dev — Server Components / State of JS 2024

→ 次の Section 9 では「AIバイブコーディングが微妙になる理由と対策6手」を解説する。スタックを固定した今、AIをどう束ねるかが次の問いになる。

🤖 Section 9: AIバイブコーディングが"微妙"になる理由と対策6手

このセクションの3点

① AIが"微妙"なのは能力の問題ではなく構造的な問題（平均化・記憶なし・過剰実装）

② 対策の本質は「AIに毎回ゼロから選ばせない」＝スタックと規約を事前に固定すること

③ lint / 型 / ADR という機械的な矯正レールを引けば、AIは速く正確になる

「AIに書かせると動くけど微妙なコードが出てくる」「設計方針がセッションをまたぐとブレる」——この感覚は正しい。 あなたの使い方が悪いのではなく、AI Code Agentの構造そのものに起因する5つの制約がある。 これを理解してから対策を打てば、AIはプロダクトの型の中で速く正確に動くツールに変わる。

なぜ"微妙"になるのか — 5つの構造的原因

原因何が起きるか対策の方向
① 学習データの平均化良いコードも悪いコードも均して"中央値"を出す。マイナー・新興技術ほど学習データが少なく品質が下がる人気・枯れたスタックを選ぶ（sec4のBoringTech戦略と直結）
② セッション記憶なし昨日決めた設計方針・ライブラリ選択をAIは知らない。セッションを開くたびゼロスタートで"自分なりの最善"を選び直すCLAUDE.md / AGENTS.md にスタックを明文化して毎回渡す
③ 過剰実装頼んでいないエラー処理・抽象レイヤー・型定義を追加し、コードが肥大化する。「役に立とう」バイアスが過多アウトプットを生む「最小実装のみ」「必要な箇所だけ編集」を毎回明示（Karpathyの4ルール）
④ 確認せず仮定で進む曖昧な要件を自分で補完して実装し始める。「それは違う」が後から判明しリワーク多発（Karpathy指摘）前提・成功基準を先に定義させる。曖昧なら質問させるよう指示する
⑤ 枯れ・人気の格差Next.js / React / Tailwind / Drizzle はLLMが大量に学習 → 良コード。マイナーORM・独自FWはコードが劣化するデフォルト構成（sec7）の人気スタックに留まる

対策6手 — AIを"決まった型の中で速く正確に"動かす

  1. 1

    コンテキスト固定

    固定スタックを CLAUDE.md / AGENTS.md に明記する

    「このプロジェクトは Next.js 16・TypeScript・Tailwind v4・shadcn/ui・Drizzle・Neon を使う。他のORMやCSSソリューションは使わない」と一度書けば、全セッションで共通コンテキストになる。 AGENTS.md は複数のAIツール（Claude / Cursor / Copilot）で横断認識される標準化傾向にある。プロジェクトルートに1ファイル置くだけでよい。

    → 記憶なし問題を「外部記憶」で補う最小コスト対策

  2. 2

    Linter as law

    ESLint カスタムルールでアーキを機械強制する

    Factory.ai が提唱する原則："Agents write the code; linters write the law"（出典: factory.ai）。 「層をまたぐ import 禁止」「named export のみ」「console.log 禁止」等のカスタムルールを書く。 エージェントは lint エラーを自己修正フィードバックとして使い、lint green = アーキ準拠の代理指標になる。AIが勝手にルールを破っても CIで即検知できる。

    → 平均化問題・過剰実装問題への機械的バリア

  3. 3

    表現の固定

    shadcn/ui でコンポーネントの書き方を1種類に絞る

    「ボタンの実装」をAIに任せると <button> / MUI Button / 自作カスタムコンポーネント / shadcn Button が混在し始める。 shadcn/ui を導入してリポジトリにコードを取り込めば、「ボタン = @/components/ui/button を import する」が唯一の正解になる。 AI の出力が揺れても1種類に収束させられる。コピペ所有モデルなのでロックインもない。

    → JS Rising Stars 2024 総合1位（+38k stars）

  4. 4

    型による制約

    tRPC / Zod でAPIスキーマから型を自動生成し、逸脱をコンパイルエラーにする

    tRPC はサーバー・クライアント間の型を共有し、APIの形が変わった瞬間に TypeScript コンパイルエラーが出る。 AIが「戻り値の型を勝手に変える」「フィールド名を変える」をしてもビルドが壊れるため即検知できる。 Zod でバリデーションスキーマを定義すると、フォーム・API・DB の3層で同じ型定義を再利用でき、AIが層ごとに別々の型を書き始める問題を防ぐ。

    → create-t3-app の中核思想。create.t3.gg

  5. 5

    Karpathyの4ルール

    「小さく作らせる」指示でリワークを消す

    Andrej Karpathy が提唱する AI Coding Agents への4ルール（出典）:

    • ① 前提を明示し、曖昧なら質問させる（確認なし仮定問題への対策）
    • ② 要求された最小実装のみ（過剰実装問題への対策）
    • ③ 必要な箇所だけ編集する（スコープ外変更の防止）
    • ④ 成功基準を先に定義する（「それは違う」リワークの防止）

    → CLAUDE.md の冒頭に「このルールに従え」と書いておくだけで全セッションに適用できる

  6. 6

    ADRをAIに渡す

    「なぜDrizzleか」を記録し、AIが別ORMを使い始めたら即指摘できるようにする

    ADR（sec6参照）は人間の新メンバー向けだけでなく、AIへの制約文書としても機能する。 docs/adr/0001-use-drizzle.md に「Prismaでなく Drizzle を選んだ理由」を書き、 CLAUDE.md から ADR ディレクトリへリンクしておく。 AIが「Prismaの方がいいと思います」と言い出したら「ADR 0001 を見ろ」で終わる。 逆に状況が変わって Drizzle を替えたい時は、ADR を更新して「AIに新しい判断根拠」を渡せる。

    → Nygard 2011 / adr.github.io — 人間とAIの両方に効く「決め直さない」仕組み

あなたのバイブコーディングが"微妙"な本当の理由
AIに毎回ゼロから技術を選ばせているから。スタックを固定し、lintと型と ADR で規約を書けば、AIは「決まった型の中で速く正確に動くツール」になる。 自由度を与えるほどAIの出力はブレる。制約を与えるほどAIは強くなる。

6手 × 5原因の対応マップ

対策手主に効く原因導入コスト優先度
① CLAUDE.md / AGENTS.md② 記憶なし・⑤ スタックブレ低（1ファイル）最優先
② Linter as law① 平均化・③ 過剰実装中（ESLint設定）高
③ shadcn/ui① 平均化・⑤ スタックブレ低（初期導入のみ）高
④ tRPC / Zod① 平均化・③ 過剰実装中（スキーマ設計）高
⑤ Karpathyの4ルール③ 過剰実装・④ 仮定で進む低（CLAUDE.mdに追記）最優先
⑥ ADRをAIに渡す② 記憶なし・⑤ スタックブレ中（ADR文書作成）高

→ 次のSection 10では、ここまでの全戦略をまとめた「選択疲れに勝つ意思決定OS」と出典一覧を整理する。

🧠 Section 10: まとめ「選択疲れに勝つ意思決定OS」＋出典

このセクションの3点

① 正解を覚えるな、決め方（意思決定OS）を持て

② 多数派×枯れ技術×オピニオネイテッド×一度決めて記録×AIを制約——この5層が選択疲れを終わらせる

③ 迷う時間を消した分を、プロダクトの独自価値に回す

ここまで読んだあなたは、すでに大事なことに気づいているはずだ。「どのライブラリが最適か」を追い続けることそのものが、最も高コストな選択だった、と。 JS疲れは気のせいではない。エコシステムの構造が生み出した既知の問題だ（Clemmons, 2015）。 そして2026年時点では、その答えはかなり収束している。必要なのは"正解リストの暗記"ではなく、「一度決めて動かす」仕組み——意思決定OSを手に入れることだ。

あなたへの処方箋 ── Vercel × AI で個人起業する人の5ステップ

  1. 1

    土台を固める

    next-forge または create-t3-app で一括確定

    フレームワーク・DB・認証・スタイリングの初期選択を「誰かがすでに決めた一式」に外注する。 Vercel × 個人起業なら next-forge（Vercel公式・本番グレード）、 または create-t3-app（Next+TS+tRPC+Tailwind+Prisma/Drizzle+Auth）。 これだけで最初の数十個の選択が消える。
  2. 2

    UIを固める

    Tailwind CSS v4 + shadcn/ui でUIの書き方を1種類にする

    Tailwindで記述場所を1ファイルに固定。shadcn/uiのコピペ所有モデルで「ボタンの書き方」が1種類になり、AIの出力も揺れなくなる。 styled-componentsは2025-03-17にメンテナンスモード入り（RSC非互換）——新規採用は避ける。 styled-components discussion
  3. 3

    状態管理を整理する

    状態はRSC優先・要る時だけ Zustand/Jotai

    React 19 + Server Components 時代の答えは「クライアント状態管理ライブラリは基本不要」。 データ取得は async/await 直書き、フォームは Server Actions（useActionState/useOptimistic）、 真にグローバルなUI状態だけ Zustand か Jotai。Redux は新規では選ばない。 react.dev
  4. 4

    決定を記録する

    ADRに1決定1ファイルで記録し、蒸し返さない

    docs/adr/0001-use-drizzle.md のように残す。 「なぜDrizzleか」を書いておけば、AIが別ORMを使い出した瞬間に指摘できる。新メンバーが加わっても無思慮な踏襲・変更を防げる。 決め直すのは状況が変わった時だけ——それ以外は蒸し返さない。 Nygard 2011
  5. 5

    AIを束ねる

    CLAUDE.md / AGENTS.md + ESLint で「AIが自由に選べない」構造を作る

    AIに毎回ゼロから選ばせるとコードが揺れる。コンテキストファイルでスタックを明記し、ESLintカスタムルールで層またぎのimportを機械禁止する。 「Agents write the code; linters write the law」——lintがグリーンになればアーキ準拠の代理指標になる。 Factory.ai / Karpathy 4 rules

「ベストプラクティスは"知識"でなく"運用"。一度決めて、決め直さない仕組みを持つ者が速い」

── Choose Boring Technology（McKinley）× ADR（Nygard）× Linter as law（Factory.ai）の統合的実践

意思決定OS ── 5層の対応表

レイヤー戦略何の選択を消すか参照先
初期スタックオピニオネイテッドな束FW / DB / 認証 / デプロイの初期選択next-forge / T3 / Epic Stack
技術選定枯れた技術を選ぶ未知の失敗・LLM出力品質の劣化McKinley / State of JS 2024
UI実装Tailwind + shadcn で固定CSS方針の毎回迷い・AI出力の揺れRising Stars 2024 (shadcn 1位)
過去の決定ADR で記録・蒸し返さない毎回の再議論・AIの逸脱Nygard 2011 / adr.github.io
AI制御CLAUDE.md + ESLint で機械強制AIのランダム技術選択・アーキ逸脱Factory.ai / Karpathy

意思決定OSを入れると何が変わるか

∞→1

初期スタックの選択肢（bundle→1スターター）

0回

ADR記録後の同じ議論の蒸し返し

lint green

AIアーキ準拠の代理指標

全部

浮いた時間をプロダクト独自価値へ

出典一覧

データ注記: 数値（使用率・保持率・スター数等）は State of JS 2024・JavaScript Rising Stars 2024 時点。バージョン情報は 2026-06 時点。技術トレンドは変化するため、最新情報は各公式ドキュメントを参照すること。