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

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

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

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

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

    Room A+B
    土 10:00 - 10:45
    • Regular(45m)
    • Advanced
    • Java SE
    • Architecture
    • Modeling
    • スライド公開予定

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

    RestTemplateは、Springで外部Web APIにアクセスする際によく使われてきたクラスです。しかしSpring公式から、RestTemplateはSpring 7.1で非推奨化・Spring 8.0で削除されると発表されました。
    このセッションでは、RestTemplateの代替であるRestClientの使い方を紹介します。加えて、Spring Framework 7でリニューアルされたSpring Retryを利用して、RestClientと組み合わせてHTTPリクエストのリトライする方法を紹介します。最後に、WireMockでモックサーバーを作成して、RestClientやリトライをどのようにテストするかご紹介します。

    Room C+D
    土 10:00 - 10:45
    • Regular(45m)
    • Basic
    • Spring
    • Test
    • スライド公開予定

  • 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%フォーカスする

    Room F
    土 10:00 - 10:20
    • Regular(20m)
    • Basic
    • Java SE
    • スライド公開予定

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

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

    Room G+H
    土 10:00 - 10:45
    • Regular(45m)
    • Intermediate
    • Tools
    • Test
    • スライド公開予定

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

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

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

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

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

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

    Room I
    土 10:00 - 10:20
    • Regular(20m)
    • Basic
    • Others
    • スライド公開予定

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

    せっかくMCPサーバーを作ったのに、AIエージェントがツール（AIから呼び出せる関数や操作のこと）をうまく使ってくれない。その原因の多くは、モデルでもプロトコルでもなく「境界設計」にあります。
    モデルは進化し、AIエージェントとツールをつなぐ手段も多様化しました。しかし、LLMが利用するツールを開発するとき、実装手段がMCPであろうとCLIであろうとAgent Skillsであろうと、問われる本質は次の4つに集約されます。
    ・どんな操作を公開するか
    ・descriptionをどう書くか
    ・何を返し、何を返さないか
    ・何が起きたかをどう記録するか
    本セッションでは、この4つを「境界設計の4原則」として整理し、Spring AI MCP Server Boot Starter（プロトコル・トランスポート・スキーマ生成を肩代わりしてくれるSpring公式ライブラリ）を使った最小構成のコードに落としてお伝えします。

    ▼ 話さないこと
    ・MCPの全仕様（Resources／Prompts等）
    ・本番運用のスケーリングや認可設計
    ・他言語フレームワークとの詳細比較

    対象はSpring Bootで業務APIを書いた経験のある方（MCP／AIは初めてでOK）です。

    Room M
    土 10:00 - 10:20
    • Regular(20m)
    • Basic
    • Spring
    • AI
    • スライド公開予定

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

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

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

    Room F
    土 10:25 - 10:45
    • Regular(20m)
    • Basic
    • Java SE
    • スライド公開予定

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

    Room I
    土 10:25 - 10:45
    • Regular(20m)
    • Intermediate
    • Java SE
    • Architecture
    • スライド公開予定

  • スパゲッティコードの次はカッペリーニコード？― 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言語仕様の詳細解説
    ・特定アーキテクチャパターンの網羅的説明
    ・パフォーマンスチューニングの詳細議論

    Room M
    土 10:25 - 10:45
    • Regular(20m)
    • Intermediate
    • Spring
    • Architecture
    • AI
    • スライド公開予定

  • 個人AIからチームAIへ：開発における品質と生産性の再設計

    生成AIの普及により、開発者個人がローカル環境でAIを活用することは一般化しました。しかしその一方で、AIを使いこなせる人とそうでない人の間に生産性やコード品質のばらつきが生まれ、組織全体としての開発品質やアウトプットの一貫性を維持することが難しくなっています。また、AI導入による生産性向上が実際にどの程度効果を生んでいるのかを、チーム単位で把握・評価することも容易ではありません。

    本セッションでは、こうした「個人最適化されたAI活用」から脱却し、「チームとしてAIを活用する」ための開発プロセス設計について解説します。プルリクエストを中心とした品質ゲートの構築、Issueやドキュメントを含むコンテキスト統合、そしてチーム内でのAIとの対話を可視化・共有する仕組みを通じて、AI活用を組織の知見として蓄積するアプローチを取り上げます。

    さらに、AIを開発プロセスの各フェーズに組み込むことで、どのように品質と生産性を両立させるのか、また2026年以降に求められるAI投資の対効果をどのように捉えるべきかについても共有します。個人のスキルに依存しない、再現性のあるAI活用を実現したいエンジニアやテックリード向けの内容です。

    Room A+B
    土 11:00 - 11:45
    • Sponsor(45m)
    • Intermediate
    • AI
    • スライド公開予定

  • AI 時代の "Software Engineering" — Server Side Realtime Event Handling を Re−Design した経験から。

    本セッションでは、2023 年 7 月に設立され 2024 年 7 月に現社名で正式に事業を開始した Gen-AX 株式会社が実行している、主力製品 X-Ghost — コールセンターの電話応対を自律的に担う、企業向け AI オペレーター — のサーバーサイドにおける Realtime Event Handling 層の Re-Design プロジェクトを題材に、AI プロダクトを作る難しさ・AI によって可能となった Engineering・そしてその両者の間で揺れる「AI 時代の Software Engineering」のリアルを共有します。

    電話越しに人間が AI と話す、というプロダクトのサーバーサイドは、ふだん「リクエスト → レスポンス」で動いている世界とは少し違う風景をしています。音声として届くユーザーの意図、OpenAI Realtime API、企業の基幹システムも動かす Function Call API 、という 3 方向からイベントが非同期に降ってきて、しかも次のような「素朴に書くと race condition の沼」が日常的に発生します。

    - AI が話している最中に人間が割り込んでくる (barge-in)
    - 割り込みでで `response.cancel` を投げた後にも、その response の遅延 audio が届く
    - Function Call の結果が別のターンに遅れて返ってくる
    - 音声プロトコル特有の strict な ordering 制約 (append / commit / cancel / truncate)

    加えてこの上で組み立てる API そのものも、preview の中で 1 度大きく schema が変わり、その半年以上後の GA リリースでさらにイベント名・config 構造が変わり、というスピードで動いています。リアルタイム性に加えて「API の中身が定期的に塗り替わる」前提でアーキテクチャを保たないといけません。

    私たちは今、このリアルタイムイベント処理層を Python (asyncio + Lock) 実装から Kotlin (Coroutines + Channel) 実装へ全面的に書き換える大規模 Re-Design の真っ最中です。これは単なるリプレースではなく、『問題をストレートに解く』『人類が解き終わった問題を解き直さない』を貫いた設計レベルからの作り直しとして進めています。

    しかし本セッションが共有したいのは「Kotlin に書き換えたら良くなりました」ではなく、そのプロセスそのものが Coding Agent と人間のエンジニアリングの協業として組み立てられている、という点です。具体的には次のようなトピックを扱います。

    - 設計の中核となる状態遷移を TLA+ で形式検証する。TLA+ モデルそのものを Coding Agent に書かせ、実装コードとモデルをラベルで紐付ける
    - 「イベントループの中で blocking I/O を絶対にしない」という人間が決めたルールを、BlockHound と Kotlin Coroutines の Dispatcher 分離で runtime 検知させる
    - フラットに 60 近いフィールドを抱えていた状態オブジェクトを、call / aiResponse / audio / domain といった "直交軸" に分解する
    - 「意思決定」「ライフサイクル管理」「I/O」という責務を別コンポーネントに切り出す
    - Kotlin の型システム (sealed interface / internal constructor) で、状態遷移やライフサイクルの分岐を網羅させ、不正な遷移をコンパイル時に止める
    - 既存 Python と Kotlin を同一ネームスペースで並走させ、テナント単位で切り替えるゼロリスク段階移行戦略

    これらを「人間が設計し、Coding Agent と一緒に実装・検証する」というやり方で進めた現場のリアルを、実コードと設計ドキュメントを交えて共有します。

    最後に、この Re-Design を通じて見えてきた「AI 時代の Software Engineering とは何が変わり、何が依然として人間にしか書けない設計判断なのか」についての現時点の結論をお話します。

    ## 発表の範囲

    話すこと:

    - Kotlin / Spring Boot / Kotlin Coroutines を使ったリアルタイムサーバーの設計判断
    - リアルタイム性・barge-in・並行イベントといった AI プロダクト固有の難所
    - 大規模 Re-Design を Coding Agent と共に進めた現場のリアル
    - 形式検証 (TLA+) や runtime 検知 (BlockHound) を実プロダクトに導入した知見

    話さないこと:

    - LLM / Realtime API そのもののモデル・チューニング論
    - 特定の Coding Agent ツールのチュートリアル
    - Gen-AX の事業数値・営業戦略

    ## 対象聴講者

    業務で Kotlin / Java を書く Software Engineer。特に並行処理・イベント駆動・大規模リファクタ・形式検証に興味のある方。AI プロダクトの裏側を実装観点から見たい方も歓迎です。

    Room E
    土 11:00 - 11:45
    • Sponsor(45m)
    • Intermediate
    • Spring
    • Architecture
    • AI
    • Modernization
    • スライド公開予定

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

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

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

    Room F
    土 11:00 - 11:20
    • Regular(20m)
    • Basic
    • Spring
    • Modernization
    • Practice
    • スライド公開予定

  • イベントストーミングと Kiro Spec で実現する、要件の認識合わせプロセス

    イベントストーミングは業務プロセスから集約やコンテキスト境界を見つけ出し、システム化の範囲を明確にする手法です。しかし、そこで得られた業務プロセスの理解を、テスト可能な要件としてチーム全員で合意するまでには、まだギャップがあります。
    本セッションでは、イベントストーミングで整理した業務プロセスを Kiro の Spec 機能に入力してユーザーストーリーを整理し、そこから画面モックや状態遷移図、ドメインモデルなどを瞬時に生成することで、要件と設計イメージのズレをその場で発見・解消するプロセスをデモでお見せします。生成 AI による即時フィードバックにより、要件と設計の認識ズレを早期に発見し、手戻りを減らしながら認識合わせの品質と効率の両方を高めるアプローチをお伝えします。

    Room G+H
    土 11:00 - 11:45
    • Sponsor(45m)
    • Intermediate
    • Cloud
    • DevOps
    • Tools
    • Methodology
    • AI
    • スライド公開予定

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

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

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

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

    Room I
    土 11:00 - 11:45
    • Regular(45m)
    • Intermediate
    • Spring
    • Architecture
    • Design
    • Modeling
    • Test
    • Practice
    • スライド公開予定

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

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

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

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

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

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

    Room M
    土 11:00 - 11:20
    • Regular(20m)
    • Intermediate
    • Java SE
    • Methodology
    • スライド公開予定

  • 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ハンドリングの違い、プラットフォーム型が発生する内部的な仕組みを整理した上で、具体的に付与すべきアノテーションや導入すべきツールを体系的に提示します。

    Room F
    土 11:25 - 11:45
    • Regular(20m)
    • Intermediate
    • Spring
    • Language
    • スライド公開予定

  • Javaで学ぶSOLID原則

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

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

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

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

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

    Room M
    土 11:25 - 11:45
    • Regular(20m)
    • Basic
    • Java SE
    • Architecture
    • Design
    • Practice
    • スライド公開予定

  • 【ランチ付き】ウェルスナビのマルチサービス化を支える技術 〜Spring Cloud GatewayとPub/Subの実践〜

    ウェルスナビ（WealthNavi）は"働く世代に豊かさを"というミッションのもと、長期運用を前提とした全自動資産運用サービスを提供しています。
    マルチサービス化を進める上で、サービス間の認可制御・データ連携方法の標準化が課題となってきました。
    本セッションでは、安定したサービス間通信を実現するための二つの取り組みについて解説します。
    前半は、Spring Cloud Gatewayを用いたAPI Gatewayの構築についてです。
    Java 25やSpring Boot 4といった最新スタックを見据え、Virtual Threadsを採用した背景や、Resilience4jを用いたレジリエンス設計の勘所を共有します。
    後半は、Amazon SNS/SQSとSpring Cloud AWSを活用したイベント駆動アーキテクチャの実装についてです。デッドレターキューの設計や、HTTPクライアントの設計に関する実践的な知見をコードを交えて紹介します。
    最新のJavaエコシステムを活用するために試行錯誤した実践知をお話しします。

    Room C+D
    土 12:00 - 12:45
    • Sponsor(45m)
    • Intermediate
    • Java SE
    • Spring
    • Cloud
    • Architecture
    • Design
    • Practice

  • 【ランチ付き】肥大化するレガシーコードに立ち向かうためのインターフェース分離と依存の逆転

    レガシーコードを改善したいのに、新規機能の開発となるとどうしてもレガシーコードに頼らざるをえない。そうすると可読性は低いままだし、レガシーコードは減るどころか逆に増やしてしまいどんどん改善から遠のいていく。ノーコード・ローコードツールのkintoneは、10年以上開発が継続した結果そのような状態になっていました。この状態を放置していると開発できるものもできなくなってしまいます。

    このような肥大化するレガシーコードに立ち向かうために行ったのがインターフェース分離と依存の逆転です。このセッションではkintoneがどのようにしてインターフェイスを見出したかということや、それによる内部設計の変化、機能開発への効果について紹介します。

    Room E
    土 12:00 - 12:45
    • Sponsor(45m)
    • Intermediate
    • Java SE
    • Modernization
    • スライド公開予定

  • ふつうのFeature Flag実践入門

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

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

    Room A+B
    土 13:15 - 14:00
    • Regular(45m)
    • Intermediate
    • Java SE
    • Spring
    • Design
    • スライド公開予定

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

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

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

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

    Room C+D
    土 13:15 - 14:00
    • Regular(45m)
    • Basic
    • Test
    • スライド公開予定

  • 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 のメソッドプロファイリング情報のキャッシュ化によるウォームアップ時間の改善について検証した結果についても紹介いたします。

    Room E
    土 13:15 - 13:35
    • Regular(20m)
    • Basic
    • Spring
    • Cloud
    • JVM
    • Modernization
    • スライド公開予定

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

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

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

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

    Room F
    土 13:15 - 13:35
    • Regular(20m)
    • Basic
    • Others
    • スライド公開予定

  • 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を利用して推論処理を高速化するユースケースを紹介します。

    Room G+H
    土 13:15 - 14:00
    • Regular(45m)
    • Advanced
    • Java SE
    • JVM
    • 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.

    Room I
    土 13:15 - 14:00
    • Regular(45m)
    • Basic
    • AI
    • スライド公開予定

  • 【ワークショップ】AIコードレビューを体験する：CodeRabbitハンズオンワークショップ

    AIコーディングの普及により、コードの生成速度は飛躍的に向上しました。一方で、レビュー対象となるプルリクエストの増加や、コード品質のばらつきといった新たな課題も顕在化しています。従来の人手中心のコードレビューでは、こうした変化に対応しきれないケースが増えています。

    本ワークショップでは、AIコードレビューサービスであるCodeRabbitを題材に、コードレビューの効率化と品質向上をどのように実現するかを、座学とハンズオンの両面から学びます。GitHubと連携したセットアップから、実際のプルリクエストに対するレビュー体験までを通じて、AIがどのようにコンテキストを理解し、レビューを行うのかを確認します。

    また、ローカル環境でのレビューとの違いや、チーム開発における品質ゲートとしての活用方法にも触れます。AIを単なる補助ツールとしてではなく、開発プロセスに組み込むための具体的なイメージを持ち帰ることを目的としたワークショップです。

    Room L
    土 13:15 - 15:00
    • Workshop(105m)
    • Basic
    • AI

  • 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を速くしたいと考えている方に、ジョブ分割の設計指針と最適化の判断基準を持ち帰っていただける内容です。

    Room M
    土 13:15 - 13:35
    • Regular(20m)
    • Intermediate
    • Java SE
    • DevOps
    • Tools
    • Test
    • スライド公開予定

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

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

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

    Room E
    土 13:40 - 14:00
    • Regular(20m)
    • Intermediate
    • Architecture
    • スライド公開予定

  • 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 を使ったプロジェクトで、コンテナイメージの改善を検討している方

    Room F
    土 13:40 - 14:00
    • Regular(20m)
    • Basic
    • Spring
    • DevOps
    • Security
    • スライド公開予定

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

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

    Room M
    土 13:40 - 14:00
    • Regular(20m)
    • Basic
    • Spring
    • DevOps
    • Architecture
    • Test
    • スライド公開予定

  • 少人数チームでの開発生産性を高めるための、システムのコンパクト化とモダナイゼーション

    AI の進化は、コードの書き方だけでなく、開発基盤の設計思想やチーム編成、さらには採用のあり方まで大きく変えつつあります。本セッションでは、少人数チームで高い生産性を維持するために私たちが取り組んだ「システムのコンパクト化」を主題に、その全体像をお話しします。
    まず、AIを活用した開発を前提として「小さいチームでも開発・運用できる」状態を目指し、リポジトリの削減やシステム統合、アプリケーション設定の最適化・統合など、一連の基盤改善について具体的に紹介します。次に、社内で開発・運用している AI エージェント「Kuro」の取り組みをご紹介します。
    これらを支える技術基盤として、Java 25 / Spring Boot 4.x へのモダナイゼーションを実施しました。移行で学んだことや注意点に加え、Claude Code が有用だった場面や限界点について、実践的なふりかえりとして率直にお話しします。

    Room A+B
    土 14:15 - 15:00
    • Sponsor(45m)
    • Basic
    • Spring
    • AI
    • Modernization

  • (仮) チームで活用する！ — アプリ開発における「AIエージェントの使い方」の設計と実践例

    最近、アプリケーション開発におけるAIエージェントの活用が急速に進んでいます。
    しかし、チームで継続的に活用するためには、「エージェントの使い方」をチームとして設計し、足並みを揃えることが重要です。

    本セッションでは、AIエージェント活用の基本的な考え方を整理したうえで、チームでの活用に重点を置いた「エージェントの使い方」の設計を、具体例を交えてお伝えします。

    Room C+D
    土 14:15 - 15:00
    • Sponsor(45m)
    • Basic
    • AI

  • クレディセゾンの内製開発に見る、技術と対話で価値をつくる面白さ

    クレディセゾンの内製開発をテーマに、事業の中にいるエンジニアが、
    技術をどう事業に活かしていくのかをお話しします。

    事業会社の開発では、実装力だけでなく、システムを使うユーザーと対話し、
    課題をともに整理しながら改善を前に進める力が欠かせません。

    責任ある挑戦の中で、困難を楽しみながら価値を生み出していく。
    そんなエンジニアリングの面白さを共有するセッションです。

    対象者
    ・内製開発に関心のあるエンジニア
    ・ユーザーと対話しながら価値をつくりたいエンジニア
    ・実装で終わらない開発をしたいエンジニア

    Room E
    土 14:15 - 15:00
    • Sponsor(45m)
    • Basic
    • Methodology
    • AI
    • Career
    • Others

  • 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のカードテーブルの導入」や「ライトバリアの命令数の大幅削減」の仕組みや効果について解説します。

    Room F
    土 14:15 - 15:00
    • Regular(45m)
    • Intermediate
    • JVM
    • スライド公開予定

  • Inside Stream API

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

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

    Room G+H
    土 14:15 - 15:00
    • Regular(45m)
    • Advanced
    • Java SE
    • Design
    • スライド公開予定

  • 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!

    Room I
    土 14:15 - 15:00
    • Regular(45m)
    • Intermediate
    • Java SE
    • JVM
    • Modernization
    • スライド公開予定

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

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

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

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

    Room M
    土 14:15 - 14:35
    • Regular(20m)
    • Intermediate
    • Spring
    • Cloud
    • Architecture
    • スライド公開予定

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

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

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

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

    # セッションで話すこと
    - GraphQLとRESTの認可モデルの違い
    - 認証・認可の基礎
    - JWTを使った認証〜認可までの一連の流れ
    - Spring Securityを用いたRBAC/ABACの実装パターン
    - GraphQLにおけるフィールド単位の認可設計のポイント

    # セッションで話さないこと
    - GraphQLの基本仕様や導入方法
    - JWTの暗号アルゴリズムやセキュリティ仕様の詳細
    - DataLoaderやN+1問題の詳細な最適化手法
    - フロントエンドの具体的なコード

    Room M
    土 14:40 - 15:00
    • Regular(20m)
    • Basic
    • Spring
    • Security
    • スライド公開予定

  • （仮）事業と​一緒に​成長する、​モノリスな​プロダクトの​ほど​よい​リプレイス戦略

    10年間運用されているPHPの巨大なモノリスプロダクトの一部機能を、Kotlin × Spring Bootにリプレイスしています。事業と一緒に成長していくプロダクトを育てるべく、様々な観点でのROIを意識したリプレイスを進めてきました。
    今回のセッションでは、具体的な実装例などを交えながらどのようにプロダクトと事業をつなげてきたかをお伝えします。

    【対象者】
    レガシーシステムのリプレイスを検討したことがある方

    【話すこと】
    テック観点でのプロダクトロードマップの決め方

    【話さないこと】
    プロダクト戦略

    Room A+B
    土 15:30 - 16:15
    • Sponsor(45m)
    • Intermediate
    • Spring
    • Architecture
    • Database
    • Modeling

  • 一晩で2000PR。Devinで変わるJavaマイグレーション

    Javaのバージョンアップやフレームワーク移行は、避けられないのに終わりが見えない、そんな作業です。

    本セッションでは、自律型AIエンジニアDevinを活用し、約150万ステップのテスト改修を200人月から50人月へ圧縮した実例を紹介します。一晩で2000件超のPRを生み、CIを通すまで自律的にやり切る開発スタイルは何が違うのか。

    「AIに任せる」から「AIを設計する」へ。Javaマイグレーションの進め方がどう変わるのか、現場の知見をご紹介します。

    Room C+D
    土 15:30 - 16:15
    • Sponsor(45m)
    • Basic
    • Java SE
    • Spring
    • DevOps
    • Methodology
    • AI
    • Modernization

  • 出前館のメニュー登録・更新用APIをSpring Boot + Kafkaで実現したお話

    出前館では、加盟店チェーンがメニューを一括で登録・更新できる API を Spring Boot + Kafka で構築しています。
    本セッションでは、その設計判断の裏側を「なぜそうしたか」を中心にお話しします。

    アジェンダ
    1. メニュー連携 API の全体像
    2. Kafka による非同期化と API / Subscriber の分離
    3. 数百〜数千商品のメニュー更新における画像登録の負担をどう軽減したか

    Room E
    土 15:30 - 16:15
    • Sponsor(45m)
    • Basic
    • Spring

  • JVMと私

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

    Room F
    土 15:30 - 16:15
    • Regular(45m)
    • Basic
    • JVM
    • Career
    • スライド公開予定

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

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

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

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

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

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

    Room G+H
    土 15:30 - 16:15
    • Regular(45m)
    • Intermediate
    • Methodology
    • Design
    • スライド公開予定

  • 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.

    Room I
    土 15:30 - 16:15
    • Regular(45m)
    • Intermediate
    • DevOps
    • Observability
    • スライド公開予定

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

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

    Room M
    土 15:30 - 15:50
    • Regular(20m)
    • Basic
    • Java SE
    • スライド公開予定

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

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

    Room M
    土 15:55 - 16:15
    • Regular(20m)
    • Intermediate
    • Java SE
    • Language
    • スライド公開予定

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

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

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

    Room A+B
    土 16:30 - 17:15
    • Regular(45m)
    • Basic
    • Tools
    • AI
    • スライド公開予定

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

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

    Room C+D
    土 16:30 - 17:15
    • Regular(45m)
    • Basic
    • Cloud
    • DevOps
    • Tools
    • スライド公開予定

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

    Room G+H
    土 16:30 - 17:15
    • Regular(45m)
    • Basic
    • DevOps
    • Tools
    • Others
    • スライド公開予定

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

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

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

    Room I
    土 16:30 - 17:15
    • Regular(45m)
    • Intermediate
    • Jakarta EE
    • AI
    • Modernization
    • スライド公開予定

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

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

    Room M
    土 16:30 - 16:50
    • Regular(20m)
    • Basic
    • Architecture
    • Modeling
    • スライド公開予定

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

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

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

    Room L
    土 16:55 - 17:15
    • Regular(20m)
    • Basic
    • Java SE
    • Language
    • Others
    • スライド公開予定

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

    セッション概要:
    リアクティブな業務アプリケーションを設計する際に、「非同期/同期」処理をどこに適用するかというガイドラインは広く共有されていないようで、特に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パターンの説明

    Room M
    土 16:55 - 17:15
    • Regular(20m)
    • Intermediate
    • Architecture
    • Methodology
    • Design
    • Practice
    • スライド公開予定
Session and Speaker Management powered by Sessionize.com