Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
【ORM不要論の歴史】で、AIは新しい根拠なのか
Search
赤神青空
PRO
September 14, 2026
Programming
20
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
【ORM不要論の歴史】で、AIは新しい根拠なのか
赤神青空
PRO
September 14, 2026
More Decks by 赤神青空
See All by 赤神青空
【AWSのログ周りを整理する】第2回 出す ── ログはどこで生まれるか
akagami
PRO
0
13
【AWSのログ周りを整理する】全体像 ── 4段に分けて 位置づける
akagami
PRO
0
16
【ORM不要論の歴史】反論と、噛み合わなさの正体
akagami
PRO
0
32
【ORM不要論の歴史】2026年の不要論は何を言っているのか
akagami
PRO
0
33
【ORM不要論の歴史】運用の問題は、いまの責務論に直結する
akagami
PRO
0
21
【ORM不要論の歴史】なぜ生まれ、20年前に何を言われたか
akagami
PRO
0
27
【高い買い物LT会】初任給で話題の国産フィジカルAIを買った話
akagami
PRO
0
150
【ORM不要論の歴史】「ORM」と呼ばれているものが3つある
akagami
PRO
0
72
【Vitest5.0大解剖】Vitest5.0で消えた記法とAPI
akagami
PRO
0
30
Other Decks in Programming
See All in Programming
Family mrubyの進捗
kishima
1
110
AIとGame Jamで、ゲームを完成させた話
takahirosaeki
0
120
From 6 People Classroom Meetup to 100 People Regional Conference / FOSS4G Hiroshima 2026
furukawayasuto
0
160
新人はどこまで自力でやり、どこからAIに頼るべきか/エンジニア育成に向き合う_先輩たちの悩みと知見共有会
toppan_digital_dev
1
610
選挙速報を多くのユーザーへ 届ける Live Activities 設計
hamayokokuririn
0
130
LL言語やWebフレームワークのPostgreSQL対応 〜DBの機能がユーザーに届くまで〜
kentaroutakeda
0
150
{ Android | Kotlin } Gradle Plugin in 2026
ryunen344
1
310
thread_parallel_with_free-threaded_Python_and_NumPy.pdf
riku_sakamoto
0
320
マイコン向けの軽量Ruby「PicoRuby」で各種デバイスを制御するネイティブアプリの実現手法
bash0c7
0
370
JPUG勉強会 OSSデータベースの内部構造を理解しよう(第2回)
oga5
0
150
アクセシビリティから考える情報設計
high_g_engineer
0
370
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
300
Featured
See All Featured
Tell your own story through comics
letsgokoyo
1
1.1k
Optimizing for Happiness
mojombo
378
71k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
123
22k
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
440
Principles of Awesome APIs and How to Build Them.
keavy
128
18k
Amusing Abliteration
ianozsvald
1
290
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Exploring anti-patterns in Rails
aemeredith
3
500
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
3k
Tips & Tricks on How to Get Your First Job In Tech
honzajavorek
1
730
Building Adaptive Systems
keathley
44
3.2k
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
68
57k
Transcript
2026年9月 ORM不要論を、20年ぶんさかのぼる 第6回 で、AIは新しい根拠なのか 赤神 青空
で、AIは新しい根拠なのか 最初の問いに戻る 今ココ 判断 2/12
▪7つの責務に照らして見る AIが変えること/変えないこと 変わった SQLを書くハードルが下がった DAOの手書きコストがほぼ消えた 生成物の説明もAIに任せられる 「面倒だから」という理由が弱くなった 変わっていない b と
c の構造的な食い違い N+1が起きる仕組みそのもの d・e が必要なこと自体 発行されるSQLを確認する必要 AIが弱くしたのはORMを採用する理由のうち「手間」の部分だけ。批判されてきた箇所は、AIによっては動いていない。 今ココ 判断 3/12
▪これは責務の分け方には乗らない、別軸の話 「AIが書くなら」の3つの立場 「どの責務が要るか」ではなく「誰が書くか」の話なので、7つの表の外側にあります。 ガードレール不要説 … 人の水準を揃えるためだったなら、AIが書くなら理由は薄い ガードレール必要説 … 生成物が本番に入るからこそ、書ける形を絞りたい コンテキスト節約説
… 抽象化で済むものを毎回生成させるのは無駄 加えて、d・e を見直す意見もある エージェントに触らせるなら、スキーマの所在と戻し方が決まっている必要がある 今ココ 判断 4/12
▪聞き手にとっての「で、どうするか」はここ 下がったのは書くコストだけ AIで「書くコスト」は下がった。 だが「判断のコスト」は下がっていない。 むしろ以前より露骨に、人間側に返ってきている。 下がったもの SQLを書く、DAOを書く、テストを書くという手間 下がっていないもの 何を選び、誰が長く保守するかという判断 ORMを使う理由は今もある。それが「前提」ではなくなっただけ。
今ココ 判断 5/12
▪論争が周期的であることの、いちばん分かりやすい証拠 「〜するたびに」という言い方 議論に参加している人たち自身が、これが繰り返しであることを前提に喋っている。 9月の波の発端の番組内でも、AI以前からある話だと言い添えられている 「SQL直接 vs ORM論争が勃発するたびにSafeQLを宣伝しており」 「定期的に発生するORM不要論」 「みんなやろうとして撤退を30年間繰り返してる」 どれも、今回の論争の中で出てきた言葉
火をつけた本人たちが、繰り返しであることを自覚したうえで話している 20年はNewardのエッセイから、30年はORMの試み全体を指す 今ココ 判断 6/12
▪エッセイの結論部分。順位は付けられていない 原典が示した6つの逃げ道 放棄 … オブジェクトをやめる。ミスマッチ自体が消える 全面受容 … リレーショナルをやめてオブジェクトDBに寄せる 手でマッピングを書く …
そこまで難しい問題ではないと認める DBのメタデータを見るツールで自動生成すれば、批判の一部は消える 限界を認めて併用 … ORMで8割、残りは生のアクセスで通す 言語に取り込む … LINQ、Scala、F# のような方向 フレームワークに取り込む … RowSet / DataSet を持つ形にする 今ココ 判断 7/12
▪第2回で見たエッセイの、結論部分です 3番目を見てください 「手で書く量が多くて保守できない」という批判は、 ツールで自動生成すれば一部は消えると2006年に書かれている。 2006年の言い方 その「ツール」はDBのメタデータを読むコード生成器だっ た。 2026年の言い方 その「ツール」の位置に、AIが入った。 2026年の不要論は、このリストの3番目とほぼ重なります。
今ココ 判断 8/12
▪「何も変わっていない」は言い過ぎになる この主張の弱いところ 20年前と変わっていない 変換と関連の構造的な難しさ 継承の写し方が3つしかないこと スキーマの所有権という政治の問題 実行されるSQLを確認する必要 実際に解決された 「文字列で実行時まで検証されない」 型付きクエリビルダが、これを消した
責務を別ツールに割り当てる構成が実用に 原典に無い選択肢が、いま存在する 2006年の批判のうち、少なくとも1つは本当に解かれている。同じことの繰り返し、と言い切るのは正確ではない。 今ココ 判断 9/12
▪今日いちばん持ち帰ってほしいこと 結論 2026年の不要論は、 2006年に列挙された6つの逃げ道の3番目。 AIは、そこに書かれた「ツール」の位置に入っただけ。 2006年の言い方 「手で書く量が多い」は自動生成で消える 2026年の言い方 「手で書く量が多い」はAIで消える 論争の当事者自身が「撤退を30年間繰り返している」と書いています。
今ココ まとめ 10/12
▪次にこの話題を見かけたとき用に まとめ 01 「ORMは要るか」と聞かない 相手が思い浮かべているのがActiveRecordかKyselyかで、答えが変わってしまう。 02 責務のどれを指しているか見る 不要論の多くは b と
c の話で、d や e に反対しているわけではない。 03 AIが変えたのは手間の部分 型で解けたものもあるが、変換と関連の難しさはそのまま残っている。 今ココ まとめ 11/12
▪今回さかのぼった資料 参考 Ted Neward「The Vietnam of Computer Science」(2006年6月・原典を参照) terurou「AI時代にORMなんて必要なんですかね?」(Zenn /
2026年1月) Kuta Labs「AI時代のSQLとORMを使う理由」(Zenn / 2026年1月) ムーザルちゃんねる ashunar0「ORMが引き受けている責務を分解してみる」(2026年9月) jojoldu「AIがSQLを書く時代、ORMは必要なのか?」(Qiita / 2026年7月) Twitter上の議論(@mattn_jp / @mconfjp / @silasolla / @HirokiTakekuma ほか) 今ココ まとめ 12/12