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
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
赤神青空
PRO
September 14, 2026
Programming
39
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 AIF対策】AIシステムを守る
akagami
PRO
0
13
【AIニュース】ChatGPT Space とは何か
akagami
PRO
0
20
【AWS AIF対策】透明性と説明可能性
akagami
PRO
0
16
【AIニュース】OpenAI の「dots」とは何か
akagami
PRO
0
22
【AWS AIF対策】責任あるAI
akagami
PRO
0
24
【AWS AIF対策】基盤モデルの評価
akagami
PRO
0
27
【AWS AIF対策】モデルの学習とファインチューニング
akagami
PRO
0
17
【AWS AIF対策】プロンプトエンジニアリング
akagami
PRO
0
17
【AWS AIF対策】RAGとベクトルデータベース
akagami
PRO
0
17
Other Decks in Programming
See All in Programming
Security issues being discussed on Web Platforms
petamoriken
0
1.4k
Streamlitで実現する自然言語データアプリ開発
ayumu_yamaguchi
1
340
ハーネス設計入門 〜 基礎知識の整理から実務へのステップアップ 〜
kinopeee
20
21k
Findy - エンジニア向け会社紹介/Findy Company Deck
findyinc
6
400k
見えないものを探る要求要件定義に必要な基本的思考 / invisible-requirement-thinking
minodriven
13
6.5k
Augmenting AI with the Power of Jakarta EE
ivargrimstad
0
520
更なる可用性を求めて、5年間運用したKotlinのアプリケーションをGoでリプレイスする話
ken_tunc
0
440
UPDATE をやめる — EF Core でマスタをバージョン管理する
panda728
PRO
0
1.1k
AI時代のコードレビューは人に向けるな、仕組みに向けろ
texmeijin
5
3.5k
マイコン向けの軽量Ruby「PicoRuby」で各種デバイスを制御するネイティブアプリの実現手法
bash0c7
0
470
モデルのリファクタリングが難しいと思ったら、そもそも複雑だったのはビジネス仕様だった ? / is-the-business-domain-the-real-complexity
hatsu38
0
440
Domain-Driven Transformation
hschwentner
2
2.3k
Featured
See All Featured
Darren the Foodie - Storyboard
khoart
PRO
4
4k
Navigating the moral maze — ethical principles for Al-driven product design
skipperchong
2
600
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
Beyond borders and beyond the search box: How to win the global "messy middle" with AI-driven SEO
davidcarrasco
3
270
Rails Girls Zürich Keynote
gr2m
96
14k
The Hidden Cost of Media on the Web [PixelPalooza 2025]
tammyeverts
2
510
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.6k
Code Review Best Practice
trishagee
74
20k
Principles of Awesome APIs and How to Build Them.
keavy
128
18k
How to Align SEO within the Product Triangle To Get Buy-In & Support - #RIMC
aleyda
2
1.8k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.6k
The Invisible Side of Design
smashingmag
301
52k
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