トーク

Turbo Frame / Turbo Stream にトランジションを簡単に追加できる npm ライブラリがあります。
とても便利ですが、Turbo Stream でアニメーションを付ける際に <turbo-transition> を毎回記述する必要があり、Railsらしい書き心地から少し離れていると感じていました。
RailsでTurbo Streamを利用する場合、turbo_stream.append のようなDSLが用意されており、このDSLを拡張して
turbo_stream.append "tasks", :fade
のように、より直感的にトランジションを指定できるgemを設計しました。

本セッションでは、デモと実装の解説を交えながら、

• フレームワークに手を入れるときの判断基準
• DSLを自作する際に考えるべき観点
  についてお話しします。

状態をなんとなくbooleanやnullableで表していませんか。そうすると「あり得ない組み合わせ」がコード上で許され、仕様追加のたびに分岐漏れが増えます。
そこで、取り得るケースを列挙して閉じ、変更時の漏れを型エラーとして表面化させる、代数的データ型の考え方を紹介します。

代数的データ型は「かつ（AND）」と「または（OR）」の組み合わせで状態を表現します。
UIの状態を列挙型や判別可能なユニオン型として定義することで、矛盾した状態を作りにくくできます。

本セッションでは、これを理論ではなくフロントエンド設計の実践として扱います。
TypeScriptの型検査を活かし、コンポーネントの状態管理や非同期処理の結果を「閉じた形」で表現する方法を整理します。
ケース追加時に直すべき場所が自然に浮かび上がる、変更に強い設計の基準を持ち帰ってもらいます。

現在 SvelteKit では Remote Functions という新機能を開発中です。
このトークでは なぜ Remote Functions が生まれて 何を 解決したいのかということを中心に話していきたいと思います。

本セッションでは主内容として、以下についてを解説していきます。

• なぜ Remote Functions が必要だったのか（背景）
• Remote Functions のコンセプトと設計
• 4 種類の Remote Functions
• バリデーションとセキュリティの考え方
• 実務でのパターン・アンチパターン

Svelteを聞いたことがある、興味がある、導入を考えている人を想定しています。

日付入力フォームはwebアプリケーションで最もありふれたフォームの一つでありながら、国際化の観点では非常に複雑なドメインです。

年月日の順序、月名の表記、カレンダーの開始曜日、グレゴリウス暦以外の暦など、ロケールごとに考慮すべき要素が多く存在します。一方で、サポートする入力パターンを増やすほどパース処理やUIは複雑化し、サービス側のロケールの扱いによっても品質は大きく変わります。

本セッションでは、実際のプロダクトでの国際化対応経験をもとに、ロケールの基本的な考え方、ロケールデータから見る日付表現の多様性、国際化における複雑さの要因を整理した上で、多くのロケールのサポートとフォームの複雑さのバランスをとるためのアプローチと妥協点を紹介します。

国際化を見据えた日付入力フォーム設計のポイントを共有し、webアプリケーションの国際化対応への理解を深めるきっかけを提供することを目指します。

このトークはDeno 初学者が深掘りした話です。

「npm installしたライブラリ、何をしているか把握していますか？」
Node.jsではライブラリに全権限が与えられますが、
Denoは「Permission（許可制）」で安全性を確保します。

このLTでは、NodeとDenoの違いを比較しながら、
Denoが守る4つのもの（ファイル、環境変数、ネット、実行権限）をコードレベルでの深堀りを行います。

みなさん、フロントエンドが「直すのが怖い状態」になっていませんか？

UIの表示、データ取得、状態管理、ビジネスロジックが同じ場所に集まり始めると、コンポーネントは巨大化します。
すると変更の影響範囲の特定が難しくなって開発速度が落ちます。テストも分離できず、表示の検証すら高コストになります。

本セッションでは、実務で行ったReactコンポーネントのリファクタリングを題材に、表示は表示に専念させ、データ取得やルーティングなどのロジックは外側に切り出した例を紹介します。
結果として、UIはPropsを差し替えるだけで検証できるようになり、ロジックも独立してテストできるようになりました。
加えて、外から来る値をどこで整えるか、どこまでを表示側の約束ごととして固定するか、といった判断の軸も合わせて整理します。

チームで責務分離をわいわい議論できるようになるきっかけを提供します！

Angularでは実験的機能として、Signalsベースで非同期データを扱うための resource() と、HttpClient を使ってHTTP取得を行う httpResource() が提供されています。
実務で中心的に採用するには慎重な判断が必要なものの、Signalsを導入し始めると、状態管理だけでなく、非同期データ取得もSignals中心の設計に揃えたくなるなります。
本セッションでは「今すぐ全面導入する」ことを目的とせず、「安全に試し、判断材料を蓄え、必要なタイミングで移行できる状態を作る」ための考え方と進め方を整理します。

本セッションで、resource() / httpResource() を「将来の選択肢」として安全に扱いながら、Serviceベースの既存アーキテクチャからSignalsへ移行するための、手順と判断基準を持ち帰れることを目指します。

AIエージェントによるWeb操作が当たり前になる中、私たちはいつまで「壊れやすいDOMスクレイピング」に頼るのでしょうか？Chromeチームが発表した新規格 WebMCPは、この状況を一変させます。
本セッションでは、Webサイトの機能を「AIが直接叩けるツール」として定義し、ブラウザを介して安全にエージェントへ提供する仕組みを、5分のLTに凝縮して解説します。

• 脱・人間シミュレーション: 画面解析を卒業し、構造化されたデータでAIと対話する。
• 2つのアプローチ: HTML属性で教える「宣言型」と、JSでロジックを繋ぐ「命令型」。
• フロントエンドの役割: 「見やすい画面」だけでなく「AIが使いやすい機能」を定義する新常識。
  早期プレビュー（EPP）の内容をベースに、Webサイトが「AIフレンドリー」なプラットフォームへと進化する未来の実装イメージを共有します。

デザインシステムというと、UIの共通化やルールの整備を思い浮かべる方が多いかもしれません。
でも実際には、それを「どう運用していくか」「どうやってチームに根づかせるか」のほうが、ずっと悩ましかったりします。

このトークでは、デザインシステムを導入・運用してきた中で見えてきた

• 再利用と柔軟さのバランスを取るコンポーネント設計の考え方
• 一貫性を保ちつつ変更に強くするための構造づくり
• チーム内の共通理解を育てるレビューやドキュメントの工夫
• 属人化しないための設計

など、エンジニア視点での実践と気づきを紹介します。
「とりあえず作って終わり」じゃなくて、「ちゃんと使い続けられるデザインシステム」を目指す。
そのために実践してることを紹介します！

SPAでの画面遷移トラッキングは、アナリティクスやエラー監視に不可欠ですが、
History APIでは popstate + onClick + router監視 といった
複合的な実装が必要で、遷移漏れも発生しやすい課題がありました

2026年1月、Navigation APIがFirefoxでも利用可能となり、
ついにBaseline機能に到達したことで、この課題に対してNavigation APIを使った実装を適用しやすくなりました

Navigation APIによって何が嬉しいのか？を実務で直面した課題ともにReactでの実装パターンをもとに紹介します

複数のサービスを運用する中で、コードの重複、責務の曖昧さ、変更時の影響範囲の広さに悩んでいませんか？
本セッションでは、4つのフロントエンドアプリケーションを1つのMonorepoに統合した事例をもとに、統合を起点に進めたリアーキテクトを紹介します。

パッケージの責務境界を見直し、共通コンポーネントと依存関係を整理することで、開発体験を改善しました。
Monorepoへの統合プロセスとツール選定から、責務分離を軸にしたアーキテクチャ再設計の手法まで、実践的なヒントをお届けします！

謎解きアドベンチャーゲーム「カミとミコ」はSPA構成のブラウザゲームです。サーバーサイド無しのフロントエンドのみで実装しています。
https://realdgame.jp/s/kamitomiko/

シナリオ・会話・キャラクター・謎の答え・進行フラグなどの情報をどのように管理してアドベンチャーゲームを開発したのか紹介します。
ゲーム開発に慣れていないメンバーも協力できるようCMSを導入して効率化し、Figma上でキャラクターの配置や移動ルートを視覚的に編集できる仕組みを作りました。

本セッションは、JavaScriptでゲームを作ってみたい人や、状態管理・データ設計に興味があるエンジニアに向けて、実装の工夫や苦労した点を紹介します。
・React/Viteで作るブラウザゲームの設計
・進行フラグや状態管理の設計
・CMSとFigmaによるコンテンツ編集
・開発中にデバッグしやすい工夫

今日、UIインタラクションは手続き的なJavaScriptのイベントハンドラによって実装されることが多く見受けられます。
一方で、Popover API や Invoker Commands API等の仕様の整備が進んだことで、モーダル表示やメニューの開閉といったUI操作をHTMLだけで表現できるようになりつつあります。また、htmxやHotwireに代表されるような、Webアプリケーションの状態更新を宣言的に記述するアプローチも近年注目されています。
本セッションではこれらのAPI群やアプローチを紹介しつつ、宣言的インタラクションという視点から、UI操作と状態更新をマークアップで表現する手段について検討し、JavaScriptを最小限に抑えたHTML中心のWeb UI設計について考察します。

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

useState、useEffect、Redux、Zustand、TanStack Query。Reactの状態管理は年々選択肢が増え、複雑さも増しています。でも立ち止まって考えてみてください。その状態、クライアントで持つ必要がありますか?Reactを選んだ時点でデータは一方向に流れ、状態管理の設計もReactの思想に委ねることになります。それは悪いことではない。ただ唯一の正解でもありません。サーバーからHTMLを返すアプローチでは、クライアントの状態管理がそもそも不要になるケースがあります。本セッションでは、Reactで状態管理が必要になる典型的なパターンを整理した上で、htmxやHotwireではそれをどう解決するかをコードで示します。Reactを否定するセッションではありません。「状態管理」という切り口から技術選定の視野を広げ、フロントエンドをもっと楽しくします。

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

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

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

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

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

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

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

昨今は猫も杓子も AI エージェントというご時世です。例えばチャットボットを開発する場合、ひと昔前は単純なテキスト応答が出来て、あとはせいぜい画像や PDF ファイルを扱えると言うだけで上等でした。しかしエージェント全盛のいまでは、ユーザからの依頼に対して実行計画を立て、必要に応じて外部データソースなどと連携し、自律的にタスクを遂行できる能力が求められます。

エージェントの振る舞いそのものは各種エージェントフレームワークや MCP などを活用することで比較的簡単に実現することが出来ます。しかしアプリケーション UI のことを考えると難易度が一段上がります。このセッションでは、エージェントの振る舞いと UI を連携させる際にどのような観点があるのかについて述べます。また、エージェントと UI を繋ぐプロトコルである AG-UI を紹介し、どのように実装することが出来るのかについて述べます。

ジェン文字(Genmoji)とは、iOSやmacOSに搭載されたApple Intelligenceの機能で、ユーザーがテキストを入力するだけでオリジナルの絵文字を生成できるものです。
標準のUnicode絵文字とは異なり、Genmojiの実体は画像データであり、iMessageやメールではインラインで自然に表示されますが、Webの世界に持ち込まれたときには独自の対応が必要になります。

本セッションでは、Genmojiの技術的な仕組みを解説した上で、Webフロントエンドで扱う際の課題と実装パターンをお話しします。
あなたのWebページでもAI生成カスタム絵文字を正しく・美しく扱い、ユーザーがさらなる表現力を発揮するためのTipsをお伝えします！

Chrome等のブラウザに標準搭載されるBuilt-in AI（Gemini Nano等）は、低コスト・低遅延・プライバシー保護を両立する新たな選択肢です。しかし、数GBのモデルDL待機や、サーバーサイドと比較して不安定な出力など、実プロダクトへの導入にはフロントエンド特有の「地雷」が多く存在します。

本セッションでは「記事要約」や「ページ内Q&A」の実装を通じ、現場で使える以下の5パターンを最小コードで詳解します。
① モデルDL進捗とユーザー体験を両立する非同期UI
② ストリーミング処理とキャンセル、リトライの鉄板実装
③ 長文分割・再帰的要約（Map-Reduce）のフロントエンド・パイプライン
④ 誤出力を許容する「編集導線」と、AIとの対話型UI設計
⑤ 未対応環境やリソース不足を検知する堅牢なフォールバック