文字と画像を並べたいだけなのに縦位置が合わない！ flexboxにしてみても…合わない！
一通りの画面構成ができるようになったと思いきや、インラインレイアウトにはまた違う世界が広がっています。

インラインレイアウトの基本から、フォントに依存する問題やフラグメンテーションについて解説、さらに広がる関連仕様への橋渡しを示します。

とりあえずflexbox、とりあえずgridではない、「なんでこうなるのか」をわかり、インラインレイアウトを活かせるWebフロントエンドエンジニアになるための時間です。

AIが書き散らかしてしまうリアクティビティが雑なコード！
ESLintのカスタムリンターを作った話をします。

Viteでシンプルなカウンターアプリを作成し、開発サーバを起動したあと、ブラウザに配信されるJSファイルには様々な工夫が施されています。
例えばソースマップの情報が追加されていたり、HMRのための処理が追加されていたり、jsx（<Hoge/>）がjsxDEV関数の呼び出しに変換されファイル名などが追加されていたりします。
このセッションでは、実際に出力されたJSファイルを見ながら、それらが何のために追加・変換され、私たちの開発体験をどのように向上させているのかを説明します。

出力ファイルをフックに、深さより広さを優先して下記の内容について触れる予定です。
初学者の方が、フロントエンドの高い開発体験の裏側にある技術について、興味を持つきっかけになると嬉しいです。

• ソースマップ
• react-refresh
• jsxの変換
• /@_ PURE _/

pnpmを使ってmonorepoでSaaSを管理していたあなた。
しかしある日突然、react-hook-formが動かなくなったり、Reactで不可解なランタイムエラーが起きるようになりました・・。

package.jsonの指定に関わらず、条件によっては同じパッケージが複数インストールされてしまい、正しく動作しなくなってしまうことがあります。
そのメカニズムと解決方法をお話します。 (デバッグ用コマンド公開予定)

JSXで書ける！hooksで状態管理できる！描画の自由度も高い！なのにあまり周囲で採用を見ない「PixiJS React」の話をします

PixiJS React は、2D Canvas 向けの高速な WebGL ライブラリ「PixiJS」を React プロジェクトで扱いやすくするためのラッパーです。
パフォーマンスの高さと柔軟な描画力をそのままに、React の世界観で使えるのが大きな特徴です。

• JSXでいつも通りコンポーネントとして記述できる
• useStateでReactのライフサイクル上で扱える
• WebGLの恩恵を手軽に受けられる

実際のプロジェクトでの活用事例をベースに、他のライブラリとの違いや、運用上の工夫・ハマりどころも交えて、その魅力を余すことなくお伝えします！

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

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

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

JavaScript には ES2015 の時代からジェネレーターとよばれる機能が存在しています。
当時は非同期処理を扱うことができる構文として着目を浴びましたが、今日ではこれは Async/Await がデファクトな構文となりました。

ジェネレーターは仕様に取り込まれてから 10 年という歳月が経過しようとしていますが、未だに世の中に浸透したといえるような使い方は皆無といっても過言ではないほど見かけません。
特徴と挙動は知っていても「で、これで何が嬉しいんだっけ？」となってしまうのが現状です。

このセッションでは以下の（特にわかりづらい）特徴からジェネレーターの真価と魅力について解説していきます。

• ジェネレーターはイテレーターでありイテラブルである
• ジェネレーターからジェネレーターを呼び出すことができる
• yield*は全てのイテラブルを消化することができる

Webアプリや入力フォームでよく目にする「〇〇文字以内」という字数制限。
しかし、全角・半角・絵文字などを含めた時にその文字数カウントは果たして正確でしょうか？
本トークでは文字コードと文字数認識の仕組みと実装時におさえておきたいベストプラクティスを紹介します。

本セッションでは、現在開発している医療系 SaaS を事例に、業務系 SaaS におけるフロントエンド品質保証の「現在地点」をご紹介します。

業務系 SaaS では、機能が適切に利用でき、ユーザーの課題が適切に解決できることがより求められます。とくに医療系 SaaS では人の命にも関わってくるため、厳格な品質保証が必要不可欠です。

React で作成されたメインのWebアプリ、サービス間連携機能およびその管理画面、サブ機能としてのモバイルアプリなど、事業上の注力度合いが異なる複数のシステムを運用しています。開発プロセスでは仕様書との整合性チェック、コード生成、テストケースの整理などさまざまな場面で AI が活用され、従来の手法と AI 支援を組み合わせた品質保証を実践しています。フロントエンドエンジニアとしてどのような品質保証アプローチを実践しているのかをお伝えします。

2011年頃にBaaS(Backend as a service)という言葉が流行り、「バックエンドエンジニアが不要になる未来」のようなことが言われたりしましたが、2025年現在、全然バックエンドエンジニアは不要になっていません。かくいう私も「もしかしてReactを書ければサービス開発全部1人でできるのでは？」と夢見て勉強した1人でして、「フロントエンドうおお！」と意気込んできましたが、そのような夢は見事に砕かれました。ビジネスが大きくなるにつれ、サービス連携やデータ連携やセキュリティなどの都合でクラウドに寄せた設計をせざるを得なくなりました。しかし世の中には夢を追いかけた同志や自分が残したBaaS前提のサービスは稼働し続けています。2025年からすると正解ではなかったと言えることもあるので、クラウドやAIなどのトピックから学んだプラクティスで、現在の正解を作っていきます。

昨今AIエージェントが実用レベルに到達し、フロントエンド領域において新たな変化が起きています。AIをインターフェースとして活用することで、アプリケーション開発の設計可能性が大きく広がったと感じています。

実際に取り組んだ2つのプロジェクトでは、非エンジニアチームがAIエージェントを通じリポジトリを直接更新し、より柔軟な修正を実現。Ruby on RailsからBraze(CRMツール)移行では、従来のドラッグ&ドロップエディターでは対応できないユーザーカスタマイズ部分を、AIで修正できる環境に整えメール修正範囲を拡張。Next.jsページでは、ヘッドレスCMSに代わりリポジトリ管理とVRTによる更新フローで、セクション・コンポーネント単位での柔軟な変更を可能にしました。

AIをインターフェースとして設計する考え方、チーム普及戦略、新しい協働モデルの可能性について実践知見を共有します!

事業拡大に伴い新サービスが次々と立ち上がるフェーズでは、限られたリソースにおける開発を加速させていくことが必要です。この取り組みの一環として、デザインシステムの構築や全社的なUIコンポーネントライブラリを作成する動きが一般的なものになりつつあります。

一方で、汎用性を持ったデザインシステムにおいては、プリミティブなコンポーネント実装に留まることが多く、画面パターンレベルでは各サービスで同じようなボイラープレートコードを繰り返し書くことになりがちです。

本セッションでは、全社的なデザインシステムの上でブランドに特化したUIパターンライブラリを作成し、プロダクトの共通基盤を構築することで、サービスの立ち上げを加速させるための取り組みについての経緯や事例についてご紹介します。

小規模なチームではフロントエンドの経験や得意分野に関わらず、全メンバーがコードレビューや開発に参加する必要がありますが、CSS、フレームワーク、UI設計への苦手意識が大きな障壁となりがちです。

本セッションでは、container/presentationパターンをベースとしたファイル分割による責務とテスト対象の明確化、TypeScript graphを活用した変更影響範囲の可視化、ドメイン固有のカスタムESLintルールによる設計ガイダンスとコード品質の自動化など、段階的な環境整備によってチーム全体のフロントエンド参加率とレビュー効率を大幅に改善した事例を紹介します。

特にAI生成コードが普及する現在、属人的なスキルに依存しない構造化されたレビュー体制の重要性についても言及します。

2018年から5年間、フロントエンドエンジニアが不在で保守がほとんど行われていなかったプロダクトのフロントエンドの技術的負債脱却のため、2023年にフロントエンドチームが結成され、負債脱却プロジェクトを進行していくことになりました。
この5年間でフロントエンド技術は大きく変化し、モダンな開発体験やチーム開発の効率化に繋がる多くのプラクティスが一般化しました。しかし、メンテナンスが止まっていたこのプロダクトには、古いツールや設計思想がそのまま残されており、技術面でも運用面でも多くの課題が蓄積されていました。
本セッションでは、現在もなお進行中であるこのプロジェクトについて、私たちが直面した失敗や得られた学びを交えながら、「なぜその選択をしたのか」「どんな工夫で乗り越えたのか」といった意思決定のプロセスも含めて、現場の視点からご紹介できればと思います。

2010年代初頭に「フロントエンド」というワード、技術分野を見かけるようになって興味を抱き、40代半ばとなった2015年よりフロントエンドエンジニアとしてのキャリアを積み始めて10年が経ちました。

この10年の間にHTML、CSS、JavaScriptもいろいろ進化や変化を続けてきました。

HTML5が浸透し始めた頃から5.1、5.2を経てHTML Living Standardへ。
テーブル、floatをレイアウトで使っていた時代からFlexboxを経てCSS Grid Layoutへ。
JavaScriptはES6、そしてES20XXやTypeScriptへ。
jQuery全盛の時代からVue.js、Reactへ。

本セッションでは、10年間の経験を踏まえつつフロントエンドについてどのような変化をしてきたのかを振り返り、フロントエンドの過去、現在、そして未来を考察していきます。

複雑なUIを作ろうとすると、どんな技術スタックでも状態管理が大きな課題になります。
Reactでは長年にわたって Redux や Recoil など多くの状態管理ライブラリが登場してきましたが、本当にライブラリが必要なケースはどのくらいあるのでしょうか？

本セッションでは、Reactの組み込みAPIである useReducer を軸に、ライブラリを導入せずに複雑な状態管理を実現する方法を紹介します。
Reduxの全盛期から useState の普及、そして Recoil のような“便利だけど依存の大きい”選択肢の登場まで、Reactにおける状態管理の変遷を俯瞰しながら、「なぜ今あえてuseReducerなのか？」という視点で語ります。

状態管理に悩んだことのあるすべての開発者に向けて、フレームワークを問わず通じる考え方のヒントを共有します。

以前はCSS側でime-modeを指定すればIMEをOFFにするだけで済んでいたIME入力制御ですが、現在ではセキュリティやアクセシビリティの観点から、ブラウザによる強制制御はできなくなっています。
その結果、OTP入力のような「必ず半角数字で入力してほしい」場面で、全角数字が入力されて2マス分消費されてしまうといった課題が生まれてきます。
このトークでは、過去の入力制御手法から、現在主流となっているinputmode や type属性・バリデーションなどの手法を整理し、現在のIME入力制御のベストプラクティスをお伝えします。

複数のフロントエンドアプリを運用する中で、コードの重複、責務の曖昧さ、変更時の影響範囲の広さに悩んでいませんか？

本セッションでは、4つのフロントエンドアプリケーションを1つのMonorepoに統合した事例をもとに、統合がきっかけとなって進んだリアーキテクトを紹介します。

パッケージの責務の境界を見直し、共通コンポーネントやデザインシステムを整理する過程で、開発体験を大きく改善しました。
さらに、静的解析やAIコーディングの適用範囲も拡大し、チーム全体の生産性にも変化がありました。

以下の観点からお話しします：

• Monorepoへの統合プロセスとツール選定
• 責務分離を軸にしたアーキテクチャ再設計の手法
• 技術的な変化がもたらしたチームの変化

複数のアプリケーションを抱える開発チームや、既存システムのリアーキテクトに取り組む方々へ、実践的なヒントをお届けします！

WICGで提案されているSoft Navigationsは、SPAにおけるpushState()等による履歴遷移を、ナビゲーションとして検出・測定可能にする仕様です。従来のNavigation TimingやWeb Vitalsでは対象外だった同一ドキュメント内の遷移にも、LCPやCLSといった指標を適用できるようになります。このLTでは、ユーザ操作やDOM変化などに基づく検出条件、現在の実装状況、そしてWebパフォーマンスの観測設計に与える影響について紹介します。

ClineやGitHub Copilotのようなコーディングエージェントの登場により、エンジニアが従来のチャットによるLLMとの対話からAIエージェントを使用する機会は増えてきていると思います。
一方で、生成AIアプリケーションの開発という点でも、業務をワークフローとしてAIエージェントに実行させるAgentic Workflowアプリケーションの開発というのも増えてきています。
本トークではAgentic WorkflowアプリケーションのUI実装をする際に発生した複雑な状態管理に立ち向かうために行ったことについてお話しします。

話すこと

• チャットアプリケーションとAgentic WorkflowアプリケーションのUI実装における違い
• Agentic Workflowの状態管理を行う際の複雑さ
• XStateを使用した解決策の提案