プロポーザル

Bunでバックエンドを構築する際、可観測性確保のためにDatadog APMを導入しました。
dd-trace ライブラリはBunを正式サポートしていませんが、工夫次第で本番環境での運用が可能です。

実際に導入を進める中で、スパンは取得できるものの、スパンが関連付けされず、トレースとしてまとまらない問題に直面しました。
Node.jsでは自動で行われるリクエストコンテキストの伝播が、BunとHonoの組み合わせでは効かないことが原因でした。

本セッションでは、この問題の「なぜ」を技術的に深掘りします。
Node.jsでの自動計装の内部メカニズム(モジュールパッチング、AsyncLocalStorageによるコンテキスト管理)を解説し、Bunとの違いがどう影響するかを分析します。
また、Bunでもdd-traceサポートの対応がなされていますが、何をカバーし、何が不足していたのかも明らかにした上で、解決策を紹介します。

対象者: BunやHonoに興味がある方、APM導入を検討している方、ランタイムの内部動作や自動計装の仕組みに関心がある方

エンジニアは技術的負債、レガシーコードの刷新、そしてリポジトリの統合といった、避けては通れない大規模なリファクタリング課題に直面します。

私はMOSHというクリエイター向けプラットフォームの開発において、8年近く運用されてきた（自らが積み上げた）負債「旧リポジトリ」の撲滅という大きな挑戦に直面しました。

膨大なコード量、複雑に絡み合った依存関係、そして不足したドキュメント。
従来の手法では数年かかると思われた作業を、AI（Claude + Cursor）とのペアプログラミングによって約100日で完遂しました。

この取り組みを通じて、「AIは単なる補助ツールではなく、最高のペアプログラミングパートナーであり、心の友である」という確信を得ました。

本セッションでは、AIの活用術ではなく、私がなぜ「旧リポジトリからもう逃げない」と決めたのか。

AIという存在がそれを可能にしてくれたわけですが、なぜその意思決定をすることができたのか。

10年近く前のコードに対する私の恐怖をどう変えたのか。

実コードと実データ、そして率直な失敗談を交えて語ります。

レガシーコードから目を背けてきたエンジニア、技術的負債の返済を諦めかけているチーム、そしてAIが開発組織の意思決定をどう変えるのか知りたいリーダーにとって、明日からの判断基準を変える内容を提供します。

UIライブラリは入れ替わりが早い一方で導入後はコンポーネント構造やテーマ設計・CSSトークン・A11y実装などがライブラリ側で固定化されやすく、結果としてロックインが生じやすいです。
本セッションではその前提を踏まえつつ、いま shadcn-ui をどのように評価し、ロックイン等のリスクと向き合うべきなのかを考えます。

発表内容

• UIライブラリのこれまで、選定基準など
• shadcn-uiを選ぶ理由と評価ポイント
  • コピー所有でロックイン低減、RadixベースのA11y、他ライブラリとの親和性
• 現場で見えた限界と対処
  • classNameによる意図せぬ拡張、改修時のルールの整備

エンジニアは新規技術の採用や組織課題など、さまざまな問題に直面します。

私は LINE API を利用した新規プロダクト開発や技術組織の拡大に伴う課題に直面した際、LINE Developers Community や EM Oasis といったコミュニティに参加することで活路を見出してきました。
そして、活動は課題解決に留まらず、現在は LINE API Expert としての初学者支援や EM Oasis の運営という形で、コミュニティへ貢献する活動へと繋がっています。

これらの経験は、「コミュニティがエンジニアの成長と課題解決に極めて有効である」という確信を与えてくれました。

本セッションでは、この実体験に基づき、以下の実践的なプロセスと技術を解説します。

• 課題発生から解決の糸口を見つけるまでのプロセス
• コミュニティ内で信頼を得て、より深い情報を得るための技術
• インプットをアウトプットに繋げ、自身の専門性を確立する方法

私がなぜ技術的な課題に直面した際にコミュニティに参加をするのか、私はなぜ課題が解決した今でもコミュニティ活動を続けているのか、LINE API Expert や EM Oasis 運営の活動を通して何を感じているのか、実体験を元にコミュニティ活動の素晴らしさを語りたいと考えています！

技術コミュニティへの参加を検討している方、また既に参加しているがより効果的に活用したい方にとって、具体的な行動指針となる内容を提供します。

私たちは常日頃からありとあらゆるエラーメッセージと向き合っています。ソフトウェアエンジニアに限った話で言えば、コンパイラや言語処理系のエラーメッセージは最も頻繁に向き合うインターフェースの一つであり、毎日眺め、頭を悩ませていることでしょう。
そういった中で、Rustコンパイラ(rustc)はわかりやすいエラーメッセージ(diagnostics)を出すことに注力しています。そして、そのエラーメッセージは一つひとつが丁寧に設計され、コードレビューで磨かれ、ユーザーフィードバックにより改善されています。

わかりやすいエラーメッセージとはどういったものなのか。どのように実装、改善されているのか。どのように開発者体験、あるいはユーザー体験を向上させているのか。
このセッションではRustコンパイラへのコントリビューションで得た経験をもとにして、Rustコンパイラで行われているエラーメッセージの実装・改善活動を例に、わかりやすいエラーメッセージのあり方などについてご紹介します。

ここではRustやコンパイラを題材としますが、これらへの深い造詣は必要ありません。
Rustコンパイラの開発がどのように行われているのかといったOSS開発に関する知見だけでなく、日頃の開発においてエラーメッセージを通して開発者・ユーザー体験を向上させるテクニックや考え方をご紹介できる内容を目指します。

メンテナンスされ続けるStorybook運用を目標に、設計と運用の要点を共有します。
Coding Agentに「作成・更新・整理」といった負荷の高い作業を委ね、速度と品質の両立をねらう取り組みを紹介します。
本テーマは実装の細部ではなく、意思決定の拠り所となる原則にフォーカスします。

発表内容

• AIに委ねる範囲・人が握る範囲の定義（境界設計・責務分離）
• 実装ガイドラインのガードレール設計
  • ファイル配置・命名、Storyの分割設計、バリエーションの整理、Controlの方針
• 小さく導入してから段階的に適用領域を拡大する進め方
• 運用コストの削減、変更の見通しとレビュー品質の維持、チームの開発速度確保

YoY300%成長のクリエイター向けオールインワンプラットフォームの成長に伴い、複数プロダクトでの通知機能共通化が急務となりました。
メール・LINE・アプリ内通知を統一基盤として提供しつつ、将来の事業拡大を見据えた拡張性と、ミッションクリティカルな通知の確実な配信を両立する必要がありました。

本セッションでは最終的なインフラ・アーキテクチャ構成を共有したのち、その設計の過程でどのような制約や判断軸の中で候補として上がった技術について触れてなぜそれを採用しなかったのかという生々しい設計のリアル話をお伝えるすることが出来ます。
作成した成果物やその結果を伝えるセッションではなく、そこに至る技術的な判断や思考をみなさんに共有して今後の設計に役立つようなものにしたいと考えております！

主な内容

マルチプロダクト戦略での基盤設計思想

• なぜ通知を共通化したのか、将来を見据えた設計判断
• 今後様々なプロダクトが利用することを考慮した責務の分離とインターフェイスの設計についてどう考えたか

技術スタック選定

• StepFunctions vs SQS/SNS vs Fluent での可用性・柔軟性・一覧性との比較
• DynamoDB vs RDS vs Redis - 冪等性におけるデータストアの検討
• TypeScript統一による認知負荷軽減の判断

冪等性設計の技術判断

• DynamoDB条件付き書き込みによる排他制御の選択理由

聴講者が得られる価値

• マルチプロダクト環境での共通基盤設計における技術選定の判断基準
• 高可用性システムでの冪等性実装における具体的な技術選択肢と評価軸
• 将来の拡張性と現在の要件のバランスを取る設計判断の考え方

PoC段階では新技術を使って、楽しいですが本番運用するにはPoCとは違って考えることがたくさんあります。
AI関連の話が乱雑になっていてたくさんの会社でPoCを開始していると思うので、決め手となるのは本番運用に載せたときのメリットデメリットの話だとおもっていますので、今一度基本に戻ってはいかがでしょうか？っということで話そうと思います。

■概要
生成AIの台頭により、GitHub Copilot（GHCP）の企業活用が急増しています。Copilotをセキュアかつ組織統制下で活かすには、その基盤となる GitHub Enterprise Cloud（GHEC）の整備が実質的に必須です。
現場では「試用 → 本番」や「通常アカウント → EMU（Enterprise Managed Users）」への段階移行が増加中。本セッションでは、実案件およびコミュニティでの知見（※GitHub Stars受賞者としての最新動向も踏まえ）から、GEI / GitHub Migration Analyzer / gh-repo-stats等の実運用ノウハウを整理します。
“移せる／移せない”の線引き、ガバナンスを崩さないCopilot活用の判断軸、スモールスタートの実例まで、明日から使えるチェックリストとともに解説します。

■こんな人におすすめ
・企業内でGitHub導入・統合・再編をリードするDevOps／プラットフォーム担当
・既存GitHub資産を落とさず移行したい技術責任者・PM
・Copilot導入を見据え、まず基盤とガバナンスを整えたい方

■前提知識
・GitHub Enterpriseの基本概念（Org／Repo／Teams／Policies）の基礎理解（薄くでOK）
・IaCやCI/CDの一般知識があると理解が早い（なくても可）

■持ち帰れること
・「計画 → 解析 → 検証 → 本番」の実務フレーム＆チェックリスト
・GEI／Migration Analyzer／gh-repo-statsの使いどころと限界
・“移せないもの”の代表例と代替策（再作成・自動化・割り切りの判断）
・EMU移行時のセキュリティ／ガバナンス観点（ID、監査、ポリシー）の勘所

■発表者プロフィール（短）
外資系コンサルのDevOpsエンジニア／マネージャー。GitHub Stars。GitHub Enterprise／EMUの導入・統合・運用、Copilot展開、監査ログ連携やセキュリティ統制の実装支援に従事。

『薬屋のひとりごと』（以下「薬屋」）に出てくる主人公・猫猫（まおまお）の問題解決の進め方をヒントに、システム障害対応を分かりやすく整理したものです。

薬屋は、薬の知識を持つ少女が後宮で起きる毒や病の理由を探る物語です。やっていることは「状態を観察→原因候補を考える→確かめる→再発を防ぐ」で、これはまさにシステム障害対応と同じ流れです。
猫猫のやり方に当てはめてシステム障害を解決に導く流れを楽しく学んでいきましょう。

なお、原著作物のストーリーや独自文章などに配慮して特定のシーンは扱いません。アニメなどを視聴した前提での話とさせていただきます。

ITエンジニアとしてのキャリアは、技術スキルだけでなく「どんな選択をするか」によって大きく形が変わっていきます。
どの技術を学ぶか、どんなコミュニティに飛び込むか、そしてチャンスが目の前に来たときに一歩踏み出すかどうか。
その一つひとつの選択が、自分のキャリアを作り上げていきます。

私は、Microsoft技術との出会いをきっかけにキャリアが大きく動き出しました。
コミュニティでの学びや仲間との交流が新たな視野を開き、Microsoft MVPを受賞することで次の扉が開きました。
そこからさらに挑戦を続け、現在はアバナード株式会社でDirectorという立場に至っています。

このセッションでは、私がどのように選択を重ね、どのような失敗や葛藤を経てチャンスを掴んできたのかを、リアルな体験談としてお伝えします。
いつもは.NETやMS技術系のテーマでしたが、今年は自身のふりかえりをかねてソフトスキル系のお話をさせていただこうかと思います。
エンジニアとして成長の道を模索している方、次のキャリアステップを考えている方に、キャリアを切り拓くための「勇気」と「ヒント」を持ち帰っていただければと思います。

BuriKaigi 2025では「2024年のWebフロントエンドのふりかえりと2025年」について話しました。
https://www.docswell.com/s/sakito/Z82RGP-burikaigi2025

話の中では、2025年のフロントエンドはどうなっていきそうかの推測もしていました。

今回は2024年の推測が当たっていたのか、2025年を振り返りつつ話をします。
そして、2026年のフロントエンドがどうなっていくのかも考察していきます。

■テーマ
バグバッシュを「品質保証」「学習」「共通理解」を同時に生む場として用意し、開発者がリリース対象機能を必ず自分の手で操作してから出す運用を紹介します。
不具合発見に留めず、多職種が操作を共有しながら触ることで、仕様意図・前提のズレをその場で解消し、プロダクト理解とチームの合意形成を加速させます。

■想定する参加者層
初心者向け

■トーク概要
バグバッシュ（Bug Bash）とは、プロダクトの品質向上のため、職種を問わずチームメンバーが集合して、指定期間内に意図的にバグ（不具合）を見つけ出すイベントです
本LTは、バグバッシュを「品質保証」「学習」「共通理解」を同時に生むイベントとして定義します。
開発者・プロダクトオーナーなど異なる役割が一堂に会し、実際にプロダクトを発話しながら操作することで、仕様意図や前提のズレをその場で解消し、個人に依存しない検出力と“使われ方”の相互学習を生み出します。
さらに、開発メンバーがリリース対象機能を必ず自分の手で操作してから出す運用をリリースゲートとして組み込みます。
これにより当事者意識とUX理解が開発プロセスに定着し、「納得して出す」文化が醸成されます。
鰤が群れで回遊して身を太らせるように、プロダクトも群れ（多職種）と手触り（ハンズオン）で育つ。
その設計と運営の要点と実践内容を共有します。
「プロダクトを育てる」ことに真正面から向き合うチームに向けた実践です。

ローコードやノーコードサービスが台頭して久しい昨今、組織によっては、様々なローコードやノーコードのサービスが統制なく使われているといった現状も存在します。
そんな折、
「どちらがいいのか？」「どちらかに寄せるべきなのか？」
と、聞かれることがよくあります。

ここでは、Microsoft 365 を主軸に活用しつつも、Power Platform と kintone が混在する組織の中で、どういう構成であれば最適な組み合わせとなりうるのか、ロールプレイング的なセッションとして、デモを交えながら解説していきます。

※本内容は Cybozu Day 2025 で軽くお見せする内容をもっと深堀した内容となっています。
※本内容は業務担当者や開発者、DX推進者など幅広い層に見ていただける内容です。