フロントエンド担当不在で引き継いだアプリは、同じ用途のUIコンポーネントがファイルごとに散在し、モバイル対応もアクセシビリティも手薄でした。改修したい部分は多いものの、かけられる工数は限られています。
そこでコンポーネントコレクションのshadcn-vueを採用。高品質なUIコンポーネントに既存デザインシステムをTailwindトークンで適用し、最小限のスタイル変更で置換。少ない工数でコンポーネント整理と改修を実現しました。本発表では、このshadcn-vueを用い「頑張らない」UI刷新を少ない工数で達成した背景、実践テクニック、導入後の変化を紹介します。

話すこと

・shadcn-vueを選んだ背景と他案との比較
・最小変更でデザインシステムへフィットさせる実践テク
・shadcn-vue導入後の変化

そのアプリ肥大化していませんか？バックエンドはマイクロサービスなどのライフサイクル改善手法が進んでいますが、フロントエンドはまだ…という企業が多いのではないでしょうか。フロントエンドを単機能アプリに分割、独立して開発・保守・破棄を繰り返す、現代のアプリニーズに合った「マイクロアプリアーキテクチャ」を提案します。
統合認証・認可技術の普及によるシーズ、VUCA時代のアプリ開発の難しさによるニーズ、双方から必要となってくるマイクロアプリ開発の考え方について発表します。

・「新しいESLintルールを導入したいけど、既存のコードで大量のエラーが出てしまう…諦めよう」
・「ESLintを導入したけど、既存のエラーが多すぎで心が折れそう…」

このような挫折を経験された方も多いのではないでしょうか？（私も経験者です）

このような状況で、ESLintのルールを新たに導入したいけど既存のコードが邪魔をしている、という悩みはよくあります。

このトークでは、ESLintの新機能であるbulk suppressionsを使って、既存のコードに対して段階的にルールを適用し、品質改善を進める方法を紹介します。

TypeScriptの型を使い倒す「type-challenges」は有名ですが、その裏にある Compiler API（TSC API）は、実はVSCodeやVolarでも密かに活用されています。
このLTでは、TSC APIの面白さとその学習を目的に作っている問題集「tsc-challenges」を紹介します。
ASTから一歩進んで「型の意味を読み取る」世界を、楽しく学びましょう。

皆さんは游ゴシックというフォントを知っていますか？

このフォントはかつてWebサービスのデフォルトフォントとして（消去法的に）それなりに有力な選択肢となっていました。
そして2025年夏現在、選ぶ理由は実質なくなりました。

本LTでは游ゴシックを見捨ててNoto Sans JPを選定するまでの経緯と、稼働中のクラウドサービスでのフォント切り替えで行った具体的かつ泥臭い知見をお話しします。

発表者はフォントにそんなに詳しくないので暖かな目でお楽しみください。

SSR（Server Side Rendering） と Server Components って何が違う？と…過去の私は思いました。
だってどっちも名前にサーバー入ってるしサーバーでなんかやるし（？）

ということで調べました。
SSR と Server Components はそもそも目的が違います。

SSR は HTML を事前に生成し、SEOや初期表示速度を改善します。
RSC は JavaScript のバンドルサイズを削減し、クライアント側のパフォーマンスを改善します。

それを踏まえ、本LTでは以下の疑問を解消していきます！

• それぞれの目的をどう達成しているのか
• 何ができて何ができないのか
• SSR と RSC を一緒に使ったらなぜいいのか

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を本格的に活用したい方にとって実践的なヒントとなる内容をお届けします。

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ライブラリへの対応

について話します。

歴史あるフロントエンドコード内部は型のない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 型自動生成ワークフロー

とあるプロジェクトにアサインされたときのこと。

巨大なAPIをフロントエンドで受け取り、フロントエンドでいい感じに描画するため、APIのデータを整形する様々な整形処理がされていました。
APIにはクエリパラメータもない。APIを改修するのは、諸般の事情で何故かできない...

同じような処理が様々なファイルに記述され、複雑に絡まったコードベースたち...　（これはメンテナンスができない！）
そんな複雑に絡み合った状況に、少しでも見通しを良くするためモデル層を設けて、データフローを一方通行にしてリファクタリングしました。
データフローを、一方通行にするために助けてくれたのが、Remedaのpipeというメソッドの力でした。

本セッションでは、Remedaのpipeを使ってリファクタリングを行った仮定を追いながらpipeの威力をご紹介します。

魔法のようなAIコードエディタ（Cursor、GitHub Copilot、Cline）は、一見すると謎めいたツールですが、その正体はElectronを基盤に、TypeScriptとReactを用いて構築されたWebフロントエンドです。

本セッションでは、AIコードエディタの内部動作を技術的に詳しく解説します。ユーザーが入力したプロンプトがどのようにLLMのAPIに送信されるのか、その際に必要な文脈や情報がどのように収集されるのか、レスポンスをどのように解析してUIに反映するのかを順序立てて説明します。

また、LLMからのツールコール（edit_file）を解析し、具体的なコード差分をVS Code APIを介してどのようにファイルへ反映するかについても触れます。実際のソースコードや具体的な動作フローの図解を交えて、「魔法」の中身を分解・理解できるようになることを目指します。