執筆者：Salesforce コンサルタント
背景と適用シナリオ
現代のビジネス環境では、単一のシステムで業務が完結することは稀です。顧客管理は Salesforce、在庫管理は外部の ERP システム、配送状況の確認は運送会社の API、与信チェックは専門の金融サービスといったように、複数のシステムが連携しあって初めて、一貫性のある優れた顧客体験を提供できます。このようなシステム間連携、すなわちインテグレーションは、ビジネスの成功に不可欠な要素となっています。
従来、Salesforce と外部システムを連携させるには、Apex (エイペックス) を用いたカスタムコード開発が主流でした。このアプローチは非常に柔軟性が高い一方で、開発には専門的なスキル、時間、そしてコストを要します。また、一度開発した連携ロジックのメンテナンスや仕様変更への対応も、開発者に依存するため、ビジネスの俊敏性を損なう一因となることもありました。
このような課題を解決するために登場したのが、External Services (外部サービス) です。External Services は、プログラミングコードを記述することなく、外部の REST API を Salesforce の Flow (フロー) やその他の宣言的ツールから呼び出せるようにする画期的な機能です。これにより、Salesforce 管理者やビジネスアナリストといった、コード開発を専門としない方々でも、クリック操作で簡単に外部システムとの連携を構築できるようになります。
コンサルタントとして、私たちがお客様に External Services を提案する典型的なシナリオは以下の通りです。
- リアルタイムでのデータ照会：商談成立時に、外部の与信調査サービスの API を呼び出し、顧客の与信情報をリアルタイムに取得して Salesforce のレコードに反映させる。
- 外部システムへのデータ登録：ケースがクローズされた際に、外部のアンケート配信システムの API を呼び出し、顧客に満足度調査のメールを自動送信する。
- マスタデータ連携：外部の ERP システムで管理されている商品マスタの情報を、Salesforce 内で定期的に、あるいは必要に応じて取得し、価格表を更新する。
- 業務プロセスの自動化：注文が確定したら、運送会社の API を呼び出して配送ラベルを作成し、追跡番号を取得して Salesforce の注文オブジェクトに保存する。
これらのシナリオを、従来であれば数週間から数ヶ月かかっていた開発プロジェクトではなく、数時間から数日で実装できる可能性があること、それが External Services の最大のビジネス価値です。
原理説明
External Services の仕組みを理解する上で、いくつかの重要な専門用語を把握する必要があります。ここでは、その中核となるコンセプトを解説します。
OpenAPI Specification (OpenAPI 仕様)
External Services の心臓部とも言えるのが、OpenAPI Specification です。これは、REST API の構造を記述するための業界標準のフォーマットであり、以前は Swagger (スワッガー) と呼ばれていました。この仕様書（通常は JSON または YAML 形式のファイル）には、API がどのような操作（GET, POST, PUT, DELETE など）を提供しているか、各操作がどのような入力（パラメータ）を必要とし、どのような出力（レスポンス）を返すかが、機械が読み取り可能な形式で詳細に定義されています。
External Services は、この OpenAPI 仕様書を「設計図」として読み込みます。Salesforce は仕様書の内容を解析し、定義されている各 API 操作を、Salesforce プラットフォーム上でネイティブに実行できるアクションへと自動的に変換します。
Named Credential (指定ログイン情報)
外部 API を呼び出す際には、エンドポイント URL (API の所在地) と、多くの場合、認証情報（API キー、ユーザ名/パスワード、OAuth トークンなど）が必要になります。これらの情報を Flow や Apex コード内に直接ハードコーディングすることは、セキュリティ上もメンテナンス上も非常に危険な行為です。環境（Sandbox, 本番環境など）ごとに URL が異なる場合、その都度コードを修正しなければなりません。
この問題を解決するのが Named Credential (指定ログイン情報) です。Named Credential は、API のエンドポイント URL と認証情報を一元的に、かつ安全に管理するための Salesforce の標準機能です。External Services を登録する際には、この Named Credential を指定します。これにより、Salesforce は認証プロセスを自動的に処理してくれるため、私たちは API の呼び出しロジックに集中できます。また、本番環境への移行時も、Named Credential の設定を変更するだけで対応でき、Flow などを修正する必要がありません。
Invocable Actions (呼び出し可能なアクション)
OpenAPI 仕様書を External Services に登録し、Named Credential を関連付けると、Salesforce は仕様書に定義された各 API 操作に対応する Invocable Actions (呼び出し可能なアクション) を自動生成します。これらのアクションは、Flow Builder の「アクション」要素から簡単に検索して利用できるようになります。
例えば、OpenAPI 仕様書に「`getUser`」と「`createUser`」という二つの操作が定義されていれば、Flow Builder には「Get User」と「Create User」という二つのアクションが表示されます。これらのアクションには、仕様書で定義された入力パラメータ（例：ユーザ ID）と出力パラメータ（例：ユーザ情報）が自動的にマッピングされており、ユーザは Flow の変数を使ってこれらのパラメータを簡単に設定・取得できます。
このプロセス全体をまとめると、以下のようになります。
外部 API の OpenAPI 仕様書を入手 → Named Credential で接続情報と認証を定義 → External Services に仕様書と Named Credential を登録 → Flow Builder で自動生成されたアクションを呼び出す
このように、宣言的な設定を組み合わせるだけで、複雑な API 連携が実現できるのです。
示例代码
ここでは、Salesforce の公式ドキュメントでよく使用される、シンプルな銀行口座サービスを例にした OpenAPI 2.0 (Swagger 2.0) 仕様書のサンプルを紹介します。この仕様書は、口座の追加 (`addAccount`) と、特定の口座情報の取得 (`getAccount`) という二つの操作を定義しています。
このスキーマを External Services に登録すると、「addAccount」と「getAccount」という 2 つの呼び出し可能なアクションが Flow で利用できるようになります。
{
"swagger": "2.0",
"info": {
"title": "Bank Service",
"description": "API for a bank service.",
"version": "1.0"
},
"host": "my_bank.com",
"schemes": [
"https"
],
"paths": {
"/accounts": {
"post": {
"summary": "Add Account",
"description": "Creates a new bank account.",
"operationId": "addAccount",
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"parameters": [
{
"name": "body",
"in": "body",
"description": "Account object",
"required": true,
"schema": {
"$ref": "#/definitions/Account"
}
}
],
"responses": {
"200": {
"description": "Success"
}
}
}
},
"/accounts/{accountId}": {
"get": {
"summary": "Get Account by ID",
"description": "Returns a single account.",
"operationId": "getAccount",
"produces": [
"application/json"
],
"parameters": [
{
"name": "accountId",
"in": "path",
"description": "ID of the account to return",
"required": true,
"type": "string"
}
],
"responses": {
"200": {
"description": "Success",
"schema": {
"$ref": "#/definitions/Account"
}
}
}
}
}
},
"definitions": {
"Account": {
"type": "object",
"properties": {
"name": {
"type": "string"
},
"balance": {
"type": "number"
}
}
}
}
}
コードの解説
swagger: "2.0": このドキュメントが OpenAPI 2.0 仕様に準拠していることを示します。info: API のメタデータ（タイトル、説明、バージョン）を定義します。paths: API が提供するエンドポイント（URL パス）と、それらに対する HTTP メソッド（`get`, `post` など）を定義するセクションです。/accounts(`post`):operationId: "addAccount": この操作の一意の ID です。Salesforce はこれをもとにアクション名（`addAccount`）を生成します。parameters: この操作が受け取る入力を定義します。ここでは `body` として `Account` オブジェクトを受け取ります。
/accounts/{accountId}(`get`):operationId: "getAccount": `getAccount` アクションを生成します。parameters: URL パスの一部として `accountId` を受け取ることを定義しています (`in: "path"`)。
definitions: API で使用されるデータモデル（スキーマ）を定義します。ここでは `Account` というオブジェクトが `name` (文字列) と `balance` (数値) というプロパティを持つことを定義しています。この定義は、Flow 内でアクションの入力および出力変数として自動的に Apex 定義型に変換されます。
この仕様書を理解することで、Flow でアクションを利用する際に、どのような入力が必要で、どのような出力が返ってくるかを正確に把握することができます。
注意事項
External Services は非常に強力なツールですが、コンサルタントとして導入を支援する際には、いくつかの制約と注意点を顧客に明確に伝える責任があります。
権限 (Permissions)
External Services を設定するには、ユーザに「アプリケーションのカスタマイズ」権限が必要です。また、External Services を呼び出す Flow を実行するユーザには、その Flow を実行する権限と、関連する Named Credential を利用する権限が必要です。プロファイルや権限セットで適切に設定されているかを確認することが重要です。
API 制限 (API Limits)
Salesforce には、プラットフォームの安定性を保つための様々なガバナ制限が存在し、External Services の呼び出しも例外ではありません。
- コールアウトの合計数：1 トランザクション内で実行できる DML ステートメント、SOQL クエリ、コールアウトの数には上限があります。Flow 内でループ処理を行い、多数のコールアウトを実行しようとすると、この制限に抵触する可能性があります。
- 仕様のサイズと複雑さ：登録できる OpenAPI 仕様のサイズには上限があります（例：100KB）。また、定義できるオブジェクトの数や操作の数にも制限があります。非常に大規模で複雑な API の場合は、API の一部だけを定義した仕様書を複数作成し、別々の External Service として登録するなどの工夫が必要になる場合があります。
- タイムアウト：外部 API からの応答が遅い場合、コールアウトはタイムアウトします（デフォルトは 10 秒、最大 120 秒）。応答に時間がかかる可能性のある API を呼び出す場合は、Named Credential でタイムアウト値を適切に設定する必要があります。
エラー処理 (Error Handling)
外部システムは常に正常に稼働しているとは限りません。ネットワークの問題、API サーバのダウン、認証情報の誤りなど、様々な理由で API 呼び出しは失敗する可能性があります。Flow を設計する際には、必ずフォルトパス (Fault Path) を設定し、エラー発生時の処理を定義する必要があります。
例えば、API 呼び出しが失敗した場合に、
- エラー内容をカスタムオブジェクトに記録する。
- システム管理者にメールで通知する。
- 画面フローの場合は、ユーザに分かりやすいエラーメッセージを表示する。
OpenAPI 仕様の制約
External Services は OpenAPI 仕様の全てをサポートしているわけではありません。以下のような、サポートされていない、または部分的にしかサポートされていない機能が存在します。
- OpenAPI 3.0 の一部の高度な機能
- `oneOf`, `anyOf`, `allOf`, `not` といった複合スキーマ
- XML (`application/xml`) 形式のレスポンス（JSON のみがサポートされます）
- 一部の複雑な認証タイプ
まとめとベストプラクティス
External Services は、Salesforce プラットフォームにおけるインテグレーションの民主化を推し進める、非常に価値のある機能です。コード開発の壁を取り払い、ビジネスの変化に迅速に対応できる宣言的な連携を実現することで、お客様のデジタルトランスフォーメーションを加速させることができます。
コンサルタントとして、External Services を最大限に活用し、プロジェクトを成功に導くためのベストプラクティスを以下に示します。
- API 仕様の事前検証を徹底する：プロジェクトの初期段階で、連携対象の API の OpenAPI 仕様書を入手し、それが正確で、かつ External Services の制約に準拠しているかを徹底的に検証します。必要であれば、API 提供元の開発者と協力して仕様書を修正します。
- 必ず Named Credential を使用する：セキュリティ、メンテナンス性、環境間の移行の容易さを考慮し、API のエンドポイントと認証情報は必ず Named Credential で管理します。
- 堅牢なエラーハンドリングを実装する：「うまくいかなかったらどうするか」を常に考え、Flow には必ずフォルトパスを実装します。ユーザ体験とシステムの信頼性を損なわないための必須事項です。
- 処理をモジュール化する：API 呼び出しを行う Flow は、それ単体で完結するサブフローとして作成することを推奨します。これにより、同じ API 呼び出しを複数の異なるプロセスから再利用できるようになり、メンテナンス性が向上します。
- ガバナ制限を意識した設計を行う：特に、ループ内での API 呼び出しは慎重に設計します。一度に大量のデータを処理する必要がある場合は、プラットフォームイベントと組み合わせた非同期処理など、別のアーキテクチャを検討します。
External Services を正しく理解し、これらのベストプラクティスを適用することで、私たちはコーディングを行うことなく、安全かつ効率的に Salesforce と外部の世界を繋ぎ、お客様のビジネスに新たな価値を提供することができるのです。
コメント
コメントを投稿