エージェントシステムを左右する4つのデータアーキテクチャの決断

※このブログは2026年03月26日に公開された英語ブログ「Four Data Architecture Decisions That Make or Break Agentic Systems」の拙訳です。

編集者注：この記事はThe New Stackに初出のものを、許可を得て転載しています。オリジナル版はこちらからご覧いただけます。

重要なポイント

• エージェント型システムには、分離性・弾力性・継続的な変化に対応できるアーキテクチャが必要です。
• コンピュートとストレージの分離、およびワークロード同士の分離は、確実なスケーリングに不可欠です。
• コストの可視化は、急速に増加するエージェントのワークロードを適切に管理し、支出の肥大化を未然に防ぐために重要です。
• オブジェクトストレージとオンライン変更により、ダウンタイムなしでリカバリ、スケール、進化が可能になります。

前回のSaaS (Software as a Service) プラットフォームの拡大局面で成功を収めたデータチームは、単に流行を追いかけたチームではありませんでした。彼らは、クラウドファーストの運用体制を導入し、コストとリソースの状況を可視化し、変化する状況に迅速に対応できるアーキテクチャを選択するという、いくつかの賢明な決断を下したチームだったのです。

結局のところ、それらはまさにエージェント時代の今、求められている手法そのものなのです。

データチームがAIへの移行をどのように進めているかを見ると、ある明確な傾向が見えてきます。パフォーマンスとコストをしっかりと管理できているチームほど、エージェントのサポートをスムーズに行えていました。こうしたチームは、すでにテナントの分離を実践し、業務時間中にオンラインでの変更を行い、オブジェクトストレージを活用したリカバリを活用していました。つまりエージェントが必要とするものはすべて、すでに整っていたのです。彼らに求められたのは、それらの原則を新しいタイプのユーザーにも適用することだけでした。

まず、「エージェントこそが新たなユーザーである」という前提から始めましょう。エージェントが他のユーザーとどう異なるのか、そしてエージェントをどのようにサポートするのが最適なのかについて見ていきます。その過程で、大規模な運用能力に影響を与える4つのアーキテクチャ上の要素についても解説します。最後に、現在のプラットフォームがエージェント主導のワークロードに適しているかどうかを評価するためのチェックリストをご紹介します。

エージェントこそが、あなたの新たな「ユーザー」です

ほとんどのデータプラットフォームは、比較的安定的で予測可能な需要を持つ人間やサービス向けに構築されています。一方、エージェントシステムはそれとは大きく異なります。これらは一時的にしか使わないアプリケーションを起動し、実験を実行し、データ移行をトリガーし、新しいデータセットを分岐させ、そしてそれらをすべて破棄します。こうした処理は、多くの場合並行して、かつ予測不能な形で実行されます。

Manusのような企業を例に、私たちはこの状況を実際に目の当たりにしてきました。同社は汎用的なエージェント型AIプラットフォームを提供しており、その「ワイドリサーチ」エージェント群は毎日、数千もの一時的ななワークロードを起動しています。もはや単一のモノリシックなデータベースを管理しているのではなく、裏側で数百万もの小さな一時的なブランチのような環境を調整しているのです。

大規模な環境において、エージェントに必要なのは、単一で絶えず拡大し続けるデータベースではありません。実際には、何百万もの小さな独立したデータベース、あるいはブランチが次々と出現しては消えていくような仕組みです。この前提を受け入れれば、エージェント型アーキテクチャには以下の4つの要件が自ずと導き出されます：

• デフォルトでの分離：テナント単位またはエージェント単位の境界設定により、実験的な処理が他全体に影響を及ぼす事態を防ぎます。
• 営業時間中のオンライン変更：スキーマやインデックスの調整は、サービスレベル目標 (SLO) に定められたp95 / p99レイテンシーの範囲内で行われなければなりません。
• 配置と割り当て：ホットデータは低レイテンシーなコンピュートの近くに配置し、コールドデータは低コストのストレージに保存する必要があります。ノイズの多いテナントは隔離されなければなりません。
• ライフサイクルの自動化：メタデータの整合性を保ち、コストの所在を明確にした上で、数秒で環境を作成・廃止できる機能が必要です。

以下に、エージェントユーザーのニーズに応える4つの設計上の選択肢をご紹介します。

1. 重要な2つの分離

エージェントは共有リソースを急速に消費してしまう可能性があります。これを防ぐには、まずコンピュートをストレージから分離し、データを移動させることなくクエリ処理能力を拡張できるようにします。さらに、コンピュート同士も分離し、オンライントランザクション処理 (OLTP)、分析処理、メンテナンス処理、それぞれに専用の実行レーンとサービスレベル目標 (SLO) を持たせる必要があります。

コンピュートとストレージの分離

ステートレスなコンピュートエンジンを、耐久性のある共有オブジェクトストレージに接続することで、以下のことが可能になります：

• 弾力的なスケーリング：複雑なデータコピーや休日の移行作業を必要とせずに、クエリ処理能力の増減が可能です。
• 予測可能なリカバリ：新しいノードはストレージから状態を取得し、キャッシュをウォームアップすることで、他のサーバーの負荷を飽和させることなくサービスを開始できます。
• 迅速なクローニング：物理的な完全コピーではなく、メタデータからコピーオンライトのブランチを迅速に構築できます。

検証事項：

• データを再配置することなく、数分でコンピュートノードを追加できますか？
• 新しいノードは、既存のノードではなくオブジェクトストレージからデータを取得していますか？
• クローニングとブランチ作成は増分処理でスペース効率が良いですか？

コンピュート同士の分離

何千ものエージェントが同時にデータのブランチ作成、インデックスの構築、クエリの送信を行っている場合、SQLフロントエンド、分析用リーダー、バックグラウンドメンテナンス (コンパクション、バックフィル)、バックアップ / リストア、およびコントロールプレーンを独立してスケールさせ、ガバナンスを効かせることで、それらを円滑に稼働させ続ける必要があります。

検証事項：

• バックフィルをOLTPトラフィックとは独立してレート制限できますか？
• 分析スキャンには独自のリソースとガードレールがありますか？
• あるコントロールプレーンのバージョンアップグレードを、別のコントロールプレーンのメンテナンスウィンドウを確保することなく実行できますか？

2. コストを可視化する (そして対策可能に)

従来のデータプラットフォームは、「万が一」に備えてリソースの予備を維持しながら、CPU使用率20〜25%でアイドル状態にあることがよくあります。それは人間のユーザーであれば許容範囲内ですが、エージェントが何千もの短寿命のワークロードを立ち上げる環境では維持不可能です。解決策は、エンジニアがすでに監視しているのと同じパネルで、例えばリクエストユニット (RU) による計測などを通じて、クエリあたりのコストを可視化することです。

そうすることで、エンジニアはどのクエリを最適化すべきか、どのような節約が期待できるかを知ることができます。製品担当や財務担当は実際の作業に関連付けた予算や上限を設定でき、プラットフォームチームは勘ではなく実際の支出に基づいて改善を提案できます。

検証事項：

• テナント、アプリ、クエリダイジェストのコスト所在を明らかにできますか？
• 予算と上限を自動的に適用できますか？
• レイテンシーとコストの回帰テストに関連付けられた「効率の悪いトップ5レポート」ループがありますか？

3. オブジェクトストレージをバックボーンとして扱う

エージェントアーキテクチャにおいて、データバックボーンにオブジェクトストレージ (S3 / Google Cloud Storage / Azure Blob) を使用することは、オプションではなく必須です。これにより、共有オブジェクトストアからデータを取得し、超低レイテンシーのためにホットデータをローカルにキャッシュするというコンテキスト認識型のスケーリングが可能になり、データベースが常にその瞬間に適したキャパシティであることを保証します。スケールアウトやリカバリの際、新しいコンピュートは他のサーバーからコピーするのではなく、耐久性のあるストレージから状態を取得する必要があります。バックアップや長期スナップショットもそこに保存すべきです。

メリット：

• 予測可能なスケールとリカバリ：拡張時やフェイルオーバー時のノード間スラッシングを低減します。
• 階層化による経済性：論理的に検討し、予算を立てることができるホット / ウォーム/コールドのデータ保存を最適化します。
• 高速なデータベースブランチ作成：データベースのクローン作成が、ポインタ操作とオブジェクトストアのセマンティクスによる処理に置き換わります。

検証事項：

• バックアップ、スナップショット、ブランチのメタデータは、デフォルトでオブジェクトストレージに保存されますか？
• 障害発生後、新しいノードがトラフィックの提供を開始するまでにどれくらいの時間がかかりますか？
• 不要になったブランチやオブジェクトを自動的にクリーンアップできますか？

4. オンライン変更を主要な機能として扱う

エージェントがユーザーである場合、変化は絶え間なく起こります。スキーマの進化、インデックス作成、データの移動、アップグレードは、何が起きているかを明確に可視化した状態でオンラインで行われなければなりません。

実践的な形は以下の通りです。

• マルチバージョン並行処理制御を備えた3フェーズのスキーマ変更 (準備→再編成→コミット) により、バックフィル実行中も読み取り/書き込みを継続。
• P95 / p99の予算を尊重するレート制限されたメンテナンス。
• 自動リーダー選出を備え、メンテナンスウィンドウを必要としないローリングアップグレード。

検証事項：

• ピーク時に稼働中のテーブルにインデックスを追加し、SLO内のp95 / p99を維持できますか？
• メタデータロック取得期間は短く予測可能ですか？
• パイプラインに事前確認、自動中断のしきい値、ロールバックプランが組み込まれていますか？

避けるべきアンチパターン

やるべきことは以上の通りです。避けるべき事項を以下に挙げます。

• シャーディングの複雑さ：アプリケーションレベルのシャーディングは一見シンプルに見えますが、ルーティング、リバランス、フェイルオーバー、クロスシャード結合を継続的に自分で管理する必要が出てくるため、長期的には非常に複雑になります。
• 単一の巨大プール：すべてのコンピュートを同一のリソースとして扱うと、ノイジーネイバー問題が発生しやすくなり、テールレイテンシーが悪化します。
• 見えない支出：インスタンス単位の課金モデルでは、クエリ単位の無駄が見えなくなっていまします。見えないものは管理できないことを忘れないでください。
• 他ノードからのコピーへの依存：負荷の高い隣接ノードに依存するリカバリやスケールアウトのプロセスは、高負荷がかかった際に、システム全体が崩壊してしまう脆弱性を抱えています。

最小限の評価チェックリスト

エージェントワークロード向けのプラットフォームを比較するために、以下のチェックリストを使用してください。

1. データベースのプロビジョニング：分離されたデータベース、スキーマ、ブランチを1分あたりにどれだけ作成できるかを確認します。また、それらがどのようにトラッキングされ、不要になった際にどのように廃棄されるかを確認します。
2. 2つの分離：コンピュートとストレージの独立性、およびコンピュート同士の独立性が、本番の負荷条件下で維持されるかを確認します。
3. コストモデル：エンジニアがテナントやアプリケーション単位でクエリコストをどれだけ正確に監視できるかを確認します。また、コスト上限の仕組みと、その強制方法を確認します。
4. オブジェクトストレージ：ノード追加およびリカバリがオブジェクトストレージからデータを取得して行われることを実証します。また、サービス提供開始までの時間を計測します。
5. オンライン変更：ピーク時にインデックス追加が可能かをテストします。その際のp95 / p99レイテンシーー、エラー率、および処理中断の閾値を確認します。
6. 障害訓練：リーダーノードまたはアベイラビリティゾーン (AZ) へのアクセス意図的に停止させます。その際のフェイルオーバー、クライアントリトライ、テールレイテンシーの挙動を観察します。
7. メタデータ管理：放置されたブランチやオブジェクトが、手動対応なしでガベージコレクションされることを確認します。

エージェント型システムは、インフラに対して全く新しいアプローチを必要とするわけではありません。むしろ、エージェントに適したアーキテクチャは、大規模な現代的ユースケース全般に適したアーキテクチャと本質的に同じです。ただし、エージェントはその必要性を強制させる存在です。

データチームは、スケールが遅く運用が難しいモノリシックなプラットフォームに固執する余裕はありません。エージェントの普及によって、従来のアーキテクチャは限界に達します。しかし、多くの成功しているデータチームが示しているように、柔軟性・可視性・性能を重視し、上記の手法に基づいて設計すれば、数百万規模のユーザーを抱え、その多くが人間ではない場合でも、より高速にデリバリーでき、週末対応の障害対応も大幅に減らすことが可能です。

エージェントワークロード向けのアーキテクチャを評価する準備はできましたか？ブログ「エージェントシステムを左右する4つのデータアーキテクチャの決断」も併せてご覧ください。