概要
https://zenn.dev/terurou/articles/55ffe7c6e5c96e
詳細内容
## AI時代にORMなんて必要なんですかね？
https://zenn.dev/terurou/articles/55ffe7c6e5c96e
AIがSQL生成やボイラープレートの実装を自動化する現代において、ORMの学習コストや機能的制約を考慮し、その必要性を問い直す。
**Content Type**: 💭 Opinion & Commentary
**Language**: ja
**Scores**: Signal:4/5 | Depth:3/5 | Unique:5/5 | Practical:4/5 | Anti-Hype:4/5
**Main Journal**: 81/100 | **Annex Potential**: 84/100 | **Overall**: 80/100
**Topics**: [[AIコーディング, ORM, システム設計, データベースアクセス, 生SQL]]
生成AIがコード生成を担う現代の開発において、ORM（Object-Relational Mapping）の必要性を根本から問い直す。著者は、新規システムの設計検討を通じ、AI時代においてはORMを採用するメリットよりも弊害の方が上回るのではないかという鋭い視点を提示している。
本記事の主張の核となるのは、「AIは生SQLの記述が得意であり、かつマッピング処理のようなボイラープレートの生成コストも極小である」という事実だ。かつて2000年代初頭にORM（Hibernate、iBATISなど）が普及した最大の要因は、JDBCを用いたDAOやDTOを手書きする作業が膨大で、人間にとって耐え難い苦痛だったからである。しかし、AIにドメイン要件を伝えればSQLもマッピングコードも単体テストも即座に得られる現在、この「記述コストの削減」というORM最大の存在意義が失われつつある。
一方で、著者はORMを使い続けることで生じる弊害として以下の点を挙げている。
1. クエリビルダーという、SQLとは別に「ORM固有で機能不足なDSL」を学習し、使いこなす必要性。
2. SQLであれば容易に書けるサブクエリや外部結合が、ORM経由だと逆に困難になるという逆転現象。
3. 実行時のオーバーヘッドや、RDBごとの方言とORMとの不整合。
4. マイグレーションがORMの仕様に縛られることによる柔軟性の低下。
著者は「ORMがSQLでできることのすべてをカバーできない問題」は20年以上解決されていない難題であり、もはや解決を待つよりも「使わない」という選択が合理的であると論じる。AIを活用し、都度必要な分だけDBアクセスコードを生成させるスタイルにシフトすれば、ORMの制約に縛られることなくRDBのポテンシャルを最大限に活用できる。
これは、長年「開発の常識」とされてきた抽象化レイヤーを、AIという新しいパラダイムによって取り除くことで、よりシンプルで透明性の高いシステム設計が可能になることを示唆している。Webアプリケーションエンジニアにとって、技術スタックの前提条件をリセットして考えるべき時期が来ていることを突きつける内容だ。