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不要論の歴史】運用の問題は、いまの責務論に直結する
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
赤神青空
PRO
September 11, 2026
Video
Programming
29
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
【ORM不要論の歴史】運用の問題は、いまの責務論に直結する
赤神青空
PRO
September 11, 2026
Video
More Decks by 赤神青空
See All by 赤神青空
【基本情報対策】浮動小数点と誤差
akagami
PRO
0
4
【AIニュース】Claude for Google Workspace とは何か
akagami
PRO
0
14
【基本情報対策】2進数・16進数と基数変換
akagami
PRO
0
18
【AIニュース】Claude Code の mods とは何か
akagami
PRO
0
18
【AWS AIF対策】ガバナンスとコンプライアンス
akagami
PRO
0
19
【AWS AIF対策】AIシステムを守る
akagami
PRO
0
31
【AIニュース】ChatGPT Space とは何か
akagami
PRO
0
32
【AWS AIF対策】透明性と説明可能性
akagami
PRO
0
21
【AIニュース】OpenAI の「dots」とは何か
akagami
PRO
0
29
Other Decks in Programming
See All in Programming
Unity6 URPによる海底をテーマにしたVJシステムの解説 | Unity Shader 完全に理解した 勉強会
gam0022
0
340
【加筆修正版】Laravel のアプリケーションをどこにデプロイするか #phpcon_ehime
akase244
0
150
Everything will be SERVERLESS — 信じて運用した10年の経験値 / Everything Will be Serverless — Lessons Learned from 10 Years of Operational Experience
seike460
PRO
1
880
難しいけど、読めた。- OSSの入口に立った話。
sts11142
0
140
AI が書く Go コードの品質を劇的に向上させる Linter: “declscope”
mpyw
0
480
Atomic Design, Enforced: Scaling Mobile Design Systems (next.app devCon / droidCon Berlin 2026)
steliosf
PRO
0
160
C#の現在地 進化の歴史と、AI時代の.NET Everywhere
neuecc
5
5k
Vue Fes Japan 2026 タイムテーブル徹底解説
448jp
1
640
wkhtmltopdfの次どうするか問題2026
willnet
2
1.9k
Kubernetes祭り #2 OP/ED
bells17
0
110
Verilogで学ぶCPU自作入門
uyuki234
8
4.1k
UPDATE をやめる — EF Core でマスタをバージョン管理する
panda728
PRO
0
1.2k
Featured
See All Featured
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
Color Theory Basics | Prateek | Gurzu
gurzu
1
480
A Tale of Four Properties
chriscoyier
163
24k
jQuery: Nuts, Bolts and Bling
dougneiner
66
8.6k
Are puppies a ranking factor?
jonoalderson
2
4k
Everyday Curiosity
cassininazir
0
350
Between Models and Reality
mayunak
4
490
Docker and Python
trallard
47
4.2k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
56k
Lightning talk: Run Django tests with GitHub Actions
sabderemane
0
290
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
930
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
3k
Transcript
2026年9月 ORM不要論を、20年ぶんさかのぼる 第3回 運用の問題は、いまの責務論に直結する 赤神 青空
▪モデルではなく、運用と組織から来る問題 所有権と、二重スキーマ スキーマの所有権 最初は白紙のDBを自由に設計できるが、その状態は長続きしない 他部署のレポート要求とDBAの性能責任で、スキーマは凍結に向かう 判別用のカラムは、レポート生成ツールから見ると意味不明な列になる 二重スキーマ 同じ知識が、DDLとオブジェクト定義の2箇所に置かれる コードの修正よりDBの修正のほうが重い。既存データの移行が要るため 今ココ
2006年 2/11
▪取得の書き方は3種類あるとされている 2006年時点でのクエリビルダ批判 QBE(テンプレートを埋める)/ QBA(クエリオブジェクトを組む)/ QBL(SQL風の別言語)。QBAが、いま言うクエ リビルダ。 SQLの書き方に比べて、一般に冗長になる outer join のような書き方は、難しいか、そもそも表現できない
テーブル名もカラム名もただの文字列で、実行時まで検証されない QBLはQBLで、SQLの部分集合にしかならない SQLに似た言語を使うなら、SQLを使うのと何が違うのか、という話になる 今ココ 2006年 3/11
04 ORMは何を引き受けているか 名前で呼ぶのをやめて、中身を棚卸しする 今ココ 責務の分解 4/11
▪ORMと呼ばれるライブラリがやっている仕事 7つの責務 a b c d e f g クエリの組み立て
行とオブジェクトの変換 関連の解決 スキーマの単一情報源 マイグレーション インジェクション対策 トランザクション管理 今ココ 責務の分解 SQL文字列を直接書かずにクエリを作る 取得した行をオブジェクトに詰め替え、書き戻す 関連レコードを属性のように辿る テーブル定義を一箇所に置き、そこから型を導く スキーマの変更を差分として記録し、順に適用する 値をプレースホルダとして扱う 一連の操作をまとめて確定または取り消す 5/11
▪表で色を付けた2つ 批判が集中するのは b と c 2006年に「解けない」とされた食い違いは、 b(変換)と c(関連) に集中している。 bとc
構造から来るので解けない。今の不要論もここが中心。 a・d・e 争点にはなるが、別のツールに任せられる。 「ORM不要」と書かれているものの多くは、bとcを指しています。 今ココ 責務の分解 6/11
▪ひとまとめで提供されるものではない 責務は別々に取り外せる それぞれを単体で引き受けるツールが、実際に存在します。 dbmate … マイグレーション(e)だけ。素のSQLでup/downを書く Atlas … スキーマを宣言的に書いて差分を計算(d と
e) Kysely … TypeScriptのクエリビルダ(a・f・g)。b・c は持たない SafeQL … ESLintプラグイン。生SQLのまま、スキーマから型を検証する 今ココ 責務の分解 7/11
▪構成ごとに、どこを誰が持つか 責務の割り当てとして見る a b c d e f g 組み立て
変換 関連 情報源 移行 注入対策 トランザクション フルスタック ORM a から g までを1つのライブラリが抱える Kysely + Atlas Kysely なし 生 SQL + SafeQL 生SQL なし Atlas なし Kysely dbmate ドライバ 自分で担保 + dbmate 手放しているのは b と c だけ 「ORM を使う/使わない」は、実際にはこの割り当ての問題だった SafeQL は生SQLに型検証を足すもので、いずれかの責務を置き換えるものではない 責務ごとに、別のツールへ割り当て直せる 今ココ 責務の分解 8/11
▪特定のコミュニティの流行ではない 同じ形が、言語をまたいで並んでいる 【SQL前提の軽量ORM】SQLは開発者が書き、ライブラリはマッピングとバインドだけ Dapper sqlx MyBatis 実態はSQLを書く前提の軽量マッパー 標準ライブラリの薄い拡張 SQLを外に置いて結果を詰める C#
Go Java 【SQLファーストな型安全ORM】SQLを書く前提で、壊れないよう型で縛る sqlc TypedSQL SQLx jOOQ SQLからコードを生成する Prismaに載っている機能 コンパイル時にクエリを検証 SQL中心で型と高度なクエリ Go TypeScript Rust Java ORMを捨てたというより、ORMに期待しすぎない、という態度に近い 今ココ 責務の分解 9/11
▪まとめて決めなければならないものではない 実は組み合わせの問題だった ORMを外しても、d・e を Atlas に、a・f を Kysely に任せられる。 このとき手放しているのは
b と c だけ。 「ORMを使う/使わない」は、もっと細かい選択の集まりです。 今ココ 責務の分解 10/11
▪第4回 次回 2026年の不要論は何を言っているか 20年前の指摘は、責務の言葉に置き換えられる。 では今年、実際に何が言われたのか。 1月と9月、2つの波の中身に入ります。 今ココ おわりに 11/11