Accessアプリが長く使われてきた理由は、
フォームやVBAが優れていたからではない。
業務の正しさを JOIN とクエリ でDBに閉じ込めていたからだ。
一方、近年主流となった2次元前提の設計は、
業務アプリではしばしば破綻する。
原因は性能ではない。
DBが業務を理解しない構造にある。
本記事では、
なぜ2次元設計が業務アプリに向かないのか、
なぜPostgreSQL（Supabase）がAccess経験者に自然にフィットするのかを、
構築手順ではなく 設計思想 の観点から解体する。
これは、新しい技術を推す話ではない。
業務の核を、どこに置くべきか を見直すための話だ。
第1章｜Accessアプリの本体は「フォーム」ではなかった
Accessと聞いて、多くの人が思い浮かべるのはフォームだろう。
入力欄が並び、ボタンを押すと処理が走る、あの独特の画面。
だが、Accessアプリの本体は、あそこではなかった。
本体は クエリ にある。
正確に言えば、保存された SELECT / UPDATE クエリの集合体だ。
一覧画面は SELECT クエリ。
集計は GROUP BY を含む集計クエリ。
状態を進める処理は UPDATE クエリ。
帳尻合わせは JOIN した結果に対する更新。
フォームは、それらを「呼び出すための操作盤」にすぎない。
Accessを長く使ってきた人なら思い当たるはずだ。
フォームを消しても、クエリが残っていれば業務の骨格は分かる。
逆に、クエリが壊れた瞬間、どれだけ立派な画面があっても業務は止まる。
Accessアプリとは、
画面の裏側に、業務を理解したクエリが並んでいる
小さなDBアプリケーション
だった。
ここで重要なのは、
Accessが「2次元ツール」だったかどうかではない。
Accessが扱っていたのは、単なる行と列ではなかった。
・顧客と案件の関係
・案件と進捗の関係
・過去の状態と現在の状態
・確定前と確定後の違い
それらを JOIN とクエリ で再構成し、
その時点の「業務として正しい姿」を切り出していた。
つまりAccessは、
現在値の一覧を見る道具
ではなく
状態と関係を組み替えて業務を表現する道具
だった。
だからAccessは、
Excelでは無理だった領域を長年支え続けた。
Excelは「表を編集する道具」だが、
Accessは「業務をモデル化する道具」だったからだ。
この違いを体感していた人ほど、
後年の「2次元で十分」という言葉に、
どこか違和感を覚えたはずだ。
その違和感の正体こそが、
次章で扱う 2次元崇拝の起源 につながっていく。
第2章｜2次元崇拝は、どこから来たのか
「業務アプリは2次元で十分だ」
「JOINは遅い」
「DBはスケールしない」
こうした言葉が“常識”として語られるようになったのは、
Accessの時代よりずっと後の話だ。
これは思想の変化ではない。
事故の記憶だ。
2000年代後半から、
Webサービスは急速に巨大化した。
ユーザー数は増え、
データ量は跳ね上がり、
アクセスは秒単位で集中する。
その中で、多くのSQLサーバーが悲鳴を上げた。
・JOINが増える
・インデックス設計が追いつかない
・集計クエリが全体を巻き込む
・ピーク時にレスポンスが落ちる
結果として、
「JOINは悪だ」
「正規化はやりすぎるな」
「データは分けて、アプリで組み立てろ」
という“教訓”が生まれた。
ここで重要なのは、
それが間違いだったかどうかではない。
それは、
大量トラフィック・巨大データを捌くための現実的な判断だった。
だが、その文脈はいつの間にか失われた。
スケール問題への対処法が、
いつしか「設計思想」として独り歩きを始める。
業務アプリでも、
社内システムでも、
小規模な管理ツールでも、
とりあえず2次元
JOINは避ける
DBは薄く
という設計が“正解”として輸入されていった。
ここで、歪みが生じる。
業務アプリが扱う世界は、
Webサービスとは前提が違う。
・同時接続は限られている
・データ量は有限
・レスポンスより正しさが重要
・履歴と状態が価値そのもの
それにもかかわらず、
スケール事故を避けるための設計を、
そのまま持ち込んでしまった。
結果、
問題を解くための道具が、
問題そのものを変えてしまった。
2次元崇拝とは、
「単純さ」を求めた思想ではない。
壊れた記憶が固定化された結果
にすぎない。
Accessの違和感は、ここにある。
Accessが生き延びたのは、
奇跡でも、Microsoftの温情でもない。
当時の業務アプリが、
そもそもスケール事故の文脈にいなかったからだ。
そして次章で見るように、
この文脈の違いは、
「JOINできない世界で、何が壊れるか」
という、より具体的な破綻として姿を現す。
第3章｜JOINできない世界で、何が壊れるのか
JOINが使えない、あるいは使いづらい。
VIEWで自由に世界を切り出せない。
この制約が業務アプリにもたらす影響は、
性能問題よりもずっと深刻だ。
壊れるのは速度ではない。
設計そのものだ。
3-1. 一覧が「業務の姿」を表せなくなる
業務アプリで、最初に必要になる画面は何か。
ほとんどの場合、それは一覧だ。
・顧客と案件
・案件と進捗
・受注と請求
・現在の状態と直前の履歴
Accessでは、それらは JOIN で自然に表現できた。
VIEWを切れば、
「今、この業務をどう見るか」をDB側で定義できた。
だが JOIN できない世界では、そうはいかない。
- 顧客API
- 案件API
- 進捗API
それぞれを個別に取りに行き、
フロントで“組み立てる”しかなくなる。
その結果、一覧はこう変質する。
DBが定義した業務の姿
ではなく
画面ごとに即席で作られた表示用データ
一覧は業務の顔だ。
その顔が、画面ごとに別人になる。
3-2. 業務ロジックが、静かにUIへ逃げる
JOINが使えない世界では、
「業務として正しい形」を定義する場所がなくなる。
DBは、ただの保存箱になる。
すると何が起きるか。
- 状態チェックはUIで行う
- 更新順序はボタンの押し方に依存する
- 整合性は「気をつける」ことで担保する
つまり、
DBが業務を理解しない世界
が生まれる。
これは、ゆっくり壊れる。
最初は問題にならない。
単純なCRUDは動く。
件数も少ない。
だが画面が増え、
例外が増え、
運用ルールが積み重なると、
「この画面から更新すると壊れる」
「この順番で操作しないとダメ」
という“暗黙知”が増殖する。
Accessで UPDATE クエリに閉じ込めていたものが、
すべてUI側に漏れ出す。
3-3. PocketBaseがハマる場所、ハマらない場所
PocketBaseは軽い。
速い。
立ち上がりも早い。
2次元で完結する業務には、今でも有力だ。
・単純なマスタ管理
・イベントログ
・個別レコードのCRUD
だが、JOINで世界を再構成する必要が出た瞬間、
限界が見えてくる。
expand やフロントJOINで“頑張る”ことはできる。
だがそれは、
DBがやるべき仕事を、UIが肩代わりしている状態
に他ならない。
結果、フロントは修羅場になる。
- 画面ごとに異なる組み立てロジック
- テスト不能な分岐
- 状態が増えるたびに爆発するコード
これは、設計ミスではない。
道具の射程外なのだ。
3-4. Firebaseでも事情は同じ
Firebaseも同様だ。
- JOINはできない
- VIEWという概念がない
- 正規化すると、読む側が地獄になる
そのため、
「非正規化して持て」
「読みやすい形で保存しろ」
という設計が推奨される。
だがそれは、
更新が簡単な業務に限って成立する。
状態遷移や履歴を扱い始めた瞬間、
破綻の兆しが現れる。
更新ロジックはフロントへ。
整合性は人間任せへ。
3-5. 「最初は動く」が、最大の罠
ここが一番残酷だ。
JOINできない世界は、
最初はとても気持ちいい。
- 画面はすぐ作れる
- APIも単純
- データ構造も分かりやすい
だが、Accessで一度でも
JOINや更新クエリを書いた人は、必ず途中で気づく。
「あ、DBが何も分かっていない」
この瞬間から、
業務ロジックはUIへ、JSへ、ワークフローへと逃げ出す。
壊れるのは、性能ではない。
業務の理解を置く場所だ。
第4章｜PostgreSQLが「偉大」と言われる理由
PostgreSQLが評価されるとき、
しばしば「高機能」「多機能」「何でもできるDB」と言われる。
だが、それは本質ではない。
PostgreSQLが偉大なのは、
業務から逃げないところだ。
4-1. PostgreSQLは「速さ」で勝つDBではない
誤解されがちだが、
PostgreSQLはベンチマークで無双するタイプのDBではない。
- 設定しないと速くない
- 書き方を間違えると平気で遅くなる
- 魔法のスケールは起きない
それでも、業務用途で選ばれ続けてきた。
理由は単純だ。
業務として“正しいこと”をDBの中に書けるから
4-2. VIEWは「業務の見取り図」になる
PostgreSQLの VIEW は、単なる便利機能ではない。
VIEWとは、
業務の世界を、どう切り取るかを定義する装置
だ。
・一覧で見たい姿
・集計したい単位
・状態を含めた現在像
それらを、SQLとして固定できる。
これはAccessの保存クエリと完全に同型だ。
重要なのは、
フロントがどう表示するか
ではなく
業務としてどう見えるべきか
をDB側に閉じ込められる点にある。
4-3. FUNCTIONとトランザクションが「逃げ道」を塞ぐ
業務アプリが壊れる瞬間は、
たいてい「更新」にある。
- 複数テーブルを跨ぐ
- 状態を進める
- 履歴を残す
これをUIでやり始めると、
必ずどこかで破綻する。
PostgreSQLでは、
これを FUNCTION とトランザクションに閉じ込められる。
- 更新手順を1か所に集約できる
- 成功か失敗かをDBが保証する
- 半端な状態が残らない
これは「便利」ではない。
業務の正しさを、DBに強制させる仕組み
だ。
4-4. MySQL育ちだからこそ分かる違い
ここで、立場を明確にしておく。
筆者は長く MySQL を使ってきた。
Webアプリの現場では、MySQLは実用的で優秀だ。
だが、業務ロジックをDBに寄せようとした瞬間、
違和感が生まれる。
- VIEWが補助的
- FUNCTIONが主役になりづらい
- 「アプリ側でやれ」という空気
結果として、
DBは保存箱
業務理解はアプリ側
という設計に流れやすい。
これはMySQLが悪いのではない。
思想が違うだけだ。
4-5. PostgreSQLは「業務を理解する場所」を用意している
PostgreSQLは、
- VIEW
- FUNCTION
- トランザクション
これらを第一級市民として扱う。
つまり、
業務の理解を、DBに置く前提で設計されている
JOINで世界を再構成し、
VIEWで固定し、
FUNCTIONで更新を束ねる。
その結果、
DBが業務を理解する。
そしてこれは、
Accessがやっていたことと同じ構造だ。
第5章
Supabaseが「自然にフィットした」理由
Supabaseを触って最初に感じたのは、
「新しい」という驚きではなかった。
懐かしさ
に近い感覚だった。
それはUIの話でも、
BaaSとしての便利さの話でもない。
PostgreSQLの置き方が、
極めて素直だったからだ。
5-1. SupabaseはPostgreSQLを隠さない
多くのBaaSやバックエンドサービスは、
まず「簡単さ」を前面に出す。
- テーブルを直接触らせる
- クエリを抽象化する
- DBを意識させない
Supabaseは違う。
- VIEWが普通に使える
- FUNCTIONが正規ルート
- RPCとして呼び出す設計が前提
つまり、
PostgreSQLを“使わせない”のではなく
“ちゃんと使わせる”構成
になっている。
これは偶然ではない。
5-2. Studioは「便利ツール」ではない
Supabase Studioは、
管理画面としてよく出来ている。
だが、価値は操作性ではない。
Studioがやっているのは、
DB中心設計から逃げさせないこと
だ。
- 業務用のVIEWを定義する
- 更新はRPC経由で行う
- テーブル直叩きを避ける
この導線が、最初から用意されている。
結果として、
「フロントで頑張る」
という発想が、自然と出てこない。
5-3. Supabaseが“すごい”のではない
ここは誤解を避けておく。
Supabase自体が、
何か魔法をしているわけではない。
すごいのはPostgreSQL
Supabaseは、その能力を引き出すための枠組み
にすぎない。
だが、この「枠組み」が重要だ。
- 自前でPostgreSQLを立てる
- 権限を切る
- APIを用意する
これらを正しくやろうとすると、
途端に敷居が上がる。
Supabaseは、
正しい構成を
最初から“当たり前”として提供している
ここがフィット感の正体だ。
5-4. Access経験者ほど、違和感がない理由
Accessでまともに作られたアプリは、
- 保存クエリが業務を表し
- 更新クエリが状態遷移を担い
- フォームは操作盤だった
Supabase＋PostgreSQLの構成は、
これと完全に同型だ。
- VIEWが業務の姿
- FUNCTIONが更新手順
- フロントは薄いUI
だから、
新しい技術を学んでいる感覚が薄い
Access経験者ほど、
「戻ってきた」感じがする。
5-5. FirebaseやPocketBaseとの決定的な違い
FirebaseやPocketBaseが提供するのは、
「すぐ動く世界」だ。
だがSupabaseが提供するのは、
業務を正しく閉じ込める場所
JOINで世界を再構成できる。
VIEWで切り出せる。
更新をDB側に束ねられる。
この自由度の差が、
フロントの地獄と安定を分ける。
第6章
フロントの自由度と、「10年耐える」設計
業務の核をDBに置く。
JOINとVIEWで業務の姿を定義し、
更新はFUNCTIONに閉じ込める。
この構成の最大の美点は、
フロントが自由になることだ。
だが、これは目的ではない。
結果にすぎない。
6-1. フロントは「業務を理解しなくていい」
DBが業務を理解している状態では、
フロントの役割は明確になる。
- 表示する
- 入力を受け取る
- 結果を返す
それだけでいい。
状態遷移の正しさや、
更新順序の保証を、
UIが気にする必要はない。
業務ロジックは、もうDBの中にある
この前提があるだけで、
フロント設計の難易度は激減する。
6-2. 技術選定の寿命が、一気に伸びる
フロントエンド技術は、必ず変わる。
- 流行る
- 廃れる
- 書き直される
これは避けられない。
だが、業務の核がDBにあれば、
それは問題にならない。
- ReactからSvelteへ
- SPAから別の形へ
- Webから別のUIへ
どれも、外皮を張り替えるだけで済む。
技術の寿命を
業務の寿命に直結させない
これは、設計上の大きな勝利だ。
6-3. 10年後も残るのは、コードではない
10年後を想像してみる。
今書いたフロントコードは、
ほぼ確実に残っていない。
だが、
- テーブル構造
- VIEW
- 業務制約
- 更新手順
これらは、残る。
いや、
残っていなければ困る。
業務は続くからだ。
Accessアプリが今も稼働している理由は、
UIが優れていたからではない。
業務の構造が、DBの中に残っていたから
に他ならない。
6-4. 「DB中心設計」は保守のための思想でもある
この設計は、
未来のエンジニアへの配慮でもある。
DBを見れば、
- 業務の全体像が分かる
- 状態遷移が追える
- 何をしてはいけないかが分かる
コードを全部読む必要はない。
DBが、業務の設計書になる
これは、
ブラックボックス化を防ぐ最も確実な方法だ。
6-5. Accessゾンビが生き延びた理由と、その限界
今も稼働しているAccessアプリは多い。
それは、
- 偶然ではない
- 運が良かったわけでもない
DB中心設計だったから、生き延びただけだ。
だが、実行環境は限界に近い。
- VBA / VBSの終焉
- OS依存
- 属人化
業務の核を救い出さなければ、
次はない。
そして、その核は、
すでにDBという形で存在している
第7章
PocketBaseは間違っていなかった ─ 軽量級と重量級の分岐点
ここで、一度立ち止まる必要がある。
筆者は以前、
Accessの移行先として PocketBase を評価する記事を書いた。
軽量で、導入が容易で、現場が自力で保守できる。
その評価自体は、今も変わっていない。
では、今回の Supabase / PostgreSQL 論と矛盾するのか。
結論から言えば、矛盾しない。
ただし、射程が違う。
7-1. PocketBaseが救える現場は、確かに存在する
PocketBaseが優れているのは、
- 単純なCRUD
- 2次元で完結する業務
- 状態遷移が浅い業務
こうした領域だ。
Access時代の“悪癖”──
マスタの増殖、過剰な正規化、無意味なJOIN──
これらを捨てるには、PocketBaseは非常に有効だ。
「まず壊れない形に逃げる」
という意味で、
PocketBaseは正しい避難路になり得る。
7-2. だが、JOINが必要になった瞬間に分岐する
問題は、その先だ。
業務が育つと、必ずこうなる。
- 一覧に条件が増える
- 状態と履歴を同時に見たくなる
- 複数テーブルを跨いだ整合性が必要になる
このとき、
JOINでVIEWを切り直せるかどうか
が決定的な分岐点になる。
PocketBaseでは、
この再構成の自由度がない。
その結果、
- フロントJOIN
- expandの多重化
- 画面ごとの即席ロジック
が増殖し、
フロントが修羅場になる。
これは設計ミスではない。
道具の適用範囲を超えただけだ。
7-3. Firebaseも同じ位置にいる
Firebaseも同様だ。
- JOINできない
- VIEWがない
- 非正規化が前提
これらは、
高速な読み取りが主役の世界では合理的だ。
だが、
業務を“再構成して見る”必要が出た瞬間
同じ壁にぶつかる。
Firebaseが悪いわけではない。
解いている問題が違う。
7-4. 軽量級と重量級の違いは「DBに任せる覚悟」
結局のところ、違いはこれだ。
- 軽量級
→ DBは保存箱
→ 組み立てはアプリ側 - 重量級
→ DBが業務を理解する
→ 再構成はJOINとVIEW
どちらが上、ではない。
どこまでDBに任せる覚悟があるか
その違いだ。
PocketBaseは「軽く逃げる」ための道具。
Supabase + PostgreSQLは
「重くても正しく生き延びる」ための構成。
7-5. 前回の記事と今回の記事の関係
前回の記事は、
「まず現場を救う」
話だった。
今回の記事は、
「業務の核を、10年先まで残す」
話だ。
思想は同じ。
DB中心設計。
射程が違うだけだ。
第8章（結論）
業務アプリに迷ったときの、ひとつの羅針盤
この話は、
Supabaseの優位性を語るための記事ではない。
PostgreSQLを讃えるための記事でもない。
業務アプリと向き合うとき、どこを基準に考えればいいか
その羅針盤を示すための話だ。
2次元育ちの若い人へ
これから、業務アプリの改修や引き継ぎに直面する人は多い。
Accessで作られた、
見た目は古く、
触るのが怖く、
ドキュメントもないシステム。
その中身を覗いたとき、
こう思うかもしれない。
「なんでこんな複雑なことをDBでやってるんだ」
だが、少し立ち止まってほしい。
それは、
「昔の人が無知だった」からではない。
業務を壊さないために、
正しさをDBに閉じ込めた結果
かもしれない。
JOINや更新クエリは、
混乱の原因ではない。
業務を理解した痕跡だ。
2次元で育った感覚を捨てる必要はない。
だが、
「DBは保存箱にすぎない」
という前提だけは、
一度疑ってみてほしい。
それだけで、見える景色は変わる。
Accessを延命してきた経営者・現場責任者へ
Accessアプリを、
ここまで使い続けてきたのは失敗ではない。
それは、
- 予算がなかったから
- IT部門がなかったから
- 現場を止められなかったから
ではない。
業務の核を、きちんとDBに置いてきたから
だ。
問題は、
その器が限界に来ていることだけだ。
VBAやVBScriptの終焉は、
脅しではない。
業務の中身を救い出すための合図
だと捉えていい。
Accessを捨てる必要はない。
捨てるのは、UIと実行環境だけでいい。
業務の核は、
すでにあなたの手元にある。
技術は変わる。業務は残る。
フロントエンドは変わる。
言語も変わる。
流行り廃りは止められない。
だが、
- 業務の正しさ
- 状態遷移
- 履歴
- 関係性
これらは、変わらない。
それをどこに置くか。
UIか、コードか、DBか
この記事が伝えたかったのは、
ただそれだけだ。
最後に
問題は、
クラウドかオンプレかではない。
問題は、
新しいか古いかでもない。
業務を2次元だと信じてしまったこと
そこから一歩引いて考えられるなら、
道はまだある。
この文章が、
誰かが業務アプリの前で立ち止まったときの
小さな羅針盤になれば、それで十分だ。
