倉庫会社のホームページに「WMS連携に対応」と書いてあっても、荷主は自社の受注データをそのまま渡せるのか、システムの変更が必要なのかを判断できません。問い合わせの後で、商品コードの整理や変換処理が必要だと分かれば、導入時期や費用の検討をやり直すことになります。
WMSは、倉庫内の入荷・出荷・在庫などを管理するシステムです。サイトでは製品名や接続方法だけでなく、どのデータを、どちらから渡し、誰が準備するかまで示します。荷主の担当者が、社内のシステム担当へ相談する材料を持ち帰れる案内にすることが大切です。
この記事では、倉庫会社の経営者・営業責任者・Web担当者に向けて、入荷予定・出荷指示・在庫結果の対応範囲を伝える方法を整理します。表は掲載内容を決める設計例です。特定の倉庫やWMSの接続可否を保証するものではなく、自社の契約・設定・運用を確認して書き換える前提で示します。
CSV・API・手作業を同じ分類に並べない
連携の説明で混同しやすいのが、データの形式、受け渡す方法、作業の進め方です。CSVは項目を区切って保存するデータの形式、APIはシステム同士が情報をやり取りするための窓口を指します。手作業は、人がファイルを出力したり取り込んだりする運用です。三つは同じ軸の選択肢ではありません。
そのため、「CSVは手動、APIは自動」と決めつけないようにします。CSVファイルを所定の場所へ置き、決まった時刻に取り込む運用もあります。一方、APIを利用できる製品であっても、荷主側との接続処理や項目の対応付けを用意しなければ使えない場合があります。
日本郵便のJPWMSは、CSVの取込や出力、項目・コードの変換などと、オプションのAPI連携を分けて紹介しています。AiR Logiの連携概要にも、CSV形式のデータと、手動・定時・定期自動という実行方法が示されています。これらは説明の軸を分ける参考であり、その機能が自社の利用環境に含まれるという根拠にはしません。JPWMSのインターフェイス機能・AiR Logiの連携概要
ホームページでは「受け取るデータ」「受渡し方法」「実行する人や時点」を分けて記載します。CSVという文字だけを大きく掲げるより、「荷主が指定形式で出力し、担当者が管理画面から取り込む」のように、実際に行う作業を短い文で示す方が導入後を想像しやすくなります。
入荷予定・出荷指示・在庫結果の対応表を作る
最初から全機能を並べるのではなく、検討中の荷主が使う三つのデータを確認します。入荷予定は倉庫に届く予定の情報、出荷指示は倉庫から出す作業の依頼、在庫結果は倉庫側から返す在庫の情報です。同じ商品を扱っていても、必要な項目、処理する時点、送受信の方向が異なります。
次の表は社内確認のひな型です。公開時は「要確認」のまま並べるのではなく、確認できた対応と条件へ置き換えます。対応していないデータは、無理に対応可能と見せず、代替手段や個別相談の対象を記載します。
| データ | 基本の方向 | 荷主と確認する内容 | 自社側で確定する掲載項目 |
|---|---|---|---|
| 入荷予定 | 荷主から倉庫 | 商品コード、予定数量、入荷予定日、変更の伝え方 | 受取形式、登録する担当、受付の時点、変更時の扱い |
| 出荷指示 | 荷主から倉庫 | 指示番号、商品と数量、必要な配送情報、取消の扱い | 受渡し方法、取込確認、締切、作業開始後の連絡先 |
| 在庫結果 | 倉庫から荷主 | 対象商品・拠点、数量の意味、必要な更新時点 | 返す項目、全件か変更分か、出力時点、確認する担当 |
ここでいう「基本の方向」は、説明を始めるための整理です。入荷した結果や出荷した結果も返す場合は、予定・指示とは別の行を追加します。「入荷連携」という一行にまとめると、予定の登録だけなのか、実際に受け入れた数量も返すのかが伝わりません。
表の近くには、対象となる倉庫・サービスと確認日を添えます。一部の拠点や特定プランだけで利用できる連携を、全拠点共通の機能として掲載しないためです。サービスが複数ある会社では、対応表をどのサービスに適用するか、見出しの段階で分かるようにします。

標準対応の中身と、追加作業の境目を示す
「標準対応」は便利な表現ですが、それだけでは準備の範囲が分かりません。指定の項目順であれば取り込めるのか、コード変換まで含むのか、初期設定は誰が行うのかを確認します。標準機能を利用する場合でも、初期設定が不要、追加費用がないと受け取られる書き方は避けます。
掲載文は「指定形式のCSV取込に対応。商品コードと数量単位の確認、初期設定が必要」のように、できることと条件を続けて書きます。ただし、この文も自社で確認できた場合に使う例です。確認できていない変換機能や設定支援を、一般的な機能だからという理由で足してはいけません。
個別開発が必要な場合は、「別途相談」の一語で終わらせず、確認する対象を示します。荷主のシステムから必要なデータを出せるか、変換処理をどこに置くか、倉庫側と荷主側のどちらが変更するかが検討材料になります。見積もりや開始時期は、その範囲を確認してから案内する流れにします。
既存の連携先を掲載する場合も、製品名が一致するだけで接続できるとは限りません。ネクストエンジンの倉庫連携ページは、対応WMSの一覧とともに、一覧外のWMSに対するCSV連携やAPIによるアプリ開発を案内しています。自社サイトでも、連携先の一覧、利用条件、個別確認の入口を分ける構成が参考になります。ネクストエンジンの倉庫連携案内
手動で受け渡す範囲も、実際のサービスとして具体化します。誰が出力し、どこへ渡し、誰が取り込むのかを示し、受付の締切や休日の扱いを確認します。「手動対応可」と書くだけでは、倉庫がデータを作り直してくれるのか、荷主が指定形式へ整えるのかが曖昧なままです。
同じCSVでも商品コード・数量・取消を確認する
CSVを出力できることと、そのまま取り込めることは別です。同じ「商品コード」という項目でも、荷主側の商品番号と倉庫側の管理番号が一致しないことがあります。数量が個数なのかケース数なのかでも、必要な処理が変わります。サイトには、項目の見本を確認して対応範囲を判断する旨を示します。
相談時の見本は、まず項目名と仮の値で構成できるかを確認します。問い合わせフォームで、実際の購入者の住所や認証情報を一律に提出させる必要はありません。詳細なデータを扱う段階では、担当者と受渡し方法を決めます。公開ページに接続用の鍵や内部の設定値を載せることも避けます。
出荷指示では、取消や変更を受け付ける条件が重要です。荷主が注文を取り消しても、倉庫で出荷作業が始まっていれば、データの変更だけでは対応できない場合があります。公開するのは内部処理の細部ではなく、変更の連絡方法、確認が必要な時点、担当窓口です。
在庫結果では、いつの、どの範囲の数量かをそろえます。保管している総数と、出荷に使える数量は、運用によって異なることがあります。対象拠点や商品、出力時点を説明せずに「在庫を自動連携」とだけ書くと、荷主が販売管理に必要とする数値との違いが後から表面化します。
全件を渡すのか、前回からの変更分を渡すのかも確認します。同じファイルを再度取り込んだときの扱いは、データと仕組みによって異なります。「失敗したらもう一度送る」と一律に案内せず、取込状況の確認と再送判断を誰が担うかを運用の説明に含めます。
送信できた後の確認担当まで案内する
データを送信したこと、倉庫のシステムへ登録されたこと、現場の作業が完了したことは別の状態です。荷主がファイルを送っただけで出荷を受け付けたと判断しないよう、どの通知や画面で受付を確認するかを整理します。サイトではその概要を示し、詳しい手順は導入時の案内へつなげます。
取込でエラーが発生したときも、連絡先があるだけでは十分ではありません。荷主側で修正する項目なのか、倉庫側の登録内容を確認する必要があるのか、最初に確認する担当を決めます。正常な行だけ登録されるのか、ファイル全体が取り込まれないのかは、実際の仕様を確かめて説明します。
定時連携を利用する場合は、予定時刻と実際の受付確認を分けます。自動実行の予定があるからといって、毎回処理が完了したとは限りません。遅延時の確認方法や代替の受渡し方法を用意する場合は、切替を決める担当と、元の経路との二重登録を防ぐ確認もそろえます。
こうした情報を公開ページへすべて書き込む必要はありません。サイトには「受付結果の確認方法と、エラー時の担当範囲を導入前に取り決める」など、確認する内容を示します。詳細な作業手順と役割分担は、接続テストや運用開始の準備で照合する構成にします。

導入前のテストと、変更時の確認を伝える
連携の準備では、正常なデータが一度通ったことだけで運用開始を決めないようにします。商品が未登録の場合、数量の単位が異なる場合、同じ指示を再送した場合など、実際の業務で確認が必要な場面を担当者同士で挙げます。テストの内容は利用する仕組みに合わせて決め、結果を双方が確認できる形で残します。
サイトに載せるのは、テストデータの作り方の細部ではなく、運用開始までに何を確認するかです。「項目の確認、接続・取込テスト、受付結果の確認、担当範囲の合意を経て開始」のように、自社が実施する準備を示します。未実施の検査を標準工程として書かず、開始希望日から逆算して確認する流れを案内します。
開始後の変更も確認対象です。荷主が受注管理システムを入れ替えたり、商品コードの付け方を変えたりすると、以前の受渡し条件がそのまま使えない場合があります。変更予定を相談する窓口と、再確認が必要な項目を運用資料に置き、公開ページにも既存連携の変更を相談できる入口を用意します。
連携先一覧や対応表の更新は、サイト担当者だけでは判断できません。対象拠点、利用プラン、接続先の変更があったときに誰が連絡するかを決めます。終了した連携や新規受付を止めた方式を残さないよう、営業資料との整合も確認します。掲載した日と内容を確認した日を区別して記録しておくと、古い条件を探しやすくなります。
問い合わせ前に用意する情報を絞る
問い合わせの入口では、利用中のシステム名、希望するデータ、対象となる倉庫業務、開始希望時期を尋ねます。システムの版や契約プランが分かれば記載してもらい、不明な場合は相談を続けられるようにします。最初からすべての技術項目を必須にすると、営業担当者が相談を始めにくくなります。
項目の見本や現在の受渡し手順は、担当者から案内する追加資料として整理できます。「システム連携の相談」というボタンの近くに、分かる範囲の情報で相談できることと、確認後に見積もり・対応範囲を案内することを示すと、問い合わせの目的が明確になります。
公開前には、営業担当だけでなく、倉庫の運用責任者とシステム担当、必要に応じて提供会社が表を照合します。製品の資料にある機能と、自社で提供しているサービスを分け、実績のない接続先や未確認の処理速度を掲載しないようにします。確認日と更新担当を社内の記録にも残します。
WMS連携の案内は、方式の名前を増やすより、荷主が準備する内容と倉庫が担う範囲を明らかにすることから始めます。入荷予定・出荷指示・在庫結果の三つを並べ、方向、形式、時点、担当を確認すれば、「連携可能」という一文を具体的な導入相談につながる情報へ変えられます。
倉庫の作業範囲や荷主向けの案内をまとめて見直す場合は、倉庫・物流センターのホームページ制作をご覧ください。事業ページの構成は事業紹介ページの作り方、EC側で整理する条件はECサイト制作の要件整理も参考になります。
参照資料
- 日本郵便「インターフェイス機能」:HTMLの機能説明を参照。リンク先のAPI仕様PDFは未確認。
- AiR Logi「S3/FTP/SFTP連携:連携概要」:本文の形式・実行方法・エラー通知等を参照。図とリンク先の設定手順は未確認。
- ネクストエンジン「倉庫連携」:概要と一覧外の連携案内を参照。個別アプリの仕様は未確認。
資料確認日:2026年9月16日。掲載条件は各サービスの最新情報と、自社の利用環境で確認してください。


