プロポーザル

謎解きアドベンチャーゲーム「カミとミコ」は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設計について考察します。

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

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

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

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

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

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

ライブラリを使わず <input type="file"> を用いて実装されたファイルアップロード機能を扱った際、 macOS から送信されたファイル名だけがサーバー側の検索と一致せず、データ取得に失敗する問題に遭遇しました。

見た目は同じ文字列でも、 OS や入力経路（フォルダ選択・テキスト入力）の違いによって内部表現（NFC / NFD）が異なる場合があります。今回の問題は、その差異がブラウザを経由してアプリケーション層まで持ち込まれていたことが原因でした。

本トークでは実際の再現手順を示しながら、この不整合がどのように発生するのかを整理します。その上で、ブラウザ標準APIでファイルアップロードを実装する際に、どの境界で正規化や比較責務を持つべきかという設計判断を取り上げます。

環境差異に依存しない、堅牢なアップロード実装のプラクティスを持ち帰っていただくことを目指します。

モバイルアプリユーザーの約25〜35%が、OS設定で文字サイズを標準以外に変更していると言われています。
この設定で文字サイズを変更している場合に、アプリ内のWebViewだけ文字サイズが変わらないことがあります。

実は、iOSならCSSの font: -apple-system-body;、Androidならネイティブ側の textZoom 設定を橋渡しすることで、Web側にもOSの文字サイズ設定を反映できます。

このとき重要なのが、文字サイズの変化を前提としたレイアウトです。 rem によるスケーリングはもちろん、文字量に応じて高さが伸びる設計や、要素が溢れた際の柔軟な折り返しなど、拡大を許容する実装が必要になります。 OSの設定をどう受け止め、UIを最適化するか。 境界を越えた実装Tipsを共有します。

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

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

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

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

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

ジェン文字(Genmoji)とは、iOSやmacOSに搭載されたApple Intelligenceの機能で、ユーザーがテキストを入力するだけでオリジナルの絵文字を生成できるものです。
標準のUnicode絵文字とは異なり、Genmojiの実体は画像データであり、iMessageやメールではインラインで自然に表示されますが、Webの世界に持ち込まれたときには独自の対応が必要になります。

本セッションでは、Genmojiの技術的な仕組みを解説した上で、Webフロントエンドで扱う際の課題と実装パターンをお話しします。
あなたのWebページでもAI生成カスタム絵文字を正しく・美しく扱い、ユーザーがさらなる表現力を発揮するためのTipsをお伝えします！

Chrome等のブラウザに標準搭載されるBuilt-in AI（Gemini Nano等）は、低コスト・低遅延・プライバシー保護を両立する新たな選択肢です。しかし、数GBのモデルDL待機や、サーバーサイドと比較して不安定な出力など、実プロダクトへの導入にはフロントエンド特有の「地雷」が多く存在します。

本セッションでは「記事要約」や「ページ内Q&A」の実装を通じ、現場で使える以下の5パターンを最小コードで詳解します。
① モデルDL進捗とユーザー体験を両立する非同期UI
② ストリーミング処理とキャンセル、リトライの鉄板実装
③ 長文分割・再帰的要約（Map-Reduce）のフロントエンド・パイプライン
④ 誤出力を許容する「編集導線」と、AIとの対話型UI設計
⑤ 未対応環境やリソース不足を検知する堅牢なフォールバック

2025年に報告されたCVE-2025-55182は、RSCのデコード処理の欠陥を突き、未認証でRCEを許すという、現代のフロントエンド開発における「安全神話」を揺るがす重大な事案でした。
本セッションでは、この脆弱性のメカニズムを深掘りします。。

1. 攻撃の再現と解析：信頼できないペイロードがどのようにデシリアライズされ、コード実行に至るのかを図解
2. 攻撃面の棚卸し：意図しない「サーバー関数実行境界」の露出を特定する手法
3. 多層防御の実装：実装レベルでの多層防御（バリデーション/到達制御）
4. 検知とインシデント対応：不審な挙動のログ検知
5. 継続的なセキュリティ運用：フロントエンドチーム主導で「緊急アップデート」を完遂するための、SLAとロールバック戦略

「便利さ」の裏に潜むリスクを正しく理解し、堅牢なフロントエンド基盤を構築するための知識を凝縮してお伝えします。

皆さんはVue.jsを作ったことがありますか？
もしかしたら無い人もいるかもしれませんね。

「いやどんな質問だよ！」 そんな突っ込みを横目に、この30分でVue 3のコアシステムをゼロから実装します。

• Proxyによる透過的な依存関係の追跡とReactivityの構築
• VNodeを介した宣言的UIの抽象化とDOMへのマウント
• 仮想DOMのオーバーヘッドを排する「Vapor Mode」という進化の必然性
  30分後、皆さんの手元には「小さいVue.js=chibivue」があるはずです。
  普段Vueを使わない人にこそ見てほしい、モダンフレームワークの裏側に流れる「思想」をライブコーディングで解剖します。

フロントエンドとサーバーサイドで言語が異なる環境において、APIスキーマの整合性をどう保つかに悩んでいる方は多いでしょう。
多くの現場でOpenAPIが採用されていますが、数千行に及ぶ openapi.yml を人間がメンテナンスし続けるのは、もはや限界ではないでしょうか。

本セッションでは、ReactとRubyのプロダクト開発で、Microsoftが開発する「TypeSpec」を2年間運用してきた知見を共有します。
TypeSpecはTypeScriptライクな構文を持つAPI定義専用の言語で、Orvalと組み合わせることで型安全なクライアント生成を強力に自動化できます。

単なる導入事例にとどまらず、運用で直面したトラブルや、AIとの相性の良さなど、
2年経った今だからこそ語れる導入後の現在地を紹介します。

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ライブラリの採用判断に役立つポイントを整理してお話しします！

新しいバージョンをデプロイした直後、ユーザーの画面が真っ白になる。
コンソールにはChunkLoadErrorの文字。フロントエンド開発をしていれば一度は遭遇する問題ではないでしょうか。
この問題の正体は「バージョンスキュー」です。 ブラウザに残った古いHTMLが参照するJSチャンクが、デプロイ後のサーバーには存在せず404になり、画面が壊れます。

本トークではまずチャンク分割とバージョンスキューの仕組みを図解し、なぜこの問題が構造的に避けられないのかを明らかにします。
その上で、Error Boundaryによるリカバリー、外部ストレージでの旧アセット保持、バージョンチェックによる事前検知など複数の対策を比較検討します。
最後に、Next.js＋コンテナデプロイの環境で実際に対策を導入した過程と得られた知見を共有します。

Next.js 16 から登場した Cache Components. かつては試験的な機能としてPartial Prerendering（PPR）という名前で提供されていました. ですが, Next.js Conf 2025では "Cache Components" という名前になりました. "Rendering"のも"Parital"でもない, けれどもPPRの後継機能.

"Cache" "Components"が意図するところからこの機能でNext.jsチームが達成したいこと, 私たち開発者が新機能に対してどう向き合うべきかを再確認します.

Webサービスのフロントエンドを開発していると、<link rel=”prefetch”>のような記述を見かけることがあります。
これはユーザーの動きや利用する際の環境を予測して、あらかじめWebページの読み込みやレンダリングなどを行い、パフォーマンスを向上させるための投機的読み込み向けの記述の1つです。

このセッションでは、link要素のrel属性で設定できる投機的読み込み機能を理解し、サービスの特性にあわせた使い分け方法をご紹介します。
また、ブラウザの実験的機能である投機ルールAPIで、従来の投機的読み込み機能のどういった課題を解決しようとしているのかについてもお話します。
対象者は、Webサービスのパフォーマンス改善に興味のある方を想定しています。

RSCの普及とともに、フロントエンドからバックエンドの処理を直接呼び出す手法が一般的になりました。
私はその中でもフレームワーク間の Server Functions のアプローチの違いが非常に面白いと感じています。

本セッションでは、Tanstack StartとRSCに焦点を当て、設計思想の違いや内部実装について包括的に説明します。
例えば、RSCは関数単位で実行ランタイムを指定できる設計になっており、ネットワーク越しの通信であっても単なる関数呼び出しとして記述します。一方Tanstackは、ミドルウェアやバリデーションなどAPIサーバーの概念が積極的に取り入れられているのが特徴で、両者はネットワークやAPIサーバの隠蔽度合いに差異があります。

これに加えて、業務でTanstack StartやNextを、個人でWakuを利用しているため、実際の開発体験の違いについても説明します。