TypeScriptシステム構成20選！どの構成を選べばいいの？
tiura
TypeScriptって、どうやってWebシステムをつくるの？
最近、なにかと話題のTypeScriptですが、実際どうやって現場で使われているのって気になりませんか？
そもそも大前提として「TypeScript」という言語そのものには、Rubyにおける『Ruby on Rails』やPHPにおける『Laravel』のような、業界の圧倒的な標準（デファクトスタンダード）となるWebフレームワークが存在しません。
つまり、TypeScriptはどこまでいってもJavaScriptであり、それ以上でもそれ以下でもないということ。「JavaScriptがあるところであれば、TypeScriptに置き換えられる」というだけです。
TypeScriptの人気は、現在第一線で活躍している主流のフレームワークが積極的にサポートしているところも大きいです。このあたりから、TypeScriptはどんなシステムに向いているのか？一緒に深堀っていきましょう！
まずは、TypeScriptのシステム構成にはどんなものがあるか、確認してみたいと思います。
この記事の対象読者
- TypeScriptにこれから触れる、または触れ始めたばかりの初学者
- 「TypeScriptを学べ」と言われたが、何から手を付ければいいか分からない人
- 既存のシステム（PHP、Rubyなど）に、これからTypeScriptを取り入れようか検討している人
- 業界のトレンドより、まず自分の状況に合った現実的な選択肢を知りたい人
TypeScriptを使ったシステム構成
| 分類 | 定義 | サーバーサイド | クライアント側 |
|---|---|---|---|
| ① 全部TS | サーバーもクライアントもTypeScriptで統一 | Node.js / Deno / Bun（Express, Fastify, NestJS, Hono等） | React/Vue/Svelte＋TS（ブラウザ） |
| ② フロントエンドだけTS | サーバーは別言語、ブラウザに表示する画面（コンポーネント）だけTSで構築 | PHP（Laravel）、Java（Spring Boot）、C#（.NET）、Python（Django） | React/Vue/Angular＋TS（Inertia経由、または別リポジトリのSPA） |
| ③ バックエンドだけTS | サーバーはTSだが、クライアント側はTS化されない、またはWebブラウザ上のJS/TSという概念自体が関係ない | Node.js / Deno / Bun（Express, Fastify, NestJS, Hono, AdonisJS(APIモード)等） | ①モバイルアプリ（Swift/Kotlin/Flutter）②他社システム・B2B API連携③マイクロサービス間通信（Go/Python/Java等から呼ばれる）④Web画面はあるが素のバニラJS/htmxのみで、TS化されていない |
| ④ JSだけTS（安全なJS化） | サーバーも画面の骨組みも別言語・別技術のまま。画面内の一部スクリプトだけTS化 | PHP（Laravel/CakePHP/WordPress）、Ruby（Rails）、Python（Django） | 素のTypeScript（Vite等でビルドし、既存のテンプレートに埋め込む） |
こうして整理してみると、「TypeScriptでWebシステムを作る」という一言の中に、実はまったく違う4つの選択肢が混在していることが分かります。
「①全部TS」サーバーからフロントまで全部TypeScriptで統一する方法は、確かに今のトレンドの中心にありますが、これを選ぶべきかどうかは「本当にそこまでの統一が必要か」で決まります。逆に、すでにLaravelやRuby on Railsのような強力なバックエンドの資産がある場合は、無理にサーバー側までTypeScriptに置き換える必要はなく、「②フロントエンドだけTS」や「④JSだけTS」のように、既存の土台を活かしたまま部分的に型安全性を取り入れる、という選択肢が現実的です。
「③バックエンドだけTS」は、Web画面を主戦場にしている開発者からは見えにくい領域ですが、モバイルアプリ向けのAPIや、他社システムとの連携基盤、マイクロサービス間の通信など、「画面がそもそもブラウザではない」という場面では、むしろ主流の選択肢になります。
「④JSだけTS」は、サーバーやHTML部はそのままに、スクリプトだけをTypeScript化して、型チェックの恩恵だけをつまみ食いするパターンです。実験・検証の場としてTSを試したい場合も、ここからスタートすることも多いのではないでしょうか？
「TypeScript=SPA（シングル・ページ・アプリケーション）を作ること」というイメージを持っている方も多いかもしれませんが、実際には従来通りのリロード型のシステム（SSR：サーバー・サイド・レンダリング）のままでも、TypeScriptの型安全性だけを取り入れることは十分可能なのです。
大切なのは、「今どのフレームワークが流行っているか」で選ぶのではなく、「今のシステムに何が既にあり、これから何が本当に必要なのか」を起点に、この4つの中から必要な部分だけを選び取ることです。
そうなってくると、実際にみんなどうしているのか気になりますよね？日本と世界でどのような構成で使われているかまとめてみました。
みんなどうしてる？
TypeScriptを使ってWebシステムを構築する際、みんなどのような技術の組み合わせを選んでいるのか、Qiitaの記事数から人気度を調査してみました。
修正版
| # | サーバー | フロント | TSの配置場所 | 挙動 | Qiitaシェア(TS全体) | Qiitaシェア(表内) |
|---|---|---|---|---|---|---|
| 1 | Next.js | React | 両方 | SPA(フルスタック) | 11.2%(4460) | 35.4%(4460) |
| 2 | Nuxt | Vue | 両方 | SPA(フルスタック) | 3.6%(1426) | 11.3%(1426) |
| 3 | Rails | React | フロント | SPA | 2.2%(874) | 6.9%(874) |
| 4 | Go | Next.js | フロント | SPA(API分離型) | 1.3%(527) | 4.2%(527) |
| 5 | Laravel | React | フロント | SPA | 1.3%(516) | 4.1%(516) |
| 6 | WordPress | 独自テーマ | フロント | リロード型 | 1.0%(408) | 3.2%(408) |
| 7 | Rails | Next.js | フロント | SPA | 1.0%(386) | 3.1%(386) |
| 8 | Django | React | フロント | SPA | 0.9%(372) | 3.0%(372) |
| 9 | Spring Boot | React | フロント | SPA | 0.9%(347) | 2.8%(347) |
| 10 | Rails | Vue | フロント | SPA | 0.8%(328) | 2.6%(328) |
| 11 | Laravel | Vue | フロント | SPA | 0.8%(299) | 2.4%(299) |
| 12 | Laravel(API専用) | Next.js(別リポジトリ) | フロント | SPA(API分離型) | 0.6%(239) | 1.9%(239) |
| 13 | Remix | React | 両方 | SPA(フルスタック) | 0.5%(217) | 1.7%(217) |
| 14 | Rails | Angular | フロント | SPA | 0.5%(206) | 1.6%(206) |
| 15 | NestJS | React | 両方 | SPA | 0.5%(194) | 1.5%(194) |
| 16 | Django | Next.js | フロント | SPA | 0.5%(193) | 1.5%(193) |
| 17 | NestJS | Angular | 両方 | SPA | 0.4%(154) | 1.2%(154) |
| 18 | Spring Boot | Angular | フロント | SPA | 0.4%(142) | 1.1%(142) |
| 19 | Spring Boot | Next.js | フロント | SPA | 0.4%(141) | 1.1%(141) |
| 20 | Django | Vue | フロント | SPA | 0.3%(127) | 1.0%(127) |
| 21 | Spring Boot | Vue | フロント | SPA | 0.3%(125) | 1.0%(125) |
| 22 | ASP.NET | React | フロント | リロード型(部分SPA) | 0.3%(119) | 0.9%(119) |
| 23 | Django | Angular | フロント | SPA | 0.3%(116) | 0.9%(116) |
| 24 | Rust | Svelte | フロント | SPA(API分離型) | 0.3%(114) | 0.9%(114) |
| 25 | ASP.NET | Angular | フロント | SPA | 0.2%(79) | 0.6%(79) |
| 26 | Laravel | Blade | フロント | リロード型 | 0.2%(77) | 0.6%(77) |
| 27 | NestJS | Vue | 両方 | SPA | 0.2%(67) | 0.5%(67) |
| 28 | Rails | ERB | フロント | リロード型 | 0.2%(60) | 0.5%(60) |
| 29 | ASP.NET | Vue | フロント | リロード型(部分SPA) | 0.1%(46) | 0.4%(46) |
| 30 | Express | EJS | 両方 | リロード型 | 0.1%(46) | 0.4%(46) |
| 31 | Spring Boot | Thymeleaf | フロント | リロード型 | 0.1%(44) | 0.3%(44) |
| 32 | Express | htmx | サーバー | リロード型(部分更新) | 0.1%(42) | 0.3%(42) |
| 33 | ASP.NET | Razor | フロント | リロード型(部分SPA) | 0.1%(28) | 0.2%(28) |
| 34 | Express | Eta | 両方 | リロード型 | 0.1%(21) | 0.2%(21) |
| 35 | AdonisJS | Edge | 両方 | リロード型 | 0.0%(16) | 0.1%(16) |
| 36 | Django | DTL | フロント | リロード型 | 0.0%(15) | 0.1%(15) |
| 37 | WordPress(Gutenberg) | Reactエディタ | フロント | 管理画面SPA的 | 0.0%(13) | 0.1%(13) |
| 38 | Fastify | htmx | サーバー | リロード型(部分更新) | 0.0%(6) | 0.0%(6) |
この結果をみると、Next.js＋Reactと、Nuxtの2つだけで、表内の記事の約半分を占めていることが分かります。この2つは、サーバーとフロントを、1つのフレームワークで完結させる、フルスタック構成です。開発環境が1つで完結し、型もフロント・バックエンドで統一できるため、TypeScriptとの相性が良く、記事数にも、その傾向がはっきり表れています。
一方、Rails＋React、Django＋React、Rails＋Vueのように、「サーバー側は、これまで通りの言語を使いながら、フロントだけReact/Vueに置き換える」という場面でもTypeScriptが一緒に導入されていることもうかがえます。これは、Spring Boot、ASP.NET、NestJSのような、型を厳密に扱う設計思想のフレームワークでも同様です。
| 順位 | サーバー | フロント | JS/TS層 | 挙動 | 日本 シェア | 海外 シェア |
|---|---|---|---|---|---|---|
| 1 | Laravel | Blade | 素のTS | リロード型 | 16% | 5% |
| 2 | Laravel | Inertia+React/Vue | TS | SPA | 12% | 8% |
| 3 | NestJS(TS) | なし | React/Vue/Angular+TS | SPA（API分離型のシステム） | 10% | 13% |
| 4 | Spring Boot | Thymeleaf/なし | React/Angular+TS | SPA | 10% | 6% |
| 5 | ASP.NET Core | Razor | 素のTS | 両対応 | 8% | 4% |
| 6 | Next.js/Remix | React | React+TS | リロード型（モーダルなどパーツのみSPA） | 7% | 19% |
| 7 | Nuxt | Nuxt自身 | Vue+TS | リロード型（モーダルなどパーツのみSPA） | 5% | 5% |
| 8 | Rails | ERB | 素のTS | リロード型 | 3% | 1% |
| 9 | Laravel | Blade+React/Vue埋め込み | TS(アイランド) | リロード型（モーダルなどパーツのみSPA） | 3% | 1% |
| 10 | WordPress | 独自テーマ | TS | リロード型 | 3% | 3% |
| 11 | Express(TS) | EJS | バニラJS(TS部分的) | リロード型 | 2% | 1% |
| 12 | AdonisJS(TS) | Edge | 型付きスクリプト | リロード型 | 2% | 1% |
| 13 | Go/Rust | Next.js/Svelte | TS | SPA（API分離型のシステム） | 2% | 7% |
| 14 | Laravel(API専用) | Next.js(別リポジトリ) | React+TS | SPA（API分離型のシステム） | 2% | 2% |
| 15 | Django | DTL | 素のTS | リロード型 | 2% | 1% |
| 16 | 任意API | Angular自体 | Angular(TS必須) | SPA | 2% | 4% |
| 17 | WordPress(Gutenberg) | Reactエディタ | React+TS | 管理画面SPA的 | 1% | 1% |
| 18 | Astro | HTML+コンポーネント | TS(アイランド) | リロード型（モーダルなどパーツのみSPA） | 1% | 2% |
| 19 | Next.js/Express(tRPC) | 型共有 | TS | 主にSPA | 1% | 3% |
| 20 | Express/Fastify(TS) | htmx | なし（htmxはJSを使わない思想） | リロード型（部分更新） | 1% | 1% |
| 21 | Express(TS) | Eta（EJSの後発） | 素のTS | リロード型 | 0% | 1% |
上記のシェア率は、統計にもとづくものではなく、AI（Claude）の肌感によるものですので参考程度にしてください。この文章を引用したり二次使用することはお控えください。
＜出典として参考にした主なデータ＞
・テクフリ、TechReach、TECH STOCK等のフリーランス案件数（2025年時点）
・npm trends（EJS/Eta/Handlebars等のダウンロード数）
・State of JavaScript 2024/2025
・W3Techs（WordPressの市場シェア）
この表は最近の情勢をもとにAI（Claude）に作ってもらったものですが、これによると、日本の並びで目立つのは、上位がLaravel関連で占められている点です。日本はLaravel案件がPHPフレームワークの中で多く、既存のLaravel資産にTypeScriptを組み合わせる構成が広く見られます。
海外の並びで目立つのは、Next.jsが最上位に来ている点です。海外ではNext.jsのようなTypeScript中心の構成が強い傾向にありますが、Java・Go・PHPなど他言語も依然として広く使われています。
どれを選ぶ？ケース別システム構成
ここまで、TypeScriptの4つの使われ方と、Qiitaの検索件数をもとにした、実際の構成別の記事数を見てきました。ただ、これを見て「じゃあ自分は何から学べばいいのか」と迷う方も多いと思います。
TypeScript単体の文法から丁寧に学んでから、システム構成を考える、という順番だと、実は二度手間になりがちです。TypeScriptという言語自体の機能は、SPAでもSSRでも変わりません。ただ、SPAでよく使うReact/Vueなどのライブラリには、SPA特有の型の書き方（JSXの型付けなど）が多く登場します。先に「自分がどんなシステムを作りたいか」を決めてから学ぶ方が、圧倒的に早道です。
作りたいものの形は、大きく３つのケースに分けられます。
- ① SPA（サーバーとフロントが同じFW）のシステムをつくりたい：
- ② SPA（サーバーとフロントが別のFW）のシステムをつくりたい：
- ③ 一般的なリロードタイプのシステムをつくりたい：
まずは自分がどのケースに近いか、当てはめてみてください。それぞれの主流の組み合わせを、難易度・転職市場での需要と一緒にまとめた表がこちらです。
| ケース | 難易度 | 学ぶべきこと・主流の組み合わせ | IT業界・転職市場での需要 |
|---|---|---|---|
| ① SPA(サーバーとフロントが同じフレームワーク) | ★★☆（中） | Next.js（React） | ◎Qiita実測で1位 |
| ★★☆（中） | Nuxt（Vue） | ◎Qiita実測で2位 | |
| ★★★（高） | Remix（React） | ◯Next.jsの対抗馬 | |
| ② SPA(サーバーとフロントが別フレームワーク) | ★★★（高） | Rails＋React | ◎Qiita実測で3位 |
| ★★★（高） | Go＋Next.js（別リポジトリ） | ◯チーム開発向け | |
| ★★★（高） | Laravel＋React | ◯既存のPHP資産を活かせる | |
| ③ 通常のシステム（SSR） | ★☆☆(低) | Laravel＋Blade＋素のTS | ◯日本国内で一定の求人がある |
| ★★☆（中） | Rails＋ERB＋素のTS | △求人数は少なめ | |
| ★★☆（中） | Express＋EJS（サーバーもTSで統一、画面は従来型） | △求人数は少なめだが、Node.js経験としてはカウントされやすい |
まず①は、「サーバーもフロントも、1つの技術で、統一して作りたい」という人向けです。Next.js・Nuxt・Remixのいずれも、学ぶ内容の多くが、「1つのフレームワークの、作法を覚える」ことに集中でき、覚えることが、比較的、整理しやすいのが特徴です。海外では、Next.jsの人気が、圧倒的です。
②は、「画面をリッチに、サクサク動かしたい。ただし、サーバー側は、既にある資産を活かしたい、あるいは、担当を分けて開発したい」という人向けです。サーバー側の技術(Rails、Go、Laravel等)と、フロント側の技術(React等)を、別々に覚える必要があるため、①より、習得の手間は増えますが、その分、既存システムの改修や、チーム開発との相性がよい構成です。
③は、「画面が切り替わるたびにページ全体が読み込まれる、従来通りの作り」を、安全に型を取り入れて実装したい人向けです。特に社内システムや業務システムのように、堅牢性・保守のしやすさを優先する場面では、こちらが向いています。3パターンの中では、最も学ぶ範囲が狭く、着手しやすい構成です。
Node.jsってどうなの？Apache(Nginx)よりいいって本当？
システム構成を選ぶ際に、Webアプリケーションサーバーが、Apache/Nginx（PHP）かNode.jsの2択どちらがよいのかも気になるところ。
ここでは、Apache/Nginx（PHP）構成とNode.js構成で比較したので見ていこう。
静的/動的の基本比較表
| 処理内容 | Apache/Nginx（PHP） | Node.js | 優位 |
|---|---|---|---|
| 静的ファイル配信 | 実測ベースで高速 | やや劣る | Apache/Nginx |
| DB書き込みを伴う動的処理 | Persistent Connection・OPcache等でカバー可能 | やや高速 | Node.js（僅差） |
実務でよくある処理シーンまで広げた表
| シーン | Apache/Nginx（PHP-FPM） | Node.js | 優位 |
|---|---|---|---|
| 重い画像アップロード | アップロード中、ワーカーが専有される | 非同期I/Oで他リクエストも並行処理 | Node.js |
| 100人が同時アクセス | ワーカー数を適切に設定すれば問題なし | メモリ効率よく捌ける | 体感差なし(数千人規模から差が出る) |
| 定期バッチ・cron処理 | Web用プロセスと完全分離できる | 同一プロセス内だと重い処理が全体を止めるリスク | Apache/Nginx |
| CPU/メモリ逼迫時の耐久性 | 1リクエスト1プロセスで隔離、影響範囲が狭い | シングルプロセスなので影響範囲が広がりやすい | Apache/Nginx |
| 重いセッション処理 | ファイルロックで詰まる場合あり(Redis等で解消可) | 比較的詰まりにくい | Node.js(僅差) |
上記にしめしたとおり、
- 静的ファイル配信では、Apache/NginxがNode.jsよりも明確に高速（実測ベースでおよそ2〜3倍）
- DB書き込みを伴う動的処理では、逆にNode.jsがやや有利という調査結果が見られます
という差はあるものの、システム設計の性能による影響と比較すると微々たる差。どちらも大手サービスで採用されており、性能差はシステム設計（特にDBまわりの処理時間）にくらべれば微々たるものというのが実情です。
「Webアプリケーションサーバーはどっちがいいの？」に対する答としては、大差はない。強いていうなら、リッチなリアルタイム性・大量同時接続が求められるシステムをつくりたいのか（Node.js）、従来の堅牢な業務系システムをつくりたいのか（Apache/Nginx）で、判別してよいといえる。
さいごに
今回は、TypeScriptの使い所に焦点をあててまとめてきましたが、いかがだったでしょうか？次回は、これらの最速の検証環境の構築についてもご紹介していきたいと思います。それでは、また次の記事で。
