受注→出荷指示→ヤマトB2・佐川e飛伝への転記をなくす方法

ECの注文が増えてくると、意外と負担になりやすいのが「送り状を作るための転記」です。

EC管理画面を開き、購入者の氏名、郵便番号、住所、電話番号を確認する。次にヤマト運輸のB2クラウドや佐川急便のe飛伝へ入力する。注文備考を見ながら、ギフト包装や同梱の有無も確認する。

1件ずつなら数分で終わる作業でも、1日30件、50件、100件と増えれば大きな負担になります。

さらに問題なのは、作業時間だけではありません。

住所を一つ下の注文からコピーしてしまった、前のお客様の情報が残っていた、同梱指示を見落とした、といった出荷ミスにつながる可能性があります。

そこで「AIで送り状作成を自動化できないか」と考えるEC事業者も増えています。

ただし、結論から言うと、送り状発行のすべてをAIに任せる必要はありません。

むしろ、決まったデータの転記は「連携」で消す。住所や備考など判断が必要な部分だけ「AI」で補助する。最後の出荷確認は「人」が担当する。この3つに分ける方が、少人数のEC事業者には現実的です。

この記事では、EC受注から出荷指示、ヤマトB2クラウド・佐川e飛伝への送り状データ作成、出荷後の追跡番号反映までに範囲を絞り、「どこまでを連携で消し、どこからAIを使うのか」を具体的に解説します。

倉庫・物流代行の選び方や商品登録については扱いません。今のEC運用を大きく変えず、毎日の送り状転記を減らしたい事業者向けの記事です。

1日50件の送り状を手入力し、月2〜3件の誤配送が出ていたネットショップ

まず、少人数ECで起こりやすい状況を想定例で見てみましょう。

※以下は特定企業の実在事例ではなく、よくある業務状況をもとにした想定例です。

出荷量が増えても送り状作成だけは手作業のまま

ある小規模ネットショップでは、以前は1日10件程度だった注文が、広告やリピーターの増加によって1日50件前後まで増えていました。

受注管理そのものはECシステムを使っています。

しかし、出荷時には担当者が注文一覧を開き、次のような情報を確認しながら送り状発行システムへ入力していました。

• 氏名
• 郵便番号
• 住所
• 電話番号
• 配送希望日
• 配送時間帯
• 品名

注文数が少ない頃は、それほど大きな問題ではありませんでした。

ところが50件になると、1件1分でも50分です。注文備考の確認や修正、送り状の再発行などが入れば、毎日1時間以上を送り状作成に使うこともあります。

コピー＆ペーストでも取り違えは起きる

「手入力ではなくコピー＆ペーストだから安全」と考える人もいます。しかし、コピー＆ペーストでもミスは発生します。

たとえば、注文Aの氏名をコピーし、注文Bの住所を誤ってコピーして、そのまま送り状を発行してしまうような組み合わせミスです。

また、前の注文でコピーした住所がクリップボードに残っていると、同じ住所を別のお客様へ貼り付けてしまう可能性もあります。

この想定例では、月に2〜3件ほど、住所や注文内容の確認が必要になる誤配送・出荷ミスが発生していました。

件数だけを見れば少なく感じるかもしれません。しかし、誤配送が1件起きれば、次のような複数の仕事が発生します。

• お客様への謝罪
• 商品の再発送
• 誤配送品の回収
• 送料の追加負担
• 問い合わせ対応
• 在庫修正

送り状作成で数分短縮する以上に、そもそも転記する工程を減らすことが重要です。

問題は担当者の注意力ではなく「転記する工程」が残っていること

こうしたミスが起きると、「もっと確認してください」「ダブルチェックしてください」と対策しがちです。

しかし、50件の注文を人が入力して50件すべてを再確認する仕組みでは、注文数が増えるほど負担も増えます。

本当に見直すべきなのは担当者の注意力ではなく、ECにすでに入っている情報を、なぜもう一度人が送り状ソフトへ移しているのかという業務フローです。

結論｜出荷業務は「連携・AI・人の確認」の3つに分ける

送り状発行を効率化するときは、最初から「AIで何ができるか」を考えない方が分かりやすくなります。

まず業務を、1. 決まったルールで処理できる仕事、2. 内容を読んで判断する仕事、3. 最終責任として人が確認する仕事、の3つに分けます。

目安は次のとおりです。

ポイントは、AIと自動化を同じものとして考えないことです。

「郵便番号」という列の値を、別のCSVの「郵便番号」に入れるだけならAIの判断は必要ありません。

一方で、「プレゼントなので納品書は入れないでください。できれば土曜日着でお願いします」という備考から、ギフト注文、納品書不要、配送希望あり、と読み取る作業にはAIが役立つ可能性があります。

この違いを理解すると、必要以上に複雑な仕組みを導入せずに済みます。

受注CSV→送り状CSVの変換にAIはいらない

送り状自動化の第一歩は、ECから取得できる注文データを確認することです。多くのECサービスでは、注文情報をCSVなどの形式で出力できます。ここですでに購入者の氏名や住所がデータになっているのであれば、それを人がもう一度送り状ソフトへコピーする必要はありません。

郵便番号・住所・氏名を別の列へ移すだけなら連携でよい

送り状ソフト側にも、お届け先名、郵便番号、住所、電話番号など、それぞれ入力先があります。この場合に必要なのは「どの項目をどこへ移すか」というルールです。AIに毎回「この注文情報を送り状形式にしてください」と依頼する必要はありません。決められた列から決められた列へ移すだけなら、CSV変換、表計算ソフト、連携ツール、プログラムなどで固定処理した方が結果を予測しやすくなります。

「ECの列」と「送り状ソフトの列」を対応させる

この作業は「マッピング」と呼ばれることがあります。難しそうに聞こえますが、考え方は単純です。ECの注文番号を送り状側の管理番号へ、お届け先氏名をお届け先名称へ、郵便番号をお届け先郵便番号へ、といった対応表を最初に作ります。一度ルールを決めれば、次回から同じ変換を繰り返せます。ただし、実際の項目名称、必須項目、文字数、区分値などは送り状サービスごとに異なります。実装するときは、必ず利用中サービスの最新公式仕様を確認してください。

毎日同じ変換をするなら自動処理にする

最初はExcelやスプレッドシートで変換しても構いません。ECからCSVを出力し、決めたシートへ読み込み、送り状用の列へ並び替え、CSVとして保存して送り状ソフトへ取り込むだけでも、一件ずつ住所をコピーする作業は大幅に減らせます。さらに件数が増えた場合は、ECから送り状発行用データまでを自動連携する仕組みに進めます。重要なのは、いきなり高度なAIシステムを導入するのではなく、最も単純な転記から順番に消すことです。

送り状発行の自動化はどこまでできる？

ECから受注データを取り出す

最初に確認するのは、利用しているECからどの項目を取得できるかです。注文番号、お届け先氏名、郵便番号、住所、電話番号、配送方法、配送希望日、時間帯、注文備考などを確認します。ここで必要情報がすでにデータとして取得できるなら、手入力を残す理由は少なくなります。

送り状用データへ整形する

EC側と送り状側で住所の持ち方や列構成が異なる場合は、配送会社側で受け取れる形へ変換します。こうした変換も基本的にはAIではなくルール処理です。

送り状ソフトへ取り込む

配送会社側がデータ取り込みに対応している場合、一件ずつ入力せず複数件をまとめて処理できます。佐川急便のe飛伝Ⅲでは、CSV、Excel、固定長形式のデータを取り込み、一括で送り状を作成できると案内されています。ヤマト運輸ではB2クラウドの機能をWebAPIとして利用できるB2クラウドAPIも案内されています。件数が少ない事業者ならCSV連携で十分な場合もあり、件数やシステム要件によってAPI連携を検討するという段階的な考え方が現実的です。

送り状を印刷して商品と照合する

データが自動で送り状へ反映されても、商品そのものまで正しいとは限りません。送り状転記をなくすことと、出荷確認をなくすことは分けて考える必要があります。

AIが必要になるのは「決まった変換」ではなく「判断」がある部分

住所の表記ゆれを候補として検出する

住所の書き方には表記ゆれがあります。AIを使い、表記が通常と異なる注文や確認した方がよさそうな住所を候補として抽出する方法があります。ただし、AIが推測で住所を書き換え、そのまま発送する仕組みは避けるべきです。AIは修正者ではなく、確認対象を絞る補助役として使うのが安全です。

番地抜け・住所不足の可能性を見つける

住所が市区町村や町名で終わっている注文があれば、番地が不足している可能性があります。ただし必ず間違いとは限らないため、AIには「住所不足の可能性があります」と候補を出させ、人が元注文を確認する運用が向いています。

同梱指示を注文備考から拾う

「昨日注文した分と一緒に送ってください」のような備考は、単純なCSV変換だけでは判断できません。AIで注文備考を読み、「同梱確認が必要」というフラグを付ければ、担当者は備考を全件読む必要がなくなります。

ギフト包装・明細不要などの指示を分類する

「プレゼントなので値段が分かるものは入れないでください」といった文章から、ギフト、明細不要、包装確認などへ分類する仕事はAIと相性があります。最終決定ではなく、出荷担当者が見るべき注文を目立たせる用途に向いています。

AIの判断だけで送り状を確定しない

AIは文章の意味を常に100％正しく判断できるわけではありません。AIが例外を検出し、担当者が確認し、送り状を確定する順番を基本にします。人をゼロにするのではなく、人が確認する件数を減らすと考えてください。

ヤマトB2クラウド・佐川e飛伝への取り込みは「形式を合わせる」と考える

ECから出したCSVをそのまま取り込めるとは限らない

CSVはファイル形式の一つにすぎません。同じCSVでも、列の順番、項目名称、必須項目、区分値、文字コード、日付形式などが違えば、そのまま取り込めない可能性があります。ECのCSVを出し、送り状ソフトが必要とする形式へ変換し、取り込むという中間処理が重要です。

ヤマトB2クラウドは公式仕様に合わせて設計する

ヤマト運輸ではB2クラウドの送り状発行機能をWebAPIとして利用できるB2クラウドAPIを提供しています。公式案内では、CSVやExcelを介さず、サービスに登録された配送情報をB2クラウドへ送って送り状発行につなげられるとされています。ただし、APIを使う場合は開発や利用条件の確認が必要です。1日20〜50件程度のECであれば、まずCSV連携で十分なケースもあります。

佐川e飛伝も取り込み項目・形式を確認する

佐川急便のe飛伝Ⅲでは、CSV、Excel、固定長ファイルから送り状データを取り込めると案内されています。ただし、CSVなら何でも取り込めるわけではありません。項目割り当てや区分値、利用中バージョンの仕様を確認してください。

CSVをExcelで触るときにも注意する

e飛伝Ⅲの公式FAQでは、UTF-8のCSVを古いExcelで編集・上書き保存すると形式が変わり、取り込めなくなる場合があることも案内されています。できればECから変換処理、送り状取込用CSVまでを一連のルールにし、途中で担当者が列を削除したりファイル形式を変えたりしなくても済む設計にします。

仕様変更を前提に公式マニュアルを確認する

送り状システムは、項目、区分値、対応サービス、仕様などが変更される可能性があります。実際に自動化するときは、最新の取込レイアウト、必須項目、文字数、使用できる文字、区分値、文字コード、出力形式、APIの利用条件などを公式サイト・公式マニュアルで確認してください。

ヤマトと佐川を併用していても元データは1つにする

受注データを配送会社ごとに手直ししない

避けたいのは、ECからCSVを出した後にヤマト用Excelと佐川用Excelへそれぞれコピーし、担当者が別々に修正する運用です。せっかくECに注文データがあるのに、新しい転記作業を増やしてしまいます。

共通の出荷データから配送会社別CSVへ分岐させる

EC受注データから共通の出荷データを作り、そこからヤマト用形式と佐川用形式へ分岐させます。注文番号、氏名、郵便番号、住所、電話番号、配送会社、配送指定日、時間帯、品名などを共通データに持たせる考え方です。

配送会社を変更しても作業が増えにくい

この設計なら、配送会社を追加・変更したときもEC側の受注データを一から作り直す必要がありません。ECから各配送会社へ直接バラバラにつなぐのではなく、自社の出荷データを一つ持つという考え方がポイントです。

出荷後は追跡番号をECへ戻すところまで連携する

送り状を発行しただけでは自動化は半分

ECから送り状ソフトへの流れだけでなく、出荷後には送り状ソフトからECへ追跡番号を戻す逆方向の連携も必要です。50件の送り状を自動発行できても、50個の追跡番号をECへ手入力していては、別の転記作業が残ります。

追跡番号と注文番号を対応させる

送り状用データを作る段階で、ECの注文番号と送り状データの対応関係が分かるようにしておけば、後から追跡番号を戻しやすくなります。自動化は送り状を作る前だけでなく、出荷後に何の情報を戻すのかまで考えて設計する必要があります。

追跡番号をECへ戻す

佐川急便のe飛伝Ⅲでは、送り状作成履歴のデータをCSVファイルへ出力できると案内されています。こうした出力データを利用できれば、出荷履歴を出力し、注文番号と送り状番号を対応させて、EC側へ反映する流れを検討できます。実際の自動反映可否は、利用しているECサービスや連携方法、契約内容によって異なります。

お客様への発送連絡はAIで下書きを作れる

追跡番号そのものは連携で取得する

送り状番号はAIに考えさせるものではありません。送り状システムから正確なデータを取得し、その値をEC側へ渡します。ここは連携です。

お客様向けの文章作成はAIが得意

一方、発送案内の文章はAIで下書きを作れます。通常発送、一部商品の分割発送、発送遅延、ギフト発送、複数口発送など、状況ごとに文章を変える場合は生成AIを使う価値があります。

通常発送・遅延・分割発送などで文面を出し分ける

事実データは連携、文章表現はAIという役割分担が基本です。AIに追跡番号や発送日を推測させてはいけません。

出荷ミスを減らすには「全部自動化」よりチェックポイントを減らす

住所を目視で転記確認する作業をなくす

ECの住所データをそのまま送り状用データへ連携できれば、人が自分でコピーしたものを自分でもう一度確認する業務を減らせます。

エラーがある注文だけ人が見る

理想は、50件の注文をシステムとAIが一次確認し、通常注文はそのまま処理し、住所が短い、番地不足の可能性、同梱指示、ギフト指定、配送希望日の特別指定、注文備考あり、といった例外だけ担当者が確認する流れです。

商品と送り状を最後に照合する

一方で残した方がよいのが、実物との最終照合です。送り状データが完全でも、梱包する商品が間違っていれば誤配送になります。注文番号、商品、個数、送り状の関係を最終確認できる仕組みを残します。

AIが修正した情報は確認対象にする

AIが住所不足などを指摘しても、自動で配送先を書き換えるのではなく、AIが異常を検知し、人が元注文を確認し、必要ならお客様へ確認して正式な配送先を確定する順番にします。

少人数ECが送り状転記をなくす導入手順

STEP1｜現在コピペしている項目を書き出す

まず、システム選定より先に現在の作業を書き出します。注文番号、氏名、住所、郵便番号、電話番号、配送希望日、時間帯、品名などのうち、何を人が入力しているのか確認します。

STEP2｜ECから出せるデータを確認する

現在利用しているECサービスから何を取得できるか確認します。CSVで出せるのか、API連携があるのか、外部連携サービスがあるのかを調べます。

STEP3｜送り状ソフトの必要項目を確認する

ヤマトB2クラウド、佐川e飛伝など、現在利用している送り状発行環境の最新仕様を確認します。必須項目、任意項目、文字数、区分値、ファイル形式、文字コードなどを見ます。

STEP4｜項目対応表を作る

ECの項目と送り状側の項目を並べ、そのまま移せる項目、結合や変換が必要な項目、判断が必要な項目に分けます。

STEP5｜まずCSV変換を自動化する

最初から完全自動を目指す必要はありません。ECからCSVをダウンロードし、自動変換して送り状ソフトへ取り込むところまででも十分に効果があります。

STEP6｜住所・備考など例外処理だけAIを試す

CSV連携が安定したら、注文備考、住所不足、ギフトメッセージ、同梱依頼など、人がまだ読んでいる項目へAIを使います。

STEP7｜追跡番号をECへ戻す

送り状発行後の転記も確認します。CSV、API、外部連携などで追跡番号をEC側へ戻せるか確認します。

STEP8｜少量の注文でテストしてから本運用する

いきなり全件を自動処理せず、まず5件、10件程度で、氏名、住所、電話番号、配送指定、注文番号、追跡番号などが正しく対応するか確認します。長い住所、法人名入り、建物名あり、離島、ギフト、同梱、時間指定など通常と異なる注文もテストします。

送り状自動化を始める前のチェックリスト

• ECから注文情報をCSVなどで出力できる
• 注文番号を一意に管理している
• 1日20件以上の送り状を作ることがある
• 同じ住所をECと送り状ソフトへ二重入力している
• ヤマトB2クラウドまたは佐川e飛伝を利用している
• 配送会社を複数利用している
• 注文備考を毎回人が読んでいる
• ギフトや同梱の例外処理がある
• 発送後に追跡番号をECへ入力している
• 発送完了メールの文面を人が作っている
• 出荷件数が増えると送り状作成が遅れる
• 住所転記や送り状選択のミスが起きたことがある

複数当てはまるのであれば、送り状ソフトそのものを変更する前に、今のECと送り状ソフトの間に残っている転記を整理する価値があります。

よくある質問

ヤマトB2へECのCSVをそのまま取り込めますか？

ECと送り状側でデータ項目や形式が異なる場合があるため、そのまま利用できるとは限りません。まずECから取得できる項目と、送り状側の最新取込仕様を比較してください。

送り状発行は全部AIに任せた方が効率的ですか？

いいえ。氏名や住所などの決まった転記は通常のデータ連携の方が向いています。AIは住所不足の候補や同梱・ギフトなど、判断が必要な例外処理に絞るのがおすすめです。

AIを使えば出荷ミスを完全になくせますか？

完全にはなくせません。AIにも誤判断の可能性があります。例外候補の抽出に使い、最終的な住所変更や出荷確定は人が確認できる仕組みを残してください。

ヤマトと佐川を併用していても自動化できますか？

可能性があります。共通の出荷データを作り、そのデータから配送会社ごとの取込形式へ変換する設計にすると二重管理を減らせます。実際の対応可否は各サービスの最新仕様を確認してください。

送り状だけでなく追跡番号の登録も自動化できますか？

利用するECや送り状サービスの機能・連携方法によりますが、出荷履歴データなどから注文番号と追跡番号を紐付け、ECへ戻す方法を検討できます。送り状発行だけで終わらず、追跡番号反映までを一つの業務フローとして設計することが重要です。

まとめ｜転記は連携で消し、判断だけAIに任せる

ECの送り状発行を効率化するとき、最初から「AIに全部やらせる」と考える必要はありません。最も重要なのは、出荷工程を分けることです。

氏名・郵便番号・住所・電話番号など、決まったデータの転記は連携で消す。住所表記の確認、番地不足の候補検出、同梱、ギフトなど、人が文章を読んでいる部分にAIを使う。商品と送り状、AIが判断した例外など、最後に責任を持って確定する部分は人が確認する。この3つに分けると、必要以上に大きなシステムを導入しなくても改善できる可能性があります。

特に少人数のEC事業者では、ECからCSVを出し、送り状形式へ自動変換し、B2クラウド・e飛伝などへ取り込み、例外だけAIと人が確認し、送り状発行後は追跡番号をECへ戻し、発送連絡文をAIで作成する、という順番で考えると整理しやすくなります。

送り状の手入力をなくす目的は、担当者を減らすことではありません。人が転記作業に時間を使わず、本当に確認が必要な注文だけを確認できる状態を作ることです。

なお、B2クラウド・e飛伝などの取り込み形式、項目、区分値、APIの提供条件は変更される可能性があります。実装前には必ず各社の最新公式情報をご確認ください。

毎日ECの注文画面から送り状ソフトへ住所をコピーしている場合、最初から大きなシステムへ入れ替える必要はないかもしれません。

まずは、使用しているECサービス、配送会社、B2クラウド・e飛伝など現在の送り状発行方法、1日のおおよその出荷件数、人が転記している項目、同梱・ギフトなどの例外処理、発送後の追跡番号登録方法を整理すると、「CSV連携だけで消せる作業」と「AIを使う価値がある作業」が見えてきます。

今使っているECや送り状ソフトを大きく変えず、どこから自動化できるのか確認したい方はご相談ください。