データブラウザ——ステージングテーブルを直接歩いて「汚れの正体」を見る

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

名寄せの条件は、データを実際に見た人にしか書けません。データブラウザは、作業台（ナヨセルDB）に取り込んだステージングテーブルを、読み取り専用で直接歩くための画面です。クリックで辿るリストビューと、マルチタブのSQLワークベンチ。検索の入り口は「日本語で書くだけ・宣言的な条件指定・SQLエディタ」の3つで、どこから入っても最終的に確認可能なSQLに合流します。この記事では、なぜ名寄せツールに「データを眺めるためだけの画面」をここまで作り込んだのか、その設計判断を解説します。

条件を書く前に、データを見る

「会社名と電話番号で突き合わせればいい」——この判断は、電話番号がきちんと埋まっているデータでの話です。実物を開いてみると、現実はたとえばこうなっています。

電話番号の欄に「本社代表」「携帯に連絡」と文字が入っている
会社名の末尾に「※重複注意」「（旧：山田製作所）」というメモが書き足されている
担当者名の欄が一律「ご担当者様」で埋められている
住所の欄に建物名だけが入っていて、番地は備考欄にある

どれも、集計値だけを見ていては気づけない汚れです。そしてどれも、知らずに突合キーへ使えば誤マージか拾い漏れを起こします。

前回のAI名寄せ診断は、データ全体を面でプロファイルして重複率と条件案を出しました。しかし面の把握と点の確認は別の仕事です。「埋まり率72%」という数字は、残り28%が単なる未入力なのか、それとも「なし」「−」「000-0000-0000」のような埋まっているように見える空欄なのかを教えてくれません。それを知るには、実際の行を開いて自分の目で見るしかない。条件設計の前の実地検分——データブラウザはそのための道具です。

これは名寄せに限らないデータ整備の鉄則でもあります。条件やルールは、データの実態の写し絵です。実態を見ずに書いたルールは、実態と初めて出会う本番実行の瞬間に壊れます。だからナヨセルは、取り込んだ直後のデータを、加工せず・遅延なく・そのまま歩ける画面を名寄せ本体と同格の機能として持っています。

2つのビュー——リストビューとSQLワークベンチ

データブラウザには、性格の違う2つのビューがあり、上部のタブでいつでも切り替えられます。最後に使ったビューは記憶されるので、次回は自分の定位置から始まります。

	リストビュー	SQLワークベンチ
操作感	SFAの画面のように、テーブルのタブと一覧をクリックで辿る	分析ツールのように、複数のタブで問い合わせを並行して開く
向いている人	業務部門・SFAに慣れた人	データ担当・SQLや分析に慣れた人
向いている仕事	特定のレコードを開いて中身を確かめる	複数の切り口で汚れを横断調査する
検索の入り口	一覧の絞り込みとレコード詳細	日本語で書くだけ／宣言的な条件指定／SQLエディタ

入り口を2つ用意したのは、名寄せのレビューに参加する人が2種類いるからです。「この2社は同じか」を判断できるのは業務の人、「この揺れはどのパターンか」を切り分けられるのはデータの人。どちらか一方に画面を寄せると、もう一方がレビューから脱落します。前々回の日本語化がここで効いて、検索結果の列名は表示名（日本語）と物理名をワンタッチで切り替えられます。業務の人は「請求先市区町村」で読み、データの人は物理名で確かめる——同じ結果を、それぞれの言葉で読めます。

見られるテーブルは、取り込みデータ（主・副）・関連データだけではありません。名寄せ実行後の統合ドラフト・統合台帳、さらに実行前に自動採取されるバックアップまで、作業台の上のテーブルはすべて同じ画面で開けます。取り込み直後の検分も、実行後の検品も、「あの時点のデータはどうだったか」の確認も、道具は1つです。

NAYOSELのデータ閲覧。名寄せを選ぶと取り込み（基準）・統合ドラフト・統合台帳のテーブル一覧が表示される — 名寄せを選ぶと取り込み（基準）・統合ドラフト・統合台帳のテーブル一覧が表示される（NAYOSELのデータ閲覧）

検索の3つの入り口はSQLに合流する

SQLワークベンチの検索には3つの入り口があります。

日本語で書くだけ——「東京の製造業の会社を見せて」と書くと、AIがSQLに変換します。変換されたSQLは必ずSQLエディタに表示され、確認・編集してから実行します。日本語の指示のまま実行されることはありません
宣言的な条件指定——表示する項目をチップで選び、「を含む」「が空」「より大きい」などのフィルタを重ねます。組み上がるSQLが画面に常に表示されます
SQLエディタ——SELECT文を直接書きます。書ける人には最短の道です

日本語で書くだけ・宣言的な条件指定・SQLエディタという3つの入り口が、すべて確認可能なSQLに合流してから読み取り専用で実行される構造図 — 3つの入り口は全部SQLに合流する。実行されるものは常に目視できる1つの形式

どの入り口から入っても、実行される直前には必ず「読めるSQL」がある。入り口は好みで選び、実行されるものは常に1つの透明な形式。

この構造は、ナヨセルの重複条件が「AIレコメンド・日本語で書くだけ・SQLの直接指定」の選べる3通りで、どれも最終的に編集できるルール（SQL）に着地する設計と、意図的に同じ形にしてあります。理由も同じです。AIや画面操作は入力を楽にするための入り口であって、システムが実行する実体は常に人が読める形式に一本化する。「なぜこの結果が出たのか」と聞かれたら、実行されたSQLを見せれば答えになる——検索のような小さな操作でも、この透明性の原則を崩しません。

細かい配慮もあります。日本語からの変換結果には補足（どういう解釈で変換したか）が付き、テーブルを選んだ瞬間に先頭100件が自動で表示されるので、「まず何か見たい」に対しては何も入力しなくても答えが出ます。結果の行をクリックすればレコード詳細ページに飛び、1件の全項目を縦に眺められます。

読み取り専用という設計判断

データブラウザからの問い合わせは、読み取り専用のデータベースロールで実行されます。実行できるのはSELECT文だけ、取得は最大500件。UPDATEもDELETEも、経路として存在しません。

作業台はナヨセルが管理するデータベースなのだから、技術的には編集機能を付けることもできました。それでも閲覧経路から書き込みを外したのは、「見る」と「変える」を別の経路に分けるためです。ナヨセルでデータが変わる経路は、次の正規ルートに限定されています。

取り込みフローの実行——コネクタやCSVから作業台へデータが入る
名寄せ処理の実行と承認——条件に基づく統合が、シミュレーションと人の承認を経て確定する
書き戻しの実行——確定した結果だけが元サービスへ反映される

この正規ルートには、スナップショットと監査の記録が必ず付きます。もし閲覧画面から直接値を直せてしまうと、この安全装置の外側でデータが変わる抜け道ができてしまう。「汚れを見つけたその場で直したい」誘惑はわかりますが、その1件の手直しは、監査ログに残らない変更・スナップショットに守られない変更になります。だから見つけた汚れは、正規化・辞書・条件・取り込み設計という正規の道具で直す——のが、この製品の一貫した流儀です。

読み取り専用にはもうひとつの効用があります。誰にでも安心して配れることです。壊す手段が存在しない画面なら、新しく入ったメンバーにも、データベースに不慣れな業務部門にも、「自由に歩いて汚れを探してください」と渡せます。触る人が増えるほど汚れは見つかりやすくなるので、読み取り専用は制限であると同時に、検分の人手を増やすための設計でもあります。

歩いて見つかる「汚れ」の類型

実際にデータを歩くと、汚れはおおむね4つの類型に整理できます。類型ごとに、次に取るべき打ち手が違うことがポイントです。

① 文字の揺れ——「㈱プラート」と「株式会社プラート」、全角と半角、余分な空白。機械的な正規化で吸収できる揺れです（次回の文字正規化の回で内側を解説します）
② 意味の揺れ——旧社名と新社名、通称と正式名称。「山田電機」と「山田電器」のように、同じかもしれないし別会社かもしれない揺れ。辞書と人の判断が要る領域です
③ 欠損と代用値——空欄、「なし」「−」、「ご担当者様」「000-0000-0000」。埋まっているように見える空欄は、突合キーに使うと無関係な行同士を束ねる事故のもとです
④ 構造の汚れ——1つのセルに電話番号が2つ、住所欄に建物名だけ、備考欄に本来別項目であるべき情報。取り込みや列設計の見直しで対処します

歩いて見つかる汚れの4類型。文字の揺れ、意味の揺れ、欠損と代用値、構造の汚れのそれぞれの例と打ち手を示した図 — 汚れの4類型。どの類型かで「正規化・辞書・条件のガード・取り込み設計」と打ち手が変わる

この類型分けが、そのまま条件設計の質を決めます。①が多いなら正規化を効かせた条件でほとんど拾えます。②が多いなら辞書づくりに投資すべきで、③が多い列は突合キーから外すか「空欄は一致とみなさない」ガードを確かめるべきです。診断のレポートを読むときも、この4類型を頭に入れて実例を見ると、「なぜこの案が推奨なのか」が腹落ちします。

ナヨセルの場合——診断と対になる検分の道具

ナヨセルの中で、データブラウザはAI名寄せ診断と対になる位置にあります。診断が「面」——全体をプロファイルして重複率と条件案を出す——なら、ブラウザは「点」——気になった箇所を開いて現物を確かめる。診断レポートの実例で「この2行がまとまる」と示されたら、ブラウザでその会社名を検索して周辺の行ごと眺める、という往復が実際の使い方です。

そしてこの画面は、名寄せの全工程を通じて使い続けます。取り込み直後の検分、条件設計中の裏取り、シミュレーション後の抜き取り確認、実行後の検品、バックアップとの突き合わせ。工程ごとに別の閲覧ツールを渡り歩かなくていいことが、作業台方式（連載第1回）の実利のひとつです。これで連載第1部「接続とデータの土台」は完結です。つなぐ・読める形にする・実測で診る・歩いて確かめる——土台が揃ったので、次部からはいよいよ「重複をどう見つけるか」、条件設計の内側に入ります。

データブラウザは全プランでお使いいただけます。プランごとの違いは料金プランを、アクセス制御の考え方はセキュリティのページをご覧ください。