比較

Busabase と Firebase：AI エージェントに使わせるならどちらか

Firebase は、モバイルアプリや Web アプリに Google Cloud 上のマネージドなバックエンドを提供します。Busabase は、エージェントとチームに共有のワークスペースを提供します。ビジュアルなデータテーブル、チームのナレッジベース、スキル、アプリ。そしてエージェントの変更はすべて、読んで、レビューして、取り消せるチェンジリクエスト（Change Request）になります。「エージェントが業務のためにした仕事をどこに置くか」が問いなら、Busabase は初日から答えを出します。

Firebase のエージェント向けツールは、コーディングエージェントが Firebase アプリを作り、運用するのを手助けするのが得意です。Busabase が受け持つのは、エージェントの仕事のもう半分、つまり毎日生まれるレコード、ドキュメント、判断です。両方使うチームも多いはずなので、このページではやりたい仕事ごとに比べます。

最終確認日：2026 年 11 月 13 日。Firebase の料金ページ、Firestore・MCP サーバー・エージェントスキルのドキュメント、Firebase 公式ブログ、および現行の Busabase をもとにしています。

結論を先に

Busabase を選ぶのは

エージェントの成果物を、チームが読み、確かめ、次の仕事に使う場合。顧客レコード、リサーチ、コンテンツ、業務ドキュメント、スキルなど。すべての変更に履歴が残り、非エンジニアにも見えるビューがあり、その上にアプリも作れる。しかも先にバックエンドを書く必要はありません。

Firebase を選ぶのは

モバイルアプリや Web アプリを出していて、そのバックエンドが必要な場合。ユーザー認証、オフライン同期つきのリアルタイムデータベース、プッシュ通知、アナリティクス、クラッシュレポートを、Google Cloud の規模で。

両方使うのは

アプリは Firebase で動かし、エージェントはその周りで働く場合。営業、コンテンツ、サポート、運用。エージェントの成果は Busabase に、アプリのユーザーデータは Firebase に置きます。

いちばんの違い：すべての変更がチェンジリクエスト

Busabase は、あらゆる編集をデータのプルリクエストとして扱います。レコードの追加、ドキュメントの書き直し、スキルのファイル修正、スキーマ変更。どれもチェンジリクエストで、変更不可能なコミットの連なりを持つブランチです。マージするとレコードは先に進み、以前の版もそのまま残ります。

Firebase はデータを「入口」で守ります。Firestore セキュリティルールがアプリからのリクエストを一つずつ確認し、許可するか拒否するかを決めます。サーバー用ライブラリはルールを通らず、IAM で認可されます。書き込みが通れば、ドキュメントには新しい値だけが残ります。以前の状態に戻すには、過去 7 日以内の時点を復元するか、バックアップから復元することになり、どちらも新しいデータベースへの復元です。ドキュメント 1 件の 1 回の変更だけを戻す仕組みではありません。

  • 書き込みが自分を説明する。変更ごとに説明とフィールド単位の前後があり、レビューする人は何が動いたかをすぐに把握できます。
  • すべての変更に名前が残る。作成者と、経由したエージェントのキーやツールが、コミットにずっと残ります。
  • 戻すのは 1 つの変更だけ。レコード、ドキュメント、スキルは履歴をすべて保持し、どの変更も単独で巻き戻せます。データベース全体を戻す必要はありません。
  • レビューするかはあなたが決める。書き込み権限があれば即座にマージ。エージェントに「提案のみ」のキーを渡せば何も反映できず、変更は受信箱で人の承認か差し戻しを待ちます。
レビュー中の Busabase のチェンジリクエスト。変更の説明、レコード本文の変更前後の差分、「承認」「修正を依頼」のボタン
Busabase の受信箱に届いたチェンジリクエスト。説明、誰がどのツールで提案したか、フィールドの変更前と変更後。そのまま承認も差し戻しもできます。

エージェントをデータに「近づける」ことと、データの上で「働かせる」ことの差はここにあります。Busabase では、エージェントのどの変更も見えて、誰のものか分かり、元に戻せます。

Busabase がエージェントとチームに用意するもの

Firebase のようなバックエンドでは、以下はどれも自分で設計し、コードを書き、ホストするものです。Busabase ではワークスペースに最初から含まれています。

ビジュアルなデータテーブル

どの Base もテーブル、ギャラリー、カンバン、カレンダー、ガントチャートで開けます。ビューを保存し、AND/OR フィルタを組み合わせれば、コンソールもクエリもなしに、誰でもエージェントの成果を確認できます。

チームのナレッジベース

方針を書いたドキュメント、エージェントが作ったファイル、レコードを持つ Base が、1 つのツリーに並びます。人とエージェントが共有し、権限もひとつです。

すべてを grep

1 回の正規表現検索で、ファイル、ドキュメント本文、レコード、エージェントプロンプトを横断し、一致箇所を行番号と前後の文脈つきで返します。エージェントが根拠を探す最短ルートです。

スキルをアップロード

チームのスキルを一度ワークスペースに置けば、接続したすべてのエージェントが同じ版に従います。スキルの編集もチェンジリクエストなので、誰がルールを変えたかが分かります。

4 つのエンジンで動くアプリ

エージェントにデータを使った AirApp を作らせ、ブラウザ、手元のマシン、クラウドサンドボックス、常時公開の Web サイトのいずれかで動かせます。

独自ドメインの Web サイト

Website エンジンは Cloudflare Workers 上で動き、バックエンドのエンドポイントを持て、独自ドメインで公開できます。サイトを作ったエージェントが、プレビューも公開も担当できます。

チームのために

メンバーは閲覧・書き込み・管理のロールで招待し、エージェントには仕事に必要な権限までに絞ったキーを渡します。権限はノード単位でもキー単位でも設定できます。

数分でエージェントを接続

MCP、CLI、OpenAPI の REST API、Webhook、そして Claude Code と Codex 向けプラグイン。同梱のスキルが、ワークスペースの構成をエージェントに伝えます。

データを置きたい場所に

MIT ライセンス。ノート PC でも、自社サーバー（完全オフラインを含む）でも、Busabase Cloud でも動き、スペースは Markdown、Base 定義、JSON レコードといった普通のファイルに書き出せます。
Busabase の Base。エージェントが書いたブログ記事がタイトル、カバー画像、本文の列を持つテーブルで表示され、「公開待ち」「下書き」などの保存済みビューがある
エージェントが書いた記事を収めた Busabase の Base。チームの誰もが読んで直せ、「公開待ち」のような保存済みビューで同じレコードを絞り込めます。

やりたい仕事で比べる

各行は、チームが実際にこれらの製品に持ち込む仕事です。Firebase の本領は独立した 1 行にし、Firebase を使うべき場面ははっきりそう書いています。

やりたいことBusabaseFirebase
何が、どう変わり、誰が変えたかを見る標準搭載：チェンジリクエストにフィールド単位の差分、作成者、エージェントのキー、履歴、取り消しドキュメント単位では残らない。書き込みはドキュメントを置き換える。PITR（最長 7 日）とバックアップは新しいデータベースへの復元
特定のエージェントには提案だけさせるできる：「提案のみ」のキーで、変更は受信箱でレビュー待ちにデータ層では不可。セキュリティルールはクライアントのリクエストを許可か拒否するだけで、サーバー用ライブラリはルールを通らない
エージェントが書いた内容をチームが見て直すできる：テーブル、ギャラリー、カンバン、カレンダー、ガント。クエリ不要Firebase コンソールの Firestore データビューアとクエリビルダー。開発者向け
メンバーとエージェントを同じワークスペースにできる：メンバーは閲覧・書き込み・管理の 3 ロール。エージェントは自分のキーで参加コンソールと API にアクセスする、IAM ロールつきのプロジェクトメンバー
チームのナレッジベースを運用するできる：ドキュメント、ファイル、Base が同じツリーで権限も共通ファイルは Cloud Storage。ドキュメントはない
すべての中から正確に文字列を探すできる：ファイル、ドキュメント本文、レコード、エージェントプロンプトを 1 回の正規表現 grep で横断自分のコレクションへのクエリ。全文検索は Firestore Enterprise エディションでプレビュー中
全エージェントに同じチームのスキルをできる：一度アップロードすれば、接続したすべてのエージェントが同じ版を読む製品機能ではない（Firebase のエージェントスキルは Firebase での開発方法を教えるもの）
アプリ開発なしで、データを社内ツールにするできる：エージェントが AirApp を作り、ワークスペース内でそのまま開けるアプリを自分で（またはコーディングエージェントで）書いてデプロイする
同じデータでサイトを公開し、独自ドメインで出すできる：Cloudflare Workers 上の Website エンジン、独自ドメイン対応（Cloud は Plus 以上）できる：Hosting と App Hosting は独自ドメイン対応。サイトのコードは自分で書く
Claude Code、Codex、Cursor などを接続できる：MCP、CLI、OpenAPI、Webhook、プラグインできる：ローカルの MCP サーバー、エージェントスキル、プラグイン。用途は Firebase プロジェクトの構築と運用
請求額を事前に読める席単位の定額、従量の超過料金なし無料枠を超えると従量課金。利用上限（spend caps）はパブリックプレビューで、ハードキャップではない
セルフホスト（オフライン含む）できる：MIT。ノート PC からエアギャップ環境までできない：Google Cloud のマネージドサービス。Emulator Suite はローカルテスト専用
自社のモバイル・Web アプリのバックエンド：ユーザー認証、リアルタイム同期、プッシュ、分析担当外。Firebase を使うできる。Firebase の本領

次に来るもの

以下の 3 つは現在開発中で、まだ利用できません。計画の参考として載せており、リリース時にこのページを更新します。

アプリユーザー（App users） 開発中

公開したアプリを使う人（たとえばショップの顧客）が、メールのコードでサインインし、自分のレコードだけを見られます。プラットフォームが強制し、ワークスペースのメンバーにはならず、席も消費しません。

オントロジー 開発中

チームが扱う業務オブジェクト（会社、連絡先、商談）とそのつながりを、いまある Base の上に定義します。人とエージェントが同じ言葉で話せるようになり、その変更もチェンジリクエストで行います。

きめ細かな権限 開発中

Base 内の行・フィールド単位のアクセス制御、範囲と期間を限ったエージェントへの付与、人が承認するアクセス申請。仕事に必要な分を超える権限を持つエージェントはいなくなります。

Firebase のエージェントツールはアプリを作るため。Busabase はエージェントが働く場所

エージェントを迎え入れることにかけて、Firebase は多くのバックエンドより先を行っています。MCP サーバーは Antigravity、Claude Code、Cursor、VS Code Copilot などのクライアントで使え、エージェントスキルは Firebase のベストプラクティスを AI アシスタントに教え、プラグインがその両方を Claude Code、Codex、Cursor 向けにまとめています。コーディングエージェントはプロジェクトを作り、認証を設定し、最初のセキュリティルールを書き、デプロイまでできます。

これらはアプリを作り、運用するためのツールです。MCP サーバーは Firestore のドキュメントを読み書きすることもでき、そのツール呼び出しは「あなたの承認のもとで」行われます。つまり、呼び出しの瞬間にエディタで承認します。その後のドキュメントには新しい値があるだけで、なぜ変えたかの説明も、後から見返せる差分も、その 1 回だけを取り消す手段もありません。

アプリ自身のデータならそれで十分です。しかしエージェントが業務のためにする仕事、つまり顧客レコードの更新、コンテンツの下書き、業務ドキュメントやスキルの手入れでは、どのエージェントが何をなぜ変えたかを知り、1 つのミスだけを戻せる必要があります。Busabase は、すべての書き込みについてその記録を残します。

いまツールを選んでいるなら、もう一つ知っておく価値があります。プレビューとして提供されてきた AI 支援のフルスタック開発環境 Firebase Studio は 2027 年 3 月 22 日に提供終了となり、Firebase はエージェントによるアプリ開発の移行先として Google AI Studio と Antigravity を案内しています。Firestore や Authentication などのコアサービスには影響しません。

両方を組み合わせる

アプリを Firebase で動かし、その横でエージェントを走らせるチームのよくある分担です。

  1. アプリ本体（ユーザー、認証、リアルタイムデータ、プッシュ通知）は Firebase に置きます。
  2. サポートエージェントがユーザーのフィードバックを読み、Busabase の「フィードバック」Base に整理。プロダクトチームがカンバンで仕分けます。
  3. コンテンツエージェントが「コンテンツ」Base にリリースノートやストア掲載文を下書きし、編集者がそのチェンジリクエストを確認してから公開します。
  4. アプリに届けるべき内容は、あなたのコードが Busabase API で確定済みのレコードを読みます。または、エージェントが独自ドメインの AirApp Web サイトとして公開します。

Firebase はアプリをユーザーのために動かし続けます。Busabase はエージェントの仕事を、チームが読めて、誰のものか分かり、再利用できる状態に保ちます。

料金の概要

Busabase

Free：1 スペース、3 席、5,000 レコード、1 GB のファイル。スキル、ワークフロー、AirApp を含むすべてのノードタイプ。
Plus：1 席あたり月 10 ドルから（年払い）。Pro：20 ドルから。
席単位の定額で、従量の超過料金はありません。セルフホストは MIT で無料、席数の制限もありません。

Firebase

Spark：無料で、支払い方法の登録も不要。無料枠の範囲内で使えます。たとえば Firestore Standard は保存 1 GiB、1 日あたり読み取り 5 万回・書き込み 2 万回まで。
Blaze：従量課金。Spark の無料枠を含み、超えた分の多くは Google Cloud の料金で請求されます。条件を満たす新規アカウントは 300 ドル分のクレジットを受け取れます。
AI Logic、Cloud Functions、App Hosting の利用上限はパブリックプレビューで、Firebase はハードキャップではないと説明しています。

料金は 2026 年 11 月 13 日時点の公開情報です。最新の内容は Busabase の料金と Firebase の料金をご確認ください。

Firebase のほうが向いている場面

  • モバイルアプリや Web アプリを作っている。Authentication、リアルタイム同期とオフライン対応の Firestore、Cloud Functions、Cloud Messaging、Crashlytics、Analytics が、Android、iOS、Flutter、Unity、Web 向けの SDK でそろいます。Busabase はモバイルのバックエンドではありません。
  • クライアントアプリの中で Gemini を使いたい。Firebase AI Logic なら、自前のサーバーなしでモバイル・Web アプリから Gemini モデルを呼び出せ、Google Cloud のほかのサービスにもすぐ手が届きます。
  • 書き込みが機械的な規模である。イベント、テレメトリ、高頻度のアプリ更新は、アプリケーションのデータベースに置くべきです。

Busabase に現時点でできないことも明記します。リアルタイム購読、ベクトルインデックス、プッシュ通知やクラッシュレポート、アプリのスキーマのマイグレーション管理はありません。公開したアプリのエンドユーザー認証は開発中（アプリユーザー）で、まだ利用できません。いま必要なら、アプリは Firebase のままにして、Busabase をその横に置いてください。

よくある質問

Busabase は Firebase の代わりになりますか？
アプリのバックエンドとしては代わりません。代わるのは、エージェントの仕事を置くためにバックエンドの上へ追加で作るもの、つまり社内用の管理画面、共有ドキュメントのフォルダ、変更の追跡、そしてその上の社内ツールです。
Firebase の MCP サーバーでもう Firestore に書けます。なぜ Busabase を足すのですか？
書き込むのは半分にすぎないからです。Firebase の MCP ツールはエディタでの承認のもとで実行され、その後のドキュメントは新しい値になるだけです。Busabase では書き込みのたびに、説明、差分、作成者、取り消しを持つチェンジリクエストになり、チームはコンソールではなくテーブルで結果を確認できます。
チェンジリクエストはポイントインタイムリカバリと何が違いますか？
PITR は、データベースを過去 7 日以内のある時点に戻し、新しいデータベースとして復元するものです。チェンジリクエストは、説明と差分を持つ 1 つの変更です。反映前にレビューを待たせることも、ほかに一切触れずにそれだけを巻き戻すこともできます。
エージェントの書き込みはすべて人のレビューが必要ですか？
いいえ。書き込み権限があれば即座にマージされ、履歴が残ります。レビューは任意です。エージェントに「提案のみ」のキーを渡すか、変更をレビューに出すよう指示してください。
1 回の作業で Firebase と Busabase の両方に書き込めますか？
はい。自然な分担です。アプリの運用データは Firebase へ、リサーチ、レコード、コンテンツ、ドキュメントはワークスペースへ。
Busabase はセルフホストできますか？
できます。MIT ライセンスで、1 台のマシン、自社サーバー、エアギャップ環境で動きます。セルフホストのガイドをご覧ください。Firebase 自体はマネージドサービスで、Emulator Suite はローカルテスト用であり本番向けではありません。

次のステップ

いま使っているエージェントを接続し、Base で完結する本物の仕事を 1 つ任せてみてください。フィードバックの仕分けリスト、リリースノートの予定表、顧客テーブルなど。数分後には、チームが結果をテーブルで開き、エージェントの変更を一つずつ確認できます。

関連記事： Busabase の比較一覧 · Busabase と Supabase の比較 · Notion と Supabase のハイブリッドとしての Busabase · 各プラットフォームはエージェントの書き込みをどう扱うか · チェンジリクエストの仕組み · 検索と grep · AirApp を Web サイトとして公開する

出典： Firebase pricing, Firebase MCP server, Firebase agent skills, Get started with Cloud Firestore Security Rules, Firestore point-in-time recovery, Firestore scheduled backups, Introducing Firebase spend caps, Firebase Local Emulator Suite, Firebase Studio sunset and project migration, What’s new from Firebase at Cloud Next 2026, Busabase pricing