プロポーザル

「コントラスト比を気にしてみた」「ボタンを大きくしてみた」
アクセシビリティを気にしてデザインや実装をしている方も多いかもしれません。

SmartHRでは、国際基準のWCAGをもとにした簡易チェックリスト（https://smarthr.design/accessibility/check-list/） を使用し、実装段階でのアクセシビリティ向上に取り組んできました。

しかしながら、アクセシビリティは「実装」がゴールではなく、スタートラインであり、継続して観測していくことが重要だと考えています。

このセッションではSmartHRのアクセシビリティ担保の仕組みを中心に、以下の内容を説明します。

• アクセシビリティ担保が必要な理由
• アクセシビリティ向上のための定期試験
• WCAG準拠以外のアクセシビリティ〜障害特性を考慮したガイドライン〜

AIエージェントが開発に活される時代において、スキーマ駆動開発が持つ新たな役割と、その価値について解説します。

近年のAIエージェントの台頭は、私たちの開発スタイルを大きく変えようとしています。
AIエージェントはコードベース全体を理解してコードを生成してくれます。それならば、責務分離のためのスキーマ駆動開発はもう不要なのでしょうか？

実際にAIエージェントと日常的に開発する中で、私はむしろスキーマ駆動開発こそがAIエージェントの能力を引き出す鍵になるのではないかと考えました。

本発表では、TypeScriptスキーマがAIエージェントを支える役割を解説します。
これらの役割を通じて、AIの自律的な開発を実現するハブとしてのスキーマの価値を示します。

対象は、AIエージェントを活用している方、これから活用したい方々です。スキーマ駆動開発の経験は問いません。
この発表を通じて、AIと共存する未来の開発において、スキーマがいかに重要なハブとなるかを理解し、日々の開発に活かすための視点を提供します。

みなさんWeb IDLって知っていますか？

Web IDLは、WHATWG/W3Cの仕様書で定義されたWeb APIのインターフェースを定義するために使われている言語です。
TypeScriptのlib.dom.d.tsの生成時にもWeb IDLを情報源として使っています。

本LTでは、Web IDLがどんなものなのかWeb IDLを知っておくと何が嬉しいのかについてお話します。

本LTでは以下の内容についてお話しします。

• Web IDLとはなにか
• Web IDLの見方
• 「なぜこのAPIはWorkerで使えないのか」「なぜHTTPだとundefinedになるのか」「なぜこの文字列だけ文字化けするのか」などをWeb IDLの観点から説明予定

工数見積りってのは一人でやったらだめなんだ！
マネージャーやリーダを含めて！チームでやるんだ！

一人でやったらだめな理由

• 数字が個人にのしかかってくるから追い詰められる
  • そもそもマネージャーは見積りの数字を納期にするな
• 見積もったヤツが病気になったらどうするんだ？引き継いだやつが工数の責任負わされるのか！？
• 数字よりも、どうしてその工数でできると思ったかが重要なんだ
  • 見積りは実質設計（なんなら開発まで）をやってるようなもんだから、思考プロセスの共有が最も重要なんだ
• そもそもシステムやドメインの境界線について一人で考えられないでしょ多分

みんなでやろう

• 対話を通して不確実性を洗い出そう
• 知識を共有しチーム内の知のバランスを整えよう
• 工数はチームみんなで責任を持とう。でも絶対じゃないってのも知ろう

見積りって行為はエイヤァじゃないってのを伝えたい
真剣に取り組むことでチームやプロダクトを牽引する強い力が働く行為ですよ

<a>要素を使ったLinkButton実装において、disabled状態にもかかわらずフォーカスが当たり、Enterキーで操作できてしまうケースに遭遇しました。

本LTでは、この挙動がアクセシビリティの観点でどのような点が問題になり得るのか、HTML要素の役割（セマンティクス）、W3C仕様、ARIA属性の考え方を踏まえながら見ていきます。
さらに、主要なUIライブラリの実装例を参考にしつつ、LinkButtonにおけるdisabled状態をどのように実装・表現するのがよいのかを考えていきます。

長期的な保守性や再利用性を考慮して、Reactに依存しないライブラリを選ぶことがあります。
このLTでは、TanStack Query風のライブラリを簡易的に自作しながら、「Reactに依存しないライブラリ設計」とは何か、コードベースからイメージを掴みます。

useSyncExternalStore と Pub/Subパターンを使った React と VanillaJS の連携
Reactから他UIライブラリへの対応

について話します。

「改行が消えた」「謎のタグが混入した」…
WYSIWYGエディタにありがちな壊れやすさに悩まされたことはありませんか？

本LTでは、Tiptap を用いてHTMLの一貫性・拡張性・テスト可能性を兼ね備えた堅牢なリッチテキストエディタをどのように設計・開発するかを紹介します。

ProseMirrorのスキーマ定義を活用したHTML構造の強制と正規化
Reactコンポーネントの組み込みやプラグインによる拡張性
TiptapのExtension単位での単体テストによる機能ごとの信頼性担保
について話します。
WYSIWYGエディタの扱いに課題を感じている方や、Tiptapを本格的に活用したい方にとって実践的なヒントとなる内容をお届けします。

たくさんWebアプリを構築するけどホスティング費用は抑えたい
そんな個人的な悩みの解決方法を共有したくなったので、2026年現在のホスティングサービス料金を徹底比較します！

NextJSを使用されている方向けに、Vercel以外のホスト手段として
・Cloudflare Workers
を用いたホスティングについて解説します。
無料枠内でWebアプリをホストできるので
・何個までホストできるのか
・どのような手順でホストできるのか
を紹介します。

またLaravelなどを使用されている方向けに
Renderを使用した複数のWebアプリのホスティングについて解説します。
無料枠内でWebアプリをホストできるので
・何個までホストできるのか
・どのような手順でホストできるのか
・Dockerファイルの設置
を紹介します。

上記のホスティングサービスを利用する以外の手段として
・Nextjs / Laravelがホストできる安価なVPSを利用する方法
・バニラPHPのWebアプリを共有サーバーを利用する方法
・ローカルサーバーを用いたホスティング（CloudFlare Tunnel併用）方法
を紹介します。

モノリシックなフロントエンドでは、認証や画面の増加に伴い開発と保守の負担が増大します。本発表では、認証を統合した上でフロントエンドを機能単位に分割し、それぞれ独立して開発・デプロイ可能にする手法を紹介します。バックエンドのマイクロサービスアーキテクチャの考え方をフロントエンドに応用する「マイクロフロントエンド」や、認証・データ取得の統合戦略を解説し、開発効率とスケール性の向上につなげる具体的な実装例と注意点を共有します。小規模〜大規模チームに有効なフロントエンドの新しい開発アプローチをお届けします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LLM にフロントエンドのコードを書かせたときにこんな問題に直面していませんか？

・同じようなコードが繰り返されている
・コンポーネントの責務が曖昧
・使われていないコンポーネントがある

これらのコード品質の問題は開発前の設計で防ぐことができます。

Vue コンポーネント開発において、props とコンポーネントの依存関係を事前に設計することで、LLM が生成するコードの品質を安定させることができます。

本 LT では、業務で試して分かった品質を担保するための設計プラクティスをお話しします:

・LLM に渡すべき設計情報
・品質ブレを防ぐ設計フォーマット
・実務で得られた効果と課題

LLM でも長期的に保守できるコードを書けるように設計を工夫していきましょう！

みなさんは「この会社、エンジニア強そうだな」と感じたことはないでしょうか。
実は、エンジニア組織の強さは外からでも意外と見えます。

26卒の就活生として、学生の立場で多くの企業を見てきた中で感じたのは、プロダクト思考やビジネス視点があることはもちろん大切ですが、
それだけでは「エンジニアとして強い組織」には見えないということでした。
一方で、設計の話をしている、技術選定の理由を語れる、失敗を技術として言語化している。
そうしたエンジニアがいる会社は、学生から見ても自然と「ここは強い」と伝わってきます。

本LTでは、学生目線で企業のエンジニアを観察してきた経験をもとに、プロダクト思考と技術思考の違いに触れつつ、外から見える“エンジニアとしての強さ”の正体を整理します。

SPA フレームワークのひとつ、Blazor WebAssembly は、React や Angular、Vue、Svelte などといったライブラリ/フレームワークと同じく、UI コンポーネントを組み上げてクライアント Web アプリケーションを構築する「コンポーネント指向」のフレームワークです。しかし最大の違いは「C# で実装する」という点です。しかも C# のソースを JavaScript にトランスパイルするのではなく、C#/.NET のアセンブリバイナリをそのまま WebAssembly によるインタープリタで実行してしまうという大胆なアーキテクチャです。さらに加えて、ただ実行できるだけでなく、ブラウザの開発者ツールウィンドウでのデバッグが可能です。つまり、開発者ツールでのブレークポイントの設定とステップ実行、変数ウォッチなどが C# ソースを対象に行えるのです。

ということでこの LT では、開発者ツールに JavaScript 以外の言語が表示される、そんな不思議な光景をライブデモでお見せします。

その角丸、本当に納得していますか？
Apple製品のアイコンやハードウェアの曲線がどこか「気持ちよく」感じる理由。それは単純な円弧（border-radius）ではなく、直線から曲線へと曲率が滑らかに変化する形状が使われているからです。こうした形状は一般にSquircleなどと呼ばれ視覚的な自然さを生み出しています

これまでWebでこのような角丸を再現するには、SVGマスクやclip-pathなどを用いた実装が必要でメンテナンス性に課題がありました
しかし現在CSS Backgrounds and Borders Module Level 4において、corner-shapeプロパティが提案されておりCSSネイティブで表現できる未来が見え始めています。

本LTでは以下の内容についてお話しします。

• なぜ border-radius の角丸は硬く見え、Squircleは「気持ちよく」感じられるのか
• 提案されているCSS仕様corner-shapについて

たかが角丸、されど角丸。
フロントエンドエンジニアのこだわりを、CSS がどこまで表現できるようになるのか。その一端を一緒に覗いてみませんか？

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

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

ターゲット:

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

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

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

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

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

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

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

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