ロジスティクス関係で働く人には、おじいちゃんが沢山います。
おじいちゃん達は、年齢による症状（老眼、認知負荷）や長年ちから仕事をしているため、指が太く細かい操作がしにくいなどの問題がありました。
それらを解決するために、webエンジニアがおじいちゃんに優しいUIを作ってみたお話です。
（硬く言うと、シニア世代に向けたアクセシビリティのお話です）

Webサイト制作の際に気を付ける点のひとつに、リソースの容量があります。
読み込み速度を意識しつつ、さらにWebGLを用いたカロリーが高いサイトはモバイル環境でも快適に動作させなければなりません。
画像圧縮にもお作法があるように、3Dモデルの圧縮にもお作法があります。

本LTでは、私が実際に3Dモデルを用いたWebサイトやWebARコンテンツ案件を実装する上で学んできた知見を活かし、
WebGL製サイトがモバイルでも快適に動作するのに欠かせないモデル圧縮の基礎と応用をお伝えします。

【話すこと】
・Webに最適な3Dモデルデータ形式とは？
・テクスチャとポリゴン、それぞれの最適化法
・アニメーション付きモデルの最適化法
・スマートフォンでも快適に動作させるコツ
・フロントエンドエンジニアがモデラーへ3Dモデルを外注する際のコミュニケーションのコツ

「改行が消えた」「謎のタグが混入した」…
WYSIWYGエディタにありがちな壊れやすさに悩まされたことはありませんか？

本LTでは、Tiptap を用いてHTMLの一貫性・拡張性・テスト可能性を兼ね備えた堅牢なリッチテキストエディタをどのように設計・開発するかを紹介します。

• ProseMirrorのスキーマ定義を活用したHTML構造の強制と正規化
• Reactコンポーネントの組み込みやプラグインによる拡張性
• TiptapのExtension単位での単体テストによる機能ごとの信頼性担保

について話します。
WYSIWYGエディタの扱いに課題を感じている方や、Tiptapを本格的に活用したい方にとって実践的なヒントとなる内容をお届けします。

「改行が消えた」「謎のタグが混入した」…
WYSIWYGエディタにありがちな壊れやすさに悩まされたことはありませんか？

本LTでは、Tiptap を用いてHTMLの一貫性・拡張性・テスト可能性を兼ね備えた堅牢なリッチテキストエディタをどのように設計・開発するかを紹介します。

• ProseMirrorのスキーマ定義を活用したHTML構造の強制と正規化
• Reactコンポーネントの組み込みやプラグインによる拡張性
• TiptapのExtension単位での単体テストによる機能ごとの信頼性担保

について話します。
WYSIWYGエディタの扱いに課題を感じている方や、Tiptapを本格的に活用したい方にとって実践的なヒントとなる内容をお届けします。

　p5.jsは、Processing言語をベースにした、クリエイティブコーディングのためのJavaScriptライブラリです。簡単にグラフィックやアニメーションを生成し、Web上で動作するインタラクティブな作品を創出できます。Webエディタを利用すれば、環境構築なしに利用することができます。
　昨年のフロントエンドカンファレンス北海道2024でもp5.jsについてLTを行い、Webカメラやマイクを使ったデモやtoioとの連携などのデモをお見せしました。しかし、まだまだp5.jsの魅力を伝えきれていません。本LTでは、昨年紹介できなかったWeb Serial APIを用いた外部デバイス(M5Stack)との連携や、物理演算を手軽に扱えるゲームエンジンp5playを、デモを交えてご紹介します。LTを通じて、p5.jsの可能性をお伝えできればと思います。

Reactのフレームワークといえば、Next.js？
いいえ、ReactベースのWebフレームワークはNext.jsだけじゃありません。
このトークではNext.js以外のフレームワークとして、 React Router（Remix）やWakuなどさまざまなReactベースのWebフロントエンドフレームワークに触れ、その結果と個人的な感想について話をします。

デプロイのしやすさ、フレームワークの機能、レンダリングの挙動 etc...できるかぎり多くの観点で比較に挑戦します。

※このプロポーザルは執筆（2025/5/27）時点の情報を多く含みます。当日トーク内容の詳細部分に変更が入る可能性があります。

Webフロントエンド開発において、グローバルでの状態管理は常について回ってきます。
特にクライアントサイドにおいては、バックエンドや外部のサービスから取得した状態をグローバルに持ち、バックエンドと同期を取りながら画面を更新していくことが前提となっています。
とはいえ、グローバルでの状態管理は開発が進むにつれて、認知負荷が高くなりやすかったり、全体像を把握しづらかったり、はたまたライブラリを扱うためのコードで見通しが悪くなったりするなど課題も多いのが現状です。

このトークでは、極力グローバルでの状態管理を避けていかに「取得⇨更新/同期⇨取得」のサイクルを実現するかについて紹介した後に実際の事例としてReact x useSWRでの実現例、CQRS的な実装（オレオレCQRS）を取り入れることによって解決できた事柄について紹介します。

next/imageを触ったとき、「widthとheightの数値指定が必須！？widthを親要素の100%でアスペクト比を維持したいな。。。」と悩んだことはありませんか？
そこに現れた救世主、fill=true。なんとこの要件をいとも簡単に満たしてくれます。
これで表示されているし一件落着。。。しかしここには１つ落とし穴があります。

next/imageを採用する理由の1つは、画像サイズを表示領域に合わせるように最適化して配信してくれることです。
しかし、fill=trueだと事前に取得したい画像サイズが不明であり、多くの場合では表示領域より巨大な画像が取得されてしまいます。

本トークでは起こりうる状況・原因・解決策を、imgタグ、devicePixelRatioの話を絡めつつお話します。

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

話すこと

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

長期的な保守性や再利用性を考慮して、Reactに依存しないライブラリを選ぶことがあります。
このLTでは、TanStack Query風のライブラリを簡易的に自作しながら、「Reactに依存しないライブラリ設計」とは何か、コードベースからイメージを掴みます。

• useSyncExternalStore と Pub/Subパターンを使った React と VanillaJS の連携
• Reactから他UIライブラリへの対応

について話します。

2025年現在、Viteはフロントエンド開発の至るところで見られるようになりました。
Next.jsを除く、ほとんどの主流なフロントエンドフレームワークで採用され、Webアプリだけではなく、ライブラリ開発やテストなどにも利用されています。

なぜ、これほどまでに普及したのでしょうか。
１つはスピードでしょう。ESModulesを基本とした設計により圧倒的な開発スピードをもたらします。
それだけではなく、もう１つはプラグイン開発のしやすさだと私は考えています。
Rollupをベースにしたプラグインインターフェースはプラグイン開発者の体験をワンランク上へと引き連れました。

本トークでは、簡単なプラグインの作成ハンズオンをしながら、プラグイン作成の容易さを確認し、Viteの内部的な動きをイメージできるようにします。

本発表ではドキュメント駆動な開発によってCoding AgentやCode Generatorなどを積極的に活用していくための戦略や取り組みについてお伝えします。
私が所属する組織で取り組んでいる内容、私個人で試してみて良かったこと、これからやっていきたいと思っている内容なども含めてお話しします。

• 人とAIで作業の分担、Coding AgentとCode Generatorの棲み分け
• UIやロジック、テストを生成するためのドキュメンテーション
• OpenAPIを用いたAPI仕様の記述とコード自動生成によるポータビリティの向上
• コード品質を担保するためのLinterやテスト、コメントの記述
• 継続的に品質・スピードを上げ続けていくためのドキュメントのメンテナンス

当日は上記に関するデモなども交えながら実際にどのように開発しているのかをお見せする予定です。

歴史あるフロントエンドコード内部は型のないJavaScriptで溢れかえっていませんか？ 私たちのチームも同じ問題に直面していました。
チームではフロントエンド担当1名を含むエンジニア5名でNuxt3アプリケーションを扱っています。そのうち8割はJavaScriptです。
この状況で、すべてのコードにTypeScriptを厳密に導入するのは、影響範囲・工数観点でも現実的ではありません。
本発表では、私たちが実践している段階的なTypeScript導入のアプローチを共有します。
特に「コンポーネント改修の優先順位付け」「現実的な型定義の落としどころ」、そして「妥協しなかったAPIスキーマの型定義」について具体的な事例を交えて解説します。
完璧な型システムを目指すわけではありません。重要な箇所に型を適用し、エンジニアが快適に開発できる環境を構築する実践的な知識をお伝えします。

Rust 製 NES エミュレータを 1 コードベースのまま

• wasm（ブラウザ）
• SDL2（デスクトップ）
• CLI（ターミナル）
  の 3 環境で動作させる設計方針を 5 分で紹介します。

今回の発表では主に以下の内容を詳しく話します。

• 純 Rust コアと UI 境界を trait で分離するアーキテクチャ
• ブラウザ向けに wasm-bindgen でバインディングを生成する手順
• Canvas＋WebAudio を用いたフレーム／音声レンダリング
• ts-bindgen 等を使った Rust 型 → TypeScript 型自動生成ワークフロー

Tauri は軽量でも「OS 依存 WebView」と「ビルド待ち」の二重コストが開発速度を阻害します。
Electron では Chromium が吸収していた OS 間の実装差異を自分たちで解決する必要があり、スクリーンキャプチャなどブラウザ未実装機能も Rust 側で補完しなければなりません。
さらに UI 修正の共有のために毎度フルビルド配布が必要で 15 分超の待機が発生します。
本発表では以下を紹介します。

• 音声API を Rust 側で抽象化し OS 環境に依存せず動作させる方法
• OS ごとに機能を分岐する方法
• Tauri API を Bridge パターンで抽象化し、ブラウザ／Tauri 環境をシームレスに切り替える手法
• plop によるボイラープレート自動生成で開発サイクルを高速化する仕組み

本セッションでは、Tauriフレームワークを通じたWebフロントエンド技術とRustを組み合わせたアプリケーションの開発事例を紹介します。

・ アプリケーションデモとアーキテクチャの紹介
・ Tauriの概要について
・ 他クロスプラットフォームフレームワークとの比較
・ Tauriを導入することで実際のプロジェクトで獲得した知見の共有
　- フロントエンド/Rust間の状態・疎通
　- 他デスクトップアプリケーションとの連携
　- フロントエンドエンジニアがRustを習得するために乗り越えるべき課題
・ macOSアプリケーションの頒布において直面した課題とその解決、OSSコミュニティへの貢献事例

2025年1月2日にRecoilがGitHub上でアーカイブされ、React 19で動作しないという問題を抱えたまま開発が完全にストップしました。

私の所属する会社ではRecoilを広く活用しており、データ取得からUI表示までを一貫してRecoilで構築していました。Recoilの代替としてjotaiなどのライブラリが挙げられますが、Recoilのデータフローが大きく複雑に絡み合っていたため、一括で移行することは困難でした。そのため、まずはデータフローの流れを可視化するツールを作成し、重要な点から剥がしていく方法を取りました。また、一定の基準を設けてRecoilをuseMemo、useContext, TanStack Query、jotaiに分割して移行しました。

本セッションではデータフローの可視化からRecoilを各ライブラリへ移行した方法について実例を交えてご紹介します。

アイディアと動作するプロトタイプの間には多くの地味な作業がある。技術選定から基礎設計、実装までやるべきことが多い。そこを生成 AI に任せて「動く仮説」を素早くつくり、ユーザーにあてていく開発スタイルを模索した。本トークでは、次の観点で実践内容を共有する。

• 生成 AI にざっくり作らせる
• 技術検証したい部分だけはしっかり作る
• 生成 AI が苦手なところとその対策

インタビューやフィードバックから動くものまでの距離が短ければ、学習も速く、深くなる。生成 AI を使うことで、人間はユーザーが触れるフロントエンドに注力しやすくなる。仮説検証サイクルがどう変わったかを実例ベースで紹介する。

教育向けプロダクトにおいて、教材を Markdown で構造化・管理している。その中で直面した課題は大きく次の 3 つだった。

1. 一般的な Markdown には存在しない構文の追加: ルビや画像サイズの指定など
2. Markdown 編集支援: textlint ルール作成
3. 効率的なレンダリング: SSR / CSR / Edge 使い分け

本トークでは、これらへの自分なりの解決を共有する。

Reactで宣言的に3Dシーンを構築し、React Hooksでインタラクションやアニメーションを制御する、具体的で「Reactらしい」実装方法をデモを交えてお届けしたいです。

Reactで開発していると、整ったUIだけでなく、ユーザーが思わず触ってしまうようなインタラクティブな表現を追求したくなります。しかし、そのためにWebGLを導入しようとすると、途端に「Reactらしくない」複雑な連携に悩まされる。私もそのギャップに苦しみました。
React Three Fiberは、そんな「Reactのままで、もっと面白いものを作りたい！」という純粋な思いを叶えてくれたツールです。このトークを通じて、WebGLが決して特別な技術ではなく、Reactスキルを拡張する楽しい武器になることを伝えたいです。複雑さから解放され、表現の喜びを皆さんと共有できれば最高です。