Reactは登場から10年以上経ち、コミュニティに広く受け入れられるとともに、React自体も進化を続けています。

私もReactに関する情報発信を多く行ってきました。
また、去年終わり頃からはAIの進化によるコーディングスピード向上に助けられ、Reactに関係する実験的で小さなライブラリをいくつかFUNSTACKシリーズとして開発してきました。

私は発信するときや何か作るときは新規性を重視しており、新しい知見や斬新なソリューションを重視します。
その私を2026年になってもまだ楽しませ続けてくれる、いまだ新規性の宝庫であるReact。これはとんでもないことです。

Reactに対するこの情熱を共有するべく、
FUNSTACKを中心に最近の活動とその成果についてお話しします。このトークを通じて、私がReactのどういうところに楽しみを見出して、どうやって新規性の種を見つけ、それを育てているのかをお伝えします。

フロントエンド開発では、コンポーネント分割やフレームワークの使い方が設計そのものとして語られがちです。
しかし、状態遷移や操作の連鎖を扱う現代のフロントエンドは、すでに一つの「アプリケーション」です。

本セッションでは、Vue / React / Svelte で同一のアプリケーションコアを共有する TODO アプリの実装と、
過去に作成したサンプルが 5年後に view 側ライブラリを刷新してもコア部分には一切手を付けずに済んだ という経験を手がかりに、
フロントエンド設計における境界の引き方を考察します。

このように UI の外側に知識と振る舞いを固定する設計は、流行やツール変更に耐えるだけでなく、
型と振る舞いが明示された構造として AI を用いた開発とも相性が良い という側面を持つ、というお話も含みます。

テクニックではなく、「何を UI とみなし、何をアプリケーションの知識として扱うのか」という設計上の態度を共有します。

歴史のあるコード、いわゆるレガシーコードは直そうとすると壊れがちです。
また、IDEでは未使用に見えるのに、実はAPIやバッチで呼ばれていたコードを変更して障害になる事故も少なくありません。
最終的に、一度事故が発生した箇所に誰も触れなくなるという光景を目にしたことはないでしょうか？

このトークでは、リファクタリングやバージョンアップのような変更を安全に進めるため、変更に入る前に呼び出し元や依存関係の洗い出しについてお話します。そのなかで、コーディング支援ツールを調査役として使うコツも取り上げます。

ターゲット:

• 実務でレガシーコードの変更に不安がある人
• 影響範囲の調査にコーディング支援ツールを活かしたい人

皆さんは日常でどのようなコミュニケーションツールを使っていますか?
Slack, Microsoft Teams, Chatwork, Google Meet, Zoom, LINE etc... 挙げていけばキリが無いと思います。

コミュニケーションツールでよく利用するのが絵文字。皆さんも一度は「🙇‍♂️」や「:yoroshiku_onegaishimasu:」を使ったことがあるのではないでしょうか。
ところで、「👍」と「👎」ってこのようなツールだとよく並んでいますよね。誤って「👎」を押さないように、必死に「👍」の左端を狙っている日々を送っている方もいるんじゃないかと思います。

そこで、本セッションでは、何故上記のような押しミスが発生しやすいUIが作られがちなのかという疑問を解説します。
また、絵文字ピックのUIを提供する上でどのようにすると、ユーザーを幸せにできるのか勘所をお伝えします。

このセッションは、フロントエンドエンジニアや絵文字に興味がある方、絵文字の処理に苦しんだことのあるサーバーサイドエンジニアを対象としています。

フロントエンド技術が多様化する中、管理画面においても将来の拡張を見越してReactなどのSPA構成を選択するケースが増えています。
SPA構成では、フォーム項目やバリデーションといったUI構造をAPIとして表現する必要があり、そのたびにフロントエンドとバックエンドの調整が発生します。結果、小さな変更であっても、実装や保守のコストが膨らみがちです。
一方HTML+JSで構築するとUIの状態やロジックが分散し、仕様変更が続くにつれて全体を把握しづらくなります。
管理画面はビジネス側の要望を素早く反映することが求められ、変更のしやすさは重要な設計要件と言えるでしょう。

本セッションでは、Server-Driven UI(SDUI)という考え方に着目し、Laravel用のUIフレームワークであるLivewireを題材に、UI構造と振る舞いをサーバー側で一元管理することで、変更に強く開発速度を維持できる設計について解説します。
逆にSDUIが苦手でSPAが適している面なども合わせて説明します。
本セッションを通してSDUIの利点を知っていただけると幸いです。

近年、カンファレンスや書籍を通じて多様なソフトウェア設計手法が広まり、選択肢は増え続けています。
しかしリソースは有限であり、すべてを完璧に実装することは困難です。
力を注ぐべき箇所を見極めることも重要になってきています。

事業の競争優位を支える核心領域を見極めそこに積極的に投資する。
判断を誤ると逆に設計に振り回され事業価値に結びつかないコストばかりが増える危険もあります。

さらに最近では、コードの「捨てやすさ」も注目されています。
「作る」ことの判断だけでなく、「捨てる」ことの判断も重要となってきました。

本セッションでは、KentBeckの“Optionality”などの考え方に触れつつ、設計投資にメリハリをつけ設計・コーディングの「力の入れどころ」や「捨てやすさのデザイン」をどう考えるかお話します。
また、私自身の過去の失敗例も交え、理論と実践の両面から学びをお届けできればと思います。

事業価値を見据え、何に投資しどう捨てるべきか。
判断のヒントとなれば幸いです。
※本セッションはPHPカンファレンス香川2025の講演内容をベースに設計判断部分によりフォーカスしてブラッシュアップしたものです。

概要

ウェブサイトの「速さ」はLighthouseのスコアだけで決まるものではありません。通信環境やデバイスの制約を超え、フロントエンドの工夫ひとつで「体感速度」は向上させられます

本トークでは、ユーザーの待ち時間をゼロに感じさせるための実装戦略を、「操作前・中・後」という3つのフェーズに分けて紹介します

1. [操作前]先読み：Next.jsやTanStack Queryを用いた、クリック前の予測実行。実験的なWeb APIであるSpeculative Rules APIについて
2. [操作中]段階的表示：初期表示の高速化と、その際に課題となりやすいN+1問題に対するDataLoaderを用いた対策
3. [操作後]楽観的更新：useOptimisticやTanStack DBを活用した、通信待ちを感じさせない書き込み処理

それぞれがどのようなもので具体的にどのように実装すれば良いかついて話します

持ち帰れるもの

• 3つのフェーズ（操作前・中・後）における、体感速度改善を実現する実装イメージ
• 実装コストとUXの向上を天秤にかけるための、状況に応じた高速化手法の選定基準

ソフトウェア開発者の皆さん、上空でのプログラミングに困っていませんか？
飛行中だと、WiFiがなくてChatGPTと繋がらないよ！ (´；ω；｀) みたいなことが起きて困りますよね？

実は、お手持ちのローカル環境で大規模言語モデルを動かす！ という技を使うことで飛行中のプログラミングは解決できるのです！ というのは数年未来のお話です。 現在はまだ実用的ではありません。 しかし、技術的には可能です。 技術的に可能ならやるしかないですよね。
ということで、今回は指定したプロンプトに対して生成された答えを返す、という仕組みをローカル環境で作ってみます。 普段使いのSvelteKitでOllamaを操作し、推しの大規模言語モデルと対話してみませんか？ PHPの活躍にもご期待ください。

※この分野は急速に発展途上中であり、現時点(1月)の内容が発表時の(6月)には、全然そんなことしなくてもよかったのに...となっている可能性もあります。 ご了承ください。

概要

たくさんのアプリで見られる「あなたにおすすめ」という機能は便利なはずですが、時としてユーザーに不気味さや、強引な「押し付け」を感じさせてしまうことがあります。このとき、開発側の意図とユーザーの受け止めの間にある「溝」の正体は何でしょうか。

本トークでは、システム側が一方的に提示しがちな情報を、ユーザーがいかに自分の意志で受け入れ、信頼できるものに変えていくかを考察します。

具体的には、UI/UX設計における「透明性」と「制御権」の2つの観点を深掘りします。メインの題材として、「レコメンドシステム」を取り上げ、有名アプリの事例を引き合いに出しながら、内部ロジックをフロントエンドがいかに「納得感のある体験」として翻訳・実装できるか、具体的なUIパターンを交えて解説します。

持ち帰れるもの

• ユーザーに「操られている感」を与えないための制御権の設計術
• 「なぜそうなったか」を提示し、不信感を払拭する説明可能なUIの設計術

生成AIの普及により、エンジニアはかつてない量のコードを読み、レビューすることが求められています。
これからの時代、コードを「速く」かつ「正確に」読むスキルは、エンジニアの生産性を決定づける最重要能力です。

「速く読むこと」と「正確に読むこと」はトレードオフだと思われがちですが、そうではありません。 読む「目的」に応じてモードを切り替えることで、この2つは両立できます。

本トークでは、シニアエンジニアが経験則として持っている暗黙知を体系化し、コードを「信じる」「疑う」という2つのモードについて、具体的な使用場面を交えて解説します。

認知負荷のハック（信じる技術）： 変数名や構造などの「意図」を信じることで、脳内コンパイルを回避し読む速度を上げる

バグ検知の感度向上（疑う技術）： 「意図（命名）」と「事実（実装）」の乖離に気づくために、入出力やエッジケースを徹底的に疑う

本トークを通じ、ジュニアエンジニアにはコードリーディングの新たな知見を、シニアエンジニアには「なんとなく」読んでいた感覚を言語化するヒントを提供します。

𠮷 ← これは何文字でしょう？
当然、1文字と答えますよね？

では、JavaScriptで'𠮷'.lengthで測りましょうとすると罠に落ちます。
2が返ってくるためです。このときの正しい測り方は何でしょう？

PHPならこんなことにはならないぞ、だってmb_strlenは正しく1を返すぞと反論するとします。
では、 🇯🇵 をmb_strlenで測ってみてください。2と返ってきますよね？
邉󠄀でもいいかもしれません。2と返ってきますね？

本トークでは文字とはなにか、フロントエンドとバックエンドで揃えるときどうするべきか、
そのときに必要になる書記素クラスターの存在を解説していこうとおもいます。

「なぜNginxなどのWebサーバーが必要になるのか」
PHPerが一度は疑問に思うことランキングの上位だと(勝手に)思っています。

このトークでは、NginxになりきってPHPと話してみることで、WebサーバーとPHPがそれぞれ何をやっているのか、を理解することを目指します。

話すこと

• FCGIでPHPと通信し結果を得る方向
• NginxなどのWebサーバーの役割
• 他の言語ではどのようにWebアプリケーションをホストしているのか

他の言語との違いを知ることで、よりPHPの理解を深めることができます。自信を持ってPHPの特徴を説明できるようになりましょう。

基本的な情報

私たちのプロジェクトでは、Lumen FrameworkとCodeception / Specifyを採用していましたが
Codeception / Specify の更新が終了してしまいました。
移行先は pestphp を予定していましたが、１万を超えるテストケースを具体的にどうやって移行するのかが課題になっていました。

これらに、この１年でどう立ち向かったのか、どのように方針転換をしたのかをお話しします。

お品書き

• codeception / specify についての簡単な説明
• 終わりの始まり：テスト用フレームワークの EOL
• Pest への移行
• Rector による置換の試みとその問題点
• 技術の進歩: Agent Skills という光
• まとめ

弊社サービスの検索機能は、検索基盤にAWS OpenSearch Service を利用しており、数百万件規模のデータに対して毎分数千件の検索リクエストが発生します。
現行バージョンのEOL見込みにより移行が必要でしたが、サービス停止時の影響が大きく、アプリケーション側の修正も伴うため低リスクで進める必要がありました。

このトークでは、新クラスターの並走や段階的リリースを活用して安全に切り替え、異常時には即時ロールバックを可能にする手法を解説します。
加えて、 移行する中で顕在化した切替点が分散した設計を、Factory Patternや静的解析などを利用して改善した事例についても紹介します。

Goal

• 本番環境にある検索基盤を低リスクに切り替える
• 切替点を集約し、次回の移行を楽にする設計の型を持ち帰る

Non-Goal

• OpenSearchの機能深掘り

現代のソフトウェア開発者で「技術的負債」という言葉を知らない方はほとんどいないでしょう。一方で「技術的負債とは何か」を正しく理解し、自信を持って説明できる人はあまり多くありません。相手が非エンジニアであればなおさらです。

技術的負債についての理解が不十分なことから「技術的負債＝悪」というイメージを持ち、無謀なリファクタリングを行う例や、逆に放置しすぎてビジネス面でのリスクが顕在化してしまう例は今なお後を絶ちません。

PHPはその長い歴史から、フロントエンドは流行の移り変わりの速さから技術的負債とは切っても切れない関係にあります。本トークでは「技術的負債とは何か」を言語化した上で、バックエンド・フロントエンドの両方に深く関わってきた経験、さらにAIによって大きく変わりつつある現代の開発環境を踏まえつつ、双方に共通する技術的負債との向き合い方や付き合い方をお伝えします。

Vitestでコンポーネントなどに対してテストを書く際に初学者が躓きやすいAPI通信のモックについて、主要なパターンを3つ紹介します。各パターンのメリット、デメリットを考察し、リファクタリング耐性などの観点についても話します。
また、現在私がVitestにPull Requestを出しているVitest標準のAPIモック機能について、どのような仕組みで実装したのかなどを紹介し、将来デファクトになるかもしれない未来について思いを馳せたいと思います。

再利用性の高いコードを書きたいと考えた結果、
いつの間にか責務が肥大化した「神クラス」を作ってしまった経験はないでしょうか。

多くの場合、その背景には「さまざまなケースに対応できる1つのコード」を作ろうとする考え方があります。
しかし、世の中で再利用されているモノほど小さな目的に特化して作られているという特徴があります。

本セッションでは、
具体的な実装手法や設計パターンを紹介するのではなく、
世の中で再利用されているモノと「神クラス」の違いに着目しながら
「再利用性とは何か」を考え直すことを目的としたセッションです

ifを減らしたい、複雑さを抑えたい、オープン・クローズドの原則に沿った変更に強いコードを書きたい。
しかし「どう設計すれば良いか分からない」と感じたことはないでしょうか。
本セッションはそんなエンジニアに向けた内容です。

分岐が多く保守が辛いコードの多くは、
複雑なロジックを「使う」側で分岐させていることが原因だと考えています。
この設計では機能追加や変更のたびにifが増え、
可読性が低く、テストが辛い、変更に弱いコードになってしまいます。

本セッションでは、
複雑なロジックを「使う」側で分岐するとなぜ辛くなるのか、
「どう使うか」ではなく「どう作るか」で分岐すると、設計がどう変わるのかを整理して解説します。

その上で、「作る」と「使う」を分けることで複雑さを適切な場所に閉じ込め、
オープン・クローズドの原則に沿った変更に強いコードにつながる理由を実践的な題材を通して説明します。

TypeScriptなどを用いた開発の中で、「美しく、保守性の高いコードとは何か」を模索している方は多いのではないでしょうか。
私は業務で先輩エンジニアからコードレビューを受ける中で、その「美しさ」の源泉が関数型プログラミングの考え方に深く根ざしているかもしれない、というお話を聴く機会がありました。「なぜイミュータブルであることが重要なのか」「なぜ関数を最小化すべきなのか」を、概念としてだけでなく「言語仕様レベルで強制される環境」で肌感覚として理解したいと考え、 F#の学習を始めました。
本セッションでは、F#を学ぶことで意識するようになった「所作」や、関数型の思考がなぜ多言語の品質向上に結びつくのかについて吟味し、「綺麗なコードを書きたいけれど、何から学べばいいかわからない」という悩みに対する一つの指針として「他言語学習」の価値と、そこから得られる視点の変化をお伝えできればと思います。

テストコードを書いていれば安心、そう思っていませんか？
プロダクトコードに明らかなバグがあるにもかかわらず、テストが成功を表示し続けることがあります。
これらは開発体験のお邪魔虫に違いないのですが...意図せずこれらを生み出しているかもしれません。
そう、わたしのように...。

このセッションでは「実際の失敗例」を通じてなぜそれが生まれるのか、そしてどうやったらそれが生まれないのかを話します。
昨今ではAIを使ってテストコードを生成することもあるため、生成させるときにどのような点を気に掛ければ良いかについても触れていきます。

テストを書きやすく、かつ壊れやすく（＝正しく失敗するように）するための「テストコードの設計」を追求しましょう!!

話すこと

• わたしの失敗例たち＆どうすればよかったか
• 偽陽性・偽陰性を防ぐテストコード設計
• 良いテストコードを書いてもらうためのAI活用法