見出し画像

Data Catalog 2025 (Things behind Agentic AI)

松元亮太 / Quollio Technologies

はじめに

2024年が終わる。今年は大企業の多くのCDOやCIOが、「うちの生成AIの推進は大丈夫なのか！」といった風当たりを受けてきたと思う。Agentic AIやMulti-agentという言葉も認知され、2025年はAIを業務で「本格的に活用する」には何が足りていないか、を真摯に考え始めることになるだろう。他方で、日本のデータマネジメントシーンでも「AI Readiness」が歌われ、BIや顧客分析以外の動機でなかなか推進力が持てなかったデータマネジメントも、ようやく経営（CEO）のトップオブマインド＝経営課題のメインストリームに躍り出てきた。ありがとうAI。

なぜAIの裏側にデータマネジメント？

AIの裏側にデータマネジメントが必要だというと、「LLMってすでに色々なデータを食ってるんじゃなかったっけ？」と思う人がいるかもしれない。その通り、ChatGPTなどはインターネットに転がっているデータをほとんど食っている。それもテキストデータだけではなく、最近では画像や動画から学習させる技術も発展し、LLMのベースモデル自体は日進月歩で進化している。一般の消費者が使う用途であれば、これだけで相当使える。私自身もChatGPTのヘビーユーザーで、英会話をしたり、思考の整理に役立てたり、生産性を2-3倍に引き上げてくれる優秀なバディという感覚だ。しかし、AIを大企業で本格的に活用するとなると、オープンデータに依存したベースモデルをそのまま使うとはいかない。

例えば、システム開発で「情報系」と「業務系」という分類が長らく使われてきたように、大企業は「良い意思決定」と「業務の仕組み化」のためにテクノロジー投資を行う、と整理できる。「AIを大企業で本格的に活用する」というのは、つまりAIで良い意思決定を後押しするのか、AIで業務の仕組みを変えるのか、を考えることに他ならない。（厳密には情報系はコミュニケーション系など他の分野も含むが、ここでは意思決定にフォーカスする。また、ここでいう業務系は基幹系を含む。）

情報系の仕事 vs 業務系の仕事

"Data World" 出身の人からすると、まず前者は想像にたやすいだろう。大企業で「Data Analytics」と呼ばれていたものは、「情報系」を発端とし経営の重要な意思決定を行う領域（BIや顧客分析）で発展してきた。この分析ロジックに、統計の代わりにAIを使いましょうということだ。今までと同じく、AIの裏側では構造化データの管理が肝になる。

後者に関して。「情報系」出身には馴染みが薄いかもしれないが、ここがAgentic AIやMulti-agentの大本命のようだ。先ほど話した通り、Analyticsが成長してきた「情報系」の土俵では、金融業のリスク分析や材料化学のMaterial Informaticsにおける分析など少し特殊な領域を除けば、業務系（＝人物金を扱う業務システム）はデータの発生元であって、業務系「の中」でデータが統計やAIを通じて再利用され価値を出す、イメージは沸きずらかったように思う。（情報系の世界では、データ基盤は常に左から右へ、左には「業務系」が右には「情報系」と一方通行に描かれることが多かった）

しかし、今回のAIの流れで「データ」はとんでもない「業務系」の太客を手に入れた。High-levelゴールを所与とし、Agentic AIはどんどん勝手に仕事を進めることが想定されている。また、Multi-agentはそこからさらに発展し、その遂行を複数モデルの協同で行うことで精度を高める。ドラえもん vs 猫型ロボット集団 のようなイメージを思い浮かべそうだが、AIはデジタル空間に存在できることを考えると、この「優秀なバディ」は実のところ大企業のシステムのいろんな隙間に存在（Omni-presence）できることになる。

親LLMの中で、子LLMが出し分けられる。みかけよりLLMの個体は多い？

AI時代でも構造化データに光が当たる

では、Omni-presenceするAIバディに食わせるデータは各々で出し分ける必要が出てきそうだ。
人事業務をするバディには人事評価データを渡すが、新卒教育をするバディにはなるべくそのデータは渡したくない。「渡辺くんの今期の査定とボーナスの金額を教えて」とかが起きるのは避けたい。もっと細かいレベルで切ると、人事業務の中でも営業部門の評価データは見ていいがIT部門の評価データは見せたくない、とか。AIバディ自体の倫理観に出しわけを委ねるのは悪手なので、一般的なシステム利用が想定するような権限粒度で、異なる優秀なバディ(ズ)にアクセス権を出し分ける必要がある。ツールが元々想定している作業やデータの制限であればツール（業務系システム）の権限設定をレバレッジするのだろうが、他の業務系や情報系にある独自データをAIバディに学習させるところまでくると、ツールの外で別途「ビジネス用途別にデータを構造化して管理しておくこと」が必要になる。

結局、LLMがデータにアクセスする時は、人のRBACをベースに行うのかな..

すると、「構造化データを作り、管理する仕事」に光が当たる。誰かが、せっせこせっせこと構造化データを作る。では、誰がやるんだろう。今までは情報系の “少ない” ユースケースの中（それでも多かったが・・）で構造化データを準備してきた。しかし、今後のAI時代においては、情報系のみならず業務系の間にもAIバディが無限に存在し、無限に出しわけパターンを作る必要がある。”作る”というと簡単な感じがするが、実際はビジネス要求を把握し、持ってる部品を把握し、要件に落としていき、計画を持って作っていく。これを、何百というユースケース、しかも作って終わりではなく、頻繁に作り替えたり、説明責任を持ったり、、企業活動では一般的にこういう仕事を「生産 = Production」と呼ぶらしい。生産をひたすら科学してきた自動車メーカーもびっくり、来るAI時代には「構造化データの生産活動」を行わないといけない。

データの生産管理（Data Production Management）

自動車のメタファーで行くと、データの生産活動には理系的な生産技術（設計とか）業務と文系的な生産管理（計画とか）業務があるはずだ。
理系的なデータの生産技術に関しては、結局データモデリング（設計）とデータウェアハウスの構築（実装）になる。ここは、OLAP時代からレイクハウスに至るまで、30年以上もの歴史があるので、体系化され尽くしている。（アジャイルデータモデリング本が詳しい。私も日本語レビューに参加させていただいた）。

で、文系的なデータの生産管理はあまり科学され尽くしていない。データの生産管理は直訳するとData Production Managementなので、その生産行為の結果生まれる成果物はデータプロダクト（Data Product）と呼ばれる。データマネジメントシーンでは、実は2020年あたりから提唱され続けてきた。ビジネス目的駆動であり、自己記述的（Self-explonatory）であり、利用するためのアクセシビリティが備わっている、というのが特徴で、当初は”Analytics”に利用するデータを提供するための一番都合の良い管理単位、というふうだった。しかし、データプロダクトをどう企業として管理するか（データの生産管理）に関しては、これまであまり議論が発展してこなかった。”Data World”の住人たちはオブジェクトオリエンティッドなので(?)、生産管理のようなワークフローオリエンティッド(?)な領域に興味がなさそうに見える。

いずれにしても、データの生産管理がなければ、異なるAIユースケース（ビジネス目的）に対してデータを出し分ける、という理想を実現することはできない。そうなると、LLMは汎用的なナレッジのみ理解し、企業の事情やコンテキストを理解しないで業務を行う、或いは意思決定を行うことになる。

データプロダクトという単位は、構造化データの説明可能性を作る

情報系で話した意思決定とは、「これに投資する」「これを購入する」「この人を採用する」「この人を異動する」「広告でこういうメッセージを打ち出す」みたいな株式会社としての決断を伴うものである。株式会社の仕組み上こういった営みでは「最後は誰が責任を負うのか」を明確にしなけりゃいけず、これを負うのが代表取締役と呼ばれる人間、ここから一定のデリゲーションを受けたのが執行役員だということだ。これをAIが引き受けることはできない。厳密には技術上はできるが、AIが起こしたミスは全て社長の責任になるということであり、これは”Data Analytics”と呼ばれた統計分析の時代から難点の一つになっている。同じ理由で情報系のみならず、業務系のAIバディが行う仕事も多かれ少なかれ何のデータに基づいてどんなロジックで仕事を進めたのか、が論点になる。
つまり、「説明可能性」がAIに求められることになる。その説明を持って社長などの人間が改めて判断し、AIの代わりに責任を被る。或いはすでにAIによって誤って進んでしまった仕事をRebootするということが可能になる。当然、株主や顧客に「こう言ったデータ・こう言ったロジックで決断しました」と説明するのも社長の責任であるため、事後であれ説明可能性が必要だ。データプロダクトは、データに関して説明可能性を担保する便利な最小単位になりうる。

データカタログ 2025 (Data Catalog 2025)

生産管理のベースになるのが、在庫管理だ。データに関して、この領域は長らくデータカタログと呼ばれてきた。従来のデータカタログはただRDBのインベントリだったが、DWHとBIが発達してから “分析用途にデータが追加生産されはじめ” たおかげ（/ せい）で、最近はインベントリの範囲が拡大した。2025年以降はAIの流れも合わせて、この需要はかつてない拡大を見せるだろう。また、RDBやDWHのデータのみならず「AnalyticsやAIでどのデータが使われているか」という情報もカタログ化する動機が出てくるのは想像にたやすい。つまりはデータプロダクトのカタログである。

というわけで今後、データカタログの需要は鰻登りになる。そして、文系的な生産管理を完成させるためには、ワークフローケイパビリティが追加で必要になる。データカタログ自体がオブジェクトオリエンティッドで平べったいSystem of Insight + System Integrationであるのと対照的に、ワークフロー領域はタスクオリエンティッドな仕組みが必要になる。

データの生産管理は、タスクオリエンティッドな業務システムとなる

アクティブメタデータとの関わり

アクティブメタデータは、北米スタートアップの動きを受けてGartnerが2021年に提唱し始めた概念である。（私も少し前に記事を書いている）あれからもう3年、日本でもちょっとは市民権を得ただろうか。詳細は省略するがこの概念が象徴するのは大きく2つ、「動的にメタデータを常に取ってきて使えるようにする」「そのメタデータはメタデータが必要な他のシステムに還元を行う」ということ。データの生産管理の観点でメタデータの需要が高まるのは想像にやすいが、実はメタデータはAgentic AIやMulti-Agentに安心して食わせられる数少ない特殊なデータでもあり（詳細はLoysの記事が詳しい）、これはアクティブメタデータにおける最高の還元先ともなる。企業内にどんなデータがあって、どのデータが新しくて、どんな目的に使われていて、どんな方法でアクセスできるのか、といった情報をAIバディが先に知っているのには大きな意味がある。例え、業務系に散りばめられたAIバディ自体にデータアクセスが制限されていたとしても、メタデータを活用すればAIバディは足りないデータが企業内に存在するかを察知し、そこへアクセスできるかどうかを人間に質問できるのである。

参考資料


いいなと思ったら応援しよう！