AirtableとGlideで比べるノーコード型データベースの料金設計
この話題の全体像は 業務で使うノーコード型データベースの全体像と選定基準 にまとめている。
ノーコード型の「データベース」に含める範囲を決める
表形式のデータを持ち、権限を付けて共同編集したいとき、AirtableとGlideは候補に挙がる。 両者は設計思想が異なるが、どちらもコードを書かずにデータに基づくアプリやワークスペースを組める。 この記事は料金と課金単位に焦点を当て、一次資料に書かれた事実から、どのような使い方に向くかの前提を固める。 日々の運用コストは課金の粒度で決まり、設計の自由度にも直結するためである。
AirtableとGlideの料金記述を読み解く
Airtableの資料は、課金の基本が席課金であると記している。 有料のTeamやBusinessでは、少なくとも一つのベースに編集権限を持つユーザーが課金対象で、閲覧専用の協力者とフォーム投稿と共有リンクは課金対象から外れるとしている。 月の途中で追加した編集者は日割り、企業向けのBusinessとEnterprise Scaleでも、編集権限を持つユーザー数に基づいて請求されるという扱いは同じだ。 Enterprise Scaleでは組織単位とワークスペースとベースを無制限に作成できる能力が含まれると書かれている。
料金水準について資料は、Freeは無償で、Teamは年払いの場合に1ユーザーあたり月額20ドルと記している。 Freeは個人やとても小さなチームや軽い用途を想定した構成だと説明され、有料プランは規模と管理機能を拡張する位置づけだと述べられている。 これらの記述は一次資料に基づく。 数値は将来変わり得るため、最新の料金表の本文を必ず確認してほしい。
Glideの資料は、Freeが月額0ドルでクレジットに制限があり、チームメンバー2人とプロジェクト10件が含まれると記している。 Basicは月額25ドルで100クレジット、チームメンバー2人、公開アプリ2件、有効化できるワークフロー1件とされる。 Plusは月額50ドルで250クレジット、チームメンバー3人、公開アプリ5件、プロジェクト20件、有効化できるワークフロー5件が含まれると書かれている。 Proは月額125ドルで開始し、5人以上のチームを前提に、メンバー1人あたり50クレジットを含み、公開アプリとワークフローは無制限、組織ロールやプレミアム連携やサポートが付くとされる。
Enterpriseは問い合わせベースで、シングルサインオンやエンタープライズ連携やバックアップや担当者の支援などの記述が並ぶ。 資料はAI機能の構築やエージェント関連の選択肢にも触れているが、課金の核はチームメンバー数とプロジェクトや公開アプリの上限とクレジットの三要素であると読み取れる。 なお、クレジットの消費単位や対象処理の詳細は、引用部分には明記がない。
課金単位と上限が設計に与える影響
Airtableは編集できる人を何人にするかで費用が決まる。 閲覧専用の共有やフォーム投稿はTeamやBusinessで課金対象外と資料が明言しており、編集者と閲覧者を分ける運用ほど費用が読みやすくなる。 編集者を増やした瞬間からの課金は日割りになるため、短期の編集が多い現場でもコストの見逃しを抑えやすい。 Enterprise Scaleは容器の数を無制限に広げられるが、費用の決定要因はあくまで編集権限にある点は変わらない。
Glideはメンバー数とプロジェクト数と公開アプリ数がプランごとに固定され、クレジットが利用量のふたになる。 複数の小さなアプリを配布する構想では、Plusの公開アプリ上限やプロジェクト総数が設計の制約になる。 Proで公開アプリとワークフローの上限が外れる一方、チーム人数の下限とクレジットの単価感が予算の土台になる。 クレジットが何にどれだけ減るかの細目は、今回の引用にはないため別途の一次資料で確認が要る。
同じ「外部に見せる」でも、Airtableは共有リンクの閲覧やフォームが課金外、Glideは公開アプリ数の上限があるという違いがある。 この差は、外部公開をどれほどの単位で行いたいかに応じて利点と不利が入れ替わる。 上限の枠組みが違うため、設計の早い段階で公開方法と編集の導線を決めておくと、後戻りのコストを抑えられる。
用途ごとに選び分ける判断材料
多数の閲覧者と少数の編集者で運用するなら、Airtableの「閲覧専用は課金外」という扱いが効く。 フォームでの受け付けが多い場面でも、TeamやBusinessで追加費用が発生しにくい構造は読みやすい。 一方で、編集者が増減を繰り返す運用では日割りの効果が働くが、増員のたびに費用が跳ねる点は予算管理に組み込む必要がある。 Enterprise Scaleの容器無制限は組織運用の自由度を上げるが、費用の鍵は編集者数だと理解しておく。
小さく作って素早く配布するやり方を重ねるなら、GlideのPlusの上限に早く達するかを見積もっておきたい。 多数の公開が前提ならProの「公開無制限」を起点に、必要なチーム人数とクレジット量を乗せる形で検討するのが現実的だ。 AI機能やワークフローをどの程度使うかでクレジットの消費が変わる可能性があるが、今回の引用だけでは計算できないため、必ず公式の説明を突き合わせる。 EnterpriseのSSOや連携の記述は、組織の要件が厳しい場面での候補になり得る。
最後に、数値と条件は一次資料に記された内容であり、将来の変更を前提に設計を固定しないことが安全だ。 費用の見積もりは、料金ページ本文の「誰に課金されるか」と「何が上限か」を原文で確認し、運用の実務に落とすところまで行う。 その上で、無料枠は試作の速度を上げる道具と捉え、本番の課金単位に合わせた設計へ早めに寄せていく。