プロポーザル

約10年間frontend開発をメインターゲットにしたVisualTestingツールreg-viz/reg-cliのメンテナンスを行っています。
reg-viz/reg-cliは画像を比較し差分をとることで予期しない変更を検出することを目的としたツールです。
やはり長い間メンテナンスすると様々な悩みが発生するものです。
それらの悩みを解消することを目指し、Rust/WebAssembyに書き換えを行うことを決断しました。
今回は、その意思決定を行った理由、書き換え戦略やアーキテクチャ、得られたもの、思ってたんと違ったもの、お話できればと考えています。

https://github.com/reg-viz/reg-cli

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

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

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

Web標準化団体であるW3Cが行っている国際的な標準化会議であるTPACが2025年11月に日本で行われたので参加してきました。
そこで、まだ新卒1年目だった私はWeb APIの標準化の議論を見て、「Webは自分達も作っていく側」なのだと意識が変わりました。

上記をきっかけに自分が出来ることはなんだろうと考えた結果、まずは知るところだと思い、MDNにあるWeb APIについて全部読んでみました。

皆さんはどのようなWeb APIがあるかご存知ですか？
例えば、DOMに挿入される際に不要な要素や属性などをフィルタリングする「HTML Sanitizer API」などがあります。

単純に面白いWeb APIや技術的にすごいけれど使われていないWeb APIがあることをそこで知ることが出来ました。
皆さんにTPACの現場の様子やWeb APIの面白さを可能な限り伝えたいと思います。

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

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

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

ある日、次のミッションが舞い込んできました。

「1,500ページ以上あるヘルプサイトのフロントエンド基盤をひとりで全部刷新できない？」

数年前なら「ひ、ひとりで？面白い冗談ですね、ははは...」となりますが、
結果としては、AIをフル活用することで数カ月の作業期間で全ページの刷新およびリリースが完了し、
Hugo をベースに書かれていたものが、Astro を中心としたモダンなフロントエンドスタックに置き換えられました。

コードの理解・別アーキテクチャへの書き換え・大量ファイルのマイグレーション・ナレッジ蓄積など、
「AIを使って結局何を達成したのか？」という具体的な事例をご紹介します。

加えて発展的な話題として、自分が所属するフロントエンドの横断的な支援チームでの活動も踏まえ、
刷新で得られた知見から、組織でのAI活用に向けた取り組み、今後の展望についてもご紹介します。

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への統合プロセスとツール選定から、責務分離を軸にしたアーキテクチャ再設計の手法まで、実践的なヒントをお届けします！

新卒入社して半年——フロントエンドの正社員エンジニアが、自分一人になりました。フロントエンドには課題が山積み。でも事業のための開発もあるし、自分にはまだ力が足りない。いつか経験豊富なエンジニアが来て、一緒に刷新を進めてくれるだろう——そう思っていました。
でも気がつけば、事業の開発で信頼を積み重ね、デザイナーと一緒にデザインシステムを育て、PdMやバックエンドと連携しながら小さな検証から新しいアーキテクチャを導入してきました。
自分には解決できないと思っていた課題を分解し、理想のシステムを描いて議論し、事業の開発プロジェクトにうまく重ねて提案する。周りを巻き込みながら一つずつ改善を積み上げてきた5年間の、泥臭い努力と試行錯誤から得た実践知を共有します。

どんな人向けか？

• システムの大規模改善したいけど、燻っている人
• 少人数のフロントエンドで、事業用の開発で精一杯何とか回している人