React Nativeはオワコンか？離れの実態を更新頻度・案件数・採用状況で検証【2026年8月時点】

React Nativeがオワコンかどうかは、賛否の記事を読み比べても決着しません。肯定側と否定側で、根拠として挙げる出来事の年代がそろっていないためです。この記事では2026年8月時点で確認できる数値だけを並べ、安定版がどの間隔で出ているか、導入量が減っているか、国内でどれだけ仕事があるかを順に見ます。そのうえで、これから作るアプリでReact Nativeを選んでよいのか、既存アプリを5年運用し続けてよいのかを条件付きで切り分けます。

まとめ：React Nativeはオワコンかを3つの実測値で判断する

結論から書きます。2026年8月時点のReact Nativeは、条件が合う案件であれば新規に選んで差し支えない状態にあります。根拠は3つです。第一に、安定版が2025年10月から2026年8月まで約2か月間隔で6版出ており、途切れていません。第二に、npmの週間ダウンロード数が前年同週比で約3.2倍に増えました。第三に、国内のフリーランス案件検索で475件が掲載されており、要員を調達できる規模が残っています。

ただし手放しで薦められるものでもありません。サポート対象は最新3系統に限られ、2か月ごとの版上げに追随しなければ約半年でサポート外へ落ちます。オワコン論の実質は技術の終焉ではなく、この追随を誰が負担するのかという運用体制の問題として表面化する構図です。追随の枠を年間予算に組めない案件では、2年後に版が古すぎて上げられない状態に陥ります。

見送るべき場面もはっきりしています。OSの新機能を発表当日に取り込む必要がある案件と、毎フレーム描き替える高負荷な画面を主機能に据える案件です。この2つに当たるなら、React Nativeがどれだけ更新されていても選ぶ理由になりません。以下、それぞれの数値を確認していきます。

「React Native離れ」と言われた経緯を年代順に整理する

まず言説の出どころを年代で並べます。ここを整理しないまま賛否を読むと、2018年の話と2026年の話が同じ土俵で語られてしまいます。

2018年の大手撤退が言説の起点となり議論が更新されないまま残った

オワコン説の起点ははっきりしています。2018年6月、Airbnbが自社アプリでのReact Native利用を終了する経緯を公開しました。当時挙げられた理由は、JavaScriptとネイティブの橋渡しに起因する性能上の制約、iOSとAndroidで分岐せざるを得ないUI、そして両OSの知識とJavaScriptの知識を同時に要求される採用の難しさです。この撤退は技術メディアで広く取り上げられ、その後の日本語記事でも根拠として引かれ続けました。

問題は、引用元が更新されていない点にあります。2018年の判断材料は当時の内部構造を前提にしたもので、後述するとおりその構造は2025年に置き換わりました。撤退の事実そのものは動きませんが、撤退の理由が2026年時点でも同じ形で残っているかは別の話になります。

Bridge構成時代の不安定さが離れという実感を現場に残した

もう1つの源泉は、版を上げるたびに何かが壊れるという開発現場の実感でした。旧構成ではJavaScript側とネイティブ側が非同期のメッセージ列を介して通信しており、ネイティブ機能を呼ぶライブラリはこの仕組みに依存していました。本体の版が上がるとライブラリ側の追随が要り、片方だけ古いまま組み合わさると起動時に落ちるという事故が起きます。

この構造上の弱点は、公式の推奨構成が定まっていなかった時期に増幅されました。初期化の方法が案件ごとに違い、詰まったときに参照できる標準的な答えがなかったためです。離れという言葉は、技術の性能そのものではなくこの運用の面倒さに向けられていました。

New Architecture既定化で2025年に議論の前提が置き換わった

前提が変わった時期も日付で押さえられます。公式ブログによれば、2025年6月12日公開の0.80系で旧構成が凍結され、動かなくなる予定のAPIに警告が出るようになりました。続く2025年10月8日公開の0.82系が、全面的に新構成の上で動く最初の版です。C++層でJavaScriptとネイティブを直結する方式へ移り、旧構成のコードは以降の版で順次取り除かれています。

つまり、2018年の撤退理由のうち橋渡しに由来する部分は、2025年10月をもって議論の対象から外れました。オワコン説を読むときは、その記事が0.82系より前を前提にしているかどうかを最初に確かめると判断を誤りません。新旧構成の内部的な違いはReact Nativeとは？仕組みとNew Architectureの構造・採用判断で層ごとに整理しているため、そちらを参照してください。

更新が続いているかを安定版の公開間隔とサポート対象の範囲で見る

開発元が今後も投資を続けると述べたかどうかは、判断材料としてほとんど機能しません。方針は変わりますし、変わったときに告知されるとも限らないためです。代わりに見るのは、安定版が何日間隔で出ているか、同時に何系統がサポートされるかの2点になります。

直近6版の公開日から読み取れる約2か月という安定した発行間隔

公式のリリース情報とendoflife.dateの集計で確認できる公開日を並べます。2026年8月時点の実測値です。

10か月で6版、間隔は55日から63日に収まっています。開発が止まった技術に見られる半年以上の空白や不定期化は、この期間には起きていません。中身にも差があります。0.86系は利用者向けの破壊的変更なしと案内された版で、0.87系はTypeScript向けの厳密なAPIが既定になり、ビルド環境側でNode.js 22以上とKotlin 2.0以上が求められるようになりました。

サポート対象は最新3系統のみで追随を止めれば半年で対象外となる仕組み

発行間隔と同じくらい効くのが、いくつの版が同時に面倒を見てもらえるかです。endoflife.dateのReact Nativeのページで確認すると、2026年8月時点でサポート対象は0.85系・0.86系・0.87系の3系統に限られます。2か月ごとに1系統ずつ落ちていく計算です。

ここから導かれる運用上の帰結は単純です。版上げを止めた瞬間から約6か月でサポート外に落ち、その後に見つかった不具合や依存ライブラリ側の非互換は自力で解決する必要が出てきます。オワコンかどうかを論じる前に、年2回から3回の版上げ作業を保守契約に含められるかを先に決めるべきです。

導入量が減っているかをnpm週間ダウンロード数の前年同週比で見る

次に、実際に使われている量が減っているかを見ます。ここは公開APIから誰でも再取得できる数値で判断できます。

本体とExpoの週間実測値を1年前の同じ週と並べて比較した結果

npmの公開統計から取得した週間ダウンロード数です。2026年8月9日から15日までの週と、2025年8月10日から16日までの週を比較しました。

本体は1年で約3.2倍、Expoは約4.7倍に増えました。離れているという表現と、この増加は整合しません。あわせて読み取れるのが構成の変化です。本体を入れた案件のうちExpoも入れている割合が46パーセントから67パーセントへ上がっており、素の構成で組む案件は相対的に減っています。

ダウンロード数が示すのは配布量であって人気そのものではないという限界

この数値の限界も先に書きます。npmのダウンロードには継続的インテグレーションでの取得やミラーの巡回が含まれ、実際に開発している人数とは一致しません。1年で3.2倍という増え方も、案件が3.2倍になったのではなく、自動ビルドの実行回数が増えた分を多く含むと考えるのが妥当でしょう。

それでも判断には使えます。人数の絶対値ではなく、同じ計測方法で前年と比べた増減の向きを見るためです。少なくとも、廃れつつある技術に見られる漸減はここでは観測できません。

Expoの前提化で開発体験のどこが変わりどこが残ったのか整理する

前節の構成変化は、開発体験の変化と直結しています。オワコン説の中身が「面倒だからやめた」である以上、その面倒さが減ったのかを見ておく必要があります。

公式の始め方がフレームワーク経由へ移り初期化の分岐が減った背景

公式ドキュメントは新規アプリの作成手順としてフレームワーク経由の構成を案内しており、Expoがその筆頭に挙がっています。素の構成で組む道も残っていますが、案件ごとに初期化方法が違うという状態は解消へ向かいました。標準の答えが1つ決まったことで、詰まったときに参照できる情報の質も安定しています。

版上げの手順も変わりました。Expoが管理する構成では、本体と周辺ライブラリの組み合わせが版ごとに検証済みで、個別に整合を取る手間が減ります。Expoが担う範囲と担わない範囲の切り分けはExpo（React Native）とは？Expo Go・開発ビルド・EASの役割と採用判断に整理しています。

それでも残るビルド環境側の追随作業とネイティブ知識の必要量と範囲

減っていない負担もあります。0.87系ではAndroid向けビルドツールの世代が上がり、Node.js 22以上とKotlin 2.0以上が前提になりました。この種の要求は本体の版ごとに更新され、開発機と継続的インテグレーションの両方へ反映する作業が発生します。JavaScriptだけ書いていれば済むという理解のまま体制を組むと、この工程で止まります。

ネイティブ側の知識が不要になったわけでもありません。カメラや位置情報のような端末機能を扱う場面では、権限の宣言やストア審査の要件がOSごとに異なり、その差はどのフレームワークを使っても消えません。2018年に指摘された採用の難しさのうち、両OSの知識を要求する部分は現在も残っています。

国内の案件数475件が示す要員調達の余地とネイティブ案件との開き

技術が続いていても、日本で人を集められなければ採用できません。ここは国内の案件掲載数で測ります。

同じ検索条件で並べた4技術の掲載件数と読み取れる要員調達の余地

国内のフリーランス案件検索でキーワード指定して得た掲載件数です。2026年8月18日時点の実測で、条件はキーワード以外そろえています。

475件という水準をどう読むかが判断の分かれ目になります。ネイティブ2言語とは5倍から6倍の開きがあり、同じクロスプラットフォームのFlutterにも約1.8倍差をつけられました。国内でReact Nativeが多数派でないのは数字のとおりです。一方で475件は、要員が見つからない水準ではありません。乗り換えを迫られるほど枯れているかというと、そこまでではないというのが実勢です。

案件数が示すのは調達の余地であり技術の継続性ではない点に注意する

この数値を将来性そのものと読み替えないよう線を引いておきます。案件数は国内の受託構造や過去の採用実績を反映した結果であり、開発元の投資量とは別物です。前節までのリリース間隔とダウンロード数が本体の継続性を、この件数が国内での調達しやすさを表す、という役割分担で使います。

同じ物差しをFlutter側から見た記事がFlutterの将来性を数値で判断する｜リリース実績・国内案件数・競合の現在地です。両者の機能面をどう選び分けるかはFlutterとReact Nativeの違いと選び方｜2026年の判断基準で扱っているため、比較の詳細はそちらに委ねます。

撤退事例と継続事例をデスクトップとモバイルに切り分けて確かめる

採用状況は、ひとまとめにすると読み違えます。デスクトップ向けとモバイル向けで置かれた状況が違うためです。

デスクトップ実装は本体より3系統遅れて追随している状態にある

Windows向けの実装は、Microsoftが公開しているリポジトリのリリース履歴から状況を確認できます。2026年6月30日に0.84系、その前は6月4日に0.83系が出ています。本体が2026年8月11日に0.87系へ進んでいることを踏まえると、3系統ぶん遅れて追随している形です。

この遅れは実務に直接効きます。本体の最新版で使えるようになった機能や、最新版のみ対応と案内された周辺ライブラリを、デスクトップ側では数か月待つことになるためです。モバイルとデスクトップを1つのコードでそろえる計画を立てるなら、遅れる側に合わせて版を固定する運用が要ります。

モバイル側の採用は続き撤退事例の更新は2018年で止まっている

モバイル側は事情が異なります。Microsoft自身がOutlookやTeamsのモバイル版で採用しているほか、大手の採用事例は公開情報として残り続けています。逆に、2018年のAirbnb以降で同等の注目を集めた撤退事例は見当たりません。オワコン説の根拠が8年前の1件から更新されていないという事実は、それ自体が判断材料になります。

ただし採用事例の多さを安心材料にしすぎるのも避けるべきです。大手の採用は自社にネイティブ側を書ける要員がいる前提で成り立っており、その体制がない組織にそのまま当てはめられません。事例は技術が使えることの証明であって、自社で運用できることの証明ではないと切り分けます。

React Nativeを採用してよい3条件と見送るべき2場面

ここまでの数値を、採用判断の形に落とします。条件を満たすかどうかで結論が変わるため、言い切れる範囲を条件つきで示します。

採用条件はWeb側の要員と年2回の版上げ枠と画面の性質の3点

第一の条件は、ReactでWebを書いている要員が社内か委託先にいることです。記述の考え方が共通するため、両OSぶんのアプリを既存要員の延長で作れます。この条件がないなら、国内の案件数で上回るFlutterかネイティブを選ぶほうが調達で有利になります。Web側の資産をどこまで持ち込めるかはReactとReact Nativeの違いを描画・部品・スタイル・画面遷移の4層で比較で、ファイル種別ごとの書き換え率として見積もれます。

第二は、年2回から3回の版上げ作業を保守予算に組めることです。サポート対象が最新3系統である以上、追随を止めた案件は約半年でサポート外になります。ここを予算化できない案件は、技術の良し悪しに関係なく2年で行き詰まります。

第三は、作る画面がOS標準の部品で表現できる範囲に収まることです。フォームや一覧、詳細表示が中心の業務アプリはこの範囲に収まります。逆に独自の描画表現を全面に出す設計は、次に述べるとおり不利になります。

見送るのはOS新機能の即日追随と高負荷な描画を主機能に据える案件

見送るべき1つ目は、OSの新機能を発表当日から使う必要がある案件です。新しいAPIはまず各OSのネイティブ向けに提供され、React Native側で扱えるようになるまで待ち時間が生じる構造です。デスクトップ向けはさらに3系統ぶん遅れます。発表当日の対応を約束する案件では、この待ち時間が致命傷になります。

2つ目は、毎フレーム描き替える画面や高精細なアニメーションを主機能に据える案件です。OS標準の部品を操作する方式である以上、描画のすべてを自前で持つ方式に比べて表現の自由度と滑らかさで不利が残ります。ゲーム的な表現や図形編集を中核に置くなら、別の選択肢を先に検討してください。なお指の操作に追従する程度の動きであればReact Native Reanimatedとは？UIスレッド駆動の仕組みと4系の版の縛りで扱うUIスレッド駆動の実装で足ります。

5年間の運用を前提にした版追随の費用設計と外注時に確認する3項目

採用条件の第二に挙げた版上げ枠を、見積もりの形にします。ここが曖昧なまま発注すると、2年目以降に想定外の追加費用として表面化します。

年2回から3回の追随を均等割りせず重い版を1回見込む年間設計

版上げの作業量は一定ではありません。0.86系のように利用者向けの破壊的変更がない版もあれば、0.87系のようにビルド環境の前提そのものが動く版もあります。年間費用を均等割りで置くと、重い版に当たった年に破綻します。年2回の軽い追随と1回の重い追随を見込み、重い側にはネイティブ側の設定変更と検証の工数を別枠で積むのが実務的です。

版を飛ばさない運用も費用を下げます。3系統ぶん飛ばしてから一気に上げると、間の版で入った変更をまとめて処理することになり、原因の切り分けに時間がかかります。サポート対象が3系統である以上、少なくとも半年に1回は上げる前提で計画してください。

外注する場合に見積書と契約書で確認しておきたい3つの具体項目

発注側が確認する項目は3つです。1つ目は、保守契約に本体の版上げ作業が含まれるか、含まれる場合に年何回までかという範囲の明記になります。2つ目は、Expoを使う構成かどうかと、使う場合にビルドや配信の外部サービス費用をどちらが負担するかです。3つ目は、ネイティブ側のコードを書く必要が生じた場合の対応可否と単価でしょう。

この3点が見積書に書かれていない場合、2年目以降の追加費用として現れる可能性が高いと考えてください。既存アプリの現況診断や、これから作るアプリの構成選定から相談したい場合は、Flutter / React Nativeによるクロスプラットフォーム開発で対応しています。

よくある質問

React Nativeは2026年時点でオワコンと言えますか？

実測値からは言えません。安定版が約2か月間隔で6版出ており、npmの週間ダウンロードは前年同週比で約3.2倍です。国内の案件数はFlutterの約55パーセントで多数派ではありませんが、要員を調達できない水準でもありません。

React Native離れは実際に起きているのですか？

2018年の大手撤退を起点とした言説が、更新されずに残っている状態です。同等の規模で注目された撤退事例はその後見当たらず、導入量の統計も減っていません。ただしデスクトップ向けは本体より3系統遅れて追随しており、この領域では待ち時間が生じます。

これから学ぶならReact NativeとFlutterのどちらですか？

すでにReactでWebを書いているならReact Nativeが、モバイル専業で国内案件の数を優先するならFlutterが有利になります。国内の掲載件数はFlutterが857件、React Nativeが475件で、調達のしやすさには差があります。

古いバージョンのまま運用を続けても問題ありませんか？

サポート対象は最新3系統に限られるため、版上げを止めると約半年で対象外になります。対象外の版で見つかった不具合や依存ライブラリの非互換は自力で解決することになり、放置した期間が長いほど復帰の費用が上がります。

New Architectureへ移行していない既存アプリはどうなりますか？

2025年10月公開の0.82系以降は全面的に新構成で動いており、旧構成のコードは順次取り除かれています。移行せずに版を上げ続ける道は残っていないため、既存アプリは移行するか版を固定するかの二択になります。

関連記事

• React Nativeとは？仕組みとNew Architectureの構造・採用判断を実装目線で解説：本記事で前提にした新構成の中身を層ごとに確認できます
• Expo（React Native）とは？Expo Go・開発ビルド・EASの役割と採用判断：前提化したExpoが担う範囲と担わない範囲が分かります
• FlutterとReact Nativeの違いと選び方｜2026年の判断基準：本記事で扱わなかった機能単位の比較を整理しています
• Flutterの将来性を数値で判断する｜リリース実績・国内案件数・競合の現在地：同じ物差しで競合フレームワークの継続性を見た記事です
• COBOLはなぜ廃れたと言われるのか？「オワコン」説の真相：同型の言説を別の技術で検証した記事です