プロポーザル

みなさんWeb IDLって知っていますか？

Web IDLは、WHATWG/W3Cの仕様書で定義されたWeb APIのインターフェースを定義するために使われている言語です。
TypeScriptのlib.dom.d.tsの生成時にもWeb IDLを情報源として使っています。

本LTでは、Web IDLがどんなものなのかWeb IDLを知っておくと何が嬉しいのかについてお話します。

本LTでは以下の内容についてお話しします。

• Web IDLとはなにか
• Web IDLの見方
• 「なぜこのAPIはWorkerで使えないのか」「なぜHTTPだとundefinedになるのか」「なぜこの文字列だけ文字化けするのか」などをWeb IDLの観点から説明予定

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

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

本セッションでは、

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

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

プロダクト開発の一歩目、あなたは何から始めますか？
「デザイン」を思考に組み込むのはどのタイミングでしょうか。
LovableやFigma Makeの登場で「それっぽいUI」が瞬時に生成できる今、私たちが向き合うべきはその裏側にある「ドメインの本質」と「UXの文脈」です。
AIは綺麗なUIを作りますが、「なぜその配置なのか」「そのビジネス課題を解決できるのか」という判断基準（Context）までは持ち合わせていません。

本セッションではLIXIL Intelligenceチームの泥臭い取り組みを通し、皆さんと共に「AIが進化し続ける世界で、人間だからこそできるプロダクト開発」の姿を模索していきます。

◼︎サブテーマ

1. プロダクトデザインを考える「一歩目」
2. AI×コンポーネント集：Figma MCP/Make等ツールを実務に繋げる方法、どう考える？
3. UXの空洞化：「文脈」と「意思決定の基準」をチームで共有するには
4. エンジニアとデザイナーの役割：意思決定に全振りすべき？それとも…

当日はチャットでリアルタイムに質問を拾いながら進行します。
プロダクトの明日について語り合いましょう！

工数見積りってのは一人でやったらだめなんだ！
マネージャーやリーダを含めて！チームでやるんだ！

一人でやったらだめな理由

• 数字が個人にのしかかってくるから追い詰められる
  • そもそもマネージャーは見積りの数字を納期にするな
• 見積もったヤツが病気になったらどうするんだ？引き継いだやつが工数の責任負わされるのか！？
• 数字よりも、どうしてその工数でできると思ったかが重要なんだ
  • 見積りは実質設計（なんなら開発まで）をやってるようなもんだから、思考プロセスの共有が最も重要なんだ
• そもそもシステムやドメインの境界線について一人で考えられないでしょ多分

みんなでやろう

• 対話を通して不確実性を洗い出そう
• 知識を共有しチーム内の知のバランスを整えよう
• 工数はチームみんなで責任を持とう。でも絶対じゃないってのも知ろう

見積りって行為はエイヤァじゃないってのを伝えたい
真剣に取り組むことでチームやプロダクトを牽引する強い力が働く行為ですよ

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

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

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

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

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

Dockerfileを書くのって難しいですよね。
理由は、単なるセットアップ用のシェルスクリプトと違い、「レイヤー」という概念を理解した上でのキャッシュ効率の最適化や、イメージサイズの削減が強く求められるからです。

特に、Kubernetesのようなオーケストレーションツール上での運用を想定した場合、コンテナはエフェメラルな存在となり、頻繁にビルドとデプロイが繰り返されます。
実運用レベルでは、単に動くだけでは不十分で、ビルドの高速化と軽量なイメージの作成が前提条件となります。

本セッションでは、私が実際にオンプレミスのPHPサーバー上で動作するアプリケーションをKubernetesへ移行した経験に基づき、
ここ数年のアップデートを取り入れた「2026年のDockerfileの書き方」について、PHPのイメージを用いて話します。

話すこと
・OverlayFSの仕組みとパフォーマンス影響
・キャッシュマウントとマルチステージビルド
・PHP拡張の依存管理
・CI/CD環境でのキャッシュ共有

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に「適したこと」「適していないこと」を共有します。

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

「会場のみなさんから，様々なネタを拾い集めて各地で実践して，最強の勉強会を作りたいんですよ～」
※ Bof : https://atmarkit.itmedia.co.jp/icd/root/24/2973424.html
　
北海道は広大な土地に技術系コミュニティが点在しており，非常に恵まれた地域です．
しかし，これらの勉強会には，人口密度最低の都道府県であることに起因する，ある課題があると感じています．
　
これらの勉強会は人数の少なさもあり，全員共通で深く潜っている技術が多くありません．
発表形式になるとノンジャンルで，比較的理解しやすいものを選ばれる方が多いように見受けられます．
　
せっかくの 2 カンファレンス合同開催の機会ですから，みなさんのお知恵を拝借したいです．
この地域の状況下で PHP やフロントエンドに親しんでもらい，コミュニティの裾野を広げるネタにどんなものが考えられるのか？
会場の全員で頭の体操をしませんか？
　
幅をひろげるネタ，深さを追求するネタ，とにかくネタを出していきます．
ここで思いついたネタを，みんながどこかの勉強会で実践すれば，最強の勉強会が生まれるはず――――――．

フロントエンドが実装されている現場でネイティブアプリの話を出たことある人いますよね？
そんなひとは、React Nativeを併用するプロジェクトで、APIクライアントをどこまで共通化すべきか悩むことでしょう。
ちなみに私は悩みました・・・。

本セッションでは、OpenAPIスキーマを起点としたコード生成ツール（orval、openapi-typescript、openapi-fetchなど）を活用し、Web/Native間でAPIクライアントを共通化する戦略を4段階のレベルで整理します。

Lv.1: 型定義のみ共通
Lv.2: + fetcher関数も共通
Lv.3: + エラーハンドリング共通
Lv.4: + hooksまで完全共通

• ネイティブアプリとフロントエンドのメンテは同一チームか別チームか
• SSRは必要か
• オフライン対応は必要か

などといったプロジェクト特性に応じた判断軸を示し、最適な共通化レベルを解説します。OpenAPIスキーマからフロントエンドで型安全なクライアントを自動生成する実践的なワークフローもご紹介します。

12月4日 (日本時間) に公開されたReact2Shell脆弱性。

React2ShellはReact Server Compoentの "Flight Protocol" において、
悪意のあるリクエストを送ることで任意のコードを実行できてしまう危険な脆弱性でした。
LayerXのバクラク事業部でも、複数のNext.jsプロダクトを運用しており、その対応が必要になりました。

このトークでは、Flight Protocolや脆弱性がどのように発現したかの解説を行うとともに、
わたしたちがどのようにmonorepo内の複数プロダクトに対する対応を初日に完了することができたのか、
その対応を紹介します。

12月4日 (日本時間) に公開されたReact2Shell脆弱性。

React2ShellはReact Server Compoentの "Flight Protocol" において、
悪意のあるリクエストを送ることで任意のコードを実行できてしまう危険な脆弱性でした。
LayerXのバクラク事業部でも、複数のNext.jsプロダクトを運用しており、その対応が必要になりました。

このトークでは、Flight Protocolや脆弱性がどのように発現したかの解説を行うとともに、
わたしたちがどのようにmonorepo内の複数プロダクトに対する対応を初日に完了することができたのか、
その対応を紹介します。

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

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

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

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

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

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

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

Composerの「ガラクタ」版を作りあげ、動くようになる様子を、ゼロからお見せします。
実装している様子を事前に録画しておいて共有する、ライブ(ではない)コーディングの発表です。
発表者は、動画を再生しながら「何をしているのか」の解説を行います。

私は普段Composerに大変お世話になっているので、皆さんもきっとそうだろうと思い、
「だったら内部で何をしているのか、どう動くのか知るのは楽しくない？」と考えて共有するものです。

つくるもの

composer require コマンドと同じように動くもの

• CLIツールとして動く
• 任意のpackageを指定できる
• Packagist からpackage情報を取得する
• GitHubからソースコードを取得・展開する
• packageとversionの解決を行う
• composer.json / composer.lock 相当のファイルの作成
• PSR-4オートローダーの作成

※ 時間の関係上、package間のversionの整合性の解決については「3分間クッキング」方式とし、あらかじめ発表の外で作っておいたものを利用します

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

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

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

読みやすいコード、分かりやすいコード、とっても良いですよね！
そのためには「しっかり読まなくても良い部分」が大事です

実際の所、プログラミングは「いかにして”端折るか”」の勝負でもあります
低レイヤーはよく枯れた実装に、頻出する処理はフレームワークやライブラリに任せる
そうした汎用的なサポートがあってこそ、「ビジネス固有の処理の実現への注力」が実現します

半世紀以上も前に提唱された「構造化プログラミング」がもたらすのは、正にそんな力です
「順接、分岐、反復の制御構造を用いる手法」と説明されても、今や当たり前すぎてよく分からないかも知れません
その反面、構造化こそが、「抽象概念と詳細な実装の分離」「段階的な詳細化」をもたらす武器となるのです

Agentic Codingの普及で「人間の役割」が変わりつつある今日、
いま一度「構造化プログラミングとは何だったのか」に立ち返って考えてみませんか？

このトークでは

• 構造化プログラミングと、それが無い世界
• 具体の方法論を超え、その背景にあった「良いプログラミング」への視点
• ”今風”な設計手法やアーキテクティングと「構造化」の関係

について展開します

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

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

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

静的解析は単なる「コードの粗探し」ではありません。

React Compiler はコードを静的に解析することで、 React が前提としているメンタルモデルを私たちに提示します。
また、プロジェクト固有のカスタムルールは、暗黙のコード規約を明文化し、人が書いても、 AI が生成しても同じ品質を担保するための基盤になります。

本セッションでは、静的解析が私たちに「どんな世界を見せてくれるのか」を掘り下げた上で、 ESLint・Biome・oxlint といった主要ツールの現在地を整理します。
その上で、プロジェクト規模やフェーズに応じた、静的解析との現実的な向き合い方を提案します。