トーク

ジェン文字(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設計
⑤ 未対応環境やリソース不足を検知する堅牢なフォールバック

フロントエンドとサーバーサイドで言語が異なる環境において、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を使いこなすためのノウハウを紹介させていただきます。

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

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

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

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

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

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

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

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を効率よく作るための実装パターンを紹介します。

Reactを使いこなす鍵は、その「思想」の正しい理解にあります。
本セッションでは、Reactを単なるライブラリではなく一つの「思想体系」として捉え直し、全てのReact開発者が共通して持つべき基礎教養を提示します。

「f(state) = UI」という純粋関数性の重要性、状態をスナップショットとして扱うイミュータブルな設計、
そして副作用を「外部システムとの同期」として外部に逃がす設計など、React独自のメンタルモデルを深掘りします。
さらに、Fiberアーキテクチャや差分検知アルゴリズムといった内部実装のソースコード・データ構造にも踏み込み、
並行レンダリング等の最適化手法も踏まえつつ、その思想と実装の繋がりを紐解きます。

この一年、様々なところで「MCP」という単語を聞くようになりました。
なにやらAIチャットが外部と連携できるようになるようです。
ところでMCPサーバーとはどのような仕組みで動いているのでしょうか。

また、MCP Appsという仕様も2026年1月に安定化しました。
MCP Appsとは一体なんなのでしょうか。もしくは、どのように動いているのでしょうか。いわばサードパーティのアプリケーションをどのように隔離しているのでしょうか。

MCP Appsのためのフレームワークchapplinを開発している私が、MCPサーバーからMCP Appsまで技術的な面にスコープを当てて紹介します。

SignalsはTC39のStage1標準化プロポーザルとして進行中で、依存関係を追跡し必要な部分だけを効率的に更新する仕組みとして注目されています。

Signalsが提案するリアクティブモデルは、状態の変更を効率よく扱う設計アプローチとして現代のフロントエンド開発における重要な設計パターンのひとつです。

状態管理は避けて通れない課題ですが、Signalsを理解することで、不要な再描画を減らす設計やリアクティブシステムの振る舞いを構造的に捉える視点が得られます。

フレームワークに依存しない状態管理の共通原理を理解できる内容です。

本セッションでは、以下の視点でSignalsの仕組みを解説します。
・Signalsがどのように依存関係を追跡しているのか
・状態が変わったとき、必要な箇所だけ更新される仕組み
・signal-polyfillを用いた実装検証から得られた知見

ガワネイティブアプリとは、SwiftやKotlinで開発されたネイティブアプリの中でWebViewで機能を表現するアプリの形式です。
様々な都合で、ネイティブアプリ開発が行えない場合において、
Webフロントエンドエンジニアを中心に組成されたチームで、スマートフォンアプリを開発する際に選択される形式でもあります。

本セッションでは、ガワネイティブアプリにうっかり遭遇してしまったフロントエンドエンジニアの方に向け、WebViewの取り扱い方法や、注意点などをお話しします。
また、WebViewで作られた画面とネイティブコードの連携方法など高機能なアプリ開発のためのTipsもお伝えします。

トピック

• iOSで注意すべきCSS
• 検知できるイベント、できないイベント
• ページ遷移（画面遷移）の注意点

React Server Components（RSC）の登場によって、サーバーサイドでのデータ取得やレンダリングが可能になり、GraphQLが解決してきた課題の一部をRSCでもカバーできるようになりました。 一方で、ReactのRFCでは「Server ComponentsはGraphQLに取って代わるものではない」と明言されており、Meta社内ではRelayとRSCを併用する取り組みも進められています。

では実際のところ、GraphQLとRSCはどう使い分ければいいのか、あるいは併用するのがいいのでしょうか。

本セッションでは、まずGraphQLとRSCがそれぞれ何を解決する技術なのかを整理した上で、類似点と相違点を解説します。 そして、RFCや公式の発信情報も参照しつつ、併用で得られるメリットとそれに伴う複雑性のトレードオフについて、実務での経験も交えながら紹介します。

現在携わっているプロジェクトでは、 Next.js を利用しています。
プロジェクト開始当初、私は React / Next.js の開発経験がありませんでした。
そのため、ほぼ知識ゼロから実務を通してキャッチアップを進めてきました。

本トークでは、 Next.js 未経験者が 1年半の実務で得た経験を、以下のトピックを中心にお話します。

• 知識ゼロから実務利用するまでの習得プロセス
  • Next.js と React Hook Form, Zod などの周辺ライブラリの習得
• 利用経験のある Vue.js / Nuxt.js との対比
• 実務を進める上でつまづいた点
  • 多様な React Hooks の役割の理解と実用方法の習得
  • サーバーコンポーネントとクライアントコンポーネント

本セッションの内容が、未経験の技術で開発を進める方に少しでも参考になれば幸いです。

アプリケーションのフルリニューアルや大規模リファクタリングを経験したことはありますか？１ヶ月から長ければ６ヶ月近い時間をかけて、既存のアプリケーションを新しく作り直す。技術負債の解消や最新のデファクトスタンダードを採用でき、モダンなユーザー体験の提供なども期待できる大掛かりなプロジェクトになりがちな取り組みです。

しかし一度挑戦すると、道中さまざまな苦難に遭遇します。既存アプリへの機能追加への追従や不具合対応の反映、そしてそれに伴うコンフリクト解消作業。。そして膨れ上がった巨大なコードベースのテスト工数やデプロイ準備タスクに目を回す・・・

継続的デリバリーは、このような大きな開発とデプロイの苦痛を軽減するためにあります。古くから読まれている・実践されているソフトウェア開発手法から何を学べるのか。CI/CDのエキスパートとして、またPaaS企業でのフルリニューアル経験を元に、紹介します。

生成AIを利用したコーディング、AI駆動開発は2026年における不可避な流れです。しかしこれまでのチーム開発とは異なり、課題の解決から先送りしていた問題の顕在化まで、良い点も悪い点も全てが高速で開発チームに押し寄せることになります。

AI駆動開発において「何をAIに委ね、何を人間が決めるか」は、多くの開発者が直面する権限委譲の問題です。
本セッションでは、Vibe Coding（AIを完全に信頼）とSpec駆動開発（仕様で制約）
という両極端なアプローチを、ジョハリの窓を用いて整理します。

「わからないことについてどう向き合う、折り合いをつけるか」
「わかっていることを確実に遂行させるために何ができるか」

変化の激しい時代における「変わらないもの」と「不可避な変化」への向き合い方についてみんなで考えましょう。