AI時代のデータ管理

• 生成AIが信頼できるデータに基づいて動作しなければ、分析結果も信頼しにくくなるため、データ管理は技術支援業務から戦略的な中核機能へと格上げされた
• 初期のアプリケーション開発者がデータ構造まで担当していた段階から、データベース設計者/管理者、CIO、CDOへと役割が分化し、データの完全性と企業全体での一貫した理解が主要課題となった
• 構造化データではデータモデルとデータベースを直接修正するが、生成AI環境ではLLMに入力されるテキストを選別・精製する形で間接的に制御する
• 非構造化テキストには従来のデータモデルの代わりにオントロジー/分類体系が必要であり、これを企業論理データモデル（ELDM）と結合し、継続的に更新する必要がある
• データが複数のシステム/PC/インターネットに分散するにつれ、物理的な集中化は不可能になり、企業レベルの意味をELDMで統合する意味論的な集中化が重要になっている

---

アプリケーション開発業務から始まったデータ管理

• 初期のコンピュータシステムでは、アプリケーション開発者が要件収集、方法論の遵守、プログラミング、テストに加えて、システムが使用するデータとその構造も定義していた
• データ設計は独立した企業機能ではなく、開発プロセスに含まれる複数の作業の1つだった

トランザクション処理とデータベース専門職の登場

• トランザクション処理システムが普及するにつれ、応答時間、システム可用性、トランザクション実行の完全性をデータベース設計に反映する必要があった
• こうした要件を専門的に扱うデータベース設計者が登場し、データ管理が独立した業務として認識され始めた
• トランザクション処理データベースが急増すると、複数のデータベースを統制・調整するデータベース管理者が必要になった

データ完全性の問題とデータウェアハウス

• 相互に接続された多数のアプリケーションに同じデータ要素が繰り返し保存されることで、場所ごとに異なる値を持つ問題が発生した
• 企業の問題は、データを保有することから、どのデータを信頼すべきかを判断することへと変わった
• アプリケーションや技術を追加するだけでは完全性の問題は解決されず、むしろ問題を拡大し加速させた
• 技術的な修正ではなく、運用データと分析データを分離するアーキテクチャ上の解決策が必要になり、その結果データウェアハウスが登場した

データモデルと構造化データ環境

• 運用データを分析データとデータウェアハウスへ変換するには、現在存在する、または今後必要になるデータ型を抽象化したデータモデルが必要である
• 運用システムとデータウェアハウスは、各レコードの形式は同じで内容だけが異なる構造化データ環境で構成される
• アプリケーション、データベース、トランザクション処理データベースの構造化データは、データベース管理システム（DBMS）で管理される
• トランザクションシステムの障害がATMや航空予約システムのような実業務と顧客に直接影響を与えるようになり、正確で安定したシステムとデータ管理の価値が高まった

構造化データ管理者の業務

• データモデルを構築した後、経済状況、競争、技術、法律、市場の変化に合わせて継続的に維持・修正する
• データベース設計では正規化の原則に従いながら、トランザクション処理性能のために必要な範囲で非正規化を適用する
  • データ管理者は正規化と非正規化の間で、システムの目標と性能要件を調整する
• データモデルに基づいてデータベースを定義するDDLを作成する
• トランザクション処理機器がいつ容量の限界に達するかを予測するキャパシティプランニングを行う
• データベースの活動とデータ増加量を継続的に監視する
• 問題が見つかると、該当するデータモデルやデータベースに直接アクセスして修正する直接制御方式を使う

非構造化/テキストデータの拡大

• 企業には構造化データだけでなく広範な非構造化/テキストデータが存在し、企業データの最大90%がテキストだという推定もある
• 重要な企業情報の相当部分がテキスト形式で存在するため、データ管理組織はこれもあわせて管理する必要がある
• 構造化データとテキストデータは、構造と管理方法が根本的に異なる

テキスト環境におけるオントロジーと分類体系

• テキスト環境には、従来の構造化データモデルをそのまま適用することは難しい
• 構造化データでデータモデルが担う役割を、テキスト環境では**オントロジー/分類体系（ontology/taxonomy）**が担う
• 2つのモデルは対応する役割を持つが、構造と管理手法は大きく異なる
• 構造化データのモデリングと管理技術をテキストにそのまま適用することは適切ではなく、実質的な成果もほとんど生まない

LLM入力テキストの選別と精製

• 生成AI環境で最も重要なデータ管理業務は、原文テキストがLLMに入る前に検討することである
• 企業業務と関係のない不要なテキストがLLMに流入しないよう除去する必要がある
• 不要なテキストを除去すると、クエリを実行するたびに処理すべきデータが減り、コストを削減できる
• 業務関連テキストだけを残せば、LLMが何を表現し扱うのか、その範囲が明確になる

ELDMと構造化/非構造化データの接続

• 生成AI環境のデータ管理者は、オントロジー/分類体系を企業全体の**ELDM（Enterprise Logical Data Model）**と結合しなければならない
• ELDMは、従来の構造化データモデルとテキスト環境のオントロジー/分類体系を統合するために使われる
• 企業の業務要件が変われば、オントロジー/分類体系もあわせて更新する必要がある

外部テキストの収集と継続的な保守

• インターネットのような情報源から、広範な原文テキストをまず選択する必要がある
• その後、選択されたテキストから企業業務に関連するデータを再度絞り込む2段階の選別プロセスが続く
• 業務環境と世界情勢は絶えず変化するため、オントロジー/分類体系を継続的に監視・管理する必要がある
• 変化した条件と分類体系が互いに一致するよう、反復的な保守が必要である

LLMに対する間接制御

• 構造化データ管理者はデータモデルとデータベースを直接変更できるが、生成AI環境ではLLM自体を同じ方法で直接制御することはできない
• 生成AIの結果を制御する手段は、LLMにどのテキストを入力するかを管理することである
• したがって生成AIのデータ管理は、直接修正ではなく、入力データの選択と精製を通じた間接制御に近い

企業組織におけるデータ管理の役割の変化

• 初期には、データ管理はシステム開発者が行う複数の作業の1つであり、別個の企業組織や職務はなかった
• トランザクション処理が重要になるにつれ、データベース設計が独立した業務として分離され、データベース設計者の役割が生まれた
• データベースが急増し、管理すべきデータ要素が増えるにつれ、データベース管理者の役割が拡大した
• 複数システムのデータが一致しない問題が大きくなると、企業レベルの情報統合を担う**CIO（Chief Information Officer）**が登場した
• 構造化データとテキストデータを統合し、企業データを全体として理解する必要が生じたことで、**CDO（Chief Data Officer）**の役割へと発展した
• データの形態が多様になるほど、管理の複雑さと重要性、活用機会と課題がともに増大する

物理的な集中化から意味論的な集中化へ

• 企業全体でデータとその意味を一貫して理解するには、集中化されたデータ理解の仕組みが必要である
• 初期のコンピューティングにおける集中化は、データベースを大型メインフレームに集める物理的な集中化を意味していた
• その後、データがパーソナルコンピュータ、インターネット、企業システムなど複数の場所へ分散するにつれ、物理的な集中化は不可能になった
• データが分散するほど、インターネットと企業内部で同じ対象を同じ意味で理解できるよう調整する必要性はさらに大きくなる
• 集中化の対象は、データが保存された場所から、データの意味と定義へ移った
• ELDMは、データが複数の物理的場所に存在していても、企業レベルの共通したデータの意味を中央で維持する手段として使われる