業務で使うノーコード型データベースの全体像と選定基準

2026年9月17日 ・ 朝倉 凛

• ノーコード
• 課金とライセンス
• セルフホスト
• オープンソース

対象はAirtable、Notion、Baserow、Glide、NocoDBに限る。 価格と仕様は各社の一次資料に基づく。 資料に無い事項は推測せず、文言と数値だけを扱う。

どこまでを「データベース」とみなすか

業務で扱う範囲は、表形式のデータを作り、ビューやフォームで入出力し、権限で制御する道具だと定義する。 この定義に素直に当てはまるのはAirtableとBaserowとNocoDBである。 Notionは文書とデータベースを一体で扱う基盤で、文書機能が前提にあると資料から読み取れる。 Glideはデータ格納とUI生成を合わせてアプリとして配布する前提が強い。

この違いは費用設計と上限の現れ方に影響する。 座席数で費用が動く製品と、行数やストレージや実行量で頭打ちが来る製品で、構築の作法が変わる。 自社の配布形態と編集者の分布を先に決めておくと判断が容易になる。

料金設計と無料枠の違いを一次資料で比べる

座席課金か利用量上限か、その混合かが分岐点になる。 以下は資料本文に記された課金単位と代表的な数値だけを並べる。 価格と通貨は資料の記載を写す。

Airtableは有料プランでも読み取り専用やフォーム送信が費用に含まれないと資料は述べる。 Baserowは行数とストレージとオートメーションをワークスペース単位で明示している。 Glideはプロジェクト数や公開アプリ数とクレジットが前面に出る設計である。 NocoDBは価格表ではなく機能ドキュメントが中心で、自己ホストの前提が伝わる。

表現の差が実務で効いてくる箇所

資料の文言差が契約や設計に波及しやすい箇所を挙げる。 いずれも一次資料の書きぶりが根拠であり、機能の優劣の話ではない。 解釈が割れると、費用や配布方式の見積もりがずれる。

• 編集者と閲覧者の線引きは費用に直結する。 Airtableは有料プランでも読み取り専用の共同編集者やフォーム送信や共有リンクは課金対象外と記している。 閲覧主体の配布では費用予測が立てやすいが、全員が編集する運用では座席費用が積み上がる。

• 上限の単位はテーブルではなくワークスペースに付く場合がある。 Baserowは行数とストレージとオートメーションの上限をワークスペース単位で示している。 テーブルを分割しても同一ワークスペースなら合算される前提で積算すべきである。

• 実行量を示す「クレジット」は配布形態に影響する。 Glideはクレジットと公開アプリ数とプロジェクト数に上限があると記す。 利用者数の増減だけでなく、アプリの切り方で消費が変わるため、設計段階で配布構成を固定できると安定しやすい。

• 「データベース」という語の内実が製品で揺れる。 Notionは文書とデータベースを同じワークスペースで扱う旨を記載している。 行数や同時実行の数値上限は資料抜粋では示されていないため、規模要件が堅い案件は事前検証を挟むのが安全である。

用途別に選ぶ判断と留保

判断は編集者の数、配布形態、必要な上限の明示度、運用体制の四つに分解できる。 座席課金は編集者の少なさが武器になり、利用量上限は見積もりの透明性が武器になる。 自己ホストは自由度と可用性の責任が交換条件になる。

最後に、どれを選んでも見直しの余地を残す契約にしておくと安全である。 座席数や行数やクレジットのどれがボトルネックになるかは、実データと運用でしか見えてこないことがある。 資料に明記された上限と課金単位を契約文書に写し込むと、後日の解釈違いを減らせる。