2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@M_Ozu
in

AIに同じ質問をしたら、部署ごとに違う数字が返ってきた　― いま「オントロジー」と呼ばれているもの ―

2
Last updated at Posted at 2026-08-13

同じ質問を投げたのに、部署ごとに違う数字が返ってくる。しかも、どちらのAIも間違ってない。

生成AIを業務に入れた組織で、いま静かに起きている現象です。この記事では、その正体を解きほぐしたうえで、2025年くらいから主要ベンダーが揃って使い始めた「オントロジー」という言葉が、いま何を指し、技術的に何を作る話なのかを整理します。

この記事の立ち位置

オントロジーの技術スタック――URI から RDF、RDFS / OWL、推論、SPARQL、トリプルストアへと積み上がっていく話――は、すでに良質な解説がたくさんあります。この記事では、構文の書き方までは踏み込みません（用語が何を指すかだけ、2章で一度まとめて整理します）。

扱うのはその手前です。「なぜ今この言葉が戻ってきたのか」「業務のどこで効くのか」「そして誰がそれを書くのか」。コードは出てきますが、動かすためではなく、話を具体にするために置いています。

先に、この記事の要点を三つ

  1. 同じ質問なのに部署ごとに違う数字が返ってくるのは、AIの精度の問題ではありません。 言葉の意味を誰も書いていないだけです。だから、より賢いAIに入れ替えても直りません。
  2. 「言葉の意味を書き出しておく」という発想自体は、20年前からあります。 方向は正しかったのですが、当時は書く手間が見合わず、エンタープライズITの文脈ではあまり語られなくなりました。いま戻ってきたのは、AIが下書きを書けるようになり、同時に曖昧なままでは動いてくれない相手が業務に入ってきたからです。
  3. ただし、製品を導入すれば解決する話ではありません。 何をどう定義するかは業務側にしか決められず、誰が決め、誰が維持し続けるのかまで含めて初めて機能します。

1. その食い違いは、AIが来る前からあった

二つのチームが、同じ日に、まったく同じ一文をAIアシスタントに投げたとします。どちらも普段はSQLを書きません。DWHに繋がったAIに聞けば、クエリを組み立てて数字まで返してくれるからです。

営業チーム

-- 指示：「先月のアクティブ顧客の数を出して」
-- 参照可能：crm スキーマ

SELECT COUNT(DISTINCT cust_id)
FROM   crm.customer_master
WHERE  last_contact_at >= '2026-07-01';

-- → 820

経理チーム

-- 指示：「先月のアクティブ顧客の数を出して」
-- 参照可能：billing スキーマ

SELECT COUNT(DISTINCT client_no)
FROM   billing.invoice
WHERE  paid_at >= '2026-07-01'
  AND  amount > 0;

-- → 394

同じ一文。違うスキーマ。違うSQL。違う答え。どちらも一発で、それらしく返ってきた。

そして、この二つの数字が並んでどちらのAIがおかしいのか、という話になり、しばらく定義の議論が続き、意思決定はされないまま、「アクティブ顧客の定義を明確化する」というチケットだけが残ります。

どちらのAIもバグっていない

生成されたSQLは両方とも正しく動いています。違っていたのは「アクティブ顧客」という言葉が指すもので、そしてそれはどこにも書かれていなかった。

書かれていない以上、AIはその場に置かれた前提に従うしかありません。そして前提は、部署ごとに違いました。投げた一文は同じでも、その周りにあるものは同じではないからです。営業のアシスタントには営業の常識が、経理のアシスタントには経理の常識が、システムプロンプトや過去のやりとり、そして見えているスキーマという形で、すでに入っています。

  • 営業側の文脈では、顧客とはこれから接触する相手のことで、手元のスキーマには最終接触日があった
  • 経理側の文脈では、顧客とは金銭のやりとりが発生した相手のことで、手元のスキーマには入金日と金額があった

AIは推測したというより、与えられた前提どおりに実行しただけです。しかもどちらの実行も、その文脈の中では正しい。

ここが最初に押さえたい点です。

モデルをより賢いものに替えても、この食い違いは直りません。 賢いモデルは、与えられた前提をより忠実に、より綺麗なSQLで実行します。前提が食い違っている限り、答えも食い違ったままです。これはAIの精度の問題ではなく、意味が明示されていないという構造の問題です。

同じ会社が別のIDで管理されている

加えて、このシステムの例では同じ会社が別のIDで管理されているとします。

システム 識別子 社名の持ち方
CRM cust_id = C-0012 山田工業
会員基盤 user_id = 88213 ヤマダ工業(株)
請求システム client_no = BL-4471 山田工業株式会社

突き合わせるコードは、たいてい誰かが手作業で書いた変換表の上に載っていて、その更新者はもう分かりません。

人間はこの三つを見て「同じ会社ですね」と言えます。文脈で補完できるからです。しかしAIにはこの三つが別物に見えています。先ほどの二本のSQLが噛み合わなかった、もう一つの理由がこれです。

ここで気づきたいのは、意味はすでにどの組織にもあるということです。ないのではなく、書かれていない。人の頭の中と、変換用のExcelと、誰かが5年前に書いたクエリのWHERE句に、バラバラに散っている。それを一箇所に、機械が読める形で書き出そう――というのが、この記事のテーマである「意味の層」の話です。

2. なぜ今、各社が同じ言葉を使い始めたのか

2026年に入って、主要ベンダーが揃って「オントロジー」「セマンティックレイヤー」という言葉を前面に出し始めました。技術が成熟したから、という説明はあまり実態に合っていません。順序としては、Palantirの商業的成功がカテゴリを作り、各社がそこに追随したと見えます。

ただ、この会社の来歴を知らないと「AIで勢いのある会社」に見えてしまうので、そこだけ補足しておきます。Palantirの創業は2003年。当初の顧客は政府機関や情報機関で、扱う課題は「要件を書き出せない」種類のものでした。生成AIブームより20年近く前から存在する会社です。その同社が一貫して中核に据えてきたのが、データを現実の業務（ヒト・モノ・カネ・プロセス）と意味的に結びつける層、すなわちオントロジーでした。

オントロジーを軸にした事業を長年かけて作ってきたところに、生成AIという技術のほうが後から追いついてきた。AIを起点に意味の層へ降りてきたのではなく、意味の層の上にAIが乗った――順序が逆ではありません。

補足：源流は一つではない

いま「セマンティックレイヤー」と呼ばれているものは、単一の源流から広がったわけではありません。もう一つ、BIの指標定義から来た流れがあります。「売上とは何か」を各ダッシュボードで書き直さずに一箇所へ固定する、という発想で、こちらはメトリクス定義の系譜として独立に育ってきました。

業務そのものをモデル化しに行く流れと、指標の統制から入る流れ。出自の違う二つが、AIに正しく参照させるという同じ目的の下で近年合流しつつある、というのが実際の構図に近いはずです。この記事でオントロジーと呼んでいるのは前者ですが、あなたの現場で必要なのが後者だけ、ということも十分あり得ます。

ちなみに、FDEという役割もこの会社が作った

近年よく聞くようになった FDE（Forward Deployed Engineer） ――顧客組織の中に入り込み、顧客の実データと実システムに対して本番コードを書き、成果物ではなく成果に責任を持つエンジニア――という役割も、発祥はこの会社です。

そしてこれ、最近できた役割ではありません。 生成AIブームよりずっと前、2000年代の政府・情報機関向けの仕事の中から生まれています（正確な時期は資料によって2000年代半ばから2010年代初頭まで幅があります）。要件を事前に書き出せない顧客に対して、仕様書を渡して帰るのではなくエンジニアごと送り込むという選択でした。

その現場で積み上がったものが製品の形になり、いまのFoundryやオントロジーがある――と見ると、話の筋は通ります。オントロジーとFDEが同じ会社から出てきたのは、おそらく偶然ではありません。この点は、記事の最後にもう一度出てきます。

ただし、オントロジーという言葉は一度、聞かれなくなっている

ここで冷静になっておきたいのですが、オントロジーという語は2000年代のセマンティックウェブで一度広まり、その後しばらくエンタープライズITの表舞台では聞かれなくなりました（医療・バイオ・図書館情報学などでは継続して使われています）。当時の技術要素そのものは、今も残っています。表現力は当時から十分でした。

当時のスタックを、名前だけ押さえておく

以降で何度か出てくるので、ここで一度整理しておきます。構文は出しません。それぞれが何を担当していたかだけ掴めれば十分です。

┌──────────────────────────────────────────────┐
│ SPARQL     グラフをパターンで検索する          │
├──────────────────────────────────────────────┤
│ 推論       定義から、書いていない事実を導く    │
├──────────────────────────────────────────────┤
│ OWL        排他・推移など、込み入った制約      │  ← 意味づけ
│ RDFS       クラス階層・型・属性の定義域と値域  │
├──────────────────────────────────────────────┤
│ RDF        事実を「主語-述語-目的語」で表す    │  ← 事実の表現
├──────────────────────────────────────────────┤
│ URI        ものと関係に、一意な名前を与える    │  ← 識別
└──────────────────────────────────────────────┘
用語 何を担当していたか
URI 概念・関係・個体に、システムをまたいで衝突しない一意な名前を与える仕組み。1章の「同じ会社が三つのIDで管理されている」問題に対する、20年前の答えがこれです
RDF 事実を「主語 - 述語 - 目的語」の三つ組で表すデータモデル。文章ではなく、ノード間に張られた有向の辺だと捉えると腑に落ちます
RDFS RDFの上に、クラス階層（AはBの下位クラス）、型付け（個体xはクラスAに属する）、属性がどんな主語に使えてどんな値を取るか、を定義する語彙を足したもの
OWL RDFSより表現力の高い定義言語。クラス同士が排他である、この関係は推移的である、といった込み入った意味づけができる
推論 定義にもとづいて、明示されていない事実を導く操作。「猫は哺乳類」「哺乳類は動物」から「猫は動物」を得る、あれです
SPARQL できあがったグラフを、パターンマッチで検索する言語。SQLが表を検索するのに対し、こちらはグラフの形を検索します

この積み上げ自体は、今見てもよくできています。足を止めたのは表現力ではなく、記述コストでした。

同じ壁は、我々の業界だとMOF（Meta Object Facility）・メタモデル・OCL（Object Constraint Language／オブジェクト制約言語）の系譜でも起きています。たとえば「注文は明細を1件以上持つ」という一文を、OCLで正式に書くとこうなります。

-- 日本語で言えば「注文は明細を1件以上持つ」
context Order inv atLeastOneLineItem:
  self.lineItems->size() >= 1

-- 「注文の合計金額は、明細の単価×数量の総和と一致する」
context Order inv totalMatchesLineItems:
  self.total = self.lineItems->iterate(
      li : LineItem; acc : Real = 0 |
      acc + li.unitPrice * li.quantity)

-- 「プレミアム顧客には必ず専任担当が付く」
context Customer inv premiumHasManager:
  self.oclIsTypeOf(PremiumCustomer) implies
    self.oclAsType(PremiumCustomer)
        .dedicatedAccountManager->notEmpty()

-- …これを、全エンティティ・全制約について、手で書き切る

正確です。厳密です。曖昧さがありません。そして、誰も書きませんでした。

間違っていたのは構想ではなく分量です。業務ルールが数百あれば、この記述も数百必要になる。仕様が変われば全部追随する。書ける人は限られ、レビューできる人はもっと限られる。「そこまでやるならコードにIF文で書く」で終わってきたのが、この20年でした。

余談：なぜOCLなんてマイナーな記法を例に出したのか

当時MDA（モデル駆動アーキテクチャ）やメタモデルにドハマりしていた、筆者の趣味です。

念のため書いておくと、あの頃も「モデルさえきちんと書けば、あとは勝手に動く」なんて思っていたわけではありません。むしろ悩んでいたのは粒度でした。正規化を進めれば構造は整理されますが、意味が正確になるわけではありません。その一方で、細かく割るほど処理は重くなり、扱いも面倒になる。どこまで割るのが妥当で、どこから先は割りすぎなのか。適切で使いやすい粒度はどこにあるのか。そればかり試行錯誤していた記憶があります。

というのも、当時の障害は「書く手間が重い」だけではなかったからです。書けたとしても、動かすと重かった。 正確に定義したモデルほど参照も変換も増えて、出来上がったものが遅くて使い物にならない。正しさと実用性が両立しない、というのが実感としてありました。

そして今のオントロジーは、当時のMDAとはアプローチがだいぶ違います。MDAはモデルから実装を生成する話で、モデルは実装の上流にありました。一方、今のオントロジーは何も生成しません。実装はすでに動いていて、それを止めずに意味だけを上から束ね、AIに参照させる。方向としてはむしろ逆に近い。だからモデルが完全である必要もなく、「アクティブ顧客」の一語だけ定義しても、その一語については機能します。

それでも、粒度の問題だけは当時のまま残っています。 どこまで厳密に定義するか、どこから先は割に合わないか。20年経って、道具も相手も変わったのに、悩みどころは同じ場所にある。この話は記事の最後にもう一度出てきます。

では、何が変わったのか

変化点は二つで、供給側と需要側の両方です。

記述コストが下がった。 LLMが下書きを書けるようになりました。障害が表現力ではなく分量だった以上、ここが直接効きます。

記述の用途ができた。 意味が曖昧でも人間が補完すれば動いた時代と違い、業務に入ってくるAIエージェントは補完してくれません。

20年前に諦めた理由の両方が、ほぼ同時に解消されつつあります。

ただし、解消されたのは「書けない」ほうだけです。余談で触れたもう一つの障害――正確に作るほど重くなる――には、LLMは何もしていません。意味の層を一枚挟むということは、参照が一段増えるということなので、構造的には遅くなる方向に効きます。

「一過性のバズワードではないか」という疑念について

ここまでの話を聞くと、Palantirの成功に便乗した一時的な流行ではないか、という疑いが当然出てきます。その疑いは健全ですが、次の三点は流行とは別の理由で説明がつきます。

観点 疑い 流行とは独立している理由
問題の古さ 2026年に急に言われ出した話ではないか 冒頭の会議は、生成AIが登場する前から各社で起きていた。語彙が新しいだけで、対象は古い
条件の変化 技術的には20年前と同じでは 障害は表現力ではなく分量だった。下書きが自動生成できる状態から、再び手書きに戻る理由が見当たらない
需要側 結局、使う人がいないのでは 曖昧なままでは動かない相手（AIエージェント）が、業務の中で今後も増え続ける

加えて、Snowflake・Salesforce・dbt Labsらが2025年9月に立ち上げた OSI（Open Semantic Interchange） のように、各社が個別に囲い込むのではなく標準化に動いている点も、単一ベンダーのマーケティングではないことの傍証になります。

ただし**「オントロジー」という呼び名のほうは、数年後には別の言葉に置き換わっているかもしれません。** 名前は変わり得る。問題と条件は残る。この二つを分けて評価するのが安全だと思います。

3. 技術的には何を作る話なのか

概念の話から、実装の話に降ります。一言でいえば、生データとAIアプリケーションの間に、実行可能なスキーマを一枚挟むという話です。

┌─────────────────────────────────────────────┐
│ CONSUMER  AIエージェント / BI / 業務アプリ    │
│           「先月のアクティブ顧客は？」と問う側 │
└─────────────────────────────────────────────┘
                    ↕ 参照
┌─────────────────────────────────────────────┐
│ SEMANTIC  意味の層（オントロジー）             │
│           用語の正規化 / 関係の明示            │
│           継承と分類 / 制約                    │
│           ★ 定義はここにしか置かない           │
└─────────────────────────────────────────────┘
                    ↕ バインド
┌─────────────────────────────────────────────┐
│ RAW       生データ（CRM / 基幹 / ログ / 文書） │
│           cust_id / user_id / client_no       │
└─────────────────────────────────────────────┘

重要なのは、これがドキュメントではなく実行されるという点です。「データ辞書・用語集」というExcelを作る話とは違います。定義がクエリの実行経路に組み込まれていて、定義に反するものは通らない。そこが従来のデータカタログとの決定的な差です。

書くとこういう見た目になります（記法は製品ごとに違うので、あくまでイメージです）。

entity Customer:
  properties:
    customer_id:   { required: true }
    registered_at: { required: true, type: date }

  # 冒頭のあの議論を、ここで一度だけ決着させる
  metric ActiveCustomer:
    definition: "直近3ヶ月に入金実績がある顧客"

relationship places:
  from: Customer
  to:   Order
  constraint: "Supplier は places を持てない"

binding Customer:
  crm.customer_master.cust_id
  billing.invoice.client_no    # 同一実体として束ねる
  member.user_account.user_id

定義と、実データへの結びつけが、同じ一箇所に並ぶのがポイントです。

構成要素と、勘所

オントロジー自体は、クラス（存在するものの種類）、インスタンス（個別の実体）、プロパティ（属性）、関係（実体どうしの繋がり）、そして制約（起こり得ないことの明示）から成ります。

勘所は最後の制約です。人間なら言われるまでもなく分かっていることでも、書かなければ機械の世界には存在しません。「仕入先が発注することはない」と書いていないシステムは、仕入先が発注した経路を平然と返してきます。

用語の整理（この記事で必要な区別はこれだけ）

  • オントロジー ＝ 何が存在し、どう繋がり、何は起こり得ないかを定めた設計図
  • ナレッジグラフ ＝ その設計図に従って実データを流し込んだ結果できる、実体と関係のネットワーク

両者はしばしば混同されますが、設計図と、それを具現化したものの関係です。

グラフDBが加える三つの層

素のグラフ構造は、ノードとエッジがあるだけです。そこにオントロジーを載せるとは、次の三つを足すことを指します。

層 内容 これが無いと起きること
型システム すべてのノードにラベル、すべてのエッジに型を与える（顧客／製品／拠点、購入した／出荷先／製造元） 同じ「顧客」がシステムごとに別物として増殖する
プロパティ制約 型ごとに必須項目と任意項目を定める（顧客は顧客IDと登録日が必須、メールは任意） 欠損が下流で発覚し、集計のたびに個別対処が要る
関係制約 どの型とどの型の間に、どの関係が存在し得るかを定める（顧客は発注できるが、仕入先はできない） あり得ない経路をAIが自信満々に辿り、それらしい答えを返す

気づいたかもしれませんが、これは再登場です

この三つを、2章で整理した用語に並べ直すとこうなります。

いまの言い方 20年前の担当
型システム（ノードのラベル、エッジの型） RDFS のクラス定義・型付け（subClassOf / type にあたるもの）
プロパティ制約（必須・任意、値の型） RDFS の定義域・値域（domain / range にあたるもの）
関係制約（この型とこの型の間にこの関係は張れない） OWL の排他・推移といった、込み入った意味づけ

新しい概念が生まれたというより、同じことが別の名前で再登場している、というのが実際のところです。2章で「一度聞かれなくなった言葉が戻ってきた」と書いたのは、こういう意味でもあります。

ただし、当時とそのまま同じではありません。違いは二つあります。

ひとつは置き場所。当時は三つ組をトリプルストアに溜め込む形が中心でしたが、現代の製品の多くは、既存のテーブルやDWHはそのままにして、その上に定義を束ねる方式を取ります。データを移さずに意味だけ載せる、という発想です。

もうひとつは推論の扱い。OWLの世界では、定義から書いていない事実を導く「推論」が主役でした。一方いまの実務では、そこはあまり期待されていません。やっているのは推論というより検証です。書かれていないことを導き出すより、書かれた制約に反していないかを確かめるほうに寄っている。AIが辿ろうとした経路が定義上あり得るかを見る、という使い方が中心です。

強制のタイミングは二つある

この三層は、書き込み時に弾くこともできれば、クエリ時に検証することもできます。前者は入口を固くする代わりに、既存システムからの取り込みが止まりやすい。後者は取り込みは通るが、汚れたまま溜まる。

製品ごとにどちらに寄せているかが違い、これが各社の設計思想の差にほぼ直結します。

リレーショナルでは不可能かというと、そうではありません。実際、主要なクラウドデータ基盤の実装はテーブルの上に意味の層を定義する方式です。

グラフが有利になるのは、「A社がB社を保有、B社がC社を保有」から「A社はC社を間接保有」を導くような、多段の関係を辿る問いが中心になる場合です。逆に言えば、用語定義と派生ルールを統制したいだけなら、数十億ノード規模の基盤は必ずしも要りません。

なお、この記事ではSQLとデータ基盤を例に説明していますが、これはいちばん短く示せる例だからであって、この構造が現れる場所はそこに限りません。ある言葉が複数のシステムをまたいで使われ、かつ出てきた答えを誰かが説明しなければならない――この二つが揃えば、扱う対象がテーブルであれ、文書であれ、設備や工程であれ、同じ問題が同じ形で立ち上がります。

冒頭の営業の解釈と経理の解釈は、どっちが正しかったのか

ここで1章に戻ります。**答えは「どちらも正しい」で、そして「どちらも名前を持っていなかった」**です。曖昧だったのは、アクティブ顧客という一語に二つの意味が乗っていたことであって、片方が誤りだったわけではありません。

Before ― 一語しかなかった

数字 中身
820 営業のAIが従った前提
394 経理のAIが従った前提

どちらも、名前を持っていない。

After ― 名前が二つに分かれる

数字 名前 定義
394 ActiveCustomer 直近3ヶ月に入金実績がある顧客
820 ContactedCustomer 直近3ヶ月に接点があった顧客

820という数字は消えません。名前が変わっただけです。営業がその数字を使いたければ、これからは正式な名前で呼べばいい。

ここを取り違えて「定義を一本化して片方を捨てる」と説明すると、定義権を握った部門が勝つ仕組みに見えます。そう見えた時点で、この手の取り組みは現場の支持を失います。減らすのは数字ではなく、曖昧さです。

そもそも、なぜ二つの定義が生まれたのか

ここを掘ると、話の底が見えます。

  • 営業がアクティブ顧客を知りたかったのは、次に誰へアプローチするかを決めるため
  • 経理が知りたかったのは、その月の実績を締めるため

目的が違えば、必要な定義も当然違う。

定義は語からは決まらず、用途から決まります。
「アクティブ顧客の正しい定義は何か」という問いには答えがなく、「何のためにその数を知りたいのか」を先に決めないと、定義は書けません。

そう考えると、その定義を決められるのが誰なのかも見えてきます。その用途に責任を持っている人であって、技術的にモデルを書ける人ではありません。ここは仕組みの外側の話で、どんな製品を入れても代わりにやってはくれない部分です。

そして、どちらの定義も決めたのはAIではありません。 AIがやったのは、決まった定義を参照して正しいSQLを組み立てたことだけ。変わったのはモデルの賢さではなく、モデルが何を参照するかです。

ここで期待を一段下げておきます。

ここまで見ると、意味の層を入れればAIは嘘をつかなくなるように見えます。そこまでは言えません。 これは定義次第の仕組みです。定義されていない問いに対しては何も起きませんし、定義そのものが間違っていれば、AIはその間違いを忠実に、しかも前より自信を持って返してきます。

つまり精度を決めるのは、モデルの性能ではなく定義の書き方と、その後の運用管理のほうです。

そしてもう一つ、正しさとは別の軸で速度の問題があります。 どれだけ正確に動いても、遅くて使い物にならなければ、誰も使いません。20年前のMDAが躓いたのも、実はここが半分でした。当時と違ってカラムナや実体化ビューやキャッシュでどうにかできる領域は広がっていますが、問題が消えたわけではなく、どこでコストを払うかの選択に変わっただけです。

前節の「書き込み時か、クエリ時か」は、その選択そのものでもあります。書き込み時に固めれば参照は軽くなるが、取り込みが止まりやすい。クエリ時に検証すれば取り込みは通るが、問い合わせのたびにコストを払う。設計思想の差であると同時に、重さをどこに寄せるかの差です。そして余談で書いた粒度の悩み――細かく割るほど整理はされるが、辿る回数が増えて重くなる――も、この構造にそのまま残っています。

まとめ ― 器は買えるが、中身は買えない

この領域の製品は、器としてはよく出来ています。しかしどれも、その意味の層を誰が書き、誰が決め、誰が維持するのかには答えていません。 それは製品の機能不足ではなく、そもそも製品が引き受けられる種類の仕事ではないからです。

ここで、2章に出てきたFDEの話が戻ってきます。意味の層は、誰かが顧客の業務の中に入って書くしかない――Palantirはそれを最初から前提にして、書く人ごと事業に組み込んでいた、と読めます。

この記事の要点

同じ問いに違う答えが返るのは、AIの精度ではなく意味が書かれていないことが原因。だからモデルを替えても直りません。意味の層は、その未記述を実行可能な形で埋める仕組みですが、器を導入すれば意味の層が適切に出来上がるわけではありません。

効いてくるのは、誰が書き、誰が決め、誰が維持し続けるのかを決められるかどうかです。器は手に入りますが、中身は手に入りません。

で、それって結構しんどくないですか

ここまで書いてきて思ったんですが、この「意味の層を書いて、維持する」という仕事、想像するとかなり大変です。

必要になりそうなものを並べるとこうなります。

  • 業務が分かること。 「アクティブ顧客」の裏に二つの目的があると気づけないと、そもそも定義が一本に潰れます
  • モデルに落とせること。 業務の話を、型と関係と制約という形に翻訳する作業。これは普通にエンジニアリングです
  • どこまで厳密にやるか決めるセンス。 OCLの例が示したとおり、厳密さを上げすぎると誰も書かなくなる。緩すぎるとAIが好き勝手に解釈する。2章の余談で書いた粒度の悩みが、そっくりそのまま戻ってくる部分です。この匙加減に正解はありません
  • 調整して、説明できること。 冒頭の営業と経理、どちらの定義も殺さずに名前を分ける――あれを実際にやろうとすると、両部門に話を通して納得してもらう必要があります

四つ目が一番きつい気がします。技術的には正しい設計でも、「なんで経理の言い分が通ってるんだ」と思われた時点で運用が止まるので。定義を決める作業は、けっこうな部分が政治です。

しかも、一度書いて終わりではありません。業務が変われば定義も変わる。組織が変われば決める人も変わる。放っておけば、また誰かのExcelに意味が逃げていきます。

それでも、これは今後のエンジニアの仕事の一つになっていくんだろうなと思っています。定義を書き下ろす作業そのものは、LLMがかなり手伝えるようになりました。20年前に諦めた理由が消えたのはそこです。でも、何をどう定義するかを決める部分は残ります。そして、そこでの性能――決める側の力量そのものが、問われるようになります。

業務を聞き取って、モデルに落として、関係者に説明して合意を取り、変わったら直す。字面だけ見ると地味ですが、上流から下流まで通しで見ないとできない仕事でもあります。

参考

概念の出どころ

FDE ― 役割の発祥

標準化の動き

この記事は、実装の手順ではなく捉え方に絞って構成しています。RDF/OWLの記法やグラフアルゴリズムといった技術的な深掘りは割愛しています。文中の企業・製品・時期に関する記述は執筆時点（2026年8月）のものです。コード例および数値はすべて説明のための架空のものであり、特定の企業・システムを指すものではありません。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?