2025年9月24日·1 分
Salesforce：CRMがプラットフォーム型エコシステムへ進化した理由
SalesforceがCRMをどのようにプラットフォーム化し、エコシステムを築き、なぜパートナーやアプリがエンタープライズSaaSの機能競争に勝てるのかを平易に解説します。
SalesforceがCRMをどのようにプラットフォーム化し、エコシステムを築き、なぜパートナーやアプリがエンタープライズSaaSの機能競争に勝てるのかを平易に解説します。
従来のCRMは「使う」ものでした：連絡先を保存し、商談を追跡し、活動を記録し、レポートを出す。ライセンスを買い、いくつかの項目を設定し、チームを教育すれば大抵は完了します。
一方でCRMのプラットフォームは「上に構築する」ものです。基本機能は残るものの、本当の価値はCRMが営業プロセス、顧客データ、自動化、連携アプリが一緒に存在する場になり、実際のビジネスに合わせて形作られる点にあります。
プロダクトマインドでは問いは「機能Xがあるか？」です。
プラットフォームマインドでは問いは「変化に応じて適応できるか？」になります。典型的には以下を含みます：
この転換が重要なのは、エンタープライズの要件はめったに静的でないからです。新たな収益モデル、コンプライアンス、組織再編、買収などで「十分な機能」がボトルネックになり得ます。
機能のチェックリストは収束します。ほとんどのCRMはパイプライン、メール同期、ダッシュボード、自動化を扱えます。差が出やすいのはCRMを取り巻くエコシステムです：導入初日から使える連携、業界向けのプリビルト拡張、実装できるパートナー、既にその知識を持つ人材プール。
企業は長期リスクを下げる選択をします。「今日これができるか？」だけでなく「来年必要になったときに対応できるか？」という問いです。強いエコシステムはその答えをより予測可能にします。
以下で、この変化を可能にしたプラットフォームの動き――カスタマイズ、APIと連携、マーケットプレイス、パートナーネットワーク――と、陰の部分：ロックイン、コスト増、複雑さ、ガバナンスについて分解していきます。
初期のCRM選定は単純でした：連絡先を保管し、パイプラインで商談を追い、基本的なレポートを作る。通話を記録し、リマインダーを送り、今月何がクローズするかを見せられれば十分に思えました。
CRMが成熟するにつれて、これらのコア機能は標準化されました。ベンダーは営業チームが必要とすることを学び、ベストプラクティスが製品間に急速に広まりました。長年の競争の結果、ステージ、ダッシュボード、メール同期、モバイル対応、予測などの機能はほぼ同等になりました。
その時点で新機能は重要ですが、単独で購入を決めることは稀です。より良いレポートビルダー、見た目の改善、新しい自動化ルールといった漸進的改良はコピーされ、追随され、回避され得ます。差別化は「箱から出して何ができるか」から「自社にどれだけフィットし、安全にスケールするか」へ移ります。
大企業は普通「最高のパイプラインビュー」を求めているわけではありません。導入とリスク低減を最適化します：
言い換えれば、戦場は機能から「デリバリー」へ移りました：実装速度、拡張性、コントロール、そして企業がCRMを自分たちの運用モデルに適応させるのを助けるエコシステムです。
プロダクトはそのまま使うもの。プラットフォームは上に構築できるものです。
簡単に言えば、プラットフォームは拡張可能なコア（頼るべきメインシステム）＋ルール（データ、セキュリティ、変更の管理方法）＋インターフェース（他のツールやチームが接続する方法）です。目標は全顧客にすべての機能を提供することではなく、各顧客が自分のやり方にシステムを合わせやすくすることです。
Salesforceの場合、コアは最初はCRM（アカウント、連絡先、リード、商談）でした。進化するにつれ差別化要因は「どのCRM画面が優れているか」より「どれだけ簡単に自社のCRMにできるか」になりました。
拡張性はこれを可能にします：カスタムオブジェクトやフィールド、業界特化のプロセス、チームに合ったユーザー体験。
ほとんどのプラットフォームは次の要素を共有します：
企業は常に変わります：新製品、新地域、合併、価格改定、コンプライアンス。プロダクトだけの世界では、変化ごとにミニプロジェクトが必要になり、ワークアラウンドやスプレッドシート、高コストの再実装が発生します。
プラットフォームは標準化された適応手段を提供することでその痛みを和らげます：別データベースを付け足す代わりにデータモデルを拡張し、手作業を増やす代わりに自動化を更新し、ワンオフのスクリプトではなく安定したインターフェースでシステムを接続する。時間が経つほど、これはCRMをビジネスに合わせて進化させるコスト（とリスク）を下げます。
営業チームは常にCRMを自分たちの売り方に合わせたがってきました。かつてはスクリプト、外部データベース、ワンオフツールを寄せ集めるのが普通で、アップグレード時に動かなくなるリスクがありました。
Salesforceはカスタマイズをサポートされる機能として扱うことでそのモデルを反転させました。CRMをフォークするのではなく、アップデートに耐え、管理者が扱えて、ITの視界に入る形で拡張できるようにしたのです。
重要な変化は多くの変更を設定優先にしたことです：データ、プロセス、画面を組み込みツールで調整し、本当に独自性が必要な場合だけコードを書く。その結果「カスタマイズして後悔する」という古典的なトレードオフを軽減しました。
カスタマイズは実務的には次の形で現れます：
最大の利点は速度です：チームはフルソフトリリースを待たずにプロセスを適応できます。採用率も上がります。
リスクは「変更しやすい」が「過剰に作り込む」につながることです。自動化、特殊フィールド、例外が増えすぎると複雑化し、変更が遅くなり所有権が不明確になります。勝つためのアプローチは意図的であること：ビジネスを標準化するためにカスタマイズし、作ったものを文書化し、もう役に立たないものは廃止することです。
デモを勝つのは機能。更新を勝ち取るのは連携です。
Salesforceが営業以外（サービス、マーケティング、財務、オペレーション）へ広がるにつれ、重心は「CRMが何をできるか」から「どれだけ他とつながるか」へ移りました。APIと連携は単一のアプリを企業アーキテクチャの一部に変えるため、プラットフォーム成長のエンジンとなりました。
多くの企業は単一システムで動いているわけではありません。リードはウェブフォームで始まり、マーケティングオートメーションを経てSalesforceで見込みになり、CPQで契約を作り、ERPにアカウントが作られ、サービスシステムでエントitlementが開かれる、といったチェーンで動くことが普通です。
そのチェーンが壊れると、ユーザーは“連携”ではなくCRMを責めます。
企業はワンオフスクリプトでなく、製品のように振る舞うコネクタを求めます：
Salesforceとそのエコシステムがこれらを提供すれば、ITは連携を承認しやすくなり、ビジネスチームはデータを信頼してコアプロセス上で運用できます。
成熟したエコシステムは、顧客ID、アカウント階層、商品カタログ、イベント駆動の更新といった共通パターンを再利用することで連携労力を下げます。各社が同じ「連絡先をXに同期する」ロジックを一から作る代わりに、ネイティブ機能、パートナー、パッケージ化されたコネクタを通じて標準的なアプローチが生まれます。
この複利的な再利用は地味ですが強力です。プロジェクトリスクを下げ、価値実現までの時間を短縮し、「次の連携は前の10件がパターンとツールとガバナンスを作ったから安くなる」という実利を生み出します。
アプリマーケットプレイスは"連携"をカスタムプロジェクトから評価・購入・導入できる製品に変えます。B2Bソフトウェアにとって重要な転換です：各ベンダーが独自に販売動線を作るのではなく、マーケットプレイスがプラットフォームに付属した共通の流通チャネルになります。
AppExchange型のマーケットプレイスは、プラットフォームを既に使っている顧客に直接届くストアフロントのように機能します。これがサードパーティアプリに自然な利点を与えます：
良いリスティングは単なるマーケティング文ではありません。買い手が必要とする情報を標準化します：機能、対応エディション、セキュリティ注記、価格、導入期待値。レビューと評価は社会的証明になり、ニッチツールを最初に試したくないチームの不安を減らします。
マーケットプレイスは調達サイクルを短縮することもあります。法務やセキュリティ、ITが「マーケットプレイスアプリ」のプロセスに慣れていれば、比較検討が増え、小さなコミットで早くパイロットが始められます。
ノイズの多いディレクトリと価値あるマーケットプレイスを分けるのは三つの特性です：
これらが機能すると、マーケットプレイスは単にアプリを売るだけでなく、エコシステム全体を加速させます。
Salesforceを購入することはめったに「インストールして終わり」ではありません。本当の仕事は、企業の営業プロセス、データモデル、承認、セキュリティルール、レポーティング、連携を実際に人が使える形に翻訳することです。このギャップがパートナーの稼ぎどころです。
ISV（独立系ソフトウェアベンダー）：Salesforce上で動く、または連携する製品を作ります。CPQ、データ強化、電子署名、業界コンプライアンス機能、分析パッケージなどが例です。彼らの価値は、繰り返し可能な機能をパッケージ化し、保守とロードマップを提供する点です。
システムインテグレーター（SI）／コンサル：要件定義、アーキテクチャ、設定、カスタム開発、データ移行、テスト、チェンジマネジメント、トレーニングを行います。大手は複雑なマルチシステム案件を得意にし、小規模は特化したロールアウトをより早く回せます。
エージェンシー：フロントエンド体験（ウェブ、ポータル、ブランディング）、キャンペーン運用やコンテンツに絡む営業／サービスフローに集中することが多いです。
マネージドサービスプロバイダ：本番運用後の管理（管理者カバレッジ、リリース管理、バックログ処理、監視、小規模改善、ガバナンス）を提供します。プロジェクト型ではなく継続的な運用安定性を担保します。
パートナーは実装能力を補うだけでなく、パターン認識を持ち込みます。同じワークフローを複数社で実装した経験がある者は、採用が破綻しやすい箇所、データが汚れやすいポイント、将来の手戻りを招く近道を予見できます。
また業界固有の知見（医療の同意管理、金融の監査要件、製造のチャネル設計）を提供し、実際に使えるシステムにするための差別化要因になります。
エコシステムの複利効果は、パートナーがテンプレートやアクセラレータ、パッケージアプローチを創り、それが再利用されることです。時間が経つとそれらが業界の“デフォルト”な実装方法になることもあります。これがSalesforceがプラットフォームのように振る舞う大きな理由の一つです：成果は多くの専門プレイヤーから生まれるので、単一ベンダーのロードマップだけで完結しません。
プロダクトの堀はソフトが何をするかに関するものです。エコシステムの堀はアプリやパートナー、共有されたナレッジを通じて何を解放するかに関するものです。CRMがプラットフォームになると、競争は「機能A対機能B」から「今後5年住みたい世界はどれか？」になります。
プラットフォームがより多くのアプリ開発者を引きつけると、顧客はニッチな問題をコアベンダーに頼らず解決できる選択肢が増えます。するとさらに顧客が増え、さらにアプリが増える――というループが働きます。
このループは単なる量ではなく“カバレッジ”の拡大です。エコシステムは業界、地域、エッジケースのギャップを埋め、単一製品チームが優先できない領域をカバーします。
プラットフォームは“移しにくい”資産を蓄積するため粘着力が出ます：
たとえ別のCRMが安く見えても、総合セットアップを再現するには高い費用とリスクが伴います。
エコシステムは知覚にも影響します。買い手は安全そうに見える選択を好みます：認定人材が豊富、実績ある連携、馴染みのマーケットプレイス。これが自己強化的なパターンになり、採用が増えるほどエコシステムへの投資が進み、プラットフォームがさらに正当化されやすくなります。
企業の購買担当は単に「より多くのCRM機能」を求めているのではなく、「自分たちの世界を理解したCRM」を求めています。データフィールド、ハンドオフ、規制、用語が既に合っていることが重要で、そこが垂直ソリューションが汎用製品を凌ぐ理由です。
プラットフォームエコシステムは実績あるパターンをテンプレート化できます：プリビルトのオブジェクト、ページレイアウト、承認フロー、報告書。医療なら同意管理や患者コミュニケーションのワークフロー、金融なら受付、適合性チェック、監査対応ログなどが例です。
「ゼロから始める」ことは中立ではなく、多くの場合何ヶ月ものワークショップと手戻りを意味します。
規制業界では深さが決定要因になることが多いです。コンプライアンス要件はオプションではなくワークフロー全体を形作ります。垂直ソリューションは用語（member、policy、claim等）や承認順序、必要証跡などを組み込み、監査で認められる構造を提供します。
汎用CRMはカスタマイズで対応できますが、垂直製品はガードレールを焼き付けてリスクを減らします。
単一ベンダーのチームがすべてのサブ業界を追うことはできません。パートナーやISVのエコシステムはニッチ向けに素早く構築し、それを多くの顧客へ配布・保守できます。結果として顧客は“準備に近い”ソリューションを得て、プラットフォーム提供者は基盤に集中できます。
CRMをプラットフォームにすることは速度と柔軟性を解放しますが、「成功」の定義が変わります。単一製品を管理する代わりに、アプリ、連携、カスタム作業のエコシステムを管理することになり、時間とともにそれらは漂流しがちです。
よくあるパターンは管理者スプロール：誰も完全には説明できないオブジェクト、フィールド、自動化、レポートが増えることです。チームはローカル問題をツールで解決し、重複アプリや二重入力、プロセスの競合が生まれます。プラットフォームは動くが、理解しにくく、安全に変更しにくくなります。
ライセンス費用は新チームの参加や追加アドオンの承認、ポイントソリューションの更新で徐々に上がります。連携はミドルウェアやコネクタの費用を追加することがあります。小さな改修が恒常的な保守項目になると、カスタム作業が恒久的な予算行になります。
過度のカスタマイズと管理されていない連携は技術的負債を生みます：もろい自動化、未文書のフロー、特定の人しか直せないワンオフAPI接続。時間が経つと単純な変更でも、どれかが壊れるリスクがあるため時間がかかるようになります。
ガバナンスは重くある必要はありませんが、実効性が必要です：
これらがなければプラットフォームは成長しますが、汚く、高コストで信用しにくくなります。
機能比較はスプレッドシートで簡単にできますが、後で後悔しやすい方法でもあります。CRMが本当にプラットフォームであるなら、あなたは『時間とともに適応する能力』を買っています：新しいワークフロー、新しいデータソース、新しいアプリ、新しいコンプライアンスルール、新しいチームに対応する能力です。
最初のローンチ後を基準に考えます：
マーケティングではなく具体を求めてください：
プラットフォームエコシステムは引力を持ちます。アーキテクチャで常にレバレッジを保ってください。
CRMの「エコシステムを作る」と聞くと大規模に思えますが、他のビジネス施策と同じく成果から始め、必要最小限の拡張で価値を出すことができます。
まず最もボリュームの大きいワークフローを端から端まで文書化します：リード→収益、ケース→解決、オンボーディング、更新。誰がどのシステムで何をして、どこで引き継ぎが失敗するかを平易に書き出してください。
その地図から次を分けます：
これでアプリや連携、カスタマイズで価値が出る優先スロットのリストができます。
各拡張項目について自問してください：
標準的なニーズは買う方が勝ちやすく、ユニークなプロセスやデータモデルは作る価値があります。
中間の実践は、開発アクセラレータで“小さくても実際に使える”内部アプリを素早く出すことです。たとえば、チームはKoder.aiのようなvibe-codingプラットフォームを使って、チャットインターフェースからCRMに隣接するウェブアプリ、軽量ポータル、ワークフローツールを作り、準備ができたらソースコードをエクスポートして完全に所有する、という流れを採ることがあります。承認フロントエンドや内部リクエストフォーム、Salesforceと連携する運用ダッシュボードなどに有用です。
1〜2のインパクトの大きいユースケースを選びます（例：見積承認、サポートの振り分け）。構築前に成功基準を定義してください：
最小の形で出荷し、パイロットグループに教育して実際の使用に基づき改良します。
拡張を作るなら（プラットフォーム内でも外部でも）プロダクトとして扱ってください：バージョン管理、リリースノート、ロールバック計画。スナップショットや簡単なロールバックをサポートするプラットフォーム（Koder.aiはこのワークフローを含む）は変更への恐怖を減らし、反復を安全にします。
小さなエコシステムでもガードレールは必要です：連携のオーナー、変更レビュー、命名規則、新アプリリクエストのプロセス。これがワンオフ解決策の増殖を防ぎます。
エコシステムが成長したら、追加したもの（アプリ、自動化、連携ポイント、データオーナー）のインベントリを維持してください。ガバナンスは官僚制ではなく、システムを説明可能に保つための仕組みです。
CRMのツールは主にそのまま使うもの（連絡先、商談、アクティビティ、レポート）です。CRMのプラットフォームは『上に構築するもの』で、データモデルを拡張し、ワークフローを自動化し、他システムとつなげて複数チームの共通の運用層にします。
実務的な判定基準：ロードマップにカスタムオブジェクト、複数の連携、継続的なプロセス変更が含まれるなら、単なるツールではなくプラットフォームを検討していると考えてよいでしょう。
コアなCRM機能は多くの製品で揃ってきたため、単純な機能チェックリストが購入決定を左右しなくなっています。
エンタープライズ購買では通常、以下を最適化します：
エコシステムは“運用後（Day-2）”の変更を容易にし、長期リスクを下げます。
見るべきサイン例：
ビジネス言語とプロセスから出発して、意図的に拡張するのが有効です：
誰も所有しない“便利そうだが不要”なフィールドや自動化は避けましょう。
アドホックなスクリプトではなく、製品のように振る舞う統合を優先してください。
最低ライン：
監視と説明ができない連携は、後でサポート負荷になります。
マーケットプレイスはアドオンを『購入して評価し、導入できる製品』に変えます。
メリット：
マーケットプレイスのアプリはソフトウェア依存と同様に、更新頻度やサポート品質を確認して扱ってください。
プラットフォームの能力をビジネス成果に変えるのがパートナーの仕事です。
共通の役割：
パートナー選定では単なる認定よりも、業界でのパターン知識と同規模での参照を重視してください。
業界固有のデータモデルやワークフローをあらかじめ持つため、ゼロから始める必要がなくなります。
通常含まれるもの：
コンプライアンスや用語が事業運営の中心なら、バーティカルな提供が有利です。
CRMをプラットフォーム化する最大のトレードオフは複雑化とコストの増加です。
よくある失敗：
対策：
機能デモだけでなく、導入後の運用と移行準備で評価してください。
実務的なチェック：
早期に“出口計画”を作る：カスタマイズのドキュメント化、連携契約のバージョン管理、主要データをウェアハウスへ複製することを推奨します。