---
title: "SupabaseとCloudflareで専用Webアプリを作っている件"
date: 2026-10-22
categories: column
author: 大塚
canonical: https://www.liberogic.jp/topics/supabase-apps-cloudflare1/
---

# SupabaseとCloudflareで専用Webアプリを作っている件

![](https://images.microcms-assets.io/assets/4b13731f29254025b91c8d846198ffc9/581e3df395b8484ca694cec2b70428c8/cover.png)

SupabaseとCloudflareを活用した専用Webアプリ開発を解説。社内申請・承認システム、会員向けマイページ、取引先ポータルなど、業務に合わせたWebアプリの構築方法と、運用負担を抑えながら小さく始めて育てる開発手法を紹介します。

こんにちは、リベロジックでCTOをしている大塚です。

企業のWebサイトやシステムを狙ったサイバー攻撃が相次いでおり、一昨日よりPHPの重大な脆弱性も話題となっています。

今回お話しするWebアプリケーション開発に関しては、そうしたセキュリティ対策や運用の負担をできるだけ減らす構成とも言えますが、セキュリティの話はまた別の機会に取り上げたいと思ってます。

---

申請や承認、会員向けマイページ、取引先向けポータル、工数管理など、その会社の業務に合わせて作るオーダーメイドのWebアプリ構築によく使っているのがSupabaseとCloudflareの組み合わせです。

以前はAWS上にEC2・RDS・S3・Cognitoといったパーツを個別に構築したり、Linuxサーバーを立ててWebサーバーやミドルウェア、フレームワークを自前で載せたりとデータベース / 認証 / API / ファイルストレージのそれぞれに構築と運用の手間がかかっていました。  
SupabaseとCloudflareを利用すると、こうした土台部分はサービス側に任せてそのアプリに本当に求められる機能を作ることに集中できるようになったんですね。

今回はSupabaseとCloudflareを組み合わせると、どんな専用Webアプリが作れるのかをざっくり紹介します。

## 専用Webアプリとは

ここでいう「専用Webアプリ」とは、その会社や業務に合わせて作るWebアプリケーションのことです。  
例えばこんなものですね。

- 社内申請・承認システム
- 会員向けマイページ
- 取引先専用ポータル
- 工数・勤怠管理
- 案件管理
- 問い合わせ管理
- 店舗・拠点向け管理システム
- ファイル共有・確認システム
- アンケートや診断結果の管理
- 各種業務用の管理画面

このようなご相談をいただくと、まず既存のSaaSやパッケージ製品で実現できないかを調べます。一般的な業務であれば、その方が早く安く導入できることも多いからです。

ただ実際に要件を並べてみると、「まさにやりたいこと」にぴったり合う製品ってなかなか見つからないんですよね。  
会社独自の承認フローがあったり、部署や拠点ごとに見せる情報が違ったり、既存システムとの連携が必要だったり。

そうなってくると、SaaSに業務を合わせて運用でカバーし続けるよりも、業務に合わせた専用Webアプリを作ってしまった方が、クライアントの業務がスムーズに回る良い提案になる。そう判断するケースが実際には多いです。

## SupabaseはWebアプリのデータ基盤をまとめて持てる

Supabaseは、Webアプリに必要になるバックエンド機能をまとめて利用できるサービスです。

世界的に見てもかなり勢いのあるサービスで、利用する開発者は1,000万人を超えています。米国の著名スタートアップアクセラレータY Combinatorでは、直近のバッチの55%がSupabaseを採用したと発表されており、新規サービスのバックエンドとしては定番の選択肢になりつつあります。

こうした実績はBtoCで多数の利用者を抱えるサービスでのものが中心ですが、私たちはこの仕組みが、社内や取引先向けにいわば「イントラ的に使われる業務向けWebアプリ」にもそのまま適用できると考えて利用しています。

代表的な機能としては、

- Database（マネージドなPostgreSQLデータベース）
- Auth（ユーザー認証・ログイン）
- 自動生成API（テーブルを定義するとREST APIがそのまま使える）
- RLS（Row Level Security：行単位の権限制御）
- Storage（ファイルストレージ）
- Realtime（リアルタイム通信）
- Edge Functions（サーバーレスで動くAPI処理）

などがあります。

業務アプリであれば、ユーザー情報 / 案件情報 / 申請データ / 操作履歴などをSupabaseのデータベースで管理できます。

さらにSupabase Authを使えば、そのままログイン機能も持たせられます。このAuthが業務アプリと相性が良いのは、MicrosoftアカウントやGoogleアカウントでのサインインに対応していることです。

すでにMicrosoft 365やGoogle Workspaceを利用している会社であれば、社員は普段使っているアカウントでそのままログインできます。アプリ専用のID・パスワードを新たに発行して配る必要がなく、入退社時のアカウント管理も既存の仕組みに寄せられるんですね。

以前であればデータベースと認証を別々に用意してそれぞれをつなぐ構成も珍しくありませんでしたが、Supabaseならデータと認証をひとつの基盤としてまとめられます。

RLS（Row Level Security）を使えば、

- 自分のデータだけ見せる
- 同じ拠点のデータだけ見せる
- 管理者は全部見られる

といった制御もデータベース側で行えます。

業務アプリではこの権限制御がかなり重要です。

## フロントエンドの配信にCloudflareを使う

一方で、Supabase単体ではできないことがあります。「Webサイト（フロントエンド）のホスティング」です。  
データベースやAPIはSupabaseに持たせられても、ユーザーがブラウザでアクセスする画面そのものは、別の場所から配信する必要があるんですね。

この配信先の代表格がVercelとCloudflareです。私たちはCloudflareを選択しています。理由はいくつかあります。

- DNS / CDN / WAFからアプリの配信までをCloudflare上で一元管理できる
- Cloudflare Workersでフロントエンドの配信だけでなく、API処理や外部サービス連携までまとめて持たせられる
- R2（ストレージ）やAccess（アクセス制限）など、業務アプリと相性の良い周辺サービスが揃っている
- 転送量課金の考え方がシンプルで、予算が読みやすい

CloudflareというとCDNやDNSのイメージが強いかもしれませんが、現在はこうしたWebアプリの実行基盤としても十分に使えるサービスになっています。

[**Cloudflareを制作会社視点で整理する**](https://www.liberogic.jp/topics/20260416-cloudflare-intro1/)

つまりこの構成では、ユーザーからのアクセスを受けて画面とAPIを返すところまでをCloudflareが担い、その裏側のデータ・認証・権限制御をSupabaseが担う、という役割分担になります。

## SupabaseとCloudflareを組み合わせる

例えばこんな構成です。

![](https://images.microcms-assets.io/assets/4b13731f29254025b91c8d846198ffc9/a029c741f27244f2bb61e4c7a1ec0c6a/%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%88%E3%82%99%E9%80%A3%E6%90%BA%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3%E3%83%95%E3%83%AD%E3%83%BC%E5%9B%B3.png)

Cloudflare Workers上のアプリがユーザーからのアクセスを受けて画面とAPIを返し、その裏側でSupabaseがデータや認証を担当します。

必要に応じて、SendGridでメールを送ったり、Boxなどの外部ストレージにファイルを保存したり、他の業務システムとAPI連携したりします。

この構成の良いところは、全体が標準的な技術の組み合わせでできていて、連携先を選ばないことです。  
API連携に対応しているものであれば、既存の基幹システムでも、すでに使っているSaaSでも自由につなぎ込めます。業務パッケージにありがちな「この製品は○○としか連携できません」という制約がないんですね。

## 例えばこんな業務アプリを作れる

### 社内申請・承認アプリ

各拠点や担当者から申請を登録し上長や管理者が承認するようなアプリ。  
ログインしているユーザーによって、

- 自分の申請だけ表示する
- 拠点内の申請を表示する
- 管理者は全件表示する

といった制御もできます。  
メールとExcelで回していた業務を、そのままWebアプリ化するようなイメージですね。

### 取引先向けポータル

取引先ごとにログインIDを発行し、

- 資料の閲覧
- ファイルのアップロード
- 進捗確認
- 問い合わせ
- 契約情報の確認

などを行えるポータルも作れます。  
取引先ごとに見せる情報を変える、といった制御も比較的作りやすいです。

### 工数・勤怠管理

社員ごとに勤務時間や工数を入力しプロジェクト別、担当者別に集計するアプリで。  
一般的な勤怠SaaSでは扱いにくい独自ルールや自社特有の集計方法がある場合には専用Webアプリとの相性が良いです。

こういう業務って既製品に合わせようとすると逆に面倒になることがあるんですよね。

### 拠点管理システム

全国の店舗や営業所から情報を登録し、本部側でまとめて管理するようなWebアプリにも向いています。

数人だけで使う社内ツールから、複数拠点で使う業務アプリまで対応できます。  
「Supabaseだから小規模向け」というわけでもありません。  
設計次第で、かなり広い用途に使えます。

### 例えば弊社ではこんなアプリをお手伝いしています。

[トヨタ自動車様 SNS運用管理システム「TOYOTA Social Hub」UI/UX設計・システム開発](https://app.notion.com/p/SNS-TOYOTA-Social-Hub-UI-UX-33e7f3963da580059c60d0b6362ee72d?pvs=21)

## SaaSではなく専用Webアプリと判断する基準

ここまで専用Webアプリの良さを紹介してきましたが、常に専用Webアプリが正解というわけではありません。  
では、どこで「作った方がいい」と判断すればいいのか。実際のご相談を通して感じている目安を挙げてみます。

- **運用でカバーが常態化している** 承認ルートが部署ごとに違う、例外処理が多いなど、業務フローがSaaSの想定から外れていて、設定では吸収しきれていない
- **権限や見せ方の制御が細かい** 部署・拠点・取引先ごとに見せる情報を変えたいが、SaaSの権限機能では粒度が足りない
- **複数のツールをまたいで業務が回っている** Excel・メール・複数のSaaSを行き来し、転記やコピペが日常になっている
- **独自の管理項目や集計ルールが多い** 自社特有のデータをSaaSの汎用項目に無理やり押し込んでいる
- **現場には機能が多すぎる／足りない** 汎用SaaSゆえに画面が複雑で現場に使われない、あるいは肌心の機能だけがない

ひとつふたつ当てはまる程度なら、SaaSの設定や運用の見直しで乗り切れることも多いです。  
ただ、複数当てはまり、日々の「ちょっとした手間」が積み重なっているようなら、業務に合わせた専用Webアプリを検討するタイミングだと考えています。

実際、「Excelで管理している情報をWeb化したい」「メールで回している申請をシステム化したい」「複数のSaaSを行き来している業務をひとつにまとめたい」専用Webアプリの話は、こうした相談から始まることが多いです。

## 小さく作って、使いながら育てていく

ここまでは技術構成の話をしてきましたが、最後にお伝えしたいのは、SupabaseやCloudflareの機能そのものというより、プロジェクトの進め方です。

### 「何を作るべきか」は、要件定義書からは意外と見えてこない

一般的なソフトウェア開発は要件定義から始まります。既存の業務を一旦資料にまとめて、それを満たすシステムを設計していく進め方ですね。

ただ、この進め方には弱点があります。資料の上では業務を網羅できていても、「実際に使いやすい画面になるのか」「その機能は本当に必要なのか」という視点が抜け落ちたまま、要件だけが積み上がっていきやすいんです。  
特に、DX推進の担当になったもののシステム開発そのものは専門ではないという方にとって、文章と表だけで要件の妥当性を判断するのはかなり難しいはずです。

そこでリベロジックでは、最初に分厚い要件定義書を固めるのではなく、Figmaやv0、Claude Codeといったツールでモックアップ（実際に操作できる画面の試作）を作り、それを触ってもらいながら話を進めています。

文章だけの要件定義と違い、実際に画面を操作してみると「使ってみてどうか」を圧倒的なリアリティで体験できます。すると面白いことに、「この画面があれば業務のあの部分がすごく楽になる」「そういえば別でやっているあの作業も自動化できないか」と、目線が“資料の確認”から“業務の改善”へ変わっていくんですね。

専用Webアプリで意外と大事なのは、この「何を作るべきか」の部分です。それはドキュメントの中ではなく、モックアップを通してイメージを共有していく中でこそ見えてくると考えています。

### 基本部分だけ実装して、まずローンチする

最初にすべての要件を決めて一気に作りきる、いわゆるウォーターフォール型の進め方はしていません。モックアップで方向性が固まったら、まずはログイン / データ登録 / 一覧表示 / 管理画面といった基本的な部分だけを実装してローンチします。

そこから実際に使ってもらいながら、使用感や現場の反応を確認しつつ、承認機能・メール通知・ファイル管理・外部API連携などを追加していく。  
SupabaseとCloudflareの構成は、この段階的な進め方ととても相性が良いんです。

### 予算と業務価値に合わせて育てていける

「小さく作って必要に応じて拡張できる」というのは、予算面の話でもあります。例えば、

- 年間で確保している予算に合わせて、少しずつ機能を開発していく
- まず小さくローンチし、業務上の価値が見えてきたタイミングで追加投資してアプリを拡充していく

といった進め方ができます。最初に大きな開発費を一括で用意しなくても、業務アプリを持ち、育てていける。業務アプリは最初から要件を完璧に決めるより、使いながら改善した方がうまくいくことが多いと考えています。

## まとめ

SupabaseとCloudflareを組み合わせることで、認証・データベース・権限制御・API・ファイル配信を備えた専用Webアプリを、比較的小さな構成で作ることができます。社内の小さな業務ツールから、取引先向けポータル、複数拠点で使う業務システムまで、用途に応じて広げていけます。

ただ、本当に大事なのはSupabaseやCloudflareというツールそのものではなく、進め方です。

- まずモックアップで「実際に使うイメージ」を共有し、何を作るべきかを見つける
- 基本部分だけ作って、早くローンチする
- 使いながら、予算と業務価値に合わせて育てていく

こうした進め方はかつては現実的ではありませんでした。ソフトウェアの実装コストもインフラの構築コストも高く、あらかじめすべてを決めきってから作り始める必要があったからです。

今では、SupabaseやCloudflareのような現代的な技術スタックと、AIエージェントを活用した開発・プロトタイピングによって、「まず触れるものを作り、使いながら育てる」という、より理想に近い形でプロジェクトを進められるようになりました。リベロジックが得意としているのは、まさにこの進め方です。

「Excelとメールで回しているこの業務、Web化できないかな」「SaaSを試したけど、どうもうちの業務にはしっくりこない」そんな段階のご相談で大丈夫です。業務に合った構成を一緒に考えますので、お気軽にお問い合わせください。
