資料ダウンロード
無料デモを予約「〇〇株式会社 大阪支店」は同じ会社か別か——拠点名寄せの決め方
「株式会社山田製作所 大阪支店」を本社のレコードと統合すべきか——この問いに全社共通の正解はありません。与信や売上集計にとっては「同じ会社」、配送先や営業担当割にとっては「別の拠点」が正しい。つまり拠点の名寄せは、判定精度の問題である前に「どの業務にとっての同じか」を先に決める問題です。月末のCRMに「山田製作所」「山田製作所 大阪支店」「山田製作所 大阪営業所」が並び、統合してよいのか誰にも聞けないままその3行が来月も残る——この記事では、この光景がなぜ生まれるのかを解きほぐし、単位を宣言してから機械に任せる「拠点名寄せの決め方」を解説します。
この「あるある」——支店レコードの前で毎回手が止まる
取引先マスタの重複を洗い出すと、必ずこの型に出会います。「株式会社山田製作所」「株式会社山田製作所 大阪支店」「山田製作所 大阪営業所」「（株）山田製作所 西日本支社」。名称はほとんど同じ、電話番号は違う、住所も違う。表記揺れの重複なら迷わず統合するところですが、この4行の前では手が止まります。同じ会社のようでもあり、業務上は別の相手のようでもあるからです。
担当者が営業に聞くと「大阪は大阪で別のお客様。うちの担当は本社だけ」と言われ、経理に聞くと「請求はぜんぶ本社宛にまとめている。分かれていると困る」と言われます。どちらも正しいのがこの問題の厄介なところです。判断を保留した支店レコードは統合候補のリストに残り続け、名寄せのたびに同じ4行を眺めることになります。
先に結論を言い切ります。この手詰まりの原因は、ツールの判定精度でも担当者の知識不足でもなく、「どの業務にとっての同じか」を組織として決めていないことです。単位を決めれば、あとは機械的に処理できます。決めないまま精度だけ上げても、止まる場所は変わりません。
なぜ拠点レコードは増えるのか——入口ごとに「会社」の単位が違う
拠点レコードは、誰かのミスで増えるのではありません。データの入口ごとに「会社」という言葉が指す単位が違うから増えます。
- 展示会・名刺——名刺に刷られているのは「株式会社山田製作所 大阪支店 営業二課」。取り込めば拠点単位のレコードになる
- 契約・請求——契約書の名義は法人。経理が起こすレコードは「株式会社山田製作所」の本社単位になる
- サポート・配送——問い合わせも納品先も現場の拠点。物流部門が登録するのは「大阪営業所」の住所と電話番号
- 営業の手入力——担当エリアの相手先として「山田製作所 大阪」とだけ登録される
それぞれの部門にとって、その入力は正しいのです。名刺の通りに入れた営業も、契約名義で起こした経理も、間違っていません。問題は、CRMの「取引先」というひとつの箱に、法人の顔をしたレコードと拠点の顔をしたレコードが区別なく混ざることにあります。
もうひとつ、制度の側の事情があります。支店や営業所には法人格がありません。登記上、大阪支店は株式会社山田製作所という1つの法人の一部です。ところが業務の現場では、支店は独立に振る舞います。発注書は支店名義で届き、窓口の担当者も支店にいます。制度上は1つ、業務上は複数——このずれが、拠点レコード問題の構造です。詳しくは次の連載記事で扱いますが、これが子会社なら話は逆で、名称が似ていても登記上は別法人です（親会社と子会社をうっかり統合しない）。
放置するとどうなるか——統合しても分割しても誰かが困る
拠点レコードの怖さは、放置しても、雑に統合しても、それぞれ別の業務被害が出ることです。
放置した場合、法人単位で見る業務が壊れます。山田製作所との取引が本社・大阪・西日本の3行に分散すると、取引額の実像が見えません。年間数千万円の取引がある重要顧客が、1行ずつ見れば中位の顧客に見える。与信枠は法人単位で判断するものなのに、レコードが割れていれば判断材料も割れます。全社の顧客ランキングも、上位に来るべき会社が3つに割れて圏外に沈みます。取引先が数万件の規模なら、支店表記を含むレコードは経験上その数パーセントから1割程度を占め、しかも取引額の大きい会社ほど拠点が多いため、金額ベースの歪みは件数の比率より大きくなります。
雑に統合した場合、拠点単位で動く業務が壊れます。大阪営業所のレコードを本社に統合すると、配送先住所が本社の住所で上書きされ、納品物が本社に届きます。大阪を回っていた営業担当の割当も外れます。統合の朝から、物流と営業の現場で実害が出はじめます。
拠点名寄せは「統合すべきか、すべきでないか」の二択問題ではありません。「法人として見る業務」と「拠点として見る業務」が同じデータの上に同居していることが本質で、どちらかに倒せば必ず反対側が壊れます。
そして被害は静かに積もります。レポートの数字が割れていても、配送先が違っていても、システムはエラーを出しません。発覚のしかたは、たいてい次のどれかです。
- 与信の会議で「この会社、実際はもっと取引があるはずでは」と数字への不信が口に出る
- 統合の翌週、納品先の誤りがクレームとして営業に返ってくる
- 営業会議の数字と全社レポートの数字が合わず、原因調査に半日消える
どれも、被害が起きたあとの発覚です。エラーが出ない問題は、仕組みで先回りする以外に防ぎようがありません。
手作業で対処するとどこで詰むか
多くの現場では、まずExcelでの月次補正が始まります。取引先一覧を出力し、「支店」「営業所」「支社」を含む行を検索して、集計用の列に親会社の名前を書き込む。この運用は、3つの場所で詰みます。
第一に、表記のパターンが尽きません。「大阪支店」「大阪営業所」「関西支社」「西日本統括部」「大阪支店 第二営業部」——拠点の呼び方に規格はなく、部署名まで混ざります。検索語を継ぎ足すほど補正式は読めなくなり、それでも「山田製作所 大阪」のような手がかりの薄い行は人が1行ずつ判断するしかありません。数千行の目視補正は、月次で数時間の作業になります。
第二に、補正はExcelの上にしか存在しません。集計は直せても、CRM本体の3行はそのままです。配送や担当割が拠点レコードを使っている以上、行を消すわけにはいかないからです。翌月も、その翌月も、同じ補正を繰り返すことになります。
第三に、判断が人に張り付きます。「西日本支社は大阪支店と同じ拠点」「山田製作所 大阪は営業所のこと」という知識は補正担当者の頭の中にだけあり、担当が代わると前月と数字が合わなくなります。さらに根深いのは、営業会議は補正後の数字を見て、物流は補正前のデータで動いていることです。単位の宣言がないまま部門ごとに別の数字を見る——照合のたびに「どちらが正しいのか」の不毛な確認が発生します。
拠点名寄せの決め方——単位はレコードではなく業務に聞く
手詰まりを抜ける手順は、逆順にするだけです。レコードを見て「同じか別か」を悩むのではなく、先に業務ごとの単位を宣言し、そのあとでレコードを機械的に仕分けます。
1. 業務ごとに正しい単位を書き出す
宣言は表1枚で足ります。典型的にはこうなります。
| 業務 | 正しい単位 | 理由 |
|---|---|---|
| 与信管理・取引限度額 | 法人 | 支払能力と責任は法人に帰属する |
| 売上集計・顧客ランキング | 法人 | 取引の実額は法人でまとめないと分散する |
| 請求書の宛先 | 法人（契約名義） | 支払の主体は法人 |
| 配送・納品 | 拠点 | モノは拠点の住所に届く |
| 営業担当・テリトリー | 拠点 | 人は拠点に通い、窓口も拠点にある |
この表を埋める作業は、システムの話ではなく業務の合意形成です。だからこそ最初にやる価値があります。表が埋まれば、「統合すべきか」という曖昧な問いは消え、「法人キーを振るか、拠点として残すか」という機械的な仕分けだけが残ります。
2. 法人番号は本社に振られる——確定キーが引く境界線
法人の単位を機械的に確定する鍵が法人番号です。ここで重要な性質がひとつ。法人番号は法人に1つだけ振られ、支店や営業所には振られません。「株式会社山田製作所 大阪支店」に法人番号を引き当てると、本社と同じ番号が付きます。これは照合の失敗ではなく、「大阪支店は登記上、同じ法人である」という制度の事実がキーの形で現れたものです。つまり法人番号は、「どこまでが同じ法人か」の境界線を国のマスタで確定的に引いてくれます。500万法人超の法人マスタとの突合で名称から番号を補完する仕組みは、法人番号による確定名寄せの記事で解説しています。
3. 2階建てで持つ——潰す統合ではなく、束ねる統合
単位の宣言と法人キーが揃えば、実装は2階建てになります。拠点レコードは消さずに残し、すべての拠点レコードに同じ法人キー（法人番号）を持たせる。法人単位の業務は法人キーで束ねて集計し、拠点単位の業務は行をそのまま使う。統合とは行を1つに潰すことではなく、業務ごとに正しい単位で束ねられる状態を作ることです。潰してよいのは「大阪支店」と「大阪営業所」が実は同じ拠点の表記違いだった、という拠点内の重複だけです。
ナヨセルの場合——「単位の宣言」を編集できるルールにする
当社のAI名寄せ・顧客データ統合クラウド「ナヨセル」は、この決め方をそのまま実装に落とせるように作られています。単位の宣言は、頭の中の運用ルールではなく、画面で確認・編集できる重複条件になります。
- 法人キーの補完——gBizINFO由来の法人マスタ500万法人超と突き合わせ、名称と所在地から法人番号を引き当てます。支店表記を含むレコードにも本社の番号が付き、「同じ法人か」が確定します（法人番号による確定名寄せ）
- 単位を条件で宣言する——「拠点表記を除いた名称と法人番号が一致し、かつ住所も一致するものだけ統合する（拠点内の表記違いだけ潰す）」のような条件を、AIのレコメンド・日本語で書くだけ・SQL直接指定の選べる3通りで定義できます。生成された条件は必ず画面に表示され、編集できる透明なルールとして残ります（重複条件は選べる3通り）
- 決めきれない行は人へ——「山田製作所 大阪」のように手がかりの薄いレコードは、無理に自動で決めず承認キューに回します。変更前・取り込み・変更後の3枚を並べて人が判断し、判断は記録されます（承認キュー）
- 値の残し方も宣言する——拠点内の重複を統合するとき、どちらの住所や電話番号を残すかはルールで決められます。「本社の値で上書きされて配送先が消えた」を防ぐのはこの宣言です（勝ちレコードの決め方）
実行の前には全件シミュレーションで「この宣言なら何件が束なり、何件が残るか」を確認でき、確定は人の承認、実行後も監査ログとスナップショットが控えます。AIが叩き台をつくり、確定は人の承認で、実行は編集できる透明なルールで——単位の決めが要る拠点名寄せこそ、この役割分担が効く場面です。料金はマージ対象レコード数だけで決まり（Starter月額5万円〜・税抜）、全プランに導入支援（2ヶ月・50万円〜）が標準付帯します。単位の宣言づくりの合意形成から伴走しますので、料金プランもご覧ください。
よくある質問
支店レコードを統合すると、配送先や担当割は消えてしまいませんか？
「拠点は残す」と宣言すれば消えません。ナヨセルの統合は編集できる条件で動くため、法人キーで束ねるだけの設計と、拠点内の表記違いだけを潰す設計を分けて定義できます。潰す場合も、どちらの住所を残すかは勝ちレコードルールで宣言できます。
法人番号で支店と本社を区別できますか？
できません。法人番号は法人に1つで、支店には振られないためです。法人番号が教えてくれるのは「同じ法人かどうか」までで、拠点の区別は住所・電話番号・拠点名で行います。役割の違うキーを重ねて使うのが実務の形です。
「大阪支店」と「大阪営業所」が同じ拠点なのか、判断できません。
条件で決めきれないペアは承認キューに回し、住所や電話番号を見比べて人が判断してください。「同じ拠点」と確定した判断は次回以降にも効き、別拠点なら別のまま残ります。判断は監査ログに記録されるため、あとから経緯を説明できます。
どの業務をどの単位にすべきか、社内で意見が割れます。
割れるのが正常です。部門ごとに正しい単位が本当に違うからです。本文の表のように業務別に書き出すと、「全社で1つに決める」必要がそもそもないことが共有され、議論が収束します。ナヨセルの導入支援では、この宣言づくりから一緒に行います。
まず、支店表記のレコードがどれだけあるか把握したいのですが。
統合の前に現状を数えるのが正しい順序です。ナヨセルではデータブラウザでステージングテーブルを直接歩いて「支店」「営業所」を含む行を確認でき、AI名寄せ診断で重複の規模を実行前に数字で把握できます。
料金プランと導入支援の内容がわかる
資料をご用意しています
サービス概要から料金プラン、2ヶ月の導入支援の進め方まで
まとめた資料を無料でダウンロードいただけます。
