【テーマ】
サーバーサイドレンダリング（SSR）における「クロスリクエスト状態汚染」の危険性と、その根本原因となる設計上の問題の解説。モダンWebフレームワーク「Astro」を例に、リクエストごとに状態を安全に分離するための具体的な設計パターンと実践的対策。

【想定する参加者層（前提知識）】
Webアプリケーションの開発経験がある方 (特定のフレームワーク（Astroなど）の知識は必須ではありません。)

【トーク概要】
「ローカル開発では完璧に動くのに、本番環境で時々データがおかしくなる…」 そんな経験はありませんか？その原因、もしかしたらサーバーサイドでの「状態管理」の実装にあるかもしれません。

サーバーサイドレンダリング（SSR）のような、サーバー上でリクエストごとに処理を行うアーキテクチャは、Webのパフォーマンスを向上させる強力な手法です。しかし、クライアントサイドの感覚で安易に状態管理ライブラリを導入すると、実は時限爆弾を抱えている可能性があります。

同時リクエストが多発するサーバー環境では、あるユーザーのために用意された状態が、競合によって別のユーザーに漏洩してしまう、「クロスリクエスト状態汚染」という深刻な問題を引き起こす可能性があるのです。これは単なる表示の不具合に留まらず、個人情報漏洩に直結しうる、極めて危険なセキュリティリスクです。

このセッションでは、多くのWeb開発者が見落としがちな、このサーバーサイド特有の落とし穴を深掘りします。 なぜこの問題が起こるのか？その根本原因は、サーバー上でただ一つの共有データ置き場を、複数のリクエストで使い回してしまうという、設計上の問題にあります。 セッションでは、モダンなWebフレームワーク「Astro」と状態管理ライブラリ「Nanostores」を具体的なケーススタディとして取り上げ、どのようなコードが「地雷」となり、公式ドキュメントがなぜサーバーサイドでの安易な利用に警鐘を鳴らしているのかを、実際のコードを交えて解説します。

ClaudeやChat GPTなどの生成AIでは、プロンプトを記述することで出力をコントロールします。
この際、自然言語ではなく疑似コードを用いてプロンプトを記述することで、手順や論理構造を端的に指示するテクニックが知られています。
疑似言語にはJavaScriptの文法を用いる例が多いですが、SudoLangなど専用の文法も考案されています。

この手法は一見便利そうですが、実際にどれだけ正確に意図が伝わるのでしょうか？
if文のネストは正しく解釈されるのか？ for文やwhile文によるループは正確な回数繰り返されるのか？ C言語のマクロ・Go言語のGoroutine・Prologのバックトラックなど、言語ごとの特殊な機能は正しくエミュレートされるのか？

わたし、気になります！

というわけで試した結果を共有します。

想定する参加者層
生成AIに関心を持っているエンジニア。
特にプロンプトエンジニアリングの経験は問いません。

テーマ
生成AIの疑似言語によるプロンプティングの正確性・限界を確認する

(レギュラーセッションと同内容で応募していますが、LT枠に収めるため事前説明は省いてプロンプト例と結果を出して一言解説つけるくらいのテンポ感を想定しています)

ClaudeやChat GPTなどの生成AIでは、プロンプトを記述することで出力をコントロールします。
この際、自然言語ではなく疑似コードを用いてプロンプトを記述することで、手順や論理構造を端的に指示するテクニックが知られています。
疑似言語にはJavaScriptの文法を用いる例が多いですが、SudoLangなど専用の文法も考案されています。

この手法は一見便利そうですが、実際にどれだけ正確に意図が伝わるのでしょうか？
if文のネストは正しく解釈されるのか？ for文やwhile文によるループは正確な回数繰り返されるのか？ C言語のマクロ・Go言語のGoroutine・Prologのバックトラックなど、言語ごとの特殊な機能は正しくエミュレートされるのか？

わたし、気になります！

というわけで試した結果を共有します。

想定する参加者層

生成AIに関心を持っているエンジニア。
特にプロンプトエンジニアリングの経験は問いません。

テーマ

生成AIの疑似言語によるプロンプティングの正確性・限界を確認する

昨今のITエンジニアは求められる知識と技能が広がり続けています。私自身もWeb業界にいてその変化を強く感じてきました。これまでも新しい技術を学び、自分のできることを増やす機会は多くありましたが、生成AIの登場によって学び方は少し変わりました。

これまでバックエンドエンジニアとしてキャリアを積んできた私がフロントエンド開発に挑戦し、日々の実践と生成AIの活用を通じて成長していった過程をお話しします。
最初はTypeScriptでCLIツールやREST APIを作るところから始め、React.jsで小さなアプリを作ってアウトプット。転職後は実務でフロントエンド開発を進んで担当し、ペアプログラミングを実施することで自然と自らフロントエンド開発を進められるようになりました。

学びを支えたのは「継続して手を動かすこと」と「生成AIを学習の加速装置として使う姿勢」です。自分に無い実装の引き出しを他の人と一緒に実装することで獲得したり、AIの出力を鵜呑みにせず一次情報を調べ、実装で確かめることで理解を深めました。人との協働による実践的な成長と生成AIによる学習サイクルの高速化がうまく融合しました。

その積み重ねの結果、私はフロントエンド中心のプロジェクトに参加し、自身の責務を果たすことができました。
このセッションでは、「新しい領域を学ぶためにできる工夫」、「生成AIによって変化した自学習」、「実践を通じてどう変わっていったか」を、私自身の経験をもとにお話しします。

話すこと(変更の可能性あり)
・ 新しい領域を学ぶときの工夫
・ 生成AIによって自学習がどのように変化したのか
・ たくさんの実践を経て自分がどう変化したのか

FlutterによるWeb開発の基礎から最近の技術まで解説します。
1つのコードから複数プラットフォームに展開する開発手法、Flutter Webで既存Webコードを活用する方法、そしてWebAssembly (WASM)の対応状況と使い方を、実例を交えて解説します。

想定する参加者層

FlutterやDartの経験は不要です。

• モバイルアプリ開発者でWebにも挑戦したい方
• Flutterに興味がある方

概要

Flutterはマルチプラットフォーム開発に対応しており、Webアプリの開発にも対応しています。
この発表では、Flutter Web開発を中心にFlutterについて解説します。

マルチプラットフォーム開発

Flutterの基礎として、1つのコードでiOS、Android、Web、デスクトップすべてに対応できるマルチプラットフォーム開発を紹介します。 またFlutter Webについて取り上げ、レンダリング手法について紹介します。

WebComponentsの活用

Flutter Webの中で既存のWebComponentsを埋め込んで使う方法を紹介します。Flutter Webではまだサポートされていない技術や、既存のWebの資産を再利用したいときに便利な方法です。

WebAssembly対応

WebAssemblyの対応状況や、WebAssemblyを有効にする方法を紹介します。Flutter 3.22以降で正式対応したWASMビルドで、Flutter Webのレンダリングがどう変わるのか既存のレンダリングと比較します。

このセッションで得られるもの

• Flutter Webの全体像と使いどころ
• マルチプラットフォーム開発の実践的な知識
• Flutter Web内で既存Webコードを活用する方法
• WebAssembly対応の現状と使い方

FlutterやFlutter Web開発の良さをお伝えできたらなと思います！

去年の Burikaigi では WebDriver BiDi とは何なのか話しました
https://speakerdeck.com/yotahada3/webdriver-bidi-burikaigi2025

今回は 2025 年の WebDriver BiDi の動向として

• 仕様についてどう言った議論があったか
• 各ブラウザベンダーの実装状況
• ブラウザツールの対応状況

をふりかえり、2026 年の WebDriver BiDi がどうなっていくのかを予想します。

ブレットボードで回路を組んだり、はんだ付けをしたり電子工作に慣れてくると基板を作りたくなりませんか？なりますよね。
JLCPCB を初めとした安価な中国メーカーの誕生により以前よりも基板を作るハードルはグッと下がりました。

しかしブレットボードやユニバーサル基板で試作した回路を実際どうやって基板にするかわからない方も多いことでしょう。
このセッションでは Kicad を使い、カンファレンスや勉強会などで使えるような名刺基板を作って発注するところまでを解説をしながら行います。

このセッションを聞けばすぐに皆さんも基板を作ることができるようになるでしょう。
ぜひ自分だけの基板を作ってTinyGoで遊んでみませんか。

想定する参加者層

・ 電子工作が好き、興味がある方
・ 基板を作ってみたい
・ もの作りが好き
・ TinyGoに興味がある方

Javaで外部デバイスを直接制御する―
かつてそれは、JNI（Java Native Interface）による煩雑な連携とJVM外でのメモリ管理が必要で、できれば避けて通りたい領域でした。
しかし、Java 22で正式に導入されたFFM API（Foreign Function & Memory API） によって状況は大きく変わりました。

FFM APIは、Javaからネイティブ関数や外部メモリを安全かつ効率的に扱うための新しい標準APIです。
MemorySegmentやLinkerといった抽象化を通じて、JNIのようなヘッダ生成やネイティブラッパー無しで、Cの関数ポインタや構造体を安全に操作できます。
JDK標準として提供されるため、追加ライブラリに依存せずポータブルなコードを書くことが可能です。
本セッションでは、FFM APIを活用して Cライブラリやデバイス制御をJavaから安全かつ簡潔に扱う方法 を解説します。
簡単な電子工作を題材に、JNIとの違い、FFM APIの基本的な構造、メモリ管理モデル、そして実際のコード例を交えながら、Javaがネイティブの世界とどう橋渡しできるのかを紹介します。

想定する参加者層

Javaの最新動向に興味があって、Javaでいろんなことがしてみたい人。
電子回路は最低限しか扱わないので電子工作未経験でも大丈夫です。

テーマ

Javaもどんどん進化してるということを見てもらいたい

概要

タイトルを見て「本当ですか？」と思われるかもしれません。事実、2024年まで登壇活動はおろか社外コミュニティへの参加はほとんど行っておりませんでした。そんな経歴の私ですが、2025年（10月時点）では社外登壇数４０件超を達成しています。今回のセッションでは「未経験でも（頑張れば）私と同じペースでアウトプットできる方法」について紹介したいと思います。

聴講者に持ち帰ってもらいたいこと

1. 一見無謀なアウトプット目標であっても工夫と努力で達成可能
2. 登壇活動を行っている方は特別な方ではない
3. 社外発信の種は周りにいくらでもある

対象聴講者

1. 技術イベントに参加しているが登壇活動を行ったことがない方
2. 登壇にチャレンジしたいがハードルの高さを感じている方
3. 定期的に登壇活動を行っているが発表ネタにマンネリ感を感じている方

セッションの流れ

はじめに（5分）

自己紹介、2024年まで発信活動について紹介します。本セクションではエンジニアとしてのキャリアスタートから登壇活動を全く行っていなかった2024年10月までをふりかえります。

登壇に目覚めたきっかけ（10分）

登壇活動を始めたきっかけ、登壇したことで得られた体験について紹介します。私が登壇活動に初めてチャレンジしたのは2024年11月に開催されたAWSコミュニティ（JAWS-UG Education支部）でした。社内でも講師として人前で発表する機会は比較的多くありましたが、社外での登壇は初めてでした。今までの社内での発表と違い、「短い時間で自分の想いを伝える」ことに非常に苦労しました。本セクションでは「はじめての登壇経験を通じて失敗したこと、失敗から得た体験」について紹介したいと考えています。

年間40件以上登壇してみて（10分）

2024年11月の初登壇から今までの登壇遍歴、登壇活動を通じて見えたナレッジについて紹介します。最初の数か月は月に1件程度登壇するのがやっとでした。そのうえで、月に2~3件登壇するために必要なアクションについて模索していました。模索する中で「多くの登壇数をこなしている方の共通項」について見出すことが出来ました。結果として、多い時には月8件以上の登壇活動を実現することが出来ました。本セクションでは未経験者でも頑張れば継続的に月2～3件以上登壇するためのポイントについて紹介したいと考えています。

まとめ（5分）

本セッションのまとめ、聴講者へ持ち帰ってもらいたいことについて紹介します。社外発信を行うなかで「人前で話せる経験なんて無い」といった不安があると思います。初登壇する前は私も同じように考えていました。登壇活動を行っていくなかで、「誰もが登壇するためのネタはある、気づいていないだけ」という事実に気づきました。本セクションでは、聴講者がこれから登壇活動してもらうための後押しにつながる話を行いたいと考えています。

プログラムを書いたり文章を入力したりする際に欠かせないキーボード。
その中には、スイッチやキーキャップなどのパーツを自分で選び、好みの打鍵感やレイアウトを追求する自作キーボードという世界があります。

自作キーボードのファームウェアは、従来は C 言語で書かれることがほとんどでした。
しかし、 Go 言語で書けるとしたらどうでしょうか？

このトークでは、組込環境で使える Go である TinyGo を使って、自作キーボードのファームウェアを作る過程を紹介します。

• 自作キーボードを作るために必要な要素
• TinyGo を選択した理由と、そのメリット
• TinyGo で実際に開発する際の流れ

さらに、セッション後半ではライブコーディングを行い、 TinyGo でシンプルなキーボードファームウェアを一から作るデモを行います。

具体的には、キー入力、レイヤー機能、 USB HID 出力を最小構成で実装します。
Go でこんなに簡単にキーボードが作れるのか、という体験をお届けします。

厳しい現実のクラウドインフラに遭遇したことはありますか？ぼくはあります。

誰もわからない全貌、オフショアメンバーしか入り方を知らないサーバー、本番しかない環境、デプロイはもちろんぬくもりある手動、ユーザーからの問い合わせでわかる機能停止、・・・

とある急成長企業のSRE支援に入った自分は、この状況からの改善に取り組みました。
スタートダッシュで試用を数日で終わりと言わせ半月後には本契約を取り、未知のサーバーを見つけては構成図に落とし込み、通信を洗い出し、一方でガラ空きのポートを塞ぐなど、１つ１つカオスを潰す日々を過ごしました。

前任の会社が実現できなかった、本番環境からステージング環境を作ることも、不完全ながらある程度成功し、CI/CD整備やIaC化に着手できる地点まで数ヶ月というスピードで進めました。
が、そのくらいで突然告げられた「契約終了」。

こんなことある？

あれからまだ４ヶ月。もう４ヶ月。あれどうなったんだろうな？と思いたまーに様子を見ると、LP(Landing Page)はこれまで通りにあって、しかし10/31には終わることがわかっている。風の便りで。

このトークでは、この現場で自分が感じ・学び・向き合っていたさまざまなカオスと対応を、成長とともに呼び名を変える鰤になぞらえて物語的に語ってみたいと思います。
途中で終わりにせざるを得なくなった時に感じた諸行無常と共に。

概要
みなさん、エンジニアになったばかりの頃の気持ち、覚えていますか？
日々の開発に追われ、いつの間にか仕事の楽しさや「手触り感」を見失っていませんか？
このトークでは、安定した公務員という“養殖場”を飛び出し、エンジニアという大海原にやってきた僕が、エンジニアになって1年半、この世界でどう泳いで、どうもがいて、どんな楽しさを発見してきたかお話しします。
自分のコードが世界を動かす手応え、お客様との対話、チームで大きな壁を越えるスリル。
僕の回遊の物語を通じて、「あ、だからこの仕事は面白いんだ！」と皆さんの日常にある輝きを再発見してもらえたら嬉しいです！

話すこと
なぜ安定の“養殖場”を飛び出したのか？
大海原で見つけた、エンジニアという仕事の楽しさ
バブルに乗った僕が辿り着いた、最高の「結果」とは

対象者
エンジニアという仕事の楽しさを改めて感じたい方
“養殖場”育ちのエンジニアが、どんな泳ぎ方をしているのか興味がある方

テーマ

例外とResult型の解説、エラーハンドリング設計

想定する参加者層

例外処理やエラーハンドリングについて関心がある初級〜中級の開発者

トーク概要

例外処理は、単なるコード上の仕組みではなく “失敗とどう向き合うか” を決める設計上の意思決定です。
エラー対応が「起きた後の対処」だけに偏ると、再発と手戻りは減りません。

Result型は、失敗の可能性を型で表し、例外に頼らずエラーを設計する手法です。
これにより、エラーの種類や処理責任が明確になり、設計の一貫性を保ちながら保守性を高められます。

本セッションでは、例外（try-catch）を用いる言語のプロジェクトにResult型を取り入れる設計方法を紹介します。
実務での知見を踏まえ、例外の扱いをより明確にし、エラー処理を改善するためのヒントと指針をお持ち帰りください！

概要

3年目の新人エンジニアとして入社2週間で、2.5ヶ月以内の採用管理ツール（ATS）のMVP開発を一人で任されました。
既存SaaSの上に Next.js + Hono + AWS Lambda で構築し、DDDを前提に拡張可能な設計を担当。
要件定義は済んだ状態で引き継いだものの、ページデザイン未定、外部連携（A社は運用まで6週間かつ要運用実績、B社は連絡不通）など不確実性が多く、仕様確定を待たずに進める必要がありました。
既存コードのキャッチアップから設計・実装まで、短期間で並走させるために取った「考え方」と「進め方」を実体験ベースで共有します。

想定ターゲット

• 新しいプロジェクトを中途参入または単独で引き継ぐエンジニア
• 要件定義後のフェーズから設計・実装を任される中堅層（2〜5年目）
• スタートアップや小規模チームで、不確実性の高いMVP開発に関わるエンジニア
• “設計の理想と現実的な進め方”の調和方法を模索している方

数理最適化は、物流ルートの最適化やシフトの最適化などに活用される、数学の応用分野の一つです。

世間では Python による実装が標準ですが、ここは、あえて Go 言語で解きながら、Step by step で解説します

https://qiita.com/ysaito8015@github/items/087e11b940d64731b816

AI時代の今、あえて「ライブラリを使い倒す」経験は必要なのか？

キャッチコピー: バイブコーディングが教えてくれないこと 〜なぜ私はReact Hook Formに“育てられた”のか〜

ターゲット: AIコーディングに慣れ始めた若手・中堅エンジニア、技術選定を行うテックリード

概要:

（導入）昨今の開発はAIアシスタントの登場で劇的に変化した。「バイブコーディング」でそれなりの実装が瞬時に手に入る。

（過去）しかし、私（発表者）が学んだ時代は違った。特にフロントエンドは「正解」がなく、React Hook FormやFullCalendarのような複雑なライブラリを、文字通り「片っ端から試し」ながら使い倒す必要があった。

（対比）この「使い倒す」泥臭い経験は、単にライブラリの使い方を覚えるだけでなく、「なぜこのAPI設計なのか」「状態管理のどのパターンが最適か」といった実装の裏にある『Why』を深く理解するプロセスだった。

（問い）AIが最適なコードを提示してくれる今、この「苦しみながら使い倒す」経験は不要になったのか？ AIが提示するコードの「意味」を真に理解できているか？

（結論）「使い倒した」経験こそが、AIの出力を鵜呑みにせず、より良い設計を判断・選択できるエンジニアの「幹」となる。バイブコーディングの時代だからこそ、意識的に「使い倒す」経験が重要である。

みなさん好きなスポーツはありますか？
そのスポーツの放送をDXしたいと思ったことはありませんか？
デジタルのデータを使って、その情報を即時でTV画面にプロットできたら、さらに放送やスポーツ観戦が盛り上がると思いませんか？

JavaScript（＋Vue.js）とCanvas、Chromeを使って実際のTV放映で使われている字幕の自動生成について解説いたします。

今回は単なる表示だけではなく、サイクルロードレースの場合をベースに、どのように元のデータを引っ張ってくるのか？PCと放送機材のつなぎ込み方、実際に使用している機材の紹介まで、細かすぎて伝わらない粒度と、そのスポーツへの熱量でオーバーエンジニアリングした記録をお話いたします。

こんなお話をします。

• どんな画面構成？
• どんな機材を使うの？
• どんなJSを書いているの？
• 競技センサーからデータを取得する手法の歴史
• レースの残り距離を表示するための仕組み
• 選手の位置情報はどう取得する？

キャリアの話は、働く人にとって最も重要な事柄の1つにも関わらず、あまり公には話されません。
一方、思い通りの仕事をしたり、希望するロールにたどり着けるのは一握りの人です。

思い通りのキャリアを歩むには社内政治や転職が必要なのでしょうか？
はたまた計画的偶発性理論？セルフブランディング？

継続的なアウトプットをしつつ、コミュニティの運営・裏方も担当し、採用担当もするKaitouが、着実に自分の思い描くキャリアに近づくための「アウトプット」についてお話いたします。

こんな方に聞いて欲しい！

• キャリアについて考えたことがない方
• キャリアについて迷っている方
• キャリアを上手く歩めていないと感じている方
• アウトプットに勇気が出ない方
• アプトプットをついついサボってしまう方
• 若手や部下にアウトプットしてもらいたいけれど、なかなかしてもらえなくて困っている方
• 面白おかしくキャリアップしたい方

テーマ

ドメインイベント導入と責務分離の実践

想定する参加者層

保守・機能追加で副作用や依存の整理に悩む初級〜中級の開発者

トーク概要

ドメインイベント、使っていますか？
これは、注文完了やユーザー登録などビジネス上の“出来事”を表すモデルです。
状態変化を出来事として切り出すことで、副作用が見える場所にまとまり、設計の見通しが良くなります。

本セッションでは、既存コードに潜むイベントの見つけ方から始めて、責務分離から非同期処理への段階的なリファクタリング手順を紹介します。
小さな一歩から始められる実践に絞るので、無理なく取り入れられます。
ぜひ「あ、こう設計すればいいのか」という発見を持ち帰ってください！

近年のWindows OSに実装されているデバッグ機能について解説します。デバッグは、ソフトウェア開発者がプログラムの複愛を特定したり、動作を確認したりするための一般的な動的解析技術であり、その特性から近年ではサイバーセキュリティでの問題分析や攻撃検知にも活用されています。Windows OSでの動的デバッグに用いられるソフトウェアとしてはWinDbgが広く知られていますが、Windows OS自体にもプログラムの動的解析を支える複数の機能が実装されています。本講演では、Windows OS自体に実装されている動的解析を支援する機能の中から、いくつかの機能に焦点を当てて、デモンストレーションを交えて解説します。