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

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

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

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

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

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

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

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

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

得られる知見：

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

想定聴衆

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

テーマ

Webに関する様々な情報がまとめられている MDN Web Docs に、日本語翻訳で貢献する方法を紹介します。OSSコントリビューションの第一歩として、翻訳を通じてWebの知識を広める活動を取り上げます。

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

GitやGitHubの基本操作（git pull / commit / push）を理解しており、Node.jsの環境が整っている初級〜中級レベルのWebエンジニアを想定しています。
OSSへの貢献に興味がある方、英語のドキュメント翻訳に挑戦してみたい方も歓迎です。

トーク概要

Webアプリケーション開発者であれば、一度は見たことがある MDN Web Docs。
この膨大なドキュメントの多くは、世界中の開発者コミュニティによって日々翻訳・更新されています。

本セッションでは、MDN Web Docs 日本語翻訳コミュニティのガイドラインに沿って、誰でも簡単に翻訳に参加できるプロセスを、初心者の立場からわかりやすく紹介します。
環境構築から翻訳の反映までの流れ、貢献時のポイント、そして実際に翻訳して感じた「MDN翻訳の面白さ」や「学び」を共有します。

英語が得意でなくても、翻訳活動は技術理解を深め、世界中のエンジニアとつながるきっかけになります。
OSSに関わる最初の一歩として、MDN翻訳の世界を一緒に覗いてみましょう！

テーマ

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 として伸ばしているかの整理
• 研究ベンチマークが開発現場でどの程度・どの領域に起用できるかを考え、議論するための視点

テーマ

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

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

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

トーク概要

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

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

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

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

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

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

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

Python風言語でプログラミングするゲーム「農家は Replace() されました」のエンドコンテンツ、リーダーボードをモブプログラミングします。
より効果的な農場をプログラミングして世界中のプレーヤーとタイムを競いましょう！

Webサービス開発、特に自社事業の開発では、機能要件と非機能要件がしばしば明確に分けて扱われます。
企画や施策を実現し、売り上げるを上げるものは「機能要件」、パフォーマンス・UX・セキュリティ・アクセシビリティなどの領域は、「非機能要件」として扱われます。

果たしてここで分類された非機能要件は、本当に非機能的なものでしょうか。

本セッションでは、「機能要件」と「非機能要件」と二分化された分類を1からもう一度捌き、これらが離散的ではなく連続的に捉えるものであり、エンジニアだけではなく全ロールの人が向き合う必要があるという考察をします。

想定参加者:

• Webサービス開発者(エンジニア、デザイナー)
• プロダクトマネージャー・プロダクトマネージャー
• カスタマーサポート・セールス

テーマ

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

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

初心者向け

トーク概要

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

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

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

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

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

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

【テーマ】
・ AWS の IAM RoleやIAM Policy、およびAWSにおけるアクセス可否の判定の仕組みなど

【想定する参加者層】
・ AWSを業務・私用問わず触っている方
・ IAM RoleやIAM Policyについて詳しく知りたい方（特にIAM RoleのAssumeRoleやPrincipalなど）
・ アイデンティティベースポリシー、リソースベースポリシーなどポリシーの種類やそれによる最終的なアクセス可否の判定について知りたい方

【トーク概要】
2025年もいろいろなセキュリティ事故がニュースになり、特に2025年後半はサプライチェーン大手企業に対する攻撃により、我々の生活に関係するほどの影響がありました。
このようなセキュリティ事故ですが、「セキュリティ関連の設定不備」が原因となる事例がかなり多いのも事実です。
IPAの「情報セキュリティ10大脅威 2025」でも3位となっていることからも、「セキュリティ関連の設定不備」がどれほど致命的であるかがわかります。

そしてAWSにおいてセキュリティの基本であり、かつ最も重要なもの、それはIAM PolicyとIAM Roleです。
しかし、それだけ重要なIAM PolicyとIAM Roleですが、意外と十分に理解しきれていない、という方もいらっしゃると思います。
特にIAM RoleのAssume RoleやPrincipal、そしてアイデンティティベースポリシー、リソースベースポリシーなどの各種ポリシーが
複雑に絡み合った場合のアクセス許可・拒否判定の挙動がどうなっているかについて、なかなか把握できないという方もいらっしゃると思います。

そこでこのセッションでは、そんなセキュリティ的に最重要項目であるIAM PolicyとIAM Roleについて、
・ IAM PolicyとIAM Roleの基本
・ IAM RoleのAssume RoleやPrincipal
・ 各種ポリシーが複雑に絡み合った場合のアクセス許可・拒否判定のしくみ

についてお話しし、皆さんが携わっているシステムにおいて、思わぬセキュリティ事故が発生することを防ぐためのお役に立てればと思います。

【セッションゴール】
・ IAM PolicyとIAM Roleの基本、およびAssume RoleやPrincipalなどの仕組みを理解できるようになる
・ AWSにおけるアクセス許可・拒否判定のしくみを理解できるようになる

概要

人生で何度も入力したことのある住所フォーム。
しかし、入力するたびに「郵便番号のハイフンの有無でエラーになる」「全角しか受け付けない」「ブラウザの自動補完が効かない」など、細かな苛立ちを感じたことはないでしょうか。

では、ユーザーにとって使いやすく、迷いのないフォームを作るにはどうすればよいでしょうか。
その判断の指針となる考え方として、「驚き最小の原則」があります。
この原則は「どう振る舞うべきか迷ったときには、相手が最も驚かない選択をする」という考え方です。

このセッションでは、住所フォームを題材に「驚き最小の原則」を具体的な設計判断に落とし込む方法を紹介します。
具体的には次のような内容を予定しています。

• サービスにおける「住所」という重要情報の立ち位置
• 「驚き最小の法則」とは何か、サービス開発ではどのように応用できるのか
• 住所フォームでのHTMLで構築するための input 要素や select 要素、または補強する属性 (placeholderなど）の正しい使い方
• システムによる住所自動入力と、ユーザーの意図した手動入力を両立させる工夫

日々 UI を設計・実装するエンジニアに向けて、ユーザーが自然に感じる動作を実現するための具体的な指針を提供します。
セッションを聞いた後、判断に迷ったときには「驚き最小の原則」に立ちかえり、より良い選択ができるようになることをゴールとします。

想定する参加者

• UI を実装する際にどのような画面を作ればよいか判断に迷う初級〜中級エンジニア
• UI 設計の判断基準をジュニアエンジニアに伝えていきたいベテランエンジニア
• 専任のフロントエンドエンジニアやデザイナーがいない現場で UI を作る必要があるエンジニア

想定する参加者に持ち帰ってほしいこと

• サービス開発をしていて迷ったときに「ユーザーが驚きが少ない選択」を取れるようになる「驚き最小の原則」という判断軸を身につけること
• input 要素や select 要素など、フォーム構築する上で必要なHTML要素を定義に沿って正しく使うこと

【テーマ】
アプリケーション設計において、「この処理はどこに置くべきか？」という問いは常につきまといます。
特にオブジェクト指向言語では、クラスやオブジェクトが自由に設計できる反面、責務と状態の境界が曖昧になりやすく、気づけば副作用があちこちに散らばります。
一度拡散した副作用は、バグやテストの不安定さを呼び、まるで割れ窓理論のように保守性の低下を加速させます。

本テーマでは、オブジェクト指向設計の原則（単一責務・不変条件・副作用の分離）に立ち返り、
「コールバック・イベント・非同期処理といった選択肢の中で、どのように責務と状態の境界を見極めるか」を体系的に整理します。
具体的な設計判断の基準と、現場で使える“判断ツリー”を共有することで、日々の開発における「処理をどこに置くか問題」に自信を持って向き合えるようになることを目指します。

【想定する参加者層】

• オブジェクト指向プログラミングの基礎（クラス・責務・状態）を理解している方
• 何らかのオブジェクト指向言語（Ruby / Java / PHP / Python / TypeScriptなど）で業務アプリケーションを開発している方
• ミドル〜シニア層のエンジニア（コード設計やレビューを担う人）

※発表者はRailsエンジニアであり、サンプルコードはRubyで示しますが、設計原則は言語・フレームワークを問わず応用可能です。

【トーク概要】
「コールバックに書くべき？」「イベントに切るべき？」「非同期に逃がすべき？」
日々の開発で誰もが悩む“副作用をどこに置くか問題”に悩むかと思います。この判断をセンスや慣習に頼らず、オブジェクト指向設計の原則に基づいて整理するのが本トークの目的です。
副作用を

1. エンティティ内部の不変条件を守る処理（DB内で完結）
2. 状態確定後の通知（他の関心へ伝える）
3. 外部I/Oや重い処理（非同期・再試行を前提とする）

という3層に分類し、それぞれをコールバック／ドメインイベント／非同期ジョブに対応づけた「設計判断ツリー」を提示します。
また、現場で陥りがちなアンチパターンとして

• コールバックが連鎖して依存が見えなくなる
• 順序依存で動作が壊れる
• ロールバック後に外部I/Oが発火してしまう

といった問題を、責務と状態の境界設計の観点から分解します。実際のコード例（Rubyで示します）を通じて、「副作用をどこに置くべきか」を説明できるようになることを目指します。

テーマ

Webアプリケーションにおけるファイルアップロード機能のセキュリティリスクと、実装時に考慮すべきベストプラクティスを解説します。

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

初心者〜中級者のエンジニア

• 基本的なWebアプリケーション開発の経験がある方
• ファイルアップロード機能を実装したことがある、またはこれから実装予定の方

トーク概要

CSV一括登録、プロフィール画像の登録、動画音声ファイルのアップロード――これらは多くのWebサービスに不可欠な機能ですが、その実装、本当に安全ですか？

「拡張子をチェックしているから大丈夫」

「Content-Typeを見てるから大丈夫」

こんな風に思っていませんか？実は、それだけでは不十分かもしれません。

本セッションでは、以下の4つのステップで当たり前の機能の裏に潜むセキュリティリスクを解説。ファイルを介した深刻な攻撃手法を具体的に示し、安易な対策では防げない見落とされがちなポイントと、いますぐ導入できる具体的な防御策をお伝えします。

1. 実際に動く「危険なコード」のデモ

2. ファイルアップロードに潜む主な脆弱性

3. セキュアな実装のベストプラクティス

4. 実装チェックリスト

このLTを通じて、ファイルアップロードの「危険性」に対する意識が変わり、皆さんのコードのレベルを引きあげることができるはずです。

もう「拡張子をチェックしたから大丈夫」とは言わないはず。

安心・安全なサービス開発を、共に実現しましょう！

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

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

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

テーマ

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をもっと気持ちよくできそう！」と感じられることを目指します。

▪️テーマ

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

Nxの被害など、npmパッケージのサプライチェーン攻撃が現実の脅威となった今、開発環境のセキュリティ対策は全ての開発者にとって避けられない課題です。

本セッションでは、実際の攻撃事例から学ぶ教訓をもとに、今すぐ実行できる対策から1Password CLIとコンテナ技術を組み合わせた理想形まで、段階的にセキュリティを強化していく現実的で実践的なアプローチを紹介します。

AIと共創する時代に、プラットフォームをどう設計すべきか？

AIやAIエージェントが開発のパートナーとなったAgentic AIの時代には、「生成AI／エージェントとのコラボレーションを支えるプラットフォームづくり」が欠かせません。
開発者が創造性を発揮できる「自由」を確保しながら、AIが扱う膨大な開発データや知識をどう「統制」するか。プラットフォームの自由と統制のバランスを見失うと、生産性の低下だけでなく、情報漏洩やシャドーAIのリスクにもつながります。
開発者が創造性を発揮できる「自由」を確保しながら、AIが扱う膨大な開発データや知識をどう「統制」するか。そのバランスを見失うと、生産性の低下だけでなく、情報漏洩やシャドーAIのリスクにもつながります。Agentic AI時代においては、プロンプトエンジニアリングを超えて、AIのコンテキストとなるデータをどう整備し、プラットフォーム全体をどう設計するか――つまり、AIが“理解しやすい環境”そのものを構築することが必要です。

本セッションでは、Platform Engineering と Context Engineering をひとつなぎで捉え、AIのパフォーマンスを最大化するための開発基盤設計と、プラットフォームにおける最適なデータマネジメントを探ります。また、機密データの漏洩、モデル汚染、プロンプトインジェクションなどの「生成AI時代ならではのプラットフォームに対する脅威」にどのように備えるか、ガードレールとしてのDevSecOpsやポリシー設計の観点から、「ゴールデンパスとしての自由」「統制しすぎないガバナンス」「AIとの安全なコラボレーション」を実現するためのプラクティスを、具体的なアーキテクチャや事例を交えてご紹介します。

Agileがクライアントと開発者の協調に挑んだように、DevOpsがDevとOpsのコラボレーションを追求したように、
Agentic AI時代は、人とAIのコラボレーションのためのエンジニアリングをどのように実現するかが問われています。
人と人、AIと人とのコラボレーションについてinsightを得たい方、AI-readyな開発プラットフォームの構築/運用に興味がある方はぜひご参加ください！

■対象レベル
中〜上級

■想定する参加者

• 開発プラットフォームの構築・運用に関わるプラットフォームエンジニア、DevOpsエンジニア、SREの方
• 生成AI／AIエージェントの活用や導入を検討しているエンジニア・アーキテクト
• 開発生産性や開発体験（DX）の向上とセキュリティの両立に関心がある方

■必要な前提知識

• GitHub や GitLab などの開発プラットフォームに関する基本的な理解
• 生成AIを活用した開発やプロンプトエンジニアリングに関する基礎知識
• 開発生産性や開発体験（DX）の向上とセキュリティの両立に関心がある方

Claude Codeは自律して実装を行えるAIコーディングエージェントです。
Claude Codeは特定のオプションを与えると持ちうる権限の範囲内の操作は何でも行います。
悪い方向に働くと、ホームディレクトリが削除されたり、大事なデータが削除された事例も…

本セッションでは、そんなClaude Codeや他のAIコーディングエージェント全般を如何にして安全に扱うのかプラクティスを紹介します。
具体的には、脅威モデリングの手法であるSTRIDEモデル（なりすまし、改ざん、否認、情報漏えい、サービス拒否、特権の昇格の6つの観点）を応用してClaude Codeがもちうる脅威を分析します。それぞれの脅威に対して、どんな対策が講じられるか、DockerやIaCのサンプルコードを用いてご紹介します。

AIコーディングエージェントは今後生産性を向上する要となりますが、組織として扱うには権限と制約のバランスを考える段階がどこかで発生します。2026年はおそらくその年になるので備えましょう。

セッションという場ではありますが、一方的にお話するというより自分たちのチームで改めて脅威を考えるためのきっかけや、組織での考え方の一助として使っていただければ幸いです。

「IPv4 のアドレスがもうすぐ枯渇する！」と言われ続けてはや◯年。

これは決してオオカミ少年的な話ではなくて IPv4 アドレスの節約・やりくりを頑張っている人たちのおかげでもあると思うのですが、そんな「努力の限界」がいつ来るかについてはわれわれ素人には正確にはわかりません。

そこで、X デー（？）がいつ来ても良いように、今のうちに「完全に理解した」とは言わないまでも「雰囲気は掴んだ」というレベルになっておこう！というのが当セッションの目的です。

■話す内容（一部）

• IPv4 との違い
  • アドレスの構成と表記
  • アドレスの種類
  • アドレスの割り当て方
• ホスト（ノード）間通信
• IPv4・IPv6 共存技術
  • デュアルスタック
  • NAT64 + DNS64
• AWS のリソースを IPv6 で組んでみる
  • IPv6 の仕組みのうち AWS で隠蔽されている（意識しなくても良い）部分について軽く説明
  • IPv6 専用 VPC で組んでみる
  • デュアルスタックで組んでみる
  • 結局 IPv4 パブリックアドレスは減らせるの？（安くなるの？）
  • アプリケーション側での考慮点
• IPv6 を使うときの注意点
  • GitHub、もしかして使えない？
  • マネージドサービスを使わずにメールをまとめて送ろうとすると…？

などなど

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

• IPv4 のことは概ね理解しているが IPv6 については何もわからない方
• 主に AWS を使われている方

テーマ

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

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

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

トーク概要

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

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

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

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

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

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

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

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

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

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

テーマ

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（リンクボタン）を実装するときに配慮すべきことに気づける