エンジニア採用のスカウトメッセージで「ちゃんとレジュメを読んでくれた」と感じてもらえる文章をAIに生成させようとしたら、想像以上に大変でした。プロンプトエンジニアリング、RAG、ファインチューニング...次々と手法を試しても期待する品質に届かない。本セッションでは、AIの専門家ではないエンジニアが、特定ユースケースで「妥協しない品質」を実現するまでの泥臭い試行錯誤と、そこから得た知見を共有します。

これまでエンジニア採用で何百、何千のスカウト文章を書いてきて思いました。エンジニア採用の成功率を上げるには、候補者一人ひとりに向き合った「人間味のある」スカウトが大切です。でも、これをAIで自動化しようとしたら...予想以上の苦労が待っていました。

本セッションで話すこと：

1. プロンプトエンジニアリングの限界

   • プロンプト改善で見えた「できること」と「できないこと」
   • 具体例：なぜAIは「〇〇の経験を活かして」という抽象的な表現に逃げるのか

2. RAGで過去資産を活用...したかった

   • 過去のよくできたスカウト文章をRAGで学習させた結果
   • 文脈理解の落とし穴：なぜ的外れな引用をしてしまうのか

3. 品質を妥協しないための工夫

   • 評価基準の明確化：「人間らしさ」を数値化する試み
   • ハイブリッドアプローチ：AIと人間の協調による品質担保

得られる知見：

• MLエンジニアでなくても、AIの出力品質を改善できる実践的手法
• 「期待する品質」を定義し、測定し、改善するフレームワーク
• プロダクト開発でAIを活用する際の現実的な落としどころ

想定聴衆

• AIを活用したプロダクト開発に興味があるエンジニア（初〜中級者向け）
• 生成AIの実用化で苦労している方
• 「AIに任せきり」ではなく品質にこだわりたいエンジニア

テーマ

Keycloakで始める認証基盤入門 — 1年半の運用で学んだ飴と鞭

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

初心者向け

トーク概要

Keycloak という OSS をご存知でしょうか？

昨今、SSOや2段階認証など、認証・認可にまつわる話題が絶えません。
Keycloakは、そんな認証・認可に必要な機能を汎用的に実現できる、セルフホスティングが可能なOSS認証基盤です。

発表者は実務で Keycloak を導入し、1年半ほど運用してきました。
導入の簡単さや、豊富な拡張機能、そして個々の要望への対応の苦労など、飴と鞭を等しく味わっています。

本発表では、そんな Keycloak について興味を持っていただき、将来的な"飴"の量を増やすことをねらいとしています。

• Keycloakで何ができるのか？（SSO統合、OIDC連携、多要素認証など）
• 運用時の課題やその対応、そして実施した工夫
• 認証・認可の複雑さとKeycloakでの向き合い方

これらの知見の共有を通して、これからKeycloakを検討される方、すでに使っている方、どちらにも参考になれば嬉しいです。

▪️テーマ

耐量子計算機暗号 (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対応ライブラリの現状を知ることができる

テーマ

明日から使える！ソフトウェアテストの歩き方

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

主にソフトウェア開発に携わる一般エンジニアを対象としています。
テストを我流で行っている方、または単体テストや結合テストの品質をもう一歩上げたいと考えている初学者〜中堅エンジニアを想定しています。
JSTQBなどの体系的なテスト知識がなくても理解できる内容ですが、仕様を読みコードを書いた経験があると理解が深まります。
テストエンジニアだけでなく、開発者・PM・デザイナーなど「自分の成果物の品質に責任を持ちたい」と考えている方にもおすすめです。

トーク概要

テストって、どこまでやればいいんだろう？
機能は動いているけど、なんとなく不安。レビューでは「テストケースが浅い」と言われる。
そんな経験をしたことがある方は多いのではないでしょうか。

このセッションでは、現場で本当に役立つ「ソフトウェアテストの考え方」を、明日から実践できる形でお伝えします。
テーマは「同値分割を基本としたテスト技法」「経験ベーステスト」「生成AIを活用したレビュー技法」の3つ。
教科書でおなじみのテスト技法に加え、現場で実践している生成AIの活用方法を紹介します。

テストは、実際のプロジェクトでどう活かすかとなると、途端に難しく感じる人が多い分野でもあります。

私自身、スタートアップでQAエンジニアとして日々開発と向き合っています。
IT業界20年。開発者やマネージャーとしての経験を経て、「理論通りにやってもうまくいかない現場」と、「時間がない中でも品質を守る工夫」を何度も経験してきました。

そこで気づいたのは、テストは“やり方そのもの”ではなく“テストの考え方”を学ぶことが大事だということ。
同値分割の前に「どんな違いが意味を持つのか」を見抜く目。境界値分析の前に「どこが境界なのか」を見つける力。
そして、マニュアルに載っていない「勘」や「経験」は、実は“多くは理屈で説明できる”ものだということです。

本セッションでは、JSTQBの定義をベースにしつつ、
・仕様の読み方をどう変えるとテストがしやすくなるか
・チームで納得できるテストを作るために必要な考え方
・不具合を探索する道標の作り方
など、「ものづくりのラストワンマイル」を埋めるヒントをお話しします。

単に「テストをやる人」ではなく、
「品質をつくる人」として一歩踏み出すためのきっかけになればと思っています。

テストを専門にしていなくても大丈夫。
むしろ、今までは“なんとなく動作確認していた”という方にこそ聞いてほしい内容です。
セッション後には、自分のプロダクトや関わっているプロジェクトを少し違う視点で見られるようになり、
「ここは確認しておこう」「ここが危なそう」と、自然にテストの意図が浮かぶことを期待して準備します。

テストは退屈な作業ではなく、プロダクトを深く理解するための一番身近な探求です。
このセッションを通じて、あなたのテストが「やらされるもの」から「やりたくなるもの」に変わる。
そんな体験をお届けしたいと思っています。

「自分のテストがなんとなく不安」「レビューで指摘されがちでしんどい」そんな方に、
明日から試せる“ソフトウェアテストの歩き方・付き合い方”を持ち帰ってもらえるセッションです。

テーマ

不確実性に立ち向かう品質マネジメント

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

開発現場では、品質に関する判断に迷ったり、リスクを後追いで発見してしまう経験のあるエンジニアを想定しています。
職種としては、開発者・QAエンジニア・テックリード・マネージャーなど、チームでプロダクト開発に関わる方を幅広く対象としています。
品質マネジメントやリスクマネジメントの専門知識がなくても理解できる内容ですが、日々の開発プロセスに課題意識を持っている方ほど共感しやすいと思います。
特に「不確実な環境での意思決定」や「リスクとどう向き合うか」に興味のある方におすすめです。

トーク概要

私は全てのマネジメントの目的は"リスクを見つけ「なるべく早く」対処することが本質だと考えています。
このトークでは、リスクを「なるべく早く」見つけるために工夫しているノウハウを共有します。

変化の激しい開発環境では、不確実性に起因する判断ミスやリスクの見落としが、重大な品質問題へと発展することが多くないと思います。
本トークでは、私がエンジニアとして取り組んできた、そうしたリスクに向き合う考え方と実践について発表します。

過去には、曖昧な仕様や品質知識の不足により十分なテストが行えず、リリース遅延や品質低下を招いた経験があります。
現在、その経験を教訓に、リスクを「プロジェクトリスク」と「プロダクトリスク」に分類し、それぞれに応じた対応を開発プロセスに実施する取り組みを行ってきました。
具体的な例としては、リスクを見分けるのための会議体を設け、開発チームと早期に情報を共有し、設計段階から品質に向き合えるプロセスを整備しました。
これにより、仕様検討段階での認識のずれや改善事項を前倒しで発見・対処する等、リスクの顕在化を未然に防ぐ効果があった。
不確実性が高まるなかで、品質に向き合うためのマインドセットと品質マネジメントの両面から対応した実践的アプローチを紹介します。

皆様にとって、現場で再現可能な品質マネジメントのヒントを提供できれば幸いです。

本トークは、昨年YAPC函館や本年開催のSQiP2025に関連する内容です。
YAPC函館）https://fortee.jp/yapc-hakodate-2024/proposal/da4c92fe-0a90-4fd1-9eec-946ce046c1e2
SQiP2025）https://www.juse.jp/sqip/symposium/detail/day2/#b3-2

【テーマ】
複雑なビジネスロジックを持つ機能の設計についての、現実的なアプローチ

【想定する参加者層（前提知識）】
要件定義や設計から開発まで担当しているソフトウェアエンジニアを主な対象とします。
特に、複雑なビジネスロジックの実装で悩んだ経験のある方はきっと共感できる内容となっています。
他には、今後そのような業務を行う予定、または興味を持っている方も歓迎します。

MVCやオブジェクト指向、アジャイルな開発手法についての知識があると、より深くトークを楽しめると思いますが、それらを特別に意識しない、普遍的な「設計思想と現実的な判断基準」に焦点を当てたトークをする予定です。

※特定の業界知識は不要です。
※スピーカーは、Ruby on Railsで開発を行っていますが、設計思想と現実的な判断基準が中心となるため、他言語・他フレームワークのエンジニアにも十分応用可能な知見を提供します。

【トーク概要】
私の所属する会社では、クライアントと保証契約を締結するために必須の与信審査をRuby on Railsでプログラムのソースコードに落とし込んで自動化し、現在に至るまで約2年間運用してきています。

月間1万件を超えるこの審査業務は、与信に関する高度な専門知識や経験、柔軟な判断を要し、「プログラミングによる自動化に向かない」領域とされてきました。
しかし、私たちは、アジャイルなアプローチで開発を進め、「将来が読めない」という現実と向き合いながら、必要に応じて進化できるシステムを、泥臭くも丁寧に築き上げてきました。

本セッションでは、教科書的な設計原則と現実が衝突した際に、どのように設計判断をすればよいのか、具体例を交えながら、私自身の経験を踏まえて知見を共有します。
具体的には、以下のような内容について話します。

・拡張性を生む骨格設計：すべての土台となる基本ルールを、一番初めに明確化することの必要性
・Fat Modelを恐れない：ロジックをModelに集約させることで得られる凝集度と保守性
・判断基準を「設定」として切り出すコツ：個別パターンのビジネスロジックをカテゴリ化し、設定として切り出すことのススメ
・それでも吸収できない例外パターンへの対処法：可能な限りのグループ化と、最終手段としての影響を最低限に留めるハードコーディング/割り切りの判断基準

これは単なる「実装事例」ではなく、複雑なドメインロジックに日々格闘する全てのエンジニアに贈る、泥臭くも強いコードを生み出すための設計哲学と実践録です。
理想と現実のギャップに悩むあなたの現場に、即戦力となる「泥臭くも強いコード」を生み出すためのヒントを持ち帰ってください。

LLM の登場で、Chrome 拡張のようなシンプルな構成でホスティングする必要のないアプリは Vibe Coding だけで驚くほど簡単に作れるようになりました。
しかし、それを「継続的に」開発・運用しようとすると、

・動作確認はどうする？
・毎回、開発者コンソールからzipを手動アップロードするのは面倒

といった壁にぶつかり、Vibe Coding の手軽さが失われます。

本セッションでは、私が個人開発している Chrome 拡張の実際の開発環境を題材に、Chrome 拡張の E2E テスト自動化の方法やデプロイの自動化といった継続的開発を行うための開発手法を紹介します。
この Chrome 拡張の開発はすべて Vibe Coding で行われており、私は要件の指示とコードレビューのみ実施しています。この経験を紹介することで、LLM 時代の新しい開発プロセスとそのリアルな実践値を共有します。

【想定する参加者層】
・Chrome 拡張の開発に興味がある方、または開発で面倒さを感じている方
・特に、Chrome 拡張のE2Eテスト自動化や自動デプロイに関心がある方
・Vibe Coding やプロンプトエンジニアリングの実践例に興味がある方
・CI/CD や開発環境の自動化・効率化に関心がある方

【このセッションで得られること】
・Chrome 拡張のテストやデプロイを自動化する具体的な手法
・Vibe Coding での開発サイクルの実例

高可用性を実現するために冗長化の設計をしてみたものの、「机上の確認では問題なさそうだが、実際に障害が起きた時に本当に動作してくれるかわからない」と不安になることは誰しも経験があるのではないでしょうか。少なくとも自分はあります。特にKubernetesの設定は複雑で本当に機能するのかに自信が持てませんでした。
ではどうするか？という一つの回答として、できるだけ障害に近い状況を再現して試してみました。今回はKubernetesのPDBやトポロジー制約等のアプリケーションの可用性を担保する仕組みを諸々設定し、さらにAWS Fault Injection Simulator（FIS）を活用してカオスエンジニアリングとして意図的に障害を発生させ動作確認をしました。
本セッションでは、設定した可用性対策についての解説とそれを実際に検証して上手くいったことや上手くいかないことを赤裸々にお話しします。

■ テーマ
システム分離、リプレース、テスト、移行戦略

■ 想定する参加者層
中級者以上を対象
安全なシステム分離、移行戦略に興味のある方

■ トーク概要

新卒4年目、ECサイト構築サービス「カラーミーショップ byGMOペパボ」のエンジニアです。今年1月に別のサービスから異動し、ジョインして間もなく、私は「レンダリングシステムを分離する」というミッションを任されました。
カラーミーでは、自分のショップのデザインを「デザインテンプレート」という機能で、独自の記法のテンプレートを用いて自由にカスタマイズすることがあります。この機能は、内部ではカスタマイズされたテンプレートをレンダリングする責務を担ったアプリケーションによって実現されています。

しかしこのアプリケーションには、ショップページの「テンプレートレンダリング処理」に加え、そのテンプレートに必要なデータを取得する「データ取得処理」、その他、他のシステムから参照されるさまざまな責務が密結合していました。 この構成は、柔軟性のあるシステムの実現や、パッケージのアップデートを難しくする可能性を秘めていました。
この課題を解決し、より柔軟で堅牢なアーキテクチャを実現するため、「テンプレートレンダリング処理」の責務を別のアプリケーションに分離する必要がありました。

もちろん、サービスを止めることは許されません。 その上で、別のアプリケーションに分離した上でも、レンダリング結果が変わらないことを保証する必要があります。そこで私が採用したのが、稼働中のシステムを徐々に新しいシステムへ置き換えていく「ストラングラーフィグパターン」と「ペンギンテスト」の考え方です。

ストラングラーフィグパターンは、システムを段階的に移行するための手法、そしてペンギンテストは、NE株式会社のさくらいさんがブログで紹介している、システムの移行前と移行後の動作を担保するための手法です。後者は、新旧両方のシステムに同じリクエストを流し、その結果を比較検証することで動作を担保するアプローチです。

本登壇では、異動して半年の私が、このシステム分離にどう立ち向かったのか。 ストラングラーフィグパターンとペンギンテストを参考にした具体的な戦略、新旧の安全な切り替え手法、移行中に実感したペンギンテストのメリット、そして無事に分離を完遂するまでの道のりをお話しします。

この発表を通じて、システムの安全な移行戦略や、段階的なリリースの具体的なノウハウを持ち帰っていただけます。

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

【テーマ】

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

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

・想定する参加者層

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

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

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

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

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

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

私の所属するプロダクトは開発者が数十名まで拡大していましたが、SREは長らく2名体制のままでした。この状況で、問い合わせが来るたびにSREが情報共有ツールのKibela上で関連ドキュメントを探し出し、繰り返し同じ説明をすることに時間を費やすことが発生していました。
解決策としてNotebookLMの導入を試みましたが、KibelaのMarkdown形式を直接NotebookLMに取り込むと、回答の根拠となるソース表示が崩れる問題に直面。NotebookLMの回答における情報ソースとしての信頼性を担保できませんでした。この課題を解決したのが、NotebookLMと相性の良いGoogle Docsです。本トークでは、私の専門外のApps ScriptをGeminiと対話しながら構築し、KibelaからGoogle Docsへのドキュメント同期ツールを自動で作成し、NotebookLMに取り込むまでの一連のプロセスを共有します。この対応により問い合わせ工数の削減だけでなく、多国籍チームの開発生産性向上という思わぬ価値も発見しました。AI活用の障壁を乗り越えた実践的な問い合わせ削減の実例をお話しします。

[想定する参加者層]
・社内ドキュメントの管理や活用に課題を持つエンジニア
・Gemini、NotebookLMの具体的な業務活用事例に興味がある方
・多国籍な開発チームの生産性向上に関心がある方

[前提知識]
・ドキュメント管理ツール（Kibela, Google Docsなど）の利用経験
・AIチャット（Gemini, NotebookLMなど）への基本的な関心
※Apps ScriptやJavaScriptの深い知識は不要です。

テーマ

ORMやフレームワークに依存しない、SQL主導のDBマイグレーション。
スキーマを長期的に管理するための合理的アプローチを、ツールと思想の両面から考察します。

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

• Webサービス等のDB設計や運用に関わるエンジニア
• ORMやフレームワークのマイグレーション機能を使った経験がある方

トーク概要

ある程度経験を積んだエンジニアなら誰しも一度は「これはSQLで書いたほうが早い」と感じたことがあるでしょう。
ORMやDSLによるDB操作は安全面など様々なメリットがある一方で、RDBMSの機能や性能を限界まで引き出すことはできません。
DBのマイグレーションに関しても同様に、SQLで書きたい、あるいは書かざるを得ない場面が稀によくあります。

データの寿命がサービスのそれよりはるかに長いことはよく知られています。ではスキーマの寿命はどうでしょう。
スキーマはDBと共に生きるものであり、フレームワークやライブラリ、ツールといった周辺技術よりもずっと長命なのです。
寿命の短いものでスキーマを管理するより、DBと寿命をともにするSQLを用いるのが合理的ではないでしょうか。

一方で、SQLだけでDBマイグレーションを運用するには多くの課題があります。
本セッションでは、SQLだけで安全かつ確実にDBマイグレーションを行うために必要な要素を整理し、それを支えるためのツール「migy」とそのコンセプトを紹介します。
SQLをマイグレーションの中心に据えてRDBMSの力を最大限に活かしつつ、長期的な信頼性を実現するためのアプローチを提案します。

ゴール

• 熟練エンジニアがSQLに立ち返る理由を、技術要素の寿命構造から理解する
• スキーマ・データ・アプリ・ツールのライフサイクル関係を整理し、SQLで管理する合理性を掴む
• SQLによるマイグレーションの課題とその克服方法を通じて、ORMやFWに依存しない持続的なデータ管理の視点を得る

---私はこんな人！---
私は日頃、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/

■ 対象聴衆／前提スキル

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

概要

エンジニアとして実務に携わり始めた私は、最初の数ヶ月で数々の"しくじり"を経験しました。
例えば、SQL の条件指定ミスでスコープ外のデータが見える危険なバグを作成したり、「善意のリファクタリング」が先輩の変更とコンフリクトして修復不能に陥ったり...。さらには、AI レビューツールの提案を鵜呑みにして無駄な修正を繰り返すという、しくじりも経験しました。
しかし今となって思うのは、これらの失敗こそが最高の学習材料でした。特に AI ツールを活用するようになってから学んだのは、AI やツールが答えをくれる時代だからこそ、「自分の頭で考え、判断する力」が重要であるということです。
このセッションでは、ジュニアエンジニアが現場で直面する様々な課題と、そこから学んだ「AI 時代に必要な判断力」について等身大でお話することで、これから同じ壁にぶつかるジュニアエンジニアや、彼らを支える先輩エンジニアの助けになる時間にしたいと思います。

対象者

• 実務 1 年目前後のジュニアエンジニア
• ジュニアエンジニアを育成・レビューするメンター
• チーム開発に慣れず悩んでいる初学者
  ※主な言語は Ruby ですが、特定技術の知識は不要です

トーク構成
第 1 章：新米エンジニアの洗礼

• 初めて直面する膨大なソースコードに戦々恐々

第 2 章：俺のしくじりを超えてゆけ

• データ流出寸前！SQL 条件指定の落とし穴
• これが車輪の再発明！？
• 「それ…AI がやりました！」問題
• 原因は…エラーメッセージに書いてありました
• 善意のリファクタリングが招いた大惨事

第 3 章：AI レビューツール導入編

• 激突！！CodeRabbit vs Rubocop
• AI 君の嘘つき…！

第 4 章：失敗から得た学び編

• 自分の頭で考えて言語化してみよう
• 失敗を恐れず挑戦しよう
• コードレビューは最高の成長機会

伝えたいこと
AI やツールが正答を示してくれる時代だからこそ、私たちは「判断する力」を磨かなければならないと感じています。
AI は確かに効率的で、間違いを減らしてくれます。
しかし、すべてを委ねてしまえば、自分で考え、判断し、失敗から学ぶ機会が失われてしまいます。

ツールは答えをくれますが、どの答えを採用するかは、最終的に自分が決めなければなりません。
このセッションで伝えたいのは、「失敗を恐れず、自分の考えで決めること」の大切さです。

優秀なエンジニアの成功談ではなく、“何度もしくじりながら少しずつ判断力を磨いてきた ジュニアエンジニア”として、同じように悩む誰かの背中をそっと押せる時間にしたいと思います。

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