「とりあえずリアルタイムで連携しておきたいです」「本当に必要ですか、それ」

リアルタイムAPI連携（REST/SOAP）

即時性が必要な場面（在庫確認・与信照会等）向け。呼び出し先の障害時に処理が止まらないよう非同期化を検討する

バッチ連携（Bulk API）

大量データの定期同期向け。1回あたりの処理件数を分割する設計が必要

iPaaS/ミドルウェア経由

複数システムとの多対多連携、変換ロジックが複雑な場合。「壊れたら誰が直すか」の運用体制を導入前に決める

Platform Event / CDC

Salesforce側の変更を他システムへリアルタイム通知。イベントの取りこぼし・重複配信を前提にした受信側設計が必須

連携方式の判断基準はシンプルです。「即時性が必要か」「データ量はどの程度か」「失敗時に誰が気づき、どう復旧するか」の3点で選びます。

連携要件を1件ずつ記録し、選定方式を判断していくフォーマットです。

• 連携元システムのキーを外部ID項目として保持し、Upsertで冪等な同期を実現する
• 同じ項目を複数システムで編集可能にすると競合が発生する。項目ごとに「正となるシステム」を決め、一方向同期を基本にする
• 双方向同期が必要な場合は、更新日時ベースの優先ルールを明文化しておく
• リアルタイムが本当に必要か、5分〜1時間の遅延で業務上問題ないかを要件段階で確認する

最初の分岐は「これは自社の差別化要素か、業界共通の作業か」です。競合優位性に直結する独自ロジックはビルド（自社実装）、名刺管理・電子署名のような業界標準機能はバイ（AppExchange導入）が基本になります。ビルドは初期コストが高くランニングコストが低くなりがちで、バイはライセンス費が継続的に発生する点も判断材料です。

ここで一つ、先に反論しておきます。「自社開発の方がコントロールできるから、迷ったらビルドを選ぶべきでは」と思うかもしれません。短期的にはその通りですが、Apexで書いた独自ロジックは、開発した本人が抜けた瞬間に「誰も触れないブラックボックス」になりがちです。業界共通の作業まで自社実装で抱え込むと、差別化に使うべき開発リソースが保守に食われ続けます。

• フローのループ処理や複雑な条件分岐がガバナ制限に抵触する場合
• 外部APIとの複雑な認証・レスポンス処理（OAuth、ページネーション処理等）
• 標準UIでは表現できない独自の画面体験
• 大量データの一括処理（Batch Apex、Queueable Apex）

設計原則は「フローで実現できないことが確定してからApexに進む」こと。Apexで書かれたロジックは非エンジニアが保守できないため、保守契約の要否に直結します。

例えば、「他システムの在庫情報をSalesforceの商談画面にリアルタイム表示したい」という要望が来たとき、まずリアルタイム性が本当に必要か（5分〜1時間の遅延で業務上問題ないか）を確認します。多くの場合、要件を精査するとバッチ連携で十分なことが分かり、実装コストを大きく抑えられます。「リアルタイム」という言葉は、救急車のサイレンのように聞こえた瞬間に全員を身構えさせますが、実際に必要なのは「今日中に届けばいい」程度の速さであることが大半です。

Sandbox種別

Developer（データなし・小規模開発用）、Partial Copy（本番データの一部）、Full（本番全データ複製・最終検証用）

開発〜本番の流れ

開発（Sandbox）→レビュー→UAT（Partial/Full Sandbox）→本番反映（Change Set／メタデータAPI／CIパイプライン）

バージョン管理

メタデータをGit管理し、変更差分をレビュー可能にする。直接本番編集を避けるのが原則

Change Set中心の運用から脱却し、メタデータをGit管理してCI/CDに乗せる際の中核ツールがSalesforce CLI（現行の`sf`コマンド。旧`sfdx`コマンドも互換運用されている）です。GUIでのポチポチ作業に依存しない、再現可能なデプロイフローを組めるのが最大の利点です。

組織への接続（org login）

`sf org login web` でブラウザ認証し、対象orgをローカルCLIに紐づける。複数org（開発用スクラッチorg・Sandbox・本番）をalias名で使い分けるのが基本

スクラッチ組織（scratch org）

`sf org create scratch` で使い捨ての検証用組織を数分で払い出せる。機能単位のブランチごとにスクラッチorgを作り、動作確認後に破棄する開発スタイルが、Sandboxベースの運用より高速

メタデータの取得・反映

`sf project retrieve start` でorgからローカルへメタデータを取得し、`sf project deploy start` でローカルの変更をorgへデプロイする。この2コマンドがGitとorgをつなぐ基本動線

デプロイ前検証（dry-run）

`sf project deploy start --dry-run` で、実際にデプロイする前にテストクラス実行や依存関係チェックだけを走らせられる。本番デプロイ前の必須ステップ

package.xmlによる対象指定

デプロイ・取得の対象メタデータをpackage.xmlで明示的に指定できる。差分だけを扱う運用にすることで、意図しないメタデータの巻き込みデプロイを防げる

CI/CDパイプラインへの組み込み

GitHub Actions等のCIでPRごとにスクラッチorgを立て、`sf project deploy start`と自動テストを実行し、マージ後に本番へデプロイする、というフローが典型。CLIがスクリプトから呼べることがCI化の前提条件

小規模な運用ではSandbox＋Change Setで十分なケースも多く、CLI導入自体が目的化しないよう注意が必要です。「変更のレビューをGit上で行いたい」「デプロイを自動化・再現可能にしたい」というニーズが具体的に出てきた段階で検討するのが実務的な導入タイミングです。着手前に確認すべき事項はSalesforce構築前の環境確認チェックリストにまとめています。

連携方式（リアルタイムかバッチか）はどう決めればいいですか

「即時性が必要か」「データ量はどの程度か」「失敗時に誰が気づき、どう復旧するか」の3点で判断するのが実務的です。過剰にリアルタイム性を求めると実装コストが跳ね上がるため、要件段階で本当に必要な鮮度を確認することが重要です

AppExchangeアプリを使うか、自社で作り込むかはどう判断しますか

「これは自社の差別化要素か、業界共通の作業か」が最初の分岐です。競合優位性に直結する独自ロジックはビルド、名刺管理や電子署名のような業界標準機能はバイ（既製品導入）が基本的な判断基準になります

本番環境への変更は直接行ってもいいですか

一般的には推奨されません。Sandboxで開発・レビューし、メタデータをGit管理した変更差分としてデプロイする流れが標準とされています。直接本番編集は変更履歴が残らず、問題発生時の切り戻しが困難になります

直近で「リアルタイム連携したい」「自社で作り込みたい」と言われた要件のうち、実際にその必要性を数字（許容遅延・利用頻度・保守にかけられる工数）で確認したものはいくつあるでしょうか。言葉の勢いだけで方式を決めてしまった要件が残っていないか、一度棚卸しする価値があります。