「これ、AppExchangeにありますよね？」「まず標準機能で足りるか見ましょう」
Salesforceの現場に入ると、「〜と連携したい」「〜を自動化したい」という要望はほぼ毎回飛んできます。よくあるのが、要望を受けた側がいきなりAppExchangeを検索し始めてしまうケースです。標準機能・AppExchangeアプリ・自社開発のどれで実現するかを、検索の前に一度立ち止まって切り分けられると、提案の精度とスピードが大きく変わります。ここでは選定の全体フローと、代表的な連携領域を整理します。
選定の全体フロー
要望を受けたら、以下の順で切り分けます。
- 標準機能（Flow／承認プロセス等）で実現できないか。できるなら追加コストなしで、まずここを疑う
- 業界共通の作業か、独自の差別化ロジックか。前者はAppExchangeアプリを優先検討し、後者はApex/LWCでのビルドか個別開発を検討する
- 単発の1対1連携か、複数システムをまたぐ連携か。前者は個別コネクタ、後者はiPaaSを検討する
- Salesforce公式の拡張（Data Cloud、Flow Orchestrator、MuleSoft等）で吸収できないか。保守元が一本化される利点がある
Flow／承認プロセス等をまず疑う
前者はAppExchange、後者はビルドを検討
前者は個別コネクタ、後者はiPaaSを検討
Data Cloud等で保守元を一本化できないか
判断基準は一貫して「これは自社の差別化要素か、業界共通の作業か」です。差別化要素でなければ、既製の仕組みに乗るほうが保守コストを抑えられます。
現場から来た要望を1件ずつ記録し、選定方式を判断していくフォーマットです。
| 要望 | カテゴリ判定 | 選定方式（標準機能／AppExchange／ビルド） | 選定理由 |
|---|---|---|---|
| 記入例他社の電子署名ツールと連携したい | 記入例電子署名・契約管理（業界共通の作業） | 記入例AppExchange | 記入例差別化要素ではなく、実績のあるアプリの方が保守コストが低いため |
代表的な連携カテゴリ
- 名刺管理・リード獲得
- 名刺データ化とリード自動登録、企業・人物データベースからのエンリッチメント、リード〜取引先責任者のルーティング・重複マッチングなど
- 電子署名・契約管理
- 電子署名、商談・契約オブジェクトとの直結。国内の契約実務（押印文化・電子帳簿保存法対応）に強い国内製品もある
- 見積・CPQ・請求書生成
- 見積書・契約書のドキュメント自動生成。複雑な価格ロジックがある場合はSalesforce公式のCPQ／Revenue Cloudをまず検討する
- 商談インテリジェンス・会話解析
- 商談録画・解析、勝ちパターン抽出、コーチング。国内には日本語の商談録音解析に強い製品もある
- カスタマーサクセス・ヘルススコア
- ヘルススコア設計、解約予兆管理。CS業務の標準プラットフォームとしてService Cloudとの併用が多い
- データクレンジング・名寄せ
- 重複排除・データクレンジングの定番。移行前クレンジングや重複マージルールの自動化に使う
- iPaaS・連携ミドルウェア
- 大規模・多対多のエンタープライズ連携から、軽量なノーコード連携まで幅がある。連携の複雑さと組織規模に応じて選ぶ
- 国内業務システム連携
- 人事労務（組織変更・入退社に伴うユーザー管理の自動化）、会計・請求（受注確定後の請求書発行自動化）などの国内SaaSとの連携
- BI・分析
- Salesforce内データの高度な可視化や、他システムデータとの統合ダッシュボード構築
- Reverse ETL・データ基盤連携
- データウェアハウスとSalesforceの双方向同期。分析基盤で算出したスコア等をSalesforceに書き戻す用途で使う
このほかにも、DevOps・リリース管理、バックアップ・データ保護、フォーム・日程調整、ERP連携、サブスクリプション課金など、業務領域ごとに多数のカテゴリが存在します。すべてを暗記する必要はなく、「要望が来たときにどのカテゴリの話かをまず特定する」という使い方が実務的です。
選定時の追加チェックポイント
- AppExchangeのレビュー・導入実績数：保守元の継続性の目安になる
- セキュリティレビュー通過の有無：通過済みアプリは一定の技術審査を経ている
- ライセンス体系：ユーザー課金かデータ量課金かで、組織規模拡大時のコスト構造が変わる
- API制限への影響：導入するアプリがAPI呼び出し数・ガバナ制限を消費する場合、他の連携との合算で上限に達しないか確認する
- 日本語対応・国内サポート窓口の有無：海外製品は日本語UI／サポートの有無で運用負荷が大きく変わる
個別製品は栄枯盛衰が速い領域のため、この記事では特定製品の推奨は行っていません。実際の選定では、要件・予算・保守体制に基づき、最新の対応状況・価格を一次情報で確認してください。
Quote-to-Cashフローの連続性に注意する
「見積→契約→納品→請求」は連続した一つの業務フローです。例えば「電子契約を導入したい」という単発の要望に見えても、実際にヒアリングを進めると見積の自動生成や、契約後の納品書・請求書配信まで芋づる式に要望が出てくることがあります。いずれかの工程の要望が来たら、前後の工程も併せて確認しておくと、後から手戻りになる提案の抜け漏れを防げます。
よくある質問
- 要望を受けたら、まず何を確認すればいいですか
- 標準機能（Flow／承認プロセス等）で実現できないかを最初に確認するのが定石です。できるなら追加コストなしで実現できるため、AppExchangeアプリの検討やビルドの判断は、標準機能で不可能と確定した後に進めます
- 海外製品と国内製品、どちらを優先すべきですか
- 一概にどちらが優れているとは言えず、業務要件で決まります。国内の契約実務（押印文化・電子帳簿保存法対応）に強い国内製品もあれば、Salesforce本体との親和性を重視するなら海外の公式拡張が有利な場合もあります。日本語対応・国内サポート窓口の有無は運用負荷に直結するため確認が必要です
- AppExchangeアプリを追加するとAPI制限に影響しますか
- 影響する可能性があります。導入するアプリがAPI呼び出し数・ガバナ制限を消費する場合、既存の他の連携との合算で上限に達しないかを事前に確認する必要があります。特に複数のAppExchangeアプリを組み合わせる場合は注意が必要です
問い
直近でSalesforceに来た連携・自動化の要望を一つ思い浮かべてください。それは「標準機能で無理だと確認した」上でAppExchangeやビルドに進んだものでしょうか、それとも要望を聞いた瞬間に検索窓を開いていなかったでしょうか。