エージェント・データ・スタック：なぜすべてのAIエージェントに独自のデータ・スタックが必要なのか

中央集権型から分散型エージェント・データへの移行

AIエージェントは、データアーキテクチャの根本的な転換を必要としています。SaaS時代の中心的なデータプラットフォームから、各エージェントが独自のサンドボックス化されたデータ・スタックを持つ分散型モデルへの移行です。この移行が必要な理由は、エージェントが24時間365日、しばしばループ内で動作し、従来のインフラストラクチャを圧倒するようなクエリ負荷を生み出し、本番稼働中のデータベースに直接アクセスを許可すると重大なセキュリティリスクを引き起こす可能性があるためです。

エージェントにとってのモダン・データ・スタックの失敗

従来のモダン・データ・スタックは、中央集権的なシステムとETL (Extract, Transform, Load) パイプラインに依存しています。このモデルは、以下のいくつかの理由からAIエージェント時代には不十分です。

• レイテンシと提供スピード: ETLパイプラインの構築には数週間から数ヶ月かかることがありますが、AIエージェントのユースケースは、競争力を維持するために迅速に提供される必要があります。
• データの多様性: エージェントは、分析用データだけでなく、OLTPデータベース、document DBs、およびメッセージバスを含む幅広いデータソースへのリアルタイムアクセスを必要とします。
• インフラストラクチャの負荷: エージェントによるワークロードは、人間による利用よりも桁違いに大きな負荷を生み出します。Luke Kimは、最近のGitHubの停止事例を、エージェントによるユースケースの急増がもたらした結果の一部であると述べています。
• セキュリティリスク: エージェントへの直接的なデータベースアクセスは危険です。Kimは、AIエージェントが本番データを破壊した事例や、Lovableにおけるバックエンド・データベースの制御不足によるセキュリティインシデントを引用しています。

提案される解決策：エージェント・データ・スタック

データのアクセシビリティとシステムの安定性の間の衝突を解決するために、提案されているアーキテクチャは、各エージェントに独自の分離されたデータ・スタックを提供することです。このスタックは、エージェントと組織のバックエンド・データ・システムとの間の、安全でファイアウォールで保護されたレイヤーとして機能します。

アーキテクチャと実装

エージェントに本番システムへの直接的なネットワークアクセスを許可する代わりに、エージェント・データ・スタックは、意図的にプロビジョニングされた安全なローカル・データセットを提供する「サイドカー」として機能します。

このアーキテクチャの主な機能は以下の通りです：

• フェデレーテッドSQLクエリ: Parquet, Iceberg, Snowflake, MySQL, MongoDB, および Elasticsearch、ならびにHTTP APIs, GitHubデータ, およびファイルシステムを含む、多様なバックエンド・ストアへのクエリ能力。
• ローカル加速: 一貫貫したパフォーマンスを確保し、バックエンドの過負荷を防ぐために、データのワーキングセットはDuckDB, SQLite, または Arrowなどの組み込みデータベースにレプリケーションされます。これにより、エージェントのための高速なローカル・ループバックが作成されます。
• ローカル・モデル・サービング: エージェントのワークフローを可能な限りローカルに留めるため、データと同じマシン上でモデルをロードしてサービングします。

実践的な応用：SREエージェントのデモ

分離されたデータ・スタックの有用性を実証するために、KimはOpen Clawで構築されSpice AIによって駆動されるSRE (Site Reliability Engineering) エージェントのデモを行いました。エージェントは本番システムから分離されているため、ライブ環境の安定性を損なうことなく、ログ、メトリクス、およびデータベースへの広範なアクセス権限を付与することが可能です。

インシデント解決ワークフロー

デモでは、SREエージェントが以下のステップを通じて、ライブサイトのインシデント解決を支援しました：

1. 検知: エージェントは、注文のレイテンシが高まっていることに関するGrafanaの警告を受け取りました。

2. 診断: エージェントは、本番データベース、モニタリングログ、およびGitHubにMarkdown形式で保存されている非構造化トラブルシューティング・ガイド (TSGs) をクエリして、原因を特定しました。

3. 初期緩和策: エージェントは、負荷の増加に対処するため、注文サービスを3つのレプリカにスケーリングすることを推奨しました。

4. 二次的なトラブルシューティング: スケーリングによってエラー率が増加した際（データベース接続制限のため）、エージェントはデータを再度分析し、接続プーラーの問題を特定しました。

5. 最終的な解決策: エージェントは、接続プーラーのモードを「session」から「transaction」に変更することを推奨し、これによりサービスの安定性が無事に復旧しました。

6. 事後分析 (Post-Mortem): エージェントは、注文の失敗に影響を受けた特定の顧客を特定し、顧客対応に必要なデータを提供しました。

AIインフラストラクチャに関する技術的な教訓

• 分離は実現手段である: エージェントをバックエンド・システムから分離することで、組織はエージェントに、より多様な本番稼働中のデータへのアクセスを安全に許可できるため、結果としてエージェントをより強力にすることができます。
• ハイブリッド・データ・アクセス: 効果的なエージェント・スタックは、フェデレーテッド・アクセス（広範なアクセス）とローカル・レプリケーション（速度と安全性）を組み合わせる必要があります。
• 統合インターフェース: エージェントは、データ・スタックを標準的なデータベース、検索エンジン、またはOpenAI endpointのように扱うことで、データ・スタックとやり取りを行います。これにより、LLMのツール呼び出しプロセスが簡法化されます。