生成AIの情報の出方、React黎明期に似てるんじゃない？

2026年10月30日 10:00

背景

生成AIの時代ですが、エンジニアのみなさんはReactの出始めの頃を覚えていますか。そう、Fluxを追い、Reduxを追い、Hooksでやっと「綺麗に書けるかも」となったあの時代です。React黎明期を2013年ごろから見ていたときの感じと、いまの生成AIの情報の陳腐化の速さや社会への影響が似ていると思ったので、類似しているであろう箇所を分析しました。

分析の軸は3つです。

年表から、プロダクトの成熟過程を見る
年表から、必要なスキルがどう変わったかを見て、いま何に投資するかを決める
Reactと生成AIで、キャッチアップの仕方がどう変わったかを見る

例えば、1つめでは、公式プロダクトの手が届かないところを個人の開発者が工夫で埋めて、それを公式が吸収していく流れが共通しています。Reactの時は何が残ったっけ、と振り返ってみました。生成AIはすぐに情報が古くなるので、React側は、当時の空気は私の記憶です。フロントエンドの人じゃないのでだいぶ雰囲気なところがあるかもしれません。フロントエンドの人、誰か一緒に振り返ろう….。

ざっくり年表

ChatGPTがポップな図を描いてくれました。

なんとなく大きい流れとしてはデファクト確定、書き方の確定みたいな転換点があり、生成AIとReactの時の期間の長さの差でいうと、デファクト確定が2.0倍、書き方の確定が1.9倍生成AIの方が早いです。公式が周辺を吸収する行だけ58ヶ月に対して7ヶ月で、8.3倍あります。乱立の期間と、LangChain がデファクトになった年だけは公式の日付が取れないので、調べたうえでの私の判断です。

エコシステムざっくり年表

それぞれのエコシステムとしてざっくりと発展をふりかえると上記の表のようになります。MobX使うといいとか言われてた時期、懐かしいですね….。ReactはHooksあたりで実装方針が落ち着いた気がしますが、それまではベストプラクティスがころころと変わって、どう情報に追いつくか迷子になることが多かったと思います。対して生成AIも、今はReactでいうHooksくらいまではいったんじゃないでしょうか。情報を追うのも初期よりはだいぶ楽になってきましたね。

周辺ツールの乱立期

生成AI側は Chroma と LangChain と LlamaIndex の3本が ChatGPT の公開より前に出ているので、ChatGPTより前から始まっています。生成AI側の3本は、日付をリポジトリの作成日で見ていて、Chromaが2022年10月5日、LangChainが10月17日、LlamaIndexが11月2日です。

生成AI関連は組織の反応も速かったです。日立が生成AIの専門組織を作ったのが2023年5月15日で、ChatGPT公開から5.5ヶ月。時代をめちゃくちゃ先取りしていますね、すごい。Reactのほうで日本の大手がいつ本格着手したかは、業界統計が見つかりませんでした。

年表から見えたプロダクトの成熟過程

プロダクトの成熟過程のアナロジーについて考えると、
1. 公式プロダクトの手が届かないところを個人の開発者が工夫で埋めて、それを公式が吸収していく
2. 抽象レイヤーが下から上へ積み上がって、議論の場所が上レイヤーにうつる（生成AIならプロンプト→コンテキスト→ハーネス）

1の例としては、最初Reactが引き受けていたのはビューを描くところで、アプリ全体の状態は外に置かれていました。Facebook がFluxという設計を出して、その実装が上の表のとおり2014年に何本も並びます。Redux が本命ということになったあと、React 本体に Context API と Hooks が入り、単純な用途なら、外部ライブラリを足さなくても書けるようになりました。

対して生成AI側は、モデルに道具を使わせたい人が、出力を自分でパースして分岐を書いていました。LangChain がその処理をまとめて、2023年6月に Function calling が公式に入っています。関数の形を渡すとモデルが引数のJSONを返す仕組みなので、パースを自前で書く必要がなくなりました。

2はもっとわかりやすくて、ReactはDOM操作からコンポーネント、Hooks、フレームワークへと発展していきました。生成AIはプロンプトからコンテキスト、ハーネスへと繋がっていきます。

何が残ったのか

例えば消えたものについては、mixins も HOC も、ロジックを使い回す手段がなかったことへの対処策です。対しての残ったものはなんとなく、依存関係が綺麗に整理されて保守性がよくなるような、本質的なアーキテクチャという気がします。createClassが消えたのはES6のクラス構文のせいで、JavaScriptなど依存している言語の仕様によって左右された内容もありそうです。

余談ですが、key prop は2013年から13年ずっと、Reactが再レンダー間でリスト要素を同定できない問題に対処しています。useEffectの依存配列も7年以上そのままで、私の知る限りでは変わっていません。このへんは破壊的すぎる変更なので残したんだろうか。

生成AIでも同様です。CoTの定型句も few-shot の大量添付も、モデルが指示を追えなかったことの対応策です。残っているのは概念というか、やっぱりアーキテクチャレベルで抽象度の高いものが多い気がします。生成AIはエンジニアのいう「破壊的変更」が起こりにくいので、余計具体実装が消えやすいんでしょうね。

この2つを見ると、何が残るかは技術の優劣だけでは決まらないのがわかります。コミュニティでの取り扱いだったり、資金力、コミュニティで暗黙の前提とされている規範の変化、なども関与するため、ある程度落ち着くまでは何が残るかわからない上、消えるまでの時間が早いので具体実装を学ぶ学習コスパが悪いです。もちろん学習過程がメタ的にプラスになるとかそういう話はあるかもしれませんが。

ちなみに公式なら生き残るのか

Facebook 発でも止まったものがあります。Recoil は2025年1月にリポジトリがアーカイブされ、Draft.js も0.11.7（2020年8月）で止まっています。Relay は2026年5月、CRA も公式ツールでしたが2025年2月に終了しました。

逆に React Router と Redux と React Query は、外部で作られて生き残っています。

公式かどうかではなく、そのベンダーがそれを維持し続ける経済的な理由があるかで見るのがよさそうです。Assistants API が2025年8月に廃止を通知されて2026年8月に止まったのも、同じ見方で説明がつきます（deprecations）。

必要なスキルはどう変わったか

2つめの軸です。先に結論を書くと、細かい仕様を覚えていることの価値が下がって、代わりにアーキテクチャ全体を見る力と、AIに仕事を任せて結果を検収する力が要るようになりました。

ただ、この流れは生成AIで急に始まったわけではなくて、React の中でもすでに起きていました。

React黎明期に「できる人」だった条件

React を書き始めたころ、できる人とそうでない人の差は、だいたい仕様をどれだけ正確に覚えているかでした。

クラスコンポーネントで this.handleClick = this.handleClick.bind(this) を書き忘れない
componentWillMount / componentDidMount / componentWillReceiveProps の呼ばれる順番と、どこで setState してよいかを知っている
リストに key を付ける理由と、index を key にすると壊れるケースを説明できる
Hooks 以降は、useEffect の依存配列に何を入れるか、useMemo / useCallback をどこに置くかを判断できる

とか。このリストのほとんどが後から React 側に吸収されたことです。this のバインドとライフサイクルの使い分けは Hooks でほぼ要らなくなり、componentWillMount 系は 16.3 で UNSAFE_ 接頭辞が付きました。依存配列の漏れは eslint-plugin-react-hooks の exhaustive-deps が指摘してくれるし、メモ化は React Compiler が自動でやる方向に進んでいます。

残ったのは、状態をどこに置くか、どこでデータを取るか、コンポーネントをどの単位で切るか、という設計の判断です。

生成AI期に覚える意味が薄れたもの

例えばプロンプトの定型句なんかはReactと同じ、テクニックとして流行ったけど今は使われない技術です。「ステップバイステップで考えて」や「あなたは熟練のエンジニアです」は、2023年ごろは効くテクニックとして出回っていました。でも推論モデルが出てから、OpenAI 自身が推論モデル向けのガイドで、思考の手順を指示するプロンプトは不要で、場合によっては性能を落とすと書いています。覚えた定型句が、2年ほどで逆効果側に回ったわけです。

次にコードの細部。API のシグネチャ、ライブラリの引数の順番、正規表現の書き方、こういうものは AI が書くので、覚えていなくても手は止まりません。React 期に exhaustive-deps が依存配列を覚える負担を減らしたのと同じことが、言語仕様全体で起きている感じです。なお、覚えていなくても、というのは仕様を知らなくても、という意味ではありません。何も見ずに書ける状態まで覚えておく必要がなくなったという意味です。

代わりに必要な力①アーキテクチャを見る力

AI はファイル単位、関数単位ではかなり正確に書きます。一方で、システム全体のどこに何があるべきかは、渡されたコンテキストの範囲でしか判断しません。

たとえば、既存コードでは API 呼び出しを lib/api/ 配下に集めて、エラーハンドリングとリトライをそこで統一しているとします。AI にある画面の改修を頼むと、コンポーネントの中で直接 fetch を書いて動くものを返してくることがある。テストは通るし画面も動くので、差分だけ見ると問題に見えません。でも放っておくと、エラー処理の経路が2本になって、障害のときにどちらを見ればいいかわからなくなります。

これに気づけるかどうかは、コードの書き方の知識ではなく、このシステムはどういう責務分担で作られているかを頭に持っているかで決まります。React 期に状態をどこに置くかを判断していたのと同じ種類の力で、対象がコンポーネントからシステム全体に広がった、と考えています。

代わりに必要な力②マネジメントする力

もう1つは、AI に仕事を渡して、結果を受け入れるか判断する力です。AIがコードを書いてくれるんだからマネジメントしないといけない、という状況に見えています。例えば

仕事を切る：1回の依頼を、レビューできる差分の大きさ（目安として1PR）に収めるなど
必要な情報を渡す：設計方針、命名規則、触ってはいけないディレクトリを CLAUDE.md や AGENTS.md に書く。逆に必ずみてほしいファイルを指定する、など
権限を決める：実行してよいコマンド、本番環境や秘密情報に触れるかどうかを、エージェントの設定で絞る
検収する：自分でも動かして確認する
まずい時に止める：危険な操作の前に確認を挟む、CI で落とす、ループが回り続けたら打ち切る

というふうに、人のマネジメントとかなり近いです。

権限設計や監視の経験がある人は実は今めちゃくちゃ価値があると思っていて、例えばインフラや SRE をやっていた人が経験を活かせる世界になりそうだなと思います。

キャッチアップの仕方はどう変わったか

3つめの軸です。時期は3つに分けられると思っています。

React黎明期のキャッチアップ

当時いちばん効果があったのは、たぶん GitHub の issue を読むことでした。大きい変更をリリースされてから知るのも、書籍が出た時点で古いのも、当たり前だった記憶があります。

講演1本で常識が変わった例も実際にありました。Hooks が発表されたのはReact Conf 2018の基調講演で、安定版がでたのは2019年2月6日です。RFCプロセスが始まったのが2017年12月なので、それより前は設計の意図が issue のコメントに散らばっていました。

react.dev のローンチ記事では、公式自身が、新しい読者は React を2回学ぶ羽目になっていたと書いています。Hooks のドキュメントがクラスコンポーネントを知っている前提で書かれていた、という話です。原文に期間は書いていませんが、Hooks の安定版（2019年2月）からこの記事（2023年3月）までなので、4年以上その状態だったことになります。

今はどうキャッチアップするのか

公式ドキュメントの重要度が上がりました。特にリリースノートと deprecation ページは、参考資料というより運用のために毎回見るものです。X はいまも最速ですが、ノイズが多いのでずっと追うと疲れてしまいます。

また、生成AIでは、リバースエンジニアリングが学習の材料になりました。リークされたシステムプロンプトを集めたリポジトリは14万スターを超えています（2026年9月時点）。ドキュメントには使い方が書いてありますが、システムプロンプトを読むと、そのツールの作り手が何を禁止して何を優先しているかがわかります。React のときに issue の長文コメントを設計文書の代わりに読んでいたのと、やっていることは同じだと思います。

React黎明期同様、何人かのインフルエンサーやキュレーターをキャッチアップすると最新の情報は手に入る
公式ドキュメントやリポジトリを解析して思想の流れをキャッチすることでトレンドについていくことは重要
最先端を追わなくてもそのうち収束はするので、一発当てよう！じゃなければ静観も手だし、そのうち理解しやすい形になってくる

といった特徴があるなと思います。

どうキャッチアップするか

1. 信頼できる少数のキュレーター。数を増やさない。この記事で生成AI側の解説として頼ったのは、Simon Willison のブログ、Anthropic の engineering ブログ、harness の整理は Böckeler でした
2. 公式のリリースノート、deprecation ページ、モデルカード
3. 自分の実タスクでの小さい比較検証

あたりを抑えておけばいいと思います。あとは失敗談を集めるとそちらの方が実務に役立つことも多いです。（だから過渡期はコミュニティの勉強会などでの学びが多いんですよね）

生成AIの特異性

生成AIとReactが似てないところももちろんあります。

出力が確率的で、再現しない
影響する業務の範囲がとんでもなく広い
資本がないと入れない層がある
物理リソースで成長が止まるかもしれない

情報収集の方法なんかはアナロジーがききますし、キャリア的な意味でもエンジニアが全員死んだわけではないが、デファクトスタンダードな技術は変わったよね、といったところもアナロジーがきくと思いますが、事業構造や影響力は違います。

出力の再現性

React は、同じ props と state を渡せば同じ画面が出ます。バグも再現手順を書けば誰の手元でも再現するので、issue に再現コードを貼って、直ったかどうかもそれで確認できました。

生成AIは、同じプロンプトを投げても毎回同じ答えが返ってくるとは限りません。temperature を0にすれば揃うと思われがちですが、それでも揃わないことがあります。Thinking Machines Lab の検証記事（2025年9月）では、Qwen3-235B に temperature 0 で同じ入力を1000回投げて、80種類の出力が出たそうです。（原因はサーバーの負荷でバッチサイズが変わり、計算の順番が変わることだと書かれています）

さらに、モデル側が更新されると、エラーを出さずに出力の質や形式が変わります。React なら非推奨の警告が出て、数年の猶予があって、削除される、という順番でした。生成AIでは、警告が出るまで放置する、という運用が通りません。
そのため、確率的な出力をどうコントロールするか、とか、確率的な前提で業務プロセスを設計できるか、という観点が必要です。

影響する業務の範囲

React が変えたのは、フロントエンドの書き方でした。影響を受けたのはほぼフロントエンドエンジニアで、営業や経理の仕事の中身は変わっていません。

生成AIはどこにでも入ります。営業の提案書、CS の問い合わせ対応、法務の契約書レビュー、経理の仕訳、採用の書類選考。エンジニアのコードもその中の1つにすぎません。この流れにより、生成AIの情報の出どころはエンジニア以外であることも多くなりました。ドメイン知識の深い人を技術畑に巻き込みやすくなった一方、情報の正確性を見る力はより一層必要になっています。

さらに、この流れのせいで、エンジニアにも業務知識が必要になりました。AIの出力を評価する必要があるので、ビジネスサイドや利用者から見た「ふるまい」をしっかり理解しないとシステムを作れません。

資本がないと入れない層

React には、資本がないと入れない層がありませんでした。npm に publish できて GitHub アカウントがあれば、誰でも参加できました。Babel も、もとは個人のプロジェクトです。1つめの軸で書いた、個人が使いにくいところを埋めて公式が吸収する、という流れは、誰でも改善できるから成り立っていました。

それに比べて、生成AIは、モデルそのものを作れるのは企業だけです。フロンティアモデルの学習には、GPU とデータと電力に、個人や中小企業では出せない額のお金がかかります。

モデル周辺の層については個人でも手が出せて、ハーネスや eval、MCP サーバのような周辺の層は個人が開発しているものも多いです。この構造の場合、モデルの方針変更を一方的に受けるしかないことには注意が必要で、破壊的な変更やAPIの廃止で作ったものがゴミになる、という可能性は0ではありません。

物理リソースの天井

生成AIは、学習にも推論にもデータセンターの GPU と電力が要ります。IEA のEnergy and AI（2025年4月）では、データセンターの電力消費は2024年の約415TWhから、2030年には約945TWhと倍以上になる見込みだそうです。学習データも有限で、Epoch AI の推定（2024年6月）では、人間が書いた公開テキストは2026〜2032年のどこかで使い切るとされています。

これは推測ですが、生成AIのモデルの性能の成長ペースが下がるとか、提供方法に規制がかかって個人利用が難しくなるような可能性は0ではないと考えています。例えば推論コストとレート制限を、あとから考える運用の話ではなく、最初の設計の制約として扱い、価格改定に備えるとか、モデル呼び出し部分は差し替えられるように、またはローカル推論に逃がせるようにしておく、といった防御策はしたほうがいいなと考えます。

終わりに

生成AIもReactも共通の特徴で注目すべきは「情報の流行り廃りが早すぎてついていくと脳が疲労する」というところかもしれません。業務の知識やトレンド以外の部分が不要になったわけではないので、自分なりの良い付き合い方、距離感を模索できるとよく生きられそうです。結局、続けた人が一番すごいですからね。

参考記事

営業ゾーン

改めて、私はうぐいすソリューションズという会社を経営しています。

採用も積極的にしていて、いまはtoB のソリューション営業の経験がある人やPM に興味のあるエンジニア、または PMを募集しています。我こそは！とまでは思わなくても、気になったらぜひ声をかけてくださいね。

https://www.uguisu-solutions.com/recruit