オープンロジAPIは、ECサイトやOMSなどの受注・商品・在庫データを、オープンロジの入荷・出荷などの物流処理につなぐための仕組みです。標準連携の対象サービスであれば受注から発送通知までを自動化できる場合があり、API未対応の販売チャネルでもCSVや手動登録で出荷依頼につなげられます。
ただし、連携できるデータや自動化の範囲は、ECカート・モールごとの仕様、契約、アカウント、機能開放状況によって異なります。自社の販売チャネル、商材、在庫同期、同梱条件、出荷締切を照らし合わせて、API・標準連携・CSV運用を使い分けることが重要です。
オープンロジAPIで連携できる物流業務
オープンロジAPIでは、商品、入荷、出荷に関するAPI群が用意されています。変更履歴には、`items`、`warehousings`、`shipments`に関する取得・登録・更新などのエンドポイントや、出荷・入荷実績を扱うエンドポイントが記載されています。ただし、各操作の必須項目、契約上の利用可否、商品画像や期限情報などの対応項目は、利用するAPIバージョンと契約環境の仕様で確認が必要です。
商品・入荷・出荷・実績を分けて連携範囲を整理する
物流連携では、次の業務を一つの処理として考えず、データの目的とタイミングを分けて設計します。
| 業務 | 連携する主な内容 | 導入前に確認すること |
|---|---|---|
| 商品 | 商品コード、SKU、商品名などの商品マスタ | 登録・取得・更新・削除の可否、必須項目、画像やロット情報の扱い |
| 入荷 | 倉庫へ送る入荷依頼、入荷予定、入荷実績 | 入荷先、商品、数量、到着予定、変更・取消しの条件 |
| 出荷 | 注文をもとにした出荷依頼 | 注文番号、配送先、SKU、数量、配送方法、同梱・加工指示 |
| 実績・在庫 | 入荷・出荷実績、在庫数、処理状況 | 取得できる時点、在庫の区分、ページネーションや更新間隔 |
受注から出荷依頼を作る場合は、注文を識別する番号、配送先情報、倉庫側の商品コードと一致するSKU、数量を正確に渡す必要があります。配送方法、希望日、同梱物、ギフトなどの指示を利用する場合は、その情報が連携先と出庫ルールの対象項目になっているかも確認します。
出荷依頼の変更・取消しは、APIに変更や取消しの操作が用意されていることだけで判断できません。倉庫で作業が始まった後は、変更できる項目が限られたり、停止が間に合わなかったりするためです。国内出荷では梱包済みになると停止できない場合があり、海外発送では梱包済み出荷を管理画面から修正・キャンセルできない案内もあります。受注側でキャンセルされた注文を自動で取り消す場合は、出荷の進行状況を確認してから処理する設計が必要です。
APIの変更履歴では、出荷依頼の作成・取得・更新・削除・変更・取消し、出荷実績取得に関するエンドポイントが確認できます。ただし、作業状態ごとの実行可否や、入荷依頼の取消し条件まで一律に示すものではありません。実装前に対象APIのリクエスト・レスポンス仕様を確認してください。
自動実行の条件は連携基盤側で設計する
「受注確定時に出荷依頼を作成する」「商品マスタの更新時に商品情報を同期する」といった起動条件は、オープンロジAPI単体ではなく、標準連携、自社システム、OMS、外部連携ツールの構成によって決まります。
そのため、連携設計では次の処理を分けて考えます。
- どの状態を起点にするか。例：決済確定、出荷可能、注文キャンセル
- 同じ注文を二重送信しない方法
- APIエラーや通信失敗時の再実行方法
- 一部の商品だけ登録に失敗した場合の扱い
- 出荷依頼作成後に発送通知や追跡番号をどこへ返すか
APIの機能と、条件分岐・監視・再試行を担う連携基盤の機能を混同しないことが、導入範囲を見積もるポイントです。
ECカート・モール・OMSとの連携範囲を判断する
オープンロジは、Shopify、ecforce、楽天市場、Yahoo!ショッピング、BASE、makeshop、STORES、TikTok Shop、Qoo10などとの連携を案内しています。独自システム向けのAPIもありますが、「連携対象である」ことと、受注・商品・在庫・出荷のすべてを自動化できることは同じではありません。
まず公式の連携一覧で、利用中のサービス名、対象アカウント、必要な契約や機能開放を確認します。そのうえで、次のデータごとに範囲を確かめます。
- 受注をオープンロジへ取り込めるか
- 商品情報やSKUを同期できるか
- 在庫数を販売チャネルへ返せるか
- 出荷依頼を自動作成できるか
- 発送完了や追跡番号を販売チャネルへ返せるか
- 入荷・出荷・在庫の状況をオープンロジ側で確認できるか
標準連携は対象チャネルごとのデータ範囲で選ぶ
Yahoo!ショッピングとのAPI連携では、オープンロジの画面で受注・入荷・出荷・在庫の変動を確認できると案内されています。販売チャネルと倉庫の画面を切り替える作業を減らせる点がメリットです。
Qoo10との連携では、注文情報の取り込み、受注管理、倉庫への出荷指示、配送手配、発送通知までの一連のオペレーションを設定・自動化できるとされています。一方、これはQoo10連携について示された範囲であり、他のカートやモールにも同じ機能があるとは限りません。
メガ割など注文が集中する時期でも、API連携によって注文の転記や重複入力は減らせます。ただし、倉庫の受け入れ能力、在庫確保、出荷締切、住所不備などの確認作業まで自動で解決するわけではありません。繁忙期の最大注文数と、例外注文を誰が処理するかを別に決めておく必要があります。
独自システム・ネクストエンジンは個別仕様を確認する
独自のECシステムや基幹システムを使う場合は、標準連携で不足するデータだけをAPIで接続する方法を検討します。すべてを新規開発するより、標準連携で扱える部分と独自実装が必要な部分を切り分けるほうが、開発・保守の範囲を抑えやすくなります。
ネクストエンジンは別仕様で対応すると案内されていますが、商品マスタの同期方向、在庫数の更新方法、受注から出荷実績・追跡番号の返却までの詳細は、利用環境ごとの確認が必要です。また、複数ショップへ約10分間隔で在庫数を同期する機能がネクストエンジンに非対応であることと、ネクストエンジン連携全体の在庫処理がないことは別の話です。機能名だけで対応範囲を判断しないでください。
注文条件に応じた出庫ルールと同梱指示
出荷依頼を作成するだけでなく、注文内容に応じてノベルティやチラシを同梱したい場合は、出庫ルールの条件と適用範囲を確認します。
条件別の同梱・流通加工を自動化できる範囲
出庫ルールでは、注文金額などの条件に応じた商品の追加、ノベルティ・チラシの同梱、流通加工の指示、配送オプションの設定を自動化できます。Yahoo!ショッピングでは、個人別・商品別の同梱に加え、定期購入回数や受注日時を条件に設定できると案内されています。
たとえば「定期購入の初回だけチラシを入れる」「一定金額以上の注文にノベルティを付ける」といった条件を、出荷作業への指示に反映できます。ただし、設定できる条件や指示内容は連携先によって異なるため、キャンペーン、定期購入、ギフト販売で必要な条件を先に洗い出して照合します。
出庫ルールの対象は、外部連携、CSV、APIで作成した出荷依頼です。つまり、標準API連携に限らず、後述するCSV・手動登録の注文にも適用できる可能性があります。ただし、対象となる出荷依頼の状態や利用サービスは、契約・機能設定とあわせて確認してください。
API未連携チャネルはCSV・手動登録で出荷依頼につなげる
API連携していないECカート、モール、実店舗の注文でも、OMSの受注登録機能を使えば、CSVアップロードまたは手動登録でオープンロジへ集約できます。APIに対応していない販売チャネルがあるからといって、物流を委託できないわけではありません。
CSV・手動登録でできることと残る作業
登録した注文は、受注ページでショップ別に管理し、フリー在庫数を確認したうえで出荷依頼へ進められます。住所不備などの注文を「確認待ち」として扱えるほか、国内配送だけでなく海外配送の注文情報もCSVで登録できる案内があります。
一方、API連携と違って、販売チャネルから注文データを出力し、CSVの形式を整え、登録結果を確認する作業は残ります。注文数が少なく更新頻度も低い場合は現実的ですが、注文量が多い場合は、CSV作成・重複登録防止・住所エラー対応の負荷を見積もる必要があります。
OMS課金と利用申請を確認する
CSV・手動登録機能を使って新しい販売チャネルを追加する場合は、新たなチャネル追加としてOMSの課金対象になる案内があります。利用を希望する場合は、OMS受注登録機能の利用希望を問い合わせる手続きが必要です。
見積もりでは、入荷・保管・配送などの物流費と、OMS利用料、マルチチャネル利用料、外部連携ツールの料金、自社開発・保守費を分けて確認します。Qoo10連携ではOMS・WMS一体型の利用料無料が案内される一方、マルチチャネルは別途利用料が必要とされています。すべての利用形態に同じ料金条件が適用されるとは限らないため、利用するチャネル数と登録方法を伝えて確認してください。
商材・在庫同期・出荷条件が運用に合うか確認する
APIが使えるかだけでなく、在庫更新の間隔、商材の保管条件、入荷処理の時間、当日出荷の締切を確認しなければ、導入後に売り越しや納期遅延が起こる可能性があります。
在庫同期は約10分間隔で、売り越しを完全には防げない
対応・開放済みの環境では、複数ショップへ在庫数を同期できます。ただし、案内されている同期間隔は約10分で、注文直後にすべての販売チャネルの在庫が変わる即時同期ではありません。
そのため、限定在庫商品やセールで短時間に注文が集中する商品では、在庫同期だけで売り越しを完全に防ぐことはできません。販売可能数に余裕を持たせる、注文集中時は販売を一時停止する、在庫確定後に出荷依頼を作成するなど、自社側の運用も必要です。対象サービスにも制限があり、Shopify・ecforceは利用対象が限られ、ネクストエンジンや旧方式のBASEはこの在庫同期機能に対応しない案内があります。
温度帯・期限管理は倉庫・機能開放・商材条件を先に確認する
賞味期限・製造年月日の管理や、定温・冷蔵・冷凍での保管は、機能開放、専用倉庫などの事前調整、商材ごとの取扱条件を満たす必要があります。通常倉庫は常温であるため、冷蔵・冷凍品を扱う場合は、保管場所、入荷から出荷までの温度管理、配送会社の対応可否を確認します。
APIの変更履歴には入荷実績のロット関連項目が登場しますが、期限や温度帯の情報をAPIのリクエスト・レスポンスでどこまで登録・取得できるかは、画面上の管理機能とは分けて確認してください。化粧品や香水も、通常保管の可否だけでなく、危険物性、配送会社の条件、資格が必要なラベル貼付などの加工可否を個別に確認する必要があります。
自動作成した出荷依頼にも締切・変更取消しの制約がある
通常の国内出荷では、営業日の12時30分までに「取込待ち」となった出荷依頼が当日出荷の対象です。日曜・祝日は出荷休業で、海外発送やAmazon FBA納品などは別条件になります。
APIで出荷依頼を自動作成しても、締切後に作成された依頼が当日出荷になるとは限りません。繁忙期は、最大出荷量、在庫確保、倉庫の稼働日、出荷締切、住所不備などの例外処理を事前に確認します。
API導入前に技術・契約面で確認すること
料金は物流費・OMS・マルチチャネル・外部ツールに分ける
API導入の費用は、APIだけで決まるとは限りません。次の費用を分けて、利用形態に応じて確認します。
- 入荷料、保管料、配送料、ピッキングや同梱などの追加作業費
- OMS・WMSの利用料、API未連携チャネルの受注登録費
- マルチチャネル利用料
- 外部連携ツールの利用料
- 自社で開発する場合の初期開発費、保守費、監視費
API利用に物流サービス契約が必要か、API自体に固定費や従量課金があるかは、対象サービスと契約条件で確認します。料金例を比較するときは、API料金だけでなく、月間注文数、SKU数、保管量、同梱作業、チャネル数をそろえることが大切です。
認証情報・処理上限・障害時の動作を仕様で確定する
認証情報は、ソースコードや共有ファイルに直接記載せず、アクセス権を限定した安全な保管先で管理します。実装前には、次の項目を公式仕様と契約環境で確認してください。
- トークンの発行方法、有効期限、権限範囲
- 不要になった認証情報の失効・再発行方法
- 漏えい時に停止できる単位と緊急連絡先
- APIのリクエスト上限と、超過時の応答
- 再試行までの時間、ページネーション、処理順序
- 出荷依頼を二重作成した場合のエラーと復旧方法
変更履歴には、レート制限超過時のリセット時刻や再試行可能までの秒数を示すレスポンスヘッダーの追加、出荷依頼作成が重複した場合に`409 Conflict`を返す変更が記載されています。大量処理では、上限に達したら待機する、処理を分割する、失敗した注文だけを再実行するなどの設計をあらかじめ決めておく必要があります。
まとめ
オープンロジAPIや標準連携では、商品・入荷・出荷・実績に関するデータをつなぎ、連携先によっては受注取り込みから出荷指示、配送手配、発送通知まで自動化できます。一方で、商品・在庫・出荷の対象範囲はサービス、契約、アカウント、機能開放状況によって異なります。
API未連携のカート・モール・実店舗でも、CSVや手動登録から出荷依頼へ進められます。導入前は、自社の販売チャネルと必要なデータ範囲を確認したうえで、在庫同期の約10分間隔、温度帯・期限管理、出荷締切、変更・取消し、OMSやマルチチャネルの費用、認証・API上限をまとめて確認しましょう。