sales-ops

営業オペレーションとCRMワークフロー

Airtableで営業オペレーションのワークフロー（パイプライン、アカウント、更新、ディールデスク、RFP追跡、パートナーCRM、業界に特化した営業システムなど）を構築して運用します。チームの規模、既存のCRM、業界に合わせて調整します。構築に着手する前に対象範囲を確認してください。同じきっかけでも、5人のチーム向けの3テーブルのパイプライン、200人規模のエンタープライズ営業組織向けのSalesforceを補完するディールデスク、住宅ローンブローカー／不動産会社／公共工事請負業者向けの業界特化型CRMなど、ニーズは異なります。

対象ユーザーと解決したい課題

営業オペレーションは、「Salesforceを運用する営業担当副社長」という典型的なイメージよりも、多くの役割や業界にまたがります。

• 収益責任者（CRO／営業担当副社長／RevOps／営業オペレーションマネージャー）— パイプラインのカバレッジ、予測の精度、セグメントの可視性、リードから収益につなげる効率を重視します。_「壊れている」とは、「数字を信頼できない」_ということです。
• 日々のオペレーター（AE／SDR／BDR／アカウントマネージャー）— 顧客との接点における見込み客のコンテキスト、インバウンドの迅速な振り分け、商談ステージの明確さ、手間の少ない記録を重視します。_「壊れている」とは、「メールを1通送るのに5つのタブを行き来して貼り付けている」_ということです。
• 部門横断のサポート担当（ディールデスク、セールスエンジニアリング、営業オペレーションアナリスト）— 監査証跡を伴う承認ルーティング、需要に対する対応能力、技術的適合性のスコアリング、例外のトリアージに取り組みます。CRM自体とは異なる製品領域です。
• パートナー／チャネルマネージャー — パートナー主導のパイプライン集計、競合防止ルールを備えた商談登録、共同アカウント計画、MDFの追跡を担当します。
• 業界特化のオペレーター — 住宅ローン担当者、不動産ブローカー、案件獲得マネージャー（公共工事／AEC）、寄付者関係責任者、資本市場のデスク担当者など、業界固有の用語、規制、連携を伴う、営業型のワークフローを扱います。

業界横断的な課題として、既存のCRMは通常そのまま使われますが、実際に業務が行われる場所ではスプレッドシートへの依存が広がっています（「画面を行き来する作業」、「信頼できる唯一の情報源」）。ユーザー単位のライセンス費用によって関係者がシステムから締め出され、可視性が損なわれます。最新の営業テクノロジースタック（Outreach／Salesloft／Apollo／Gong／CaptivateIQ）が、テクノロジー業界以外や中堅市場では導入されていないこともよくあります。AIを重視するチームは、AI機能を後付けしたCRMではなく、Clay相当のデータ拡充、AIが作成するアウトバウンドメッセージ、会話インテリジェンスの取り込みを構築するためのオープンなデータ基盤を求めています。

構築に着手する前に：対象範囲を確認する

営業オペレーションは、多くのカテゴリが想定する以上に幅広い業界や形態にまたがります。Airtableで営業ワークフローを運用する顧客の多くは、テクノロジー業界のSaaS GTMチームではありません。不動産仲介会社、住宅ローン業務、保険会社、資本市場のデスク、公共工事請負業者、寄付者を管理する非営利団体、パートナーシップを管理する教育機関、商談を追跡するタレントエージェンシーなどが、それぞれ異なるスキーマやワークフローで「Airtable上の営業オペレーション」を実行しています。まず3つの対象範囲に関する質問をして、そこから分岐してください。

1. チームの規模と構成。 ソロ／小規模（10人未満）／中規模（10～50人）／大規模（50人以上）／エンタープライズ（複数のチーム／拠点）。スキーマ構成のデフォルトを決めます。初めてCRMを構築する5人のチームと、Salesforceを拡張する200人の営業組織では、求める足場が異なります。
2. 既存のCRM（または意図的に導入していないこと）。 「現在、CRMを使っていますか（Salesforce、HubSpot、Pipedrive、小規模／業界特化型CRM、まだなし、『誰もが嫌っているSalesforce』、または従来型のCRMを使わないAIネイティブなスタックを構築中、など）？」 このスキルで最も重要な質問です。拡張・置き換え・ゼロからの構築の判断を明確にします。統合による価値を提示し、ユーザーに選んでもらいます。全面移行（AirtableでCRMを置き換える。小規模な組織や非テクノロジー系の業界でよく見られます）、拡張（Airtableを、SoRとしてのCRMの上にある柔軟なUI／ステージング／CRM導入前／CRM導入後のレイヤーとして使う。大規模組織では主流です）、ライセンス削減（CRMのシートを正当化できない関係者向けに、Airtableを主に読み取り専用のUIとして使う）、メインのCRMをSoRとして維持しながらサブチーム向けの軽量CRMを導入する、またはAIネイティブな軽量スタック（従来型CRMを導入しない可能性もあるAI活用型スタートアップ向けに、Airtableをデータ基盤として使う。Clayのような情報拡充、AIによるアカウント概要、AIを活用したアウトバウンド営業を、Airtableの型付きレコード、AI Field Agents、REST APIの上に構築します）。どの方法も有効です。特定の方法を押し付けないでください。CRMごと、およびAIスタックとの統合方法については、references/integrations.md を参照してください。
3. 主要なサブワークフロー。 「パイプライン管理、アカウント管理、更新対応、ディールデスク、RFP／入札パイプライン、パートナー／チャネルCRM、それとも業界特化型（住宅ローン、不動産、仲介など）ですか？」 どのWorkモードのプレイブックを使い、どのスキーマ構成から始めるかを決めます。ほとんどのユーザーは、最初から全部ではなく、まずこのうち1つを求めています。

必要に応じて、以下の点も確認します。

• 業界／業種を示す手がかり。 ユーザーの表現に手がかりがある場合（「ブローカー」、「入札」、「ローン」、「引受」、「物件」、_「寄付者」_など）は、業界を確認し、業界特化型のスキーマを読み込みます。業界特化型のスキーマは業界をまたいでそのまま適用できません。住宅ローンCRMと公共事業の入札パイプラインには、運用上の共通点がほとんどありません。
• ライセンス削減の動機。 Salesforceを利用しており、チームの営業担当者が少数（20人未満）である場合、または予算に制約がある場合に確認します。全面的な置き換えではなく、「SFDCの上にAirtableを主に読み取り専用のUIレイヤーとして置く」パターンが候補になります。
• AIベンダーの制約。 AIワークフローが話題に上った場合は、承認済みベンダーのLLMに関する制約（Geminiのみ、サードパーティーのLLMは不可など）を確認します。規制対象のエンタープライズでは実際によくあるパターンです。
• 外部向けのインターフェースが必要ですか？ 「ブランドに合わせたパートナー／ベンダー／請負業者向けポータルですか？ 一般公開のパートナー登録ですか？ 既存の製品への埋め込みですか？ Slack／WhatsApp／Teamsのボットですか？」 実現可能な方法は2つあります。両方を提示し、ユーザーに選んでもらいます。Airtable Portalsは、ブランドに合わせた外部コラボレーター向けのファーストパーティーのインターフェースです（Interfaceベースで、カスタムサインイン／ロゴ／背景に対応。ポータルのシートごとにTeamプラン相当の料金で利用できる有料アドオン）。設定が最も簡単で、Interface Designerのコンポーネントでワークフローをカバーできる場合に適しています。VercelなどでのカスタムUIは、デザインを完全に制御したい場合、Portalアドオンの費用に懸念がある場合、Interface Designerのコンポーネントでは実現できないUXが必要な場合、サーバーサイドの処理が必要な場合、既存の製品に埋め込みたい場合、またはチャットを利用したチャネルが必要な場合に適しています。どちらも妥当な選択肢です。決めるのはユーザーです。

主な質問を3つすれば、通常は1回のやり取りで必要な足場が明確になります。話を聞く前にフレームワークを押し付けないでください。

2つのモード

セットアップモード：基本スキーマを作成する

ユーザーが 「CRM をセットアップして」／「営業パイプラインを作って」／「商談を追跡して」／「パートナー登録システムを作って」 と依頼した場合、範囲が明確になってから MCP 経由でスキーマを作成します。

1. 範囲を確認する質問（上記）。回答を読みます。このカテゴリーが対象とする業界の多様性を考えると、誤った構成を作り直すより、5 分間の確認のほうが効果的です。
2. チームの規模、CRM の有無、業種に合ったスキーマ構成を選びます。このスキル本文では、5 つのリード構成をインラインで紹介しています。業種別および専門的な構成は、必要に応じて references/vertical-shapes.md と references/schema-shapes.md を参照してください。
3. MCP 経由でスキーマを構築する — ベース、型付きフィールド、リンクされたレコード、数式、ロールアップ、サンプル／シードデータを用意します。スキーマは、その後に構築するすべての基盤です。エージェントの作業時間を、より充実した型付きフィールド、ステータス用の singleSelect における検討されたステージカラー、ロールアップ件数を伴うリンクレコードの関係に充てます（例：Opportunities.Amount × Probability をロールアップして、Account レベルの予測売上を算出します）。
4. UI 設定を引き継ぐ — ビュー（ステージ別の Opportunities のカンバン、次のアクション日付のカレンダー、Accounts のギャラリー）、Interface ページ、自動化、フォーム、同期ウィザード（Salesforce／HubSpot／Slack／Jira）。下記の「構築計画の出力」を参照してください。
5. ユーザーが希望する外部向け画面を構築する — パートナー／ベンダー／請負業者／クライアント向けポータルについては、Airtable Portals（有料アドオン、Interface ベース、ブランドに合わせたサインイン）が選択肢の 1 つであり、REST API 経由で Airtable を読み取るカスタム Vercel アプリも別の選択肢であることを伝えます。ユーザーが選んだものを構築し、こちらから決めつけないでください。チャット主導のワークフロー（Slack／WhatsApp／Teams ボット）、既存製品への埋め込み画面、その他のカスタム UI についても同様です。何が状況に合うかは、ユーザー自身が把握しています。パターンについては references/build-shapes.md を参照してください。

リードのスキーマ構成

最も一般的な 5 つの構成で、依頼の大部分をカバーします。フィールドごとの詳しい説明は references/schema-shapes.md にあります。

• 軽量パイプライン（1～2 テーブル） — パイプライン＋連絡先。創業者が 1 人の企業、2～3 人の営業チーム、専任の SDR／AE 機能を持たない商談管理向けです。利用しない複数テーブル構成の CRM を押し付けないでください。顧客の言葉では、「商談を管理するだけでいい」「話をした相手の一覧がほしい」といったニーズです。
• 小規模（3 テーブル） — 取引先＋連絡先＋商談。典型的な CRM の三要素です。既存の CRM を拡張するのではなく、CRM を使いたいユーザー向けのデフォルトです。ステージの進捗、確度、予想成約日、担当者、リードソースを追加します。軽量な AI 統合（LinkedIn による情報拡充、AI が生成するミーティング準備情報など）は任意です。
• 中規模（5～6 テーブル） — ＋活動（通話／ミーティング／メール）、インバウンドの量に応じてリード用の独立したテーブルを追加、＋ステージ設定テーブル。CRM をエンドツーエンドで自社運用する 10～50 人のチーム向けです。予測の集計（四半期ごとの確度加重予想額）、リードスコアリング、リードのラウンドロビン割り当てを追加します。
• CRM 拡張（Salesforce／HubSpot と併用） — 同期された取引先／連絡先／商談（CRM からは読み取り専用）＋CRM では適切にモデル化しにくい項目用の Airtable ネイティブテーブル：Deal Desk リクエスト、顧客リファレンスデータベース、キャパシティ／ノルマの追跡、セールスエンジニアリングの割り当て、活動／ミーティングノートの同期。営業組織が 50 人以上の場合に最も一般的な構成です。 CRM への書き戻しが必要な場合は、Automations を介した双方向同期パターンを含みます。
• エンタープライズ向けマルチベース拡張 — マルチベースのハブ・アンド・スポーク構成。中央ハブが地域別またはプログラム別のスポークを統合します。Automations による双方向同期と、Interfaces による行レベルの権限設定により、営業担当者には自分の取引先のみを表示しつつ、マネージャーは全体を集計できます。各部門に自律性が必要で、かつ経営陣向けの集計も求められる、複数地域または複数プログラムを展開する営業組織向けです。
• AI ネイティブな軽量スタック（意図的に従来型 CRM を使わない構成） — 取引先＋連絡先＋商談＋活動＋AI を多用する情報拡充テーブル。AI Field Agents が LinkedIn、ウェブ調査、外部の情報拡充 API からレコードを段階的に情報拡充します（Clay 相当のパターンを Airtable ネイティブで実現）。AI が作成するアウトバウンドメッセージ（レビューキューに下書きを入れ、自動送信はしない）、AI による取引先概要の生成、同期された文字起こしからの AI による MEDDIC フィールド抽出を追加します。Salesforce＋アドオンではなく、Airtable＋AI ツールを選ぶ AI 志向のスタートアップ向けです。詳細は references/schema-shapes.md#ai-native-lean-stack を参照してください。

業界別および専門的な構成 — 適用範囲に関する回答で該当する場合にのみ提示します（詳細は references/vertical-shapes.md と references/schema-shapes.md を参照してください）。

• 仲介業／コミッション CRM（不動産、タレント、住宅ローン仲介、ファイナンシャルアドバイザー） — 業界固有の価格設定／契約／コミッション計算
• 不動産 CRM（住宅／商業用；案件の追跡ステージ、MSA、土地面積の数式）
• 住宅ローン業務 CRM（顧客 → 案件 → プラン、6 か月ごとの更新トリガー、LOS 同期）
• 資本市場／投資銀行（ブロックトレードのライフサイクル、スポンサー対応）
• 公共事業／AEC の入札パイプライン（案件の優先度分類、進退判断、関係者情報）
• 非営利団体／資金調達／寄付者のパイプライン
• 外部協力者のアクセスを許可するパートナー／チャネル CRM
• Deal Desk／承認ワークフロー／価格計算ハブ（CRM とは異なる製品領域）
• 顧客リファレンス／アドボカシーデータベース
• セールスエンジニアリングの活動およびキャパシティの追跡
• 営業担当者ごとの行権限を備えた売上予測
• RFP／入札パイプラインと入札前の情報分析

3 人のチームに 7 テーブルの CRM を押し付けないでください。営業部門が 5 つのチームに分かれ、既存の Salesforce もあるエンタープライズ組織に、3 テーブルのスターターを提供しないでください。回答に合った構成を選んでください。

要望があれば提示する価値のある新たなパターン：相互アクションプラン（MAP）／商談ルーム／評価ルーム — 顧客の需要は高いものの、実際に提供されている例はまだ少ないパターンです。商談テーブルを土台にサブワークフローとして構築できますが、デフォルトではなく新たなパターンとして示してください。

構築レイヤーの判断

セットアップモードのスキルは、ウォーターフォールではなく、次の4つのレイヤーを並行して組み合わせられます。

1. スキーマレイヤー（常に MCP 経由） — ベース、型付きフィールド、リンクされたレコード、数式、シードデータ。基盤となるもので、どの経路でも必ずここを通ります。
2. Airtable のネイティブ UX — ビュー、Interface Designer のページ、Automations、フォーム、きめ細かな権限、同期セットアップウィザード。現時点でサポートされているものには MCP を使い、まだ対応していないものは [click here] で引き継ぎます。
3. Airtable Portals — Airtable が提供する、外部コラボレーター向けのブランド付き画面です。Interface Designer を基盤とし、ロゴと背景を設定したカスタムサインインページ、ベースごとに1つのポータル、読み取り専用／コメント投稿者／編集者の権限レベルでのゲストユーザーアクセスを備えています。有料アドオン（Team と Business の各プラン。Enterprise の機能です）。外部コラボレーター向けのブランド付きサインインを手早く用意したい場合や、Interface Designer のコンポーネントでワークフローをカバーできる場合に適しています。
4. カスタムアプリレイヤー（REST API ＋ エージェントが構築する UI） — Vercel 上の Next.js／React アプリ、Slack／WhatsApp／Discord／Teams のボット、スケジュール実行スクリプト、ユーザーが既に利用している製品内に埋め込む画面などです。完全なデザイン制御、既存製品内に埋め込む画面、チャットを使ったチャネル、サーバーサイドの計算、または Interface Designer のコンポーネントではカバーできない UX が必要な場合に適しています。

外部向けの画面を用意する場合は、Portals とカスタム Vercel の両方の選択肢を提示し、ユーザーに選んでもらってください。 どちらも既定の選択肢ではなく、どちらも有効です。コンポーネントが要件に合い、アドオン費用も問題ない場合、Portals は構築時間を短縮できます。カスタム Vercel なら、構築とホスティングに充てる余力がある場合に、完全なデザイン制御が可能になり、アドオン費用も避けられます。予算、デザイン要件、エンジニアリングの対応力、リリースまでの時間といった制約は、スキルよりもユーザーのほうがよく把握しています。

ユーザーが外部向けの画面に触れず、「案件を追跡したい」／「アカウントを管理したい」 と述べた場合は、Airtable のネイティブ機能を優先します。外部コラボレーターが話題に上がったら、Portals とカスタムアプリの両方を選択肢として伝え、ユーザーの意向に沿って進めてください。

両方の経路における具体的なパターンについては、references/build-shapes.md を参照してください。

作業モード：既存のベースを操作する

スキルを既存のベースに対して実行する場合（「今週のリードを仕分けして」、「四半期ごとのビジネスレビューの予測を準備して」、「リスクのある更新案件にフラグを付けて」、「受信した RFP をスコアリングして」 など）は、ユーザーが必要とするサブワークフローを特定し、MCP 経由で実行（フィルタリング、スコアリング、更新、集計）したうえで、show-airtable-link を使って結果を引き継ぎます。

リードのサブワークフロー

ほとんどの呼び出しをカバーする、12種類のサブワークフローの形があります。それぞれの詳細な手順は references/sub-workflows.md に記載されています。必要に応じて、該当するセクションを読み込んでください。

1. パイプラインのトリアージとステージの進行 — ステージ、資格確認フィールド、経過期間、担当者で商談を絞り込み、停滞している商談を特定し、ステージ／次のステップ／確度を更新します。Work モードで最もよく使われる呼び出しです。
2. リードの振り分けと割り当て — インバウンドリードをスコアリング／分類し、ラウンドロビン方式またはルールベースの割り当てで AE／SDR に振り分け、Slack に通知します。自動化チェーンが適切に組まれていれば、1 分未満で対応できます。
3. 予測のレビュー — 四半期／担当者／セグメント／業種別に Amount × Probability を集計し、予測リスクを特定して BI にエクスポートします。パイプラインカバレッジと予測精度を主要指標とします。
4. アカウント調査とアカウント概要の作成 — Accounts／Opportunities／Activities／外部ソース（LinkedIn、ニュース、ウェブ調査）から情報を集め、会議準備用の概要を作成します。アクセスが許可されている場合は AI で支援します。
5. 更新パイプライン／リスクのモニタリング — 更新が近づいているアカウントを特定し、利用状況／エンゲージメントのシグナルを集計して、リスクのあるアカウントにフラグを立て、CSM の対応を促します。通常のパイプラインとは別の、販売後の商業面に関するワークフローです。
6. 営業からサービスへの引き継ぎ — Closed-Won の商談が必須フィールドの基準（PO、金額、出荷日、条件）を満たしていることを確認し、運用／設置／プロジェクト用テーブルに後続レコードを作成して、引き継ぎチームに通知します。パイプラインは「Closed-Won」で終わるわけではありません。
7. ディールデスクのレビュー — Deal Support Requests／価格例外／パートナー例外申請をトリアージして承認者に回し、SOX 監査に対応できる形で承認状況を追跡し、商談に関連付けます。
8. パートナー／チャネルの CRM 運用 — パートナーのパイプラインレビュー、チャネル登録、共同アカウントプランニング、パートナー主導パイプラインの集計、商談登録の承認を行います。パートナーが Airtable にログインして自身のレコードを更新する、外部コラボレーター向けインターフェースも含みます。
9. RFP／入札パイプライン運用 — 入札前の情報をトリアージし、応札可否の判断を追跡し、入札提出状況を管理し、階層別の落札率を分析します。AEC／公共事業／エンタープライズ B2B 向けに、獲得活動と追求活動を区別します。
10. 顧客リファレンス／アドボカシー DB の運用 — 顧客からの依頼を利用可能なリファレンスと照合し、契約から確認した権利／許可／条項をチェックし、利用状況を記録して過剰依頼のリスクを追跡します。
11. データエンリッチメントのウォーターフォール（Clay 相当） — レコードごとに複数のソースを使って AI で情報を補完します（LinkedIn → ウェブ調査 → 外部データプロバイダー → 非構造化ソースから構造化フィールドを抽出する AI Field Agents）。レコードごとのウォーターフォールロジックでは、まず主要ソースを試し、情報がなければ二次ソースを試し、フォールバックとしてウェブ調査で補完します。Airtable の標準的なパターンであり、ほとんどのチームでは別途 Clay を契約する必要はありません。
12. AI によるアウトバウンド文面の下書き（自律型ではなくコパイロットパターン） — AI Field Agents を使い、アカウントと連絡先のコンテキストをもとに、宛先ごとのアウトバウンド文面（メール、LinkedIn、マルチチャネルシーケンス）を生成します。下書きはレビューキューに入り、人間が承認してから送信します。重要なのは、これが実証済みの形だという点です。完全自律型の AI SDR ツールは市場で大きく減少していますが、コパイロットパターン（AI が下書きを作成 → 人間がレビュー）は定着しています。

ユーザーがエージェント主導のワークフローを明示的に構築している場合に提示する価値のある、オプトインパターンがもう 1 つあります。

13. エージェントアクティビティログのパターン — ユーザーがエージェント主導のワークフロー（定期的なトリアージ、複数ステップの計画、自動モニタリング）について説明した場合は、オプトインの Agent activity log パターンを提示し、agent-activity-log スキルを組み合わせて、その構築と運用を支援します。スキーマをインラインで再実装しないでください。

references/sub-workflows.md には、Work モードで参照できる、より専門的なサブワークフローが多数あります。業種特化型（住宅ローン更新のクロージング、証券仲介の手数料精算）、専門型（セールスエンジニアリングのキャパシティ集計、営業受注予測スナップショット、ホワイトスペースのマッピング、四半期営業計画）、新たなパターン（Mutual Action Plans／ディールルーム）、追加の AI コパイロットパターン（AI による MEDDIC 抽出 → 人間による検証、自動振り分け機能付き AI インバウンド分類器、ウェブ調査をもとにした AI アカウント概要）などがあります。対象範囲に含まれる場合は読み込んでください。

構成

このスキルは3つの兄弟スキルと連携します。それぞれの担当範囲を独自に作り直さないでください。

• show-airtable-link — Setup モードのビルド計画はすべてベースリンクで終わります。Work モードでレコードに触れる操作はすべて、レコード／テーブル／ページのリンクで終わります。連携は必須です。ツールの呼び出しでアクセス可能だと確認できた、最も具体的な URL を引き継いでください。
• airtable-filters — Work モードの操作でレコードを絞り込む場合（トリアージキュー、「30日間アクティビティのないエンタープライズアカウントを探す」、キャパシティの集計など）は、フィルター構文を再導出するのではなく、このスキルを通じて組み立ててください。
• airtable-overview — ユーザーが基本的なデータモデルの概念（ベース／テーブル／レコード／インターフェースページ）について混乱している場合にのみ読み込んでください。ほとんどのユーザーには不要です。デフォルトで読み込むとトークンの無駄になります。

権限を考慮した動作

MCP ユーザーの認証によって、ユーザーが実際に開ける URL が決まります。ツールの呼び出しで確認できたアクセス範囲を尊重してください。

• ページ限定ユーザー（Airtable の権限モデルでインターフェースのみアクセス可能なユーザー）— インターフェースページの URL のみを引き継いでください。ユーザーが開けない tbl_* URL は、そのユーザーにとってリンク切れです。
• テーブルレベルのアクセス — テーブル URL は安全に共有できます。
• ワークスペースレベルのアクセス — ワークスペース URL は安全に共有できます。

基本ルール：ツールの呼び出しでアクセス範囲が確認できていない場合は、そのリンクを貼らないでください。迷ったら、具体性を1段階下げてください。URL を引き継ぐ際は show-airtable-link スキルがこれを徹底します。

ビルド計画の出力

適用するレイヤーに応じて、出力形式は4種類あります。ユーザーが実際に求めているものに合う形式を選んでください。過剰に作り込まず（「案件を追跡したい」という依頼にカスタムのパートナーポータルを作らない）、不足もさせないでください（「ブランドに合わせたパートナー登録ページ」という依頼に UI 操作手順の一覧だけを提示しない）。

以下の「Configure in Airtable」または「Configure Portal」ブロックに項目を列挙する前に、mcp.airtable.com/mcp でライブ MCP の最新のサポート状況を確認してください。MCP が、本来なら引き継ぐはずの画面（ビュー、インターフェースページ、オートメーション、フォームなど）を現在作成できる場合は、MCP 経由の方法を使用してください。MCP の機能範囲は急速に変化しています。今日 UI への引き継ぎが必要なものも、明日は MCP 経由で実行できる可能性があります。

Airtable のみ（最も一般的 — ユーザーがネイティブな使用体験を求めている場合）：

✅ Built (via MCP):
  - [Base name] with [N] tables, [N] fields, linked records, [N] seed records
  - View in Airtable: [base link]

🎨 Configure in Airtable:
  - [Specific Kanban / calendar / gallery view, e.g. "Kanban on Opportunities grouped by Stage"] — [click here]
  - [Specific Interface page for the right stakeholder audience, e.g. "Forecast dashboard for sales leadership"] — [click here]
  - [Specific form / automation, e.g. "Form for inbound lead intake" or "Round-robin lead assignment automation"] — [click here]

Airtable + Portal（ユーザーがこの方法を選んだ場合）：

✅ Built (via MCP):
  - [Base + schema]
  - View in Airtable: [base link]

🌐 Configure Airtable Portal:
  - Enable Portal on the [base] — [click here]
  - Branded sign-in page (logo + background — Business/Enterprise) — [click here]
  - Share the [partner-facing Interface] to portal guests at [permission level] — [click here]

🎨 Configure in Airtable:
  - [Admin Interface page for sales-team triage of incoming portal activity] — [click here]
  - [Automation, e.g. "Slack notification when portal guest submits a form"] — [click here]

Airtable + カスタム Vercel アプリ（ユーザーがこの方法を選んだ場合）：

✅ Built (via MCP):
  - [Base + schema]
  - View in Airtable: [base link]

🛠️ Custom app:
  - [Next.js app at vercel-deploy-url]
  - Reads / writes [tables] via Airtable REST API
  - PAT scoped to [scopes]
  - Source: [github-repo-link]

🎨 Configure in Airtable:
  - [Admin interface page for sales-team triage] — [click here]
  - [Automation tying app to base events] — [click here]

Airtable で Salesforce／HubSpot を拡張（大規模環境で主流のパターン）：

✅ Built (via MCP):
  - [Base name] with [N] tables for what the CRM doesn't model — Deal Desk, Reference DB, etc.
  - Synced from [Salesforce/HubSpot]: Accounts, Contacts, Opportunities (read-only via native sync)
  - View in Airtable: [base link]

🔄 Configure CRM sync (see references/integrations.md for current mechanics):
  - Native sync from [Salesforce/HubSpot] — [setup wizard]
  - Write-back path (Salesforce Automation Actions for SFDC; REST API for HubSpot) for [specific writeback fields]

🎨 Configure in Airtable:
  - [Specific Interface page for Deal Desk / sales-team triage] — [click here]
  - [Automation for stage-change push-back to the CRM] — [click here]

最も効果の大きい UI への引き継ぎを1～3件選んでください。考えられるすべてのビューを列挙しないでください。実行時に最新の同期制限、プラン別の制約、サポート対象オブジェクトを確認してください。ツール別のフレームワーク（ネイティブ同期、Automation Actions、大規模データセット向けの HyperDB 同期、REST API、MCP）については、references/integrations.md を参照してください。

アンチパターン（デフォルトで避けること）

データが裏付けていない前提に基づいて判断する、繰り返し発生する失敗パターンです。

• テック系 SaaS の GTM を前提にしないでください。 このカテゴリーでは、業界の多様性が際立っています。不動産、住宅ローン、保険、資本市場、ヘルスケア周辺、公共部門、非営利団体、教育、人材・メディアの企業も、Airtable で営業オペレーションを運用しています。「典型的な営業オペレーションの顧客」は、テック系スタートアップで Salesloft＋Gong＋Outreach のスタックを使う企業ではなく、中小企業または中堅企業の非テック系企業です。決めつけず、幅広く確認してください。
• Salesforce を置き換えたいと決めつけないでください。 導入済み環境で Salesforce に言及される場合、その多くは置き換えではなく機能の拡張です。CRM の名前が出たら、まずは機能の拡張を前提にしてください。小規模・中規模の顧客や特定の業界では置き換えも現実的な選択肢ですが、まず確認してください。
• 最新の営業テクノロジースタックが導入済みだと決めつけないでください。ただし、その可能性を否定もしないでください。 Airtable を使う営業オペレーションの顧客の多くは、Outreach／Salesloft／Apollo／Gong／6sense／Demandbase／CaptivateIQ／Spiff／Xactly を導入していません。Airtable＋Mailchimp／SendGrid＋Slack でアウトバウンド営業を行い、Airtable 上でネイティブにコミッションを管理し、製品を購入する代わりに Airtable で CPQ ロジックを構築しています。そのため、顧客が導入していない可能性の高いツールとの連携を自動的に推奨しないでください。ただし、新しいスタックを意図的に構築する、AI ネイティブなスタートアップという、実在する成長中の顧客層もあります。Clay 形式のエンリッチメント、AI SDR コパイロット、Granola／Fathom による会話インテリジェンス、エージェント型のプロスペクティングなどを活用しています。こうした顧客にとって、Airtable の役割は異なります。Clay 相当のウォーターフォール型エンリッチメント、AI が作成したアウトバウンドメッセージ、AI によるアカウント概要を、ネイティブに構築できるデータ基盤です（型付きレコード＋AI Field Agents＋Automations＋REST API）。ユーザーの言葉から AI ネイティブな志向（「まだ CRM がありません」、「Clay／Apollo／Granola／Bardeen を基盤に構築しています」、「AI ファーストの GTM」）が読み取れる場合は、説明の軸を切り替えてください。Airtable は、ツールが不足しているチーム向けの代替策ではなく、ユーザーが自分のスタックをその上に構築できるオープンなレイヤーです。パターンについては references/integrations.md#ai-native-stack-clay-equivalents-ai-sdrs-conversation-intel を参照してください。
• 現在 MCP がサポートしている機能には MCP を使い、サポートしていない機能は UI に引き継いでください。また、これは品質の選択ではなく、機能上のギャップとして扱ってください。 ここに記載されたハードコードのリストに頼らず、最新のツール範囲は稼働中の MCP（mcp.airtable.com/mcp）に問い合わせてください。MCP が現在作成できる範囲では MCP を使ってください。より高速で、決定論的であり、エージェント駆動型です。まだ作成できない範囲は、[click here] リンクで Airtable の UI に引き継いでください。自分で調整したいユーザーには、どちらの場合も UI を利用できます。ワンクリックで越えられる機能上の境界なのに、品質上の判断であるかのように取り繕わないでください。
• CPQ を連携ツールとして推奨しないでください。 顧客は Salesforce CPQ／DealHub／PandaDoc-as-CPQ を購入するのではなく、Airtable で CPQ を構築しています。価格表、段階別の数式、DocuSign 送信などを作成しています。Airtable で価格設定ロジックの構築を支援し、外部の CPQ ツールを推奨しないでください。
• コミッション管理ツールを推奨しないでください。 CaptivateIQ／Spiff／Xactly／QuotaPath は、Airtable の利用環境ではほとんど見られません。人材／仲介業／住宅ローン／販売パートナーの業界では、コミッション管理は Airtable でネイティブに行われます。数式とリンクされたレコードで対応できます。
• 「サブチーム向けの軽量 CRM」というケースを過小評価しないでください。 3～5 人の GTM チームが、組織のメイン CRM と並行して「CRM lite」／「mini CRM」を構築するのは、実際にある典型的なケースです。顧客自身が「CRM lite」「mini CRM」「skunkworks service line CRM」と呼ぶことがあります。正規の複数テーブルスキーマを押し付けないでください。
• 大企業規模での Salesforce 置き換えを過大評価しないでください。 大勢の営業担当者を抱える企業から Salesforce の全面的な置き換えを求められることは繰り返しありますが、実際に導入されることはほとんどありません。規模の大きな組織で現実的なのは「ライセンス削減」のパターンです。ユーザーごとの CRM ライセンスを正当化できない関係者向けに、Airtable を主に閲覧用の UI として使います。
• AI による高精度な MEDDIC 抽出を約束しないでください。 文字起こしの正解データは不完全です。顧客から要望される機能ですが、実際の導入では部分的にしか対応できず、人による確認が必要です。「AI が下書きを作成し、人が確認する」というパターンを、AI が自律的に行うものではないという注意書きとともに提示してください。
• Airtable Automations でアウトバウンドメールシーケンスを自律的に実行しないでください。 到達率と CAN-SPAM／CASL の影響により、顧客は最終的に Outreach／Salesloft を利用することになります。AI が作成した下書きを人が確認するのが適切なパターンです。
• フルスタック PRM（パートナー間の競合解決、MDF を伴うパートナー主導のパイプラインオーケストレーション）を約束しないでください。 Airtable は、パートナーのディレクトリ、共同アカウント計画、案件登録など、パートナー CRM には適しています。しかし、大規模なパートナー間の競合解決は、PRM 専業ベンダーの中核領域です。
• GTM 組織の最上位規模で、テリトリーとクォータの管理に Anaplan を置き換えないでください。 大規模なテリトリー計画には、オペレーションズリサーチ水準の再調整が必要です。Airtable で小規模チームのクォータを追跡するのは問題ありませんが、大規模組織のテリトリー最適化には適していません。
• ユーザーが希望していない限り、REST API の利用を推奨しないでください。 ほとんどの営業オペレーションの用途には、Airtable のネイティブ機能で十分に対応できます。カスタムアプリが適切なのは、Interfaces／Portals では表現できないブランド体験、既存製品への埋め込み、チャット駆動型のワークフロー、マルチテナントのパターンをユーザーが求めている場合です。「営業パイプラインを作って」という依頼に対する既定の選択肢ではありません。
• AI 機能で Claude または OpenAI を利用できると決めつけないでください。 承認済みベンダーの LLM に関する制約は実際にあります（Gemini のみ、一部の規制対象企業ではサードパーティ製 LLM が不可など）。特定のプロバイダーに紐づく AI 連携を推奨する前に、必ず確認してください。 どの道を選ぶべきか迷ったら、質問してください。スコープに関する質問を2つするのにかかる時間は10秒ですが、間違った形で作り直すには1時間かかります。