本エントリーの前提としては関数コンポーネント+hooksは知っているよ、ということで進めていきます。関数コンポーネントからだとちょっと差が大きすぎてしまうのでそこは扱いません。

React 19の考え方

Reactの最近の変更は大まかには次のモチベーションで行われている、と考えると理解しやすいと思いました。

• パフォーマンスの低下原因となる余計な更新処理を減らし、応答性を上げる
• 自分で管理する状態の数とEffectを減らす

いろんな新機能などを見るとこの2つの観点が混ざっているものもありますが、分解してみれば理解しやすいと思います。

あとは昔はなかった3つの言葉が出てきます。これを理解してから見てみないと「React変わりすぎてついていけない」となってしまうと思いました。まずはこちらの解説をします。

• トランジション
• アクション
• ストリーミング

トランジション

たぶん、一番？となりやすいところかと思います。キーボードの入力のたびに画面表示するとして、変更が重い場合に、React内部の画面の変更(レンダリング)リクエストが溜まってしまう応答性が下がってしまうことがあります。トランジションは「この変更による描画は優先度が低いから重複したら中断したり後回しにしたり破棄してもいい」というのをReactに伝えるものです。

状態変更はロジックで行いますが、そのロジックはReactでは主に2ヶ所に書きます。

• ハンドラ: ユーザーの操作が起点となるもの
• エフェクト: 他の状態変更が起点となり、外部と同期を取るもの

トランジションの中から呼ばれる関数（普通の関数もOK）がアクションと呼ばれます。

なお、トランジションは結果の描画を効率化して応答性を良くしますが、中で行われる通信の抑制はしません。タイプごとにコード補完のために通信する、みたいな場合の通信の間引きみたいな処理は引き続き必要です。

アクション

トランジションの中から呼ばれる処理です。同期も非同期も可です。サーバーに変更をポストしたりとかが主な役割になるかと思います。

実装方法としては単なる非同期関数とかを作ってもアクションと言えますが、それにちょっと付加価値がついたものもあります。

• useActionStateでラップされて作ったもの。それ単体でのステート管理の機構も持っている。useState()のすごい版。非同期関数対応で、アクションが実行中かどうかのフラグ管理もしてくれる
• Server Function。以前サーバーアクションと呼ばれていたもの。サーバーで動く。APIハンドラを作らずに自動で作ってくれる

組み合わせると以下の実装パターンがあります。

• 非同期関数
• useActionState + 非同期関数
• サーバー関数
• useActionState + サーバー関数(この場合はステートはシリアライズ可能である必要あり)

アクションを呼ぶときはトランジションの中で呼ぶ必要があります。また、標準的なタグだと<form action={action}/>がアクションを引数として持っています。アクションをpropsとして渡す場合は、それを受け取って実際に呼ぶ側がトランジションを開始するのがルールです。

'use server'がついたファイルに書かれたのサーバー関数です。クライアントからも呼べるがHTTPをまたいでの実行となります。

'use server';

export async function updateProfile(formData: FormData) {
  const name = formData.get('name') as string;
  const email = formData.get('email') as string;

  if (!name || name.trim().length === 0) {
    return {
      success: false,
      message: '名前を入力してください。',
    };
  }

  await db.user.update({ where: { id }, data: { name, email } });

  return {
    success: true,
    message: 'プロフィールを更新しました！',
    user: { name, email },
  };
}

ストリーミング

Promiseのいけてる使い方です。サーバーとクライアントの間でPromiseをやり取りする仕組みです。

もともとはlazyのコンポーネント非同期読み込みのためにPromiseをthrowすると解決するまで待つというのが16あたりのころにありましたが、コンポーネントとの組み合わせで、ロード中などが表示できるようになりました。

ErrorBoundaryは関数コンポーネントとしては長らく提供されてきませんでしたが、サードパーティのライブラリを使うように公式ドキュメントも追加されていますね。

import { Suspense } from "react";
import { ErrorBoundary } from "react-error-boundary";

<ErrorBoundary fallbackRender={<div>エラー中</div>}>
  <Suspense fallback={<div>ロード中</div>}>
    <AsyncComponent /> {/*非同期コンポーネント*/}
  </Suspnse>
</ErrorBoundary>

このようなPromiseを扱う仕組みの上に、クライアント／サーバーの間の仕組みとして整理されたのがストリーミングです。

サーバーコンポーネントではデータの取得を非同期に書けますが、awaitで待つのではなく、Promiseのまま子供のコンポーネントなどに渡せるようになりました。こうすることで、ロード中の状態でサーバーサイドレンダリングが行われてクライアントで一時的な結果表示が行われ、サーバー側の処理が終わったらその後フロントエンドが更新されて表示が行われます。

import { Suspense } from 'react';
import { fetchUsers } from '../lib/db';
import { UserList } from '../components/UserList';

export default function Page() {
  // ここで await しない！
  const usersPromise = fetchUsers();

  return (
    <main className="p-8">
      <Suspense fallback={
        <div>
          ⏳ ユーザーデータをロード中...
        </div>
      }>
        {/* Promiseのまま子コンポーネントに渡す */}
        <UserList usersPromise={usersPromise} />
      </Suspense>
    </main>
  );
}

'use client'

import { use } from 'react';
import type { User } from '../lib/db';

type Props = {
  // データそのものではなく「データを取得するPromise」を受け取る
  usersPromise: Promise<User[]>; 
};

export function UserList({ usersPromise }: Props) {
  // React 19の use() で Promise を解決する
  // Promiseが未解決(pending)の間は自動的にサスペンドされ、親の <Suspense> が発火
  const users = use(usersPromise);

  return (
    <ul>
      {users.map((user) => (
        <li key={user.id}>
          {user.name}
        </li>
      ))}
    </ul>
  );
}

今までは同様の非同期更新をしようとすると、一度フロント側がロードされて表示されてから、CSRでuseEffect()を使って追加情報を取得し、結果を待って更新となっていましたが、初回のサーバーリクエスト時に追加リクエストまで開始するのでかなりリードタイムは更新されます。

応答性を上げる

エフェクトロジックの無駄起動の排除

エフェクトはその名の通り、他のデータなどが変わったあとの作用（副作用）として使います。で、useEffect()の2つめの引数にはその中で参照している変数を入れます。それらの変数が変更されたらその中のコードが呼ばれます。最近あまり使うなという風潮ですが、どうしても使うケースはあります。

効率を考えていくと、Effectの「変更を検知したい変数」と「使いたいデータ」が一体化しているのが問題となることがあります。次のコードはcategoryとidと2つ使っているのでそれを後ろで渡しています。

const [data, setData] = useState(null);
const [count, setCount] = useState(0);

useEffect(() => {
  const fetchData = async () => {
    const response = await fetch(`https://api.example.com/data/{category}/{id}`);
    const result = await response.json();
  };

  fetchData();
}, [category, id]);

でも、idの変更は検知したいがcategoryの変化だけだとまだ通信したくないとしてもそれはここでは実現できませんでした。useRefとか使えばできたかもしれませんが。

React19で追加されたuseEffectEventを使って実行したいロジックとuseEffect()を切り離すことができます。useEffectEvent()は常に最新の値を使います。

// id変更時に呼びたいロジック
// categoryはその場でレキシカルスコープで見える最新の変数を参照
const fetchData = useEffectEvent(async () => {
  const response = await fetch(`https://api.example.com/data/${category}/${id}`);
  const result = await response.json();
  // setData(result) など
});

useEffect(() => {
  // idが変わった時だけ実行される
  fetchData();
}, [id]); // 依存配列には id だけを含める

画面更新を遅延させる

useState()で状態を更新すると、変更がトリガーされて画面更新が実行されます。
useDefferedValueでラップしてラップした方を画面表示に使うと、遅延して表示をさせることでユーザーの操作の反映が遅れて操作がスムーズにいかない、というのを抑制します。

import { useState, useDeferredValue, memo } from 'react';

export function SearchPage() {
  const [query, setQuery] = useState('');
  
  // deferredQuery は query から少し遅れて更新されます
  const deferredQuery = useDeferredValue(query);

  return (
    <div>
      {/* ユーザー入力は素早く画面反映 */}
      <input
        value={query}
        onChange={(e) => setQuery(e.target.value)}
        placeholder="検索キーワードを入力..."
      />

      {/* 検索結果の表示は遅延ロードさせる */}
      <HeavyList query={deferredQuery} />
    </div>
  );
}

サーバーとの通信の作法

サーバーからのデータ取得周りも整理されて、それにともなう余計なコード（通信前後の状態管理など）はどんどん減ってきています。

コンポーネント初期化時のGET処理

だいたい、ライフサイクルメソッドやEffectでfetch()で情報取得して、それをステートに入れて管理、あるいはSSRだとページのルートのgetServerSideProps()などでしか状態が取れないのでそこでまとめて取得してコンテキストに入れて・・・みたいな感じでした。中央集権が必要だったからこそたくさんのデータが一か所にあって統制も大変だったのですが、今はだいぶそのあたりは緩和され、コンポーネントごとの管理でよくなってきていると感じます。

以前から、クライアントコンポーネントの場合、SWRなんかは受信や再読み込みが宣言的に記述できてこの通信回りの状態管理はだいぶシンプルになっていました。

"use client"

function Profile() {
  // これ！
  const { data, error, isLoading } = useSWR('/api/user', fetcher)
 
  if (error) return <div>failed to load</div>
  if (isLoading) return <div>loading...</div>
  return <div>hello {data.name}!</div>
}

サーバーコンポーネントになると、手続き的に書けて状態管理は不要、というよりも書けません。またクライアントだとクライアントのロードが終わって最初のEffectが終わってから通信開始ですが、最初のリクエスト時に取得を開始するので完了までの時間も短くなります。

async function Note({id}) {
  const res = await fetch(`/note/{id}`);
  const note = await res.json();
  return (
    <div>
      <Author id={note.authorId} />
      <p>{note}</p>
    </div>
  );
}

先ほども紹介したように、awaitを書かないで置けばストリーミングにもできます。isLoading相当はReactが面倒を見てくれるという感じですね。

初期化以外の通信

ボタン操作やフォーム送信後のデータの更新処理は今まではハンドラの中からfetch()を呼び結果をstateに入れるというのが一般的でした。useSWRMutationなどもありますが。自分で書こうとすると、1つの通信でたくさんの状態の管理が必要となります。このあたりは、改善ポイントを発見する良い指標かと思います。生成AIも注意しないとこういうコード書いてきます。

import React, { useState } from 'react';

export function TraditionalButton() {
  const [name, setName] = useState('');
  const [isLoading, setIsLoading] = useState(false);
  const [error, setError] = useState<string | null>(null);
  const [resultMessage, setResultMessage] = useState<string | null>(null);

  const handleSubmit = async (e: React.FormEvent<HTMLFormElement>) => {
    e.preventDefault();
    setIsLoading(true);
    setError(null);
    setResultMessage(null);

    try {
      const response = await fetch('/api/update-user', {
        method: 'POST',
        body: JSON.stringify({ name }),
      });
      if (!response.ok) {
        throw new Error('サーバーでエラーが発生しました');
      }
      const data = await response.json();
      setResultMessage(data.message || '更新が完了しました');
      setName('');
    } catch (err: any) {
      setError(err.message || '通信エラーが発生しました');
    } finally {
      setIsLoading(false);
    }
  };

  return (
    <button disabled={isLoading} onClick={handleSubmit}>
      {isLoading ? '送信中...' : '送信する'}
    </button>
  );
}

useActionStateを使うとLoading状態管理は減らせます。ついでにエラー管理も<ErrorBoundary>に任せるようにしましょう。このサンプルでは省略していますが、react-error-boundaryのFallbackComponent propを使うとエラー情報を取り出して表示したりできます（他にも色々書き方があります）。

'use client'

import React, { useActionState, startTransition } from 'react';
import { ErrorBoundary, FallbackProps } from 'react-error-boundary';

// 初期状態
const initialState = {
  resultMessage: null,
};

// クライアント側で実行するアクション関数
async function updateProfileClient(prevState, formData) {
  const name = formData.get('name') as string;
  const response = await fetch('/api/update-user', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ name }),
  });
  if (!response.ok) {
    // 💡 throw されたエラーは React 19 が自動で捉え、 ErrorBoundary に送られる
    throw new Error('サーバー通信でエラーが発生しました (Status: ' + response.status + ')');
    }
  const data = await response.json();
  return {
    resultMessage: data.message || '更新が完了しました',
  };
}

export function ModernButton() {
  // updateProfileClientをラップしたformAction。内部で管理する状態、ロード状態取得
  const [state, action, isPending] = useActionState(
    updateProfileClient, 
    initialState
  );

  // transitionでラップする
  onClick = startTransition(async () => {
    action();
  })

  return (
    // エラーハンドリング
    <ErrorBoundary fallbackRender={<div>エラー発生</div>}>
      <button onCick={onClick} disabled={isPending}>
        {isPending ? '送信中...' : '送信する'}
      </button>
    </ErrorBoundary>
  );
}

useActionState()でラップしたのを再度startTransition()でラップするのはちょっと無駄っぽいですよね？次のフォーム送信の場合はstartTransition()不要なのでその感覚は薄れますが、もしuseAcitonState()の状態管理が不要ならもっと短く書けます。useTransition()側でisPendingフラグが取れるので、この状態管理のためだけにuseActionState()を書く必要はありません。

export function PostOnlyButton() {
  // このstartTransitionと対応したisPendingが同時に取れる
  const [isPending, startTransition] = useTransition()

  function onClick() {
    startTransition(async () => {
      const res = await fetch("/api/send/request")
      :
    })
  }

  return (
    <button onClick={onClick} diabled={isPending}>
      {isPending ? '送信中...' : '送信する'}
    </button>
  )
}

フォーム送信

フォームの場合はstartTransition()は不要です。フォームのaction propsに直接入れます。 useActionStateでラップするのがクライアントの非同期関数ではなく、サーバー関数だったら、ハイドレーションが終わってなくても起動するらしい。

export function ModernForm() {
  // updateProfileClientをラップしたformAction。内部で管理する状態、ロード状態取得
  const [state, formAction, isPending] = useActionState(
    updateProfileClient, 
    initialState
  );

  return (
    // エラーハンドリング
    <ErrorBoundary fallbackRender={<div>エラー発生</div>}>
      // onSubmit ではなく action に formAction を渡す
      <form action={formAction}>
        :
        <button onClick={} disabled={isPending}>
          {isPending ? '送信中...' : '送信する'}
        </button>
      </form>
    </ErrorBoundary>
  );
}

なお、Reactではなく、react-domパッケージ側の機能になりますが、こちらもアクションのラップが不要で、単に「ロード中」などの状態などが取得したい場合は userFormStatus() というフックがあります。ここではpendingを使っていますが、dataとかmethodとかactionの関数も取得できます。

import { useFormStatus } from "react-dom";

function Submit() {
  const { pending } = useFormStatus();
  return <button disabled={pending} />
}

export function ModernForm() {
  const { pending, data, method, action } = useFormStatus();
  return (
    <form action={}>
    </form>
  )
}

通信時の先行UI更新

通信完了を待たずに先に値を更新しておいてユーザーの体感を良くすることがよくあります。

import React, { useState, useRef } from 'react';

export function LegacyLikeCounter() {
  const [count, setCount] = useState(10);
  const [isPending, setIsPending] = useState(false);

  const previousCountRef = useRef<number>(count);

  const handleLike = async () => {
    if (isPending) return; // 連打防止

    // サーバー通信を待たずに、バックアップをとりつつ先にStateを更新する
    previousCountRef.current = count;
    setCount((prev) => prev + 1);
    setIsPending(true);

    try {
      await updateLikeApi();
      // 成功したら何もしない（すでに画面は +1 されているため）
    } catch (err) {
      // 失敗した場合は、useRef から古い値を読み出して手動で復元する！
      alert('失敗したため元の数値に戻します');
      setCount(previousCountRef.current);
    } finally {
      setIsPending(false);
    }
  };

  return (
    <button onClick={handleLike} disabled={isPending}>
      ❤️ {count} {isPending && '(更新中...)'}
    </button>
  );
}

何度か出てきているトランジションとセットで使うuseOptimisticというものがあります。トランザクション中では先にuseOptimisticで値を更新しておきます。画面は先に値が新しくなります。その後、トランジションを抜けるまでに元となる要素（これもuseStateのはず）のsetを呼ぶとOKですが、よばないと、useOptimisticは破棄されて元の値が表示されます。

export function LikeCounter() {
  const [count, setCount] = useState(10); // 本番State
  const [, startTransition] = useTransition();

  // useOptimistic(本番State, 楽観更新用の計算式)
  const [optimisticCount, setOptimisticCount] = useOptimistic(
    count,
    (current) => current + 1
  );

  const handleLike = () => {
    startTransition(async () => {
      // 先に画面の数字を +1 する（仮）
      setOptimisticCount(count + 1);

      try {
        await updateLikeApi();
        // 成功した時だけ本番Stateを更新
        setCount((prev) => prev + 1);
      } catch (err) {
        // 失敗した時は setCount を呼ばない！
        // ── これだけで自動的に元の数値（10）に戻ります
        alert('失敗したため元の数値に戻します');
      }
    });
  };

  return (
    <button onClick={handleLike}>
      ❤️ {optimisticCount}
    </button>
  );
}

Next.jsのクエリーパラメータを使った検索フォーム通信

先ほどのフォームのsubmitではどちらかというと、フロントエンド主体でフローをコントロールし、更新結果の管理もしていました。サーバーコンポーネント主体かつ検索のようなURLのクエリーに結果を書くフォームだと動きが大幅に変わってきます。

フロントのタスクとしてはURLのクエリーパラメータだけがタスクとなります。その後、Next.jsがサーバーのページのコードを再実行が自動で行われ、その中でDB問い合わせもしくはバックエンドAPI呼び出しをして結果のページを作ると画面が更新される、という流れとなります。

生成AIに何も指示せずに作らせると、すべてクライアントコンポーネント上の処理とされてしまいますがReact Server Componentの構成を生かすフォームはこのようになるはずです。ここはバリデーションとかは不要なのでuseActionState()は使ってませんが、もちろん組み合わせも可能です。

"use client";

import { usePathname, useRouter } from "next/navigation";
import { useState } from "react";

type SearchPanelProps = {
	initialQuery: string;
};

export function SearchPanel({ initialQuery }: SearchPanelProps) {
	const router = useRouter();
	const pathname = usePathname();
	const [query, setQuery] = useState(initialQuery);

	const updateUrl = (nextQuery: string) => {
		const trimmedQuery = nextQuery.trim();
		const nextUrl = trimmedQuery
			? `${pathname}?${new URLSearchParams({ q: trimmedQuery }).toString()}`
			: pathname;

		router.replace(nextUrl, { scroll: false });
	};

	return (
		<form
			onSubmit={(event) => {
				event.preventDefault();
				updateUrl(query);
			}}
		>
			<label>
				<span>検索キーワード</span>
				<input
					type="text"
					value={query}
					onChange={(event) => setQuery(event.target.value)}
					placeholder="Next.js などを入力"
				/>
			</label>
		</form>
	);
}

import { SearchPanel } from "@/components/SearchPanel";
import type { SearchItem } from "@/lib/search";
import { getAppUrl } from "../../lib/app-url";

// ページの引数にsearchParmasを設定
export default async function SearchPage({ searchParams }) {
	const { q } = await searchParams;
	const query = q?.trim() ?? "";
    console.log("SearchPage searchParams:", query);
	const apiSearchParams = new URLSearchParams();

	if (query) {
		apiSearchParams.set("q", query);
	}

	const response = await fetch(new URL(`/api/search?${apiSearchParams.toString()}`, getAppUrl()), {
		cache: "no-store",
	});
	const results = (await response.json()) as SearchItem[];

	return (
		<main>
			<section>
				<p>Search</p>
				<h1>本を検索する</h1>
				<p>入力すると URL の q パラメータが更新され、結果も連動して表示されます</p>
				<SearchPanel key={query} initialQuery={query} />
			</section>
			<section>
				<div>
					<h2>{query ? `「${query}」の検索結果` : "検索結果"}</h2>
					<p>{results.length} 件</p>
				</div>
				<ul>
					{results.map((item) => (
						<li key={item.id}>{item.title}</li>
					))}
				</ul>
					{results.length === 0 && (
					<p>該当する本がありません。</p>
				)}
			</section>
		</main>
	);
}

アーキテクチャの変化

これまでもPure React(Client Side Rendering: CSR)、サーバーサイドレンダリング(ISGなども含む)などを提供するNext.jsのPages Routerがありました。これにReactサーバーコンポーネント(RSC)主体のApp Routerが加わりました。

すでに上に登場していますが、RSCはその名の通り、サーバーで動作し仮想DOM的なJSONをフロントに送って表示します。JSロジックの代わりに、サーバーで作ったRSCペイロードを送って差分更新することでシームレスな更新と、JSロジックの削減を両立しています。旧来のReactには様々な弱点がありました。それを解決するためにRSCが導入されました:

• Pure ReactやPages Routerではページの全てを構成できるロジックを配る必要があるためJSサイズが大きかった。サーバー専用コードやライブラリを減らす
• DBやファイルシステムなどのサーバー資源へアクセスするコードをシームレスに書ける
• データ取得コードと表示を近くにする
• Server/Client Componentを1つのReactツリーで統合

その代わり、状態を持てなかったり、イベントハンドラが書けない、ブラウザAPIが利用できないという制約があります。

デフォルトはRSCで、”use client”を書くとクライアントコンポーネントになります。なお、”use server”は全く別のディレクティブでサーバー関数用で非対称なのは混乱の元ですが、サーバーコンポーネント指定のためのものではありません。クライアントコンポーネントはそのロジックがすべてブラウザ上に転送されて動作します。なお、それでもNext.jsを使うと初回のレンダリングはサーバーで行われます。

Pure React(CSR)、Pages Router、App Routerの動きの違いを整理しました。

Pure React(Client Side Rendering)

PureだったりNext.jsのstatic export、あるいはクライアントコンポーネント利用がこれにあたります。レンダリングの場合はそれを描画するReactのロジックそのものを送ります。複雑なライブラリなどを利用するとJavaScriptのファイルサイズも多くなりがちですし、それを読み込んでロジックが実行されて初めて表示が開始されるので最初の表示までの時間(FCP)がやや遅くなるといわれています。

なお、Next.jsのstatic exportは、App Routerでも使えて、サーバーコンポーネントもビルド時にHTMLを作成するというのはできます。

Next.jsのPages Router

Reactの弱点（当時）だったSEO対策の改善なども考慮されて作られたのがSSRでした。画面全体をサーバー側で一度作ってそれを送信します。その後、ハイドレーションを行ってイベントハンドラなどを注入します。最初にJSを全部読み込み、初回表示後は前述のクライアントレンダリングになります。

なお、事前にページ全体のコンテンツを作っておく、SSGや、データが追加されたらそのデータを使ったページを作っておくISGというのもありますが、これはサーバー側のレンダリングをユーザーリクエストの前に作っておくということです。この時代の仕組みは「ページ全体を丸ごとキャッシュする」方向での最適化を全力で行なっています。

Next.jsのApp Router

RSCが動くようになったのがこちらです。サーバー主体で動きますよ、となると「PHPで良いのでは？」とか思われるかもしれませんが、サーバー側で動くコードとクライアントで動くコードをモザイクのように組み合わせて最適に動くシステムが構築できる基盤というのは他になかなかない特徴です(.netのblazeはそれに近いと聞いたことがあります)。また、クライアントコンポーネントも初回はサーバーでレンダリングされてからPages Routerと同じくハイドレーションして動きます。

なお、変更があった部分のみの更新となっていますが、実質layout.tsxの部分は再描画しないが、page.tsxの範囲は毎回全部転送となります。そのため、1ページの中にメインコンテンツ(やリスト)が1つみたいな構成であれば無駄な転送が少ないと言えます。一方、メインのチャット欄・ちょくちょく最新情報で更新されるチャンネル一覧・DMリスト、みたいなメインコンテンツが多いものは1つの更新で他のコンテンツもサーバー側が再描画になり、すべてがRSCペイロードに乗っかってくる、みたいな形になって美味しくなさそうです。なるべくメイン以外はクライアントコンポーネントに逃がすとかが必要かと思います。あと無限スクロールを実装するのはServer ComponentとClient Component両方を組み合わせるなど従来通りのClient Componentだけでやるよりも難易度があがります。

なお、page.tsxを全部転送するかと言って毎回同じCPUコストがかかるかというとそうではなく、コンポーネント単位のキャッシュなどがあるため、RSCペイロードを組み立てるコストは削減可能です。ただし、その全量をクライアントには送ることになります。

Pages Routerはページ全体ごとのキャッシュがメインでしたが、App Routerの場合、page.tsxの外側のlayout.tsx、あるいはコンポーネント単位、API/DBアクセス単位など細かくキャッシュさせる機能が提供されています。

それぞれのモードやコンポーネントの動作モード

static exportは除いていますが、なぜ今までのReactと違って色々考えることがあるのかというと、今までのNext.jsは、CSRでできることは基本全てできていて、それをサーバー側でもやる、という思想でした。

ただ、Server Componentは、サーバーのみで動作します。なので今までできていたことを「効率化のために捨てる」とことが必要になります。それにより、今までできていなかった最適化の殻を破ることができます。

App Routerのビルド時orリクエスト時というのは、パラメータがない、動的要素がないコンポーネントは静的に解決されちゃうという意味です。そういうところも今までできない高速化を図っています。

今のところ考えている基本的な方針

さて、ここまで見てきたところで、どのような方針でReact/Next.jsを書いていけばいいかという場合のチーム方針はこんな感じでやろうかと思っています。このあたりは僕がこう考えているだけなので、人によっては別の方針になるかと思います。

1. なるべくサーバーコンポーネントにする
   1. 動的なUIだからクライアントコンポーネント、とあきらめずに、 daisyUIでJSレスで実現されているものはサーバーコンポーネントで実現できると信じる
   2. ↑で紹介した検索パネルのようにsearchParamsに状態を移せるものかどうか検討する
2. 非同期通信のawaitを調整する。時間がかかかる重い通信・データ取得などはストリーミングも検討する
3. キャッシュできそうな部分を見つけて、コンポーネントキャッシュにしていく
4. クライアントコンポーネントでも状態を減らす
   4. isLoading/isPending系を撲滅して回る
   5. サーバーアクションを活用できないか検討する
   6. フォーム回りのロジックを整理する
5. クライアントコンポーネントの遅そうなハンドラをトランジションにしていく
   4. 一時表示系はuseOptimisticを使っていく

まとめ

最初に、Reactの最近の変更のモチベーションとして2つの要素がある、ということを説明しました。それに当てはめるとこんな感じに分類できるのかな、と思います。順番はこのエントリーで紹介した順です。

hook出始めの頃のReactのシンプルな仕組みを組み合わせて「変更をコントロールして結果が正しく表示される」というところから、Reactに任せるところは任せて状態を減らし、なおかつReactの描画をコントロールするという感じで、もう一段ギアが上がった感じがあります。非同期通信が扱いやすくなったのもうれしいですね。

難しくなったのか？というと、そんなことはなくてコントロールできる範囲が広がり、設計の方針がシンプルにわかりやすくなった、という感じかに思います。サーバーサイドレンダリングでどうせ作るのであればそれをそのまま活用しようとか、状態管理ピタゴラスイッチは減らしていこう、という公式のメッセージだな、というのを感じました。状態が減ればその分複雑な状態を扱う状態管理ライブラリが必要になることも減ります。通信もサーバーコンポーネントに寄せれば、ワンショットでコンポーネント表示でデータ取得するようなケースはだいぶ楽に書けます。React 18/19で導入された数々をきちんと理解すると、「うわー、前のやり方は無駄が多かったんだ」という気持ちになり少なくとも、以前のReactの書き方に戻ろうとは思えなくなりました。

19で追加されたuseSyncExternalStoreとかexperimentalな<ViewTransition>みたいな面白そうな機能もあったりしますが、よく使いそうなところでまとめてみました。

• Enterで勝手に送信しちゃう
• IMEの最初の文字が取れない

Enterで勝手に送信されちゃう

<input>でテキスト入力を作り、チャットを作りたいとします。わざわざボタンをクリックしないと送信できないのは不便なのでEnterで送信できるようにしようとします。changeイベントやblurではフォーカスを一度外さないと確定にならないため、keydownイベントでEnterを拾って送信したいとします。こんな感じでしょうか？もう令和8年なのでReact Compilerを想定してシンプルに書いています。

const [text, setText] = useState("");

function checkEnter(e) {
    if (e.key === "Enter") {
        sendMessage(text); // 送信！
    }
}

<input
    type="text"
    value={text}
    onChange={(e) => setText(e.target.value)}
    onKeyDown={checkEnter}
/>

これを実際に動かしてみると、日本語確定のEnterで送信されてしまいました。

「はい(変換確定)」と入力し、送信用にEnterを押すとには次のようなイベントが流れてきます。

1. [h]押下
   • input: value=h
   • keydown: key=h
2. [a]押下
   • input: value=は
   • keydown: key=a
3. [i]押下
   • input: value=はい
   • keydown: key=i
4. [Enter]押下で確定
   • input: value=(empty)
   • input: value=はい
   • keydown: key=Enter →ここで送信されちゃう！
5. [Enter]押下で送信したかった
   • keydown: key=Enter
   • change: value=はい

これを見れば、keydownイベントでとるのではなく、changeイベントで送信すれば一見良さそうです。しかしそれではうまくいきません。Slackとかもそうですが、だいたい「送信ボタン」がありつつも、ショートカットとして「Enter」送信を許容しています。

送信確定前にちょっと別のチャンネルを見て確認しておこうと別の要素にフォーカスしたりすると次のようなイベント発生されます。

6. [Enter]を押さずに別の要素をフォーカス
   • change: value=はい
   • blur: value=Enter

このchangeではまだ送りたくはないですが、送信するかどうかはこのあとにblurが起きるかどうかで判定が必要です。が・・・なんて後の時系列で起きるイベントの判定ロジックなんて実装したくはないですよね。

IMEに関するイベントや情報がHTMLにはあります。IMEを使った変換の開始と確定後にはcompositionstartとcompositionendイベントが発火します。また、inputイベントやkeydownイベントにはisComnposingという属性が付きます。Reactであれば、e.nativeEvent.isComposingといった感じで情報が取れます。この2つも足すと以下のようなイベントが流れてきます。

1. [h]押下
   • compositionstart
   • input: value=h isComposing=true
   • keydown: key=h isComposing=true
2. [a]押下
   • input: value=は isComposing=true
   • keydown: key=a isComposing=true
3. [i]押下
   • input: value=はい isComposing=true
   • keydown: key=i isComposing=true
4. [Enter]押下で確定
   • input: value=(empty) isComposing=true
   • input: value=はい isComposing=true
   • compositionend: value=はい
   • keydown: key=Enter isComposing=false // ここに注目
5. [Enter]押下で送信
   • keydown: key=Enter isComposing=false
   • change: value=はい

残念ながら、最後の確定のEnterではisComposing=falseなので、ステートレスに判定はできません。しかし、compositionendからすぐ後にkeydownが発生するので、最後のcompositionendイベントでタイムスタンプを取得し、そこから短時間(20mSとか)以内のEnterは除外するというロジックにすればOKです。

isComposing属性関係ないじゃん！ と思われるかもしれませんが、グリッドコントロールとかで確定済み状態でのカーソルやタブでアクティブなセルを移動したい、みたいなケースはあるかと思います。Enter以外のキーであれば、isComposing=trueの時のこれらのキーは無視する、というロジックにすればOKです。

キー入力でラベルの変更するが変換前の文字が入ってしまう

PowerPointのオブジェクト編集機能のようなものを作りたいとします。マウスクリックなどでフォーカスした要素に対し、キーボード入力をするとそのラベルの変更ができ、確定するとそのラベルが設定されます。よくある機能なのでイメージしやすいですよね？前項の確定部分の話はちょっとここでは除外してonChangeで確定としておきます。こんな感じでしょうか？

const divRef = useRef(null);
const [editing, setEditing] = useState(false);
const [label, setLabel] = useState("ラベル");

function focus() {
    difRef.current?.focus();
    e.preventDefault();
}

function keydown(e) {
    if (!editing) {
        setLabel(e.key);
        setEditing(true);
    }
    e.preventDefault();
}

function fix(e) {
    setLabel(e.value);
    setEditing(false);
}

<div ref={divRef}
    onClick={focus}
    onKeyDown={keydown}
>
    {editing ? <input value={label} onChange={fix} /> : label}
</div>

これ、そのまま動かしてみると「あいうえお」と入力すると「aいうえお」となっちゃうんですよね。keydownでは変換前の文字が入ってしまうので。inputイベントにすると、あ行だけはうまくいきますが、子音を入力すると同じ結果になります。変換途中の情報はフォーカスと一緒で、controlled componentとして外から状態を与えられないので、1文字目が変換中、という状態を外から作り出すことはできません。

あと、ここでは毎回リセットになっていますが、カーソル移動で末尾だけ編集したいみたいなものを実現するのは大変です。

代わりに、選択時に非表示のinputタグを作って、全選択状態でフォーカスしておきます。そして何かしらのイベントが発生したらそのinputタグを表示するというやり方にします。IMEが関連するテキスト入力は1つのinputタグが責任を持って最初の文字から全て受ける必要があります。クリックやカーソルでの適切な位置のカーソル移動もinputタグ任せにできるため、最小工数で自然な入力が実現できるでしょう。

const inputRef = useRef(null);
const [select, setSelect] = useState(false);
const [editing, setEditing] = useState(false);
const [label, setLabel] = useState("ラベル");

function focus() {
    inputRef.current?.focus();
    inputRef.current?.setSelectionRange(label.length, label.length);
    e.preventDefault();
}

function show(e) {
    if (!editing) {
        setEditing(true);
    }
    e.preventDefault();
}

function fix(e) {
    setLabel(e.value);
    setSelect(false);
    setEditing(false);
}

let inputStyle = "";
if (editing) {
   inputStyle = "";
} else if (select) {
   inputStyle = "position: absolute; left: -9999px;"
} else {
   inputStyle = "display: hidden;"
}

<div ref={divRef}
    onClick={focus}
    onKeyDown={keydown}
>
    <input ref={inputRef} style={inputStyle} value={label} onChange={fix} onKeyDown={show} onClick={show} />
    {isEditing ? undefined : label}
</div>

まとめ: キーボード入力は使い勝手に直結する

どちらも明確な「送信ボタン」「編集ボタン」を用意すれば用意して、操作する人に対して１アクション余計にしてもらえば良いだけの話ですが、世の中に便利なものがあるなら、それと近づけてほしいと思うのが人情というものです。

試験的なプログラムでその1アクションを減らすのに、生成AIに雑に指示を投げてもなかなか問題を解決してくれなくてちょっと苦戦したのでメモとしてブログにしておきます。

生成AIに指示するなら？

シンプルな機能であればWhatを指示することで賢いモデルであればきちんと実装してくれるのですが、過去の経験上、このIME周りのハンドリングは必ずしもうまくいかないですね。Howで実装方法を指定してあげる必要があります。

前者のEnterのハンドリングを指示する場合は…

compositionendのタイムスタンプを取得し、keydownでのEnterの判定で変換直後の物は除外してください

…といった感じで指示すればうまくいくでしょう。

後者の方はやや難しいですが…

オブジェクトの状態には選択モード、編集モードがあります。選択モードでは見えないinputタグを作り、これまでのラベルのテキストを入れた上で全選択状態としてください。その後何かしらのキー入力で編集モードになります。編集モードではinputタグが見えるようになります

…といった感じの指示の必要があるでしょう。前者の確定のEnter除外を組み合わせたい場合は別途追加で指示が必要です。ESCでrevertとかいろいろ機能を入れようとするとそれなりに複雑化しますが、最初のIMEハンドリングがきちんとできていればなんとかなるはずです。

プロによる本気の攻略本『JavaScript/TypeScript実力強化書』 - FL#115というForkwellを運営するGroovesさんのイベントで登壇してきました。こちらが発表資料になります。

元の原稿が2019年でECMAScript 2018を想定していたものだったので、今回の書籍化にあたってはだいぶ現行に手を入れました、というお話でした。

ただ、時間的にその内容を全部紹介する時間はなかったので、更新の紹介はダイジェストにしつつ、2017ぐらいのJavaScript界隈はどんなエコシステムでどんな雰囲気を書いていたのか、という話を中心にしました。「こんなに変わったんだ」「だいぶ進化したな」とか思っていただけたのではないかと思います。おそらく、多くの人はそれなりに新しいトレンドには追従している（関数型志向なフレームワークに巻き込まれる形で）と思っていますが、きっと過去との比較を見ると「知らない間に自分もレベルアップしていた」みたいな気持ちになる人も多いと思います。

他の人の発表も面白かったです。クロージャの仕組みとかは当たり前に思えるけれども、特に仕様をしっかり読まないとなかなか知りえない話だったりするので。ゆるーく、有識者同士で話をするのも楽しかったです。

イベントは本日(11/28)も後半の部がありますので、ご興味のある方は登録するとよいと思います。

写真は私の登壇の様子を参加していた別の社員に撮っていただいたものです。

はじめに

FVGの永井優斗です。秋のブログ週間1本目です。

2025年10月25日に開催された「Vue Fes Japan 2025」のライトニングトーク（LT）に登壇いたしました。昨年のプラチナスポンサーセッション（昨年の登壇報告記事） に続き、2年連続での登壇となります。

今回フューチャーアーキテクト株式会社は、今回ゴールドスポンサーおよびルームネイミングライツスポンサーとして協賛しました。ネーミングライツにより、１つの部屋（トラック）は「経営とITをデザインする フューチャーアーキテクトトラック」として会場内でアナウンスされたほか、#vuefes_future のハッシュタグで本トラックの公演内容はX上でポストされました。

『React Nativeならぬ”Vue Native”が実現するかも? 新世代マルチプラットフォーム開発フレームワークの LynxとLynxのVue.js対応を追ってみよう』 というタイトルで、今年3月にOSS化されたばかりのフレームワーク「Lynx」と、そのVue.js対応の動向についてお話ししました。

また、登壇とは別の時間は、私は当日ボランティアスタッフとしても活動しており、ハンズオンの出欠を確認したりしておりました。

CfP(Call for Proposal)の採択

今回はスポンサーセッションではなく、公募（いわゆる「CfPを通す」）での登壇です。VueFesでは、CfPのスピーカーの採択は、完全に匿名で応募者の名前を隠したうえで登壇タイトルと詳細をみて判断をしているそうです。その話を聞いて、著名なスピーカーでなくとも、ニッチな話をもっていけば、もしかしたら面白がって採択されるかもな？と思い、ニッチなネタとして3月のLynx公開時からLynxのVue対応のネタを温めていました。

また、私はTSKaigi 2025にも運営スタッフとして参加しています。そのAfter Eventで知り合ったsiminoriさんと、「（上記のような）Lynxネタを温めており、VueFesのLTに応募をしようと思っている」と話したところ、意気投合し、お互いLTでCfPに応募しようと盛り上がりました。まさか、二人ともLT登壇が決まるとは思わず、スピーカーの紹介がWebサイトに載った時には大変驚きました。

来年はTSKaigiの登壇…かな…！

登壇内容と資料

当日の登壇資料はこちらです。

LTなので詳細を語ることを省きつつも、Vueでモバイル開発することへの過去のチャレンジを振り返りつつ、3月発表されたLynxに着目していること、Vue対応の経緯と現状について話しました。

また、VueLynxについては海外の方によってまとめられた記事があるため、自分がこれを発表する意味はなんだろうと考えた結果、自分自身がLynxを触った感想も入れ込みました。それを入れようとおもったがゆえに、9月にLynx記事を仕込んだりするわけですが笑

当日の様子と反響

昨年に続き、2年連続での登壇、3年連続の参加となりましたが、やはりVue Fes Japanの熱気は格別でした。
毎回思うことですが、「Fes」という言葉が正しいと思えるくらいにお祭り感のある、たのしいカンファレンスでした。

登壇後の反応としては、Lynxそのものを知らなかったという話や、LynxとLynxのVue対応、あれだけ盛り上がってたのにいまは確かにそうでもないなといったコメントをいただきました。

＜X上での反応＞

Lynx 初聞き
2025年3月に出たのねhttps://t.co/8OD0OQqLyU#vuefes_mates

— yuki / ほにゃにゃ (@honyanyas) October 25, 2025

確かにLynx出た直後は話題になってたけど、それ以降あんまり話題になってない感じするな#vuefes #vuefes_mates

— thirdlf (さどるふ) (@thirdlf1) October 25, 2025

また、自己紹介スライドにあった、BBQインストラクターやパエリア検定上級が気になったと声をかけてくださった人もいました笑

スポンサーブース

フューチャーアーキテクトは、今回ゴールドスポンサーとしてブースも出展していました。

今回は配布物（ノベルティ）を3種類用意し、くじ引きでどれかが当たる企画を実施しました。1等は最近発売された当社の渋川よしきが著者の1人である「JavaScript/TypeScript実力強化書―⁠―関数・非同期処理・型システム完全攻略」に渋川のサイン入りでお渡ししました。

くじはVueFesだからと、Vue.jsを使ったHTMLファイルで作成しました。（GeminiさんがHTMLファイル1枚で9割方作成してくれました。生成されるまで30秒くらい。ほんとにすごいね。）

実際には一瞬で抽選処理は終わるんですが、ドキドキ感のある「抽選中」の演出をつけたものを作成しました。

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>くじ引き</title>
    <script src="https://unpkg.com/vue@3"></script>
    <style>
        body {
            font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, 'Helvetica Neue', Arial, sans-serif;
            display: flex;
            justify-content: center;
            align-items: center;
            min-height: 100vh;
            margin: 0;
            background-color: #f4f7f9;
        }
        #app {
            text-align: center;
            background-color: white;
            padding: 30px 40px;
            border-radius: 12px;
            box-shadow: 0 10px 25px rgba(0,0,0,0.1);
            width: 90%;
            max-width: 400px;
        }
        h1 {
            color: #333;
            margin-bottom: 10px;
        }
        button {
            padding: 15px 35px;
            font-size: 1.2em;
            font-weight: bold;
            cursor: pointer;
            border: none;
            background: linear-gradient(45deg, #ff8a00, #e52e71);
            color: white;
            border-radius: 8px;
            transition: transform 0.2s, box-shadow 0.2s;
            margin: 25px 0;
            box-shadow: 0 4px 15px rgba(229, 46, 113, 0.4);
        }
        button:disabled {
            background: #ccc;
            cursor: not-allowed;
            box-shadow: none;
        }
        button:hover:not(:disabled) {
            transform: translateY(-2px);
            box-shadow: 0 6px 20px rgba(229, 46, 113, 0.5);
        }
        #result {
            margin-top: 20px;
            font-size: 2em;
            font-weight: bold;
            color: #e52e71;
            height: 60px;
            display: flex;
            justify-content: center;
            align-items: center;
        }
        .finished-message {
            color: #555;
            font-weight: bold;
        }
        .prize-list {
            list-style: none;
            padding: 0;
            margin-top: 25px;
            text-align: left;
        }
        .prize-list li {
            margin-bottom: 10px;
            font-size: 1.1em;
            background-color: #f9f9f9;
            padding: 10px;
            border-radius: 5px;
        }

        /* ドキドキ感を出すためのアニメーション */
        @keyframes drumroll {
            0% { transform: scale(1); opacity: 0.7; }
            25% { transform: scale(1.1); opacity: 1; }
            50% { transform: scale(1); opacity: 0.7; }
            75% { transform: scale(1.1); opacity: 1; }
            100% { transform: scale(1); opacity: 0.7; }
        }

        .drawing-text {
            font-size: 1.5em; /* 結果より少し小さく */
            color: #555;
            animation: drumroll 1.2s infinite;
        }
    </style>
</head>
<body>

<div id="app">
    <h1>🥢Future Architectくじ🥢</h1>
    <button @click="startDraw" :disabled="isFinished || isLoading">くじを引く</button>

    <div id="result">
        <p v-if="isLoading" class="drawing-text">抽選中...</p>
        <p v-else-if="result">{{ result }}</p>
    </div>

    <div v-if="isFinished" class="finished-message">
        <p>くじはすべてなくなりました！</p>
    </div>

    <hr>

    <h2>残り本数</h2>
    <ul class="prize-list">
        <li v-for="prize in prizes" :key="prize.name">
            {{ prize.name }}: 残り <strong>{{ prize.stock }}</strong> 本
        </li>
    </ul>
</div>

<script>
    const { createApp, ref, computed } = Vue

    createApp({
        setup() {
            const prizes = ref([
                { name: '🥇 1等', stock: 5 },
                { name: '🥈 2等', stock: 60 },
                { name: '🥉 3等', stock: 100 },
            ]);

            const result = ref('');
            // 抽選中かどうかを管理する状態
            const isLoading = ref(false);

            const totalStock = computed(() => {
                return prizes.value.reduce((total, prize) => total + prize.stock, 0);
            });

            const isFinished = computed(() => totalStock.value === 0);

            // くじを引く処理を2段階に分ける
            const startDraw = () => {
                if (isFinished.value || isLoading.value) return;

                isLoading.value = true; // 抽選開始
                result.value = ''; // 前回の結果をクリア

                // 2500ミリ秒 (2.5秒) 後に結果を出す
                setTimeout(() => {
                    drawLottery();
                    isLoading.value = false; // 抽選終了
                }, 2500);
            };

            // 実際の抽選ロジック
            const drawLottery = () => {
                const random = Math.floor(Math.random() * totalStock.value) + 1;
                let accumulated = 0;
                for (const prize of prizes.value) {
                    if (prize.stock > 0) {
                        accumulated += prize.stock;
                        if (random <= accumulated) {
                            result.value = `🎉 ${prize.name} 当選！ 🎉`;
                            prize.stock--;
                            break;
                        }
                    }
                }
            };

            return {
                prizes,
                result,
                startDraw,
                isFinished,
                isLoading // テンプレートで使えるようにする
            };
        }
    }).mount('#app');
</script>

</body>
</html>

ありがたいことに、昨年を大幅に上回る人数の方がスポンサーブースに立ち寄っていただいたこともあり、ノベルティは13時頃にはすべてはけてしまったようです。
それ以降に立ち寄ってくださった皆様、申し訳ございません。

さいごに

今回のセッションでお話しした「VueLynx」は、まだプロトタイプが公開された段階で、正直なところ、この先どうなるかは分かりませんし、Lynxそのものも、まだ日本語での情報が少ない状況です。登壇資料の最後に書いた通り、本登壇を通じて、実現した時のワクワク感が参加者の皆さんに届き、少しでも盛り上がれば幸いです。

最後になりましたが、このような素晴らしい技術コミュニティの「お祭り」を企画・運営し、LT登壇の機会をいただいたVue.js日本ユーザーグループの皆様、そして当日LTにご参加いただいた皆様、ありがとうございました。

こんにちは、CSIG（Cyber Security Innovation Group）所属 の松本です♪

フロントエンド初心者ですが Vue連載 で頑張ってみました。

現在専門ドメインはセキュリティです。もともとデータのセマンティックに関心がありますが、加えて最近では脅威モデリングや脅威インテリジェンスに注目しています。

今回は、経営者がセキュリティ投資判断をしやすくする簡易ダッシュボードを構築しました！使用するデータ量が多くなってもブラウザで固まらず、今後の拡張性も加味した構成にしたかったため WASM (WebAssembly) を組み込んでいます。開発プロセスで遭遇するセキュリティ豆知識も掲載しているので、記事を通して一緒に学んでいければと思います。

背景

本テーマを執筆した背景としては、セキュリティ投資意識を具体的な行動へつなげる支援ができたら、という思いからです。

セキュリティは売り上げに直接的に結びつかないため「守りの投資」と言われており、平時はコストとみなされがちです。しかし、有事になるとこれまで投資を着実に進めてきた企業とそうでない企業で結果は 二極化 します。

直近でも、国内大手企業においてインシデントが多発しており、特にランサムウェア被害が拡大しています。もはやサイバー攻撃を完全に防ぐことはできません。自社リソースを鑑みて “どこ” に “どの程度” セキュリティ投資すると最もROIが高くなるのかを真剣に見極め、現時点ベースでの対策を実行に移していくことが被害を最小限にする対策です。

本記事を読むメリット

• Single Page Applicationでデータ分析～可視化の可能性を知ることができる
• Vite環境でDuckDB-WASMを扱う際のポイントを知ることができる
• VueとEChartsの連携方法と描画機能とUIの関係について知ることができる
• 現時点ベースでのセキュリティ投資判断の重要性を認識できる

本ツールがもたらす効果

• 工数削減と迅速化
  これまで担当者が数時間～数日かけて定期的に行っていたセキュリティ対応の精査及び優先順位付け（情報の調査、分析、対策立案まで）のプロセスを短縮します。
• 対策の精度向上
  「とりあえず全部のログを取る」といった闇雲な対策から、自社に合わせた費用対効果（ROI）の高い対策へシフトできます。
• 組織内のコミュニケーション円滑化
  エンジニア、マネージャー、経営層が同じデータを見て会話できるため、セキュリティに関する意思決定がスムーズになります。

※気になる方が多ければ何かしらの形でツール公開も視野に入るため、記事へのリアクションを いいね♥ や SNS などでいただければ幸いです。今回はあくまでフロントエンド開発の記事となります。

アウトプット

最終的に経営者ビューと技術者ビュー二画面切り替え仕様にし、ホバーやドラッグ&ドロップができるInteractiveなアプリとなりました :)

【経営者ビュー】

投資対効果を検討するため、その対策をしたときの想定損失低減率を縦軸、１つの対策で自社の資産をどの程度（範囲/規模）守ることができるのかのカバレッジを横軸に4象限で区分けし、現状に即したセキュリティ投資対象を選別することを想定しています。バブルチャートは投資割合を表しており、左下の基準(1)となる円より大きければ過剰投資、小さければ投資不足を意味します。つまり、右上の “IDEAL AREA” に基準円と同じ大きさの円があれば、最適な投資対象 に 最適な投資額 を投じていることになります。具体的な数値は、カーソルオン時のポップアップに記載しています。

【技術者ビュー】

経営者に根拠をもって説明するため、技術的脅威（attack technique）と防御策と対象資産を網羅的に紐づけ、防御策の有効性を可視化することを想定しています。クリックすると、各ノードは該当するMITREのリンクへアクセスしてくれます。

要件と仕様

個人の即席アプリ開発ということで、技術選定しました。

要件

• 素早い開発環境構築
• 高速処理
• インタラクティブなUI
• 拡張性

仕様

• Vite + vue：高速な開発環境とUI構築
• DuckDB-WASM：ブラウザ内蔵の超高性能データベースエンジン
• Echarts：インタラクティブ性の高い豊富なグラフ描画ライブラリ

関連用語

• SPA（Single Page Application）
  処理の多くをサーバーと通信せずにブラウザ内（クライアントサイド）で完結させ、ページ遷移なしの高速なUIレスポンスを実現するアプリケーション全般を指します。
• DuckDB
  もともとは、データ分析（大量のデータを読み込んで集計や計算をすること）に特化した、高速なデータベースです。「データ分析版SQLite」のような存在です。操作デモ をweb上で行うことができるので是非使用感をお試しください。
• WASM (WebAssembly)
  C++やRustのような高速な言語で書かれたプログラムを、ブラウザ内でほぼネイティブの速度で実行可能にするための技術です。
• DuckDB-WASM
  DuckDB本体をWASMに変換することで、この強力なデータベースをブラウザの中で完結させる（=サーバレス）ことを実現しました。DuckDB-WASMは外部サーバーと通信するのではなく、SPAが動いているブラウザの中で直接、強力なデータ処理能力を提供します。したがって、サーバーとの通信は最初のデータ取得1回だけに減り、その後の複雑なフィルタリングや集計はすべてブラウザ内で完結し、結果としてUIは常に高速なまま動作することになります。

開発環境準備

Windowsでの Duckdb-WASM開発はすでに 先駆者 がいらっしゃったため、今回は Rocky Linux を利用することとしました。

$ curl -o- [https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh](https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh) | bash
~~~ (中略) ~~~

$ node -v
v22.19.0
$ npm -v
11.6.0

参照先：https://github.com/nvm-sh/nvm?tab=readme-ov-file#installing-and-updating

開発環境は、下記で進めます。

• プロジェクト名：security-invest
• フレームワーク：Vue
• 言語：TypeScript

今回使用したライブラリ群は以下の通りです。

$ npm list
security-invest@0.0.0 /home/user01/security-invest
├── @duckdb/duckdb-wasm@1.29.0
├── @types/node@24.9.1
├── @vitejs/plugin-vue@6.0.1
├── @vue/tsconfig@0.8.1
├── echarts@5.6.0
├── path@0.12.7
├── typescript@5.6.3
├── vite-plugin-static-copy@3.1.4
├── vite@5.1.2
├── vue-echarts@6.7.3
├── vue-tsc@3.1.2
└── vue@3.5.11

※DuckDB APIは 1.29.0と1.30.0でAPIの仕様変更があり、事前によく確認してから利用することをお勧めします。

ソフトウェアサプライチェーン問題

npmは汚染されやすいという話を聞いたことがありますか？

npm audit

上記コマンドは、プロジェクトが依存しているパッケージ（package.json にリストされているもの）に既知の脆弱性がないかを自動チェックし、脆弱性が見つかった場合はその詳細（深刻度、影響を受けるパッケージ、修正方法）をレポートしてくれます。

npm audit fix npm audit fix --force

上は互換性を維持したまま（セマンティックバージョニングの範囲内で）修正可能な脆弱性の多くを自動でアップデートしてくれます。下はメジャーバージョンが上がるような、互換性が壊れる可能性のあるアップデートも強制的に実行します。基本は上のみで問題ないと思います。

開発ディレクトリへ移動して…

npm run dev

この時点で、表示されたURLにブラウザでアクセスすると、Vueの初期画面が表示されます。立ち上がりが早いですね！

ディレクトリ構成

duckdb-graph-spa/
├── index.html
├── vite.config.ts
├── package.json
├── public/                <-- WASMとCSVの配置場所 (Viteの標準)
│   ├── inputdata_01.csv
│   ├── inputdata_02.csv
│   └── ...（材料はここへ）
│   └── duckdb-wasm/       <-- DuckDBのWASM/Worker関連ファイル
│       ├── duckdb-mvp.wasm
│       ├── duckdb-mvp.worker.js
│       └── ... (その他必要なファイル)
└── src/
    ├── components/
    │   ├── RiskCharts.vue
    │   ├── MitreGraph.vue
    │   └── ToggleSwitch.vue
    ├── composables/
    │   └── useDashboardData.ts  <-- DBヘルパー呼び出し
    ├── services/
    │   └── duckdbService.ts     <-- DB初期化、接続、クエリ実行のヘルパー
    └── sql/                     <-- SQLクエリファイルの置き場所
        ├── getRiskData.sql
        ├── getMitreData.sql
        └── getPriorityscore.sql

実装

実装にあたってポイントをご紹介します。

Viteビルドオプションの活用

Viteは、モダンなWeb開発で使われる非常に高速な開発ツール（ビルドツール）です。下記設定ファイルを使って、Viteの動作をプロジェクトに合わせてカスタマイズします。オプションがさまざまあるので こちら を参考に使いこなしてみましょう。

クロスオリジン分離

処理を高速化させたい場合に、DuckDB-WASM のマルチスレッド機能を利用するため COEP/COOP ヘッダーを設定することでデフォルトではセキュリティ面（Spectre脆弱性）から無効化されている SharedArrayBuffer を有効化できます。が、「自ドメイン以外のリソースを読み込む際に、相手側が読み込み許可と宣言してくれていないと、ブラウザがブロックする」という制限がかかります。そのため、許可宣言を記載をすべてのリソースに行わないといけないのでかなり大変です。ここに高速処理とセキュリティのトレードオフを垣間見ました…。最初知らずに設定し続けていたため、画面に何も表示されず沼にはまりました(´;ω;｀) (3Dグラフィックスの計算などはWASM-Thread高速処理設定が必要だったりするのですかね…今回はそこまでの量を扱ってないので利用せず)
詳細解説は こちら

import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [vue()],
  optimizeDeps: {
    include: [
      'echarts',
      'vue',
      'duckdb-wasm',
    ],
  },
  server: {
    headers: {
      // Activate to use SharedArrayBuffer function
      'Cross-Origin-Opener-Policy': 'same-origin',     // COOP
      'Cross-Origin-Embedder-Policy': 'require-corp',  // COEP
    },
  },
})

optimizeDeps では、Viteが自動検出しにくい可能性のある echarts, vue, duckdb-wasm の3つを、強制的に最適化（事前バンドル）の対象に含めて開発環境の安定化を図っています。

DBインスタンスのシングルトンパターン管理

下記のような専用ファイルを作成し、そのファイル内でDBインスタンスを1回だけ生成し、exportすることでコンポーネントの再描画時にDuckDB初期化処理の実行をスキップさせます。Vue コンポーネント側は、常にこの export されたインスタンスを import して使います。

import * as duckdb from '@duckdb/duckdb-wasm';
import duckdb_wasm from '@duckdb/duckdb-wasm/dist/duckdb-mvp.wasm?url';
import duckdb_worker from '@duckdb/duckdb-wasm/dist/duckdb-mvp.worker.js?url';

// 1. DBインスタンスをここで生成
const dbInstance = new duckdb.AsyncDuckDB();
let isInitialized = false;

// 2. 初期化処理を関数として切り出す
export async function initializeDB() {
  if (isInitialized) return dbInstance;

  await dbInstance.instantiate(duckdb_wasm, worker);
  isInitialized = true;
  return dbInstance;
}

// 3. インスタンスそのものやクエリ関数をexportする
export const db = dbInstance;

Interactive UI

こちらは、ホバー時のポップアップ表示の挙動を指示している箇所です。「データ要素にマウスを合わせたらツールチップを出す。その際、もしデータに詳細な description があればIDと説明文をリッチに表示し、なければ name だけをシンプルに表示する」を実現しています。

tooltip: {
      trigger: "item",
      formatter: (p: any) =>
        p.data.description
          ? `<b>${p.data.id}</b><br/>${p.data.description}`
          : p.data.name,
    },

こちらは、ノード（点） と リンク（線） で構成されるデータの関係性を表現している箇所です。

~~~（中略）~~~
          color: "#333",
          fontSize: 11,
        },
        // --- 力学シミュレーション設定 ---
        force: {
          repulsion: 180,
          edgeLength: [80, 140],
        },
        // --- データ配列設定 ---
        data: sortedNodes.map((n) => ({
          ...n,
          itemStyle: { color: n.color },
          // --- リンク数（重要度）に応じてノードを巨大化 ---
          symbolSize: 25 + nodeDegree(n.id) * 3,
        })),
        links: mitreGraph.value.links,
        lineStyle: {
          color: "rgba(150,150,150,0.4)",
          width: 1.5,
        },
        // --- ホバー時のハイライト設定 ---
        emphasis: {
          focus: "adjacency",
          lineStyle: { color: "#888", width: 3 },
        },
      },
    ],

Parquet形式

DuckDB-WASMは Parquet形式 の読み込みに最適化されています。したがって、大量のデータをS3等に保管し、そこから必要な分だけ読み出すという処理を得意とします。データ量が膨大になった際、こちらの機能を利用することが想定されます。CloudShell上にDuckDBをinstallしてデータDLなしで分析可能な体制を作る ことが可能（無料!!）なのでAthenaの代替として有効な手段かもしれません。

インプットデータ

管理台帳系

情報資産管理台帳で一般的に取得可能と想定されるデータを用意しました。それに加え、定量化するにあたって必要な情報を疑似的に保持させました。

MITRE系

今回利用する MITRE ATT&ACK と MITRE D3FEND は STIX準拠のNoSQLでした。DuckDBを利用するためクエリ検索しやすい形に変換する必要があります。

公式サイト内をよく探すと、STIXではない形式での取得が可能なAPIが提供されていました。興味のある方は見つけてみてくださいね :)

※今回利用しているデータは一般公開情報を元にしたサンプルデータとなります。

参考

https://duckdb.org/docs/stable/clients/wasm/instantiation
https://duckdb.org/docs/stable/clients/wasm/data_ingestion
https://duckdb.org/docs/stable/clients/wasm/query
https://www.flatuicolorpicker.com/all-flat-ui-colors/
https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/000055518.xlsx
https://www.ipa.go.jp/security/sme/f55m8k000000587z-att/outline_guidance_risk.pdf
https://attack.mitre.org/resources/attack-data-and-tools/
https://d3fend.mitre.org/api-docs/

まとめ

今回は、実用性のあるアプリを題材に、Vue + DuckDB-wasm + ECharts を実装する上でのポイントやセキュリティ関連の知識を解説してみました。

この記事をきっかけに、

• サーバーレスでも分析アプリをつくってみたい！という方
• セキュリティを意識した開発プロセスを実践できる技術者
• セキュリティ投資の重要性を理解し投資判断できる経営者

が増えるといいなと思います :)

※上記サムネイルはChatGPTにて本記事を読み込ませて生成しました。

Future Value Group（FVG）の永井優斗です。

Vue.js連載の6本目です。Vue.js は使いやすく、直感的なテンプレート構文でフロントエンド開発を加速してくれます。しかし、その便利さゆえに「セキュリティをうっかり見落とす」ことがあるのも事実です。

この記事では、Vue.jsで実際にわざと脆弱なアプリを作り、そこからXSS・Cookie・CSRF・レート制限といった脆弱性を一気に体験してみます。ちなみにソースの8割ぐらいは生成AIに生成してもらいました。この記事も生成AIと相談しながら書きました。すごいね。

教材アプリはこちらのGitHub上で公開しています。

※試すことを優先しているのでUIはシンプルに。そのうちきれいにしたいなあ…

はじめに

今回の教材アプリは Vue 3 + Vite で構築し、バックエンドには Express を利用します。

「脆弱版」と「安全版」を切り替えて、落とし穴と対策を比較できる構成です。

01-vulnerable/   # ← わざと脆弱な実装
02-safe/         # ← 対策を施した実装

ローカルで起動してお試しください。

教材アプリはセキュリティの知識を駆使して情報を抜き取るゲームである、「CTF（Capture The Flag）」のような形で作成しており、脆弱版では各課題にて「攻撃」が成功すると100点のスコアがGetできます。全部で3問あります。

この記事はCTFの「答え」にあたるものでもあるので、セキュリティ知識を試したい方は先に教材アプリを試してみてから本記事をお読みください。

起動方法：

cd 01-vulnerable
npm install
npm run server   # APIサーバ (http://localhost:3001)
npm run dev      # フロントエンド (http://localhost:5173)　上のnpm run serverとは別のターミナルで実行してください

1. DOM XSS（v-htmlの乱用）

Vue.js では、テンプレートの中で変数を埋め込む際、{{ userInput }}のように記述すると、自動的にHTMLがエスケープされます。
そのため、通常の使い方ではユーザーの入力からXSSは発生しません。

しかし、「HTMLを直接描画したい」という欲求に負けて v-html を使うと、XSSの標的になるかもしれません。

v-htmlとは

<div v-html="someHtml"></div>

このように書くと、someHtml の中身がそのままHTMLとして挿入されます。

つまり、ユーザー入力が <p>こんにちは</p> なら、実際に <p> タグが生成されます。そしてユーザー入力が <img src=x onerror="alert(1)"> だったら……？そのままスクリプトが実行されます。

実際にXSSを起こしてみよう

教材アプリでは「脆弱UI（XSS）」という課題ページがあります。

手順：

• テキストエリアに以下を入力してください。

<img src=x onerror="alert(window.__FLAG_XSS)">

• 下のプレビュー領域が v-html で描画されています。

そこに画像タグが挿入され、onerror 属性が評価されるとアラートが表示されます。ここで表示される window.__FLAG_XSS は教材用のフラグでグローバルな秘密変数を想定しています。実運用ならこのような「グローバルな秘密変数」は致命的です。

攻撃を試してみて何も起きないときは以下を確認してみてください。

• <script> タグは innerHTML 経由では実行されません。イベント属性（onerror / onload）を使ってください
• CSP（Content-Security-Policy）が有効な場合、inline スクリプトがブロックされることがあります
• 要素が正しく挿入されているか、開発者ツールの Elements タブで確認しましょう

対策

• v-html を安易に使わない
• どうしてもHTMLを扱う場合は、ホワイトリスト方式のサニタイズを適用する
• ユーザー入力は常に 「テキスト」として表示 することを原則に

2. Cookieの危険な使い方

続いて、Cookie周りの落とし穴です。

教材の2つ目の課題は「CookieにセッションIDを保存しているが、HttpOnly が設定されていない」例を取り扱います。

document.cookieとは

ブラウザ内でアクセス可能なCookieを読み取るAPIです。

console.log(document.cookie)
// => "sid=demo-session; theme=light"

しかし本来、セッションIDなどの機密情報はサーバー専用で使うべきです。
それをHttpOnly無しで発行すると、XSSを使って誰でも読める状態になります。

Cookieからsidを盗みだす

脆弱版では sid というCookieが HttpOnly: false で発行されています。
そのため、以下のコードで誰でも読み取れます。

<img src=x onerror="alert(document.cookie)">

もしアラートに sid=demo-session と出たら、XSSがCookieを盗み出せたということです。
攻撃者はこの値を使って、別の環境で「なりすましログイン」ができます。

攻撃を試してみてアラートが空だった場合は以下を確認してみてください

• HttpOnly が有効になっている（安全版を開いていないか？）
• オリジンが異なる（5173と3001問題）
• Viteのプロキシ設定でcookieDomainRewriteが漏れている

対策

• セッションIDなどのCookieには必ずHttpOnlyとSecureを付与
• SameSite=Lax 以上を設定してクロスサイト送信を制限する
• 機密情報をフロント側のJSから参照できないように設計する

3. CSRF

次に、CSRF（クロスサイトリクエストフォージェリ）の課題です。

バックエンドの話も入ってしまうんですが、フロントエンドの開発者も知っておくべきだと思うので入れてみました。

ここでは、ユーザーが意図していない送金が実行されてしまう脆弱なAPIを見ます。

CSRFとは？

ユーザーが認証済み状態（Cookieを持っている）で、攻撃者のサイトを開いたとき、そのブラウザが自動的にCookieを添えてリクエストを送ってしまう、これがCSRF攻撃の基本構造です。

情報処理推進機構（IPA）:安全なウェブサイトの作り方 - 1.6 CSRF（クロスサイト・リクエスト・フォージェリ）より引用

意図せず残高を減らす「罠ページ」

教材の「CSRF」課題では、次のようなAPIがあります。

GET /api/csrf/transfer?to=attacker&amount=100

1. /api/wallet を開くと、現在の残高が表示されます（例：1000）
2. 攻撃者ページを開きます（以下を保存してブラウザで開く）：

<html>
  <body>
    <h1>かわいいねこの画像だよ！</h1>
    <img src="http://localhost:5173/api/csrf/transfer?to=attacker&amount=100">
  </body>
</html>

3. ページを開くと自動的にリクエストが発生します
4. /api/walletを再確認すると、残高が減っていることを確認します

※ 教材アプリでは攻撃が成功した際にスコア付与のため、csrfCode が付与されています。それをフォームに入力して提出してください。

対策

1. 副作用のある操作はGETにしない（POST限定）
2. CSRFトークンを導入する

// 発行時
res.cookie('csrfToken', token, { httpOnly: false, sameSite: 'lax' })

// 検証時
if (req.cookies.csrfToken !== req.headers['x-csrf-token']) {
  return res.status(403).json({ error: 'csrf check failed' })
}

3. SameSiteを適切に設定（Lax or Strict）
4. Referer / Origin チェックを補助的にする
5. レート制限で濫用防止(次の章で説明します)

4.（補足） レート制限なし

CSRFやXSSなどの被害を拡大させるのは「無限リクエスト」です。

同一IPやユーザーが短時間に何百回もアクセスできる状態は危険です。

Expressで簡単にレート制限を導入する

以下のようにexpress-rate-limitを設定することで簡単にレート制限を導入できます。

import rateLimit from 'express-rate-limit'

const limiter = rateLimit({
  windowMs: 30_000, // 30秒
  max: 10,
  message: { ok:false, error: 'rate limited' }
})

app.post('/api/transfer', limiter, (req, res) => {
  // 安全な送金処理
})

これだけで「30秒に10回まで」という制限を導入できます。

短いコードですが、セキュリティ上の効果は絶大です。

まとめ

さいごに

Vue.js は便利ですが、安全性を担保する仕組みは「フレームワークまかせ」では不十分です。

「なぜ危ないのか」を一度体験しておくことで、脆弱性への実感を持ってもらえたらうれしいです！

脆弱なアプリを作らないように気をつけながらフロントエンド開発をEnjoyしましょう！

GitHubリポジトリ
vue-ctfs（脆弱版と安全版を含む）

Vue.js連載です。ライトめなネタです。

Next.jsやNuxt.jsなどのサーバーサイドレンダリング必須なフレームワークであれば、Node.jsと一緒にコンテナ化するか、Vercelなどにデプロイする方法があります。こちらはJavaScriptのウェブアプリケーションなので実行環境を用意する必要があります。

一方、SPAとして作成したVue.jsなど、現代のフレームワークで作成したフロントエンドは、ビルドすると静的HTMLとJavaScriptコードになります。ただし、物理的なファイルが存在しないパスへのリクエストがあった場合にindex.htmlの内容をフォールバックとして返す必要があるため、動作させるにはそのあたりが設定可能なウェブサーバーを使う必要があります。index.htmlをロードするとブラウザ上でJavaScriptのコードが動作しますが、そのコードが内部で持っているURLのパス情報をみて適切なページを表示したり、それでも存在なければJavaScriptがエラー画面を出力します。

フューチャー作のガイドラインのWebフロントエンド設計ガイドラインのSPAのホスティングでは、いくつかホスティング方法を紹介しています。

1. CloudFront+S3
2. LB+S3
3. LB+Webサーバー

このうち、LB+S3サーバーはSPAで必要なフォールバックができないのでSPA不可となっていますが、最近、ALBでパスのリライトができるようになったので、拡張子がないパスはindex.htmlにリライトとかやれば実はいけるのでは？という気が少ししていますが、それはまたの機会に試そうと思います。

• classmethodブログ: Application Load Balancer のリスナールールでトランスフォームを構成し、ターゲットにルーティングする前にホストヘッダーや URL パスを書き換えれるようになりました

これ以外には、ウェブアプリケーション側に配信機能を持たせてしまうというのも過去に技術ブログで紹介しました。比較的高速なGoとかRustならこれもありでしょう。

• Go 1.16のembedとchiとSingle Page Application

今回はガイドラインではSPA用によいとしている1. 3のうち、Dockerイメージを作った3番目の方法を全力で試そうと思います。

なぜDockerにするか

S3とかオブジェクトストレージにおいて配信というのがお手軽ですが、コンテナにまとめておくことでデプロイ時にまとめてフロントエンド資材を入れ替えたり、戻したりがしやすいのがメリットと考えています。また、CloudFrontはインターネット公開するサービスには良いのですが、社内システムでは使えません。加えて、ビルド済みフロントエンドを軽量なサーバーで配信すればリソース消費は少なくて済みます。開発時もフロントエンドを触らない人がローカルで動作検証するにはありがたいでしょう。

せっかく作るのであればセキュリティを意識したコンテナを目指します。近年、ランサムウェアが流行っています。静的なHTML/JSでアプリを作りフロントエンドを配信するだけのコンテナにしてバックエンドをプライベートネットワークの後ろ側に隠すことで攻撃面をかなり狭くできます。ですがHTMLなどが買い替えられると不正なプログラムを配る踏み台にされる可能性があるため、そうならないために次の項目にもチャレンジしてみます。

• シェルがないDistroless
• フロントエンドのartifactは読み込み専用で実行ユーザーでは書き換えられない

テスト用アプリケーション作成

Viteの標準的なサンプルです。

% npm create vite@latest
Need to install the following packages:
create-vite@8.0.2
Ok to proceed? (y) y

> npx
> "create-vite"

│
◇  Project name:
│  sample-app
◇  Select a framework:
│  Vue
◇  Select a variant:
│  TypeScript
:

シングルページアプリケーションとして正しく動作することをテストするために、vue-routerを入れてページをいくつか足します。

import { createRouter, createWebHistory } from 'vue-router'
import Home from '../pages/Home.vue'
import About from '../pages/About.vue'
import Products from '../pages/Products.vue'
import ProductDetail from '../pages/ProductDetail.vue'
import Contact from '../pages/Contact.vue'
import NotFound from '../pages/NotFound.vue'

const routes = [
  { path: '/', name: 'Home', component: Home },
  { path: '/about', name: 'About', component: About },
  { path: '/products', name: 'Products', component: Products },
  { path: '/products/:id', name: 'ProductDetail', component: ProductDetail, props: true },
  { path: '/contact', name: 'Contact', component: Contact },
  { path: '/:pathMatch(.*)*', name: 'NotFound', component: NotFound },
]

const router = createRouter({
  history: createWebHistory(),
  routes,
})

export default router

ルーターを組み込みます。

import { createApp } from 'vue'
import './style.css'
import App from './App.vue'
import router from './router'

createApp(App).use(router).mount('#app')

アプリケーションのトップのレイアウト側にはページナビゲーションを起きます。

<script setup lang="ts">
</script>

<template>
  <div id="nav">
    <nav>
      <router-link to="/">Home</router-link>
      |
      <router-link to="/products">Products</router-link>
      |
      <router-link to="/about">About</router-link>
      |
      <router-link to="/contact">Contact</router-link>
    </nav>
  </div>

  <router-view />
</template>

<style scoped>
#nav { margin-bottom: 1.5rem }
nav a { margin: 0 0.5rem; color: #646cff }
nav a.router-link-active { font-weight: 600 }
</style>

ページを適当に作りました。全部紹介する必要性はあまりないと思うので2つだけ紹介します。

<template>
  <div>
    <h1>Home</h1>
    <p>Welcome to the SPA home page.</p>
  </div>
</template>

<script setup lang="ts">
</script>

<style scoped>
h1 { margin-bottom: 1rem }
</style>

<template>
  <div>
    <h1>About</h1>
    <p>This is an example About page for the SPA.</p>
  </div>
</template>

<script setup lang="ts">
</script>

<style scoped>
h1 { margin-bottom: 1rem }
</style>

npm run devで動作させて動いたら次はDockerファイルを作っていきます。

Dockerfile作成

nginxの設定

Vueアプリができたところで次はサーバーです。Rust製のstatic-web-serverとか安全そうだし良さそうだなとも思ったのですが、APIサーバーへのリクエストをプロキシするような設定がなく、今後も入らなそうということもあり見送りました。このプロキシ機能があればウェブフロントエンドとバックエンドが同じドメイン（ポート番号も含めて）動作するので、CORSを機にする必要がなくなります。もちろん、作ったイメージを本番デプロイするだけならALBがやってくれるはずなのでstatic-web-serverでも良いかと思います。ここはありきたりですがnginxにしておきます。なお、今回はイメージサイズは60MBほどになりました。static-web-serverはシングルバイナリで4MBほどらしいので小ささを極めたい場合はstatic-web-serverで試すと良いでしょう。

設定ファイルとしては、SPAで必要なフォールバックを入れたのと、ログは/var/logとかではなく、コンソールに出力するようにしています。

設定ファイル上にuser www-data;と書けばユーザーが設定できます。ただし設定しなくてもワーカーはnobodyユーザーで動作します。最初はセキュリティ強化のためにサーバーは非ルートユーザーで動かすぞ！と設定していたのですが、ワーカーさえルートでなければ実用上は問題ないため、無視底のnobodyで十分だと判断しました。なお、別ユーザーで動かすと、特権ポートの1024以下は使えないため、80番ポートでサーバーを動かすことはできなくなります。

worker_processes  auto;

error_log  /dev/stderr info;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;
    keepalive_timeout  65;

    access_log  /dev/stdout;

    server {
        listen 80;
        server_name  localhost;

        root   /usr/share/nginx/html;

        # /api/ へのリクエストはバックエンドにプロキシするなど、必要に応じて設定を追加
        #location /api/ {
        #    proxy_pass http://backend-host:3000/;
        #    proxy_set_header Host $host;
        #    proxy_set_header X-Real-IP $remote_addr;
        #    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        #    proxy_set_header X-Forwarded-Proto $scheme;
        #}

        # 存在しないファイルへのアクセスを index.html にフォールバック
        location / {
            try_files $uri $uri/ /index.html;
        }

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/share/nginx/html;
        }
    }
}

Dockerfile

Dockerfileは以下の通りです。最初Geminiに雛形をざっと作ってもらいましたが、いろいろ細かいところを後から修正しました。その際に心がけたポイントは以下の通りです。

1. ビルドステージ
   • bindマウント、cacheマウントを駆使してキャッシュフレンドリーな高速ビルド(生成AIはいつもやってくれない)
2. nginxの設定
   • こちらもbindマウント、cacheマウントで効率化
   • 最終イメージのDistrolessはシェルがなくてmkdirとかもできないので、こちらのステージですべての必要なフォルダを作ったり、ユーザーやグループの設定を引っこ抜いたり、ディレクトリの権限を設定したり、nginxの動作に必要ライブラリをコピーしたりも含めて全て行なっています
3. 実行イメージ
   • Debianの新しいバージョンのtrixie(13)が使いたい→まだベータ扱いなのでいったん保留
   • ビルド済みのHTML/JSを持ってきたり、nginxの設定を持ってきたり
   • 実行ユーザー(nobody)から書き換えられないユーザーでHTML/JSを配置

# syntax=docker/dockerfile:1

ARG NODE_VERSION=24.8.0

# ----------------------------------------------------
# ステージ 1: ビルドステージ (Vite SPAのビルド)
# ----------------------------------------------------
FROM node:${NODE_VERSION}-slim AS builder

WORKDIR /app

RUN --mount=type=bind,source=package.json,target=package.json \
    --mount=type=bind,source=package-lock.json,target=package-lock.json \
    --mount=type=cache,target=/root/.npm \
    --mount=type=cache,target=/app/node_modules \
    npm ci

COPY . .
RUN --mount=type=cache,target=/app/node_modules \
    npm run build

# ----------------------------------------------------
# ステージ 2: nginxの実行ファイルとライブラリの取得
# ----------------------------------------------------
FROM debian:bookworm-slim AS nginx-files

RUN --mount=type=cache,target=/var/lib/apt/lists \
    --mount=type=cache,target=/var/cache/apt/archives \
    apt-get update \
    && apt-get install -y --no-install-recommends nginx-light

RUN mkdir -p /tmp/nginx-root/usr/sbin \
    && mkdir -p /tmp/nginx-root/etc \
    && mkdir -p /tmp/nginx-root/usr/share/nginx/html \
    \
    && cp -L /usr/sbin/nginx /tmp/nginx-root/usr/sbin/ \
    && cp -a /etc/nginx /tmp/nginx-root/etc/ \
    && cp -a /etc/passwd /tmp/nginx-root/etc/ \
    && cp -a /etc/group /tmp/nginx-root/etc/ \
    \
    && mkdir -p /tmp/nginx-root/var/lib/nginx/body \
    && mkdir -p /tmp/nginx-root/var/cache/nginx/client_temp \
    && mkdir -p /tmp/nginx-root/var/run \
    \
    && chown -R nobody:nogroup /tmp/nginx-root/var/lib/nginx \
    && chown -R nobody:nogroup /tmp/nginx-root/var/cache/nginx \
    \
    && chmod 775 /tmp/nginx-root/var/lib/nginx/body \
    && chmod 775 /tmp/nginx-root/var/cache/nginx/client_temp \
    && chmod 775 /tmp/nginx-root/var/run

RUN LIBS="$(ldd /usr/sbin/nginx | grep '=>' | awk '{print $3, $5}' | sed 's/not found//g' | sort -u)" \
    && for lib in $LIBS; do \
        if [ -f "$lib" ]; then \
            mkdir -p /tmp/nginx-root$(dirname $lib) && cp -L $lib /tmp/nginx-root/$lib; \
        fi \
    done

# ----------------------------------------------------
# ステージ 3: ランタイムステージ (distroless)
# ----------------------------------------------------
FROM gcr.io/distroless/base-debian12

COPY --from=nginx-files /tmp/nginx-root/ /
COPY nginx.conf /etc/nginx/nginx.conf
COPY --chown=root:root --from=builder /app/dist /usr/share/nginx/html

EXPOSE 80

ENTRYPOINT ["/usr/sbin/nginx", "-g", "daemon off;"]

実行するには次のようにします。

# ビルド
$ docker build -t vue-spa .

# 実行
$ docker run --rm -it -p 8080:80 vue-spa

デバッグ実行

設定を変えてみたい場合のデバッグ方法も紹介しておきます。Distrolessではセキュリティのためにシェルがイメージに含まれていませんが、デバッグ用のイメージが提供されています。

• ランタイムをイメージをgcr.io/distroless/base-debian12からgcr.io/distroless/base-debian12:debugに変更
• docker run --rm -it -p 8080:80 --entrypoint=sh vue-spa で、shをnginxの代わりに実行

まとめ

Dockerfileは新旧の書き方がウェブには混在しているため、機会をみてはbind/cacheを使ったモダンなDockerfileの記法をブログに書くように日頃からしていました。今回はVue連載ということで、Vue製のSPAの静的HTMLのコンテナを作ってみました。単に作るだけでは世の中の有象無象の記事と変わらないので、最新の記法を使ったビルドの効率、実行効率、セキュリティ、どれも妥協しないDockerfileを作りました。Vue以外の方にも参考にしてもらえる記事になったと思います。

明日は松本朝香さんです。

こんにちは、フューチャーアーキテクト株式会社 テクノロジーイノベーショングループ所属の中村立基です。

Vue.js連載ということで、この記事ではVue.jsアプリケーションにチャート分析機能を実装するための、初心者向けの包括的なガイドを提供します。代表的な2つのライブラリ、vue-chartjsとvue-echartsを取り上げ、その概要から具体的な使い方、メリット・デメリット、そして実運用で考慮すべき点を解説していきます。

チャート分析とは

現代のビジネス環境は、かつてないほど膨大なデータに溢れています。しかし、生データの集合体は、それ自体が価値を持つわけではありません。その真価は、データを解釈し、実用的な洞察を引き出すことで初めて発揮されます。このデータ活用の「ラストワンマイル」を担うのが、データ可視化、すなわちチャート分析です。

伝統的に、チャート分析という言葉は金融市場で使われ、過去の価格変動パターンから将来の値動きを予測する手法を指してきました。現代のWebアプリケーションにおけるチャート分析は、「どの製品カテゴリが最も売れているか？」 「直近四半期のユーザーエンゲージメントの傾向は？」といったビジネス上の問いに対して、視覚的に答えを提示します。これにより、ユーザーは数値の羅列からは見出すことのできない傾向、パターン、相関関係、異常値を直感的に発見できるようになります。

専門のアナリストに頼らずとも、現場の担当者が自らの手で日常的な疑問を解決し、データに基づいた行動を起こせるようにすること、それが現代のWebアプリケーションにおけるチャート分析の価値です。

チャート分析のメリット

アプリケーションにチャート分析機能を組み込むことは、単に見た目を良くする以上に下記の様なビジネスにおけるメリットがあります。

• 傾向とパターンの視覚的な把握
  • 生データをグラフなどで視覚化することで、変化に気づきやすい（異常値や新たなトレンドに気が付きやすい）
• 共通認識の醸成と連携強化
  • 同じチャートを利害関係者全員で見ることで、共通認識を持ち円滑にコミュニケーションを取れる

Vueでの利用方法

このセクションでは、vue-chartjsとvue-echartsの導入方法と使い方を、サンプルコードを交えて紹介します。

1. vue-chartjs

vue-chartjsは、JavaScriptのチャートライブラリChart.jsをVueで手軽に利用するためのラッパーライブラリです。標準的なチャートを迅速に実装できるシンプルさが特徴です。

導入方法

vue-chartjsはchart.js本体に依存しているため、両方をインストールする必要があります。これはPeerDependency（仲間依存）と呼ばれる関係性です。

npm install vue-chartjs chart.js

使い方

vue-chartjsを使用する際の重要なポイントは、vue-chartjsからチャートコンポーネント（例：Bar）をインポートするだけでなく、chart.js本体からも必要なモジュール（スケール、要素、ツールチップなど）をインポートし、ChartJS.register()メソッドで登録することです。
（これはChart.jsのTree Shaking（不要なコードをバンドルから除外する仕組み）に対応するための必須のステップであり、つまずきやすい点でもあります。）

以下は、棒グラフを作成する基本的なコンポーネントの例です。

<template>
  <div style="height: 400px;">
    <Bar id="my_chart_id" :options="chartOptions" :data="chartData" />
  </div>
</template>

<script>
import { Bar } from 'vue-chartjs'
import { Chart as ChartJS, Title, Tooltip, Legend, BarElement, CategoryScale, LinearScale } from 'chart.js'

// 必要なモジュールをChart.jsに登録
ChartJS.register(Title, Tooltip, Legend, BarElement, CategoryScale, LinearScale)

export default {
  name: 'BarChart',
  components: { Bar },
  data() {
    return {
      chartData: {
        labels: ['1月', '2月', '3月', '4月', '5月'],
        datasets: [
          {
            label: 'データセット1',
            backgroundColor: '#f87979',
            data: [5, 10, 3, 7, 2]
          }
        ]
      },
      chartOptions: {
        responsive: true,
        maintainAspectRatio: false,
        plugins: {
          title: {
            display: true,
            text: '月別データ'
          }
        }
      }
    }
  }
}
</script>

表示例

データ構造

vue-chartjsのコンポーネントは、主にdataとoptionsという2つのpropsを受け取ります。

• chartDataオブジェクト: チャートに表示するデータを定義します
  • labels: X軸の各項目を表す文字列の配列です (例: [‘1月’, ‘2月’, ‘3月’])
  • datasets: グラフにプロットするデータ系列の配列です。各オブジェクトが1つのデータ系列に対応します
    • label: データ系列の名前（凡例に表示されます）
    • backgroundColor: 棒グラフの色などを指定します
    • data: labelsの各項目に対応する数値の配列です
• chartOptionsオブジェクト: チャートの外観や挙動をカスタマイズするための設定です
  • responsive: trueに設定すると、親要素のサイズ変更に応じてチャートがリサイズされます
  • maintainAspectRatio: falseに設定することが多く、これにより親要素の高さと幅に合わせて柔軟にリサイズできます
  • plugins: タイトル(title)や凡例(legend)、ツールチップ(tooltip)などのプラグインに関する設定をここで行います

2. vue-echarts

vue-echartsは、Apache EChartsをVueで利用するためのラッパーです。EChartsは、非常に多機能でカスタマイズ性が高く、大規模データセットの描画パフォーマンスにも優れたライブラリです。

導入方法

echarts本体とvue-echartsをインストールします。

npm install echarts vue-echarts

使い方：サンプルコード

vue-echartsの最大の特徴は、チャートのすべての設定を単一のoptionオブジェクトに集約して渡す点です。また、バンドルサイズを最適化するために、必要なモジュールのみをインポートしてuse()関数で登録する「オンデマンドインポート」が推奨されています。

以下は、vue-chartjsの例と同じ棒グラフをvue-echartsで作成するサンプルコードです。（Composition APIを使用）

<template>
  <v-chart class="chart"
           :option="chartOption"
           :autoresize="true">
  </v-chart>
</template>

<script setup>
import { use } from 'echarts/core'
import { CanvasRenderer } from 'echarts/renderers'
import { BarChart } from 'echarts/charts'
import {
  TitleComponent,
  TooltipComponent,
  LegendComponent,
  GridComponent
} from 'echarts/components'
import VChart from 'vue-echarts'
import { ref } from 'vue'

// 必要なモジュールを登録
use([
  CanvasRenderer,
  BarChart,
  TitleComponent,
  TooltipComponent,
  LegendComponent,
  GridComponent
])

const chartOption = ref({
  title: {
    text: '月別データ',
    left: 'center'
  },
  tooltip: {
    trigger: 'axis'
  },
  legend: {
    data: ['データセット1'],
    bottom: 10
  },
  grid: {
    left: '3%',
    right: '4%',
    bottom: '10%',
    containLabel: true
  },
  xAxis: {
    type: 'category',
    data: ['1月', '2月', '3月', '4月', '5月']
  },
  yAxis: {
    type: 'value'
  },
  series: [
    {
      name: 'データセット1',
      type: 'bar',
      // eslint-disable-next-line no-magic-numbers
      data: [5, 10, 3, 7, 2]
    }
  ]
})
</script>

<style scoped>
.chart {
  height: 400px;
}
</style>

表示例

データ構造

vue-echartsでは、すべての設定がoptionオブジェクトに集約されます 。

• chartOptionオブジェクト:
  • title: チャートのタイトルに関する設定です (text、leftなど)
  • tooltip: マウスオーバー時に表示されるツールチップの設定です
  • legend: 凡例に関する設定です
  • grid: チャート描画領域のグリッドに関する設定です（位置や余白など）
  • xAxis: X軸に関する設定です (type: ‘category’でカテゴリ軸、dataにラベル配列を指定)
  • yAxis: Y軸に関する設定です (type: ‘value’で数値軸)
  • series: データ系列の配列です。各オブジェクトが1つの系列に対応します
    • name: 系列名
    • type: チャートの種類 (‘bar’, ‘line’など)
    • data: 数値データの配列

チャート表示例

上記で紹介した以外のvue-chartjsで利用できる代表的なチャートは以下です。

※画像は vue-chartjs公式ガイドラインより引用

チャート種別	ユースケース	表示例
折れ線グラフ	・月間売上高の追跡 ・株価の推移 ・Webサイトのトラフィック分析
レーダーチャート	・個人のスキル評価 ・製品の機能比較 ・チームのパフォーマンス分析
円グラフ	・市場シェアの表示 ・予算の内訳 ・アンケートの回答比率
ドーナツチャート	円グラフに主要な数値を強調したい場合
散布図	・広告費と売上の関係分析 ・身長と体重の関係 ・従業員の経験年数と生産性の相関分析
バブルチャート	・プロジェクトのコスト／期間 ・期待収益の比較 ・製品の売上／利益率／市場規模の分析
ポーラーエリアチャート	・月ごとの平均気温 ・時間帯別のウェブサイトトラフィック ・曜日ごとの売上パターン
ミックスチャート	・売上（棒グラフ）と利益率（折れ線グラフ）の同時表示 ・降水量（棒グラフ）と気温（折れ線グラフ）の比較

チャートライブラリ毎のメリット/デメリット

両者の長所と短所を比較します。

ライブラリ利用時の考慮事項

チャート機能を実装するにあたって、堅牢かつユーザーフレンドリーに構築するためには、いくつかの重要な点を考慮する必要があります。

パフォーマンス

• 遅延読み込み (Lazy Loading)
  • 多くのチャートを含むページでは、VueのdefineAsyncComponentを使用してチャートコンポーネントを遅延読み込みすることで、初期バンドルサイズが小さく保たれ、チャートが必要になったときに初めてそのJavaScriptがロードされるため、初期表示速度が向上します。
• リアクティビティの管理
  • 非常に大規模で、かつ変更されることのない静的なデータセットを扱う場合、Vueのデータとして渡す前にObject.freeze()でオブジェクトを凍結させることで、Vueはそのオブジェクトをリアクティブにするためのオーバーヘッドをスキップし、メモリ使用量とCPU負荷を大幅に削減できます。
• アニメーションの無効化
  • リアルタイムでデータが更新されるチャートや、非常に大規模なデータセットを描画する場合、アニメーションを無効にすることで描画パフォーマンスが大幅に向上します。
• データの間引き
  • 500px幅のチャートに10,000点のデータをプロットするなど、ピクセル解像度に対してデータ点が多すぎる場合、描画するデータ点を間引く機能を利用することで、描画負荷を軽減し、パフォーマンスを向上させることができます。

レスポンシブデザイン

canvas要素に描画されるチャートは、CSS要素のように本質的にレスポンシブではありません。その応答性は、親コンテナのサイズに依存します。常にチャートコンポーネントを <div> ような自然言語のプロンプトから、前項までで紹介しで囲み、そのdivに対してCSS（パーセンテージ、Flexbox、Gridなど）でレスポンシブなスタイルを適用することがベストプラクティスです。ライブラリは親コンテナのサイズ変更を検知し、チャートを適切に再描画します。

アクセシビリティ

アクセシビリティは現代のWeb開発において不可欠な要素です。特にチャートの可視化においては、視覚的な情報にアクセスできないユーザーへの配慮が重要になります。

canvas要素の課題

<canvas>要素は、スクリーンリーダーなどの支援技術にとっては「ブラックボックス」であり、そのままでは内容を読み取ることができません。

• vue-chartjsでの対策
  • <canvas> 要素にrole=”img”と、チャートの内容を要約した説明的なaria-labelを付与します。または、 <canvas> タグの内部に、データの表などの代替コンテンツを提供します
  • chartjs-plugin-a11y-legendのようなプラグインを使用して、凡例をキーボードで操作できるようにします
• vue-echartsでの対策
  • EChartsは、より優れたアクセシビリティ機能を標準で備えています。オプションでaria: { show: true }を設定するだけで、EChartsがチャートとその要素に対してインテリジェントに説明的なラベルを生成します

スクリーンリーダー以外の考慮事項

• 色のコントラスト
  • すべてのテキストやデータ系列の色が、WCAG（Web Content Accessibility Guidelines）のコントラスト比の基準を満たしていることを確認します。
• 色のみに依存しない情報伝達
  • 色覚多様性を持つユーザーのために、色だけで情報を伝えないようにします。EChartsがサポートするデカールパターンや、データラベル、凡例などを併用して、データ系列を区別できるように設計します。
• キーボードナビゲーション
  • ツールチップの表示、凡例の切り替え、ズーム操作など、チャートのすべてのインタラクティブな要素がキーボードのみで操作可能であることを保証します。

発展：AIを活用したチャート生成によるデータ分析

本テーマから逸れる為、ここではサンプルコードの紹介等は省略して概要の提示に留めますが、今まで紹介してきたVue.jsにおけるデータ可視化の発展形として、AIを活用したチャート生成が注目されています。

例えば「地域別の月間売上を棒グラフで表示して」のような自然言語のプロンプトから、前項までで紹介したチャートで活用できるデータセットを自動で生成し、vue-chartjsのようなライブラリで描画する手法です。

こういったAI技術を活用することで、自前でデータセットを作成するより効率的に複雑かつ膨大なデータを視覚化し、分析できるようになりました。今後AI技術と組み合わせたライブラリの利用はデータ分析においてより重要性を増していくと考えています。

まとめ

この記事では、Vue.jsでチャート分析を実装するための具体的な手法までを解説しました。vue-chartjsとvue-echartsという2つの代表的なライブラリを取り上げ、それぞれの特徴と使い方をご紹介しました。
ライブラリ利用にあたってはプロジェクトの特性に応じて使い分けることを推奨します。

• vue-chartjsは、シンプルさ、開発の速さ、そして標準的なチャート要件が求められる場合に最適な選択です。プロトタイピングや、基本的なダッシュボード機能の実装に力を発揮します。
• vue-echartsは、複雑な要件、高度なカスタマイズ性、豊かなインタラクティビティ、そして大規模なデータセットを扱う必要がある場合にその真価を発揮します。本格的なデータ分析アプリケーションや、独自のビジュアル表現が求められる場面で適しています。

個人的にですが、昨今爆発的に性能発展が進む生成AI技術によって、新しい洞察やデータ分析のプロセスにおいて、よりデータ可視化の有用性が増してきていると感じており、こういったWebアプリケーションのライブラリと上手く組み合わせることで、プロダクトの価値向上に繋がると思っています。

ぜひ興味を持ってくださった方はチャートを用いたデータ分析にTryしてみてください。

参考文献

• Vue.js 公式ドキュメント
• vue-chartjs 公式ドキュメント
• Chart.js 公式ドキュメント
• vue-echarts GitHubリポジトリ
• Apache ECharts 公式ドキュメント

Vue.js連載の2本目です。

はじめに

こんにちは。TIGでフロントエンドをガリガリやっている小杉山です。

昨今では生成AIを用いたコーディング、Vibe Codingが盛んに行われていますね。人間の代わりに生成AIがコードを書いてくれるというのは非常に魅力的ですが、その過程で生み出されるコードの品質はまだまだ発展途上の段階にあります。

そのため、必要最低限の品質を担保するガードレールとしての役割を果たすテストコード、そしてその自動化の重要性が非常に高まってきています。

今回はVue.js連載ということもあり、Vue.jsで記述されたUIコンポーネントや画面のテスト基盤を構築する選択肢の1つとして、StorybookとVitest Browser Modeを組み合わせたテスト手法を簡単に紹介します。

最近のStorybook

Storybookはフロントエンド開発の生産性を高める素晴らしいツールです。以前はUIコンポーネントを一覧表示する「コンポーネントカタログ」としての利用が主流でした。

しかし、近年のStorybookはテスト関連の機能を大幅に強化しています。その中心的な機能の1つが、今回紹介するVitestとの連携です。この連携により、フロントエンド開発において信頼性の高いテストを効率よく進めていくことが可能になりました。

この「信頼性の高いテスト」を実現するための重要な要素の1つが、後述するVitest Browser Modeです。

Vitest Browser Mode

従来JestやVitestを使用してフロントエンドのテストをする際、DOMに関してはjsdomやhappy-domを使用することで擬似的なブラウザ環境を再現していました。

しかしあくまで「擬似的な」ブラウザ環境なので、windowオブジェクトやResizeObserverなどのブラウザAPIはモックした上でテストしなければなりませんでした。

そんな時、VitestにBrowser Mode (Vitest Browser Mode)という機能が実装されました。

この機能によりテストコードの実行環境が擬似ブラウザ環境から（ユーザが使用する）ChromeやFirefoxといった実際のブラウザそのものに置き換わるので、より信頼性の高いテストが実施できます。

検証コード

テスト対象のUI、Storyファイル、そしてテストコードをざっくりと見ていきます。

リポジトリ

検証コードはこちらのGitHubリポジトリにあります。

https://github.com/koralle/mock-webapp-with-vue-for-writing-article

Vueコンポーネント

今回はテスト対象の画面として、以下の依存関係で構成される非常に簡易的なログイン画面を用意しました。
メールアドレスとパスワードを入力して「ログイン」ボタンを押下すると、ログインフォームの下部に「ログインに成功しました。」というメッセージを表示します。

<script setup lang="ts">
import * as z from 'zod';
import Button from '../components/Button.vue';
import Input from '../components/Input.vue';
import { useForm } from 'vee-validate';
import { toTypedSchema } from '@vee-validate/zod';
import { ref, useId } from 'vue';

const hasCompletedSubmit = ref(false);

const loginSchema = z.object({
  email: z.email('有効なメールアドレスを入力してください。'),
  password: z
    .string('パスワードは必須です。')
    .max(128, 'パスワードは128文字以内で入力してください。')
    .regex(/^[a-zA-Z0-9]+$/, 'パスワードは半角英数字で入力してください。')
});

const { defineField, errors, handleSubmit } = useForm({
  validationSchema: toTypedSchema(loginSchema)
});

const [email, emailAttrs] = defineField('email');
const [password, passwordAttrs] = defineField('password');

const onSubmit = handleSubmit(() => {
  hasCompletedSubmit.value = true;
});

const emailId = useId();
const passwordId = useId();
</script>

<template>
  <form
    class="grid gap-10"
    @submit="onSubmit"
  >
    <fieldset class="grid gap-6">
      <label
        :for="emailId"
        class="grid gap-1"
      >
        <span>メールアドレス</span>
        <Input
          :id="emailId"
          name="email"
          required
          :invalid="Boolean(errors.email)"
          autocomplete="email"
          v-model="email"
          v-bind="emailAttrs"
        />
        <p class="text-red-500">{{ errors.email }}</p>
      </label>

      <label
        :for="passwordId"
        class="grid gap-1"
      >
        <span>パスワード</span>
        <Input
          :id="passwordId"
          name="password"
          required
          type="password"
          :invalid="Boolean(errors.password)"
          autocomplete="current-password"
          v-model="password"
          v-bind="passwordAttrs"
        />
        <p class="text-red-500">{{ errors.password }}</p>
      </label>
    </fieldset>

    <Button label="ログイン" />
  </form>

  <p
    v-if="hasCompletedSubmit"
    class="font-bold"
  >
    ログインに成功しました。
  </p>
</template>

Storyファイル

先述のログイン画面をStorybook上で管理するためのStoryファイルはこちらです。

import type { Meta, StoryObj } from '@storybook/vue3-vite';
import { expect, within, userEvent } from 'storybook/test';

import LoginPage from '../pages/LoginPage.vue';

const meta = {
  title: '画面 / ログイン画面',
  component: LoginPage
} satisfies Meta<typeof LoginPage>;

export default meta;
type Story = StoryObj<typeof meta>;

export const InitialState = {
  name: '初期表示'
} satisfies Story;

export const LoginCompleted = {
  name: 'ログイン成功',
  play: async ({ canvasElement, step }) => {
    const canvas = within(canvasElement);

    await step('メールアドレスを入力する', async () => {
      const emailInput = await canvas.findByRole('textbox', { name: 'メールアドレス' });
      await userEvent.type(emailInput, 'frontend@example.com', { delay: 100 });
    });

    await step('パスワードを入力する', async () => {
      const passwordInput = await canvas.findByLabelText('パスワード');
      await userEvent.type(passwordInput, 'password', { delay: 100 });
    });

    await step('「ログイン」ボタンをクリックする', async () => {
      const submitButton = await canvas.findByRole('button', { name: 'ログイン' });
      await userEvent.click(submitButton);
    });
  }
} satisfies Story;

「ログイン成功（LoginCompleted）」というStoryは文字通り「正常にログインが完了できる」というユーザシナリオを想定しており、そのユーザシナリオに沿った画面操作をPlay Functionで記述しています。

Storybookを起動すると以下の画像のようになります。

「ログイン成功（LoginCompleted）」のStoryを開くと以下の画面操作が自動で実行され、ログイン後の画面状態を確認できます。

1. メールアドレスの入力
2. パスワードの入力
3. 「ログイン」ボタンの押下

Storybook + Vitest Browser ModeでVueのテストを書いてみよう

先述の「ユーザが正常にログインが完了できるシナリオ」を、StorybookとVitest Browser Modeを使ってテストしてみます。

テストコードは以下の手順となるように書きます。

1. Storyファイルに定義したPlay FunctionをVitestのテストコード上で再利用し、ブラウザ上でユーザ操作する
2. 手順1の結果として得られるDOMの状態を検証する

Storyオブジェクトのrun()メソッドを実行することで、Play Functionに記述した画面操作がブラウザ上で自動的に実行されます。これが手順1です。

手順2では、Vitest Browser ModeのAPIを用いて画面操作後のDOM状態を検証します。

これを実現するVitestのテストコードがこちらです。

import { composeStories } from '@storybook/vue3-vite';
import { page } from '@vitest/browser/context';

import * as LoginPageStories from '../stories/LoginPage.stories';

const composedStories = composeStories(LoginPageStories);

describe('LoginPage', () => {
  describe('`ログイン成功`Storyに対するテスト', () => {
    const { LoginCompleted } = composedStories;

    test('ログインに成功すること', async () => {
      // ログイン操作の実行
      await LoginCompleted.run();

      // ログイン操作の実行結果を検証する
      const completedMessage = page.getByText('ログインに成功しました。');
      await expect.element(completedMessage).toBeVisible();
    });
  });
});

あとはターミナル上でnpx vitestを実行することでテストを実行できます。

まとめ

今回紹介したテスト手法の採用には以下のようなメリットがあります。

• jsdomやhappy-domを利用した擬似ブラウザ環境の代わりに実際のブラウザでテストを実行するため、より本番に近い環境でコンポーネントの動作を検証できる
• StorybookのPlay Functionで定義したユーザシナリオをそのままテストコードとして再利用できるため、テスト実装の効率が大幅に向上する

ただし、前述の通りVitest Browser Modeはまだ実験的な機能です。

導入の際はその点を考慮し、動作確認をしながら慎重に進めてください。

Vue.js連載の1本目です。

はじめに

私は普段Reactを触ることが多く、フォーム開発ではreact-hook-form + zod(+ shadcn/ui)の組み合わせでの開発をよく行なっていました。

今回Vueでプロジェクトを進めるにあたり、vee-validateを使ってフォーム開発を行ないました。コンポーネントやZodとの組み合わせに試行錯誤したことに加え、アクセシビリティ対応にも力を入れたので、そこで得た知見を共有いたします。

ここで紹介する内容を理解すれば、ほとんどのフォーム実装に対応できるはずです。 より複雑なケースでも、この記事の内容を組み合わせたり派生させることで実現できると思います。ぜひ参考にしてみてください！

また、以下にサンプルとなるリポジトリを用意しましたので、こちらもご参照ください。

https://github.com/hasehiro0828/sample-vue-form

技術スタック概要

vee-validate

https://vee-validate.logaretm.com/v4/

Vue.js向けのフォームライブラリです。Zodなどとの統合が容易で、Composition APIとの親和性も高いです。

Reactの場合はフォームライブラリにいくつか選択肢がある印象ですが、Vueの場合は基本的にvee-validateを使うことになりそうです（2025年10月時点）。

Zod

https://zod.dev/

TypeScript-firstなスキーマ定義ライブラリです。型安全性を担保しながらランタイムバリデーションを実現でき、フレームワークによらず同じように利用できます。

vue-query

https://tanstack.com/query/latest/docs/framework/vue/overview

サーバーステートの管理を行なうライブラリで、Tanstack QueryのVue版です。実践的なアプリケーションを見据えて導入しましたが、今回のメイン要素ではないので詳細は割愛します。

shadcn-vue

https://www.shadcn-vue.com/

Tailwind CSSベースのUIコンポーネント集で、Reactのshadcn/uiのVue版です。こちらも今回のメイン要素ではないので詳細は割愛します。

取得したデータを watch で resetForm することで、フォームの初期値を設定します。

アクセシビリティ対応

今回のプロジェクトではアクセシビリティ対応にも力を入れました。デジタル庁のデザインシステムを参考に、日付入力の実装やボタン要素の扱い（disabled属性を利用しない）など、アクセシビリティの観点から工夫を行なっています。

本記事ではとくに試行錯誤した日付入力の実装について後述します。

vee-validateの基本方針

vee-validateはさまざまなコンポーネントやAPIを提供してくれています。それらを利用するにあたり、利用するもの・利用しないものの基本方針を明確にしておくことで、チーム開発での一貫性を保ち、実装の迷いを減らすことができます。
今回は以下のような基本方針を設けて実装を行ないました。

利用するもの

• Fieldコンポーネント
  • 単一のフォームフィールドを扱う際の基本となるコンポーネント
  • v-slotでfield、meta、errorMessageを受け取り、入力欄とバリデーション結果を紐づけ
  • <script>内でフィールドの値を直接操作する必要がない場合に使用
• ErrorMessageコンポーネント
  • フォーム全体やグループ全体に対するエラーメッセージの表示に利用
  • 相関チェックの結果を親要素に設定するようなバリデーションエラーの表示などに適している（例: 日付の存在チェックなど）
• useFieldArray
  • 動的に追加・削除可能な配列形式のフィールドを管理するComposable関数
  • fields、push、removeなどの関数を提供し、配列形式のフィールドの操作を行なえる
  • FieldArrayコンポーネントではなくこちらを使用する理由は、pushやremoveなどの操作を<script>内で柔軟に扱えるため
• useForm
  • フォーム全体の状態管理を行なうComposable関数
  • バリデーションスキーマの設定、送信処理、フォームの値やエラー状態の取得などを行なう
• useField
  • 複数の入力欄を持つフォーム機能を統合したカスタムコンポーネントを作成する際に使用
  • 基本的にはFieldコンポーネントを使用する方がシンプルだが、複数のinputを持つカスタムコンポーネントを作成するような場合はuseFieldでそれぞれのフィールドを個別に定義する方が見通しが良くなる

利用しないもの

• FieldArrayコンポーネント
  • 配列の操作（追加・削除）を<script>内で行なうケースが多く、useFieldArrayの方が柔軟性が高い
• defineField from useForm
  • meta（touched、dirtyなど）が使えない？みたいなので利用用途がわからず・・
  • useFieldを使って正しく動作したので利用しなくて良さそう・・？

具体的な実装例

以降では、上記の基本方針に基づいた具体的な実装例を紹介していきます。

Fieldを使った基本的な入力

<Field v-slot="{ field, meta, errorMessage }" name="name">
  <div class="flex flex-col gap-2">
    <label :for="nameId">
      名前
      <span class="text-red-600 bg-red-100 px-1 py-0.5 rounded-md text-xs ml-1">必須</span>
    </label>
    <Input
      :id="nameId"
      :model-value="field.value"
      type="text"
      :aria-invalid="shouldShowError(submitCount, meta)"
      @update:model-value="field.onChange"
      @blur="field.onBlur"
    />
    <p v-if="shouldShowError(submitCount, meta)" class="text-sm text-red-600">
      {{ errorMessage }}
    </p>
  </div>
</Field>

シンプルな単一フィールドです。
テキスト入力やテキストエリア、セレクトボックスなど、1つの入力欄で完結するフィールドに使用します。

ポイント:

• field.valueで現在の値を取得
• field.onChangeで値の変更を検知
• field.onBlurでフォーカスが外れたことを検知
• shouldShowErrorでバリデーションエラーを表示するかを判定
• errorMessageでバリデーションエラーメッセージを取得

これらは以降のフォーム実装でも同様です。

useFieldArrayを使った配列管理

<script setup>
const { fields, remove, push } = useFieldArray("conditions");

const addCondition = () => {
  push({
    // 初期値
  });
};
</script>

<template>
  <div v-for="(condition, idx) in fields" :key="condition.key">
    <!-- ネストした配列は別コンポーネントで管理 -->
    <ConditionalParams :index="idx" />
    <Button @click="() => remove(idx)">削除</Button>
  </div>
</template>

動的に追加・削除可能なフィールドです。
ユーザー操作で追加・削除できるような入力に使用します。

ポイント:

• pushで配列に新しい要素を追加
• removeで指定したインデックスの要素を削除
• v-forのkeyには{array}.key（インデックスではなくkey）を使用

ネストした配列要素はコンポーネント分離する

配列の中に配列があるような場合には、ネストされる配列を別コンポーネントに分離すると扱いやすくなります。
サンプルでは以下のような構造にしています。

conditions（配列）← NestForm.vue で管理
  └── params（配列）← ConditionalParams.vue で管理

親コンポーネント（NestForm.vue）

<script setup>
// 外側の配列を管理
const { fields: conditionFields, remove, push } = useFieldArray("conditions");
</script>

<template>
  <div v-for="(condition, conditionIdx) in conditionFields" :key="condition.key">
    <div class="mb-2">
      <div class="font-bold">{{ condition.value.readonly.title }}</div>
      <div class="text-gray-500 text-sm">{{ condition.value.readonly.description }}</div>
    </div>
    <!-- ネストした配列の管理は子コンポーネントで行う -->
    <ConditionalParams :index="conditionIdx" />
    <Button @click="() => remove(conditionIdx)">条件を削除</Button>
  </div>
</template>

子コンポーネント（ConditionalParams.vue）

<script setup>
const props = defineProps<{ index: number }>();

// 親から受け取ったindexを使ってパスを構築
const paramKey = computed(() => `conditions[${String(props.index)}].params`);

const { fields: params, remove, push } = useFieldArray<Param>(paramKey.value);

const handleAddParam = () => {
  push({
    type: "text",
    value: { text: "" },
    required: true,
    readonly: { title: "", description: "" }
  });
};
</script>

<template>
  <div v-for="(param, paramIdx) in params" :key="param.key">
    <!-- paramの内容を表示/編集 -->
    <template v-if="param.value.type === 'text'">
      <Field :name="`${paramKey}[${paramIdx}].value.text`" v-slot="{ field }">
        <Input v-model="field.value" />
      </Field>
    </template>
    <Button @click="() => remove(paramIdx)">パラメータ削除</Button>
  </div>
  <Button @click="handleAddParam">パラメータを追加</Button>
</template>

この設計のメリット:

• useFieldArrayを使用する際にパス名が必要だが、コンポーネント分離することでindexを渡すことが可能に
• ネストが深くなっても各コンポーネントは自分が管理する要素だけを見ればいいので、コードが読みやすくなる

この構成は3階層以上の深いネストにも応用できます。各階層をコンポーネントに分離することで個々のコンポーネントの複雑性を増すことなく、複雑なフォームでも保守性の高いコードを維持できます。

ちなみに・・・
nameの値は hoge[index] の形式と hoge.index の形式のどちらでも可能なようです。ただ、errorsから値を取得する際には hoge[index]の形式で取得する必要があるため、基本的には hoge[index] の形式で指定するのが良さそうです。

useFieldを使ったカスタムコンポーネント

<script setup>
const props = defineProps<{
  namePrefix: string;
  type: "date" | "month" | "year";
}>();

// 個別のフィールドを定義
const yearField = useField<string>(`${props.namePrefix}.year`);
const monthField = useField<string>(`${props.namePrefix}.month`);
const dayField = useField<string>(`${props.namePrefix}.day`);

// フォーム全体のエラーを取得
const { errors } = useFormContext();

const rootErrorMessage = computed(() => errors.value[props.namePrefix]);
</script>

<template>
  <AppDateInput
    :year="yearField.value.value"
    :month="monthField.value.value"
    :day="dayField.value.value"
    @blur:year="yearField.handleBlur"
    @blur:month="monthField.handleBlur"
    @blur:day="dayField.handleBlur"
  />
</template>

複数の入力欄で1つのコンポーネントとするような場合に使用します。
とくに、日付入力（年・月・日）のように、個別のフィールドでもバリデーションが必要かつ全体としてもバリデーションが必要な場合に適しています。

ポイント:

• 各フィールドを個別にuseFieldで定義することで、年・月・日それぞれのバリデーションが可能
• useFormContextでフォーム全体のエラー情報を取得し、親要素のエラー（例:「年月日をすべて入力してください」）を取得
  • （useFieldでルートの要素を定義すると上手く動作しなかったのでこの形に）
• カスタムコンポーネント内で複数フィールドを統合し、外部からは1つのコンポーネントとして扱えるように

エラー表示のタイミング

export const submittedOrTouchedAndDirty = (submitCount: number, meta: { touched: boolean; dirty: boolean }) => {
  return submitCount > 0 || (meta.touched && meta.dirty);
};

export const shouldShowError = (submitCount: number, meta: { touched: boolean; dirty: boolean; valid: boolean }) => {
  return submittedOrTouchedAndDirty(submitCount, meta) && !meta.valid;
};

エラー表示の条件は meta.valid 以外にも以下のような条件を設けています。

• touched && dirty: フィールドにフォーカスを当て（touched）、かつ値を変更した（dirty）後にエラーを表示
• submitCount > 0: 送信ボタンを押した後は、すべてのフィールドのエラーを表示
  • エラーがなくなるまでボタンをdisabledにする実装も考えられるが、アクセシビリティを考慮しdisabledを使用しない形にしている
  • その場合touched && dirty のみだとsubmitしてもエラーが表示されないため、この条件を追加

以上のようにすることで、ユーザーが何も操作していない状態でエラーが表示されることや入力中にエラーが表示されてしまうことを避けられます。また、送信ボタンを押した際にはすべてのフィールドのエラーが表示されます。

Zodスキーマ設計

typeフィールドによる分岐

今回、配列形式かつ種類の違うフィールドを動的に管理する必要がありました。これを解決するために、typeフィールドによるスキーマの分岐を行なっています。こうすることで、画面表示の分岐を自動的に行ないつつ型安全にデータを扱えるようになります。

以下のようにbaseのスキーマを拡張しtypeで分岐させるように実装しています。

const baseParamSchema = z.object({
  required: z.boolean(),
  type: z.unknown(), // 各サブスキーマで具体的な型に
  value: z.unknown(), // 各サブスキーマで具体的な型に
  readonly: z.object({
    // フォームで入力しない値
    title: z.string(),
    description: z.string(),
  }),
});

const textParamSchema = baseParamSchema.extend({
  type: z.literal("text"), // 👈 typeで分岐
  value: z.object({
    text: z.string(),
  }),
});

const dateParamSchema = baseParamSchema.extend({
  type: z.literal("date"), // 👈 typeで分岐
  value: zodDateValue,
});

// Union型で統合
export const paramSchema = z.union([
  textParamSchema,
  dateParamSchema,
  monthParamSchema,
  yearParamSchema,
  dateRangeParamSchema,
  monthRangeParamSchema,
  yearRangeParamSchema,
]);

コンポーネント側では以下のように利用します。

<template v-if="param.value.type === 'text'">
  <!-- param.value.value.text が型安全にアクセス可能 -->
  <Input v-model="param.value.value.text" />
</template>

<template v-else-if="param.value.type === 'date'">
  <DateInputField :name-prefix="`${paramKey}[${paramIdx}].value`" />
</template>

readonlyフィールド（フォームで入力しない値）の活用

フォームでは入力しない値もスキーマに含めて定義することにしています。

readonly: z.object({
  title: z.string(),        // フィールドのラベル
  description: z.string(),  // フィールドの説明
}),

この構成にしておくと、フォームデータと表示用データを1つのオブジェクトで管理できます。とくに配列操作において恩恵が大きく、追加・削除する際に表示情報も一緒に管理でき、画面表示やAPI送信時のデータの扱いが楽になります。
一緒に管理しない場合、フォームの入力とAPIから取得したデータを突き合わせる必要が出てきてしまうのでこのようにしました。

// 配列に要素を追加する際、表示情報も一緒に管理
const handleAddParam = () => {
  push({
    type: "text",
    value: { text: "" },
    required: true,
    readonly: {
      title: "新しいフィールド",
      description: "説明文",
    },
  });
};