🪝

【React】「とりあえず切り出す」をやめる - カスタムフック設計で大事なこと

haruten

2025/10/13に公開

React

TypeScript

tech

こんにちは!

株式会社Sally エンジニアの haruten です♪
私たち株式会社Sallyでは、マーダーミステリーをスマホやPCで遊べるアプリ「ウズ」や、マーダーミステリーを制作してウズ上で公開・プレイできるエディターツール「ウズスタジオ」などを開発・運営しています。

https://sally-inc.jp/
今回はReactのカスタムフックの設計について学び直す機会があったので、その備忘録です！

 はじめにカスタムフックは、Reactにおけるロジックの再利用を可能にする強力な機能です。
しかし最近、とりあえずスパゲッティコードを切り出して分割するだけに利用していることに気づき、改めてカスタムフックの最適な設計を意識しました。
この記事では、３つの重要な設計原則を軸に、実務で使えるカスタムフックのパターンを紹介します。良い例・悪い例を比較しながら、「なぜそうすべきか」を説明しています。

 この記事で学べる３つの原則
単一責任 - 1つのフックは1つのことだけをする

直感的なAPI - 使いやすいインターフェース設計

パフォーマンス - 適切な最適化の判断基準

 そもそもカスタムフックとは？まず、３つの原則に入る前に、カスタムフックの基本を確認しておきましょう。

 なぜ存在するのか？Reactコンポーネントを書いていると、同じようなロジックを複数のコンポーネントで使い回したくなることがあります（フォーム管理、データ取得、イベント監視など）。
React Hooks 以前は、HOC（Higher Order Component）や Render Props でロジックを共有していましたが、コンポーネントの階層が深くなる「ラッパー地獄」が問題でした。
カスタムフックは、コンポーネントの階層を増やさずに、ロジックだけを共有するための仕組みです。

 カスタムフックを作るべきタイミング
同じロジックを複数箇所で使っている時 - 重複を避けて再利用する

コンポーネントのロジックが複雑になってきた時 - ロジックとUIを分離してシンプルに保つ

副作用を適切に管理したい時 - API呼び出しやイベントリスナーなどをカプセル化

 アンチパターン
1箇所でしか使わないロジック - まずはコンポーネント内に書く。必要になってから切り出す

単純な計算や変換 - 普通の関数で十分
カスタムフックは「後から切り出す」こともできます。最初から完璧を目指さず、重複が出てきたタイミングで抽出するのも良いアプローチです。
冒頭で述べたような「コードが長くなったから、とりあえずカスタムフックに切り出す」というアプローチは、本来の目的からズレています。大切なのはロジックの再利用性や責務の分離であり、単なるコード分割ではありません。

 1. 単一責任：1つのフックは1つのことだけをするカスタムフックを設計する上で最も重要な原則です。1つのフックが複数の無関係な機能を持つと、再利用性が著しく低下します。

 ❌ 悪い例：責務が多すぎる// 複数の責務を持ちすぎ
function useEverything() {
  const [user, setUser] = useState(null);
  const [posts, setPosts] = useState([]);
  const [theme, setTheme] = useState('light');
  const [isOpen, setIsOpen] = useState(false);

  // 関係ない機能が混在
  useEffect(() => {
    fetchUser();
    fetchPosts();
  }, []);

  return { user, posts, theme, isOpen, setTheme, setIsOpen };
}
何が問題か？
このフックを使いたいコンポーネントは、必要のない状態（例：ユーザー情報だけ欲しいのにテーマやモーダルの状態も一緒についてくる）も抱え込むことになります。さらに、テストも困難です。

 ✅ 良い例：単一の責務に集中// トグル状態の管理だけに集中
function useToggle(initialValue = false) {
  const [value, setValue] = useState(initialValue);

  const toggle = useCallback(() => setValue(v => !v), []);
  const setTrue = useCallback(() => setValue(true), []);
  const setFalse = useCallback(() => setValue(false), []);

  return { value, toggle, setTrue, setFalse };
}
なぜ良いのか？
トグル状態の管理という1つの明確な責務だけを持つ
どこでも再利用できる（モーダル、アコーディオン、テーマ切り替えなど）
テストが容易
判断基準:

「このフックは〇〇をする」と一言で説明できるか？

説明に「と」「や」が入るなら、分割を検討した方がいいでしょう。

 2. 直感的なAPIカスタムフックのAPIは、一貫性があり、予測可能であるべきです。

Reactの標準フック（useState、useReducerなど）の形式に合わせることで、使い方が予測しやすくなります。

 APIの設計パターンパターン1: 配列形式 - useStateスタイル
const [value, setValue] = useLocalStorage('key', initialValue);
シンプルで、1つの値とその更新関数を返す場合に最適。
パターン2: オブジェクト形式 - 複数の値を返す場合
const { data, error, isLoading, refetch } = useQuery(url);
返り値が多い場合、名前で識別できるので分かりやすい。
パターン3: ハンドラを分離 - 状態と操作を明確に区別
const [items, { add, remove, clear }] = useArray([]);
値は直接参照、操作はオブジェクトにまとめることで役割が明確に。
重要なのは、プロジェクト内で一貫したパターンを使うことです。

 実践例1: useBooleanモーダルの開閉やトグルボタンなど、ON/OFFの状態を扱う場面で便利なフックです。
function useBoolean(initialValue = false) {
  const [value, setValue] = useState(initialValue);

  const handlers = useMemo(
    () => ({
      setTrue: () => setValue(true),
      setFalse: () => setValue(false),
      toggle: () => setValue(v => !v),
    }),
    []
  );

  return [value, handlers];
}

// 使用例
function Modal() {
  const [isOpen, { setTrue: open, setFalse: close }] = useBoolean();

  return (
    <>
      <button onClick={open}>開く</button>
      {isOpen && <ModalContent onClose={close} />}
    </>
  );
}
ポイント:
配列 + オブジェクトの組み合わせで、値とハンドラを明確に分離
分割代入でハンドラ名を変更できる柔軟性（setTrue: open）

 実践例2: useLocalStorageユーザー設定（テーマ、言語など）をブラウザに保存したい場合に使えるフックです。useStateと同じ使い心地で、LocalStorageへの保存も自動で行います。
function useLocalStorage<T>(
  key: string,
  initialValue: T
): [T, Dispatch<SetStateAction<T>>] {
  // 初期値の読み込み
  const [storedValue, setStoredValue] = useState<T>(() => {
      const item = window.localStorage.getItem(key);
      return item ? JSON.parse(item) : initialValue;
  });

  // 状態が変更されたら LocalStorage に保存
  useEffect(() => {
    try {
      window.localStorage.setItem(key, JSON.stringify(storedValue));
    } catch (error) {
      console.error(`Error saving localStorage key "${key}":`, error);
    }
  }, [key, storedValue]);

  return [storedValue, setStoredValue];
}

// 使用例
function ThemeSelector() {
  const [theme, setTheme] = useLocalStorage<'light' | 'dark'>('theme', 'light');

  return (
    <button onClick={() => setTheme(t => t === 'light' ? 'dark' : 'light')}>
      Current: {theme}
    </button>
  );
}
ポイント:

useStateと完全に同じAPIで、LocalStorageへの追加も可能
APIがシンプルに保たれている

 3. パフォーマンス：カスタムフック内での最適化カスタムフックを設計する際、パフォーマンスを意識しすぎて複雑になってしまうことがあります。シンプルさを保ちつつ、必要な箇所だけ最適化するのが重要です。

 原則1: フックが返す関数は必ずメモ化するカスタムフックが返す関数は、コンポーネントの再レンダリングのたびに新しい関数が生成されないよう、useCallbackでメモ化すべきです。

 ❌ 悪い例：関数をメモ化していないfunction useCounter(initialValue = 0) {
  const [count, setCount] = useState(initialValue);

  // 毎回新しい関数が生成される
  const increment = () => setCount(c => c + 1);
  const decrement = () => setCount(c => c - 1);
  const reset = () => setCount(initialValue);

  return { count, increment, decrement, reset };
}

// このフックを使うコンポーネントでは、
// increment などが毎回変わるため、useEffect の依存配列に入れると毎回実行される

 ✅ 良い例：関数をメモ化しているfunction useCounter(initialValue = 0) {
  const [count, setCount] = useState(initialValue);

  const increment = useCallback(() => setCount(c => c + 1), []);
  const decrement = useCallback(() => setCount(c => c - 1), []);
  const reset = useCallback(() => setCount(initialValue), [initialValue]);

  return { count, increment, decrement, reset };
}
ポイント:
フックが返す関数は、使う側のコンポーネントでuseEffectの依存配列に入る可能性がある
メモ化しないと、意図しない再実行を引き起こす

 原則2: 重い計算が必要なら、カスタムフックに切り出すコンポーネント内で複雑な計算やフィルタリングを行っている場合、それをカスタムフックに切り出すことで、再利用性とテスタビリティが向上します。
// カスタムフックに切り出す
function useFilteredItems<T>(items: T[], filterFn: (item: T) => boolean) {
  return useMemo(() => items.filter(filterFn), [items, filterFn]);
}

// 使用例
function ProductList({ products }: { products: Product[] }) {
  const [searchTerm, setSearchTerm] = useState('');

  // フィルタリングロジックをフックに委譲
  const filteredProducts = useFilteredItems(
    products,
    (product) => product.name.toLowerCase().includes(searchTerm.toLowerCase())
  );

  return (
    <div>
      <input
        value={searchTerm}
        onChange={(e) => setSearchTerm(e.target.value)}
      />
      {filteredProducts.map(product => (
        <div key={product.id}>{product.name}</div>
      ))}
    </div>
  );
}
ポイント:
重い計算をフックに隠蔽することで、コンポーネントがシンプルになる

useMemoによる最適化もフック内部で完結
同じフィルタリングロジックを他のコンポーネントでも再利用可能

 原則3: 過度な最適化は避けるカスタムフックを作る時、「将来使うかもしれない」機能を先回りして実装したり、不要な最適化をしてしまうことがあります。

 ❌ 悪い例：やりすぎfunction useCounter(initialValue = 0) {
  const [count, setCount] = useState(initialValue);

  // 全部メモ化する必要はない（countは単なる数値）
  const doubledCount = useMemo(() => count * 2, [count]);
  const isEven = useMemo(() => count % 2 === 0, [count]);
  const isPositive = useMemo(() => count > 0, [count]);

  // 使われないかもしれない機能まで実装
  const incrementBy = useCallback((n: number) => setCount(c => c + n), []);
  const decrementBy = useCallback((n: number) => setCount(c => c - n), []);
  const multiplyBy = useCallback((n: number) => setCount(c => c * n), []);

  return {
    count,
    doubledCount,
    isEven,
    isPositive,
    incrementBy,
    decrementBy,
    multiplyBy,
  };
}

 ✅ 良い例：シンプルに保つfunction useCounter(initialValue = 0) {
  const [count, setCount] = useState(initialValue);

  // 必要最小限の機能だけ提供
  const increment = useCallback(() => setCount(c => c + 1), []);
  const decrement = useCallback(() => setCount(c => c - 1), []);
  const reset = useCallback(() => setCount(initialValue), [initialValue]);

  return { count, increment, decrement, reset };
}
判断基準:

YAGNI原則（You Aren't Gonna Need It）: 今必要ないものは作らない
簡単な計算（count * 2 など）はメモ化不要
実際に使われる機能だけを実装する

 まとめカスタムフックを設計する際の３つの重要な原則を振り返ります。

 1. 単一責任の原則1つのフックは1つのことだけをする
「このフックは〇〇をする」と一言で説明できるか？
説明に「と」「や」が入るなら分割を検討する

 2. 直感的なAPI配列形式 [value, setValue]、オブジェクト形式 { data, error }、ハンドラ分離 [value, { add, remove }] を使い分ける
Reactの標準フック（useStateなど）と同じ形式にすると使い方が予測しやすい
プロジェクト内で一貫したパターンを使う

 3. パフォーマンスフックが返す関数は必ず useCallback でメモ化する（useEffectの依存配列問題を防ぐ）
重い計算はカスタムフックに切り出して useMemo で最適化
YAGNI原則: 今必要ない機能は実装しない、過度な最適化は避ける
これらの原則を理解しておけば、再利用性が高く、保守しやすいReactアプリケーションを構築できます。
カスタムフックは強力なツールですが、「本当にカスタムフックにすべきか？」を常に問いかけることも大切です。
シンプルなコンポーネント内のロジックまで無理にフック化する必要はありません。適材適所で活用しましょう。
この記事が皆さんのお役に立つと嬉しいです！

最後まで読んでいただきありがとうございました！

UZU テックブログPublication

私たちはマーダーミステリーに関連するプロダクト群を展開しています。主なプロダクトとして、スマホ一つで遊べるマダミスアプリ「ウズ」、誰でも簡単にマダミスを制作できるマダミス制作ツール「ウズスタジオ」、日本最大級のマダミス情報プラットフォーム「マダミス.jp」の開発・運営をしています。

はじめに

この記事で学べる３つの原則

そもそもカスタムフックとは？

なぜ存在するのか？

カスタムフックを作るべきタイミング

アンチパターン

1. 単一責任：1つのフックは1つのことだけをする

❌ 悪い例：責務が多すぎる

✅ 良い例：単一の責務に集中

2. 直感的なAPI

APIの設計パターン

実践例1: useBoolean

実践例2: useLocalStorage

3. パフォーマンス：カスタムフック内での最適化

原則1: フックが返す関数は必ずメモ化する

❌ 悪い例：関数をメモ化していない

✅ 良い例：関数をメモ化している

原則2: 重い計算が必要なら、カスタムフックに切り出す

原則3: 過度な最適化は避ける

❌ 悪い例：やりすぎ

✅ 良い例：シンプルに保つ

まとめ

1. 単一責任の原則

2. 直感的なAPI

3. パフォーマンス

Discussion