ReactのPropsとは？初心者から上級者まで徹底解説【2025年最新動向：RSC、TypeScript対応】

2025 11/17

2025年11月17日 2025年11月17日

Reactアプリケーション開発の核心には、常に「Props」が存在します。Props（プロップス）は、Reactのコンポーネントベース・アーキテクチャを支える最も基本的かつ強力な概念です。その役割は、Reactの誕生から今日のReact 19におけるReact Server Components（RSC）の登場に至るまで、進化を続けています。

本レポートでは、ReactのPropsに関する包括的な解説を、海外の技術文献や公式ドキュメントに基づき、非エンジニア向けの基礎から開発者向けの高度なパターン、最新の技術動向まで、実例を交えて詳細に解説します。

セクション1：React Propsの基本原則 — 非エンジニアにもわかる核心

このセクションでは、技術的な背景を持たないプロジェクトマネージャーやデザイナーにも伝わるよう、Propsの基本的な概念とその重要性を解説します。

Propsとは何か？コンポーネントに渡す「指示書」

ReactのUIは、「レゴブロック」の集まりとして考えると理解しやすいです ¹。一つひとつのUI部品（ボタン、フォーム、ヘッダーなど）が「コンポーネント」と呼ばれる独立したブロックです。

**Props（Propertiesの略）とは、これらのコンポーネント（レゴブロック）を組み立てる際に渡す「指示書」や「設定値」**のことです ²。

例えば、<Button>というボタンコンポーネントがあったとします。このコンポーネントを再利用可能な部品にするためには、ボタンを配置する場所によって、その振る舞いや見た目をカスタマイズできる必要があります。

「このボタンの色は青にしてほしい」（例：color=”blue”）
「表示する文字は『送信』にしてほしい」（例：text=”送信”） ⁴
「クリックされたら、この動作（例：データを送信）を実行してほしい」（例：onClick={handleSubmit}） ⁵

これら一つひとつの具体的な指示がPropsです。

技術的に言えば、Propsは親コンポーネントから子コンポーネントへデータを渡すための主要な手段であり ²、コンポーネントの再利用性を高めるための核となる仕組みです ⁷。

Propsの最大の特徴：データは「読み取り専用（Immutable）」

Propsを理解する上で最も重要なルールが一つあります。それは、**「Propsは読み取り専用である」**ということです ²。

これは、先ほどの「指示書」の例えで言うと、「指示書を受け取った側（子コンポーネント）は、その指示書を勝手に書き換えてはならない」というルールです。

もし「青いボタン」として作られたボタンが、自分自身の判断で「赤いボタン」に色を変えてしまったら、アプリケーション全体のUIの秩序が失われ、不具合の原因となります。データは必ず「親」から「子」へと一方向に流れます ²。これを**「単方向データフロー（Unidirectional Data Flow）」**と呼びます。

この「Propsは不変（Immutable）である」という制約は、単なる機能ではなく、Reactの「単方向データフロー」という設計思想を強制するための仕組みです。もしPropsが可変であれば、子が親の状態を意図せず変更できてしまい、データフローが双方向になり、アプリケーションの挙動は予測不可能になります。Propsの不変性こそが、Reactアプリケーションの予測可能性とデバッグの容易性を支える根源です。

Props vs State：Reactにおける「渡されるデータ」と「持つデータ」

Reactの初学者が最も混乱するポイントが、PropsとStateの違いです ¹⁰。この二つは、Reactコンポーネントが扱う「データ」という点では同じですが、その出所と役割が根本的に異なります。

Props（渡されるデータ）: コンポーネントの**「外」から**渡される設定値です。これは、関数の世界における「引数（arguments）」によく例えられます ¹¹。Propsは親コンポーネントが所有しており、子コンポーネントはそれを受け取って読み取ることしかできません ¹²。
State（持つデータ）: コンポーネントが**「内」で**独自に管理する「記憶」です。これは、コンポーネントの「メモリ」に例えられます ¹¹。例えば、フォームに入力中のテキスト、トグルスイッチのON/OFF状態、マウスが乗っているかどうかの状態（isHovered）など、時間経過やユーザーの操作によって変化する動的なデータがStateです ¹¹。Stateは可変（Mutable）であり、コンポーネント自身が専用の関数（setState）を使って変更できます ⁸。

PropsとStateの区別は、コンポーネントを設計する上での最初のアーキテクチャ設計です。最も一般的で基本的なパターンは、「親コンポーネントがStateとしてデータを持ち、そのデータを子コンポーネントにPropsとして渡す」というものです ¹¹。このデータの分類（これはPropsか？ Stateか？）を誤ることが、Reactのバグの主な原因となります。

【テーブル1：PropsとStateの機能比較表】

特徴	Props (プロップス)	State (ステート)
データの役割	外部からの設定値（関数の引数） ¹¹	内部の記憶（ローカル変数） ¹¹
可変性	不変（Immutable / 読み取り専用） ⁸	可変（Mutable / 読み書き可能） ⁸
所有者	親コンポーネント ¹²	コンポーネント自身 ¹²
データの流れ	親から子への一方通行 ²	コンポーネント内で完結 ⁹
主な用途	コンポーネントのカスタマイズ、再利用 ⁶	動的なUIの変更、インタラクションの管理 ⁸
再利用性への影響	高める（Propsが多いほど汎用的に） ⁸	影響しない（Stateは自己完結） ⁸

セクション2：実践：Propsの基本的な使い方と主要パターン

このセクションでは、開発者向けに具体的なコード例を交えながら、日常的に使われるPropsのパターンを解説します。

Propsの渡し方と受け取り方（実例コード）

Propsの受け渡しは非常に直感的です。

1. 親コンポーネント（渡す側）

親コンポーネントは、JSXタグに対し、HTMLの属性（attributes）を記述するのと同じ構文でPropsを渡します 4。

JavaScript

// 親コンポーネント (App.js)
import Welcome from ‘./Welcome’;

function App() {
// ‘name’ というPropsに “Sara” という文字列を渡す
return (
<div>
<Welcome name=”Sara” />
<Welcome name=”Cahal” />
</div>
);
}

2. 子コンポーネント（受け取る側）

子コンポーネントは、関数の第一引数としてPropsを受け取ります。

方法1：propsオブジェクトとして受け取る

Propsは、渡されたすべてのデータ（この場合は{name: ‘Sara’}）を含む単一のオブジェクトとして渡されます 3。

JavaScript

// 子コンポーネント (Welcome.js)
function Welcome(props) {
// props オブジェクトの name プロパティにアクセス
return <h1>Hello, {props.name}</h1>; //
}

方法2：分割代入（Destructuring）で受け取る（推奨）

現代のReact開発では、ES6の分割代入構文を使い、propsオブジェクトから必要なプロパティだけを直接取り出す方法が主流です。これにより、コードがクリーンになり、どのPropsが使われているかが一目瞭然になります 4。

JavaScript

// 子コンポーネント (Welcome.js)
// 引数の時点で { name } と記述して取り出す
function Welcome({ name }) {
return <h1>Hello, {name}</h1>;
}

特別なProps：「children」が実現するコンポーネント合成

Propsの中でも一つだけ特別な名前を持つものがprops.childrenです。これは、コンポーネントの開始タグ（<Tag>）と終了タグ（</Tag>）の間にネストされたすべての内容（JSX）を受け取るための、予約されたPropsです ¹⁴。

childrenを使うと、「汎用的な箱」コンポーネントを作ることができます ¹⁶。例えば、<Card>という枠組みコンポーネントを作り、その「中身」は<Card>を使う側が自由に定義できるようにしたい場合に使います ¹⁵。

JavaScript

// 親コンポーネント (App.js)
// <Card> と </Card> の間にある h1 と p が Card の ‘children’ になる
<Card>
<h1>今週のトピック</h1>
<p>React Server Componentsについて。</p>
</Card>

// 子コンポーネント (Card.js)
function Card({ children }) {
// 受け取った ‘children’ (h1 と p) を好きな場所に配置する
return (
<div className=”card”>
<div className=”card-content”>
{children}
</div>
</div>
);
}

この<Card>{…}</Card>のようにコンポーネントを組み合わせるパターンは「コンポーネント合成（Composition）」と呼ばれ、Propsを何層にもわたって深く掘り下げて渡す「Prop Drilling」問題（セクション4で詳述）の最もシンプルかつ強力な解決策となります ¹⁸。

知っておくべき高度なパターン

1. Propsとして関数を渡す

Propsは読み取り専用ですが、子が親のデータを変更したい場合はどうすればよいでしょうか？

答えは、「親が、自身のStateを変更する関数を、Propsとして子に渡す」ことです 5。

JavaScript

// 親コンポーネント
function Counter() {
const [count, setCount] = React.useState(0);

// 1. 親が State を変更する関数を定義する
function handleIncrement() {
setCount(count + 1);
}

// 2. ‘onButtonClick’ というProps名で、その関数を子に渡す
return (
<div>
<Display count={count} />
<MyButton onButtonClick={handleIncrement} />
</div>
);
}

// 子コンポーネント
function MyButton({ onButtonClick }) {
// 3. 子は渡された関数を onClick イベントで呼び出す
return <button onClick={onButtonClick}>+1</button>;
}

function Display({ count }) {
return <p>Count: {count}</p>;
}

2. スプレッド構文（{…props}）

受け取ったPropsを、変更せずにそのまま別のコンポーネントやHTML要素にすべて渡したい場合、スプレッド構文（{…props}）が非常に便利です ⁴。

JavaScript

// HTMLの <button> をラップするカスタムボタン
function CustomButton(props) {
// ‘className’ や ‘onClick’, ‘aria-label’ など、
// CustomButton が受け取ったすべてのPropsを
// 内部の <button> 要素に一括で展開（スプレッド）する
return <button {…props}>{props.children}</button>;
}

// 使う側
<CustomButton onClick={() => alert(‘Clicked!’)} className=”primary”>
Click Me
</CustomButton>

props.childrenとスプレッド構文{…props}は、一見無関係に見えますが、「コンポーネントの抽象化」という共通の目的を持っています。childrenはコンポーネントが「何を含むか」を抽象化し、スプレッド構文は「どのように設定されるか」（aria-labelやdata-testidなど、コンポーネントが直接関知しない未知の属性を含む）を抽象化します。

ただし、このスプレッド構文の利便性にはリスクも伴います。特にHTML要素に直接{…props}を使うと、意図しないHTML属性や、場合によっては悪意のある属性（例：dangerouslySetInnerHTMLなど）がDOMに注入される危険性があると指摘されています ²¹。これは、コンポーネントの内部実装（例：<div>を使っている）が外部に漏れる「leaky abstraction（漏洩した抽象化）」を引き起こす可能性があります。

3. Propsのデフォルト値

Propsが親から渡されなかった場合の初期値を設定できます。

（旧）defaultProps: かつてはdefaultPropsという静的プロパティが使われていました ²²。
（新）ES6デフォルト引数（推奨）: 現代の関数コンポーネントでは、分割代入と同時にデフォルト値を指定するのが最もクリーンな方法です ⁴。

JavaScript

// ‘size’ が渡されない場合、デフォルトで 100 が使われる
function Avatar({ person, size = 100 }) {
//…
}

defaultProps ²² からES6デフォルト引数 ²⁴ への移行は、ReactがReact固有の機能から標準のJavaScript機能へと移行している大きなトレンドの一部です ²⁵。これにより、Reactコードの学習コストが下がり、JavaScript開発者にとってより親しみやすいものになっています。

セクション3：Propsとパフォーマンス — React.memoによる最適化

Propsは、Reactアプリケーションのパフォーマンス、特に「再レンダリング」の最適化と密接に関連しています。

なぜ最適化が必要か？親が再レンダリングされると子も再レンダリングされる

Reactのデフォルトの動作では、親コンポーネントが（自身のState更新などで）再レンダリングされると、その親が呼び出しているすべての子コンポーネントも、Propsが変更されているか否かに関わらず、再レンダリングされます ²⁶。

これが大規模なアプリケーションになると、不要な再レンダリングが積み重なり、パフォーマンスの低下を引き起こします。

React.memoとは？ Propsの変更を監視する

React.memoは、この不要な再レンダリングを防ぐためのツールです。これは関数コンポーネントをラップする「高階コンポーネント（HOC）」です ²⁷。

React.memoでラップされたコンポーネントは、親が再レンダリングされても、自身のPropsが「前回と変わっていない」と判断した場合、再レンダリング処理をスキップします ²⁹。

JavaScript

memoが機能しない時：浅い比較（Shallow Comparison）の罠

React.memoは万能ではありません。なぜなら、デフォルトではPropsが「前回と変わっていないか」を**「浅い比較（Shallow Comparison）」**で判断するためです ³⁰。

浅い比較:

文字列や数値などのプリミティブ値（例：prop=”text”）は、値が同じであれば「変更なし」と正しく判断できます。
オブジェクト、配列、関数などの参照型（例：prop={{}}, prop={}, prop={() => {}}）は、中身が同じでも、レンダリングの度に新しい参照（メモリ上のアドレス）が作られるため、常に「変更あり」と誤って判断されます ³¹。

アンチパターン（memoが無力化される例）:

JavaScript

このパフォーマンス最適化の難しさは、React.memoの浅い比較 ³⁰ という動作と、JavaScriptの参照型の特性 ³¹ の組み合わせが根本原因です。

この問題を解決し、React.memoを正しく機能させるには、親コンポーネント側でuseMemoフック（オブジェクトや配列の参照をメモ化）とuseCallbackフック（関数の参照をメモ化）を使い、Propsとして渡す参照自体を固定化する必要があります。

memoの乱用を避ける：最適化が逆効果になる時

React.memoは「最適化」であると同時に、「Propsを比較する」という新たな「コスト」を導入します ³²。そのため、むやみに使用すると逆にパフォーマンスを低下させる可能性があります。

React.memoは万能薬ではなく、特定の条件下でのみ有効な処方箋です ²⁷。

memoが有効なケース（以下の3つをすべて満たす場合） ²⁷

そのコンポーネントが頻繁に再レンダリングされる。
かつ、同じPropsで再レンダリングされることが多い。
かつ、そのコンポーネントのレンダリング処理自体が重い（例：複雑な計算、多くの要素を描画）。

memoが不要（または有害）なケース

Propsがレンダリングの度にほぼ毎回変わるコンポーネント（比較するだけ無駄）。
レンダリングが非常に軽量なコンポーネント（比較コストのほうが高くつく） ³²。

開発者はまずmemoなしで構築し、React DevToolsのプロファイラ機能 ³⁰ を使って実際のパフォーマンスボトルネックを特定し、上記の基準に合致した場合にのみmemoを適用すべきです。「早すぎる最適化」は避ける必要があります ²⁷。

セクション4：深刻な問題「プロップバケツリレー」とその解決策

アプリケーションのコンポーネント階層が深くなると、Propsの受け渡しが設計上の大きな問題となります。それが「プロップバケツリレー（Prop Drilling）」です。

プロップバケツリレー（Prop Drilling）とは？

あるデータ（例：ログイン中のuserオブジェクト）を、コンポーネントツリーの最上部（例：App）から、ツリーの奥深く（例：Avatar）まで渡したい場合に発生します ³⁵。

App → Page → Sidebar → Profile → Avatar

このとき、途中のPage、Sidebar、Profileといったコンポーネントは、userデータを全く使う必要がないにもかかわらず、Avatarコンポーネントにデータを届けるためだけに、Propsを受け取り、それをそのまま子コンポーネントに渡すためだけのコードを書く必要があります ³⁷。

この「バケツリレー」のようなデータの受け渡しは、以下の深刻な問題を引き起こします。

保守性の低下: コードが冗長になります ⁴⁰。
リファクタリングの困難: 途中のコンポーネントのProps定義を変更するだけでも、その上下すべてのコンポーネントに影響が及びます ³⁹。
密結合: コンポーネントが不要なデータに依存するため、疎結合性が失われます ³⁶。

解決策1：コンポーネント合成（Composition） — React公式の推奨

多くの開発者がProp Drillingの解決策として即座に「Context API」を思い浮かべますが、Reactの公式ドキュメントは、まず「コンポーネント合成」という、よりシンプルな解決策を検討するよう強く推奨しています ¹⁸。

これは、セクション2で解説したprops.childrenを活用するパターンです。

悪い例（Prop Drilling） 35

Sidebarはuserを必要としないのに、Propsとして受け取っている。

JavaScript

良い例（Composition） 18

Sidebarはchildrenを受け取るだけにし、userの存在を知らない。

JavaScript

React公式がProp Drillingの第一の解決策としてContext API ¹⁸ ではなく、コンポーネント合成 ¹⁸ を挙げている点は非常に重要です。合成は、Context APIが導入する「暗黙的な依存関係」や「パフォーマンス問題」（後述）なしに、コンポーネントの関心事を明確に分離します。Sidebarはレイアウトに専念し、Profileはデータの表示に専念できます。開発者は安易にContext APIに飛びつくべきではありません。

解決策2：Context API — 「テレポート」させる技術

コンポーネント合成パターンが適さない場合、Context APIが有効です。例えば、アプリケーションの非常に多くの場所で、かつ深くネストした場所で「現在のテーマ（ダークモードか否か）」や「認証ユーザー情報」にアクセスしたい場合です ⁴³。

Contextは、データをPropsで手動でバケツリレーすることなく、コンポーネントツリー全体に「テレポート」させる（ブロードキャストする）仕組みを提供します ¹⁸。

Provider（データを提供する側）とuseContextフック（データを消費する側）を使って実現します ³⁵。

JavaScript

// 1. Contextオブジェクトを作成
const UserContext = React.createContext(null);

// 2. App全体を Provider でラップし、’value’ としてデータを渡す
function App() {
const user = { name: ‘Paulo’ }; //
return (
<UserContext.Provider value={user}>
<Page />
</UserContext.Provider>
);
}

// 3. 途中のコンポーネントはPropsを一切必要としない
function Page() { return <Sidebar />; }
function Sidebar() { return <Profile />; }

// 4. データを必要とするコンポーネントが ‘useContext’ で直接データにアクセス
function Profile() {
const user = useContext(UserContext); //
return <p>Name: {user.name}</p>;
}

Props設計の分岐点：Context API vs Redux/Zustand

Context APIはProp Drillingをエレガントに解決しますが、万能ではありません。

Context APIの限界:

Context APIの最大の弱点は、パフォーマンスです。Contextのvalue（上記例のuser）が更新されると、そのContextを消費（useContext(UserContext)）しているすべてのコンポーネントが、たとえその変更に関係のないデータ部分だけを使っていたとしても、強制的に再レンダリングされます 45。

Global Stateライブラリの利点:

Redux 47 や Zustand 49 といったグローバル状態管理ライブラリは、この問題を解決します。これらのライブラリは、「セレクタ」を通じて、コンポーネントが巨大なStateオブジェクトの*特定のスライス（一部分）*だけを購読することを可能にします。これにより、関係のないStateが変更されても、コンポーネントは再レンダリングされません 49。

Context APIが引き起こすこの「不要な再レンダリング」 ⁴⁵ こそが、ZustandやReduxのようなグローバル状態管理ライブラリが依然として必要とされる最大の理由です。

これらの知見から、以下の技術選定フレームワークを導き出すことができます。

Props (1〜2階層): まずはPropsで明示的に渡すことを検討します ⁵¹。
Composition (3+階層, UI分離): Prop Drillingが始まったら、まずコンポーネント合成（children）で解決できないか検討します ¹⁸。
Context API (グローバル, 低頻度更新): 合成が難しく、「低頻度で更新される」グローバルなデータ（例：テーマ、ユーザー認証情報）に使います ⁴⁵。
Global State (Zustand/Redux) (グローバル, 高頻度更新): 「高頻度で更新される」グローバルなデータ、または状態変更ロジックが複雑な場合に選択します ⁴⁸。

【テーブル2：状態・データ伝達パターンのトレードオフ比較】

パターン	概要	ベストケース	考慮事項（アンチパターン）
Props (直接渡し)	親から子へ明示的にデータを渡す ²。	1〜2階層下のコンポーネントへのデータ渡し。	3階層以上になるとProp Drillingが発生する ³⁷。
Component Composition (children)	JSXをPropsとして渡し、描画を親に委ねる ¹⁸。	UIの「枠（Frame）」と「中身（Content）」を分離したい場合 ¹⁶。	中身が枠の外部にあるデータ（例：兄弟コンポーネントの状態）にアクセスする必要がある場合、結局Drillingになる ⁵³。
Context API	ツリー全体にデータを「ブロードキャスト」する ⁴⁰。	低頻度更新のグローバルデータ（テーマ、認証など） ⁴³。	高頻度更新 ⁵²。Contextの値が変更されると、全消費者が再レンダリングされる ⁴⁵。
Global State (Zustand/Redux)	アプリケーション外部のストアで状態を集中管理する ⁵⁰。	高頻度更新、複雑な状態、多くのコンポーネントが共有するデータ ⁴⁸。	シンプルなアプリにはオーバーキル（過剰設計） ⁵⁴。Reduxのボイラープレート（記述量の多さ） ⁴⁹。

セクション5：型安全なProps：TypeScriptによる最新のベストプラクティス（2025年版）

現代のReact開発（2025年）において、TypeScriptはデファクトスタンダードとなっています ⁵⁵。Propsに型を付けることは、コードの品質、保守性、開発者体験（DX）を向上させる上で不可欠です ⁵⁷。

interface vs type：React Propsの型定義、どちらを選ぶべきか

TypeScriptには、オブジェクトの型を定義する方法としてinterfaceとtypeの2種類があり、コミュニティで長年議論されてきました ⁵⁹。

interface の特徴:

extendsキーワードを使った「継承」が可能で、オブジェクト指向プログラミング（OOP）に慣れた開発者にとって直感的です ⁵⁹。
**「宣言のマージ（Declaration Merging）」**をサポートします。これは、既存のinterface（特にサードパーティライブラリの型）に後からプロパティを追加（拡張）する際に非常に強力です ⁶¹。
type の特徴:

ユニオン型（|）やインターセクション型（&）など、interfaceよりも複雑で柔軟な型操作が得意です ⁵⁹。
プリミティブ型やタプル型にも別名を付けられます ⁶⁰。
関数型プログラミングと相性が良いとされ、Reactコミュニティでの人気が高まっています ⁵⁹。

このinterface 62 vs type 59 の議論の現実的な結論は、「どちらでも機能するが、プロジェクト内での一貫性が最も重要」 62 というものです。

実用的な指針としては、「サードパーティの型をマージ（拡張）する必要がある場合はinterfaceを使い、それ以外（特にユニオン型などが必要な場合）はtypeを使う」という使い分け 61、あるいは「一貫性を保つために、より柔軟なtypeに統一する」 59 というのが現代的な落とし所です。

childrenの型定義：React.FCはもう使うべきではない？

ReactとTypeScriptの組み合わせで、childrenの型定義は歴史的に混乱があるポイントです。

背景: 以前は、React.FC（またはReact.FunctionComponent）という型を使うと、childrenプロパティが暗黙的にPropsの型に含まれていました ⁶³。
React 18での変更: React 18の型定義アップデートで、React.FCからこの暗黙的なchildrenが削除されました ⁶⁴。
理由: childrenは特別なものではなく、他のPropsと同様に「明示的に定義されるべき」である、という考え方への転換です ⁶⁴。React.FCを使っていると、そのコンポーネントが実際にはchildrenを想定していない（使わない）場合でも、childrenを渡せてしまうため、バグの温床になっていました。

現代の型付け（React.FCを使わない方法）

現在のベストプラクティスは、React.FCを使わず、Propsの型定義にchildrenを明示的に含めることです 63。

TypeScript

import type { ReactNode } from ‘react’;

// Propsの型に ‘children’ を明示的に含める
type MyComponentProps = {
title: string;
children: ReactNode; // childrenが必須の場合
// children?: ReactNode; // childrenがオプショナルの場合
};

// React.FC を使わずに、引数に直接型を適用する
export const MyComponent = ({ title, children }: MyComponentProps) => {
return (
<div>
<h2>{title}</h2>
{children}
</div>
);
};

childrenを明示的に追加するPropsWithChildrenというヘルパー型も存在しますが ⁶⁵、上記のように型定義に直接childrenを記述する方が、コンポーネントのAPIがより明確になります。

ユーティリティ型：PickとOmitでPropsを賢く扱う

TypeScriptのユーティリティ型は、既存のProps型を再利用し、 DRY（Don’t Repeat Yourself）な型定義を実現するのに非常に強力です ⁶⁷。

Pick<Type, Keys>: Typeから指定したKeysのプロパティだけを選び出し、新しい型を作ります ⁶⁷。
Omit<Type, Keys>: Typeから指定したKeysのプロパティを除外し、新しい型を作ります ⁶⁸。

Omitは、コンポーネントのラッパーを作る際に絶大な威力を発揮します 69。

例えば、外部ライブラリのExternalComponentをラップするInternalComponentを作るとします。InternalComponentは、ExternalComponentのPropsをすべて受け入れつつ、classNameだけはInternalComponentが制御し、代わりにouterClassNameという独自のPropを追加したい、というケースです 70。

TypeScript

import { ComponentProps } from ‘react’;
import { ExternalComponent } from ‘external-lib’;

// 1. ComponentProps<T> を使い、ExternalComponent のProps型を取得
// 2. Omit<T, K> を使い、’className’ プロパティだけを除外
// 3. ‘&’ (インターセクション) を使い、独自の ‘outerClassName’ プロパティを追加
type InternalComponentProps =
Omit<ComponentProps<typeof ExternalComponent>, ‘className’> &
{
outerClassName: string;
};

const InternalComponent = ({
outerClassName,
…restProps // Omitされた残りのPropsがすべて入る
}: InternalComponentProps) => (
<div className={outerClassName}>
{/* 外部コンポーネントには残りのPropsをスプレッド構文で渡す */}
<ExternalComponent {…restProps} />
</div>
);

セクション6：【最新動向】React Server Components (RSC) とPropsの未来

React 19 ⁵⁶ で本格的に導入されるReact Server Components (RSC) は、Propsの扱いや制約に関して、Reactの歴史上最も大きなパラダイムシフトをもたらします ⁷²。

RSCとは何か？なぜPropsの常識が変わるのか

RSCは、従来のReactコンポーネント（現在は区別のため「Client Components」と呼ばれる）とは異なり、サーバーサイド専用で（ビルド時またはリクエスト時に）実行されるコンポーネントです ⁷¹。

RSCの最大の特徴は、クライアント（ブラウザ）にJavaScriptバンドルを送信しないことです ⁷²。

Propsのシリアライズ（直列化）とは？

従来のSSR（サーバーサイドレンダリング）がHTML文字列をクライアントに送信していたのに対し ⁷⁵、RSCはHTMLを直接送るわけではありません ⁷⁶。

RSCは、「RSC Payload」 ⁷⁷ と呼ばれる、レンダリング結果（どのコンポーネントが、どのPropsで、どの順番で描画されるか）を記述した、特別なJSON風のデータ形式 ⁷² をクライアントに送信します。

これにより、Propsに関する新しい、そして非常に厳格なルールが生まれました。

Server ComponentからClient ComponentへPropsを渡す際、そのPropsはもはやメモリ内の参照ではなく、ネットワーク経由で送信可能な**「シリアライズ（直列化）可能」**な値でなければなりません 78。

最大の制約：「Client Componentに関数を渡せない」問題

このシリアライズのルールの最大の帰結は、**「関数はシリアライズできない」**という事実です ⁷⁸。

これにより、Reactの基本的なパターンであった「イベントハンドラをPropsとして渡す」ことが、Server ComponentからClient Componentへ渡す際には原則として禁止されました ⁸⁰。

JavaScript

// MyServerComponent.js (Server Component)
import ClientButton from ‘./ClientButton’;

function MyServerComponent() {
function handleClick() {
// この関数はサーバー側にしか存在しない
console.log(“Clicked on server”);
}

// 致命的エラー：
// 関数 (handleClick) はシリアライズ不可なため、
// Client Component にPropsとして渡せない
return <ClientButton onClick={handleClick} />;
}

// ClientButton.js (Client Component)
‘use client’;
export default function ClientButton({ onClick }) {
// サーバーから onClick 関数を受け取れない
return <button onClick={onClick}>Click Me</button>;
}

この「関数を渡せない」制約には、**「Server Actions」**という重要な例外があります ⁸¹。関数に”use server”というディレクティブをファイルの先頭か関数自体に付与する ⁸¹ と、Reactはその関数自体をシリアライズする代わりに、クライアント側に「この関数を呼び出すためのネットワークリクエストを行うスタブ（代理）」を渡します。これにより、クライアントの操作（例：フォームの送信）がサーバー上の関数を直接呼び出す（RPC: リモートプロシージャコール）ことが可能になります。

解決策：コンポーネントをPropsとして渡す正しい方法（JSX vs 関数）

では、Server Component（例：サーバーでデータをフェッチする<UserProfile />）を、Client Component（例：タブ切り替えUI）のPropsとして渡すにはどうすればよいでしょうか？ ⁸³

この違いを理解することが、RSCにおけるPropsの概念を理解する鍵となります ⁸³。

間違った方法（コンポーネントの「関数」を渡す） ⁸³

JavaScript

// Parent.js (Server Component)
import ClientTabs from ‘./ClientTabs’;
import UserProfile from ‘./UserProfile’; // (Server Component)

// エラー： ‘UserProfile’ はコンポーネント関数そのもの。
// 関数はシリアライズできないため渡せない。
return <ClientTabs slot1={UserProfile} />;

正しい方法（コンポーネントの「JSX要素」を渡す） ⁸³

JavaScript

// Parent.js (Server Component)
import ClientTabs from ‘./ClientTabs’;
import UserProfile from ‘./UserProfile’; // (Server Component)

// OK： ‘<UserProfile />’ はJSX要素 (React Element)。
// これはシリアライズ可能な値として渡せる。
return <ClientTabs slot1={<UserProfile />} />;

なぜJSX（<UserProfile />）なら渡せるのでしょうか？

これは、slot1={UserProfile}が「コンポーネントの関数（コード）そのもの」を渡そうとするのに対し、slot1={<UserProfile />}は「サーバーサイドで<UserProfile />を先にレンダリングし、その結果（RSC Payloadの一部であるシリアライズされたUIオブジェクト）」を渡しているからです ⁷²。

Client ComponentであるClientTabsは、UserProfileコンポーネントのコードや関数を一切受け取りません。ただ、slot1というPropsに、既にレンダリング済みの「静的なUIの断片（シリアライズされたオブジェクト）」 ⁷³ を受け取るだけです。これは、RSCにおける「コンポーネント合成」の新しい形であり、props.children ⁷³ もこの仕組みで機能しています。

セクション7：結論 — Propsマスターへの道

ReactのPropsは、その誕生から ³、React 19とServer Componentsの時代 ⁷³ に至るまで、Reactのコンポーネントベースの設計思想の核であり続けています。

Propsの概念は、「親から子への読み取り専用データ」 ⁹ という基本的な役割から、TypeScriptによる「型安全なAPIコントラクト」 ⁵⁸ へと進化しました。

そしてRSCの登場により、Propsは新たに「サーバーとクライアントの境界線を跨ぐ、シリアライズ可能なペイロード」 ⁷⁷ という重要な側面を獲得しました。

Propsの基本的な原則（単方向データフロー、不変性）を深く理解し、その上でchildrenやContext APIといったアーキテクチャパターンを使いこなし、React.memoでパフォーマンスを最適化し、TypeScriptでその振る舞いを厳密に定義し、最終的にRSCのシリアライズ制約に適応すること。これらすべてをマスターすることが、現代のReactエキスパートへの道です。