紙・PDFカタログを商品データ化するには｜AI活用と費用の目安

長年紙のカタログや注文書で商流を回してきた会社ほど、実は「商品データそのもの」を持っていないという状態に陥りがちです。商品名・型番・価格・規格・産地といった情報は、印刷されたカタログやPDFの中には確かに存在しています。ところがそれは、人が目で読んで初めて意味が分かる形——ExcelやDB（データベース）のように、システムが直接扱える形にはなっていません。

この状態で「ECサイトを立ち上げたい」「取引先向けのWeb発注画面を作りたい」「AIチャットボットに商品案内をさせたい」といった話が持ち上がると、決まって最初の壁になるのが商品データの整備です。カタログが1シリーズ数十点程度ならまだしも、数百〜数千点規模になると、担当者が手作業で入力し直すだけで数週間〜数ヶ月かかることも珍しくありません。しかも、カタログは季節ごと・年度ごとに更新されるため、一度作って終わりにもできません。

この記事では、紙やPDFのカタログをAIで商品データ化するとはどういうことか、どう進めるのか、費用はどれくらいかかるのかを、専門用語をかみ砕きながら整理します。

なぜ「紙・PDFカタログ」はそのままではAIやシステムに使えないのか

紙やPDFのカタログには、実は2つの壁があります。壁の1つ目は、文字自体が「データ」になっていないことです。スキャンした紙カタログや、デザイン重視で作られたPDFカタログの多くは、画像として文字が埋め込まれているだけで、コンピュータが文字として読み取れない状態になっていることがあります。この場合、まずOCR（Optical Character Recognition＝画像の中の文字を読み取り、テキストデータに変換する技術）で文字情報を取り出す工程が必要です。

壁の2つ目は、文字は読み取れても「意味の構造」がバラバラなことです。仮に文字自体はテキストとして取得できても、「この数字は価格なのか、型番なのか、内容量なのか」をシステムは自動では判断できません。カタログのレイアウトは商品ごと・ページごとに微妙に異なり、表組みの崩れ、改行位置の違い、略称や社内用語の混在などがあるため、単純なルールベースの処理（決まった位置・決まった書式だけを機械的に拾う処理）では抜け漏れが多発します。

ここで効いてくるのがLLM（大規模言語モデル＝文章を人のように理解して処理できる生成AIの中核技術）です。LLMは「このページの商品名はどれで、価格はどれで、規格はどれか」を、人間が読むのと近い形で文脈から判断できます。OCRで文字を取り出し、LLMで意味を構造化する——この2段階の組み合わせによって、初めて「バラバラなレイアウトのカタログ」を「システムが扱える商品データ」に変換できるようになります。

• カタログの見た目（レイアウト・書体・写真配置）は毎回違っても、LLMは「商品名・価格・規格・産地」といった意味の軸で情報を拾い直せる
• 表形式が崩れているページ、注釈や但し書きが混在しているページでも、文脈から「本体価格なのか、送料込みなのか」を判断しやすい
• 一度仕組みを作れば、次のシーズンのカタログ更新時にも同じ流れで再利用できる（毎回ゼロから手入力しなくてよい）

着手前に決める「出力する項目」の設計

データ化で最も後戻りが多いのは、項目の決め方です。読み取ってから決めようとすると、全点をやり直すことになります。最低限、次の3つを先に決めます。

• 項目名と型を固定する：商品名・型番・入数・価格・規格・産地・原材料など、使う項目を一覧にし、それぞれ文字か数値かを決めます。「規格」「サイズ」「容量」のような重複した呼び方は1つに統一します。
• 1商品1行にするための主キーを決める：型番かJANか自社品番か。色・サイズ違いを別行にするのか、1行の中に列で持つのかも決めておきます。ここが曖昧だと、あとでECにも基幹にも取り込めません。
• 価格の定義を明示する：税抜か税込か、送料込みか、掛率のある卸価格なのか。カタログには複数の価格が併記されていることが多く、どれを取るかを決めずに読み取ると混在します。

この3点をA4で1枚にまとめてから読み取りに入ると、PoCで見るべきものが「精度」だけに絞られ、判断が速くなります。

紙・PDFカタログの商品データ化は、いきなり全点を一括処理するのではなく、段階を踏んで進めるのが実務的です。

①現状の把握では、対象カタログが何点あり、拾うべき項目は何か（商品名・型番・価格・規格・産地・原材料など業種によって異なる）を洗い出し、どこまでを構造化の対象にするかを決めます。ここで「本当に効果が出る範囲」を見極めることが、後工程の手戻りを減らす最大のポイントです。

②PoC（Proof of Concept＝小さく試して効果と実現性を確かめる工程）では、いきなり全点に着手せず、まず1シリーズ・1カテゴリ分だけをOCR＋LLMで構造化してみます。実際のカタログで試すことで、「このレイアウトなら精度が出るが、この表組みは抜け漏れが出やすい」といった実務上の癖が見えてきます。ここで精度を確認してから本格展開に進むほうが、結果的に手戻りが少なく済みます。

③実装では、PoCで見えた課題（表組みの崩れ対応、略称の辞書化など）を踏まえて処理の範囲をカタログ全体に広げ、構造化した商品データをExcelやDB、ECサイトの商品マスタへ取り込める形式で出力できるようにします。

④運用は、カタログの更新は一度きりで終わらないという前提に立った工程です。新シーズンのカタログが出るたびに同じ仕組みで再構造化できる状態を保守し、レイアウトが変わった場合の調整にも対応します。

陥りやすい失敗パターン3つ

カタログの商品データ化を検討する際、よくつまずくポイントを3つ挙げます。

①「全点いきなり自動化」を狙って精度検証を飛ばす——数千点あるカタログを一気に処理しようとすると、レイアウトのばらつきによる抜け漏れに後から気づき、手作業での修正コストがかさみます。まず一部で精度を確認してから範囲を広げるほうが、結果的に速く安く済みます。

②表記ゆれ・項目定義の統一を後回しにする——「規格」という項目一つとっても、カタログによって「サイズ」「型番」「容量」など呼び方が混在していることがあります。構造化の前に「どの項目名で統一するか」を決めておかないと、後からデータを結合・検索する段階で不整合が発生します。

③更新運用の仕組みを作らずに終わる——初回の構造化だけで満足してしまい、次シーズンのカタログ更新時にまた手作業に戻ってしまうケースがあります。継続的に使えるデータにするには、更新のたびに再構造化できる運用体制まで見据えて設計する必要があります。

精度はどこまで出るのか｜目視確認を前提に設計する

「AIで全自動」を期待して着手すると、必ず落差を感じます。実務では、次の前提で設計するほうが結果的に速く進みます。

• レイアウトが揃ったページは高い精度が出る一方、注釈・但し書き・複数価格が混在するページは取り違えが残ります。全点で同じ精度にはなりません。
• 重要な項目ほど検算の仕組みを入れます。価格と型番は、ページ画像と並べて目視確認できる一覧を出力しておくと、確認が数分の作業で済みます。
• 「読み取れなかった」ことが分かる状態にします。空欄なのか読み取り失敗なのかが区別できないデータは、後工程で必ず事故になります。
• 精度の合格ラインを事前に決めます。たとえば「価格・型番は100%目視確認、それ以外は9割の自動精度で可」といった具合に、項目ごとに基準を変えるのが現実的です。

費用の目安

費用はカタログの点数・レイアウトの複雑さ・拾いたい項目数で決まります。以下は市場の一般的な目安であり、特定サービスの確定価格ではありません。

判断の分かれ目は「何回やるか」です。1回きりなら手入力や入力代行が最も安く済みます。毎シーズン更新があるなら、初回に仕組みを作るほうが2〜3回目で逆転します。自社がどちらかは、カタログの更新頻度と点数を掛け合わせれば計算できます。

構造化した商品データは、そのままECの商品マスタになり、サイト内検索の精度改善（ECサイトの商品検索をAIで改善する）や商品説明文の生成（商品説明文をAIで自動生成・効率化するには）にも使えます。複数のカタログや取引先から取り込む場合に起きる型番の表記ゆれ・重複の整理はEC商品マスタの名寄せ方法｜表記ゆれ・重複をAIで統合する手順で扱っています。

紙カタログを、更新のたびに人力で打ち直さなくていい状態へ

「カタログはあるのに、システムで使える商品データがない」という状態は、業歴の長い会社ほど陥りやすいねじれです。しかも一度作って終わりではなく、シーズンごとの更新のたびに同じ苦労を繰り返すことになりがちです。

着手は、①出力する項目をA4で1枚に決める、②1シリーズだけ読み取って精度を見る、③更新頻度と点数から手入力・既製ツール・仕組み化のどれが安いかを計算する、の順です。②までは大きな費用をかけずに実行でき、そこで出た精度が、外注するかどうかの判断材料そのものになります。