---私はこんな人！---
私は日頃、QA（テストエンジニア）として案件にアサインされています。

作業範囲はIT、ST、リグレッションなど状況に応じて様々。
管理ツールなどは利用しつつ、未だテスト設計そのものはほぼ手書きになっているのが現状です。
そんな中、社内外ともに積極的なAI利用が求められ、苦手なAIと真正面から向き合わないといけない日々が到来してしまいました。。

---こんな方に聞いて欲しい---
開発に関わるすべての方。
現場でバリバリ開発やテストをしている方も、案件管理などマネジメントラインの方も、すべてが対象です。

---テスト設計とAI---
私はテスト設計（≒QA）とAIはとても「相性が悪いもの」だと思っています。

本当は気軽にあれもこれもAIに読み込んで処理してもらいたい・・・
でも現実はそうはいかず、ただ資料を読み込ませたりルールを指定するだけだと、結果を出力する度に内容が変わっていたり、あるものを「ない！」と元気に返してくれたり、なんだかんだで使い物にならず頭を抱えます。

仕様書／設計書は基本的に日本語で書かれていますので、時に書き手により文体や表現の違う文章を処理しないといけません。
フローチャートなど、AIが苦手とする図表などがふんだんに含まれている場合も多々あります。
そもそも、昨今アジャイル開発が増えている中、仕様書がちゃんと作成されていないことも・・・

そう、テスト設計はAIと相性の良さそうなプログラミング言語ではなく「自然言語」、ひいては「人」を相手にしないといけない、という大きな壁が立ちはだかるのです。

また、利用できるAIには制限があります。
できれば日本語の処理に強いものを利用したいのですが、予算や会社都合が発生したりします。

私はいまcursorを利用しているのですが、そもそも開発者ではないのでエディタ系の画面がまず見慣れない・・・
こんな思わぬ落とし穴もあったりします。

---この登壇でお伝えしたいこと---
近年、AI活用をテーマにした有効なお話はたくさんありますが、たまには扱いが下手な人が、苦手なりに頑張るお話があっても良いんじゃないかな？と思い、この内容で応募させて頂きました。
特に開発とQAではAIが作業効率に寄与する割合に大きな差があるものの、現場目線だとそれが伝わりにくく「やりたくないだけでしょう？」と思われてしまうこともしばしば。
そんな誤解を少しでも解消すべく、どのようなことに苦戦し、試行錯誤しているのか・・・をお話する予定です。
また、この問題の解決にはエンジニアの協力がとても重要だと感じていることもお伝えできればと思っています。

※政治に関する話題は最低限にしている、あくまで技術的な視点でのトークです。
※特定の政治家・政治団体・政党のお名前を一切お話しません。

テーマ

テクノロジー × デモクラシー

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

何かを作ってみたい、アウトプットをしてみたい方
政治なんてさっぱりわからない！という方（政治の知識は不要です。私も無いです）
学生の発表なので難しい話はしません、できません！

トーク概要

みなさんは「デジタル民主主義2030プロジェクト」をご存知でしょうか。
「デジタル民主主義2030」は、技術の力で市民の声を活かし、政治をより良い形に進化させることを目指したプロジェクトです。透明性と信頼を重視し、多くの人々が政策に参加できる未来を目指しています。
今回は、このプロジェクトから生まれたオープンソースソフトウェア（OSS）である "Polimoney" について、技術的な視点からご紹介します。

「Polimoney」は、政治とお金にまつわる「複雑なデータ」や「アナログな業務フロー」といった課題を、テクノロジーの力でボトムアップに解決しようとする「シビックテック」（※）の取り組みです。
（※市民がテクノロジーを活用して社会課題を解決する活動）
このプロジェクトは誰でも活動に参加できるのが特徴で、学生である私もcontributorとして開発に参加しています。

「なぜ今、この領域にエンジニアリング（OSS）が必要なのか？」という視点から、私たちが直面している課題と、それをどう乗り越えようとしているかをお話しします。

• 「政治とカネ」の現場にある「技術的負債」
• なぜデータ活用が進まないのか？制度と実務のギャップ
• Polimoneyによる課題解決のアプローチ
• 学生エンジニアが政治系OSSに参加したリアルな体験
• 「コードを書く」だけじゃない！ OSSへの貢献方法

デジタル民主主義2030 https://dd2030.org/
polimoney https://polimoney.dd2030.org/

▪️テーマ

耐量子計算機暗号 (PQC)、暗号技術、セキュリティ、NIST標準化 (FIPS 203, 204, 205)

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

前提知識

• 特定のプログラミング言語に関する知識は不要です
• 高校程度の数学の知識があるといいが、必須ではないです
• 公開鍵暗号方式（RSAなど）の基本的な概念を理解しているといいが、必須ではないです

想定する参加層

• Webアプリケーションやシステムのセキュリティに関わるエンジニア
• 暗号技術の最新トレンドや量子コンピュータの動向に興味がある方
• 将来の標準技術（PQC）の仕組みや実装状況を早めにキャッチアップしたい方

▪️トーク概要

耐量子計算機暗号（Post-Quantum Cryptography: PQC）は、将来登場が予測される高性能な量子コンピュータによる解読の脅威に耐え得る、新しい暗号技術の総称です。
PQCの基盤となる数学的問題は一つではなく、様々なアプローチが研究・開発されています。

特に大きな動きとして、2024年8月、NIST（米国国立標準技術研究所）は2016年から進めてきたPQC標準化プロジェクトの成果として、FIPS 203、204、205という3つの標準を正式に発表しました。
これにより、PQCは研究段階から「実装段階」へと大きくシフトし始めています。

本トークでは、まず「なぜ今PQCが必要なのか？」という背景や、NISTによる標準化の最新動向といった概要を解説します。
その上で、標準化されたPQCがどのような仕組みで安全性を担保しているのか、代表的な方式（例：格子ベース暗号など）の技術的な仕組みを分かりやすく紐解きます。
最後に、私たちエンジニアが最も関心のある、主要なプログラミング言語（Java, Go, Rust など）におけるPQCライブラリのサポート状況を紹介します。

想定しているアジェンダ

• 耐量子計算機暗号入門
  • なぜ耐量子計算機暗号が必要なのか
  • NIST の耐量子計算機暗号の標準化について（FIPS 203、FIPS 204、FIPS 205）
  • 主要な耐量子計算機暗号の紹介（格子暗号、同種写像暗号、符号ベース暗号、多変数多項式暗号、暗号学的ハッシュ関数）
• 各プログラミング言語に関するサポート状況
  • Java （Java 24での機能提供）
  • Go （1.24での機能提供）
  • Rust （Rust Crypto での提供）　など

このトークで得られること (Takeaway)

• 量子コンピュータがなぜ現在の暗号（RSA, ECC）に脅威となるのかを理解できる
• NISTによって標準化されたPQC（FIPS 203, 204, 205）の概要と重要性を学べる
• 代表的なPQCアルゴリズムの基礎的な仕組みを把握できる
• 主要言語（Java, Go, Rust等）でのPQC対応ライブラリの現状を知ることができる

AI時代の今、あえて「ライブラリを使い倒す」経験は必要なのか？

キャッチコピー: バイブコーディングが教えてくれないこと 〜なぜ私はReact Hook Formに“育てられた”のか〜

ターゲット: AIコーディングに慣れ始めた若手・中堅エンジニア、技術選定を行うテックリード

概要:

（導入）昨今の開発はAIアシスタントの登場で劇的に変化した。「バイブコーディング」でそれなりの実装が瞬時に手に入る。

（過去）しかし、私（発表者）が学んだ時代は違った。特にフロントエンドは「正解」がなく、React Hook FormやFullCalendarのような複雑なライブラリを、文字通り「片っ端から試し」ながら使い倒す必要があった。

（対比）この「使い倒す」泥臭い経験は、単にライブラリの使い方を覚えるだけでなく、「なぜこのAPI設計なのか」「状態管理のどのパターンが最適か」といった実装の裏にある『Why』を深く理解するプロセスだった。

（問い）AIが最適なコードを提示してくれる今、この「苦しみながら使い倒す」経験は不要になったのか？ AIが提示するコードの「意味」を真に理解できているか？

（結論）「使い倒した」経験こそが、AIの出力を鵜呑みにせず、より良い設計を判断・選択できるエンジニアの「幹」となる。バイブコーディングの時代だからこそ、意識的に「使い倒す」経験が重要である。

【テーマ】
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のビルドを行い、検証実験に至ったのか、その過程を共有します。

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

概要

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

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

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

こんな人に聴いてほしい

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

■ 対象聴衆／前提スキル

• 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」領域の開発ネタ・実験アイデアを持ち帰れる

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

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

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

こんなお話をします。

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

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

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

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

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

こんなことある？

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

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

【テーマ】

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分後、きっとあなたの ”推しランタイム” が見つかりますよ

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

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

・想定する参加者層

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

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

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

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

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

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