トーク

コードベース全体に関わる変更に立ち向かっていますか？

「自分でやるのは時間かかりすぎるけど、AIに任せるのは正確性に不安がある。かといって静的解析は設計のコストが大きいよなぁ...」
こんな風に思いながら放置されているタスク、あなたのプロジェクトにもあるのではないでしょうか。

今回は、AIと静的解析の協働によって安全性と低コストを両立したTypeScriptの一括変換アプローチについてお話しします。

AIを元に静的解析を低コストで実現するアプローチ、静的解析を元にAIを安全に動かすアプローチの２つを比較し、双方のメリットデメリットを比較しながらより良いアプローチを模索します。

本トークでは、WebRTC配信に“わざと通信障害”を起こし検証する技術を紹介します。
WebRTC は JavaScript API を呼ぶだけで、Webブラウザ間でカメラ映像・音声を暗号化し P2P でリアルタイム送受信できる技術です。
私たちの研究では、WebRTCを用いた車載カメラ映像配信を検討しています。実験用のバーチャル都市をUnityで構築し、Unity Render Streamingを用いてUnity内の車載カメラからWebブラウザへのWebRTC配信を実現しました。加えて、Linuxのtcコマンドを用いて任意の帯域制限、遅延、パケットロスを発生させる機能を実装しました。
通信障害による映像の崩れ方、tc制御の課題と対策、複数ストリーム表示の工夫等、リアルな話をお届けします。
「通信障害で映像はどう乱れる？」そんな疑問をお持ちの方、ぜひお聞きください！

Vitestは今やフロントエンド開発に欠かせないテストランナーの一つですが、「モック」機能がどう動いているかを深く知る機会は意外と少ないのでは？
このセッションでは、Vitestがどのように関数やモジュールを“すり替え”、テスト時に挙動を偽装しているのか、その内部のしくみを追いかけます。

ESMの制約、Viteとの連携、vi.mock()がやっている魔法、spyとの違いなどを解き明かしていきます。
「ただの便利なAPI」が、実はどれだけ緻密な仕組みの上に成り立っているのかを一緒に覗いてみませんか？

想定する聴講者
-VitestやJestを普段から使っているが、内部動作までは知らないフロントエンドエンジニア

• テストツールやバンドラの裏側に興味がある方

WebAssembly の名前は一度は聞いたことがあったり、使い方は知ってるがその技術が目指しているゴールや思想を知らない人が多いかと思います。WebAssembly は Web 標準として組み込まれるために以下の 4 つの目標を挙げています。

1. 高速かつ高効率、そしてポータブルであること
2. 可読性があり、デバッグ可能であること
3. 安全であること
4. ウェブを破壊しないこと

本セッションでは、実際に策定された仕様や実装例から、WASM を利用する開発者の目線からどのように Web 標準として組み込まれ、モダンなフロントエンド技術からどのように利用できるのか、順を追ってご紹介しようと思います。

フロントエンドエンジニアの登場以降サービスのUIはどんどん使いやすくなる一方で裏側のUIロジックは複雑になる一方です。
Reactはコードを宣言的にかけるようにしてくれましたが、現在のアプリケーションはそれでもなお複雑なロジックを抱えています。

私は業務の中でReact/Next.jsのアプリケーションのリファクタリング業務などを行っており、その経験を元に現在業務でReactを活用している人向けに、分かりやすいReactコンポーネントの書き方について紹介させていただきます。

大まかな構成

• 漸進的にコンポーネントを移行する
• C/Pパターンから学ぶファイル構成の重要性
• Reactを使いこなそう

※構成は現状の想定のため少し内容の変更があるかもしれません。

旅行アプリ『NEWT』では、ツアー、ホテル、マガジンの機能をモノレポ内の独立したNext.jsアプリとして構築し、これらをメインドメイン配下にリライトとベースパスで統合しています。

さらにリライト機能を駆使し、(1)空港/出発地コードのURL正規化、(2)マガジン記事のクロスドメイン提供、(3)クエリパラメータのパス変換、(4)外部ノーコードツールの同一ドメイン統合などを実現しています。
これによりマイクロサービスごとの独立性を保ちながら、ドメインオーソリティの集約・ドメインランクの大幅な向上を達成しました。

状態管理やログ分析への課題と、それらを乗り越えてドメインランク向上に貢献した実践知を、具体例を交えながらご紹介します。

■ 想定観客：フロントエンド中級者〜上級者、SEOを意識したアーキテクチャ設計に興味がある方
■ 期待効果：マイクロサービス環境でのSEO戦略立案など

【セッション概要】
近年のフロントエンド開発は、AIによる開発体験と生産性がより求められるようになってきました。そんな中で業務上で、どんなふうに私たちがAIと向き合ってきたか、どうやって生産性を上げることができたのかなどをトピックに話します。

本セッションでは、特に以下の3つについてお話しします。

• Design to Codeをより効率的に実現するFigma MCPの活用法を実践例を交えて紹介します。
• AIの力を借りて、いかに開発効率を高めていくかについて、私が思う勘所を共有します。
• これらの取り組みを通じて私たちが目指したい理想の開発体制や文化についての展望を提示します。

【対象者】

• フロントエンド開発の生産性を向上させたいエンジニアの方
• 実際のAI x フロントエンドの実践例を知りたい方
• よりAIを活用できる方法に興味がある方

現代のフロントエンド開発では TypeScript を用いることが多く、開発者は型の恩恵を享受しながら本質的な開発に集中できます。

しかし、REST API を挟んだ「外界」との接続点において「型安全」は必ずしも担保できるわけではなく、仮初めの型定義に頼った開発を余儀なくされる場面も少なくありません。
あるいは、バックエンドから書き出したスキーマから TypeScript 用型定義を生成する手もありますが、開発においてバックエンドが先行する必要があるなどの難点を抱えています。

このトークでは、

• 「REST API 型安全は誰の嬉しさなのか」という原点に立ち返り
• バックエンドと協調しながら双方が嬉しい「API 仕様」の共有を実現する手法について
• 技術面だけでなくドキュメンテーションの観点からも

「REST API 型安全」を考え直すきっかけとなることを期待してお話します。

サービス成長に伴い、機能の複雑化やマーケティングツール導入によってパフォーマンスが劣化する課題が発生します。弊社の提供する旅行アプリ『NEWT（ニュート）』でも同様の問題に直面しました。
本セッションでは新機能開発で忙しい中でも、AIを活用して効率的にパフォーマンス改善を効率的に実現する手法をお話しします。アクセス数の多いページに改善対象を絞り、LighthouseとDevToolsのPerformance AIアシスタント、ChatGPTを組み合わせることで、設定ミス、不要ライブラリ、分析ツール読み込み順序などの問題を手軽に特定できました。問題の修正にはDevinを用いています。
サービス成長期におけるパフォーマンス改善の優先順位付けと、AI活用による効率的な問題解決アプローチをお教えします。

プロダクション水準のWebアプリ開発において、ReactはUI構築のためのJavaScriptライブラリとして、国際的にも事実上の一強状態であると言えます。
Next.jsはそれを支えるReactフレームワークとして、App RouterをやRSCといった革新的なメカニズムをReactに先駆けて導入してきました。
しかし移行の困難さやSSRに偏重した姿勢は「Next.js疲れ」を開発者にもたらし、Remixなど他のフレームワークへの離反も招きました。

本発表ではNuxtやSolidといった「React以外の」オルタナティブなOSSフレームワークの開発体制に着目し、フロントエンドを取り巻くエコシステムを「地政学」の観点から読み解きます。

米国を中心に激変しつつある昨今の国際情勢において、本発表がエンジニアとしての技術スタックを見つめ直すきっかけとなることでしょう。

プロダクト開発におけるAI活用は、現状コーディングタスクが一般的です。しかしそれ以外の開発タスクにおいても、AIを有効に活用できる可能性があります。
その一例としてユーザービリティテストがあります。

ユーザビリティテストはユーザー体験を改善するために重要ですが、その継続的な実施には多大な時間とコストがかかります。また人間の主観的な評価が求められるため、自動化は困難な領域とされてきました。その一方でAIエージェントを用いてユーザーの行動をシミュレートし、擬似的にユーザビリティテストを行う萌芽的研究が登場しています。

本セッションでは、実際のプロダクト開発現場にAIエージェントによるユーザビリティテストをPoC導入した結果、得られたインサイトを共有します。
また、AIエージェントの活用がユーザー体験の改善に今後どのように貢献できるのか、その課題は何かについても考察します。

React でパフォーマンス最適化のために React.memo を使うことがありますが、ちゃんと使うことは意外とトリッキーです。

たとえ React.memo でメモ化しても、props がオブジェクトや関数だと参照が毎回変わるため、再レンダリングが発生してしまいます。その場合は props も useMemo や useCallback を使ってメモ化しないといけません。

何か思いませんか？はい、めんどくさいし冗長です。

この課題を解決するために React チームは2021年に React Forget を発表しました。コンパイル時に依存関係を解析し、自動でメモ化を挿入してくれる仕組みです。そしてその実装である React Compiler は2025 年に RC版として公開されました。

その React Compiler の仕組みや導入方法を紹介したいと思います！

2025年3月、styled-components がメンテナンスモードへ移行することが発表されました。
弊社を含め、多くの開発チームが次に選ぶべきスタイリングライブラリに頭を悩ませているのではないでしょうか。

どの選択肢にも移行コストは伴いますが、できる限りその負担を抑えたいのが理想です。
本セッションでは、コストを抑えつつ次世代の要求を満たす有力候補 「Next-Yak」 にフォーカスし、その可能性を深ぼっていきます。

・Next-Yakとは
・Next-Yak が有力候補となる理由
・主要ライブラリとの比較
・現行プロジェクトでの移行検証と得られた知見

上記トピックを交えながらお話しします。

対象: フロントエンド初心者～中級者向け予定

最近はAIエージェントによるコーディングが急速に発展し、フロントエンドの開発経験がなくても、AIが高品質なコードを生成することができるようになりました。
しかし、プロダクトにバグが発生した際、ユーザーに影響を与える責任を負うのは開発者です。
AIに「何を作ってくれ」と指示するだけでなく、適切な作業計画を立てて実装を進めることで、より高品質で保守しやすいコードを実現できると考えています。

このトークでは、入力フォームの実装という基本的な機能の開発を例に、日頃行っている作業工程を発表したいと思っています。

• 実装の順序
• バリデーションの方法
• テストの設計・実装方法

『それはもっといいやり方がある』『なるほど、そこは取り入れても良いかもしれない』といった議論の叩き台になれば幸いです

目まぐるしく移り変わる web フロントエンドの世界において最も重要な要素とはなんでしょうか。ずばり「互換性」です。

ライブラリの提供する API や体験、運用されているコードのインターフェースやプロダクトの提供する価値に至るまで、私達 web フロントエンドエンジニアは常に「互換性」と向き合っています。

本トークでは、そんな「互換性」の重要性について紐解き、このトークを通じて皆さんの「互換性」に対する考えが変わることを期待しています。

• 互換性ってなんだ？
• 互換性に裏切られた例
• 互換性に救われた例
  • webpack から rspack への移行など…
• 互換性との向き合い方

アプリケーション開発でSVGのイラストを使う場面は多いですが、中身については実は見逃されがちです。このセッションでは、SVGの基本的な構造から、光る・動く・触れるイラストの実装方法、さらに情報可視化の応用まで、SVGの多彩な表現力と実用性を紐解きます。
line要素やcircle要素、path要素といった基本的な要素から、動的なイラストを定義できるanimate要素を使ってイラストを光らせたり動かしたりする方法にも触れます。tabindex属性を使ってキーボードでも操作可能にしたり、多言語に対応したりして、アクセシブルなイラストを作る方法も提案します。
後半では、SVG要素の機能と簡単なCSSを使って作る地図機能の実装の一例を紹介します。この実装は、天気予報図など、イラストと連動する情報を提供したい場面に応用できます。
SVGの魅力を再発見して活用の幅を広げましょう！

CSSは、変数や関数、様々な擬似クラスや制御文(if else)などの登場で、UI実装をマークアップで完結できるような進化を遂げています。
便利な構文が増え、JavsScriptが介在しない軽量なUIを組みやすくなった反面、複雑な記述を生み出しやすくもなっています。

本セッションでは、これまではJavaScriptが必須だったが、今ではCSSで実装できるUIと、これに対するテスト手法を検討し、CSSによる堅牢かつ軽量なUI実装の可能性を探ります。

・どのようにすればCSSを安全に活用できるのでしょうか？
・CSSで果たしてどこまでフロントエンドを開発できるのでしょうか？
・CSSは今後のフロントエンドの開発で、どういった立ち位置になるのでしょうか？

以上の問いに対する答えとなるようなセッションとなっています。

AIエージェントは、ユーザー体験を劇的に変える可能性を秘めています。タスクの非同期実行や、データに基づいた最適なアクション提案など、その恩恵は計り知れません。しかし、これまでのアプリケーションとは異なる特性を持つAIエージェントにおいて、セキュリティ、特に認証・認可の設計は十分に考慮されているでしょうか？

本セッションでは、セキュアなAIエージェントアプリケーションを開発するにあたり重要な認証、認可の4つの観点について取り上げます。

• ユーザー認証: アプリ利用者（ユーザー）の安全な識別と信頼性確保
• AIエージェントによる外部API呼び出し: 外部サービスアクセス時の認証情報管理
• バックグラウンドのAIエージェント認可: 非同期・自律的なAIエージェントが処理を行う際の同意取得
• 外部データへのきめ細かなアクセス権の制御: RAGなどで扱うデータソースへの適切なアクセス制御

「Webエンジニア」から「フロントエンド」という職域が分化してから、フロントエンドにまつわる領域は広がり続け、覚えておかなければならないことは多くなってきています。
「今、何を学ぶべきか」「代わりに何を後回しにしてもいいのか」と情報の取捨選択に迷う人も多いと思います。

本セッションでは、チームの技術判断を担う立場から、日々の情報収集をどのように技術選定へ繋げているのか、その具体的なプロセスを失敗談も交えてご紹介します。

技術の選択肢が数多くある中で、何を学び、何に注目すべきかの判断は、個人のみならずチームや組織の成長にも直結します。
特に「なんとなくの技術選定をやめたい」「キャッチアップの精度を上げたい」「情報をうまくチームに還元したい」と感じている開発者に向けて、情報との付き合い方を改めて見直すヒントをお届けします。

JavaScriptでリストをソートする際、多くの開発者は sort() 関数を何気なく使っているのではないでしょうか？

しかし、「ソート」と一言で言っても、複数のアルゴリズムが存在しており、それぞれ特徴や性能が異なります。
また、JavaScriptの内部実装は、使っている実行環境（エンジン）によって異なり、sort()関数もその例外ではなく内部で使用されているソートアルゴリズムが異なるのです。
つまり、同じコードでも、実行環境（エンジン）によって処理速度に微妙な差が生じる可能性があるということになります。

本トークでは、普段何気なく使用しているsort() 関数の裏側に焦点を当てて、実行環境（エンジン）ごとのソートアルゴリズムの違いや処理速度の微妙な違いなどをお伝えできたらと思います。