プロポーザル

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

個人開発でWebアプリを量産したいけれど、ホスティング費用はできるだけ抑えたい。そんな悩みを抱える開発者の方に向けて、2026年時点での実用的なホスティング戦略を紹介します。
NextJSユーザー向けに、Vercelの代替選択肢としてCloudflare Workersを使ったホスティング方法を解説します。無料枠で何個までアプリをホストできるのか、具体的なデプロイ手順とともに実例を交えてお伝えします。
また、主要なホスティングサービス以外の選択肢として以下の方法も紹介します。
・NextJSに対応した低価格VPSの活用法
・バニラPHPアプリを共有サーバーで運用する方法
・ローカルサーバーとCloudFlare Tunnelを組み合わせた自宅ホスティング
各サービスの料金比較と実際の運用コストを明示しながら、皆さんの開発スタイルに合った最適なホスティング戦略を見つける手助けをします。

現在のフロントエンド開発では、さまざまな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時代のフロントエンド開発の変化の一つの可能性を考察します。

リファクタリングによるデグレーションは、機能は正しく動いているのに体験が劣化するという、テストでは捕捉しにくい領域で起こります。
ユーザーからの問い合わせが届く前に検知したい。しかし、すべての指標を監視するのは現実的ではありません。
本LTでは、「ユーザーの体験に悪影響を与えるか？」を基準に監視対象を絞り込む設計指針と、その基準をもとに筆者が実際にどのように指標を選定し運用したのかを紹介します。
特定の技術スタックに依存しない設計思想の話なので、どなたにも持ち帰れる内容です。リファクタリングに限らず、日々の開発で「何を監視すべきか」を判断するためのヒントになればと思います。

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

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

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

追加開発のたびにアプリケーションの仕様を設計書に書き写し、その設計書を見ながら実装する。
この往復作業は工数がかかるわりに付加価値が低く、設計と実装の乖離も生みやすい構造的な課題となっているのではないでしょうか。

本トークでは、SPA の画面から単一の HTML ファイルを自動生成し、「実画面そのものを設計の正」とする開発フローを紹介します。
生成された HTML モックは AI エージェントが直接読み書きできるため、画面の現状把握や改修案の作成に活かせます。
モックは開発サイクルごとに再生成するだけなので、従来の設計書のようなメンテナンスは不要です。
さらに Figma への取り込みも可能なため、デザイナーとの協働にも活用できます。

設計と実装をつなぐ作業に使っている時間を UX 設計やコンポーネント設計に回せるようにしたい、そんなきっかけになるフローをご紹介します！

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
• 検知できるイベント、できないイベント
• ページ遷移（画面遷移）の注意点

差分の大きいPRを複数の小さなPRに分けることでレビュワーの負担を抑えることができます。
でも、チケットを細かく分割するのって正直めんどくさくないですか？
そんなあなたに！！！
エンジニア歴半年の学生でもできた、AIとタスク管理ツールを活用して"ちょっと楽に"チケット分割するためのヒントを、数千ファイルの変更を伴うチケットに立ち向かった経験をもとに紹介します！

React19.2で新しいHooksであるuseEffectEventが追加されました。
これにより古い状態を参照し続ける「stale closure問題」にメスが入り、イベントハンドラの貼り直しなど余分な処理をEffectとして実行する必要がなくなりました。
一方、どのようにして最新の状態を取得しているのかご存知でしょうか？
なぜ、依存配列に含めていないはずの最新の状態を持ってくることができるのでしょうか？

本セッションではReactのソースコードを紐解き、useEffectEventが内部でどのように「関数の同一性」と「最新状態の維持」を両立しているのかを解説します。

こちらの延長線の話となります。
https://zenn.dev/maguro_alterna/articles/17a0938c5b02a3

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 の役割の理解と実用方法の習得
  • サーバーコンポーネントとクライアントコンポーネント

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

「重い計算処理の速度もメモリ効率もWasmが良い」という直感から、zip圧縮モジュールをWasm（Rust）で自作をしました。しかし、実際に使ってみると、既存のJSライブラリ（JSZip）のほうが使い勝手が良いという結論に達しました。
なぜJSライブラリのほうが良かったのか？というところをWasmの制限を絡めて紹介をします。
最後に、それでも私がWasmを使いたい理由についても語ります。