プロポーザル

フロントエンドの負債解消に悩んでいる方は多いのではないでしょうか。
複雑なpropsリレー、依存関係が絡み合ったコンポーネント、EOLになったライブラリ。
コードを開いた瞬間に「どこから手を付ければいいのか分からない」と感じる状態は、決して珍しくありません。

私自身も昨年のはじめまでは、コードを一つずつ読み解き、脳の疲労やメンタルと向き合いながらリファクタリングを進めていました。
しかし、ClaudeCodeの登場をきっかけに、フロントエンドの負債に対する向き合い方が大きく変わりました。

本セッションでは、

• フロントエンドにおける「負債」とは何か
• AI の登場によって負債の見え方がどう変わったのか
• 実際の負債解消で、楽になった点・依然として難しい点

これらを実例を交えて共有し、AI時代におけるフロントエンドの負債との向き合い方を考えます。

工数見積りは実に難しい。というか精緻な見積りは不可能だ。そして、求めていない。

見積りに重要なのは対話だ。
対話を通して既知と未知をわける行為が本質だと考えている。

本セッションでは、私たちのチームが実践してきた見積り方法をベースに話をする。
見積もりを「精緻な数字の報告」ではなく、「プロジェクトの不確実性を制御するための共同作業」と捉え直すきっかけを与える。

以下のアウトラインでお届けする

• 正確な見積りはできないという前提から始める
  • マネージャーは当てずっぽうの数字を信頼してはいけない。また、チームは出した数字に怯えなくてよい
• 見積りはチームにとって情報共有と学習の場である
  • 知の偏りの検知と知識の共有の役割を果たす
  • 見積りにおける対話がチームとプロダクトを強化する
• 既知と未知に線を引く
  • 見積れない領域こそが重要である
  • 見積りを通して未知の領域を狭める
• 見積り結果が開発順位を左右する
  • 未知（不確実性）が高い箇所から手を入れる。初期にリスクを最小化する。安易に作りやすいものに飛び付いてはいけない

PHPは動的型付け言語の代表格ですが、長年の進化を経て、現在では大規模開発に耐えうる堅牢な型システムを手に入れました。
一方、TypeScriptは強力な型推論を武器にJavaScript開発の景色を塗り替え、今や不可欠な存在です。

本セッションでは、PHP 4.x および TypeScript 0.x の時代から両言語を使い続けてきた経験をベースに、2つの言語の型システムの歴史と特徴を比較。
さらに AI 時代に突入しアップデートされた「型との付き合い方」についてお話しします。

ユーザーのマウス操作、スクロール、入力値に合わせて、キャラクターが視線を動かしたり、ボタンが有機的に変形したりする体験を作りたくありませんか？
「Rive」というツールを使えば、インタラクションを作成でき、そのデータはそのままWebサイトへ組み込むことができます。
本セッションでは、Riveのエディタ画面を使ったライブデモを行い、アイコン一つからキャラクターまで、UIに「命」を吹き込むプロセスを共有します。

得られる知見

1. タイムライン再生型とインタラクティブ型の違い
2. Webへの組み込みとインタラクション設定
3. マイクロインタラクションの実例

PHPはリクエスト駆動・短命プロセスを前提とした言語であり、一般的にリアルタイム通信には向いていないと言われています。
しかし、やってみないと分からない。実験してみましょう！

本発表では、あえてPHPだけを使い、ブラウザからの動画をリアルタイムに配信する仕組みを UDP版 と WebSocket版 の2種類で実装し、挙動・遅延・壊れ方を比較します。その結果から、PHPの言語思想・言語設計がリアルタイム処理にどのような影響を与えるのかを整理し、PHPに「適したこと」「適していないこと」を共有します。

【対象】
リアルタイム通信や動画配信に興味がある方、フロントエンドが好きな方、言語思想・言語設計に関心のある方

みなさん、フロントエンドが「直すのが怖い状態」になっていませんか？

UIの表示、データ取得、状態管理、ビジネスロジックが同じ場所に集まり始めると、コンポーネントは巨大化します。
すると変更の影響範囲の特定が難しくなって開発速度が落ちます。テストも分離できず、表示の検証すら高コストになります。

本セッションでは、実務で行ったReactコンポーネントのリファクタリングを題材に、表示は表示に専念させ、データ取得やルーティングなどのロジックは外側に切り出した例を紹介します。
結果として、UIはPropsを差し替えるだけで検証できるようになり、ロジックも独立してテストできるようになりました。
加えて、外から来る値をどこで整えるか、どこまでを表示側の約束ごととして固定するか、といった判断の軸も合わせて整理します。

いきなり全面適用するのではなく、既存コードを壊さず段階的に分離するコツも紹介します。
チームで責務分離をわいわい議論できるようになるきっかけを提供します！

LLMで品質の高いコードが生成できるようになった今、コーディングよりもLLMへの指示出しに時間を使うようになりました。
しかし管理画面のようにデザイナーが関与していない領域ではUI定義が薄く、実装方針を事前に確認しづらいため、こまめな成果物確認が必要になります。
そこで、UI設計からLLMに任せつつ品質を担保する方法を考えました。

本トークでは、ASCIIワイヤーフレーム等の画面表現＋クリック要素/遷移を構造化し、スキーマ/整合性を機械検証した上で、別LLMに「最初の1クリック（First-click）」を選択式で回答させて定量評価する手法を紹介します。
選択肢匿名化・シナリオ駆動で「キーワード当て」など、意図しないヒント混入（コンテキストリーク）を防ぐ工夫についても解説します。

【時間配分】課題3分→構造化/検証4分→First-click6分→まとめ2分
【対象】LLM開発に興味があるフロントエンドエンジニア（初級〜中級）

ブラウザ上で Web サイトを構築・編集できるサービスに、Zustand と Zundo を使って Redo/Undo 機能を実装した際、最小構成で組んだだけでは、ユーザーの直感とずれる挙動が発生することが分かりました。
具体的には、次のような問題が発生しました。

• IME 入力中の中間状態が履歴に入ってしまう問題
• debounce の影響で直前の変更が戻らない問題

本セッションでは、これらの問題の原因を Zundo の履歴保存モデルや debounce を前提とした設計から整理し、実際にどう解決したのかをコード付きで解説します。
さらに、テキスト入力・セクション追加・ページ並べ替えといった複数の操作を扱うため、Undo 対象と対象外を分ける目的で Store を分離した設計についても紹介します。

デザインシステムというと、UIの共通化やルールの整備を思い浮かべる方が多いかもしれません。
でも実際には、それを「どう運用していくか」「どうやってチームに根づかせるか」のほうが、ずっと悩ましかったりします。

このトークでは、デザインシステムを導入・運用してきた中で見えてきた

• 再利用と柔軟さのバランスを取るコンポーネント設計の考え方
• 一貫性を保ちつつ変更に強くするための構造づくり
• チーム内の共通理解を育てるレビューやドキュメントの工夫
• 属人化しないための設計
  など、エンジニア視点での実践と気づきを紹介します。

「とりあえず作って終わり」じゃなくて、「ちゃんと使い続けられるデザインシステム」を目指す。
そのために実践してることを紹介します！

複数のサービスを運用する中で、コードの重複、責務の曖昧さ、変更時の影響範囲の広さに悩んでいませんか？
本セッションでは、4つのフロントエンドアプリケーションを1つのMonorepoに統合した事例をもとに、統合を起点に進めたリアーキテクトを紹介します。

パッケージの責務境界を見直し、共通コンポーネントと依存関係を整理することで、開発体験を改善しました。
Monorepoへの統合プロセスとツール選定から、責務分離を軸にしたアーキテクチャ再設計の手法まで、実践的なヒントをお届けします！

バックエンドアプリケーションをPHPで書いていると、ORMをもりもり使いますよね。
アプリケーションレイヤーとDBレイヤーで、持っている知識が微妙に異なる事がありませんか？
例えば「DB上で外部キーを利用していない場合」や、「より論理的なグルーピング」を考えた場合です。

そして、次の発想に至ります。
─ORMでの定義からER図を生成できたら、より本質的な形式知の共有の助けにならないか？

Data MapperベースのORMなら実現可能性が高いです。
Doctrine ORMを利用したPJに関わっている中で、
「PHPのクラス定義からER図を出力しちゃえ！」というツールを作りました。
汎用性が高く高機能なER図生成ツールであるtblsと、その「外部ドライバー」を自作した組み合わせです。

これは、「tblsは便利！自分の環境用のオレオレな使い方してもいいよね」を届けるトークです。
ポイントさえ踏まえれば、特定の言語やORMライブラリに閉ざさない話になると考えています。

トークの主なポイント

• tblsはそもそも何ができるか
• Doctrineだと何故できるのか
• 開発したツールの動作例

何かの問題を解決する時、
実装としては動くけど、方法が複雑すぎて、もっと良い解決方法があるのでは
と感じたことはありませんか？

僕は何度もあります。
そのたびに「ではこの実装は、美しいか？」と、
僕の中のフベルトさんが問いかけてきます。
（チ。 ―地球の運動について― 1巻 p39）

そんな時、仕様を深く読み解くことでシンプルな解決方法が見つかることがあります。

本トークでは、ある問題に直面した際に、
CSSのtransformの仕様を読み解く中で、
それが内部的に行列計算されていることを知り、
各記法がどのような計算をしているかを理解することで
複雑だった実装をシンプルにできた経緯を紹介します。

もしかすると最後には
ラファウよろしくこう叫ぶことになるかもしれません。

あんな複雑な実装を、仕様を読み解くだけで、こんなにシンプルにできてしまったら、
この実装を、美しいと、思ってしまうッ！！

デザインシステムの目的は、デザイナーと開発者の間に共通言語を作ることです。しかしFigmaのDev Modeが出力するコードと実際のコードベースが一致していなければ、開発者はデザインを見ながら自分で書き直すことになります。共通言語のはずが翻訳が必要な状態では、デザインシステムは本来の価値を発揮できません。

この課題を解決するのがFigma Code Connectです。FigmaコンポーネントとコードをPropsレベルで接続し、Dev Modeから直接使えるコードを出力可能にします。本セッションでは、自作UIコンポーネントライブラリとFigmaを1:1で対応させた実践をもとに、設計方針と実装手順を解説します。

さらにCode ConnectはFigma MCPと組み合わせることで、AIエージェントにもデザインシステムの文脈を共有できます。静的変換の確実性とAIの柔軟性を両立させるアプローチ、そしてCode Generation APIによるページ単位の出力まで、実践的な活用法をお伝えします。

ストリートビュー機能で有名なGoogleマップは、今の生活で必須のサービスになっています。
そんなストリートビュー付きのWebマップを自作できないかと思って、小さなフィールドを舞台に撮影から実装まで自力で行いました。
WebGLを使って360度パノラマを表示し、地図と連携させるまでの苦労話を共有します。

https://forestacdev.github.io/morivis/map?3d=0&b=0&c=136.920747_35.552897&cr=18.04_122.77&p=0&sv=1327&z=18.0

PHPのsocket機能を使うと手軽にネットワークプログラミングができます。
2025年11月にリリースされたPHP8.5からそれが強化され、TCP/IP以下の層も手軽に読み書きできるようになりました。

PHPのネットワークプログラミングでどこまでいけるか探るため、自宅で動いている無線LANルーターのようなものをPHPで実装してみました。
PHPでイーサネットフレームを処理し、パケットの転送、ARPによるアドレス解決などを実装、それをラズベリーパイという小型のPCに乗せて実際のIPルーターとして動作させることに成功しました。

IPルーターを作るにはどのような機能が必要か、それをPHPでどう処理するかという話をしつつ、
ネットワークプログラミングの楽しさ、実機で動いた時の感動が伝えられたらと思います。

「この記事、前に読んだはずなのに見つからない」——キーワード検索の限界を感じたことはありませんか？
私が個人開発している記事キュレーションサービス「CuraQ」では、Gemini APIとpgvectorを組み合わせたセマンティック検索を実装しています。

本セッションでは、以下の実装をコードレベルでお話しします：

• Gemini 2.0 Flashによる記事解析と「concepts」生成
• gemini-embedding-001によるベクトル埋め込み
• Supabase + pgvectorでのベクトル検索RPC実装
• キーワード検索とのハイブリッド戦略

• プロンプトインジェクション対策と安全性への配慮

  「個人開発でもここまでできる」という実践例として、すぐに使える知見をお持ち帰りいただけます。

対象者

• ベクトル検索・セマンティック検索を実装してみたい方
• Gemini APIをプロダクトに組み込みたい方
• Supabase + pgvector の実践例を知りたい方
• 個人開発でAI機能を実装したい方

サービス開発において、私たちはこれまで「これがベストだ」と仮説を立て、実装し、検証するサイクルを回してきました。
しかしWeb技術の発達と共にユーザーの属性や文脈は多様化しており、既存のUI/UX理論や全体最適（最大公約数）のアプローチだけでは個々のユーザーが真に求める体験に辿り着くことが難しくなっています。

理想は「個人最適化」ですが、すべてのユーザーに合わせてUIを個別実装・運用することはコストの観点から現実的ではありませんでした。
本セッションではGoogleが提唱する「A2UI」を軸に、コストの壁を突破するための以下2点をお話しします。

1. PMFへの到達を加速させる「仮説検証エンジン」としてのA2UI活用
2. 現実的なコストバランスで個人最適化UXを提供するアプローチ

AI Agentsの台頭は「正解の画面を作る」ことから「正解を見つける」ことへ、私たちの役割を変えようとしています。
固定されたUIから脱却し、ユーザーが真に欲していたルート、いわゆる「けもの道（Desire Path）」を探す旅に出掛けましょう。

約10年ぶりのメジャーバージョンアップとなるjQuery 4.0が2026年1月にリリースされ、2006年の発表から20年の節目を迎えました。モダンなフロントエンド開発が主流となった現在でも、実際の現場ではjQueryを使って長年運用されているWebサイトは数多く存在しています。

こうしたサイトでは、バージョンアップ時に「どこに影響が出るのか分からない」「非互換が怖くて手を出しにくい」と感じる保守担当者も少なくありません。本トークでは、jQueryをバージョンアップする前に試しておきたいツールとしてjQuery Migrateを取り上げます。

jQuery 4.0における変更点とjQuery Migrateの使い方を解説し、既存のjQueryサイトと現実的に向き合う際に役立つ情報を紹介します。

概要
PinterestのようなレイアウトをCSSだけで実装する日がついに来ます。CSS Grid Level 3で提案されている機能は、従来のGridの概念（行と列の厳密な整列）を打破し、柔軟な「レーン（Lanes）」配置を可能にします。

本セッションでは、Safari Technology Previewを用いて実際にライブコーディング/デモを行います。アイテムが吸着する様子や、レスポンシブ対応の容易さを体感してください。また、議論が続いていた「仕様策定の現在地」についても解説します。
またanime.jsやGSAPなどのアニメーションライブラリーを交えてのデモも用意する予定です。

注：本公演時にはすでに各ブラウザへの搭載が進んでいる可能性があります。

得られる知見

1. グリッドレーンレイアウトの具体的なCSS記述方法
2. Grid統合 vs 独立プロパティの経緯

プロダクトの成長に伴い、フロントエンドで採用しているスキーマライブラリを速度重視のmyzodから標準的なZodへ移行する必要に迫られました。しかし、メソッドチェーンを多用するコードベースにおいて、grep置換のような機械的アプローチは困難であり、かといってすべてを手作業で書き換えるのは非効率です。
そこで私たちは、移行スクリプトを実装しつつ、複雑なマイグレーションをLLMに委ねるハイブリッドなアプローチを採用しました。その結果、数日の稼働でライブラリリプレースを完遂できました。

本セッションでは、大規模なライブラリマイグレーションをなるべく機械的に終わらせるための実践的なプロセスとして、以下のトピックをお話します。
・型レベルでのメソッド利用状況調査
・Coding Agentによるテスト駆動なCodemod実装
・複雑なマイグレーションをLLMで実施するハイブリッドなアプローチ

TypeScriptユーザーはもちろん、大規模なライブラリマイグレーションや自動化に興味があるすべてのWebエンジニアに向けて、応用しやすい知見を共有します。