生成AIがSQLだけでなく、テストコードも書くようになりました。では、ORMを使わず、ネイティブSQLとJDBCだけで十分なのでしょうか。
先日、Java Championであり、Hibernate ORMの主要コントリビューターでもあるVlad Mihalcea氏に、この点を聞きました。本稿では、インタビューのうち「AI時代のORMとSQL」に関する議論を紹介します。
SQLに習熟したチームなら、JDBCとAIも現実的な選択肢
Vlad氏は、Hibernateを一律に勧めたわけではありません。
以前のJDBCでは、SQLの実行や結果処理を人が多く記述する必要があり、手間がかかりました。Vlad氏は、AIによってこうした作業へ取り組みやすくなり、SQLに習熟したチームが軽量な構成を求めるなら、JDBCとAIは良い組み合わせになり得ると述べました。
JPAとHibernateは、単なるSQL生成ツールではない
一方、JPAとHibernateは単なるSQL生成ツールではありません。エンタープライズアプリケーションで繰り返し必要になる仕組みが、すでに備わっています。
- 楽観的ロックと悲観的ロックを統一的に扱う仕組み
- JDBCバッチ実行の自動化
- 継承マッピング
- 永続化コンテキスト（1次キャッシュ）
- 遅延ロードや複数の取得戦略
例えば、JDBCには楽観的ロックが標準機能として用意されているわけではありません。悲観的ロックも、データベースごとの差を意識しながら扱う必要があります。
ここで、1次キャッシュとコレクションの取得戦略は分けて考える必要があります。1次キャッシュは、永続化コンテキスト内で管理されるエンティティを保持する仕組みです。それ自体が直積（Cartesian product）を自動的に防ぐわけではありません。
Hibernateでも複数のto-many関連を同時にJOIN FETCHすると、Cartesian productが発生する可能性があります。一方、遅延ロードやセカンダリクエリを使い、コレクションを段階的に取得する設計も選べます。この場合もN+1が起こり得るため、実際に発行されるSQLの確認は必要です。
jOOQやBlaze-Persistenceを使わず、素のJDBCだけでMULTISETクエリ相当の処理を書くこともできます。ただし、実装も保守も難しくなります。
Vlad氏によれば、JPAとHibernateには20年にわたって実装され、実際のプロジェクトで検証されてきたパターンが蓄積されています。
なお、Vlad氏自身も、Hibernateに関わってきたため自分には少しバイアスがあると話していました。
Spring Data JPA vs Spring Data JDBC
インタビューでは、Spring Data JPAからSpring Data JDBCへ移行する動きについても聞きました。
Spring Data JDBCはJPAより軽量な選択肢に見えますが、置き換えるだけで性能が改善するわけではありません。
Spring Data JDBCは遅延ロードを行いません。集約ルートを読み込むと、集約の一部としてマッピングされたコレクションもロードされます。そのため、集約境界や実際に発行されるSQLを確認しなければ、必要以上のデータを取得する可能性があります。ただし、任意の関連がすべて自動取得されるという意味ではありません。
JPAやHibernateの挙動を十分に確認せず、Hibernateを問題視していたチームは、移行後に同じ理由でSpring Data JDBCを問題視しかねません。どの技術を選んでも、実際に発行されるSQLの確認は必要です。
AIの回答品質は、公開情報の量にも左右される
Vlad氏は自身の経験として、公開資料が豊富な技術ほど、AIから適切な回答を得られる可能性が高いと話していました。
Spring Data JPAやjOOQには、長年にわたって蓄積されたドキュメント、ブログ、Q&A、サンプルコードがあります。反対に、資料が十分に整っていない技術では、正しい回答を得るのが難しかったとも話しています。
もちろん、AIの回答品質は資料の量だけでなく、モデル、検索機能、与えるコンテキストにも左右されます。ここでのポイントは、成熟した技術ほど、人間もAIも参照して検証できる資料が多いということです。
ORMかSQLかではなく、チームとプロジェクトから考える
ここまでの話を私なりに整理すると、次のようになります。
| 状況 | 検討の方向性 |
|---|---|
| SQLとDBパフォーマンスに詳しく、軽量な構成を求める | 素のJDBC + AI |
| ロック、継承マッピング、永続化コンテキスト、遅延ロードなどをフレームワークに任せたい | JPA / Hibernate |
| 集約中心のシンプルなモデルを使い、遅延ロードやSessionを必要としない | Spring Data JDBC |
| SQL中心で型安全性や高度なクエリ機能を求める | jOOQ |
| チームがJPAを長く安定して運用している | 流行だけを理由に置き換えない |
Vlad氏は、素のJDBCに習熟しているなら、それも良い選択肢だと話していました。ただし、流行だけを理由に技術を置き換えるべきではありません。
判断材料になるのは、チームのスキル、プロジェクトに必要な機能、そして長期的な保守を誰が担うかの3点です。
インタビュー全編
本稿では、インタビューからORM、JDBC、ネイティブSQLに関する部分を紹介しました。全編（日本語版）では、Java Championになるまでの経緯、AI時代の学習方法、Javaを選ぶ理由についても話しています。
Java Champion Vlad Mihalcea インタビュー