AirtableでSFAを自作する全工程──設計・自動化・費用・そして向かない会社
「Salesforceは高い。Airtableで自分たちで作れないか」という相談が増えています。実際に本番運用しているSFAの構築工程を、テーブル設計から入力を消す自動化、AI機能の使い分け、費用、限界まで通しで公開します。自作に向かない会社の条件も書きます。
AirtableでSFAは作れます。テンプレートを使えば、その日のうちに動くものができます。問題は、作った箱に営業が入力してくれるかどうかです。私たちはAIコンサルティング会社として、実案件でAirtableベースのSFAを設計・構築してきました。この記事では、実際に本番運用している構成をもとに、テーブル設計から自動化・費用・限界までを通しで公開します。
この記事でわかること
- 最小構成の4テーブル設計と、案件テーブルだけ最初から作り込む理由
- SFAが死ぬ「入力されない問題」を設計で消す4つの対策
- AI機能は買う(Omni / Field Agents)か、作る(GAS+AI API)かの判断基準
- 費用の内訳と、3年総額で比較する考え方
- レコード数の限界と、自作に向かない会社の条件
工程1:テーブル設計は「4つ」から始める
最初から作り込むと必ず失敗します。最小構成は4テーブルです。Excelから移行する場合、1枚のシートに全部入っている状態を、この4つに分解するのが最初の作業になります。「同じ会社名が何度も出てくる」列は取引先テーブルに、「1回きりの出来事」は活動履歴に分かれます。
| テーブル | 持つ情報 | リレーション |
|---|---|---|
| 取引先(企業) | 会社名・業種・規模・住所・顧客ランク・担当営業 | 案件・担当者・活動履歴へ |
| 担当者(人) | 氏名・部署・役職・連絡先・リードソース | 取引先に紐づく |
| 案件(商談) | 案件名・ステータス・金額・確度・次アクション・期日 | 取引先・担当者・活動履歴へ |
| 活動履歴 | 種別(議事録/電話/メール)・日時・内容・担当 | 取引先・案件に紐づく |

最初は作らなくていいもの
商品マスタ、見積明細、契約管理——これらはあると便利ですが、なくても運用は始められます。最初のフェーズで作り込むと、リレーションが複雑になって入力負荷が跳ね上がり、結局使われなくなります。
「案件」テーブルだけは、最初から作り込む
4つのうち、案件テーブルだけは例外です。ここが営業パイプラインの核なので、最初から必要な項目を揃えます。実案件で設計した項目は次の通りです。
案件テーブルの必須項目
- 案件名/取引先(link)/プロダクト
- ステータス(単一選択。例:提案中→商談中→内諾→導入準備→受注/失注)
- 金額(初期費用とランニングを分けて持つ)/確度(ステータス連動の掛け目)/売上予測(金額×確度の自動計算)
- 次アクション/次アクション期日(期日超過アラート用)/最終活動日
- BANT(予算・決裁者・ニーズ・時期)/失注理由
ポイントは「売上予測」を数式で自動計算することです。ステータスごとの掛け目を決めておけば、営業が金額と確度を入れるだけでパイプラインの予測値が出ます。ここを手入力にすると、誰も更新しなくなります。
ビューは「かんばん」と「異常値」の2つを最初に作る
テーブルができたら、ビューを2つ作ります。1つ目はかんばん(ステータス別)、パイプラインを見る標準ビューです。2つ目が異常値ビュー——「最終活動日が2週間以上前の案件」「期日を超過した次アクション」だけを抽出したビューです。
実案件で効いたのは、後者でした
SFAが形骸化する会社は、放置されている案件が見えない状態になっています。異常値ビューを最初に作り、週次のミーティングでこのビューだけを見る運用にすると、SFAが「報告のための入力先」から「抜け漏れを防ぐ道具」に変わります。
工程2:「入力される」ための設計が9割
SFAが死ぬ理由はいつも同じです。「案件は登録されているが、中身が3割しか埋まっていない」。ある実案件では、案件の登録自体は100%されているのに、BANTや次アクションといった詳細項目は3割程度しか埋まっていませんでした。原因は営業のやる気ではなく、入力の手間が営業本人の成果に見合っていないことです。だから設計で解決します。

「編集席を最小限にする」
Airtableは編集権限を持つユーザー単位の課金です。全営業に編集席を配ると、ライセンス費が跳ね上がるうえに、入力品質もバラつきます。実務的な設計は「編集席は責任者と管理者のみ。他のメンバーはフォーム・共有ビュー・Slack経由」。ライセンス費が下がり、同時に入力の統制も取れる——コストと品質が同じ方向に動く、珍しい設計判断です。
営業に「Airtableを開かせない」
理想は、営業がAirtableの画面を一度も開かないことです。実案件では、Slackから案件の照会・更新ができるAIエージェントを構築しました。営業は普段いるSlackから「@Agent ○○社の案件、いまどうなってる?」と話しかけるだけ。「次アクションを変えておいて」で更新もできます。
この構成(Google Apps Script+外部AIのAPI+Airtable API)はサーバー不要で構築でき、実装の全コードをAirtable AIエージェントの作り方で公開しています。
「議事録から自動で埋める」
さらに踏み込むなら、入力そのものをAIに肩代わりさせます。商談の議事録(Google MeetやZoomの自動文字起こし)をAIが読み取り、BANT・次アクション・ステータスを抽出して案件レコードに書き込む流れです。営業がやることは「商談する」だけ。記録は勝手に残ります。
ある実案件では、この仕組みで議事録入力とステータス更新の手作業がほぼゼロ、商談前の準備時間が1日60分から5分になりました。
Automationsで「更新漏れ」を潰す
Airtable標準の自動化でも、かなりのことができます。実案件で必ず入れているのは次の3つです。
- ステータスが「受注」に変わったら、顧客カルテ側のテーブルへ自動転記
- 次アクション期日を超過したら、担当者にSlack通知
- 最終活動日が2週間更新されていない案件を、週次でまとめて通知
「人間が思い出して入力する」箇所を、ひとつずつ機械に置き換えていく作業です。
既存SFAから移行する場合、最初にやること
ゼロから作るのではなく、SalesforceなどのSFAから移行するケースも多いはずです。その場合、最初にやるべきは現行システムの「使われていない項目」を洗い出すことです。ここを飛ばして全項目を移すと、使われない箱をもう一度作ることになります。
実案件では、移行前に現行システムの各項目の入力率を調べました。結果は、項目の多くが空欄かゼロのまま。ダッシュボードも「グラフデータがありません」と表示される状態でした。移行とは、現行の構造を引き写す作業ではなく、実際に使われている項目だけを残して設計し直す作業です。
移行前のチェックリスト
- 現行システムの各項目の入力率を確認する(3割を切る項目は、移行先で作らない判断もあり)
- 実際に見られているレポート/ダッシュボードを特定する(誰も見ていないものは移行しない)
- ステータスの段階数を見直す(段階が多すぎると必ずサボられる。実案件では、途中段階が飛ばされてクローズに直行していました)
- 自動化されている処理(メール連携・フォーム取り込み等)を棚卸しし、移行先で代替できるか確認する
- 移行後の合格ラインを先に合意する(「現行でできていたこの業務が、そのまま回ること」)
合格ラインを先に決めるのが、移行の肝です
「現行と同じことが全部できる」を目指すと、移行は永遠に終わりません。実務が回るために必要な機能のリストを先に作り、そこに到達したら移行完了と決める。この合意を着手前にしておくと、検証フェーズの判断が驚くほど速くなります。
工程3:AI機能は「買う」か「作る」か
2026年現在、AirtableにはOmni(会話でアプリを構築するAIビルダー)とField Agents(フィールド単位で動くAI)が搭載されています。自作するなら、まずここを試す価値があります。実際に私たちが検証したところ、実案件と同じSFA要件をOmniに投げると、約5分で6テーブル+画面一式が生成されました。叩き台としては驚異的な速さです。
ただし、そのまま業務に載せるのは危険でした
検証で見つかった問題は3つ。①かんばんビューは指示どおり日本語のステータスで作られたのに、実データは英語のステータスで生成され、噛み合わずに0件表示になっていた ②「見積明細から案件金額に自動集計する」という指示はエラーも出さずに未実装 ③「失注時だけ必須」のようなAirtableの機能上できない要件を、できないと言わずに部分実装してきた。検証の詳細(スクリーンショット付き)はAirtable Omniの実案件レビューにまとめています。

| やりたいこと | 選択肢 |
|---|---|
| 台帳の叩き台を最速で作る | Omni |
| レコードの要約・分類など定型処理 | Field Agents |
| 業務フロー固有の判断、Slack等への埋め込み、AI課金体系からの独立 | 自作(GAS+外部AI API) |
工程4:費用の実際
自作の費用は「ライセンス費」と「構築の手間」に分かれます。よくある誤解は、ライセンス費だけを比較して安いと判断してしまうことです。
| 費目 | 考え方 |
|---|---|
| ライセンス費 | Teamプランで1ユーザー月額$20(年払い時)。編集席を絞る設計で大きく変わる |
| 自作の工数 | 設計〜構築で数十時間。担当者の人件費として計上すべき |
| AI機能の費用 | 外部API直結なら従量課金(この規模なら月数百円〜)。Airtableの上位プランは不要 |
| 保守・改修 | 自作なら内製で吸収。外注した場合は都度見積が発生し続ける |
判断材料としては、3年間の総額で比較するのが実務的です。現行SaaSを3年続けた場合と、自作(または構築外注)+3年運用の総額。入力・転記に費やしている人件費まで含めると、順位が入れ替わることがあります。実案件の試算では、年間ライセンス費が数百万円規模のSaaSからAirtableへ移行した場合、ライセンス年額は約9分の1、3年総額では約3分の1になる設計が可能でした。
限界も先に知っておく
レコード数とワークフローの限界
Airtableは、レコード数が増えると動作が重くなります。私たちの実測では、1テーブルあたり2万件を超えたあたりから体感が変わります。テーブル分割やアーカイブ設計で回避できるケースも多いですが、恒常的に数十万件規模を扱う予定があるなら、Airtable以外を検討すべきです。また、複雑な承認ワークフロー(多段階の条件分岐)、「失注時だけ必須入力」のような条件付き必須、データの国内保存が規程で必須の場合も、標準機能では要件を満たせません。
自作に向かない会社
該当するなら、別の道を検討してください
- 社内に設計できる人がいない:Airtableを操作できることと、業務を分解してテーブル設計に落とせることは別のスキル。ここが欠けると、Excelをそのまま移しただけの「多機能な表」になります
- 営業の入力率が既に低い:ツールを替えても入力率は上がりません。入力を消す設計(対策2・3)が必須で、それには実装力が要ります
- 情シスの承認要件が厳しい:純正ツール以外を原則禁止している会社では、そもそも稟議が通りません(→稟議・情シス承認を通す方法)
- 作った人が辞める前提がない:自作システムは属人化します。ドキュメントと引き継ぎの設計をセットでやらないと、半年後に誰も触れないシステムになります(→AIで作った業務ツールは半年後に誰が直すのか)
まとめ:箱を作るのは1日、回すのは3ヶ月
Airtableで営業管理の箱を作ること自体は、難しくありません。テンプレートでもOmniでも、その日のうちに動くものはできます。差がつくのは「入力されない問題」をどう設計で消すかです。編集席を絞る、営業にAirtableを開かせない、議事録から自動で埋める、Automationsで漏れを潰す——この4点の設計が、SFAが3ヶ月後も使われているかどうかを決めます。
同じ取り組みを、貴社でも。
「設計から一緒に考えてほしい」「自作したものを業務に耐える形にしたい」という場合は、進め方と料金を実額で公開しています。動くデモを無料でお作りして、それを見てからご判断いただけます。
AI×CRM構築サービスを見る他の記事