エージェント型ソフトウェア開発はデータベースをどう変えるか

以前の ブログで、ストレージとコンピューティングを根本的に分離する第3世代のデータベースアーキテクチャであるLakebaseを紹介しました。このブログでは、この変化の重要な結果、つまりAIエージェントがソフトウェア開発ライフサイクルをどのように変えているのか、そしてAIエージェントが実際にどのようなデータベースを必要としているのかを探ります。

ソフトウェア開発ライフサイクルは根本的な変革を遂げています。LLMは、要件分析、コード作成、テスト実行、サービスデプロイ、アプリケーションの反復的な改善をすべて記録的な速さで行える、新世代のエージェントフレームワークを可能にしました。その結果、アプリケーションの構築とデプロイにかかる限界費用は急落しています。

エージェントによるソフトウェア開発はまだ初期段階ですが、Databricks社内およびお客様の間で、実験のペースが加速し、構築されるアプリケーションの量が爆発的に増えていることが一貫して観察されています。世界が手作業によるソフトウェアからエージェントによるソフトウェア開発へと移行する中で、現代のデータベースシステムの要件を共同で再定義する3つの新たなトレンドを特定しました。

1. ソフトウェア開発は、従来の遅く線形的なプロセスから、迅速な進化プロセスへと移行します。
2. ソフトウェア全体の価値は高まりますが、ソフトウェア開発の限界費用が下がるにつれて、個々のアプリケーションの価値は急落します。これは、最小限の限界費用でソフトウェア開発をサポートできるインフラストラクチャが必要であることを意味します。重要なのは、これらの小さく一時的なデータベースのいずれかが、大量のトラフィックを伴う本番システムになる可能性があるという事実もアーキテクチャが考慮に入れる必要があり、シームレスで弾力的な成長をサポートする能力が基本的なアーキテクチャ要件となることです。
3. オープンなエコシステムは、単なる好みではなく、厳格な運用要件となります。

これらの各トレンドと、Lakebaseがそれらをサポートするためにどのように独自に設計されているかを詳しく見ていきましょう。

迅速な進化的ソフトウェア開発

ソフトウェア開発ライフサイクルの大部分は、歴史的に非常にコストがかかるものでした（コード作成、テスト、運用）。そのため、新しいアプリケーションの構築と運用には多大なエンジニアリング投資が必要でした。その結果、従来のソフトウェア開発は、慎重な計画と比較的線形的なプロセスに最適化されていました。

エージェントはこのダイナミクスを変えます。アプリケーションは数分で生成、変更、再デプロイできるようになりました。開発者とエージェントは、慎重に設計された1つのシステムを構築する代わりに、可能な実装の広大な空間をますます探索しています。開発は進化アルゴリズムに似てきています。

1. アプリケーションの初期バージョンを生成する。
2. 異なるスキーマ、プロンプト、またはロジックを持つバリアントを迅速に作成する。
3. 結果を評価する。
4. 最も成功したバージョンから開発を続ける。

複雑さにもよりますが、各進化的イテレーションは数秒から数時間かかることがあり、これはLLM登場前の開発サイクルよりも100倍から1000倍高速です。実際、Lakebaseの本番環境からのテレメトリによると、平均して各データベースプロジェクトには約10のブランチがあり、ネストされたブランチを持つ一部のデータベースでは500以上のイテレーション（つまり、進化における500回の反復）に達する深さがあります。

Gitのようなコードインフラストラクチャは、このワークフローをすでに非常によくサポートしています。開発者やエージェントは、git checkout -b を使用してコードベースのブランチを瞬時に作成できます。しかし、従来のデータベースインフラストラクチャでは、データベースの状態を迅速かつ費用対効果の高い方法でブランチする手段がありません。

Lakebaseは、このエージェントによる進化的ワークフローをネイティブにサポートするように設計されています。エージェントは、本番データベースまたはテストデータベースのブランチを瞬時に、ほぼゼロコストで作成できます。Lakebaseはストレージ層でO(1)のメタデータコピーオンライトブランチメカニズムを使用するため、高価な物理データコピーは不要です。コードと並行してデータをブランチするだけで、実験期間中のみデータベースのコンピューティング費用を支払います。

コスト感度

前述のとおり、ソフトウェア全体の価値は高まりますが、ソフトウェア開発の限界費用が下がるにつれて、個々のアプリケーションの価値は急落します。多くのエージェント生成サービスは、小規模な社内ツール、プロトタイプ、または特定のワークフローです。これらは、たまにしか実行されないか、非常にバースト性の高いイベント駆動型ワークロードに対応する場合があります。

この世界では、最小限の限界費用/増分費用で新しいソフトウェア開発をサポートできるインフラストラクチャが必要です。アプリケーション自体が限定的または実験的な価値しか提供しない場合、月額数百ドルを最低価格として課すデータベースは正当化できません。当社のデータによると、これらのエージェントアプリケーションの約半分で、データベースコンピューティングの寿命は10秒未満です。

従来のデータベースは、固定のプロビジョニングと運用オーバーヘッドを持つ常時稼働のインフラストラクチャコンポーネントとして設計されていました。このモデルは大規模で安定したアプリケーションには適していますが、アプリケーションが多数、一時的、短命である場合には経済的に破綻します。

Lakebaseのサーバーレスで弾力的な性質は、このコスト上の要請に直接応えます。コンピューティングインスタンスをストレージ層から完全に分離することで、Lakebaseは負荷に基づいてデータベースコンピューティングをサブ秒単位で自動的にスケールできます。重要なのは、利用されていないときにはデータベースをゼロにスケールダウンし、コストフロアを完全に排除し、ほぼゼロのアイドルコストを実現することです。

小規模から大規模への成長

エージェント駆動型開発の性質上、テスト、プロトタイピング、特定のワークフローのために、大量の小さく一時的なデータベースが常に作成されています。重要なアーキテクチャ上の課題は、開発者やエージェント自身が、これらの初期段階のアプリケーションのどれが突然成功し、大規模な本番スケールを必要とするかを予測できないことです。

したがって、データベースアーキテクチャは、小さく低コストのインスタンスから、大量のトラフィックを伴う本格的な本番システムへの シームレスで弾力的な成長を本質的にサポートする必要があります。この移行は、ユーザーによる手動での再プラットフォーム化、プロビジョニング、または複雑な移行手順を必要とせずに行われる必要があります。アーキテクチャ自体が進化を処理し、ほぼゼロから大規模な容量へと瞬時にスケールできる能力は、エージェントによる探索がデフォルトの開発モデルとなる世界において、基本的な要件となります。

オープンソースエコシステム

エージェントシステムは、公開されている膨大なソースコードと技術文書のコーパスでトレーニングされたLLMからその能力を引き出します。このトレーニングバイアスにより、エージェントはオープンソースエコシステム、API、およびエラーセマンティクスに深く運用的に精通しています。

Postgresのようなデータベースは、オープンソースの世界に深く組み込まれています。そのインターフェース、動作、エラーコードは、現代のモデルが学習するトレーニングデータ全体に現れます。その結果、エージェントはそれらに対してクエリ、スキーマ、統合をはるかに信頼性高く生成できます。プロプライエタリなデータベースは、エージェントがそれらを効果的に操作するための十分なコンテキストを欠いているため、本質的な不利に直面します。

エージェント駆動型開発にとって、オープン性はもはや哲学的な好みではなく、信頼性の高い自動化のための実用的な要件です。しかし、この要件はクエリインターフェースだけでなく、ストレージ層自体にも及ぶ必要があります。第2世代のクラウドデータベースはオープンソースの実行エンジンを使用するかもしれませんが、データは依然としてプロプライエタリな内部ストレージ形式にロックされます。

LakebaseはPostgres上に構築されていますが、オープン性をさらに一歩進めています。データは標準のオープンなPostgresページ形式で、クラウドオブジェクトストレージ（データレイク）に直接保存されます。これにより、エージェント、外部分析エンジン、および新しいツールが、単一のプロプライエタリなコンピューティングエンジンによってボトルネックになることなく、データとネイティブにやり取りできるようになります。

エージェント時代のデータベース

この変化は仮説ではなく、すでに進行中です。DatabricksのLakebaseサービスでは、AIエージェントが人間ユーザーの約4倍のデータベースを作成しています。

このデータポイントは、上記の傾向を単一のグラフにまとめています。エージェントはデータベース環境を活発に作成します。実験のためにインスタンスを立ち上げ、テストのためにブランチを作成し、完了したら破棄します。これらのワークロードを処理するインフラストラクチャは、経済的かつ運用的にこのパターンをサポートする必要があります。

コスト効率、俊敏性、オープン性といった特性は常に望ましいものでした。しかし、エージェント型ソフトウェア開発の台頭により、これらは「あれば良いもの」から「基本的な要件」へと変化しました。高いコストを課したり、ブランチングの基本機能が不足していたり、データを独自の形式でロックしたりするデータベースは、ソフトウェアの構築方法からますます外れていくでしょう。

これこそがLakebaseの設計思想です。AI主導の開発が生み出す特定の経済的および技術的現実、すなわちゼロコストでの進化的ブランチング、真のスケール・トゥ・ゼロの弾力性、レイク上でのオープンなPostgresストレージ、そして自己管理型運用に対応するために構築されました。エージェントがソフトウェアの構築と進化にますます参加するにつれて、この新しい世界に最適なデータベースは、実験、オープン性、および弾力性を最初から考慮して設計されたものとなるでしょう。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事