「同じ商品なのに、システムの中では別物として何件も登録されている」——データを扱う現場で、これは驚くほどよく起きます。通販サイトから集めた商品名、名刺から起こした会社名、複数のツールに散らばった顧客情報。どれも人が見れば同じものだと分かるのに、コンピューターにとっては「違う文字列」でしかありません。
この「同じものを、同じと分かる形にそろえる」作業を、データ正規化と呼びます。地味ですが、検索・集計・レコメンドといったあらゆる活用の土台になる工程です。
これまで正規化は、決まった手順を書ける範囲までは機械（プログラム）で自動化できても、その先——「表記は違うが同じ中身か」「この変わった名前は誤記か実在名か」といった、意味を読まないと判断できない部分は、人が手で片づけるしかありませんでした。データが大量なら、そこは実質「正規化できない」領域だったのです。この最後の壁を、いまはAIで越えられます。本記事では、AIに丸投げするのでも全部手作業でやるのでもない、ルールとAIの役割分担による正規化の設計を、当社が自社の日本酒サービスで実際に行った事例をもとに、指示の出し方・精度・コストの数字を交えて具体的に解説します。
そのデータ、「同じ商品」がいくつにも分かれていませんか
正規化が必要になるのは、集めたデータが「販売や物流の都合で飾り付けられている」からです。
たとえば通販サイトの日本酒の商品名は、実際にはこう並んでいます。
久保田 くぼた 萬寿 純米大吟醸 1800ml 送料無料（クール便・本州以外は別途…
ギフト プレゼント 日本酒 久保田 純米大吟醸 萬寿 720ml 化粧箱入り 新
久保田 萬寿 純米大吟醸 720ml人が見れば、3つとも「久保田 萬寿」という同じお酒だと分かります。違うのは容量（720ml と 1800ml）と、店ごとの売り文句だけです。ところがコンピューターは、文字が違えば別物として扱うため、このままでは同じ商品が3件に分裂してしまいます。逆に「久保田 酒粕」や「久保田の焼酎」のように、名前は似ていても中身が別物（日本酒ではない）のものを、うっかり同じ仲間に入れてしまう事故も起きます。
正規化とは、「余計な飾りを外して、中身で見分けられる形に戻す」作業です。
集めたデータをそのまま使うと、検索してもヒットせず、集計しても数が合わず、おすすめ機能も的外れになります。だからこそ、活用の前に一度「そろえる」必要があるのです。
AIに丸投げでも、全部手作業でもうまくいかない
正規化を設計するときの出発点は、「何を機械に任せ、何をAIに任せるか」をはっきり分けることです。
正規化には、性質の違う2種類の作業が混ざっています。ひとつは、決まった手順で必ず同じ答えが出せる作業です。「送料無料」という語を消す、全角と半角をそろえる、容量の数字を取り除く——これらは、やり方さえ決めれば機械（プログラムのルール）が確実にこなせます。もうひとつは、意味を読まないと判断できない作業です。「この2つの商品名は、表記が違うだけで同じ中身か」「この変わった名前は、入力ミスの残骸か、それとも実在する商品名か」。こうした判断は、文脈を理解できるAIの得意分野です。
ここで肝心なのは、機械で判定できることをAIに聞かないことです。決まった処理までAIに任せると、遅くなり、費用（AIに読ませる文字量）がかさみ、しかも毎回わずかに違う答えが返る（再現性が落ちる）という、三重の損をします。逆に、意味の判断が必要なところをルールだけで押し切ろうとすると、例外を一つずつ手で潰し続ける終わりのない作業になります。
機械で消せるノイズを、AIに聞かない。AIには、意味を読まないと分からないことだけを任せる。
この記事の後半で紹介する自社事例では、ルール（機械処理）だけで消せたノイズは全体のごく一部にとどまり、その先はAIでなければ整えられませんでした。役割を分けることは、きれいごとではなく、コストと精度の両面から避けられない設計判断なのです。
品質ゲートという考え方 ― 3つの層で守る
正規化を安定させる設計は、「ルールで整える」「AIが判断する」「通過を強制する」という3つの層に分けると、見通しがよくなります。
機械で判定できるものは決まった検査で先に弾き、意味を読まないと分からないものだけをAIの判断に回し、「チェックを通したかどうか」自体は仕組みで担保する。この型は商品データに限らず、品質を守りたいあらゆる場面に共通する骨格です。
以降で、この3つの層を順に見ていきます。
第1層：機械で消せるものは、ルールで消す
最初の層では、決まった手順で確実に消せる飾りを、プログラムのルールで機械的に取り除きます。
やることは大きく2つです。ひとつは表記の統一。全角・半角、大文字・小文字、似た記号などを一つの形にそろえます。もうひとつは、飾りの除去。「送料無料」「ギフト」「化粧箱入り」「1800ml」「令和6年」といった、商品の中身を見分けるのに関係のない語を、あらかじめ用意した一覧（消す語のリスト）に従って削っていきます。
ここで先に決めておくべき、最も大事なことがあります。「どこまでを同じ商品として1つにまとめるか」という単位です。私たちの日本酒サービスでは、この単位を「銘柄 × 種類（純米大吟醸などの区分）× 識別できる特徴（使用米やシリーズ名）」と定めました。そして容量（720ml か 1800ml か）は、この単位に含めないと決めています。容量違いは同じお酒の「サイズ違い」であって、別の商品ではないからです。この線引きを最初に固定しておかないと、後の工程がすべてぶれます。
まとめる単位を先に決める。これが決まっていないと、機械もAIも判断できません。
冒頭に挙げた久保田の3件を、この第1層に通すとどうなるか。飾りと容量を外すと、3つとも「久保田 萬寿（純米大吟醸）」という同じ中身に行き着きます。あとは、これを1つの商品としてまとめ、720ml と 1800ml は「その商品のサイズ違い」として脇に持たせるだけです。人が見れば当たり前のこの整理を、機械が迷わず実行できる形にするのが第1層の役割です。
ただし、この機械的なルールには、はっきりとした限界があります。店ごとに付ける飾り文句は無限に増えるため、消す語のリストは永遠に追いつきません。また、商品名によっては、消したい飾りと、残したい商品名の一部が、文字として見分けられないこともあります。実際、当社の事例でルールだけで消せたノイズは全体のわずか1〜2%程度でした。ここから先は、機械では歯が立たないのです。
第2層：意味の判断は、AIに任せる ― 指示の出し方が肝
第2層では、ルールでは消せなかった「意味を読まないと分からないもの」を、AIに判断させます。
このときの成否を分けるのが、AIへの指示の出し方です。私たちが実践した工夫を、3つに絞って紹介します。
まず、まとめて渡すこと。商品を1件ずつバラバラにAIへ見せるのではなく、同じ銘柄の商品を全部ひとまとめにして渡します。すると「この銘柄には、こういう名前のラインナップがある」という文脈がAIに伝わり、「これは表記違いの重複だ」「これは別の商品だ」という判断の精度が、1件ずつ見せるより大きく上がります。
次に、実在するものを列挙して守ること。日本酒には、一見すると入力ミスに見える不思議な商品名が実在します。同じ銘柄の中に、記号や英字の入り混じった変わったライン名が並ぶことも珍しくありません。そういった名前を「これは実在するので消してはいけない」とあらかじめ具体的に伝えておかないと、AIは「変な名前だから残骸だろう」と早合点して、実在する商品を消してしまいます。迷ったら消さずに残す、という保守的な姿勢を徹底させることが、事故を防ぐ鍵でした。実際に私たちがつまずいたのは、果実を思わせる名前の純米酒をAIが「果実酒」と誤認しかけた場面です。銘柄ごとの実在ラインナップを渡していたことで、この取りこぼしに気づけました。
そして、判断の形式を決めること。AIには自由に文章で答えさせるのではなく、「この商品は、残す・名前を直す・別の商品と統合する・除外する、のどれか」と、選択肢を決めた形で答えさせます。加えて「なぜそう判断したか」の理由も一言添えさせます。答えの形をそろえておくと、後の工程で機械的に扱え、人が確認するときも見落としが減ります。
AIへの指示は、「迷ったら残す」「実在するものは名指しで守る」「答えの形を決める」。この3つで、精度が安定します。
抽象的な「うまくやって」では、AIは的外れな判断をします。何を守り、何を選ばせ、迷ったらどちらに倒すか——判断の分かれ道を具体的に指示することが、意味の判断をAIに任せるうえでの土台になります。
数字で見る ― AIは強力、でも「1回」では信用しない
役割を分けてAIに意味の判断を任せると、機械だけの正規化を大きく超える成果が出ます。ただし、AIの判断を1回で信用してはいけません。
当社の事例では、機械のルールで消せたノイズがごく一部（1〜2%程度）だったのに対し、AIを組み合わせることで、整えられたデータの割合はおよそ半分以上まで跳ね上がりました。ルールの延長では決してたどり着けない水準です。まず小さく試した検証では、約8つの銘柄・200件あまりの商品に対して、実在する商品を誤って消したケースはゼロに抑えられました。「迷ったら残す」という指示が効いた結果です。
一方で、全体（約1万件規模の商品データ）へ広げたとき、見過ごせない事実が分かりました。AIの1回きりの判断は、「削除」と「自信のない統合」において、およそ15%が間違っていたのです。実在する日本酒を「これは果実酒だ」と誤認して消そうとしたり、本来は別物である「甘口版」と「通常版」を同じ商品としてまとめようとしたり——もっともらしいけれど間違っている判断が、一定の割合で必ず混ざります。
単独のAIによる「削除」「自信のない統合」は、私たちの実測で約15%が誤り。ここを素通しにはできません。
そこで欠かせないのが、次の一手です。削除や自信のない統合の候補だけを、わざと疑ってかかる二度目のAIチェックに通します。一度目とは別の視点で「本当に消してよいか」「本当に同じ商品か」を問い直させると、先ほどの誤りの多くを取り戻せます。実際、この二度目のチェックが、消されかけた実在商品と、まとめられかけた別商品を救い出しました。AIは強力な道具ですが、重い判断ほど「一度で信じない」設計が要るのです。
AIにかかる費用の設計 ― 全部渡さない、まとめて渡す
AIを業務で使うとき、見落とせないのが費用です。AIは読み書きした文字量（トークン）に応じて課金され、量が増えるほど遅くもなります。正規化のように大量のデータを扱う作業では、この設計が実用性を左右します。
私たちが徹底したのは、「AIに全部を渡さない」ことです。たとえば表形式のデータを扱うとき、中身をまるごと渡すのではなく、先頭の数件と、各項目がどんな型か（数値か、日付か、文章か）という「要約」だけを渡します。AIが判断するのに必要なのは全体の雰囲気であって、一行残らず読ませる必要はありません。同じ発想で、処理の途中でエラーが出たときも、長いエラー全文ではなく要点の数行だけを返すようにします。
一方で、精度を上げるためには「まとめて渡す」ことも必要でした。前の章で触れたとおり、同じ銘柄の商品はひとまとめにして文脈ごと見せます。「減らす」と「まとめる」は矛盾しません。無駄な情報は削り、判断に効く文脈は束ねて渡す——このメリハリが、コストと精度を同時に満たす鍵です。
参考までに規模感をお伝えすると、約1万件の商品データ全体を、多数のAIに分担させて点検し切るのに、数百万トークン規模・時間にして20分あまりで完了しました。渡し方を設計しておけば、これだけの量でも現実的なコストと時間で回せます。逆に、何も考えずに全データを渡していたら、費用も時間も何倍にも膨らんでいたはずです。
第3層：「通したか」を仕組みで強制し、必ず戻せるようにする
最後の層では、「正規化を正しく通したデータだけが本番に反映される」ことを、人の心がけではなく仕組みで担保します。
いくら良い正規化を設計しても、「うっかり未処理のデータを本番に入れてしまう」ことが起きれば台無しです。そこで、確定した正規化を反映する処理は、決まった手順どおりに動き、何度実行しても同じ結果になるように作ります。そして、AIの判断は確信度で扱いを変えます。確信度が高いもの（あるいは複数の判断が一致したもの）は自動で反映してよい。中くらいのものは、人が最終確認する列に回す。重い判断は人の目を通す、という線引きです。
もうひとつ絶対に外せないのが、すべての操作を「あとで元に戻せる形」にしておくことです。統合したデータは、元がどれだったかを退避してから統合する。除外したデータは、完全に消すのではなく「非表示」の印を付けるだけにする。名前を直すときは、旧い名前を控えてから直す。こうしておけば、後から「この統合は間違いだった」と分かっても、安全に巻き戻せます。とりわけ、お客様が書いてくれたレビューのような大切なデータは、正規化の巻き添えで消えることが絶対にあってはなりません。私たちの事例でも、商品データを大きく整理しながら、レビューは一件も失わずに保全しました。
反映は仕組みで強制し、操作はすべて元に戻せるように。この2つが、安心して正規化を回し続ける土台です。
そして、この層にはもうひとつ役割があります。AIレビューで見つかった「新しいノイズのパターン」を、第1層のルールに書き足していくことです。今回は意味の判断が必要だったものも、パターンとして分かれば、次回からは機械のルールで先に消せます。使うほど第1層が賢くなり、AIに回す量が減っていく。品質を守る仕組みが、自分で育っていくのです。
まとめ ― 正規化は「丸投げ」でも「全部手作業」でもない
データ正規化は、AIに任せれば一発で片づく魔法でも、人が延々と手作業で潰す苦行でもありません。要は、役割分担の設計です。
本記事の要点は、シンプルです。決まった手順で消せるものは、機械のルールで消す。意味を読まないと分からないものだけを、AIに任せる。そのAIにも「迷ったら残す」「実在は名指しで守る」「答えの形を決める」と具体的に指示し、重い判断は二度目のチェックと人の確認で守る。渡す情報は、無駄を削り文脈を束ねてコストを抑える。そして、正しく通したデータだけが反映され、いつでも元に戻せる仕組みで全体を支える。
この型は、日本酒の商品データに限らず、会社名や顧客情報の台帳（マスタ）の整備など、「同じものを、同じと分かる形にそろえたい」あらゆる場面に応用できます。私たちは、AI導入を「試しに動かしてみる」で終わらせず、こうした継続運用と品質担保の仕組みまでを設計の対象にしています。自社のデータ整備をどこから手をつけるべきか迷われた際は、ご相談ください。
参考・引用元
- 千葉（アルダグラム Tech Blog）「Claude Codeのskillをskillでレビューする ― 静的チェック×LLMレビュー×git hooksの3層ゲート」（Zenn） https://zenn.dev/aldagram_tech/articles/c407ae672c9c0e
- 三好大悟（リベルクラフト）「CSVを渡すだけで分析するエージェントを作る ― Codeインタープリターパターンの設計と安全な実装」（Zenn） https://zenn.dev/libercraft/articles/20260621-analysis-agent-code-interpreter
- Anthropic「Skill authoring best practices」（公式ドキュメント） https://docs.claude.com/en/docs/agents-and-tools/agent-skills/best-practices
※本文は上記の公開情報および当社の自社プロダクト運用で得た知見をもとに再構成したものです。数値は当社の一事例での実測であり、対象データや設計により異なります。事例は特定の企業・案件を指すものではありません。