トーク

https://daisyui.com/

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

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

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

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

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

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

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

概要

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

このテーマを選んだ理由

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

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分で説明します。

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

JSXは、UIとロジックを自然に結びつけられるという優れた開発者体験で、Reactの普及に大きく貢献しました。
その影響はJavaScript以外にも広がっており、Rubyでも「JSXのコンセプトを取り入れた書き方」に挑戦する動きがあります。

このトークでは、Ruby on Railsのフロントエンドに、JSXのコンセプトを適用したRuxというライブラリを紹介します。
これまでのRailsフロントエンドについて軽く触れつつ、Ruxの可能性と課題についてお話します。

Railsユーザーに限らず、JSXに馴染みがある方にも別の角度から楽しめる内容にする予定です。

皆さんはロケールごとに日時をフォーマットする際に、どのようなことを考慮していますか？

もちろんIntl.DateTimeFormatだけで済むのが理想ですが、実際にはIntlで対応できる範囲以上の細かい制御を求められることも多いと思います。

では、フォーマットパターン文字列（yyyy/MM/ddのようなもの）で指定できれば問題ないのでしょうか？残念ながらフォーマットパターン文字列自体の扱いや各パターンに対応するデータがライブラリによって異なるため、この方法も万能ではありません。

このLTでは、「日時のフォーマット」という一見簡単そうに見える機能の背景にある仕様と複雑さについて解説します。現状日時のフォーマットに完全な正解はないと考えていますが、今後国際化を考えたフォーマット機能を実装する際に考慮すべきポイントと陥りがちな落とし穴を可能な限り網羅することを目指します。

カラム定義、行アクション、一括操作、フィルター。データテーブルに必要な機能を「利用者側から自由に差し替えられる」コンポーネントはどう設計すればいいのか。
@wordpress/dataviews、MUI の Data Gridなど、拡張性の高い OSS のデータテーブルを読み解くと、設計指針が見えてきます。何をPropsで受け取り、どこを拡張ポイントにするか。見た目はコンポーネントが担保しつつ、中身は利用者に委ねる構造をどう作るか。
OSSから学んだ設計指針と、それを実際のプロダクト開発に落とし込んだ実践例をあわせて共有します。

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を自作する際に考えるべき観点
  についてお話しします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Reactのkey、警告が出るから付けてるだけになっていませんか?
「なぜ必要なのか」を考えると、Reactの内部動作が見えてきます。

• Reactは何を基準にUIを更新しているのか
• keyはその中でどんな役割を担っているのか

このセッションでは、keyを入り口に、仮想DOMとReconciliationの仕組みを整理します。
実装を深掘りするのではなく、「だからkeyが必要なんだ」と腹落ちできることを目指します！

Panda CSSは、Chakra UIチームが開発したゼロランタイムで型安全なCSS-in-JSライブラリです。
私は新製品プロジェクトでPanda CSSを採用し、約2年にわたり実務で運用してきました。

本セッションでは、

• PandaCSSの概要と注目度
• ゼロランタイムのCSSライブラリを選ぶ理由
• 型安全が開発体験に与える具体的な影響
• Emotionやstyled-componentsとの思想・運用の違い
• 実際の開発現場で見えてきた強みと弱み
  などを具体例とともに共有し、CSSライブラリの採用判断に役立つポイントを整理してお話しします！