Argano の江川です。
前書き
最近、AI がアプリケーションに組み込まれるのが当たり前のようになっていると思います。
業務で利用するアプリから、業務外で普段使いするアプリまで AI が目玉の機能になっていたり、前面に出ていなくても裏側のどこかで利用しているというケースはかなり増えてきていると感じてます。
AI がアプリに組み込まれやすいように各サービス提供者は様々なアプリ、サービスをリリースしてます。
私が直近で見たものだと、AWS では Lambda Durable Functionsという複数ステップの処理で便利なオーケストレーションとステップの管理がしやすくなるサービスをリリースしていたり、Vercel でも AI 開発向けのツール Workflow DevKit をリリースしてました。
そういった中で Vercel の Workflow Devkit では JS ファイルに use workflow を記述しているところが目に留まりました。JS ファイルに書く use XXX (以降 use ディレクティブと呼びます)では use strict 始め、React(特に Next.js)を触っている人なら目にする use client などがあると思います。
今後 use ディレクティブは増えていくのかな、と思いつつ現時点で use ディレクティブはどの程度あり、どんな使われ方をしているのかというのが気になりました。
ということで今回の記事では 2025 年末時点で、JavaScript で利用される use ディレクティブについてまとめます 🎄
use ディレクティブまとめ
use strict
use strictは JavaScript で最も歴史のあるディレクティブです。
ファイルや関数の先頭に記述することで、JavaScript をより安全で厳格な strict モードで実行できます。(逆に use strict ではない時には Sloppy モードと呼ぶらしいですが公式的な呼び方ではないそうです。)
歴史的背景
use strictは ES5(ECMAScript 5、2009 年)で導入されました。
JavaScript 初期には、暗黙のグローバル変数や予期しない動作を引き起こす仕様が多く存在していました。
しかし、後方互換性を保つためにこれらの仕様を直接変更することはできません。
そこで、"use strict"と明示的に宣言することで、より厳格で安全なルールを適用する strict モードという仕組みが導入されました。
strict モードの主な効果
strict モードでは、暗黙のグローバル変数の禁止など様々な制限を受け安全性を高めてます。
例えば一番わかりやすい例だと
// 非strictモード
function nonStrict() {
x = 10; // グローバル変数が暗黙的に作成される
console.log(x); // 10
}
// strictモード
function strict() {
"use strict";
x = 10; // ReferenceError: x is not defined
}
があるかなと思います。
その他の制約だと以下などあります
- this の挙動変更: 関数内の
thisがグローバルオブジェクトではなくundefinedになる - 重複パラメータ名の禁止:
function foo(a, a) {}がエラー - 削除不可プロパティの削除禁止:
delete Object.prototypeがエラー - 8 進数リテラルの禁止:
0123のような表記がエラー
モダン JS との関係
React や Vue.js から JavaScript を学び始めた人や主に書いている人にとって “use strict"を書く機会は減ってきていると思います。
その理由としては、ES modules(ESM)では自動的に strict モードが有効になるからです。
// ES moduleでは"use strict"不要
import { something } from "./module.js";
// すでにstrictモード
x = 10; // ReferenceError: x is not defined
ただし、<script>タグで直接読み込む従来型の JavaScript では、今でも"use strict"を明示的に記述することがあるので HTML に JavaScript を書くときがあれば目にするんじゃないかなと思います。
use asm
use asmは asm.js で使われるディレクティブです。
関数の先頭に記述することで、その関数が asm.js のコードであることを JavaScript エンジンに伝え、最適化を促します。
概要
asm.js は JavaScript のサブセットで、型付けが一貫したコードを事前コンパイル(AOT)して高速に実行することを目的としています。
主に Emscripten などのコンパイラが C/C++コードを JavaScript に変換する際のターゲットとして使われました。
function MyAsmModule() {
"use asm";
function add(x, y) {
x = x | 0; // int型であることを示す
y = y | 0;
return (x + y) | 0;
}
return { add: add };
}
現在では WebAssembly に置き換えられており、新規プロジェクトで使われることはほぼないそうです。
参考: asm.js - Wikipedia, human-asmjs - GitHub, Why WebAssembly is Faster Than asm.js - Mozilla Hacks
use client
use clientは React Server Components(RSC)で使われるディレクティブです。
ファイルの先頭に記述することで、そのコンポーネントがクライアントサイドで実行されることを明示します。
背景
React Server Components(RSC)の導入により、React コンポーネントはデフォルトでサーバーサイドで実行されるようになりました。
Next.js では 13(2022 年 10 月リリース)の App Router から本格的に採用されています。
サーバーコンポーネントは軽量で高速ですが、useStateやuseEffectなどのクライアントサイドの機能は使えません。
インタラクティブな機能が必要な場合にuse clientを使ってクライアントコンポーネントとして明示します。
使い方
"use client";
import { useState } from "react";
export function Counter() {
const [count, setCount] = useState(0);
return <button onClick={() => setCount(count + 1)}>Count: {count}</button>;
}
use clientが必要なケース:
useState,useEffectなどの React Hooks を使うonClickなどのイベントハンドラを使う- ブラウザ API を使う(
window,documentなど)
逆にデータ取得だけのコンポーネントなどは、サーバーコンポーネントのまま(use clientなし)で問題ありません。
参考: React 公式ドキュメント - ‘use client’
use server
use serverは React Server Actions で使われるディレクティブです。
関数やファイルの先頭に記述することで、その関数がサーバーサイドでのみ実行されることを保証します。
背景
Server Actions は、React 18 で実験的に導入され、Next.js 13.4(2023 年 5 月)で安定版がリリースされました。
従来、フォーム送信やデータ更新などのサーバーサイド処理には API ルートを作成する必要がありましたが、Server Actions を使うことでコンポーネント内から直接サーバーサイドの処理を呼び出せるようになりました。
使い方
関数単位で指定する場合:
export default function Form() {
async function createUser(formData) {
"use server";
// サーバーサイドでのみ実行される
const name = formData.get("name");
await db.users.create({ name });
}
return (
<form action={createUser}>
<input name="name" />
<button type="submit">作成</button>
</form>
);
}
ファイル全体で指定する場合:
"use server";
export async function createUser(formData) {
// このファイルの全関数がServer Actionになる
await db.users.create({ name: formData.get("name") });
}
Server Actions は、データベースアクセスや API キーを使った処理など、クライアントに公開したくない処理をサーバーサイドで安全に実行できます。
名前の変更について
React 19(2024 年 9 月)から、公式ドキュメントではServer ActionsではなくServer Functionsという名前に変更されました。
参考: GitHub PR #7180
変更理由は、用語をより正確にするためだそうです:
- Server Functions:
"use server"でマークされたすべての関数 - Server Actions: Server Functions の中でも、action プロップに渡されたり action 内で呼ばれるもののみ
つまり、すべての Server Functions が Server Actions ではなく、Server Actions は Server Functions のサブセットという位置づけです。
ただし、Next.js のドキュメントなどでは引き続き「Server Actions」という用語も使われているため、両方の用語を見かけることがあります。
参考: React 公式ドキュメント - ‘use server’, React 公式ドキュメント - Server Functions, GitHub PR #7180
use memo
use memoは React Compiler による最適化をオプトインするディレクティブです。
関数の先頭に記述することで、その関数を React Compiler が最適化対象として処理します。
背景
React 19 から導入された React Compiler は、ビルド時にコードを分析して自動的にメモ化などの最適化を適用します。use memoは、コンパイラが通常スキップするようなケースでも明示的に最適化を適用したい場合に使用します。
使い方
function ExpensiveComponent() {
"use memo";
// この関数は React Compiler により最適化される
const result = heavyCalculation();
return <div>{result}</div>;
}
対となるディレクティブとしてuse no memoもあり、こちらは逆に最適化を防ぎます。
use no memo
use no memoは React Compiler による最適化を防ぐディレクティブです。use memoとは逆に、関数の先頭に記述することで React Compiler がその関数をスキップするよう指示します。
使い方
function MyComponent() {
"use no memo";
// この関数は React Compiler による最適化をスキップ
return <div>...</div>;
}
主な使用場面:
- コンパイラの最適化が問題を引き起こしていないかデバッグする場合
- サードパーティライブラリとの互換性問題がある場合
参考: React 公式ドキュメント - use no memo
use cache
use cacheは Next.js 16 で導入されたキャッシュディレクティブです。
関数の先頭に記述することで、その関数の実行結果をビルド時にキャッシュし、全ユーザーで共有できるようにします。
利用ケース
従来の静的生成(SSG)に最も近い動作を実現するディレクティブです。
ブログ記事一覧のように、ビルド時に取得して全ユーザーで同じデータを共有できる場合に使用します。
使い方
async function getBlogPosts() {
"use cache";
const posts = await fetch("https://blog.example.com/api/posts");
return posts;
}
ビルド時に実行され、サーバーサイドでキャッシュが保存されます。
注意点として、cookies()やheaders()などユーザー固有の情報は使用できません。
なお、use cacheには以下のバリエーションもあります:
use cache: remote- 動的コンテキストで全ユーザー共有のデータをキャッシュ(商品価格など)use cache: private- ユーザーごとに異なるデータをキャッシュ(おすすめ商品、カート情報など)
参考: Next.js 16 で追加された use cache の基礎知識 - Zenn
use workflow
冒頭であげた Vercel の Workflow Development Kit(2025 年 10 月公開ベータ)で使われているディレクティブです。
関数の先頭に記述することで、その関数を永続的なワークフロー(durable workflow)として定義します。
特徴
use workflowでマークされた関数は以下の特性を持ちます:
- 一時停止と再開: 処理を数分から数ヶ月間一時停止し、後で再開できる
- 耐久性: デプロイやクラッシュを生き延び、中断した場所から正確に再開
- シンプル: キューやスケジューラ、YAML の手動配線が不要
複数ステップを要する処理の大元となり、後述するuse stepを管理するオーケストレーターとして振る舞います。
import { sleep } from "workflow";
import { sendEmail, recordToDb } from "./tasks";
export async function welcomeWorkflow(userId: string, email: string) {
"use workflow"; // ワークフローのエントリポイントであることを宣言
// 1. ユーザーをDBに登録(stepを呼び出す)
await recordToDb(userId);
// 2. 最初のメールを送信(stepを呼び出す)
await sendEmail(email, "登録ありがとうございます!");
// 3. 3日間待機(Vercelが実行状態を保存し、サーバーを止める)
await sleep("3 days");
// 4. フォローアップ(再開後、次のstepを実行)
await sendEmail(email, "使い心地はいかがですか?");
}
参考: Built-in durability: Introducing Workflow Development Kit - Vercel, Vercel、AI 開発向けの新ツール「Workflow DevKit」を発表, Vercel Workflow Docs
use step
use stepは Vercel の Workflow Development Kit で使われるディレクティブです。
関数の先頭に記述することで、その関数をワークフロー内のステップとしてマークします。
特徴
use stepでマークされた関数は以下の特性を持ちます:
- 自動リトライ: 一時的な失敗時に自動的に再試行される
- 進捗の永続化: 各ステップの進捗が自動的に保存される
- チェックポイント: デプロイやサーバー再起動、失敗を跨いで状態を維持
- 独立実行: 各ステップが独立して実行され、失敗したステップのみ再実行
use workflowと組み合わせることで、通常の async/await コードを書きながら、ワークフローを構築できます。
export async function sendEmail(to: string, body: string) {
"use step";
const response = await fetch("https://api.email-service.com/send", {
method: "POST",
body: JSON.stringify({ to, body }),
});
return { sent: true };
}
冒頭で触れた AI 開発の文脈では、LLM の呼び出しやベクトル DB へのクエリなど、時間がかかる外部処理を各ステップとして定義し利用します。
参考: Understanding Directives - Workflow DevKit
こういう意見もある
TanStack の Tanner Linsley 氏は、use clientやuse serverなどのディレクティブが言語機能のように見えるが実際はフレームワーク特有のものであり、標準化されていない点を問題視しています。
ディレクティブではなく、明示的な API(インポート)を使うべきで、もし共通の仕組みが必要ならフレームワーク間で協力して TC39 に標準化を提案すべき、という意見もあるそうでした。
参考: Directives and the Platform Boundary | TanStack Blog
ということで 2025 年末時点で JavaScript で利用できる use ディレクティブについてまとめました。
最初に見た AI の話から結構外れてしまいましたが use ディレクティブは今こんなのあるんだな〜と見ていただけたと思います。
個人的には React,Vercel のものは便利かなと思いつつ、ブラックボックスな感じが強いと思うのであまり複雑なものは増えてほしくないなと思いました。
おわり 🎅
