API 連携とは、システム同士が決まった形式でデータをやり取りし、人の転記や二重入力をなくす仕組みです。 API（Application Programming Interface）はシステムが外から呼び出せる窓口で、たとえば「予約が入ったら会計のシステムに顧客を作る」「受注を在庫のシステムに反映する」といった処理を、人を介さずに行えます。ここでは、社内システムと SaaS をつなぐときの方式の選び方と、失敗したときの扱い、発注の前に決めることを整理します。
API 連携でできること
- 転記をなくす：ある画面で入力した内容を、別のシステムに手で写す作業がなくなります
- 反映を早くする：夜にまとめて取り込む方式と違い、数秒〜数分で相手のシステムに反映されます
- 入力の誤りを減らす：コードや金額を写し間違えることがなくなります
- 記録を一か所にまとめる：顧客や取引の情報を、正本のシステムに集められます
一方で、つないだシステムの片方が止まると連携も止まります。どちらのシステムの情報を正しいとするか（正本）を決めずに双方向でつなぐと、更新がぶつかって情報が食い違います。
連携の方式は 3 つ
| 方式 | 動き | 向く場面 | 注意 |
|---|---|---|---|
| API を呼び出す | こちらから相手の API を呼んで、読み書きする | 必要なときに最新の情報を取る・登録する | 呼び出しの回数の上限（レート制限） |
| Webhook で受け取る | 相手で出来事があると、相手からこちらに通知が届く | 予約・支払いなど、起きたらすぐ知りたいもの | 受け取る側の公開 URL と、署名の検証 |
| ファイルで受け渡す | CSV などを決まった時刻に出力・取り込む | 件数が多く、反映が翌日でよいもの | 反映の遅れ。項目の並びの変更に弱い |
多くの連携は、この 3 つの組み合わせです。たとえば、出来事は Webhook で受け取り、詳しい内容は API で取りに行き、月末にファイルで件数を突き合わせる、といった形です。Webhook の送信側で必要になる仕組みは「Webhook の送信を外部サービスに任せるメリット」で整理しています。
認証の種類
API を呼ぶには、相手に「誰が呼んでいるか」を示す必要があります。
- API キー：管理画面で発行した文字列を送ります。簡単ですが、漏れると誰でも使えるため、保管場所と入れ替えの手順を決めます
- OAuth 2.0：利用者が「このアプリに自分のデータへのアクセスを許可する」と同意し、期限付きのトークンで呼び出します（RFC 6749）。顧客ごとに別の SaaS のアカウントをつなぐ連携は、多くがこの方式です
- IP アドレスの制限や証明書：金融機関や大企業の連携では、送信元の IP や、クライアント証明書を求められることがあります
失敗したときの扱いを先に決める
API 連携の開発で手間がかかるのは、うまく動いたときより、失敗したときの扱いです。
- 再送の決まり：相手が一時的に止まっているときは、間隔を空けて送り直します。何回まで、どの間隔で送るかを決めます。HTTP の 429（呼び出しが多すぎる）や 503 が返ったときは、相手が示す待ち時間（Retry-After）に従います
- 重複の防止：送り直すと、同じ登録が 2 回届くことがあります。取引ごとに一意の番号を付け、受け取った側で同じ番号を 2 回処理しないようにします
- 順番：「登録」より先に「変更」が届くと処理できません。順番が大事な連携は、順番を保証する仕組みか、届いた順に関係なく正しくなる作りにします
- 止まったことに気づく：失敗が続いたら担当者に通知します。誰が、どの画面で失敗を確認して送り直すのかまで決めます
- 記録：いつ、何を送り、何が返ったかを残します。「届いていない」という問い合わせに答えられるようにするためです
発注の前に決めること
- 正本：顧客・商品・予約などの項目ごとに、どちらのシステムを正しいとするか
- 項目の対応表：相手のどの項目をこちらのどの項目に入れるか。コードの変換（都道府県・税区分など）と、片方にしかない必須項目の補い方
- 頻度と量：1 日に何件、どの時間帯に集中するか。相手の呼び出しの上限に収まるか
- テスト環境：連携先に試すための環境があるか。ない場合の確かめ方
- 止まったときの運用：連携が止まっている間の業務の回し方と、復旧後の追いつき方
- 費用：連携先の API の利用が有料か、プランによって使える API が違わないか
当社の開発のご案内
当社は、業種に合わせた業務システムと SaaS の開発で、既存の SaaS や社内システムとの API 連携、Webhook の受信、CSV による突き合わせまでを設計からお引き受けしています。進め方はバーティカル SaaS 開発のページをご覧ください。
出典
- RFC 6749: The OAuth 2.0 Authorization Framework
- RFC 9110: HTTP Semantics（503・Retry-After）
- RFC 6585: Additional HTTP Status Codes（429 Too Many Requests）
よくある質問
API 連携と CSV の取り込みは、どちらがよいですか？
反映を急がず、1 日 1 回まとめて移せばよいなら CSV のほうが簡単で、障害の切り分けもしやすくなります。予約や在庫のように、相手の画面にすぐ反映したいものは API 連携が向きます。両方を組み合わせ、日中は API、夜に CSV で突き合わせる構成もよく使われます。
連携先の SaaS が API を公開していない場合はどうしますか？
まず CSV の書き出し・取り込みや、Webhook の通知がないかを確かめます。画面を自動で操作する方法（RPA）もありますが、画面が変わると止まるため、業務の要の連携には向きません。API の公開予定を提供元に問い合わせるのも一つの手です。
API 連携の開発費用は何で決まりますか？
連携する項目の数より、項目の対応づけ（コードの変換・必須項目の補い方）、失敗時の再送と重複の扱い、認証の方式、テスト環境の有無で決まります。連携先にテスト環境がないと、本番のデータで確かめる手間がかかります。
