トーク

HTMLにおける“品質”って何でしょうか？
私の所属する会社では、HTMLに対する品質基準が明文化されておらず、lintツール導入時にも「何をもって良いHTMLとするか」「良いHTMLを担保するためにどんなルールが必要なのか」が定まっていない、そもそもHTMLの仕様理解にばらつきがある、などの課題がありました。

本トークではHTMLの品質ってどうやって担保できるんだろう？から深堀りしてHTMLクライテリアを作成した話やクライテリアの結果を元に行った改善活動について紹介します。

話す予定の内容

• HTMLの品質について
• HTMLクライテリア策定のプロセス
• クライテリアの構成と内容
• クライテリアの結果を元に改善した活動

文字と同じく数千年の歴史を誇る「改行」。あまりに身近なものなので、文章を読む時はその存在を意識することすらありません。しかし、開発の場面で改行を扱うとなると、「改行コードが複数パターンある」「CSSに似たような改行系プロパティが色々ある」といったややこしい事実に直面するうえ、挙動が思いのほか複雑なので表示崩れをはじめ様々な観点で思わぬトラブルを招く厄介な側面があります。

本セッションでは、テキストデータ・HTML・CSSのそれぞれにおける改行周りの厄介ごとを文字入力の歴史やタイポグラフィの知識などと絡めて紹介。さらにテキストデータにおける改行の扱い方から改行を制御する多種多様なCSSプロパティの使い分けまで、実務に役立つ改行のアレコレを扱います。

たった20分で、「なんとなくの実装」から脱却し、改行と自信をもって向き合えること間違いなし！

バイオ×AI分野では、数百万〜1,000万件規模のデータをリアルタイムで可視化・分析するニーズが急速に高まっています。もともとAI解析ではバックエンドでの大規模データ処理が重視されていましたが、現在ではブラウザ上でのインタラクティブな可視化においても同等の処理性能が求められるようになっています。本セッションでは、WebGL2を活用し、Transform FeedbackやR32Fテクスチャ、Framebufferなどを組み合わせて、サーバーに依存せずにブラウザ内で完結するGPGPUベースの高速データ処理の仕組みを解説します。さらに、カテゴリ・数値フィルタの操作に対して即座にGPU演算が反映されるUIや、FPSやGPU時間などのパフォーマンス指標を可視化するインタラクティブなデモも併せて紹介します。

DuckDB Wasmの魅力の１つとして、フロントエンドの実装だけで地理空間情報を扱うことができるということがあります
実際、どのような構成となるのか、メリットやデメリットなど、サンプルのアプリケーションを通じてお伝えできればと思います

CSSは不完全な言語です。JavaScriptのようなプログラミング言語でもなく、デザインツールが完璧に再現することもできません。

宣言的で、コンテキストに依存し、あらゆるデバイスで予測不能に動作するCSSの言語特性は、「互換性に縛られた未知で無限の空間」である「Web」という媒体において、実は必然的かつ合理的な設計判断だったのではないでしょうか。

昨今のCSSWGでの仕様策定を俯瞰すると、Inheritance、Defaulting、Cascade、Specificity 等の根底の設計思想を尊重しつつ、より洗練された形で活用可能にする傾向が見受けられます。

本セッションでは、CSS がなぜこの設計思想を継承し、どのように発展させ、どのような変化がこれから予想されるかを、Cascade Layers・Scope・Container Queries などに焦点を当てつつ考察します。

スクリーンリーダーは視覚的なUIの見た目だけではなく、DOM構造や設定された文字を頼りに情報を伝えるため
divボタンにonClickだけ付けたパターンや、読み順がぐちゃぐちゃなレイアウト、モーダルのフォーカストラップ漏れなど
視覚的には問題ないのに“読み上げ体験”を壊してしまうことがあります。

本セッションでは、こういった問題を解決するためのHTMLマークアップを実際にスクリーンリーダーで検証した例を交えながら
見た目だけでは測れないUI崩壊に気づくポイントと、改善例をお話します。

名刺忘れた？名刺切れた？——あるあるですよね！
でももう大丈夫。そんなときは、スマホをサッと出して「これが私のWeb名刺です！」ってドヤ顔キメちゃいましょう！

今回のLTでは、できるだけ簡単に！でもちゃんとカッコよく！ をモットーに、リアルなWeb名刺をVanillaで爆速制作しちゃいます！
フレームワーク？ナニソレおいしいの？今回はVanillaのHTML・CSS・JavaScriptだけで作っちゃいます！

「Webは好きだけど、ちょっと作るのめんどくさそう…」という方も大丈夫！
超簡単に、自分だけのオレオレ名刺を爆誕させましょう！

フロントエンドの責務は広がり続けており、その中で「エラー」の扱いは重要な課題の一つです。Result型などエラーハンドリングは確立されつつありますが、そのエラーを「UIとしてどうユーザーに伝えるか」という観点での議論は、まだ十分とは言えません。

本LTでは、その問いへの一つの答えとして、アクセシビリティの観点から「良いエラーUI」を考察します。具体的なUIデザインを交えながら、エラーメッセージの文言、表示タイミング、位置など、すぐに実践できる設計のヒントを紹介します。

このLTは、エラー実装に「アクセシビリティ」という新たな評価軸をもたらします。また、実装都合ではない、サービスの品質を高めるためのUI設計に取り組むきっかけを提供します。

▼ 話すこと

• エラーUIの設計方針
• ヒントとなるWCAG達成基準の紹介

▼ 話さないこと

• ロジックや描画層でのハンドリング実装

　p5.jsは、Processing言語をベースにした、クリエイティブコーディングのためのJavaScriptライブラリです。簡単にグラフィックやアニメーションを生成し、Web上で動作するインタラクティブな作品を創出できます。Webエディタを利用すれば、環境構築なしに利用することができます。
　昨年のフロントエンドカンファレンス北海道2024でもp5.jsについてLTを行い、Webカメラやマイクを使ったデモやtoioとの連携などのデモをお見せしました。しかし、まだまだp5.jsの魅力を伝えきれていません。本LTでは、昨年紹介できなかったWeb Serial APIを用いた外部デバイス(M5Stack)との連携や、物理演算を手軽に扱えるゲームエンジンp5playを、デモを交えてご紹介します。LTを通じて、p5.jsの可能性をお伝えできればと思います。

「スピナーよりスケルトンスクリーンの方が早く感じる」という体験をしたことはありませんか？
物理的にはスピナーと同等の待機時間でも、ユーザーはスケルトンスクリーンを「より早い」と感じる傾向があります。
この現象は偶然ではなく、人間の認知特性に基づいた心理学的なメカニズムによるものです。
ただし、すべての状況でスケルトンスクリーンが最適というわけではありません。どんな場面で使うべきか、逆に避けるべきかの判断も必要になります。
本LTでは、スケルトンスクリーンが早く感じるメカニズムや、使用する際の留意点についてご紹介します。

Kent C. Dodds が提唱した Testing Trophy はWebフロントエンド開発にテストの重要性と、効果的なテスト戦略の基礎となる知見をもたらしました。 Testing Trophy がフロントエンドテストの常識として確立した結果、現代では新たな問題が顕在し始めています。それはテストの実行コストの肥大化やテストの壊れやすさなどの問題です。Testing Trophy ではこれらの問題に対する指針を与えてくれず、そのため現代においては Testing Trophy は叫ばないテストアーキテクチャとなってしまいました。そこで本セッションではGoogleが提唱した Test sizes の分類と関数・UI・E2Eの分類との2つの分類を導入することでテスト設計に対する新たな指針を与えます。より効率的で堅牢なテストについて考えるための叫ぶテストアーキテクチャの実現を目指します。

2025年現在、Viteはフロントエンド開発の至るところで見られるようになりました。
Next.jsを除く、ほとんどの主流なフロントエンドフレームワークで採用され、Webアプリだけではなく、ライブラリ開発やテストなどにも利用されています。

なぜ、これほどまでに普及したのでしょうか。
１つはスピードでしょう。ESModulesを基本とした設計により圧倒的な開発スピードをもたらします。
それだけではなく、もう１つはプラグイン開発のしやすさだと私は考えています。
Rollupをベースにしたプラグインインターフェースはプラグイン開発者の体験をワンランク上へと引き連れました。

本トークでは、簡単なプラグインの作成ハンズオンをしながら、プラグイン作成の容易さを確認し、Viteの内部的な動きをイメージできるようにします。

WebARとは、ブラウザ上で体験できるARコンテンツのことです。
ユーザーにとっては、アプリインストールなしでブラウザで体験できる利点があり、
フロントエンドエンジニアにとってはWeb制作と同じようにHTML / CSS / JavaScript（WebGL）で実装できる利点があります。

【話すこと】
フロントエンドカンファレンス北海道2025のために作成したWebARコンテンツを通して、以下をお話しします。
・そもそもARとは？
・WebARを支える技術
・WebARの始め方
・WebARの魅力

【トークへ込める想い】
私自身フロントエンドエンジニアとして働いてきて、通常のWeb制作から飛び出した新しいコンテンツを制作したいなと考えていました。
WebARはブラウザ空間で今までのスキルセットを活かしながら、新しい表現に挑戦できます。
そのワクワクを皆様と共有したいなと思ってます。

RSC (React Server Components) が登場してから数年、React本体と周辺フレームワーク（Next.jsなど）の境界はよく分からなくなってきました。

RSCはReact本体の機能のはずですが、フレームワークが無いと使えないし、なんだかNext.jsと密結合しているようにも見えます。

そこで、このトークでは、Reactや周辺フレームワークの実装を見ながら、両者の境界がどこにあるのか、そもそもはっきりした境界があるのか、ということを明らかにします。

"use client" は誰が実装してどういう仕組みで動いているのか？　 "use server"は？　といった疑問を解消しましょう。

「CSSって地味？古い技術？」そのイメージ、もう過去のものです！
実はCSSはここ数年で驚異的な進化を遂げ、かつてないほど便利で強力なツールになっています！
これまでJavaScriptやSassの助けが必要だった複雑なレスポンシブレイアウト、ユーザーの動きに合わせた動的なスタイル変化、そして目を引くリッチなアニメーションなど、多くのことがCSSだけで、直感的かつシンプルに実現できるようになりました。
本トークでは、そんなモダンCSSの持つ真の力を凝縮してお届けします。

JavaScriptの「Proxy」objectは非常に強力です。
objectに存在しないプロパティの値を取得したり、存在しないメソッドを呼び出したりなど、objectに対するあらゆる処理に介入し、通常のobjectでは不可能な柔軟な処理を実現できます。

本発表では、発表者が業務でiframeとmain window間のRPC機構を構築した経験をもとに、以下の内容について解説します。

• JavaScriptのProxyの基本
• Window間通信の基本
• 別Window上のメソッド呼び出しのProxyによる実装
  • Window間通信のProxyによるWrap方法
  • 別Window上のメソッドの型情報の利用
• Window間のRPC実装として有名なComlinkの実装の簡単な解説
• Window間通信以外の応用例

ネットサーフィンをしていると「アプリをインストール」というポップアップを誰しも１度は経験したことがあると思います。

ショートカットを作成するのと何が違うのか、何をインストールしているのか。
そんなポップアップの裏側である技術「Progressive Web Apps （PWA）」。
OSや端末を選ばないWebアプリの利点と、オフラインでも使用できるネイティブアプリの特性を融合したPWAはどのように生まれて、どのように実装されているのか。
なぜ、PWAはそこまで普及していないのか。
PWAはどこまでネイティブアプリに近づけているのか。

本トークでは、PWAに関するこれまでの歴史を振り返りつつ、PWAがどのような仕組みでブラウザや端末に実装されているのかを読み解きます。

PWAに夢を見た1人のWebエンジニアから見たPWAの世界を共有できればと思います。

「フロントエンドのセキュリティ」と聞くと、XSSやClickjackingを思い浮かべるかもしれません。

しかし本来はもっと色々なことを気にしてもよいはずです。
「他のタブで開かれたサイトが攻撃してこないだろうか」
「リンク先のサイトが牙を向いたら」

あるいはユーザーとして、こんな心配をしたことがあるかもしれません。
「変なサイトを開いてポップアップが止められなくなったら」
「端末が特定されて追跡されたら」

そして、ブラウザは実際にこれらの脅威に立ち向かってきました。

このセッションでは、ブラウザが「フロントエンド」領域で繰り広げるセキュリティの攻防を、UI SpoofingからXS-Leaks、Fingerprintingなどなど、原理や歴史とともに追いかけます。

ブラウザは何をどこまで守っているのでしょうか。
私たちは何をどこまで自力で守らなければならないのでしょうか。

Push APIを活用すれば、Webサイトからネイティブアプリのようにプッシュ通知を送ることができます。
しかし、実際にはFirebaseなどのSDKを使って導入することが多く、内部の仕組みを学ぶ機会は多くありません。

本セッションでは、W3CのPush API仕様を紐解きながら、外部サービスに頼らずにフロントエンド・バックエンドをフルスクラッチで実装します。
通知が届くまでに、フロントエンド、ブラウザ、バックエンドサーバーがそれぞれどのような役割を担い、どう連携して動作しているのかを解説します。

LLMが出てきて、Webページを見る代わりに、チャットで情報を得るようになりました。チャットってチャットUIですよね。だから「Webページ、ひいては多くのUIが必要なくなるんじゃないか？」なんてビビってました。でも、UIは必要なんですよ。やり方が変わるんだと思います。

Kent C Doddsさんの「The future of AI interaction: Beyond just text」が非常に面白いです。「MCPでテキストを送るけど、それじゃ味気ないよね。例えばストップウォッチやデータの可視化、インタラクティブなマルチモーダルのUI欲しくない？」ってね。

MCPだとHTMLやJSXを含む新しいコンテンツタイプも提案されているし、UIを送るAIエージェントのデモもあります。今回はそれらの最新動向を紹介しつつ、デモも作って、AI時代のUIについて考えてみたいと思います。