プロポーザル

あなたはautofocusの正しい用法を知っていますか？
私はまず存在すら知りませんでした。
autofocusは、フォーカスを当てるべきことを示すHTML属性です。

ESLintのjsx-a11yルールをプロジェクトでリポジトリに導入したとき、no-autofocusルールに違反するエラーが発生しました。
そこで初めてautofocusという属性の存在を知り、プロダクトで使われていることに気づきました。
ESLintのエラーなので単純にautofocusを消すこともできましたが、知らなかった属性だったのでMDNやW3Cのドキュメントを読みました。
その結果、アクセシビリティに配慮したautofocusの正しい用法を理解できました。
本LTでは、実務での経験をもとに以下を紹介します。

• autofocusとは何か
• なぜLinterが警告するのか
• autofocusの正しい用法

聞き終わる頃には、みんなautofocusを自信を持って使えるようになるはずです。

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

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

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

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

「あとで読む」に保存した記事、本当に読んでいますか？

私は個人開発で記事キュレーションサービス「CuraQ」を開発し、3400人以上のユーザーに使っていただいています。
このサービスの根底にあるのは「知識は溜めるのではなく循環させるべき」という思想と、「AIは代行者ではなく触媒である」という設計哲学です。

本セッションでは、この思想がどのように技術選定とAI実装に反映されているかをお話しするとともに、「個人開発でもここまでできる」という実践例として、設計思想から具体的な実装まで一気通貫でお伝えします。

対象者

• AIを活用したプロダクトを作りたい方
• Next.js以外のフロントエンド技術（Hono）に興味がある方
• ベクトル検索・セマンティック検索の実装に興味がある方
• プロダクトの設計思想と技術選定の関係に興味がある方

PHPとフロントエンドと聞くと、個人的に思い浮かぶのが, Facebook社（現Meta社）でした.
なにしろFacebookやInstagramでPHPやJavaScriptがそれはもうふんだんに使われてるらしいですよね.
そこから生まれたHHVMやHack言語, ReactやFlow, 結果はどうあれそれらがもたらしてくれたもの.

PHPとフロントエンドとFacebookの話に想いを馳せる30分間ってどうでしょうかね.

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

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

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

皆さんはフロントエンドの監視を行えていますか？

サーバーやインフラの監視に比べ、フロントエンドのエラーは後回しにされがちで、そもそも監視していない、通知は鳴っているものの見られていない、行動につながらないといった状態に陥っているチームも多いのではないでしょうか。

私たちのプロダクトでも、エラーは収集していたものの、何を基準に対応すべきかが曖昧で、フロントエンド監視が形骸化していました。

本セッションでは、

• フロントエンドの監視とは何か、アラートは誰のためのものか
• AI を活用したアラート内容の要約、重要度判断、一次切り分けの仕組み
• チームで機能するフロントエンド監視体制を構築した実践例

これらを具体的な実例とともに紹介し、フロントエンドのアラート運用を形骸化させず、チームで継続的に実践していくための考え方と方法を共有します。

品質向上のためにE2Eテストを導入したものの、「実行時間が膨れ上がってきている」「たまに原因不明で落ちる」「メンテナンスが大変でもう動かしてない」という経験はありませんか？

E2Eテストはシステム全体を通した品質を担保できる一方、安定した運用が難しく形骸化しやすいという課題があります。

本セッションでは、私がPlaywrightを使ったE2Eテストを運用する中で、高速化・安定化させるために行った以下の取り組みを紹介します。

• テストアカウント分離によるテストの並列化
• project機能を使ったテスト分割
• テスト間のデータ受け渡しによる検証の安定化

発表では、申請・承認フローなどがあるBtoB向けのサンプルWebアプリケーションを用いて、実践的な形で改善していきます。
AIにより実装スピードが上がり続ける今だからこそ、高速で信頼性の高いE2Eテストを目指していきましょう！

「useEffectってなんかわからんけど使わない方がいいらしい」

ReactのuseEffectって便利ですよね。
ですが本来の用途とは異なる使い方をされることが多く、公式ドキュメントにも「そのエフェクトは不要かも」という項目が作られるほどです。
しかし非推奨ではなく本来使われるべき用途があります。
正しい使い方とは何か？AIにコードを書かせるとuseEffectを多用する部分も見られ、正しく使っているか見極める必要性が増してきました。

本セッションでは、useEffectの役割を使用例を交えながら説明します。
なぜ非推奨と言われるような風潮になっているのか、現代のライブラリ事情も合わせて解説します。
useEffectの使い方を見極められるようになれば幸いです。

※本セッションはフロントエンドカンファレンス関西2025の再演となります。
https://speakerdeck.com/maguroalternative/useeffecttutenandefei-tui-jiang-mitainakotoyan-wareteruno

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

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

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

得られる知見

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

以前、AIが計算ミスをする失敗談を話しました。
あれからAIは進化し、計算も完璧に。「ついに信頼できる相棒になった」と確信した矢先、
今度は「サボる」ことを覚えたようです。

Claude Codeに「なぜQueryBuilder（設計ルール）を守らず、生SQLを書いた？」と詰め寄ると、
「正直に言うと…手早い方法を優先しました」という衝撃の供述が！
これはバックエンドだけの話ではありません。
Reactならコンポーネント分割をサボったり、CSS設計を無視したり。
AIは「動作」は保証しても「保守性」は軽視する（局所最適化する）傾向があります。

本LTでは、賢くなったAIが新たに獲得した「手抜き癖」の実態と、
それを人間がどう見抜き、教育（レビュー）していくべきか。
PHP/フロントエンド共通の「AIとの付き合い方」をお話しします。

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

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

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

弊社ではエディター開発にTiptapというモジュールを利用しており、昨年のv3正式リリースでBreaking Changeが発生。
以前行ったbeta版から正式版へのアップデートの際には2ヶ月近くを要したため、昨年度は優先度を下げていましたが今年ついに本格対応を開始。
作業はAIアシスタントのClaudeに多くを任せることで、想定より大幅に工数を削減しつつ完了できました。

本セッションでは対応の手順を時系列で追い、
・Claudeに投げたプロンプト例
・Claudeだけでは解決できず手修正した箇所
・テストや検証で注意した点
・導入による効果
を共有し、皆さんの今後の開発に役立てていただくことを目的としています。

if 文を1つ足す、Props を1つ追加する……そんな「Easy」な修正の積み重ねが、コードを複雑に絡ませ、変更を困難にします。これはフロントエンドやバックエンドなど、特定の技術領域に限らない共通の課題です。

AIエージェントによるコードの自動生成が当たり前になった今、設計の価値は「書きやすさ」から「読みやすさ・説明しやすさ」へと完全にシフトしました。複雑に絡み合ったコードは、人間だけでなくAIの推論をも狂わることとなり、以前にも増して「Simple」であることの価値が高まっています。

本セッションでは設計、そしてコードを「Simple」に保つことの価値について改めて確認すると共に、フロントエンド・バックエンド双方にとって役立つ「Simple」な設計を実現するテクニックについて、開放閉鎖の原則（OCP：Open/Closed Principle）を軸に解説します。

概要

O(1), O(log N) といった記法を見かけたことがありますか？
これは計算量を示す記法となっておりパフォーマンスを考慮する際の重要な指標です。

Redisのコマンドリファレンスにはこの記法が記載されており各コマンドがどれくらいの計算量になるかを示してくれています。

これを教材に実際に計算量の増加を体感し、実務の設計時に計算量をどう考慮すればよいかを学びましょう。

ターゲット

• 計算量を意識したことがない方
• 計算量は知ってるけど実務でどう効くかを体感したい方
• パフォーマンスを意識した設計をしたい方

お話すること

• 計算量の基本（主に時間計算量と Big-O 表記）
• Redisのコマンドリファレンスを使った計算量の読み解き方
• データ量を変えたときに体感できる計算量の違い
• 計算量を踏まえた設計時の考え方

Webサイトの表示速度とユーザー体験を左右する重要な要素、それが「画像」です。
しかし、JPEG、PNG、GIF、そして次世代フォーマットのWebPといった多様な画像形式を、特徴や用途に合わせて使い分けできていますか？

本セッションでは、日常的に利用されるJPEG、PNG、GIF、SVG、ICOといった画像形式と、次世代フォーマットとして注目されるWebPについて、
各形式が採用する圧縮方式、画質、そして透過やアニメーションといった機能の違いを深く掘り下げ、
多様なユースケースにおいて、どの形式が最適解となるのかを明らかにします。

さらに、WebPを導入する際の互換性問題を解決する<picture>要素を用いたフォールバックの実装方法についても解説します。

このセッションを通じて、あしたから自信を持って画像形式の選択ができるように目指します。

「Webサイトが重い…」その原因、画像ファイルかもしれません。
次世代フォーマットとして注目されるWebPを使い、サイトパフォーマンスを改善する方法を解説します。

WebPはJPEGより3割程度軽量でありながら、見た目の品質はほぼ変わらない、そんなWebPの基本とメリットを分かりやすくお伝えします。
さらに、多くの開発者が懸念するブラウザの互換性問題についても、安全なフォールバック方法をコード例と共に紹介します。

このセッションを聞き終える頃には、WebP導入へのハードルは無くなっているはずです。

サービスの開発にTypeScriptを利用していると、クライアントとサーバーのモノレポで型を共有するパターンがあります。
同じ言語であればすんなり型を共有できますが、異なる言語の場合は少し工夫が必要です。

このトークでは、TypeScriptで書いた型をサーバーサイドのPHPで扱うために行った工夫を紹介します。
具体的には、以下の内容となっています。

・TypeScript Compiler APIでTypeScriptの型をASTに変換し、FormDataの型を抽出
・FormDataのASTをPHPで読み込める形式（JSON）に変換
・PHP-ParserでJSONをPHPDoc Typesに変換し、$_FILES から指定したキーで値を取得するメソッドにセット
・PHPStanで型チェックが可能に（存在しないキーを指定した場合型エラーに）
・FormData以外の応用例

対象者は、TypeScriptとPHPのいずれかに触れたことがあり、型やASTに関心のある方を想定しています。

Laravel上の巨大なjQueryレガシーコードに対し、顧客体験やURLを変更せず、安全かつ段階的にReactへ移行する具体的戦術を提案する。

移行の鍵は、新旧システムの「境界線」を明確にし、開発者が安心してコードを書ける「安全地帯」を作ることだ。技術的には以下の2点を組み合わせることで実現した。

Feature Flagによるバックエンド制御：
　リクエスト単位で「従来のjQuery Blade」と「React用Blade」を出し分ける。これにより未完成の機能を隠蔽し、本番環境でも安全に制御・リリースが可能になる。

戦略的な強制リロード：
　React Routerを導入しつつ、レガシー画面との境界ではあえて強制リロードを行う。SPA化に固執せず疎結合を保つことで、複雑さを排除し置換スピードを最大化する。

本手法の最大のメリットは、URL変更が不要なため顧客への通達コストがゼロである点だ。
「すべてを一度に救わない」「やらないことを決める」というマインドセットと共に、ビジネス価値を損なわず技術負債を返済する現実解を共有する。

2025年11月、私は株式会社kubellに転生（転職）しました。
待っていたのは、長年の運用に耐え抜いた独自の自社フレームワークと、複雑な契約ロジックという巨大ダンジョン。
しかし、適切な「AI活用」により、このキャッチアップ期間を劇的に短縮することに成功しました。

本セッションでは、PHP/フロントエンドを問わず、誰でも明日から実践できる「未知のコードとドメイン」の攻略術を共有します。

【攻略の書】
1.Claude Codeによる異世界翻訳：独自FWや難解なコードをAIに「自分の得意な設計パターン」へ翻訳させ、脳内モデルを爆速構築する技術。

2.NotebookLMによる聴く仕様書：仕様と経緯をPodcast化し、BGMとしてドメイン知識をインストールする術。

3.公認チートの流儀：会社公認のセキュリティ指針を味方につけ、迷いなくAIを使い倒すための環境作り。

JS/TSを長く触っていると、不便な点も「そういうもの」として、無意識に受け入れてしまいがちですよね。その一つが、TypeScriptにおける非同期処理のエラーハンドリングです。 async/await のおかげでコードは劇的に書きやすくなりましたが、便利になった一方で、try-catch のネストや型安全性の曖昧さといった、新しい悩みとも付き合うことになってしまいました。

本LTでは、この課題を解決するために、GoやRustのように「エラーを値（Value）として扱う」アプローチを紹介します。
具体的には、Discriminated Union（Result型）を用いて、コンパイルレベルでエラーハンドリングを強制する手法です。

また、単なる理論だけでなく、実際に自作ライブラリ try-ok を作成し、既存のプロダクトへ導入したことも共有します。 「なぜ標準提案のタプル形式ではなくオブジェクト形式を選んだのか？」という技術的判断や、導入後、狙った通り良い効果があったのかに対してもお話ししたいと思います。

https://github.com/Sangun-Kang/try-ok