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開発の良さをお伝えできたらなと思います！

テーマ

React 19の楽観的更新で、日常のUIをもっと気持ちよく、操作体験を磨くヒントを届けます。
React 19の正式リリースから1年。
主要なライブラリやフレームワークでも対応が進み、今では実際のプロダクト開発でも十分に使える段階に入りました。

本セッションでは、React 19で追加された「新しいレンダリングの考え方」と「フック（useTransition / useOptimistic）」を活用し、「待たせない」「引っかからない」「自然に感じる」UI体験をどう実現できるのかを、実例を交えて紹介します。

非同期処理やサーバー通信が当たり前になった今、「読み込み中」「遅延」「再描画のちらつき」は避けられません。
しかし、React 19のuseTransitionやuseOptimisticを使えば、ユーザーに「遅れ」を感じさせないアプローチを実装できます。

フォーム送信、フィルタリングUI、ボタン操作など日常的なインタラクションを題材に、「技術でUXをなめらかにする」ための発想と実装パターンを一緒に探ります。

想定する参加者層

• Reactでの開発経験があるフロントエンドエンジニア
• React 19や新しいレンダリングの仕組みに興味がある方
• 「UXを良くしたいけど、どこから手をつけていいかわからない」方
• 理論よりも、現場で“手を動かして試したい”タイプの方

（主に初中級者〜中級者の現場エンジニアを想定）

トーク概要

React 19では、useTransitionやuseDeferredValueを使って「急ぎの更新」と「ゆっくりしてもいい更新」を分けることで、UIの引っかかりを減らす仕組みが整いました。
さらにuseOptimisticを組み合わせることで、サーバー応答を待たずにUIを「先に動かす」ことができます。
この「先回りするUI」は、ユーザーに「軽快でスムーズな操作感」を与える鍵になります。
正式リリースから1年が経過した今、これらの機能は既に安定しており、Next.jsやReactRouter（Remix）などの主要フレームワークでも標準的に採用されています。

つまり、「もう試す段階ではなく、使いこなす段階」です。

本トークでは以下の3つのテーマを中心に進めます

1. 「待たせないUI」を実現する考え方とコードパターン
   • useTransitionとuseDeferredValueの具体的な活用例
   • Concurrent Renderingの理解を深める
2. 「楽観的UI」のつくり方
   • useOptimistic + Actionで即時応答を実装
   • 失敗時のロールバック処理のベストプラクティス
3. これからのUX設計の方向性
   • <ViewTransition>で実現するシームレスな画面遷移
   • Reactの進化が示す「体験設計のこれから」

難しい理論を詰め込むよりも、「これなら自分のプロダクトで使えそう」と思える具体例を中心に構成します。
セッション後には、参加者が「自分のUIをもっと気持ちよくできそう！」と感じられることを目指します。

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

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

わたし、気になります！

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

想定する参加者層

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

テーマ

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

概要

近年、アクセシビリティの重要性が高まってきています。普段携わっているWebサービスやプロダクトでアクセシビリティのテストを自動で行うツールはいくつかあります。その中でもAxeはとても有名なツールの一つです。

本セッションでは、Axeのコアエンジンであるaxe-coreの中でアクセシビリティの自動テストがどのように行われているのかを、具体的なJavaScriptのコードを追いながら確認します。

アクセシビリティのテストは100%自動で検出できるものではありません。しかし、AIの登場によってできることも増えてきました。axe-coreの処理を一緒に探索した後に、自動テストでは何ができて何ができないのかについても考察します。アクセシビリティの理解を一緒に深めていきましょう！

こんな人に聴いてほしい

• アクセシビリティに興味がある方
• フロントエンドエンジニアの方
• HTMLで一度でもコーディングしたことがある方

2025年後半は、ランサムウェア感染、データ損害、クラウド障害という話題がIT業界を震撼させました。
クラウドはスケーラブルな一方で、障害・攻撃・設定ミスなどのリスクを正しく評価できていないことは問題です。いま求められているのは、単なる高可用性ではなく「レジリエンス＝回復力」を備えた設計です。本セッションでは、マルチクラウド（AWS/Azure/GCP/OCI）におけるレジリエンス可視化について考え、システム障害・サイバー攻撃の両面から耐性を強化するアプローチを解説します。四大クラウドにおけるベストプラクティス比較も行い、設計・評価・運用を一体化した継続的レジリエンス向上の手法を紹介します。
想定対象は、クラウドアーキテクト、セキュリティ担当者、システム企画担当。中級者以上を主な対象とします。

2025年9月にリリースされたJava 25は2年ぶりのLTSということもあり、様々な機能が取り込まれています。また、1つ前のLTSであるJava 21からJava 25までにも多くの機能が導入されています。これらの機能を俯瞰することにより今のJavaが向かっている方向も見えてきます。

そこで、本セッションでは、Java 22からJava 25の機能の中から代表的なものを紹介すると共に、Javaが向かっている方向性について考えていきます。

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

■ 対象聴衆／前提スキル

• Webエンジニア、インフラエンジニア、AI・音声認識技術に関心のある技術者
• 普段はHTTPやWebSocket、クラウドAPIを扱っているが「電話通信」にはあまり触れたことがない方
• 難易度：初中級（通信や音声処理の基礎から実例まで）

■ 登壇者プロフィール
通信事業者向けの研修事業を経て、2013年からCPaaS領域に携わる。
2016年よりTwilioのエバンジェリストとして活動し、現在はVonageのエバンジェリスト。
電話・WebRTC・生成AIを組み合わせた音声アプリケーションの開発・普及に取り組むフルスタックエンジニア。
年間100件以上登壇し、APIと音声の融合領域でコミュニティ啓発を行っている。
元、赤い芸人。

■ セッション概要
Web技術の進化により「電話」はいま、APIで自在に制御できる時代を迎えています。
さらに生成AIの登場によって、音声の世界にも新しい開発体験が生まれました。
本セッションでは、電話の基本構造からVoIP／WebRTC、STT・TTS、生成AI連携まで、Webエンジニアにも馴染みのある技術を軸にわかりやすく解説。
デモでは「AIがリアルタイムに電話対応する」仕組みを紹介し、音声通信の新しい可能性を体感していただきます。

■ 学び・持ち帰りポイント（Take-aways）
HTTP／WebSocketなどWeb標準技術で“電話”を扱う基本概念を理解できる
VoIP／WebRTC／STT／TTS／生成AIを組み合わせた音声アプリ構成をイメージできる
通話のリアルタイム処理（音声ストリーミング・LLM連携）の仕組みを知る
「電話×AI×Web」領域の開発ネタ・実験アイデアを持ち帰れる

Raspberry Pi Pico 2Wという小さなマイコンをRustで動かしながら、組込み開発の面白さを“ちょっと深く”味わっていく話をします。対象は、普段はWebやアプリを触っているけれど、マイコンにも興味がある学生さんやエンジニアの方、あるいはC言語での組込みに少し触れたことがあるけれどRustでの開発は初めて、という方です。

Raspberry Pi Pico 2Wは、1,000円ちょっとで買えるボードですが、デュアルコアCPU、Wi-Fi / Bluetooth、USB通信など、かなり本格的な機能を持っています。このトークでは、そんなPico 2WをRustで動かしてみる中で見えてきた“Rustらしい組込みの考え方”を紹介します。

トークの中では、

・Lチカ（LED点滅）のプログラムを動かす
・USB経由で、PCのGUIアプリからLEDの点滅速度を変える
・Blutooth通信を使ってスマートフォンのアプリ（Flutterで自作）からLEDの点滅速度を変える

という使い方を実物で示しながら、その中身で活躍するコードのテクニックを紹介します。単なるハードウェア制御ではなく、「PC・スマホ・マイコンをRustでつなぐ」体験を通して、Rustの良さを感じてもらえることを目標とします。

Rustで組込み開発をすると、最初は「何がそんなに違うの？」と思うかもしれません。でも、実際に書いてみると、変数の所有権や型システムが“動かないバグ”を事前に防いでくれたり、スレッドや割り込みの扱いがとても安心できる設計になっていたりします。C言語では見落としがちな部分を、Rustは“コンパイルエラー”として教えてくれるのです。これは、組込みのようなハードウェアに近い開発では特にありがたい特徴です。

このトークでは、そんなRustの「安全さ」と「気軽さ」を両立させる実践方法を、Raspberry Pi Pico 2Wという分かりやすい題材を通して紹介します。コードの細かい部分よりも、「なぜこう書くと安全なのか」「どんな考え方で設計するとRustが生きるのか」というポイントを中心にお話しします。また、途中でPico 2W特有の“ちょっと変わった構造”（PIOによる柔軟なI/O制御や、無線モジュールCYW43の動作など）にも軽く触れ、マイコンの内部構造を理解する面白さも感じてもらえるようにします。

このトークを通して、Rustを使った組込み開発が「難しそう」から「やってみたい！」に変わるきっかけを届けたいと思っています。マイコンを初めて触る方にも、CからRustへ一歩踏み出してみたい方にも、ぜひ聞いてほしい内容です。

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

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

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

こんなお話をします。

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

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

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

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

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

こんなことある？

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

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

本セッションでは、Amazon Aurora を題材に、SQLの実行計画分析とパフォーマンスチューニングを
AWSサービスと生成AIの力で効率化するアプローチを紹介します。

従来の手作業による実行計画の読み解きでは、時間がかかり、知識の属人化も起きがちです。
しかし、Aurora Performance InsightsやCloudWatch LogsなどのAWSサービスを活用し、
さらに Amazon Bedrock や Claude 3 などの生成AIモデルに実行計画を要約・分析させることで、
より直感的かつスピーディーにチューニングを進めることが可能になります。

◼️テーマ
データベース最適化／SQLチューニング／生成AI活用／Aurora／パフォーマンス可視化

◼️想定する参加者層（前提知識）
中級者以上のエンジニア向け
• SQLを日常的に書いている方
• クエリのパフォーマンスチューニングに苦手がある方
• チューニングの「調査・分析」を効率化したい」方
• 生成AIを業務活用してみたいクラウドエンジニア
初心者も歓迎
• 実行計画を読んだことがない方でも理解できるよう、最初に基礎概念を解説します。

◼️トーク概要
「SQLが動くけれど遅い。何をどう直せばいいか分からない。」
──そんな経験をしたことはありませんか？

SQLのチューニングには“実行計画”という最強の手がかりがあります。
しかし、EXPLAINを見ても「Index Scan」「Nested Loop」などの言葉の意味が分からず、
“結局どこが遅いのか”が掴めないという声を多く聞きます。

このセッションでは、Amazon Aurora（MySQL/PostgreSQL互換）を実際に操作しながら、
実行計画を「読む」「比べる」「直す」プロセスをリアルタイムで紹介します。
• 実行計画から何が分かるのか？
• フルスキャン・インデックススキャン・結合順序の違い
• Aurora特有のチューニングポイント（キャッシュ・パラメータ・I/O最適化）
• 実際にパフォーマンスを改善した事例（Before/After）

理論だけでなく、“目で見て速くなる”デモを通して、
実行計画がただのテキストではなく「データベースの会話」に見えてくる瞬間を体感してもらいます。

テーマ

HTMLのbutton要素とa要素の正しい使い分け、マークアップ、アクセシビリティについてを主題とします。安易な実装が引き起こすバグやアクセシビリティ低下という課題に対し、Web標準に基づいた「ボタンの定義」についてを改めて見直す内容を提供します。

想定する参加者層

• とりあえず<div>や<a>にonClickを書きがちな方
• コンポーネント設計の際に、<button>と<a>の使い分けで議論した経験のある方
• UIのセマンティクスやアクセシビリティに関心のある方

トーク概要

今やWebサイトやアプリケーションに必ず存在するようになった「ボタン」というUI。私たちは毎日当たり前のように実装していますが、「ボタンとは何か？」と聞かれたら、明確に定義できるでしょうか？

<a>タグをボタン風に装飾したUI、type属性を忘れて意図せず画面をリロードさせる<button>、そして歴史の彼方に消えつつある<input type="button">...。なぜこんなにも多様な『ボタンのようなもの』が生まれ、そしてバグの温床となるのでしょうか。

私はこれまで、マークアップのセマンティクスを重視する立場として、こうした「残念な」実装が溢れる現状を常にもどかしく感じてきました。「動けば良い」という流れの中で、なぜ「本来あるべき姿」が失われてしまうのでしょうか。
このセッションでは、「type属性の指定漏れ」でバグを踏んだ経験や、デザイナーと「ここはリンクか？ボタンか？」で実装方針が割れた際の苦い議論を基に、このボタンUIを深掘りします。

HTML仕様やアクセシビリティの観点から「ボタンとは何か」を再定義すると同時に、私が実務のコードレビューや設計議論で直面してきた葛藤と、それを乗り越えるための知見を共有します。
この発表を経て「たかが」と思っていたボタンUIについての考えを変えるきっかけになるかもしれません。

期待する聴者に持ち帰ってほしい内容

• 「ボタンとは何か？」という問いに対し、セマンティクス・振る舞い・アクセシビリティの観点から自信を持って説明できるようになる
• type属性の指定漏れによる意図せぬフォーム送信バグを、未来永劫なくすことができる
• リンクをボタンのように見せるUI（リンクボタン）を実装するときに配慮すべきことに気づける

【テーマ】

JavaScript 3大ランタイム Node.js、Deno、Bun についてさまざまな観点から比較を行います。
さらに各ランタイムそれぞれが持つユニークな特徴なども深掘りしていきます。

【想定する参加者層】

• JavaScript / TypeScript に興味のあるすべての人（言語自体は知らなくても OK）
• Node.js、Deno、Bun。聞いたことはあるけど何が違うかよくわかっていない人

【トーク概要】

JavaScript ランタイムといえば何を思い浮かべますか？
一番メジャーなのは Node.js ですが、Deno や Bun を聞いたことがある方も多いかもしれません。

「セキュリティや Web 標準は Deno」「高速性は Bun」といった大きな特徴ではよく比較されるものの、各ランタイムを取り巻くエコシステムや、開発環境における違いなど細かい部分についてはあまり知らない方も多いと思います。

本発表では、JS エンジンや速度面はもちろん、ランタイム自体の開発言語やエコシステム、開発環境などにも焦点を当てて、各ランタイムの比較・ユニークな特徴を紹介したいと思います！

JS を知らない方には、JS ランタイムについて知ってもらい、
Node.js を使ってきた方には、Deno や Bun の違いを知ってもらい、
3つをすでに知っている方にも、さらにディープな違いを知ってもらえる内容です！

30分後、きっとあなたの ”推しランタイム” が見つかりますよ

テーマ

定理証明：複雑なロジックと事実上無限の入力を持つソフトウェアに対して、テストケースの網羅性に依存せず、論理的に挙動を保証する手法およびその実例

想定する参加者層（前提知識）

• 計算機科学に興味があるが敷居の高さを感じている方
• 設計と一体化した品質保証に興味がある方
• 形式手法や定理証明に関する前提知識は仮定しません
• 特定の CPU 命令セットに関する前提知識は仮定しません
• 特定のコンパイラバックエンドに関する前提知識は仮定しません
• 型システムに関する理論的な前提知識は仮定しませんが、何らかの静的型付き言語によるプログラミング経験は前提とします
• 基本情報技術者試験に出題されるような計算機アーキテクチャの初歩、例えば「メモリとは何か」のような知識は前提とします

トーク概要

本セッションでは、定理証明支援系 Lean を用いたコンパイラの実装技法を解説します。ただしこれは本質的にはコンパイラのトークではありません。頭の痛い複雑なロジックや、うんざりするほど多様な入力データと戦っている、すべてのソフトウェアエンジニアに贈る新しい世界への招待状です。

今日、プログラムを書く際に一緒に単体テストを書くことは、一種のマナーとして広く普及しています。しかし、かつて Dijkstra はこう言いました。「テストではバグの存在を示すことはできても、不在を示すことはできない」つまりテストが成功していたとしても、それはたまたまテストケースが不足していてバグを踏まなかった可能性が否定できない、というのです。一方で、仮に全通りのテストケースを生成してバグの不在を示そうとした場合、組み合わせの爆発により膨大な数のテストが必要になってしまいます。例えば「長さ 3 以下の char の配列を受け取る関数」をテストするだけでも入力パターンは 16,843,009 通り。通常の任意長の配列を受け取る関数ならば文字通り「無限個のテストケース」が必要です。

本セッションで紹介する定理証明は、文字通り、この「無限個のテストケース」を扱うための手法であるといえるでしょう。テストしたい関数の性質を型レベルの制約として表現することで、単体テストのような実行時ではなく静的な型検査時に、かつ「任意の char 配列」のような事実上無限個のテストケースに対して関数の性質を保証できます。

いくつかある定理証明支援系の中でも、Lean は単に証明を記述するだけでなく、実際に動くプログラミング言語であるという面で近年注目を浴びています。一例として、Amazon Web Service では、認可ポリシー記述言語である Cedar の開発と最適化のために、この Lean を採用しています。認可ポリシーエンジンの実装は「ロジックが複雑」「あらゆるパターンに対応する必要がある」「最終結果がぱっと見で分からない」「ミスがあると被害が甚大」という点で、まさに定理証明向きの事例と言えます。また、国内においてもちょうど日本語書籍『ゼロから始める Lean 言語入門』が出版されたばかりで、今 Lean が盛り上がりつつあるのは間違いないでしょう。

本セッションでは、Lean を利用して、自作言語をコンパイルしてシンプルな CPU 上で動かすための「証明付きコンパイラ」を実装します。コンパイラもまた、複雑なロジックと多様な入力が求められるソフトウェアの典型です。ところで、引数と戻り値を持つ個別の関数のテストならともかく、ここで言う「コンパイラの正しさ」とは何でしょう？ コンパイルしたプログラムの挙動が正しいこと？ ではその「正しい」とはどういう状況か、定義できるでしょうか？

この問いへの答えとして、今回の解説では、コンパイラの性質を「ソース言語の意味論」と「ターゲット言語の意味論」の間をつなぐものとして定式化し、実装したコンパイラが意味論を保存することを証明します。また、コンパイラの挙動を保証するための理論的な解説に加え、実際に動くプログラムを書けるという Lean の特性を活かして、「インタプリタ」「VM」そしてその間をつなぐ「コンパイラ」をそれぞれ実装し、簡単なプログラムをコンパイルして動かす様子もお見せします。

受講にあたって必要なものは、プログラミング経験者であれば普通に知っている程度の知識と、ほんの少しの知的好奇心だけです。定理証明や特定の CPU 命令セットに関する前提知識は要求しませんし、それどころかコンパイラとしては、最適化も行わない、本当に素朴な実装しかしません。むしろ「コンパイラの正しさとは何か？」を題材として、複雑なプログラムの挙動も数学的にきちんと定式化できるのだ、そしてそのための理論や考え方は、他ならぬあなた自身とも無関係の世界ではないのだ、という感動を味わって頂ければと思います。

VS Codeのオープンな文化と、IBMが推進するエンタープライズ開発者体験(DX)。その交点には、“ギーク的思考“と”企業的スケール“を融合する挑戦があります。
このセッションでは、IBMが提供するVS Code拡張機能を通じて、クラウド(IBM Cloud)、AI (watsonx)、コンテナ(Red Hat OpenShift)のローカル開発からクラウドデプロイ、AI支援まで一気通貫で行う開発フローをご紹介します。

・テーマ
オンプレミス脳からクラウドネイティブ脳への「思考のリファクタリング」を、料理のレシピのように4つのステップで話します。現場の失敗談と成功体験を材料として混ぜ込み、クラウド移行の悩みを解消するレシピを提供します。
さらに、「思考のリファクタリング」にAIが与える可能性を、実験的な「隠し味」として紹介します。

・想定する参加者層

• オンプレミスレシピの呪縛から解放されたいエンジニア
• クラウド移行で迷子になっている方
• AIによるアレンジで開発レシピを革新してみたい技術者

・トーク概要
従来のオンプレミス環境で培われた設計思想から、クラウドネイティブな考え方への転換を、4つのステップとして体系化してお話します。技術的な詳細よりも、思考プロセスの変化に焦点を当てることで、参加者の方が持ち帰って実践できる考え方やアプローチを中心にお話しします。クラウドネイティブへの転換に悩む方々にとって、明日からの取り組みのヒントとなるような内容を目指します。
また、AI技術を使って設計プロセスの効率化や品質向上にどの程度貢献できるのかを実際に試してみた結果を紹介します。成功例だけでなく、期待通りにいかなかった事例も含めて、現実的な視点でAI活用の可能性と限界について考察します。

オンプレ思考からクラウドネイティブ思考への転換レシピ
～AI活用のスパイスを添えて～

• ステップ１　システム分離への思考転換
• ステップ２　データ戦略の思考転換
• ステップ３　処理方式の思考転換
• ステップ４　障害対応の思考転換
• アレンジ　　AI活用の可能性

共同スピーカー:加藤寛士

テーマ

4つの異なる言語・フレームワークにおける「列挙型（Enum）」の比較から学ぶ、設計思想の多様性と型安全性の未来

想定する参加者層（前提知識）

中級者以上を対象 （複数の言語のいずれかで開発経験があり、基本的な型システムやデータベース連携の概念を理解しているエンジニア）
Java、C#、Ruby、JavaScript（TypeScript）を想定しています。異なるコミュニティが集まるこの場所で、あえてすべての言語に共通する、そして最も設計思想の違いが表れる機能の一つ、「列挙型（Enum）」を徹底的に解剖します。

一見シンプルなEnumですが、その実装は言語の哲学そのものです。本セッションでは、この共通概念が各言語でどのように進化し、開発者にどのような設計上の恩恵と制約をもたらしているのかを、実用的なコード例を交えて比較・考察します。

トーク詳細

本トークでは次の内容について話を進めます。

1. Enumとは一般的にどのようなものか？
2. Enumはクラスか定数か
   　2.1. JavaとC#でのEnumの比較
   　2.2. 後発言語、PHPでの扱い
3. ネイティブでEnumを持たない言語のアプローチ比較
   　3.1. TypeScriptでのEnumの工夫
   　3.2. Ruby on RailsでのEnumの使われ方
4. 全体への洞察
   　4.1. Enumの役割を改めて見直す
   　　4.1.1. 多値の表現力、振る舞いのカプセル化、永続化やリファクタリングといった観点からそれぞれのEnumについてまとめ直します
   　4.2. 言語の思想への考察

Enumは「クラス」か「定数」か？

まず、JavaとC#という兄弟のような言語におけるEnumの根本的な違いを明確にします。

JavaのEnumはEnum定数がフィールドとコンストラクタを持つ「クラスインスタンス」です。これにより状態と振る舞いをカプセル化し、ポリモーフィズムを実現する設計哲学を解説します。

C#のEnumは「名前付きの整数定数」として扱います。拡張メソッドや[Flags]属性による実用的な拡張に焦点を当てます。

そして後発のPHPのEnumはJavaのメソッドとC#のバッキング値の良いところを取り入れ、特にDB連携を意識したモダンな設計になっている点を紹介します。

ネイティブでEnumを持たない言語のアプローチ比較

ネイティブでEnumを持たない言語が、いかにしてこの概念を取り込んだかを探ります。

TypeScriptのEnumは開発時の型安全性と、それがJavaScriptにトランスパイルされた際の挙動の危うさ（数値の型安全性の問題など）を示します。最近のJavaScriptへのネイティブEnum導入に関するTC39の議論にも触れ、この機能の未来を予測します。

一方、Ruby on Railsのenumは言語本体ではなく、フレームワーク（Rails）の機能としてDB連携に特化することで、生産性と利便性を極限まで高めたアプローチを考察します。静的型付けの世界では見られない、Rails特有の「規約の力」を強調します。

全体への洞察

最後に、これらの比較を通して得られる重要な知見を共有します。

多値の表現力としてJavaの複数のフィールド vs PHPの単一のバッキング値 vs TSの柔軟性。
振る舞いのカプセル化としてEnum自身にロジックを持たせるべきか、外側でswitchで分岐すべきか。
永続化とリファクタリングとしてDBに依存するRailsのenumと、依存しないJava/C#のEnum、どちらが長期的な保守性に優れるのか。
など、Enumを基準として各言語ごとにどのように「列挙型」と向き合っていくべきかを示します。

このセッションは、単なる機能紹介に留まらず、あなたの日常的なコーディングにおける「良い設計とは何か」「型安全性とは何か」という問いに、複数の視点から答えを与えます。他言語のEnumを知ることで、あなたのメイン言語のEnumが持つ強みと制約を再認識し、より深く、より保守性の高いコードを書くための新たな視点と熱意を持ち帰ってください。

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

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

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

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

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