この記事でわかること

• Salesforce と Notion を「連携」する前に確認すべき、連携の3つの方法（純正同期／iPaaS／自作API）とそれぞれの現実
• 連携が生む「隠れコスト」5つ — 維持費・破損リスク・APIレート制限・エディション制約・データ整合性/属人化を一次情報で分解
• 30名の会社で「Salesforce＋Notion＋iPaaS」を連携し続けるコストと、Lark 統合に一本化したコストの横並び試算
• 「連携が要らない」設計とは何か — 顧客・文書・案件を single source of truth に束ねる考え方
• Salesforce が営業の生命線の会社でも通用する「土台は Lark、専門はSalesforce」のハイブリッド設計と、自社EC事例に見る効果

目次

1. 結論 — 「連携させる」前に、連携の維持コストを見よ。多くの答えは「連携が要らない統合」
2. なぜ Salesforce と Notion をつなぎたくなるのか — 二重管理という病
3. Salesforce と Notion をつなぐ3つの方法とその現実
4. 連携の「隠れコスト」5つを分解する
5. 料金の一次情報 — 連携に必要なエディション・iPaaSまで含めて見る
6. 30名で試算 — 「連携し続ける」対「統合して連携ごと消す」
7. 逆張りの結論 — Lark なら「連携」そのものが要らない
8. Salesforce が生命線なら残す — 連携を最小化するハイブリッド設計
9. 自社EC事例 — 工数は「つなぎ目」に溶ける（240h→24h）
10. 連携依存から抜ける現実的3ステップ
11. よくある質問（FAQ）
12. まとめ — つなぐ前に「つながなくていい形」を検討する

結論 — 「連携させる」前に、連携の維持コストを見よ。多くの答えは「連携が要らない統合」

結論を先に述べます。Salesforce と Notion を連携させるかどうかを考える前に、まず「その連携を数年にわたり維持し続けるコストとリスク」を直視すべきです。そして多くの中小企業にとっての現実解は、2つを頑張ってつなぐことではなく、連携そのものが要らない統合基盤に土台を移すことです。連携は「一度つないで終わり」ではありません。片方の仕様が変わるたびに壊れ、誰かが直し続ける“生き物”です。この維持負担は、ツールの月額料金には表示されない「見えない固定費」として静かに積み上がります。

まず、本記事の立ち位置をはっきりさせます。世の中の「salesforce notion 連携」記事の大半は「Zapier でこうつなぐ」「Make でこう自動化する」という“つなぎ方”のHow-Toです。それ自体は有用ですが、「つなぐ価値があるか」「もっと根本的に連携を不要にできないか」という問いが抜け落ちがちです。本記事はその抜けを埋めます。判断の軸は次の3つです。

この3問に真正面から答えると、「連携を頑張る」より「連携が要らない形にする」ほうが、総コストも運用リスクも小さい——という結論にたどり着く会社が非常に多い。中小企業白書が繰り返し指摘するとおり、中小企業のDXが進まない二大要因は「人手不足」と「コスト負担」です。連携を増やすほど、この両方が積み上がります。なお、4ツールを役割で選び分ける全体像は姉妹記事 Salesforce・Notion・kintone・Lark 使い分け判断基準2026 にまとめており、本記事はその中の「連携」という論点を一段深掘りする位置づけです。

なぜ Salesforce と Notion をつなぎたくなるのか — 二重管理という病

結論として、Salesforce と Notion をつなぎたくなる根本原因は「顧客に関する情報が2つのツールに分断されている」ことです。多くの会社で、次のような分断が起きています。

情報の種類	どこにある	起きている問題
顧客・商談・売上予測	Salesforce	営業担当は見るが、他部門は開かない
議事録・提案書・社内Wiki	Notion	顧客名が手入力で、Salesforceと表記ゆれ
案件の進捗・タスク	両方に散在	どちらが最新か分からず二重更新
日々の連絡・依頼	別のチャットツール	決定事項がどこにも残らない

この状態だと、営業担当は「Salesforce に商談を入力し、同じ内容を Notion の提案メモにも書き、進捗をチャットで報告する」という三重入力を強いられます。だから「せめて Salesforce と Notion を連携させて、顧客名や商談ステータスを自動で同期したい」という発想が生まれる。これは自然な欲求です。問題は、その連携を実現・維持する手段が、思ったより高くつくことにあります。次章で、つなぐ方法を具体的に見ていきます。

Salesforce と Notion をつなぐ3つの方法とその現実

結論として、Salesforce と Notion をつなぐ方法（salesforce notion 連携の実装手段）は大きく3つあり、いずれも「無料・簡単・壊れない」のどれかを必ず欠きます。まず前提として重要な事実を1つ。Notion 公式が用意する Salesforce 連携は「Notion AI コネクタ」だけで、これは Salesforce → Notion への“読み取り専用（片方向）”です（Notion公式ヘルプ（Salesforce AI コネクタ）、2026年8月時点）。しかもその利用には Notion 側は最上位の Enterprise プラン、Salesforce 側は API アクセスが必須という条件が付きます。つまり「顧客名や商談ステータスを双方向に自動同期する純正機能」は存在せず、双方向でつなぐには Zapier・Make などの外部の仕組みか自作 API が要ります。方法を整理すると次のとおりです。

方法	中身	コスト	弱点
① iPaaS（Zapier / Make 等）	両者のAPIを外部サービスが仲介。ノーコードで条件設定	月額のiPaaS料金＋タスク量で逓増	タスク数課金で規模拡大に弱い／複雑な双方向同期は設定が難しい
② 専用連携ツール（Unito等）	双方向同期に特化した第三者SaaSを挟む	別途サブスク（同期件数で課金）	また1つ月額ツールが増える／対応項目に制約
③ 自作（API開発）	Salesforce API × Notion API を自前コードで連結	開発費＋保守工数（人件費）	作った人しか直せない＝属人化／仕様変更で停止

ここで見落とされがちな技術的な壁が2つあります。第一に、Notion の API には「1つの連携につき平均で毎秒3リクエスト程度」というレート制限があり（Notion 公式 API ドキュメント）、大量のレコードを頻繁に同期する用途では詰まりやすい。第二に、Salesforce の外部連携に使う Web API は、上位エディションの特長として位置づけられています。公式の料金ページでも Enterprise（¥21,000）の説明に「さらに自由度の高い営業用CRMと Web API」と明記されており（Salesforce 公式 料金ページ、2026年8月11日確認）、下位の Starter Suite（¥3,000）や Pro Suite（¥12,000）で本格的な API 連携を前提にすると、Enterprise 以上への移行が実質必要になりえます。つまり「安いプランでつなぐつもりが、連携のために単価が数倍に跳ね上がる」という逆転が起きえます。連携は入口だけ見ると簡単そうですが、規模と頻度が上がるほど技術的・費用的な天井にぶつかるのです。

連携の「隠れコスト」5つを分解する

結論として、ツール間連携の本当のコストは「月額のツール料金」ではなく、次の5つの見えない負担の合計です。見積もりでここを数えないと、連携は「安く見えて高い」買い物になります。

隠れコスト①：維持費（iPaaSのタスク課金）

iPaaS はたいてい「実行タスク数」で課金されます。連携する項目や更新頻度が増えるほど上位プランが必要になり、連携が“育つ”ほど月額が上がる構造です。最初は数千円でも、部門展開すると数万円規模になることは珍しくありません。

隠れコスト②：破損リスク（仕様変更で止まる）

連携は「作って終わり」ではありません。Salesforce か Notion のどちらかが仕様・項目・認証方式を変えれば、同期は静かに止まります。しかも止まったことに気づくのは、たいてい「データが合わない」と現場が騒いだ後。“壊れたら直す人”を常時確保しておくという、見えない人件費が発生します。

隠れコスト③：APIレート制限による詰まり

前述のとおり Notion API は毎秒3リクエスト程度が目安。大量データの一括同期や高頻度更新では制限に当たり、遅延・取りこぼしが起きます。回避するには設計を作り込む必要があり、これも工数として跳ね返ります。

隠れコスト④：エディション制約（連携のために単価が上がる）

前章のとおり、Salesforce の Web API は Enterprise（¥21,000）以上の特長です。Web API を持たない Starter Suite（¥3,000）で契約していると、本格的な API 連携の要件を満たせずWeb API を搭載する Enterprise への移行が必要になり、エディション単価は ¥3,000→¥21,000 の7倍に跳ねます。連携を成立させるためにツール単価そのものが上がる——これは見積もり段階で最も見落とされる費用です。

隠れコスト⑤：データ整合性と属人化

双方向同期には「どちらが正か（コンフリクト解決）」という永遠の課題が付きまといます。両側で同時に更新されたらどうするか。さらに自作連携は「作った担当者が辞めたら誰も直せない」属人化を生みます。データがずれた状態で営業判断を下すリスクは、金額に換算しにくいぶん、かえって深刻です。

料金の一次情報 — 連携に必要なエディション・iPaaSまで含めて見る

結論として、連携コストを正しく見るには「各ツールの単価」だけでなく「連携に必要な上位エディション」と「iPaaSの月額」まで足して比較しなければなりません。まず各社公式の現行料金（1ユーザー月額・税抜）を正確に押さえます。

ツール	エントリー	中位	上位（連携に必要になりがち）
Salesforce	Starter Suite ¥3,000	Pro Suite ¥12,000	Enterprise ¥21,000
Notion	フリー ¥0	プラス ¥1,650	ビジネス ¥3,150
Lark	Starter ¥0（20名まで）	Pro ¥1,420	Enterprise 要問い合わせ

出典: Salesforce公式 料金ページ（JPY/ユーザー/月。Starter Suite ¥3,000／Pro Suite ¥12,000／Enterprise ¥21,000／上位に Unlimited ¥42,000。Enterprise 以上が Web API を搭載、2026年8月11日確認）／Notion公式料金（月払い表示価格。年払いで最大20%オフ）／Lark公式プラン（税抜・年払い、Enterpriseは公開価格なし＝要問い合わせ）。2026年8月11日確認。これに加えて双方向連携する場合は iPaaS（例: Zapier は無料100タスク/月、有料は月額約$20〜でタスク課金）の費用が上乗せされます。

ここで見えてくる落とし穴は2つ。第一に、Salesforce の Starter Suite（¥3,000）と Enterprise（¥21,000）は同じ「Salesforce」でも別物で、API連携を本格的に使う構成では上位エディションが前提になりやすい。「安いプランで契約してNotionと連携」のつもりが、連携要件でエディションが上がり、実質単価が数倍になることがあります。第二に、連携を成立させるための iPaaS 費用は、どのツールの料金表にも載っていない“第4の固定費”だという点。ツール2つの単価だけを見て「連携すれば安く済む」と判断すると、この上乗せを見落とします。値上げ局面での棚卸しは 2026年 中小企業 SaaS コスト見直しガイド にまとめています。

30名で試算 — 「連携し続ける」対「統合して連携ごと消す」

結論として、「Salesforce＋Notion＋iPaaSで連携し続ける構成」と「Larkに土台を統合して連携ごと消す構成」を、30名で並べると差は歴然です。ここでは「営業の高度なCRMが必須ではなく、顧客・文書・案件の一元管理が主目的」の会社を想定した単純比較です（いずれも税抜・年払い換算、iPaaS等は概算）。

パターン	構成（30名）	月額の目安	連携維持
A：連携し続ける	Notion ビジネス ¥3,150×30＝¥94,500 ＋ Salesforce（CRM最小の Starter Suite ¥3,000×30＝¥90,000／API連携には Enterprise ¥21,000×30＝¥630,000）＋ iPaaS（Zapier 等）月 ¥3千〜¥1万	約 ¥19万〜¥74万	常時必要（壊れたら直す人）
B：Lark に統合	Lark Pro ¥1,420×30 ＝¥42,600（チャット・会議・文書・Base・承認・カレンダー込み）	¥42,600	不要（同一基盤内で完結）

パターンA は Notion ビジネス（¥3,150×30＝¥94,500）だけで既に Lark 統合構成の倍以上。ここに Salesforce のライセンスと iPaaS の月額・タスク課金が積み上がります。パターンB は Lark Pro ¥1,420×30＝¥42,600 で、顧客・文書・案件・連絡・承認を1基盤に収めるため連携そのものが発生しません。パターンAは、営業CRMを最小の Starter Suite で抑えても月 ¥18.5万（¥94,500＋¥90,000）に iPaaS（Zapier 等で月 ¥3千〜¥1万）を足して約 ¥19万、API連携で Enterprise が要るなら月 ¥72.5万（¥94,500＋¥630,000）＋iPaaS で約 ¥74万に達し、いちばん安く見積もっても Lark 統合（¥42,600）の約4.4倍です。各社料金は上記「料金の一次情報」章の出典に基づく2026年8月11日時点の値。実額は必要機能・人数・タスク量で変わります。

重要なのは、「Bが安いからBにすべき」という単純な話ではないことです。もし営業DXが事業の生命線で Salesforce の深い機能が売上に直結するなら、その投資は「高い」のではなく「効く」投資です（その場合の設計は次章のハイブリッド）。ここで言いたいのは、「顧客・文書・案件を別々のツールに置いて連携で必死につなぐ」という構造そのものが、料金表に出ない維持コストとリスクを生んでいるということ。IPA「DX動向」や 中小企業白書2024 が示すように、中小企業のDXは人材とコストの制約で足踏みしがちです。連携の維持に人と金を取られるほど、本来のDXに回せる余力は削られます。

逆張りの結論 — Lark なら「連携」そのものが要らない

結論として、Salesforce と Notion をつなぐ最良の方法の1つは、「つながなくていい形」にすることです。連携が必要になるのは、顧客データと文書が“別々の場所”にあるからです。最初から同じプラットフォーム上に置けば、同期という工程自体が消える——これが統合基盤（Lark）の発想です。

Lark は、チャット・ビデオ会議・ドキュメント・カレンダー・承認・業務データベース（Lark Base）・メールを1つのアプリで提供します。顧客・案件は Lark Base（業務DB）で管理し、提案書・議事録・マニュアルは同じ Lark のドキュメントで作り、連絡・承認も同じ画面で完結する。データが1か所にあるので、そもそも「AツールからBツールへ同期する」必要がない。これが single source of truth（信頼できる唯一の情報源）の状態です。Lark Base の業務DBとしての実力は Lark Base が中小企業の業務効率を変える3つの理由、Notion との棲み分けは Notion vs Lark Base 比較・Lark と Notion の違い に詳しくまとめています。

論点	連携する構成（SF＋Notion＋iPaaS）	統合する構成（Lark）
データの置き場所	2か所に分散、同期で整合	1か所（同期不要）
壊れるポイント	API・iPaaS・認証の3層	連携がないので壊れる箇所が少ない
維持する人	常時必要（属人化しやすい）	同期の保守が不要
外部SaaS連携	iPaaS前提	AnyCross・APIで必要な所だけ連携

とはいえ、Lark も「外部と一切つながない」わけではありません。会計 freee・マネーフォワードのようなどうしても外部に置きたい専門SaaSとは、AnyCross（連携自動化）や API でつなげます。ポイントは、「内側（連絡・文書・顧客・案件）は最初から全部つながっている状態を作り、外部連携は本当に必要な所だけに絞る」こと。連携の“総数”を減らすほど、壊れる箇所も維持コストも減ります。会計連携の具体例は Lark × freee/マネーフォワード連携、連携自動化の仕組みは Lark AnyCross 完全ガイド にまとめています。

Salesforce が生命線なら残す — 連携を最小化するハイブリッド設計

結論として、営業の高度なCRMが売上に直結する会社は、Salesforce を無理に捨てる必要はありません。その場合の現実解は「土台は Lark、営業の司令塔は Salesforce」というハイブリッドです。ここでも連携を最小化する設計の勘所があります。

ポイントは、「Notion が担っていた文書・議事録・ナレッジの役割を Lark に寄せる」こと。こうすると、Salesforce ↔ Notion の連携そのものが消え、残るのは「Salesforce ↔ Lark」の1本だけになります。連携の本数が2本から1本に減り、Notion のサブスクも不要になる。営業の深い管理は Salesforce に残しつつ、日常業務の土台（連絡・会議・文書・承認・簡易DB）は Lark に集約する——これが「専門は深く、土台は1つ」の設計です。

Lark Base を営業・顧客管理の受け皿として使う具体例は Salesforce の代替に Lark Base で CRM を組む・Lark Base で SFA（営業管理）を内製する にまとめています。もちろん「Salesforce を残すべきケース」もあるため、当社は乗り換えありきではなく中立に設計します（Lark 導入支援サービス／Lark Base 業務システム構築）。他ツールとの1対1比較は Lark vs kintone・Lark vs Microsoft Teams も参考にしてください。

自社EC事例 — 工数は「つなぎ目」に溶ける（240h→24h）

結論として、当社自身が「役割の重なる多ツール併用＋手作業の連携」から「Lark を土台に統合」へ切り替えたことで、月240時間かかっていた定型業務を24時間（90%削減）まで圧縮できました。これは机上論ではなく、群馬・前橋で運営する自社EC事業での実測値です（削減の内訳は 自社EC事業の240時間→24時間 削減の詳細 にまとめています）。

切り替え前は、顧客・受発注・在庫・問い合わせが別々のツールに散らばり、「Aで見た情報をBに転記する」「どっちが最新か確認する」「通知を見に行く先が多い」という“ツールのつなぎ目”に時間が溶けていました。まさに本記事で述べた「連携（自動でも手動でも）の維持コスト」が、人の工数として顕在化していた状態です。これを Lark に集約し、受発注・在庫・問い合わせを Lark Base で管理し、承認・連絡・会議を同じアプリ内で完結させた結果、転記・確認・行き来の工程そのものが消えたのです。

この事例の教訓は明確です。工数を食っているのは個々の作業より「ツールとツールの間」であることが多い。連携はその“間”を自動化する試みですが、自動化しても維持コストは残ります。だからこそ、「間」自体をなくす統合の効果は、料金削減にとどまらず、時間という最も希少な経営資源を取り戻すことにつながります。中小企業のDXを段階的に進める全体像は 中小企業のDXが64%失敗する理由と回避5ステップ をご覧ください。

連携依存から抜ける現実的3ステップ

結論として、連携依存から抜けるのは「一気に全部移す」ことではなく、連携の本数を1本ずつ減らしていく段階作業です。次の順番が現実的です。

ステップ1：連携箇所の棚卸し（見えない連携を可視化）

まず「今、何と何を、どうつないでいるか」を紙1枚に書き出します。iPaaS・自作スクリプト・そして“人による手作業の転記”も立派な連携です。ここで初めて、維持コストと破損リスクが見えます。

ステップ2：土台の一本化（連携が要らない領域を作る）

チャット・会議・文書・承認・カレンダーといった「毎日使う土台」を Lark に集約します。この領域は連携で頑張るより統合したほうが速く、ここを1本化するだけで連携箇所が大きく減るのが普通です。

ステップ3：残った専門連携を最小化

Salesforce のような「残す価値のある専門ツール」だけを残し、連携は必要最小限の1本に絞る。連携を“ゼロ”ではなく“最小”にするのが現実解です。壊れる箇所を減らせば、維持する人の負担も減ります。

よくある質問（FAQ）

Q. Salesforce と Notion は純正機能だけで連携できますか？

双方向の自動同期はできません。Notion 公式の Salesforce 連携は「Notion AI コネクタ」だけで、これは Salesforce → Notion への読み取り専用（片方向）であり、しかも Notion Enterprise プランと Salesforce の API アクセスが必要です。顧客名や商談を双方向に同期するには Zapier・Make などの iPaaS か、Unito 等の専用連携ツール、または API で自作する必要があり、いずれも追加のコストと保守が発生します。

Q. salesforce notion 連携のいちばん安い方法は？

小規模なら iPaaS（Zapier 等）の下位プランが入口としては安価ですが、連携する項目や更新頻度が増えるとタスク課金で上がります。さらに Salesforce 側は連携要件で上位エディションが必要になる場合があり、Notion も有料プランが前提になりがちです。「単価の安さ」だけでなく「維持し続ける総額」で比較してください。

Q. 連携はどのくらいの頻度で壊れますか？

頻度は構成によりますが、Salesforce・Notion のいずれかが仕様・項目・認証を変えると同期が止まる可能性があります。重要なのは「壊れる前提で、直せる人を確保しているか」です。自作連携で担当者が退職すると誰も直せなくなる属人化リスクが典型的な落とし穴です。

Q. Salesforce を使い続けたいのですが、Lark と両立できますか？

両立できます。おすすめは「土台は Lark、営業の高度管理は Salesforce」のハイブリッドです。Notion が担っていた文書・ナレッジを Lark に寄せると、Salesforce↔Notion の連携が消え、残る連携は Salesforce↔Lark の1本だけになります。連携の本数を減らすほど維持は楽になります。

Q. Lark に統合すると、本当に「連携」は要らなくなりますか？

社内の連絡・会議・文書・顧客・案件・承認を Lark に集約すれば、それらの間の同期（連携）は不要になります。データが1か所にあるためです。ただし会計 freee など外部に残す専門SaaSとは AnyCross や API で必要な所だけ連携します。狙いは「連携ゼロ」ではなく「連携を最小化して壊れる箇所を減らす」ことです。

まとめ — つなぐ前に「つながなくていい形」を検討する

Salesforce と Notion を連携させるかどうかは、「つなぎ方」を調べる前に「つなぎ続けるコストに見合うか」を問うべきテーマです。判断の原則は3つ。①連携の隠れコスト（維持費・破損・レート制限・エディション制約・属人化）を必ず数える、②単価ではなく“維持し続ける総額”で比較する、③そもそも顧客・文書・案件を同じ場所に置いて連携ごと消せないかを検討する。この順番で考えれば、「連携を頑張る」より「連携が要らない土台にする」ほうが、多くの中小企業にとって総コストもリスクも小さいことが見えてきます。

当社は自社EC事業でこれを Lark に集約し、月240時間→24時間（90%削減）を実証しました。Salesforce を残す判断も含めて中立にご提案します。まずは「今、何と何を、どうつないでいるか」を1枚に書き出すところから始めてください。

関連記事

• Salesforce・Notion・kintone・Lark 使い分け判断基準2026 — 4ツールを役割で選び分ける上位フレームワーク。
• SaaSポカリプス2026 — 統合型へ移行すべき5つの理由 — ツールを束ねる考え方。
• 2026年 中小企業 SaaS コスト見直しガイド — 値上げ局面の棚卸し。
• Lark Base が中小企業の業務効率を変える3つの理由 — 統合型の業務DBの実力。
• Lark AnyCross 完全ガイド — 必要な所だけ外部連携する仕組み。
• Lark と Notion の違いを徹底比較 — 文書・ナレッジ領域の棲み分け。
• 中小企業のDXが64%失敗する理由と回避5ステップ — DXの進め方の全体像。
• Lark 導入支援サービス — 選定から移行・定着までの伴走メニュー。
• アウフヘーベンジャパン株式会社 会社案内 — 群馬・前橋拠点。Lark 導入を支援する独立系コンサルティング事業者。