‹ ブック一覧へ戻る

【Concept】コンポーネント指向と状態管理の基本

📚 本ガイドブックは、モダンWeb開発の中核をなす*コンポーネント指向*と*状態管理（State Management）*の概念を理解し、従来のページ単位の開発から部品単位の開発へと設計思考を転換することを目的としています。jQueryなどを用いた直接的なDOM操作から、データ駆動型の宣言的UIへの変革をマスターしましょう。

コンポーネント指向とは：UIを部品で考える
比較：ページ単位（旧）vs コンポーネント単位（新）
「状態（State）」のメカニズム：画面が動く仕組み
実践：コンポーネントの分解と実装例
副作用（useEffect）：画面の外で起きることを管理する
グローバルな状態管理：Stateをコンポーネントの外で管理する
jQuery時代との決定的違いと保守性の向上
よくある質問とトラブルシューティング

1. コンポーネント指向とは：UIを部品で考える

概要・説明

コンポーネント指向とは、Webサイトの画面全体をひとつの大きな塊として捉えるのではなく、再利用可能な*小さな部品（コンポーネント）の組み合わせ*として構成する設計手法です。例えば、「ヘッダー」「商品カード」「サイドバー」といった単位で部品を作り、それらをパズルを組み立てるように配置していくことで、複雑なUIを効率的に構築できます。

コンポーネント化の3大メリット

メリット	説明
再利用性	一度作った部品を別のページや別のプロジェクトで使い回せます。
独立性	各部品が自己完結しているため、修正が他の場所に影響しにくくなります。
可読性	ファイルが小さく分割されるため、コードの意図が把握しやすくなります。

2. 比較：ページ単位（旧）vs コンポーネント単位（新）

従来のWeb開発（JSP, ASP, jQuery等）とモダンWeb（React, Next.js等）での設計思想の違いを整理します。

比較項目	従来のページ単位開発	モダンなコンポーネント指向
構成単位	ページ（HTMLファイル）全体	部品（Component）の組み合わせ
コード構成	HTML / CSS / JS がバラバラ	1つのコンポーネントにセットで定義
UIの作り方	命令的（「XXを書き換えろ」）	宣言的（「データがXXならこう表示」）
更新の仕組み	ページ全体の再読み込み / DOM直接操作	必要な部品のみが自動的に再描画
保守性	変更の影響範囲が予測しにくい	部品内で完結するため修正が容易

設計思想のイメージ図


graph TD
    subgraph "ページ単位 (Traditional)"
        P1[ページ全体] --> H1[HTMLファイル]
        P1 --> C1[CSSファイル]
        P1 --> J1[JSファイル]
        J1 -- "直接操作" --> H1
    end

    subgraph "コンポーネント指向 (Modern)"
        CompA["コンポーネントA<br/>(Header)"] --- CompB["コンポーネントB<br/>(ProductCard)"]
        CompA --- CompC["コンポーネントC<br/>(ProductCard)"]
        CompB --- CompD["コンポーネントD<br/>(Button)"]

        style CompA fill:#f9f,stroke:#333
        style CompB fill:#bbf,stroke:#333
        style CompC fill:#bbf,stroke:#333
        style CompD fill:#bfb,stroke:#333
    end

3. 「状態（State）」のメカニズム：画面が動く仕組み

モダンWebにおいて、画面の表示内容を決定するのは*状態（State）*と呼ばれるデータです。

状態（State）とは

コンポーネントが保持する「変化する内部的なデータ」のことです。

「ボタンがクリックされたか？」
「検索ボックスに入力された文字は何か？」
「APIから取得したデータリスト」

自動更新のフロー

モダンWebフレームワーク（React等）では、*「Stateが変わると、UIが自動的にリセット（再描画）される」*という強力な仕組みを持っています。


sequenceDiagram
    participant U as ユーザー
    participant S as 状態 (State)
    participant V as 仮想DOM (Virtual DOM)
    participant D as 実際の画面 (Real DOM)

    U ->> S: 1. 操作してデータを変更
    S ->> V: 2. 状態の変化を通知
    V ->> V: 3. 新しいUI構造を計算
    V ->> D: 4. 差分だけを適用（最小限の更新）

*ポイント*：開発者が「ここの文字を書き換えろ」とDOMに命令する必要はありません。開発者は「このStateならこのUIを表示する」というルール（宣言）を書くだけで、あとはフレームワークが自動で同期してくれます。

4. 実践：コンポーネントの分解と実装例

具体的に、「お気に入りボタン付きの商品カード」を例に考えてみましょう。

UIの分解（コンポーネント構成）

App（最上位）：複数の商品カードを並べる親画面
ProductCard（中間）：商品情報の枠組み。name と price をPropsで受け取る
LikeButton（末端）：お気に入り状態の管理と表示

コンポーネントの実装（子：LikeButton）

お気に入りボタンの状態管理に注目してください。


// components/LikeButton.tsx
import { useState } from 'react';

// 子コンポーネント：お気に入りボタン
export function LikeButton() {
  // liked が「状態（State）」、setLiked がそれを更新する関数
  const [liked, setLiked] = useState(false);

  return (
    <button onClick={() => setLiked(!liked)}>
      {liked ? '❤️ お気に入り済' : '🤍 お気に入りに追加'}
    </button>
  );
}

コンポーネントの実装（中間：ProductCard）

Propsで親からデータを受け取り、子コンポーネントを組み合わせます。


// components/ProductCard.tsx
import { LikeButton } from './LikeButton';

// Propsの型定義（TypeScript）
interface ProductCardProps {
  name: string;
  price: number;
}

// 親コンポーネント：商品カード
export function ProductCard({ name, price }: ProductCardProps) {
  return (
    <div style={{ border: '1px solid #ccc', padding: '16px', borderRadius: '8px' }}>
      <h3>{name}</h3>
      <p>価格：{price.toLocaleString()}円</p>
      <LikeButton />
    </div>
  );
}

コンポーネントの呼び出し（最上位：App）

ProductCard を実際に画面に並べる側のコードです。ここを見ることで「Props（引数）としてデータを渡す」イメージが掴めます。


// App.tsx
import { ProductCard } from './components/ProductCard';

// 商品データ（実際はAPIから取得する）
const products = [
  { id: 1, name: 'ノートPC', price: 120000 },
  { id: 2, name: 'キーボード', price: 8000 },
  { id: 3, name: 'マウス', price: 3500 },
];

export default function App() {
  return (
    <div>
      <h1>商品一覧</h1>
      {products.map((product) => (
        // Props として name と price を渡している
        <ProductCard key={product.id} name={product.name} price={product.price} />
      ))}
    </div>
  );
}

*出力例*：ProductCard が3つ並び、それぞれに独立した「🤍 お気に入りに追加」ボタンが表示されます。1つをクリックしても他のボタンには影響しません——なぜなら、それぞれの LikeButton が*独自のState*を持っているからです。

5. 副作用（useEffect）：画面の外で起きることを管理する

副作用とは

コンポーネントの「描画（レンダリング）」以外に発生する処理を*副作用（Side Effect）*といいます。代表的なものは以下の3つです。

*APIコール*：コンポーネントが表示されたとき、サーバーからデータを取得する
*タイマー・インターバル*：定期的に処理を実行する
*イベントリスナーの登録・解除*：ウィンドウサイズ変更の検知など

useEffect の基本形


// components/OrderList.tsx
import { useState, useEffect } from 'react';

interface Order {
  id: number;
  status: string;
}

export function OrderList() {
  const [orders, setOrders] = useState<Order[]>([]);
  const [loading, setLoading] = useState(true);

  // コンポーネントが「マウント（表示）」されたタイミングで実行される
  useEffect(() => {
    // APIからデータを取得
    fetch('/api/orders')
      .then((res) => res.json())
      .then((data: Order[]) => {
        setOrders(data);
        setLoading(false);
      });
  }, []); // ← [] は「最初の1回だけ実行」を意味する依存配列

  if (loading) return <p>読み込み中...</p>;

  return (
    <ul>
      {orders.map((order) => (
        <li key={order.id}>注文 #{order.id} - {order.status}</li>
      ))}
    </ul>
  );
}

useEffect の依存配列

useEffect の第2引数（依存配列）の意味を理解することがReact習得の鍵です。

依存配列の書き方	実行タイミング
`useEffect(() => {...}, [])`	マウント時に1回だけ
`useEffect(() => {...}, [userId])`	`userId` が変わるたびに
`useEffect(() => {...})`	毎回のレンダリング後（無限ループに注意）

6. グローバルな状態管理：Stateをコンポーネントの外で管理する

Props のバケツリレー問題

コンポーネントが深くネストされると、上位のStateを下位のコンポーネントまで渡すために多くの中間コンポーネントがPropsをただ「中継」するだけになります。これを*Props Drilling（バケツリレー）*と呼びます。


graph TD
    A[App - ユーザー情報State保持] -->|Props| B[Layout]
    B -->|Props| C[Sidebar]
    C -->|Props| D[UserMenu - ここで使いたい]
    style D fill:#fbb,stroke:#333
    style A fill:#bfb,stroke:#333

解決策1：React Context API（標準機能）

Reactに組み込まれているグローバルState共有の仕組みです。ログインユーザー情報・テーマカラーなど、アプリ全体で使うデータに適しています。


// context/UserContext.tsx
import { createContext, useContext, useState } from 'react';

interface User { name: string; role: string; }
const UserContext = createContext<User | null>(null);

// Provider：State の供給源
export function UserProvider({ children }: { children: React.ReactNode }) {
  const [user] = useState<User>({ name: '森田', role: 'admin' });
  return <UserContext.Provider value={user}>{children}</UserContext.Provider>;
}

// フック：どのコンポーネントからでも使える
export function useUser() {
  return useContext(UserContext);
}


// 深くネストされたコンポーネントでもPropsなしでアクセスできる
import { useUser } from '../context/UserContext';

export function UserMenu() {
  const user = useUser();
  return <p>ようこそ、{user?.name} さん</p>;
}

解決策2：外部ライブラリ（Zustand / Redux Toolkit）

アプリ全体の状態が複雑になってきたら、専用の状態管理ライブラリを検討します。

ライブラリ	特徴	向いているケース
Zustand	シンプル・軽量・学習コストが低い	中規模アプリ・まず試す
Redux Toolkit	厳格なアーキテクチャ・デバッグが強力	大規模チーム開発
React Query / TanStack Query	サーバーからのデータ取得・キャッシュ管理に特化	APIデータの管理

7. jQuery時代との決定的違いと保守性の向上

1. 命令的プログラミングの限界

jQueryでは「このボタンを押したら、このIDの要素を探して、クラスを削除して、テキストを書き換えて...」という*手順（命令）*を書きます。規模が大きくなると、どのコードがどのHTMLをいじっているのか把握できなくなり、スパゲッティコード化（*保守性の崩壊*）へ繋がります。


// jQuery（命令型）：処理の手順を細かく命令する
$('#likeButton').on('click', function () {
  const isLiked = $(this).hasClass('liked');
  if (isLiked) {
    $(this).removeClass('liked').text('🤍 お気に入りに追加');
    $('#likeCount').text(parseInt($('#likeCount').text()) - 1);
  } else {
    $(this).addClass('liked').text('❤️ お気に入り済');
    $('#likeCount').text(parseInt($('#likeCount').text()) + 1);
  }
});

2. 宣言的UIによる保守性の向上

Reactでは同じ機能を「データ（State）がどういう状態か」だけを定義します。


// React（宣言型）：データの状態だけを管理する
function LikeButton() {
  const [liked, setLiked] = useState(false);
  const [count, setCount] = useState(0);

  const handleClick = () => {
    setLiked(!liked);
    setCount(liked ? count - 1 : count + 1);
  };

  return (
    <button onClick={handleClick}>
      {liked ? '❤️ お気に入り済' : '🤍 お気に入りに追加'} ({count})
    </button>
  );
}

特徴	jQuery (直接操作)	React等 (状態管理)
整合性	自分で整合性を保つ必要がある	フレームワークが強制的に同期する
テスト	画面を実際に動かさないと難しい	データの変化だけでテストが可能
開発効率	規模に比例して複雑度が爆発	規模が大きくても複雑度を抑えられる

8. よくある質問とトラブルシューティング

Q1. 全てのボタンをコンポーネントにするべきですか？

A. *再利用性がある*、または*独自の内部状態を持っている*場合はコンポーネント化を推奨します。あまりに細分化しすぎると管理が大変になるため、まずは「再利用したい塊」から始めましょう。

Q2. 状態（State）が書き換わったのに、画面が更新されません。

A. 以下を順に確認してください：

直接代入していないか：state = newValue のように直接代入してはいけません。必ず setState などの更新関数を使ってください。
参照型データの更新：オブジェクトや配列の場合、中身だけを書き換えても検知されません。新しいオブジェクトとして作成（スプレッド構文 ... など）してセットする必要があります。


// NG：同じ配列オブジェクトを変更しているためStateが変わったと検知されない
items.push(newItem);
setItems(items);

// OK：新しい配列を作って渡す
setItems([...items, newItem]);

Q3. 「Props」と「State」の違いは何ですか？

項目	Props (プロップス)	State (ステート)
役割	親から子への「引数」	自分自身の「内部データ」
変更権限	子から変更することはできない	自分自身で自由に変更できる
イメージ	スマホの「設定情報」(外から来る)	スマホの「残バッテリー」(中で変わる)

Q4. useEffect の依存配列に何を入れればよいか分かりません。

A. useEffect 内で参照している変数（StateやProps）を依存配列に入れるのが基本ルールです。ESLintの eslint-plugin-react-hooks を導入すると、不足している依存配列を自動で警告してくれます。


React Hooksのルールを強制するESLintプラグイン
npm install --save-dev eslint-plugin-react-hooks

Q5. グローバルStateはいつ使えばよいですか？

A. 以下の場合にグローバルStateを検討してください。1) 同じデータを3階層以上の深さで複数コンポーネントが参照する場合。2) ログインユーザー情報・テーマ・言語設定など「アプリ全体の設定」を保持する場合。それ以外はローカルState（useState）で十分なことが多いです。

まとめ

本ガイドブックでは、モダンWeb開発の心臓部である *コンポーネント指向* と *状態管理* を解説しました。

最初の一歩：思考のアップデート

画面をパーツに分ける：1つのHTMLとしてではなく、部品の積み重ねとして見る。
命令を捨てる：要素を捕まえて書き換えるのをやめる。
データを中心に置く：データ（State）がどう変わるかだけを考え、UIはそれに従わせる。
副作用を分離する：描画以外の処理（APIコール等）は useEffect に切り出す。
グローバルStoreは最後の手段：まずローカルState、次にContext、最後に外部ライブラリ。

モダンWeb特有の「作り方」をマスターすることで、*メンテナンスしやすく、堅牢で、かつ美しいWebアプリケーション*をAIエージェントと共に爆速で開発できるようになります。

参考リンク一覧

リンク	詳細
React 公式ドキュメント（日本語）	useState・useEffect・Contextの真髄を学べます
TanStack Query（React Query）	サーバーデータのフェッチ・キャッシュ管理の定番
Zustand（状態管理）	シンプルなグローバルState管理ライブラリ
MDN: 状態管理の概念	技術的な深掘り

更新日時：2026 年 03 月 21 日