• 「とりあえず200を返す」をやめるまで ― Spring Cloud AWSで実装する非同期処理への移行/設計

    30秒以内の応答が求められ、超過すると（仕様上）再送される可能性がある注文APIで、クライアント側の仕様変更を受け、処理が30秒に収まらないケースが増えてきました。現状は「先に200を返して内部処理を継続する」方式で再送自体は回避できていましたが、障害時のリカバリや運用面の課題が顕在化していました。

    本セッションでは、受付と処理を分離した非同期構成へ移行する中で、at-least-once前提の設計（冪等性・状態管理）、並列度の調整、リトライや失敗データの隔離・再処理の設計、負荷試験によるボトルネック特定とパラメータ調整をどのように進めたかを紹介します。

    非同期処理を動かすだけでなく、挙動を理解しながら扱うために行った取り組みをお話しします。本事例は、日用品を中心に扱うECサービス「楽天24」での取り組みです。

    • Regular(20m)
    • Intermediate
    • Spring
    • Cloud
    • Architecture
    • スライド公開予定

  • 10年続くJavaシステムの進化を支える戦略：API・DB・キャッシュの互換性設計

    アプリケーションの進化のためには、JavaやSpring Bootのバージョンを上げていくだけではなく、ユーザーやAPI、データベースなど、アプリケーションの「外」と「境界」を意識した互換性設計が大切です。

    本セッションでは、筆者が長く関わっているSpring Bootアプリケーションを題材として、ビジネスを止めずに進化し続けるための互換性設計の考え方を共有します。
    「痛い失敗」も交えながら、API、永続データ、一時データ（キャッシュ）の3層それぞれについて、具体的なポイントを絞ってお伝えします。

    • Regular(20m)
    • Basic
    • Spring
    • Modernization
    • Practice
    • スライド公開予定

  • AIだと陥りがちなJakarta EE最新技術への移行時の落とし穴とその解決策

    EJBからCDI、XMLベースのWebサービスからRESTful Webサービスへの移行など、レガシー技術から最新のJakarta EE技術への移行は、AIを使えば簡単に済むように思われがちです。
    たしかにAIの支援によりこうした移行が容易になりますが、実際にAIコーディングツールを適用してアプリケーションを変換してみると、表面上はうまく移行できたように見えていても、実際に動作させてみると期待通り動かず悩むことがよくあります。
    長年運用されてきたレガシー資産のモダナイゼーションは多くの企業が抱える課題ですが、AIを適用したとしてもこうした資産を最新技術へ移行することは決して容易ではありません。

    本セッションでは、こうしたレガシー資産のモダナイゼーションにおいて、AI技術がどのような支援となりえて、どのような限界があるのかを解説します。
    EJBからCDIへの移行など、利用する標準仕様の変更を伴う移行にAIを適用する際には、EJBとCDIのライフサイクルの違いからくる動作の非互換のように、仕様の機能差異や設計思想の違いからくる落とし穴に気をつけなければなりません。
    このようなJakarta EE最新仕様へのモダナイゼーションにおけるよくある躓きポイントとその回避策について、実践的なノウハウを中心に解説します。

    • Regular(45m)
    • Intermediate
    • Jakarta EE
    • AI
    • Modernization
    • スライド公開予定

  • AI時代のソフトウェア設計の学び方

    現代のソフトウェア開発では、AI技術の活用があたりまえになりました。

    AI技術を使って効率的かつ効果的にソフトウェア開発がでてきているエンジニアを観察すると、AIの生成結果の評価や、生成結果が思わしくない時のチューニングポイントの発見が高速かつ的確なことに気が付きます。

    その人が体が覚えている鋭い設計感覚が、AI活用にもいかんなく発揮されているように感じます。

    では、このような設計感覚を身に付けるにはどうすればよいでしょうか。このセッションでは、この点をいろいろな視点から掘り下げてみます。

    ・どのような設計感覚がAI活用に役立つか
    ・そのような設計感覚をどうやったら習得できるか
    ・AI以前の時代の設計の学び方と、AIを活用できる時代の設計の学び方に共通点はあるのか、それともまったく別のアプローチが必要か
    ・過去数十年にわたって積み重ねられたきた設計原則、パターン、事例、お手本などを知識として獲得することはこれからも重要か
    ・自分の手を動かしてコードを書きながら設計やリファクタリングを体で覚えることはこれからも重要か

    • Regular(45m)
    • Intermediate
    • Methodology
    • Design
    • スライド公開予定

  • Bootiful Spring AI

    The age of artificial intelligence (because the search for regular intelligence hasn't gone well) is nearly at hand, and it's everywhere! But is it in your application? It should be. AI is about integration, and here the Java and Spring communities come second to nobody. In this talk, we'll demystify the concepts of modern-day Artificial Intelligence and explore its integration with the white-hot new Spring AI project, a framework that builds on the richness of Spring Boot to extend it into the wide world of AI engineering.

    Speakers: James Ward, Josh Long,

    • Regular(45m)
    • Intermediate
    • Spring
    • AI
    • スライド公開予定

  • Computer Programming is Dead; Long Live AI-First Programming

    Computer science graduates are facing an increasingly difficult job market. Recent data shows a sharp decline in employment outcomes for computer science majors, highlighting the mismatch between what universities teach and what employers now demand. The traditional model of teaching syntax first and hoping students eventually build something useful is no longer working. In this keynote we argue that programming as we knew it is effectively dead. The future lies in AI-First programming, built on the simple loop of try, learn, and grow. Learners try building code with AI assistance, learn by unpacking the generated code and asking AI for detailed explanations, and grow by testing and extending real applications. This loop not only builds confidence but also ensures we grow the generation of AI engineers that companies are desperate to hire.

    • Regular(45m)
    • Basic
    • AI
    • スライド公開予定

  • Enum徹底入門

    【概要】
    Java 5で導入されて以来、日々の開発に欠かせない存在となった enum。
    「単なる定数の集まり」として使われがちな Enum ですが、Javaの Enum は「クラス」としての強力な性質を持っており、適切に活用することでコードの堅牢性と表現力を劇的に向上させることができます。

    20分間で、Enum を「なんとなく」使う段階を卒業し、Javaの型システムを最大限に活かす武器にしましょう。

    【アジェンダ】
    - Enumとはなにか
    - JLSでの定義と、コンパイル後の姿
    - Enumのメリットと実装パターン
    - 型により選択肢が絞り込まれるメリット（with 生成AI時代）
    - 複数のプロパティと振る舞いを持つEnum
    - Enumとデータベース
    - 各ORM（Spring Dataなど）でのEnumとカラムのマッピング
    - Enumの利用と進化
    - switch 式における網羅性チェック
    - Java 21以降のパターンマッチング
    - Enum vs Sealed Class

    【話さないこと】
    - Java 5未満の古い代替手法（int 定数など）の詳細な歴史
    - 他言語との比較ではなく、Javaの言語仕様とエコシステムに100%フォーカスする

    • Regular(20m)
    • Basic
    • Java SE
    • スライド公開予定

  • Gradle×GitHub ActionsでCI時間を約50%短縮 ─ ジョブ分割の設計と落とし穴

    生成AIでコーディング速度が上がった今、開発サイクルの新たなボトルネックの1つがCIの待ち時間です。
    本セッションでは、Java/Spring Boot/GradleプロジェクトのCI実行時間をGitHub Actionsのジョブ分割で約50%短縮した実践知を共有します。
    並列化後に生じた215秒ものジョブ間の偏りを、テスト実行時間の均等化を目的としたパッケージベースの分割戦略で15秒まで改善した設計判断。
    SpotlessやJaCoCoといったツールの内部挙動に踏み込んだfetch-depthやGit戦略の最適化。
    さらに半年分のCI失敗データ分析に基づくlint/test並列化の意思決定など、現場で直面した落とし穴とその乗り越え方をお話しします。
    GradleとGitHub Actionsを利用してCIを速くしたいと考えている方に、ジョブ分割の設計指針と最適化の判断基準を持ち帰っていただける内容です。

    • Regular(20m)
    • Intermediate
    • Java SE
    • DevOps
    • Tools
    • Test
    • スライド公開予定

  • Inside Stream API

    Java 8でStream APIが提供開始されたのが2014年。最近では、Java 24でStream Gathererという中間操作の大幅なアップデートもありました。Stream APIを使いこなすことは、現代のJavaでは必要不可欠です。

    しかし、Stream APIがどのように実装されているか、あまり触れられていないのではないでしょうか。Stream APIを使うとなぜ高速にループ処理ができるのか、ラムダ式をどのように処理しているのかなど、他のプログラムにも応用できるヒントがいろいろあるはずです。特に、ラムダ式を使うAPIを作成する場合、大いに役に立つはずです。そこで、本セッションではStream APIの実装について、実際のコードを参照しながら解説していきます。

    • Regular(45m)
    • Advanced
    • Java SE
    • Design
    • スライド公開予定

  • Java × distroless で軽量なコンテナイメージを

    Java のコンテナイメージにはフル OS や JDK 全体など、本番実行に不要なコンポーネントが多く含まれています。Google が提供する distroless イメージは shell もパッケージマネージャも持たない最小構成のコンテナイメージであり、攻撃対象領域の削減とイメージサイズの最適化が期待できます。

    一方で、日本語圏の技術記事を調べてみると、Java × distroless については「試してみた」という紹介記事が中心で、具体的な知見はまだ多くない印象です。

    本セッションでは、Spring Boot アプリケーションを題材に 3 つの Dockerfile を段階的に構築し、イメージサイズと構成がどう変わるかを具体的に比較します。

    1. Amazon Corretto をそのまま使う
    2. distroless/java21 に差し替える
    3. jlink でカスタム JRE を作り distroless/java-base に載せる

    さらに、Dockerfile を書かないもう一つのアプローチとして、Spring Boot plugin に内包されている Cloud Native Buildpacks で jlink と runImage のカスタマイズを行う方法も紹介します。`BP_JVM_JLINK_ENABLED` や `BP_JVM_JLINK_ARGS` による必要モジュールの絞り込みなど、実際のビルド設定を共有します。

    加えて、イメージサイズの違いが実際のデプロイにどの程度影響するかを確認するため、AWS のコンテナ実行環境における起動時間の比較結果もお見せします。

    話さないこと:

    - Dockerfile の詳細
    - jdeps / jlink の詳細
    - GraalVM Native Image によるネイティブコンパイル
    - 運用・監視

    ## Outline

    - 導入: distroless についてや本セッションのゴール
    - ベースライン：Amazon Corretto そのまま
    - Step 1：distroless/java21 に差し替える: イメージサイズの変化やイメージが変わることによる影響
    - Step 2：jlink + distroless/java-base で最小構成を作る: イメージサイズの変化や注意点
    - Step 3：Spring Boot Buildpack + jlink: イメージサイズの変化や設定
    - コンテナ起動時間の比較: イメージ pull 含む時間の比較
    - まとめ

    ## Target Audience

    - Java / Kotlin でコンテナベースのアプリケーションを開発・運用しているエンジニア
    - Docker イメージのセキュリティやサイズ最適化に関心がある方
    - Spring Boot を使ったプロジェクトで、コンテナイメージの改善を検討している方

    • Regular(20m)
    • Basic
    • Spring
    • DevOps
    • Security
    • スライド公開予定

  • javadoc 再入門 & AI時代のドキュメント戦略

    JavaDocはJavaのソースコードからHTML形式のAPI仕様書を生成するプログラミングツールです。
    Javaの最初期から存在していますが、このツールの機能についてあやふやな人は多いかもしれません。
    また、Java23では Markdown 形式でのドキュメント記述に対応するなど進化をしています。
    本セッションでは前半では Java 25 時点での JavaDoc 機能を一通り紹介します。
    後半では現代のAIを用いた開発環境も視野に入れて、チーム開発におけるドキュメント戦略はどのようにあるべきかについて解説していきます。
    本セッションに関しては特別な前提知識は必要ありません。

    * JavaDoc 再入門
    * JavaDoc概要
    * JavaDocの歴史
    * JavaDocの機能性
    * ドキュメント戦略
    * 契約プログラミングとJavaDoc
    * 誰の為のドキュメントか？ - ドキュメントの現世利益化
    * 構造化と複雑性の抑制 - 組み合わせ爆発との闘い
    * シャノンの情報源符号化定理 - 情報量の削減限界
    * AIの限界と停止性問題 - 情報理論的に無理なものは無理
    * だから僕らはドキュメントを書く

    • Regular(45m)
    • Basic
    • Tools
    • AI
    • スライド公開予定

  • Javaコミュニティの関心の変遷を可視化する：JJUG CCC 発表データから見る変化と不変

    JJUG CCCでは、毎年 Java に関連する多様なトピックが議論されています。
    本セッションでは、テキスト分析とデータ可視化の手法を使って、直近5年のJJUG CCCの発表データ（タイトル、アブストラクト）を分析した結果を発表します。Java CCC の長い歴史の中で、直近の5年だけではありますが、どんなトピックが注目を集めてきたのか、長年変わらず議論されるテーマは何か、など、データ可視化の視点からJavaコミュニティの関心の変遷を紐解きます。

    可視化結果から過去のイベントを振り返ることで、そのタイミングに参加していた人も、参加していなかった人も、世代を超えたコミュニティの対話のきっかけになればと思います。

    • Regular(20m)
    • Basic
    • Java SE
    • Language
    • Others
    • スライド公開予定

  • Javaで学ぶSOLID原則

    AI主体の開発が進むこの時代、ソフトウェア設計原則はそのガードレールとして新たに価値を見出されています。
    SOLID原則とは、オブジェクト指向プログラミングにおいて、従うべき5つのソフトウェア設計原則と呼ばれています。

    本セッションではSOLID原則とは何か、また従うことによってどのようなメリットがあるのかをJavaコードを交えてご紹介します。

    【対象者】
    - ソフトウェアアーキテクチャに興味があるが、敷居が高く感じられている方

    【得られること】
    - SOLID原則そのものの考え方
    - 保守性、変更可用性が高いコードの実例を知れる

    【話さないこと】
    - Javaに関する基礎知識
    - オブジェクト指向プログラミング(OOP)の概念について

    • Regular(20m)
    • Basic
    • Java SE
    • Architecture
    • Design
    • Practice
    • スライド公開予定

  • Javaで絵文字を正しく扱おう🥲

    Javaでは、文字列を String クラスとして表現しています。そのおかげで、文字コードや内部の実装を詳しく知らなくても簡単に文字列を扱えるようになっています。
    しかし、仕組みを知らないとはまってしまう罠があります。文字数を .length() で取得しようとしてはダメだったり、部分文字列を取得しようとして□（tofu）になってしまったり…

    特に、いまでは絵文字を当たり前に使うようになってきたことで、これらの罠を踏みやすくなりました。
    そこで、このセッションでは文字列の中でも絵文字に焦点を当てて解説をしていきます。
    具体的には、前提知識として絵文字の歴史やその内部表現を説明し、そのうえでJavaで正しく絵文字を扱うための方法をまとめる予定です。

    • Regular(20m)
    • Basic
    • Java SE
    • スライド公開予定

  • Java正規表現エンジン（NFA）の仕組みと、パフォーマンスを維持するための最適化手法

    Java標準の正規表現パッケージ（java.util.regex）は広く利用されていますが、その内部動作については意識されることが少ないのが現状です。
    特定の入力によって CPU 使用率が高騰する ReDoS（正規表現による DoS 攻撃）などの問題は、Java が採用している NFA（非決定性有限オートマトン）エンジンの「バックトラック」という仕組みに起因しています。

    本セッションでは、正規表現エンジンが内部でどのように文字列を評価しているのかを解説し、計算量が爆発する原理を紐解きます。その上で、Java 特有の「独占的量指定子」や「アトミックグループ」を用いて実行効率を改善する手法を紹介します。

    ■ セッションで話すこと
    ・Java の Pattern クラスが採用している NFA エンジンの動作原理。
    ・バックトラックの発生条件と、それが計算量に与える影響。
    ・パフォーマンス改善のための構文（独占的量指定子 ++、アトミックグループ ?>）。

    ■ 話さないこと
    ・正規表現の基本的な構文（メタ文字の解説など）の網羅的な説明。
    ・RE2/J など、DFA ベースの外部ライブラリの比較。

    ■ 想定するオーディエンス
    ・実務で正規表現を「なんとなく」使っているが、その実行モデルや計算量のリスクを詳しく理解していない中級エンジニア。
    ・AIが生成した正規表現をレビューする立場にある開発者。

    • Regular(20m)
    • Intermediate
    • Java SE
    • Methodology
    • スライド公開予定

  • JEP 522 Deep Dive - G1 GC同期コスト削減によるスループット向上を徹底検証&解説

    G1 GCは設計当初から「低レイテンシと高スループットの両立」を目指していますが、この両立は決して容易ではありません。スループット志向のParallel GCと比べ、G1 GCはより多くの処理をアプリケーションと並行実行することでポーズ時間を短縮する一方、その代償としてアプリケーションスレッドとGCスレッド間の同期が増えます。この同期コストこそが、G1 GCのスループット向上を阻む避けがたい障壁なのです。
    2026年3月リリースのJDK 26では、JEP 522「G1 GC: Improve Throughput by Reducing Synchronization」により、この同期コストを削減する改善が行われています。
    本セッションではまず、OSSベンチマークであるRenaissanceを用いて私が行った性能評価の結果を提示し、「どのようなタイプのアプリケーションで、どの程度スループットが向上するのか」や「本当に期待通りの効果がでるのか」を考察します。続いて、本JEPによるスループット向上の核心である、「第2のカードテーブルの導入」や「ライトバリアの命令数の大幅削減」の仕組みや効果について解説します。

    • Regular(45m)
    • Intermediate
    • JVM
    • スライド公開予定

  • JSpecify で実現する Kotlin フレンドリーな Java API 設計

    KotlinからJavaコードを呼び出す際に発生するプラットフォーム型（T!）は、Kotlin の null 安全性を損ない、実行時例外の原因となります。これまではJSR-305やJetBrains注釈が利用されていましたが、Spring Boot 4におけるJSpecifyの標準採用やKotlin 2.1によるJSpecify診断のエラー格上げにより、状況は大きく変化しています。

    本セッションでは、Javaライブラリの作者が、Kotlinから安全に利用できるAPIを提供する方法を提示します。背景としてJavaとKotlinでのnullハンドリングの違い、プラットフォーム型が発生する内部的な仕組みを整理した上で、具体的に付与すべきアノテーションや導入すべきツールを体系的に提示します。

    • Regular(20m)
    • Intermediate
    • Spring
    • Language
    • スライド公開予定

  • JVMと私

    このセッションは、JVMに関連するいろいろな技術的事項について話したり、はたまたそんなJVMが好きという気持ちだけでJVM開発に携わることになった私のキャリアについて話したりするセッションです。
    JVMというのは問題が頻発するものではなく（頻発したら全員が困る）、このセッションで話す技術的事項が直接的にみなさんの業務を助けるということはあまりないでしょう。でも、楽しんです、JVM。当時周囲にいる人たちに私は「JVMのこと学んで何の意味があるの？」とよく言われました。明確な理由はとくにないんですが、とにかくJVMが好きで、好きを公言して10年触り続けていたら段々業務がJVMに近づいてきました。
    意味とか効果とかを超えたこういう思いをコミュニティのみなさんにも大切にしてほしくて、技術だけでなくキャリア開発についても話すセッションです。

    • Regular(45m)
    • Basic
    • JVM
    • Career
    • スライド公開予定

  • Keeping Your Java Hot by Solving the JVM Warmup Problem

    Java bytecodes and class files deliver on the original vision of “write once, run anywhere”. Using a Just-in-Time (JIT) compiler allows JVM-based applications to compile only the code that’s being used frequently and optimise it precisely for how it is being used. Using techniques like speculative optimisation can often deliver better performance than static, Ahead-of-Time (AOT) compiled code.

    However, this flexibility and performance comes at a cost. Each time the JVM starts an application, it must perform the same analysis to find hot spots of code and compile them. This is referred to as the application warmup time.

    In this session, we’ll look at several approaches to how this problem can be alleviated or even eliminated. Specifically:

    • Static compilation of Java code ahead-of time (AOT). Specifically, the Graal native image approach
    • Generating a JIT compiler profile of a running, warmed-up application that can be reused when the same application is restarted, eliminating the need for much of the JIT compilation. This will include details of the work of the OpenJDK Project Leyden.
    • Decoupling the JIT compiler from the JVM for a Cloud environment. Providing a centralised JIT-as-a-Service allows caching of compiled code and offloading the compilation work when new code must be compiled.
    • Creating a checkpoint of a running application. This includes all application state (heap, stack, etc.) in addition to the JIT-compiled code. Project CRaC will be used as an example.

    At the end of the session, you’ll be all set to keep your Java hot!

    • Regular(45m)
    • Intermediate
    • Java SE
    • JVM
    • Modernization
    • スライド公開予定

  • OpenID Connectによるサービス間連携

    今では非常に多くのサービスがOpenID Connectに基づいたトークンを使用したサービス間連携が実行されています。またクラウドの利用やGItHub Actions等のCI/CDでも利用されています。さらにLMSに関連する標準規格 LTI 1.3ではOpenID Connectが採用されています。こうしたOIDCを利用したサービス間連携について解説します。

    • Regular(45m)
    • Basic
    • Cloud
    • DevOps
    • Tools
    • スライド公開予定

  • RestTemplate非推奨化に備えよう！RestClient入門、そしてリニューアルされたSpring Retryでリトライして、WireMockでテストする。

    RestTemplateは、Springで外部Web APIにアクセスする際によく使われてきたクラスです。しかしSpring公式から、RestTemplateはSpring 7.1で非推奨化・Spring 8.0で削除されると発表されました。
    このセッションでは、RestTemplateの代替であるRestClientの使い方、およびSpring Framework 7でリニューアルされたSpring Retryでのリクエストのリトライ、そしてWireMockを使ったRestClientのテストのやり方をご紹介します。

    • Regular(45m)
    • Basic
    • Spring
    • Test
    • スライド公開予定

  • Scripting on the JVM with Java, Scala, and Kotlin

    This talk will explore use of JVM languages as scripting languages, replacing the Bash and Python scripts common throughout the industry. We will walk through live-coded demonstrations of how the JVM's benefits of performance, compile-time safety, and vast library ecosystem are advantages over traditional script platforms, but also how language verbosity, build tool overhead, and lack of convenient libraries hampers the efforts. Lastly we will demonstrate how script-focused tooling is able to smooth over some of those issues, simplifying build configuration and providing suitable libraries to make the JVM truly a world-class scripting environment as robust as any scripting language out there.

    • Regular(45m)
    • Intermediate
    • JVM
    • DevOps
    • Tools

  • SLAs, SLOs, and SLIs: Demystifying SRE

    Reliability is not an accident — it's math. This session builds a clear, working understanding of SLIs, SLOs, and SLAs from first principles, starting with availability math: what the nines actually mean, how multi-service architectures compound failure, and what it realistically takes to move from two nines to four. We define exactly what to measure and why — the difference between infrastructure signals and user-experience signals, and how to derive SLIs that reflect real outcomes rather than server health. The centrepiece is the error budget: what it is, how it's calculated, and how it changes the way teams make decisions. Error budgets turn reliability from a feelings argument into a shared engineering constraint that drives development velocity, architecture choices, and operational maturity at the same time. We close with the SRE maturity arc — the practices, not the tools, that separate reactive firefighting from proactive reliability engineering. You'll leave with a mental model your whole team can use, from developer to architect to ops lead.

    • Regular(45m)
    • Intermediate
    • DevOps
    • Observability
    • スライド公開予定

  • Spring AI × MCP入門 〜AIエージェントへのツール公開、境界設計から始める最小構成〜

    モデルの進化によってAIエージェントへのツール公開手段はMCP・CLI・REST APIと多様化しています。手段が増えるほど「何をどこまで公開してよいか」という境界設計の重要性が増します。この原則は実装手段を問わず普遍的です。Spring AI MCP Server Boot Starterはプロトコル・トランスポート・スキーマ生成を引き受けるため、開発者が書くのは境界設計の部分だけになります。本セッションではその境界設計の要点を4点セットとして整理し、最小構成の実装を通じて持ち帰ってもらいます。対象はSpring Bootで業務APIを作った経験がある方（MCP/AIは入門）です。

    • Regular(20m)
    • Basic
    • Spring
    • AI
    • スライド公開予定

  • Spring Boot における AOT Cache 活用テクニックと起動時間改善事例

    昨今の Java システムのモダナイゼーションではクラウドやコンテナ環境への移行が進んでおり、その中で Javaアプリケーションのスタートアップ時間の長さが課題として顕在化してきました。例えば、サーバレスのような短命アプリケーションにおける実行時間の増加や、オートスケール時におけるノード追加からリクエスト受付可能になるまでの時間増加などが挙げられます。
    OpenJDK コミュニティではこの問題に対処するために Project Leyden を立ち上げ、スタートアップ時間の改善に取り組んできました。その成果の一つとして、Java 24 から AOT Cache が導入されています。今後増加する Java 25 以降のシステムではスタートアップ時間改善の手段としてこの AOT Cache を利用することが一般的になっていくと考えます。
    本セッションでは AOT Cache の基本的な使い方に加え、Java システムのモダナイゼーションとしてよく利用される Spring Boot 向けの AOT Cache 利用ノウハウとそのスタートアップ時間の改善例を紹介します。また Java 25 で導入された JIT のメソッドプロファイリング情報のキャッシュ化によるウォームアップ時間の改善について検証した結果についても紹介いたします。

    • Regular(20m)
    • Basic
    • Spring
    • Cloud
    • JVM
    • Modernization
    • スライド公開予定

  • Spring Security 実践 ─ GraphQL APIで実務に役立つ 認証・認可 を学ぶ

    # セッションの概要
    Spring Securityは、Javaエコシステムにおけるデファクトスタンダードなセキュリティフレームワークですが、その柔軟性ゆえに設定が複雑になりがちです。特に、GraphQLのようなAPI用のクエリ言語と統合する際には、認証・認可の設計において多くの課題が生じます。

    このセッションでは、Spring Securityを用いた認証・認可の設計と実装を解説します。これにより、参加者は実践的な知識を持ち帰り、自身のプロジェクトに適用できるようになります。

    # 想定するオーディエンス
    - Java/Spring Boot開発者（経験半年以上）
    - GraphQLの基本的な概念を把握している方
    - Spring Securityを学びたい方
    - セキュリティに関心のある方
    - Javaを愛している方

    # セッションで話すこと
    - Spring Securityの基礎と設計方法
    - GraphQL APIでの認証と認可
    - 実践的なコードレビュー
    - セキュリティベストプラクティス

    # セッションで話さないこと
    - OAuth2.0やOpenID Connectの詳細な仕様
    - SAMLやLDAPなどのエンタープライズ認証
    - GraphQLの基本的な使い方や導入方法
    - 暗号化アルゴリズムの理論的な背景

    • Regular(20m)
    • Basic
    • Spring
    • Security
    • スライド公開予定

  • switch式で始めるJava流パターンマッチング

    Java 8 のラムダ式や Stream API、Java 14 の switch 式をはじめ、近年の Java には関数型的・ステートレスな実装を支援する言語機能が数多く追加されてきました。
    本セッションでは、関数型言語におけるパターンマッチの思想を出発点に、switch 式、pattern matching for instanceof、sealed、record などを組み合わせた「Java流パターンマッチング」の実践的な使い方を紹介します。

    • Regular(20m)
    • Intermediate
    • Java SE
    • Language
    • スライド公開予定

  • TornadoVMが切り拓くJavaの新領域：GPU活用と生成AIへの適用

    現在のAI領域でのコンピューティングにおいて、計算負荷の高い推論処理部分は、GPUを活用するネイティブコードとそれを取り巻くPythonエコシステムが主流となっています。
    一方、AI領域でのJavaの利用は、LLMをリモート呼出しで使うケースにとどまっています。
    そこで、本セッションでは、AI領域でのJavaの利用範囲を広げる可能性のあるTornadoVMを使ったGPU活用方法を解説します。
    JavaでGPUを使うアプローチとしては、OpenJDKのBabylonプロジェクトがありますが、TornadoVMはBabylonとはアプローチが異なり、
    Just-In-Time(JIT)コンパイラによりJavaコードをOpenCL、Nvidia PTX、SPIR-Vなどにコンパイルし、GPU上にオフロードします。
    これにより、Javaエンジニアは、C++、CUDA、Pythonエコシステムなどに頼らず、ヘテロジニアス環境を透過的に扱えるようになります。

    本セッションでは、TornadoVMのアーキテクチャや、使用方法をデモを交えて紹介します。
    また応用例として、LangChain4jにおいて、TornadoVMを利用して推論処理を高速化するユースケースを紹介します。

    • Regular(45m)
    • Advanced
    • Java SE
    • JVM
    • AI
    • スライド公開予定

  • スパゲッティコードの次はカッペリーニコード？― AI時代に問われる設計責任 ―

    ◆セッション概要

    □背景・問題提起

    AIエージェントがコードを書く時代になりました。
    Claude Code や Copilot の登場により、私たちは短時間で整ったコードを手に入れられるようになっています。

    しかし――
    コードがきれいであることと、設計が健全であることは同義でしょうか。

    AIはクラスを細かく分割し、責務を整理します。
    Javaの進化（record、sealed class、Virtual Thread など）も、その分割をさらに容易にしています。

    分割そのものが問題なのではありません。
    問題は、設計意図や境界を明確にしないまま分割が進むことです。

    その結果、私たちは次のような構造を生み出してはいないでしょうか。

    ・クラスは小さく整っている
    ・責務も一見整理されている
    ・しかし全体像は把握しづらく
    ・変更の影響範囲が読みにくい

    従来、責務が絡み合い肥大化した構造は「スパゲッティコード」と呼ばれてきました。

    本セッションではその対極ともいえる、
    細かく分割されているがゆえに全体が絡まりやすくなる構造を
    「カッペリーニコード」と定義します。

    ※カッペリーニは非常に細いパスタです。一本一本は繊細で整っていますが、数が増えると容易に絡み合い、扱いが難しくなります。

    □本セッションで扱う内容

    Spring Bootの一般的な構成（Controller → Service → Repository）を前提に、

    ・AIが関心事を細かく分けすぎた結果、処理の流れが見えにくくなる問題
    ・レイヤの役割が少しずつ混ざっていく構造の変化
    ・仮想スレッド導入によって変わる処理の分割と配置
    ・小さなクラスが増えることで、どこを直せばよいか分かりにくくなる問題

    を具体例（Before / After）で整理します。

    □結論

    AI時代に必要なのは「書く力」ではなく「構造設計力」である。

    AIを否定するのではなく、
    Skillsやカスタムインストラクションを活用しながら、
    設計のガードレールをどう築くべきかを提示します。

    ◆アジェンダ（予定）

    ・カッペリーニコードとは何か
    ・スパゲッティコードとの構造的な違い
    ・AIによる分割が招く責務の分散
    ・Javaの進化と設計境界の変化
    ・並列処理導入時に起きるレイヤ責務の揺らぎ
    ・小さなクラス群が変更予測を難しくする理由
    ・変更の予測可能性を守るための構造ガードレール
    ・AIに与える構造ガードレールの設計思想

    ◆発表の範囲

    話すこと
    ・Javaの進化が設計に与える影響
    ・AI生成コードに見られる責務分散の具体例
    ・「分割＝設計改善ではない」という構造視点
    ・変更の予測可能性という設計評価軸
    ・レイヤ責務と依存関係を意識した構造設計
    ・AI時代における設計責任のあり方

    話さないこと
    ・AIツールの操作方法や比較
    ・Java言語仕様の詳細解説
    ・特定アーキテクチャパターンの網羅的説明
    ・パフォーマンスチューニングの詳細議論

    • Regular(20m)
    • Intermediate
    • Spring
    • Architecture
    • AI
    • スライド公開予定

  • チーム全員で実施できるプロジェクトに集中するためのゴール設定を磨くスキル

    「ゴール設定は大事」と分かっていても、実際の現場ではやっている割に効果を感じない、 結局タスク消化に戻ってしまう、そんなモヤモヤを抱えていないでしょうか。
    本セッションは、ゴール設定にはスキルが必要であり、チームとして練度を上げていくことが重要だという前提に立ち、チーム全員が集中できるゴールを作るための考え方とコツを紹介します。
    良いゴールが設定できるようになると、日々の会話が変わります。タスクを終わらせるかではなく、「ゴールに対して今どんな状態か」「次に何を打つべきか」という対話が中心になります。 その結果、
    集中度が上がり、優先度の入れ替えや中止を冷静に判断できる エンジニア自身が次の一手を提案しやすくなる
    といった変化が生まれます。セッションでは、以下のポイントを実践的に扱います。

    ・チーム全員でゴールを作る理由 / 利点
    ・自分たちも含めたステークホルダーの良い状態を毎回イメージしてディスカッションする
    ・SMART・ALIVE・FOCUSを使ったゴール設定の視点
    ・完璧なゴール（青い鳥）を追わず、手元から始める考え方

    ゴール設定を「イベント」ではなく、チームで磨き続けるスキルとして捉え直したい方に向けたセッションです。

    • Regular(20m)
    • Basic
    • Others
    • スライド公開予定

  • テストコードのないプロジェクトにテストを根付かせる

    テストコードがない、あるいはテストコードが存在はするがあまり機能していないプロジェクトに途中から参画したとき、あなたならどうしますか？「テストを書きましょう」と言うだけではチームは中々動きません。

    テストコードが浸透していないコードベースには必ず理由があります。テストを書く時間がない、テストの必要性が共有されていない、あるいはやむを得ない事情で書いていないなど。まずは既存コードとそれを書いてきたチームに敬意を払い、背景を丁寧にヒアリングすることが出発点です。

    本セッションでは、いちメンバーの立場からボトムアップでテスト文化をチームに浸透させた実体験をもとに、技術面だけでなくチームコミュニケーションの側面にも焦点を当ててお話しします。テストを導入するための技術的なステップはもちろん、チームの合意を得るための対話の進め方を共有します。

    • Regular(45m)
    • Basic
    • Test
    • スライド公開予定

  • デプロイを恐れていたSpringチームが、月200回リリースするまで 〜真のリスクは停滞だった〜

    リリースは慎重に行うべきだと思っていた。しかし本当に恐れるべきは、成長の停止だった。
    大量データを扱うBtoB向けDevOps基盤で、月平均200回のリリースを実現したチームの実践を紹介します。
    Spring Bootを中心としたアーキテクチャにおいて、高頻度リリースを支えたパイプライン設計の勘所、組織変化の中で揺らいだ爆速文化の立て直し、インシデントへの向き合い方、そして「真のリスクは、停滞にある」という思想への到達プロセスを、実体験をもとにお伝えします。

    • Regular(20m)
    • Basic
    • Spring
    • DevOps
    • Architecture
    • Test
    • スライド公開予定

  • なぜJavaのジェネリクスには「PECS原則」が必要なのか？ - Scala/Kotlinと比較して理解するワイルドカードの設計思想

    コレクションフレームワークやStream APIのメソッドシグネチャを呼んでいると、? extends T と ? super T が頻繁に登場します。これらのワイルドカードについて、「なんとなく雰囲気で使っている」「どういった場合にこれらのワイルドカードが必要なのかがわからない」という方も多いのではないでしょうか？
    本セッションではこれらのワイルドカードの使いどころを説明するとともに、? extends と ? super を正しく使い分けるための原則である「PECS原則」を説明します。また、ScalaやKotlinにおけるジェネリクスと比較することで、どのような設計思想のもとでJavaのワイルドカードが存在しているのかを理解することを目指します。

    • Regular(20m)
    • Basic
    • Java SE
    • スライド公開予定

  • ビジネスルールを型システムで表現する

    私が開発・運用するシステムでは、ビジネス要件の成長に伴い、1つのクラスに多種多様な状態と処理が凝集し、保守性が低下していきました。
    「nullableなフィールドの組み合わせで状態を表現し、判定ロジックが各所に散らばる」 「新しい状態を追加するたびに、既存ロジックを破壊していないか怯える」
    本セッションでは、こうした課題を解決するために実施した、nullableベースから sealed interface を用いた「型安全な状態管理」へのリファクタリング方法をお話しします。

    • Regular(20m)
    • Basic
    • Architecture
    • Modeling
    • スライド公開予定

  • ふつうのFeature Flag実践入門

    Feature Flagの名前を聞いたことがある方は多いと思います。概念は理解していても、実際にプロダクトへ導入しようとすると設計や運用で悩むことも少なからずあるでしょう。実装自体は「フラグを参照して分岐する」というシンプルなものですが、方針なく適用するとフラグの増殖や複雑化を招きます。これに対し、Feature Flagの目的と解決しようとしている課題を理解すると、設計や運用ポリシーを考えるときにとても役立ちます。

    本セッションでは、基本概念と代表的なユースケースを整理し、設計原則、実装アプローチを紹介し、デプロイ、運用中の切り替え、撤去までと言ったライフサイクルを通した話をSpringBootでの具体的な実装を題材に解説します。
    単にフラグを追加する方法ではなく、どのような状況でどのようなフラグを選ぶのがよいか、そして技術的負債を抑えるために何を考えて適用するかを紹介します。

    • Regular(45m)
    • Intermediate
    • Java SE
    • Spring
    • Design
    • スライド公開予定

  • ユニットテストの先へ：テスト技法で要求・仕様を整理するJava開発実践

    要求や仕様が曖昧なまま実装に入り、後から「そういう仕様だったんですか！」と手戻りが発生した経験はありませんか？
    テスト技法は、ユニットテストを書くときだけのものではありません。同値分割や境界値分析、デシジョンテーブルといった技法は、実は要求や仕様の曖昧さを発見し、チーム内の認識を揃えるための強力なツールです。
    本セッションでは、テスト技法をJava開発の上流工程から活用する方法を実例とともに紹介します。「仕様が曖昧で何をテストすべきか分からない」「レビューで認識齟齬が発生する」といった課題を、テスト技法でどう解決できるかを具体的に解説します。
    対象者：Javaでのテストに課題を感じている方、上流工程の品質向上に興味がある方

    • Regular(45m)
    • Intermediate
    • Tools
    • Test
    • スライド公開予定

  • 不変条件と整合性境界—ビジネスが決める設計判断と実現パターン

    「集約は不変条件を守る」——ドメイン駆動設計を学ぶと必ず出てくる説明です。
    しかし、不変条件とは何でしょうか
    すべての不変条件は集約で守るべきなのでしょうか

    不変条件には即座にトランザクションで守るべき「真の不変条件」と、結果整合性で十分な「プロセス不変条件」があります。
    そして、どちらに分類されるかを決めるのは技術的制約ではなく、ビジネスが「遅延を許容するか」という判断です。
    開発者はACIDであることを好みますが、実際にはドメインエキスパートのほうが遅延に寛容なことが多いのです。

    本セッションでは、不変条件を守る場所として集約・ドメインサービス・ドメインイベントとそれに伴うパターンを整理し、それぞれがどのような整合性を担うのかをJavaコードをまじえながら解説します。
    また、集約とドメインサービスの選択がパフォーマンス・並行性・概念的凝集度といったトレードオフで決まることも示します。

    集約の境界を正しく引くには、パターンの知識だけでなくビジネスへの深い理解が必要です。
    このセッションを通じて、集約の境界を自信を持って引けるようになっていきましょう。

    • Regular(45m)
    • Advanced
    • Java SE
    • Architecture
    • Modeling
    • スライド公開予定

  • 依存関係から依存物へ―Dependencyという言葉の歴史をひも解く

    Dependencyの訳語として「依存性」が定着していますが、用語によっては「依存性」が最適な訳語ではないケースも存在します。たとえばDIを「依存性の注入」と訳す場合、DIが内包する「注入するオブジェクト」の意味合いが伝わらないため、初学者の理解を阻害したり、誤訳だと判断される要因になっています。

    このセッションでは、2000年前後の10年間、Dependencyという言葉が「依存関係」や「依存物」といった複数の意味合いで使われていた事実を示します。関連する英語文献とリファレンスの検証を通じて、Dependencyが「利用される依存物」という意味合いを持つようになり、DIのような用語（用例）および「依存性」という訳語が生まれた流れを描き出します。

    ■こんな人におススメ
    ・Dependency/依存性という言葉を使ってDIを説明したい人
    ・2000年前後のオブジェクト指向デザインにまつわる議論の一部を知りたい人
    ・当時現役であり、自身の経験を振り返りたい人

    ■検証対象
    ・Dependency関連の英語文献
    ・Spring Frameworkなどの原語版リファレンス
    ・インターネットアーカイブ上の2000年代中盤の日本語Webページ

    ■検証対象外
    ・J2EEやJakarta EEの詳しい歴史
    ・各種フレームワークにおけるDIの実装の詳細

    • Regular(20m)
    • Basic
    • Others
    • スライド公開予定

  • 先取りMaven 4 - 16年ぶりのメジャーアップデート、その進化とは？

    Javaのビルドツールとして長年に渡り世界で広く使われているMavenが、16年ぶりのメジャーバージョンアップとなるMaven 4のGAを目前に控えています。

    Maven 4ではコンシューマーPOMの導入により、ビルドに必要な情報と利用者に必要な情報が分離されるなど、これまでになかった機能が盛りだくさん取り入れられています。

    このセッションでは単にMaven 4の新機能を説明するだけでなく、なにがこれまでできなかったのか？課題だったのか？それに対してMaven 4ではどうなるか？どう解決されるか？など、これまでのMavenの「なんだかなぁ」な点を振り返りながら、Maven 4の新機能の良さを説明していきます。

    セッションでは、Mavenにあまり詳しくない方にも理解していただけるよう、推移的依存関係やスコープといったMavenの基本的な仕組みについても簡単に触れます。
    ですので、「Mavenはなんとなく使っているけれど、実はよくわかっていない」「Maven 4で何が変わるのかは気になっている」という方にも参加いただける内容です。

    なお、本セッションは Maven 4の進化を理解することを目的としています。そのため、以下の内容は扱いません。
    - 依存関係の解決やビルドライフサイクルなどMavenの詳細な仕組み
    - Mavenプラグイン個別の詳細な説明
    - Gradleとの比較（私はMaven派なので）

    また、Maven 4は現時点で開発中となります。可能な限り最新情報をもとに解説しますが、正式リリース版では仕様が変更される可能性があります。こちらもあらかじめご承知おきください。

    • Regular(45m)
    • Basic
    • DevOps
    • Tools
    • Others
    • スライド公開予定

  • 変化に強いテストを育てる、Spring Bootのレイヤー設計

    テストの品質を左右するのは、「モックをどこでどう使うか」です。使いすぎると内部のリファクタリングでテストが壊れやすく、バグを見落とすリスクも生まれます。かといって何でも統合テストにすると、実行が遅くなりエラー原因の特定も難しくなります。

    解決策の鍵はレイヤー設計です。レイヤーの責務を適切に分けることで、テストすべきビジネスロジックを実クラスのまま動かしながら、モックが必要な箇所を外部との境界だけに絞り込めます。リファクタリングに強く、速く動く安定したテストを育てることができます。

    本セッションでは、Spring Boot アプリケーションの Controller・Service/UseCase・Repository・外部アクセスなど、それぞれについて、「どう設計するか」と「どうテストするか」の対応を解説します。参照系と更新系でテスト戦略を分けるアプローチ、インメモリ Repository によるモックレスなサービス層テスト、H2 と Testcontainers の使い分け基準など、現場にそのまま持ち帰れる実践的な知見をお伝えします。

    • Regular(45m)
    • Intermediate
    • Spring
    • Architecture
    • Design
    • Modeling
    • Test
    • Practice
    • スライド公開予定

  • 大規模なメトリクス収集の仕組みをアーキテクチャ変更して得た学び

    このセッションでは、メトリクス収集・送信の仕組みのアーキテクチャを変更した話をします。具体的には、Spring BootのServlet FilterとMicrometerを用いた仕組みから、Fluent BitとAWSのサービスを用いた仕組みに変更しました。
    当初の仕組みの課題となぜこのような技術的決定に至ったのか、そして現在それらの課題は解決されたのか、といった点から、大規模なメトリクスデータを扱うアーキテクチャにおける設計観点をお伝えします。

    対象者
    - JavaやWebアプリケーションのアーキテクチャについて基礎的な知識がある
    - ※ AWSのサービス, Servlet Filter, Micrometerについては当日説明します
    - 実用上の大規模なメトリクスデータを扱う現場でのアーキテクチャ選定に興味がある

    • Regular(20m)
    • Intermediate
    • Architecture
    • スライド公開予定

  • 業務アプリケーションでリアクティブ化するところ、しないところ

    セッション概要:
    リアクティブな業務アプリケーションを設計する際に、「非同期/同期」処理をどこに適用するかというガイドラインは広く共有されていないようで、特にClean系アーキテクチャの設計を採るときには判断に困るポイントになると感じています。
    本セッションでは、実際に非同期な業務アプリケーションを立ち上げたときの検討内容から、「モデルの判断は同期、サービスの判断は非同期」という線引きを採用した事例を紹介し、設計判断に資したいと思います。

    ----

    発表要旨:
    リアクティブアプリケーションはリソース効率やスケーラビリティの面で優れていますが、実際に業務アプリケーションをどのように設計するか、という資料は広く共有されていません。すべての処理を非同期に実装すると業務判断が分かりにくくなります。
    どこかで同期・非同期の切り分けをする必要があるのですが、今回は「業務モデルの判断は同期で、[ドメインサービス|アプリケーション]サービス、インフラの判断は非同期で行う」ことで、業務判断にフォーカスしやすい状態を構築する方法を説明します。
    また、これらの設計がRxJava, Mutiny, Spring WebFluxでどのように実装されるかのサンプルを提示し、リアクティブ実装の種類を問わずJavaで実現可能であることを示します。
    まとめとして、以下をテイクアウェイとして提供します。
    ・Clean系アーキテクチャが原則的にリアクティブアーキテクチャと組み合わせ可能であること
    ・そのために守った方がよい線引きの方法

    ----

    アジェンダ(18分):

    1. どこまでリアクティブに書く？(3分)
    - 業務アプリケーションをリアクティブ化するときの疑問
    - 案1 全部リアクティブ
    - 案2 モデルの"判断"とサービスの"オーケストレーション"

    2. 業務"判断"とそれ以外を分ける(4分)
    - 業務モデルとサービスの再確認
    - 判断とオーケストレーションの分離
    - ドメインサービスは？

    3. ちょっとした工夫 - 準正常系の扱い(3分)
    - 正常系以外全部例外の場合
    - Resultパターンの導入
    - 例外とResultの使い分け

    4. 実装はどうなるか(5分)
    - RxJava
    - Mutiny (w/ Quarkus)
    - Spring WebFlux
    - 骨子は一緒

    5.まとめ: 持ち帰り (3分)
    - リアクティブCleanは実現可能
    - 非同期処理をスコープ管理する
    - 業務判断は同期、それ以外は非同期
    - そうでなくても最初に線を引きましょう

    ----

    発表の範囲:
    話すこと
    ・Reactive導入時のアーキテクチャ設計
    ・同期/非同期の境界の決め方
    ・Result型と例外の役割分担
    ・フレームワークに依存しない構造
    話さないこと
    ・ReactiveなJavaの基礎
    ・Clean系の基礎
    ・Resultパターンの説明

    • Regular(20m)
    • Intermediate
    • Architecture
    • Methodology
    • Design
    • Practice
    • スライド公開予定

  • 軽量Java基盤の設計 ー DIコンテナに頼らない、長期保守と1秒起動の実現

    私たちは長年Spring FrameworkやHibernateを採用し、業務アプリケーションを開発してきました。しかし、数十案件を保守する中で次の課題に直面しました。

    - 単体テスト、Webアプリの起動に10〜20秒
    - フレームワークのバージョン更新に伴うマイグレーションコスト
    - 依存関係の肥大化

    従来のDIコンテナに依存する設計では、DIコンテナは多くのクラスをスキャンするため、依存関係の把握が難しく、フレームワークの初期化コストが支配的でした。この状況を打開するため、社内に必要な機能のみを持つ軽量なアプリケーション基盤を、標準APIとシンプルなオブジェクト指向設計を組み合わせて構築しました。

    本セッションでは、基盤構築の流れを実例コードとともに解説します。

    - DIコンテナを用いず、オブジェクト指向設計でDBセッション等の依存関係を管理する方法
    - Java Platform Module System (JPMS)を活用したマイクロカーネル型設計
    - FaaS環境でも高速に起動する軽量アーキテクチャ

    新基盤では、下記を実現しています。

    - クライアントコードの変更なしに、依存ライブラリをバージョンアップ
    - 単体テスト起動1秒未満、Webアプリも1〜2秒で起動
    - AWS Lambdaのコールドスタート2秒以内
    - 依存ライブラリを150MBから20MBへ削減

    本セッションではDIコンテナに依存しない設計を選択肢の一つとして提示します。小規模プロジェクトでも適用可能な、軽量な依存関係管理クラスと疎結合なモジュールの作り方、基盤の高速起動のコツをコード付きで共有します。

    • Regular(20m)
    • Intermediate
    • Java SE
    • Architecture
    • スライド公開予定
Session and Speaker Management powered by Sessionize.com