SalesforceのAPIの呼び出し方法や仕組み、注意点を解説

Salesforce APIは、外部システムとSalesforceを連携させるための強力なツールです。データの取得や更新、削除といった操作をプログラムから実行できるため、業務の自動化や効率化に欠かせない技術となっています。

しかし、APIの呼び出しには認証の仕組みや制限事項など、理解しておくべきポイントが数多く存在します。適切な知識なしに実装を進めると、セキュリティリスクやパフォーマンスの問題に直面する可能性があります。

本記事では、Salesforceの導入サポート、開発・連携を行う(株)FDCのエンジニアチームが、Salesforce APIの呼び出しについて、基本的な仕組みから具体的な実装方法、注意すべき制限事項まで、どなたにもわかりやすく解説していきます。

Salesforce APIの基本的な仕組みとは
1. APIとは何か：基礎知識
2. Salesforceが提供するAPI一覧
REST APIとSOAP APIの違いと選び方
Salesforce APIの認証方法：OAuth 2.0の仕組み
Salesforce APIの具体的な呼び出し方法
Salesforce API呼び出しの制限事項と注意点
API呼び出し時のセキュリティベストプラクティス
よくある認証エラーとトラブルシューティング
1. 主要な認証エラーと対処法
2. デバッグのチェックポイント
2025年以降の重要な変更点と今後の動向
まとめ

Salesforce APIの基本的な仕組みとは

Salesforce APIは、外部アプリケーションがSalesforceのデータやリソースにアクセスするためのインターフェースです。HTTPリクエストを通じてSalesforceとデータをやり取りし、顧客情報の取得や商談データの更新などの操作を実行できます。

APIを使用することで、手動での作業を自動化したり、複数のシステム間でリアルタイムにデータを同期したりすることが可能になります。これにより、業務効率が大幅に向上し、人的ミスを削減できます。

APIとは何か：基礎知識

API（Application Programming Interface）とは、異なるソフトウェアやシステムが互いに通信するための規約や手順を定めたものです。レストランで例えるなら、メニュー（API）を見て注文（リクエスト）すると、厨房（システム）が料理（データ）を提供してくれるイメージです。

Salesforce APIも同様に、決められた形式でリクエストを送信すると、Salesforceが処理を実行して結果を返してくれます。この仕組みにより、プログラムから自動的にSalesforceを操作できるようになります。

Salesforceが提供するAPI一覧

2025年現在、Salesforceでは用途に応じて複数のAPIを提供しています。主要なAPIは以下の通りです。

API名	用途	特徴
REST API	汎用的なデータ操作	軽量でモバイルやWeb開発に最適。JSON形式でデータをやり取り
SOAP API	複雑な処理や厳格な型定義が必要な場合	XML形式。エンタープライズ向けで堅牢な処理が可能
Bulk API / Bulk API 2.0	大量データの処理	数千〜数百万件のレコードを効率的に処理
Metadata API	組織の設定情報の取得・変更	カスタムオブジェクトやページレイアウトなどのメタデータを操作
Streaming API	リアルタイムデータ通知	データ変更をプッシュ通知で受信

それぞれのAPIには得意な領域があるため、実装する機能や処理するデータ量に応じて適切なAPIを選択することが重要です。

REST APIとSOAP APIの違いと選び方

Salesforceの代表的なAPIであるREST APIとSOAP APIは、それぞれ異なる特徴を持っています。どちらを選択するかは、開発するアプリケーションの要件によって決まります。

REST APIの特徴と適用シーン

REST APIは、軽量で柔軟性に優れたAPIで、最新のアプリケーション開発に広く採用されています。特徴は以下の通りです。

JSON形式またはXML形式でデータをやり取り（JSONが主流）
HTTPメソッド（GET、POST、PUT、PATCH、DELETE）を使用
シンプルなURL構造で直感的にアクセス可能
モバイルアプリケーションやWebアプリケーションに最適
学習コストが低く、実装が容易

REST APIは、リアルタイムでデータの読み書きが必要な場合や、軽量な処理を実行したい場合に適しています。例えば、モバイルアプリから顧客情報を検索したり、Webフォームからリード情報を登録したりする際に最適です。

SOAP APIの特徴と適用シーン

SOAP APIは、より厳格なプロトコルに基づいたAPIで、エンタープライズ向けの統合に適しています。特徴は以下の通りです。

XML形式でリクエストとレスポンスをやり取り
WSDLファイルによる厳密な型定義
複雑な処理や複数の操作を一度に実行可能
エラーハンドリングが堅牢
トランザクション処理に対応

SOAP APIは、複雑なビジネスロジックを実装する場合や、厳格なセキュリティ要件がある場合に適しています。ただし、2027年のSummer ’27リリースでSOAP API login()メソッドが廃止される予定ですので、新規開発ではOAuth 2.0認証への移行が推奨されています。

どちらのAPIを選ぶべきか

API選択の基準は以下のように考えるとよいでしょう。

選択基準	REST API	SOAP API
開発の容易さ	◎ シンプルで学習しやすい	△ 学習コストが高い
データ形式	JSON（軽量）	XML（厳密な型定義）
モバイル対応	◎ 最適	△ オーバーヘッドが大きい
複雑な処理	△ シンプルな操作向け	◎ 複雑な処理に対応
推奨度（2025年現在）	◎ 新規開発で推奨	△ 既存システムのみ

一般的には、特別な理由がない限りREST APIの使用が推奨されます。軽量で実装が容易であり、現代的な開発スタイルに適しているためです。

Salesforce APIの認証方法：OAuth 2.0の仕組み

Salesforce APIを呼び出す際には、必ず認証プロセスを経る必要があります。これは、正規のユーザーやアプリケーションのみがSalesforceのデータにアクセスできるようにするためのセキュリティ対策です。

OAuth 2.0とは

OAuth 2.0は、トークンの交換を通してアプリケーション間の安全なデータ共有を認証するオープンプロトコルです。パスワードを直接扱わずに安全に認証を行えるため、現在最も推奨されている認証方式となっています。

OAuth 2.0では、ユーザーが認証に成功すると「アクセストークン」という一時的な認証情報が発行されます。このトークンをAPIリクエストに含めることで、Salesforceはリクエストの正当性を確認し、データへのアクセスを許可します。

主要な認証フロー

Salesforceでは、用途に応じて複数のOAuth 2.0認証フローを提供しています。

Webサーバーフロー：Webアプリケーション向けで最も推奨される方法。認証コードとアクセストークンを使用
JWTベアラーフロー：サーバー間連携向け。ユーザー操作不要で自動化されたバッチ処理に最適
リフレッシュトークンフロー：有効期限が切れたアクセストークンを再取得するために使用
クライアントクレデンシャルフロー：アプリケーション自体の認証に使用

接続アプリケーションの設定

OAuth 2.0認証を実装する前に、Salesforceで「接続アプリケーション」を作成する必要があります。接続アプリケーションは、外部アプリケーションとSalesforceを統合するためのフレームワークで、APIや標準プロトコルを使用して認証・認可を管理します。

接続アプリケーションの作成手順は以下の通りです。

Salesforceの[設定]から[アプリケーションマネージャー]を開く
[新規接続アプリケーション]をクリック
基本情報（アプリケーション名、API名、連絡先メールなど）を入力
[OAuth設定の有効化]にチェックを入れる
コールバックURL（認証後のリダイレクト先）を設定
必要なOAuthスコープ（アクセス権限）を選択
保存して完了

なお、2025年9月以降、組織に正式にインストールされていない接続アプリケーションの新規利用が制限されています。そのため、接続アプリケーションを使用する際は、必ず組織にインストールする必要があります。

Salesforce APIの具体的な呼び出し方法

ここでは、実際にREST APIを使用してSalesforceのデータを呼び出す具体的な手順を解説します。

ステップ1：アクセストークンの取得

API呼び出しの前に、まずアクセストークンを取得する必要があります。Webサーバーフローの場合、以下の手順でトークンを取得します。

認証エンドポイントにユーザーをリダイレクト
ユーザーがSalesforceにログインして承認
認証コードが発行される
認証コードをアクセストークンに交換

トークンエンドポイント（https://login.salesforce.com/services/oauth2/token）に以下のパラメータを含めてPOSTリクエストを送信します。

grant_type：authorization_code
code：取得した認証コード
client_id：接続アプリケーションのコンシューマキー
client_secret：接続アプリケーションのコンシューマシークレット
redirect_uri：設定したコールバックURL

レスポンスとして、アクセストークンとリフレッシュトークンが返されます。アクセストークンは実際のAPI呼び出しに使用し、リフレッシュトークンはアクセストークンの有効期限が切れた際に新しいトークンを取得するために使用します。

ステップ2：APIエンドポイントへのリクエスト送信

アクセストークンを取得したら、実際にAPIを呼び出します。REST APIのエンドポイントは以下の形式です。

https://yourInstance.salesforce.com/services/data/vXX.X/resource

例えば、Accountオブジェクトの一覧を取得する場合は以下のようになります。

エンドポイント：https://yourInstance.salesforce.com/services/data/v61.0/sobjects/Account
HTTPメソッド：GET
Authorizationヘッダー：Bearer {アクセストークン}

ステップ3：レスポンスの処理

APIからのレスポンスはJSON形式で返されます。レスポンスには、リクエストした情報やエラーメッセージが含まれています。

正常なレスポンスの例：

HTTPステータスコード：200 OK
ボディ：取得したレコード情報（JSON形式）

エラーレスポンスの例：

HTTPステータスコード：401 Unauthorized（認証エラー）
ボディ：エラーの詳細情報（JSON形式）

レスポンスの内容を適切に処理し、エラーが発生した場合は適切なエラーハンドリングを実装することが重要です。

主要なAPI操作の例

REST APIでは、HTTPメソッドによって異なる操作を実行できます。

操作	HTTPメソッド	エンドポイント例
レコード取得	GET	/services/data/v61.0/sobjects/Account/{ID}
レコード作成	POST	/services/data/v61.0/sobjects/Account
レコード更新	PATCH	/services/data/v61.0/sobjects/Account/{ID}
レコード削除	DELETE	/services/data/v61.0/sobjects/Account/{ID}
SOQL検索	GET	/services/data/v61.0/query/?q={SOQL}

Salesforce API呼び出しの制限事項と注意点

Salesforce APIには、システムのパフォーマンスを保護し、すべてのユーザーに公平なリソースを提供するために、様々な制限（ガバナ制限）が設けられています。これらの制限を理解せずに実装を進めると、予期せぬエラーや処理の失敗につながるため、事前に把握しておくことが重要です。

24時間あたりのAPI呼び出し回数制限

Salesforceでは、組織のエディションごとに24時間あたりのAPI呼び出し回数に制限があります。2025年現在の制限は以下の通りです。

エディション	基本API制限	追加制限
Developer Edition	15,000回/日	–
Professional Edition	15,000回/日	ライセンス数 × 1,000回（最大1,000,000回）
Enterprise Edition	100,000回/日	ライセンス数 × 1,000回
Unlimited Edition	100,000回/日	ライセンス数 × 1,000回

例えば、Enterprise Editionで15ユーザーライセンスを持つ組織の場合、API呼び出し制限は「100,000 + (15 × 1,000) = 115,000回/日」となります。

同時API接続数の制限

24時間の合計制限に加えて、同時に実行できるAPI接続数にも制限があります。通常、組織あたり25の同時接続まで可能ですが、エディションや設定によって異なる場合があります。

API呼び出し回数の確認方法

現在の組織のAPI使用状況は、Salesforceの管理画面から確認できます。

Salesforceにログイン
[設定]を開く
[クイック検索]で「システムの概要」を検索
[API 要求数（この24時間以内）]で現在の使用状況を確認

定期的に使用状況を監視し、制限に近づいている場合は対策を講じることが重要です。

API制限を回避する方法

API呼び出し回数の制限を効果的に管理するためには、以下の対策が有効です。

Bulk APIの活用：大量データを処理する場合はBulk APIを使用することで、1回のリクエストで多数のレコードを処理できます
複合リクエストの使用：複数の操作を1つのリクエストにまとめることで、API呼び出し回数を削減できます
キャッシュの実装：頻繁にアクセスするデータはキャッシュして、不要なAPI呼び出しを削減します
バッチ処理の時間調整：大量のAPI呼び出しが必要な処理は、夜間など利用が少ない時間帯に実行します
エラーハンドリングとリトライ制御：制限エラー（HTTP 429）が発生した場合は、適切な間隔を空けてリトライします

その他の重要な制限事項

API呼び出し回数以外にも、以下のような制限があります。

制限項目	制限値
1回のリクエストで取得できるレコード数	通常2,000件まで
SOQLクエリの最大文字数	20,000文字
バッチサイズ（Bulk API）	最大10,000レコード/バッチ
APIタイムアウト	120秒（2分）

API呼び出し時のセキュリティベストプラクティス

Salesforce APIを安全に利用するためには、セキュリティを最優先に考慮した実装が必要です。適切なセキュリティ対策を講じることで、データ漏洩や不正アクセスのリスクを最小限に抑えることができます。

トークンの安全な管理

アクセストークンとリフレッシュトークンは、Salesforceのデータにアクセスするための鍵となる重要な情報です。これらのトークンが漏洩すると、第三者が不正にSalesforceにアクセスできてしまいます。

トークンは必ず暗号化して保存する
トークンをクライアント側（ブラウザやモバイルアプリ）に直接保存しない
環境変数や専用のシークレット管理サービス（AWS Secrets Manager、Azure Key Vaultなど）を使用する
定期的にトークンをローテーション（更新）する
ソースコードにトークンを直接記述しない

接続アプリケーションの適切な設定

接続アプリケーションの設定は、API連携のセキュリティに直接影響します。

最小権限の原則：必要最小限のOAuthスコープのみを付与する
IPアドレス制限：特定のIPアドレスからのアクセスのみを許可する設定を検討する
組織へのインストール：接続アプリケーションを組織にインストールして正式に承認する（2025年9月以降必須）
定期的な見直し：未使用の接続アプリケーションは削除する

通信のセキュリティ

APIリクエストの送信時には、通信経路のセキュリティも確保する必要があります。

必ずHTTPS（TLS/SSL）を使用してAPIリクエストを送信する
証明書の検証を必ず実施する（証明書検証を無効化しない）
PKCE（Proof Key for Code Exchange）を使用してセキュリティを強化する
古い認証フロー（ユーザーエージェントフローなど）は使用しない

監視とログ管理

API使用状況を継続的に監視し、異常なアクセスパターンを早期に検知することが重要です。

API使用状況を定期的に監視する
異常なアクセスパターン（短時間での大量リクエスト、未知のIPアドレスからのアクセスなど）を検知する仕組みを構築する
エラーログを適切に記録し、セキュリティインシデントに備える
Salesforceの[設定]→[私の個人設定]→[リモートアクセス]で接続状況を定期的に確認する

よくある認証エラーとトラブルシューティング

API呼び出しの実装時には、様々なエラーに遭遇することがあります。主要なエラーとその対処方法を理解しておくことで、スムーズな開発が可能になります。

主要な認証エラーと対処法

エラーコード	原因	対処法
invalid_grant	認証コードやトークンが無効、または有効期限切れ	新しい認証コードを取得し直す。リフレッシュトークンを使用してアクセストークンを更新する
invalid_client	クライアントIDまたはシークレットが間違っている	接続アプリケーションの設定を確認し、正しいコンシューマキーとシークレットを使用する
unauthorized_client	接続アプリが組織にインストールされていない	接続アプリケーションを組織にインストールする
redirect_uri_mismatch	コールバックURLが一致しない	接続アプリのコールバックURL設定とリクエストのredirect_uriが一致しているか確認する
401 Unauthorized	アクセストークンが無効または期限切れ	リフレッシュトークンを使用して新しいアクセストークンを取得する
403 Forbidden	権限不足	ユーザーの権限設定やOAuthスコープを確認する
429 Too Many Requests	API呼び出し制限に到達	リクエストの頻度を下げる。エクスポネンシャルバックオフでリトライする