Server Actions とは何か？Next.js / React で 「フォームから関数を直接呼ぶ」 仕組みと API Routes との違い

Server Actions って結局何ができるの？ API Routes と何が違うの？ 「

// app/todos/actions.ts
'use server';

import { db } from '@/lib/db';
import { revalidatePath } from 'next/cache';

export async function createTodo(formData: FormData) {
  const title = formData.get('title') as string;
  await db.todo.create({ data: { title } });
  revalidatePath('/todos');
}

// app/todos/page.tsx
import { createTodo } from './actions';

export default function TodosPage() {
  return (
    <form action={createTodo}>
      <input name="title" required />
      <button type="submit">追加</button>
    </form>
  );
}

「Web の基本に戻る」 哲学を、「React のコンポーネント記述スタイル」 に組み込んだのが Server Actions の野心的な部分です。

「useFormStatus」 / 「useOptimistic」 で動的 UI

「送信中はボタンを無効化」 「楽観的に UI 更新」 のような React らしい書き味も用意されています。

'use client';
import { useFormStatus } from 'react-dom';

export function SubmitButton() {
  const { pending } = useFormStatus();
  return (
    <button type="submit" disabled={pending}>
      {pending ? '送信中…' : '追加'}
    </button>
  );
}

'use client';
import { useOptimistic } from 'react';

export function TodoList({ todos }: { todos: Todo[] }) {
  const [optimistic, addOptimistic] = useOptimistic(
    todos,
    (state, newTodo: Todo) => [...state, newTodo]
  );

  async function addAction(formData: FormData) {
    const title = formData.get('title') as string;
    addOptimistic({ id: 'temp', title });
    await createTodo(formData);
  }

  return (
    <>
      <form action={addAction}>...</form>
      <ul>{optimistic.map(t => <li key={t.id}>{t.title}</li>)}</ul>
    </>
  );
}

「プログレッシブエンハンスメントを保ちつつ、リッチな UX も両立する」 のが、Server Actions が React に組み込まれている理由です。

API Routes / tRPC との違い

「Server Actions と他の API 方式、何が違う？」 を表で並べます。

要点は 外部公開 API → API Routes、内向き複雑な API → tRPC、フォーム / 内部アクション → Server Actions という棲み分けです。 3つは競合ではなく、「用途で使い分ける道具立て」 として捉えるのが正解です。

ハマりやすいポイント

便利だが、現場で詰まりやすい注意点もあります。

「API を書かなくていい」 と聞くと万能に思えるかもしれませんが、` API を書かない代わりに、Action の冒頭で 「認証・認可・検証」 を必ずやる規律 が必要、というのが正確な理解です。

いつ Server Actions を選ぶか

採用判断の目安を整理します。

「Next.js App Router を採用したら、Server Actions は自然と使うことになる」 という距離感が現実的です。

AI 時代の Server Actions

AI 連携の文脈でも Server Actions の使いどころは増えています。

「AI 時代の Next.js アプリ」 と 「Server Actions」 は、設計思想として相性が良いペアになっています。

Server Actions に関するよくある質問

Q. Server Actions は本番運用に耐えますか？

A. Next.js 14.0 で stableになっており、Vercel をはじめ多くの本番採用例があります。「認証 / 認可 / 検証」 を関数の冒頭で必ず行うルールさえ守れば、安全に運用できます。

Q. API Routes はもう不要ですか？

A. 用途で残るケースは多いです。「 外部公開 API」 「Webhook」 「モバイルアプリから叩く」 用途は API Routes / Route Handlers の方が向きます。「内向きのアクションだけ Server Actions に寄せる」 のが現実的です。

Q. tRPC と Server Actions、どちらを使うべきですか？

A. ` 共存可能です。「複雑な型を持つ内部 API 群は tRPC、フォーム / 単純な CRUD は Server Actions」 と分けるチームも多いです。「どちらか一方を選ぶ」 必要はありません。

Q. ファイルアップロードを Server Actions で扱えますか？

A. 小〜中サイズなら可能、大サイズは別ルートです。Next.js のリクエストサイズ制限(デフォルト 1MB / 4MB 程度)に注意し、大きいファイルは 「署名付き URL で S3 / R2 に直接アップロード」 する設計に分けます。

Q. エラー時のメッセージはどう表示しますか？

A. useActionState」 と `return { error: '...' }の組み合わせが標準パターンです。「throw して 500 になる」 と UX が悪いので、ユーザーに見せるエラーは値として返します。

Q. Server Actions は Vercel 以外でも動きますか？

A. はい。Next.js が動く環境ならどこでも(self-hosted Node、AWS、Cloudflare、Bun など)で動きます。「Vercel 以外で動かない」 という誤解を持ちやすい機能ですが、標準の Next.js 機能です。

Q. Server Actions を学ぶ最短ルートは？

A. ① 「'use server'」 と 「