ecforce×発送代行のAPI連携実務ガイド｜設定手順・定期購買出荷の自動化・トラブル対処法

ecforceのAPI連携：概要と発送代行に使える機能

ecforceは国内D2C（Direct to Consumer）特化のECカートサービスで、高いCVR（コンバージョン率）・専属サポート体制・定期購買機能の充実が強みです。D2Cとは？物流戦略の基礎を参照すると、ecforceが選ばれるD2C事業の構造がわかります。発送代行との連携においては、APIオプション（別途有償）を活用することで以下のデータが連携できます。

詳細はecforce公式API ドキュメントを参照してください。

APIで取得・更新できるデータ種別

取得可能なデータは、①広告集計、②顧客情報、③受注情報、④商品情報、⑤配送業者情報、⑥商品在庫情報、⑦定期受注情報の7種類です。発送代行との連携で特に使用するのは③受注情報（出荷指示）と⑦定期受注情報（サブスク出荷指示）、そして逆方向の配送伝票番号・発送日の更新（出荷実績反映）と在庫数の更新です。EC物流のAPI連携ガイドでAPI連携の概念から理解できます。

発送代行連携で実現できる3つの自動化

1. 受注の自動取得——ecforceに注文が入ると発送代行WMSへ出荷指示が自動送信されます。
2. 出荷実績の自動反映——発送代行で出荷完了後、伝票番号・発送日がecforceの受注管理に自動反映され、対応状況が「発送完了」に更新されます。
3. 在庫の自動同期——出荷のたびにecforce側の在庫数が自動更新されます。

API連携で発送を自動化する仕組みも合わせて理解しておくと、連携設計がスムーズに進みます。

日本でDXに取組んでいる企業の割合は2022年度調査では69.3%まで増加した。ただし、全社戦略に基づいて取組んでいる割合は米国が68.1%に対して日本が54.2%となっており、全社横断での組織的な取組として、さらに進めていく必要がある。

── IPA「DX白書2023（エグゼクティブサマリー）」

受注・出荷・在庫のAPI連携は、EC事業における最も投資対効果の高いDXの一つです。次章から具体的な設定手順を見ていきます。

連携前の準備：ecforce APIオプションの申込と設定

ecforceのAPI連携は「外部サービスAPI連携」という有償オプション機能です。通常のecforceプランには含まれておらず、別途申込が必要です。申込から稼働まで約5営業日かかります。発送代行への移行ガイドで解説しているように、稼働開始日の逆算スケジュールを立てることが欠かせません。

申込から稼働までのステップ

1. APIオプション申込——ecforceカスタマーサポートへ連絡
2. エンドポイントURL発行——オプション契約完了後、約5営業日でメール通知
3. 発送代行業者へURL共有——連携設定を依頼
4. API接続用ユーザー作成——ecforce管理画面でAPIトークンを発行
5. 接続テスト——発送代行側でテスト受注による動作確認
6. 本番稼働開始

ecforce公式サイトでサービスの最新仕様を確認した上で申込に進んでください。

API接続用ユーザーの作成

ecforceへの接続には専用のAPIユーザーアカウントを作成することが強く推奨されています。通常業務のログインアカウントと分けることで、パスワード変更時の連携断絶リスクを避けられます。APIトークンは発行直後にしか確認できず、再発行が必要になるとecforce側での再申請が必要になるため、発行時に必ず控えを取ってください。

発送代行業者側の準備

発送代行業者がecforceのAPI連携に対応しているかを事前確認します。STOCKCREWはecforceのAPI連携に対応しており、発送代行に商品を預ける前の完全準備ガイドを参考に商品コード（SKU）を整備してから入庫・連携設定を進めます。

API連携の設定手順：受注取得〜出荷実績反映まで

連携設定は大きく「受注の取得設定」と「出荷実績の反映設定」の2つに分かれます。楽天連携による発送自動化の解説やBASE×発送代行のAPI連携と比較すると、ecforce特有のステータス管理が理解しやすくなります。

受注取得の設定：3つのステータスを正しく設定する

ecforceのAPI連携では「対応状況（ステータス）」の設計が要になります。標準的な設定として、「complete（注文確定）」の受注を発送代行WMSへ取り込み、取込後は「working（出荷作業中）」に自動更新、出荷完了後は「shipped（発送完了）」に更新するという3ステータスの流れを設計します。独自ステータス名を使っている場合は、発送代行業者に実際のステータス名を伝えて設定を調整する必要があります。

出荷実績の反映：伝票番号・発送日の自動登録

発送代行で出荷完了後、配送業者の伝票番号と発送日をecforceに自動登録します。これにより、ecforceの対応状況が「shipped（発送完了）」に更新され、後払い決済を利用している場合は売上確定処理も自動で行われます。後払い決済（atone等）では伝票番号と発送日の登録が売上処理のトリガーになるため、この設定が特に重要です。

テスト出荷で動作確認する3つのチェックポイント

本番稼働前のテスト出荷では、以下の3点を確認します。

• ecforceの受注が発送代行WMSに正しく取り込まれるか
• 出荷完了後にecforceの対応状況が「shipped」に更新されるか
• 在庫数がecforce側で正しく減算されるか

入庫設計と誤出荷防止策を参考に、テスト出荷の記録を残しておくと後のトラブルシューティングに役立ちます。

1日1万リクエスト上限の注意点

ecforceのAPIには「1日1万リクエスト」という上限があります。これはecforce固有の制限で、1日の処理件数が多いEC事業者には実務上の影響があります。

1万リクエスト上限が問題になるケース

1件の受注を取得・処理・ステータス更新するだけで複数回のAPIコールが発生します。5分ごとの定期チェックを設定すると1日で約288回のチェックが走ります。出荷件数が300〜400件/日を超えてくると、1万リクエストに近づく場合があります。上限を超えると翌日の朝9時（リセット時間）まで正常なAPI連携ができなくなり、その間の受注が取得されない・ステータスが更新されないといった問題が発生します。

対策①：ポーリング間隔を5分より長く設定する

発送代行業者のシステムがecforceをチェックする間隔（ポーリング間隔）を5分より長め（15〜30分）に設定することでリクエスト数を削減できます。ただし、間隔が長すぎると出荷指示の送信が遅れます。出荷締め時間から逆算して最適な間隔を設定してください。

対策②：Webhook（プッシュ型連携）の活用

ポーリング（定期的に確認する方式）ではなく、ecforce側に注文が入った瞬間に発送代行へ通知が飛ぶWebhook方式を使えるかどうかを発送代行業者に確認します。Webhook方式はリクエスト数が大幅に削減され、リアルタイム性も高まります。

対策③：ステータス更新の対象を絞る

「出荷済み」「発送完了」といったステータス更新のAPIコールを最小化する設計にします。不要なステータスチェックを減らすことで、1日のリクエスト数を抑制できます。

定期購買（サブスク）出荷の自動化：通常受注との違い

ecforceの強みのひとつがサブスクリプション（定期購買）機能です。リピート通販を成功させる発送代行活用術でも解説していますが、定期受注は通常受注と異なる処理が必要です。

定期受注と通常受注のAPI取得の違い

ecforceのAPIでは「受注情報」と「定期受注情報」は別のエンドポイントで取得します。発送代行側のシステムが定期受注に対応しているかどうかを確認することが肝心です。対応していない場合、定期出荷だけCSVで手動処理する必要が生じます。

定期出荷のタイミングと発送日の設計

定期購買は毎月特定の日に出荷が集中します。例えば「毎月15日出荷」の商品が500定期会員いれば、15日に一気に500件の出荷指示が発送代行に送られます。発送代行の費用シミュレーションでこの波動コストを試算してください。発送代行業者に事前に「定期出荷の集中日と件数の目安」を伝えておくことが、スムーズな対応につながります。

定期受注のキャンセル・一時停止の連携

顧客がマイページから定期購買をキャンセル・一時停止した場合、既に発送代行に送った出荷指示のキャンセル連携が必要になる場合があります。ecforce側でキャンセルが発生したときにAPIで発送代行のWMSへキャンセル指示を送れるかどうかを設定時に確認してください。

在庫連携：ecforce在庫と発送代行WMS在庫の同期

在庫連携が正しく機能しないと「ecforce上の在庫数は10個あるのに、発送代行の倉庫には実際には3個しかない」という乖離が発生し、オーバーセル（売り越し）や欠品の原因になります。ネットショップの在庫管理完全ガイドと適正在庫管理の考え方も合わせて理解してください。

在庫連携の方向：双方向同期が理想

理想的な在庫連携は「出荷のたびにecforce在庫が減算される」かつ「入庫のたびにecforce在庫が増加される」という双方向のリアルタイム同期です。ただし、ecforceのAPI上限（1日1万リクエスト）を考慮すると、リアルタイム同期ではなく1時間ごとなどの定期同期を採用するケースもあります。

在庫連携のSKU（商品コード）マッピング

ecforceの商品コードと発送代行WMSの商品コードが一致していることが在庫連携の前提条件です。コードが異なると在庫同期が機能しません。ロット管理の実務と棚卸しの実務を参考に、入庫前に商品コードの整合性を確認することが最も重要な事前作業です。

在庫差異が発生した場合の調整

定期的な棚卸し（ecforce側の理論在庫と発送代行WMSの実在庫の突合）で差異を検出します。差異が大きい場合は原因を調査し（返品処理漏れ・入庫検品ミス・API連携エラーなど）、手動で在庫数を修正します。物流KPIの設計において在庫精度を定期モニタリング指標に含めることが推奨されます。

連携エラーと対処法：よくあるトラブル4パターン

ecforce×発送代行のAPI連携で発生しやすいトラブルと対処法を整理します。物流クレームの対処法と防止策と合わせて、事前にトラブルシュート手順を決めておくことをおすすめします。

トラブル①：1日1万リクエスト上限超過

症状：夕方以降から受注が取得されなくなり、翌朝9時まで連携が止まります。対処：ポーリング間隔を伸ばす、Webhook方式への切り替えを検討する、出荷件数が多い場合はecforceに上限引き上げの相談をします。

トラブル②：SKUコードの不一致による在庫同期エラー

症状：在庫数が正しく更新されない、出荷後も在庫が減らない。対処：ecforceの商品コードと発送代行WMSのコードが一致しているかを確認します。発送代行に商品を預ける前の準備で事前に整備します。

トラブル③：後払い決済の売上確定が進まない

症状：atone等の後払い決済で売上が確定されない。原因：伝票番号・発送日の反映がAPI経由で正しく行われていません。対処：ecforceへの出荷実績反映の設定を再確認します。伝票番号が空白のまま送られていないかチェックします。

トラブル④：定期受注が取得されない

症状：通常受注は問題ないが定期受注の出荷指示が発送代行に届かない。原因：発送代行システムが定期受注APIに未対応。対処：発送代行業者に定期受注（サブスク）の対応状況を確認します。対応していない場合はCSVでの手動処理か、対応業者への変更を検討します。

STOCKCREWとecforceのAPI連携実務

STOCKCREWはecforceとのAPI連携に対応しています。連携設定の大まかな流れは、ecforce側でAPIオプションを申込→エンドポイントURLとAPIトークンをSTOCKCREWに共有→STOCKCREW側で接続設定→テスト受注で動作確認→本番稼働という順番です。STOCKCREWのサービス詳細で確認できますが、初期費用・固定費ゼロ・最低出荷件数なしという条件は、ecforceでの事業が立ち上がりフェーズのEC事業者にも使いやすい設計です。

STOCKCREWとの連携で自動化される業務

ecforce→STOCKCREWへの受注自動取得（通常受注・定期受注の両方）、STOCKCREW→ecforceへの出荷実績反映（伝票番号・発送日）、在庫の双方向同期の3つが自動化されます。QCDS評価（品質・コスト・納期・サービス）の観点でSTOCKCREWのパフォーマンスをモニタリングしながら運用します。

AMRロボットとecforce定期出荷の組み合わせ

定期購買が増えると毎月の集中出荷日に大量の出荷が発生します。STOCKCREWはAMR（自律走行ロボット）100台以上を稼働させており、繁忙期・集中出荷日でも人員増加なしで安定した出荷が可能です。EC物流ロボット（AMR）完全ガイドとSTOCKCREWの倉庫オペレーションも参照してください。

発送代行導入タイミングと費用対効果の試算

ecforceで事業が成長するにつれて、発送代行の導入タイミングを判断する必要があります。発送代行は月何件から使うべきか？では損益分岐点を計算しています。ecforce特有の文脈で補足します。

D2C・定期購買事業での判断基準

ecforceを使ったD2C事業は定期購買比率が高くなりやすいため、月間出荷件数が「毎月安定して増加する」という特徴があります。立ち上がりフェーズ（月50〜100件）でも、発送代行に切り替えることで「発送作業から解放された時間」を商品開発・広告改善・顧客対応に使えます。D2C事業の物流設計でも、物流を早期にアウトソーシングすることがD2Cの成長加速につながると解説しています。　なお、国土交通省「ラストマイル配送の効率化等に向けた検討会」が示すとおり輸送力は構造的に逼迫しており、出荷体制の外部化は「件数が増えてから」より「増える前」に備えるほうが安全です。

費用対効果の試算（月300件・ecforce定期購買の場合）

月300件（通常100件＋定期200件）の出荷を自社発送した場合、60サイズで約1,807円/件×300件＝541,000円のコストがかかります（ヤマト運輸持込料金940円＋資材費200円＋人件費667円）。STOCKCREWで発送代行を利用すると560円/件×300件＝168,000円となり、差額は約373,000円です。発送代行費用の詳細シミュレーションで自社の商品サイズに合わせた試算ができます。

出荷精度の向上効果

定期購買のリピート率はショップの信頼性に直結します。誤出荷・遅延が発生するとリピート解約につながり、ecforceで構築したサブスクビジネスの根幹を揺るがします。ピッキングと誤出荷防止策で解説しているように、専門業者への委託は出荷精度の均一化につながります。同梱物の設計も発送代行を通じて標準化することで、ブランド体験の一貫性が保たれます。

まとめ

ecforce×発送代行のAPI連携で押さえるべきポイントは4つです。①ecforce側のAPIオプション（有償）の申込が必須で稼働まで約5営業日かかる、②1日1万リクエスト上限を考慮したポーリング設定が必要、③定期受注は通常受注と異なるAPIエンドポイントで処理されるため発送代行業者の対応確認が必要、④SKUコードの一致が在庫連携の前提条件。発送代行完全ガイドとEC物流完全ガイドも参照しながら、連携設定を進めてください。

STOCKCREWはecforceとのAPI連携に対応しており、通常受注・定期受注の両方を自動化できます。初期費用ゼロ・最低出荷件数なしでD2Cの立ち上がりフェーズから利用できます。発送代行サービスの選び方とSTOCKCREWのサービス完全ガイドを確認の上、無料資料ダウンロードまたはお問い合わせからご相談ください。