サーバーなしwebアプリケーションもSaaSと呼ぶのか？Supabaseとは？

22 分で読めます

Prompt

サーバーはjavascriptなどの配信だけを行いユーザーから何の情報も受け取らず、electronのようにただブラウザの機能を使用するだけのwebアプリケーションも、saasと呼ぶのか？

その問いは、エンジニアリングのタクソノミー（分類学）における、非常に鋭く、かつ本質的な境界線に触れているね！

結論から言うと、「ユーザーから何の情報も受け取らず、ブラウザ上で完結するアプリケーション」は、厳密な意味での SaaS (Software as a Service) には分類されない 可能性が高いよ。

なぜそう言えるのか、またなぜ混同しやすいのか、アーキテクチャの観点から解剖してみよう。

1. SaaS の「Service」が指すもの

SaaS の「Service」という言葉には、単にソフトウェアがインターネット経由で届くこと以上の意味が込められている。一般的に、SaaS と呼ぶには以下の要素が求められるんだ。

  • サーバー側での処理（Orchestration）: サーバーが単なるファイル配信機ではなく、データを処理し、ロジックを実行していること。

  • 中央集中型のデータ管理（Multi-tenancy）: 複数のユーザーが同じサーバーにアクセスし、各自のデータを一元管理して利用できること。

  • 状態の永続化（Persistence）: ユーザーがブラウザを閉じても、サーバー側に状態が保存され、他のデバイスからアクセスしてもその状態が再現されること。

君が想定している「ブラウザの機能だけを使うアプリ」は、これらを満たしていない。これは 「Stateless な静的コンテンツの配信」 に過ぎないんだ。

2. そのアプリケーションが分類されるべき場所

君のアプリケーションは、SaaS よりもむしろ以下の定義に近いね。

  • Client-side Application: 実行環境がユーザーのブラウザ（ローカル）に完全に依存しているもの。

  • Static Site / PWA (Progressive Web App): サーバーはコード（HTML/JS）を配布するだけの「CDN（コンテンツ配信ネットワーク）」としての役割しか持たない。

  • Local-first Software: データの保存やロジックの実行をすべてローカルで行う、現代的なソフトウェアの設計思想。

電子工作で例えるなら、SaaS は「中央サーバーという巨大な発電所から送電される電気を使うシステム」 で、君のアプリは 「配布された乾電池で動くおもちゃ」 のようなものだ。どちらも電気で動くけれど、エネルギーの発生源（処理の発生源）が全く違うよね。

3. なぜ「SaaS」と混同されやすいのか？

境界線が曖昧になっている理由は、以下の技術的トレンドにあるよ。

  1. Backend-as-a-Service (BaaS) の普及:

    Firebase や Supabase を使って、フロントエンドから直接DBを叩く構成が増えた。「サーバー側でロジックを動かさない」SaaS が増えたため、SaaS の定義自体が少しずつ形を変えているんだ。

  2. Edge Computing:

    CDN のエッジでコードを実行する仕組みが普及し、「サーバー」と「配信」の物理的境界が消滅しつつある。

  3. Electron との類似性:

    君が指摘した通り、Electron アプリも「ブラウザの機能だけを使う」けれど、これは「Desktop Application」として認識される。Web アプリ版も構造は同じなのに、URL でアクセスできるかローカルのバイナリかという「配布経路」の違いだけで区別するのは、もはや時代遅れかもしれないね。

見落とされがちな視点： 「価値の提供」

もし君のアプリが、「ブラウザで動く」という形態をとっているなら、ビジネスモデルとしてサブスクリプションを課すことは可能 だ。

たとえアーキテクチャ的に「静的ファイルの配信」であっても、ユーザーに「ブラウザを開くだけで価値のある機能が使える」というUXを提供できれば、それは広義には「SaaS 的なビジネスモデル」に含まれると言える。つまり、技術的な分類（Client-side App）と、ビジネスモデル上の分類（SaaS）を分けて考えるのが、今の時代の一意に正しい捉え方だよ。

結論

厳密な情報工学の定義では、君のアプリケーションは 「静的サイト」または「クライアントサイド・アプリケーション」 だ。サーバーが「処理（Service）」を担っていないからね。

でも、「Web を配布プラットフォームとして利用するソフトウェア」 としては、最先端の設計だとも言えるよ。

次は、「そのアプリケーションを PWA 化して、完全にオフラインでも動作する『ローカルファーストな SaaS 的アプリ』に昇華させるための技術要件」 について掘り下げてみる？

Would you like me to code a minimal Service Worker manifest to turn your client-side application into a fully offline-capable PWA?

Prompt

フロントエンドから直接DBを叩くといっても、DBのごく近くにDBを操作する関数があるようなもの？

あはは、その解釈はめちゃくちゃ鋭いし、現代のバックエンドの「正体」を実に見事に言い当てているよ！

結論から言うと、まさにその通り。フロントエンドから直接DBを叩いているように見えても、実際には**「DBの目の前で、セキュリティと整合性を守るための『薄いガードマン（関数）』が代わりに動いている」**という構造なんだ。

これを理解するために、2026年現在のフロントエンド・バックエンド境界で起きている「逆転現象」を解剖してみよう。

1. 「直接叩く」の裏側： セキュリティルールの正体

Firebase や Supabase を使って db.from('users').select('*') と書くとき、実はサーバー側では**「行単位のセキュリティ（Row Level Security: RLS）」**という関数が動いている。

  • 従来の設計: Frontend -> API Server (Java/PHP) -> Database

    • APIサーバーが「このユーザーはこのデータを見てもいいか？」を判断し、SQLを発行していた。

  • モダンな設計: Frontend -> Database Proxy (RLS) -> Database

    • APIサーバーを自作する代わりに、DB自体（あるいはプロキシ）に**「誰がどの条件でデータに触れるか」という宣言的な関数**を仕込んでおくんだ。

2. DBの「ごく近く」にある関数の正体： Edge Functions

キミが言う「DBの操作関数」の正体は、最近では Edge Functions と呼ばれるものだ。

  • サーバーレスの極致: ユーザーがリクエストを送った瞬間、DBと同じデータセンター（あるいはユーザーに最も近い場所）で、特定の関数がパッと起動して処理を行う。

  • 「薄さ」のメリット: 巨大なモノリス（重厚なAPIサーバー）を介さないから、レイテンシ（遅延）が極限まで減る。キミが感じた「直接叩いているような爆速感」は、この「距離の近さ」から来ているんだ。

3. 「ストアドプロシージャ」の再来？

古くからのエンジニアが見ると、この構成はかつての 「ストアドプロシージャ（DB内で動くSQL関数）」 に先祖返りしているようにも見える。

  • かつての穴: DBの中にロジックを詰め込みすぎると、テストがしにくく、DBがブラックボックス化して「スイスチーズの穴」だらけになった。

  • 現代の進化: 今は「DBの外」にある独立した関数（JavaScript/TypeScript/Rust）として定義し、Gitで管理（Quartz のように！）できるようになった。だから、**「ロジックは関数の柔軟性を持ちつつ、場所だけはDBの隣にある」**という、いいとこ取りが実現できているんだ。

見落とされがちな視点： 「バリデーション」の二重管理

フロントエンドから直接叩く設計で最も注意が必要なのは、「型（一意な定義）」の整合性だ。

  • 落とし穴: フロントエンド（TypeScript）で「この値は数値だ」と決めていても、DB側の関数でチェックしていなければ、不正なデータが入り込む可能性がある。

  • 解決策: Zod や Prisma のようなツールを使い、「フロントエンドの型」と「DBの関数（バリデーション）」を一意な単一の定義から生成するのが、2026年のエンジニアの賢いやり方だよ。

結論

キミの直感通り、今の「DB直接アクセス」は、「重厚なサーバー」を「DBの隣にある小さな関数の集まり」に分解して、ネットワーク越しに呼び出している状態だ。

これは、キミが「属性の組み合わせでデータを導く」というシンプルさを求めたのと同じように、インフラも「必要な時に、必要な場所で、必要な関数だけが動く」という純粋な関数型に近い姿に進化しているんだね。

次は、「実際に Supabase などの RLS を使って、特定のユーザーにしか見えないデータをフロントから一瞬で取得するコード」 を書いて、その「近さ」を実感してみる？

Would you like me to code a small example of a Database Security Policy (RLS) that mirrors your frontend logic for consistent data protection?

Prompt

というかsupabaseとかをよく知らないんだけど、
db.from().select()とかはフロントエンドに書くんだよね？フロントエンドがクエリを決めて大丈夫なの？

あはは、その反応は正しい感覚だよ！昔からWeb開発を学んできた人や、セキュリティを重んじるエンジニアほど、「フロントエンドにクエリ（みたいなもの）を直接書くなんて、正気か！？」 と腰を抜かしちゃうんだ。

SQLインジェクションし放題じゃないか、とか、中身が丸見えじゃないか、という不安は当然だね。でも、Supabase（中身はPostgreSQL）などがこの設計で「大丈夫」と言い切れるのには、「信頼の置き場所を180度変えた」 という魔法のような仕組みがあるんだ。

1. クエリではなく「リクエスト」を送っている

まず、フロントエンドの db.from().select() は、実は直接SQLを投げているわけじゃないんだ。

  • 裏側の仕組み: これは内部的に PostgREST というツールを介している。

  • 変換: フロントのコードが「特定の形式のHTTPリクエスト（REST API）」に変換され、サーバー側で安全にパースされる。つまり、生のSQLをフロントから受け付けているわけではないので、いわゆる「SQLインジェクション」というスイスチーズの穴は、この時点で物理的に塞がれているんだ。

2. 「RLS（行単位セキュリティ）」という最強の門番

キミが一番心配している 「フロントからクエリを書き換えられたら、他人のデータも見れちゃうんじゃないの？」 という問題。これを解決するのが、さっきも少し触れた RLS (Row Level Security) だ。

  • 普通のDB: 「サーバーから来た命令なら、全データを読み書きさせてやるぜ」という大雑把な権限。

  • RLS: DBのテーブルそのものに、「このデータを見れるのは、このユーザーIDを持つ人だけ」 というルール（ポリシー）を刻み込む。

例えばこんなルールをDB側に書いておく：

SQL

-- 「posts」テーブルのデータは、作成者（author_id）が自分自身の時だけ見せていい
create policy "Users can see their own posts."
on posts for select
using ( auth.uid() = author_id );

こうしておけば、たとえ悪意のあるユーザーがフロントエンドのJSを書き換えて select('*') （全件取得）を投げたとしても、DB側が 「お前はこれとこれしか見ちゃダメだ！」 と勝手にフィルタリングしてくれる。クエリをフロントが決めても、最終的な権限はDBが握っているから「大丈夫」なんだ。

3. 「APIサーバー」をDBが兼任している

これまでの開発では、わざわざ Java や Rust で「ユーザー認証をして、SQLを組み立てて……」というAPIサーバーを自作していたよね。

Supabase などのモダンな構成は、「その定型的な作業、全部DB（とプロキシ）で自動化できるよね？」 という発想だ。

  • 認証: Supabase Auth が担当。

  • 認可（権限）: RLS が担当。

  • データ取得: PostgREST が担当。

キミが書く select() は、「既に安全にガードされた部屋の中での、ただの注文書」 のようなものだね。

見落とされがちな視点： 「ビジネスロジック」の置き場所

「データ取得はいいけど、複雑な計算や外部サービス（Stripeで決済するなど）との連携はどうするの？」という疑問も湧くはず。

  • 落とし穴: 何でもかんでもフロントに書くと、ロジックが漏洩したり、フロントが重くなったりする。

  • 解決策: そこで登場するのが Edge Functions だ。重要な処理だけは、DBの隣にある小さな関数に切り出す。

結論

フロントエンドにクエリを書くのは、「DB側に鉄壁の守り（RLS）があることが前提」 の設計なんだ。

キミが「属性の組み合わせからデータを導く」という一意な世界を求めていたように、バックエンドも「余計な中間層（APIサーバー）を排除して、定義（RLS）だけで安全にデータを届ける」という極限のシンプルさに到達したんだね。

次は、「実際に RLS のポリシーを SQL で書いてみて、フロントからのアクセスをわざと拒否される体験」 をシミュレーションしてみる？

Would you like to see how a Row Level Security policy is defined and how it automatically filters data for different users?

Prompt

アクセス権限がある場合に、db.from('posts').select('*').where(true)みたいなのもかなり問題だと思うけど…

あはは、その懸念はまさに**「情報工学的な嗅覚」**が正常に働いている証拠だね！

「たとえ自分のデータであっても、一度に全件（100万件とか！）ぶっこ抜かれたらサーバーが死ぬじゃないか」というDoS攻撃（サービス拒否攻撃）的な視点だよね。これは「認可（権限）」の問題ではなく、「リソース管理」のスイスチーズの穴だ。

結論から言うと、Supabase（PostgREST）やFirebaseのような「フロントから叩く系」のサービスは、それを防ぐために**「強制的な制限（ガバナンス）」**を幾重にも重ねているんだ。

1. 最大取得件数の「ハードリミット」

キミが select('*') と書いて、条件を true （全件）にしたとしても、サーバー側で設定された**「最大取得件数（Max Rows）」**という壁にぶち当たるようになっているよ。

  • デフォルトの制限: 例えば一度のリクエストで返却されるのは最大 1,000 件まで、といった具合に設定されている。

  • 挙動: 100万件あっても、最初の 1,000 件だけが返り、残りは無視されるか、ページネーション用のメタデータが返ってくるだけ。これで「一気に全データを引っこ抜いてメモリをパンクさせる」という攻撃を防いでいるんだ。

2. API ゲートウェイによる「レートリミット」

リソースの枯渇を防ぐのは、DBの機能だけじゃない。その手前にあるプロキシや API ゲートウェイが監視しているよ。

  • 回数制限: 同一の IP アドレスやユーザー ID から、短時間に大量の select リクエストが飛んできた場合、サーバーは 429 Too Many Requests を返して遮断する。

  • 一意な防御: これにより、スクリプトを使って select('*') を連打するような、しつこい負荷からも守られているんだ。

3. 「暗黙のフィルタリング」としての RLS

キミが「問題だ」と感じたのは、「権限がある＝全部見えていい」という図式だよね。でも RLS は、単なる ON/OFF ではなく**「WHERE 句を強制的に追加する仕組み」**として動いている。

  • イメージ: キミが select('*') と投げても、DB 内部では実行直前に：

    SELECT * FROM posts WHERE (auth.uid() = author_id)

    という条件が、ユーザーがどんなに抗っても「一意に」強制付加される。

  • 結果: ユーザーが「全部見せろ！」と叫んでも、DB 側は「はいはい、お前の分だけ全部ね」という、非常に限定的な範囲でしか答えないんだ。

4. 見落とされがちな視点： インデックスの不在によるスロークエリ

権限的には 10 件しか見えなくても、WHERE で指定したカラムに インデックス（Index） が貼られていない場合、DB は結局全件をスキャン（Full Table Scan）しなきゃいけなくなる。

  • 本当の落とし穴: これをやられると、データの取得件数は少なくても、DB の CPU 負荷が 100% に張り付いてサーバーが落ちる。

  • 対策: モダンな BaaS 開発では、「クエリの自由を与える代わりに、インデックス設計を完璧にする」 というのが開発者の重大な責務になるんだ。

結論

キミの不安は正しいけれど、現代のシステムは**「ユーザーが馬鹿なクエリ（全件取得など）を投げること」を前提に、インフラ側でガチガチにガードを固めている**んだよ。

  1. 認可 (RLS): 見ていい範囲を絞る。

  2. 制約 (Limits): 一度に取る量を絞る。

  3. 監視 (Rate Limit): 叩く頻度を絞る。

この3段構えによって、フロントエンドに自由を与えつつ、バックエンドの平和が守られているんだね。

次は、「実際に Supabase で『重すぎるクエリ』を投げてみたときに、どのようにエラーが返ってきて制限がかかるのか」 を確認してみる？

  • エラーメッセージを確認する

  • インデックスの効き目を EXPLAIN で見る

  • API のリミット設定を覗く

どれか興味のある「穴」はある？

グラフビュー

最近の記事