プロポーザル

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

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

昨今は猫も杓子も 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年経った今だからこそ語れる導入後の現在地を紹介します。

新しいバージョンをデプロイした直後、ユーザーの画面が真っ白になる。
コンソールには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チームが達成したいこと, 私たち開発者が新機能に対してどう向き合うべきかを再確認します.

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

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

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

AIとの開発を日常的に取り入れたことで、フロントエンドエンジニアとしての働き方が大きく変わりました。コードを自分で書く時間が減り、バックエンド領域にも自然と染み出せるようになり、CursorからClaude Codeへツールを移行する中で「開発する」という行為そのものの捉え方も変化しています。本セッションでは、AIエージェントを活用した開発を実践する中で起きた変化と、これからのフロントエンドエンジニアの可能性についてお話しします。

現在のフロントエンド開発では、さまざまなUIフレームワークを利用して宣言的でコンポーネント指向な開発スタイルを採用しています。

一方でUIフレームワークの普及とともにstorybookも利用者を増やしていきました。
これらのライブラリによりフロントエンド開発は更に効率的なものとなりましたが、ただ導入するだけではうまく使いこなしているとは言えません。

この発表ではstorybook導入するにあたって、私が行ったフロントエンド開発プロセス自体の見直しの内容をもとに「Containerから実装を始めないこと」や「外部接続を面倒くささで定義する方法」などstorybookを使いこなすためのノウハウを紹介させていただきます。

私たちフロントエンドエンジニアは日々ブラウザ上で動くアプリケーションやページを開発しています。
一方でみなさんはブラウザがどのように開発され、リリースが行われているかご存知でしょうか。

現代の主要なブラウザブラウザエンジンはすべてOSSとして開発されており、誰でもバグの修正や新機能の実装ができます。

このセッションでは、JavaScriptしか言語が書けなかった私がWeb標準とRustを学び、そしてFirefoxへのコントリビューションに挑戦した過程で得られた学びを共有しつつ、ブラウザの開発はどこか知らない場所の話ではなくフロントエンドエンジニアも参加できるということをお伝えしたいと思っています。

2026年1月、MCPの公式拡張としてMCP Appsがリリースされました。

AIがテキストだけでなくインタラクティブなUIコンポーネントを返せるようになり、AIチャット上でリッチな体験が実現します。

• AIが返したグラフやチャートを直接操作し指示を出す
• AIがカンバンUIを返し、その場でタスクを編集・登録する

これまでプラットフォーム固有でこうした仕組みの議論が進んでいましたが、MCP Apps で標準化され、複数のAIクライアントで動くようになりました。

フロントエンドエンジニアにとって、これは「AIの中にUIを設計する」という新たな領域の登場です。本セッションでは、

• MCP Appsの仕組みについて
• 人間が操作すべきUIとAIに委ねるUIの境界線
• 実装デモを交えたユースケース紹介

を通じ、AI時代のフロントエンド開発の変化の一つの可能性を考察します。

フロントエンドエンジニアがこれまで向き合ってきた相手は、人間でした。しかしAIの登場によって、この前提が変わりつつあります。

AIはWebの出力者になりました。ストリーミングで流れるチャットUIが注目を集め、インタラクティブなUIを返せるMCP Appsも登場しています。
同時にAIはWebの消費者にもなりました。AIが効率的に情報を取得できるよう、HTMLの代わりにマークダウンでコンテンツを配信する動きや、AIがWebアプリをツールとして利用するWebMCPの策定も進んでいます。さらにAIが生成したことを示すai-disclosure属性の提案・仕様の議論が進んでいます。

このようにWebフロントエンドは「AIとの接点」として日々進化しています。本セッションではこれらの変化を整理し、AI時代においてもWebが情報をやり取りする手段として重要な役割を果たしていることをお伝えします。

OG画像メーカーやSNSキャンペーン、プロフィールカード生成など、ブラウザ上で画像を生成する事例が急速に増えています。
近年はCoding Agentなどの登場により画像を生成する実装の敷居が下がりましたが、実際のプロダクトとして成立する品質に引き上げるためには、知識が必要だと考えています。　

本セッションでは、Canvas APIを使った画像生成の基礎から実践的な設計パターンまでを解説します。仕事で開発した大規模メディアで利用しているOG画像エディタや、SNSキャンペーン用に開発した画像エディタの事例を紹介しながら、クオリティを高めるためのテクニックや、ユーザーが迷わず利用できる設計について取り上げます。

Cloudflareはフロントエンドエンジニアにとって親しみのあるPaaS的なサービスを多数持っています。

例えば、安価にサーバーレスが配信できるCloudflare Workers、Dockerコンテナを安価に動かせるContainers、イベント駆動の非同期処理パイプラインを構築できるCloudflare Workflowsなどです。

これらのサービスはWorkersを中心に設計されており、運用時に知っておきたい落とし穴もあります。

本セッションでは、Cloudflareのサービス群を使うプラクティスを紹介します。具体的には以下を扱います。

1. 各種サービス（Workers / Containers / Workflowsなど）の基本紹介
2. 各種サービスの作成方法とwrangler configが与える影響
3. 本番運用を見据えたWorkersの運用プラクティス

Apple製品の紹介ページや映像作品のLPでは、React登場以前からjQuery/GSAP等で「スクロール演出・トランジション多めのCSSリッチなLP」（通称、クリエイティブ系）が作られてきました。その実態は熟練のマークアッパーがアニメーションの状態・タイミング・イベントを泥臭く調整する試行錯誤です。

実現したい要件をほとんどCoding Agentが実装してくれる2026年でも、複雑なアニメーション付きのマークアップをAIだけで仕上げることは困難を極めます。（要件を自然言語などで伝えることが困難なため）

本セッションでは、最近のフロントエンド環境に合わせて主要なアニメーションライブラリ（GSAP/Motion/Anime.jsなど）を比較、選定を行い
Coding Agentと一緒にクリエイティブ系LPを効率よく作るための実装パターンを紹介します。