トーク

本セッションでは、大規模ECの200ページ超ある管理画面で6年ぶりのデザイン刷新をするにあたり、全レイアウト、UIコンポーネント40種×3実装（React, Vue2, Vue3）を始めとした広範囲の書き換え実施するという課題に対する1年間の実践を、技術とプロジェクト運営に絞って共有します。

技術面では、レポジトリ統合による開発フロー簡素化、epicブランチへの日次自動マージによるコンフリクト早期検知、先行PJ向けの暫定コピペから後置換戦略などを、
運営面では、ミッションステートメントの共同作成、Notionへの意思決定ログ整備、開発フェーズに応じたチームの組み替え等を実施しました。

結果、約12万行の変更をロールバックなし、SNS炎上なし、退職・燃え尽きゼロでリリースしました。
長期間にわたるPJを成功に導くためにエンジニアの枠を超えて取り組んできたことをお伝えします。

Stencil.jsはWeb Componentsを生成するオープンソースのJavaScriptフレームワークで、ReactやVueなど特定のフレームワークに依存せず利用できます。

コンポーネント単位で独立性を保てるため、既存アプリ全体を作り替えずに、一部だけ新技術を導入も可能です。AIコーディングにも最小限のコンテキストで実装できるメリットがあったり、動的なプラグイン開発にも利用できます。

UIをコンポーネント化しておくことで、将来的なバージョン変更やリプレイス時の事業リスク低減にもつながるのでお勧めです。

tailwindcssとEveryLayoutはどちらも素晴らしいが、少し極端すぎる。その中間のようなものを目指したのがLism CSSです。
reset.cssからレイヤー定義、デザイントークンとユーティリティクラスの設計まで、サイト全体に関わるCSS設計になっています。

• ユーティリティファーストとレイアウトプリミティブの融合
• 余白とタイポグラフィの設計方法
• コンテンツレイアウト手法

などについてお話しできたらなと考えています。

また、専用のReact/Astroコンポーネントを開発してnpmで公開しているのでその苦労話など。

• Lism CSS: https://lism-css.com/
• リポジトリ: https://github.com/lism-css/lism-css

HTMLメールの実装をしたことはあるでしょうか？

HTMLメールには通常のHTMLとは異なる技術的制約があり、特殊な知識が必要だと感じる方も多いかもしれません。

その原因にはレンダリングの標準が存在しないという事情があります。送受信はRFCで標準化されていますが、HTMLの表示方法は各メーラーに委ねられています。独自のレンダリングを行っているメーラーもありますが、実はWebブラウザと同じレンダリングエンジンを採用しているメーラーも多くあります。
もちろん通常のWeb開発とは異なる部分も多くありますが、エンジン毎の特性≒ブラウザ毎の特性を理解すれば、普段のWeb開発の知識が活かせる場面もあります。

本トークではメーラーごとのレンダリング事情を整理し、Web開発の経験と結びつけながら、HTMLメール実装の実践的なポイントをお話しします。

主要なブラウザやプラットフォームでの対応が進み、Passkeyを採用するサービスも増えてきました。しかし、マルチテナントSaaSに導入しようとすると特有の検討事項が多くあります。
RP IDとドメインの関係はPasskeyが使える範囲を決定づけるため、サービスを提供するドメインの設計に注意が必要です。また、複数テナントを利用するユーザーの認証体験や、テナントごとに異なる認証要件への対応など、フロントエンドにも多くの課題が生まれます。
本セッションでは、Passkeyの基本的な知識をおさらいしつつ、これらの課題に対して私たちがどのような選択をしたのかをお伝えします。

プログラミングの初学者にとって、セキュリティは後回しになりがちなテーマです。
学んだとしてもスライドや記事を読むだけで、腹落ちさせるところまでもっていくことが難しかったりします。
現場においてセキュリティに関わる「失敗」は許されません。一方で、失敗から得られる学習効果は非常に大きい。このある種の矛盾をどう扱うか、教える側の立場では悩ましい課題でした。
本セッションでは、学習教材として脆弱なアプリケーションをあえて実装し、セキュリティを学ぶという、「失敗を設計する」ことで安全に学ぶアプローチを提案します。
XSSや認可の誤り、状態改ざんなどのセキュリティの問題がどのように起きるのかを可視化し、どう攻撃されるのか、そしてどう防御するのかを理解したうえで、フロントエンド開発で気をつけたいセキュリティポイントを整理します。失敗を経験値に変えるための学習設計を考えます。

Astroではドキュメントに「Astro is an all-in-one web framework」と記載があるようにAstro上でReact, Vue, Svelteなどの他のフレームワークを使うことができます。一方で、ReactはSPAの開発によく用いられ、一方でAstroはMPAの開発に用いられ、これらは非常に対照的です。
本セッションでは、これらの対照的なフレームワークが共存する際に、Astro上のReactはどこまでReactなのかに関して議論したいと思います。

現代のフロントエンドのテストはJestやVitestが主流ですが、それ以前に作られたMocha Chai Sinonを組み合わせたテストは今も多くの現場で動いています。
ライブラリのモダン化はしたいものの、全部を一から書き直したり、一度にすべてを置き換えたりすることが難しいというのが実情だと思います。

本トークでは、既存のテストコードを保ったまま、漸進的にVitestへ移行していった話をします。
BabelのRewire PluginやImmutable.jsなど、当時らしい技術選定と絡んでいた部分も含め、どこで詰まり、どのように進めていったかについて紹介します。

また、ライブラリの変遷を追いかけることで、フロントエンドのテスト戦略が時代とともにどう変わってきたかも振り返れるような内容にしたいと思います。

長年フロントエンド開発を支えてきたSass。
登場の背景には、当時のCSSが抱えていた書きづらさを何とかしたい、という強いニーズがありました。

それから時が経ち、CSSそのものも大きく進化しています。
Sassでおなじみの変数やネスト、条件分岐など、Sassが便利にしてきた領域に近い体験を、標準機能で得られる場面も増えてきました。

このトークでは、Sassで馴染み深い機能を題材にしながら、モダンCSSではどう書けるのかを比較して紹介します。
あわせて、CSSの変化を俯瞰的に眺めることで、今後のCSSの進化について考えてみます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

複数のサービスを運用する中で、コードの重複、責務の曖昧さ、変更時の影響範囲の広さに悩んでいませんか？
本セッションでは、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設計について考察します。

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

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

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