ByteDance、Agent 時代のクラウドストレージ再構築「Storage Agent Family」を発表

Storage Agent Family: 代理时代重构云存储的“人机交互”

原创 | 火山引擎存储 | 2026-07-20 18:00 北京

系列定位： 本文是《从 Data Lake 到 State Lake：面向 Agent 时代的存储基础设施重构》的续篇。前作探讨了 Agent 时代下存储体系的三条主线：沙箱存储（Sandbox Store）、制品存储（Artifact Store）以及 Agent 观测与评测。本篇将聚焦于最贴近用户的一条支线——存储产品自身的 Agent 化，我们将其命名为“Storage Agent Family”。

从一个真实场景开始

一位负责 AI 数据运维的工程师，一天内需要多次登录火山引擎控制台。

仅创建一个用于训练的数据桶，就需跨越多个页面：创建桶、配置 KMS 加密、开启版本控制、修改 ACL（访问控制列表）、设置访问日志。一旦遗漏任何一步，审计部门便会找上门来。

下午发现图片无法打开，他不得不进入对象存储控制台，逐一排查权限、限流策略和 CORS 配置，在多个页面间反复切换。到了晚上，面对老板关于“上月账单为何上涨 30%

过去，构建一个生产级的存储桶需要在多个标签页之间反复切换，批量修改配置时也只能逐个点击或自行编写脚本。如今，只需清晰表达意图即可：

“帮我创建一个用于 AI 训练数据的存储桶，开启 KMS 加密和版本控制，关闭 ACL 公共访问权限，并接入访问日志。”

“列出我账号下所有华东 1 区域中对象数量超过 1000 的存储桶，统一开启访问日志。”

TOS Agent 将此类指令拆解为一条有序的执行链，逐步落地执行，过程全程透明。遇到批量变更或不可逆操作时，它会先进行影响预演（Dry-Run），清晰展示波及范围，随后等待用户确认——从而将繁琐的“多步操作编排”简化为一句话。

异常排查：从一条报错信息追根溯源并修复

线上访问出现问题时，根本原因可能涉及权限、签名、CORS 策略、限流或慢请求等，排查过程往往需要丰富的专业经验。TOS Agent 将接手这些繁琐工作：只需将一个无法打开的图片链接发送给它，它便会自动解析 URL 和报错信息，拉取访问日志与监控指标进行聚合分析，对照错误码释义定位根因，最终输出一份包含“现象→根因→修复建议”的完整结论——从单纯告知“为什么不行”，转变为真正帮你解决问题。

数据洞察：账单、热点与冷热分层，一次问清

TOS 的计费项目繁多，每个存储桶的费用构成和访问结构也各不相同。过去，“上个月账单为何突然上涨 30%？”或“哪些对象近 90 天未被访问，转为归档能节省多少费用？”这类问题需要跨多个系统才能计算清楚。

现在，TOS Agent 会自动拉取账单与计量数据，识别异常波动并归因分析，同时洞察访问热点与冷热分布情况，最终提供一份结构化的洞察报告及可落地的优化建议。生命周期策略、归档机制、加速服务、QoS 保障等功能均包含在内——“数据”不再仅仅是被查询的对象，而是转变为能主动解释并提供建议的洞察对象。

「素材探しから制作、そして保存まで」を一つの流れで完結させる

これが TOS Agent が持つ最も想像力豊かなユースケースです。

コンテンツの理解と処理能力を連携させ、「素材を探す→制作する→成果物を保存する」という一連のプロセスを、単なる会話の中で完結させます。多角的な意味解析に基づき、膨大な素材の中から指定された条件に合致する画像や動画クリップを即座に検索します。

さらに生成機能を活用して画像の加工や透入（ウォーターマーク）の実行も可能。完成した成果物は自動的に指定されたストレージバケットへ保存され、既存の権限設定やガバナンスポリシーがそのまま引き継がれます。その後の業務フローにも直ちに活用可能です。

メディア資産管理、EC、マーケティングチームにとって、素材生産のワークフローは「複数のツールを行き来してファイルを転送する」という煩雑な作業から、「会話の中で要件を伝えるだけ」へと劇的に簡素化されます。

「対話型ワークステーション」を実用化するための 4 つの重要メカニズム

編成可能なエージェントは数多く存在しますが、顧客がオンライン上の生産業務を任せるためには、「モデルがいかに賢いか」という点よりも、長期的な協働、記憶の連続性、権限の境界、そして動作の安全性という 4 つの能力がすべて確実であることが不可欠です。

TOS Agent はこの 4 つの能力においてそれぞれ针对性的な設計を施しており、これが Storage Agent Family に属するすべてのメンバーが遵守すべき最低ラインとなっています。

無制限のアクティブセッション数

従来のインテリジェントアシスタントは、固定されたセッションリソースに制約されることが多く、セッション数を増やすと待ち行列が発生したり、自動的に回収されたりします。

TOS Agent は TOS のネイティブな分散アーキテクチャを活用してセッションを処理するため、アクティブなセッション数に上限を設けていません。「異常の調査」「月次のコスト精算」「素材の整理」など、目的ごとに独立したセッションを複数開き、互いに干渉させながら並行実行が可能です。途中で中断しても、次回再開すればその続きから作業を進められます。

この点は大規模な制作チームにとって特に重要です。数百人、数千人のクリエイターが同時にワークステーションを開いても、全員が独立したセッションを持ち、接続が切れることはありません。「誰かが使用中だから」という理由で処理速度を落とされたり、強制的に切断されたりすることはありません。

ユーザーレベルの長期記憶

ワークステーションは、各ユーザーごとに独立した長期記憶空間を維持し、セッションを超えた嗜好や文脈情報を蓄積します。

頻繁に利用する地域、命名規則、暗号化と権限のベースライン、コスト計算の基準など、これらすべてが記憶され、後のタスクで自動的に再利用されます。記憶への記録、検索、アーカイブはサーバー側で一元的に管理されるため、自然言語による操作が可能です。裏側の技術実装を気にする必要はありません。

毎回背景から説明し直す必要はなく、使い込むほどにユーザーの好みを理解していきます。

ユーザー権限がすべての実行を貫く

これがワークステーションのセキュリティモデルの中核です。タスクを発行したユーザーの認証情報は、そのタスク内で Agent がトリガーするあらゆる動作に付随します。クエリの実行や設定変更、データの読み書きに関わらず、Agent が呼び出すすべてのツールは、必ずユーザーの権限情報を保持して実行されます。

つまり、Agent ができることは「ユーザー本来が許可されていること」のサブセットに限定され、「Agent に任せたからといって」権限を超えてアクセスできないリソースが存在することはありません。能力は拡大しますが、権限の境界線は微動だにしません。

実行の安全装置：コミット、事前検証、段階的制御

書き込み操作では、「まずコミットし、その後で実行する」ルールが適用されます。モデルが「作成」「変更」「削除」「上書き」「一括処理」といった書き込みリクエストと認識すると、即座に実行するのではなく、必ずフロントエンドにアクションを提示します。

「何をしようとしているのか」「どのリソースに影響するのか」「どのような結果を招く可能性があるのか」を明確に示し、ユーザーの承認を得てから初めて実際に実行されます。

コミットプロセスに加え、ワークステーションにはさらに複数の安全装置が重ねられています。例えば、取り消しが不可能な削除動作に対しては、影響範囲を事前に提示して二次確認を求めるようになっています。書き込みにおいては、誤った上書きを防ぐため「存在しない場合にのみ作成する」というセマンティクスを採用しています。また、設定変更やストレージタイプの転換などの操作では、実行前にシミュレーション（Dry-Run）を実施します。

API の動作は読み取り、書き込み、削除の 3 つに分類され、それぞれ異なるレベルで管理されています。特にリスクの高い動作については、より厳格な確認プロセスが求められます。

ワークステーションには自動実行機能も備わっていますが、「承認ボタンを押す権限」は常にユーザーの手元に戻されています。

さらに上位のレイヤーでは、このワークステーションをパッケージ化して多数のエンドクライアントに販売する際にも、TOS Agent は TOS のネイティブ機能を活用し、マルチテナントの分離を即座に実現します。各顧客には専用スペースが割り当てられ、作業空間、セッション、記憶領域、利用枠などが完全に隔離されます。これにより、単一のワークステーションで数百から数千ものクライアントをサポートすることが可能になります。

TLS Agent：可観測性分析の専門家

TLS Agent はファミリーの2番目のメンバーです。ログサービスチームが独自に開発したもので、TOS Agent とは並行する開発ラインを辿っていますが、ユーザー体験は統一されており、同じファミリーから生まれた製品です。

クラウド上のログサービスは、ログ、トレース、メトリクス、および各種マシンデータの受入と保存分析の基盤として機能し、その能力は包括的です。しかし、業務上の問題の観測や診断には依然として専門家の経験が不可欠です。新規ユーザーは各機能が何を解決するものか、どこから着手すべきかを理解する必要があります。一方、熟練したユーザーでさえも複雑なシナリオでは、検索分析クエリの作成、関連ドキュメントの参照、問題分析ステップの分解といった作業を強いられます。

TLS Agent は利用のハードルを下げることを目指し、観測可能な情報を行動可能な洞察へと変換します。これにより、ユーザーは単に「ログを見つける」段階から、「システム現象を理解する」段階へと進化できます。

もちろん、Text2SQL だけで実現できるわけではありません。日志服务团队（ログサービスチーム）が取り組んでいるのは、Agent をログサービスのワークフローに組み込むことです。

全体として、この仕組みは3 つの能力層に分解されます。探索可能な知識基盤、実行可能な作業環境、そして注意を分析へと引き戻すためのガイドメカニズムです。

探索可能な知識基盤：LLMWiki

ログ分析には、製品知識だけでなくユーザーの業務知識も必要です。サービストポロジー、インターフェースの意味、エラーコード、アラートルール、過去の障害事例、チームの標準手順（SOP）など、これらは往々にしてユーザー独自のドキュメントや経験の中にしか存在しません。

単にすべてのドキュメントをスライスしてベクトル検索を行えば、想起結果が不安定になる恐れがあります。結果が多すぎればノイズとなり、少なすぎれば重要な情報が抜け落ちてしまいます。TLS Agent は LLMWiki を活用し、知識ベースを探索可能な空間として構築します。一度に断片をコンテキストに詰め込むのではなく、タスクの段階に応じて順次探索を進めます。まず知識の範囲とディレクトリを限定し、次にファイル名やタイトル、該当する断片を確認した上で、価値が確認できた場合にのみ原文を読み込みます。

グラフ構造は「類似検索ではヒットしないケース」を補完します。これはモデルに対して、「なぜこのドキュメントが関連している可能性があるのか」「いつ続きを読むべきか」を示唆します。RAG（Retrieval-Augmented Generation）は単に「類似したテキストの一部を見つける」ことから、「より小さく、精度が高く、説明可能な分析コンテキストのセットを見つける」へと進化します。

長期記憶もこのクローズドループの一部です。一度分析が完了し確認されれば、その業務背景、一般的な問題、リソースへの嗜好、トラブルシューティングの経路は自動的に蓄積されます。次回同様の問題が発生した際、Agent はゼロから理解する必要なく正確に分析を行うことができます。

実行可能な作業環境：Sandbox

観測分析の多くのタスクは、モデルのコンテキスト内だけで完結させることはできません。Agent には、クエリの実行や検証スクリプトの実行、結果のプログラム処理を支えるための、真で安定した制御された実行環境が必要です。

TLS Agent は TLS CLI を統一された能力入口として採用しています。TLS API がカバーするリソースとアクションは多岐にわたりますが、もし各 API をモデルが認識できるツールとして個別にパッケージ化すれば、ツールリストは瞬く間に肥大化してしまいます。CLI を採用することで、Agent はエンジニアのように振る舞い、コマンドのグループ化やサブコマンド、ヘルプ情報を通じて段階的に製品能力を把握できるようになります。

CLI を選んだ以上、ターミナルも必要です。Sandbox は Agent に対して安定した作業台を提供します：

沙箱環境はコマンドの実行、中間ファイルの保存、出力の読み取りをサポートし、失敗した場合は自動的に調整して再試行します。各スキルにはプロンプトやツール呼び出しに加え、検証スクリプトが標準で備わっています。これにより、返されたフィールドが完全か、時間範囲が適切か、集計基準が期待通りか、クエリ結果が現在の結論を裏付けられるかなどを確認できます。Agent は「一見もっともらしい答え」を生成するのではなく、沙箱内で検証を行い、問題を発見して再試行します。

大量のログ検索におけるフィルタリング、集約、TopN 抽出、トレンド分析といった計算負荷の高い処理は、優先的に TLS 検索分析エンジンに下推されます。Agent が大規模計算をモデルで代替する必要はありません。もし結果の量が依然としてコンテキストに入りきらない場合、Agent は沙箱内で rg や Python を活用してフィルタリング、集計、サンプリング、検証を行い、より小さく重要な事実だけをモデルに渡して表現させます。「サンプルの観察」を「全体の結論」として扱うことはしません。

コンテキストによる注意の誘導：重要な制約への回帰

完全なログ分析には多段階の対話が必要です。問題の確認、リソースの理解、知識の読み込み、クエリの生成、ツールの実行、経路の修正などです。コンテキストが長くなると、モデルは中間情報に流されやすく、当初の分析目標や時間範囲、フィルタ条件を見失いがちです。

TLS Agent は注意誘導モジュールを備えており、ルールに基づいて重要な情報を注入します。これは Agent の意思決定を代替するものではなく、重要な局面で失われやすい制約をモデルの視野に再び戻す役割を果たします。

• 「情報収集」から「クエリ生成」へ移行する際、元のユーザー要求を再提示し、目標・時間範囲・フィルタ条件の確認を促します。
• 負荷の高いクエリを実行する前に、Agent に範囲の収束を促し、時間ウィンドウ、インデックスのヒット数、返却行数、クエリ効率への注目を呼びかけます。
• トレンド分析や集約、異常検知に関わる場合は、結論が検索分析能力に基づいていることを確認させ、単なるサンプル数に依存しないように導きます。

こうした誘導は一見軽微に見えますが、長期的なタスクの安定性には不可欠です。

内部実践：実際のトラブルシューティング事例

仕組みをいくら説明しても、具体例を見る方が理解しやすいでしょう。以下は2つの実例です。

• 「この収集ルールが深夜に変更され、ログが消えました。人為的な操作かどうか、その理由も確認してください」
• 「過去12時間のデータ加工タスクにインデックスへの登録遅延が発生しています。どの段階で遅延が生じたか分析してください」

事例1 | 操作の追跡：ユーザーは深夜に変更された収集ルールによりログが消失したと報告し、人為的な変更かどうかとその理由を確認したいと考えています。

TLS Agent は、ユーザーから提供されたプロジェクト名、トピック、収集設定などのコンテキストを統合し、該当する操作記録を特定します。出力には修正時刻、使用されたインターフェース、操作者、ソース、影響を受けたリソースなどが含まれます。これにより、トラブルシューティングは「誰が設定を変更したのか推測する」段階から、「操作証拠に基づいて影響と解決策を分析する」段階へと移行します。

事例2 | 遅延の帰属：ユーザーは過去12時間にインデックス登録の遅延が発生したと報告しています。

Agent はタスク ID、ソーストピック、時間範囲を組み合わせることで内部ログを検索し、遅延が「ソース側での消費復旧フェーズ」に集中していることを特定しました。具体的には、消費者のハートビートが期限切れになった際にワーカーがバッチで再構築され、タスクが回復した後に処理が続行されます。継続的な書き込みのブロックや実行エラーは検出されていません。

この分析により、「入库（データ取り込み）が遅い」という問題を検証可能な段階と証拠に分解し、単なる一時的なジッターなのか、それとも連鎖的なボトルネックを追跡すべきなのかを判断しやすくしています。

こうした分析のたびに、確認済みの業務背景や一般的な課題、リソースへの嗜好、トラブルシューティングの経路が長期記憶に蓄積されます。次回同様の問題が発生した際も、ゼロから説明する必要はなくなります。同じチーム、同じシステムに対する Agent の理解は、利用を重ねるごとに安定して深まっていきます。

Storage Agent Family の一貫性

2 つのメンバーを紹介したので、Storage Agent Family が顧客にもたらす価値を 3 つのポイントにまとめます。この家族に新たに加わるすべての Storage Agent は、以下の原則に従います。

一貫した操作リズムで、再学習は不要です。

TOS Agent でも TLS Agent でも、会話の入口、データ範囲の選択方法、結果の表示形式、「まず範囲を指定し、次に会話を始め、危険な動作は事前に確認する」という流れはすべて同じです。製品が変わっても使い方を学び直す必要はありません。「1 つ覚えれば、すべての製品で活用できる」を実現した最たる例と言えます。

一貫した安全基準で、安心してタスクを任せられます。

リスクレベルを 3 つに分類し（読み取りは即時実行、書き込みは二重確認、破壊的動作は自動実行を拒否）、ユーザーの認証情報をすべての操作に適用します。また、書き込み操作では必ず「コミット」してから実行し、データ範囲を制限するフェンスを設定し、実行前に権限を検証します。これらはオプションではなく、家族共通の必須条件です。TOS Agent も TLS Agent も同様で、今後追加されるメンバーもすべてこれを満たす必要があります。

使い込むほどにシステムを理解します。

各タスクでユーザーが確認した業務背景やトラブルシューティングの経路、リソースへの嗜好は、そのユーザーの長期記憶として保存されます。次のタスクでは自動的に呼び出されます。これはすべての Storage Agent に共通する機能です。利用期間が長くなるほど、Agent はあなたのチームとシステムをより正確に理解できるようになります。

さらに、家族全体で外部インターフェースを統一しており、プラグインのように追加の Storage Agent を簡単に接続できます。ある製品内で別の製品に関する質問をした場合も、自動的に遷移を案内して途切れさせません。

おわりに

「ストレージを効果的に使う」ためには、従来はコンソールの仕組みを深く理解し、SDK を使いこなし、ベストプラクティスを丸暗記する必要がありました。

今では、言葉が通じるパートナーがいます。複数の手順を自動で編成したり、異常の根本原因を特定したり、コストとインサイトを一度に確認したり、長時間のタスクや長期記憶を安定して運用したりできます。そして、この優れた体験はすべてのストレージ製品で一貫しています。

Storage Agent Family に TOS Agent と TLS Agent が登場しました。vePFS、EFS、EBS、MQ の各製品向け Agent も順次リリース予定です。

これらは一貫した「家族の約束」に基づいて設計されており、今後は二つの方向へ進化します。一つは対象製品の拡大と利用シーンの広がりです。もう一つは、Agent と作業環境をより深く統合し、人間と Agent が同じ空間で協働できる体制を整えることです。これにより、ドキュメント、管理コンソール、チャット画面を行き来する手間がなくなります。

火山引擎 Storage Agent Family は、すべてのストレージ製品に「その製品を理解し、ユーザーのニーズも理解する」専門家を備えさせることを目指しています。一つ覚えるだけで、あらゆる製品を効果的に活用できるのです。