AIエージェントは、ディレクトリをナビゲートしたりファイルパスを読み取ったりするための標準的なツールを使って、ファイルシステム上で動作します。
しかし課題は、オブジェクトストレージシステム、とりわけAmazon S3には大量のエンタープライズデータがあることです。オブジェクトストアは、ファイルパスではなくAPI呼び出しによってデータを提供します。このギャップを埋めるには、S3と並行して別のファイルシステム層を用意し、重複したデータと同期パイプラインを構築して、両者の整合を保つ必要がありました。
The rise of agentic AI makes that challenge even harder, and it was affecting Amazon's own ability to get things done. AmazonのAWSエンジニアリングチームは、KiroやClaude Codeのようなツールを使って、同じ問題に突き当たり続けました。エージェントはデフォルトでローカルのファイルツールを使うのに、データはS3にありました。エージェントのコンテキストウィンドウが圧縮され、セッション状態が失われるまでは、ローカルにダウンロードすることでうまくいっていました。
Amazonの答えはS3 Filesです。ワンクリックではなく単一コマンドで、任意のS3バケットをエージェントのローカル環境に直接マウントします。データはS3のままで、移行は不要です。裏側では、AWSがElastic File System（EFS）の技術をS3に接続し、回避策ではなく、完全なファイルシステムのセマンティクスを提供しています。S3 Filesは現在、ほとんどのAWSリージョンで利用可能です。
"S3内のデータを、ローカルファイルシステムの一部であるかのように、すぐに利用できるようにしたことで、KiroやClaude Codeのようなものがそのデータで作業できる能力が大きく加速するのを実感しました," とAWSのVP兼ディスティングイッシュト・エンジニアであるAndy Warfield氏はVentureBeatに語りました。
ファイルストレージとオブジェクトストレージの違い、そしてそれが重要な理由
S3は、オブジェクト単位での耐久性、スケール、APIベースのアクセスのために構築されました。これらの特性により、エンタープライズデータの標準的なストレージ層になりました。ですが同時に、開発者やエージェントが依存するファイルベースのツールとの間に、根本的な非互換性も生み出しました。
"S3はファイルシステムではありませんし、さまざまな面でファイルのセマンティクスも持っていません," とWarfield氏は述べています。 "オブジェクトの移動はできませんし、アトミックな移動もできません。また、S3には実際のディレクトリがありません。"
これまでそのギャップを埋めようとする試みは、FUSE（Filesystems in USErspace）に依存していました。FUSEは、基盤となるストレージを変更せずに、ユーザースペースへカスタムのファイルシステムをマウントできるソフトウェア層です。AWS自身のMount Point、Googleのgcsfuse、Microsoftのblobfuse2といったツールはすべて、FUSEベースのドライバを使って、それぞれのオブジェクトストアをファイルシステムのように見せていました。
Warfield氏は、問題はそれらのオブジェクトストアが依然としてファイルシステムではない点だと指摘しました。これらのドライバは、バケット内に追加のメタデータを詰め込んで擬似的にファイルの振る舞いを作ることでオブジェクトAPIの見え方を壊すか、あるいはオブジェクトストアが対応できないファイル操作を拒否するかのどちらかでした。
S3 Filesは、まったく別のアーキテクチャを採用しています。AWSはEFS（Elastic File System）の技術をS3に直接接続し、S3を記録の正本（system of record）として維持しつつ、完全なネイティブのファイルシステム層を提示します。ファイルシステムのAPIとS3のオブジェクトAPIの両方が、同じデータに対して同時に利用可能です。
S3 Filesがエージェント型AIをどのように加速するか
S3 Files以前は、オブジェクトデータを扱うエージェントが、ツールを使う前に明示的にファイルをダウンロードするよう指示される必要がありました。これはセッション状態の問題を生みました。エージェントがコンテキストウィンドウを圧縮するにつれて、ローカルにダウンロードされた内容の記録が失われがちでした。
"データがローカルで利用可能だということを、エージェントに思い出させる必要が出てきてしまいました," とWarfield氏は語っています。
Warfield氏は、ログ分析という一般的なエージェントタスクについて、「導入前」と「導入後」を説明しました。開発者がKiroやClaude Codeを使ってログデータを扱う場合、オブジェクトのみのケースでは、ログファイルがどこにあるかをエージェントに伝え、そこからダウンロードするよう指示する必要がありました。ところが、ログがローカルファイルシステムにすぐマウントできるなら、開発者はログが特定のパスにあることを示すだけで済み、エージェントは即座にそれらを辿ってアクセスできます。
複数エージェントのパイプラインでは、複数のエージェントが同じマウント済みバケットに同時にアクセスできます。AWSは、単一のS3ファイルシステムに同時に数千の計算リソースが接続でき、合計の読み取りスループットが毎秒複数テラバイトに達するとしています。これはVentureBeatが独自に検証できなかった数値です。
エージェント間で共有される状態は、標準的なファイルシステムの慣習によって機能します。すなわち、サブディレクトリ、ノートファイル、そしてパイプライン内の任意のエージェントが読み書きできる共有プロジェクトディレクトリです。Warfield氏は、AWSのエンジニアリングチームが社内でこのパターンを使っていると説明しました。エージェントは調査のメモやタスクの要約を共有プロジェクトディレクトリへ記録します。
共有エージェントコンテンツの上にRAGパイプラインを構築するチーム向けには、
