【テーマ】
Webページのパスキーに対応できるかどうかを明らかにするため、WebViewのビルドに挑戦した新卒エンジニアの試行錯誤

【想定する参加者層】
・WebViewを使ったAndroidアプリ開発に携わっている方
・ブラウザ、パスキーに関心がある方
・WebView（Chromium）やカスタムROMのビルドに興味がある方
・「やってみた」系の話が好きな方

【トーク概要】
WebViewは最小限のブラウジング機能を有しますが、Chromeと異なりWebページのパスキーに対応していません。
AOSP（Android Open Source Project）のWebViewに関するコードを調べたところ、パスキーを利用可能にする「CHROME_3PP_ENABLED」定数が設定不可にされている一方、別箇所ではその定数の設定を想定しているようなコードも存在しました。
この矛盾する発見について、上司から次のように提案を受けました。 「もしこの定数を設定できるようコードを修正し、パスキーを動作させられれば、それをPoCとしてGoogleに機能拡張を提案できるかもしれない。AOSPをビルドして検証してみてはどうか？」

本セッションでは、この仮説に基づいて行った検証実験を以下の内容で共有します。
・前提１： 基本的なWebViewのパスキー実装
・前提２： パスキー実装の制約、その技術的背景
・WebViewのビルド： Azure VMを使ったビルドマシンの用意、ビルド成功までの試行錯誤
・さらなる課題： WebViewの実行環境としてのLineage OS（カスタムROM）のビルド、エミュレータの起動
・ようやくたどり着いた検証実験、その結果

本セッションはサクセスストーリーではありません。新卒入社２年目のエンジニアが情報リソースの限られた中で、いかにしてWebViewのパスキー実装に関する調査や、WebViewおよびLineage OSのビルドを行い、検証実験に至ったのか、その過程を共有します。

Webブラウザはこれまで、数々の機能を実装し、セキュリティを強化し、相互運用性を高めながら発展してきました。
現在では情報アクセスの一部がAIを介した対話的UIへと移り始め、ブラウザでUIを提供する時代は終わるという声も聞かれるようになりました。

現代、もしくは近い未来私達が情報の消費者としてもコンテンツを作り出す開発者としても、Webブラウザに何を求めるのかを問い直します。

また、モダンブラウザと呼ばれる主要なブラウザエンジンに加えて、新興ブラウザエンジンの開発も進んでいます。
実際に1つのブラウザエンジンプロジェクトにコントリビュートしている発表者の視点から、ブラウザ開発に関わるモチベーションを紹介し、日本人開発者が参加する意義についても考察します。

"Why do you need End-to-end Encryption in Ruby? Because..."

国際情勢の緊張が高まる現在、メッセージングのエンドツーエンド暗号化技術はかつてなく重要性が高まっています。
Eメールはその仕組み上エンドツーエンドでの暗号化を持たず、どうしても暗号化を実現しようと思うとS/MIMEなどの高価な仕組みやPGPなどの「オタクしか使っていない」仕組みに頼るしかありません。一方で我々が日常的に利用しているメッセージングアプリにはエンドツーエンド暗号化の仕組みが搭載されていますがベンダーごとに個別の方式で実装されており相互運用性を持ちません。
これらを解決すべくIETFで標準化が行われているMessaging Layer Securityという相互運用可能な鍵交換の技術があります。
現在私はMessaging Layer Security Protocol (RFC 9420)のRuby実装を進めています。この実装を通してMessaging Layer Securityの仕組みを解説することで、皆さんが日常使っているメッセージングアプリのセキュリティについて安心感を持つことができるようになるでしょう。

技術的には以下の内容をカバーする予定です:

• 求めるセキュリティ性質: Forward SecrecyとPost-Compromise Security
• 2人でこれを実現するのは容易だが3人以上の場合は難しい
• MLSの構成要素: Key Schedule, Secret Tree, TreeKEM
• 進行中のRuby実装について

ハッシュ化、共通鍵暗号、公開鍵暗号の概念程度の暗号技術の知識をある程度前提としますが、トークの内容自体はセキュリティに興味のある全技術者向けの内容です。

テーマ

AIエージェントの導入によって、開発の現場は実際にどのくらい生産性が向上したかをテーマに、導入した現場での定量的な実測値とAIエージェントのベンチマークを深掘って考察した結果を発表します。
いくつかのAIエージェントの導入(2023年のCopilot、2024年のCursor、2025年のClaude Code)による社内でのマージ頻度やリードタイムの変化と考察、AIエージェントの研究開発の分野で参照されるHumanEval / SWE-Bench等のベンチマークの深掘り、そのベンチマークによる定量評価がどれくらい現場での定性的な評価と合っているのかを考察した内容を発表します。

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

機械学習やLLMに関する研究の知識などを必要とせず、コード生成をするAIエージェントを見聞きしただけの人にもわかりやすいような基礎からの発表にします。特に、ベンチマークについては、具体的にどのような課題があってどのように判定されているのかを噛み砕いて説明します。

トーク概要

本セッションでは、AI コードエージェント導入による開発加速の実態を、現場データとベンチマークの両面から整理してご報告します。
当社では 2023 年以降、その時点で有効と判断したコード生成 AI エージェントを導入してきました。マージ頻度やリードタイムの集計の結果、ある事業部では Cursor 導入後にマージ頻度がおよそ 3 倍、Claude Code 併用後にリードタイムがおよそ 1/2 となる変化を観測しました。この事実をもとに、「AI でどれくらい加速したのか」「どう評価すべきか」を定義し直します。

AI 導入初期はコード生成の品質が安定せず、人手による修正が前提となる場面が多いと感じていました。その後、モデル世代の変化に伴いコード生成の「精度」が向上し、コードエージェントの導入により開発体験が実際に変化した手応えがありました。ただし、この「精度」が具体的に何を指すのかに疑問を持ちました。変化量を外部基準でも確認するため、研究開発分野で一般的なベンチマークが何を測り、どのスコアを KPI としているかを整理する必要があると判断しました。

そこで、HumanEval と SWE-Bench を取り上げ、研究・開発分野で何を指標としてスコアを伸ばそうとしているかを解説します。これらのベンチマークでは、HumanEval は明確な入出力をもつ小粒度タスクに対する関数レベルの正確性を測定し、SWE-Bench は既存リポジトリ上での Issue 修正達成（文脈統合・依存解決・テスト通過）を測定します。現場では前者をユーティリティ／純粋関数の自動実装の置換可能性、後者を既知バグ修正や小〜中規模改修の到達率として読み替えます。本発表では、実際のテストデータを参照しながら両者の評価対象と前提条件を具体的に説明します。

あわせて評価指標にも短く触れます。pass@k は同一課題に対して k 本のコード生成を行い、少なくとも 1 本がテストを通過する確率を示します（例：pass@1 は単発生成の正答率、pass@5 は多様サンプルからの到達率）。SOTA（state of the art） は特定ベンチマーク・評価手順・バージョンにおける当時点の最高到達成績を指します。いずれも評価プロトコルと前提条件への依存性が高いため、比較は同一条件で行う必要があります。

そのうえで、ベンチマークの数値は次の三点で位置づけて読み解きます。第一に、何を前提に何を測っているか（課題の明確さ、必要コンテキスト、依存・ビルド環境、採点方法）を明示します。第二に、どの作業単位に対応するか（例：小粒度の実装、既知 Issue の修正、結合起点の不具合対応）を対応付けます。第三に、影響しやすい成分／しにくい成分を仮説化します。なお、研究分野の「コード精度」は pass@k やテスト合否が中心であり、仕様の曖昧さの解消、非機能要件、ステークホルダー調整、セキュリティやロールバック設計、コードデザイン（責務分割・凝集／結合・API 境界）といった現場要素は評価外になりやすい点を前提にします。本セッションでは、この読み替えを対応表と最小手順として提示し、新しいモデル・ツール・論文に出会った際に、作業単位や手元の指標へトレースする実務的なガイドとして持ち帰っていただきます。

聴講者が得られること
• AI 導入による効果が定量的にどのくらいあるかと、その評価方法
• 研究開発分野での AI エージェントの扱われ方と、どのスコアを KPI として伸ばしているかの整理
• 研究ベンチマークが開発現場でどの程度・どの領域に起用できるかを考え、議論するための視点

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文によるループは正確な回数繰り返されるのか？ Prologのバックトラック・Go言語のGoroutineなど、言語ごとの特殊な機能は正しくエミュレートされるのか？

わたし、気になります！

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

想定する参加者層

生成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 エージェント設計開発の本質を楽しみましょう！

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

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

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

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

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

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

現在AIを基盤とした様々な製品、サービスがありますが、IDEメーカーとして人気のJetBrainsの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」などの言葉の意味が分からず、
“結局どこが遅いのか”が掴めないという声を多く聞きます。

この発表で以下のようなことを持ち帰っていただきたく思います。
• 実行計画から何が分かるのか？
• SQLチューニングの属人化からの脱却
• Amazon CloudWatch Database Insightsについて