「複数の業務システムをまとめて、データを横断で見られるようにしたい」——DX を進めたい中小企業から、よく受ける相談です。ところが、いざ着手すると最初の数週間は新しいシステムを作る話に進みません。代わりに、こんな問いの前で立ち止まります。「この『顧客』は、契約済みの会社のことですか、それとも見込み客も含みますか」。営業部門と経理部門で、同じ「顧客数」という言葉が違う数を指している。受発注システムでは一つの取引先が、部署ごとに別々の ID で三重に登録されている。データを統合する前に、そもそも言葉と意味が揃っていないのです。
この問題を正面から論じているのが、Zenn の データエンジニアこそ組織のオントロジーに向き合うべき です。データを「AI で扱える状態（AI-Ready）」にしてきた実践の先で、最後に残る壁が組織のオントロジー——その組織が使う言葉と概念の体系をそろえること——だという指摘です。受託でデータ基盤や業務システムを作る立場では、これは技術選定より前にある、いちばん地味で、いちばん成否を分ける工程だと考えています。
「データを統合したい」が必ずつまずく場所
複数システムの統合がつまずくのは、技術的につなげられないからではありません。つなげた結果が信用できないからです。
たとえば「売上」。受注ベースで数える部署、入金ベースで数える部署、税込・税抜が混在する帳票。これらを機械的に足し合わせても、出てくる数字は誰も信じない「合計らしきもの」にしかなりません。「取引先」も同様です。表記ゆれ（株式会社の有無、全角半角）、合併や社名変更の履歴、同名の別会社。名寄せをしないままデータを集めると、一つの会社が複数に分裂したまま集計され、実態とずれます。
ここで起きているのは、データの量や形式の問題ではなく、意味の問題です。それぞれのシステムは、それぞれの部署にとっては正しく動いています。問題は、部署をまたいだ瞬間に「同じ言葉が違うものを指し、違う言葉が同じものを指す」状態が露わになることです。非構造のデータ（PDF やメール）を取り込む話とも地続きで、その観点は 非構造化データを LLM で構造化する受託（GH Media） でも扱っています。
オントロジーとは「組織の言葉をそろえる」こと
オントロジーというと難しく聞こえますが、受託の文脈でやることは具体的です。その組織で使われる言葉が、それぞれ「何を指すか」「他の言葉とどう関係するか」を一つに定めることです。
「顧客とは、契約が有効な法人を指す。見込み客は『リード』と呼んで区別する」「取引先は法人単位で一意の ID を持ち、部署や担当者はその下にぶら下がる」——こうした定義を、関係者で合意して文書とデータ構造の両方に落とします。大切なのは、これを情報システム部門が一人で決めるのではなく、実際にその言葉を使っている現場（営業・経理・現場部門）を巻き込んで合意することです。技術的に正しいモデルより、現場が「確かにそれで合っている」と納得できる定義のほうが、長く使われます。
| よくあるズレ | 放置するとどうなるか | オントロジーで決めること |
|---|---|---|
| 「顧客」の範囲が部署で違う | 集計が一致せず数字を信じられない | 顧客 / 見込み客の定義と境界 |
| 取引先が重複登録される | 売上が分散し実態が見えない | 法人を一意にする ID と名寄せ規則 |
| ステータスの呼び方が乱立 | 連携のたびに変換地獄になる | 状態の正式名称と遷移の定義 |
状態（ステータス）の設計は、削除や終了の扱いを含めてデータ品質を大きく左右します。具体的なテーブル設計の勘所は 論理削除をやめて状態テーブルで設計し直す受託（GH Media） も参考になります。
なぜ今、これが重要なのか
「言葉をそろえる」こと自体は昔から大事でした。それが 2026 年に一段と切実になったのは、AI に業務データを扱わせるようになったからです。
人間どうしなら、「この『顧客数』は見込みも入ってる数字ね」と暗黙に補正できます。AI にはそれができません。定義が曖昧なデータをそのまま渡せば、AI は曖昧なまま、しかし自信ありげに間違った答えを返します。「先月の顧客あたり売上は」と尋ねて返ってきた数字が、実は分母と分子で別の「顧客」を使っていた——こうした事故は、データの意味がそろっていない組織で必ず起きます。AI 活用の精度は、モデルの賢さより前に、渡すデータの意味の明確さで決まるのです。エンタープライズ規模のデータ統合の全体像は エンタープライズデータ統合の受託設計（GH Media） も併読してください。
受託でどう進めるか
弊社の受託では、いきなり統合基盤や新システムを作らず、意味をそろえる工程を独立した最初のステップとして置きます。
最初にやるのは、現状のヒアリングと用語の棚卸しです。各部署が使っている言葉を集め、「同じ言葉で違うもの」「違う言葉で同じもの」を洗い出して一覧にします。次に、関係者を集めて定義を一つに合意し、用語集とデータモデルに落とします。ここまでは、まだ大きな開発をしません。あるサービス業のクライアントでは、この用語の棚卸しだけで「顧客」が部署ごとに三通りの意味で使われていたことが判明し、統合システムの要件そのものが大きく変わりました。先に意味をそろえたから、作るべきものを正しく定義できたわけです。
そのうえで、既存データの名寄せ・マスタ統一を段階的に進め、最後にシステム統合や活用基盤を載せます。順番を守ることが肝心で、意味の合意を飛ばして基盤から作ると、後で必ず作り直しになります。「作らない・後で作る」を含めてスコープを見極める姿勢は 過剰開発を防ぐ要件・スコープ設計の受託（GH Media） とも共通します。
ハマりやすい落とし穴
第一に、完璧な定義を最初に作ろうとして止まること。全社のあらゆる言葉を一度にそろえるのは不可能なので、まず統合したい範囲（売上と顧客など）に絞って合意します。第二に、情報システム部門だけで決めること。現場が使っていない定義は守られず、形だけのルールになります。第三に、用語集を作って終わりにすること。定義はデータ構造とシステムの両方に反映して初めて効きます。文書とコードを切り離さないことが重要です。
まとめ — 作る前に「言葉」をそろえる
データ活用やシステム統合がうまくいかない原因の多くは、技術ではなく「同じ言葉で違うものを指している」という意味のズレにあります。とくに AI に業務データを扱わせるなら、この土台の曖昧さは、そのまま自信ありげな誤答に変わります。受託では、基盤やシステムを作る前に、組織の言葉と意味をそろえる「オントロジー設計」を独立した最初の工程として置き、作るべきものを正しく定義してから手を動かします。
「部署で数字が合わない」「データを統合したいが何から手をつけるべきか分からない」というご相談は お問い合わせフォーム からお気軽にどうぞ。用語の棚卸しから始められます。
