プロポーザル

以前からのトレンドとしてフロントエンド開発で使われるツールがRustで実装されています。Rust は一般的に高速で安全とされており、Rustで実装できるのであればなるべくRustを採用したいと思うのかもしれません。ただわざわざ別の言語を持ち出すと、その橋渡しが課題になると予想されます。現在はnapi-rs というツールの存在によってシームレスな橋渡しが実現されています。そのため我々もnapi-rsという魔法を使えば、Rustを使ってフロントエンドツーリングを実装することができ、Rustの恩恵を受けられます。ところでこのnapi-rsは何をしているのでしょうか。これは主に多様なOSで動作するバイナリを生成し、Node.jsから呼び出し可能な形のグルーを生成し、エディタ支援を受けられるような型定義を出力します。そしてこれはRustのマクロとして提供され開発者に使いやすい形のインターフェースです。napiの実装はさまざまな分野の総合格闘技技になっているとおもい、これを解き明かすことは知的好奇心がくすぐられる楽しいトピックだと思います。そこでこのトークではnapiの最小構成を再実装しながら、楽しいお勉強をします。

ユーザとの接点という意味でのフロントエンドは Web ブラウザで動作するアプリケーションに限りません。 モバイルアプリはもちろん TUI や CLI, ... "フロントエンド" は様々なかたちをとります。

Web フロントエンドを持つプロダクトを開発する人間が、それ以外に開発するフロントエンドとしてメールや Slack app などを取り上げます。 これらは専用のライブラリを使いそのドキュメントをなぞるように作られがちでしょう。 しかし、ある程度の複雑さや物量を超えてくると途端に苦しくなってきます。

本発表では、この複雑さの低減に Web フロントエンドの設計・実装の考え方が有効であるということを紹介します。

• Web フロントエンドのように宣言的に実装し、
• Web フロントエンドのようにデータの依存関係を宣言・分離し、
• Web フロントエンドのようにテスト・プレビュー可能していく

• ……

  「Web フロントエンド」での考え方を抽象的に捉え「フロントエンド」に展開していくことで、他のフロントエンドでも開発体験を向上させる例をお見せできればと思います。

なんとなくパフォーマンスが出るからという理由でQwikを使っていましたが、 内部構造を調べていくうちに「ハイドレーションなしでなぜアプリがインタラクティブになのか」が腑に落ち、Qwikの設計思想に感動しました。
本トークでは、Qwikのパフォーマンスを支える内部構造に焦点を当て、DevToolsやソースコードを使って実際の動きを追いながら解説します。
QRL (Qwik URL) の仕組みからQwikloader、qwik/jsonまで、段階的にDeep Diveしていきます。
また、現在ベータ段階にあるQwik 2.0で何が変わるのかにも簡単に触れます。

このトークを聞くことで、 Qwikが「なぜ速いのか」を内部構造レベルで説明できるようになることを目指します。

■ 対象者

• Qwikに興味はある方
• Qwikを使い始めたが、内部の仕組みはまだよく分かっていない方
• フレームワークの内部実装やアーキテクチャに興味がある方

私たちが普段何気なく使っている絵文字（Emoji）は決して天から降ってきたものではありません。新しいEmojiは、世界中の老若男女から寄せられる数々の提案の中でUnicodeに採択されたものが毎年追加されています。実は誰もが応募資格を持っていて、この文章をお読みのあなたにも新しいEmojiのアイデアを試すチャンスがあるのです。
Unicodeが新しいEmojiの提案を募集するのは例年4〜7月で、フロントエンド・PHPカンファレンス北海道の開催日はまさに募集期間の真っ只中です。

そんな背景を踏まえ、この発表では、Unicodeが新たなEmojiを決める過程と私たちが新しいEmojiのアイデアを提案する方法を実例を交えて分かりやすく紹介するとともに、ここ数年に新たに追加されたEmojiの傾向を踏まえながら「勝てそうな」Emojiのアイデアを考察します。あらゆる情報を駆使して私が考えた今年最強のEmojiも披露します。

この発表を聞いたあなた！すぐにUnicodeのページを開いて今まで温めてきたEmojiのアイデアを応募様式にガツンとぶつけてやりましょう！！

Laravelでは、Inertia.jsがスターターキットの一つとして提供され、PHPエンジニアにとってもReactが身近な存在になってきました。
一方で、モバイルアプリ開発となるとWebとは前提が違うという理由から、距離を感じている人も多いのではないでしょうか。

私自身、Inertia.jsを使った開発を通してReactに触れてきました。そして現在は、React Nativeによるモバイルアプリ開発を主に担当しています。
モバイル開発に取り組む中で、ReduxやAsyncStorageを前提とした状態管理など、Webとは異なる考え方に向き合う必要はありましたが、Inertia.jsで身につけたReactの感覚が活きる場面も多くありました。

本セッションでは、Laravelエンジニアの視点から、Webとモバイルで前提がどう違い、それをどう捉え直してきたのかを辿ります。
また、Inertia.jsを通して得た知識や感覚が、React Nativeの開発にどうつながっていったのかを、具体例とともにお話しします。

ウェブフロントエンド開発者にとって、パフォーマンス計測といえばChrome DevToolsです。確かにChrome DevToolsは素晴らしいツールで、アプリケーションのトレースが手に取るようにわかります。しかし、よくよく見るとサーバー側で何が行われているかは待機時間としてしか表示されず、送ったリクエストがどのように処理されているかはわかりません。
本セッションではOpenTelemetryというOSSプロジェクトを紹介します。OpenTelemetryによってウェブアプリケーションのリクエストの様子がサーバーサイドまで透過的に確認できる様子をデモで示し、ちょっと試してみるためのステップを1つずつ紹介していきます。このセッションによって、手作業によるテストから、負荷テストでの利用、本番環境での障害対応など、フロントエンドのさまざまな場面でOpenTelemetryを活用できることが実感できることでしょう。

1,000社以上にわたり利用されてきた、多様な従業員が利用する360度評価サービスを題材に「評価」という重要な情報を扱うサービスを、誰もが支障なく利用できる状態を目指し、既存サービスのアクセシビリティ改善をどのように進めてきたか具体的な実装事例とともに紹介します。

画面数が多く仕様も固まった既存サービスでは、すべてを一度に対応することは現実的ではありません。そのため、「情報を正しく理解できなければサービスとして成立しないコア機能」を基準に、対応範囲の優先順位を定義しました。

コア機能の中でも、目が見えることを前提としたUIや操作を洗い出し、aria-labelを用いたスクリーンリーダー対応、ホバー依存の操作をtabフォーカスで操作対応、aria-liveを用いた視覚依存の通知表現の改善など、優先度に沿って段階的に実装しました。既存の仕様を壊さず進めるための判断基準や、aria設計・フォーカス制御・通知の扱いで意識したポイントについても解説します。

既存サービスに対してアクセシビリティ対応にハードルを感じているエンジニアが、「何から手を付け、どの順で進めればよいのか」の判断軸を持ち帰れる内容です！

当時はまだベータ版だった Tanstack Start を管理画面のフレームワークとして採用し、1年近く運用しています。
フレームワークは様々な機能を提供してくれる一方で、コードベース全体がフレームワークにロックインされてしまう懸念も存在します。特に、挑戦的な新しいフレームワークを選定をする場合には、いざというときの捨てやすさ/乗り換えやすさも考慮する必要があります。
かといって、重厚な腐敗防止層を設けるとプロダクト規模に見合わない複雑な設計になりがちです。

このセッションでは、「どこまでフレームワークに依存し、どこから依存しないのか」というフレームワークとの距離感について私の考えを説明します。
また、tanstack/react-start の実際のコード例に触れながら、実装や設計面において気をつけたこと、うまく行ったことなどにも触れる予定です。

フレームワークとの付き合い方の話をメインとしつつ、@tanstack/react-startのフレームワーク自体について興味のある方にも楽しんでもらえるようにする予定です。

業務システムでよく求められるPDF帳票。しかし「金額が空欄になっていた」「長い文字列ではみ出してレイアウトが崩れていた」といった事故を経験したことはないでしょうか。 PDFはバイナリ出力ゆえに出力結果の差分が取りにくく、動的データとテンプレートの組み合わせは事故の温床になりがちです。本セッションでは、開発時と実行時の両面からPDF出力の品質を守る次のようなアプローチを紹介します。

・TypeScriptとZodによるスキーマ定義で、入力データの不整合を開発時に防ぐ仕組み
・Reactコンポーネントベースでの作成やテキスト抽出によるスナップショット、VRTをPDF出力で実現する仕組み
・文字数超過や改行によるレイアウト崩れを検知する仕組み

TypeScriptやフロントエンドのエコシステムをPDF生成に活用し、「動けばOK」から一歩進んだPDF出力を解説します。

去年、フロントエンドカンファレンス北海道2025で「AI時代のUIはどこへ行く？」というトークをしました。
https://speakerdeck.com/yusukebe/aishi-dai-nouihadokohexing-ku

AI時代によくある「チャット」だけじゃなくて「UI」も欲しいよねという命題のもといくつかの試みを紹介しました。最後に紹介した「MCP-UI」はMCPの上でUIインタラクションを実現するスペックとSDKでした。それが先日1月26日。MCP-UIがベースとなり「MCP Apps」が標準化されました。これに準拠していればClaudeやChatGPTでUIが動きます。そこで今回はMCP Appsを実装面から解説し、デモを紹介します。さらに当初の「AI時代のUIはどこへ行く？」という命題に立ち返り、MCP Appsが「本当に標準」になるのか？実装的にイケてるか？文化的に受け入られるか？という2つの側面を考えていきたいと思います。

2025年12月にReact2Shellという脆弱性が発見されました。
これはReact.jsの脆弱性で"安全でないデシリアライゼーション"により任意コードが実行されるというものでした。

"安全でないデシリアライゼーション"は我々PHP界でもphpMyAdminやJoomla!, Drupalなど多くのOSSで脆弱性の原因になってきました。

本トークではデシリアライゼーションとは何か、そして"安全でないデシリアライゼーション"とは何か、どうしてそれが脆弱性につながるのかを解説します。

デシリアライゼーションは強力なプログラミングテクニックです。本トークを聞いた方が安心してデシリアライゼーションを使ったコードを書けるようになることを願っています。

LaravelとInertia.jsを使ったフルスタック開発では、バックエンドからReact/Vueのコンポーネントへ渡すPropsやリクエストボディの型情報をTypeScriptで手動で定義する必要がありました。
これにより、バックエンドとフロントエンドで型定義の不整合が起きやすかったり、データ構造の変更時に複数箇所の修正が必要などの課題がありました。
Laravel Wayfinder は、Laravelのコントローラーやモデル、フォームリクエストなどのPHPコードから自動的にTypeScript型定義を生成するパッケージです。バックエンドを変更すると自動的にフロントエンドの型情報も変更されるので、開発体験が大幅に向上します。

話すこと

• Inertia.js概要
• Laravel Wayfinderの導入方法と基本的な使い方
• Inertia.jsのPropsとフォームデータの型自動生成
• 実際のコード例とライブデモ

TanStack Start は、Router・Loader・Action を中心に据えた、型安全なフルスタック React フレームワークです。
一方で自由度が高く、個人・少人数開発では設計判断に迷いやすい側面もあります。

本セッションでは、Next.js と迷った経験を起点に、なぜ TanStack Start を選び、どのように Routes / Loader / Action を分けて考えると迷いにくくなったのかを、実体験をもとに解説します。
最初に TanStack Start の基本構造を簡単に紹介した上で、「画面を成立させるために読む処理」と「ユーザー操作で状態を変える処理」をどう切り分けるか、判断基準や失敗例、割り切り方を共有します。
API解説ではなく設計判断の背景に焦点を当て、個人開発で破綻しにくい構成を考えるヒントを持ち帰ってもらうことを目指します。

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

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

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

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

「会場のみなさんから，様々なネタを拾い集めて各地で実践して，最強の勉強会を作りたいんですよ～」
※ 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内の複数プロダクトに対する対応を初日に完了することができたのか、
その対応を紹介します。

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開発に興味があるフロントエンドエンジニア（初級〜中級）