1そもそも「API」って何？
APIとはApplication Programming Interfaceの略で、簡単に言えば「システム同士が会話するための窓口」です。
たとえば、Amazonの管理画面にログインして受注一覧を目で見て、手動で自社システムに入力する――これが「人間がやる方法」です。API連携は、この作業をプログラムが自動でやる仕組みです。プログラムがAmazonの「窓口（API）」に「新しい注文ありますか？」と聞きに行き、データを受け取ります。
「新しい注文ある？」
窓口で受付
「3件あります」+ データ
この仕組み自体はシンプルです。しかし、実際に本番で運用し始めると、思いもよらないトラブルが次々に発生します。
APIをひとことで言うと
- API ＝ システム同士がデータをやり取りするための「窓口」
- 人間がブラウザで操作する代わりに、プログラムが自動でデータを取得・送信する
- 「つなげば終わり」ではなく、運用してからが本番
2API連携の3大トラブル
EC業務のAPI連携で起きるトラブルは、大きく3つのカテゴリに分けられます。
| トラブル | どういう状態か | よくある原因 |
|---|---|---|
| タイムアウト | APIに問い合わせたが、返事が返ってこない | モール側のサーバー負荷、データ量が多すぎる |
| レート制限 | APIへのリクエストが拒否される | 短時間にリクエストを送りすぎた |
| データ不整合 | 取得できたが、データが正しくない | タイミングのずれ、仕様変更、変換ミス |
タイムアウト ― 「待っても返事が来ない」
人間が相手に話しかけて、30秒経っても返事がなかったら「おかしいな」と思いますよね。プログラムも同じで、一定時間（たとえば30秒）待っても返事がなければ「タイムアウト」として処理を打ち切ります。
タイムアウトが起きる主な原因は以下の通りです。
- モール側のサーバーが重い ―― セール期間中やアクセス集中時は、APIの応答が極端に遅くなる
- リクエストするデータ量が多い ―― 「過去1年分の全注文を一括取得」のような重いリクエストはタイムアウトしやすい
- ネットワークの一時的な不調 ―― インターネット回線やクラウドサービスの瞬断
問題は、タイムアウトが起きたとき「データが取れなかった」のか「途中まで処理された」のか判断できないことです。たとえば在庫更新のAPIがタイムアウトした場合、「在庫は更新されたのか、されていないのか」がわからない。確認せずにもう一度送ると、二重に更新されてしまうリスクがあります。
レート制限 ― 「窓口が混雑しています」
APIには「1分間に何回まで」「1日に何回まで」という呼び出し回数の制限があります。これをレート制限（Rate Limit）と呼びます。
なぜ制限があるのか？ 窓口に1人のお客さんが1秒に100回も問い合わせてきたら、他のお客さんの対応ができなくなりますよね。モール側も同じで、全出店者が同じAPIサーバーを共有しているため、1店舗が大量にリクエストすると全体に影響が出ます。それを防ぐための仕組みがレート制限です。
レート制限に引っかかると、その後しばらくAPIが使えなくなります。商品数が多い店舗ほど、在庫更新や価格変更で大量のAPIリクエストが必要になるため、この制限にぶつかりやすくなります。
データ不整合 ― 「動いてるのに数字が合わない」
最も厄介なのがこれです。APIは正常に動いている。エラーも出ていない。でも、データが正しくない。
データ不整合が起きる原因は後のセクションで詳しく解説しますが、ひとことで言えば「API連携はリアルタイムではない」ことに起因します。「リアルタイム同期」と言われても、実際には数秒～数分のタイムラグがあり、そのわずかな隙間でデータがずれます。
3大トラブルの厄介な共通点
- どれも「たまにしか起きない」ため、テスト段階では発見できないことが多い
- セール期間中やアクセス集中時など、最も困るタイミングで発生しやすい
- エラーが起きたことに気づく仕組み（監視・通知）がないと、被害が拡大してから発覚する
3在庫同期で起きる「数字のズレ」
API連携の最も典型的なユースケースが在庫同期です。自社の在庫管理システムの数字を、楽天・Amazon・Yahoo!ショッピングなど複数モールにAPIで自動反映する。理想的な仕組みですが、現実には「数字がズレる」問題が頻発します。
なぜ在庫がズレるのか
在庫がズレる根本原因は、「注文が入るタイミング」と「在庫を更新するタイミング」にズレがあることです。
残り3個→2個
2～3分かかる
Amazonはまだ残り3個のまま
楽天で売れた情報がAmazonに反映されるまでの数分間、Amazonには古い在庫数が表示されています。その間にAmazonでも売れると、実際には在庫がないのに注文を受けてしまう（＝売り越し）ことになります。
売り越しが起きるとどうなるか
- お客様への欠品連絡・キャンセル対応 ―― ショップの信頼低下、レビュー悪化
- モールからのペナルティ ―― 楽天やAmazonでは、キャンセル率が一定を超えると検索順位の低下やアカウント警告を受ける
- 在庫数の手動修正 ―― どのモールの在庫が正しいのか確認して、全モールを手動で修正する作業が発生
「安全在庫」という苦肉の策
この問題への現実的な対策として、各モールに表示する在庫数を実在庫より少なく設定する方法があります。たとえば実在庫が10個なら、各モールには8個と表示する。2個分の「バッファ」を持つことで、売り越しリスクを下げます。
しかしこれは売上機会の損失でもあります。実際にはまだ在庫があるのに「在庫切れ」と表示されてしまう。特に人気商品では、このバッファが大きな機会損失になります。
在庫同期の理想と現実
- 理想：注文が入った瞬間に、全モールの在庫が同時に更新される
- 現実：API経由の更新には必ずタイムラグがあり、完全なリアルタイムは不可能
- 妥協点：更新間隔を短くする + 安全在庫で売り越しを防ぐ + 売り越し時のリカバリ手順を整備する
4受注連携で起きる「取りこぼし」
もうひとつの典型的なAPI連携が受注データの自動取得です。各モールの注文データをAPIで取得し、自社の受注管理システムに自動で取り込む。手動でコピペする手間がなくなり、入力ミスも減る――はずですが、ここにも落とし穴があります。
「取りこぼし」が発生するパターン
受注データの取りこぼしは、主に以下のパターンで発生します。
- ページングの実装ミス ―― APIは一度に返すデータ数に上限がある（例：100件まで）。注文が100件を超えたとき、2ページ目以降を取得するロジックにバグがあると、101件目以降が消える
- 時刻の指定ミス ―― 「前回取得した時刻以降の注文を取得」というロジックで、タイムゾーンの計算を間違えると、特定の時間帯の注文が取れない
- ステータスの見落とし ―― 注文のステータス（仮注文・確定・キャンセル待ちなど）によってAPIの返すデータが変わる。特定ステータスの注文を取得条件から漏らしてしまう
- エラー時のリトライ漏れ ―― API呼び出しが失敗したとき、リトライせずに「取得完了」として次に進んでしまう
セール期間中
1ページ100件まで
2ページ目の取得漏れ
取りこぼしに気づけない問題
受注の取りこぼしの厄介なところは、「注文が来ていないように見える」点です。エラーが出るわけではなく、ただ静かにデータが欠落する。お客様から「注文したのに確認メールが来ない」と問い合わせが来て初めて発覚する、というケースが少なくありません。
問い合わせが来るならまだ良い方です。最悪の場合、お客様が「注文できなかったのだろう」と判断して、そのまま他店で購入してしまう。気づいたときにはすでに顧客を失っている、という事態になります。
受注連携の取りこぼしが危険な理由
- エラーが出ないため、問題の発覚が遅れやすい
- 1件の取りこぼし ＝ 1件の売上損失 ＋ 1人のお客様の信頼を失う
- セール期間など注文が多いときほど、ページングやレート制限で取りこぼしが起きやすい
- 「毎日何件取得したか」をモール管理画面の数字と突き合わせる確認作業が必要
5モール別APIの落とし穴
API連携をさらに複雑にしているのが、モールごとにAPIの仕様がまったく違うことです。
| 項目 | Amazon SP-API | 楽天 RMS API | Yahoo! API |
|---|---|---|---|
| 認証方式 | OAuth 2.0 + IAMロール | 独自トークン方式 | OAuth 2.0 |
| データ形式 | JSON | XML（一部JSON） | JSON / XML |
| レート制限 | API毎に異なる（厳しめ） | 比較的緩い | API毎に異なる |
| 仕様変更頻度 | 高い（MWS→SP-API移行あり） | 低い（安定的） | 中程度 |
| ドキュメント | 英語が主、量は豊富 | 日本語あり、やや古い | 日本語あり |
Amazon SP-API ― 最も複雑
AmazonのSP-API（Selling Partner API）は、EC系APIの中でも最も複雑です。認証だけで「AWSのIAMロール」「LWA（Login with Amazon）のOAuth」「リフレッシュトークン」という3段階を突破する必要があります。
さらに、Amazonは頻繁にAPIの仕様変更やバージョンアップを行います。以前は「MWS（Marketplace Web Service）」というAPIでしたが、これが「SP-API」に移行。旧APIが廃止されるたびに、プログラムの改修が必要になります。
楽天 RMS API ― XMLの壁
楽天のRMS APIは、データ形式にXMLを使っている部分が多いのが特徴です。現在のWeb開発の主流はJSON形式ですが、楽天のAPIは歴史が長いためXMLが残っています。
XMLはJSONに比べてデータの構造が複雑で、解析処理も煩雑になります。また、楽天独自のデータ項目やコード体系があり、他のモールとデータ構造を統一するための変換処理が必要です。
「仕様変更」という最大のリスク
API連携で最も恐ろしいのは、モール側の仕様変更です。ある日突然、APIのレスポンス形式が変わる。新しい必須パラメータが追加される。これまで動いていたプログラムが、何の前触れもなくエラーになります。
- 事前告知がある場合 ―― メールや開発者向けフォーラムで通知。ただし英語のみの場合も多く、見落としやすい
- 事前告知がない場合 ―― 突然動かなくなって初めて気づく。原因特定に時間がかかる
- 非推奨化（Deprecated） ―― 「このAPIは○○年○月に廃止します」という猶予期間つきの変更。対応を後回しにすると、期限切れで一斉に動かなくなる
モール別APIで特に注意すべきポイント
- 各モールのAPIドキュメントの更新情報を定期的にチェックする体制が必要
- 1つのモールのAPI仕様変更が、マルチモール在庫同期全体に影響する可能性がある
- テスト環境（サンドボックス）と本番環境で挙動が違うことがある
- APIの認証トークンには有効期限があり、期限切れで突然接続が切れることがある
6「動いている」と「正しく動いている」の違い
API連携の最大の落とし穴は、「動いている」ことと「正しく動いている」ことは別物だという点です。
在庫同期のプログラムがエラーなく動いている。受注連携も毎日実行されている。でも、本当に正しいでしょうか？
- 在庫数は本当に全モールで一致しているか？
- 受注データは1件も漏れなく取得できているか？
- レート制限に引っかかったリクエストは正しくリトライされているか？
- タイムアウトしたリクエストの後処理は正しく行われているか？
これらを確認するには、「監視」と「ログ」の仕組みが必要です。
必要な監視の仕組み
API連携に最低限必要な監視項目
- 成功・失敗の記録 ―― 各APIリクエストの結果を記録し、失敗があれば即座に通知する
- データ件数の突き合わせ ―― APIで取得した受注件数と、モール管理画面の件数を定期的に比較する
- 在庫数の定期チェック ―― 各モールの在庫数が自社マスタと一致しているか定期的に検証する
- レスポンスタイムの監視 ―― APIの応答時間が異常に長くなっていないかチェックする
- トークン有効期限の管理 ―― 認証トークンの期限切れを事前に検知し、自動更新する
こうした監視の仕組みは、API連携本体と同じくらい重要です。むしろ「監視がないAPI連携は、時限爆弾と同じ」と言っても過言ではありません。
中途半端なAPI連携が一番危険
手動でモール管理画面を見て処理する方法は、確かに面倒です。しかし、人間の目が入るため、異常に気づきやすいというメリットがあります。
一方、中途半端なAPI連携は、「自動化されている」という安心感があるために誰もチェックしなくなり、異常が見過ごされやすいのです。
- 完全手動 ―― 面倒だが、異常には気づく
- 中途半端な自動化 ―― 面倒は減るが、異常に気づかない。最も危険
- 監視付きの自動化 ―― 面倒もなく、異常にも気づける。ここを目指すべき
API連携を導入するなら、「動かすこと」と「監視すること」をセットで考える必要があります。動かすだけなら半分しかできていません。
もし現在のAPI連携に不安があるなら――エラー通知が来ていない＝正常、と信じてしまっているなら――一度立ち止まって、「本当に正しく動いているか」を検証してみることをおすすめします。