弊社ではエディター開発に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>要素を用いたフォールバックの実装方法についても解説します。

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

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

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

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

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

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

ユーザーが試行錯誤しながら状態を行き来する探索的UIでは、CRUDアプリケーションなどとはまた異なる前提・アプローチが必要になると考えます。

本セッションでは、サーバーをほぼ持たないクライアント完結型のツール開発を通して得た経験をもとに、
「画面の状態」と「アプリケーションとして守るべき論理状態」を分離することの重要性を整理します。

入力・状態の正解が存在しないUIにおいて、どの状態をUIに委ね、どの状態を設計として固定すべきか。
UIから分離した設計を固定するために、どのような構成・配置にするのか。

その考え方を、特定のフレームワークやドメイン知識に依らず、一般化して共有します。

みなさんは、「このUI、わかりにくいな」と思った瞬間にアプリを閉じたことはないでしょうか？

ユーザーは迷った瞬間に離脱します。説明が必要なUIは、その時点で選ばれません。

私はスポーツ指導者や高齢者支援、地域サービスといった現場にITを持ち込み、実際にユーザーに使ってもらうプロダクト開発に取り組んできました。しかし、そこで何度も目にしたのは「正しく作ったはずのUIが、誰にも使われない」という現実でした。

本セッションでは、現場で実際に起きた「想定外の使われ方」「そもそも使われなかったUI」の失敗事例をもとに、ユーザーを迷わせないUIとは何かをフロントエンドの視点で整理します。

フレームワークやコンポーネントの前に考えるべき、ユーザー行動から逆算したUI設計の原則を持ち帰っていただければ幸いです。

エンジニアとして成長したい！でもなぜか成長が頭打ち…そんな焦り、ありませんか？
僕も未経験〜５年目の今まで、成長したい一心で “正しそうに見える地雷” を踏み続けてきました。
今回はそんな僕がやって来た「働き方アンチパターン」をご紹介します

アンチパターン５選+α
・「設計後回しで突っ込む」病
・エラー/Warning無視」病（敵を味方にしない…）
・「思い込みで進める」病（きっと〇〇のはず！）
・「迷走して自分でも説明できない」病（木を見て森を見ず！）
・「無茶して英雄になりたい」病（持続不能、SDGSな働き方大事！）
＋
「努力の空回り」病（やるべきことをやらず、やらなくていいことをやる）
などなど…

これらは若手のあるあるかと思います
頑張っている”のに、実は遠回りになる典型的なアンチパターンです。

本トークでは、なぜそれが起きるのかと、明日から置き換えられる具体アクションを、実体験、先輩からの助言を踏まえ、現場あるあるで共有します。

成長は“努力量”より“努力の設計”で決まる。
皆さんも明日から、まずは「努力の設計」始めてみませんか？

「ゴール設定は大事」と分かっていても、実際の現場ではやっている割に効果を感じない、
結局タスク消化に戻ってしまう、そんなモヤモヤを抱えていないでしょうか。

本セッションは、ゴール設定にはスキルが必要であり、チームとして練度を上げていくことが重要だという前提に立ち、チーム全員が集中できるゴールを作るための考え方とコツを紹介します。

良いゴールが設定できるようになると、日々の会話が変わります。タスクを終わらせるかではなく、「ゴールに対して今どんな状態か」「次に何を打つべきか」という対話が中心になります。
その結果、

集中度が上がり、優先度の入れ替えや中止を冷静に判断できる
エンジニア自身が次の一手を提案しやすくなる

といった変化が生まれます。セッションでは、以下のポイントを実践的に扱います。

・チーム全員でゴールを作る理由
・自分たちも含めたステークホルダーのゴールを毎回イメージ
・SMART・ALIVE・FOCUSを使ったゴール設定の視点
・完璧なゴール（青い鳥）を追わず、手元から始める考え方

ゴール設定を「イベント」ではなく、チームで磨き続けるスキルとして捉え直したい方に向けたセッションです。

「技術はあくまで手段であり、目的ではない」本当にそうでしょうか？

振り返れば、通信速度の飛躍が人々のコミュニケーションの形を変え、AIという技術の登場が人間の思考のプロセスそのものを塗り替えています。これらは「手段」が「目的」を追い越したのではなく、「新たな技術の出現が、世界の前提を書き換えた」のです。

技術のポテンシャルを誰より、深く理解しているのは私たちエンジニアです。 ならば、「ビジネスの課題を解決するために技術を選ぶ」という受動的な姿勢はもう捨て、能動的なビジョンを提示し、責任を持ってそれを具現化していくべきです。

本セッションでは、フロントエンドやPHPというWebの最前線に立つ私たちが、技術的確信から逆算して「新しい当たり前」を創り出すために
・　 「技術が世界を定義する」というパラダイムシフト： 技術を手段に留めず、世界のあり方を規定する「前提条件」として捉え直す。
・　「見えている者」の責任： 技術の進歩がもたらす未来を予見し、それを事業やプロダクトにねじ込んでいくための覚悟。
・　技術の進化： 変化の渦中で「好きな技術」を使い続けることは、エゴではなく、未来を証明するための闘いである。

SPA フレームワークのひとつ、Blazor WebAssembly は、React、Angular、Vue、Svelte 等と同類の「コンポーネント指向」フレームワークです。その最大の特徴は「C# で実装する」という点です。これは C# を JavaScript にトランスパイルするのではなく、ビルドして生成された .NET のアセンブリ (.dll) を WebAssembly によるインタープリタで実行するという大胆な仕組みで実現されています。Blazor は認知度こそ低いですが、WebAssembly を利用して JavaScript 以外の言語で SPA 開発を行う成功例のひとつと言えます。このトークを通じて JavaScript 一辺倒の SPA 開発に一石を投じ、様々な言語の開発者の声を拾うきっかけになればと思います。
また、「ブラウザで C#/.NET が動く」という点だけでなく、SPA フレームワークとしての Blazor の特徴や設計思想についても、他ライブラリと比較しながら取り上げていきます。
普段とは異なる技術スタックに触れることで、技術者としての視野を広げる機会になれば幸いです。

TypeScriptのファーストのスキーマ検証ライブラリであるZod。
「TypeScript バリデーション」で検索すると必ずと言っていいほど候補に上がってくるライブラリであることから、
入力フォームのライブラリで採用している方も多いかと思います。

それに加え、入力フォームの検証以外にもJSON.parseしたオブジェクトなどに利用することも有効です。
ですがTypeScriptのJSON.parseはある問題を抱えています。

本セッションははその問題を起点に複雑なネストを抱えたオブジェクトに対して、
どういうアプローチで型安全な実装をしていくかをお話していければと思います。

目次

1. Zodについて
2. JSON.parseの問題点
3. 複雑なネストを抱えたオブジェクトに対して、ユーザー定義の型や型ガードで対応するのじゃだめなの？
4. Zodの使用例

Obsidianとは、マークダウン形式のテキストデータをローカルで管理できるノートアプリケーションです。
デフォルトの設定で使っても十分に便利ですが、各種プラグインを導入して色々とカスタマイズすることも可能です。

そして実はなんと、Obsidianのプラグインは、フロントエンドの技術（TypeScriptなど）だけで簡単に開発できるようになっています。素晴らしいですね！

本セッションでは、Obsidianのプラグイン開発の基礎と、作成したプラグインの公開方法についてお話します。
また、サンプルとして私が丹精込めて作った謎プラグインをお出しします。

こんな人におすすめ

• Obsidianが好き
• Obsidianのプラグインを作ってみたい
• 謎機能が追加されてしまったObsidianを見たい

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

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

概要

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

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

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

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

持ち帰れるもの

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

概要

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

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

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

持ち帰れるもの

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

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

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

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

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

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

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

基本的な情報

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

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

お品書き

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