## はじめに

前回の記事「[Claude Codeで始めるISSUE駆動開発](https://sterfield.co.jp/blog/claude-code-issue/)」を公開したのが2025年12月でした。それから約4ヶ月、自分の開発環境は当時とはかなり違うものになっています。特にIDEをほぼ開かなくなったのが、一番の変化でした。

本記事では、12月時点の環境からどのように変わったのか、そのきっかけとなったツール導入や運用の変化を振り返ります。

## 12月時点の環境

前回記事を書いた頃の開発環境は、以下のようなものでした。

- エディタ：Visual Studio Code（以下、VSCode）
- AI：Claude Code（VSCode拡張機能）

VSCodeの中ですべてが完結していました。Claude Codeは拡張機能としてサイドパネルに常駐し、指示はそこで出す。コードはエディタで読み書きする。GitHub ISSUEの読み書きやgit操作も含めて、日々の開発はほぼこの一画面で回せていました。IDEが作業の中心だった、という言い方がしっくりきます。

## 今の環境

現在の環境は、以下のようになっています。

- エディタ：[Zed](https://zed.dev/)（たまに開く程度）
- AI：Claude Code CLI、[cmux](https://cmux.com/ja)で複数セッションを同時起動
- Markdownプレビュー：[mo](https://github.com/k1LoW/mo)、もしくはPRを作ってGitHub上で確認

作業の中心はターミナルに移りました。

Claude Codeにタスクを渡したら、あとはエージェントが動きます。コードを確認したくなったときだけZedを開いて眺める程度で、編集することはほぼありません。このブログ記事の執筆も同じ流れで、プレビューはターミナルからmoを叩くか、PRを作ってGitHub上で確認するのが基本です。

## 何が変わったのか

12月時点でも、Claude Codeを使って一通りの開発は回せていました。VSCodeを開き、拡張機能を通じてClaude Codeに指示し、一つの作業を一つずつ進める。それで十分機能していたのです。

そこから変わったのは、複数の作業を同時に走らせられるようになったことです。きっかけは主に2つありました。

### 1. cmuxによる複数セッションの並走

1つめは、[cmux](https://cmux.com/ja)の導入です。

cmuxは、Claude Codeをはじめとするコーディングエージェントを複数同時に実行・管理するためのデスクトップアプリケーションです。各セッションを独立したタブとして扱い、それぞれのエージェントの状態を一目で把握できます。現時点ではmacOSのみの対応です。

画面には常に4〜5個のClaude Codeが並んでおり、それぞれ別のリポジトリ、別の機能、別のバグを担当しています。一つにバグ修正を頼み、別のセッションにリファクタを投げ、さらに別のセッションでドキュメントを書かせる。どれかが考えている間に、どれかが実装を終えている。以前なら順番にこなしていた作業が、いくつもの並列レーンで同時に進んでいく感覚は、これまでの開発体験にはなかったものです。

![cmuxで複数のClaude Codeセッションを並走させている様子](https://cont.sterfield.co.jp/uploads/cmux_parallel_sessions_83c193db65.png)

### 2. git worktreeを使ったPRレビュースキルの整備

2つめは、git worktreeを活用してPRをレビューするためのClaude Codeのスキルを整備したことです。

worktreeで別ディレクトリにPRブランチをチェックアウトし、そのディレクトリ上でClaude Codeを立ち上げてレビューを進める、という仕組みです。これを整えたことで、メインの作業ツリーで別ISSUEの開発を進めながら、同じリポジトリのPRレビューも並行して走らせることができるようになりました。

worktreeを使わずにブランチを切り替えてしまうと、進行中の作業が一時的に止まってしまいます。worktreeを前提にすることで、作業の文脈を切らずにレビューだけを別トラックで走らせられるようになりました。

### IDEの立ち位置の変化

この2つが組み合わさったことで、同一リポジトリ内の複数作業はもちろん、別リポジトリの作業までも並行できるようになりました。そうなると、作業の中心は自然とターミナルに寄っていきます。

VSCodeはもともと「書く・読む・実行する」のすべてをこなす場所でしたが、今はZedに乗り換えた上で「読む」しかしていません。しかも常時開いているわけでもなく、必要なときだけ立ち上げるスタイルです。

もちろん人間側のボトルネックはあります。5つのPRが同時に上がってくれば、レビューするのは自分ひとりです。それでも「手が足りないから諦める」が減り、「やりたいことを同時に走らせてみる」が選択肢に入ってきたのは大きな変化でした。一人で開発しているのに、まるで小さなチームを抱えているような気分になります。

## まとめ

「AIをIDEの中で使う」から「AIを中心に置いてIDEを脇に置く」へ。構造の逆転が起きたというのが、この4ヶ月の一番の実感です。ツール選びの軸も「書きやすさ」から「エージェントとの並走のしやすさ」に変わりました。

cmuxによる複数セッションの並走、git worktreeを活用したレビュースキルの整備。どちらも派手な話ではありませんが、組み合わせることで「一人で複数のエージェントを指揮する」開発スタイルが現実のものになりました。

Claude Codeを日常的に使っている方は、ぜひcmuxやworktreeとの組み合わせも試してみてください。開発の体験が一段変わると思います。

large_eyecatch.jpg

medium_eyecatch.jpg

small_eyecatch.jpg

thumbnail_eyecatch.jpg

eyecatch.jpg

AIエージェントを中心に据えた開発環境への移行

## はじめに

Anthropicが提供するCLIベースのAIコーディングエージェント「Claude Code」を使った開発ワークフローをご紹介します。

Claude Codeの特徴は、ターミナル上で動作し、GitHubのISSUEやPRと直接連携できる点です。これにより、ISSUEを起点とした開発フローを非常にスムーズに進めることができます。

## Claude Codeとは

[Claude Code](https://docs.anthropic.com/ja/docs/claude-code/overview)は、Anthropicが提供するCLIベースのAIコーディングエージェントです。ターミナルから自然言語で指示を出すだけで、コードの生成・修正からGit操作まで一連の開発作業を自律的に進めてくれます。

Claude Codeの基本的な使い方やインストール方法については、[前回の記事「Claude有料版を初めて使う開発者向けガイド」](/blog/blog-32/)で詳しく解説していますので、そちらをご覧ください。

本記事では、Claude Codeの中でも特に強力なGitHub連携機能を活用した「ISSUE駆動開発」のワークフローに焦点を当てて紹介します。

## ISSUE駆動開発とは

ISSUE駆動開発は、ISSUEを起点として開発を進める手法です。GitHubやGitLabなど、ISSUEトラッカーを持つサービスで実践できます。すべての作業がISSUEに紐づくため、以下のようなメリットがあります。

- トレーサビリティ: なぜその変更が行われたかが明確
- チーム連携: 作業状況の可視化と共有が容易
- 品質管理: レビューとテストのプロセスが明確

## Claude CodeによるISSUE駆動開発ワークフロー

Claude Codeを使うと、ISSUE駆動開発が驚くほどスムーズになります。以下に実際のワークフローを紹介します。

Claude CodeはCLAUDE.mdという設定ファイルでカスタマイズできます。今回のワークフローでは、CLAUDE.mdという設定ファイルに「ISSUEのURLが提供された場合はghコマンドで内容を確認する」といった指示を記述しておく必要があります。

### 1. ISSUEの確認と計画立案

```
> #123のISSUEに対応してください
```

このように指示すると、Claude Codeは以下を自動で行います。

1. `gh issue view 123` でISSUEの内容を取得
2. 要件を分析し、TODOリストを作成
3. 仕様や設計に不足があれば指摘し、見直しを促す
4. 作業計画を提示して確認を求める

ここで重要なのは、AIとの議論を通じて明確になった仕様や設計をISSUE側に反映させることです。これにより、ISSUEが単なるタスク管理ではなく、ISSUEが開発の意図や設計の背景を記録した、生きた仕様書として機能するようになります。

### 2. ブランチ作成と実装

計画が承認されると、Claude Codeは以下のワークフローを実行します。

1. フィーチャーブランチを作成（例: dev/123_add-user-validation）
2. 必要なファイルを特定し、コードを実装
3. 動作確認やテストを実行
4. 問題があれば修正を繰り返す

### 3. PRの作成とレビュー依頼

実装が完了すると、Claude Codeは変更内容をまとめたPRを自動作成します。

```
> PRを作成してください
```

PRには以下が自動で含まれます。

- 変更内容のサマリー
- テスト計画
- 関連するISSUEへのリンク

## やってみた所感

実際に3ヶ月間、このワークフローで開発を続けてきました。その中で得られた気づきを共有します。

### 既存プロジェクトへの導入のしやすさ

最も大きなメリットは、今まで使っていたGitHub ISSUEをそのまま活用できる点です。新しいツールやフローを導入する際、既存の運用を変える必要があると導入コストが跳ね上がりますが、Claude CodeはGitHubのISSUEを直接読み込んで内容を理解するため、既存のプロジェクト管理をそのまま維持できます。

この3ヶ月間、ほぼ全ての実装作業をClaude Codeに任せることができています。ISSUEを起点にした開発フローが確立されていれば、導入は驚くほどスムーズです。

### AIを信じて任せることの重要性

運用を続ける中で気づいたのは、細かくやり方を指示しすぎない方がAIの能力を発揮してくれるということです。

最初は「このファイルを開いて」「この関数を修正して」と細かく指示を出していましたが、それではAIの自律性を活かせません。「#123のISSUEに対応して」とだけ伝え、計画立案から任せる方が、結果的に質の高いアウトプットが得られます。人間が想定していなかったより良いアプローチを提案してくれることも少なくありません。

### 伴走スタイルがベストプラクティス

一方で完全に自律させるのではなく、あくまでも「伴走」というスタンスを維持することをおすすめします。

AIに複数のタスクを並列で任せたり、完全に放置して自律的に進めさせることも技術的には可能です。しかし、そうすると人間側のレビュー工数が一気に増え、かえって非効率になります。1つのタスクをAIと一緒に進め、要所要所で確認しながら進める「伴走スタイル」が、現時点ではベストプラクティスだと感じています。

「人間がISSUEを作成し、AIが実装する」という一方通行の役割分担ではなく、ISSUEを軸に人間とAIが協働しながら開発を進める。これがClaude Codeを活用したISSUE駆動開発の醍醐味だと感じています。

## まとめ

Claude Codeを使ったISSUE駆動開発は、開発ワークフローを大きく効率化する可能性を秘めています。特に、ISSUEの確認からPR作成までの一連の流れをAIがサポートしてくれることで、開発者はより本質的な設計や問題解決に集中できます。

設定ファイルを活用すれば、チームのコーディング規約やワークフローをClaude Codeに教え込むことも可能です。これにより、チーム全体で一貫した開発スタイルを維持しながら、AIの力を借りることができます。

AIコーディングエージェントはまだ発展途上ですが、開発者の強力なパートナーとなる未来は確実に近づいています。皆さんもぜひ、Claude Codeを使ったISSUE駆動開発を体験してみてください。

large_eyecatch.png

medium_eyecatch.png

small_eyecatch.png

thumbnail_eyecatch.png

eyecatch.png

Claude Codeで始めるISSUE駆動開発

## はじめに

2023 年 10 月ごろに、[Recoil と Jotai に関する記事](https://sterfield.co.jp/blog/which-recoil-or-jotai/)を投稿しましたが、2023 年 3 月以降、Recoil の更新が進められていない状況で、React 19 以降では正常に動作しない見込みとなってきました[<a href="https://github.com/facebookexperimental/Recoil/issues/2318#issuecomment-2120383312" target="_blank">参考</a>]。  
そのため、これまで Recoil を使ってきた React のプロジェクトにおいて、別の状態管理ライブラリへの移行が必要となり、対応を進めています。  
その選択肢の一つとして、Redux への移行を行ったので、そのときの方法を Recoil と Redux のコードを比べながら、通常の状態と、API との通信を伴う非同期の状態の移行に分けて、ご紹介します。  
ここでご紹介する方法は、Redux は、Redux Toolkit と React Redux の利用を前提にしています。

## インストール

Recoil から Redux へ移行する場合、Redux Toolkit と React Redux を使うことで、Recoil のときと同じようなコードの書き方で、スムーズに移行できるので、そちらをインストールします。

```bash
npm i @reduxjs/toolkit react-redux
```

## ファイルの準備

以下はファイル構成の例です。

```
redux
├ hooks/ // React用のHooksを格納する
│ ├ normalExample.ts
│ ├ familyExample.ts
│ ┗ asyncExample.ts
├ slices/ // ReduxのSliceを格納する
│ ├ normalExampleSlice.ts
│ ├ familyExampleSlice.ts
│ ┗ asyncExampleSlice.ts
┗ store.ts  // Reduxのstore
```

## 通常の状態

### Recoil

```typescript
import {
  atom,
  useRecoilValue,
  useResetRecoilState,
  useSetRecoilState,
} from "recoil";

// Recoilのatomを設定
export const normalExampleState = atom<string>({
  key: "normalExample",
  default: "",
});

// get state
export const useNormalExampleValue = () => useRecoilValue(normalExampleState);

// set state
export const useSetNormalExampleState = (key) =>
  useSetRecoilState(loadingState);

// reset state
export const useResetNormalExampleState = () =>
  useResetRecoilState(normalExampleState);
```

上記のような状態を Recoil で設定していた場合、Redux Toolkit と React Redux を使って以下のように置き換えることができます。  
ご覧いただくとわかりますが、reducer による action の設定や Root の store.ts への設定のところが Recoil にはない記述ですが、それ以外は似たコードで構成できることがわかります。

### Redux

redux/slices/normalExampleSlice.ts

```typescript
import { createSlice, type PayloadAction } from "@reduxjs/toolkit";

const initialState = "";

// ReduxのSliceを設定
export const normalExampleSlice = createSlice({
  name: "normalExample",
  initialState,
  reducers: {
    // set
    setNormalExample: (state, action: PayloadAction<string>) => {
      state.normalExample = action.payload;
    },
    // reset
    resetNormalExample: (state) => {
      state.normalExample = "";
    },
  },
});

export const { setNormalExample, resetNormalExample } =
  normalExampleSlice.actions;

export default normalExampleSlice.reducer;
```

redux/store.ts

```typescript
import { configureStore } from "@reduxjs/toolkit";
import { TypedUseSelectorHook, useSelector } from "react-redux";
import normalExample from "./slices/normalExampleSlice";

// 用意したSliceをstoreに登録する
export const store = configureStore({
  reducer: {
    normalExample,
  },
});

export type AppStore = typeof store;

export type RootState = ReturnType<AppStore["getState"]>;

export type AppDispatch = AppStore["dispatch"];

// useSelectorでは型が引き継がれないので、TypeScriptでは型を引き継げるuseAppSelectorを用意する
export const useAppSelector: TypedUseSelectorHook<RootState> = useSelector;
```

React 用の Hooks は、以下のように React Redux の useDispatch と useSelector（TypeScript の場合は store.ts で定義した useAppSelector）を利用して以下のように構成できます。

redux/hooks/normalExampleSlice.ts

```typescript
import { useDispatch } from "react-redux";
import { useCallback } from "react";
import {
  setNormalExample,
  resetNormalExample,
} from "@/redux/slices/normalExampleSlice";
import { useAppSelector, type RootState } from "../store";

// get state
export const useNormalExampleValue = () =>
  useAppSelector((state: RootState) => state.normalExample);

// set state
export const useSetNormalExampleState = () => {
  const dispatch = useDispatch();
  return (value: string) => {
    dispatch(setNormalExample(value));
  };
};

// reset state
export const useResetNormalExampleState = () => {
  const dispatch = useDispatch();
  return () => {
    dispatch(resetNormalExample(value));
  };
};
```

## AtomFamily からの移行

Recoil では、atomFamily という、同じ型の状態をキーごとに再利用するための便利な機能が用意されていますが、Redux Toolkit の Slice でも、以下のように構成することで、似た機能を実装できます。

### Recoil

```
import { atomFamily } from "recoil";

import {
  atom,
  useRecoilValue,
  useResetRecoilState,
  useSetRecoilState,
} from "recoil";

// RecoilのatomFamilyを設定

export const familyExampleState = atomFamily<string, string>({
  key: "familyExample",
  default: null
});

// get state
export const useNormalExampleValue = (key: string) => useRecoilValue(familyExampleState(key));

// set state
export const useSetNormalExampleState = (key: string) =>
  useSetRecoilState(familyExampleState(key));

// reset state
export const useResetNormalExampleState = (key: string) =>
  useResetRecoilState(familyExampleState(key));
```

### Redux

redux/slices/familyExampleSlice.ts

```typescript
import { createSlice, type PayloadAction } from "@reduxjs/toolkit";

export interface FamilyExampleState {
  [key: string]: string | null;
}

const initialState: FamilyExampleState = {
  default: null,
};

const familyExampleSlice = createSlice({
  name: "familyExample",
  initialState,
  reducers: {
    // set
    setFamilyExample(
      state,
      action: PayloadAction<{ key: string; value: string }>
    ) {
      state[action.payload.key] = action.payload.value;
    },
    // reset
    resetFamilyExample(state, action: PayloadAction<string>) {
      state[action.payload] = null;
    },
  },
});

export const { setFamilyExample, resetFamilyExample } =
  familyExampleSlice.actions;

export default familyExampleSlice.reducer;
```

redux/hooks/familyExampleSlice.ts

```typescript
import { useDispatch, shallowEqual } from "react-redux";
import { type RootState, useAppSelector } from "../store";
import {
  setFamilyExample,
  resetFamilyExample,
} from "../slices/familyExampleSlice";

export const useFamilyExampleValue = (key: string) =>
  useAppSelector((state: RootState) => state.familyExample[key], shallowEqual);

export const useSetFamilyExampleState = (key: string) => {
  const dispatch = useDispatch();
  return (value: string) => {
    dispatch(setFamilyExample({ key, value }));
  };
};

export const useResetFamilyExampleState = (key: string) => {
  const dispatch = useDispatch();
  return () => {
    dispatch(resetFamilyExample(key));
  };
};
```

## API 通信を伴う非同期の状態

API からのデータ取得など、非同期を伴う場合、Redux への移行には少しなれがひつようかもしれません。
以下のような Recoil では selector で API からのデータ取得を伴う状態を構成していた場合を移行する場合の例です。

### Recoil

```typescript
import {
  atom,
  selector,
  useSetRecoilState,
  useRecoilValue,
  useRecoilRefresher_UNSTABLE,
} from "recoil";
import { apolloClient } from "@/api/apollo-client";
import { exampleQuery } from "@/api/query/exampleQuery";

export const asyncExampleState = selector({
  key: "asyncExample",
  get: async () => {
    const { data, errors } = await apolloClient.query({
      query: exampleQuery,
      fetchPolicy: "no-cache",
    });
    if (errors) {
      throw errors;
    }
    return data.example;
  },
});

// get state
export const useAsyncExampleValue = () => useRecoilValue(asyncExampleState);

// reset state
export const useResetAsyncExampleState = () =>
  useRecoilRefresher_UNSTABLE(asyncExampleState);
```

### Redux

Redux Toolkit で非同期を伴う Slice を作成する場合、createAsyncThunk と createSlice の extraReducers で構成します。

redux/slices/asyncExampleSlice.ts

```typescript
import { createSlice, createAsyncThunk, PayloadAction } from "@reduxjs/toolkit";
import type { ApolloError } from "@apollo/client";
import { apolloClient } from "@/api/apollo-client";
import { exampleQuery, type Example } from "@/api/query/exampleQuery";
import type { RootState } from "../store";

// API用の状態の型を定義
const initialState: {
  data: Example[];
  status: "idle" | "loading" | "succeeded" | "failed";
  error: ApolloError;
} = {
  data: [],
  status: "idle",
  error: null,
};

// 非同期用のreducerを設定
export const fetchAsyncExample = createAsyncThunk<
  Example[],
  void,
  { state: RootState }
>("asyncExample/fetchAsyncExample", async (_, { rejectWithValue }) => {
  const { data, errors } = await apolloClient.query({
    query: exampleQuery,
    fetchPolicy: "no-cache",
  });

  if (error) {
    return rejectWithValue(error);
  }

  return data.example;
});

// SliceにextraReducersを使って非同期用のreducerを紐づける
export const asyncExampleSlice = createSlice({
  name: "asyncExample",
  initialState,
  reducers: {},
  extraReducers: (builder) => {
    builder
      .addCase(fetchAsyncExample.pending, (state) => {
        state.status = "loading";
      })
      .addCase(fetchAsyncExample.fulfilled, (state, action) => {
        state.status = "succeeded";
        state.data = action.payload;
      })
      .addCase(fetchAsyncExample.rejected, (state, action) => {
        state.status = "failed";
        state.error = action.payload as any;
      });
  },
});

export default asyncExampleSlice.reducer;
```

redux/hooks/asyncExampleSlice.ts

```typescript
import { useDispatch, shallowEqual } from "react-redux";
import { type RootState, useAppSelector } from "../store";
import { fetchAsyncExample } from "../slices/asyncExampleSlice";

// get state
export const useAsyncExampleValue = () => {
  const dispatch: AppDispatch = useDispatch();
  const { data, status } = useAppSelector(
    (state: RootState) => state.example,
    shallowEqual
  );

  // 状態が"idle"の時はfetchを実行する
  useEffect(() => {
    if (status === "idle") {
      dispatch(fetchAsyncExample());
    }
  }, [status, dispatch]);

  return data;
};

// reset state
export const useResetNormalExampleState = () => {
  const dispatch = useDispatch();
  return () => {
    dispatch(fetchAsyncExample());
  };
};
```

## 移行途中で Recoil と依存する状態を連携させる場合

移行途中で共存させなければならない場合、以下のように Recoil に依存する状態を Redux と連携できます。
ただし、Recoil 同士の状態と違い、Redux の状態の変化を Recoil は自動で検知してくれないので、Redux の状態を変更するときに、Recoil で Reset や Refresh を実行する必要があることの注意が必要です。

```typescript
import { selector } from "recoil";
import { store } from "@/redux/store";
import { apolloClient } from "@/api/apollo-client";
import { exampleQuery, type Example } from "@/api/query/exampleQuery";

export const exampleState = selector({
  key: "exampleState",
  get: async ({ get }) => {
    const keyword = store.getState().keyword;

    const { data, errors } = await apolloClient.query({
      query: exampleQuery,
      variables: {
        keyword,
      },
      fetchPolicy: "no-cache",
      errorPolicy: "all",
    });
    if (errors) {
      throw errors;
    }
    return data.example;
  },
  cachePolicy_UNSTABLE: {
    eviction: "most-recent",
  },
});
```

## まとめ

Recoil の atom や selector の書き方と Redux Toolkit の createSlice の書き方が似ていることもあり、意外とコードの移行の親和性が高いと感じました。  
ただ、非同期関係では Redux において createAsyncThunk を利用するなど、Recoil にはない独特の記述も必要で、慣れが必要な部分も実感しました。

## 参考リンク

- Recoil の更新状況: <a href="https://github.com/facebookexperimental/Recoil/issues/2318#issuecomment-2120383312" target="_blank">React 19 support · Issue #2318 · facebookexperimental/Recoil</a>
- Recoil の更新状況: <a href="https://recoiljs.org/blog" target="_blank">Blog | Recoil</a>
- Redux Toolkit の使い方 (はじめ方): <a href="https://redux-toolkit.js.org/tutorials/quick-start" target="_blank">Quick Start | Redux Toolkit</a>
- Redux Toolkit の使い方 (TypeScript): <a href="https://redux-toolkit.js.org/tutorials/typescript" target="_blank">TypeScript Quick Start | Redux Toolkit</a>
- Redux Toolkit の使い方 (非同期の状態): <a href="https://redux-toolkit.js.org/api/createAsyncThunk" target="_blank">createAsyncThunk | Redux Toolkit</a>

medium_20240719_recoil-to-redux.png

small_20240719_recoil-to-redux.png

thumbnail_20240719_recoil-to-redux.png

20240719_recoil-to-redux.png

Recoil から Redux へ移行するときにやったこと

## はじめに
Reactでフロントエンドの開発を行う場合に、おそらく一度は誰でも状態管理に頭を悩ませるのではないでしょうか。  
2023年10月現在、Redux、React Hooks、zustand、そしてここで取り上げる Recoil、Jotai など、Reactの状態管理をするためのライブラリや方法は数多く存在ます。  
多くの開発者によりその使い方が模索・洗練されていますが、絶対的な正解というものは存在しません。  
故に、プロジェクトに導入する場合に、どれを選定するかで、とても迷う方は多いのではないでしょうか。  
このブログでは、私が状態管理のライブラリを選定するときに悩んだ内容から、案件の向き不向きについて考察し、ご紹介したいと思います。  

**[2024.6.3 追記] Recoilから正式に発表されているわけではありませんが、2023年3月以降アップデートがなく、Recoilの開発は実質的に打ち切られてしまったようです。そのため、Recoilを選択することは避けた方がよさそうです…  
参考: <a href="https://github.com/facebookexperimental/Recoil/issues/2318" target="_blank">React 19 support · Issue #2318 · facebookexperimental/Recoil</a>**

**→ [2024.7.19 追記] [Reduxへ移行する方法の記事](https://sterfield.co.jp/blog/recoil-to-redux/)を投稿しました。**

## まず Redux、zustand と Recoil、Jotai の違いについて
Redux は、Reactを作ったFacebookが提唱した[Flux](https://github.com/facebookarchive/flux/tree/main/examples/flux-concepts)というアーキテクチャをもとにした、初期から最も利用されている状態管理ライブラリです。  
Reactとは切り離して１つのストアに集約して管理するため、情報の流れが一方通行で辿りやすい特徴があります。WEBアプリ全体の一貫性を重視し、堅牢な作りにする場合、Reduxは有望な選択肢となります。  
しかしながら、Reduxは非同期通信を伴うような複雑な状態管理ではそのまま使うのはあまりにもコードが膨大になってしまうため、サードパーティのプラグインなどを導入することが現実的な選択肢となります。また、1つのストアで管理するため、コンポーネント単位でのカプセル化が苦手です。  
  
zustand はこのReduxの苦手な部分を補うことで、Reduxからの乗り換えが進んでいるライブラリです。  
基本的な思想はReduxと同じですが、Reduxで煩雑になるような記述をより簡潔に書くことができます。 
  
Recoil は Redux とは違う思想で、ストアを複数持ち、それぞれに対して別々のコンポーネントからアクセス可能です。ストアが一元管理されているReduxやzustandとちがい、コンポーネント単位でのカプセル化がしやすく、データとアプリ全体の結合を制限することに向いているので、柔軟性を重視するアプリに向いていると言えそうです。
ただ、複数のストアに別々のコンポーネントから双方向でアクセスできる特徴が故に、組み方によってはReduxと比べると情報の流れを辿りにくくなる可能性があることに注意が必要です。  
  
Jotai は Recoil をより簡潔に記述できるようにしたライブラリで、[npm trends](https://npmtrends.com/Jotai-vs-react-redux-vs-recoil-vs-zustand)を見ると、2023年10月現在、本家のRecoilを追い抜いています。  

## RecoilよりJotaiが向いている案件
RecoilとJotaiで同じ状態管理をするためのコードを比べてみましょう。
#### Recoil
```typescript
const exampleState = atom({
  key: "exampleState",
  default: 0
});
const exampleSelector = selector({
  key: "exampleSelector"
  get ({ get }) => `${get(exampleState)}個を選択中`
});
```
#### Jotai
```typescript
const exampleState = atom(0);
const exampleSelector = atom((get) => `${get(exampleState)}個を選択中`);
```
こうやって並べてみるとよく分かりますが、  
Jotaiの方が圧倒的にコード数が少なくなります。  
Recoilで用意されている機能の多くはJotaiでも利用できるので、よりシンプルに状態管理を行いたい場合は、  Jotaiが向いていると言えます。  
  
## JotaiよりRecoilが向いている案件
では、次の場合はどうでしょう。  
#### Recoil
```typescript
// Writable
const idState = atom({
  key: "idState",
  default: 1
});

// Read Only
const fetchState = selector({
  key: "fetchState",
  get: async ({ get }) => {
    const id = get(idState);
    try {
      const response = await fetch(`example.api.json?id=${ id }`);
      const json = await response.json();
      return json;
    } catch (error) {
      throw error;
    }
  }
});

// Writable (default value fetched)
const complexState = atom({
  key: "complexState",
  default: selector({
    key: "complexSelector",
    get: async ({ get }) => {
      const json = await get(fetchState);
      return {
        id: json.id,
        name: json.exampleName
      }
    }
  })
});
```
#### Jotai
```typescript
// Writable
const idState = atom(1);

// Read Only
const fetchState = atom(async (get) => {
  const id = get(idState);
  try {
    const response = await fetch(`example.api.json?id=${ id }`);
    const json = await response.json();
    return json;
  } catch (error) {
    throw error;
  }
});

// Writable (default value fetched)
const defaultComplexState = atom(async (get) => {
  const json = await get(fetchState);
  return {
    id: json.id,
    name: json.exampleName
  }
});
const overWrittenComplexState = atom(null as { id: number; name: stirng; });
const complexState = atom<number, [number], void>(
  async (get) =>
    (await get(overWrittenComplexState)) ||
    (await get(defaultComplexState)),
  (_get, set, update) => set(overWrittenComplexState, update)
);
```
このように初期値をフェッチしつつ、後からデータの上書きもできるようなストアを作ろうとするような複雑な処理をさせようとした場合、JotaiよりRecoilの方が分かりやすいコードになることがわかるかと思います（もっと上手な書き方があったらすみません）。  
また、フェッチしたデータをリセットできるようにする場合、  
  
#### Recoil
```jsx
const exampleState = atom({
  key: "exmapleState",
  default: 0
})
const ExampleComponent = () => {
  const [example, setExample] = useRecoilState(exampleState);
  const reseter = useResetRecoilState(exampleState);
  const handleAddClick = () => setExample(previousState => previousState + 1);
  return (
    <div>
      <p>{example}</p>
      <button onClick={handleAddClick}>追加</button>
      <button onClick={reseter}>リセット</button>
    </div>
  )
}
```
のように、Recoilはatomに対してそのままuseResetRecoil()を使うことでリセット可能ですが、  
  
#### Jotai
```jsx
const exampleState = atomWithReset(0);
const ExampleComponent = () => {
  const [example, setExample] = useAtom(exampleState);
  const reseter = useResetAtom(exampleState);
  const handleAddClick = () => setExample(previousState => previousState + 1);
  return (
    <div>
      <p>{example}</p>
      <button onClick={handleAddClick}>追加</button>
      <button onClick={reseter}>リセット</button>
    </div>
  )
}
```
のように、Jotaiでは、あらかじめreset用のutil（atomWithRest）を使ってatomを用意する必要があります。  
その他にも、Jotaiでは複雑な操作をしようとした場合に、Recoilと同様の操作をするためにより多くのutilを使ったり、helperを自前で用意しなければいけない場合に遭遇します。  
  
これらのことから、より複雑なデータ処理を扱うような使い方をする場合、Recoilの方が向いていると言えます。  

## まとめ
堅牢でアプリ全体を見通すことを優先するのであれば Redux。  
基本的な思想はReduxと同じだけど、よりシンプルに描きたいのであれば zustand。  
機能追加やコンポーネントの入れ替えが多いような柔軟性のあるアプリで、複雑なデータ管理が必要なら Recoil。  
柔軟性とシンプルさを重視するなら Jotai というのが、現時点での自分の選択基準でした。

## 参考リンク

- [Jotai](https://jotai.org/)
- [Recoil](https://recoiljs.org/)
- [Redux](https://redux.js.org/)
- [zustand](https://github.com/pmndrs/zustand)
- [npm trends: jotai vs recoil vs redux vs zustand](https://npmtrends.com/jotai-vs-recoil-vs-redux-vs-zustand)

medium_20231006_1.png

small_20231006_1.png

thumbnail_20231006_1.png

20231006_1.png

Reactの状態管理ライプラリはRecoilとJotaiならどちらをえらべばいいか？

<h2>はじめに</h2>
<p>消費者は何を決め手に購入を決めるのか、様々な視点から考察するシリーズ第3弾。<br />
前回は「支払方法」がどの程度購入の決め手になるのか紹介しました。今回はサステナビリティが購買活動に与える影響を見ていきたいと思います。</p>
<h2>世界各国で変わる消費者意識</h2>
<p>各メディアで取り上げられるサステナビリティやSDGsという言葉や考え方。一定の規模を持つ企業であれば、CSRの一貫／延長として取り入れ始め、学校の授業のトピックになっている…日本ではまだその程度の認識かもしれません。<br />
しかし、先進国を始め、世界各国ではそれ以上に関心を持ち、自分事として捉えている人が増えているようです。</p>
<p>たとえばシンガポールでは、<strong>約85%の消費者が環境に優しい製品を購入するために、より多くの金額を支払う意向を示した</strong>という調査結果もあります（参考：<a href="https://launchcart.jp/contents/ekkyo-ec_sdgs-singapore/" target="_blank" rel="noopener">シンガポールの買い物事情</a>）。<br />
また、アジア最大のECモールShopeeにおいても、様々な取り組みが行われています（参考：<a href="https://launchcart.jp/contents/ekkyo-ec_shopee_sdgs/" target="_blank" rel="noopener">アジアECモールもSDGs商品に注目！</a>）</p>
<p>また、サスティナブル消費のわかりやすい例であるリユース業界も、世界的に非常に盛り上がりを見せています（参考：<a href="https://launchcart.jp/contents/ekkyo-ec_sdgs_clothes/" target="_blank" rel="noopener">【越境EC】古着業界が火傷じゃ済まないくらい熱くなる</a>）。</p>
<h2>最新の消費者意識は？</h2>
<p>以前もサスティナブル消費／エシカル消費の意識調査についての<a href="https://launchcart.jp/contents/ekkyo-ec_ec_sdgs-branding/" target="_blank" rel="noopener">記事</a>を執筆しましたが、それから約1年が経過し、変化はあったのでしょうか。</p>
<p>アメリカのITサービス・コンサルティング会社のAstound CommerceとShopifyが提携して行った調査「<a href="https://astoundcommerce.com/landing/the-value-of-sustainability-to-your-brand/" target="_blank" rel="noopener">Sustainability and Your Customer</a>」(※)によって、各国の消費者が、サステナブルな製品により多くのお金を支払いたいという強い意欲を持っていることが明らかになりました。<br />
※米州（カナダ、メキシコ、米国）、欧州（ドイツ、イタリア、オランダ、スイス、英国）、中東（サウジアラビア、UAE）が対象。</p>
<p>特に注目すべきは、これから長い間ファンとなってくれる可能性のある若い世代、つまり<strong>Z世代の消費者は、環境問題に対するブランドの姿勢に最も影響を受けており、その割合は62%に上る</strong>ということです。また、<strong>ミレニアム世代の71％が、サスティナブルな商品に（そうでない商品に対して）より多くのお金を支払うつもりがあると回答</strong>しています。<br />
<img loading="lazy" src="/uploads-archive/lc/2023/06/c1f27bb75f7fcd71a5563ba048192faa.png" alt="" width="526" height="543" class="alignnone size-full wp-image-11983" srcset="/uploads-archive/lc/2023/06/c1f27bb75f7fcd71a5563ba048192faa.png 526w, /uploads-archive/lc/2023/06/c1f27bb75f7fcd71a5563ba048192faa-291x300.png 291w" sizes="(max-width: 526px) 100vw, 526px" /><br />
※画像は「Sustainability and Your Customer」レポートからのキャプチャ</p>
<p>さらに、同調査によると、グローバルな消費者の5人に3人が、環境問題に対する企業の姿勢に注目していると答えたそうです。<br />
また、購入することでそのブランドを支持することを示す際に注目するポイントとしては、二酸化炭素の低排出、輸送、リサイクル包装といった要素が上位にランクインしています。</p>
<p>つまり、気候変動などの環境問題への取り組みに対する企業の前向きな姿勢は、消費者の購入の意思決定に何らかの影響を与えていると言えます。</p>
<h2>まとめ</h2>
<p>昨今あらゆる分野やシーンで取り上げられる「サステナビリティ」ですが、それだけ人々の意識が高まっていると言えます。この結果はその表れの一端ではないでしょうか。<br />
購入者の満足度が上がり、売上もアップ、さらに環境や社会に良い影響を与えるなら、この課題に着手しない手はないでしょう。</p>
<h4>参考</h4>
<p><a href="https://www.ecommercetimes.com/story/sustainability-is-more-than-a-buzzword-for-e-commerce-survival-177393.html" target="_blank" rel="noopener">Sustainability Is More Than a Buzzword for E-Commerce Survival</a></p>


medium_mert-guller-jFBWOaoS-7o-unsplash.jpg

small_mert-guller-jFBWOaoS-7o-unsplash.jpg

thumbnail_mert-guller-jFBWOaoS-7o-unsplash.jpg

mert-guller-jFBWOaoS-7o-unsplash.jpg

Eコマースにおける購入の決め手は？(3)<br>鍵はSDGsにあり

Company

Our Solutions

Support

News

Blog

Blogブログ

カテゴリーから探す

年別から見る

記事一覧 - タグ: #ECO

2026/04/17

2025/12/26

2024/07/19

2023/10/05

2023/07/26