SalesforceからAirtableへ移行する全手順──オブジェクト対応表と「移らないもの」まで

「Salesforce Airtable 移行」と検索してヒットする情報の多くは、「同期（Sync）」ツールの解説です。しかし同期はSalesforceの契約継続が前提であり、「Salesforceをやめたい」という方の問いには答えていません。この記事で扱うのは同期ではなく、あくまで移行──Salesforceの契約を終了し、営業管理をAirtableへ全面的に載せ替える手順です。実際にSalesforceの代替となるSFAをAirtableで構築している実案件をもとに、オブジェクトからテーブルへの対応表、レポートの再構築手順、そして見積もりから抜け落ちやすい「そのままは移らないもの」まで、網羅してお伝えします。

「同期」と「移行」は別物──検索で出てくる情報のほとんどは同期の話

まず、このキーワードで調べた際につまずきやすいポイントを整理します。Airtableの公式機能にはSalesforce Sync integrationがあります。これはSalesforceのデータをAirtableへ一方向で同期し続ける機能で、利用できるのはBusinessプラン以上です。WhalesyncやZapierなどの外部ツールも同様であり、双方のツールを契約し続けたまま連携させることを目的としています。つまり、検索上位に並ぶ情報は、ほぼすべて「Salesforceを使い続けながらAirtableも併用する」ためのノウハウです。

移行の全体像──5つの工程と期間の目安

移行は単なる「データをエクスポートしてインポートする作業」ではありません。実案件で組んでいる工程は次の5つです。

全体で最短でも2〜3ヶ月を要します。ここで重要になるのが、Salesforce側の解約期限との兼ね合いです。解約には「更新を断る期限」と「実際にサービスが停止する日」という別々の期日があり、そこから逆算して計画を立てないと、意図せず1年分の追加費用が発生してしまいます。期日の逆算方法についてはSalesforceを解約する前に──逆算すべき3つの日付にまとめてありますので、移行の検討を始めた段階で必ずご確認ください。

工程1：棚卸し──「できること」ではなく「使われていること」を移す

移行の見積もりが崩れる最大の原因は、「SalesforceでできていることをすべてAirtableで再現しよう」とすることです。しかし実際には、備わっている機能の大半は使われていません。

このように、「Salesforceで設定上できること」と「日々の業務で実際に回っていること」の間には大きな乖離があります。移すべきは後者だけです。前者まで網羅しようとすれば設計は肥大化し、期間は倍増したうえ、使われない項目が新環境へそのまま引き継がれてしまいます。

工程2：オブジェクト→テーブル対応表──実構築の設計

棚卸しが完了したら、SalesforceのオブジェクトをAirtableのテーブルへ対応させていきます。以下の表は、実案件においてSalesforceのSandbox環境の実構造を分析しながら構築した対応表です。

テーブル設計の具体的な進め方（最小4テーブル構成・案件テーブルの必須項目・異常値ビュー）については、AirtableでSFAを自作する全工程で詳しく解説しています。

そのままは「移らないもの」7つ──ここを見積もらないと計画が崩れる

対応表だけを見ると「大半はそのまま移せる」と感じられるかもしれませんが、データ以外の周辺機能や設定は、ほぼゼロからの作り直しになります。ここが移行計画における最大の盲点です。「データを移せば完了」と考えていると、移行後に「必要なレポートが出力できない」「重要な通知が止まっている」といったトラブルが続出します。

自動化の月間実行上限についてはAirtable Automationsの実行上限を、添付ファイルの取り扱いについてはAirtableのバックアップに詳細をまとめています。

レポート・ダッシュボードは「作り直す」──同じ見た目ではなく、同じ問いに答える画面を

移らないものの代表格が、レポートとダッシュボードです。ここで留意すべきは、Salesforceのダッシュボードと同じ見た目を目指さないことです。本質的に目指すのは、「そのダッシュボードが本来答えていた問いに対し、Airtableでも的確に答えられる状態」を作ることです。

Airtable側では、これらを3本の条件付きビューによって再現しました。「最終活動日が14日以上前」かつ「ネクストアクション期日が空白」という条件で絞り込んだビューを作成すれば、それがそのまま放置商談の一覧になります。数値のグラフ化が必要な箇所に絞ってInterface Designerで可視化すれば十分です。

工程3：データ移行の実務──SF側の持ち出し仕様とAirtable側の受け入れ上限

データそのものの移行作業は、双方の仕様さえ正確に把握していれば難しくありません。逆に仕様を知らないまま進めると、終盤の段階で作業が頓挫します。

これらの仕様の詳細や「一発勝負に頼らない」ための具体的な進め方は解約前の逆算記事に記載しているため、ここでは割愛します。Airtable側（受け入れ）の上限仕様は、公式ドキュメントにより以下のように確定できます。

実務上重要なのが2行目です。CSV import extensionには「既存レコードとマージ」オプションが備わっており、メールアドレスや外部IDなどのキーを指定することで差分更新が行えます。並行稼働期間中に「Salesforce側で増えた分だけAirtableへ反映する」といった運用は、この機能によって成立します（キーの照合時は英字の大文字・小文字が厳密に区別される点にご注意ください）。

データのインポート順序はマスタデータが先です。取引先→責任者→案件→活動の順に登録し、リンクは後から紐付けます。ひとつの表を分解して取り込む具体的な実務フローはExcelからの移行手順と同様ですので、そちらをご確認ください。

工程4：並行稼働と「回らなければ移行しない」──成功基準を先に合意する

移行プロジェクトにおける最大の懸念は、「新環境へ切り替えて、万一業務が回らなかったらどうするか」という点にあります。この不安を解消するために必要なのは精神論ではなく、契約条件とプロジェクト工程の設計です。実案件においてクライアントと事前に合意した成功基準がこちらです。

ポイントはプロセスの順序です。「移行してから使えるかを確かめる」のではなく、「検証を通じて実務が回ると確認できてから移行する。回らなければ移行しない」。検証期間中はSalesforceを並行稼働させておくため、後戻りできない状況が発生しません。

並行稼働にあたって、事前に必ず決めておくべき事項が1つあります。それは「いつSalesforceへの入力を完全停止するか」です。この期日を決めずにスタートすると、双方のシステムへ二重入力し続ける期間がずるずると延び、現場の疲弊を招く原因となります。

費用はどう変わるか──課金構造の違いが本体

システムの移行を検討する主な動機はコストにあるケースが多いため、課金構造の違いを整理します。Salesforceの料金体系は「エディション単価×全ユーザー課金」であり、閲覧するだけの人にも等しくライセンス費用がかかります。一方、Airtableの課金対象は編集権限を持つアカウントのみであり、閲覧・コメント権限のアカウントは無料です（プランごとの違いは権限とコスト設計の記事に整理しています）。

このライセンス体系の構造差が、大幅なコスト削減をもたらします。実案件における試算では、営業チームの全員分の編集アカウントを確保してもなお、Salesforceの更新後年額の約1/9に抑えられました。しかも実際には全員が編集作業を行うわけではないため、編集する人だけに席を絞り込めば費用はさらに下がります。なお、この会社では、契約更新のたびに1割超の値上げ通知が届いていたことが、移行検討に踏み切った直接のきっかけでした。

移行しない方がいいケース

最後に、私たちが実際の商談の場でもお伝えしている、「移行をお勧めしないケース」を明記しておきます。

逆に言えば、事前の棚卸しによって「使われているのは基本的なSFA機能だけ」と確認できた企業にとって、移行プロジェクトは見た目以上にハードルの低い取り組みです。実案件でも、数十項目のうち日常的に入力されていたのはごく一部であり、移すべきものは想像より少なかったというのが率直な実感です。

まとめ──移行は「機能の引っ越し」ではなく「業務の再設計」

Salesforceの解約日程は待ってくれません。移行の検討を始めたら、作業に着手する前に解約の3つの日付を確認し、期日から逆算して全体スケジュールを引いてください。