Claude Code で React/TypeScript フロントエンドを構築する: 実践ガイド (2026)
はい、Claude Code だけで React フロントエンドを最初から最後まで構築できます。プロジェクトのセットアップ、TypeScript コンポーネントの生成、状態やデータの扱い、デザインシステムに沿ったスタイリング、テストの作成、パフォーマンス最適化まで一通りこなせます。Claude Code はリポジトリ全体を読み取り、複数ファイルを編集し、開発サーバーやテストをループで実行するエージェント型 CLI です。だからこそ React/TS と相性が良いのです。6 ステップのワークフロー:
- Claude Code をインストールし、Vite の React-TS アプリを scaffold する
- スタックと規約を固定する
CLAUDE.mdを書く - 範囲を絞ったプロンプトからコンポーネントを生成し、受け入れる前に diff をレビューする
- TanStack Query + Router でデータと状態を追加する
- テスト(Vitest + RTL)を書き、アクセシビリティを直す
- 遅延読み込み、メモ化、バンドル分割で最適化する
Claude Code は React/TS フロントエンドを構築できるか?
はい。Claude Code は単一コンポーネントから、テストとパフォーマンス調整を含む本格的な機能まで、完全な React/TypeScript フロントエンドを構築できます。まだ検討中の方への短い答えはこれです。ただ、コードを貼り付けるチャットボットよりなぜうまくいくのかを理解するには、Claude Code の何が違うのかを知る必要があります。
Claude Code はエージェント型の CLI です。コピー用の断片を返すのではなく、プロジェクトツリーを直接読み取り、複数ファイルを同時に開き、仕様どおりに編集し、コマンド(開発サーバー、テスト、型チェック)を実行して出力を読み、修正を続けます。この「リポジトリを読む → 編集する → 実行する → エラーを読む → また直す」というループこそが React/TS に向いている理由です。実際のフロントエンドプロジェクトは常に相互に絡み合う部品を持つからです。新しいコンポーネントは別ファイルの型を必要とし、正しい import を必要とし、既存のテーマや既存のテストに合わせる必要があります。単一のプロンプトしか見えないモデルにはこうした制約が見えませんが、Claude Code はプロジェクト全体をコンテキストとして保持しているので見えるのです。
実際には、変更のたびに型チェックとテストを走らせるときに最も力を発揮します。誤った型や壊れた import が、ビルド時に襲ってくるのを待たずに同じセッション内で表面化するからです。まったくの初心者なら、まず Claude Code とは何か、どう動くのかを読んでエージェントモデルを押さえてから飛び込むとよいでしょう。
セットアップ: Claude Code のインストール + React/TS プロジェクトの scaffold
最初のプロンプトを打つ前に 3 つ: Claude Code をインストールし、React-TS のひな型を scaffold し、プロジェクトディレクトリ内で Claude Code を起動します。
- Claude Code をインストールする。OS ごとの手順は Claude Code のインストール方法のガイドを参照してください。インストールできたら
claude --versionを実行して CLI が準備できたか確認します。 - Vite + React + TypeScript アプリを作成する。Vite は React の SPA 向けの軽量な既定選択肢です:
npm create vite@latest my-app -- --template react-ts
cd my-app
npm install
npm run dev
これで src/ 構造、TypeScript の設定、localhost:5173 の開発サーバーが用意されます。SPA ではなく Next.js を狙う場合は、末尾の FAQ を参照してください。
- リポジトリ内で Claude Code を開く。プロジェクトルートから次を実行します:
claude
Claude Code は package.json と tsconfig.json からこれが React-TS プロジェクトだと認識します。ここからは平易な日本語で指示を出せます。ひとつ小さな習慣として、実作業を任せる前に Read the src/ structure and summarize the stack in use と頼み、本当にプロジェクトを「理解」しているか確認しましょう。
React/TS プロジェクト向けに CLAUDE.md を設定する
これは 3 社中 2 社の競合が飛ばすステップですが、下流のすべての品質を左右します。CLAUDE.md は Claude Code が毎セッション自動で読むファイルで、毎回スタックやルールを繰り返さなくて済むよう一度だけ書く「プロジェクト規約」だと考えてください。フロントエンドなら、実用的なテンプレートは次のようになります:
# CLAUDE.md - React/TS project
## Stack
- Vite + React 19 + TypeScript (strict mode)
- Styling: Tailwind CSS (or MUI v7 - pick one, don't mix)
- Data: TanStack Query; Routing: TanStack Router
- Testing: Vitest + React Testing Library
## Code conventions
- Functional components + hooks only. No class components.
- TypeScript strict: NO `any`. If a type is unclear, ask first.
- Absolute imports via the `@/` alias (already set in tsconfig).
- Every component has explicit prop types (a `XxxProps` interface).
- Complex components ship with a test.
## Workflow
- Before editing multiple files, outline a short plan for me to approve.
- After each change: run `npm run typecheck` and the relevant tests.
- Don't install new dependencies without asking.
最も価値がある行は 「no any」、「absolute imports」、「run typecheck after every change」です。これらは制約がないときに Claude Code が犯しがちなミスをまさに防ぎます。このファイルの書き方をさらに掘り下げるには、CLAUDE.md 完全ガイドを参照してください。フロントエンド作業での要点はこうです。スタックと「受け入れる前に diff をレビューする」ルールをはっきり固定するほど、出力は毎回ぶれるのではなく、あなたのプロジェクトのスタイルに合致します。
最初の React/TS コンポーネントを生成する(実際の手順)
ここが核心です。プロンプトの書き方が結果の 80% を決めます。良いプロンプトは、目的だけでなく、スタック + 制約 + 扱うべき状態を明示します。比べてみましょう:
- 弱いプロンプト: 「UserCard コンポーネントを作って。」 → Claude Code は props を推測し、スタイリングを推測し、勝手にライブラリを引き込むかもしれません。
- 良いプロンプト: 「
src/components/にUserCardコンポーネントを作って。型付き props:user(id, name, avatarUrl, role)、isLoading、error。読み込み中はスケルトンを表示;エラー時はメッセージを表示;既存テーマを使って Tailwind でスタイリング。基本的なテストファイルを追加。新しい依存関係は追加しないで。」
2 番目のプロンプトなら、Claude Code はたいてい一度に全部作ります: UserCard.tsx、props インターフェース、3 つのレンダー分岐(loading/error/data)、そして UserCard.test.tsx。生成されるインターフェースの例:
interface User {
id: string;
name: string;
avatarUrl: string;
role: string;
}
interface UserCardProps {
user?: User;
isLoading?: boolean;
error?: string | null;
}
飛ばしてはいけないステップ: 受け入れる前に diff をレビューする。Claude Code は変更をファイルごとに diff として表示します。よく読んでください。import が実在するか、他ファイルをこっそり触っていないか、型が any に緩められていないかを確認します。満足できる部分は受け入れ、残りは修正を頼みます(例: 「スケルトンを独立したコンポーネントに切り出して」)。受け入れたら、そのセッション内で npm run typecheck とテストを走らせましょう。
状態、データ取得、ルーティング
2026 年の現代的な React プロジェクトでは、Claude Code をいきなり Redux に既定させないでください。多くのケースでより無駄のないパターンはこうです: ローカル状態には hooks、サーバー状態には TanStack Query、ナビゲーションには TanStack Router、そしてグローバル状態(Zustand/Context)は、本当に多くの分岐で共有される状態があるときだけ使います。
Suspense 経由で loading/error を組み込んだ取得フックを生成するサンプルプロンプト:
Create a `useUser(id)` hook using TanStack Query `useSuspenseQuery`,
fetching from /api/users/:id and returning a typed User.
Wrap UserCard in a <Suspense fallback> and an error boundary.
Don't create global state.
useSuspenseQuery(TanStack Query v5)は、データが準備できるまでコンポーネントのレンダリングを「サスペンド」させ、loading 状態を親の <Suspense> へ押し上げます。if (isLoading) をあちこちに散らばせる代わりになり、明らかにすっきりしたコードになります(TanStack Query ドキュメント, 2026 を参照)。委譲するときのルール: 「サーバー状態は Query に入れる、グローバルストアに詰め込まない」と明示してください。さもないと Claude Code は必要のない大きなストアで過剰に作り込みがちです。
スタイリングとレスポンシブ(デザインシステム、ダークモード)
Claude Code はコンポーネントを素早くスタイリングしますが、止めないと平気で色や余白をハードコードします。デザインシステムに従わせる方法: CLAUDE.md にトークン/テーマのみを使うと宣言し、プロンプトで具体的に指定します。
- トークンに従い、ハードコードしない: 「既存の設定の Tailwind クラスを使って(余白と色はテーマから);生の hex 値は書かないで。」MUI v7 なら: 「
sxとテーマ経由でスタイリング、theme.paletteを使い、色はハードコードしないで。」 - レスポンシブ: 望むブレークポイントを名指しする — 「モバイルでは 1 列、768px 以上で 2 列に切り替え。」
- ダークモード: 既存のテーマ変数 /
dark:クラスを使うよう頼み、並行するテーマ機構を新しく作らせないこと。
ここでも diff をレビューし、新しい UI ライブラリを紛れ込ませていないか確認します。見た目や体験の面をさらに掘り下げたいなら、Claude Code で UI/UX をデザインするという記事が、洗練され一貫したインターフェースの作り方に特化しています。
コンポーネントのテストとアクセシビリティ
これは競合記事の大きな盲点です。テストと a11y をついでに触れるだけです。しかしコンポーネントの本当のライフサイクルには両方が含まれます。Claude Code がテストを上手に書けるのは、まさにそれを実行し、緑になるまで直し続けられるからです。
Vitest + React Testing Library でのテスト。効果的なプロンプトはカバーすべき分岐を明示します:
Write tests for UserCard with Vitest + React Testing Library:
- render loading state -> shows a skeleton
- render with a user -> shows name and role
- render with an error -> shows the error message
Run the tests and fix until they pass.
生成されるテストケースの例:
it('shows a message when there is an error', () => {
render(<UserCard error="Failed to load" />);
expect(screen.getByText('Failed to load')).toBeInTheDocument();
});
アクセシビリティ。ここは、促さないと Claude Code が忘れがちなところです。コンポーネントが動いたら、直接のタスクを渡します: 「UserCard のアクセシビリティを監査して直して: role/aria が適切か、アバター画像に alt テキストがあるか、キーボード操作できるか、色コントラストが十分かを確認して。」すると alt を追加し、正しい aria-label/role を付け、フォーカスを調整します。それでも、実際にコンポーネントを Tab で辿って確認しましょう。a11y は「正しいと思い込む」のが簡単です。
パフォーマンス最適化(遅延読み込み、memo、バンドル)
アプリが大きくなったら Claude Code に最適化を頼みます。ただし早すぎず、意図的に。
- ルート単位のコード分割:
React.lazy+<Suspense>でページごとにバンドルを分割し、必要なものだけ読み込みます(React ドキュメント -lazy, 2026 を参照)。プロンプト: 「ルートを React.lazy + Suspense に移してバンドルを分割して。」 - 効くところをメモ化する: 高コストな計算には
useMemo、安定した props で頻繁に再レンダーするコンポーネントにはmemo。何でも包まないこと — 不用意なメモ化は得より損になり得ます。 - 無駄な再レンダーを見つける: 「<コンポーネントのリスト> の不要な再レンダーを見つけて修正案を出して。」Claude Code はコンポーネントツリー全体を読めるので、推測ではなく実際の原因を指し示せます。
率直な警告: 早すぎる最適化は、速くなる保証もないのにコードを読みにくくします。計測(バンドルサイズ、React DevTools Profiler)して実際の問題があるとわかってから、初めて最適化しましょう。
あらかじめ用意されたフロントエンドスキルで加速する(AgentKit)
プロジェクトごとに CLAUDE.md を書き直し、React/TS 規約を固定し、「Suspense を使って」「テーマに従って」と毎回念押しするのは面倒です。近道があります: あらかじめ用意されたフロントエンドスキルを使うのです。具体的には、AgentKit の ak-frontend-development スキルが現代的な React/TS パターン — 関数コンポーネント、React.lazy/Suspense、useSuspenseQuery、MUI v7、TanStack Router — をパッケージ化しているので、毎回説明し直さなくても Claude Code がすぐに適用します。
混同を避けるために: ここでの AgentKit は Claude Code 向けのキット(agentkit.best、ak CLI)であり、「OpenAI の AgentKit」ではありません。まず全体像を把握したいなら、AgentKit とは何か、それに価値はあるかを参照してください。スキルという概念が初めてなら、Claude Code のスキルとは何かを読んでください。ak-frontend-development スキルは Engineer Kit に含まれます。完全な内訳は Engineer Kit レビュー(ak-frontend-development スキル付き)にあります。
Claude Code に最初から正しく React を作らせたいですか?Engineer Kit($99、サイトに継続課金の記載なし)は ak-frontend-development を含む 60 以上のスキルを、返金保証と生涯アップデート付きでまとめています — 頻繁にフロントエンドを作り、繰り返しのセットアップを省きたい人に向いています。
Claude Code が React をうまく作れないのはいつか?よくある失敗パターン
正直さこそ、競合が避けるところです。Claude Code は完璧ではありません — 弱点を先に知っておけば、要所を守れます。
- 幻の import / 誤ったライブラリバージョン。インストールしていないパッケージから import したり、古いバージョンの API を使ったり(例: プロジェクトが v5 なのに React Query v4 のパターン)します。対策:
CLAUDE.mdにバージョンを固定し、すぐに型チェックを走らせます — 壊れた import は即座に表面化します。 - 過剰設計。単純なフォームに、まるごと状態機械が付いてしまうことがあります。対策: 望む複雑さを明示します(「シンプルに、新しいライブラリなしで」)。
- プロップドリリング。context/コンポジションを使わず、多くの層に props を渡し続けます。対策: コンポーネントツリーが深くなったらアーキテクチャレビューを頼みます。
- アクセシビリティを忘れる。前述のとおり — a11y は促さないと既定で抜け落ちやすいです。
- 古い React API。ときに Suspense/Query ではなく、旧式の
useEffectでのデータ取得に手を伸ばします。対策:CLAUDE.mdに現代的なパターンを固定します。
どの対策にも共通する筋はこうです: すぐに diff をレビューし、テスト/型チェックを走らせ、盲目的に受け入れない。これは「AI スロップ」— 動くけれど雑で保守しにくいコード — を避けることにもつながります。
よくある質問(FAQ)
Claude Code は npm run dev やテストを自分で実行しますか?
はい。Claude Code はプロジェクト内でターミナルコマンドを実行します — 開発サーバーの起動、テストの実行、型チェック — そして出力を読んで自ら修正します。変更のたびにテスト/型チェックを頼む習慣をつけ、バグを早く表面化させましょう。
Vite だけでなく Next.js にも使えますか?
どちらも使えます。Claude Code は特定のフレームワークに縛られません。プロジェクトがきちんと構成されていれば、Next.js、Vite、Remix、React Native で動きます。正しい規約に従わせるため、CLAUDE.md にフレームワークを宣言するだけです(例: Next.js の App Router)。
使う前に React を知っている必要はありますか?
知っておくべきです。Claude Code はコードを速く書きますが、diff を読み、どこで間違えたかを見抜き、正しい制約を設定するには十分な React/TS の知識が要ります。まったくの初心者でも学べますが、理解できないコードを受け入れてはいけません — それはほどきにくいバグの元です。
Cursor や VS Code と併用できますか?
はい。Claude Code は CLI で、どのエディタとも並行して動きます。多くの開発者は、エージェント的な作業(多数のファイルの生成/編集、テスト実行)を Claude Code に任せつつ、読み書きや手直しのために VS Code を開いたままにします。2 つのツールは互いに補完し合います。
古いコードや誤ったライブラリバージョンを避けるには?
CLAUDE.md に具体的なバージョンを固定し、すぐに型チェックを走らせるよう頼み、望む現代的なパターン(Suspense、TanStack Query v5)を明示します。古い API に手を伸ばすのを見たら指摘し、最新のドキュメントに更新するよう伝えます。
フロントエンド作業向けのあらかじめ用意されたスキルはありますか?
はい。AgentKit の ak-frontend-development スキル(Engineer Kit、agentkit.best)は現代的な React/TS パターンをパッケージ化しており、プロジェクトごとに規約を設定しなくても Claude Code がすぐに適用します。これは Claude Code 向けの AgentKit で、OpenAI の AgentKit とは異なります。
まとめと次のステップ
ワークフローは 6 つの反復可能なステップに集約されます: インストール + scaffold → CLAUDE.md を書く → 範囲を絞ったプロンプトでコンポーネントを生成し、常に diff をレビューする → TanStack Query/Router で状態/データを追加する → テストして a11y を直す → 必要になったらパフォーマンスを最適化する。鍵は「長いプロンプト」ではなく、明確な制約 + diff のレビュー + すぐにテストを走らせることです。次は: インターフェースを底上げするために Claude Code で UI/UX をデザインするを読み、フルスタックアプリのために Claude Code でバックエンド API を構築すると組み合わせ、変更をコミットするときは Claude Code での git ワークフローを標準化しましょう。まだ環境を整えているところですか?Claude Code のインストールに戻りましょう。そして、フロントエンド構築が日々の仕事なら、あらかじめ用意されたスキル付きの AgentKit バンドル — 今なら $149($198 から)が、繰り返しのセットアップをかなり省いてくれます。