赤兎馬EC運用支援
公開情報からメーカーの連絡先を集める作業を、AIエージェントとスクリプトで進めています。2026年9月16日、その名簿に「別の会社の連絡先」が混じっているのを見つけました。609行を点検し直して140社分を撤回したのですが、2日後、そのうち87社分が別のファイルから戻りかけました。
この記事では、AIやスクリプトの出力を撤回するときに「台帳から消すだけでは終わらない」理由と、撤回を完了させるために直すべき3か所を、実際にやった手順とチェックリストの形で書きます。受注データと在庫、広告レポートと売上など、出どころの違うデータをAIに突合させている方に、そのまま持ち帰れる形にしました。
9月16日、名簿の1行が「別の県の会社」だった
きっかけは確認作業中の違和感でした。ある地域の食品メーカーの行に、別の県にある同名店のメールアドレスが入っている。電話番号の市外局番を見れば、明らかに別会社です。
1件だけなら入力ミスで済みます。ただしその行は人が手で入れたものではなく、2026年9月上旬にまとめて機械で補完した609社分の一部でした。1件出たということは、同じ作り方をした609行すべてが同じ理由で間違っている可能性がある、ということです。個別の修正ではなく、全数点検の話になります。
原因は「名前の部分一致だけで判定していた」こと
補完のロジックは単純でした。名簿にある店舗名と、公開されている店舗情報の名前を突き合わせ、部分一致したらその連絡先を採用する。所在地も法人名も見ていませんでした。
この作り方だと、少なくとも2つを取り違えます。
- 同じ屋号の、資本関係のない別会社（地域名＋業種名のような屋号はとくに衝突しやすい）
- 自治体のふるさと納税ページのように、そのメーカーの商品を扱っているだけのページを「その会社の出店」として拾ってしまう
AIの判断が悪かったというより、「一致」の定義を私たちが緩く与えていたのが原因です。名前が同じことと、同じ会社であることは別物で、その差を埋める情報（法人名・所在地）を最初から渡していませんでした。
609行を、法人名と所在県で突き合わせ直した
点検は総当たりにしました。各社が公開している特定商取引法に基づく表記から法人名と住所を取り、名簿側の県・市と照合します。2026年9月16日時点の結果は次の通りです。
- 社名も県も一致：318件
- 県が違う：86件
- 社名が一致しない：39件
- そもそも表記を取得できていなかった：166件
まず同日中に109社を撤回し、取得できていなかった分は追加で取ってから再判定しました。同日中に109社、追加分で31社、合計140社を名簿から消しています。
このとき人として決めたことが2つあります。
- 似た名前の別会社を当てにいくくらいなら、空欄にする。営業リストの価値は「埋まっている率」ではなく「間違いが混じっていないこと」にあります。誤った連絡先は、送った瞬間に相手にも自社にも迷惑がかかる
- 社名は一致しないが県は一致する39件は、機械で決めない。ブランド名と登記上の法人名が違うだけ、というケースが確実に混ざるので、人が目で見る列に回しました
あわせて、撤回した値は消して終わりにせず、根拠メモに「何を、なぜ撤回したか」を残しました。後から誤判定だったと分かれば、人が1行見れば戻せます。
2日後、撤回したはずの87社が戻りかけた
ここからが本題です。
2026年9月18日、別の工程で使っている中間ファイルを開いたところ、そこに同じ誤マッチが丸ごと残っていました。気づかずに反映していれば、撤回した87社分が名簿に戻っていたことになります。
理由は単純で、直したのは名簿の中身だけで、誤りを生んだ照合の処理そのものは直っていなかったからです。中間ファイルは撤回作業の対象に入っておらず、同じ照合の処理から作られたままになっていました。台帳を見るかぎり、その2日間は「直っている」ように見えていました。
撤回の3点セット（チェックリスト）
この件で決めたのは、AIやスクリプトの出力を撤回するときは、次の3か所を同じ作業の中で直す、というルールです。
- ① 生成元のロジック：誤りを生んだ判定条件そのもの。今回は「採用するのは法人名と所在県の両方が一致したときだけ。通らないものは『なし』ではなく『未確認』に戻す」に変えました。「なし」にすると、後から見た人が「調べた結果なかった」と誤読します
- ② 既存の中間物：同じロジックで作られた途中のファイル、下書き、別工程にコピーされた分。台帳だけ直してもここが残っていれば戻ります。今回はここで詰まりました
- ③ 反映前の関門：未検証の値が残っていたら、反映処理そのものを中止する。手順書に「確認すること」と書くのではなく、機械が止める
③を入れた結果、2系統あわせて165件が反映されずに止まりました。手順書だけの運用だったら、このうち何件かは通っていたはずです。人は急いでいるときにチェックを飛ばしますが、スクリプトは飛ばしません。
地味ですが大事なのが、撤回を「記録つきで」行うことです。単純に消すと、再発したときに「これは直した分なのか、まだ直していない分なのか」が判別できなくなります。
EC実務だと、どこで同じことが起きるか
名寄せの話に見えますが、構造は受注・在庫・広告の突合とまったく同じです。商品名の部分一致でつないだ集計表、仕入先名で紐づけた原価表、広告レポートと売上を媒体側の商品名で合わせた資料。どれも「名前が同じ＝同じもの」という前提で動いています。
判断基準の例として、次の4つを挙げます。
- 突合のキーがコード（JAN・SKU・注文番号・広告のID）でないなら、その集計は参考値として扱う。名前の一致だけで金額を動かさない
- 一致しなかった行を「0」や「なし」で埋めない。「未確認」のまま件数を出す。未確認が何件あるか書かれていないレポートは、精度が分からないレポートです
- 数字を訂正したら、その数字を引用した資料・共有ファイル・自動更新の集計を同じ日に洗う（＝3点セットの②）
- 自動で反映する仕組みがあるなら、未検証の行が1件でも残っていたら反映を止める条件を入れる（＝③）
利益の見え方に直結するのは、広告後粗利（売上から原価・各種手数料・広告費を引いた、実際に手元に残る利益）を出すときです。広告後粗利を見るには、受注・原価・手数料・広告費という出どころの違う4つを突合する必要があります。どこか1か所のキーがぶれると、SKU別損益は表として整っているのに中身だけ入れ替わる。しかも「赤字に見えるSKU」は広告停止や値上げの判断に直結するので、誤りが行動に変わるのが早いのが厄介です。数字が動いたときに疑うのは計算式より先に、結合のキーと未一致件数でいいと思っています。
人が残る場所
今回、機械に任せられなかったのは2か所でした。
- 社名が一致しない39件をどう扱うかの判断
- 「カバー率より精度を取る＝迷ったら空欄」という方針の決定
AIは照合も点検も高速にやってくれますが、「間違えたときにどちらに倒すか」は人が決めるしかありません。むしろそこを先に決めておくほど、任せられる範囲は広がります。
まとめ
- 誤りが1件見つかったら、同じ作り方をした全行を疑う
- 撤回は「生成元のロジック」「既存の中間物」「反映前の関門」の3点セット。台帳だけ直すと戻る
- 関門は手順書ではなく機械に置く
- 一致しなかったものは「なし」ではなく「未確認」にする
データの突合や集計をAIで内製していくと、速さより先に「間違えたときの戻し方」を決めてあるかどうかで差がつきます。もし自社のEC運用まわりで、数字の出どころや突合の精度に不安があるようでしたら、まずは現状を可視化するところからでも。店舗URLをいただければ、改善余地をレポートにしてお返ししています（無料EC診断）。AI導入・社内内製化のご相談も同じ窓口で受けています。
https://ec-sekitoba.jp/#contact