Agent Bucket：兆単位の Agent ネイティブストレージバケット

AI Agent が雨後の筍のように現れている今日、開発者はかつてないほどのスピードで想像力豊かなインテリジェントアプリケーションを構築しています。コードの作成を支援するプログラミングアシスタントから、一言で映画を生成する創作ツール、そして常に待機している個人のインテリジェントアシスタントまで、Agent は私たちとデジタル世界のインタラクションを再構築しています。この潮流の背後には、Serverless アーキテクチャ（Lambda など）、大規模言語モデル（LLM）、クラウドストレージ（S3、TOS など）を活用し、Vibe Coding と組み合わせることで、誰でも 30 分以内に独自の AI Agent を迅速に構築できるという共通認識がますます明確になっています。

「使える」から「使いやすい」へ、Agent 開発者が「おもちゃ」から「本番環境向けアプリケーション」へ移行するには、依然として課題を克服する必要があります。ビジネスが膨大な数のユーザーに拡大するにつれて、開発者は非常に複雑な課題に直面せざるを得ません。それは、膨大な数のエンドユーザーのために、オブジェクトストレージ上に完全なストレージソリューションを構築する方法です。ほとんどの開発者にとって、これは技術的なハードルであるだけでなく、Agent の大規模な配布を妨げる溝でもあります。Agent Bucket は、AI ネイティブのストレージ設計を通じて、マルチテナントシステムの構築プロセスを完全に簡素化し、より使いやすい Agent 機能を提供することを目的としています。

億単位のユーザーが押し寄せると、従来のオブジェクトストレージは「役に立たなくなる」

あなたが大ヒットした AIGC アプリケーションを開発したと想像してください。各ユーザーは大量の画像、ビデオ、および一時ファイルを生成して保存します。開発者として、S3 や TOS のような成熟したスケーラブルなオブジェクトストレージサービスを選択するのは当然です。しかし、問題はここからです。膨大な数のユーザーのデータをどのように管理するか？

2022 年の S3 のブログ「Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3」では、2 つの方法、「テナントごとに独立した S3 バケットを使用する」と「プレフィックスに基づいて分離された共有 S3 バケット」について説明しています。

ユーザーごとに独立した「バケット」を作成する：これはユーザー数が少ない場合は実行可能ですが、ユーザー数が数万、数百万に増加すると、バケットの数が急速に爆発的に増加し、管理コストとリソース制限が耐えられなくなります。S3 はリージョン全体で合計 10000 のバケットクォータを提供しますが、人気の AI 機能を考えると、1 万ではまだ十分ではありません。

AWS S3 Bucket-Per-Tenant Model

同じバケット内で「プレフィックス」を使用してユーザーを区別する：これが主流のソリューションになりました。たとえば、ユーザー A のファイルはすべて user-a/ で始まり、ユーザー B のファイルは user-b/ で始まります。これは、コンピューターでフォルダーを使用してファイルを管理するのと同じです。ただし、オブジェクトストレージにはネイティブのフォルダーが存在しないため、このソリューションは「K-V」ストレージシステムで「共通プレフィックス」（Prefix）を使用してマルチテナントを区別します。

AWS S3 Object Key Prefix-Per-Tenant Model

この「バケット」または「プレフィックス」に基づくソリューションは、過去 10 年間広く採用されてきました。ただし、次の問題があります。

マルチテナント分離：すべてのユーザーのデータが同じバケットに混在しているため、1 人のユーザーの異常な高頻度アクセスが他のすべてのユーザーに影響を与え、「近隣効果」が発生する可能性があります。パフォーマンス分離、障害分離は不可能です。
権限管理：複雑な権限ポリシー（IAM Policy）の維持は難しく、構成ミスが発生しやすく、ユーザーデータが誤ってアクセスされる可能性があります。特に、他のクラウドサービスとやり取りする必要がある場合は、リスクエクスポージャーが大きくなります。
コストの明確化：各ユーザーが実際にどれだけのストレージスペースを消費し、どれだけのトラフィック料金が発生したかを正確に知ることは困難です。使用量に基づいて有料ユーザーに請求したい場合、請求と測定があいまいになります。なぜこれらの基本的なニーズに対して、Agent 開発者はオブジェクトストレージの実装を「重い」と感じるのでしょうか？その原因を深く探ると、現在のクラウドネイティブアーキテクチャにおいて、S3のような「オブジェクトストレージ」と従来の「ファイルシステム」の間には、巨大な空白地帯が存在するからです。オブジェクトストレージ（S3/TOS）の本質は「フラット化」であり、その設計当初の目的は、大量のデータを単純に格納することでした。それは巨大な倉庫のようなもので、容量はほぼ無限ですが、論理構造は極めてシンプルです。オブジェクトストレージは、高度なディレクトリ管理、細粒度のメタデータ制御、そして真のテナント認識をネイティブに備えていません。開発者が「フラット」なS3上で、ハードコーディングされたプレフィックスを使って「立体的な」マルチテナントファイルシステムをシミュレートしようとすると、実際には「静的なKVストレージ」を使って、「ディレクトリセマンティクス、強力な隔離」を持つAgentアプリケーションのファイルアクセス方式を担おうとしていることになります。つまり、Agentはファイル管理のために追加のトークンを消費し、マルチテナントの権限と隔離を制御・解決する必要があります。これらの追加のトークン消費は、S3が定義するシンプルなストレージサービスがAgentにとって十分シンプルではないことを示しています。

2025年のS3ブログ「Design patterns for multi-tenant access control on Amazon S3」では、S3 Access Pointについてさらに詳しく説明されています。これは、複数の仮想ネットワークアクセスポイントを作成し、各アクセスポイントにカスタマイズされたアクセスポリシーを設定できることを意味し、ネットワークスケジューリングのレベルでマルチテナントシナリオに対するいくつかのソリューションを提供します。

Agent Wonderland

理想的なAgent開発者は、AI Agentを開発する際に、「Agent SDK + ストレージ + MaaSサービス」に基づいて、完全にサーバーレス化されたAgentを構築できます。

Agentは完全にサーバーレスで実行可能
Vibe Codingの手法で、既存の製品能力を組み合わせてAgentを構築可能
メンテナンスが必要なのは「ADK」のpythonスクリプトのみ
ストレージはオブジェクトストレージを使用
AI能力は豆包を使用
理論上、ECSまたはその他のインスタンス型製品は不要

同時に、ストレージは以下の能力を提供する必要があります。

Agentは、オブジェクトセマンティクスを持つストレージ（ファイルの保存）を持ち、マルチテナントアクセス能力を提供し、100万レベルから始まり、億レベルまで拡張可能
Agentは、各ユーザーに独立したスペースを提供可能（複数のビジネス間、ビジネスまたはuidが重複する可能性あり）
Agentは、各ユーザーの帯域幅を直接設定可能、ユーザーオブジェクトの総サイズ上限を設定可能
Agentは、ユーザーに基づいて課金、監視、観察が可能
Agentは、各ユーザーのファイルにアクセスポリシーを設定可能

Agent Bucket：AI Agentに「マルチテナントネイティブ」遺伝子を注入する

この問題を根本的に解決するために、私たちは全く新しいオブジェクトストレージパラダイム——Agent Bucketを提案します。その核心的なイノベーションは、従来の「バケット」と「オブジェクト」の間に、新しいネイティブリソース階層：オブジェクト集合を導入することです。

この設計の中核となる考え方は非常にシンプルです。各エンドユーザーに、専用のObjectSetを割り当てるのです。ObjectSetを、各ユーザーのために作られた「データセーフティボックス」または「クラウド上の個人スペース」と想像してください。それは論理的にはあなた（開発者）のBucketに属していますが、物理的および管理的には、独自の「個性」と「ライフサイクル」を持っています。Agent Bucket は各バケットで1億個の ObjectSet をサポートします。これにより、数億規模のエンドユーザーに余裕を持ってサービスを提供できます。まるで各エンドユーザーが独立したストレージ空間で「生活」しているかのように、マルチテナントストレージ管理に頭を悩ませる必要はありません。

ObjectSet 設計——Agent フレンドリーな機能

Agent Bucket の ObjectSet は、単に階層を追加しただけでなく、マルチテナント環境で最も厄介なニーズを、すぐに使えるネイティブ機能に変えます。データの所有権が ObjectSet レベルで明確になると、これまで実現が難しかった一連の機能が自然に実現します。

ネイティブ分離：ObjectSet レベルでは、各ユーザーに独立した QPS、帯域幅制限、および容量クォータを設定できます。有料ユーザーのエクスペリエンスは保証され、無料ユーザーの異常な動作が他のユーザーに影響を与えることもありません。これは真の障害ドメイン分離であり、「隣人」が互いに干渉しなくなります。
ネイティブ権限：各 ObjectSet は独立したドメインを持つことができます。つまり、ユーザー A には user-a.yourapp.com の専用アクセスアドレスを提供でき、ストレージバケット全体のドメインを公開する必要はありません。さらに巧妙なのは「二重ロック」設計です。最初のロックはクラウドサービスプロバイダーが発行する一時的なアクセス認証情報（STS）であり、アプリケーションレベルでのアクセス許可を制御します。2番目のロックは ObjectSet の独立したドメインであり、ネットワークレベルでアクセス要求をユーザー自身のデータ空間にロックします。これにより、データセキュリティが大幅に向上します。
ネイティブ監視：監視ダッシュボードでは、バケット全体の概要データしか表示できなくなりました。ObjectSet ごとに監視グラフを分解し、どのエンドユーザーが大量のアクセスを行っているかを明確に把握し、正確な運用と最適化の意思決定を行うことができます。
ネイティブ機能のシンクダウン：これまでバケットレベルでのみ設定できたポリシーを、各ユーザーにシンクダウンできるようになりました。さまざまなレベルのユーザーに異なるデータライフサイクルを設定したり、各 ObjectSet に異なる暗号化キーを使用したりして、よりきめ細かく安全なデータ管理を実現できます。
ネイティブ計測：各ユーザーがどれだけのストレージスペースを使用しているかを知りたいですか？ストレージコストを各ユーザーに正確に割り当てたいですか？今では簡単になりました。Agent Bucket は、各 ObjectSet の容量と使用状況を自動的に統計し、請求とアカウントの分割を明確にします。
ネイティブ課金：開発者はコスト配分を簡単に実現し、ストレージによって発生する費用を各エンドユーザーに正確に反映させることができます。たとえば、A、B、C の異なるユーザーが実際に発生させたコストの割合に応じて差別化された料金を請求し、Agent の収益化のためのデータサポートを提供します。
ネイティブ容量上限：Agent の運用コストを制御するために、各 ObjectSet に Quota（容量上限）を設定できます。プリセット値に達すると、システムはそのユーザーが新しいファイルを生成し続けることを制限し、マルチテナント環境でのリソースの乱用を根本的に回避します。
ネイティブインテリジェンス：Agent Bucket は、Agent が従来のファイルの単純な「アクセス」の制限から抜け出し、Object にネイティブインテリジェンスを与え、Agent のワンストップ開発をより効率的にサポートできるようにします。ObjectSet は、ワンクリックでスマートインデックスを有効にし、従来の Object CRUD の機械的な操作に代わる、Agent フレンドリーなマルチモーダル質問応答機能を提供します。Agentself モードをワンクリックで有効にし、ベクトル、知識、モデル、プロンプトを接続して、シナリオ化されたサブ Agent 機能を直接公開することもできます。これにより、上位の Agent 開発者は主要なビジネスワークフローの作成に集中し、インテリジェントな収益化効率を最大限に高めることができます。

アプリケーション規模の爆発的な増加による技術的課題

Agent Bucket は、ObjectSet というネイティブな概念を導入することで、アプリケーション開発者に数億レベルのエンドユーザーデータを管理するためのエレガントで効率的な方法を提供します。各ユーザーのデジタル資産は、専用の ObjectSet に安全に保存され、分離、課金、およびクォータ管理が自然に実現されます。

アプリケーションの規模が急速に拡大するにつれて、大量の Set の管理の複雑さ、分離の難しさ、および物理的なボトルネックが同時に明らかになります。

大量のユーザーの階層化された管理の問題：アプリケーションが大量の異なるレベルのユーザーのリソースと機能を差別化して管理する場合、ユーザーの階層化されたメタデータを独自に設計および実装し、オブジェクトストレージ機能スイッチを関連付ける必要があります。Set のネイティブな概念に基づいて、開発者がユーザーの階層化をエレガントに管理できるようにすることは、アプリケーションの導入を加速するために重要です。- 単一クラスタの容量ボトルネック：Agent Bucket は論理的には無限に拡張できますが、そのメタデータはデフォルトで単一の物理クラスタに格納されます。バケット内のオブジェクトの総数が数千億、さらには数兆に達すると、単一クラスタの物理容量が超えられない上限になります。
アクセスポイントの共有問題：Agent のビジネスの多様性と膨大な数のユーザーが、アクセスポイント自体に大きなセキュリティリスクと爆発半径をもたらします。大量の異なるビジネスとユーザーの差異に基づいて動的なスケジューリングを行い、差別化されたセキュリティ、隔離、および高速化機能を実現する方法が課題となります。

Set Tagging：タグによるユーザーの階層化管理

ObjectSet は、ネイティブなタグ管理方式を提供し、Agent 開発者が簡単に set tagging 機能を使用して、ユーザーの階層化管理を完了できるようにします。開発者は、定義されたユーザーレベルごとにタグを割り当て、各タグに対して異なるクォータと特性を有効にできます。このタグが付けられたすべての ObjectSet には、対応するクォータと特性が適用されます。V1、V2、V3 の 3 つのレベルを例に説明します。

V1：デフォルトレベル、無料ユーザー。すべての ObjectSet のデフォルトタグ。最大 1GiB のデータを保存でき、パブリックネットワーク配信は 100mbps の帯域幅を超えられず、シングルストリームのダウンロード速度は 1mbps に制限されます。
V2：入門レベルの有料会員。最大 10GiB のデータを保存でき、パブリックネットワーク配信は 10gbps の帯域幅を超えられず、シングルストリームのダウンロード速度は 10mbps に制限されます。
V3：高度な有料会員。より大きなストレージ容量とパブリックネットワーク配信クォータを提供するだけでなく、追加のパブリックネットワークの低品質ネットワーク高速化と高性能メディア高速化機能を有効にすることもサポートします。

Agent 開発者は、さまざまなユーザーの成長段階に応じて、V1/V2/V3 tagging を柔軟に使用して、これらのユーザーが使用できるリソースと付加価値機能を管理できます。

Set Tagging ユーザー階層化管理

Set Slice：膨大なユーザーデータのネイティブな隔離

Agent Bucket 内の Set が数億に達し、オブジェクト数が数千億、数兆に達すると、「単一の Bucket のすべてのメタデータが 1 つの KV クラスタに集中している」という事実自体が、容量とパフォーマンスの両方のリスクをもたらします。

Set Slice は、「論理的には分割せず、物理的に分割する」という考え方を提供します。

論理的には、1 つの Agent Bucket のみを管理します。
物理的には、Set と Set 内のオブジェクト名の範囲に基づいて、メタデータを複数の Slice（スライス）に分割します。各 Slice は異なるクラスタに格納でき、複数の Set は自然に隔離され、単一の Set は水平方向に拡張されます。

Set Slice 物理分割

Set Slice は、ObjectSet 機能のさらなる拡張と保証であり、基盤となる物理容量の無限拡張の問題を解決すると同時に、上位の ObjectSet 管理モデルの安定性と一貫性を確保します。

管理境界の安定性：Agent Bucket のデータが複数の物理クラスタにまたがっていても、ObjectSet は依然として権限、クォータ、課金、および監視の唯一の基本単位です。開発者が ObjectSet に対して構成したポリシー（アクセス制御、容量上限など）は、関連するすべての Slices で自動的に有効になり、基盤となるデータの分布を気にする必要はありません。
単一の Set は線形に拡張可能：特定の ObjectSet のデータ量が急速に増加すると、そのデータは自然に複数の Slices に分散されます。クラスタ全体の拡張に伴い、ObjectSet の容量もシームレスかつ線形に増加するため、開発者は ObjectSet 自体を分割または移行するなどの破壊的な操作を行う必要はありません。
Set を跨いだリソース隔離：異なる範囲のオブジェクトを異なる物理クラスタに分散させることで、SetSlice はより高次元のリソース隔離を実現します。ObjectSet のクォータ管理と組み合わせることで、特定の「超大口」ObjectSet のデータ増加が単一クラスタのすべてのリソースを圧迫し、他の ObjectSet の安定性に影響を与えるのを効果的に防ぎ、全体的な容量リスクを制御可能にします。- 論理的な統一性と互換性：ビジネスと開発者にとって、基盤にいくつの Slice があっても、常に論理的に統一された Agent Bucket に直面します。バケット、ObjectSet、オブジェクトに対するすべての操作方法は変わらず、物理的な拡張が上位アプリケーションに対して完全に透過的になります。

Set AccessPoint：各ユーザーのアクセスポイントを分離する

Agent Bucket は、各 ObjectSet に対して独立したアクセスポイント（独立したドメイン名）を有効にし、アクセスポイント上で、差別化されたセキュリティ、分離、および高速化機能を拡張することをサポートしています。システムは、数億レベルの独立したアクセスポイントのスケジューリングと差別化された構成機能をサポートする必要があります。

独立したアクセスドメイン名 {$apid}。tos-objectset-ap.volces.com：2段階のセキュリティ保護

第1段階 Obscurity（隠蔽性）：ユーザー/ObjectSet ごとに独立したサブドメイン、apid の高エントロピーハッシュ、非常に低い衝突確率。アクセスドメイン名から特定のユーザーエントリを推測したり、総当たりで調べたりすることはできません。
第2段階 Containment（収束性）：Agent 開発者は、sts を使用して ObjectSet レベルのアクセス許可を配布します。sts が漏洩した場合でも、アクセス範囲を特定の ObjectSet の限られた有効期間内に制限できます。

ヒューリスティックなスケジューリングシステム：数億レベルのドメイン名スケジューリング戦略の計算

ユーザー/ObjectSet:tag ごとの差別化されたアクセス戦略
複数のユーザー/ObjectSet を異なるパブリックネットワークエントリに自動的に分散し、単一のエントリの障害がユーザー数に与える影響を制御します。
全地域での弾力的なスケジューリング。任意の単一エントリの障害/過負荷は、トラフィックの箱詰めと移動を自動的に完了します。
パブリックネットワークの高速配信ユーザーには、パブリックネットワーク伝送高速化タグを付け、高速化エントリを自動的にスケジュールします。
パブリックネットワークのリスクのあるユーザーには、リスクタグを付け、パブリックネットワークの分離エントリを自動的にスケジュールし、パブリックネットワークの帯域幅割り当てを削減します。
イントラネットのクロスドメインユーザーには、クロスドメインタグを付け、イントラネット専用線高速化パスを自動的にスケジュールします。
ローカルアクセラレータユーザーには、アクセラレータタグを付け、ローカルアクセラレータを自動的にマウントします。

Set AccessPoint スケジューリングシステム

プログラミングアシスタントから AI クラウドディスクまで、Agent Bucket の無限の可能性

Agent Bucket は Agent に完全なソリューションを提供し、ObjectSet の設計アプリケーションシナリオはこれだけにとどまりません。大量のエンドユーザーにサービスを提供する必要があるすべてのアプリケーションに簡単に拡張できます。

コードリポジトリ：これまで、企業または個人がクラウドでコードをホストする場合、アカウントの分離とアクセス制御を実現するために、オブジェクトストレージの上に「テナントシステム」を構築する必要がありました。現在、各開発者に専用の ObjectSet を割り当て、コードリポジトリ、ビルド成果物、および依存関係をまとめて含めることができます。Agent Skills も ObjectSet に自然に適応し、Skills のアップロードとダウンロードの配布は ObjectSet を介して強力な分離を提供し、Agent の実行時のノイズを回避します。
企業アルバムネットワークディスク：従来のアルバムまたはネットワークディスクサービスでは、すべてのユーザーの写真が同じバケットに混在し、プレフィックスでユーザーを区別することがよくあります。これは管理が複雑になるだけでなく、「隣人効果」が発生しやすくなります。ObjectSet に基づいて、各ユーザーの写真とビデオはそれぞれの Set に配置され、アクセスピークが互いに干渉しません。また、ユーザーごとに容量制限、バックアップポリシー、暗号化方式を設定して、「誰もが安全で制御可能なクラウドアルバム」を実現できます。
Hadoop データウェアハウス：企業データウェアハウスでは、異なるビジネスラインと異なるデータベースが同じ基盤となるストレージ上でリソースを共有することがよくあります。各データベースを ObjectSet にマッピングすることにより、企業は統一されたストレージ上でデータベースごとの分離とクォータ制御を実現できます。特に、ObjectSet は TOS 上に追加の権限レイヤーを提供し、既存の Proton on TOS を変更せずに、TOS 上に保存されている Database と Tables の分離とアクセス制御を提供します。 - モデルホスティングプラットフォーム：大規模モデルのホスティングシナリオでは、各モデルはサイズが大きいだけでなく、異なるバージョン、重み、推論構成に対応している可能性があります。各モデルに対して ObjectSet を作成することで、モデルの重み、Tokenizer、構成ファイル、および関連する評価データを同じスペースにまとめてホストできます。運用側は、異なるモデルに対して差別化された暗号化ポリシー、バックアップポリシー、および帯域幅制御を設定できます。同時に、ネイティブな計測機能を通じて各モデルの実際の使用コストを統計し、モデルごとの課金とリソーススケジューリングの基礎を提供します。
データ SaaS サービス：大量のターミナルユーザーを対象としたデータ配信プラットフォームは、多くの場合、多数のデータプロバイダーに同時に接続する必要があります。各プロバイダーのデータ境界を明確に保ちながら、「1つの大きなバケツがすべての人を妨げる」というパフォーマンスリスクを回避する必要があります。Agent Bucket を使用すると、各データプロバイダーは独自の ObjectSet を持つことができ、元のデータと処理結果を統一的に管理できます。さらに、独立したドメイン名、帯域幅、QPS クォータを通じて、異なるプロバイダーに対して差別化されたサービス保証とレート制限を提供し、「1つのプラットフォーム、複数のプロバイダー、相互に隔離され、制御可能な連携」を実現するデータ配信インフラストラクチャを実現します。

Reference: