かつて「商用データベースのライセンスコスト削減」の切り札として導入されたPostgreSQLは、クラウドインフラの需要の高まりに合わせて普及が進んだ。2025年11月に公開されたバージョン18では、OSのページキャッシュへの依存を脱却する非同期I/Oストレージサブシステムの実装など、商用DBに匹敵する機能強化が図られている。しかし技術的な進化以上に注目すべきは、その周辺ビジネスで起きたITベンダーの組織再編だ。

　2025年のデータベース業界では、巨大プラットフォーマーによる独立系PostgreSQLベンダーの買収が相次いだ。データレイクハウスを提供するDatabricksは、サーバレスPostgreSQLを提供するNeonを10億ドル（約1500億円）で買収した。データクラウド大手のSnowflakeも、PostgreSQLのエンタープライズサポートを担っているCrunchy Data Solutionsの買収を発表している。

　この一連の動きは、IT部門にとって何を意味するのか。それは「PostgreSQLを選べばベンダーロックインを回避できる」という言説の終わりだ。これまで企業は、AWS（Amazon Web Services）の「Amazon Aurora」やGoogle Cloudの「AlloyDB for PostgreSQL」といったクラウドベンダーのPostgreSQL互換データベースサービスだけでなく、NeonやCrunchy Dataといった独立系ベンダーのサービス（DBaaS）を選択することで、特定プラットフォームへの依存を避けることができた。

　しかし有力な独立系ベンダーがDatabricksやSnowflakeといった巨大エコシステムの一部に組み込まれたことで、選択肢は狭まりつつある。パヴロ氏は、これを2000年代後半のOLAP（オンライン分析処理）市場における買収劇になぞらえ、独立系ベンダーの選択肢が急速に失われている現状を指摘する。

　巨大資本による寡占化が進めば、長期的にはライセンスや利用料の価格決定権がベンダー側に移るリスクがある。BroadcomによるVMware買収後の混乱が記憶に新しい中、データベース市場でも同様のコスト増加やユーザーの囲い込みへの警戒が必要だ。Microsoftは2025年に新たなマネージドPostgreSQLサービス「Azure HorizonDB」を投入しており、主要クラウドベンダーによるPostgreSQLの囲い込み競争は激化の一途をたどっている。

「互換性」は安全地帯ではない　商用ソフトウェア互換OSSの法的リスクが顕在化

　2つ目の懸念材料は、オープンソースの互換ソフトウェアを巡る法的リスクの顕在化だ。2025年5月、NoSQLデータベース大手のMongoDBは、同社の製品と互換性を持つオープンソースソフトウェア（OSS）「FerretDB」の開発元を提訴した。

　FerretDBは、PostgreSQLをバックエンドに使用しながら、アプリケーションからはMongoDBとして振る舞うプロキシソフトウェアだ。これにより企業は既存のMongoDB用アプリケーションを書き換えることなく、ライセンスコストのかからないPostgreSQLへ移行できる──はずだった。

　MongoDB側は、FerretDBが商標権や著作権を侵害し、ドキュメントやプロトコル仕様のライセンスに違反していると主張している。パヴロ氏は、APIの複製に関する訴訟の前例としてOracle対GoogleのJava API訴訟（Googleが勝訴）を挙げるが、今回のケースが同様の結末になるかは不透明だという。

　この訴訟が示唆するのは、「高額な商用ソフトウェアから、互換性のあるOSSへ逃げる」という戦略に、法的な不確実性が生じているという事実だ。もしMongoDB側の主張が認められれば、FerretDBのような互換OSSを採用していた企業は、システムの停止や再構築を余儀なくされる可能性がある。

　一方でMicrosoftがMongoDB互換の「DocumentDB」をLinux Foundationに寄贈するなど、各社の思惑が入り交じっている。データベースを選定するときは、単なる機能やコストだけでなく、開発元の法的な立ち位置や知財リスクまで精査しなければならない時代が到来している。

AIエージェントの浸透と「ガバナンス崩壊」の危機

　ベンダーロックインのリスクと並んで、2025年に急浮上したのが「AIエージェント」によるデータベース操作のガバナンス問題だ。

　2024年末にAnthropicが発表し、2025年にOpenAIなどの主要プレイヤーがサポートを表明した「MCP」（Model Context Protocol）は、大規模言語モデル（LLM）と外部データソースを接続するための標準規格だ。これによりOpenAIの「ChatGPT」やAnthropicの「Claude」といったAIサービスが、中間コードを書くことなく、データベースへ直接クエリ（問い合わせ）を投げられるようになった。

　各データベースベンダーはこの動きに即座に反応した。OracleやMongoDB、YugabyteDBなど、あらゆる主要ベンダーがMCPを利用可能なサーバを公開した。これは開発者にとっては福音だが、運用管理を担う情シス部門にとってはセキュリティやデータの制御を失うリスクになりかねない。

　最大の問題は、AIエージェントによる操作の追跡と制御が難しいことだ。従来データベースへのアクセスは、アプリケーションサーバや特定の管理者アカウント経由で実行され、アクセス権限やクエリの内容は人間が設計したロジックの範囲内に収まっていた。しかしMCPを通じてAIエージェントが接続する場合、AIが文脈に応じて動的に生成したSQLやコマンドが実行されることになる。

　パヴロ氏は、「監視されていないAIエージェントに管理者権限を与えるような怠惰な運用は、破滅的な結果を招く」と警告する。例えばAIエージェントが誤った推論に基づき「通常時の100倍の品物を発注する」といったトランザクションを実行したり、データ分析のために高負荷なクエリを大量に発行して本番データベースを停止させたりするリスクがある。

　一般的なMCPサーバは単純なプロキシ（中継地点）にすぎず、クエリの内容を深く検査して「それが適切か」を判断する機能を持っていない。企業がAI活用を急ぐあまり、データベースを「世界中に公開」してしまうようなセキュリティホールを作り出す危険性が高まっている。

2026年以降のIT部門のデータベース運用

　2025年の動向は、データベースが単なる「データの入れ物」ではなく、企業戦略の要であり、同時に脆弱（ぜいじゃく）性になり得ることを示した。では、情シスの部長はこの状況にどう対抗すべきか。

1．フルマネージド一辺倒からの脱却検討

　DatabricksやSnowflakeによる買収劇は、SaaS（Software as a Service）やDBaaS（Database as a Service）への過度な依存が、将来的なコスト増や選択肢の喪失につながるリスクを浮き彫りにした。パヴロ氏が紹介するSupabaseの「Multigres」やPlanetScaleの「Neki」といったPostgreSQL向けの新しい分散処理ミドルウェアは、特定のクラウドベンダーに依存せずにデータベースの拡張性を確保する手段となり得る。

　全てをSaaSに委ねるのではなく、自社でコントロール可能なオンプレミスデータベースや、インフラ間の移行性が高いコンテナベースのシステムを「プランB」として維持することが、ベンダーとの価格交渉力を保つ鍵となる。

2．AIエージェントに対する「データベースファイアウォール」の構築

　AIエージェントの導入時は、性善説を捨てるべきだ。MCPサーバとデータベースの間に、強力な接続プールやプロキシを配置し、クエリのタイムアウト設定や返却レコード数の制限を強制する必要がある。

　またIBMの「IBM Guardium」やOracleの「Oracle Audit Vault and Database Firewall」といった、異常なクエリを検知し、遮断するエンタープライズ向けのデータベースセキュリティ機能は、人間ではなくAIエージェントがクエリを書く時代にも役立つ可能性がある。ユーザー企業はオープンソースのMCPサーバをそのまま使うのではなく、ガードレール（防御壁）を組み込んだアーキテクチャを設計しなければならない。

　2026年は、AIエージェントによる自律的なデータベース操作が本格化する年になるだろう。その前に足元のデータ基盤が、「誰のものか」、そして「誰が守るのか」を再定義することが、情報システム部門に課せられた急務だ。