2 年前の 1 月，PHP Conference Hokkaido 2024 で冬の上川南部を巡る雪原開発旅行を提案しました．
フロントエンド・PHPカンファレンス北海道2026 では春の上川中部・南部，空知中部・北部を巡る草原開発旅行を提案します．
雪解けの大地を見下ろしながら着陸する，就航率99%を誇る旭川空港を起点に，実りある2泊3日の旅程をお楽しみいただけます．

旭川市，東川町，美瑛町，上富良野町，富良野市，芦別市，赤平市，滝川市，深川市を巡ります．
この旅では，芽吹きの大地があなたの開発環境です．咲き誇る花々，見渡す限りの空と心が通じたとき，かつてない躍動感に包まれるでしょう．

広い大地を巡ると体力が持たないのでは？
ご安心ください．旅程には源泉かけ流しの天然温泉も組み込まれています．
源泉かけ流しの天然温泉の力を借りることで，より精緻で俊敏な開発が実現可能です．

天井のある退屈な AI との対話を抜け出して，上川空知の春を満喫し，人間の底力で世界を変えるべきです．
北海道≒札幌——誤った認識は今すぐ捨てましょう．179の市町村があなたを待っているのですから．
（実践したものを LT します）

概要

LLMを活用したアプリが増加する中、AIが生成したコードを安全かつ迅速に実行する環境の重要性が高まっています。本セッションでは、TSネイティブなフレームワーク「Mastra」とセキュアな分離環境「Vercel Sandbox」を組み合わせ、ユーザーの入力からミニゲームを生成・実行する手法を解説しまし

材料

1. Mastra：型安全で旨みの強いベース
2. KAPLAY：爆速ゲーム開発用メイン食材
3. Vercel Sandbox：高火力な隔離環境
4. LLM：香り高いスパイス

作り方

1. ベース準備：MastraのAgentにコンテキストを馴染ませる
2. 隠し味：Sandbox操作用ToolをMastraに混ぜ込む
3. 仕込み：Workflowで生成からデプロイまでを準備
4. 安全な火入れ：Sandbox内で隔離実行し、味を整える
5. 盛り付け：完成URLをユーザーに提供し、その場で実食

ポイント

• 素材の簡単さ： 複雑なエージェントもTSだけで完結する手軽なレシピ
• 衛生管理： 隔離環境でAI生成コードを安全に実行

概要

LLMを活用したアプリが増加する中、AIが生成したコードを安全かつ迅速に実行する環境の重要性が高まっています。本セッションでは、TSネイティブなフレームワーク「Mastra」とセキュアな分離環境「Vercel Sandbox」を組み合わせ、ユーザーの入力からミニゲームを生成・実行する手法を解説しまし

材料

1. Mastra：型安全で旨みの強いベース
2. KAPLAY：爆速ゲーム開発用メイン食材
3. Vercel Sandbox：高火力な隔離環境
4. LLM：香り高いスパイス

作り方

1. ベース準備：MastraのAgentにコンテキストを馴染ませる
2. 隠し味：Sandbox操作用ToolをMastraに混ぜ込む
3. 仕込み：Workflowで生成からデプロイまでを準備
4. 安全な火入れ：Sandbox内で隔離実行し、味を整える
5. 盛り付け：完成URLをユーザーに提供し、その場で実食

ポイント

• 素材の簡単さ： 複雑なエージェントもTSだけで完結する手軽なレシピ
• 衛生管理： 隔離環境でAI生成コードを安全に実行

普段Jest/Vitestでテストを書いているフロントエンドエンジニアが、PHPUnitを触ったとき、クラスベースの構文やアサーションの書き方などで不慣さや冗長さを感じることがあります。言語によるテストの書き方の違いは、生成AIによりコードを読む機会が増えた昨今において、認知負荷としてボディーブローのように効いてくるはずです。

Pestは、RSpecやJestからインスピレーションをうけている、PHPUnitをラップした軽量なテストフレームワークです。
describe/it/expectといったJest/Vitest風の構文で書け、PHPUnitの資産もそのまま活かせるのが特徴となっています。

本セッションでは、Jest/Vitestユーザーの視点から、Pestの書き味の良さ、それによって得られるメリットを紹介します。

話すこと：

• Pestの特徴と採用メリット
• Vitest/Pest/PHPUnitで同じテストを比較
• PHPUnitとの共存について

話さないこと:

• PHPUnitやPest以外のテストツールについて
• フロントエンドのテスト技法について

Smarty などのテンプレートエンジンで構築された既存ページに React を導入したい場面、ありますよね？

中には「ページまるごとリプレイス」ではなく「ページの中で部分的に React 導入」を選ぶべき場面も多いはずです。

この LT では、Astro で知られる "Islands Architecture" の概念を、
フレームワークに頼らず既存のシステム上で再現・実践するためのアプローチを 5 分間に濃縮します。

概念自体は React の大前提とも言えるユースケースであり、一見シンプルに見えます。
理論上は、script タグで React をロードして、createElement することもできます。

しかし、JSX はほしいですし、TypeScript 対応や npm ライブラリの利用にはビルドが必要となり、
アーキテクチャやデプロイフローが一気に複雑化してしまいます。

このような悩みに対して、理想論ではない「現実的で実践的な付き合い方」をお話します。

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

私はこれまで、大規模かつレガシーなMPAサイトの保守・運用に携わっていました。現場では「SPAいいな」と憧れつつも、大掛かりなリプレイスは現実的ではなく、モダンな画面遷移の提案を諦めていました。本セッションで紹介する「View Transition API」は、そんなかつての私と同じような制約下にあるエンジニアへの一つの回答となる標準技術です。

この技術の最大の特徴は、既存のHTML構造を維持したままCSS数行から導入でき、未対応ブラウザでもサイトが壊れない「プログレッシブ・エンハンスメント」の考え方にあります。リスクを最小限に抑え、ブラウザの標準機能だけで心地よい体験を後付けできるため、実務において非常に現実的な選択肢となります。

本セッションでは5分という限られた時間の中で、MPAでの実装方法や擬似要素による仕組みの要点を絞って解説し、実際の挙動をデモで素早く提示します。大規模サイトの保守に携わる方はもちろん、クライアントへ低コストかつ効果的な提案をしたいエンジニアやディレクターの方に向け、フレームワークに頼らず「もっと良い体験」を今すぐ届けるためのエッセンスを凝縮してお伝えします。

私はこれまで、大規模かつレガシーなMPAサイトの保守・運用に携わっていました。現場では「SPAいいな」と憧れつつも、大掛かりなリプレイスは現実的ではなく、モダンな画面遷移の提案を諦めていました。本セッションで紹介する「View Transition API」は、そんなかつての私と同じような制約下にあるエンジニアへの一つの回答となる標準技術です。

この技術の最大の特徴は、既存のHTML構造を維持したままCSS数行から導入でき、未対応ブラウザでもサイトが壊れない「プログレッシブ・エンハンスメント」の考え方にあります。リスクを最小限に抑え、ブラウザの標準機能だけで心地よい体験を後付けできるため、実務において非常に現実的な選択肢となります。

本セッションでは5分という限られた時間の中で、MPAでの実装方法や擬似要素による仕組みの要点を絞って解説し、実際の挙動をデモで素早く提示します。大規模サイトの保守に携わる方はもちろん、クライアントへ低コストかつ効果的な提案をしたいエンジニアやディレクターの方に向け、フレームワークに頼らず「もっと良い体験」を今すぐ届けるためのエッセンスを凝縮してお伝えします。

Laravelで開発しているWeb APIのテストでデータベースやRedisを使いたいとき、どうしていますか？
SQLiteで代用する、Docker Composeで事前に立ち上げておくなどのアプローチがありますが、どれも一長一短があります。
Testcontainersは、テストコードから直接コンテナを起動・破棄できるライブラリです。
MySQL/PostgreSQLでテストでき、テストごとにクリーンな環境が手に入り、CI設定もシンプルになります。

本セッションでは、LaravelプロジェクトにTestcontainersを導入し、APIテストを書く方法を紹介します。

話すこと：

• APIテストにおける課題
• Testcontainersの仕組みと利用するメリット
• LaravelのHTTP TestsやDBのマイグレーションと組み合わせた利用例
• GitHub ActionsなどCIでの動かし方
• テスト速度とのトレードオフ

状態をなんとなくbooleanやnullableで表していませんか？
そうすると「あり得ない組み合わせ」がコード上では許されて、仕様追加のたびに分岐漏れが増えがちです。
そこで、取り得るケースを列挙して閉じ、変更時の漏れが型エラーとして出るようにする、という代数的データ型の考え方を紹介します。

代数的データ型は、「かつ（AND）」と「または（OR）」という2種類の型の組み合わせで表現できます。
これにより矛盾した状態を作りにくくなり、分岐漏れも型検査で見つけやすくなります。

本セッションでは、代数的データ型を難しい理論としてではなく、変更に強い設計のための道具として扱います。
フロントエンドではTypeScriptの型検査、PHPではPHPStanの静的解析を活かし、言語やツールで担保できる範囲は素直に任せつつ、担保しきれない分岐や失敗だけを「閉じた形」として扱う落とし所を整理します。ケース追加時に「直すべき場所」が自然に見える形に寄せます。

型のテクニック集ではなく、レビューやAIコーディングでもブレにくい設計の基準を持ち帰ってもらうのがゴールです。

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

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

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

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

• ……

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

フロントエンドのパフォーマンス改善は「詳しい人がやるもの」と思っていませんか？

本セッションでは、プロジェクトの全体像を把握していなかった転職間もなかったエンジニアが、既存のVueアプリケーションのパフォーマンス改善に挑んだ実体験をもとにお話しします。
当時の私はコード理解が浅いまま、コーディングエージェントを活用して開発を進める中で、“それっぽい最適化”によって逆に性能を悪化させる失敗を何度も繰り返しました。

本発表では、
・コーディングエージェント利用下で起きたパフォーマンス改善のしくじり
・Chrome DevTools Performance タブを使ったボトルネック特定方法
・改善前後の具体的な変化
を、実例を交えながら紹介します。

勘や雰囲気ではなく、観測に基づいて進めるフロントエンドパフォーマンス改善の考え方と手順を持ち帰れるセッションです。

多くの人はWebアプリケーション開発の技術選定をする際に、

・フロントエンドとバックエンドを統一した言語やフレームワークを採用して開発する。
・フロントエンドとバックエンドそれぞれ適材適所の言語やフレームワークを採用して開発する。

かと思います。
それは開発効率やエコシステムの恩恵を最大限に受けられることや、各言語やフレームワークの持つ強みを活かせるからです、

ではバックエンドにTypeScriptを採用しつつ、フロントエンドにあえてPHPを採用して開発してみるとどうなるのでしょうか？

様々なライブラリやフレームワークが充実した現代では、このような構成でも開発できることは想像できますが、実際に試した方は少ないのではないでしょうか。
開発者体験や実装はどうなるのか？ライブラリやエコシステムの充実度は？パフォーマンスへの影響は？

本トークでは、この構成で実際に開発した経験を通じて、普段意識せずに享受している技術選定、言語やフレームワークの強みを再発見するきっかけなどをお伝えできたらと思います。

対話型AIのUIは即時応答を前提とした設計が主流でしたが、近年はウェブ検索や外部ツール操作、成果物の検証・修正を自律的に行うマルチエージェントAIの登場により、数分以上にわたる処理体験が一般化しつつあります。このような非即時性を伴うタスクにおいて、実行プロセスをどのように可視化するかは、ユーザーの作業効率を大きく左右します。

登壇者のチームでは、コーディングエージェントや近年のAIプロダクトを参考にしながら、マルチエージェントの実行プロセス表現を設計パターンとして整理・検証してきました。その結果、長時間処理であってもユースケースによって適切な表現手法は大きく異なることが明らかになりました。

本セッションでは、ストリーミング表示、中間成果物の即時確認、バックグラウンド実行と通知、エージェント単位の進行状況可視化といったパターンを紹介するとともに、それらの中からどの手法をどのような判断軸で選択し、実際のプロダクトへ適用してきたのかを解説します。パターンを銀の弾丸とせず、実装と検証を通じて設計判断を積み重ねてきた実践知を共有します。

私の関わるプロジェクトでは独自PHPフレームワークを長年運用しています。
ここにClaude Codeを導入しましたが、想定ほどチームに広がりませんでした。

理由はいくつかあり、独自PHPフレームワーク特有の前提が伝わりにくく、提案されるコードが期待とズレる場面があったこと。
加えて、そもそも「どう使うのが良いのか分からない」というメンバーが一定数いたことも影響しました。

そこでAIコーディングツールの定着に向けてフォロー体制を整備しました。
主に、利用状況の見える化や、意見箱の設置による改善サイクルを回す工夫、
独自フレームワーク前提でも使いやすいようにClaude Codeの設定やコマンドも整備などです。
こうした泥臭い取り組みを続けた結果、利用率は改善し、開発生産性への影響も見られるようになりました。

このLTでは、
・前提が強い環境でAIコーディングが馴染まなかった理由
・定着させるために現場で回したフォローのやり方と判断のコツ
・Claude Codeを現場向けに使いやすくする最適化の工夫
を共有します。

特に、活用にチーム内の温度差がある状況をどう扱ったかを中心に話す予定です。

いまや、フロントエンド開発に欠かせなくなったJSX (TSX)。
これが、実際にどのようにして解釈・実行されているか、説明できるでしょうか？
本発表では、非常に単純なJSXランタイムの実装例を取り上げて、その構造と、応用幅について紹介します。
また、発表者が直近自作JSXランタイムをTypeScriptと合わせて使った際に、JSX (TSX) の式を評価した結果の型の表現力に感じた限界について説明します。

取り上げる予定のもの

• 自作JSXランタイム
• React
• hyperscript
• jsx-slack

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

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

■ 対象者

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

私は今、とても悩んでいます。
チームメンバーの育成に、とても悩んでいます。

この一年で劇的に変化し、進化してきた生成AIによるコーディング支援技術はエンジニア個人の能力を拡張すると同時に、個人間の能力差というものも絶望的に広げていってしまいました。
すでに一線で活躍している人や、手を動かす以外の仕事に忙殺されるようになってしまった人にとって、これはとても喜ばしいことです。

しかし、チームで開発を続けていく以上、若手たちの育成もしていかなければならない。
私が十数年かけて培ってきたフロントエンドエンジニアとしての知識、経験。それらからくる勘所のようなもの。
こういったあれそれを、後輩たちに伝えていかなければならない。

アーキテクチャを教えればいいのかな？　
テクニックを教えればいいのかな？
心構えの話でもすればいいのかな？

・・・・・・一体どうすればいいんだーーーっ！！！

という具合に、この一年間、私が任されたフロントエンドチームメンバーの育成について、悩んだり実践したりしてきたあれこれを、お話しようと思います。

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

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

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

私はこれまで、大規模かつレガシーなMPAサイトの保守・運用に携わっていました。現場では「SPAいいな」と憧れつつも、大掛かりなリプレイスは現実的ではなく、モダンな画面遷移の提案を諦めていました。本セッションで紹介する「View Transition API」は、そんなかつての私と同じような制約下にあるエンジニアへの一つの回答となる標準技術です。

この技術の最大の特徴は、既存のHTML構造を維持したままCSS数行から導入でき、未対応ブラウザでもサイトが壊れない「プログレッシブ・エンハンスメント」の考え方にあります。リスクを最小限に抑え、ブラウザの標準機能だけで心地よい体験を後付けできるため、実務において非常に現実的な選択肢となります。

本セッションでは、MPAでの基本的な実装方法や、擬似要素によるスナップショットの仕組み、そしてDOMをクリーンに保つことによるアクセシビリティ上のメリットまでデモを交えて解説します。大規模サイトを保守している方はもちろん、クライアントへ低コストかつ効果的な改善提案をしたいエンジニアやディレクターの方に向け、フレームワークに頼らず「もっと良い体験」を届ける第一歩をお伝えします。