React のサポート期限はいつまで？公式の EOL 日は存在しません【2026年8月版】

文責: Scott Bissett  ·  公開日: 2026年8月14日  ·  記載の日付はすべて React の公式リリース履歴および当サイトのライフサイクルデータと2026年8月14日に照合済み — 検証方法（英語）  ·  リスクスコアはビルドごとにデータから自動生成しています  ·  English version

「React のサポート期限はいつまでか」という検索でこのページにたどり着いた方に、まず最も重要な事実をお伝えします。その期限は存在しません。 Meta（React チーム）は、これまで一度も React のメジャーバージョンに対して終了日を公表したことがなく、サポート期間の年数も定めていません。したがって「React 18 のサポート期限は◯年◯月◯日」と書かれた表を掲載しているページがあれば、それは出典のない数字です。本記事では、ありもしない日付を示すのではなく、期限の代用になる判断材料を整理します。具体的には、後継メジャーが公開された日、各系列の最終リリース日と経過期間、CISA KEV への登録状況、そして EOL リスクスコアの4点です。

React に「サポート期限」がない — まず事実を整理する

React のサポートを正しく理解するには、ひとくくりに語られがちな「サポート」を、3つに分けて考える必要があります。日本の IT 業界で使われている用語に対応させると、次のようになります。

• アクティブサポート（Active Support） — 新機能、性能改善、通常のバグ修正が提供される状態です。React では現行メジャーの1系列だけが対象で、2026年8月時点では React 19 のみが該当します。次のメジャーが公開された時点で、前のメジャーはこの状態から外れます。
• セキュリティサポート（セキュリティ修正のバックポート） — React の公式バージョニングポリシーは、脆弱性が見つかった場合には「影響を受けるすべてのメジャーバージョンに対して、バックポートされた修正を提供します」と記載されています（出典: React 公式ドキュメント日本語版「バージョニングポリシー」）。期限も対象範囲も明示されていない方針であり、契約上の保証ではありません。
• 事実上のサポート終了（実質的な停止） — 公式なアナウンスはないものの、実際には長期間ひとつもリリースが出ていない状態です。React 15・16・17 はこれに該当します。日本語の資料では「サポート切れ」と表現される状態に近く、公表された終了日がないぶん、社内の資産管理台帳の上では「サポート中」のまま残り続けます。

なお、「保守終了」「保守期限」という言葉を React に対して使うのは適切ではありません。日本語の「保守」は、特定の事業者が対価を得て維持管理を行う契約を指す言葉であり、React はそもそもそのような契約の対象ではないためです。「保守」を使うべきなのは、後述する自社と開発ベンダーの間の保守契約についてです。同様に、ハードウェアの世界で使われる EOSL（保守・修理サービスの終了）も React には当てはまりません。React はそのいずれのモデルにも当てはまらない、と考えるのが正確です。

React 全メジャーバージョンの状況一覧【2026年8月時点】

公式の EOL 日が存在しない以上、一覧表に「サポート終了日」の列を作ることはできません。代わりに、後継メジャーが公開された日（その系列へのアクティブサポートが実質的に引き継がれた日）と、その系列で最後に出たリリースを並べています。日付は ISO 8601 形式（年-月-日）で表記しています。

「アクティブサポート終了」列は、後継メジャーが公開された日を当サイトが採用している慣例的な区切りとして記載したものであり、Meta が発表した終了日ではありません。公開日・最終リリース日・リスクスコアは、当サイトのデータレイヤー（毎晩 upstream と同期）と照合され、ビルドごとに自動更新されます。バージョン名またはスコアをクリックすると、各バージョンの最新ステータスと採点根拠を確認できます。

この表から読み取るべきポイントは3つあります。第一に、「公式の EOL 日」列がすべて「公表なし」であることです。これは調査漏れではなく、React というプロダクトの性質によるものです。第二に、React 18 の最終リリースは後継の React 19 が出るより約7か月前だったという点です。18.3.1 が2024年4月26日、React 19 の公開が2024年12月5日ですから、React 18 系は後継の登場を待たずに更新が止まっていたことになります。第三に、React 15 と React 16 の最終リリースが同じ2020年10月14日であることです。これは偶然ではなく、当時 React チームが新しい JSX 変換を 16 系と 15 系の両方へ同日にバックポートした結果です。React 15 の後継である React 16 が公開されたのは2017年9月26日ですから、後継登場から3年後に古い系列へ手が入った例が実際に存在する、ということになります。

「期限がない」＝「無期限サポート」ではない — React 18 は「凍結」状態

ここが本記事で最も重要な部分です。次の2つの文は、どちらも正しい事実です。

矛盾しているように見えるこの2つの事実こそ、React のライフサイクルで最も誤解されやすいポイントです。仕組みはこうです。React が現行メジャー以外に対して約束しているのは、セキュリティ修正のバックポートだけです。バグ修正も、性能改善も、新機能も、現行メジャーにしか入りません。そして React 18 に関しては、2024年4月26日の 18.3.1 以降、セキュリティ修正を含めてひとつもリリースが出ていません。これは「見捨てられた」という意味ではなく、バックポートを要する事象がまだ発生していない、あるいは発生しても対象と判断されていないという意味です。この状態を表す言葉として、当サイトでは「サポート終了（EOL）」ではなく「凍結（フリーズ）」を使っています。

では、なぜ「期限がない」ことがリスクなのでしょうか。理由は3つあります。

1. 更新を促す強制力が存在しないから。 RHEL や Windows Server であれば、カレンダーに期限が入り、ベンダーから通知が届き、契約が切れます。React にはそのいずれもありません。誰も催促しないため、バージョンアップの議論は「何かが壊れる」か「監査で指摘される」まで先送りされます。
2. いつ実質的に打ち切られるかを事前に知る方法がないから。 期限が公表されていれば、その日から逆算して計画を立てられます。React ではその起点がないため、バックポートが来なかったことに事後にしか気づけません。「期限がない」は「無期限にサポートされる」ではなく、「終わりの時期を予測できない」という別のリスクです。
3. 依存パッケージ側が先に追従をやめるから。 React 本体が動き続けていても、周辺のライブラリやビルドツールが古い React のサポートを打ち切れば、実質的にアップグレードを強制されます。React 本体に期限がないことは、エコシステム全体に期限がないことを意味しません。

もうひとつ、日本語圏でよく見かける主張についても触れておきます。「React は古いバージョンにもセキュリティ修正を提供するので心配ない」という説明は、公式ポリシーの記述としては正確です。ただし、その約束には期限も、対象範囲も、提供までの時間も明記されていません。SLA のある商用サポートとは性質が異なります。「修正が来るかもしれない」を「修正が来る」と読み替えないことが、この判断の要点です。

EOL リスクスコアで見る React — 採点の内訳

公式日付がない製品を評価するために、当サイトでは EOL リスクスコア™（100点満点、点数が高いほどリスクが高い）を算出しています。React 製品全体のスコアと、その内訳は次のとおりです。

スコアと内訳は当サイトのデータから自動生成され、ビルドごとに更新されます。評価対象は「サポート外である期間の長さ」「攻撃対象領域」「CISA KEV への登録」「延長サポートの状況」の4点のみで、コードの品質や開発体制の評価は含みません。

採点方法について1点補足します。「更新の古さ」は通常40点満点の項目ですが、React のように公式の EOL 日が存在しない製品では、後継メジャーの公開日を起点とし、上限を30点に抑えた緩やかな曲線で評価しています。推定した日付は、ベンダーが公表した日付より根拠が弱いためです。バージョン別のスコアは、React 19 が 40、React 18 が 62、React 17・16・15 がいずれも 70 です。React 19 のみ Medium、それ以外はすべて High と判定されています。

CVE-2025-55182 と IPA 注意喚起 — 影響範囲を正確に把握する

2025年12月、React 関連で日本国内でも大きく報じられた脆弱性が CVE-2025-55182（Meta React Server Components の遠隔コード実行）です。2025年12月5日に CISA の KEV カタログ（悪用が確認された脆弱性の一覧）へ追加されており、当サイトのリスクスコアで React に KEV 項目の20点が加算されているのは、React 本体（React Server Components）が KEV に登録されているためです。日本国内でも、IPA が注意喚起を公開し、JPCERT/CC も関連情報を出しています。

ここで、多くの日本語記事が曖昧にしている点を正確に書きます。この脆弱性の対象は React 本体ではありません。 IPA の注意喚起は「影響を受けるシステム」として、React Server Components 関連パッケージである react-server-dom-webpack、react-server-dom-parcel、react-server-dom-turbopack の 19.0、19.1.0、19.1.1、19.2.0 を挙げており（修正版は 19.0.1、19.1.2、19.2.1）、React 18 および React 17 の本体は本脆弱性の対象として記載されていません。つまり、次のように整理できます。

• React 19 系で Server Components を利用している場合 — 対象になり得ます。package-lock.json や pnpm-lock.yaml で react-server-dom-* の解決済みバージョンを確認し、最新パッチへ更新済みかを点検してください（React 19 系の最新は 19.2.8、2026年7月21日リリースです）。フレームワーク経由で間接的に依存しているケースが多いため、直接の依存関係だけを見ても検出できません。
• React 18 / 17 / 16 / 15 を利用している場合 — この CVE を理由に緊急対応する必要はありません。ただし、これは「安全だから移行しなくてよい」という意味ではなく、今回の1件については対象外だったという意味にとどまります。

なお、本記事では React の CVE 件数を提示しません。React という名前を含むパッケージは React Native 関連を含めて多数存在し、それらを合算した件数は React 本体のリスクを表さないためです。件数ではなく、自社のロックファイルに実際に含まれるパッケージ名とバージョンで判断してください。

「期限がない」製品をどう稟議に載せるか — 日本の現場向けの判断材料

React のバージョンアップが日本の組織で止まりやすいのは、技術的な理由よりも手続き上の理由によるところが大きいと考えられます。単年度予算の下で稟議書を通すには、外部の根拠となる日付が必要です。Ubuntu にも RHEL にも Node.js にもその日付がありますが、React にはありません。結果として「まだ期限が来ていないので今期は見送り」という判断になり、システムはそのまま塩漬けになります。以下は、公式の日付の代わりに稟議書へ記載できる判断材料です。

• 最終リリース日と経過期間。「React 18 系の最終リリースは 18.3.1（2024年4月26日）であり、以後2年以上ひとつも更新が出ていない」— これは推測ではなく検証可能な事実であり、期限の代替として最も説得力があります。React 17 であれば 17.0.2（2021年3月22日）から5年以上、React 16 / 15 であれば2020年10月14日から5年以上です。
• アクティブサポートの対象がどの系列か。「新機能・バグ修正・性能改善が入るのは React 19 のみで、自社は対象外の系列を使用している」という事実は、稟議書の1行として明快です。
• EOL リスクスコアと第三者の評価軸。 社内の主観ではなく外部の指標を引用できることに意味があります（React 製品全体は 62 / 評価 D）。
• 監査・調達要件との突き合わせ。 SOC 2、PCI DSS、ISMS などの枠組みでは、フロントエンドの依存関係もソフトウェア資産として棚卸しの対象になります。また、官公庁や大企業の調達仕様書には「サポート期間」の記入欄があることが多く、React はその欄を埋められません。この事実自体を、移行を前倒しする根拠として記載できます。
• SBOM への記載。 ソフトウェアサプライチェーンの観点では、React 本体だけでなく react-server-dom-* のような推移的依存を SBOM に含められているかが実務上の分かれ目になります。前掲の CVE で問題になったのはまさにこの層です。

受託開発・SIer に発注しているシステムの場合

自社開発ではなく開発ベンダーに構築を依頼したシステムでは、そもそもバージョンアップ追従が保守契約の範囲に含まれているかが最初の確認事項になります。これは技術的な問題ではなく契約上の問題です。そして実務上、移行が進むかどうかを決めているのは、たいていこちらの問題です。契約書を確認する際は、次の3点を切り分けてください。

1. 障害対応と脆弱性対応は同じ範囲か。 「障害発生時の対応」は含まれていても、「利用しているライブラリのバージョン追従」は別見積り、という契約は珍しくありません。
2. メジャーバージョンアップは別プロジェクト扱いか。 React 18 から 19 への移行は、既存コードの改修を伴うため保守作業ではなく開発案件として扱われるのが一般的です。実際の規模感として、日本国内で公開されている React 17 から 19 への移行事例では、約450ファイル・約43,700行のアプリケーションで113ファイルの変更と1,000行超の書き換えが必要だったと報告されています（出典: PLAY Developers Blog）。工数見積りの参考になります。
3. 「サポート期限が来ていないから対応不要」という回答への備え。 React には期限がないため、この回答は形式的には成立してしまいます。本記事の一覧表と最終リリース日を、期限に代わる判断材料としてそのまま提示してください。客先常駐などで自分ではバージョンを決められない立場の方は、この表をそのまま印刷して打ち合わせに持参いただけます。

移行の進め方 — 18→19 と 16/17→19

移行そのものの手順については、日本語の良質な解説記事が既に数多く公開されているため、本記事では要点のみ整理します。React 18 から 19 への場合、作業自体は react と react-dom の更新、@types/react 系の更新（React 19 は型定義を同梱するため）、npx codemod@latest react/19/migration-recipe による自動変換、そして削除された API（propTypes、関数コンポーネントの defaultProps、文字列 ref、レガシー Context、ReactDOM.render）の置き換えが中心になります。最大の障壁はたいていの場合、依存ライブラリ側の対応状況で、--legacy-peer-deps による一時回避は技術的負債として記録しておくべきものです。

React 16 / 17 からの場合は、一段階ずつ進めるほうが安全です。まず削除予定 API の利用箇所を現行バージョンのまま解消し、次に 18 へ、最後に 19 へ、と段階を分けることで影響範囲を切り分けられます。加えて、Create React App が既にアーカイブされているため、ビルド基盤を Vite や Next.js へ移す作業がReact のアップグレードよりも大きなプロジェクトになるケースが少なくありません。ここを見落とすと工数見積りが大きく外れます。

また、Next.js や Remix などのフレームワークを利用している場合、実際に動作している React のバージョンはフレームワーク側が固定しています。思い込みではなく、ロックファイル上の解決済みバージョンを確認してください。

よくある質問

関連ページ

• React 全バージョンのサポート状況・リスクスコア（毎日更新） · React 19 · React 18 · React 17 · React 16 · React 15
• React End of Life — 凍結とサポート終了の違い、移行手順の詳細（英語）
• RHEL 8・RHEL 9 のサポート期限はいつまで？RHEL ライフサイクル完全ガイド（日本語）
• Exploited & Unpatchable — 悪用が確認された脆弱性 × EOL 製品の一覧（英語）
• EOL チェッカー — 480以上のプロダクトのサポート期限をまとめて確認（英語）
• 日付の検証方法について（英語）