Kotlinで型安全にバイテンポラルデータを扱いたい！ ReladomoラッパーをAIと実装してみた話 Kotlin Fest 2025 2025年11⽉01⽇ 株式会社ログラス 執⾏役員CTO 伊藤博志（いとひろ @itohiro73） 1 

#KotlinFest ⾃⼰紹介 2 ゴールドマン・サックスのテクノロジー部に新卒入社後、同社の機関システム開発に 従事。その後、VP/Senior Engineerとしてプラットフォーム開発に携わり、同社 発のJavaのOSSであるEclipse Collectionsのコミッター兼プロジェクトリード やOpenJDKへのコントリビュートを行うなど、OSS戦略を牽引。 スタートアップ2社を経て、READYFORに入社し執行役員VPoEに就任。 同社のエンジニア組織の10名から30名規模への成長、決済基盤の刷新や、技術的 負債の返済、新規プロダクト開発を牽引。 2022年10月に株式会社ログラスの開発部へエンジニアとして入社。 エンジニアリングマネージャー、事業執行役員VPoEを経て、現職。 株式会社ログラス 執行役員 CTO 伊藤 博志 （いとひろ @itohiro73） Hiroshi Ito 

#KotlinFest 本⽇のアジェンダ 3 1. はじめに: RDBでの履歴管理‧時点情報管理の難しさ 2. テンポラルデータモデルとは 3. Reladomoの紹介 4. ReladomoをKotlin/Spring Bootで使う際の課題 5. reladomo-kotlinをClaude Codeと協働開発 6. reladomo-kotlinの機能紹介 7. デモ：Chronostaff 8. 得られた知⾒とまとめ 

はじめに: RDBでの履歴管理‧ 時点情報管理の難しさ 4 

#KotlinFest RDB上で履歴情報‧時点情報を管理するのがむずかしい... ❌ 「このデータ、先⽉どうだったっけ？」 → updated_atしかない... ❌ 「いつ、誰が変更したの？」 → 変更ログが散在 ❌ 「来⽉からの予定を記録したい」 → データモデリングが複雑 みなさん、こんなご経験はありませんか？ 5 

#KotlinFest RDB上で履歴情報‧時点情報を管理するのがむずかしい... 例えばこんな解決法があるか...？ 1. updated_atだけで管理 a. 過去の状態が追跡できない b. 「いつの時点で何を知っていたか」が不明 2. 履歴テーブルの活⽤ a. employees, employees_history, employees_log… b. 複雑なJOIN、パフォーマンス問題 c. 整合性の維持が困難 3. JSON/Blobに履歴を詰め込む a. クエリ不可 b. 型安全性の喪失 みなさん、こんなご経験はありませんか？ 6 

#KotlinFest RDB上で履歴情報‧時点情報を管理するのがむずかしい... RDBの構造上、履歴データ‧時点管理をするのは性質としてそもそも難しい。 その解決法の⼀つとして、「テンポラルデータモデル」と、それをサポートするJava ORM「Reladomo」を紹 介したいと思います。 参考資料: 「データ履歴管理のためのテンポラルデータモデルとReladomoの紹介」 みなさん、こんなご経験はありませんか？ 7 

テンポラルデータモデルとは 8 

#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日に訂正した履歴も残したい」 → どうする？ これらを全て記録するには？ 

#KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル1: スナップショットデータモデル（時点管理をしないモデル） 最もシンプル - 現在の状態だけ保持する テンポラルデータモデル 10 

#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日の価格は？」→ わからない （既に上書き） ● ❌ 「誰がいつ変更した？」 → わからない （履歴なし） ● ❌ 「過去の価格推移を分析」 → 不可能 問題: 履歴が残らない → 分析・監査・復元が不可能 

#KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル2: トランザクション時間データモデル 「いつ記録したか」を記録 テンポラルデータモデル 12 

#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: 値下げ → 古いレコードを終了、新レコード追加 

#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: 値上げの最新情報を登録 

#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 

#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時点で有効だった価格かは不明 問題: 「システム上の記録」の履歴は追えるが「実際にいつ有効だったか」がわからない 

#KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル3: 有効時間データモデル 「いつ有効か」を記録 テンポラルデータモデル 17 

#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万円」→ 期間を分割 

#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万円」 

#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万円という間違いの記録が消えてしまう 

#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万円だと思っていた」履歴は消えてしまう ● ❌ 修正の履歴がない → 監査証跡不完全 問題: 訂正すると元の間違いが消える → 監査証跡が失われる 

#KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル4: バイテンポラルデータモデル 2つの時間軸を同時に記録 テンポラルデータモデル 22 

#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万円」 

#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万円」 

#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万円」 

#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万円だった」 → 間違いの記録も残る 

#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つの時間軸を考慮） ● ⚠ データ量増加（訂正のたびにレコード追加） 

#KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル4: バイテンポラルデータモデル 2つの時間軸を同時に記録 テンポラルデータモデル 28 クエリ方法 1: 「現在の価格は？」 

#KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル4: バイテンポラルデータモデル 2つの時間軸を同時に記録 テンポラルデータモデル 29 クエリ方法 2: 「2月15日の価格は？」 

#KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル4: バイテンポラルデータモデル 2つの時間軸を同時に記録 テンポラルデータモデル 30 クエリ方法 3: 「3月4日時点では、 2月15日の価格は何だと思っていた？」 

#KotlinFest リアルライフシナリオで理解する、データの時点管理 データモデル4: バイテンポラルデータモデル 2つの時間軸を同時に記録 テンポラルデータモデル 31 クエリ方法 4: 「訂正履歴を全て表示」 

#KotlinFest リアルライフシナリオで理解する、データの時点管理 まとめ 時点管理を⾏わないスナップショットデータモデルと、時点管理をDB上で表現するテンポラルデータモデルとして「トラ ンザクション時間データモデル」「有効時間データモデル」「バイテンポラルデータモデル」をそれぞれ紹介 テンポラルデータモデル 32 機能 スナップショット トランザクション時間 有効時間 バイテンポラル 現在の状態 ✅ ✅ ✅ ✅ 履歴参照 ❌ ✅ ✅ ✅ 「2月15日の価格は？」 ❌ ❌ ✅ ✅ 将来予約 ❌ ❌ ✅ ✅ 「3月4日時点で2月15日の価格は？」 ❌ ❌ ❌ ✅ 訂正履歴 ❌ ⚠ 記録としてのみ ❌ ✅ 完全な監査証跡 ❌ ⚠ 部分的 ❌ ✅ タイムトラベル ❌ ⚠ 記録時点のみ ⚠ 有効時点のみ ✅ 

Reladomoの紹介 33 

#KotlinFest エンタープライズグレードのバイテンポラルデータモデルをサポートするJava ORM https://github.com/goldmansachs/reladomo • ゴールドマン‧サックスが開発し、OSSとして公開 ‐ 複雑な業務ロジックを持つ⼤規模システム向けに設計されたJava ORM • バイテンポラルデータモデルを透過的にサポート ‐ 有効時間 (Business Date)とトランザクション時間 (Processing Date)をネイティブサポート • 型安全なクエリ⾔語 ‐ リフレクションを使わず、静的に型付けられたクエリを⽣成 • ⾼度な機能 ‐ トランザクション管理（変更履歴の⾃動追跡） ‐ シャーディング（複数DBへのデータ分散）を透過的にサポート Reladomoとは？ 34 

#KotlinFest バイテンポラルネイティブ対応 • データモデルをXML（！）で定義するだけ でバイテンポラルデータモデルをサポート するオブジェクトのコードを⾃動⽣成。 • ⾃前でコードを書くことなくバイテンポラ ルを操作することができるクエリを構築で きるDSLも同時に⼿に⼊れられる Reladomo: 強みの詳細 35 

#KotlinFest 複雑性を型安全にAPIで吸収 - Java コード例 Reladomo: 強みの詳細 36 

#KotlinFest 複雑性を型安全にAPIで吸収 - Java コード例 Reladomo: 強みの詳細 37 

#KotlinFest パフォーマンス関連機能の充実 • Deep Fetchという事前フェッチ機能でN+1 問題を回避 • カーソルをつかったインメモリのストリー ミング処理による⼤量データ処理 Reladomo: 強みの詳細 38 

#KotlinFest パフォーマンス関連機能の充実 • Deep Fetchという事前フェッチ機能でN+1 問題を回避 • カーソルをつかったインメモリのストリー ミング処理による⼤量データ処理 Reladomo: 強みの詳細 39 

#KotlinFest パフォーマンス関連機能の充実 • Deep Fetchという事前フェッチ機能でN+1 問題を回避 • カーソルをつかったインメモリのストリー ミング処理による⼤量データ処理 Reladomo: 強みの詳細 40 

#KotlinFest Relationshipのネイティブサポート • Relationshipを設定ファイル上で定義するこ とで関連を持つレコードをドメインモデル として⾃然な形で取得可能 Reladomo: 強みの詳細 41 

ReladomoをKotlin/Spring Bootで使う際の課題 42 

#KotlinFest 課題1: ⽣成されるJavaコードがKotlinの強みを活かせない Javaの⾃動⽣成コード ReladomoをKotlin/Spring Bootで使う際の課題 43 

#KotlinFest 課題1: ⽣成されるJavaコードがKotlinの強みを活かせない Kotlinから使うと: ReladomoをKotlin/Spring Bootで使う際の課題 44 

#KotlinFest 課題1: ⽣成されるJavaコードがKotlinの強みを活かせない Kotlinで書きたいコード: ReladomoをKotlin/Spring Bootで使う際の課題 45 

#KotlinFest 課題2: エンティティ定義⽤のXMLを⼿書きする必要がある ReladomoをKotlin/Spring Bootで使う際の課題 46 

#KotlinFest 課題3: ⼤量のボイラープレートコード - 初期化コード ReladomoをKotlin/Spring Bootで使う際の課題 47 

#KotlinFest 課題3: ⼤量のボイラープレートコード - DataSource設定 ReladomoをKotlin/Spring Bootで使う際の課題 48 

#KotlinFest 課題3: ⼤量のボイラープレートコード - エンティティごとのSequenceFactory実装 ReladomoをKotlin/Spring Bootで使う際の課題 49 

#KotlinFest 課題3: ⼤量のボイラープレートコード - Spring Beanとして登録 ReladomoをKotlin/Spring Bootで使う際の課題 50 

#KotlinFest 課題4: Spring Dataパターンが適⽤しずらい ReladomoをKotlin/Spring Bootで使う際の課題 51 

#KotlinFest 課題4: Spring Dataパターンが適⽤しずらい ReladomoをKotlin/Spring Bootで使う際の課題 52 

reladomo-kotlinをClaude Codeと協働開発 53 

#KotlinFest やりたいけど時間がなくて諦めていたことが、かなり簡単にできるように AIコーディングエージェントが⾮常に優秀... 54 

#KotlinFest 実はこのころ電⾞の通勤時間にAndroid上でコーディングするのがマイブーム AIコーディングエージェントが⾮常に優秀... 55 

#KotlinFest reladomo-kotlinは電⾞の中でAndroid上で完成しました https://github.com/itohiro73/reladomo-kotlin AIコーディングエージェントが⾮常に優秀... 56 

#KotlinFest シンプル: KotlinでReladomoを扱う際の課題感をインプットしただけ ⼊⼒したプロンプト（失われてしまったのでうろ覚え再現） ReladomoをKotlin/Spring Bootで扱おうとすると、様々な課題があります - XMLで⾃動⽣成されたJavaのコードがKotlinと親和性が良くない - ボイラープレートな初期設定を⼿動で書かなければいけない - Spring Bootとのインテグレーションがないため、開発初期スピードが上がらない これらの課題を解決するreladomo-kotlinというライブラリを開発したいので、要件‧仕様を設計し、MVPの実 装プランを⽴ててください => ここから出てきた仕様提案にフィードバックを送りつつ、理想的な形へとガイドしながら開発。⼈間は1⾏もコードを書い ていない Claude Codeで何をしたのか？ 57 

#KotlinFest Maven Centralへのリリース⼿順の作成 Maven Centralリリース⽤のGitHub Actionsや、リリースの際の⼿順書をClaude Codeに作ってもら い、ただただそれを実⾏すればよい状態に Claude Codeで何をしたのか？ 58 

#KotlinFest Maven Centralへのリリース⼿順の作成 Maven Centralリリース⽤のGitHub Actionsや、リリースの際の⼿順書をClaude Codeに作ってもら い、ただただそれを実⾏すればよい状態に => 無事リリース！ Claude Codeで何をしたのか？ 59 

#KotlinFest reladomo-kotlinというラッパーライブラリを⼈間が作ろうと思ったら おそらくフルタイムで数ヶ⽉はかかるであろう分量 - Javaのコード⽣成機能をどうKotlinコードに変換するべきかを調査‧設計‧実装 - 既存のコード⽣成ロジックの精査 - Kotlinコードの理想状態を定義 - Gradle Pluginとしてのプラクティスを調査しつつプラグイン設計‧実装 - Spring Bootに統合するための既存Reladomoの動作理解とSpring Boot上の詳細機能調査 + 設計実装 - リリースビルドや⼿順書の作成 - テストの作成 - 等々 => Claude Codeに電⾞の中でスマホ内で数⽇で完成...！ AIコーディングエージェントの強⼒さを⽬の当たりに 60 

reladomo-kotlinの機能紹介 61 

#KotlinFest 課題1: ⽣成されるJavaコードがKotlinの強みを活かせない => Kotlinコード⽣成 理想的なKotlinコードを ⾃動⽣成 Reladomoの課題に対するreladomo-kotolinの解決法 62 

#KotlinFest 課題2: エンティティ定義⽤のXMLを⼿書きする必要がある => Annotation-Based Configuration アノテーションから XMLとコードを⾃動⽣成 （実装WIP） Reladomoの課題に対するreladomo-kotolinの解決法 63 

#KotlinFest 課題3: ⼤量のボイラープレートコード => Gradleプラグインによるボイラープレート対応 プラグインへの依存を⾜すだけで、 以下が全て⾃動設定される: • ✅ MithraManager初期化 • ✅ DataSource統合 • ✅ Transaction Manager設定 • ✅ GenericSequenceObjectFactory登録 Reladomoの課題に対するreladomo-kotolinの解決法 64 

#KotlinFest 課題4: Spring Dataパターンが適⽤しずらい => Repositoryパターンのサポート 提供される機能: • ✅ Query Method⾃動パース • ✅ ⾃動Bean登録 • ✅ @Transactionalサポート • ✅ 標準CRUD操作サポート Reladomoの課題に対するreladomo-kotolinの解決法 65 

デモ：ChronoStaff 66 

#KotlinFest ChronoStaff: ⼈事情報管理アプリケーション ChronoStaff（クロノスタッフ）は、従業員の配属‧給与管理をバイテンポラルデータモデルで実 装したデモアプリケーションです。 バイテンポラルの2つの時間軸でデータを管理し、以下のような機能を実現します： - ✅ 将来の変更を予約: 「来⽉から営業部に異動」を今⽇登録 - ✅ 過去時点の状態を参照: 「3ヶ⽉前の組織図」を配属⼈員の情報も含め正確に表⽰ - ✅ 完全な監査証跡: 「誰が、いつ、何を変更したか」を記録 reladomo-kotlinを⽤いたアプリケーションデモ 67 

#KotlinFest ChronoStaff: ⼈事情報管理アプリケーション 百聞は⼀⾒にしかず、動作をみてみましょう reladomo-kotlinを⽤いたアプリケーションデモ 68 

デモ内容の技術的詳細 69 

#KotlinFest Step 1: 組織セットアップ - 有効時間の起点設定 3ヶ⽉前を起点にバイテンポラルデータを初期化 ChronoStaffデモの技術的詳細 70 

#KotlinFest Step 2: 従業員登録 - Bitemporal配属レコード作成 Unitemporal（Employee）とBitemporal（EmployeeAssignment）の組み合わせ ChronoStaffデモの技術的詳細 71 

#KotlinFest Step 3: 組織変遷 - AsOfクエリで過去時点レコード取得 DemoHistoryGenerator: 2ヶ⽉前の異動を記録 ChronoStaffデモの技術的詳細 72 

#KotlinFest Step 3: AsOfクエリパターン - バイテンポラル更新の核⼼ TransferController.kt: Reladomoの⾃動バイテンポラルチェイニング ChronoStaffデモの技術的詳細 73 

#KotlinFest Step 3: AsOfクエリパターン - バイテンポラル更新の核⼼ TransferController.kt: Reladomoの⾃動バイテンポラルチェイニング ChronoStaffデモの技術的詳細 74 

#KotlinFest Step 3: AsOfクエリパターン - バイテンポラル更新の核⼼ TransferController.kt: Reladomoの⾃動バイテンポラルチェイニング ChronoStaffデモの技術的詳細 75 

#KotlinFest Step 5: タイムトラベル - 時点クエリで組織図取得 OrganizationController.kt: Business Date でのAsOfクエリ ChronoStaffデモの技術的詳細 76 

#KotlinFest reladomo-kotlin活⽤: 型安全なKotlinコード Spring Data⾵のRepository（将来機能） ChronoStaffデモの技術的詳細 77 

おわりに 78 

#KotlinFest 本セッションでは、テンポラルデータモデルとReladomo、AIと⼀緒に開発した reladomo-kotlinについて紹介しました。 • バイテンポラルデータモデルとReladomoの強⼒さ • AIコーディングエージェントでライブラリ開発が簡単にできる世界観 • さらに作成したライブラリを活⽤したデモアプリさえもAIでつくりました • さらにいうとこのスライドも80%くらいAI作成 バイテンポラルデータモデルすごい！ Reladomoすごい！ AIコーディングエージェントすごい！ ということがご理解いただけると幸いです。ご清聴ありがとうございました。 おわりに 79 

80