Airtable のデータ上限に達したとき、どうする？代表的な3つの対処法

最近、Airtable を使っているユーザーからこんな声をよく聞くようになりました。

チームが拡大し、データも増えてきた。そろそろ、もっとスケーラブルでコスパの良いツールに乗り換えるべきかも？

実際にコミュニティの投稿をいくつか見てみると、同じような悩みを持つ開発者は少なくありません。

あるエンジニアは「5万件の上限があるせいで、大量データを扱うプロジェクトが進まない」と話しています。

Airtable Data Limit

もちろん、Airtable は非常に優れたツールです。直感的で使いやすく、小規模チームにとっては十分な機能があります。

10人程度のチームであれば、コスト面でも運用の手軽さでも非常にバランスの取れた選択肢でしょう。

しかし、ビジネスの成長とともに、次第に限界を感じることも出てきます。

Airtable の料金プランは以下のとおりです：

pricing

Free：1ベースあたり1,000件まで
Team（$20／ユーザー／月）：5万件
Business（$45／ユーザー／月）：12万5,000件
Enterprise（要問い合わせ）：50万件

これらの上限は公式サイトに記載されていますが、実際にトラブルが起きてから気づく人も多いようです。

動作が遅くなったり、自動化が止まったり、新規データが登録できなくなって、ようやく「上限に達した」と実感するパターンもよくあります。

もしあなたも同じような状況なら、次のような選択肢があります：

上位プランに切り替えて、できるだけ今のまま使い続ける
データを複数のベースに分けて、スクリプトやAPIで連携させる
スプレッドシート型のツールから、より柔軟で拡張性の高い業務システム構築ツールに移行する（セルフホスティング可能なオープンソース製品など）

この記事では、それぞれの方法について詳しく解説し、あなたに合った次のステップを見つけるヒントをお届けします。

💬 こんにちは、NocoBase ブログへようこそ。NocoBase は、データアプリ・内部ツール・業務フローを構築できるオープンソースのノーコードプラットフォームです。自社運用・プラグイン構成・開発者に優しい設計が特徴です。 → GitHub で詳しく見る

1.プランをアップグレードする

一番簡単な対処法

今後もデータ量の増加がそれほど見込まれない場合は、Airtable のプランをそのままアップグレードするのが最も手軽な方法です。

ある Reddit ユーザーいわく、「たいていの人は5,000〜10,000件以下で収まるか、一気に10万件を超えるかのどちらか。中間層はほとんどいない」とのこと。

Upgrade Your Plan

たとえば10人のチームで、Team プラン（$20／人／月）から Business プラン（$45／人／月）に変更すると、年間で追加コストは約3,000ドル。1ベースあたりの上限も5万件から12万5,000件へと大きく拡張されます。

プラン	レコード上限（1ベース）	料金（年払い）
Team	50,000件	$20／ユーザー／月
Business	125,000件	$45／ユーザー／月
Enterprise	500,000件	カスタムプラン

ただし、データがさらに増えたり、構成が複雑になると、コストに見合うメリットは次第に小さくなります。

そんなとき、多くのチームが次に選ぶのが、「データを複数ベースに分割する」という選択肢です。

2. ベースを分けてスクリプトで同期する

もう一つよく使われている方法が、データを複数の Airtable ベースに分割し、API やカスタムスクリプトでつなぐやり方です。

この方法はコミュニティでも多くの開発者にシェアされています。

ある開発者はこう話しています：

Splitting Bases + Sync Scripts

50万件ものデータを全部まとめて編集したり、自動化したりする必要はまずない。自分は Airtable を編集用のレイヤーとして使い、本物のデータベースと API 経由で同期していたよ。

具体的にはこんな使い方です：

Airtable はフロントエンドとして使い、その週に必要な一部のデータだけを読み込む
すべてのデータや履歴は PostgreSQL や MongoDB などの本番データベースに保存し、スクリプトやミドルウェアを通じて同期する

構成の一例としては：

Node.js＋cron ジョブ、または Zapier や Make を使って必要なデータを定期的に Airtable に反映
チームが作業を終えたら、変更内容を本データベースに書き戻して整合性を保つ
頻繁に更新されるデータや機密データはデータベース側に置いたまま、必要に応じて API で取得

このように Airtable を操作用のインターフェースにして、裏側で本格的なデータベースと連携することで、大量データでもスムーズな運用が可能になります。

Node.js、Airtable SDK、PostgreSQL を使用した簡単な例を以下に示します。

// 例：更新されたレコードを Airtable からメインデータベースに同期する
const Airtable = require('airtable');
const { Pool } = require('pg');

// 環境変数から API キーとデータベース接続文字列を安全に取得します。
// ハードコーディングするのではなく、環境変数を使用してください。
const AIRTABLE_API_KEY = process.env.AIRTABLE_API_KEY;
const AIRTABLE_BASE_ID = process.env.AIRTABLE_BASE_ID;
const DATABASE_URL = process.env.DATABASE_URL;

if (!AIRTABLE_API_KEY || !AIRTABLE_BASE_ID || !DATABASE_URL) {
  console.error("AIRTABLE_API_KEY、AIRTABLE_BASE_ID、および DATABASE_URL 環境変数が設定されていることを確認してください。");
  process.exit(1);
}

const base = new Airtable({ apiKey: AIRTABLE_API_KEY }).base(AIRTABLE_BASE_ID);
const pg = new Pool({ connectionString: DATABASE_URL });

async function syncUpdatedRecords() {
  try {
    // すべての未同期レコードを取得できるようページネーションを実装します。
    let allRecords = [];
    let offset = null;
    do {
      const response = await base('Orders')
        .select({ 
          filterByFormula: 'NOT({Synced} = TRUE)',
          pageSize: 100, // 1リクエストあたりのレコード数
          offset: offset 
        })
        .firstPage(); // firstPage() を使用してオフセットを手動で管理します。

      allRecords = allRecords.concat(response);
      offset = response.offset;
    } while (offset);

    for (let record of allRecords) {
      const { id, fields } = record;
      // Status および UpdatedAt フィールドが存在すると仮定します。
      const status = fields.Status || null; 
      const updatedAt = fields.UpdatedAt || new Date().toISOString(); 

      // メインデータベースに書き込みます（upsert: 存在する場合は挿入または更新）。
      await pg.query(`
        INSERT INTO orders (airtable_id, status, updated_at)
        VALUES ($1, $2, $3)
        ON CONFLICT (airtable_id) DO UPDATE SET
          status = EXCLUDED.status,
          updated_at = EXCLUDED.updated_at
      `, [id, status, updatedAt]);

      // Airtable でレコードを同期済みとマークします。
      await base('Orders').update(id, { Synced: true });
    }
    console.log(`${allRecords.length} 件のレコードが正常に同期されました。`);
  } catch (error) {
    console.error('レコードの同期中にエラーが発生しました:', error);
  } finally {
    // スクリプト完了後に接続プールを閉じるか、適切に管理してください。
    // await pg.end(); 
  }
}

// 同期関数を呼び出します（例：本番環境では cron ジョブまたはその他のスケジューラを介して）。
// syncUpdatedRecords(); 

// 注：この例のコードは、中核的なロジックのみを示しています。本番環境では、
// 包括的なエラー処理、増分的な同期、
// API レート制限、高度なページネーションといった考慮事項が不可欠です。

このコードは同期の基本ロジックを示したものです。実際の運用では、エラー処理や差分同期、API 制限、ページネーションの工夫など、さらに多くの要素が必要になります。

仕組みとしては：

Airtable は操作用のインターフェース
データの保存は本番データベース（例：PostgreSQL）
双方をつなぐのが同期スクリプト

SKU やコンテンツ、承認フローなどの用途では、この「フロントで Airtable、裏で DB」という構成がうまく機能します。

ただし、この方法にも注意点があります：

スクリプトの作成や DB 操作など、一定の技術スキルが必要
システムが複雑化しやすく、保守や人の引き継ぎが大変になりがち
ベースが増えると、権限や表示設定の管理も煩雑になり、統一的な制御が難しくなる

すでにスクリプトや同期に多くの手間をかけているなら——それは Airtable に少し無理をさせているサインかもしれません。

自社ホスティングで自由度の高いシステムを構築する

ベースの分割や同期スクリプトを運用できるレベルのチームであれば、より柔軟で本格的な方法も視野に入ってくるはずです。

それが、自社ホスティング可能なシステムを構築するという選択肢。データ構造もワークフローも自由に設計でき、スケールにも強い運用が可能になります。

「ツールを使う」段階を超え、「自分たちのビジネスに合った仕組みを作る」フェーズへ。

定型的な表形式に業務を無理に合わせるのではなく、複雑な構造やプロセスそのものを、自由に設計して構築できるようになります。

この方法には、次のような大きなメリットがあります：

✅ 柔軟なデータ設計ができる

1つのプロセスを無理に5つのベースに分けてつなぐより、最初から多対多リレーションや複数テーブルが使える仕組みの方がずっと効率的。

入れ子の構造、状態管理、サブフローなども、ツールに逆らうことなく自然にモデリングできます。

✅ 本格的な自動化が組み込める

Airtable の Automations は簡易的で便利ですが、

承認ステップが複数ある
条件分岐がある
一連の複雑なアクションがある（例：承認 → 顧客ステータス変更 → タスク割当 → 通知）

といったケースでは機能不足になることも。

ワークフローエンジンを備えたプラットフォームなら、スクリプトを書いて補う必要はなく、全体を視覚的に設定できます。

✅ データ管理の自由度が高く、コストもスケーラブル

自社ホスティングを選ぶことで：

データは完全に自分たちで管理可能（オンプレミスやプライベートクラウドにも対応）
プラグインや API を使って、必要な機能を自由に追加できる
そして何より、月額のユーザー課金に縛られず、自分たちのペースで、必要な分だけ拡張していけます

「1人あたり◯ドル」ではなく、「必要な機能を自分たちで組み上げていく」——その発想が、次のステージへ進む鍵になります。

どんなチームに、このようなプラットフォームが向いているのか？

すべてのチームが移行すべきというわけではありません。

実際に他のプラットフォームに移ってから「やっぱり Airtable が一番使いやすい」と戻ってくるケースも少なくありません。

Who Should Consider These Platforms?

ただし、もしあなたやチームが次のような課題に悩まされているなら、別の選択肢を検討するタイミングかもしれません：

テーブルや権限が増えすぎて、データ構造が複雑化し、管理が混乱している
承認フローやタスクの自動割り当て、細かなロール管理などが Airtable では難しい
金融・医療・教育など、厳格なコンプライアンス要件がある分野で機密性の高いデータを扱っている
チームの拡大に合わせてコストが急増するのを避け、長期的な費用を抑えたい

もしこうした状況に一つでも心当たりがあるなら、より柔軟なプラットフォームを試してみる価値はあります。

すべてを一度に移行する必要はありません。まずは、CRM 機能の一部や簡単な問い合わせ管理など、小さなモジュールから始めるのも一つの手です。

こうしたタイプのツールに興味がある方のために、他のチームでも導入実績のあるプラットフォームをいくつかまとめています。

それぞれ機能や特徴が異なるため、自社の体制やスキルセット、用途に合わせて選ぶのがおすすめです。

ツール名	デプロイ形式	主な特徴	想定される利用シーン
NocoBase	自社ホスティング	柔軟なデータモデリング、プラグイン構成、ワークフローエンジン、詳細な権限設定対応	CRM や承認フロー、プロジェクト管理などの業務システム構築。データ制御とセルフホスティングを重視するチームに最適。
Appsmith	自社ホスティング / クラウド	UI 開発に強み。カスタマイズ可能なコンポーネント群と API 連携に優れる	ダッシュボードやクエリ画面などの社内向けツールを構築する技術チームに適しており、柔軟なコード対応が可能。
Budibase	自社ホスティング / クラウド	フォーム中心の簡易アプリ構築、シンプルなバックエンド管理	レポート作成や監査、フォーム業務アプリなどを短期間で立ち上げたい小規模チーム向け。運用もシンプル。
Baserow	自社ホスティング / クラウド	Airtable に似た視覚的なテーブル UI。API 拡張にも対応	視覚的にテーブルを操作したいユーザーや、Airtable からスムーズに乗り換えたいライトユーザーにおすすめ。

上記のツールはすべてオープンソースで、自社ホスティングに対応しています。

業務要件や運用環境、エンジニア体制に合わせて、最適なプラットフォームを選択してください。

さらに Airtable のオープンソース代替を探している方は、以下の記事も参考になります： GitHubで最もスターを獲得したAirtableのオープンソース代替品トップ7

あとがき

多くのチームにとって、Airtable はデジタル変革の入り口でした。

誰でも簡単に社内ツールを作れるようになり、データの見せ方やチームの協働の仕方に新しい選択肢を与えてくれました。

ただ、業務が複雑になるほど、「このツールでどこまでいけるか？」「データやコストをちゃんとコントロールできるか？」といった視点も必要になってきます。

もちろん、すべてのチームに共通する正解はありません。大切なのは、自分たちの課題に正面から向き合い、その選択が将来の可能性をどう広げるかを見据えること。

今回の記事が、その判断のヒントになれば嬉しく思います。

関連読み物：