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

カタログPDFを商品データ化する4つのフェーズ

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

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

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

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

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

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

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

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

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

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

費用の目安

費用はカタログの点数・レイアウトの複雑さ・拾いたい項目数によって変わりますが、市場の一般的な目安として、awaiがご案内している水準は次のとおりです（相場感の参考としてご覧ください）。

• 初期診断・設計：20〜30万円（カタログの現状把握・構造化範囲の設計・ROI試算）
• 実装：50〜200万円（カタログの点数・複雑度による）
• 保守・運用：5〜15万円／月（シーズン更新時の再構造化・調整）

awaiでは、この初期診断そのものを入口としてご提供しています。有償の診断で「どのカタログを、どこまで、いくらで構造化できるか」を先に見える化し、その後に実装をご発注いただいた場合は診断費を全額実装費に充当します。「診断だけで終わってもレポートは残り、進めれば診断費は実質無料になる」形なので、いきなり大きな開発費をかける前に、費用対効果を確かめてから判断していただけます。

なお、構造化した商品データはそのままawaiのShopifyサイト構築における商品マスタとしても活用できるため、「カタログのデータ化」と「ECサイトへの反映」を一気通貫で依頼することも可能です。また、構造化の考え方や外注時の一般的な費用感については、非構造化データの構造化でも整理していますので、カタログ以外の文書・レビューデータも含めて検討したい方はあわせてご覧ください。

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

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

awaiは、OCRとLLMを組み合わせたカタログの読み取り・構造化から、商品データとしての出力、更新運用まで一気通貫で対応します。ECサイト（Shopify）の構築・改修と同じ体制で行っているため、「データ化して終わり」ではなく、その先の販売・業務での活用まで見据えた設計が可能です。「うちのカタログ、データ化できる？」と感じたら、まずは現状をお聞かせください。

※本記事の費用は市場の一般的な目安であり、カタログの点数・レイアウト・拾いたい項目数によって変動します。正確なお見積りは診断にて算出します。