はじめに

Reactでアプリを作り始めると、.tsファイルと.tsxファイルが混在していることに気づきます。

なんとなく「コンポーネントは.tsx、それ以外は.ts」というルールで書いている方も多いのではないでしょうか。

実はこの使い分け、なんとなくで済ませてしまっても動くには動きます。

ですが、なぜ拡張子を分ける必要があるのかを理解しておくと、ファイル構成で迷うことが減りますし、エラーが出たときの原因も特定しやすくなります。

今回は、そもそもReactとは何かというところから、.tsと.tsxの違いまで、順番に整理していきます。

1. そもそもReactとは何か

.tsと.tsxの違いを理解するには、まずReactが何をしているものかを押さえておく必要があります。

Reactは、画面のUI（ボタンやフォーム、リストなど）を「部品」として組み立てるためのJavaScriptライブラリです。

ボタンひとつ、カードひとつといった単位を「コンポーネント」と呼び、コンポーネントを組み合わせることで画面全体を作っていきます。

このコンポーネントを定義するとき、Reactでは見た目の構造（HTMLのようなもの）とロジック（JavaScriptの処理）を同じファイルの中に一緒に書くのが特徴です。

この「HTMLっぽい構文をJavaScriptの中に書く」ための仕組みが、次に説明するJSXです。

2. 結論：違いは「JSX（画面のパーツ）」が入っているかどうか

先に結論からお伝えすると、違いはシンプルです。

.tsx：JSX（HTMLのような構文）を含むファイル
.ts：JSXを含まない、通常のTypeScriptファイル

つまり、ボタンやフォーム、レイアウトなど「画面の見た目（UI）」を定義するコンポーネントのファイルは .tsx になります。

一方で、データの型定義、日付のフォーマットといった計算処理、APIとの通信処理など、「見た目を持たないロジック」だけをまとめたファイルは .ts になります。

ここで出てきた「JSX」という言葉が、この使い分けのすべての鍵を握っています。

JSXとは、JavaScript（TypeScript）の中にHTMLのようなタグを直接書けるようにする特殊な構文のことです。

本来、プログラムの処理を書く言語の中にHTMLのタグをそのまま混ぜることはできません。

しかしReactでは、「画面の見た目」と「ボタンを押したときの処理」を同じ場所にセットで書いた方が開発しやすいという思想があるため、このJSXという仕組みを採用しています。

では、なぜわざわざ拡張子まで変えて、JSXの有無を区別しなければならないのでしょうか。

3. なぜ分ける？山括弧（`< >`）をめぐるTSとJSXの衝突

拡張子を分ける本当の理由は、人間が見た目を整理するためだけではありません。

裏側でコードをチェックしている「TypeScriptのコンパイラ（プログラム）」に対して、「このファイルの中身をどういうルールで解釈すればいいか」の合図を送るためです。

ここで大問題になるのが、山括弧（< >）という記号の存在です。

実は、TypeScriptの世界において山括弧は、非常に重要な別の役割を持っています。

それが「型（ジェネリクス）」の指定です。

例えば、普段Pythonを触っている方なら、型ヒントで list[int] や dict[str, int] のように四角括弧を使って中身の型を指定する感覚をお持ちかもしれません。

TypeScriptでは、これを List<number> のように、まさに山括弧を使って表現します。

ここにReactのJSXがやってくると、コンパイラは大混乱に陥ります。

// これはTypeScriptの「型の指定」？ それともReactの「画面のタグ」？
<Widget>

コードの中にこう書かれていたとき、コンパイラは「Widgetという型を指定しようとしている」のか、「Widgetという画面パーツ（タグ）を置こうとしている」のか、記号だけでは判別がつきません。

同じ山括弧という記号が、2つの異なる意味で衝突してしまっているのです。

この致命的な曖昧さをスパッと解決するために、拡張子によるルール分けが存在します。

.tsファイル：「山括弧はすべて『型の指定』として扱います」というルール
.tsxファイル：「このファイルの中の山括弧は『JSXのタグ』として解釈してOKです」というルール

つまり、拡張子の違いは人間向けのただの目印ではなく、コンパイラが迷子にならずに正しくコードを解釈できるようにするための、エンジニア側からの明確な「指示」なのです。

4. なぜ拡張子を分ける必要があるのか

ここまでで、JSXという構文があることはわかりました。

ではなぜ、ファイルの拡張子を.tsと.tsxで分ける必要があるのでしょうか。

理由は、TypeScriptのコンパイラ（コードをチェックし、変換するプログラム）が、ファイルの中身をどう解釈すればいいかを、拡張子を見て判断しているからです。

具体的には、山括弧「< >」の扱いが問題になります。

TypeScriptの世界では、山括弧は「型を指定するための記号」としても使われます。

一方でJSXでも、タグを表すために山括弧を使います。

同じ記号が2つの異なる意味で使われているため、コンパイラは「これはJSXのタグなのか、それとも型の指定なのか」を判断しなければなりません。

この曖昧さを解消するために、TypeScriptは拡張子でルールを分けています。

.tsxという拡張子がついたファイルは「このファイルの中の山括弧はJSXとして解釈してよい」という合図になり、.tsファイルでは「山括弧はすべて型の指定として扱う」というルールが適用されます。

つまり拡張子の違いは、見た目の分類ではなく、コンパイラに対する明確な指示なのです。

5. 実務ではどう使い分けるか

理屈がわかったところで、実際の開発ではどのように.tsと.tsxを使い分ければよいか、具体的に整理します。

.tsxを使うファイル

画面に表示されるコンポーネントを定義するファイル（ボタン、カード、フォームなど）
ページ全体を構成するファイル（Next.jsでいうpageファイルなど）
JSXを一部でも含む、カスタムフックやレイアウト定義

.tsを使うファイル

型定義だけをまとめたファイル
APIとの通信処理をまとめた関数（データを取得するだけで、見た目を持たない処理）
日付のフォーマットや計算処理など、汎用的なユーティリティ関数
定数や設定値をまとめたファイル

判断に迷ったときの基準はシンプルで、「そのファイルの中でJSX（山括弧のタグ）を1つでも書くかどうか」です。

1つでも書くなら.tsx、まったく書かないなら.tsを選びます。

なお、実際にはJSXを含んでいないのに間違って.tsxにしてしまっても、多くの場合はビルドが通ってしまいます。

逆に.tsファイルの中でJSXを書こうとすると、コンパイラがエラーを出して教えてくれます。

とはいえ、意味のない拡張子の使い方はチーム開発でファイルの見通しを悪くするため、意図に沿った拡張子を選ぶことが大切です。

まとめ

.tsと.tsxの違いは、単なる見た目の違いではなく、TypeScriptコンパイラに対する「このファイルにはJSXが含まれているかどうか」を伝えるための合図でした。

Reactはコンポーネントを組み合わせて画面を作るライブラリ
JSXはJavaScriptの中にHTMLのような構文を書ける仕組み
.tsxはJSXを含むファイル、.tsは含まないファイル
迷ったら「JSXを書くかどうか」で判断する

普段なんとなく使い分けていたルールの背景がわかると、ファイル構成を考えるときの解像度が上がります。

次回は、Reactにおける「UIコンポーネント」とは何かというところから、UIライブラリの選び方について整理していきます。