Airtable から PostgreSQL へ移行する — 実践的な変換パターン

本番データベースでは Airtable のパターンが違って見える理由

Airtable はスプレッドシートに似た感覚で構造を持たせたい時に便利です。しかし、ベースが「システム」になり、多くの人が日々それに依存するようになると問題が始まります。リンクされたレコード、ロールアップ、数式を巧妙に組むと、動作が遅くなり、制御が難しく、意図せず変更されやすくなります。

本番で動く PostgreSQL バックエンドのアプリは違った前提に基づいて作られます。データは共有され、ルールは常に（ビューだけでなく）強制され、変更は追跡可能である必要があります。だから「Airtable から PostgreSQL へ移行する」は単純にテーブルをコピーする話ではなく、振る舞いを翻訳する作業なのです。

本番運用が意味する具体的な要件はいくつかあります：

• 信頼性：アプリはすべてのユーザーに対して常に同じ振る舞いをする。
• アクセス制御：人は許可されたものだけを見て編集する。
• 監査可能性：「誰が何をいつ変更したか」に答えられること。
• スケール時のパフォーマンス：レコードやユーザーが増えても日常業務が壊れないこと。
• 明確な所有権：更新はビューごとの手作業ではなく、アプリのルールに従って行われること。

Airtable では多くのルールが「ビュー時」にあります。ロールアップは合計を表示し、数式は計算値を示し、フィルタされたビューはレコードを隠します。PostgreSQL では、これらの振る舞いは通常、リレーション、集計クエリ、そしてどこからアクセスしても一貫して動くアプリケーションロジックに置き換わります。

Airtable の振る舞いの中には 1 対 1 でマッピングできないものもあります。「ただ動く」リンクフィールドは、より厳格なルールを持った join テーブルに変わるかもしれません。テキスト、日付、ルックアップを混ぜた数式は、SQL 式、データベースビュー、またはバックエンドロジックに置き換わる可能性があります。

単純な例：Airtable でマネージャーがロールアップで「Total Pipeline」を見ている場合、本番アプリではその数値が権限を尊重し（どの商談が見えているか）、予測可能に更新され、レポートで再現できるものである必要があります。

実際のワークフローに合った Airtable の監査から始める

PostgreSQL へ移行する前に、ベースが日常的にどう使われているかを書き出してください。Airtable は「生きたスプレッドシート」として始まることが多く、同じテーブルがレポーティング、承認、簡単な編集を同時にこなしていることがあります。データベースに裏打ちされたアプリはより明確なルールを必要とします。

存在するものすべてを棚卸しし、忘れられがちな部分（「一時的な」ビューや一度きりのスクリプトなど）も含めて可視化します。

• テーブル（非表示やアーカイブ済みも含む）
• チームが頼りにしているビューとフィルタ（特に「自分の作業」ビュー）
• インターフェース、フォーム、各々の利用者
• オートメーション、スクリプト、連携
• 手動のルーチン（コピー/ペーストのインポート、週次クリーンアップ）

次にフィールドを「真実のソース（source of truth）」か「派生（derived）」かでラベル付けします。

• 真実のソース：人や信頼できるシステムが入力するフィールド（顧客メール、契約締結日など）
• 派生フィールド：ロールアップ、数式、ルックアップ、他データに依存するステータスフラグ

派生値の中には保存すべきもの（履歴や監査のため）と、必要なときに計算すべきものがあります。

実用的なルール：人が「その時点でどうだったか」を知る必要がある値（例：商談がクローズした瞬間のコミッション）は保存する。表示のためだけなら（例：「最終活動からの日数」）都度計算する。

問題点は平易な言葉で書き出してください。例：「Deals ビューのロードに 20 秒かかる」「マネージャーが給与欄を見られる」「インポート後に壊れたリンクを修正し続けている」。これらが新アプリの権限、パフォーマンス、データチェックの実要件になります。

データモデルの翻訳：テーブル、フィールド、ID

Airtable から PostgreSQL に移行する際の最大のマインドセットの変化は、スキーマのラベルやレイアウトが変わってもルールが保持されることを期待する点です。Airtable は「今日セルに何が入っているか」に寛容ですが、PostgreSQL はそうではありません。

まず各 Airtable テーブルを安定した主キーを持つ実体に翻訳します。人間の名前（例：「Acme, Inc.」）を ID に使わないでください。名前は変わり、綴りを間違えられ、時には衝突します。内部 ID（UUID や数値 ID）を使い、名前は編集可能な属性として保持します。

フィールドの型は慎重に見直してください。Airtable の「number」「text」は重要な違いを覆い隠すことがあります：

• 少数の既知の値しか取り得ない場合は、制御された選択肢（ステータス、優先度、ティア）として扱う。
• 金額は通貨計算に適した数値型で保持し、通貨単位も決める。
• 時刻は日付（時間なし）かタイムスタンプ（正確な時刻）かを判断する。

空欄の扱いも方針が必要です。Airtable は「空」「ゼロ」「不明」を混ぜて扱いがちです。

• 真に「まだ不明」の場合は NULL を使う。
• 「通常の値がある」場合はデフォルトを設定する（例：status = "new"）。
• 空文字列が「欠損」を意味するなら NULL に変換する。
• 空文字が意味を持つ場合のみそのままにする。
• 不正なインポートを防ぐための基本的なチェック（例えば amount >= 0）を追加する。

最後に、実際の利用状況に基づいたインデックスをいくつか追加します。人々が毎日アカウント、ステータス、作成日で絞り込むなら、その列はインデックス候補です。実際のパフォーマンスデータが出るまでは凝ったインデックスは避けますが、明らかなものは付けておきましょう。

例："Deals" テーブルは deals(id, account_id, stage, amount, close_date, created_at) のようになります。どの UI を載せてもこの構造は安定します。

リンクされたレコード：リンクをリレーションと join テーブルに変える

Airtable はリレーションを簡単に感じさせます：リンクフィールドを追加するだけで済む。しかし PostgreSQL ではそのリンクが何を意味するのかを決める必要があります。

まず基数（cardinality）を決めてください：各レコードは 1 つの対応先しか持てないか、それとも複数か？

• 1 対多：1 つの Company に複数の Contacts があり、各 Contact は 1 つの Company に属する。
• 多対多：1 人の Contact が複数の Deals に関わり、1 件の Deal に複数の Contact がいる。

PostgreSQL では：

• 1 対多は通常「多」側の単一列（例：contacts.company_id）になる。
• 多対多は deal_contacts(deal_id, contact_id) のような join テーブルになる。

その join テーブルには、role_on_deal や added_by のように、人が関係にこっそり入れている追加情報を保持できます。

参照整合性でリンクを安全に保つ

Airtable ではリンクが時間とともに乱れることが多いです。データベースでは外部キーと明確な削除ルールでそれを防げます。

決めること：

• 削除時に CASCADE、RESTRICT、SET NULL のどれが適切か？
• 孤立した行（例：実在しない deal や contact を参照する deal_contacts）をブロックするか？

ID と表示名

Airtable はリンクラベルとして親しみやすい "primary field" を表示します。PostgreSQL では安定したキー（数値 ID や UUID）を保存し、アプリ側で表示用の名前を見せるべきです。

実用的なパターン：あちこちに company_id を保存し、表示・検索用に companies.name（必要なら companies.code）を保持します。

ロールアップ：ビュー時の計算をデータベースの集計に

Airtable のロールアップは「関連レコードにまたがる計算」です。見かけ上は単一フィールドのようですが、多くの行の集約の要約です：カウント、合計、最小/最大日付、平均、リンクを通したリストなど。

PostgreSQL では同じ考えが集計クエリになります。関連テーブルをジョインし、親レコードでグループ化して組み込み関数で合計を計算します。Airtable のロールアップは表計算のフィールドでなく、データベースが答える問いになります。

一般的なロールアップの SQL への翻訳

よくあるパターン：

• 「この顧客の請求総額」 → 顧客ごとに SUM(amount)
• 「このプロジェクトの未完了タスク数」 → ステータスでフィルタした COUNT(*)
• 「最新の活動日」 → MAX(activity_date)
• 「この担当者の平均商談額」 → AVG(deal_value)

Airtable のロールアップは「Active のものだけ」「過去 30 日だけ」のようなフィルタを含むことが多いです。データベースではそれが WHERE 句になります。タイムゾーンや「過去 30 日」の定義を明確にしてください。本番のレポートは必ず問い直されます。

計算するロールアップ vs 保存するロールアップ

選択肢は二つです：

• 要求時に計算する（常に最新、保守は簡単）。
• 保存する（画面は高速、しかし更新を保つ必要がある）。

実用的なルール：ダッシュボードや一覧は計算で、スケールやスナップショットのために速さが必要な場合のみ保存します。

数式：何を SQL にして何をアプリロジックにするか決める

Airtable から PostgreSQL に移すとき、数式の翻訳が最も注意を要することが多いです。Airtable の数式はビュー、フィルタ、ワークフローを同時に支えることがよくあります。本番アプリでは、結果が一貫して速く、すべての画面で同一であることが望まれます。

数式をその本質で分類します：

• フォーマット：値を "Q1 2026" や "高" のようなラベルに変える
• 条件フラグ：TRUE/FALSE のチェック（"期限超過"、"要レビュー" など）
• 計算：合計、マージン、日付差、スコア
• ルックアップ：リンクを通して値を取り出す
• ビジネスルール：ユーザーの行動を変えるもの（適格性、承認）

単純な計算やフラグは SQL（クエリ式、ビュー、計算列）に置くことが多いです。これで画面ごとに同じ結果が得られ、同じ計算を複数のクライアントで重複して実装する必要がなくなります。

もし数式が「ルール」であるなら（例：「アカウントが有効で商談が 5,000 ドル以上なら割引を許可する」）、バックエンドロジックに移すべきです。そうすれば別のクライアントや CSV インポートで簡単に回避されることがありません。

フォーマットは UI に近づけてください。表示ラベルはデータベースに固め込むのではなく Web やモバイルの UI 側で作れます。

最終決定の前に、常に一致させるべきいくつかの出力（Status、Amount Due、SLA Breach など）を選び、それらがどこに保存されるかを決めます。そしてすべてのクライアントからテストして、アプリで見える数値が経理がエクスポートするものと一致することを確認します。

権限の再設計：ロール、レコードアクセス、監査トレイル

Airtable の権限はベース、テーブル、ビューに基づくことが多く、シンプルに感じられます。しかし本番アプリではそれだけでは不十分です。ビューはワークフローに便利ですが、セキュリティの境界ではありません。Airtable から PostgreSQL に移行する際は「誰がこれを見られるか？」の判断を API、UI、エクスポート、背景ジョブすべてで強制されるアクセスルールとして扱ってください。

まずアプリが必要とするロールを一覧化します。タブではなくロールに焦点を当てます。典型的なセット：

• Admin：設定、ユーザー、全データの管理
• Manager：変更の承認とチームの作業の閲覧
• Staff：割り当てられたレコードの作成・更新、限定的なレポート
• Customer：自分のリクエスト、請求書、ステータスを閲覧

次にレコードレベルのルール（行レベルのアクセス）を定義します。実際の多くのアプリは「自分のレコードのみ」「自分のチーム」「自分の組織」というパターンに落ち着きます。データベースで行レベルセキュリティ (RLS) を使うか、API 層で強制するかに関わらず、重要なのは一貫性です：エクスポートや "隠れた" 画面も含め、すべてのクエリにルールを適用します。

監査は最初から計画してください。変更ごとに記録すべき項目を決めます：

• 誰が行ったか（ユーザー ID、ロール）
• 何が変わったか（必要に応じてフィールド単位の前後）
• いつ起きたか（タイムスタンプとタイムゾーン）
• どこから来たか（UI、インポート、API）
• なぜか（任意のメモや理由コード）

サプライズを避ける段階的な移行計画

最も安全な移行は地味に見えます。日付を決め、関係する要素を減らし、古いベースと新しいアプリを比較しやすくします。

移行の 1 週間前にはスキーマの変更を止めてください。カットオーバー日を決め、ルールを設けます：新しいテーブルを作らない、フィールドを追加しない、名前を変更しない。小さな変更がインポートや数式を静かに壊すことがあります。

シンプルな 5 ステッププラン：

1. 構造をロックし「完了」の定義（どの画面、ワークフロー、レポートが一致する必要があるか）を決める。
2. データをエクスポートして Airtable の外でクリーンアップする。マルチセレクトの正規化、結合フィールドの分割、リンクを保持するための安定した ID 作成。
3. PostgreSQL スキーマを作成し、バッチで検証しながらインポートする。行数、必須フィールド、一意性、外部キーを検証。
4. 日常で使う重要な画面を先に再構築し、作成/更新フローを整える。
5. 短時間並行運用した後に切り替える。ロールバックプランを持つ：Airtable を読み取り専用にする、カットオーバー前の PostgreSQL スナップショットを取る、重大な不一致が出たら停止するルール。

例：営業 ops ベースなら、両システムを 1 週間並行で動かす。営業担当は新アプリで活動を記録しつつ、チームは朝に Airtable とパイプライン合計を突き合わせて数値が一致するまで確認します。

データ品質とテスト：新アプリが実情に合っていることを証明する

多くの移行バグは「PostgreSQL のバグ」ではありません。Airtable が意味していたことと新しいテーブルが保存するものの不一致です。テストをデータ作業の一部として扱い、最後の最後の仕事に回さないでください。

簡単なマッピングシートを保ちます。各 Airtable フィールドについて、ターゲットの Postgres 列とそのフィールドがアプリ内のどこで使われるか（画面、レポート、ステータスルール）を書き出します。これで「インポートしただけ」で終わることを防げます。

まずは早いサニティチェックを行います：

• テーブルごとの行数をインポート前後で比較する。
• 壊れたリンク（何も指さない外部キー）をチェックする。
• 実務上一意だった値（メール、商談 ID）に重複がないか調べる。
• Airtable がフォーム経由で許していた必須フィールドの空欄を見つける。

次に人々が頼る計算を検証します。実際のレコードを選び、合計、ステータス、ロールアップが既知の例と一致するか確認します。数式の置き換えでずれが生じるのはここが最も多いです。空欄、ゼロ、欠損リンクの扱いが違うためです。

最後に、わざとエッジケースデータをテストします：空白、削除済みリンク、長いテキスト、特殊文字、改行。O'Neil のような名前や複数行のメモはインポートと表示の問題の典型です。

Airtable から PostgreSQL へ翻訳するときのよくある落とし穴

最大の落とし穴は Airtable のベースを単純なデータベースのエクスポートとして扱うことです。Airtable はストレージ、ビュー論理、数式、共有ルールを混ぜてしまいます。PostgreSQL はそれらの関心事を分離します。これは本番では健全ですが、各振る舞いがどこに属するかを選ばされます。

リンクされたレコードは古典的な例です。見た目は単一フィールドなので多くのチームがすべて 1 対多だと仮定しますが、実際には多対多であることが多いです。それを単一の外部キーでモデル化すると関係が失われ、後で回避策が必要になります。

ロールアップは別の問題を生みます。現在のロールアップ数値を「最終的な答え」としてインポートしてしまうと、それがどう計算されたかを保存していないため、数値が後で変わったときに説明できません。再計算可能な集計（SUM/COUNT）と定義の明確化を優先し、キャッシュが必要なら更新方法を決めてください。

ビューも誤解を招きます。チームが Airtable のビューを新アプリの固定フィルタとして再現するとき、それらのビューが個人的なワークフローであり共有要件ではなかったと気付くことがあります。フィルタを固定化する前に、誰がそのビューを使っていたか、その後どのようなアクションを取っていたか、保存済みフィルタやセグメント、ダッシュボードが必要かを確認してください。

短い落とし穴チェックリスト：

• クリーンアップされていない自由入力のステータス（"In progress", "in-progress", "IP"）
• 定義や再計算方法のないままインポートされたロールアップ
• 多対多の関係を外部キーだけでモデル化してしまう
• ユーザー意図を確認せずに固定画面として再構築されたビュー
• 後回しにされた権限、のちの痛い書き直しを招く

例：営業 ops ベースを本物のアプリとして作り直す

営業 ops の Airtable ベースに Accounts、Deals、Activities、Owners（担当とマネージャー）の 4 テーブルがあると想像してください。Airtable では Deal は 1 つの Account と 1 つの Owner にリンクし、Activities は Deal にリンクします（通話、メール、デモ）。

PostgreSQL では明確なリレーションになります：deals.account_id は accounts.id を参照し、deals.owner_id は owners.id を参照し、activities.deal_id は deals.id を参照します。もし 1 つの商談に複数のオーナー（営業＋セールスエンジニア）が必要なら、deal_owners のような join テーブルを追加します。

Airtable の一般的な指標は「Account ごとの Deal Value ロールアップ（リンクされた商談の合計）」です。データベースアプリでは、このロールアップはオンデマンドで実行できる集計クエリになり、キャッシュやマテリアライズも可能です：

SELECT a.id, a.name,
       COALESCE(SUM(d.amount), 0) AS total_pipeline
FROM accounts a
LEFT JOIN deals d ON d.account_id = a.id
              AND d.stage NOT IN ('Closed Won', 'Closed Lost')
GROUP BY a.id, a.name;

次に「Health score」数式を考えます。Airtable で何でも 1 フィールドに詰め込みたくなりますが、本番では入力値を監査できる形で保存しておく（last_activity_at、next_step_date、open_deal_count、overdue_tasks_count など）ほうが良いです。スコアはバックエンドロジックで計算し、ルール変更があっても古い記録を書き換えずに済むようにします。フィルタやレポート用に最新のスコアを保存しておくことはできます。

権限は通常最も見直しが必要です。ビューのフィルタの代わりに明確なアクセスルールを定義します：

• 営業は自分の商談と活動のみ閲覧・編集できる。
• マネージャーは自分のチームの商談を閲覧できる。
• ファイナンスは Closed-Won の収益を見られるが、プライベートなメモは見られない。
• Sales Ops はステージやスコアリングルールを管理できる。

本番公開前のクイックチェックリスト

本番公開前にもう一度「Airtable の感触」が安定性、テスト性、安全性に翻訳されているか確認してください。小さなギャップが実際のインシデントになります。

公開前チェックで捕まる主な項目：

• リレーション：すべての元リンクに明示的な関係タイプ（1 対多、多対多）とキー戦略（安定した ID、一意制約、削除ルール）がある。
• 集計：請求書、クォータ、適格性など常に正確であるべき合計と、遅延しても許されるダッシュボードの区別が付いている。
• 意思決定ロジック：承認、価格、手数料のように結果を変える数式は適切な場所に実装されテストされている。
• 権限：各ロールごとに実際のユーザーストーリー（作成、編集、エクスポート、削除、承認）を終端まで実行し、レコードレベルアクセスを確認する。
• 所有権とデプロイ：スキーマ変更の所有者、ロジック変更のレビュー方法、ロールバック方法、アプリの実行場所を決めている。

現実的なチェック：もし営業担当が Airtable で "Account Tier" を編集でき、そのティアが割引を決めていたら、編集権限の変更（マネージャーのみ編集可能）と、誰がいつ変更したかを記録する監査トレイルの両方が必要になる可能性があります。

次のステップ：作る、公開する、改善を続ける

Airtable から PostgreSQL に移行した後の最大のリスクは一度に全部を作り直そうとすることです。実際のユーザーで 1 つのワークフローを端から端まで動かすパイロットから始めてください。測定可能な小さな範囲（例：「レコード作成→承認→通知→レポート」）を選び、範囲を狭く保ちます。

パイロットをプロダクトとして扱ってください。新しいデータモデルと権限ルールを非技術的なオーナーにも分かる平易な言葉で書いて、次の 2 点にすぐ答えられるようにします：「この値はどこから来るのか？」「誰がそれを見たり変更したりできるのか？」

ドキュメントは軽量に保ちます。多くのチームは次の程度で十分です：

• 主要テーブルと各テーブルが何を表すか
• 重要なリレーション（削除/アーカイブ時に何をすべきか）
• どのフィールドが計算項目か（SQL vs アプリロジック）とその理由
• ロール、レコードレベルのアクセスルール、誰がアクセスを付与するか
• 監査で期待すること（何をログに残すか）

全部を一から手作りする余裕がないなら、ノーコードプラットフォームは早さを提供しますが、本物のバックエンドを生成しルールを一貫して強制することが条件です。AppMaster (appmaster.io) は PostgreSQL バックエンドのアプリを構築し、ビジネスロジックとロールベースのアクセスを提供しながら、本番用ソースコードを生成する設計です。

段階的に展開して人々が安全に切り替えられるようにします：1 チームでパイロット、短い並行運用、ロールバックプラン付きの計画的なカットオーバー、その後ワークフローごとに拡大。