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

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

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

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

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

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

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

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

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によるラベル検査機能をリリースしました.
これは端末のカメラで撮影したラベル画像から異常を判断するもので、従来はフロントエンドで撮影した画像をGPU搭載サーバへ送り推論結果を返していました。しかし通信待ち時間や運用コストの問題があります。

そこで今回は、フロントエンドならではの問題を克服し、C++で実装した推論処理を呼び出すWasmを採用。Wasmのバイナリを約9MBまで圧縮し、SIMD最適化やLazy Loadingを駆使しブラウザ上で約200msの高速推論を実現しました。また、Wasm開発時・リリース時に陥りがちな問題や、押さえておきたいメモリ管理やキャッシュ制御、エラーハンドリングのポイントも交えてご紹介します。

実際にこれらに関する一部のことは記事で紹介しています。
https://tinyurl.com/3rwtwa3m

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

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

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

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

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

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

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

ハイパーメディア駆動アプリケーション（HDA）アーキテクチャは、従来のマルチページアプリケーション（MPA）の単純さと柔軟性に、シングルページアプリケーション（SPA）の操作体験を取り入れる設計アプローチです。本セッションの前半では、HDAの設計思想に基づく実践例として、htmxを用いたWebアプリケーションの画面遷移や状態更新の設計手法を具体的に紹介します。後半では、局所的な動的振る舞いが求められる場面において、Islandアーキテクチャを取り入れて補完する方法とその設計上の工夫について考察します。

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

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

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

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

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

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

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

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

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

ライブラリやSDKをメンテナンス/品質保証する際、ある特定バージョンや配布形式、またそれらの任意の組み合わせによってデバッグや動作確認をしたいケースはしばしばあります。 もしそれがnpmパッケージであれば、個別にビルドするのでは手間がかかり、また幾つものバージョンを事前にバンドルするとアプリケーションサイズが膨大になってしまうことが容易に想像できます。
この課題は、Dynamic ImportとViteのビルド設定をうまく組み合わせることで解決することができます。

このトークでは、Viteの具体的なビルド設定の内容を踏まえ、実際にビルドが実行されてからランタイム上でパッケージが解決されるまでのフローも解説しながら、この課題に取り組むにあたり工夫が必要だった点や実装時の注意点を紹介していきます。

長年にわたり、フロントエンド開発の現場を支えてきたSass。
その登場の背景には、当時のCSSが抱えていた課題を解決したいという強いニーズがありました。

それから時が経ち、CSSそのものも大きく進化を遂げています。
Sassが提供してきたような機能も、モダンなCSSで標準的に利用できるものが増えてきました。

このトークでは、モダンCSSの機能を、Sassでおなじみの機能と比較しながら紹介します。
さらに、CSSの進化を俯瞰的に眺めることで、今後のCSSがどのような方向に向かうのかを考察してみます。

想定する参加者

• モダンなCSSの機能を知りたい方
• Sassを知っている・知りたい方
• CSSの未来に興味がある方

LLM 時代に急増した「死んだexport」をKnip×ESLintでゼロ化する提案です。
ESLintだけでは検出できない、テストやStorybookで利用されている関数にも対応し、
私の担当するプロダクトでも10以上の関数を削除しています。

内容

1. Knip設定 & ESLint連携
2. Storybook・テスト用のexportへの対処
3. GitHub Actionsで再発を防ぐCIフロー
4. Claudeによる削除候補レビュー PoC

対象

プロダクトの信頼性を高めたいフロントエンド開発者

持ち帰れるもの

明日の30分で完了できる設定。それ以降は不要な関数とコンポーネントがゼロに。

—

ライブデモ込みの30分です。
私も以前、不安感を持って開発をした経験があり、そんな思いをする方を減らしたいと考えて提案をしています。

普段の開発を行っていると、mdnのCSSリファレンスを端から読むことってそんなに多くはないと思います。
ですが改めて読んでみると、「知らなかったけどこれは便利だな！」というものから「このプロパティいつ使うん？」とつい思ってしまう様なマイナーなものまで、様々なプロパティと出会うことができます。
今回の発表では、mdnのCSSリファレンスを全て読んで見つけたマイナーなプロパティを紹介しながら、何とか業務内でも用いることが出来そうな用途を可能な限り捻り出して紹介します。
「自分でmdnを通読するのはめんどくさいけど、何か面白いものがあるなら知りたい！」という贅沢な方々に向けて、すぐに業務に役立つ訳ではないけれど知っておくといつかどこかで使えるかもしれない知識をお届けします。

知れること

• 一般的に広く使われていないが、特定の用途で便利なプロパティ
• 通常では使わない特異なプロパティ

私のチームは現在、長年利用されているレガシーシステムの移管プロジェクトに取り組んでいます。

アプリからインフラ、組織体制まであらゆる面で見直しと再設計が必要となり、当然フロントエンドも大規模なマイグレーションが必要となりました。

しかし蓋を開けば遠い昔に見たMarionette.jsやUrushiなど古のフレームワーク群が数多く登場。
フロントエンドエコシステム黎明期に作られたスクリプト群に対し、現代の静的解析はまともに機能しませんでした。

当然ながらAIエージェントも適切に回答できることが少なかったため、自力で解読して再設計することから始めました。

ステップ数は1ファイルあたり3000〜10000強。
それらをモダンな構成へ移行する試行錯誤のなか、巨大フロントエンドをモダンに仕上げる「ツボ」があることに気がつきました。
それらについて、私たちの挑戦と共にご紹介いたします。