はじめに
こんにちは、グローバルシステム部フロントエンドブロックの平田です。
私が所属するチームでは ZOZOMETRYというtoBサービスを開発しています。スマートフォンを用いて身体計測し、計測結果を3Dモデルやデータとして可視化します。計測結果はWeb上で管理できます。
このサービスのフロントエンドではReact（Next.js）を採用しています。さらにそれらの知見を深めるために、NYで開催されたJSNation、React Summit US 2025に参加してきました。
この記事では現地参加ならではの経験や、参加したセッションへの考察などを紹介していきます！
- はじめに
- JSNationとReact Summitとは？
- Day 1 - JSNation
- Day 2 - React Summit
- After Party
- 気になったセッションについて
- Workshop
- イベント全体を通じて感じたこと
- 最後に
JSNationとReact Summitとは？
JSNationとReact Summitは、JavaScriptおよびReactに特化した国際的なカンファレンスで、GitNationが主催しています。現地参加とオンライン参加のハイブリッド形式で開催され、それぞれJavaScript、React.js関連の様々なセッションが行われます。また、ネットワーキングやオンラインワークショップ、アフターパーティーなど、多彩なプログラムが提供されています。最新の技術の動向を学び、世界中の開発者と交流する絶好の機会です。
様々な国や地域で開催されていますが、今回は2日間に渡ってアメリカで開催されたJSNation、React Summitに参加してきました。ZOZOからは昨年アメリカ・ニューヨークで開催された同イベントにもエンジニアが参加しており、今回も引き続き参加できることになりました。
| 日付 | 時間帯（EST） | イベント | 場所 |
|---|---|---|---|
| 2025/11/17 | 9:00 - 17:00 | JSNation | Liberty Science Center |
| 2025/11/18 | 9:00 - 18:00 | React Summit | Liberty Science Center |
| 2025/11/18 | 19:00 - 22:00 | After Party | Zeppelin Hall Beer Garden |
それでは早速参加したそれぞれのイベントについて詳しく紹介していきたいと思います。
Day 1 - JSNation
今年も会場は昨年と同様のLiberty Science Centerです。
ランチタイムはフィンテック系企業でフルスタックエンジニアをしている人々と、デザイン系SaaS企業でバックエンドエンジニアをしている人と一緒に過ごしました。我々グローバルシステム部が扱っているプロダクトはやはり世界的にもユニークなので、興味を持ってもらえることが多くて嬉しかったです。午前中のセッションの感想や旅行の話などをしたらあっという間に午後のセッションの時間になったので移動しました。
ちなみにデザイン系SaaS企業の人は、昨年会社が企業ブースを出したので、無料で参加できたそうです。
またセッション以外には、複数のスピーカー達が意見を交わすディスカッションコーナーが設けられており、リスナーとしても参加可能でした。
セッションよりも近い距離で見ることができ、質問も可能なためセッションにはない面白さがありました。
Day 2 - React Summit
企業ブースもたくさんあり、幾つか回りました。こちらはおなじみのFigmaです。
プロジェクトによってはフロントチームがデザインをすることがあり、その際にFigmaのMCPサーバを使ってUIの実装をすることがあります。仕上がりにバラつきがあるので安定してUIを作れないかどうか聞いてみましたがそれはまだまだ難しいとのことでした。これからに期待ですね。
この日のランチタイムは、前日に出会ったフィンテック企業の人々と、新たに出会ったノルウェーのコンサルティング企業のエンジニアと当日のスピーカーのNicolasさんと一緒にお昼を食べました。
セッションの感想やどんな仕事をしているか基本的な会話をした後、移住の話題で盛り上がりました。ノルウェーのエンジニアがスイスに移住検討中であること、Nicolasさんがイギリスから元々アメリカに移住したことなどを話しました。地理的にも、言語的にも色々と移動しやすいことはとても良いですね。
こちらはPRをAIがレビューするツールのCodeRabbitのブースです。AIの導入によりPRの作成が高速化した一方で、チーム内レビューが追いついていないという問題は、どこのチームでも発生していると思います。このツールはコードレビューを自動化するサービスで、PR作成からマージまで大幅に高速化できるので、実際のプロダクトでも試してみたいと思いました。
気づけばあっという間に2日目も終了しました。この2日間はエネルギッシュな雰囲気に触れ、非常に刺激的で充実した時間を過ごすことができました。
After Party
React Summitの後には、After Partyの場が用意されています。今年はZeppelin Hall Beer Gardenでの開催でした。せっかくの機会なのでぜひ参加したかったのですが、今回宿泊したホテルが会場からかなり遠かったため、安全面を考慮して泣く泣く参加を見送りました。代わりに、宿泊先が割と近かった一部の参加者と夕食を食べることになりました。
気になったセッションについて
それでは、特に印象に残ったセッションを4つご紹介します。これらはGitNationのウェブサイトでも視聴可能ですので、ぜひチェックしてみてください。
The AI-Native Software Engineer
まず1点目は、Google ChromeのエンジニアリングリーダーであるAddy Osmaniさんによるセッションです。AI時代のエンジニアはどうあるべきかという問いに対し、「The Human 30％（人間の30％）」というキーワードを軸に、AIとの共存戦略を説いた非常に刺激的な内容でした。
以下、気になったポイントをまとめます。
AIネイティブ・ソフトウェアエンジニアへのシフト
AIは単なる補助ツールではなく、開発プロセスの初期段階から組み込まれる「AIネイティブ」なワークフローへと進化しているという点が非常に印象的でした。エンジニアの役割は、自ら一行ずつコードを書く「実装者」から、複数のAIエージェントを指揮して目的の成果物を得る「オーケストレーター」へと変化しています。これからは「どうコードを書くか」ではなく「どう正しいコードを構築させるか」という、より高次な視点が求められると感じました。
「70％のAI」と「30％の人間」の境界線
AIは定型的なコーディングやプロトタイプ作成など、タスクの約70％を驚異的なスピードでこなせます。しかし、残りの30％には人間の介入が不可欠です。特に、複雑なアーキテクチャ設計、エッジケースの考慮、セキュリティリスクの判断といった「高コンテキスト」な領域は、依然として人間にしかできない重要な付加価値です。AIが得意な「低コンテキスト」な作業を委ねることで、人間はより本質的な問題解決に集中できるという考え方に強く共感しました。
生産性のパラドックスと検証の重要性
AIによってコードの生成速度は上がりましたが、一方でプルリクエスト（PR）のサイズが肥大化し、レビューに要する時間が大幅に増加しているという「生産性のパラドックス」についても触れられていました。AIの提案は一見正しく見えても、微妙な誤りを含むことがあります。そのため、「信頼せよ、されど検証せよ（Trust, but verify）」という姿勢が、AI時代の品質担保において最も重要なスキルになると感じました。
「Vibe Coding」とエンジニアリングの規律
スピード重視の「Vibe Coding（ノリで書くコーディング）」と、厳格なプロセスを重視する「AI支援エンジニアリング」を、状況に応じて使い分けるスキルの重要性が語られていました。新規機能のプロトタイピングには前者を、ミッションクリティカルな本番環境の構築には後者をといった、AIとの距離感をコントロールする能力がこれからのエンジニアの武器になると確信しました。
まとめ
このセッションを通じて、AIに代替されることを恐れるのではなく、AIを「能力の増幅器」としてどう使いこなすかというポジティブなマインドセットの重要性を再認識しました。
特に「人間の30％」である、複雑な文脈の理解や最終的な品質責任を担う部分は、エンジニアとしての専門性がより光る領域です。AIを単なる効率化ツールとしてだけでなく、自身の学習を加速させるパートナーとして活用し、日々の開発業務の質を一段階引き上げていきたいです。
Full-Stack AI Orchestration: Modular Agents, Observability, and the Edge
2点目は、NetflixのシニアエンジニアであるJamal Sinclair O'Garroさんによるセッションです。
AIを単なる「便利な機能」としてではなく、エンタープライズレベルの本番環境で耐えうる「堅牢なシステム」として構築するための、フルスタックなオーケストレーション戦略についてです。
以下、気になったポイントをまとめます。
モジュール型エージェントとLangGraph
Netflixのような大規模システムを支える視点から、AIエージェントを巨大な1つの塊にするのではなく、特定の責務に特化した「モジュール」として分割する設計が推奨されていました。セッションではLangGraphを用いてエージェントをグラフ構造として定義します。それらを組み合わせることで、複雑なタスクを処理できる「モジュラーモノリス」なAIシステムを構築する手法が紹介されました。
信頼性を担保する「観測可能性（Observability）」
AIシステムのブラックボックス化を防ぐため、LangSmithなどのツールを活用してトレース（追跡）を行う重要性が強調されました。エージェントが「なぜその回答に至ったのか」の思考プロセスや、APIコールの履歴、トークンコストを可視化することで、エンジニアがデバッグ可能な状態を維持できます。これがプロダクション導入への鍵であると再認識しました。
Temporalによる耐久性のあるワークフロー
AIの挙動は予測不可能で、外部APIの失敗もつきものです。そこで、ワークフローエンジンであるTemporalを組み合わせるアプローチが紹介されました。これにより、処理が途中で失敗してもリトライや状態の復元が可能になり（Durable Execution）、システム全体の耐障害性を劇的に向上させることができます。
実用的なAI技術スタックの全体像
セッションでは、プロンプト管理から評価（Evaluation）、デプロイまで、モダンなフルスタックAI開発に必要なツール群が体系的に紹介されていました。
「ただAPIを叩くだけ」のフェーズから、エンジニアが主導して「信頼性の高いAIシステムを設計・運用する」フェーズへと移行していることが明確に示されていました。フロントエンドだけでなく、バックエンドやインフラ領域に興味があるエンジニアにとっても非常に興味深い内容でした。
まとめ
「AIを魔法として扱うのではなく、システム設計の一部として捉える」というJamalさんの言葉が非常に印象的でした。LangGraphでロジックを組み、Temporalで耐久性を高め、LangSmithで監視する。この「モダン・エンタープライズ・スタック」は、信頼性が求められるプロダクトにAIを組み込む上で、非常に参考になるアーキテクチャでした。
React Strict Dom: Cross-Platform React Based on the Web
3点目は、MetaのNicolas Gallagherさんによるセッションです。WebとネイティブReact Nativeの間にある「スタイリングとAPIの乖離」を解消する、react-strict-domについての解説でした。
以下、気になったポイントをまとめます。
「Web標準」をクロスプラットフォームの基盤に
これまでのクロスプラットフォーム開発では、Webとネイティブで別々のコンポーネントやスタイル記述が必要でした。react-strict-domは、divやspanといった「Web標準のHTMLタグ」と「CSS」のサブセットを共通のインタフェースとして使用します。Webエンジニアが慣れ親しんだ知識をそのままネイティブ開発に転用できるだけでなく、プラットフォーム間のフラグメンテーション（断片化）を根本から解決しようとするアプローチです。Metaの強力な意志を感じました。
厳格なサブセットによる「予測可能性」の向上
「Strict（厳格）」という名の通り、あえて使用できるCSSプロパティを限定することで、どのプラットフォームでも一貫した挙動を保証しています。Meta内部での採用実績も紹介されており、開発効率の向上だけでなく、成果物の品質も担保されている点は非常に説得力がありました。特に「AIによるコード生成」との相性も良く、構造化された厳格なAPIがAIの生成精度を高めるという視点は、これからの開発において大きなメリットになると感じました。
低コストな移行とメンテナンス性
既存のReact NativeコンポーネントをWebへ、あるいはその逆へと移行する際のコストを大幅に下げることができます。特定のプラットフォームに依存した「方言」を排除し、標準的な記述に寄せることで、長期的なメンテナンス性が向上します。マルチプラットフォーム展開を前提とした大規模プロジェクトにおいて、この共通基盤は非常に強力な武器になると確信しました。
まとめ
このセッションは、Reactエコシステムが再び「Web標準」に回帰しつつ、ネイティブの力を最大限に引き出そうとしている流れを象徴していました。
「Web向け」「アプリ向け」とエンジニアを分けるのではなく、共通の「React Strict DOM」という言語を通じて、より効率的にプロダクト価値を届ける未来がすぐそこまで来ていると感じます。我々のチームでも、今後のマルチデバイス展開を見据えて注視していきたい技術です。
Goodbye, useState
最後は、XStateの作者としても知られるDavid Khourshidさんによる、状態管理のパラダイムシフトを提案するセッションです。「複雑なアプリをuseStateだけで管理し続けるのはもう限界ではないか？」という、全Reactエンジニアが一度は直面する課題への処方箋でした。
以下、気になったポイントをまとめます。
useState の積み重ねが招く「Rube Goldbergマシン」
簡単な状態管理にはuseStateは最適です。しかし、アプリが成長するにつれてuseStateが10個、20個と並び、それらが相互に影響し合う「Rube Goldbergマシン（無駄に複雑な仕掛け）」のようなコードになってしまいます。この指摘には、深く頷かされるものがありました。特に「Boolean explosion（真偽値の爆発）」によって、あり得ない状態（例えば、読み込み中かつエラー中など）が理論上発生できてしまう設計の危うさを再確認しました。
「どこに保存するか」よりも「どうモデリングするか」
Davidさんは、状態をメモリやURLのどこに置くかという「ストレージ」の議論の前に、まず「アプリケーションのロジック（状態遷移）」を正しくモデリングすべきだと説いています。
単に値をセットするのではなく、「イベント（何が起きたか）」に基づいて「次の状態（どう変わるか）」を決定する宣言的な設計手法は、コードの予測可能性を劇的に高めます。この「イベント駆動」の考え方は、フロントエンドだけでなくシステム設計全般に役立つ視点だと感じました。
React 19とサーバーコンポーネントによる簡素化
React 19での新しいフック（useActionStateなど）や、Server Components、URLパラメータの活用により、手動でuseStateを管理するシーンはさらに減っていきます。そのような展望が示されました。
「状態を同期するためにuseEffectを頑張って書く」のではなく、プラットフォームやフレームワークが提供するプリミティブを使いこなします。ロジックをシンプルに保つ手法が今後のモダンな開発のスタンダードになると感じました。
まとめ
セッションのタイトルこそ刺激的ですが、その本質は「Reactの基本機能に頼りすぎるあまり、設計を疎かにしていないか？」という問いかけでした。
AIがコードを生成してくれる時代だからこそ、人間は「あり得ない状態を排除する堅牢なモデル」を設計する能力を磨くことが必要だと感じました。
我々も、目の前の機能実装だけでなく、数年後もメンテナンス可能な「シンプルで美しい状態管理」を追求していきたいと強く思いました。
Workshop
JSNation、React Summitでは参加者は現地セッションの他に、オンラインでワークショップを受講できます。その中で私は下記の2つを受講したので紹介します。
The React Developer's Guide to AI Engineering
このワークショップでは、Reactエンジニアが「AI機能をただ呼び出すだけ」の段階を超えて、いかにAIをアプリケーションのコアロジックに組み込み、高度なユーザー体験を構築するかを実践的に学びました。
LLMを「関数」として扱う設計思考
AIを単なるチャットUIとして捉えるのではなく、構造化されたデータ（JSON）を返す「信頼できる関数」として定義する手法が中心でした。Zodなどのスキーマバリデーションを組み合わせ、LLMの出力を型安全に扱います。フロントエンドのUIコンポーネントとAIをシームレスに結合させる設計が非常に参考になりました。
ストリーミングUIとRAGの実装
LLMの長い生成時間をユーザーに感じさせないための「ストリーミングレスポンス」の実装を体験しました。また、独自のデータソースをAIに参照させるRAG（Retrieval-Augmented Generation）の基本構成もハンズオン形式で学びました。Vercel AI SDKなどを用いた実装は、すぐにプロダクトに応用できる内容でした。
まとめ
AIエンジニアリングの本質は「プロンプトの調整」だけではなく、AIを既存のソフトウェアアーキテクチャの中にいかに「疎結合」に配置し、観測可能性を確保するかにあると強く感じました。Reactが得意とする宣言的なUIとAIを掛け合わせることで、Webアプリの可能性がさらに広がることを実感できたワークショップでした。
Debugging with Sentry AI using Seer, MCP, and Agent Monitoring
このワークショップでは、エラー監視ツールの定番であるSentryが、AIやMCPを活用してデバッグ作業を自動化・効率化する方法を深掘りしました。
自社開発AI「Seer」によるエラー解析の自動化
Sentryが開発した独自のAIサービス「Seer」の仕組みを学びました。Seerは、発生したエラーを過去の類似問題やスタックトレース、ソースコードの文脈と照らし合わせ、単なるエラー通知を超えた「根本原因の推測」と「修正案の提示」を自動で行います。人間がログを読み解く時間を大幅に短縮できる可能性を強く感じました。
MCPによるエコシステムの連携
最近注目されているMCPについても触れられていました。MCPを介してSentryのデータとAIエージェントを接続することで、エージェントが自律的にエラー情報を取得し、デバッグの調査を代行するデモが行われました。開発者がダッシュボードを確認しに行くのではなく、AIが自ら問題を調査して報告してくれる未来が現実味を帯びていました。
まとめ
AIによるデバッグ支援は「便利」な段階から「不可欠」なインフラへと進化していると実感しました。特に大規模なアプリケーション（ZOZOMETRYなど）では、膨大なエラーログから真に重要な問題を特定するのは困難です。こうしたAIツールを適切に監視フローへ組み込むことで、サービス品質の向上と開発者のメンタル負荷軽減を両立できると確信しました。
上記2つは個人で受講したのですが、この他のワークショップをチームメンバーにシェアして取り組んでみようと計画中です。
イベント全体を通じて感じたこと
実は昨年も同イベントに参加したのですが、1年で大きく変わったように感じました。まず、今回のセッションの内容は予想通りAI関係のものが大幅に増えていました。さらに、内容もシニア向けにフォーカスしたものが増えた印象でした。
セッションの中でも「AIの導入により54％のリーダーがジュニアレベルの採用を減らすことを検討している」という発表がありました。実際、去年は求職中の卒業生やジュニアレベルのエンジニアなど様々な人がいました。一方、今回会話した人々は全員経験のあるエンジニアでした（たまたまなのかもしれませんが）。AIの台頭により我々エンジニアを取り巻く環境は大きく変わりつつあることを実感しました。
昨年は「世界のエンジニアと交流でき、技術知識をアップデートできた！ モチベーションが上がった！ 楽しい！」という感想が主でした。今回はそれだけでなく、エンジニアとしてこれからの社会を生きていく上で気持ちが引き締まり、去年とはまた違った方向性でモチベーションが上がりました。ワクワクするような新しい技術がこれからもたくさん出てくるでしょう。その中でも楽しみながらアップデートして行きたいと改めて感じたカンファレンスでした。
最後に
最後に、ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！
