Claude Files APIのfile_idセキュリティリスクと対策

Files APIでアップロードしたファイルは、アップロードしたAPIキーだけでなく、同じワークスペースに属するすべてのAPIキーからfile_id経由でアクセスできます。ユーザーから受け取ったfile_idをそのままAPIに渡す実装は、他のユーザーのファイルを読ませてしまう典型的な脆弱性になります。

Files APIのfile_idはどこまで共有されるか

Files APIとは、ファイルを一度アップロードしてfile_idで繰り返し参照できるAnthropicの仕組みです。アップロードしたファイルは、エンドユーザー・会話・セッションのいずれにも紐づきません。紐づく単位はワークスペースです。

同じワークスペースへのアクセス権を持つAPIキーであれば、どのキーもそのワークスペースにアップロードされたファイルをfile_idで参照できます。組織のロールでAPIアクセスが許可されているユーザーとサービスアカウントは、割り当てられたワークスペースに加えてDefault Workspaceも使えます。つまりDefault Workspaceにアップロードしたファイルは、意図せず広い範囲から見えている可能性があります。

APIキーには単一ワークスペースキーと複数ワークスペースキーの2種類があります。単一ワークスペースキーは、作成時に選んだワークスペースだけで動作し、そのワークスペース以外のfile_idを渡してもアクセスできません。複数ワークスペースキーは、リクエストごとにanthropic-workspace-idヘッダーで対象ワークスペースを指定して使い回せます。ファイルの隔離を確実にしたいなら、テナントや用途ごとに単一ワークスペースキーを分けて発行するほうが、複数ワークスペースキーの運用よりヘッダー指定ミスの余地が小さくなります。

file_idをそのまま受け取るとどうなるか — 具体的な失敗シナリオ

マルチテナントのアプリケーションを想定します。ユーザーAが資料をアップロードし、アプリはAnthropicから返ってきたfile_idをレスポンスとしてそのままクライアントへ渡します。ユーザーBが何らかの経路でそのfile_idを手に入れ、自分のリクエストに含めてアプリのバックエンドへ送ります。

バックエンドがfile_idの持ち主を確認せず、そのままAnthropic APIのfile_idとして使い回すと、ワークスペースが同じである限りリクエストは成功します。ユーザーAの資料が、ユーザーBに読まれてしまいます。file_idは、ユーザーとファイルの対応関係を保証しません。対応関係は自分のアプリケーション側で管理する責任があります。

この失敗は、file_idを「持っていれば正当な所有者」という前提で扱ったときに起きます。file_idはサーバー側の参照として扱い、エンドユーザーから直接受け取らない設計が安全側です。

同じ構造の問題は、エラートラッキングツールのログや共有ドキュメントにAPIレスポンスをそのまま貼り付けたときにも起きます。file_idがどこかへ漏れれば、それを使ったリクエストは正規の持ち主からのリクエストと区別なく成功します。公式ドキュメントも、file_idを外部から信頼できない入力として受け取らないよう明示的に注意を促しています。

マルチテナントでの防ぎ方 — 運用規模別の早見表

対策は運用規模によって変わります。

ワークスペースは、テナント間でファイルを隔離する境界として機能します。テナントごとにワークスペースを分け、そのワークスペースに限定したAPIキー(単一ワークスペースキー)を発行すれば、あるテナントのfile_idを別のテナントのキーで参照することはできません。複数ワークスペースにアクセスできるキーを使う場合は、リクエストごとにanthropic-workspace-idヘッダーで対象ワークスペースを明示する運用になります。ヘッダーの指定ミスが、そのまま越境アクセスにつながる点に注意します。

file_idがどのワークスペースに属するか確認する方法

file_idそのものからは、どのワークスペースのファイルかを見分けられません。確認するには、そのfile_idを使ったAPIリクエストのレスポンスヘッダーを見ます。Claude APIのレスポンスにはanthropic-workspace-idヘッダーが必ず含まれ、そのリクエストが解決したワークスペースのIDが分かります。この値がDefault Workspaceかどうかは、Admin APIのGet Workspaceエンドポイントで照合できます。Default Workspaceは"name": "Default"で返ります。

運用の初期段階で、file_idの発行元ワークスペースをログへ残しておくと、後から「どのテナントのファイルか」を突き合わせる作業が楽になります。ワークスペースIDそのものはAdmin APIキーで一覧取得できるので、テナントとワークスペースIDの対応表をアプリ側に持っておくと、事故発生時の切り分けが早くなります。

file_idの扱いでよくあるつまずき

file_idをレスポンスでそのままクライアントに返してしまう

アップロード成功時のレスポンスに含まれるfile_idを、そのままフロントエンドへ渡す設計は避けます。フロントエンドが持つべきはアプリ独自のファイルIDで、Anthropic側のfile_idはバックエンドだけが扱う内部参照に留めます。

Default Workspaceの扱いを見落とす

ワークスペースを個別に作っていても、組織ロールでAPIアクセス権を持つユーザーとサービスアカウントは全員がDefault Workspaceも使えます。ここへ直接アップロードすると、意図した隔離が効きません。

削除直後に「もう見えない」と思い込む

削除したファイルはAPIから間もなくアクセスできなくなりますが、進行中のMessages API呼び出しや関連するツール呼び出しには一時的に残ることがあります。削除は取り消せませんが、即座の消去を保証するものではありません。

監査ログが最初から有効だと思い込む

Compliance APIは既定で有効ではありません。有効化する前の操作は記録されておらず、後から遡って調べることもできません。file_idの誤用を追跡したい場合は、実装の初期段階でCompliance APIを有効にしておきます。

複数ワークスペースキーを1つだけ発行して使い回す

テナントを増やすたびにワークスペースを作っても、アプリ側で複数ワークスペースキー1本を使い回し、リクエストごとにanthropic-workspace-idを切り替える実装は珍しくありません。この場合、ヘッダーの値を取り違えるコードパスが1箇所でもあれば、別テナントのワークスペースへアクセスしてしまいます。テナントごとに単一ワークスペースキーを分ければ、この種の取り違えはキーの選択ミスとして早期に検出できます。

なぜAnthropicはfile_idをユーザー単位でスコープしなかったか

file_idをワークスペース単位で共有する設計は、欠陥ではなく選択です。Files APIだけでなく、Message BatchesやSkillsも同じくワークスペース単位でスコープされています。API全体で一貫した隔離モデルを採用し、ユーザーやセッションといったアプリケーション固有の概念をAPI側に持ち込まない設計だと読めます。

この設計は、同じファイルを複数のリクエスト・複数の会話から安く使い回せる利点と引き換えに、ユーザーとファイルの対応関係をアプリケーション側の責任に置きます。ワークスペースより細かい粒度の隔離が必要なら、テナントごとにワークスペースを分けるという1段上の設計判断が必要になります。file_idを直接ユーザーへ渡さない実装さえ守れば、この設計自体が特に扱いにくいわけではありません。

仮にfile_idがユーザー単位でスコープされる設計だったとしても、それはそれで別の負担を生みます。ユーザーが退職・削除されたときにファイルをどう引き継ぐか、複数ユーザーで同じファイルを共有する運用をどう表現するかといった論点が、今度はAPI側の仕様として固定されてしまいます。ワークスペースという1段粗い単位に留め、その内側の割り当てをアプリケーション側の裁量に残す設計は、ユースケースの幅を狭めない選択とも言えます。

Files APIの容量上限や削除・失効までのライフサイクルはClaude Files APIの容量上限とファイルライフサイクルにまとめています。Anthropic API全体の料金・モデル選びはAnthropic API完全ガイドを参照してください。

まとめ

Files APIのfile_idは、ユーザー・会話・セッションではなくワークスペース単位で共有されます。同じワークスペースに属するAPIキーであれば、アップロードした本人以外からもファイルへアクセスできます。ユーザー入力のfile_idをそのままAPIへ渡す実装は、他ユーザーのファイルを読ませる失敗の典型パターンです。file_idをクライアントに直接渡さずアプリ側で対応関係を管理すること、マルチテナントならテナントごとにワークスペースとAPIキーを分けること、Compliance APIで操作ログを残すこと。この3点が実務上の防ぎ方になります。