1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@GeneLab_999

Reactってなんだ？ — 「できること」と「できないこと」の境界線がわかれば技術選定で迷わない

1
Posted at

この記事の対象読者

  • フロントエンド開発に興味があるが、Reactを触ったことがない方
  • jQueryやVanilla JSからの脱却を考えている方
  • 「React、Vue、Angular...結局どれを選べばいいの？」と迷っている方
  • Reactの記事やチュートリアルを読む前に、全体像を把握したい方

この記事で得られること

  • Reactが「UIライブラリ」であり「フレームワーク」ではないことの意味
  • コンポーネント、State、Props、仮想DOMといった中核概念の直感的な理解
  • Reactが得意なこと・苦手なことの明確な境界線
  • React 19の最新動向と、2026年現在のエコシステムの全体像
  • 学習ロードマップと、次に何を学ぶべきかの指針

この記事で扱わないこと

  • Reactのインストール手順やチュートリアル（公式ドキュメントが最良）
  • Next.js / Remix 等のメタフレームワークの詳細比較
  • React Native（モバイル開発）の話題

1. Reactという「演出家」 — UIライブラリの正体

1.1 なぜReactが生まれたのか

2013年、Meta（当時Facebook）のエンジニアJordan Walkeが、ある問題に直面していた。Facebookのニュースフィードは「いいね」の数、コメント、通知バッジ、メッセージの未読数...と画面上のあちこちで状態がリアルタイムに変わる。jQueryで一つ一つDOMを手動で書き換えていたら、コードはスパゲッティ化し、バグは際限なく湧いてくる。

「画面の状態が変わったら、変わった部分だけを自動で効率よく再描画してくれる仕組みがあればいいのに」

この発想から生まれたのがReactだ。

Reactは正式には「A JavaScript library for building user interfaces」と定義されている。ライブラリであってフレームワークではない。この違いが、Reactの「できること」と「できないこと」を理解するうえで決定的に重要になる。

1.2 「演出家」のメタファーで理解するReact

Reactの世界を、舞台演劇に例えて考えてみよう。この比喩は記事全体を通して使うので、ここで登場人物を紹介する。

舞台演劇 React 役割
演出家 React本体 舞台全体の進行を管理する
役者 コンポーネント それぞれの役割を演じる最小単位
台本の指示 Props 演出家から役者へ渡される「こう演じてくれ」という指示
役者の感情状態 State 役者自身が持つ、場面に応じて変わる内面の状態
リハーサル 仮想DOM 本番前に「次の場面」をシミュレーションする工程
本番の舞台 実DOM（ブラウザ） 観客（ユーザー）が実際に目にする画面

演出家（React）の仕事はシンプルだ。役者（コンポーネント）の感情（State）が変わったら、リハーサル（仮想DOM）で「次に舞台がどう見えるべきか」を計算し、本番の舞台（実DOM）の変更が必要な部分だけを最小限の手間で書き換える。

この仕組みこそが、ReactがUIライブラリとして圧倒的に支持されている理由だ。

2. Reactの中核概念 — 5つのキーワード

前の章で登場した「舞台演劇」の比喩を使いながら、Reactの中核概念を一つずつ解きほぐしていく。

2.1 コンポーネント — 一人ひとりの「役者」

Reactの最も根本的な考え方は、UIを独立した部品（コンポーネント）に分解することだ。

舞台演劇では、それぞれの役者が自分の役を持っている。「主人公」「ヒロイン」「ナレーター」はそれぞれ独立した存在で、自分のセリフと演技に責任を持つ。Reactのコンポーネントもまったく同じで、「ヘッダー」「サイドバー」「記事カード」「いいねボタン」がそれぞれ独立した部品として存在する。

クリックでソースコードを展開 
// 「いいねボタン」という一人の役者
function LikeButton({ count }) {
  const [likes, setLikes] = React.useState(count);

  return (
    <button onClick={() => setLikes(likes + 1)}>
      ❤️ {likes}
    </button>
  );
}

// 「記事カード」という別の役者
function ArticleCard({ title, author }) {
  return (
    <div className="card">
      <h2>{title}</h2>
      <p>by {author}</p>
      <LikeButton count={0} />
    </div>
  );
}

ここで重要なのは、LikeButtonはArticleCardの「中」に配置されているが、いいねのカウントという自分の仕事は自分で管理しているという点だ。まさに役者が自分のセリフに責任を持つのと同じ構造になっている。

2.2 JSX — 役者が読む「台本」のフォーマット

上のコードで<button>や<div>がHTMLのように見えたかもしれないが、これは実はJavaScriptだ。ReactではJSX（JavaScript XML）という記法で、JavaScriptの中にHTMLライクな構文を書くことができる。

// これはHTMLではない。JavaScriptだ。
const element = <h1>Hello, {userName}!</h1>;

舞台の台本が「セリフ」と「ト書き（演出指示）」を一つの文書にまとめているように、JSXは「見た目（HTML的な構造）」と「ロジック（JavaScript）」を一つのファイルにまとめる。

JSXはブラウザがそのまま解釈できるわけではない。Babel等のトランスパイラが通常のJavaScript（React.createElement()呼び出し）に変換してからブラウザに渡される。

2.3 Props — 演出家から役者への「指示書」

Propsは「properties（プロパティ）」の略で、親コンポーネントから子コンポーネントへ渡されるデータだ。

演出家が役者に「この場面では怒りを込めてセリフを言ってくれ」と指示を出すように、親コンポーネントは子コンポーネントに「このデータを使ってレンダリングしてくれ」と指示を出す。

// 親（演出家）が子（役者）に指示を渡す
<ArticleCard title="Reactってなんだ？" author="GeneLab_999" />

Propsの鉄則は読み取り専用であること。役者が勝手に台本を書き換えてはいけないのと同じで、子コンポーネントは受け取ったPropsを変更してはならない。

2.4 State — 役者の「感情状態」

Stateはコンポーネント自身が持つ、時間とともに変化するデータだ。

さっきのLikeButtonでlikesがStateにあたる。ボタンがクリックされるたびに数値が増えていく。この「役者の感情が変わる」瞬間がReactにとって最も重要なイベントで、Stateが変わると演出家（React）は自動的に「次の舞台がどう見えるべきか」を再計算する。

const [likes, setLikes] = React.useState(0);
// likes: 現在の感情状態（値）
// setLikes: 感情を変える関数（状態更新関数）

PropsとStateの違いを一言で表すなら、Propsは外部から渡されるもの、Stateは自分の内部で管理するものだ。演出家からの指示（Props）は変えられないが、役者自身の感情（State）は場面に応じて変わる。

2.5 仮想DOM — 本番前の「リハーサル」

Reactの高速な画面更新を支えるのが**仮想DOM（Virtual DOM）**の仕組みだ。

ブラウザのDOM操作は重い処理だ。画面上の要素を直接いじるたびに、ブラウザはレイアウトの再計算やスタイルの再適用を行う。舞台演劇で言えば、セリフ一つ変えるたびに照明・音響・セット全部を組み直すようなものだ。

Reactは、この問題をリハーサル方式で解決する。

  1. Stateが変わると、Reactはメモリ上に新しい仮想DOMツリーを作る（リハーサル）
  2. 前回の仮想DOMと比較して差分を検出する（前回との違いを洗い出す）
  3. 差分だけを実際のブラウザDOMに反映する（必要な場面だけ本番に反映）

この「リハーサル→差分検出→最小限の更新」という流れが、Reactのパフォーマンスの秘密だ。

3. Reactの現在地 — 数字で見る圧倒的シェア

概念の話が続いたので、ここでReactが2026年現在どれほど使われているかを確認しておこう。

指標 数値 出典
Stack Overflow 2025 利用率 44.7%（Webフレームワーク中2位） Stack Overflow Developer Survey 2025
世界のWebサイト利用数 1,100万サイト以上 W3Techs / BuiltWith
npmパッケージの最新バージョン v19.2.5（2026年4月8日リリース） npm
GitHubスター数 約23万 GitHub
採用企業 Meta, Netflix, Airbnb, Uber, PayPal, Tesla 他 各社技術ブログ

Stack Overflow Developer Survey 2025では、Reactの利用率は前年の39.5%から44.7%に上昇した。2位のAngular（18.2%）、3位のVue.js（17.6%）に対してダブルスコア以上の差をつけている。

この数字が意味するのは、Reactを学べばフロントエンド開発の求人の半分近くに対応できるということだ。技術選定で「とりあえずReact」が選ばれる理由は、技術的な優位性だけでなく、このエコシステムの厚みにもある。

4. Reactの「できること」 — 演出家の得意技

では本題の「できること」と「できないこと」の境界線に入ろう。まずは得意技から。

4.1 コンポーネントベースのUI構築

Reactの最大の強みは、UIを再利用可能な部品として組み立てられることだ。一度作った「いいねボタン」は、記事ページでもプロフィールページでもコメント欄でも使い回せる。

このツリー構造は、舞台の組織図そのものだ。演出家（App）の下に各セクションリーダー（Header、Main、Footer）がいて、その下に個々の役者（Logo、NavBar、ArticleCard...）が配置される。

4.2 宣言的UI — 「何を表示するか」だけ書けばいい

jQueryの時代は「ボタンをクリックしたら、まずこのdivを探して、テキストを書き換えて、クラスを追加して...」と手続き的に画面操作を記述していた。

Reactは宣言的だ。「この状態のときは、こう見えるべき」を書くだけで、実際のDOM操作はReactが面倒を見てくれる。

// 宣言的: 「状態に応じた見た目」を宣言するだけ
function Greeting({ isLoggedIn }) {
  return isLoggedIn 
    ? <h1>おかえりなさい！</h1> 
    : <h1>ログインしてください</h1>;
}

演出家に「この場面ではこうあるべきだ」と伝えれば、照明もセットも衣装も演出家が段取りしてくれる。開発者はDOMの操作方法を考える必要がない。

4.3 リアクティブな画面更新

Stateが変わった瞬間、関連するコンポーネントが自動的に再レンダリングされる。手動でDOMを更新するコードは一行も書かなくていい。

クリックでソースコードを展開 
function Counter() {
  const [count, setCount] = React.useState(0);

  return (
    <div>
      <p>カウント: {count}</p>
      <button onClick={() => setCount(count + 1)}>+1</button>
      <button onClick={() => setCount(count - 1)}>-1</button>
      <button onClick={() => setCount(0)}>リセット</button>
    </div>
  );
}
// countが変わるたびに、<p>の表示が自動で更新される
// DOM操作のコードは一切書いていない

4.4 豊富なエコシステムとコミュニティ

Reactは「ライブラリ」であるがゆえに、足りない機能は外部パッケージで補うカルチャーが成熟している。たとえばUIに動きをつけたいならReactアニメーションライブラリを導入すればいいし、アイコンが欲しければReactアイコンライブラリをインストールするだけだ。

この「必要なものだけ選んで組み合わせる」自由度の高さが、Reactのエコシステムを世界最大規模に成長させた。

4.5 マルチプラットフォーム展開

React本体はWebブラウザ向けだが、同じコンポーネントの考え方をモバイルアプリ（React Native）やデスクトップアプリ（Electron + React）にも応用できる。一度Reactの考え方を身につければ、その知識は複数のプラットフォームで活きる。

5. Reactの「できないこと」 — 演出家の管轄外

ここが最も重要なセクションだ。Reactは万能ではない。「演出家」は舞台上の演技の段取りには長けているが、劇場の建設、チケット販売、お客さんの案内までは管轄外だ。

5.1 ルーティング — 「別の舞台への移動」

Reactは「今この画面をどう見せるか」を管理するが、URLに応じてどの画面を表示するか（ページ遷移）は管轄外だ。SPAで/aboutにアクセスしたらAboutページを表示する、といった制御にはReact RouterやTanStack Routerなどの別ライブラリが必要になる。

5.2 グローバルな状態管理 — 「全役者の連携」

小さなアプリなら各コンポーネントが自分のStateを持てば十分だが、アプリが大きくなると「ログインユーザー情報」「カート内容」「テーマ設定」など、複数のコンポーネントで共有すべき状態が出てくる。React組み込みのContext APIで対応できるケースもあるが、大規模になるとZustand、Jotai、Redux Toolkitといった外部の状態管理ライブラリの出番だ。

5.3 データフェッチ — 「劇場の外との連絡」

APIからデータを取得する機能はReactに組み込まれていない。fetchやAxiosで自前実装するか、TanStack Query（旧React Query）のような専用ライブラリを使うことになる。

React 19で追加されたuseフックにより、Promise/Contextの取り扱いが改善されたが、データフェッチのキャッシュや再取得の管理まではカバーされていない。本格的なデータフェッチにはTanStack Queryが事実上の標準だ。

5.4 スタイリング — 「衣装デザイン」

Reactにはスタイリング機構が組み込まれていない。CSSをどう管理するかは完全に開発者次第だ。CSS Modules、Tailwind CSS、styled-components、Emotion...選択肢が多すぎて、初心者が最も戸惑うポイントの一つかもしれない。

5.5 サーバーサイドレンダリング（SSR）— 「舞台中継」

React単体はクライアント（ブラウザ）でのレンダリングしかできない。SEO対策やパフォーマンス向上のためにサーバーサイドでHTMLを生成したい場合は、Next.jsやRemixといったメタフレームワークが必要になる。

5.6 フォームバリデーション — 「台本の校正」

フォームの入力値チェック（バリデーション）の仕組みもReact本体にはない。React Hook FormやZodと組み合わせて実装するのが一般的だ。

できること・できないことの全体像

カテゴリ Reactでできる？ 必要な追加ツール
UI構築・コンポーネント分割 できる —
リアクティブな画面更新 できる —
JSXによる宣言的UI記述 できる —
ページ遷移（ルーティング） できない React Router / TanStack Router
グローバル状態管理 △ Context APIで簡易対応 Zustand / Jotai / Redux Toolkit
APIデータ取得 できない TanStack Query / SWR
スタイリング できない Tailwind CSS / CSS Modules / styled-components
SSR / SSG できない Next.js / Remix
フォームバリデーション できない React Hook Form / Zod
テスト できない Vitest / Testing Library

この表を見て「できないことだらけじゃないか」と思ったかもしれない。でも、これこそがReactがライブラリである証拠であり、強みでもある。演出家は演技の段取りだけに集中するから、最高の演出ができる。劇場の建設（ルーティング）や衣装デザイン（スタイリング）は、それぞれの専門家に任せた方がうまくいく。

6. React 19で変わったこと — 2026年の最新動向

2024年12月にリリースされたReact 19は、Reactの歴史上最大級のアップデートだった。2026年4月現在、最新バージョンはv19.2.5まで進んでいる。

6.1 主要な新機能

機能 概要
Server Components UIの一部をサーバー側でレンダリングする仕組み。バンドルサイズ削減に貢献
use フック Promise や Context をより柔軟に扱える新しいフック。条件分岐の中でも使用可能
React Compiler 手動のuseMemo/useCallbackを不要にする自動最適化コンパイラ
Actions フォーム送信やデータ更新の非同期処理を簡素化
View Transitions ページ遷移時のアニメーションをネイティブサポート（v19.2で追加）

6.2 Server Components — 賛否両論の新パラダイム

Server Componentsは、Reactコンポーネントをサーバー側で実行し、クライアントに送るHTMLを軽量化する仕組みだ。

舞台演劇の比喩で言えば、これまで舞台上（ブラウザ）で全ての演技をしていたのを、一部のシーンを**映像収録（サーバー）**で済ませて舞台に映すようなものだ。舞台装置（JavaScriptバンドル）が軽くなる一方、収録と生演技の切り分けが複雑になる。

State of React 2025調査によると、Server Componentsは新規プロジェクトの45%で採用されている一方、コミュニティ内では最も議論を呼ぶ機能でもある。Context APIとの互換性やデバッグの難しさが課題として指摘されている。導入を急ぐ必要はない。まずはクライアントサイドのReactをしっかり理解してからで十分だ。

7. 「Reactを選ぶべきか？」の判断フローチャート

Reactが向いているケース:

  • ダッシュボード、管理画面など状態が頻繁に変わるUI
  • SNS、チャットなどリアルタイム性の高いアプリ
  • 大規模チームでの開発（コンポーネント分割による分業がしやすい）
  • 長期運用プロジェクト（エコシステムの安定性が高い）

Reactが過剰なケース:

  • ブログやLP等の静的コンテンツ中心のサイト
  • jQueryで十分な小規模なインタラクション
  • 学習コストを最小限にしたい短期プロジェクト

8. よくあるエラーと対処法

React入門時に遭遇しやすいエラーをまとめておく。

エラーメッセージ 原因 対処法
Each child in a list should have a unique "key" prop リスト描画時にkey属性が未指定 .map()の各要素に一意のkey属性を付与する
Too many re-renders State更新がレンダリング中に無限ループ onClick={handler}と書くべきところをonClick={handler()}と即時実行していないか確認
Cannot update a component while rendering a different component 他コンポーネントのレンダリング中にState更新を呼んでいる State更新をuseEffect内に移動する
Objects are not valid as a React child オブジェクトをそのままJSXに埋め込んでいる JSON.stringify()か、必要なプロパティを個別に表示する
Invalid hook call Hooksをコンポーネント外や条件分岐内で呼んでいる Hooksは必ずコンポーネントのトップレベルで呼ぶ

React公式ドキュメント（react.dev）のエラーメッセージ検索機能が秀逸で、ほとんどのエラーについて原因と解決策が日本語でも提供されている。困ったらまず公式を確認する癖をつけよう。

9. 学習ロードマップ — 次に何を学ぶべきか

初級（1-2週間）

学ぶこと 教材
JSX、コンポーネント、Props、State React公式チュートリアル（react.dev）
イベントハンドリング 同上
条件分岐レンダリング、リストレンダリング 同上

中級（1-2ヶ月）

学ぶこと 教材
Hooks（useEffect, useRef, useContext, useMemo） React公式ドキュメント
React Router によるルーティング React Router公式
Tailwind CSS or CSS Modules でのスタイリング 各公式ドキュメント
TypeScript + React React公式のTypeScriptガイド

上級（3ヶ月〜）

学ぶこと 教材
状態管理（Zustand / Jotai） 各公式ドキュメント
データフェッチ（TanStack Query） TanStack Query公式
Next.js（SSR / SSG / App Router） Next.js公式チュートリアル
テスト（Vitest + Testing Library） Testing Library公式
React 19新機能（Server Components, Compiler） React公式ブログ

ロードマップの鉄則: 公式ドキュメントから始めること。 React公式（react.dev）は2023年にリニューアルされ、インタラクティブなサンドボックス付きの非常に質の高いチュートリアルが揃っている。有料教材を買う前に、まず公式を一周しよう。

まとめ

Reactは「UIの構築」という一つの仕事に集中したライブラリだ。フレームワークのように全てを提供してはくれないが、その分、ルーティングも状態管理もスタイリングも、自分のプロジェクトに最適なツールを選んで組み合わせる自由がある。

舞台演劇の比喩に戻れば、Reactは最高の演出家だ。役者（コンポーネント）の配置、感情の変化（State）に応じた舞台転換、リハーサル（仮想DOM）による効率的な演出変更...これらを任せたら右に出るものはいない。ただし、劇場の建設（ルーティング）や衣装の調達（スタイリング）、チケット販売（データフェッチ）までは面倒を見てくれない。それぞれ専門家を連れてくる必要がある。

2025年のStack Overflow調査で利用率44.7%、世界中で1,100万以上のWebサイトを支えるReact。「とりあえず学んでおけば損はない」という消極的な理由ではなく、コンポーネントという考え方がUI構築の本質を捉えているからこそ、10年以上にわたって最前線に立ち続けている。

その境界線を理解したうえでReactを選ぶなら、きっと良い旅になるはずだ。

関連記事

Reactのエコシステムについてさらに深く知りたい方は、こちらの記事もどうぞ。

参考文献

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?