生成AIブームという名の「EUC地獄」の再来――DIKWピラミッドから見る、組織知の構造的崩壊

※本稿は同タイトルの記事として、Zennで2026年05月24日付けで公開されていたものを移行した。移行元は本稿のリンクのみ残し空になっている。

概要

昨今、全社的な生成AI（LLM）の導入や、RAG（検索拡張生成）を用いた社内ナレッジの集約が急速に進められている。しかし、エンタープライズアーキテクチャ（EA）の歴史的変遷から俯瞰すれば、現在のAIブームは20年前に企業情報システムを機能不全に陥れた「EUC（エンドユーザコンピューティング）地獄」の構造的反復に過ぎない。本稿では、情報工学におけるDIKWピラミッドの視点から、LLM利用がもたらす「コンテキストの私有化」の病理を特定し、DMBOKとDDD（ドメイン駆動設計）の融合によるデータガバナンスの再構築を論じる。

1. EUC地獄の回顧：データモデルの分裂とサイロ化

かつてのEUC問題の本質は、情報システム部門のガバナンス外で現場が各自のローカル環境（Excel/Access）にロジックを組み込んだ結果、データモデルがサイロ化した点にある。

この構造はまず、顧客定義や商品コードといった「マスターデータ」の分裂を引き起こした。マスターが分裂すれば、それに紐づく売上実績やKPIなどの「トランザクションデータ」も部署ごとに異なる数字を叩き出す。結果として、全社における「数字の真実（Single Source of Truth）」が失われ、企業の意思決定層はデータの整合性を担保する機能を喪失した。これがEUC地獄の構造である。

2. DIKWピラミッドで解き明かす「AIの質の悪さ」

現在の生成AI利用は、このEUC問題をさらに高次のレイヤーにおいて、より深刻な形で反復している。これを情報工学におけるDIKWピラミッド（Data → Information → Knowledge → Wisdom）の階層論で捉え直す。

• 野良Excel（過去のEUC）： 破壊したのはピラミッドの下層である「Data（単なる数値）」と「Information（集計された情報）」であった。「数字が合わない」という物理的な不整合に留まる。

• 孤立したプロンプト環境（現在のEUC）： LLMが生成し、かつブラックボックス化するのは、ピラミッドの上層である「Knowledge（知識）」と「Wisdom（知恵・判断理由）」である。

現場の担当者が、社内で孤立したプロンプト環境（ローカルに閉じたLLMの利用）において業務を完結させる際、「なぜその判断に至ったのか」「どの社内情報を参照し、どう解釈したのか」という「コンテキスト（Wisdomに至る文脈）」そのものが、個人のプロンプト履歴の中に私有化される。

結果（アウトプットとしてのテキスト）だけが共有ドライブに残り、そこに到達するまでの意味構造（プロセス）は組織に還元されない。上層のKnowledgeやWisdomが局所的に生成・汚染されるため、かつてのデータ不整合よりも組織に与えるダメージは深く、リカバリは困難を極める。

3. パラドックス：個人の生産性最適化が、組織知を分解する

アーキテクチャの視点から直視すべき危機は、「AIが仕事を奪うか」ではなく、「AIが組織の知識基盤を分解（Decompose）する」というパラドックスである。

個人の作業効率（生産性）は、LLMによって劇的に向上する。しかし、各人が孤立したAIアシスタントとだけ対話して業務を完結させるようになれば、組織というネットワークに「判断のプロセス」が流れなくなる。個人最適の追求が、全社データ資産（ナレッジ）の破壊を招く。これが、現在のAI導入が抱える構造的矛盾である。

4. 「とりあえずRAG」の欺瞞：ドメイン間の意味的乖離

現在のエンタープライズIT市場では、社内の仕様書や規程のPDFをデータクレンジングもせずにそのままベクトルDB（AI用の検索データベース）に放り込み、社内専用AIを仕立て上げる「安易なRAG（検索拡張生成）構築」が横行している。

このアプローチが決定的に見落としているのは、ドメイン（部門・文脈）ごとの意味論（セマンティック）の乖離である。

例えば、「顧客」という一見単純な概念であっても、ドメインが変わればその定義は一変する。

• 営業ドメイン： 将来的に契約の可能性がある「見込み客」を含む。

• 経理ドメイン： 与信審査を通過し、実際に請求・入金が発生する「厳格な取引対象」のみを指す。

これらの定義の違いを整理せず、共通のベクトル空間に全社データを乱雑に突っ込んだRAGは、営業のコンテキストで書かれたドキュメントを経理のコンテキストに誤接続する。結果として、AIは「もっともらしいが、業務上は致命的なバグ（ハルシネーション）」を量産することになる。概念データモデルなきAI利用は、データの私有化を加速させるだけでなく、組織内の意味定義の崩壊を招く。

5. DMBOKとDDDの両輪：意味の統合と変換規則（コンテキストマッピング）

AIに正しい「コンテキスト」を理解させ、エンタープライズITとして成立させるためには、トップダウンのデータガバナンス（DMBOK）と、ボトムアップのドメインモデリング（DDD）の両輪による統制が不可欠である。

1. 全社の共通語彙を統制する「DMBOK」
   DAMAが提唱するDMBOK（データマネジメント知識体系）に基づき、ビジネスグロッサリ（用語定義集）やメタデータ、MDMを整備する。これは「AIに全社の正しいマスターデータのセマンティックを教え込む」ための、共通言語の土台となる。

2. 境界の定義と変換規則を確立する「DDD」
   共通語彙の定義だけでは、各部門の具体的な業務ロジックは扱えない。ここで、現場のモデリング手法であるDDD（ドメイン駆動設計）の知見が必要となる。
   DDDにおける「境界づけられたコンテキスト（Bounded Context）」を用い、各ドメイン（営業・経理など）ごとに概念が成立する境界線を明確に引く。その上で、ドメイン間でデータが往来する際の「変換規則（コンテキストマッピング）」をシステム構造として確立する。

DMBOKによって全社の「意味のコア」をシリアライズし、DDDによってドメインごとの「境界と変換規則」をカプセル化する。この古典的かつ実質的なデータモデリングの二層構造（アーキテクチャ）を確立しない限り、どれほど高性能なLLMを導入しようとも、システムが組織の共有知として機能することはない。

おわりに

歴史は繰り返す。生成AIは強力なツールだが、それは同時に「個人と組織の知識の分断」を加速させる諸刃の剣である。

表層的なセキュリティやハルシネーション対策に目を奪われている場合ではない。今すぐ、全社の概念データモデルを引き直し、ドメイン間の変換規則をシステム的に整備するという、泥臭いデータガバナンスに回帰すべきである。

20年前の「野良Excel」の敗戦構造から、現代のアーキテクチャはいい加減、学ぶべきである。