先に、要点をまとめます。
- 卸売業の商品登録で手作業が残る原因は、入力の量、説明文の書き手ごとの差、タグの基準がないことの3つが重なる点にあります。 AIで説明文を作るだけでは、3つのうち1つにしか届きません。
- 当社が開発した商品登録システムは、商品データの一括取り込みと商品マスタへの自動登録を土台にし、AIが作るタグと説明文は担当者が確認してから反映する設計です。 AIの出力を公開前の草稿として扱う点が、この事例の中心です。
- ECサイトやSaaSに付いている説明文の生成機能で足りる会社もあります。 仕入先ごとに形式が違うデータの取り込み、自社の分類基準、確認の担当と権限まで扱いたい場合に、個別開発を比べる意味が出てきます。
当社の卸売業向け商品登録システムでは、取り込んだ商品情報をもとにAIがタグ・説明文の草稿を作り、担当者が編集・確認する流れを構築しました。この記事では公開済みの実装内容と、同種業務で検討したい確認項目を分けて紹介します。
2026年10月13日時点の情報です。既製サービスの機能は、各社の公開情報で確認できた範囲で記載しています。
卸売業の商品登録は、なぜ手作業のまま残りやすいのですか?
商品点数に対して入力の手が足りず、説明文とタグの基準も担当者に任されているため、登録の遅れと内容のばらつきが同時に起きるからです。
この事例の発注元では、仕入れた商品を担当者が1件ずつ登録し、説明文も個別に書き起こしていました。書き手によって説明の粒度や表現が変わり、記載の薄い商品がそのまま残る状況が生じていました。
タグ付けにも明確な基準がなく、同じ種類の商品が別々の分類に入ることがありました。分類がずれると、社内で商品を探すときに目的の商品へたどり着けません。商品点数が増える見通しのなかで、手作業を前提にした運用では登録が追いつかないと判断されていました。
この3つは原因が違います。入力の量は取り込みと自動登録で、説明文の差は草稿と確認の手順で、タグの差は分類のルールで対処します。自社でいちばん困っているのがどれかを先に分けると、作る範囲を小さくできます。
公開できる実装内容
商品登録システムの実績ページでは、Next.jsとSupabaseを使った管理画面、商品情報の取り込み、AIによるタグ付けと説明文生成、人による編集・確認を紹介しています。
自社の業務と、今回の開発範囲を比べる商品登録のどこを自動化し、どこに人の判断を残したのか。実績ページで実装内容と構成を確認できます。自社で変えたい業務が決まっている方は、そのままご相談ください。商品登録システムの実装内容を見る →実装した機能は次のとおりです。
| 機能 | 内容 |
|---|---|
| 商品データの一括取り込み | 商品名・型番・価格・仕入先などを含むデータをまとめて登録する |
| 商品マスタへの自動登録 | 取り込んだデータを整形し、商品マスタへ登録する |
| AIによるタグ付け | 商品情報をもとにカテゴリ・特徴のタグを付け、検索と分類に使える形で保存する |
| AIによる説明文の草稿 | 商品情報から説明文の草稿を作り、管理画面で編集・確定できるようにする |
| 確認・修正の流れ | AIの出力をそのまま確定させず、担当者が確認・修正してから反映する |
| 検索・絞り込み | 商品名・タグ・仕入先などで商品を絞り込む |
| 権限管理 | 担当者ごとに操作できる範囲を分ける |
体制は1名のフルスタック開発で、実装期間は1〜3ヶ月でした。構成はシンプルな2層構成にし、運用の負荷を抑えて、現場で扱いやすい操作性を優先しました。
この事例の対象は商品登録業務です。配送計画、倉庫在庫の引当、WMSの置き換えまでを実装した事例ではありません。作業時間や売上への改善率は測定値として提示していません。
処理の流れと人の判断が残る場所
| 段階 | システムで扱うこと | 担当者が確認すること |
|---|---|---|
| 取り込み | 元の商品情報を登録用に扱う | 元情報の不足・誤記 |
| 草稿 | AIでタグ・説明文を作成する | 内容が元情報に基づいているか |
| 編集 | 画面で草稿を修正する | 表記・分類・商品固有の注意点 |
| 確認 | 登録内容を担当者が確認する | 公開してよい説明になっているか |
卸売の商品登録でAIを使う流れ。取り込み、草稿、編集、確認・反映の4段階のそれぞれで、システムが行うことと担当者が確認することを並べ、元資料の差し替えや再取り込みのときは確認済みの説明を見直す対象に戻すことを示した図
AIによる草稿があることは、確認作業が不要になることを意味しません。原資料にない性能や材質を補っていないかを見る必要があります。
確認の段階を設計するときは、誰が、どの画面で、何を見て確定するかを決めます。確認の担当が決まらないまま草稿だけが増えると、未確認の商品が溜まり、手作業で書いていた頃と同じ遅れが別の場所で起きます。
AIの草稿をそのまま公開しないのはなぜですか?
AIは元資料にない仕様や特徴を文章として補うことがあり、誤った説明が取引先や販売先へそのまま渡るからです。確認の手順を先に決めておくと、草稿を使う範囲を安心して広げられます。
商品説明文の誤りには、いくつかの型があります。
- 元資料にない情報の追加:材質、対応サイズ、用途など、仕入先のデータに書かれていない内容を、それらしい文章で埋めてしまう。
- 似た商品との混同:色違いやサイズ違いの商品で、別のSKUの特徴が説明に混ざる。
- 表記の不統一:単位や型番の書き方が、既存の商品マスタの決まりと揃わない。
- 公開してはいけない情報:仕入価格や仕入先名のように、社内の項目が説明文に入り込む。
この事例では、AIの出力を「編集できる草稿」として管理画面に表示し、担当者が確認・修正して確定してから反映する設計にしました。タグも同じで、AIが付けた分類を担当者が確認してから検索に使える状態にします。
確認を残すことで、AIの出力の誤りを公開前に止められるだけでなく、担当者が直した内容から分類ルールや入力元の不足が見えてきます。直しが多い項目は、次に入力元のデータを整える対象になります。
ECやSaaSの説明文生成機能と、個別開発はどう選びますか?
ECサイトの管理画面だけで商品を登録していて、説明文の下書きが欲しいだけなら、既製サービスの生成機能から試すのが手軽です。仕入先ごとのデータ形式、自社の分類基準、確認の担当と権限まで扱う必要があるときに、個別開発を比べます。
既製サービスにも説明文の生成機能はあります。たとえばECサイト構築サービスの「makeshop byGMO」は、2023年7月13日に、商品名とキーワードを入力すると400字程度の説明文を生成し、編集して使える機能を追加しています(Web担当者Forumの報道)。機能の現在の仕様と料金は、各サービスの公式情報で確認してください。
| 比べる観点 | ECやSaaSの生成機能 | 取り込みは既存のまま、整形だけを補う | 商品マスタに組み込む個別開発 |
|---|---|---|---|
| 向いている状況 | ECの管理画面で1件ずつ登録している | 仕入先データの整形に時間がかかっている | 複数の販路や社内検索で同じ商品マスタを使う |
| 入力の起点 | 商品名・キーワードを担当者が入れる | 仕入先のCSVやExcel | 仕入先データの一括取り込み |
| 分類・タグ | サービスの項目に合わせる | 整形ルールに合わせる | 自社の分類基準で付けて保存する |
| 確認の担当と権限 | サービスの権限設定の範囲 | 運用ルールで分ける | 確定できる担当を画面と権限で分ける |
| 費用の考え方 | 利用料・プランの範囲 | 整形の仕組みの開発・設定 | 要件定義からの開発と保守 |
判断に迷うときは、いま登録に使っている元データを1件取り出し、どの段階で人が手を入れているかを書き出します。手を入れている箇所がECの管理画面の中だけなら既製機能で足ります。仕入先データの整形や、社内の在庫・受発注システムとの突き合わせに手間がかかっているなら、商品マスタ側の設計から見直す対象です。
受発注や在庫管理まで含めて既製品の限界を感じている場合は、物流・卸売の在庫管理の選び方で、WMS・既製品・個別開発の比べ方を整理しています。
同種業務を検討するための受入例
以下は当該案件の試験結果ではなく、自社で検討する際の説明用サンプルです。自社の商品カテゴリに置き換えて確認してください。
- 材質が空欄の商品:材質を推測して埋めず、確認が必要だと分かること。
- 色違いの商品:親商品の説明を流用しても、対象SKUの色と混同しないこと。
- 既存商品を再取り込み:新規登録と更新を区別し、担当者の修正文をどう扱うか合意すること。
- 元資料を差し替え:どの説明を再確認するか分かること。
このような条件を先に用意すると、「自然な文章か」だけで評価を終わらせずに済みます。
AIの回答や生成物をどう評価するかは、正しい出力、出力してはいけない内容、判断を人に戻す条件に分けて決めると整理しやすくなります。評価表の作り方はAI導入前の品質チェックで扱っています。
効果の測定を始めるなら
商品カテゴリを揃えて、草稿なしと草稿ありの作業を比較します。入力時間だけでなく、確認・修正時間、差し戻し理由、登録後に発見した誤りも記録します。結果が出る前に削減率を提示せず、対象商品の範囲と確認者の条件を残してください。
記録する項目の例は次のとおりです。
| 記録する項目 | 記録の仕方 |
|---|---|
| 1件あたりの作業時間 | 入力・確認・修正を分けて記録する |
| 差し戻しの理由 | 元資料の不足、AIの誤り、表記の不統一などに分ける |
| 登録後に見つかった誤り | 発見した日と、どの段階で止められたはずかを残す |
| 対象の条件 | 商品カテゴリ、件数、確認した担当者 |
導入範囲の決め方
商品登録の問題が、情報不足なのか、転記なのか、文章作成なのかを分けます。情報不足が原因なら、入力元の整理が先です。定型文と分類ルールで足りる部分にはAIを使わない案も比較できます。
範囲は、次の順に決めると絞りやすくなります。
- いまの登録手順を書き出す:誰が、どのデータを見て、どの画面に何を入力しているかを並べます。
- 時間がかかっている段階を1つ選ぶ:取り込み、説明文、タグ付けのうち、最も手間がかかっている段階から始めます。
- 確認の担当を決める:AIの草稿を確定できる人と、確定前に見る項目を決めます。
- 一部のカテゴリで試す:商品カテゴリを1つに絞って運用し、上の記録項目で確認の負担を見ます。
- 対象を広げる:試した結果をもとに、カテゴリやタグの種類を広げます。
最初から全商品・全工程を対象にすると、要件の確認だけで時間がかかります。この事例も、商品登録という一つの業務に範囲を絞って作っています。
開発を依頼する前に、何を用意すればよいですか?
登録に使っている元データのサンプル、いまの分類のルール、確認を担当する人の3つがあれば、相談を始められます。決まっていない項目は、未確定として残したままで構いません。
- 元データのサンプル:仕入先から届くCSVやExcelを数件分。社外秘の値は伏せて構いません。
- 分類のルール:いま使っているカテゴリの一覧と、迷いやすい商品の例。
- 確認の担当:説明文とタグを確定する人、その人が見ている項目。
- つなぐ先:登録した商品情報を使うECサイト、社内の在庫・受発注システム。
当社の見積もりは、作業単価1時間11,000円(税込)を基準に、要件定義・契約後のすり合わせ・開発・テスト・バッファの時間を積み上げます。物流・卸売のシステムで範囲をどう切るかは物流システム開発の費用と期間で整理しています。業務へのAIの組み込みを依頼先として検討している場合は、AIを本番の業務に組み込む開発の相談で進め方を確認できます。
よくある質問
Q. AIが作った説明文はそのまま公開しますか?
この公開事例では人が編集・確認する流れです。自社への導入でも、商品情報の正確性と公開判断を誰が確認するか決めます。
Q. 削減時間はどのくらいですか?
この記事で提示できる測定値はありません。対象商品の条件を揃え、入力・確認・修正を含む時間で評価する方法を示しています。
Q. 既存の受発注システムやECサイトの商品データを取り込めますか?
取り込み元のデータの出力形式に合わせて、取り込みの処理を設計します。全体を作り直す前提ではなく、商品登録の部分だけを新しく作り、受発注や在庫管理は既存の仕組みのまま連携する進め方も比べられます。出力できる項目と形式を、要件定義で確認します。
自社の状況を整理して相談する
まず、商品情報の入力元、草稿で困る項目、公開前の確認担当を書き出してください。この記事に合う検討シートとAI相談用プロンプトで、未確認の項目を残したまま整理できます。シートを完成させる前でも、お気軽にご相談いただけます。
運営・編集