AIエージェントがPDFや画像を扱うと、ファイルの保存先までAI基盤に任せたくなります。しかし、ファイルを参照する file_id は、利用者を識別する権限証明ではありません。AnthropicのFiles APIドキュメントは、アップロードしたファイルの共有範囲を「会話」や「利用者」ではなくワークスペースだと明記しています。便利なIDと認可の境界を混同しない設計が必要です。
Files APIで何ができるのか
Files APIは、ファイルを一度アップロードし、返された file_id をMessages APIから繰り返し参照できる仕組みです。毎回同じPDFや画像を再送する必要がなく、コード実行で作った成果物のダウンロードにも使えます。
一方、公式ドキュメントには重要な注意があります。アップロードしたファイルはエンドユーザー、会話、セッション単位ではなく、ワークスペース全体からアクセス可能です。同じワークスペースのAPIキーは、そのワークスペース内のファイルへアクセスできます。
file_idは「ロッカー番号」であって鍵ではない
file_id はファイルを指す識別子です。たとえるならロッカー番号であり、本人確認に使う鍵ではありません。アプリが利用者から受け取った file_id をそのままClaude APIへ渡すと、別の利用者がアップロードしたファイルを参照させる余地が生まれます。
Anthropicも、エンドユーザーなど信頼できない入力元から file_id を受け取らず、利用者とファイルの対応関係をアプリ側のサーバーで管理するよう案内しています。
実装で守る4つの境界
- 所有者を自社DBで管理する：
file_id、利用者ID、テナントID、用途、作成日時を対応付けます。 - 参照時に認可する：ログイン中の利用者が、そのファイルを読む権限を持つか毎回確認します。IDが存在するだけでは許可しません。
- file_idをサーバー側参照にする：クライアントから任意のIDを受け付けず、自社DBで認可済みのIDだけをAPIへ渡します。
- 強い分離が必要ならワークスペースを分ける：Anthropicはマルチテナント用途で、テナントごとに別ワークスペースを作る方法を案内しています。APIキーも1つのワークスペースにスコープされます。
ワークスペースは組織あたり標準で最大100個です。テナント数が多い場合は、全顧客を機械的に1対1対応させる前に、データ機密度や契約要件に応じた分離単位を設計し、必要ならアカウント担当へ上限拡張を相談するのが現実的です。
保存期間も別の設計項目
アクセス制御が正しくても、保存方針が自動的に満たされるわけではありません。Files APIはZero Data Retention（ZDR、応答後に入力・出力を保存しない契約）の対象外です。公式ドキュメントでは、状態を保持するファイル系機能はZDRに適さないことが説明されています。
そのため導入時には、誰が読めるかに加えて、何をアップロードしてよいか、いつ削除するか、監査ログをどう残すかを決める必要があります。認可とデータ保持は、似て見えて別のチェック項目です。
なぜ重要か
プロジェクト初期は利用者が少なく、1つのAPIキーと1つのワークスペースでも問題が見えにくいものです。ところが業務展開すると、部署、顧客、機密区分の違いが一気に効いてきます。後から分離しようとすると、ファイル所有者の追跡やAPIキーの移行が大仕事になります。
車両開発でネットワーク境界を後付けしないのと同じで、AIのファイル境界もPoCの段階から決めるべきです。最初に「IDは住所、認可は通行許可」と分けておけば、モデルやAPIが変わっても設計原則は残ります。
まとめ
file_idはファイル識別子であり、利用者の認可情報ではありません。- Files APIのファイル共有境界はワークスペースです。
- 所有者管理と参照時認可はアプリ側で実装します。
- 強いテナント分離には別ワークスペースを使い、保存期間は認可と分けて設計します。
AIエージェントにファイルを渡す設計では、アップロード成功より先に「誰のファイルを、誰が、いつまで扱えるか」を決める。それが、PoCを業務システムへ育てるための地味ですが強い土台です。