2026.10.26 業務システム

Salesforce APIとは？種類の全体像と認証からRESTで最初の1件を取得する手順

Salesforce APIは、Salesforceの組織にあるレコードや設定を、画面を通さずに外部のプログラムから読み書きするための窓口の総称です。REST API、SOAP API、Bulk API、Pub/Sub APIをはじめ十数種類があり、どれも同じ組織のデータを別の形で公開しています。この記事では、主要なAPIの役割分担を一覧で押さえたうえで、外部クライアントアプリケーションとClient Credentialsフローでアクセストークンを取り、curlでAPIバージョンの確認、SOQLによる取得、レコードの作成とCompositeリクエストまでを順に試します。後半で扱うのは、残量の確かめ方とエラー応答の読み方、自前でAPIを呼ぶべきかの判断です。数値と仕様は2026年10月時点の公式情報に基づきます。

まとめ：まずREST APIで始め認証方式とAPI版と残量の三つを先に決める

Salesforce APIで最初に触るべきなのはREST APIです。レコードの作成・取得・更新・削除、SOQLのクエリ、オブジェクトの項目定義の取得、組織の制限値の参照まで、日々の連携で必要な操作はほぼRESTのリソースで足ります。数万件を超える一括処理になったらBulk API 2.0、変更をポーリングせずに受け取りたいならPub/Sub APIへ移る、という順で考えると迷いません。

コードを書く前に決めるのは三つです。認証は、新規の連携なら外部クライアントアプリケーションとClient Credentialsフローを第一候補にします。APIの版は、URIに書くv67.0のような番号をライブラリ任せにせず、明示する方針です。残量は、応答ヘッダのSforce-Limit-Infoで初日から記録します。この三つが曖昧なまま本番に入ると、トークン切れ・版の廃止・上限超過のいずれかで連携が止まります。

どのAPIをどの業務に割り当て、一日のコール数をどう見積もるかという設計の段階まで相談したい場合は、Salesforce導入支援サービス・Apex開発で要件の整理から対応しています。

Salesforce APIが公開するデータと主要4種のAPIの役割分担

Salesforceは機能を作るときにAPIを先に用意し、画面はその上に組み立てる方針を取っています。画面でできる操作の多くがAPIからもできるのはこのためです。

APIを呼べるエディションとAPIの有効化権限という二つの前提条件

Trailheadの単元「Salesforce プラットフォーム API について知る」によると、APIを使えるのはEnterprise・Unlimited・Developer・Performanceの各エディションと、アドオンを付けたProfessional Editionです。加えて、APIを呼ぶユーザーに「APIの有効化」権限が必要になります。

SOAP APIのlogin()を除くすべてのコールには認証が要ります。つまり、エディションが対応していても、連携に使うユーザーの権限とOAuthの設定がそろうまでは1件も取得できません。Professional Editionの組織で連携を計画するときは、アドオンの契約有無を最初に確認してください。

主要APIのデータ形式と同期・非同期の違いを一覧で比べる早見表

同じ単元では、主要なAPIを形式と通信方式で整理しています。よく使うものを抜き出すと次のとおりです。

API	種別	データ形式	通信	主な用途
REST API	REST	JSON・XML	同期	レコード操作・クエリ・制限値の参照
SOAP API	SOAP（WSDL）	XML	同期	WSDLを契約にしたサーバ間連携
Bulk API 2.0	REST	CSV・JSON・XML	非同期	5万件以上の取り込みと抽出
Pub/Sub API	gRPC	バイナリ（Avro）	非同期	変更イベントの購読と発行
メタデータ API	SOAP（WSDL）	XML	非同期	設定の取得とリリース
GraphQL API	GraphQL	JSON	同期	必要な項目だけを1回で取得

Trailheadの単元「Bulk API 2.0 を使用する」が示すとおり、Bulk API 2.0もREST APIと同じ/services/dataの下にあり、同じOAuthのトークンで呼べます。連携ごとのAPIの割り当てとBulkへ切り替える件数の境界は、Salesforceのシステム連携とAPIコール上限の設計で詳しく扱っています。

外部クライアントアプリケーションを作りClient Credentialsで認証する手順

APIを呼ぶには、まずSalesforce側に「このプログラムからの接続を受け付ける」という登録が要ります。2026年の時点で、この登録の作法が変わっています。

Spring ’26で接続アプリケーションの新規作成が既定で止まった背景

OAuthの登録先として長く使われてきたのは接続アプリケーション（Connected App）でした。REST API開発者ガイドの記載では、Spring ’26から接続アプリケーションの新規作成が既定で制限され、新しい連携には外部クライアントアプリケーション（External Client App）が推奨されています。既存の接続アプリケーションはそのまま動き続けます。

古い手順書の多くは接続アプリケーションの作成から始まりますが、2026年以降は作成ボタン自体が見当たらない組織があります。新規の連携は最初から外部クライアントアプリケーションで設計してください。

OAuth範囲apiとClient Credentialsフローと実行ユーザーの設定

サーバ間の連携で人がログイン画面を操作しない場合は、Client Credentialsフローが扱いやすい方式です。外部クライアントアプリケーションでは、次の順に設定します。

設定のクイック検索で外部クライアントアプリケーションマネージャーを開き、新規作成する
OAuth設定を有効にし、選択したOAuth範囲に「APIを使用してユーザーデータを管理（api）」を加える
Client Credentialsフローを有効にする
ポリシー側で、トークンを発行するときに代わりに動く実行ユーザーを指定する
コンシューマー鍵とコンシューマーの秘密を控え、ソースコードではなく秘密情報の保管場所に置く

Client Credentialsで発行されたトークンは、手順4の実行ユーザーの権限でデータを読み書きします。管理者を指定すれば何でも取れてしまうため、連携専用のユーザーを用意し、必要なオブジェクトと項目だけを許可するのが原則です。統合ユーザーに与える権限の最小化は、先ほどの連携設計の記事で項目レベルセキュリティまで含めて整理しています。

My Domainのトークンエンドポイントへcurlで送りアクセストークンを得る

トークンの取得先は、組織固有のMy DomainのURLです。Pythonのsimple-salesforceのlogin.pyを読むと、Client Credentialsの分岐はドメインがloginとtestのときには入らない作りになっており、汎用のlogin.salesforce.comやtest.salesforce.comではなくMy Domainへ送る前提がコードからも読み取れます。

# My Domain が acme の本番組織からアクセストークンを取得する
curl -s https://acme.my.salesforce.com/services/oauth2/token \
  -d grant_type=client_credentials \
  -d client_id="$SF_CLIENT_ID" \
  -d client_secret="$SF_CLIENT_SECRET"

成功すると、JSONでaccess_tokenとinstance_urlが返ります。以降のリクエストは、instance_urlの下へAuthorization: Bearerヘッダにトークンを付けて送ります。このフローではリフレッシュトークンが発行されないため、401が返ったら同じリクエストでトークンを取り直す処理を最初から組み込む設計にしてください。Sandboxの場合はSandboxのMy Domain URLに読み替えます。URLの形式はSalesforce Sandboxのログインと作成の手順にまとめています。

REST APIのURI構造を読みcurlで最初のレコードを取得・作成する

Trailheadの単元「REST API を使用する」は、REST要求をリソースURI・HTTPメソッド・要求ヘッダ・リクエストボディの4要素で説明しています。以下の例は、トークンを環境変数SF_TOKENに、instance_urlをSF_URLに入れた前提です。

services/dataから組織で使えるAPIバージョンを一覧で確かめる

最初の1回は、組織が受け付けるAPIの版を確かめます。/services/data/を呼ぶと、版番号と各版のURLが配列で返ります。

curl -s "$SF_URL/services/data/" -H "Authorization: Bearer $SF_TOKEN"

2026年10月時点で、Summer ’26の版は67.0、続くWinter ’27は68.0です。季節リリースの適用日は組織によって前後するため、URIに書く版はこの応答で実在を確かめてから決めます。以降の例はv67.0で書いています。

SOQLをqueryリソースへ渡して取引先を取得するcurlと応答の読み方

レコードの取得には、SOQLをqパラメータに入れてqueryリソースへ送ります。空白や記号を含むので、curlの--data-urlencodeでエンコードさせると安全です。

curl -s -G "$SF_URL/services/data/v67.0/query" \
  -H "Authorization: Bearer $SF_TOKEN" \
  --data-urlencode "q=SELECT Id, Name, ShippingCity FROM Account ORDER BY CreatedDate DESC LIMIT 5"

応答のtotalSizeは条件に合う件数、recordsは取得したレコードの配列です。各レコードのattributes.urlはそのレコード自体のリソースURIで、後続の更新に使えます。件数が多く1回で返し切れないときはdoneがfalseになり、続きの取得先がnextRecordsUrlに入る仕組みです。ループでこのURLをたどる処理を書き忘れると、先頭の分だけで処理が終わってしまいます。

sObjectリソースへのPOSTとPATCHでレコードを作成・更新する書式

作成はオブジェクト名のリソースへPOST、更新はレコードIDを付けたリソースへPATCHです。

# 取引先を1件作成する
curl -s "$SF_URL/services/data/v67.0/sobjects/Account" \
  -H "Authorization: Bearer $SF_TOKEN" -H "Content-Type: application/json" \
  -d '{"Name": "サンプル商事", "ShippingCity": "Osaka"}'

# 作成時に返ったIDのレコードの市区郡を更新する
curl -s -X PATCH "$SF_URL/services/data/v67.0/sobjects/Account/$ACCOUNT_ID" \
  -H "Authorization: Bearer $SF_TOKEN" -H "Content-Type: application/json" \
  -d '{"ShippingCity": "Kobe"}'

作成に成功するとsuccessがtrueでIDが返ります。更新の成功時は本文の無い204です。Trailheadの単元では、取引先の必須項目であるNameを省いて送ると、値の入力を求めるエラーが返る例を示しています。応答に項目名が入るので、入力規則や必須項目の設定変更で連携が止まったときも、まず応答本文を読めば原因の項目に行き着きます。

Compositeで関連レコードを1回のコールにまとめるリクエストの書き方

取引先を作り、そのIDで取引先責任者を作る、という依存のある処理は、Compositeリソースで1回のコールにまとめられます。前の応答はreferenceIdで参照します。

curl -s "$SF_URL/services/data/v67.0/composite" \
  -H "Authorization: Bearer $SF_TOKEN" -H "Content-Type: application/json" \
  -d '{
  "allOrNone": true,
  "compositeRequest": [
    {"method": "POST", "url": "/services/data/v67.0/sobjects/Account",
     "referenceId": "newAccount", "body": {"Name": "サンプル商事"}},
    {"method": "POST", "url": "/services/data/v67.0/sobjects/Contact",
     "referenceId": "newContact",
     "body": {"LastName": "山田", "AccountId": "@{newAccount.id}"}}
  ]
}'

開発者ガイドの記載では、1回のCompositeに入れられるサブリクエストは25件までで、そのうちクエリとsObject Collectionsは5件までです。allOrNoneをtrueにすると、途中で1件失敗したときに全体が取り消されます。参照の@{newAccount.id}は大文字小文字を区別するため、Idと書くとエラーになります。

PythonとNode.jsのライブラリでAPIを呼ぶときの設定の落とし穴

curlで動きを確かめたら、実装は各言語のライブラリに任せるのが普通です。ただし、ライブラリの既定値がそのまま本番に流れ込む点には注意が要ります。

simple-salesforceの既定版59.0を引き継がず版を明示する理由

Pythonでよく使われるsimple-salesforceは、READMEにClient Credentialsの書き方が載っており、consumer_key・consumer_secret・domainの3つを渡すだけでトークン取得まで済みます。

from simple_salesforce import Salesforce

# domain は https://acme.my.salesforce.com の「acme.my」の部分
sf = Salesforce(consumer_key="...", consumer_secret="...",
                domain="acme.my", version="67.0")
print(sf.query("SELECT Id, Name FROM Account LIMIT 5")["totalSize"])
print(sf.api_usage)  # 直近の応答ヘッダから読んだ残量

2026年10月時点のapi.pyではDEFAULT_API_VERSIONが'59.0'のままです。versionを省くと、組織が67.0を受け付けていても59.0で呼び続けることになります。新しい版で追加された項目や挙動が使えないうえ、古い版が廃止対象になったときに連携が一斉に止まります。版はライブラリの既定に頼らず、設定ファイルで明示して管理してください。

jsforceとPostmanコレクションで検証を始める前に確かめる認証方式

Node.jsではjsforceが定番です。ただしjsforceのREADMEは、SOAPのlogin()がSummer ’27で廃止されると告知し、loginBySoapからOAuthへの移行を求めています。Trailheadのサンプルにもこのログイン方式の例が残っているので、写して始めないよう注意してください。

コードを書く前にリクエストの形だけ確かめたいなら、Salesforceが公開しているPostman用のSalesforce APIsコレクションが手早い方法です。REST・Bulk v1とv2・Composite・GraphQL・Metadata・Toolingなど250件超のリクエスト例と応答例が入っており、本記事のcurlと同じリソースを画面から試せます。

APIの残量とエラー応答を実装の初日から記録するための確認手順

本番で連携が止まる原因の多くは、コードの誤りではなく上限超過と認証切れです。どちらも応答に兆候が出ています。

Sforce-Limit-Infoヘッダとlimitsリソースで24時間の残量を読む

Trailheadの単元は、APIの制限をタイムアウト・同時要求・直近24時間の合計の3種類に分けています。合計の残量は、REST APIの応答ヘッダSforce-Limit-Infoにapi-usage=18/5000のような「使用数/上限」の形で毎回入ります。

# ヘッダごと表示して Sforce-Limit-Info を確かめる
curl -s -i "$SF_URL/services/data/v67.0/limits" -H "Authorization: Bearer $SF_TOKEN" | grep -i -e "^sforce-limit-info" -e "DailyApiRequests"

limitsリソースは、DailyApiRequestsのMaxとRemainingをはじめ、組織の各種上限をまとめて返します。毎回のヘッダはログに残し、limitsは定期的に呼んで監視に回す分担にすると無駄がありません。設定画面の［API使用状況通知］で、超過をメールで知らせることもできます。

401・403・400の応答本文から原因を切り分けるエラーの確認順

Salesforce APIのエラー応答は、errorCodeとmessageを持つJSONの配列です。HTTPステータスとerrorCodeの組み合わせで、確かめる場所が決まります。

401とINVALID_SESSION_ID：トークンの期限切れか失効。トークンを取り直して再送する
403とREQUEST_LIMIT_EXCEEDED：24時間の合計か同時要求の上限超過。再送を繰り返すと悪化するので処理を止める
400とMALFORMED_QUERYやINVALID_FIELD：SOQLの構文か項目名の誤り。実行ユーザーに項目の参照権限が無い場合も項目が見えずにこのエラーになる
400とREQUIRED_FIELD_MISSING：必須項目の不足。組織側で必須項目や入力規則が追加されていないかを確かめる

実務でまず押さえるのは1件目と2件目です。401は自動で回復させ、403の上限超過は自動で再送させない、という二つの分岐を書いておくだけで、夜間に連携が止まり続ける事故の大半を防げます。

Salesforce APIを自前で呼ぶべき場面とノーコード連携で足りる場面の境界

APIは誰でも呼べますが、呼んだ後の保守まで含めると自前実装が割に合わない場面もあります。判断を分けるのは、データの向きと量、そして変更に追随する体制です。

自前でAPIを呼ぶ実装が見合う要件と見送ってよい場面の具体条件

自前の実装が見合うのは、自社の基幹システムや独自のWebサービスとSalesforceをつなぎ、標準のコネクタが用意されていない場合です。項目の変換や重複判定に自社固有の規則があるとき、Compositeでの一括登録やBulk API 2.0での夜間同期を組み合わせたいときも、コードで書いた方が要件を満たしやすくなります。

見送ってよいのは、SlackやGmail、kintoneのように主要なSaaSとの片方向の連携で、件数が一日数百件程度に収まる場合です。製品側の標準連携やiPaaSのコネクタで足りる範囲です。ここで自前の実装を選ぶと、トークンの管理、版の更新、上限の監視を自社で抱えることになり、作る費用より持ち続ける費用の方がかさみます。Salesforce上でロジックを書くApex RESTで外部へ口を開く選択肢もあり、その場合の言語仕様とガバナ制限はApexの言語仕様とガバナ制限の解説が前提になります。

実行ユーザーの権限と版の更新を誰が保守するかで発注範囲を決める

外部の開発会社に連携を依頼するときは、作る範囲だけでなく、作った後に誰が何を持つかを先に決めてください。具体的には、外部クライアントアプリケーションと実行ユーザーの管理者、コンシューマーの秘密を更新する担当と周期、APIの版を上げる判断をする担当、上限超過の通知を受ける宛先の4点です。

この4点が決まらないまま納品されると、担当者の異動や秘密の失効をきっかけに連携が止まり、原因を追える人がいない状態になります。設定と開発の線引きはSalesforce開発の四層とリリース管理を整理した記事でも扱っています。連携の実装から保守の分担まで一括で相談したい場合は、要件の切り分けの段階からSalesforce導入支援サービス・Apex開発へお問い合わせください。製品そのものの機能と料金体系はSalesforceの機能と料金の解説にまとめています。

よくある質問

Salesforce APIを使い始めるときに検索の多い質問に答えます。

Salesforce APIの利用に追加の料金はかかりますか？

Enterprise・Unlimited・Performance・Developerの各エディションでは、APIの利用は契約に含まれています。Professional Editionは、APIを使うためにアドオンの契約が必要です。24時間あたりのコール数には上限があり、上限を引き上げたい場合は追加の契約になります。iPaaSやETLツールを使う場合は、そのツール側の利用料が別にかかります。

接続アプリケーションを新規作成するボタンが無いのはなぜですか？

Spring ’26から、接続アプリケーションの新規作成が既定で制限されたためです。新しい連携には外部クライアントアプリケーションを使います。既存の接続アプリケーションは引き続き動作するので、すでに稼働している連携をすぐに作り直す必要はありません。古い手順書を参照するときは、作成の手順だけ外部クライアントアプリケーションに読み替えてください。

APIで取得できるデータに画面と同じ権限は反映されますか？

反映されます。APIは認証したユーザーの権限で動くため、そのユーザーに参照権限の無いオブジェクトや項目は取得できません。Client Credentialsフローでは、外部クライアントアプリケーションで指定した実行ユーザーの権限が使われます。取得できるはずの項目が応答に無いときは、まず実行ユーザーの項目レベルセキュリティを確認してください。

REST APIとApex RESTはどう違いますか？

REST APIはSalesforceが標準で用意しているリソースで、レコードの操作やクエリを設定なしで呼べます。Apex RESTは、自分で書いたApexクラスをRESTのエンドポイントとして公開する仕組みです。複数のオブジェクトにまたがる独自の処理を1回の呼び出しで完結させたいときにApex RESTを使います。標準のリソースで足りるうちは、保守するコードが増えないREST APIを選びます。

Sandboxで試してから本番へ切り替えるときに変える設定は何ですか？

トークンの取得先をSandboxのMy Domain URLから本番のMy Domain URLへ変え、本番側で作った外部クライアントアプリケーションのコンシューマー鍵と秘密に差し替えます。Sandboxは本番の設定を複製して作るため、Sandboxで作った外部クライアントアプリケーションは本番にはありません。実行ユーザーも本番で改めて指定し、APIの版がSandboxと本番で同じかを/services/data/で確かめてから切り替えます。