プロポーザル

私が書いた import ... assert { type: "json" } のコードは、ある日書き換えを迫られました。

仕様策定を担うTC39でStage 3まで進んだImport Attributesのキーワードが、assertからwithに変更されたためです。
Stage 3は採用してもほぼ安全。その思い込みが崩れた瞬間でした。なぜこの変更は起きたのか。TC39ではどのような議論が行われているのか。実体験をもとに追いかけます。
このLTを通じて、普段は遠い存在に感じるTC39やECMAScriptの仕様策定プロセスに関心を持つきっかけになれば幸いです。

約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の面白さを可能な限り伝えたいと思います。

みなさん、フォームをどのように実装していますか？

たくさんの選択肢がある中で、
「Web標準なフォームならシンプルで軽量」
そう信じて Conform を選択しました。

しかし、1万 input を超える大規模フォームの要件の前で、その理想が崩れます。
本LTでは、大規模フォーム開発で直面した課題と、そこから学んだフォームの技術選定における判断軸についてお話しします。

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

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

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

https://daisyui.com/

daisyUI は tailwind CSS の plugin です。
CSS, tailwind 初心者の私からすると

「えっ CSS だけでそんなコンポーネント実装できるの !?」

という気づきがたくさんあるコンポーネントです。
daisyUI の巧みなコンポーネントの紹介と、その実装方法を追うにあたってたくさんの学びがあった体験を発表します。

もし今、あの案件を「もう一回やり直せる」としたら。
本セッションでは小規模フォーム案件に対しての失敗体験から、案件終了後に個人で実際に再度SpecDDで0から完成まで開発をやり直したプロセス・プラクティスを共有します。

SaaS開発において、ユーザーの一括登録や各種データの一括登録など種々のCSVを用いた一括登録の機能が作られることが多くあります。一方で、CSVからデータを読み込む際に、ファイルごとに読み込む項目が違えば、バリデーションの項目、エラー表示の内容も変わってきます。このようにCSVデータの読み取り処理は柔軟性を求めると共通化の利点が減り、厳格に作ると再利用性が欠けるというトレードオフが難しい側面があります。

本セッションでは、フロントエンドにおける、CSV一括登録のコンポーネント実装、データパース処理、バリデーション処理の共通化に関して取り組んだ一つの方法を紹介したいと思います。

ZodをフォームバリデーションやAPIレスポンスの検証に使っているチームは多いと思います。そんなZodですが、近年はバリデーション専門というより、データ変換ライブラリとしても進化してきました。私もパイプラインを書いたのをきっかけに、「バリデーションのついでにデータ整形もやってしまおう」という考えが加速しました。

しかし便利さに頼るうち、スキーマ定義のチェーンがビジネスロジック化したり、スキーマを読むだけでは処理の全容が追えないコードになってしまいました。チームから「処理の流れが追えない」「便利そうだけどよく分からん」と言われたこともありました。

本発表では、フロントエンドのスキーマ定義で便利だった実装と、苦しくなった実装を、実際の声と共に紹介します。スキーマに書くべきことと、普通の関数に切り出すべきことの判断基準を、自分なりの失敗から共有します。

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

「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

Googleが公開したA2UI（Agent to UI）は、AIエージェントが宣言的なJSON記述でリッチなUIを安全に生成するためのプロトコルです。本LTでは実際にA2UIを試した所感を共有します。
任意コード実行を伴うMCP Appsとの設計思想の違いを比較しながら、エージェント時代のUI開発の選択肢を考えます。

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

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

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

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

概要

フロントエンド開発において必須の存在であるフォーマッターですが、一体どのように我々のソースコードをフォーマットしているのでしょうか。
今回の発表では、Prettierを例にソースコードの解析、ルールの適用、出力などどのようなプロセスを経ているのかを図解しながら、5分で誰でも理解できる発表を目指します。

このテーマを選んだ理由

Prettierのドキュメントには「Prettierを導入する最大の理由は、スタイルに関する終わりのない議論を止めることである」という内容が書かれていますが、チーム開発において「Prettierを実行すればフォーマットされているから大丈夫」と考える状態になってはいけないはずです。内部動作をきちんと理解し、フォーマッターの選定や意図を持ったルール設定など、チーム開発の品質基盤を自分でコントロールできるエンジニアとして成長するための話を展開します。

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

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

HTMLメールには通常のHTMLとは異なる技術的制約があり、Webページと同じ感覚で実装するとつまづいてしまうことも多くあります。

HTMLメールの送受信についてはIETFが策定したRFCで標準化されていますが、受信したHTMLをどのように表示（レンダリング）するかについては統一された標準が存在しません。WebブラウザにはWHATWGやW3Cによる仕様があり、主要ブラウザ間で表示がほぼ統一されていますが、メーラーにはそのような共通仕様がなく、各メーラーが各自の方法でレンダリングを行っています。
そのため、あるメーラーでは正しく表示されるHTMLが別のメーラーではレイアウトが崩れるといった問題が日常的に発生します。

本トークでは、HTMLメールの実装時に気をつけることをかいつまんでご紹介できたらと思います。

OKLCHは一般的に「RGBより鮮やかな色が表現できる」と言われます。しかし、RGBより鮮やかとはどういう意味でしょうか。
私たちが見ている画面は、R・G・Bの3色の混合で構成されるはずです。OKLCHも最終的にはここに還元される以上、RGBでの指定との差分が出るということに疑問を感じ、調べたことがあります。
そこには、人間が知覚可能な色の空間に対しRGB（sRGB）はその一部しか表現できていないことなどが原因だと分かりました。
このセッションではRGBとOKLCHの座標の違いや、OKLCHが鮮やかである理由について5分で説明します。

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

セキュリティのためのCSP対応が必要になった際に、CSPは外部リソースの読み込みだけではなく、インラインスクリプト・インラインスタイルに対しても適用できることを知りました。
そもそもなぜインラインスクリプトを保護する必要があるのか、nonceを利用してホワイトリスト的にインラインスクリプトを保護する仕組みについて、簡単なデモを交えながら説明します。