検索
特集

生成AIの「弱点」をどう補う? AIエージェント時代に変化するデータベースの役割AI Readyなデータベースアーキテクチャとは?

チャットbotから自律型の「AIエージェント」へと、企業での生成AI活用が新たなフェーズに進みつつある。こうした中で、データベース領域にも大きな変化を予感させる動きが出始めている。なぜ今、データベースの重要性が高まっているのか。

Share
Tweet
LINE
Hatena

 企業で生成AI(人工知能)の導入が進む中、単なる対話型のチャットbotから一歩進み、AIが自ら与えられた目標に対して計画を立案し遂行する「AIエージェント」への注目度が高まり続けている。こうした背景の下、先行企業の間ではAIエージェントを構築、運用する取り組みも広がりつつある。

 現在のAIモデルは、与えられた指示に対する推論能力において驚異的なパフォーマンスを発揮することは言うまでもない。だが、AIを一過性のツールで終わらせず、企業の競争力に直結させるためには、AIの弱点と向き合う必要がある。AIを継続的なビジネス価値へと変える鍵を握るのが、「データベース」だ。データベース領域においても大きなパラダイムシフトが起きようとしている。

 2026年1月、オライリーから『Agentic AI Data Architectures』が発刊された。著者はMicrosoftでAIやクラウドソリューションを担当するシニアアーキテクトのBlaize Stewart(ブレイズ・スチュワート)氏と、「TiDB」を提供するPingCAPの共同創業者兼CTO(最高技術責任者)のEd Huang(エド・ファン)氏。クラウドとデータベースの領域で第一線を走る2人が、AIエージェントの普及を踏まえ、データベースアーキテクチャの在り方を体系的に示しており、大きな変化を予感させる内容となっている。

AIエージェントの普及で、データベースの重要性が高まる理由

PingCAP シニアソリューションアーキテクト 関口匡稔氏
PingCAP シニアソリューションアーキテクト 関口匡稔氏

 PingCAPでシニアソリューションアーキテクトを務める関口匡稔氏は、AIエージェントをビジネスで活用する上での課題として「AIエージェントそのものがメモリ(長期記憶)を持たない点」を挙げる。あくまでもAIエージェントは目的に合わせて推論し、ビジネスのワークフローを実行するものであり、長期的な記憶の保持は外部の仕組みに頼らざるを得ないのだ。

 「昨日、報告した件だけど」といった問い合わせや、数日にまたがるような長期間のタスクを実行させる場合、AIエージェントに社内固有のコンテキスト、これまでの作業履歴を把握させる必要がある。これを担当者がAIエージェントに都度共有していては、自律的なエージェントとは呼べず、業務の効率化、自動化にも限界がある。

 つまり、企業がAIエージェントから継続的にビジネス価値を引き出すためには、過去の情報を「記憶」させる仕組みを検討する必要があるというわけだ。

 AIエージェントにおける記憶は主に3種類ある。

 1つ目は、処理中のタスクや会話の情報を保持し、インタラクションの一貫性を確保する「短期記憶」(ワーキングメモリ)。2つ目はセッションを超えて知識やユーザーの好みなどの情報を保持し、パーソナライゼーションを実現する「長期記憶」。3つ目はAIエージェントがイベントのシーケンスや結果をキャプチャーし、過去の経験から学習し、精度を高めるのに役立つ「エピソード記憶」だ。

データベースがAIエージェントの「長期記憶」の仕組みを実現(提供:PingCAP)
データベースがAIエージェントの「長期記憶」の仕組みを実現(提供:PingCAP)

 AIエージェントに全ての記憶を保持させるのではなく、目的に合わせて必要な分だけ渡すことで、より的確なアウトプットが期待できる。プロンプト設計も含めて「必要な情報を必要なだけ渡す」という設計のテクニックは「コンテキストエンジニアリング」と呼ばれている。

パーソナルAIエージェントにおける長期記憶の実装例とスケールの壁

 これまで人間や業務システムからのアクセスを想定していたデータベースだが、関口氏は「将来的にデータベースのメインユーザーは人間からAIエージェントになっていくと考えています」と語る。

 AIエージェントにデータベースを組み込んで長期記憶の仕組みを実装している事例に「OpenClaw」がある。リリースから間もないにもかかわらず、NVIDIAのイベントでも絶賛されるなど、大きな注目を集めている(関連記事)。

 OpenClawはオープンソースのAIエージェントで、OpenAIなどのLLM(大規模言語モデル)をローカル環境で動かすためのフレームワークのようなものと考えていいだろう。

 OpenClawは長期記憶を持たせるために、ローカル環境でSQLiteのベクトル拡張を使用している。RDB(リレーショナルデータベース)にベクトルインデックスとメタデータを組み合わせたことで、日付による厳密な絞り込みと、意味的類似性に基づいた検索によって、AIが過去のコンテキストを活用できるようになった。

 OpenClawのようなパーソナルなAIエージェントであれば、ローカルのSQLiteで事足りるかもしれない。しかし、企業が全社規模で導入し、無数のAIエージェントが同時に稼働する環境となれば、データベースへの負荷は全く別次元のものになる。

 エージェントごとに蓄積される膨大な「記憶」を高速に処理しつつ、企業システムとして欠かせないデータの正確性や一貫性(ACIDトランザクションなど)も確保しなければならない。単純に単一のデータベースのスペックを上げれば済む話ではなく、AI特有の同時多発的なアクセスをさばくスケーラビリティと、RDBのような厳密な管理体制の両立という課題が浮上することになる。

 エンタープライズでAIエージェントを本格稼働させるには、この「スケールの壁」を越えるアプローチが問われているというわけだ。

予測不能なアクセス増――AIエージェント時代に求められるアーキテクチャ

 こうしたAIエージェント特有の要件を踏まえ、データベースのアーキテクチャを変化させる動きが出始めている。PingCAPも、AIエージェントからのアクセスを前提に再設計した新しい分散型SQLアーキテクチャ「TiDB X」を2025年10月に発表している。

 この新しいアーキテクチャは、「TiDB Cloud」の各プラン(「Starter」「Essential」「Premium」)に導入されている。オブジェクトストレージを基盤としており、「コンピュート(計算)」と「ストレージ(保存)」を完全に切り離すことで、処理内容に応じてリアルタイムにスケールできる設計だ。

 関口氏は「TiDB Xは、人間や従来のアプリケーションからのアクセスではなく、AIエージェントからのアクセスを想定した非機能要件に合わせてチューニングを施しています。多様なワークロードへの対応と、オートスケールの2点が軸です」と説明する。

 OLTP・OLAP・セマンティック検索を複合したハイブリッドワークロード、リレーショナルとベクターなどのマルチモデルサポートを備えつつ、特に重視しているのが、オートスケールの機能だ。

 これまで分散データベースというとShared Nothing型で共有ストレージを持たず、複数のデータベースにデータをコピーすることで、どれかがダウンしてもリカバリーできるようにする構成が主流だった。しかし、このアーキテクチャは、限られた数のアプリケーションからアクセスされることを想定したものだ。

 多数のAIエージェントがアクセスする環境では前提が崩れる。場合によっては万単位となる数のエージェントが、いつ、どのようなタイミングで、どれくらいアクセスしてくるのか予測不可能な負荷に対応しなくてはならない。

 「エージェントごとにデータベースを作ると、その数は万から百万の単位になり得ます。従来のデータベースの場合、論理的なメタデータだけでシステムが破綻しかねません」(関口氏)

 そこでPingCAPは「TiDB Cloud Starter」(旧:TiDB Cloud Serverless)の頃から提供していたサーバレスアーキテクチャをベースとして、これを発展させたアーキテクチャを考案したという。関口氏は「TiDB XではTiDBそのものをマイクロサービス化して、ワークロードに合わせたリソースをオンデマンドで割り当てます」と説明する。

 より詳しく見ると、TiDB XはShared Everything型(共有ストレージを前提とした構成)アーキテクチャで、「Amazon S3」を主要ストレージとし、KV層がキャッシュとして動作する。マイクロサービス化とオンデマンドプロビジョニングで必要な分だけリソースを使い、数百万規模の論理クラスタでも耐えられるメタデータ管理を実現しようとしている。

TiDB Xのアーキテクチャ(提供:PingCAP)
TiDB Xのアーキテクチャ(提供:PingCAP)

AIエージェントがデータベースを自動生成し、使い捨てる時代へ?

 AIエージェントの爆発的な増加によってインフラが試されたケースもすでに出始めている。2025年3月にプライベートプレビューを開始するや否やユーザーが急増し、同年末にMeta Platformsに買収されたAIエージェントのスタートアップ「Manus」がその一例だ。

 2025年末に投稿されたManusのブログによると、AIエージェントのために生成したVM(仮想マシン)はトータルで8000万に達したという。関口氏は「その全てが同時稼働していたわけではないと思いますが、8000万ものVMそれぞれにひも付く膨大なデータベース要求をさばくには、TiDB Xのような概念が不可欠だったはずです」と分析する。

 なお、データベースの「作られ方」自体も変わりつつある。PingCAPは直近で、AIエージェントが自動でデータベースを作成できるサービス「TiDB Cloud Zero」の提供を開始した。

TiDB Cloud Zero(公式サイトより)
TiDB Cloud Zero(公式サイトより)

 同サービスは、AIエージェント時代に必要な機能を提供することを目的としている。これまでデータベースの作成には人間の介在が必要だったが、AIが自律的に動く上でこの待ち時間がボトルネックになりかねない。そこでAIエージェント自身がプロジェクトの目的に応じてデータベースを作成・利用できるようにするためのサービスという位置付けだ。データの保存期間は基本30日間で、目的を果たしたら破棄するコンセプトだという。

 AIエージェントが企業で本格的に実業務へ組み込まれるようになるには、まだ時間を要するかもしれない。しかし、AIエージェントが自律的にシステム基盤にアクセスし始めたとき、データベースは「人間が構築して利用するもの」から「AIが生成し、AIが利用するもの」へと、大きく変わる可能性を秘めている。

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る