Kotlinで型安全にバイテンポラルデータを扱いたい！ ReladomoラッパーをAIと実装してみた話

Transcript

1. Kotlinで型安全にバイテンポラルデータを扱いたい！ ReladomoラッパーをAIと実装してみた話 Kotlin Fest 2025 2025年11⽉01⽇ 株式会社ログラス 執⾏役員CTO 伊藤博志（いとひろ @itohiro73） 1
2. #KotlinFest ⾃⼰紹介 2 ゴールドマン・サックスのテクノロジー部に新卒入社後、同社の機関システム開発に 従事。その後、VP/Senior Engineerとしてプラットフォーム開発に携わり、同社 発のJavaのOSSであるEclipse Collectionsのコミッター兼プロジェクトリード やOpenJDKへのコントリビュートを行うなど、OSS戦略を牽引。 スタートアップ2社を経て、READYFORに入社し執行役員VPoEに就任。 同社のエンジニア組織の10名から30名規模への成長、決済基盤の刷新や、技術的 負債の返済、新規プロダクト開発を牽引。 2022年10月に株式会社ログラスの開発部へエンジニアとして入社。 エンジニアリングマネージャー、事業執行役員VPoEを経て、現職。 株式会社ログラス 執行役員 CTO 伊藤 博志 （いとひろ @itohiro73） Hiroshi Ito
3. #KotlinFest 本⽇のアジェンダ 3 1. はじめに: RDBでの履歴管理‧時点情報管理の難しさ 2. テンポラルデータモデルとは 3. Reladomoの紹介 4. ReladomoをKotlin/Spring Bootで使う際の課題 5. reladomo-kotlinをClaude Codeと協働開発 6. reladomo-kotlinの機能紹介 7. デモ：Chronostaff 8. 得られた知⾒とまとめ
4. はじめに: RDBでの履歴管理‧ 時点情報管理の難しさ 4
5. #KotlinFest RDB上で履歴情報‧時点情報を管理するのがむずかしい... ❌ 「このデータ、先⽉どうだったっけ？」 → updated_atしかない... ❌ 「いつ、誰が変更したの？」 → 変更ログが散在 ❌ 「来⽉からの予定を記録したい」 → データモデリングが複雑 みなさん、こんなご経験はありませんか？ 5
6. #KotlinFest RDB上で履歴情報‧時点情報を管理するのがむずかしい... 例えばこんな解決法があるか...？ 1. updated_atだけで管理 a. 過去の状態が追跡できない b. 「いつの時点で何を知っていたか」が不明 2. 履歴テーブルの活⽤ a. employees, employees_history, employees_log… b. 複雑なJOIN、パフォーマンス問題 c. 整合性の維持が困難 3. JSON/Blobに履歴を詰め込む a. クエリ不可 b. 型安全性の喪失 みなさん、こんなご経験はありませんか？ 6
7. #KotlinFest RDB上で履歴情報‧時点情報を管理するのがむずかしい... RDBの構造上、履歴データ‧時点管理をするのは性質としてそもそも難しい。 その解決法の⼀つとして、「テンポラルデータモデル」と、それをサポートするJava ORM「Reladomo」を紹 介したいと思います。 参考資料: 「データ履歴管理のためのテンポラルデータモデルとReladomoの紹介」 みなさん、こんなご経験はありませんか？ 7
8. テンポラルデータモデルとは 8
9. #KotlinFest リアルライフシナリオで理解する、データの時点管理 📦 商品価格管理システム あるECサイトの商品「ノートPC」の価格変更履歴: テンポラルデータモデル 9 日付 出来事 1月1日 商品登録、価格10万円でスタート 2月1日 キャンペーンで8万円に値下げ 3月1日 キャンペーン終了、10万円に戻す 3月5日 「2月1日の値下げ、実は7万円だっ た」と気づいて訂正 🤔 よくある質問 1. 「今の価格は？」→ 10万円 2. 「2月15日時点の価格は？」 → 8万円？7万円？ 3. 「3月4日時点では2月15日の価格は何だと思ってい た？」→ 8万円 4. 「3月5日に訂正した履歴も残したい」 → どうする？ これらを全て記録するには？
10. #KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル1: スナップショットデータモデル（時点管理をしないモデル） 最もシンプル - 現在の状態だけ保持する テンポラルデータモデル 10
11. #KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル1: スナップショットデータモデル（時点管理をしないモデル） 最もシンプル - 現在の状態だけ保持する テンポラルデータモデル 11 id name price updated_at 1 ノートPC 100,000 2024-01-01 10:00 id name price updated_at 1 ノートPC 100,000 → 80,000 2024-01-01 → 2024-02-01 09:00 id name price updated_at 1 ノートPC 80,000 → 100,000 2024-02-01 → 2024-03-01 08:00 ✅ できること • 現在の価格を取得 • シンプルな実装 ❌ できないこと • ❌ 「2月15日の価格は？」→ わからない （既に上書き） • ❌ 「誰がいつ変更した？」 → わからない （履歴なし） • ❌ 「過去の価格推移を分析」 → 不可能 問題: 履歴が残らない → 分析・監査・復元が不可能
12. #KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル2: トランザクション時間データモデル 「いつ記録したか」を記録 テンポラルデータモデル 12
13. #KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル2: トランザクション時間データモデル 「いつ記録したか」を記録 テンポラルデータモデル 13 id name price transaction_from transaction_to 1 ノートPC 100,000 2024-01-01 10:00 9999-12-31 1月1日 10:00: 商品登録 id name price transaction_from transaction_to 1 ノートPC 100,000 2024-01-01 10:00 2024-02-01 09:00 ⬅ 終了 1 ノートPC 80,000 2024-02-01 09:00 9999-12-31 ⬅ 新規 2月1日 09:00: 値下げ → 古いレコードを終了、新レコード追加
14. #KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル2: トランザクション時間データモデル 「いつ記録したか」を記録 テンポラルデータモデル 14 id name price transaction_from transaction_to 1 ノートPC 100,000 2024-01-01 10:00 2024-02-01 09:00 1 ノートPC 80,000 2024-02-01 09:00 2024-03-01 08:00 ⬅ 終了 1 ノートPC 100,000 2024-03-01 08:00 9999-12-31 ⬅ 新規 3月1日 08:00: 値上げの最新情報を登録
15. #KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル2: トランザクション時間データモデル 「いつ記録したか」を記録 テンポラルデータモデル 15 3月5日 15:00: 訂正「2月の値下げ、実は 7万円だった」 => トランザクション時間データモデル単体では表現が不可能 id name price transaction_from transaction_to 1 ノートPC 100,000 2024-01-01 10:00 2024-02-01 09:00 1 ノートPC 80,000 2024-02-01 09:00 2024-03-01 08:00 1 ノートPC 100,000 2024-03-01 08:00 9999-12-31
16. #KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル2: トランザクション時間データモデル 「いつ記録したか」を記録 テンポラルデータモデル 16 3月5日 15:00: 訂正「2月の値下げ、実は 7万円だった」 => トランザクション時間データモデル単体では表現が不可能 id name price transaction_from transaction_to 1 ノートPC 100,000 2024-01-01 10:00 2024-02-01 09:00 1 ノートPC 80,000 2024-02-01 09:00 2024-03-01 08:00 1 ノートPC 100,000 2024-03-01 08:00 9999-12-31 ✅ できること • ✅ 「3月4日時点では何を信じていた？」 → 8万円（transaction_to > 3/4のレコード） • ✅ 時間軸に伴った変更の監査証跡 • ✅ データ復元（タイムトラベル） ❌ できないこと • ❌ 「過去のある時点の有効情報を訂正する」 → 過去のある時点で8万円ではなく7万円だった という修正はトランザクション時間単体ではできない • ❌ 「2月15日の価格は？」→ わからない ◦ なぜ？ transaction_from = 2/1、transaction_to = 3/5 ◦ これは「2/1~3/5の間、システム上は 8万円だと記録していた」という意味 ◦ 実際に2/15時点で有効だった価格かは不明 問題: 「システム上の記録」の履歴は追えるが「実際にいつ有効だったか」がわからない
17. #KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル3: 有効時間データモデル 「いつ有効か」を記録 テンポラルデータモデル 17
18. #KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル3: 有効時間データモデル 「いつ有効か」を記録 テンポラルデータモデル 18 id name price valid_from valid_to 1 ノートPC 100,000 2024-01-01 10:00 9999-12-31 1月1日 10:00: 商品登録「 1月1日から10万円」 id name price valid_from valid_to 1 ノートPC 100,000 2024-01-01 2024-02-01 ⬅ 期間短縮 1 ノートPC 80,000 2024-02-01 9999-12-31 ⬅ 新規 2月1日 09:00: 値下げ → 値下げ「 2月1日から8万円」→ 期間を分割
19. #KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル3: 有効時間データモデル 「いつ有効か」を記録 テンポラルデータモデル 19 id name price valid_from valid_to 1 ノートPC 100,000 2024-01-01 2024-02-01 1 ノートPC 80,000 2024-02-01 2024-03-01 ⬅ 期間短縮 1 ノートPC 100,000 2024-03-01 9999-12-31 ⬅ 新規 3月1日 08:00: 値上げ「 3月1日から10万円」
20. #KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル3: 有効時間データモデル 「いつ有効か」を記録 テンポラルデータモデル 20 id name price valid_from valid_to 1 ノートPC 100,000 2024-01-01 2024-02-01 1 ノートPC 80,000 → 70,000 2024-02-01 2024-03-01 ⬅ 上書き 1 ノートPC 100,000 2024-03-01 9999-12-31 3月5日 15:00: 訂正「2月の値下げ、実は 7万円だった」 → 過去を上書き 問題: 8万円という間違いの記録が消えてしまう
21. #KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル3: 有効時間データモデル 「いつ有効か」を記録 テンポラルデータモデル 21 id name price valid_from valid_to 1 ノートPC 100,000 2024-01-01 2024-02-01 1 ノートPC 80,000 → 70,000 2024-02-01 2024-03-01 ⬅ 上書き 1 ノートPC 100,000 2024-03-01 9999-12-31 3月5日 15:00: 訂正「2月の値下げ、実は 7万円だった」 → 過去を上書き 問題: 8万円という間違いの記録が消えてしまう ✅ できること • ✅ 「2月15日の価格は？」→ 7万円（valid_from ≤ 2/15 < valid_to） • ✅ 「将来の価格変更を予約」 → valid_from = 未来の日付で登録可能 • ✅ 過去の任意時点の価格を取得 ❌ できないこと • ❌ 「3月4日時点では2月15日の価格は何だと思っていた？」 → わからない ◦ 訂正後のデータ（7万円）しか残っていない ◦ 「8万円だと思っていた」履歴は消えてしまう • ❌ 修正の履歴がない → 監査証跡不完全 問題: 訂正すると元の間違いが消える → 監査証跡が失われる
22. #KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル4: バイテンポラルデータモデル 2つの時間軸を同時に記録 テンポラルデータモデル 22
23. #KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル4: バイテンポラルデータモデル 2つの時間軸を同時に記録 テンポラルデータモデル 23 id name price valid_from valid_to transaction_from transaction_to 1 ノートPC 100,000 2024-01-01 9999-12-31 2024-01-01 10:00 9999-12-31 1月1日 10:00: 商品登録「 1月1日から10万円」
24. #KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル4: バイテンポラルデータモデル 2つの時間軸を同時に記録 テンポラルデータモデル 24 id name price valid_from valid_to transaction_from transaction_to 1 ノートPC 100,000 2024-01-01 2024-02-01 2024-01-01 10:00 2024-02-01 09:00 ⬅ 終了 1 ノートPC 100,000 2024-01-01 2024-02-01 2024-02-01 09:00 9999-12-31 ⬅ 継続 版 1 ノートPC 80,000 2024-02-01 9999-12-31 2024-02-01 09:00 9999-12-31 ⬅ 新規 2月1日 09:00: 値下げ「 2月1日から8万円」
25. #KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル4: バイテンポラルデータモデル 2つの時間軸を同時に記録 テンポラルデータモデル 25 id name price valid_from valid_to transaction_from transaction_to 1 ノートPC 100,000 2024-01-01 2024-02-01 2024-01-01 10:00 2024-02-01 09:00 1 ノートPC 100,000 2024-01-01 2024-02-01 2024-02-01 09:00 9999-12-31 1 ノートPC 80,000 2024-02-01 2024-03-01 2024-02-01 09:00 2024-03-01 08:00 ⬅ 終了 1 ノートPC 80,000 2024-02-01 2024-03-01 2024-03-01 08:00 9999-12-31 ⬅ 継続 版 1 ノートPC 100,000 2024-03-01 9999-12-31 2024-03-01 08:00 9999-12-31 ⬅ 新規 3月1日 08:00: 値上げ「 3月1日から10万円」
26. #KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル4: バイテンポラルデータモデル 2つの時間軸を同時に記録 テンポラルデータモデル 26 id name price valid_from valid_to transaction_from transaction_to 1 ノートPC 100,000 2024-01-01 2024-02-01 2024-01-01 10:00 2024-02-01 09:00 1 ノートPC 100,000 2024-01-01 2024-02-01 2024-02-01 09:00 9999-12-31 1 ノートPC 80,000 2024-02-01 2024-03-01 2024-02-01 09:00 2024-03-05 15:00 ⬅ 終 了（間違い） 1 ノートPC 80,000 2024-02-01 2024-03-01 2024-03-01 08:00 2024-03-05 15:00 ⬅ 終 了 1 ノートPC 100,000 2024-03-01 9999-12-31 2024-03-01 08:00 2024-03-05 15:00 ⬅ 終 了 1 ノートPC 70,000 2024-02-01 2024-03-01 2024-03-05 15:00 9999-12-31 ⬅ 訂正後 1 ノートPC 100,000 2024-03-01 9999-12-31 2024-03-05 15:00 9999-12-31 ⬅ 継続版 3月5日 15:00: 訂正「2月の値下げ、実は 7万円だった」 → 間違いの記録も残る
27. #KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル4: バイテンポラルデータモデル 2つの時間軸を同時に記録 テンポラルデータモデル 27 id name price valid_from valid_to transaction_from transaction_to 1 ノートPC 100,000 2024-01-01 2024-02-01 2024-01-01 10:00 2024-02-01 09:00 1 ノートPC 100,000 2024-01-01 2024-02-01 2024-02-01 09:00 9999-12-31 1 ノートPC 80,000 2024-02-01 2024-03-01 2024-02-01 09:00 2024-03-05 15:00 ⬅ 終 了（間違い） 1 ノートPC 80,000 2024-02-01 2024-03-01 2024-03-01 08:00 2024-03-05 15:00 ⬅ 終 了 1 ノートPC 100,000 2024-03-01 9999-12-31 2024-03-01 08:00 2024-03-05 15:00 ⬅ 終 了 1 ノートPC 70,000 2024-02-01 2024-03-01 2024-03-05 15:00 9999-12-31 ⬅ 訂正後 1 ノートPC 100,000 2024-03-01 9999-12-31 2024-03-05 15:00 9999-12-31 ⬅ 継続版 3月5日 15:00: 訂正「2月の値下げ、実は 7万円だった」 → 間違いの記録も残る ✅ できること • ✅ 「現在の価格は？」→ 10万円 • ✅ 「2月15日の価格は？」→ 7万円（訂正後の正しい価格） • ✅ 「3月4日時点では2月15日の価格は何だと思っていた？」 → 8万円 • ✅ 「訂正履歴も残る」→ 8万円→7万円の訂正記録 • ✅ 将来の価格変更を予約 • ✅ 完全な監査証跡 • ✅ タイムトラベル（任意の時点の知識状態を復元） ❌ デメリット • ⚠ テーブル設計が複雑 • ⚠ クエリが複雑（2つの時間軸を考慮） • ⚠ データ量増加（訂正のたびにレコード追加）
28. #KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル4: バイテンポラルデータモデル 2つの時間軸を同時に記録 テンポラルデータモデル 28 クエリ方法 1: 「現在の価格は？」
29. #KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル4: バイテンポラルデータモデル 2つの時間軸を同時に記録 テンポラルデータモデル 29 クエリ方法 2: 「2月15日の価格は？」
30. #KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル4: バイテンポラルデータモデル 2つの時間軸を同時に記録 テンポラルデータモデル 30 クエリ方法 3: 「3月4日時点では、 2月15日の価格は何だと思っていた？」
31. #KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル4: バイテンポラルデータモデル 2つの時間軸を同時に記録 テンポラルデータモデル 31 クエリ方法 4: 「訂正履歴を全て表示」
32. #KotlinFest リアルライフシナリオで理解する、データの時点管理 まとめ 時点管理を⾏わないスナップショットデータモデルと、時点管理をDB上で表現するテンポラルデータモデルとして「トラ ンザクション時間データモデル」「有効時間データモデル」「バイテンポラルデータモデル」をそれぞれ紹介 テンポラルデータモデル 32 機能 スナップショット トランザクション時間 有効時間 バイテンポラル 現在の状態 ✅ ✅ ✅ ✅ 履歴参照 ❌ ✅ ✅ ✅ 「2月15日の価格は？」 ❌ ❌ ✅ ✅ 将来予約 ❌ ❌ ✅ ✅ 「3月4日時点で2月15日の価格は？」 ❌ ❌ ❌ ✅ 訂正履歴 ❌ ⚠ 記録としてのみ ❌ ✅ 完全な監査証跡 ❌ ⚠ 部分的 ❌ ✅ タイムトラベル ❌ ⚠ 記録時点のみ ⚠ 有効時点のみ ✅
33. Reladomoの紹介 33
34. #KotlinFest エンタープライズグレードのバイテンポラルデータモデルをサポートするJava ORM https://github.com/goldmansachs/reladomo • ゴールドマン‧サックスが開発し、OSSとして公開 ‐ 複雑な業務ロジックを持つ⼤規模システム向けに設計されたJava ORM • バイテンポラルデータモデルを透過的にサポート ‐ 有効時間 (Business Date)とトランザクション時間 (Processing Date)をネイティブサポート • 型安全なクエリ⾔語 ‐ リフレクションを使わず、静的に型付けられたクエリを⽣成 • ⾼度な機能 ‐ トランザクション管理（変更履歴の⾃動追跡） ‐ シャーディング（複数DBへのデータ分散）を透過的にサポート Reladomoとは？ 34
35. #KotlinFest バイテンポラルネイティブ対応 • データモデルをXML（！）で定義するだけ でバイテンポラルデータモデルをサポート するオブジェクトのコードを⾃動⽣成。 • ⾃前でコードを書くことなくバイテンポラ ルを操作することができるクエリを構築で きるDSLも同時に⼿に⼊れられる Reladomo: 強みの詳細 35
36. #KotlinFest 複雑性を型安全にAPIで吸収 - Java コード例 Reladomo: 強みの詳細 36
37. #KotlinFest 複雑性を型安全にAPIで吸収 - Java コード例 Reladomo: 強みの詳細 37
38. #KotlinFest パフォーマンス関連機能の充実 • Deep Fetchという事前フェッチ機能でN+1 問題を回避 • カーソルをつかったインメモリのストリー ミング処理による⼤量データ処理 Reladomo: 強みの詳細 38
39. #KotlinFest パフォーマンス関連機能の充実 • Deep Fetchという事前フェッチ機能でN+1 問題を回避 • カーソルをつかったインメモリのストリー ミング処理による⼤量データ処理 Reladomo: 強みの詳細 39
40. #KotlinFest パフォーマンス関連機能の充実 • Deep Fetchという事前フェッチ機能でN+1 問題を回避 • カーソルをつかったインメモリのストリー ミング処理による⼤量データ処理 Reladomo: 強みの詳細 40
41. #KotlinFest Relationshipのネイティブサポート • Relationshipを設定ファイル上で定義するこ とで関連を持つレコードをドメインモデル として⾃然な形で取得可能 Reladomo: 強みの詳細 41
42. ReladomoをKotlin/Spring Bootで使う際の課題 42
43. #KotlinFest 課題1: ⽣成されるJavaコードがKotlinの強みを活かせない Javaの⾃動⽣成コード ReladomoをKotlin/Spring Bootで使う際の課題 43
44. #KotlinFest 課題1: ⽣成されるJavaコードがKotlinの強みを活かせない Kotlinから使うと: ReladomoをKotlin/Spring Bootで使う際の課題 44
45. #KotlinFest 課題1: ⽣成されるJavaコードがKotlinの強みを活かせない Kotlinで書きたいコード: ReladomoをKotlin/Spring Bootで使う際の課題 45
46. #KotlinFest 課題2: エンティティ定義⽤のXMLを⼿書きする必要がある ReladomoをKotlin/Spring Bootで使う際の課題 46
47. #KotlinFest 課題3: ⼤量のボイラープレートコード - 初期化コード ReladomoをKotlin/Spring Bootで使う際の課題 47
48. #KotlinFest 課題3: ⼤量のボイラープレートコード - DataSource設定 ReladomoをKotlin/Spring Bootで使う際の課題 48
49. #KotlinFest 課題3: ⼤量のボイラープレートコード - エンティティごとのSequenceFactory実装 ReladomoをKotlin/Spring Bootで使う際の課題 49
50. #KotlinFest 課題3: ⼤量のボイラープレートコード - Spring Beanとして登録 ReladomoをKotlin/Spring Bootで使う際の課題 50
51. #KotlinFest 課題4: Spring Dataパターンが適⽤しずらい ReladomoをKotlin/Spring Bootで使う際の課題 51
52. #KotlinFest 課題4: Spring Dataパターンが適⽤しずらい ReladomoをKotlin/Spring Bootで使う際の課題 52
53. reladomo-kotlinをClaude Codeと協働開発 53
54. #KotlinFest やりたいけど時間がなくて諦めていたことが、かなり簡単にできるように AIコーディングエージェントが⾮常に優秀... 54
55. #KotlinFest 実はこのころ電⾞の通勤時間にAndroid上でコーディングするのがマイブーム AIコーディングエージェントが⾮常に優秀... 55
56. #KotlinFest reladomo-kotlinは電⾞の中でAndroid上で完成しました https://github.com/itohiro73/reladomo-kotlin AIコーディングエージェントが⾮常に優秀... 56
57. #KotlinFest シンプル: KotlinでReladomoを扱う際の課題感をインプットしただけ ⼊⼒したプロンプト（失われてしまったのでうろ覚え再現） ReladomoをKotlin/Spring Bootで扱おうとすると、様々な課題があります - XMLで⾃動⽣成されたJavaのコードがKotlinと親和性が良くない - ボイラープレートな初期設定を⼿動で書かなければいけない - Spring Bootとのインテグレーションがないため、開発初期スピードが上がらない これらの課題を解決するreladomo-kotlinというライブラリを開発したいので、要件‧仕様を設計し、MVPの実 装プランを⽴ててください => ここから出てきた仕様提案にフィードバックを送りつつ、理想的な形へとガイドしながら開発。⼈間は1⾏もコードを書い ていない Claude Codeで何をしたのか？ 57
58. #KotlinFest Maven Centralへのリリース⼿順の作成 Maven Centralリリース⽤のGitHub Actionsや、リリースの際の⼿順書をClaude Codeに作ってもら い、ただただそれを実⾏すればよい状態に Claude Codeで何をしたのか？ 58
59. #KotlinFest Maven Centralへのリリース⼿順の作成 Maven Centralリリース⽤のGitHub Actionsや、リリースの際の⼿順書をClaude Codeに作ってもら い、ただただそれを実⾏すればよい状態に => 無事リリース！ Claude Codeで何をしたのか？ 59
60. #KotlinFest reladomo-kotlinというラッパーライブラリを⼈間が作ろうと思ったら おそらくフルタイムで数ヶ⽉はかかるであろう分量 - Javaのコード⽣成機能をどうKotlinコードに変換するべきかを調査‧設計‧実装 - 既存のコード⽣成ロジックの精査 - Kotlinコードの理想状態を定義 - Gradle Pluginとしてのプラクティスを調査しつつプラグイン設計‧実装 - Spring Bootに統合するための既存Reladomoの動作理解とSpring Boot上の詳細機能調査 + 設計実装 - リリースビルドや⼿順書の作成 - テストの作成 - 等々 => Claude Codeに電⾞の中でスマホ内で数⽇で完成...！ AIコーディングエージェントの強⼒さを⽬の当たりに 60
61. reladomo-kotlinの機能紹介 61
62. #KotlinFest 課題1: ⽣成されるJavaコードがKotlinの強みを活かせない => Kotlinコード⽣成 理想的なKotlinコードを ⾃動⽣成 Reladomoの課題に対するreladomo-kotolinの解決法 62
63. #KotlinFest 課題2: エンティティ定義⽤のXMLを⼿書きする必要がある => Annotation-Based Configuration アノテーションから XMLとコードを⾃動⽣成 （実装WIP） Reladomoの課題に対するreladomo-kotolinの解決法 63
64. #KotlinFest 課題3: ⼤量のボイラープレートコード => Gradleプラグインによるボイラープレート対応 プラグインへの依存を⾜すだけで、 以下が全て⾃動設定される: • ✅ MithraManager初期化 • ✅ DataSource統合 • ✅ Transaction Manager設定 • ✅ GenericSequenceObjectFactory登録 Reladomoの課題に対するreladomo-kotolinの解決法 64
65. #KotlinFest 課題4: Spring Dataパターンが適⽤しずらい => Repositoryパターンのサポート 提供される機能: • ✅ Query Method⾃動パース • ✅ ⾃動Bean登録 • ✅ @Transactionalサポート • ✅ 標準CRUD操作サポート Reladomoの課題に対するreladomo-kotolinの解決法 65
66. デモ：ChronoStaff 66
67. #KotlinFest ChronoStaff: ⼈事情報管理アプリケーション ChronoStaff（クロノスタッフ）は、従業員の配属‧給与管理をバイテンポラルデータモデルで実 装したデモアプリケーションです。 バイテンポラルの2つの時間軸でデータを管理し、以下のような機能を実現します： - ✅ 将来の変更を予約: 「来⽉から営業部に異動」を今⽇登録 - ✅ 過去時点の状態を参照: 「3ヶ⽉前の組織図」を配属⼈員の情報も含め正確に表⽰ - ✅ 完全な監査証跡: 「誰が、いつ、何を変更したか」を記録 reladomo-kotlinを⽤いたアプリケーションデモ 67
68. #KotlinFest ChronoStaff: ⼈事情報管理アプリケーション 百聞は⼀⾒にしかず、動作をみてみましょう reladomo-kotlinを⽤いたアプリケーションデモ 68
69. デモ内容の技術的詳細 69
70. #KotlinFest Step 1: 組織セットアップ - 有効時間の起点設定 3ヶ⽉前を起点にバイテンポラルデータを初期化 ChronoStaffデモの技術的詳細 70
71. #KotlinFest Step 2: 従業員登録 - Bitemporal配属レコード作成 Unitemporal（Employee）とBitemporal（EmployeeAssignment）の組み合わせ ChronoStaffデモの技術的詳細 71
72. #KotlinFest Step 3: 組織変遷 - AsOfクエリで過去時点レコード取得 DemoHistoryGenerator: 2ヶ⽉前の異動を記録 ChronoStaffデモの技術的詳細 72
73. #KotlinFest Step 3: AsOfクエリパターン - バイテンポラル更新の核⼼ TransferController.kt: Reladomoの⾃動バイテンポラルチェイニング ChronoStaffデモの技術的詳細 73
74. #KotlinFest Step 3: AsOfクエリパターン - バイテンポラル更新の核⼼ TransferController.kt: Reladomoの⾃動バイテンポラルチェイニング ChronoStaffデモの技術的詳細 74
75. #KotlinFest Step 3: AsOfクエリパターン - バイテンポラル更新の核⼼ TransferController.kt: Reladomoの⾃動バイテンポラルチェイニング ChronoStaffデモの技術的詳細 75
76. #KotlinFest Step 5: タイムトラベル - 時点クエリで組織図取得 OrganizationController.kt: Business Date でのAsOfクエリ ChronoStaffデモの技術的詳細 76
77. #KotlinFest reladomo-kotlin活⽤: 型安全なKotlinコード Spring Data⾵のRepository（将来機能） ChronoStaffデモの技術的詳細 77
78. おわりに 78
79. #KotlinFest 本セッションでは、テンポラルデータモデルとReladomo、AIと⼀緒に開発した reladomo-kotlinについて紹介しました。 • バイテンポラルデータモデルとReladomoの強⼒さ • AIコーディングエージェントでライブラリ開発が簡単にできる世界観 • さらに作成したライブラリを活⽤したデモアプリさえもAIでつくりました • さらにいうとこのスライドも80%くらいAI作成 バイテンポラルデータモデルすごい！ Reladomoすごい！ AIコーディングエージェントすごい！ ということがご理解いただけると幸いです。ご清聴ありがとうございました。 おわりに 79