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不要論の歴史】2026年の不要論は何を言っているのか
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
赤神青空
PRO
September 12, 2026
Video
Programming
50
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
【ORM不要論の歴史】2026年の不要論は何を言っているのか
赤神青空
PRO
September 12, 2026
Video
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
CodeRabbitの効果検証と過ごしてみた3ヶ月
armondando
0
140
wkhtmltopdfの次どうするか問題2026
willnet
2
1.8k
Agents on Rails - Rails at Scale 2026
irinanazarova
0
330
AI時代のコードレビューは人に向けるな、仕組みに向けろ
texmeijin
5
3.5k
AWS CDKのカスタムリソースでContinuum(旧Security Agent)を実装した話 | Implementing Continuum (formerly Security Agent) via AWS CDK Custom Resource
akihisaikeda
2
130
仕様駆動開発による爆速プロダクト開発 / Bakusoku Spec Driven Development
kobakei
0
180
UnityでSystem.Net.WebSocketsなWebSocketサーバが動かないのでUnity Monoのコードを覗いてみた / about implementing websocket server with unity mono
drumath2237
1
550
C#の現在地 進化の歴史と、AI時代の.NET Everywhere
neuecc
5
4.9k
SREの越境 / SRE Collaboration
y0hgi
2
300
見えないものを探る要求要件定義に必要な基本的思考 / invisible-requirement-thinking
minodriven
13
6.5k
Androidだけじゃない、DroidKaigiで広がった私の技術スタック
akkeylab
0
120
APNsからLive Activityを開始する話
yumnumm
0
150
Featured
See All Featured
Typedesign – Prime Four
hannesfritz
42
3.2k
What's in a price? How to price your products and services
michaelherold
247
13k
The browser strikes back
jonoalderson
0
1.8k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
2.2k
Music & Morning Musume
bryan
48
7.4k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.8k
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
PRO
1
1.6k
Statistics for Hackers
jakevdp
799
230k
A Guide to Academic Writing Using Generative AI - A Workshop
ks91
PRO
1
500
How to audit for AI Accessibility on your Front & Back End
davetheseo
0
570
XXLCSS - How to scale CSS and keep your sanity
sugarenia
250
1.3M
How To Speak Unicorn (iThemes Webinar)
marktimemedia
1
590
Transcript
2026年9月 ORM不要論を、20年ぶんさかのぼる 第4回 2026年の不要論は何を言っているか 赤神 青空
2026年の論争 今回は何が言われているのか 今ココ 2026年 2/11
▪発端が違うので、話の色も違う 今年、波は2回来ている どちらも「AIが書けるなら」を前提に置いているが、入口はまったく別のところ にある。 01 02 Zennの記事が発端。AI前提の不要論 雑談番組が発端。生SQL + Zod
+ テスト 2026年1月 今ココ 2026年 2026年9月 3/11
▪terurou氏「AI時代にORMなんて必要なんですかね?」 不要論側の主張 (2026年1月) 前提は「AIは生SQLを書くのが得意」と「ボイラープレート生成のコストは極小」の2つ。 ドメイン要件を伝えてSQLを生成させる オブジェクトマッピング処理(DAO)を生成させる 単体テストコードを生成させる 都度必要な分だけ生成するなら、時間がかかっている認識すら持たない ORMなしでも大したコストがかからない、という結論になる 今ココ
2026年 4/11
▪記事の著者自身による、投稿後の補足 主張の射程は、ORMより広い ORMに限らず「そこまで難しくはないが、手で書くとコード量が多くて大変」系のライブラリは、AIで必要性が薄れる、 という話だった。 本当に必要なのかを、いま一度考えていい 元の主張は「AIで時間・工数の前提が変わるから、今までのアーキテクチャを疑ってもいい」程度のもの それでも、人格否定と受け取られる場面が多かった 同じ語で違うものを議論していることの、そのままの帰結 今ココ 2026年
5/11
▪コストが小さいなら、弊害のほうが目立つ 挙げられている弊害 ✕ ORMを使うと 機能不足なDSLをSQLとは別に覚える outer join やサブクエリの書き方に迷う マイグレーションがORMに縛られる 実行時オーバーヘッドは、あるにはある
◯ 使わないと SQLの知識がそのまま使える SQLでできることが全部できる マイグレーションツールを自由に選べる 無いに越したことはない、という程度 オーバーヘッドは大した問題ではないと著者自身が書いている。効いているのは上の3つ。 今ココ 2026年 6/11
▪9月の番組内で出た構成 発端で実際に提案されたもの 生SQLを書き、返ってきた結果をZodなどのバリデーションツールでパースして構造を把握する。SQLの正しさは単体テ ストで担保する。 型付けのための静的解析すら要らない、という立場 PrismaのTypedSQLやSafeQLの一段先にある提案 余計なライブラリを挟まないぶん、複雑なSQLもSQLのまま書ける ORMの独自記法を覚えなくてよくなる 読みやすく書きやすい、というのがそのまま利点になる 今ココ
2026年 7/11
▪Prisma何が起きたのか で使っていた主キーが、WAF に遮断された Nano ID - - が並ぶことがある WAF が攻撃と判定
一部だけ 403 主キーを生成する 使う文字種に含まれるため - - はSQLのコメント記法 コードは変えていない 21文字のランダム列 確率 0.49% とされる ルールは公開されていない 再現条件が掴みにくい 文字種を変えたいが、Prisma に設定する方法がない 要望の Issue は「方針が違う」としてクローズ 拡張機能を自作して回避 ここが「ORM から逃げたい」の直接の引き金になった コードを変えていないのに、一部のリクエストだけ 403 になった 今ココ 2026年 8/11
▪同じ番組で語られた、Prismaをめぐる2つの出来事 発端は思想ではなく、具体的な不満だった いまのWAFの件 ライブラリの都合で決まった値が、別の層で攻撃と判定された 直したくても、ライブラリ側に設定する口が無かった v8での仕様変更(9月時点ではリリース候補) 生クエリを書く関数がなくなり、新しい組み立て方式に置き換わった WITH RECURSIVE や
UNION を含む大きなSQLが書きづらくなった v7は並行してメンテナンスするとされているが、数年後は読めない 今ココ 2026年 9/11
▪なぜTypeScript側からこの主張が出やすいのか そもそもモデルが無い、という構造の差 Railsの場合 モデルとテーブルが1対1で対応している ロジックもデータも、挿入前後のコールバックも、そこに集まる 生SQLに置き換えると、この集約が丸ごと失われる Next.jsの場合 自分で作らない限り、モデルという層がそもそも存在しない 残るのはクエリビルダ的な側面だけなので、生SQLとの差が小さい 今ココ
2026年 10/11
▪第5回 次回 反論と、噛み合わなさの正体 主張の中身は分かった。 ではそれに、どう返されたのか。 反論を並べると、噛み合っていない理由が見えてきます。 今ココ おわりに 11/11