第1章: Reactとは何か — 設計哲学と宣言的UIの世界

Reactの本質 — UIは状態の関数である

Reactを一言で表すなら、「UIは状態の関数である」という思想に尽きます。 数式で書けば UI = f(state)。ある状態（state）を入力として渡せば、対応するUI（画面の見た目）が出力される。 これがReactの設計哲学の根幹です。

この考え方が革命的だった理由を理解するには、Reactが登場する以前のフロントエンド開発を振り返る必要があります。 jQueryに代表される従来の手法では、DOMを命令的（imperative）に操作していました。 「この要素を取得して」「テキストを変更して」「クラスを追加して」と、一つひとつの手順を開発者が記述する必要がありました。

たとえばToDoリストを考えてみましょう。命令的アプローチでは「リストにアイテムを追加する」「完了したアイテムに取り消し線を引く」「削除ボタンを押したら該当のDOM要素を消す」と、 状態が変わるたびに対応するDOM操作を漏れなく書く必要があります。 アイテムが100個、フィルター機能やソート機能が加わると、整合性を保つのは困難を極めます。

Reactの宣言的アプローチでは、開発者は「このstateの配列をもとに、こういうリストを表示する」と宣言するだけです。 stateが変われば、Reactが自動的にUIを更新してくれます。開発者は「今どういう状態か」だけを管理すればよいのです。

コンポーネントモデル — UIの構成単位

Reactでは、UIをコンポーネントと呼ばれる独立した部品に分割します。 ボタン、ヘッダー、サイドバー、カード — これらすべてがコンポーネントです。 コンポーネントは入れ子にでき、小さな部品を組み合わせて複雑なUIを構築します。

現在のReactでは関数コンポーネントが標準です。 JavaScriptの関数として定義し、JSX（後述）を返します。

// 関数コンポーネントの例
function Greeting({ name }) {
  return <h1>こんにちは、{name}さん！</h1>;
}

// 使用側
<Greeting name="太郎" />

Props — 親から子への一方向データフロー

コンポーネントに外部からデータを渡す仕組みがProps（プロパティ）です。 上の例では name="太郎" がPropsにあたります。 Propsは読み取り専用であり、子コンポーネントから変更することはできません。 この制約が、データの流れを予測可能にする鍵となっています。

children — 特殊なProp

コンポーネントの開始タグと閉じタグの間に挟んだ要素は、childrenという特殊なPropとして渡されます。 これにより、他のコンポーネントを「包む」コンポーネントを作ることができます。

// Cardコンポーネント — childrenを受け取って表示する
function Card({ title, children }) {
  return (
    <div className="card">
      <h2>{title}</h2>
      <div>{children}</div>
    </div>
  );
}

// 使用側 — 好きな中身を入れられる
<Card title="お知らせ">
  <p>明日はメンテナンスのためサービスを停止します。</p>
</Card>

コンポーネント合成の考え方

Reactでは継承よりも合成（Composition）が推奨されています。 小さなコンポーネントを組み合わせて大きなUIを構築するこのアプローチは、 コードの再利用性と保守性を飛躍的に高めます。 React公式ドキュメントでも「Reactを長く使ってきた中で、継承によるコンポーネント階層を使うべきケースは見つかっていない」と明記されています。

単方向データフロー — 予測可能なデータ管理

Reactのデータは常に親から子へ、一方向に流れます。 これを「単方向データフロー（Unidirectional Data Flow）」と呼びます。

graph TD
  A[親コンポーネント\nstate: items] -->|props| B[子コンポーネントA\nリスト表示]
  A -->|props| C[子コンポーネントB\n件数表示]
  B -->|コールバック関数| A
  C -->|コールバック関数| A

  style A fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style B fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style C fill:#8b5cf6,stroke:#6d28d9,color:#fff

親コンポーネントが状態（state）を持ち、子コンポーネントにPropsとして渡します。 子が親のstateを変更したい場合は、親から渡されたコールバック関数を呼び出します。 直接stateを書き換えるのではなく、「親に変更を依頼する」という仕組みです。

function Parent() {
  const [count, setCount] = useState(0);

  // 子に渡すコールバック関数
  const handleIncrement = () => setCount(count + 1);

  return <Child count={count} onIncrement={handleIncrement} />;
}

function Child({ count, onIncrement }) {
  // 子は直接stateを変更せず、コールバックを呼ぶ
  return <button onClick={onIncrement}>カウント: {count}</button>;
}

双方向バインディングとの対比

AngularやVueの一部機能では、UIの変更が自動的にデータに反映され、データの変更も自動的にUIに反映される双方向バインディングが採用されています。 一見便利ですが、アプリケーションが大規模になると「誰がこのデータを変更したのか」が分かりにくくなるという課題があります。

Reactの単方向データフローでは、データの変更箇所が明確です。 バグが発生した場合も、stateの変更をトップダウンに追跡すれば原因にたどり着けます。 この予測可能性こそが、大規模アプリケーション開発でReactが選ばれる理由の一つです。

JSX — JavaScriptの中のUI

ReactのコードにはHTMLのような記法が登場しますが、これはJSX（JavaScript XML）と呼ばれるJavaScriptの構文拡張です。 テンプレート言語ではなく、あくまでJavaScriptの表現力を維持したまま、UIを直感的に記述できる仕組みです。

JSXは最終的にJavaScriptの関数呼び出しに変換されます。 たとえば以下のJSXは：

<h1 className="title">Hello, world!</h1>

内部的には次のように変換されます：

React.createElement('h1', { className: 'title' }, 'Hello, world!')

つまりJSXは React.createElement() のシンタックスシュガー（糖衣構文）です。 JSXを使わなくてもReactは書けますが、UIの構造が視覚的に分かりやすくなるため、ほぼすべてのReactプロジェクトで採用されています。

なぜReactが支持されるのか

2013年にFacebookがオープンソースとして公開して以来、Reactはフロントエンド開発の事実上の標準となりました。 その圧倒的な普及度を示すデータがあります：

• 週間9,600万ダウンロード（npm、2026年3月時点）
• GitHub Stars 244,000以上
• 2023年Stack Overflow調査で最も使用されているWebフレームワーク（40.58%）

Reactがこれほど支持される理由は、技術的な優位性だけではありません。

「Learn once, write anywhere」

Reactの思想はWeb以外にも広がっています。 React Nativeを使えば同じReactの知識でiOS/Androidアプリが開発でき、 さらにReact Native for Windows/macOSでデスクトップアプリまでカバーできます。 一度Reactを学べば、さまざまなプラットフォームで活用できるのです。

巨大なエコシステム

状態管理（Redux、Zustand）、ルーティング（React Router）、UIライブラリ（MUI、shadcn/ui）、 データフェッチ（TanStack Query）、メタフレームワーク（Next.js、Remix）など、 Reactを取り巻くエコシステムは他のフレームワークを圧倒する規模を誇ります。 何か実現したいことがあれば、大抵は成熟したライブラリが見つかります。

また、企業の採用においてもReactの需要は圧倒的です。 フロントエンドエンジニアの求人で最も要求されるスキルがReactであり、 学習への投資対効果が非常に高い技術と言えるでしょう。