LINE受発注の商品マスタ登録とは？初回登録の担い手とCSV連携で確認すべき点

◆監修・編集責任者　小園 将隆　2026年9月28日

B2B EC-COLUMN

LINE受発注の「商品マスタ登録」は誰が何をする作業か

取引先からの注文をLINEで受けられるようにする——そう決まった直後に受注側の担当者へ回ってくるのが、商品マスタの登録です。
取り扱う品目が数百、数千とある卸では、誰がどこまで入力するのかが見えないまま、作業量の不安だけが先に立ちます。
ただ、公開情報で確認できる範囲では、初回の商品登録はベンダー側が代行すると明記しているサービスがあります¹³。
むしろ注意したいのはCSVのほうで、両社の説明はいずれも受注データを既存の基幹システムへ出力する用途であり、商品情報を取り込む一括登録の話ではありません。
自社に残る仕事は、入力そのものより、渡す商品情報を整えることと、データの向きを取り違えずに確認することに寄ります。

商品マスタ登録が指す範囲

受発注の仕組みでいう商品マスタは、取引先が注文画面で選ぶ商品の一覧そのものです。
ここに載っていない商品は発注する側の画面に出てこないため、稼働前にひととおりを登録しておく必要があります。
TANOMUの公式サイトでは、この作業が「初回の商品登録や得意先登録」と並べて説明されており¹、登録の対象が商品の情報だけでなく、どの取引先にどう売るかという得意先側の情報にも及ぶことが分かります。
商品マスタ登録という一語で呼ばれていても、実際には自社の商いの情報をシステムへ移す作業のまとまりだと考えたほうが、準備の見当はつきやすくなります。

作業量を見積もるとき、最初に見るべきは商品の点数ではなく、その情報がいまどこに、どんな状態で置かれているかです。
販売管理システムの商品台帳に一式そろっている会社もあれば、定番品は台帳、スポット品はFAXの注文書、価格は営業が持つ価格表の最新版、という具合に散らばっている会社もあります。
同じ商品が台帳では正式名称、注文書では現場の略称、価格表では旧商品名で書かれていることも珍しくありません。
登録作業が重くなる原因は入力の手数そのものよりも、この食い違いを一つずつ突き合わせて「これは同じ商品か」を判断する部分に寄ります。

登録画面にどんな入力項目があり、何が必須で何が任意なのかは、今回確認したTANOMUとL-Pochiの公開情報からは読み取れませんでした。
項目数が分からない以上、何項目×何点だから何時間、という計算は導入前には立ちません。
その代わりに手元でできるのは、自社の商品情報を一つの表に集めたとき、どれだけ空欄や重複が残るかを見ておくことです。
ここが埋まっていれば、どの項目を求められても渡す側の負担は小さく済みますし、逆に埋まっていなければ、誰が入力するかに関わらず同じだけの整理が必要になります。

もう一つ、登録の前に決めておくと後が楽になるのが、載せる商品と載せない商品の線引きです。
廃番間近の品や、特定の一社にだけ出している特注品まで一覧に並べると、発注側の画面が見づらくなり、かえって問い合わせが増えることもあります。
逆に絞りすぎれば電話やFAXでの注文が残り、仕組みを入れた意味が薄くなります。
この判断は商品を一番よく知っている自社にしかできないため、登録作業そのものを誰が担うにしても、対象範囲を決める時間は自社の側に見込んでおく必要があります。

初回登録をベンダーが代行する事例（TANOMU・L-Pochi）

作業量への不安に対して、確認できた二つのサービスはどちらも「最初の登録はこちらでやります」という立て方をしています。
TANOMUの公式サイトには、システム稼働時に障壁となる初回の商品登録や得意先登録は当社が対応する、と明記されています¹。
提供している側が初回登録を「稼働時の障壁」と呼んでいるのは、導入が止まりやすい場所としてそこが知られている、という裏返しでもあります。

LINE連携受発注システムのL-Pochiも同様で、面倒な商品登録は不要で自社が登録を代行する、と公式サイトで説明されています³。
運営会社も対象とする業種の説明も異なる二つのサービスが、同じところを利用者の負担として取り除こうとしている点は、単なる売り文句として読み流さないほうがよさそうです。
ただしこれは公開情報で確認できたのが二社だという話であって、LINEを使った受発注サービス全体がこの方式だと言えるわけではありません。
自社でファイルを用意して登録する前提のサービスもあり得ますから、候補に挙げたサービスごとに、初回登録を誰がやるのかは個別に聞く必要があります。

代行してもらえる場合でも、自社の作業がなくなるわけではない点は押さえておきたいところです。
ベンダーが登録するのは、こちらが渡した商品情報です。
前の項で触れた表記の食い違いや、価格表の版が古いままといった状態は、渡した時点のまま画面に載ります。
他社が入力する分、間違いに気づけるのは自社の確認作業だけになるので、登録後に一覧を見て、規格や入数の表記が取引先の見慣れた形になっているかを見る時間は必要です。

そして、代行の範囲と費用の扱いは、どちらのサイトの記述からも読み取れませんでした。
初期費用に含まれるのか、点数に応じて変わるのか、二回目以降のまとまった登録も同じように頼めるのかは、公開情報では確認できない部分です。
商談の場では「代行してもらえますか」で止めず、どこまでを、どの形式で渡せば、いつまでに登録が終わるのかまで踏み込んで聞くと、稼働日から逆算した準備の計画が立てられます。

CSV連携は商品マスタの一括登録ではなく何に使われているのか

CSV機能の実態は受注データの出力

初回の登録を任せられると分かると、次に気になるのは日々のデータのやりとりです。
資料に「CSV連携」と書いてあれば、自分で作った商品一覧のファイルをアップロードして一括登録できる機能を思い浮かべる方が多いはずです。
ところが、確認できた記述はそのどちらでもありませんでした。

TANOMUでは、受注データを出力して利用中の基幹システムにインポートでき、自社の基幹システムにあわせた形で出力できるためシステムの新規開発が不要だと説明されています¹。
ここで動いているデータは、LINEで届いた注文の内容です。
向きは、受発注サービスから自社の基幹システムへ、という一方向です。

L-Pochiの説明も同じ向きで、注文内容を日別・注文別にダウンロードでき、自社で使っている基幹システムにそのデータをインポートするだけ、と書かれています³。
加えて、業界ごとに違う商習慣に合わせた基幹システム向けのCSVデータのカスタマイズにも対応するが、それは別料金だと明記されています³。
出力の形を自社の取込仕様に合わせる部分が、標準の範囲ではなく個別の対応として扱われていることは、見積もりを読むときの目印になります。

なお、インフォマートのBtoBプラットフォームには、出力項目を選ぶ、並び順を変える、字数を制限するといった設定や、タスク機能で指定した時間に連携ファイルを用意し、FTPSやHULFTを使って外部サービスとつなぐ仕組みが説明されています²。
ただしこれはプラットフォーム全体のCSV連携機能としての説明で、TANOMUの商品マスタに関する機能として書かれたものではありません。
同じ会社が提供しているからといって、同じ細かさの設定がそのまま使えると読み替えないほうが安全です。

この向きのCSVで減るのは、LINEに届いた注文を見ながら基幹システムの受注入力画面へ打ち直す作業です。
残るのは、出力した項目と基幹側の取込仕様が合っているかという最初の取り決めと、取り込んだあとに件数や内容を目で確かめる工程です。
商品情報そのものは、この経路では動いていません。

自分で一括登録するCSVではない可能性

同じCSVという言葉でも、向きが違えば担当者の負担も変わります。
受注データの出力は、システムから自社へ出ていく向きです。
商品マスタの一括登録は、自社からシステムへ入れていく向きです。
資料に書かれていたのは前者だけで、後者についての形式や件数の上限は、今回確認した範囲では記載がありませんでした。

この違いが効いてくるのは、稼働した後です。
初回の登録をベンダーが引き受けてくれても、新商品が出たとき、規格が変わったとき、価格を改定したときには、誰かがその変更を画面に反映させなければなりません。
取込用のCSVが使えるなら、手元でまとめて直して一度に上げることができます。
使えないなら、管理画面で一件ずつ直すか、ベンダーに依頼するかのどちらかになります。

ですから質問の言い方を分けておくと、答えの食い違いが起きません。
「CSVに対応していますか」ではなく、受注データはどの形式で出力できますかという問いと、商品データをCSVで取り込めますか、その場合の項目と件数の上限はどうなりますかという問いを、別々に聞くということです。
前者に詳しい説明が返ってきたのに後者が曖昧なら、その時点で運用の設計を考え直す材料になります。

もう一点、出力側の形を自社に合わせる作業が別料金として扱われる例がある以上³、費用は初期費用と月額だけでは比べられません。
自社の基幹システムがどんな形式のファイルを受け付けるのか、桁数やコード体系に決まりがあるのかを、情報システムの担当者や保守を頼んでいる会社に先に確認しておくと、見積もりの前提が固まります。
この確認は受発注サービス側ではなく自社の既存システム側の話なので、商談を待たずに進められます。

既存の在庫・販売管理システムとの連携で確認すべきこと

確認すべき3つの質問

ここまでで、初回の登録は代行される例があること、CSVは受注データの出力として説明されていることが分かりました。
この二つを踏まえると、既存の在庫・販売管理システムとの連携で確かめるべきことは、商品情報を自動で吸い上げてくれるかという点よりも手前にあります。
自社が渡す情報の形と、受け取るデータの形を、どちらの向きについても決められるか、という点です。

一つ目は、初回登録を誰が、どの形式のデータから行うのかです。
代行してもらえる場合、こちらが渡すファイルは既存システムから書き出したもので足りるのか、指定の様式に詰め替える必要があるのかで、準備の手間がまるで変わります。
公開情報からは渡す形式の指定までは分かりませんでしたから、いま使っている販売管理システムから出せるファイルを一つ持参して、これで足りるかを見てもらうのが早道です。

二つ目は、CSVが指す向きと、その調整が標準機能か別料金かです。
受注データの出力については両社とも説明がありますが¹³、自社の取込仕様に合わせる作業の扱いは同じではなく、L-Pochiでは商習慣に合わせたカスタマイズが別料金と書かれています³。
見積書の項目名だけでは判断できないので、この形式で出してもらうには追加の費用がかかりますかと、自社の実物を見せて聞くのが確実です。

三つ目は、API連携の有無と、その費用です。
これは次の項で触れるとおり公開情報では確認できなかった点なので、はっきりした答えが返ってこない可能性も含めて聞くことになります。
この三つの質問には順番があって、一つ目の答え次第で二つ目の重みが変わります。
初回も日々の更新も依頼で回る体制なら取込用CSVの優先度は下がりますし、更新は自社でやると決めるなら、その手段が一件ずつの入力しかないのかを先に確かめておく必要があります。

API自動連携は未確認

APIとは、システム同士が決められた手順でデータをやりとりする仕組みを指します。
これが使えれば、基幹システムで商品を一件追加したときに受発注サービス側の一覧にも自動で反映させる、といった作り方ができます。
今回確認したTANOMUとL-Pochiの公開情報には、この自動同期についての記述は見当たりませんでした。
記述がないことは、できないという証明ではありません。
確認できていない、というだけです。

ここで区別しておきたいのは、データが取り出せることと、取り出しが自動で行われることは別だという点です。
注文内容をダウンロードできるという説明³は、誰かがその操作をすればファイルが得られるという意味であって、放っておいても基幹システムに入り続けるという意味ではありません。
インフォマートのプラットフォーム側には、指定した時間に連携ファイルを用意するタスク機能の説明がありますが²、これはTANOMUの商品マスタについて書かれたものではないため、そのまま当てはめて考えることはできません。

実務では、自動化の可否が決まる前でも進められる準備があります。
手で回す場合の手順を、担当者と時間まで決めておくことです。
毎日の何時に、誰が、どの画面から出力して、どこに置き、誰が基幹システムへ取り込むのか。
この段取りが書けていれば、後からAPIが使えると分かったときに置き換える対象がはっきりしますし、使えないと分かっても運用は止まりません。

逆に、自動連携が前提でなければ回らない計画は、導入前に見直す価値があります。
受注件数が多く、締め時間の直前に注文が集中する商いでは、出力と取り込みに人が張り付く時間が毎日発生します。
その時間を誰が担うのかを決めないまま稼働すると、LINEで注文を受けられるようになった分だけ、事務の手が別の場所で塞がることになります。

価格改定・新商品追加などの登録後の運用負担をどう見積もるか

確認できなかった運用負担

登録は一度で終わりません。
新商品が入り、規格が変わり、価格が改まるたびに、一覧は手を入れられていきます。
この更新にどれだけの頻度と手間がかかるのかは、今回確認した資料には書かれていませんでした。
初回登録の代行については明記があるのに¹³、その後の更新をどちらが担うのかは、公開情報からは判断できない部分です。

もっとも、この負担はサービス側の仕様だけで決まるものでもありません。
年に一度の改定で済む商いと、相場で単価が動く商いとでは、同じ機能でも重さがまったく違います。
季節ごとに取り扱いが入れ替わる商材を持っていれば、切り替えの時期に登録作業が集中します。
だからこそ、機能の説明を聞く前に、自社側の変動の大きさを数として持っておくと判断が速くなります。

難しい調べ方は要りません。
直近の一年で、新しく取り扱いを始めた商品が何件あったか、価格を変えた商品が何件あったかを、既存の台帳や価格表の履歴から拾い出すだけです。
それを月あたりに直せば、毎月どれくらいの更新が発生する商いなのかが見えます。
この数を持って商談に臨めば、更新はこちらで承りますという答えが自社にとって現実的かどうかを、その場で考えられます。

取引先ごとに単価が違う商いでは、その条件をどこで持つのかも決めどころになります。
商品の一覧に一つの価格を持たせるのか、取引先別の条件を別に持たせるのかで、改定のときに触る箇所の数が変わるからです。
この設計がサービスごとにどうなっているかは公開情報からは読み取れないため、デモの画面で、一社だけ単価を変える操作を実際に見せてもらうのが確実です。
資料の機能名ではなく、自社で一番よく起きる変更を目の前で再現してもらうと、運用の重さが具体的に分かります。

導入前にベンダーへ確認する項目

更新についてベンダーに確かめることは、大きく三つに整理できます。
更新の操作を自社の管理画面でできるのか、それとも都度の依頼になるのか。
依頼だとすれば、出してから画面に反映されるまでどれくらいかかるのか。
そして、その更新に追加の費用がかかるのかどうかです。

二つ目の反映までの時間は、軽く見られがちですが運用に直結します。
価格改定の案内を取引先に出す日と、画面の価格が変わる日がずれれば、旧価格のまま注文が入ります。
入ってしまえば、受注側で一件ずつ直すか、取引先に連絡して出し直してもらうかの手間が生まれます。
依頼型の運用になるなら、改定日の何日前までに出せば間に合うのかを先に聞いて、社内の価格決定の締め日をそこから逆算しておく必要があります。

三つ目の費用については、更新そのものの費用だけでなく、形式の調整に関わる費用も含めて聞いておくと抜けがありません。
基幹システム向けのCSVの調整が別料金として扱われる例がある以上³、標準でどこまで対応し、どこから個別の見積もりになるのかの線引きは、サービスごとに違うと考えたほうが自然です。
契約後にそれは別途ですと知る事態を避けるには、想定している運用を一度文章にして渡し、この運用は標準の範囲で回りますかと聞くのが早いやり方です。

最後に、ベンダーへの確認と同じくらい効くのが、社内の段取りです。
価格改定が決まったことを最初に知るのは営業で、登録を担うのは事務、という分かれ方をしている会社は多いはずです。
この間に決まった連絡の経路がないと、更新の遅れは仕組みの性能とは関係のないところで起きます。
改定が決まったら誰が登録担当へ伝えるか、価格表のどの版が最新かをどこで見るかを決めておけば、少なくとも聞いていなかったことによる取り違えと、その後の取引先への連絡と修正の往復は減らせます。

確認できた設計と、分からないまま残っている部分を分けておけば、商談の場で聞くべきことは自然に絞られます。

初回登録を代行してもらえるかどうかと、自社の商品情報がそのまま渡せる状態にあるかどうかは別の問題で、後者は実際の台帳を見ないと判断できません。

いまお使いの販売管理システムから書き出せるファイルをもとに、どの情報が足りないか、どこを整理すれば登録を任せられる状態になるかを一緒に確認できます。無料相談で要件を整理する

要点の整理

軸	基準
初回の商品登録	代行の有無と範囲、費用の扱いを見積もり時に確認する
CSVの向き	受注データの出力か、商品データの取込かを分けて質問する
出力形式の調整	標準機能か別料金かの線引きを、自社の実物を見せて確かめる
API自動連携	公開情報では未確認。可否と費用を個別に聞き、手運用の段取りも決めておく
登録後の更新	自社で操作できるか、反映までの時間、追加費用の有無を確認する
自社側の準備	商品情報の重複と空欄を整理し、年間の追加・改定件数を数えておく

稼働した後にどの転記が減り、どの確認が残るのかは、受注の流れと既存システムの形式によって変わるため、機能一覧だけでは見積もれません。 自社の受注の流れと基幹システムの取込形式を並べたうえで、日々の更新を誰がどの手順で担う想定になるのかを具体的に整理できます。

よくある質問

LINE受発注サービスを比較する際、商品マスタ登録の代行範囲は無料か有料か確認できますか

今回確認した公開情報では、TANOMU・L-Pochiとも初回の商品登録をベンダー側で対応する旨は明記されていますが¹³、それが初期費用に含まれるのか別料金なのかまでは読み取れませんでした。
そのため、資料を読み比べるだけでは費用の比較ができません。
商談では、代行の対象（商品だけか、得意先情報も含むか）、点数によって費用が変わるか、二回目以降のまとまった登録も同じ扱いかの三点をそろえて聞くと、各社の見積もりを同じ土俵で並べられます。

商品マスタの初回登録をベンダーに任せる場合、自社で用意すべきデータ形式はありますか

渡すファイルの形式については、今回確認した資料に指定の記載がありませんでした。
形式を先に想像して整えるより、いま使っている販売管理システムから書き出せるファイルをそのまま見せて、これで登録できるかを確認するほうが確実です。
そのうえで、商品名の表記ゆれ、価格表の版、掲載しない商品の扱いだけは自社で決めておくと、どの形式を求められても渡すまでの時間が短くなります。

既存の基幹システムへの出力用CSVと、商品マスタの取込用CSVは同じ機能と考えてよいですか

別の機能と考えてください。
確認できたTANOMU・L-Pochiの記述はいずれも、受注データを既存の基幹システムへ取り込むために書き出す向きのものです¹³。
商品情報を自社からまとめて登録・更新する向きについては、形式も件数の上限も記載が見当たりませんでした。
問い合わせの際は、出力できるデータの種類と、取り込めるデータの種類を分けて質問すると、回答の行き違いが避けられます。

取引先ごとに異なる単価条件がある場合、商品マスタ登録にどう反映されますか

この点について、今回確認した公開情報からは仕様を判断できませんでした。
商品の一覧に価格を持たせる作りか、取引先別の条件を別に持たせる作りかで、改定のときに触る箇所の数が変わります。
デモの機会があれば、一社だけ単価を変える操作と、その商品を複数の取引先に出している場合の見え方を、実際の画面で再現してもらうのが最も早い確認方法です。

API連携が明記されていないサービスの場合、将来的な自動連携化は可能ですか

明記がないことは、対応していないことの証明ではありません。
今回の資料では確認できなかった、というのが正確なところです。
可否を知るには、外部システムとつないだ実績があるか、追加開発として受けられるか、その場合の費用と期間はどうかを個別に聞く必要があります。
なお、インフォマートのプラットフォームには指定時間のファイル連携や外部サービスとの接続の説明がありますが²、TANOMUの商品マスタについての記述ではないため、そのまま当てはめて期待しないほうが安全です。

1. 1　出典：株式会社インフォマート「卸向け受発注TANOMU公式サイト」（2026年）
2. 2　出典：株式会社インフォマート「CSV連携（BtoBプラットフォーム機能ページ）」（2026年）
3. 3　出典：株式会社アドップ「LINE連携受発注システム L-Pochi 公式サイト」（2026年）