Files SDK icon

Files SDK

Files SDK は、S3、R2、GCS、Azure Blob Storage などに対応する統合 TypeScript ストレージ SDK。1つの一貫した API で、プロバイダー切り替え時も同じ呼び出しを使えます。

Files SDK

オブジェクト/blob バックエンド向けの統合ストレージ SDK

Files SDK は、S3、R2、GCS、Azure Blob Storage などのオブジェクト/blob バックエンドに対応する統合 TypeScript ストレージ SDK です。AWS S3、Cloudflare R2、Google Cloud Storage、Azure Blob Storage、そのほか互換サービスに対して 1つの小さな API を提供し、バックエンドが変わっても同じ呼び出し箇所を再利用できます。

この製品は、アップロード、ダウンロード、head、list、delete、copy、move、URL 生成、署名付きアップロードなどの標準操作を備えた `Files` クラスを中心に構成されています。さらに、大規模またはより専門的なワークフロー向けに、multipart upload、リアルタイムの進捗コールバック、byte-range 読み取り、キーによる検索、インスタンス間の transfer と sync、CLI、エージェント向けファイルツールも提供します。プロバイダー固有の挙動が必要な場合は、ドキュメントでネイティブクライアントに戻る型付きの `files.raw` エスケープハッチが案内されています。

機能

統一されたストレージ操作

SDK は、`upload`、`delete`、`exists` などの一括処理に向いた呼び出しを含む、一般的なストレージ操作向けのコンパクトな `Files` サーフェスを提供します。さらに、`listAll`、`url`、`signedUploadUrl`、およびより狭い用途向けのキー固定ハンドル `file(key)` も追加されています。

キー ভিত্তの検索

`search()` は、glob、正規表現、部分一致、完全一致でキーを使ってオブジェクトを検索します。結果は async iterable としてストリーミングされ、glob 検索では不要なキーを走査しないようにバケットの探索範囲を prefix で絞り込みます。

進捗付き multipart upload

`upload()` は、大きな本文やサイズが未確定の本文に対する multipart upload、制限付き並行処理、設定可能な part サイズをサポートします。同じ操作で、単体または一括アップロードの byte レベル進捗を `onProgress` で報告することもできます。

Byte-range ダウンロード

Range request は HTTP 206 に対応し、オブジェクトの一部だけを読み取れます。ドキュメントでは、動画のシーク、再開可能なダウンロード、ファイル全体を取得せずにヘッダーを読む用途が挙げられています。

エージェントと CLI のワークフロー

SDK には、Vercel AI SDK、OpenAI Agents、Claude、MCP 向けのすぐ使えるファイルツールが含まれます。さらに、stdin/stdout を流し、既定で JSON を出力する CLI も同梱されています。

バックエンド切り替えとエスケープハッチ

アダプタ層は多くのプロバイダーをカバーしており、コアのドキュメントでは、バックエンド固有のクライアントが必要な場合に `files.raw` を使う型付きエスケープハッチが強調されています。API は、`Files` インスタンス間でデータを移すための `transfer` と `sync` もサポートします。

ユースケース

  • プロバイダー間でストレージ呼び出しを標準化する

    サポートされているプロバイダー間で、同じコードパスを使ってアップロード、ダウンロード、メタデータ確認、ファイル一覧、オブジェクト削除を行います。ストレージバックエンドをアプリケーションロジックを書き換えずに切り替えたいチームに最適です。

  • キーのパターンでファイルを見つける

    正確なキーではなく命名パターンでファイルを見つけたいときに `search()` を使います。ドキュメント化された glob、regex、部分一致、完全一致のオプションにより、請求書バケット、ログフォルダ、その他の構造化されたキー空間に適しています。

  • 進捗付きで大容量アップロードを扱う

    大きなファイル、ストリーム本文、または進捗表示が必要なユーザー向けアップロードには、multipart upload と `onProgress` を使います。SDK では、これらのフローに対して制限付き並行処理と設定可能な part サイズが案内されています。

  • 部分コンテンツを効率的に読む

    ファイルヘッダー、動画の一部分、再開可能なチャンクなど、オブジェクトの一部だけが必要な場合は byte-range ダウンロードを使います。ドキュメントでは ranged read を HTTP 206 に明確に対応付けています。

  • アプリ外でファイル操作を自動化する

    ファイルをスクリプト、CI ジョブ、または AI ワークフローから操作する必要がある場合は、CLI またはエージェントツールを使います。ソースでは、JSON 出力、stdin/stdout ストリーミング、承認ゲート、エージェント利用向けの read-only モードが説明されています。

Pros and Cons

Pros

  • 1つの API で多くのバックエンドに共通するストレージ操作を扱えるため、プロバイダー固有の書き直しを減らせます。
  • サーフェスは意図的に小さく一貫しており、共有エラーモデルと、timeout、retries、cancellation などの操作ごとのオプションがあります。
  • search、multipart upload、リアルタイム進捗、byte-range 読み取りが、ドキュメント化されたワークフローに組み込まれています。
  • SDK には CLI とエージェント向けファイルツールの両方が含まれており、アプリケーションコード以外にも用途が広がります。
  • アダプタシステムにより、プロバイダー SDK は subpath exports として遅延読み込みされ、`files.raw` もバックエンド固有アクセスが必要なときに型付きのまま使えます。

Cons

  • 料金は提供されたソースでは確定できません。料金ページは 404 を返しており、ここで確認できる公開サイトの根拠ではコストモデルは裏付けられていません。
  • 一部のアダプタ固有機能は、依然として `files.raw` を通じたネイティブクライアントを必要とするため、統一 API だけではすべてのプロバイダー機能を直接カバーしません。

FAQ

Files SDK は誰向けですか?

S3、R2、GCS、Azure などのオブジェクト/blob バックエンドに対して、1つの TypeScript ストレージ API が必要なアプリケーション向けです。ドキュメントでは、プロバイダー固有の動作が必要な場合に使える、エージェント向け CLI と型付きのネイティブクライアントへのエスケープハッチも説明されています。

コア API はどのような形ですか?

ドキュメントでは、`Files` インスタンスに 10 個のメソッドを持つ小さな統一サーフェスと、キーに紐づくハンドルとしての `files.file(key)` が示されています。API には `upload`、`download`、`head`、`exists`、`delete`、`copy`、`move`、`list`、`url`、`signedUploadUrl` に加え、グローバルな `transfer` と `sync` ヘルパーが含まれます。

プロバイダー固有の機能も使えますか?

はい。アダプタのドキュメントでは、一部のバックエンドは共有 API から直接読み書きできる一方で、バージョニング、ライフサイクルルール、multipart の挙動、ACL などのプロバイダー固有機能は `files.raw` ിലൂടെ利用でき、これはアダプタごとに型が保たれると説明されています。

Files SDK にコマンドラインインターフェースはありますか?

ソースには、既定で JSON 出力、stdin/stdout ストリーミング、バックエンド切り替え用の `--provider` フラグを備えた CLI が示されています。スクリプト、CI、単発の操作向けに位置づけられています。

Files SDK の価格はいくらですか?

収集されたソース内の料金ページは 404 で、価格やプラン構成は示されていません。そのため、ここで確認できる公開サイトの根拠では料金の詳細は確定できません。

Quick Facts

カテゴリ
開発者向けツール
主なプラットフォーム
TypeScript / JavaScript
バックエンド
S3、R2、GCS、Azure Blob Storage、その他多数のアダプタ
ソースドメイン
files-sdk.dev
コアモデル
10 個の統一メソッドを持つ 1つの `Files` クラス
価格
提供されたソースでは未記載