重複条件は選べる3通り——AIレコメンド・日本語で書くだけ・SQL直接指定

2026.09.03AI名寄せデータ整備の考え方

ナヨセルの重複条件は、AIレコメンド・日本語で書くだけ・SQLの直接指定という選べる3通りの入り口を持ち、どこから入っても最終的に同じ「編集できる一致仕様」に着地します。入り口が3つあるのは親切のためだけではありません。「誰が書いても、誰が読んでも、実行されるものと画面の説明がずれない」という設計目標を実現するための構造です。本連載の第2部「重複をどう見つけるか」の1本目として、この記事では重複条件まわりの設計を内側から解説します。前回までの「データの土台づくり」はデータブラウザの記事をご覧ください。

なぜ入り口を3つ用意したのか

重複条件とは、「何をもって同じ会社・同じ顧客とみなすか」の宣言です。名寄せの品質は、正規化でも辞書でもなく、まずこの宣言の質で決まります。「会社名が一致したら同じ」と雑に宣言すれば、愛知・栃木・福岡に実在する同名の「プラート」3社が1社に潰されます。「全項目が完全一致したら同じ」と臆病に宣言すれば、「㈱プラート」と「株式会社プラート」は永遠に別会社のままです。

問題は、この宣言を書く人が組織によってバラバラなことです。

情報システム部門——SQLは書けるが、「この2社は実務上同じ扱いでいい」というビジネスの判断材料を持っていない
営業企画・営業事務——判断材料は誰よりも持っているが、SQLは書かない
データ整備の専任者——過去に作り込んだルール資産を持っており、それを捨てたくない

入り口をSQLだけに固定すると判断材料を持つ人が書けず、日本語だけに固定すると既存のSQL資産を持つ人が乗り換えられません。名寄せの判断材料を持つ人と、条件を技術的に書ける人が別人である——この現実を、ツールの側が吸収する必要がありました。

もうひとつの理由は、重複条件が「一度作って終わり」ではないことです。運用の中で「この条件では拾いすぎる」「新しい流入元のデータは癖が違う」と気づき、直し続けることになります。直す人が、最初に作った人と同じスキルを持っているとは限りません。だから、どのスキルの人にも開かれた入り口が必要でした。

3通りの入り口と使い分け

3通りの入り口は、それぞれ想定している場面が違います。

入り口	出発点	向いている場面
AIレコメンド	白紙。AIがスキーマとデータの中身を読んで提案する	初回。データの癖をまだ誰も把握していないとき
日本語で書くだけ	「会社名の表記揺れを吸収して、電話番号が同じものを候補に」のような日本語の指示	判断材料を持つ実務者が、自分の言葉で条件を作る・直すとき
SQL直接指定	SQLの条件式そのもの	既存のルール資産を移植するとき。細部を厳密に制御したいとき

AIレコメンド——データの癖を織り込んだ叩き台

AIレコメンドは、テーブル定義や項目の型だけでなくデータの内容まで読んだうえで、「このデータは電話番号の欠損が多いので、会社名と住所の組み合わせを主軸にすべき」といった、実態に即した条件を理由つきで提案します。白紙から考える作業を「提案をレビューして直す」作業に変えるのが役割です。詳しくはAI名寄せとはで解説しています。

日本語で書くだけ——判断材料を持つ人がそのまま書く

日本語の指示は、AIが「一致仕様」（後述）に解釈します。重要なのは、日本語の指示のまま実行されるわけではないことです。解釈結果は必ず画面に表示され、人が確認・編集してから保存されます。

SQL直接指定——既存資産をそのまま活かす

長年ルールベースの名寄せを運用してきた組織には、磨き込まれた判定基準がSQLやマクロの形で残っています。ナヨセルはこれを書き直させません。SQLをそのまま条件として登録でき、AI由来の条件と同じ画面で管理できます。

NAYOSELのウィザードSTEP2。「文章で重複の条件を書いてください」の入力欄と、AIが変換した一致条件の確認画面 — 日本語で書く方式：文章をAIが一致条件に変換し、理解の内容を確認してから確定する（NAYOSELの例）

どこから入っても同じ「一致仕様」に着地する

3つの入り口の合流点が「一致仕様」です。一致仕様は条件の並びで、各条件は次の要素を持ちます。

一致の型——完全一致／表記揺れを吸収して一致／辞書で名寄せして一致／類似度で一致、の4種類
比べる項目——主データ側と取り込みデータ側、それぞれどの列を比べるか
揺れの吸収方法——会社名・住所・電話番号などの項目種別に応じたプリセット、または正規化ステップの個別指定
判断理由——AI経由の場合、なぜこの条件を選んだかの説明文

条件同士は「かつ」「または」で束ねます。そしてここが設計の要ですが、AIの仕事は「日本語を一致仕様に解釈する」ところまでです。一致仕様からSQLへの変換は、AIではなく決まった手順の変換器が担います。同じ一致仕様からは、何度変換しても、誰が変換しても、同じ構造のSQLが生成されます。AIの気まぐれが実行結果に入り込む余地を、構造的に断っています。

AIレコメンド・日本語・SQLの3つの入り口が1つの一致仕様に合流し、決まった手順の変換器がSQLを生成する流れ図 — 3つの入り口はすべて「一致仕様」に合流する。仕様からSQLへの変換にAIは関与しない

変換の前には仕様の検査が走ります。指定された列が実在するか、揺れの吸収ステップが定義済みのものか、辞書の指定が正しいか。問題があれば「取り込み側に列『tel』がありません」のような日本語のエラーで、実行前に止まります。壊れた条件が静かに実行されて、静かに間違った結果を返す——名寄せで最も怖いのはこの「静かな失敗」なので、失敗は必ずうるさくしています。

画面の説明と実行されるSQLがずれない仕組み

条件を保存すると、画面には「一致の意味」パネルが表示されます。「会社名：表記揺れを吸収して一致（会社名の揺れ）、かつ、電話番号：表記揺れを吸収して一致（電話番号の揺れ）」のように、条件を日本語で開いたものです。

このパネルは、生成されたSQLをAIがあとから要約した「感想文」ではありません。SQLの生成元である一致仕様そのものを表示しています。表示とSQLは同じ一枚の仕様から生成された兄弟なので、構造的にずれようがない——これが「画面の説明と実行されるものが一致する」ことの技術的な担保です。SQLの読めない承認者も、このパネルを読めば「何が実行されるのか」を正確に把握できます。

ではSQLを直接編集したらどうなるか。このとき一致仕様とSQLの同期は崩れるため、パネルには「SQLが手動で編集されています。この説明は最新でない可能性があります」という警告が明示されます。ずれを隠さず、ずれていることを表示する。日本語から再変換すれば同期は回復します。

一致仕様から画面表示と実行SQLの両方が生成されるため構造的にずれない。SQL手動編集時は警告が出ることを示した図 — 表示とSQLは同じ仕様から生成される。手動編集でずれた場合は、ずれていること自体を警告する

さらに実行前のプレビューでは、条件ごとに「正規化後の値」や「類似度スコア」を説明列として並べて表示します。「この2件はなぜ一致とされたのか」を、判定に使われた値そのもので確認できます。

空の値と類似度——事故を防ぐ2つの安全設計

重複条件には、経験者なら誰もが踏んだことのある古典的な落とし穴が2つあります。ナヨセルはどちらも構造で塞いでいます。

空の値は一致に使わない

1つ目は空値の事故です。「電話番号が一致したら同じ会社」という条件は一見安全ですが、電話番号が未入力のレコードが1万件あると、素朴な実装では「空と空が一致」して1万件が全部つながります。ナヨセルは次の3種類の値を、すべての条件で一致判定から除外します。

未入力の値——そもそも値が入っていないレコード同士は比べない
空文字——見た目は未入力と同じでも内部的には別物。どちらも同じく除外する
正規化した結果として空になった値——「－」のような記号だけの値、「株式会社」と法人格だけ入力された値は、揺れを吸収すると中身が残らない。これも一致には使わない

空同士は決して一致しません。この除外は個々の条件に自動で組み込まれるため、条件を書く人が気を付ける必要はありません。「気を付ければ防げる事故」を、気を付けなくても起きない構造にしておくのが方針です。

類似度は「劇薬」として扱う

2つ目は類似度です。文字列の似ている度合いで候補を出す類似度一致は、辞書にも正規化にも引っかからない揺れを拾える最後の網ですが、「山田電機」と「山田電器」のような1文字違いの別会社も同じ顔で拾ってきます。だからナヨセルは類似度を使えるようにしつつ、劇薬としての扱いを設計に埋め込んでいます。しきい値は既定で0.85、一定より緩い値はそもそも指定できません。そして類似度を含む条件を保存すると、画面が「誤って名寄せするリスクがある」旨を警告し、自動マージではなく承認キューでの人の確認を推奨します。

確実な条件は機械に任せ、確率的な条件は人の確認とセットでしか使わせない。条件の「強さ」に応じて出口の扱いを変えるのが、ナヨセルの重複条件の思想です。