プロポーザル

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が開発組織の意思決定をどう変えるのか知りたいリーダーにとって、明日からの判断基準を変える内容を提供します。

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

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

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

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

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

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

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

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

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

主な内容

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

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

技術スタック選定

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

冪等性設計の技術判断

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

聴講者が得られる価値

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

■概要
生成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展開、監査ログ連携やセキュリティ統制の実装支援に従事。