---
title: Salesforce認定Platform Integrationアーキテクト試験向け「インテグレーションパターン」概説
tags:  #salesforce #salesforce認定integrationアーキテクト #システム #アーキテクチャ #アーキテクト #archjapan  
author: [Yuji Horikoshi](https://www.docswell.com/user/yuji_horikoshi)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/LJ319642E5.jpg?width=480
description: Salesforce認定Platform Integrationアーキテクト資格をネタに、Salesforceと他システムの連携の全体感を概説します。 その中でも、特に中心となる「インテグレーションパターン」についてのイメージを中心に説明します。  【Salesforceと他システムの連携の全体感】 ① システムランドスケープの把握 ② ビジネスニーズの評価 ③ システム要件・設計・実装: 「インテグレーションパターン」の選定・実装 ④ 連携機能における保守  【インテグレーションパターン】のイメージ ・インテグレーションパターン6種を眺めてみましょう ・3層(UI、Process、Data)に分けて連携イメージを整理しています
published: September 20, 25
canonical: https://www.docswell.com/s/yuji_horikoshi/K13EEP-2025-09-20-105553
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/LJ319642E5.jpg)

Salesforce認定
Platform Integrationアーキテクト試験向け
「インテグレーションパターン」概説
2025/9/18
SalesforceArchitectMeetup
#archjapan


# Page. 2

![Page Image](https://bcdn.docswell.com/page/8JDXGVQ67G.jpg)

WHO ARE YOU?
堀越 悠久史 (ホリコシ ユウジ)
https://www.salesforce.com/trailblazer/yuji-horikoshi
X: https://x.com/yuji_horikoshi
Salesforce歴7～8年目。x14 Salesforce Certifications.
Salesforce認定システムアーキテクト
Salesforce認定アプリケーションアーキテクト
etc.
SIer(電通総研)でSalesforce案件の導入とかを 7年ちょい、
2025年7月からはマネーフォワードに転職して
AppExchangeを育て始めました。
ITストラテジスト・情報処理安全確保支援士。
湘南エリア住み。


# Page. 3

![Page Image](https://bcdn.docswell.com/page/VEPP3VGZE8.jpg)

ちょっとだけお仕事の話
マネーフォワードクラウド ERPシリーズ に連携する AppExchange製品の
企画と開発をプロダクトマネージャとしてリードしています。
(といっても転職したてなので、まだ 3か月経ってないくらい )
【目下の悩み】
① 転職してSalesforceの使い手が周囲から激減 …。自分から情報を取りにいかないとマズい
② ビジネス的には、そもそもマネフォが AppExchangeを出してるのが界隈で知られていない …
ということで、もしよかったら、
“マネフォ AppExchange”
で検索してみてください！
Salesforceで「お金周り」 (“請求”とか”売掛金回収 ”とか”契約”とか)が出てきたら、マネフォ連携で楽ができるか
も？


# Page. 4

![Page Image](https://bcdn.docswell.com/page/27V24Z6M7Q.jpg)

本題


# Page. 5

![Page Image](https://bcdn.docswell.com/page/5JGR14NX7L.jpg)

お題
●
Integrationアーキテクト資格をネタにSalesforceと他システムの連携をさらっと
○ システムランドスケープの把握
○ ビジネスニーズの評価
○ 「インテグレーションパターン」の選定・実装
○ メンテナンスとか
●
インテグレーションパターン6種を眺めてみましょう
○ 3層(UI、Process、Data)で整理してみると良いかも


# Page. 6

![Page Image](https://bcdn.docswell.com/page/47QVDGQ5EP.jpg)

Salesforce認定Integrationアーキテクトとは
Salesforce Platform との安全で拡張性が高いインテグレーションを設計するために必
要なインテグレーション要件を評価します。
このアーキテクトは各種のプラットフォームで複雑なインテグレーションパターン を設計・
実装した経験のほか、ソリューションと設計上のトレードオフ について、ビジネス分野・テ
クニカル分野の両関係者に説明した経験を持っています。
Salesforce 認定 Platform Integration アーキテクト受験ガイド
https://trailhead.salesforce.com/ja/help?article=Salesforce-Certified-Platform-Integration-Architect-Exam-Guide


# Page. 7

![Page Image](https://bcdn.docswell.com/page/KE4MZ5NV71.jpg)

CTAジャーニーからの位置づけ: システムアーキテクト系


# Page. 8

![Page Image](https://bcdn.docswell.com/page/L718RW54JG.jpg)

Integrationのユースケース
●
コールセンター (Service Cloud）
○
○
●
営業向け (Sales Cloud)
○
○
○
●
顧客の取引状況をSalesforceの画面に出す。取引状況のデータは別システムにあるのでリアルタイムでデー
タをとってくる。 ⇒ コールアウト[要求と返信]
「入金がまだなんですけど」みたいな督促する別システムがあって、その結果情報をバッチで受領する
⇒
DataLoaderを定期実行 (仕方なくバッチ方式になった)
帳票出力サービス(AppExchangeにもあるやつ)での帳票作成。事情があってApexでコールアウト。
受注できて契約できたら基幹システムにデータ登録。
データ登録できた結果を逆にSalesforceへAPI連携(リモートコールイン)し、ユーザーへ通知
申込受付システム (Experience Cloud)
○
eKYCサービスへのリクエスト。結果データ取得をコールアウト。
などなど...特に一定規模以上の組織になると、Salesforce単独で使うことのほうが珍しい


# Page. 9

![Page Image](https://bcdn.docswell.com/page/G7WZ165Z72.jpg)

Integrationアーキテクトになるとどうなるの？
●
年収が上がる...という保証はありませんが...頼られる存在にはなれるかと。
(頼られたら、会社が大事にしてくれるという保証もありませんが...)
●
システムアーキテクト系は「Salesforce以外」の知識が必要と思ってます
○ ネットワーク全般、セキュリティ系(認証・認可)などなどの知見
○ IPA「応用情報技術者試験」・「セキュリティスペシャリスト」が有利？
●
Salesforceっぽくないのが、Salesforce界隈で逆に希少価値？


# Page. 10

![Page Image](https://bcdn.docswell.com/page/4JZ1PYNLE3.jpg)

Integrationアーキテクトが居ないとどうなる？
●
連携先システム担当者のこれまでの経験や既存方式に基づいた方式に偏りがち
○ 設計フェーズ以降で「そもそも想定方式では実現不可」に気づいて大変なことに…
○ 「Salesforceを導入したのに顧客情報がリアルで見れないから今までと何も変わらないね。ラ
イセンス料でかえって高くなっただけだね」と、リリース後に言われるかも
●
例)
○
○
定期的に(10分間隔などで)更新がないかSF側からチェックしにいく方式でいいよね
■ そもそもオンプレ上のシステムにSalesforceから見に行けないじゃん、が発覚
「トランザクションデータ全量を夜間バッチ処理でコピーして移送」方式への偏り
■ データ同期の方式ありきで、企画段階なのに容量とか時間的制約が…とかの懸念解消
が先行しちゃう


# Page. 11

![Page Image](https://bcdn.docswell.com/page/YE6LMD8M7V.jpg)

Salesforce Integrationアーキテクトの理想像？
●
予算などの現実的制約とニーズのトレードオフから、関係者の納得を引き出せる
●
トレードオフ
○ ビジネスニーズから実現したい理想のシステム連携像
○ 現実の既存システムや予算・期間の制約
●
ありたき姿？
○ 将来像やネクストステップのイメージも示しながら
○ 現在可能な範囲でビジネスを成長させるシステム間の連携の実現を主導し
○ 関係者の納得を引き出せる


# Page. 12

![Page Image](https://bcdn.docswell.com/page/GE51Z39QJ4.jpg)

本日のお題、その他ご参考
●
公式のガイドライン（インテグレーションのパターンと実践）
https://developer.salesforce.com/docs/atlas.ja-jp.integration_patterns_and_practices.meta/integr
ation_patterns_and_practices/integ_pat_pat_summary.htm
●
「Salesforceインテグレーションパターンを整理する」
https://note.com/yuji_horikoshi/n/na5d00fe30611
○
●
今日の内容の主要部分「インテグレーションパターン」の整理を note にしてみたもの
クラウド時代のエンジニアが知っておくべき、顧客のビジネス課題を解決するクラウド間のシステ
ム連携/アーキテクチャ設計のステップ
https://logmi.jp/events/detail/3699
○
以前に TECH PLAYさんで講演したのをLogmiさんに拾ってもらったアーカイブ記事


# Page. 13

![Page Image](https://bcdn.docswell.com/page/9721RZ2WER.jpg)

Integrationアーキテクト試験の全体像


# Page. 14

![Page Image](https://bcdn.docswell.com/page/DJYZDRY9EM.jpg)

出題割合
現在のシステム環境の評価 : 8%
ビジネスニーズの評価 : 11%
ニーズからインテグレーション要件への変換: 22%
インテグレーションソリューションの設計: 28%
ソリューションの構築: 23%
インテグレーションのメンテナンス : 8%
: インテグレーションパターン


# Page. 15

![Page Image](https://bcdn.docswell.com/page/V7N36DPD78.jpg)

現在のシステム環境の評価: 8%
システム環境 = “システムランドスケープ”


# Page. 16

![Page Image](https://bcdn.docswell.com/page/YJ99LG38J3.jpg)

システムランドスケープの把握・評価
●
●
●
●
データや機能の所在: どのシステムに目的のデータがあるのか
標準(セキュリティポリシー等)、境界(オンプレかどうか)、制限、プロトコル
○ 標準: PCI DSSとか
○ 境界: 相手がオンプレでファイアウォールの内側だと大変
○ 制限・プロトコル: FTPじゃないとダメ、とかだとSalesforceからは無理…
制約や弱点を分析
○ 意外と稼働時間の差異とかが問題になることも
認証・認可の必要性／方式の把握
○ APIキーとかなのか
制約などから、実現可能な「接続の方向」や方式が決まってくる。
ランドスケープを把握しておくのはユーザー組織側でやるべきこと。


# Page. 17

![Page Image](https://bcdn.docswell.com/page/GJ89XVMZED.jpg)

システムランドスケープ
建築家(アーキテクト)が”全体像を描く対象 ”とは何か？
(単一の)ビル／システム
都市景観／システムランドスケープ


# Page. 18

![Page Image](https://bcdn.docswell.com/page/LJLW85317R.jpg)

(余談)XaaSの台頭とITアーキテクトの仕事の変化
一つのアプリケーション・システム
アプリケーション
アプリ基盤
アプリ基盤
ミドルウェア
導入・設定
ミドルウェア
導入・設定
OS
アプリ
機能
アプリ
機能
アプリ
機能
アプリ
機能
クラウド
設定
クラウド
設定
クラウド
設定
クラウド
設定
クラウド
クラウド
クラウド
クラウド
ハードウェア調達
(ほぼ単一の、モノリシックな )従来システム
XaaSを組み合わせるのが前提のシステム


# Page. 19

![Page Image](https://bcdn.docswell.com/page/47M963D5JW.jpg)

(余談)システムランドスケープ、めちゃくちゃ大事
●
●
当然、企業は複数のシステムを扱っている
連携していくと価値が上がる
○ 例1) 多重入力しなくて済む(従業員体験↑、ミス↓、作業時間↓)
○ 例2) SSOで別システムへ再ログイン不要(従業員体験↑、セキュリティ↑)
※SSOはIAMアーキテクトの範囲
●
(余談)マトモな連携方式に対応していないレガシーシステム = 競争力の低下へ
○ 労働人口↓・雇用流動↑: 従業員体験の悪い環境には人が行きたがらない
○ 連携処理のお守りが大変 = 保守する人が寄り付かない・離れたい
○ 連携処理の構築が大変/NW境界防御だけのセキュリティポリシー
⇒ システムが変革の足かせ → ビジネス上のビハインド拡大


# Page. 20

![Page Image](https://bcdn.docswell.com/page/P7RGPQ4ZJ9.jpg)

ビジネスニーズの評価: 11%
やりたいこと・できたら嬉しいことは何ですか


# Page. 21

![Page Image](https://bcdn.docswell.com/page/PJXX3521JX.jpg)

ビジネスニーズの把握
●
●
各インテグレーションに必要な機能要件・非機能要件をそれぞれ特定
○ 機能要件:
■ そもそも連携・自動化することで得られるビジネス価値は？
■ リアルタイムかどうか
● コールセンターで応対中に他システムのデータの参照が必要な時とか？
■ データの鮮度のビジネス影響
● 申込システムとコールセンターシステムが別の場合、申込直後に不明点が
あってコールセンターに問い合わせ電話してきたらどうなる？
○ 非機能要件:
■ 可用性 → 相手システムがダウンするかもしれないが、どうする？
■ 性能(キャパシティやコスト含む) → データの保持場所が悪いとコスト増
■ セキュリティ → 連携対象のデータが、機密データなのか公開データなのか
■ 運用 → 相手システム処理中、こっちがロールバックしたらどうなる？
時系列の読み: ビジネスの成長／規制の変化／相手システムの更改 etc.


# Page. 22

![Page Image](https://bcdn.docswell.com/page/3JKWY6MMJD.jpg)

ニーズからインテグレーション要件への変換: 22%
システムとしての実現アプローチを探る


# Page. 23

![Page Image](https://bcdn.docswell.com/page/LE3196Y275.jpg)

インテグレーションパターンの選定
やりたいこと
現在のシステム環境の評価 : 8%
全体像や制約
(やれる範囲)
ビジネスニーズの評価 : 11%
ニーズからインテグレーション要件への変換: 22%
やれる範囲の中で、
やりたいことのうち、実
現できうる方針
インテグレーションパターンに
沿い、ゼロから考えなくていい


# Page. 24

![Page Image](https://bcdn.docswell.com/page/8EDXGV56JG.jpg)

ニーズからインテグレーション要件への変換
●
●
●
●
既存システム環境に基づき、システムやインテグレーションパターンを棚卸
ユースケースとビジネスプロセスから、システムや処理の制約を評価
インテグレーションのセキュリティ要件、認証要件・認可要件を特定
パフォーマンス上のニーズ (処理量、応答時間、遅延) を特定
⇒ ビジネス要件を満たす適切なインテグレーションソリューション(実現方針)を提案
つまり、どのインテグレーションパターンを使うべきかを選択し、それを会話する


# Page. 25

![Page Image](https://bcdn.docswell.com/page/V7PP3VDZ78.jpg)

インテグレーションパターンのカタログ
●
●
パターンリスト
a. リモートプロセスの呼び出し — 要求と返信
b. リモートプロセスの呼び出し — ファイア・アンド・フォゲット
c. バッチデータの同期
d. リモートコールイン
e. データの変更に基づく UI の更新
f. データ仮想化
公式のガイドライン（インテグレーションのパターンと実践）
https://developer.salesforce.com/docs/atlas.ja-jp.integration_patterns_and_practices.met
a/integration_patterns_and_practices/integ_pat_pat_summary.htm
6つもあってイメージしにくいので、絵で整理して考えてみています


# Page. 26

![Page Image](https://bcdn.docswell.com/page/2JV24Z1MJQ.jpg)

User
UI/Presentation
Process
Data


# Page. 27

![Page Image](https://bcdn.docswell.com/page/5EGR142XJL.jpg)

User
リアルタイム向き
疎
処理特性
システム間
の結合度
バッチ処理向き
密
UI/Presentation
Process
Data


# Page. 28

![Page Image](https://bcdn.docswell.com/page/4JQVDGP57P.jpg)

なお公式ガイドラインでの整理の軸
●
インテグレーションのタイプ
○ プロセス
○ データ
○ (仮想)
■ (一部の)データベースの共有を実現する方式
●
同期／非同期
○ 同期: 相手の処理結果を待つ。処理結果の後続で処理が必要ならコッチ
○ 非同期: 相手の処理結果を待たない。投げっぱなし。


# Page. 29

![Page Image](https://bcdn.docswell.com/page/K74MZ5YVJ1.jpg)

a. リモートプロセスの呼び出し — 要求と返信
User
UI/Presentation
Process
Data


# Page. 30

![Page Image](https://bcdn.docswell.com/page/LJ18RW64EG.jpg)

b. リモートプロセスの呼び出し — ファイア・アンド・フォゲット
User
UI/Presentation
Process
Data


# Page. 31

![Page Image](https://bcdn.docswell.com/page/GJWZ16WZJ2.jpg)

c. バッチデータの同期
User
UI/Presentation
Process
Data


# Page. 32

![Page Image](https://bcdn.docswell.com/page/4EZ1PY5L73.jpg)

d. リモートコールイン
User
UI/Presentation
Process
Data


# Page. 33

![Page Image](https://bcdn.docswell.com/page/Y76LMD9MJV.jpg)

e. データの変更に基づく UI の更新
User
UI/Presentation
Process
Data


# Page. 34

![Page Image](https://bcdn.docswell.com/page/G751Z3NQE4.jpg)

f. データ仮想化
User
UI/Presentation
Process
Data


# Page. 35

![Page Image](https://bcdn.docswell.com/page/9J21RZ5W7R.jpg)

カタログにはないが、実践的にはありうるもの①: URLリンク
User
UI/Presentation
Process
Data
URLリンクで画面遷移。SSO・ディープリ
ンクに対応していたら最も容易。


# Page. 36

![Page Image](https://bcdn.docswell.com/page/DEYZDRK97M.jpg)

カタログにはないが、実践的にはありうるもの②: マッシュアップ
User
UI/Presentation
Process
Data
マッシュアップ 。CORS対応など必要だ
が、ないこともない。


# Page. 37

![Page Image](https://bcdn.docswell.com/page/VJN36DRDJ8.jpg)

インテグレーションソリューションの設計: 28%
ソリューションの構築: 23%
a. ～ f. の6パターンそれぞれで


# Page. 38

![Page Image](https://bcdn.docswell.com/page/YE99LGM8E3.jpg)

a. リモートプロセスの呼び出し — 要求と返信
User
UI/Presentation
Process
Data


# Page. 39

![Page Image](https://bcdn.docswell.com/page/GE89XVLZ7D.jpg)

b. リモートプロセスの呼び出し — ファイア・アンド・フォゲット
User
UI/Presentation
Process
Data


# Page. 40

![Page Image](https://bcdn.docswell.com/page/LELW85L1JR.jpg)

a/b. Apexコールアウト(リモートプロセス呼出)の考慮事項
●
Salesforce設定
○ 「リモートサイト」の設定
■ 相手先システムのURL
○ 「指定ログイン情報」の設定
■ 相手先システムの認証にかかる内容
※接続キー情報などのハードコードを避けるため
●
考慮事項 (特にバッチ処理的にまとまったデータを連携する場合)
○ タイムアウト(MAX120秒)
○ Apexのガバナ制限
○ 制限が厳しいなら非同期化を検討


# Page. 41

![Page Image](https://bcdn.docswell.com/page/4JM963M5EW.jpg)

c. バッチデータの同期
User
UI/Presentation
Process
Data


# Page. 42

![Page Image](https://bcdn.docswell.com/page/PJRGPQVZE9.jpg)

c. バッチデータ同期の考慮事項
●
ツール選定
○ 安く簡単に済ませるならDataLoaderとスクリプト
○ ETL
●
データの関係性の検討がより重要 ⇒ Dataアーキテクトの知見
○ 相手システムのどのデータを連携するか
○ データ同士の関係(参照／主従)を相手システムにどう同期するか
○ データ状態をどう考慮するか
■ シンプルに全量 or 未連携・更新されたもののみを移送


# Page. 43

![Page Image](https://bcdn.docswell.com/page/PEXX35Z1EX.jpg)

d. リモートコールイン
User
UI/Presentation
Process
Data


# Page. 44

![Page Image](https://bcdn.docswell.com/page/3EKWY68MED.jpg)

d. リモートコールインの考慮事項
●
●
Salesforce設定
○ 「外部クライアントアプリケーション」(接続アプリケーション)の設定
■ Salesforce側の接続ユーザーと認証方式
考慮事項 (特にバッチ処理的にまとまったデータが連携される場合)
○ Apexのガバナ制限
○ 制限が厳しいなら非同期化やデータ同期を検討


# Page. 45

![Page Image](https://bcdn.docswell.com/page/L7319622J5.jpg)

e. データの変更に基づく UI の更新
User
UI/Presentation
Process
Data


# Page. 46

![Page Image](https://bcdn.docswell.com/page/87DXGVZ6EG.jpg)

e. データ変更に伴うUI更新の考慮事項
●
そもそものユースケースとは？
○ ユーザーによるビジネス状況のリアルタイムモニタリング
■ JS(LWC)で画面をつくって対応など。難度は相応に高いはず
○ カスタム通知でユーザーに更新を連絡
●
Salesforce設定
○ 「プラットフォームイベント」
○ 「プラットフォームイベントトリガーフロー」で処理を動かす
○ レコード更新が前提ならレコードトリガーフローでも可
■ でも相手システムへの応答性は気になるのでイベント経由がいいと思う


# Page. 47

![Page Image](https://bcdn.docswell.com/page/VJPP3VYZJ8.jpg)

f. データ仮想化
User
UI/Presentation
Process
Data


# Page. 48

![Page Image](https://bcdn.docswell.com/page/2EV24ZGMEQ.jpg)

f. データ仮想化の考慮事項
●
「Salesforce Connect」によるもの
○ 相手先システムのデータベースと密結合(というかDBの一部を共有)する形
○ リアルタイム・同期的な処理
○ 一方、相手先システムのデータベースとの接続性が最大のネックのハズ
■ Salesforceからの通信パケットをどの経路で通すのか(セキュリティ？)
■ 相手先DBをメンテナンスしたいときはどうするのか
●
私はやった実績ないので語れません！
○ かなりの難度？難度に見合うだけのユースケースがあるのかどうか…


# Page. 49

![Page Image](https://bcdn.docswell.com/page/57GR148XEL.jpg)

併せて考えたい、データの観点
●
●
システム間の繋ぎこみができたとしても、「ちゃんと意味がある」連携かは別。
「意味がある」: 中身のデータが両システム間で整合していることが前提
○ 例) 同じ「取引先」でも、システムごとに関心事(Concern)が違う
■ 取引先 = 営業先、納品先、請求先(代金回収先)...
●
連携の設計時に重要なテクニック
○ 外部システム(RDB前提)内でのデータレコードの識別とデータの関係性をどう再現するか
※相手の「キーの持ち方」の理解がポイント (そのまま業務理解も必要に)
※Salesforceでは、「外部ID」などのテクニックで再現する
●
つよつよアーキテクトになるためには、「Dataアーキテクト」も欲しいかも


# Page. 50

![Page Image](https://bcdn.docswell.com/page/4EQVDG95JP.jpg)

併せて考えたい、認証と認可とユーザーの観点
●
●
●
Salesforceへのリモートコールインはユーザー認証を必要とする
○ OAuth2の対応しているフロー
■ 相手先システムがこれに対応しているかがポイント
○ Salesforce側のユーザーをどうするか
■ 連携専用のユーザーが望ましい
● Integration User ライセンス
■ このユーザーに付与すべき権限をどうするか
(若干余談)「接続元・先を(IPで)限定したいんだけど…」の要件(？)にどう対応するか
○ レガシーシステムを抱えていると、ありがち。
IAMアーキテクトでバッチリ抑えられていると自信が持てそう


# Page. 51

![Page Image](https://bcdn.docswell.com/page/KJ4MZ5XVE1.jpg)

併せて考えたい、テスト・開発計画の観点
●
連携が伴うと比較的大きめの開発や保守になる傾向
○ まずSalesforce側が、「本番組織で開発」はないはず
○ Salesforce側はSandboxを使うとして、相手先システムはどうするか
○ 相手先システム側も開発していると、合流点の調整も必要
●
相手先システムとの調整事項
○ いつ・どういうタイミングで
○ どの環境を利用し
○ どの実施主体が
○ どんなテスト・検証内容を実施するか
計画・調整はPjMかもしれませんが、内容はアーキテクトじゃないと分からないはず


# Page. 52

![Page Image](https://bcdn.docswell.com/page/LE18RWN47G.jpg)

インテグレーションのメンテナンス: 8%
連携すると、それだけ複雑化するということ


# Page. 53

![Page Image](https://bcdn.docswell.com/page/GEWZ164ZE2.jpg)

インテグレーションのメンテナンス
●
●
●
処理が失敗した場合の適切なエラー処理、エスカレーション、復旧手順
パフォーマンスとその監視
監視レポート


# Page. 54

![Page Image](https://bcdn.docswell.com/page/47Z1PY2LJ3.jpg)

インテグレーションあるある。実運用上で要検討のもの
●
●
●
ときどき通信エラー、というのは必ず起こるもの
○ Request Timeout になる
通信エラーが起こるなら、リトライする実装にする？ほんと？
○ 実は相手システムに届いていてDB更新に成功したが応答が遅いだけかも…
○ もし、決済処理とかだったら…？
→ こういうのは、KISS原則: Keep It Simple, Stupid! に尽きる
どうするかは相手とビジネス要件次第が基本だが、以下の考慮はあるべき
○ 呼出や対象データを後から特定でき、相手システムと認識合わせできること
■ そのためにログの仕掛けも必要になるかも
○ エラーを誰がどう検知するか (監視／レポーティング)
○ 復旧方法 (静観でいいならそれが楽)


# Page. 55

![Page Image](https://bcdn.docswell.com/page/YJ6LMDVMEV.jpg)

まとめと所感
まとまってない


# Page. 56

![Page Image](https://bcdn.docswell.com/page/GJ51Z3DQ74.jpg)

まとめと所感
●
●
●
Integrationアーキテクト資格をネタに、Salesforceと他システムの連携を概観
○ システムランドスケープの把握
○ ビジネスニーズの評価
○ 「インテグレーションパターン」の選定・実装
○ メンテナンスとか
インテグレーションパターン6種
○ 3層(UI、Process、Data)で整理してみると良いかも
所感: 「Integration、奥深い、幅広い」
○ Salesforceアーキテクト系のなかで、一番Salesforceっぽくない気がする
○ 奥深くて幅広い分、連携するだけの価値はある