ここでは、AI時代のデータマネジメントについて次の観点で説明します。
AI時代のデータマネジメントとは
従来のデータマネジメントの定義を、
データマネジメントとは、企業価値を創出できるように、標準化されたルールやプロセスに従って、データ資産のライフサイクル全体を継続的に管理し、その品質・セキュリティ・経済性を維持・向上させる活動である
とすると、ここでは、AI時代のデータマネジメントを次のように考えます。
AI時代のデータマネジメントとは、人とAIエージェントが協働して企業価値を創出できるように、標準化されたルールやプロセスに従って、データ資産のライフサイクル全体を継続的に管理し、その品質・セキュリティ・経済性を維持・向上させる活動である。
ここでは、データ資産を「人とAIエージェントが業務を遂行し、意思決定や価値創出を行うために必要な情報資産全体」ととらえています。
なので、データ資産には次のようなものが含まれます。
- データ（構造化・非構造化）
- メタデータ（構造化・非構造化）
- API仕様（OpenAPI）
- DTO・Schema
- AIエージェントが利用するナレッジ
- AIエージェントのアクセス権限・ポリシー
- データ品質ルール
- データセキュリティルール
それから、体系化され、意味づけされ、行動に使える状態になった情報である「ナレッジ」も非構造化データの一種として考えます。
※
構造化データ
非構造化データ
データマネジメントのPDCA
データマネジメントでは、企業価値を創出できるように、標準化されたルールやプロセスに従って、データ資産のライフサイクル全体を継続的に管理し、その品質・セキュリティ・経済性を維持・向上させるためにマネジメントサイクル（PDCAサイクル）を遂行します。
次の図は、データマネジメントのPDCAサイクルを表したものです。
このPDCAを支える知識体系が、DMBOK（データマネジメント知識体系）で下図のように11の知識領域から構成されています。
PDCAを一つひとつ説明します。
- Plan（計画）
データマネジメントにおけるPlanとは、企業価値を最大化するために、データマネジメントの目的・方針を定め、管理すべきデータ資産を明確にし、それらを適切に管理・活用するためのルールやアーキテクチャを策定する活動です。
データマネジメントのPlanでは、次のようなタスクを遂行します。- データマネジメントポリシー・スタンダード・プロシージャの策定
- データ戦略の策定
- データアーキテクチャ（概念・論理・物理）の設計
- データ品質ルール
- データセキュリティルールの定義
- メタデータの定義
- Do（実行）
Planで定めた設計・ルールに基づき、データ管理基盤を構築するとともに、データライフサイクル全体を継続的に運用する段階です。- データ管理基盤の構築・実装
データを安全かつ効率的に管理・提供するためのシステム基盤を構築します。
データ管理基盤の構築・実装では、次のようなタスクを遂行します。- テーブル・制約・インデックスの実装
- DBの構築
- バックアップ・監視・アクセス制御の設定
- API・非同期メッセージングの設計・実装
- UIの設計・実装
- データの品質やセキュリティを確保するためのビジネスロジック設計・実装
- DWH・Lakehouseの構築
- データ連携基盤の構築
- ナレッジベースの構築
- データライフサイクルの運用
構築した基盤の上で、データライフサイクル全体を継続的に運用します。
データライフサイクルの運用では、次のようなタスクを遂行します。- 生成・収集（Creation & Collection）
人やAI、IoT機器などがデータを生成・収集し、SoRへ登録する。
この時点で正確性やデータ形式を統一することが重要です。 - 管理・保守（Management & Operations）
保存されたデータを、安全かつ継続的に利用できる状態に維持する。- バックアップ・リストア
- レプリケーション
- アクセス権管理
- 暗号化
- メタデータ管理
- ストレージ管理
- 可用性・性能管理
- 統合・連携（Integration & Interoperability）
API、非同期メッセージング、データ連携基盤などを通じて、複数のシステムやデータを統合・変換し、社内外の人・AI・システムが利用できる状態にする。
ここではアクセス制御、データの意味、形式、品質を維持したまま連携することが重要です。
具体的には、次のような活動です。- APIによるデータ提供
- イベント・メッセージの配信
- システム間のデータ連携
- データ形式・コード体系の変換
- 複数データの結合
- SoRからSoI、DWH、Lakehouseへの連携
- 利用・分析（Use & Processing）
ビジネスの意思決定や業務改善のために、データを可視化・分析します。- 業務システムでの参照・処理
- BIによる可視化・分析
- AIエージェントによる判断・業務実行
- 機械学習モデルの学習・推論
- SoIによる目的別分析
- アーカイブ（Archive）
日常的には使わないものの、法令上の保管義務があるデータを長期保存します。 - 破棄・消去（Deletion）
保管期限が過ぎたデータを、復元不可能な形で完全に削除します。
- 生成・収集（Creation & Collection）
- データ管理基盤の構築・実装
- Check（検証）
データマネジメントの実施状況を継続的に測定・監視し、品質・利用状況・ガバナンスが計画どおり維持されているかを検証する段階です。
データマネジメントのCheckでは、次のようなタスクを遂行します。- データ品質測定
- アクセスログ分析
- データ利用状況分析
- 監査
- コンプライアンス確認
- KPI測定
- Act（改善）
Checkで明らかになった課題をもとに、データ管理の仕組み・ルール・アーキテクチャを改善し、データマネジメントを継続的に進化させる段階です。
データマネジメントのActでは、次のようなタスクを遂行します。- 品質改善
- 標準見直し
- データモデル変更
- API改善
- ガバナンス改善
- 不要データ削除
- AI向けメタデータ改善
AIエージェントネイティブなデータマネジメント
最後に、AI時代のデータマネジメントのポイントと、それを実現するためのデータ連携基盤、および、ナレッジベースについて説明します。
ここでは、データ連携基盤を、人・AI・アプリケーション間でデータを安全かつ一貫して連携するためのAPI、メッセージング、認証・認可などを含む実行基盤という意味で使用しています。
AI時代のデータマネジメントのポイント
AI、特に、AIエージェントと人が協働、共創する時代、データマネジメントでは次の点が重要になります。
- データガバナンス
AIエージェントと人が守るべきルール・責任・権限を管理すること。 - メタデータ管理
AIエージェントにデータの意味・構造・所在・制約を理解させること。 - データ品質管理
AIエージェントが利用・生成するデータ品質を保証すること。 - データセキュリティ管理
AIエージェントが安全にデータへアクセス・利用できるようにすること。 - ナレッジマネジメント
AIエージェントが企業のコンテキストを理解・推論・学習し、実践的な知識を蓄積・共有すること。
AI時代のデータ連携基盤
データ連携基盤は、データマネジメントのPDCAでいうと、Do（実行）のデータ管理基盤の構築・実装で構築します。
上述した「AI時代のデータマネジメントのポイント」、特に、AIエージェントが利用・生成するデータの品質とセキュリティを担保するために、次の点を考慮して、データ連携基盤を設計・構築します。
- AIエージェントが利用・更新する構造化データは、ユースケースベースのAPIを介してアクセスさせる
- APIを提供するアプリケーションは、業務領域（ドメイン）ごとにマイクロサービス化する
次の図は、AIエージェント時代のデータ連携基盤のイメージを表したものです。
データ連携基盤は、ビジネスプロセス層、UI層、アプリケーション層の３つのレイヤーで構成されています。
最上位のビジネスプロセス層は、ビジネスのステークホルダーに価値を提供する単位であるビジネスプロセスを表しています。
ビジネスプロセス層では、人またはAIエージェントが、ビジネスプロセスを構成するアクション（活動）を実行します。
各アクションは必要に応じて、UI層またはアプリケーション層のAPIを呼び出し、データの取得や更新を行います。
ビジネスプロセス層では、それを構成するアクションの構成を自由に変更できるとともに、アクションがアクセスするAPIも必要に応じて変更・差し替えることができます。
次にUI層ですが、これは人（ユーザー）に対するインターフェースを表したもので主に画面になります。
UI層を構成するコンポーネントは、アプリケーション層のバックエンドアプリケーションに対するフロントエンドアプリケーションです。
最後にアプリケーション層ですが、これは、ビジネスプロセス層のアクションや、UI層のフロントエンドアプリケーションに対するAPIを実現するバックエンドアプリケーションから構成されます。
なお、アプリケーション層には、複数のバックエンドアプリケーションを集約して、Web、モバイル、AIエージェントなど利用者ごとに最適化したAPIを提供するBFF（バックエンドフォーフロントエンド）も含まれます。
それから、アプリケーション層のバックエンドアプリケーション同士は、APIを介した同期通信や、QueueやTopicを介した非同期メッセージングで連携します。
さて、ここで重要なのが、アプリケーション層のバックエンドアプリケーションを、業務領域（ドメイン）ごとに、機能と、それを実現するために必要なデータをカプセル化したマイクロサービスにするということです。
次の図は、システムの３階層アーキテクチャを表したイメージです。
この図の、データ層のAPIは、データベースに対するCRUD（Create／Read／Update／Delete）操作を中心としたAPIであるのに対し、アプリケーション層のAPIは、「受注を登録する」「請求を確定する」「顧客を統合する」など、業務上のユースケース単位で提供されるAPIで、データ品質やセキュリティを担保するためのビジネスロジックや業務ルールを含んだものになります。
もし、相手が直接CRUDベースのAPIを直接呼び出すと、データ品質やセキュリティを担保するためのビジネスロジックや業務ルールが迂回され、結果的にデータの整合性が損なわれ、信頼できないデータが蓄積されるリスクが発生します。
マイクロサービス化されたバックエンドアプリケーションは、相手にユースケースベースのAPIを提供するので、データ品質やセキュリティを担保することができます。
バックエンドアプリケーションを、MECEに分割された業務ドメイン別のマイクロサービス化することで「One Fact in One Place」を実現することができ、データの散在を防ぐとともに、データ品質とセキュリティを担保することができます。
これにより、データ連携基盤は、各業務ドメインにおいて唯一の正本データ（Single Source of Truth）を確立し、それらをAPIやイベントを介して連携することで、企業全体として信頼できるデータ基盤を実現します。
上図の例では、販売管理は受注データ（トランザクションデータ）とそれに付随するデータ、顧客管理は顧客データ（マスタデータ）とそれに付随するデータ、請求管理は請求データ（トランザクションデータ）とそれに付随するデータを管理しています。
販売管理では、受注データに関連する顧客データを持ちますが、これは受注時点で顧客管理から取得された顧客データのスナップショットです。同様に、請求管理では、請求データに関連する顧客データを持ちますが、これは請求時点で顧客管理から取得された顧客データのスナップショットです。
もし下図のように、バックエンドアプリケーションから機能とデータを分離して、データはデータ層で一元管理するようにすると、販売管理も請求管理も一元管理された顧客データ（マスタデータ）を参照するため、販売管理は受注時点の顧客データを保持し、請求管理は請求時点の顧客データを保持することが難しくなってしまいます。
その結果、顧客マスタが更新されると、過去の受注や請求がどの顧客情報をもとに作成されたのかを正確に再現できなくなる可能性があります。例えば、顧客の住所や担当者が変更された場合でも、受注や請求は「その時点」の顧客情報に基づいて行われたという業務上の事実を保持しておく必要があります。
このため、販売管理では受注時点の顧客情報を、請求管理では請求時点の顧客情報を、それぞれのトランザクションデータの一部としてスナップショットで保持します。
顧客管理が管理する顧客マスタは「現在の顧客情報」の正本（Single Source of Truth）であり、販売管理や請求管理が保持する顧客情報は、「業務イベントが発生した時点の事実」を表すデータとして役割が異なります。
このように、各マイクロサービスが自らの業務に必要なデータを責任を持って保持することで、過去の業務を正確に再現できるだけでなく、監査性やトレーサビリティを確保しながら、各サービスを独立して変更・運用できるようになります。
AI時代のナレッジベース
AIの時代、体系化され、意味づけされ、行動に使える状態になった非構造化データである「ナレッジ」が大変重要になります。
ナレッジには、
- 「どう行動すべきか」を決める枠組（原理・原則）となる規範ナレッジ（Normative Knowledge）
- 原理原則を戦略（集中すべき場所）に落とした戦略ナレッジ（Strategic Knowledge）
- 戦略に従って行動した結果である実践ナレッジ（Practical Knowledge）
があります。
このナレッジを蓄積、管理する基盤がナレッジベースで、データマネジメントのPDCAでいうと、Do（実行）のデータ管理基盤の構築・実装で構築します。
企業のメンバーやAIエージェントは、マネジメントサイクルのタスクを遂行する時、規範ナレッジ、戦略ナレッジ、実践ナレッジを判断基準にします。
実践ナレッジは、「何をすればうまくいくか」「何をすればうまくいかないか」を蓄積した経験知です。そのため、メンバーやAIエージェントは過去の成功・失敗を学習し、より適切な判断や行動を選択できるようになり、成功確率を高めることができます。
また、規範ナレッジや戦略ナレッジは、企業固有の意味構造（オントロジー）を形成し、AIエージェントが企業固有の文脈（コンテキスト）を理解・解釈するための基盤となります。
AIは与えられた文脈の中で確率的に最適と推定される解を提示します。
しかし、企業固有の意味構造（オントロジー）が明示されていない場合、その推論は汎用的な最適解へと収束し、企業独自の戦略的一貫性を担保することはできません。
規範ナレッジや戦略ナレッジを明確化し、それに基づいて戦略と実行を統合することが、失敗リスクを低減し、長期的に安定した構造を維持するための前提条件となるのです。
※詳細は、AIネイティブ時代のナレッジマネジメントを参照してください。
次の図は、Claude Codeがナレッジベースを介して構造化データや非構造化データにアクセスする例を表したものです。
この例の場合、Claude CodeがナレッジベースにあるAPIのURLやOpenAPIで定義されたAPIの仕様を理解して、MCPを介してAPIにアクセセスします。
また、Claude Codeがナレッジベースにある文書（非構造化データ）のメタデータ（データの意味、項目、品質要件、セキュリティ要件など）を理解して文書を参照、生成します。
データ連携の例
myCompany-manager（ナレッジベース）では、アプリケーション機能のAPIと、その仕様を定義し、
そのアプリケーション機能を、部門のアクションに割当てることで、
AIエージェントが、その部門のアクションを実行する際、そこに割当てられたアプリケーション機能のAPIを自動的に呼び出し、業務システムから必要なデータを取得したり、処理結果を更新したりすることができるようになります。
AIを使ったバイブコーディングが一般的になってきた昨今、これまでSaaSを使って利用してきた販売管理や顧客管理などの業務システムを、自前で作ってAPIをAIエージェントに公開して利用させるというやり方が今後増えてくるのではないでしょうか。
弊社で実施しているアプリケーションサービス導入支援サービスでは、モデルドリブン開発ワークショップを通して比較的低コストでアプリケーション機能のAPIを開発することができます。
メタデータ理解の例
myCompany-manager（ナレッジベース）では、メンバーやAIエージェントが参照、作成するデータの型（データタイプ）を、セキュリティ要件を含めて定義して、
データタイプに属するデータ項目を、データ品質要件を含めて定義します。
次に、そのデータタイプを、メンバーやAIエージェントが行うタスクに割当てることで、
AIエージェントが、そのタスクを遂行する際、そこに割当てられたデータ項目やデータ要件を考慮して成果物を生成することができるようになります。
さて、データマネジメントのPlanでは、次のようなタスクを遂行します。
- データマネジメントポリシー・スタンダード・プロシージャの策定
- データ戦略の策定
- データアーキテクチャ（概念・論理・物理）の設計
- データ品質ルール
- データセキュリティルールの定義
- メタデータの定義
このタスクの結果、生成される
データマネジメントポリシー・スタンダード・プロシージャ
メタデータ
はナレッジベースに登録されます。
また、データマネジメントのDoのデータ管理基盤の構築・実装の
- API・非同期メッセージングの設計・実装
- UIの設計・実装
- データの品質やセキュリティを確保するためのビジネスロジック設計・実装
というタスクの結果、アプリケーションとAPIが生成されますが、そのAPIと仕様がナレッジベースに設定され、
データマネジメントのDoの統合・連携（Integration & Interoperability）の
APIによるデータ提供
になります。
