スキーマ取込とカラム名の日本語化——物理名だらけのテーブルを人が読める形にする

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

テーブルの列名を人が読める形にすることは、名寄せの「前処理」ではなく「品質保証の一部」です。重複かどうかの最終判断を下すのは業務を知る人であり、その人が読めない列名のままではレビューが成立しないからです。この記事では、コネクタから列定義を丸ごと持ってくる「スキーマ移植」と、AIの単語分割と翻訳を組み合わせた「表示名⇄物理名の相互変換」の仕組み、そしてなぜそういう設計にしたのかを解説します。連載第1回の接続の話の続きです。

物理名の壁——billingcityを誰が読めるのか

作業台にデータを取り込むと、まず目に入るのは列名です。そしてその列名は、多くの場合こうなっています——billingcity、numberofemployees、shippingstate、annualrevenue__c。データベースの物理名は英単語を連結した小文字の羅列で、Salesforceのカスタム項目なら末尾に管理用の接尾辞まで付きます。エンジニアなら文脈で読めますが、営業企画の担当者に「billingcityとshippingcityのどちらで突き合わせますか」と聞いても、会話になりません。

ここが名寄せ特有の急所です。名寄せは、データを技術的に処理する仕事であると同時に、「この2社は同じか」をビジネスの文脈で判断する仕事でもあります。「請求先住所と納品先住所のどちらを会社の所在地とみなすか」を決められるのは、そのデータで仕事をしている現場の人だけです。列名が物理名のままだと、この判断に参加できる人が社内で数人に絞られてしまい、名寄せがまた属人化します。

実際、名寄せの工程を追いかけると、列名を「人が読む」場面は想像以上に多いことがわかります。

重複条件のレビュー——「会社名＋電話番号で突合」の「会社名」がどの列か、全員が同じ理解である必要がある
承認の判断——グレーな候補を承認する画面で、判断材料の列が読めなければ承認は形骸化する
データの検品——取り込んだデータを眺めて汚れを探すとき、列名が読めないと異常に気づけない
監査への説明——「どの項目で同一と判定したか」を、監査する側にも伝わる言葉で説明する

逆方向の壁もあります。現場の人が「顧客番号・会社名・請求先市区町村」と日本語で列を設計したとき、それをデータベースに作るには英数字の物理名が必要です。日本語からデータベースとして安全な英語名を起こす作業は、地味に時間を食い、命名のセンスも人によってブレます。つまり「物理名→日本語」と「日本語→物理名」の両方向に翻訳の壁があるのです。ナヨセルはこの両方向を機能として持っています。

コネクタからのスキーマ移植

列定義を作るいちばん速い方法は、書かないことです。接続済みのサービスには列定義がすでに存在するので、それを丸ごと持ってくればいい——これが「スキーマ移植」です。操作は4ステップで終わります。

① コネクタを選ぶ——接続済みのサービスと同梱の公共データが同じ一覧に並びます
② リソースを選ぶ——オブジェクト・テーブルなど、サービスの階層をたどって対象を特定します（前回解説した2操作の正規化がここで効きます）
③ 列にチェックを入れる——列の一覧から必要なものだけ選びます。全選択もできます
④ 開いているテーブルに追加する——チェックした列が、いま編集中の主・副・関連テーブルの定義に足されます

スキーマ移植の4ステップ。コネクタを選び、リソースを選び、列にチェックを入れ、開いているテーブルへ追加する流れ図 — スキーマ移植の流れ。列定義は「書く」のではなく、元サービスから「持ってくる」

このとき裏側では、細かい配慮がいくつも走っています。元サービスが表示用のラベル（Salesforceの項目ラベルなど）を持っていれば、それも一緒にコピーして表示名の初期値にします。ラベルが「会社名(Name)」のようにAPI名込みの形式なら、括弧部分を取り除いてから使います。列名はデータベースとして安全な形——小文字・英数字とアンダースコアのみ・英字始まり——に自動整形され、すでに追加済みの列は「追加済み」と表示されて二重追加できません。移植のたびに人が気を付けることを、仕組みが先回りして潰してあります。

列を持たないデータ源のためには別の入り口があります。CSV・スプレッドシート系はファイルのヘッダ行から列を読み取り、どちらも使えない場合は手動定義です。つまり列定義の入り口は3つ——移植・ヘッダ読み取り・手動——で、どれで作っても同じテーブル定義に着地します。

ナヨセルのスキーマ編集画面。右側の「スキーマの移植（コネクタ・公共データ・CSV）」パネルでSalesforce環境の取引先(Account)オブジェクトを選び、列を選択して取り込みデータへ追加する。左側には移植済みの列が表示名・物理名・型の3列で並ぶ — コネクタからのスキーマ移植の実画面。移植元とオブジェクトを選ぶと列の一覧が現れ、チェックして追加するだけで表示名・物理名・型が揃う

日本語化の中身——分割してから訳す

移植で列は揃いました。次は日本語化です。ナヨセルの「物理名→表示名」変換は、単なる機械翻訳ではありません。物理名を翻訳エンジンにそのまま渡すと、billingcityのような連結された物理名で訳の精度が大きく落ちるからです。billingcityを1単語として訳そうとしても、辞書にそんな単語はありません。そこで変換を3段階に分けています。

① 単語分割——billingcityを「billing city」に、numberofemployeesを「number of employees」に分割します。アンダースコア区切りやキャメルケースは機械的に分割し、機械的に割れない連結語はAIが意味を読んで分割します。Salesforceカスタム項目の接尾辞（__c）はこの段階で取り除きます
② 翻訳——分割済みの英単語列を、翻訳エンジン（DeepL）で日本語に訳します。このとき「業務ユーザー向けの簡潔な表示名にする・IDなどの略語は残す」という文脈を添えて、「billing city→請求先市区町村」「number of employees→従業員数」のような訳語を引き出します
③ フォールバック——翻訳エンジンが英語のまま返してきた語（固有名詞まじりの列名など）だけを、AIが引き取って翻訳します

物理名billingcityがAIの単語分割でbilling cityになり、翻訳エンジンで請求先市区町村になる3段階パイプラインの図。訳し残しはAIがフォールバック翻訳する — 「分割してから訳す」パイプライン。連結語の分割はAI、翻訳の本線は翻訳エンジン、訳し残しだけAIが拾う

翻訳の本線は翻訳エンジン、AIは「分割」と「拾い残し」に限定する。同じ入力には同じ訳語が返る安定性を優先した役割分担。

なぜ全部AIに訳させないのか。理由は再現性です。翻訳エンジンは同じ入力に対してほぼ同じ訳語を返しますが、生成AIは同じ列名でも呼ぶたびに「請求先市区町村」「請求先の市」と揺れる可能性があります。列名は一度決めたら長く使う識別子なので、揺れない部品を本線に置き、AIは「連結語を意味で割る」「訳し残しを拾う」という、AIにしかできない部分だけに使う——という役割分担にしました。数十列をまとめて一括変換しても、待たされず、結果が安定します。

逆方向——表示名から物理名を作る

「表示名→物理名」の逆方向も、同じ思想で動きます。日本語の表示名「請求先市区町村」を、まずデータベース列名向けの文脈——冠詞を付けない・単数形を好む・IDなどの略語は残す——を添えて英語に訳し、それをデータベースとして安全な物理名に整形します。整形の規則は明確に決まっています。

英数字とアンダースコア以外の文字はすべて置き換え、小文字スネークケースにそろえる
数字始まりにならないよう英字始まりを保証する
長すぎる名前は上限で切り詰める（データベースの列名長制限より手前で止める）
同じテーブル内で名前が衝突したら自動で連番を付ける

この機能の使いどころは、現場主導の設計です。業務部門が「取り込みたい項目」を日本語で並べたExcelの設計メモから、そのまま物理テーブルを起こせます。従来はここでエンジニアが命名会議を挟む必要がありましたが、変換ボタン1つで「英語として意味が通り、規則が統一された物理名」の下書きが揃います。もちろん下書きなので、気に入らなければ手で直せます。1列ずつの変換ボタンと全列一括の変換ボタンの両方があり、一括変換は上書き前に確認を挟みます。

往復できることも重要です。物理名から表示名を起こし、表示名を直してから物理名を作り直す——どちらの方向にも同じ規則で変換できるので、「英語側と日本語側のどちらを正とするか」をプロジェクトの途中で切り替えても破綻しません。

型を6つに絞るという判断

列には型が必要です。ナヨセルの作業台で選べる型は、テキスト・数値・金額・真偽・日付・日時の6つだけです。データベースに詳しい方なら「精度指定は？　可変長と固定長は？」と思うかもしれませんが、意図的に絞っています。

理由は、作業台の型に求められる仕事が「格納の最適化」ではなく「比較のしかたの宣言」だからです。名寄せで型が効くのは、「この列は数値として比べる」「この列は日付として比べる」という比較の意味論を決める場面です。その用途に、バイト数の細かい違いは関係ありません。選択肢を6つに絞ることで、データベースに詳しくない人でも型を決められ、サービスごとに違う元の型（SalesforceのpicklistもPostgreSQLのvarcharも）を同じ抽象度に寄せられます。移植時には元の型から自動で対応する型を推定します。

設計の選択肢	利点	採らなかった理由／採った理由
DB固有の型をそのまま見せる	格納を細かく制御できる	現場が型を決められず、サービス間の型の違いが作業台に持ち込まれるため採らず
型なし（全部テキスト）	いちばん簡単	数値・日付の比較や検品が文字列比較になり、名寄せの品質が下がるため採らず
抽象型6つ（ナヨセル）	現場が決められる・比較の意味が明確	「比較のしかたの宣言」という型の本来の仕事に必要十分なため採用

安全装置もあります。列の削除や型の変更はデータに影響する破壊的変更なので、保存前に差分を検出して「列の削除: ◯◯（データも削除されます）」「型の変更: ◯◯（変換できない値はエラーになります）」と確認を挟みます。保存すると定義と物理テーブルが完全同期され、途中で失敗した場合は定義ごと巻き戻して、定義と実テーブルがズレた状態を残しません。

ナヨセルの場合——スキーマ編集画面の全体像

ここまでの部品は、1つのスキーマ編集画面に集まっています。左には主・副・関連のテーブルがタブで並び、開いたテーブルの列を「表示名・物理名・型」の3点セットで編集します。列ごとに表示名⇄物理名の変換ボタンがあり、全列一括のAI変換も使えます。右には移植パネルがあり、コネクタ・公共データ・CSVヘッダから、開いているテーブルへ列を流し込めます。

ここで付けた表示名は、この画面だけのものではありません。データブラウザの検索結果では表示名と物理名をワンタッチで切り替えられ、レポートや承認の画面でも人が読む場面では表示名が使われます。最初に一度だけ翻訳の壁を越えておけば、以降のすべての工程が日本語で回る——これがカラム名の日本語化を「品質保証の一部」と呼ぶ理由です。レビューに参加できる人が増えるほど、誤マージは見つかりやすくなります。

なお、スキーマ設計は導入支援（全プラン標準付帯・2ヶ月・50万円〜）の中心テーマのひとつです。「どの列を主テーブルに置き、何と突き合わせるか」から一緒に設計しますので、導入の流れもあわせてご覧ください。