トーク

文字と画像を並べたいだけなのに縦位置が合わない！ 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の恩恵を手軽に受けられる

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

私たちの開発体験を高めるものとして、ソースマップは必要不可欠ともいえる存在です。しかし、ソースマップをじっくり眺めたことがある方は少ないと思います。

かく言う私も、「元のコードへの参照を保持してくれるJSONのやつ」という程度の認識でした。しかし改めて中身を見てみると、"mappings"というフィールドには「AAOI;AAPJ,SAASA,kBAAkB...」といった4~6文字程度のアルファベット列がたくさん詰め込まれいています。

これはVLQというアルゴリズムによって生成される文字列なのですが、今回のセッションではこのロジックなどを中心に、ソースマップがどのように生成され、元のコードへの参照をどのように保持しているか説明します。

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パターンライブラリを作成し、プロダクトの共通基盤を構築することで、サービスの立ち上げを加速させるための取り組みについての経緯や事例についてご紹介します。

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

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

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

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

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

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なのか？」という視点で語ります。

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

「useEffectってなんかわからんけど使わない方がいいらしい」

ReactのuseEffectって便利ですよね。
ですが本来の用途とは異なる使い方をされることが多く、公式ドキュメントにも「そのエフェクトは不要かも」という項目が作られるほどです。
しかし非推奨ではなく本来使われるべき用途があります。
正しい使い方とは何か？AIにコードを書かせるとuseEffectを多用する部分も見られ、正しく使っているか見極める必要性が増してきました。

本セッションでは、useEffectの役割を使用例を交えながら説明します。
なぜ非推奨と言われるような風潮になっているのか、現代のライブラリ事情も合わせて解説します。
useEffectの使い方を見極められるようになれば幸いです。