BaaSとは?2つの意味を切り分けて解説——Backend as a Serviceで借りられる5機能、費用が跳ねる条件、Banking as a Serviceとの違い【2026年版】

「提案書に『バックエンドはBaaSを使います』と書いてあって検索したら、銀行の話が出てきたのですが」——アプリの開発を発注する立場の方から、こうした相談をよく受けます。検索し直すと、今度はFirebaseというサービスの話になっている。同じ3文字なのに、着地する記事の主題が違う。どちらを読むべきか分からないまま、タブを2つ開いて止まる。そういう方は少なくありません。

先に答えを書きます。BaaSという略語には、まったく別の2つの意味があります。ひとつは Backend as a Service。ログイン、データの保管、画像の置き場、通知といったアプリの裏側を、自前でサーバーを立てずに借りる仕組みです。FirebaseやSupabaseがこれにあたります。もうひとつは Banking as a Service。銀行が自社の機能をAPIで他社のサービスに組み込めるようにする、金融の仕組みです。2つに技術的なつながりはありません。

本記事の主題は前者に置きます。開発を発注する立場の方が「BaaS」に出会う場面のほとんどが、こちらだからです。そして発注者が本当に押さえるべきは、機能の一覧ではありません。押さえるべきは一点、借りた範囲は、自分では作り変えられないということです。ここから、費用が読みにくくなることと、他へ移りにくくなることの2つが派生します。

本記事では、2つの意味の切り分けと定義、借りられる5つの機能と代表的な3サービス、向くアプリと向かないアプリおよび費用が跳ねる3つの条件、ベンダーロックインと自前バックエンドへ移る判断、独立した章でのBanking as a Serviceの説明、そして引き継ぐ・移すときの体制の順に解説します。クラウドの基礎とSaaS/PaaS/IaaSの詳細、ノーコードの一般論、チャット機能の設計は扱わず、既存の記事に譲ります。機能と料金は2026年9月16日に公式ページで確認した値を使い、確認できなかったものは書きません。なお、Banking as a Serviceの記述は金融庁の公表資料で確認できた範囲の一般的な説明であり、法的な助言ではありません。登録や許可の要否は必ず専門家にご確認ください。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。近年増えているのが「前の開発会社がBaaSで作ったアプリを引き継いでほしい」という依頼です。そのとき最初に確認するのは、コードではありません。クラウドのアカウントが誰の名義で、課金の請求がどこへ行っているかです。前の会社の名義のままだと、コードを受け取っても動かせないからです。BaaSは技術の話に見えて、半分は取り決めの話。読み終えるころには、開発会社に何を聞き、何を書面に残すべきかが決められるはずです。

BaaSとは——まず2つの意味を切り分ける。本記事の主題は「Backend as a Service」

BaaSとは、アプリの裏側(バックエンド)を自前で作らず、クラウド上のサービスとして借りる仕組みのことです。ただし、この説明を読んで「銀行の話ではなかったのか」と思った方もいるはずです。それも間違いではありません。BaaSという3文字の略語には、まったく別の2つの意味が同居しているからです。まずここを切り分けます。

BaaSには2つの意味がある——Backend as a Service と Banking as a Service

検索して出てくる記事が「Firebaseの話」と「銀行APIの話」に分かれるのは、読んでいる側の勘違いではありません。同じ略語が、無関係な2つの言葉から作られているためです。

2つの間に技術的なつながりはありません。略語がたまたま衝突しているだけです。この記事の主題は①の Backend as a Service に置きます。開発を発注する立場の方が「BaaS」という語に出会う場面は、ほとんどがこちらだからです。②の Banking as a Service についても、後半に独立した章を設けて説明します。

Backend as a Serviceとは——サーバーを自前で持たずに、アプリの裏側を借りること

Backend as a Service とは、アプリを動かすために必要な裏側の機能を、自前でサーバーを立てて作るのではなく、出来合いのサービスとして借りる仕組みです。

スマートフォンのアプリを1本作る場面を考えてみます。画面のデザインやボタンの動きは、利用者の目に見える部分です。これをフロントエンドと呼びます。一方で、ログインの認証、入力されたデータの保管、写真の置き場所、通知の送信といった機能は、利用者の目には見えません。これがバックエンドです。この2つは通常APIという窓口でつながっており、境界の考え方そのものは『フロントエンドとバックエンドの違い』の記事に譲ります。

従来、バックエンドを用意するには、サーバーを借りてOSを設定し、データベースを立て、認証の仕組みを実装し、動き続けるように監視する、という一連の工程が必要でした。BaaSはこの工程を丸ごと肩代わりします。開発者は画面と、そこで動くロジックに集中でき、裏側は用意されたものを呼び出すだけで済みます。

省けるものが大きいぶん、開発期間は短くなり、費用も下がります。冒頭で触れた「見積もりが他社の6割」という現象は、多くの場合ここから来ています。ただし、省いた工程には省いただけの意味があったという話を、この記事の後半で扱います。

IaaS・PaaS・SaaSとの位置関係——BaaSは「アプリ開発に必要な部品を組にしたPaaSの一種」

クラウドの区分を調べると、IaaS・PaaS・SaaSという3つの言葉が出てきます。BaaSはこのどれにあたるのか、という疑問は当然出ます。

結論から言えば、BaaSはPaaSの一種と整理するのがいちばん実態に近いと考えています。IaaSがサーバーやストレージといった素材を貸すもの、PaaSがアプリを動かすための土台一式を貸すもの、SaaSが完成したソフトそのものを貸すものだとすると、BaaSは「土台のうち、アプリ開発で毎回必要になる部品(認証、データベース、ストレージ、通知)をあらかじめ組にして貸すもの」です。PaaSより用途が絞られている代わりに、そのぶん出来合いの度合いが高い、と考えると位置がつかめます。

ただし、この3区分そのものをきちんと理解したい場合は、『クラウドとは』の記事に整理があります。本記事では区分の詳細には立ち入りません。

なお、スマートフォンアプリ向けのBaaSを mBaaS(mobile Backend as a Service)と呼ぶことがあります。2010年代前半によく使われた呼び方で、現在は Web も含めて単に BaaS と呼ぶことのほうが多くなっています。古い資料でこの語を見かけたら、同じものを指していると考えて差し支えありません。

ここから先は、断りのないかぎり BaaS は①の Backend as a Service を指します。②については後半の独立した章で扱います。

BaaSで借りられる5つの機能と、代表的なサービスの特徴

では、具体的に何が借りられるのか。サービスによって名前は違いますが、中身はおおむね5つに収まります。認証、データベース、ストレージ、プッシュ通知、サーバーレス関数の5つです。ここではそれぞれについて、自前で作るなら何をすることになるのかと並べて見ていきます。機能名だけを覚えても、省ける工程の大きさは見えてこないためです。

5つの機能——認証、データベース、ストレージ、プッシュ通知、サーバーレス関数

Firebaseの場合、上記に加えて Hosting(Webサイトの公開)、App Check(不正利用の防止)、Crashlytics(アプリの異常検知)、Remote Config(アプリの設定を後から変える仕組み)、A/B Testing、Performance Monitoring などが提供されています(2026年9月16日に公式のプロダクト一覧で確認)。

この5つが揃うと、標準的なアプリはかなりの範囲を組めます。当社が手がけてきた案件でいえば、AIチャットボット、求人プラットフォーム、ヘッドレスCMSを使ったWebサイトのように、扱うデータが素直で、処理が利用者の操作に紐づいて完結するものは相性がよい部類です。チャット機能についても、リアルタイムの同期をBaaSに任せる作り方があります。ただしチャットの設計そのものは論点が多いため、『チャットシステムの作り方』の記事に譲ります。

代表的な3つのサービス——Firebase、Supabase、AWS Amplify

BaaSと呼ばれるサービスは複数ありますが、日本の開発現場で提案書に載ることが多いのは次の3つです。いずれも2026年9月16日に公式ページで内容を確認しました。

3つの違いで発注者が気にすべき点をひとつ挙げるなら、データベースの種類です。Firebaseのドキュメント型データベースは、決まった形のデータを素早く出し入れするのが得意な一方、「複数の表を突き合わせて集計する」といった処理が苦手です。Supabaseは一般的なリレーショナルデータベース(PostgreSQL)なので、SQLで書ける集計はそのまま書けます。管理画面で売上を集計する、条件を組み合わせて検索する、といった要件が最初から見えているなら、この差は後から効いてきます。

AWS Amplifyは、名前こそひとつのサービスですが、実体は Amazon Cognito(認証)、AWS AppSync(API)、Amazon DynamoDB(データ)、AWS Lambda(関数)、Amazon S3(ストレージ)といった個別のサービスを束ねて使う構成です(2026年9月16日・公式の料金ページで確認)。すでにAWSでインフラを持っている企業なら、同じ請求と同じ権限管理の中に収められる利点があります。

「バックエンドがゼロになる」わけではない——残る仕事

ここで誤解を解いておきます。BaaSを使えばバックエンドの仕事がなくなる、という説明を見かけますが、実際には残る仕事があります。

• データ設計——どんな形でデータを持つか。BaaSは保管場所を貸すだけで、設計は利用者側の仕事です。ここを誤ると、後述する費用の跳ね方に直結します
• 権限のルール——誰がどのデータを読み書きできるか。BaaSはこれを設定ファイルとして書かせる方式が一般的で、書き漏らすと全データが公開状態になります
• 画面とロジック——アプリの本体は当然作ります
• テストとリリース——動作確認、ストアへの申請、リリース後の監視
• 課金の管理——従量課金なので、使用量を誰かが見ている必要があります

つまりBaaSが省くのは「サーバーを立てて動かし続ける工程」であって、「何をどう作るかを決める工程」ではありません。ここを混同したまま「BaaSだから安く速くできる」と見積もりを鵜呑みにすると、設計の甘さがそのまま残ります。省けるのは作業であって、判断ではないのです。

向くアプリと向かないアプリ、そして費用が跳ねる3つの条件

BaaSを使うべきかどうかは、アプリの性質でほぼ決まります。そして採用した後にいちばん多い事故は、機能不足ではなく請求額です。ここでは向き不向きを条件で並べたうえで、費用が跳ねる条件を公式の料金情報に照らして具体的に示します。金額そのものより、どういう作りのときにどう増えるのかを押さえてください。

向くアプリ4つ——検証段階、社内ツール、標準的な機能で足りるもの、小さく始めたいもの

仮説検証のために最小限の機能で出す進め方そのものは『MVP開発とは』の記事にまとめてあります。また、コードをほとんど書かずに作る手段としてノーコードもありますが、こちらは『ノーコードとは』の記事の領域です。BaaSは「コードは書くが、裏側は書かない」という位置にあると考えると、両者の違いが見えます。

向かないアプリ4つ——複雑な集計、厳しい要件、大量の同時書き込み、既存システムとの密な連携

ゼロから作るか、既製のものを組み合わせるかという大きな選び分けは『スクラッチ開発とは』の記事で5分類に整理しています。BaaSはその中間、「土台は既製、上物は自作」という位置づけです。

費用が跳ねる3つの条件——読み取り回数、保存し続けるデータ、外へ出る通信

BaaSの料金は従量課金です。無料枠が用意されており、そこに収まるうちは無料ですが、超えると使った分だけ請求されます。まず無料枠の実数を見てください(いずれも2026年9月16日に公式の料金ページで確認)。

超えた場合の単価は次のとおりです。

1USD=150円換算目安で見ると、単価そのものは小さく見えます。跳ねるのは単価ではなく、回数と量です。跳ね方には型があり、当社が相談を受けてきた範囲では次の3つに集中します。

1. 一覧画面を開くたびに全件を読む作り。 読み取りは件数で数えます。100件の一覧を1回開けば100件の読み取りです。1日1,000回開かれれば10万件。Firebase Sparkの無料枠(50,000件/日)は昼過ぎに尽きます。画面の作り方ひとつで、桁が変わります
2. 消さないログと画像。 保存量は積み上がり続けます。削除も年限も決めないまま1年運用すると、保存料は毎月増える固定費になります。増えたことに誰も気づかないのがいちばん厄介です
3. 画像や動画を都度、外へ配信する作り。 外向き通信(エグレス)は、保存よりも単価が高い項目です。一覧画面にサムネイルを毎回フルサイズで出す、といった作りは、そのまま通信量に乗ります

見積もりの読み方——「開発費が安い」と「5年総額が安い」は別

BaaSを使った見積もりが他社より安く見えるのは事実です。ただし安くなっているのは初期の開発費であって、運用費は逆に読みにくくなります。私は2018年からホーチミンで約100社の開発体制を支援してきましたが、BaaSの採用で揉めるのは決まって2年目以降、利用者が増えたタイミングです。

発注前に確認すべきは1点、「想定利用者数のとき、月額はいくらになるか」を試算として出してもらうことです。出せない会社は、上の3条件を設計時に見ていません。金額そのものより、試算を持っているかどうかが判断材料になります。なお、システム開発全体の費用相場は『アプリ開発・システム開発の費用相場』の記事にまとめてあります。参考までに、当社のラボ型の最小構成は日本人PMフロント+2〜3人月で月額約80万円からですが、これは人の費用であり、BaaSの利用料とは別建てです。

いま自社で企画しているアプリについて、上の3条件にいくつ当てはまるかを数えてみてください。2つ以上当てはまるなら、無料枠の範囲で判断してはいけません。

ベンダーロックインと移行の難しさ——BaaSから自前バックエンドへ移る判断

「とりあえずBaaSで始めて、大きくなったら自前に移せばいい」。この考え方で始めた案件を、私は何度も見てきました。方針としては合理的です。ただし、移る段になって想定より難しいことが分かる。難しさは技術力の問題ではなく、どこに何が引っかかるかを先に知っていたかどうかの問題です。ここを先に書いておきます。

ロックインの正体は3つ——データの形、認証の持ち方、サービス固有の書き方

ベンダーロックインとは、特定の事業者のサービスに依存してしまい、他へ移りにくくなる状態のことです。BaaSの場合、その正体は次の3つに分解できます。

このうち、実務でいちばん詰まるのは認証です。データは時間をかければ移せますし、コードは書き直せます。しかし利用者のパスワードは、移行先で「そのまま使える形」にできないことがあります。そうなると、全利用者にパスワードの再設定を依頼することになる。アプリの利用者数が数万人規模になっていれば、これは事業上の意思決定です。技術の話として始まった移行が、途中から広報とカスタマーサポートの話になります。ここを甘く見るのが失敗のもとです。

移行が要るかを判断する5つの問い

移行は目的ではありません。必要がなければしないほうがよい。次の5つに答えてみてください。

1〜3のどれかが「はい」で、かつ4と5がともに「はい」なら、移行を検討する段階です。1〜3がすべて「いいえ」なら、いま移す理由はありません。4か5が「いいえ」なら、移行を決めても完走できない可能性が高い。移行は、動いているものを止めずに作り替える作業なので、通常の新規開発より人と時間を要します。

移すと決めた場合の順番——止めずに移す3段階

一度に全部を切り替える方法は勧めません。当社が継続開発を担当している介護記録SaaS「CareViewer」では、日本語のできるブリッジSE1名とフルスタックエンジニア2名の体制で、週次で優先順位を判断しながら開発を進めています。稼働中のサービスに手を入れる場合、この「週次で順番を決め直せる」体制があるかどうかが、そのまま成否を分けます。順番としては次の3段階です。

1. 読み取りを自前のAPIへ寄せる。 アプリが直接BaaSを読みに行っている箇所を、自社のAPI経由に置き換えます。この段階ではデータの置き場所は変えません。アプリ側の改修だけで済み、失敗しても戻せます
2. 書き込みを二重化する。 新しいデータを、BaaSと移行先の両方へ書きます。一定期間並走させ、両者の内容が一致することを確認します。過去データもこの間に移します
3. 認証を移す。 最後に認証を切り替えます。パスワードの扱いを事前に確認し、再設定が必要なら告知と問い合わせ対応の準備を済ませてから実施します

当社には、決済アプリ(Stripeによる決済、二要素認証、ウォレット、PDF出力)を新規開発から週次の保守体制へ移した実績があります。動いているものを止めずに手を入れる仕事は、新規開発とは別種の慎重さが要ります。

最後に、移らなくてよい条件も書いておきます。利用者数が横ばいで、機能の壁にも要件の壁にも当たっておらず、月額の利用料が数千円の水準にとどまっているなら、移行を検討する必要はありません。動いているものを触るのは、それ自体がリスクだからです。

もうひとつのBaaS——Banking as a Service(銀行機能をAPIで提供する仕組み)

ここまでは Backend as a Service の話でした。冒頭で触れたとおり、BaaSにはもうひとつ Banking as a Service という意味があります。金融の文脈でこの語を見た方のために、ここで独立して説明します。はじめにお断りしておくと、私は金融の専門家ではありません。以下は金融庁が公表している資料で確認できた範囲の一般的な説明であり、法的な助言ではありません。個別の事業が登録や許可を要するかどうかは、必ず弁護士等の専門家にご確認ください。

Banking as a Serviceとは——銀行がライセンスと機能を、他社のサービスに貸す

Banking as a Service とは、銀行が持つ機能(口座の開設、残高の照会、入出金、送金など)を、APIを通じて銀行以外の事業者が自社サービスに組み込めるようにする仕組みを指します。

利用者から見ると、小売店のアプリの中で残高を確認したり、支払いを済ませたりできる。その裏側では銀行の機能が呼ばれている、という構造です。事業者側は銀行免許を取らずに金融的な機能を提供でき、銀行側は自行のアプリを使ってもらう以外の接点を得られる。この考え方は「組込型金融(エンベデッド・ファイナンス)」とも呼ばれます。

先ほどの Backend as a Service と並べると、違いがはっきりします。

日本の制度ではどこに接するか——電子決済等代行業(2018年6月1日施行)

日本でこの仕組みに関わる場合、避けて通れないのが銀行法上の位置づけです。金融庁の「主要行等向けの総合的な監督指針」(Ⅹ 電子決済等代行業)によれば、電子決済等代行業者の登録制度は平成30年(2018年)6月1日に施行されました。根拠は「銀行法等の一部を改正する法律」(平成29年法律第49号)で、フィンテック企業と銀行のオープン・イノベーションを推進する目的で導入されたものです。参照条文は銀行法第52条の61以下とされています。

電子決済等代行業とは、おおまかに言えば、利用者と銀行の間に立って、利用者の指図を銀行へ伝えたり、利用者の口座情報を取得して提供したりする事業のことです。国内でこれを営むには、銀行法等に基づく登録が必要になります。申請の窓口は、主たる営業所の所在地を管轄する財務局で、国内に営業所がない場合は関東財務局とされています(金融庁「電子決済等代行業を営むみなさまへ」・2026年9月16日確認)。登録を受けた事業者の一覧は、金融庁が公表しています。

同じ監督指針は、監督上重視する点として次を挙げています。

• システムリスク管理態勢——システムの停止、誤作動、サイバー攻撃への備え。障害が発生した場合は直ちに報告し、その後も進捗を報告することが求められる
• 利用者保護——連携する銀行との役割分担を明確にし、不正防止策とモニタリング態勢を整えること(参照条文として法第52条の61の8、同61の10が挙げられている)
• 不正取引が起きた場合の補償——補償方針を策定して公表し、迅速に対応できる態勢を整えること

登録の要件自体は他の金融規制に比べて重くない設計になっている一方、システムと利用者保護の態勢は厳しく見られる、という構造です。「APIをつなぐだけ」という規模感で始められる話ではない、と理解しておくのが妥当だと考えています。

開発の相談として来る場合の注意——2つのBaaSを混ぜない

実務で困るのは、この2つが会話の中で混ざるときです。「BaaSでアプリを作りたい」という相談が、実は「自社アプリに送金機能を載せたい」という金融側の話だった、ということが起こります。逆に、金融の担当者が Firebase の記事を読んで「BaaSは安い」と理解してしまう場合もあります。

見分け方は単純です。登場人物に銀行がいるかどうか。銀行が出てくるなら Banking as a Service の話で、開発会社より先に相談すべき相手は銀行と金融法務の専門家です。銀行が出てこないなら Backend as a Service の話で、開発の要件として扱えます。

ここから先は、再び Backend as a Service の話に戻ります。

BaaSで作ったものを引き継ぐ・移すときの体制——当社の位置づけと、BaaSで十分なケース

最後に、すでにBaaSで動いているものをどうするか、という話をします。当社への相談で近年増えているのがこの領域です。先に結論を書くと、引き継ぎで最初に見るのはコードではありません。契約と権限です。そしてもうひとつ、率直に書いておきたいことがあります。相談を受けても「そのままでよい」とお答えする場合が、実際にあります。

引き継ぎで最初に確認する3つ——アカウントの名義、請求先、権限

BaaSで作られたアプリは、クラウドのアカウントごと引き渡してもらわないと動かせません。ソースコードだけを受け取っても、データも認証情報もアカウントの中にあるからです。最初に確認するのは次の3点です。

名義が前の会社のままだと、契約終了の交渉と技術の引き継ぎが同時進行になり、話が止まります。これは技術の問題ではなく取り決めの問題なので、発注時に決めておけば起きません。開発会社を替える場面全般の手順は『開発会社の乗り換えと引き継ぎ』の記事にまとめてあります。

上記3点が整ったうえで、実際に受け取るのはアクセス権限のほか、データベースの権限ルール(セキュリティルール)の設定、環境変数と各種キー、サーバーレス関数のソースコード、データのエクスポート手段の5つです。これらが揃わないまま「引き継ぎ完了」とされている案件は珍しくありません。

当社の担い方——日本人PMフロントのラボ型で、保守と移行を同じチームが持つ

当社はホーチミンを拠点に、2,000名以上のIT人財データベースから直接アサインする形でチームを組成しています。協力会社を経由しないため、仲介マージンは発生しません。体制は日本人PM/ブリッジSEをフロントに置くパターンAを推奨しており、1名から、最短2週間で開始できます。増員は約1週間、縮小や交代は1か月単位です。日本とベトナムの時差は2時間なので、日中の時間帯がほぼ重なります。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

品質面では、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点を標準としています。クラウドについてはAWS認定11冠の体制があります。既存のアプリを引き継いで保守する場合も、移行を判断して実行する場合も、同じチームが継続して担当する形をとっています。保守と移行を別々の会社に分けると、「移すべきか」の判断と「移す作業」の責任が割れるためです。改修・保守を外注する場合の費用や頼み先の選び方は『システム改修・開発保守の外注』の記事に整理があります。

最小構成は日本人PMフロント+2〜3人月で月額約80万円からです。公開している単価は実務3年目安で1,500USD(約22.5万円)、5年で2,000USD、10年以上およびブリッジSEで3,000USD(1USD=150円換算目安)。BaaSの利用料はこれとは別に、お客様のアカウントから直接お支払いいただく形を標準にしています。アカウントの名義と最上位の権限は、お客様側に残していただきます。

率直に言って、BaaSで十分なケース——相談されても「そのままでよい」と答える場合

売り込みにならないよう、はっきり書いておきます。次の4つがすべて当てはまる場合、当社は「いまは何もしないほうがよい」とお答えしています。

1. 利用者数が横ばいで、増える見込みが具体的にない
2. 標準機能で足りており、「構造上できない」と言われた機能がない
3. 月額の利用料が数千円から1万円台の水準にとどまっている
4. その事業を続ける期間が、あと1〜2年の見込みである

この状態で自前バックエンドへ移せば、移行の費用と期間がかかり、その後は保守の人件費が固定的に乗ります。得られるのは自由度ですが、使う予定のない自由度にお金を払うことになります。約100社の相談を受けてきて、BaaSのまま続けるのが最善だった案件は確かにあります。判断材料をお渡しして、そのままお帰りいただくこともあります。その代わり、上の4つのうち1つでも崩れたときには、早めに声をかけてください。崩れてから動くと、選べる手段が減ります。

【FAQ】BaaSに関するよくある質問

BaaSについて、相談の場で実際に聞かれることの多い5つの質問に答えます。いずれも本文で扱った内容の要点ですが、社内で説明する際にそのまま使える形にまとめました。金融側の質問については、法的な助言ではない点を重ねてお断りしておきます。

Q1. BaaSを一言で説明すると何ですか

アプリの裏側(認証、データ保管、ファイル置き場、通知など)を、自前でサーバーを立てずに借りる仕組みです。ただし同じ略語で、銀行の機能をAPIで他社に提供する Banking as a Service を指す場合もあります。文脈に銀行が登場するかどうかで、どちらの話かを見分けられます。

Q2. BaaSとPaaSの違いは何ですか

PaaSはアプリを動かすための土台を貸すもので、その上で何をどう作るかは利用者が決めます。BaaSはPaaSの一種ですが、アプリ開発で毎回必要になる部品(認証、データベース、ストレージ、通知)をあらかじめ組にして貸す点が違います。用途が絞られているぶん、出来合いの度合いが高いということです。IaaS・PaaS・SaaSの区分そのものは、別記事に整理があります。

Q3. Firebaseは無料で使い続けられますか

無料プラン(Spark)の枠内に収まっているかぎりは使えます。枠は2026年9月16日時点で、Cloud Firestoreが保存1GiB・読み取り50,000件/日・書き込み20,000件/日、Cloud Storageが保存5GB・ダウンロード1GB/日、Authenticationが50,000 MAUまでです。これを超える利用が見込まれる場合は、従量課金のBlazeプランへ切り替えることになります。日次の上限がある項目は、利用者が増えた日にその日だけ止まる、という形で表面化します。

Q4. BaaSで作ると、後で作り直しになりますか

必ずしもなりません。利用者数が横ばいで、機能の壁にも要件の壁にも当たっていないなら、そのまま続けるのが合理的です。作り直しが必要になるのは、費用の伸び、機能の限界、監査や保存年限といった要件の追加のいずれかが起きた場合です。発注時に備えておくべきは、作り直しの計画ではなく、クラウドアカウントの名義と最上位の権限を自社側に置いておくことです。

Q5. 銀行のBaaS(Banking as a Service)を使うには登録が必要ですか

事業の内容によります。利用者と銀行の間に立って指図を伝えたり口座情報を取得したりする事業は、銀行法上の電子決済等代行業にあたり、登録が必要とされています(制度は2018年6月1日施行)。自社の企画がこれに該当するかは、金融庁の公表資料を確認したうえで、銀行および金融法務の専門家への相談が必要な領域。

まとめ: BaaSは「バックエンドを借りる」仕組み——速さの代償は、作りを決められないことと、出にくくなること

BaaSという略語には、まったく別の2つの意味があります。①Backend as a Service は、認証・データベース・ストレージ・プッシュ通知・サーバーレス関数といったアプリの裏側を、自前でサーバーを立てずに借りる仕組み。FirebaseやSupabase、AWS Amplifyがこれにあたります。②Banking as a Service は、銀行が自社の機能をAPIで他社のサービスに組み込めるようにする金融の仕組みで、日本では利用者と銀行の間に立つ事業が銀行法上の電子決済等代行業として登録制になっています(制度は2018年6月1日施行)。見分け方は、登場人物に銀行がいるかどうか。この2つに技術的なつながりはありません。

Backend as a Service で押さえるべきは一点、借りた範囲は自分では作り変えられないということです。そこから2つの結果が出ます。ひとつは費用。従量課金なので、作り方しだいで請求が動きます。Firebaseの無料プランはCloud Firestoreの読み取りが1日50,000件まで、Supabaseの無料プランはデータベース500MBまで、Proプランは月25USDで8GBまで(いずれも2026年9月16日に公式ページで確認)。跳ねる型は3つで、一覧を開くたびに全件を読む作り、消さないログと画像、画像や動画を都度配信する作りです。もうひとつは移行。ロックインの正体はデータの形・認証の持ち方・サービス固有の書き方の3つで、実務でいちばん詰まるのは認証です。移すなら、読み取りを自前APIへ寄せる、書き込みを二重化する、最後に認証を移す、の3段階で。

そして、BaaSで作られたものを引き継ぐとき、最初に見るのはコードではありません。クラウドアカウントの名義、課金の請求先、最上位の権限の3つです。ここが前の開発会社の名義のままだと、ソースコードを受け取っても動かせません。技術の話に見えて、半分は取り決めの話。発注時に決めておけば起きない種類の問題です。開発会社を替える場面全般の手順は開発会社の乗り換えと引き継ぎに、専属チームを月額で持つラボ型という契約形態そのものはラボ型開発とはにまとめてあります。当社はホーチミンを拠点に、日本人PMをフロントに置いたラボ型で、BaaS製アプリの保守と、必要になった場合の移行を同じチームが担う形をとっています。1名から、最短2週間で開始でき、最小構成は日本人PMフロント+2〜3人月で月額約80万円から。クラウドアカウントの名義と最上位の権限はお客様側に残す形を標準にしています。ただし、利用者数が横ばいで機能の壁にも当たっておらず、月額が数千円の水準にとどまっているなら、そのまま続けるのが最善です。現在の体制と要件をお聞かせいただければ、続けるか移すかの判断を含めて概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。