プロポーザル

styled-componentsからCSS Modulesへ移行する際、CSS-in-JSだからこそ実現できていたJavaScriptでの分岐処理をどう置き換えるかが課題になりました。SCSSだけで完結させようとすると複数セレクタの組み合わせが必要になり、その切り替えを担うライブラリとしてCVA（class-variance-authority）が候補に上がりました。しかし、個人メンテナーへの依存や更新停止のリスクを考慮し、採用を見送ることに。以前なら工数を理由に既存ライブラリを選んでいたかもしれませんが、AIエージェントがある今、clsxベースで自作するハードルは大きく下がりました。OSSを「使わない」判断ができた背景をお話しします。

ReactやVueといったコンポーネントベースのUI開発が主流となり、アトミックデザインはUI設計のデファクトスタンダードとして一時代を築きました。

しかし、アトミックデザインの「5階層」の分類の定義には曖昧な部分も多く、「これはMoleculesか、それともOrganismsか？」といった議論は、度々エンジニアを疲弊させてきました。
それもあり、昨今ではアトミックデザインを用いないUI設計について積極的に議論されているように思います。

ですが、アトミックデザインの強みである「保守性・再利用性・一貫性」、そして「デザイナーとの情報連携のしやすさ」は、現代の開発においても依然として強力です。
このまま廃っていくのは非常に惜しい！

本LTでは、5年以上アトミックデザインに向き合ってきた私の個人的ベストプラクティスを紹介することにより、皆様の今後のUI設計の手助けとなることを目指します。

ライブラリを使わず <input type="file"> を用いて実装されたファイルアップロード機能を扱った際、 macOS から送信されたファイル名だけがサーバー側の検索と一致せず、データ取得に失敗する問題に遭遇しました。

見た目は同じ文字列でも、 OS や入力経路（フォルダ選択・テキスト入力）の違いによって内部表現（NFC / NFD）が異なる場合があります。今回の問題は、その差異がブラウザを経由してアプリケーション層まで持ち込まれていたことが原因でした。

本トークでは実際の再現手順を示しながら、この不整合がどのように発生するのかを整理します。その上で、ブラウザ標準APIでファイルアップロードを実装する際に、どの境界で正規化や比較責務を持つべきかという設計判断を取り上げます。

環境差異に依存しない、堅牢なアップロード実装のプラクティスを持ち帰っていただくことを目指します。

モバイルアプリユーザーの約25〜35%が、OS設定で文字サイズを標準以外に変更していると言われています。
この設定で文字サイズを変更している場合に、アプリ内のWebViewだけ文字サイズが変わらないことがあります。

実は、iOSならCSSの font: -apple-system-body;、Androidならネイティブ側の textZoom 設定を橋渡しすることで、Web側にもOSの文字サイズ設定を反映できます。

このとき重要なのが、文字サイズの変化を前提としたレイアウトです。 rem によるスケーリングはもちろん、文字量に応じて高さが伸びる設計や、要素が溢れた際の柔軟な折り返しなど、拡大を許容する実装が必要になります。 OSの設定をどう受け止め、UIを最適化するか。 境界を越えた実装Tipsを共有します。

AI に PowerPoint スライドを生成させたい。
しかし PPTX のファイル形式は複雑で、直接操作するのは難しい。

そこで、React 要素から SVG を生成するsatoriを参考に、宣言的なデータから PowerPoint を組み立てるライブラリを作りました。
中核にあるのは yogalayout による Flexbox レイアウト計算と、opentype.jsによるフォントメトリクスの解決です。
このパターンを使えば、ブラウザがなくてもフロントエンドの技術でレイアウトを構築できます。

本 LT では、ブラウザの外に広がるフロントエンドの技術と、このアプローチの始め方を紹介します。

Reactのkey、警告が出るから付けてるだけになっていませんか?
「なぜ必要なのか」を考えると、Reactの内部動作が見えてきます。

• Reactは何を基準にUIを更新しているのか
• keyはその中でどんな役割を担っているのか

このセッションでは、keyを入り口に、仮想DOMとReconciliationの仕組みを整理します。
実装を深掘りするのではなく、「だからkeyが必要なんだ」と腹落ちできることを目指します！

Panda CSSは、Chakra UIチームが開発したゼロランタイムで型安全なCSS-in-JSライブラリです。
私は新製品プロジェクトでPanda CSSを採用し、約2年にわたり実務で運用してきました。

本セッションでは、

• PandaCSSの概要と注目度
• ゼロランタイムのCSSライブラリを選ぶ理由
• 型安全が開発体験に与える具体的な影響
• Emotionやstyled-componentsとの思想・運用の違い
• 実際の開発現場で見えてきた強みと弱み
  などを具体例とともに共有し、CSSライブラリの採用判断に役立つポイントを整理してお話しします！

Webサービスのフロントエンドを開発していると、<link rel=”prefetch”>のような記述を見かけることがあります。
これはユーザーの動きや利用する際の環境を予測して、あらかじめWebページの読み込みやレンダリングなどを行い、パフォーマンスを向上させるための投機的読み込み向けの記述の1つです。

このセッションでは、link要素のrel属性で設定できる投機的読み込み機能を理解し、サービスの特性にあわせた使い分け方法をご紹介します。
また、ブラウザの実験的機能である投機ルールAPIで、従来の投機的読み込み機能のどういった課題を解決しようとしているのかについてもお話します。
対象者は、Webサービスのパフォーマンス改善に興味のある方を想定しています。

個人開発でWebアプリを量産したいけれど、ホスティング費用はできるだけ抑えたい。そんな悩みを抱える開発者の方に向けて、2026年時点での実用的なホスティング戦略を紹介します。
NextJSユーザー向けに、Vercelの代替選択肢としてCloudflare Workersを使ったホスティング方法を解説します。無料枠で何個までアプリをホストできるのか、具体的なデプロイ手順とともに実例を交えてお伝えします。
また、主要なホスティングサービス以外の選択肢として以下の方法も紹介します。
・NextJSに対応した低価格VPSの活用法
・バニラPHPアプリを共有サーバーで運用する方法
・ローカルサーバーとCloudFlare Tunnelを組み合わせた自宅ホスティング
各サービスの料金比較と実際の運用コストを明示しながら、皆さんの開発スタイルに合った最適なホスティング戦略を見つける手助けをします。

リファクタリングによるデグレーションは、機能は正しく動いているのに体験が劣化するという、テストでは捕捉しにくい領域で起こります。
ユーザーからの問い合わせが届く前に検知したい。しかし、すべての指標を監視するのは現実的ではありません。
本LTでは、「ユーザーの体験に悪影響を与えるか？」を基準に監視対象を絞り込む設計指針と、その基準をもとに筆者が実際にどのように指標を選定し運用したのかを紹介します。
特定の技術スタックに依存しない設計思想の話なので、どなたにも持ち帰れる内容です。リファクタリングに限らず、日々の開発で「何を監視すべきか」を判断するためのヒントになればと思います。

追加開発のたびにアプリケーションの仕様を設計書に書き写し、その設計書を見ながら実装する。
この往復作業は工数がかかるわりに付加価値が低く、設計と実装の乖離も生みやすい構造的な課題となっているのではないでしょうか。

本トークでは、SPA の画面から単一の HTML ファイルを自動生成し、「実画面そのものを設計の正」とする開発フローを紹介します。
生成された HTML モックは AI エージェントが直接読み書きできるため、画面の現状把握や改修案の作成に活かせます。
モックは開発サイクルごとに再生成するだけなので、従来の設計書のようなメンテナンスは不要です。
さらに Figma への取り込みも可能なため、デザイナーとの協働にも活用できます。

設計と実装をつなぐ作業に使っている時間を UX 設計やコンポーネント設計に回せるようにしたい、そんなきっかけになるフローをご紹介します！

差分の大きいPRを複数の小さなPRに分けることでレビュワーの負担を抑えることができます。
でも、チケットを細かく分割するのって正直めんどくさくないですか？
そんなあなたに！！！
エンジニア歴半年の学生でもできた、AIとタスク管理ツールを活用して"ちょっと楽に"チケット分割するためのヒントを、数千ファイルの変更を伴うチケットに立ち向かった経験をもとに紹介します！

React19.2で新しいHooksであるuseEffectEventが追加されました。
これにより古い状態を参照し続ける「stale closure問題」にメスが入り、イベントハンドラの貼り直しなど余分な処理をEffectとして実行する必要がなくなりました。
一方、どのようにして最新の状態を取得しているのかご存知でしょうか？
なぜ、依存配列に含めていないはずの最新の状態を持ってくることができるのでしょうか？

本セッションではReactのソースコードを紐解き、useEffectEventが内部でどのように「関数の同一性」と「最新状態の維持」を両立しているのかを解説します。

こちらの延長線の話となります。
https://zenn.dev/maguro_alterna/articles/17a0938c5b02a3

「重い計算処理の速度もメモリ効率もWasmが良い」という直感から、zip圧縮モジュールをWasm（Rust）で自作をしました。しかし、実際に使ってみると、既存のJSライブラリ（JSZip）のほうが使い勝手が良いという結論に達しました。
なぜJSライブラリのほうが良かったのか？というところをWasmの制限を絡めて紹介をします。
最後に、それでも私がWasmを使いたい理由についても語ります。

JavaScriptでの日付操作は、ブラウザの実装や実行環境のタイムゾーンに強く依存するため、フロントエンド開発における「鬼門」となりがちです。

実際に私のプロジェクトでも、日付フォーマットの違いによってタイムゾーンの解釈が変わったり、
toISOString を通した際に「1日のズレ」が生じたりと、Dateオブジェクトを正しく扱えなかったことによるバグが発生しました。

本LTでは、JavaScriptの仕様に基づいてバグの原因を深堀りつつ、環境に左右されない「堅牢な日付操作」の指針についてお話しします。

aタグを使ったLinkButton実装において、disabled状態にもかかわらずフォーカスが当たり、Enterキーで操作できてしまうケースに遭遇しました。

本LTでは、この挙動がアクセシビリティの観点でどのような点が問題になり得るのか、HTML要素の役割（セマンティクス）、W3C仕様、ARIA属性の考え方を踏まえながら見ていきます。
さらに、主要なUIライブラリの実装例を参考にしつつ、LinkButtonにおけるdisabled状態をどのように実装・表現するのがよいのかを考えていきます。

近年の Web における UI は装飾性の高いものが増えてきています。
a タグも例外ではなく、見た目や情報量に配慮した「装飾されたリンク UI」を求められる場面が多くなってきました。

こうしたリンク UI では、文字だけでなくアイコンや画像など様々な要素を a タグの中に含めることがあります。
これらの要素をレイアウトするために div タグを使うこともありますが、本当にそれは問題ないのでしょうか。

「a タグはインライン要素だから div タグを入れてはいけない」という認識を改め、現在の HTML 仕様ではなぜそれが可能になっているのか、その仕組みについて 透過的コンテンツモデル を中心に解説します。

React 19はServer Components・Actions・Suspenseの刷新により、データフェッチからレンダリングまでの体験を一変させました。しかし同時期、Rust製のoxfmtをはじめとする「高速・単機能」ツール群が既存エコシステムを塗り替えつつあります。見落とされがちな問題があります。ライブラリ本体の進化とツールチェーンの進化は同じ速度では進まないということです。新しいレンダリングモデルに最適化されたlintルールはまだない、CIの前提が変わっているのにパイプラインは旧来のまま──こうした「ズレ」がチームの開発体験を静かに蝕みます。本セッションでは、この1年のReact周辺とフロントエンドツールの動向を俯瞰し、両者のギャップをチーム開発・モノレポ構成・CI設計でどう埋めるかを具体事例とともに考えます。「最新を追う」だけでは得られない地に足のついた設計指針をお届けします。

実務に入りたての未経験エンジニアである私が、React Hook Form（RHF）とSWRを組み合わせた開発中に遭遇した「編集後に古いデータが残る」という不可解なバグ。その原因は、両ライブラリが持つ「ライフサイクル」の認識のズレにありました。

SWRがUX向上のために高速で返した「古いキャッシュ」を、RHFの defaultValues が「最新の初期値」として一度きりの評価で確定させてしまう。この両者の仕様同士の衝突をどう読み解き、どう解決したか。

本LTでは、単なるバグ修正に留まらず、ライブラリのライフサイクルをエンジニアがいかに設計すべきかという視点でお話しします。「ライブラリがよしなにやってくれる」という安心感の一歩先へ、実務での失敗から学んだ、状態管理における「意思表示」の大切さを共有します。

デザインシステムのコンポーネント配布はnpmパッケージが主流ですが、バージョン運用やブラックボックス化が課題になりがちです。
本セッションではshadcn/ui Registryを題材に、コンポーネントを「パッケージ」ではなく「コード」として配布する新しいアプローチを解説します。
CLIによって必要な実装がプロジェクトに展開される仕組みや、依存関係の解決方法を紹介し、従来方式との違いを整理します。
また、実装が手元に存在することでAIが内部コードを参照しやすくなり、修正提案や差分生成が行いやすい点にも触れます。

・ Registryの仕組みと導入の流れ
・ npm配布との比較と適用領域
・ AI代におけるコード配布の価値