• 「Hello World」が表示されるまで — javac、クラスファイル、JVMをたどる

    JavaのコードがJVM上で実行されることは広く知られています。しかし、自分が書いたソースコードがどのような表現に変換され、最終的に実行されるのかを普段意識する機会は多くありません。

    本セッションでは、次の「Hello World」がコンパイルされ、実行されるまでを題材に、JavaのコンパイルとJVMによる実行の流れをたどります。

    System.out.println("Hello World");

    前半では、javacがJavaソースファイルをクラスファイルへ変換する過程を扱います。字句解析によってソースコードをトークンに分解し、構文解析によって構文木を作り、意味解析によって名前や型、呼び出すprintlnのオーバーロードを決定します。その後、低層化・脱糖などの変換を経て、JVMバイトコードを含むクラスファイルが生成されます。

    生成されたクラスファイルについては、javapの出力を使いながら、メソッドディスクリプタ、定数プール、暗黙に生成されるコンストラクタ、mainメソッドのバイトコードを確認します。

    後半では、クラスファイルがJVMにロードされ、リンクおよび初期化された後、mainメソッドが呼び出されるまでを概観します。さらに、次のバイトコードを例に、オペランドスタックの状態がどのように変化するかを図で追いかけます。

    getstatic
    ldc
    invokevirtual
    return

    最後に、printlnが特別なJVM命令ではなくJavaライブラリのメソッドであり、標準出力を通じて文字列がターミナルへ渡されることを紹介します。

    本セッションでは、Javaソースコード、コンパイラの内部表現、クラスファイル、JVMバイトコードという表現の変化に焦点を当てます。

    • Regular(20m)
    • Basic
    • Java SE
    • JVM

  • 「使っているライブラリで脆弱性あるみたいなんだけどどうする」から始める脆弱性対応

    システム開発や運用に関わる以上、脆弱性対応は避けては通れないテーマです。
    しかし、いざ組織で運用しようとすると「何から手をつければいいか分からない」「自社のやり方が正しいのか不安」といった課題に直面することも少なくありません。

    このセッションでは、まず「そもそも脆弱性とは何か？」という基礎概念や一般的な知識を整理した上で、実践している脆弱性対応や活動の事例についてお話しします。

    脆弱性運用は組織の規模やフェーズによって異なり、どうしても「N=1」の事例にはなりますが、それぞれ前提の違いを踏まえつつ、自組織の運用に活かせるヒントを持ち帰っていただければ幸いです。

    【アジェンダ】
    ・そもそも「脆弱性」とは何か？
    ・脆弱性への対応の流れ
    - 情報収集の仕方（どのように情報を集めるか など）
    - リスク分析（CVEについて, CVSS スコアの見方 など）
    - リスク評価（リスクへのトリアージの考え方 など）
    - リスク対応（組織における対応の考え方 など）
    ・脆弱性対応を進める上で意識していること

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

  • 「同期成功！」のあとに問題は起きる〜失敗する、ズレる、後から変わる。それでも同期する〜

    データ同期は、テーブル構造やAPIを理解すれば始められます。しかし実際の運用では、データが後から確定したり、障害後の再実行で更新順序が崩れたり、DBごとにデータの表現が異なったりします。単なるフルロードだけでは終わりません。

    本セッションでは、検索広告システムなどの開発・運用経験から、3つのデータ同期事例を紹介します。数値が徐々に確定するレポートデータを3日間繰り返し取得し、1週間で確定と扱った事例、システム障害による大量データ未同期状態からの再同期で依存関係に沿った更新順序を取り戻した事例、順次増えていく100超のテーブルをSQL ServerからMySQLへ移行するプログラムをミス無く効率的に自動生成するテクニック。

    Java、Spring Boot、Pulsar、Spring Scheduler、Kubernetes、RDB、Prometheus、Grafanaを用いた実践を通じ、差分検知、冪等な再実行、整合性確認、監視の考え方を共有します。日々更新されるデータを扱う開発・運用担当者が、同期失敗を前提にした仕組みを考えるためのヒントを持ち帰れる内容です。

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

  • 30 年前の Java を 私の指の上でもう一度

    約30年前，Java は，家電や電話，さらには身につける物にまでコンピュータが入り込む未来を見据えていました。その未来を指の上に載せたのが，指輪の中で Java が動作する小型コンピュータ「Java Ring」です。

    しかし，30年近い時を経て，その Java Ring は正常な応答を返さなくなっていました。

    本セッションでは，この Java Ring を再び動かすまでの軌跡を語ります。限られた資料と現存する実機を手掛かりに，何が動き，何が動いていないのかを一つずつ確かめながら，30年前の Java 実行環境を現代に蘇らせていきます。

    そして，自力での解析が行き詰まった末，この問題はなぜかバラエティ番組に持ち込まれることになります。復活へ至った経緯や，放送では伝えきれなかった技術的な舞台裏についても紹介します。

    資料も環境も十分に残っていない古いシステムを，限られた手掛かりからどのように理解し，再構成し，再び動かすのか，その考え方を持ち帰っていただければと思います。

    Java Ring や組込み Java の事前知識は必要ありません。古い技術を現代に蘇らせる過程や，限られた情報から未知のシステムを解析していく過程に興味がある方におすすめです。

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

  • 8PB規模のデータを処理する内製DBのJVMメモリ管理ノウハウ

    [前置き]
    株式会社プレイドの「KARTE」では、毎日20億行以上のデータが挿入され、累計8PBに及ぶデータを扱っています。一般的なDBでは、コスト・性能面が厳しく、弊社ではKARTEのドメインに特化した独自のDBを開発しています。

    [メモリ管理の課題]
    DB開発においてシンプルに実装を行うと、データの処理時に以下のような課題が発生します。
    - 処理する行ごとにオブジェクトを生成すると、GC（ガベージコレクション）へ膨大な負荷がかかる。(例えば10億行を扱うと10億個のオブジェクトが発生します)
    - OOM(Out of Memory)発生時のどのクエリのどの処理がどの程度メモリを消費しているかを特定できず、対策が難しい
    - クエリごとのメモリ使用量を制限できないため、重たいクエリが他のクエリの実行に悪影響を及ぼしてしまう。

    これらの課題を解決するためには、単なるJVMのパラメーターの調整だけではなく、JVMの仕組みを理解し、有効なメモリ管理の仕組み自体を構築する必要があります。

    [お話しすること]
    DBの処理の流れを踏まえ、JVMメモリ管理の基本から、課題を解決するためのJNIの活用法とメモリ管理の実装アプローチを解説します。

    [こんな方におすすめ]
    - プロダクト開発に携わるエンジニアの方
    - データベースの内部構造・データ処理基盤に興味がある方
    - JVM上で大規模データを効率的に処理したい方
    - JVMのメモリ管理やJNIの仕組みについて深く知りたい方

    生成AIの普及に伴い、アプリケーションロジックのみでのプロダクトの差別化は難しくなり、企業が持つデータそのもの価値は高くなっているのではないかと思います。
    そのため、効率的にデータを処理するノウハウは、データを扱う全てのプロダクトの開発において役に立つはずです。
    ぜひご参加ください！

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

  • AIエージェントは開発でのみ使えると考えていませんか。

    事業会社の社内SEとして、SIerに開発を発注する立場で働いております。日頃AIエージェントを設計書並びにテストケースや結果レビュー、UAT計画から実施、納品物の検収といった開発以外の工程で活用しています。AIエージェントは開発以外でも様々に活用出来る事をご紹介したいです。開発でのAI活用についてはお話致しません。AIは進化が速いので発表直前の最新状況も踏まえます。聞いて頂きたい方は、発注側の立場におられる方や日頃成果物のレビューを担当されている方です。

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

  • AIに実装を任せるなら、人間は何を書くのか？ ― SoutherによるExample駆動開発

    ## セッション概要

    生成AIによって、コードを書くコストは大きく下がりつつあります。
    では、実装をAIに任せられるようになったとき、人間は何を決めればよいのでしょうか。

    「この仕様を実装して」とAIに頼むには、その前に仕様が決まっていなくてはなりません。
    しかし、自然言語で詳細な仕様書を書き、そのすべてをAIに渡すことが答えとも限りません。
    仕様を書くコストが実装のコストを上回るのであれば、開発のボトルネックを別の場所へ移しただけになるためです。
    人間が決めるべきものを、もっと小さく、もっと直接的に表現するには、どうすればよいのでしょうか。

    本セッションでは、その一つの答えとして、具体的なExampleから仕様を組み立てていく「Example駆動開発」とそれを実現するプログラミング言語「Souther」紹介します。

    「Example駆動開発」は、例えば「商品が3個なら送料は無料になる」という具体的なExampleから始めます。
    そこへ別のExampleを追加しながら、プログラムが満たすべき規則と入力領域を少しずつ明らかにしていきます。
    人間は実装方法ではなく「どのような入力に対して、何が正しい結果なのか」を決めます。

    この開発方法を実現するために、川島 義隆氏によって作られたプログラミング言語がSoutherです。
    Southerでは、業務仕様そのものを実行できます。書いたモデルが与えられたExampleを満たさなければ、コンパイル時に拒否されます。しかし、それだけではありません。与えたExampleにはすべて通っていても、入力領域や分岐にまだ仕様の穴が残っていれば、それも言語処理系が検出します。
    つまり、「Exampleに通ったから正しそう」で終わらせず「そもそも仕様として十分なのか」まで処理系に問い返させます。

    セッションでは、小さな業務Exampleから出発し、Exampleを追加するにつれて仕様モデルが組み上がっていく過程を実際に追います。そして、モデルがExampleと矛盾したとき、あるいはExampleだけでは仕様を決め切れていないときに、Southerがどのようにそれを拒否するのかを紹介します。
    Southerの文法を覚えてもらうことが目的ではなく、セッションを通じて以下を考えることが目的です。

    - AIに任せられる「実装」と、人間が決定すべき「仕様」の境界はどこにあるのか
    - Exampleを単なるテストケースではなく、仕様そのものの構成要素として扱うとはどういうことか
    - 「与えたExampleに通る」ことと「仕様として十分である」ことにはどのような違いがあるのか
    - 人間、生成AI、言語処理系をどう分担させれば、より強い開発プロセスを作れるのか

    生成AIによって、私たちは「どう実装するか」から少しずつ解放され始めています。
    だからこそ今、「何を正しいと決めるのか」という、これまで実装の影に隠れがちだった仕事を改めて考える必要があります。
    Exampleから仕様を組み立て、AIが実装し、言語処理系がその十分性を検証する。
    そんな生成AI時代のソフトウェア開発を、Southerを通して覗いてみませんか。

    ## 対象者

    主に次のようなソフトウェア開発者を対象とします。

    - GitHub Copilotなどの生成AIを実装に利用しており、AIへ何を与えるべきかに関心がある方
    - テスト、BDD、Example Mappingなど、Exampleを利用した開発手法に関心がある方
    - ドメインモデルや実行可能仕様に関心がある方
    - コンパイラや型システムを利用して、より多くの誤りを実行前に検出する設計に関心がある方

    Southerや、プログラミング言語処理系の事前知識は不要です。

    ## 聴講者が持ち帰れるもの

    本セッションで持ち帰っていただきたいのは、「生成AIを使ってどうすればもっと速くコードを書けるか」というテクニックではありません。

    コードを書く作業をAIへ渡したあと、人間は何を決定し続けなければならないのか。
    その境界を考えるためのモデルとその事例を持ち帰っていただきたいです。

    そのために、Exampleを単なるテストデータではなく仕様そのものの構成要素として扱い、その十分性まで機械的に検証するという開発アプローチを、具体的な言語実装を通して紹介します。

    • Regular(45m)
    • Basic
    • Language
    • Methodology
    • Modeling

  • CQRS+ES実践ガイド――イベントを軸にしたモデリングとシステム構築

    # JJUG CCC セッション応募

    ## タイトル

    CQRS+ES実践ガイド

    ## アブストラクト

    この大AI時代にAIに分析させようにも、そもそも必要なデータが保存されていない。
    「この値はいつ誰がなぜ変えたのか」を調べたくても、データベースには現在の値しか残っていない。
    障害の調査ではどんな経緯によりこの状態に至ったのかを推理するしかない。
    原因は共通していて、システムが「起きたこと」を捨てて「今の状態」だけをひとつの形で残しているからです。

    CQRS+イベントソーシングはこの向きを逆にして、起きたことをすべて記録し、今の状態はそこから導きます。
    この記録は履歴や監査に効くだけでなく、AIに読ませ学ばせる材料にもなります。
    業務を回すだけでその材料が業務の言葉のまま貯まっていく、この時代にいっそう重みを増すアーキテクチャです。

    また、アーキテクチャの面でも利点があります。
    書き込みと読み取りを分けると、画面や集計を追加しても書き込み側のモデルが歪みません。
    イベントを介した連携はシステム同士の結合を緩めます。
    CQRS+ESはシステムを疎結合のまま成長させたい場面に向いています。

    主にお話するトピックは次のとおりです。

    - CQRS+ESの基本的な考え方と構成
    - 実際のコードによる実装例
    - モデリングとシステムへの落とし込み
    - 結果整合性のポイント

    CQRSやイベントソーシングという言葉は聞いたことはあるものの動くシステムとして組み上げた経験はない、そんなJava開発者が対象です。
    本セッションを通じて、CQRS+ESの全体像と、自分のシステムに向くかどうかを判断する基準、そして試すならどこから手を付けるかの判断軸を得られることを目指します。

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

  • Gradleプロジェクトの脆弱性、直せる場所で見つかっていますか

    ここ数年、サプライチェーン攻撃が現実的な脅威になりました。実際に私たちが対応したCVSS 9以上の脆弱性も、その多くは自分で書いた覚えのない推移的依存にあります。何を取り込んでいるかを把握できていること自体が、セキュリティの前提条件になりました。

    ところがGradleのプロジェクトでは、その把握が標準では成立しません。ソース側のスキャナが読むlockfileが、Gradleには存在しないためです。同じJVMでもMavenでは起きません。スキャナがpom.xmlを直接読み、推移的依存まで解決してくれるからです。

    私たちの場合も、CVSS 9を超える脆弱性は検知されていました。ただしビルド後のコンテナイメージをスキャンすることによって、です。修正すべきビルドスクリプトから最も遠い場所で、マージされた後に。実務で効くのは、何件見つかるかより修正できる場所で見つかるかどうかだと考えています。

    実際に取り組んでみると、導入そのものより運用の設計に悩みました。どこで止めるか、何を閾値にするか、自動更新とどう共存するか。答えの出ていない部分も含めて共有することで、同じ状況にある方の判断材料になればと考えています。

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

  • Jakarta Data 1.0の現在地 〜Jakarta EE 11で、RDBとNoSQLはどこまで同じコードで書けるのか〜

    Jakarta EE 11で追加されたJakarta Data 1.0は、リレーショナルDBとNoSQLの双方に対して、同じリポジトリパターンでアクセスするAPIを標準化しました。

    本セッションでは、2026年2月にリリースされたGlassFish 8を使って、これを実際に動かして検証した結果を共有します。GlassFish 8はEclipse JNoSQLをバックエンドとした独自のJakarta Data実装を持ち、JPAエンティティとNoSQLエンティティの両方に対するリポジトリをサポートしています。
    同一のリポジトリインターフェースをPostgreSQLのようなリレーショナルDBと、MongoDBのようなNoSQLの双方と接続して本APIを利用する場合に何が共通化でき、何が共通化できないのかを、動かしながら明らかにします。仕様が意図的に線を引いている場所として「SQLをNoSQLのように使わせること」を目的にしていない点や、共通化できてうまくいくところだけでなく、利用者目線でもう一歩と感じる点も合わせて示します。

    • Regular(20m)
    • Basic
    • スライド公開予定
    • Jakarta EE
    • Database

  • Java 27 で標準化！Compact Object Headers を理解しよう

    Java 25 で導入された Compact Object Headers は、Java オブジェクトのヘッダを縮小することでメモリ使用量の削減を主とした性能改善を目指す JVM の新機能です。

    この機能は Java 27 でデフォルト有効化される予定であり、多くの Java アプリケーションで開発者が意識することなく利用することが見込まれます。一方でこれは比較的新しい JVM の機能であり、その仕組みや効果について触れられる機会はまだ多くありません。そこで本セッションでは、最新の Java 利用に向けて押さえておきたい JVM の新機能である Compact Object Headers を分かりやすく解説します。

    セッション内容としては、まず Java オブジェクトヘッダの役割を整理したうえで、Compact Object Headers の仕組みや従来方式との違いを解説します。さらにメモリ使用量やアプリケーション性能への影響を実測結果とともに示し、本機能によって期待できる効果や適用時のポイントを紹介します。

    Java アプリケーション開発者の方はもちろん、性能改善やメモリ最適化に関心のある方、JVM の最新機能を学びたい方におすすめです。

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

  • Java でコンテナランタイムは作れるのか？ - GraalVM Native Image で実践するシステムプログラミング -

    OS と直接やり取りするシステムプログラミングは、従来 C や Go、Rust の領域でした。しかし GraalVM Native Image によってネイティブバイナリが生成できるようになり、Panama FFM の登場により C との連携も容易になった現在、Java での低レイヤプログラミングも現実的になりつつあります。本セッションでは、実際に Java + GraalVM Native Image で低レイヤコンテナランタイムを実装した経験をもとに、システムプログラミング領域での Java 活用の可能性を探ります。

    ## Agenda
    - 導入: システムプログラミングにおける Java の立ち位置の変化
    - C interoperability
    - コンテナランタイムは何をするもの？
    - 実際のコンテナ作成の流れを追ってみよう
    - 既存コンテナランタイムとの性能比較
    - まとめ: Java でシステムプログラミングはどこまで現実的か

    ## 話すこと
    - GraalVM Native Image 動作の仕組み
    - ビルドの流れ、JVM アプリケーションとの違いなど
    - 各種 C interoperability の比較
    - 特に Panama FFM を使った C 関数呼び出しについては、jextract を利用した自動バインディング生成等の tips も含め詳しく解説します
    - コンテナランタイムが行うざっくりとした処理の流れ
    - GraalVM Native Image のマルチスレッド特性によって必要になった Hack

    ## 話さないこと
    コンテナランタイムの内部動作については、上記 Java に関連するトピック以外扱いません

    ## 対象オーディエンス
    - Panama FFM をはじめとした、Java と C との interoperability について知りたい方
    - Java をネイティブ環境で動かす際の仕組みや制約に興味がある方
    - 低レイヤプログラミングや、Java の新しい活用領域に興味がある方

    ## このテーマを取り上げる理由
    GraalVM Native Image や Panama FFM の登場により Java での低レイヤプログラミングの可能性は大きく広がりましたが、現時点で本格的なシステムソフトウェアへ活用した事例は多くありません。本セッションでは、コンテナランタイムというシステムプログラミングの領域に Java で踏み込んだ実装経験をベースに、実際に遭遇した問題から得られた教訓を共有します。

    ## このセッションで聴講者にどういうメリットがあるか
    聴講者は、Java からネイティブコードを扱うための具体的な選択肢や、JVM アプリケーションと比較した GraalVM Native Image の特性を理解できます。また、Java をシステムプログラミングに適用できる領域と、その限界を判断するための知見を得ることができます。

    • Regular(45m)
    • Advanced
    • スライド公開予定
    • Language
    • Modernization

  • Javaエンジニアが理解するMCP ～RAGから考えるSpring AIとLLM・業務システムの接続～

    生成AIを業務で活用するには、LLMに業務データやシステムをどう利用させるかが重要です。本セッションでは、RAGとMCPの役割と仕様を理解し、MCPの登場によってRAGが中心だったLLMと外部情報・機能の関係がどう変わるのかをSpringAIの実装で解説します。JavaエンジニアがAI活用を「利用する側」から「仕組みを作る側」へ進むためのMCPの考え方を紹介します。

    • Regular(45m)
    • Basic
    • Spring
    • Database
    • AI

  • Javaでデータフレームを使ってみよう！

    CSVから取得したデータをJavaで加工・集計する際、ListやStream APIを用いた結果、コードが複雑化・巨大化してしまった経験はないでしょうか？

    本セッションでは、Java向けのデータフレームライブラリ「dflib」を紹介します。dflibを使うことで、CSVの読み込みからフィルタリング・集計・データ変換の処理を、どのようにシンプルに実装できるかを解説します。

    さらに、加工したデータをもとに、チャートを描画する一連の流れについて、ライブデモを交えてお見せします。

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

  • Javaで学ぶTimsort

    Timsortは多くの言語で採用されているメジャーなソートアルゴリズムです。もともとはPython向けに開発されたものですが、現在ではJavaの標準ライブラリでも参照型の配列およびListのソートにおいてはTimsortが採用されています。

    このセッションでは皆さんもたくさんお世話になっているはずのTimsortがどのようなソートアルゴリズムなのかざっくり理解することを目指します。
    Timsortの概要を把握したところで普段の開発で直接役立つわけではないですが、普段使っているライブラリの中身を知ることは楽しいものです。
    採用事例が多いということは、それだけ速いアルゴリズムということのはずですよね。何がどう速いのか、一緒に見てみましょう。

    本セッションはソートアルゴリズムにあまり詳しくない方がTimsortをざっくり理解することを目指すため、実装レベルで詳細な解説をする時間はとれない想定です。
    （簡単なコードの例示はあると思います）

    ■話すこと
    ・ソートアルゴリズムの速さは何で決まるか
    ・Timsortのベースとなるマージソートについて
    ・Timsortの仕組みと速い理由
    ・JavaのTimsort実装特有の点

    ■話さないこと
    ・実装レベルでの詳細な解説
    ・プリミティブ型の配列のソートについて（別のアルゴリズムです）

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

  • Javaと耐量子計算機暗号（PQC）：量子時代に備えるJavaセキュリティ

    量子コンピュータの進展により、RSAやDiffie-Hellmanなど現在広く使われている公開鍵暗号が将来破られる可能性があります。本セッションでは、暗号学的に関連する量子コンピュータ（CRQC）や「Harvest Now, Decrypt Later」の脅威を概説し、NISTで標準化が進む耐量子計算機暗号（PQC）と、Java Platformでの対応を紹介します。ML-KEM、ML-DSA、KEM/KDF API、TLS 1.3の耐量子ハイブリッド鍵交換など、Java開発者が知っておくべき最新機能をコード例とともに解説します。PQCアルゴリズムの高度な数学的背景や量子コンピュータの物理学そのものは扱いません。

    • Regular(45m)
    • Basic
    • Java SE
    • Security

  • Javaのメソッド呼び出し階層を静的解析で可視化する

    このセッションでは、静的解析でJavaプロジェクト全体のメソッド呼び出し階層を一括で抽出し、CSVファイルに出力するツールを作成した経験についてお話しします。

    Javaメソッドの呼び出し階層を知りたいとき、開発環境で「呼び出し階層を開く」を実行すればいい、と思いますよね。
    しかし深掘りしてみると、変数の宣言型と実行時のインスタンス(具象クラス)は異なるため、宣言型をたどるだけでは候補までしか特定できなかったりします。
    例えば、インターフェース型の変数、ファクトリクラスにより生成されたインスタンス、リフレクション経由の呼び出しなどです。

    開発環境のように開発者が１件ずつ確認する運用では、候補が複数あっても問題になりません。
    しかし、プロジェクト全体を対象にすると候補をそのまま出力してしまうと実用にはなりません。
    そこで、候補が複数ある場合の絞り込みを静的解析にて行いました。もちろん静的解析には限界があるため候補を出すしかない場合もあります。
    それでも、全体の呼び出し階層があると「このメソッドはどこから呼ばれるか」を型階層や文字列検索(GREP)よりも簡易に確認できるようになります。

    ツールの実装そのものは生成AIに任せました。AIにコードを読ませて仕様を推論させるのではなく、AIに決定論的な解析ツールを作らせるという選択をしています。
    同じソースコードからは必ず同じ結果が出る、という性質が保守の現場では重要だと考えたからです。

    ■対象者
    ・業務システムの保守エンジニア（特にレガシーシステム）
    ・静的解析の事前知識は不要です。

    ■このテーマを取り上げる理由
    IDEの呼び出し階層で影響範囲を調査しても、途中で階層が切れてしまい、文字列検索(GREP)し直して再度絞り込む。
    そんな調査を機械的に一括で出せないかと考えてはいましたが、実装コストの大きさから手を出せずにいました。
    それが、生成AIによって現実的な範囲に入ってきたため、実際に作ってみることにしました。
    同じことで時間を使っている方に、試せる形で共有したいと思っています。

    ■持ち帰れること
    ・「呼び出し階層」の一覧を出す仕組みとその限界

    作成したJavaメソッド呼び出し階層一括抽出ツールはGitHubで公開しています。
    https://github.com/instreest/java-call-hierarchy-exporter

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

  • JVMCI - ピーキーな技術よ永遠に

    Java 9 で導入された JEP 243: Java-Level JVM Compiler Interface（JVMCI）。JVM 内の JIT コンパイラの操作を可能とする、知る人ぞ知るこの技術が Java 27 から姿を消し、多くの Java 開発者にとって「存在すら知らないまま終わった技術」になりつつあります。

    JVMCI では好きな時に・好きな機械語を JIT コンパイル済みコードとして JVM にロードし Java メソッドとして実行することができます。そのため、GraalVM や TornadoVM など独自の JIT コンパイル技術をもつプロダクトの中核を支える機能でした。この技術の詳細は Java Day Tokyo 2017 でも紹介しましたが [1]、機能削除された直後の Java 27 が登場した今、あらためて JVMCI とは何だったのかを振り返ります。

    本セッションでは機械語の細かな話（命令の説明やエンコーディングなど）に深く踏み込みません。
    HotSpot が備える JIT コンパイラはもちろんのこと、性能向上手段の 1 つとしての JNI や FFM といったネイティブ連携技術と比べながら、時に HotSpot の動きを絡めながら、JVMCI の概要や使いどころを解説します。JVMCI を通じて HotSpot の JIT コンパイル技術の概要や、開発者が性能向上のためにどのようにネイティブレイヤに手を出せそうかを感じていただくことを目指します。Java コードがどのように CPU の上で実行されるか興味のある方に向けた内容を目指しますが、ネイティブ寄りの話が多いため、Java だけでなく C（と C コンパイラの最適化オプション）をなんとなく見聞きしたことがあるとより楽しんでいただけるかもしれません。

    OpenJDK の upstream からはすでに消えてしまった JVMCI ですが、そこから垣間見える HotSpot の深淵には非常に興味深いものがあります。Java だけど Java じゃない、普段は意識しない低レベルな世界を一緒に振り返ってみませんか？

    [1] https://www.slideshare.net/slideshow/panamajvmcijit/76044673

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

  • LLMクロスレビューシステムの構築、そして……

    セッション概要:

    LLMによる高速開発を維持するためには、よりレビューがボトルネックにならないための工夫が必要になります。
    また、「設計原則を守りましょう」とレビューで伝えるだけでは、指摘の有無や粒度がレビュアーによってばらつき、原則は次第に形骸化します。

    この問題を解消するために、私たちは複数のLLMエージェントに並列でガイドラインレビューを行わせる「クロスレビュー」の仕組みを構築・導入しました。

    本セッションでは、このクロスレビューを実際に運用する中で直面した判定の不安定さと、その反省からレビュー指摘を「機械的に検出できるもの」と「判断が必要なもの」に仕分け、
    前者を静的解析へ移行していった経緯を紹介し、レビュー運用の設計判断に資したいと思います。

    ----

    発表要旨:

    LLMを利用したチーム開発においては、ボトルネックとなりがちなレビューの高速化と安定化がアウトプットのキーになります。
    またレビュアー間の観点がばらつくことによる品質のぶれも大きくなるため、これらを平準化・スケーラブル化させる必要があります。
    そこで当初私たちのチームでは「観点別ガイドラインによるLLM並列クロスレビューシステム」をレビュー依頼前のステップとして導入し、一定の成果を得ました。

    しかし、ガイドラインのスキマを埋める作業や条件付き判断などの盛り込みを進めるうちにこのシステム自体の信頼性が急速に低下し、
    レビューを人力に戻さなければならない可能性が出るなど大きな問題に直面しました。

    そこで私たちは、クロスレビューが指摘していた内容を棚卸しし、構文木(AST)ベースで機械的・決定的に検出できるものと、文脈判断が必要でLLMや人間のレビューに残すべきものとに仕分けました。
    前者については、PMDのカスタムルールとArchUnitによるアーキテクチャテストへ移行し、CIで確実に検出できる形に置き換えを行いこれを(現時点では)克服しました。

    本セッションでは、この仕分けの基準、実際に移行したルールの例、pre-commit hooksでのゲート化の運用、プロダクトコードの在り方について、実体験に基づいて紹介します。

    まとめとして、以下をテイクアウェイとして提供します。
    ・LLMレビューは「判断」を要する指摘に、静的解析は「機械的に検出できる」指摘に向いていること
    ・クロスレビューの運用から得られる、指摘の仕分け基準
    ・PMD・ArchUnitへの機械化がもたらす、レビューの決定性とコストの低減
    ・書くコストより”読む”コストを下げる方針への転換

    ----

    アジェンダ(18分):

    再現しないレビューとその対策(3分)

    コンサバティブ・レビューの非スケーラビリティ
    LLMによるクロスレビュー
    レビューのシフトレフト(PRからCIへ、CIからpre-commit hooksへ)

    LLMクロスレビューを構築し、運用してみた(4分)

    複数エージェントによる並列ガイドラインレビューの仕組み
    得られた効果（レビュー対象のスケーラビリティ、レビュー速度）
    実際に直面した問題（判定のゆらぎ、レビュー観点のスケーラビリティ、ガイドラインのスキマ）

    「機械で検出できるもの」と「判断が要るもの」を仕分ける(4分)

    クロスレビュー運用から得た指摘内容の棚卸し
    仕分けの基準と判断フロー
    手書き前提が消えた上でのちょっとラジカルな「レビューレディ」コード考

    レビューシステムの解体(4分)

    カスタムPMDルール(AST検査)による規約の機械化
    ArchUnitによるレイヤー境界・依存方向のテスト化
    CIでのゲート化と例外(抑止)の運用

    5.まとめ: 持ち帰り (3分)

    LLMも人も「判断を最小に、型で守る」
    観点の型化とコードのレビューレディネス

    ----

    発表の範囲:

    話すこと

    ・LLMクロスレビューを構築・運用して分かった限界
    ・レビュー指摘を「機械検出可能」と「判断が必要」に仕分ける
    ・判断をなるべく容易にするプロダクトコード
    ・PMDカスタムルール、ArchUnitアーキテクチャテストへの機械化事例

    話さないこと

    ・LLMのプロンプト設計そのものの詳細
    ・PMD/ArchUnitの使い方の詳解

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

  • Make Monitoring Easy for your Java Apps

    Web applications have evolved with the passage of time. From using a single-core service to having as many components glued together to meet the user requirements in the era of the cloud.

    This also brings a lot of challenges for both the Developers and the Operations teams to make sure that its performance, reliability and usability remain within the SLA without any downtime and bottlenecks.

    In this talk, we will demonstrate an example of how to monitor a Java-based email web application using Prometheus and view the metrics, logs and profiling in Grafana to get better observability by using additional tools such as Loki and Pyroscope.

    It will be an introduction to the Open Source tools, integration, application performance data and also an excellent opportunity to learn more about the community contributions.

    We look forward to hear your questions, suggestions, and feedback!

    • Regular(45m)
    • Intermediate
    • Tools
    • Observability

  • No Country For Old APIs. Wrapping legacy Java services as MCP tools without rewriting them.

    Somewhere in your estate is a Java service old enough to vote. REST endpoints by the dozen, one SOAP relic nobody will admit to, session auth, and the person who understood it all has retired. It works, which is why nobody touches it. And now the business wants AI agents to use it.

    Every enterprise is under pressure to connect AI agents to systems that were never designed for them, yet most MCP material assumes a greenfield project or a toy demo. This session addresses the situation attendees actually face: a brownfield estate of REST and SOAP services that cannot be rewritten. It is demo-driven, built on the official MCP Java SDK, Spring AI, and Spring for GraphQL, and it is honest about the failure modes: tool sprawl from auto-generation, auth translation, oversized responses, and unsafe retries against non-idempotent writes.

    Attendees leave with a reusable pattern set (facade first, curation over generation, read-only first, approval gates) they can apply to their own estate the following week.

    • Regular(45m)
    • Intermediate
    • Spring
    • JVM
    • Tools
    • Architecture
    • Methodology
    • Design
    • Modeling
    • AI
    • Modernization
    • English

  • PHPerだけどJJUG CCCに通っています 〜設計の学びは言語を越える〜

    「普段はPHPを書いています。でも、JJUG CCCに通っています」

    私は事業会社でPHPを使って開発しているエンジニアです。
    社内にJJUG CCCの登壇者がいたことでこのカンファレンスの存在を知り、2025 Springの資料を見て「設計に関するセッションが多い。これはPHPerが参加しても学びがあるのでは？」と2025 Fallに初参加しました。
    以来通い続け、今回で3回目になります。

    実際に参加してみると、期待以上でした。
    設計やデータベースの話は言語を越えて効く知識です。
    JJUG CCCのワークショップで学んだDB設計は、その後、社内でDB設計勉強会を開くところまでつながりました。
    言語に縛られずコミュニティに参加することで、新しい知識が手に入り、その学びがチームにも広がっていく——エンジニアとして楽しく成長できる。そんな実体験をお話しします。

    話すこと:
    ・PHPerがJJUG CCCに参加したきっかけ
    ・言語が違っても持ち帰れた知識の実例（設計・DB設計）
    ・持ち帰った学びが社内の勉強会開催につながった話
    ・明日からできる、隣の言語のコミュニティへの最初の一歩

    話さないこと:
    ・PHPとJavaの言語仕様比較
    ・エコシステムの比較

    こんな人におすすめ:
    ・自分の使う言語のコミュニティにしか参加したことがない人
    ・カンファレンスでの学びを現場に持ち帰る方法を探している人
    ・最近ちょっと学びがマンネリ気味だなと感じている人

    特別な事前知識は不要です。聴き終わったら、隣の言語のカンファレンスをひとつ調べたくなる20分にします。

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

  • Pure JavaでのLLM推論から学ぶVector APIとSIMD

    Vector APIは2018年にJEP 338でIncubatorとして提案されて以来、継続的に開発されていますが、Java SE 27でもまだ正式リリースされていません。一方、生成AIの領域ではPure JavaでLLM推論を行うライブラリでの活用が進み、IncubatorではありますがVector APIは注目を集め続けています。

    生成AIの主流であるTransformerアーキテクチャは行列・ベクトル演算が大部分を占めるため、現代CPUに標準搭載されたSIMD命令をJavaから直接活用できるVector APIは、Java×AI領域におけるコア技術の筆頭です。特にセキュリティ懸念やコスト高騰を背景とした「ローカル環境でのAI推論」において、高価なGPUに依存せず既存のJavaインフラ上でAIワークロードを動かせるのは魅力的です。

    本セッションでは、AI推論ライブラリ(llama3.javaなど)を題材に、以下を解説しVector APIへの理解を深めていきます。

    * Vector APIを用いた行列・ベクトル演算の実装パターン
    * HotSpotが生成するSIMD命令のアセンブリレベルの視覚化
    * CPU(Vector API)推論とGPU推論の構造的・性能的比較

    本セッションの対象は、
    * JavaでAI/LLM推論を動かす手法やローカル推論に関心がある方
    * Vector APIの書き方やSIMD活用に興味がある方
    * HotSpotの低レイヤーパフォーマンスに興味がある方
    になります。

    • Regular(45m)
    • Intermediate
    • Java SE
    • JVM
    • Language
    • AI

  • Semi-Realtime Data Warehouse with Trino, Apache Arrow, and Iceberg

    Kafkaに流れるストリームデータをKafka Streams, Apache Arrow, Icebergを組み合わせたデータストアに蓄積できる基盤を構築し、Trinoからクエリできる様にFlight SQL connectorを開発しました。

    この基盤により、数秒オーダーで秒間数万件を越える更新を反映でき、1000万を越えるクエリ結果を1、2分でクエリできるストリームデータウェアハウスを構築することが可能になりました。

    この発表では、Apache ArrowとFlight SQLを活用して従来のデータウェアハウスより遥かに短いリードタイムで大規模データをクエリ可能にするためのノウハウや、それを分散処理環境で実現するためのKafka Streamsの応用、Trinoコネクタの開発についてご紹介します。

    関係する技術要素
    Kafka, Kafka Streams, Apache Arrow, Iceberg, Trino

    • Regular(45m)
    • Advanced
    • Architecture
    • Database

  • Spring Boot 3→4アップグレードトラブル事例集

    Spring Boot 3と4では、ライブラリの細分化など多くの変更点があります。
    このセッションでは、これらの変更点により実際に業務で発生したトラブルおよびその原因や解決策を紹介します。
    併せて、Spring Bootのトラブルシュートで必要となるAuto Configurationの知識についても、分かりやすく解説します。
    紹介する予定のトラブル事例は次のとおりです。
    ・RestClientが起動しなくなった！
    ・AWS SDKをバージョンアップしたらRestClientの挙動がおかしくなった！
    ・AWS Lambda関数が起動しなくなった！
    ・Spring Sessionでセッション共有できなくなった！

    • Regular(45m)
    • Intermediate
    • Spring

  • Spring Boot でのリードレプリカ振り分け、実装と運用の勘所 〜MyBatis、JPA、jOOQ での実装例も紹介〜

    データベースの負荷を下げるために、更新は Writer（書き込み用）に、参照はリードレプリカ（参照専用）に振り分けたいケースがあります。
    Spring Boot で実現する手段として @Transactional(readOnly = true) と AbstractRoutingDataSource を組み合わせる方法が知られています。
    ただし、この2つを設定するだけでは振り分けは正しく機能せず、readOnly を指定したトランザクションも Writer に接続され得ます。
    原因は、振り分けの判定に readOnly の指定が伝わるより先にコネクションを取得してしまう処理順序にあります。
    コネクションの取得を遅延させることで対処でき、この考え方は OR マッパーが変わっても共通です。
    本セッションを終えたときには、ご自身が使っている OR マッパーで振り分けを実装し、運用で発生する問題にも備えられるようになることを目指します。

    ◾️このセッションで学べること:
    ・@Transactional(readOnly = true) だけでは振り分けられない理由と、その対処
    ・OR マッパーごとに異なる振り分け処理の実装方法（MyBatis、JPA（Hibernate）、jOOQ）
    ・運用上の問題への対処（更新直後の参照が古い値を返す、DDL 適用時に参照が失敗する等）

    ◾️想定するオーディエンス:
    ・Spring Boot でデータベースを使った機能を開発したことがある方
    ・リードレプリカの導入を検討している方
    ・Spring Boot でリードレプリカへの振り分け処理を実装する方

    ◾️話さないこと:
    ・リードレプリカの台数設計やインフラ構成
    ・検証していないデータベースを用いた場合の実装方法

    ※本セッションでは、Java 25、Spring Boot 4 系の最新版、リレーショナルデータベースに MySQL 8.4 と PostgreSQL 18 を用いています。

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

  • Spring Bootを使い続けるか？QuarkusへのAI活用した移行の実践

    Spring Bootを果たしてこのまま使い続けていいんだろうか
    でも、書き換えコストの捻出はしんどい
    ひとまずQuarkusに書き換えてみようか
    アプリケーションを、起動速度やメモリ効率に優れるQuarkusへ移行したい

    色々な思いはありつつも、大量のアノテーションやDIコンテナ、ビルド構成の書き換えコストに、Spring BootからQuarkusへの移行を阻まれていませんか？

    単なる文字列置換や汎用LLMへの丸投げでは、コード間の依存関係やフレームワーク固有の文脈を解釈しきれず、ビルドエラーの山に直面します。

    本セッションでは、AWS Transform Customの高度なコード変換メカニズムを活用し、Spring Boot（Spring MVC／Data JPA）をQuarkus（JAX-RS／CDI／Panache）へ、「ビルド＆テストが通る状態」まで一括自動変換する実践アプローチを解説します。

    バージョンアップに留まらない、「生成AIによるフレームワーク移行」の実践と可能性をお届けします。

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

  • SQLを書きたいJavaエンジニアへ、Domaの「ちょうどよさ」を推したい5つの理由

    Java で DB アクセスをするとき、JPA、Spring Data JDBC、MyBatis、jOOQ など、多くの選択肢があります。

    その中で私は長い間 Doma を使っています。

    Doma の魅力は、「SQL を自分で書けること」だけではありません。

    SQL や Java の考え方をなるべくそのまま残しながら、Annotation Processing や型の力を使って、面倒な部分や間違いやすい部分をコンパイル時に助けてくれます。

    普段はシンプルに使えますが、Domain、AggregateStrategy、Criteria API など、必要になれば一段高度なこともできます。それでも、フレームワーク独自の世界が必要以上に広がりません。

    本セッションでは Doma の機能を網羅的に紹介するのではなく、実際に Doma を使い続けてきた立場から、「なぜ Doma はちょうどいいと感じるのか」を紹介します。

    Doma を知らない人にも、Java の DB アクセスライブラリを選ぶ際の一つの選択肢として持ち帰ってもらうことを目指します。

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

  • Tackling Side Effects with Functional Programming and Flix: JVM関数型言語Flixで学ぶ副作用の分離/局所化戦略

    # セッション概要
    関数型プログラミングと呼ばれるプログラミングスタイルでは純粋関数と不変データが基本的なブロックとして重視される一方で、現実に意味のある振る舞いをもたらすにはプログラムのどこかで「副作用」を生じさせる必要に迫られます。
    新興のJVM関数型言語Flix (https://flix.dev/)を利用しながら、副作用をソフトウェアの中核から分離/局所化する典型的なアプローチを探ってみましょう。

    # 発表要旨
    JVMで動作する静的型付き関数型言語Flixのコード例とともに、関数型プログラミングの世界でよく知られている副作用の分離/局所化の手法を分かりやすく解説する。

    # このテーマを取り上げる理由
    関数型プログラミング(言語)に親しんでいくと自ずと直面する副作用との関わり方には、関数型言語に限らず任意の言語でのソフトウェア設計に有用な示唆が含まれており、(理論よりも)実践の観点から紹介したいと考えたため。

    # アジェンダ(仮)
    ## 導入
    1. 副作用とは何か、なぜ重要か
    2. Flix言語の基本(概要と書き方)
    3. 関数型プログラミングの道具箱
    ## 本編
    4. 副作用の分離/局所化のアプローチ
    - パラメータ化(高階関数)
    - 処理のデータ化と解釈(インタープリタ)
    - 型レベルの分離/局所化(モナド、代数的エフェクト)
    ## まとめ
    5. 副作用分離/局所化の基本戦略

    # 想定するオーディエンス
    - 何らかのJVM言語での開発経験がある
    - 関数型プログラミングに興味があるが、必ずしも関数型言語の学習/利用経験はない
    - Flixという言語を初めて知った(もしくは以前に知って興味があった)
    - DI (dependency injection)手法やソフトウェアテストのスタブ/モックとの付き合い方を見直したい

    # このセッションで聴講者にどういうメリットがあるか
    - 普段使いの言語や開発しているソフトウェアの文脈で副作用の分離/局所化を進める手がかりを得る
    - Flix言語を試してみたくなる

    # 発表の範囲
    ## 話すこと
    - 副作用の扱い方を議論する上で必要な範囲での関数型プログラミング一般とFlix言語の基礎解説
    - 副作用の分離/局所化に関わる典型的な手法

    ## 話さないこと
    - Flix言語の特徴や機能の網羅的な解説
    - 副作用の分離/局所化に関わるあらゆる手法の紹介

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

  • Value Classで何が変わる？

    Java 28で待望のValue ClassがPreviewとして導入されます。今までJavaではプリミティブ型と参照型という2種類の型が使用できましたが、Value Classはプリミティブ型と参照型の間を埋める新しい型となります。また、Value Classの導入によって、既存の標準ライブラリのクラスの一部がValue Classで再定義されています。

    本セッションでは、前半でValue Classがどのような型であるか解説し、その特徴についても紹介します。また、JVMによるValue Classの最適化についても言及します。

    後半では、Value ClassによるJavaのプログラミングスタイルの変化について議論します。

    • Regular(45m)
    • Intermediate
    • Java SE
    • JVM
    • Language

  • What’s new in Kotlin for Backend?

    There have been 4 minor releases of Kotlin since 2.0 bringing stable and experimental features to the language and improvements to Java interoperability.

    In this talk, we’ll highlight some of these particularly interesting for Backend JVM Developers, such as unused return value checks, explicit backing fields, name-based destructuring, collection literals, improved compile time constants and more.

    We’ll also cover JVM ecosystem improvements such as simplified JPA support, Maven quality of life changes, upcoming plans for the Lombok plugin, improved annotation handling and Java 26 support.

    Finally, we’ll briefly touch on improvements made to the Kotlin Standard Library.

    • Regular(45m)
    • Intermediate
    • JVM
    • Language
    • English

  • クライアントサイドを極小化しつつUXは犠牲にしないために ー Spring BootとhtmxでUIロジックをサーバーサイドに寄せるアーキテクチャ

    Webアプリケーションを開発する際、サーバーサイドとクライアントサイドを分け、JSONベースでデータのやり取りを行うアーキテクチャがしばしば語られます。

    一方で、Modelをそれぞれで管理する必要が生じたり、責務分担が曖昧になったりと、悩みごとが発生することも少なくありません。

    そんな中、UIロジックをサーバーサイドに寄せ、高性能なJavaScriptライブラリを用いなくても、実現できるUXは少なくないと考えています。

    本セッションでは、Spring Bootとhtmxを組み合わせ、UIロジックをサーバーサイドに寄せるアーキテクチャを取り上げ、クライアントサイドのロジックを極小化しつつUXは犠牲にしないための構成の一例をご紹介します。

    • Regular(20m)
    • Basic
    • Spring
    • Architecture
    • UI/UX

  • そのHTTP/3、Javaのどこに効く？― JDK 26とWebアプリの通信経路を整理する

    JDK 26では、標準のjava.net.http.HttpClientからHTTP/3を利用できるようになりました。

    このニュースを見て、私は最初に「Javaで作ったWebアプリをJDK 26へ更新すれば、ブラウザからの通信もHTTP/3になり、速くなるのではないか」と考えました。

    しかし、Webアプリの通信には、ブラウザからWebサーバーへの通信、WebサーバーからJavaアプリへの通信、Javaアプリやバッチから外部APIへの通信など、複数の区間があります。区間ごとにHTTPクライアントとHTTPサーバーが異なるため、JDKのHTTP/3対応が関係する場所も異なります。

    本セッションでは、Java Webアプリの通信経路を図で分解し、次の疑問を整理します。

    JDK 26のHTTP/3対応は、Javaシステムのどの通信に使えるのか
    ブラウザ向けWebアプリをHTTP/3対応させるには、どの構成要素が対応する必要があるのか
    Java WebアプリやバッチからAPIを呼び出す場合は、何が変わるのか
    HTTP/3を選択したとき、実際にHTTP/3で通信できたことをどう確認するのか

    実装例では、ローカルに蓄積したデータをサーバーへ送る小さな同期処理を題材にします。Java製の同期クライアントから、Spring Bootで作成したAPIへデータを送信し、JDK 26のHttpClientでHTTP/3を選択します。

    さらに、HttpResponse.version()を使って実際に利用されたHTTPバージョンを確認し、HTTP/3を利用できた場合と、別のHTTPバージョンが選択された場合の動きを観察します。

    「HTTP/3は新しいから速い」と一括りにするのではなく、自分が担当するシステムのどの通信区間に関係し、どのような用途で検討する価値があるのかを判断できるようになることが、本セッションのゴールです。

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

  • そのSpringコード、Javaとして説明できますか？ ～ 新人研修と現場のあいだを埋めるJava SE再入門 ～

    ■セッションの概要

    新人研修を終え、Springを使ったプロジェクトに配属された若手エンジニア。コードを書ける。テストも書ける。生成AIを使えば、知らないAPIを使った実装もできる。

    一方で、コードレビューやOJTの場で「この `.class` は何ですか？」「このラムダ式は何型ですか？」「このアノテーションはどういう仕組みで動いているのですか？」と聞いてみると、意外なところが「おまじない」のまま残っていることがあります。

    その背景の一つに、新人研修と実務で求められるJava知識の間にあるギャップがあります。

    本セッションでは、JUnitによるテストコードやSpringのカスタムバリデーションなど、若手エンジニアが現場で目にしやすいコードを題材に、その裏側にあるJava SEの言語仕様・標準APIを一段ずつ解きほぐします。「現場のコードをJavaそのものまで降りて読んでみる」ことで、おまじないだったコードが理解できるようになる体験を共有します。

    ■セッションで話すこと・スコープ

    実際のコードを入口として、「なぜこのように書けるのか」をJava SEに遡って読み解きます

    例えば、次のようなコードを扱います。

    * JUnitのテストコードから読み解く
    * ラムダ式
    * 関数型インターフェース
    * ネストしたクラス

    * Springのカスタムバリデーションから読み解く
    * enum
    * Annotation
    * Class クラス / class リテラル（ .class ）
    * default
    * equals / hashCode

    それぞれを単独の言語機能として紹介するのではなく、現場のコード → 分からない部分を取り出す → Java SEとして理解する → 元のコードをもう一度読むという流れで紹介します。

    また時間の許す範囲で、新人研修を終えたエンジニアに対して「どこまで分かっていることを期待してよいのか」「OJTやコードレビューでどのように補足すると理解につながりやすいのか」についても、講師としての若手育成の経験を交えて紹介します。

    ※JUnitやSpringの使い方を解説するセッションではありません（フレームワークの経験の有無とは関係なく参加いただけます）。

    ### 想定するオーディエンス

    若手エンジニアの受け入れ先。特に、OJT担当やチームリーダー等、若手エンジニアと技術的なコミュニケーションを取るかたを対象にお話します。また、若手エンジニア自身が、今後自身のキャッチアップする知識のカタログを得るためにも参加いただけます。

    ### このテーマを取り上げる理由

    近年の研修では大きく２つの流れを実感しています。ひとつは実践の重視です。クラウド・フレームワーク・開発演習などと引き換えに、言語仕様の理解は「細かい話」としてカリキュラムから押し出されています。もうひとつがAIです。若手エンジニアが実務的なコードを実装できるようになったことは、本人の理解度を見えにくくしています。

    こうした流れを背景に、フレームワークを使った開発における実装の一部が「おまじない」として不明なまま放置されやすい時代性があります。新人研修後に埋めるべきギャップの解像度を上げることが若手の自走の支援にも繋がると考え、取り上げることにしました。

    ### このセッションで聴講者にどういうメリットがあるか

    一般的な若手エンジニアと技術的なコミュニケーションを取る際に補足したほうがよい境界線はどこかといった感覚を養えます。また、セッションで利用するサンプルコードを持ち帰ることで、若手エンジニアと一緒に読み合わせや、若手への課題に活用いただけます。

    • Regular(45m)
    • Basic
    • Java SE
    • Spring
    • Test

  • ソフトウェアの実装と事業戦略を結びつけよう！

    事業活動のあらゆる側面でデジタル化が進んだことで、事業活動とソフトウェアシステムは広く深く連動し、双方向で強く影響を及ぼすようになってきました。

    このセッションでは、ソフトウェアの実装と事業戦略を結びつけることの価値と、ソフトウェアエンジニアが事業戦略を理解するために、何を学び、どう判断し行動すればよいかの指針を提示します。

    ソフトウェア設計の中級者向けに、上級者に進むための手掛かりを提供したいと思います。

    主な内容：

    ①事業活動の基本目的を理解する
    ②事業の基本目的を達成するための事業戦略とソフトウェアシステムの関係を理解する
    ③事業目的に適合したソフトウェアシステムを開発し発展させていくための基本原則を理解する

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

  • テストとアーキテクチャの不可分な関係

    アーキテクチャを決めたとき、それで何が決まったことになるでしょうか。構造や技術の選択は決まっている。では、そのシステムをどうテストするかは、決まっているでしょうか。

    テストを書く側から見ると、設計の段階で決まってしまっていることが多いように見受けられます。この部分をどうやってテストするのか。選んだミドルウェアはテスト環境で動かせるのか。外部システムを用意せずに検証できるのか。実装が始まってから問題として現れることが多く、その時点では打てる手が限られています。

    このセッションでは、アーキテクチャを決めるときにテストについて何を決めておけるのかを考えます。設計を決める立場からではなく、決まった設計の上でテストを書いてきた立場から、設計の時点で考慮しておいたほうがよいことを挙げていきます。

    テスト容易性を最優先すべきだ、という話をするつもりはありません。設計は常にトレードオフで、状況によっては捨てる判断もありえます。ただし、捨てると決めるためには天秤に何が載っているかが見えている必要があります。そのために何を見ておくべきかを、一緒に考えられればと思います。

    想定するオーディエンス・対象オーディエンス：
    - アーキテクチャを決める立場にある方、またはその議論に参加する方
    - 既存の設計の上でテストを書いていて、辛さの原因を言語化したい方
    - テスト基盤の整備や展開を担っている方
    - 新規プロジェクトの立ち上げを控えている方

    推奨する前提知識：
    JUnit等でテストコードを書いた経験と、レイヤーを分けたアプリケーションの開発経験があればついてこられる内容。特定のフレームワークやDDDの知識は前提としない。

    このテーマを取り上げる理由：
    「テストしやすい設計にしよう」という主張に正面から反対する人はほとんどいません。にもかかわらず、設計を決める場でテストの話が十分に議論されないまま進むことがあるように見受けられます。性能や可用性は非機能要件として検討されるのに、テスト容易性は実装が始まってから問題になることが多い。その差はどこから来るのかを考えたいと思っています。

    セッションで話すこと：
    - 設計上の判断が、テストの書きやすさ・実行しやすさにどう影響するか
    - 技術選定の時点で「テスト可能か」を確認することの意味と、確認した上で見積もるべきコスト
    - テスト基盤（テスト用の道具立て・フィクスチャの仕組み）をいつ誰が用意するか
    - テストの書き方も設計に依存すること（同じ書き方が設計によって適切にも不適切にもなる）
    - テスト容易性はトレードオフであることと、判断する際に何を見るべきか

    セッションで話さないこと：
    - 「この層にはこのテストを書く」という具体的な対応表の提示
    - 特定のアーキテクチャスタイル（Clean Architecture等）の解説や推奨
    - 特定のテストフレームワーク・ライブラリの網羅的な機能紹介
    - E2Eテスト、性能テストの手法
    - CI/CD環境の構築手順

    • Regular(45m)
    • Intermediate
    • Architecture
    • Design
    • Test

  • リファクタリング再入門 & AI時代の価値考察

    リファクタリングはマーチン・ファウラーの2000年の書籍「リファクタリング」によって整理された概念として広く認知されるようになりました。
    しかし「リファクタリング」という語の認知が広まるとともに、その理解は曖昧になり、単なるコードの書き直しを「リファクタリング」と呼んでしまっている人も散見されます。

    本セッションではまず元来の「リファクタリング」がどういうものであったかを再確認します。「外部から見たときの振る舞いを保つ」ために書籍「リファクタリング」は非常に慎重なステップで作業をします。その意義を確認しましょう。

    後半では、このリファクタリングの価値について、AIが普及した2026年の状況を踏まえて再検討します。
    リファクタリングをEpiplexity : 構造抽出性 という概念で捉えなおし、現代に取るべき指針を示します。

    本セッションに関しては特別な前提知識は必要ありません。
    用語や概念説明などについて基礎的なところから解説します。

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

  • 分割統治により仕様駆動開発を大規模開発につなげる試み

    仕様駆動開発では、Markdownなどのドキュメントに仕様を記述し、それを基にAIエージェントと開発を進めます。しかし、仕様が大規模になるにつれて、エージェントによる参照漏れや仕様間の不整合、処理効率の低下が起こりやすくなります。

    一方で、仕様を早い段階から細かく分割し、それぞれを独立して実装すると、アプリケーション全体の整合性を保ちにくくなります。局所的には正しい実装であっても、後から組み合わせた際に矛盾が見つかり、大きな手戻りが発生することもあります。

    本セッションでは、要件定義やアーキテクチャ設計などの上流工程に「分割統治」の考え方を適用し、全体像を維持したまま仕様を階層的に分解するアプローチを紹介します。大きなスコープを一度に設計しつつ、詳細設計や実装では、AIエージェントが扱いやすい単位へ段階的に分割していきます。

    実際に分割統治をつかって数万行規模のMarkdownによる仕様・設計・実装プロセスを実践した経験から、次の内容を解説します。

    * 大規模な仕様をどのような単位で分割するか
    * 分割した仕様の境界、依存関係、整合性をどのように管理するか
    * AIエージェントへ渡すコンテキストをどのように構成するか
    * 分割して生成した詳細設計や実装をどのように統合・検証するか
    * 仕様変更を各階層へどのように伝播させるか

    また、うまく機能した部分だけでなく、現在も十分に解決できていない課題についても共有します。

    特定のAIエージェントの操作方法を扱うのではなく、大規模な仕様駆動開発を成立させるための設計方法と開発プロセスに焦点を当てます。

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

  • 暴走・トークン消費・属人化 ― AI開発の"3つの壁"を、Javaの三層アーキテクチャで越える

    【セッション概要】
    10年以上運用が続くマッチングアプリ Omiai のJavaバックエンドにAIコーディングエージェントを導入しました。最初の数ヶ月は失敗の連続です。意図しない実装が量産され（暴走）、トークン上限に張り付いて業務が止まり（トークン消費）、使いこなせる人にだけ仕事が寄りました（属人化）。

    抜け出せた理由は、より賢いモデルではありませんでした。「AIに一度に渡す範囲を、三層アーキテクチャの境界で切る」と決めたことです。Presentation / BusinessLogic / DataAccess ―― Javaの世界で長く語られてきた三層の境界が、そのまま「AIに渡してよい単位」の定義として使えました。

    本セッションでは、そのために整備した規約・仕様書・実装手順を、どう作りどう運用しているか、実際の流れに沿ってお見せします。

    【アジェンダ】
    1. 3つの壁の実態 - AIコーディングエージェントを入れて起きた問題（3分）
    2. なぜ「三層アーキテクチャ」がAIへの分割単位になったのか（3分）
    3. 工夫1：三層それぞれの規約に「やらないこと」を書く（4分）
    4. 工夫2：API仕様書に「使用データ一覧」を入れ、実装の入力を集約する（4分）
    5. 工夫3：1つの実装手順に、1つの層だけを担当させる（3分）
    6. 結果と、最後まで人間に残った仕事（2分）

    【話すこと】
    ・既存の大規模Javaコードベースを、AIが扱える形に作り変えた具体的な手順。実際に運用している規約・仕様書・実装手順を提示します
    ・Javaの三層アーキテクチャによる責務の分割が、そのまま「AIに渡すコンテキストの分割単位」として使えた理由。両者の相性の良さを具体例で示します
    ・「やること」だけを書いた規約では、AIは書かれていない部分を「やってよい」と解釈する。禁止事項を書いて初めて判断余地が潰れるという話
    ・実装リードタイム3日→1日など、自社での実測値
    ・AIに任せられなかった領域

    【話さないこと】
    ・モデルの性能比較やベンチマーク、プロンプトエンジニアリングのテクニック集
    ・特定のAIエージェント製品の操作手順・料金・導入方法
    ・LLMの内部構造、RAGやファインチューニングの解説
    ・自社サービスの宣伝、採用に関する告知

    【想定オーディエンス】
    ・中〜大規模のJavaアプリケーションを業務で保守・拡張しているエンジニア、テックリード
    ・コーディングエージェントを試したが、精度・コスト・チームへの定着で行き詰まった方
    ・レガシーを抱えたままAI活用の導入判断を求められている立場の方

    AIエージェント側の予備知識は不要です。特定のツールやモデルに依存しない、設計と手順の話として持ち帰っていただける構成にします。

    • Regular(20m)
    • Basic
    • Architecture
    • AI

  • 週末プログラマー、AIエージェントに出会う 〜書きながらJava 25に追いつく〜

    【背景】
    マネジメント中心になり、仕事でコードを書く機会がほぼなくなりました。
    Javaの知識は 8 のあたりで止まったまま、25 には追いつけていません。

    週末に個人ツールを作ろうとしても、翌週末には前回何を考えていたか忘れている。
    新しい書き方を学ぼうとしているうちに時間が溶け、いつも未完成のまま放置していました。

    AIエージェントを使い始めて、これが変わりました。
    まず動くものを作り、知らない書き方を後から理解する。
    Claude Code で Spring Boot + Vue.js のツールを作りながら、
    Java 8 世代の知識のまま 25 にキャッチアップしつつツールを完成させました。

    【話すこと】
    ・AIを利用したJavaの新しい記法の学び方
    - AIにJava 25 を基本とするよう指示する
    - 生成されたコードのうち、自分が読めない記述を説明させる
    ・限られた時間で個人開発を完走させるための、AIエージェントとの付き合い方
    - コードから仕様を逆生成させ、翌週の起点にする

    【話さないこと】
    ・AIエージェント各製品の比較
    ・Java 25 の新機能そのものの網羅的な解説
    ・チーム開発や組織へのAI導入
    ・作ったツール自体の機能紹介

    【対象者】
    ・マネジメント中心になり、Javaから離れていた方
    ・週末や隙間時間しかキャッチアップの時間が取れない方

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

  • 遅いテストを速くする

    AIによるコード生成の普及でテストの実行頻度が上がり, テストが遅いことが問題として上がるようになってきています. しかしテストを速くするには検証を減らしたり, テストを並列実行したりといった話になりがちです.

    この発表ではテストピラミッドに注目してテストピラミッドの各段で何を検証すべきかを考えます. E2Eテストと単体テストとで同じようなテストケースが実行されていれば, 検証内容にも重複が多く無駄の多いテストとなってしまいます. 具体的にはデータベースを使ったテストやSpringBootTestではなにを検証すべきかを考え, こういったテストを減らし単体テストによる速いテストを増やす方法を説明します. これにより検証内容を減らさずにテストを速くできることを目指します.

    ## 話さないこと

    - テストの並列実行
    - CIツールの実行方法, キャッシュの活用など

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