トーク

30代後半になって、漠然とした不安を感じていませんか？「5年後どうなってるんだろう」「40歳で市場に出たとき、誰？って言われそう」「何から始めればいいか分からない」——私もそうでした。
転職ドラフトのデータを見ると、ミドル層を取り巻く環境は年々厳しくなっています。でも、不安の正体が分からないから動けない。そんな状態が続いていました。
試しに自社サービスでレジュメを書いてみたら、「キャリアビジョン」が全然書けない。そこでAIに高評価レジュメを分析させたところ、ビジョンには6つの型があることを発見。自分の型が分かったら、少しだけ前に進めました。

ミドル層のキャリア不安、一緒に整理してみませんか？

現在AIを基盤とした様々な製品、サービスがありますが、IDEメーカーとして人気のJetBrainsのAIツールにどのような特色があるのか紹介します。

JavaScriptのビルドツールはnode.jsで実装されることが多かったですが、この数年で状況が変わってきました。
rustやgolangベースで開発されたビルドツールが生まれるようになってきています。
今回の発表ではHelpfeelで実際に採用したツールの置き換えとどれくらい高速化されたのかをお伝えします。
また2026年に実施しようとしているビルドの高速化の調査も発表します。
置き換え自体は比較容易に行えるものが多いので、あなたの開発もツールを置き換えるとビルドの高速化の恩恵を受けることができるかもしれません。

ありそうでなかったライブラリ型動的ローコードエンジン Codeer.LowCode.Blazor のご紹介です。リリースから1年半、パッケージアプリ開発や社内システムで利用していただいています。いずれも低コスト・短納期・高品質な開発を実現しています。ローコードとBlazorフルスクラッチのハイブリッドな開発は開発者の私も驚くほどの可能性を秘めていました。今回は実例も交えてそのポイントをお話します。

・動的ローコードエンジンの威力
・Blazorのフルスクラッチとのシームレスな連携
・Blazorの既存ライブラリとの組み合わせ
・既存アプリケーションのモダナイズ
・社内アプリ開発における開発サイクルと、運用開始後のローコード調整
・パッケージアプリにおけるローコードカスタマイズ

TechTrainでCSとして働く中で、エンジニアとのやり取りやGitHubの読み込みを通じて、その魅力を言語化してきました。
多方面でエンジニアの推し活を続けるうちに、いつの間にかDevRelと呼ばれる役割を担うようになっていました。

本トークでは、技術者出身ではない私から見えたエンジニアとの関わり方をお話しします。
本トークを通して、私が関わっているTechTrainにも、少しでも興味を持っていただけたら嬉しいです。

寒い冬なので暑い夏の話をします！
サイボウズでは、夏に多くの社員が集まりブログ記事を怒涛のように投稿する夏フェス「CYBOZU SUMMER BLOG FES」を2024年から毎年開催しています。
今年はおよそ120記事が投稿され、投稿した社員数も今年は100人を超えました。
ここでは、サイボウズの発信文化を象徴するこの祭の概要と、その運営の裏側を簡単に紹介します。
アドベントカレンダーもいいけど、記事が埋もれにくい夏の季節に「フェス」をやる選択肢を皆さんにお届け！

本 LT では、toB と toC で求められるフロントエンドエンジニアリングの勘所の違いについて、実際の事業開発の現場で得た経験をもとに整理し、再現性のある学びとして共有します。
フロントエンドエンジニアは、UI 実装や技術選定だけでなくプロダクトの価値をユーザーに届けるための「最後の砦」としての役割を担います。しかし、その「価値」の定義は toB と toC で大きく異なります。toC では「多くのユーザーにどう魅力的に届けるか」が重視される一方で、toB では「限られたユーザーが日々の業務をいかに速く・正確にこなせるか」が価値の中心になります。
発表者はサイバーエージェントに新卒で入社し、フロントエンドエンジニアとして約 10 年間異なる性質を持つ複数の事業部で開発に携わってきました。
サイバーエージェントには大きく分けて以下の 3 つの事業領域があり、発表者はそのすべてに所属・関与した経験があります。

・ゲーム事業部
主に toC 向けのスマートフォンゲームを中心とした事業領域です。
フロントエンドとしては、ゲームのプロモーション用 LP の制作や、ゲーム内のお知らせ・イベント告知画面などを Web ページとして実装するケースが多くあります。特にゲーム内お知らせ画面などは緊急対応としてプランナー等非エンジニアが直接編集するケースなどもあります。
この領域では、短期間での大量リリースやキャンペーン単位での開発、タイトルごとのビジュアル的な細かいチューニングが求められるため、「スピード」「表現力」「運用のしやすさ」が重要になります。
多少の技術的負債よりも、ユーザー体験やタイミングを優先する判断が正解になる場面も多く、toC フロントエンド特有の意思決定が求められます。

・メディア事業部
ブログ、ニュース、動画配信サービスなど、Web を中心にプロダクトを展開する事業領域です。
SEO、パフォーマンス、アクセシビリティ、長期運用を前提とした設計などが重要になり、「作って終わり」ではなく「育て続けるフロントエンド」が求められます。
ユーザー数が非常に多いため、小さな実装ミスや設計判断がパフォーマンス低下や UX の悪化として顕在化しやすく、安定性と継続的改善のバランス感覚が重要になります。
その他にも動画配信の知識なども必要になるケースがあり、フロントエンドエンジニアとしては最も深い専門性を求められるかもしれません。

・広告事業部
インターネット広告配信を主軸としつつ、広告主や代理店向けの toB プロダクト（管理画面、分析ツール、運用支援ツールなど）を数多く手がけている事業領域です。
この領域のフロントエンドでは、見た目の派手さよりも堅牢性・拡張性・保守性・ドメイン理解に加え、使いやすさや作業工数の簡略化が強く求められます。
利用者は日常業務として長時間ツールを使い続けるため、UI のわずかな使いづらさや操作ステップの多さが直接的に業務コストの増加につながります。そのため、「正しく動く」だけでなく、「迷わず使える」「無駄な操作を減らす」ことがフロントエンドの重要な価値になります。

本 LT では、こうした前提をもとに、
・toB / toC でフロントエンドに期待される役割の違い
・技術選定や設計における「優先順位の変え方」
・UI / UX を考える際の視点の切り替え方
・事業が変わっても応用できるフロントエンドエンジニアの思考法
といった点を整理してお話しします。

特定のフレームワークやライブラリの解説に留まらず、「なぜその判断が必要だったのか」「別の事業だったらどう判断が変わるのか」という背景や考え方を共有することで、参加者が自身の現場に持ち帰って応用できる学びを提供することを目的としています。
toC プロダクトに携わっている方が toB 開発に関わる際の心構えとして、また toB プロダクトに携わる方が toC 的なスピード感や割り切りを理解するためのヒントとして、本 LT が役立つことを目指します。

コンパイルエラー、あまり読みたくないですね。説明してほしい。そして、できれば元気に説明してほしい。
もちろん、最近のAIを使えば解説してくれます。
でも、そういったAIには課金か大きいモデルを動かせるハードウェアが必要です。毎日何万回も出すコンパイルエラーをそのたびに課金していたら破産してしまいますね。大きいモデルを動かす環境を用意するのも大変です。
そこで、小さいサイズのLLMをファインチューンして、コンパイルエラー説明専用のLLMを作れば、手元のパソコンでいくらでもコンパイルエラーを説明してくれるはずです。
ファインチューンにはデータセットが必要です。しかし元気にコンパイルエラーを説明するデータセットなんかありません。
このセッションでは、そんなファインチューンのためのデータセットの作成やファインチューンの方法を解説します。

昨年（2025）は、.NET 4.6.2 を .NET 4.8.1 に移行して延命するのか、あるいは別の道（段階移行やモダナイズ）を取るのか―「どこへ向かうべきか。課題は何か。」をディスカッションしました。

Part2の今回は、その続きです。方針は2025年中に決める。2026年はステップを踏んで、1年で移行を完了する。それを本気でやり切るための話をします。

レガシー環境の困りごとは分かっているのに、移行が進まない理由はだいたい似ています。
「止められない」「怖い」「どこから触ればいいか分からない」―そして気づくと、また来年。

そこで本セッションでは、2025の分岐（4.8.1に上げる／別ルート）で整理した論点を踏まえつつ、2026にやることを “迷わない順番” に並べます。
移行を“壮大な理想”ではなく、1年で完走できるプロジェクトとして成立させるために、スコープの切り方、段階移行の組み方、品質の担保、切替の現実解まで、スポンサーセッションらしくテンポよく共有します。

個人開発では、利用するサービスは責任も軽い分、気軽に選べますが会社組織として採用するサービスは関係者も多いことから 気軽に選ぶことは大変です。（メジャーで、有名なサービスだとしても です。)

当社が2025年の４月にサービスインしたテレビ電話サービス「memet」において採用したサービスの選定を例に、ソフトウェア開発者視点で どんなこと・ものを用意すれば ほかの会社に目が留まるようなサービスの提供ができそうか？ということをお話します。

今年度新たにリリースした位置情報チャットアプリ spotch（すぽっち）の開発のこれまでとこれからについて話します！

CData Softwareでは、SalesforceやSAP、kintoneなど各種SaaSのビジネスデータと連携可能なMCP Server・マネージドMCPプラットフォームを提供しています。
しかし、MCPを活用してAIをビジネスに取り入れようとしても、利用するAIプラットフォーム（Claude、Amazon Bedrock、Microsoft Foundry）やエージェントサービス、LLM、ノーコードツールによって、最適なアーキテクチャは異なります。「結局、自分たちの環境ではどう実装すればいいの？」という疑問をお持ちの方も多いのではないでしょうか。
本セッションでは、各AIプラットフォームごとのMCP活用パターンを整理し、すぐに実践で参考にしていただけるリファレンスアーキテクチャをまとめてご紹介します。

AI駆動開発によりコード生成量は飛躍的に増えましたが、その結果としてレビューや品質担保が人のボトルネックになりつつあります。本セッションでは、生産性ではなく生産量に着目し、AIコーディングエージェントが生み出す大量のコードをいかに制御し、信頼性・保守性を維持するかを整理します。
AIは増幅機であり、使い方次第で組織の課題も拡大します。レビューを前提とした開発フローの再設計と、AIコードレビューをガードレールとして活用する実践的なアプローチを紹介します。

2025年はさくらインターネットにとって大きな変革の年でした。そんなさくらインターネットの近況を2名のエバンジェリストがお伝えします。

・亀田リージョン：さくらのクラウドの今 ～ハイパースケーラと肩を並べることはできたのか？～
・法林リージョン：さくらのAIとかGPUとかイベントとか 〜2026年もバク進します！〜

2025年はプログラミングの姿がすっかり変わったことで記憶に残る年になりました。 2026年、AIを活用したソフトウェア開発はより大規模化していきます。プログラミングを超えて、ソフトウェアエンジニアリングが必要な領域です。しかし、これまでのソフトウェアエンジニアリングは「人間が設計し、実装する」ことを暗黙の前提としていました。その前提が変わるとソフトウェアエンジニアリングはどう変わるのでしょうか。このセッションでは、AIとの協業が前提の2026年のソフトウェアエンジニアリングを考えていきます。

BuriKaigi ならではの「技術の旬」を楽しく理解できるセッションです。前菜は、業務を分解して繋ぐためのマルチエージェントオーケストレーションパターン。メインディッシュには、最新の Microsoft Agent Framework と Azure AI Foundry を中心に、 .NET 10 と Visual Studio 2026 / VS Code の新機能を添えます。デモを通じて、旬の技術を味わいながら AI エージェント設計開発の本質を楽しみましょう！

2026年1月9日か10日、その場で rails new してそのバージョンでライブコーディングします。
何を作るかはその場にいるみんなとノリで決めよう。

Webの縦書きについてご紹介します。

Webで縦書きをすることの意義について私が考えていること、
縦書きと横書きでは様々なことが異なっていて、ただ向きを変えるだけではないこと、
Webで縦書きを実現する現行の技術にはどのようなものがあるか、
縦書きを中心にしたWebサイトを構築しようとするとぶつかる困難と現状、
縦書きを取り巻く周辺状況、
をご紹介します。

Webの世界で縦書きができることと、それはとても日本語を扱う者にとってうれしいことであること、
そしてそれは日本語だけでなく、Webの世界にとっても、よいことなのだ、という主張をします。

Webフロントエンド領域に習熟する必要はなく、少しCSSの専門的な話をすることはありますが、すべて理解に十分な解説を付けます。

テーマ
体重、カロリー、歩数、アクティビティなどのヘルスケア由来の時系列データを分析し、データの不整合から真の問題を特定。記録の徹底と習慣化によって○○kg減量に成功した実践例を、技術的な分析手法とともに紹介します。

想定する参加者層
初心者〜中級者、データ分析に興味がある方、特別な前提知識は不要。ダイエットを始めようとしている方、健康診断の結果が気になる方

トーク概要
数年間で○○kg増えた体重。あすけんで記録したカロリーデータと、Apple Watchが記録した歩数・アクティビティデータは揃っていた。しかし分析してみると、記録されたカロリーでは体重が増えるはずがないという矛盾が浮かび上がった。
詳しく分析すると、いくつかの発見があった：

記録している期間は体重が減っている：カロリー記録がある期間をプロットすると右肩下がり
記録していない期間に体重が増えている：記録の空白期間と体重増加が相関
運動量の変化は体重にほとんど影響していない：歩数・アクティブカロリーと体重変化の相関が低い

この不整合から見えてきたのは、「記録していない日に高カロリーを摂取している」可能性。現在の体重が妥当だとすれば、問題は記録の抜け漏れにあることがわかった。
そこで徹底的に記録をつけるようにした結果、○○kg減量に成功。今度は食事記録とアクティビティデータが整合し、もっともらしい結果が得られた。人間行動心理学的にも、記録をつけることが習慣化を促すことは知られている。
このトークでは：

ヘルスケアデータの取得・可視化手法（Apple Watch、あすけんなどの連携）
時系列データ分析による不整合の発見プロセス
データから見えた「記録している時だけ痩せる」という真実
記録の徹底による習慣化と減量成功の実践例
エンジニアならではの「データドリブン」なダイエット戦略

を紹介します。
技術者として「測定できないものは改善できない」を体現し、データの嘘を見抜き、行動を変えた実体験です。結局、ダイエットは記録をサボらない自分との戦いでした。でも、そこにエンジニアリングで立ち向かいました。 健康が気になる方、データ分析を実生活に活かしたい方、ぜひご参加ください！

テーマ Google Apps Script, TypeScript, JavaScript
想定する参加者層 初学者から幅広く

内容
スプレッドシートをDBのように扱いたい時ありませんか？さらにこのDBから必要に応じて適当な情報を抜いたり差し込んだりしないといけない場合、GASを書いて自動化したくなるでしょう。
しかし、GASでスプレッドシートを操作するのは非常に面倒です。なぜならGASでデータを取得したい場合「このセル(あるいは行か列)からこのセルまでを数字で書かないといけない」ためです。増減するDBデータの中で対象データの行番号列番号位置を探し、データを抜いたり差し込んだりする手間のかかるコードを書かないといけません。
そこで私はORMのようにスプレッドシートを操作でき尚且つ、GASをローカルで開発できるツールを併用しJavaScriptだけではなくTypeScriptで開発できるライブラリを作ってみました！